Mobile App Development with Localization In Mind -…

移动应用程序开发与本地化铭记-...

2023-05-29 16:00 GALA

本文共1378个字,阅读需14分钟

阅读模式 切换至中文

Sign up for our newsletter on globalization and localization matters. It has long been known that mobile applications are a high-impact market, one that is still growing exponentially every year. It has also been long-standing knowledge that localization is an important marketing force multiplier, but is all too often overlooked and treated as an afterthought. Furthermore, implementing localization in something as complex as a mobile application presents a unique set of challenges with it: developers need to allocate extra time and effort in implementing a localization framework to enable the translation of the app content, project managers on both sides of the aisle need to work with non-trivial file formats and workflow requirements, and linguists need to deal with often-cryptic and confusing formats mandated by localization engines. My goal with this article is to help you understand how Flutter can support your team’s efforts not only by helping them build a more stable app but also by facilitating the interactions between the developers and other stakeholders such as copywriters and your translation agency of choice, all the while improving time-to-market and iteration speed. It does this not only by treating localization as a first-class citizen in its architecture, but also by using a file format that’s relatively easy to understand both for developers and other, less-technically-inclined stakeholders. For an overview of the most popular mobile frameworks, with a special eye for their localization support, check out our blog post “Mobile App Development with Localization In Mind- Part 1”. Complement this with our detailed article on using the Flutter framework in localization. One of the points of friction between software developers and LSPs is that the file formats that translators prefer to work with are usually not the same as those that developers are prepared to work with. This is usually because the two camps have very different use-cases for content, resulting in different requirements that don’t mesh well. However, Flutter’s Application Resource Bundle (ARB) format has the potential to be the bridge between these two shores. Implementing localization in a mobile app can involve multiple stakeholders, including developers, project managers, and linguists. Flutter's ARB format can streamline the workflow by providing a standardized and easy-to-understand format for managing app content translations. Developers can use familiar tools and techniques to create and manage ARB files, while project managers can easily coordinate translation efforts with linguists using CAT tools that support JSON files. This can lead to more efficient communication and collaboration between team members, reducing the likelihood of miscommunication or errors during the localization process. At its core, ARB is just a JSON (Javascript Object Notation, a relatively easy-to-read way of describing a given structure) which lends itself well to being edited by developers - since it’s the primary data exchange format of the world, almost all developers have at least some knowledge of it - while being relatively easy for “outsiders” such as copywriters as well to read and understand. This means that anyone can contribute to the app’s content, in a way that is easy to track and ensures that the translations are kept up to date as well (more on how this can be done later). Flutter's use of the ARB format as a flexible and standardized means of bridging language services providers (LSPs) can greatly improve interaction between your development team and your chosen translation vendor. Almost every CAT tool nowadays has some form of support for JSON files, which extends to ARB as well. This native support allows ARB files to be handled without the usual, time-consuming adaptation processes, saving time and money on both sides. Your developers don't have to go through complex procedures to provide your LSP with easily-handled files, while the LSP’s localization engineers don't need to spend extra time filtering and adapting the files for translation. By removing these extra steps, Flutter can greatly contribute towards a smoother workflow and a better relationship between your team and your LSP, not to mention the cost savings of avoiding unnecessary engineering hours. Because Flutter is built on a strongly-typed language (which essentially means that if you declare something to be a certain type, like a duck, you cannot then try to make it behave like another type, like a dog), it is immune to entire classes of bugs and errors that can plague developers working in other languages. Because the language works with your team to build a more secure and more stable application, your team can focus on the really important things, like building new features, instead of chasing a myriad of bugs. Furthermore, Flutter’s well-developed testing environment offers not only provides the ability to test the basic units of your application, but also the ability to test your app as it behaves on a real device, including how it looks and whether all content is visible on the screen (this is something I had to iterate on several times). With the appropriate setup, it is even possible to automatically take screenshots of the app during testing, not only for debugging purposes, but also for use as promotional material. Flutter also has advantages beyond the project management and interaction scopes too. In fact, it has even more to offer to developers and engineers who use it in their projects. Aside from the many technological advantages it has - which are beyond the scope of this article, but you can read more about them in this article’s companion piece - there are two in particular that should stand out for decision makers: its speed of iteration and its “Write once, run everywhere” nature. The ability to quickly and easily add new languages to a mobile app can significantly impact the time-to-market for international releases. Flutter's ARB format allows for efficient localization workflows, enabling development teams to easily create, manage, and update app content for multiple languages in parallel. This can help accelerate the localization process and reduce the overall time required to launch a localized app in new markets. Additionally, Flutter's hot-reloading feature allows for real-time updates and previews of app content changes, making it easier to iterate and fine-tune localized content during the development process. As most current frameworks do, Flutter also lends itself well to the automated test-build-deploy process of Continuous Integration/Delivery. Not only can its various forms of testing be automated and offloaded to external services, but it’s also quite trivial to offload the delivery process and create a pipeline where the entire value chain can be kicked off and run to completion, fully automated. Closely related to this, it’s even possible to integrate the localization step of the process into said pipeline. Since Flutter enforces the presence of localized content files for all languages the app declares support for, the build system can - and does - check for their presence at build-time, and fail the pipeline if one or more locales don’t exist. And with the right tools in hand, it’s even possible to automate the handoff of the content files to your language vendor (along with the retrieval of the translated content), freeing up valuable time to focus on what’s really important. After a thorough examination of Flutter, there are two noteworthy aspects that I would like to highlight. First, using Flutter can speed up the development process and, more importantly, accelerate the delivery of the product by incorporating the localization step into the process. This makes it easier to include localized content and ensures its presence in the final product. Second, Flutter streamlines the process by using a file format that is understood by both developers and translation companies, thus saving valuable engineering time that would otherwise be spent manually converting files between the two groups. Finally, for the more engineering-minded among you, there’s another article that focuses more on the developers’ perspective of Flutter strong points. You can read it via this link if you’re interested in another point of view. We’re always on the lookout for informative, useful and well-researched content relative to our industry. Write to us.
订阅我们的全球化和本地化新闻通讯。 众所周知,移动应用程序是一个高影响力的市场,每年仍在呈指数级增长。本地化是一个重要的营销力量倍增器,这一点也是长期以来的共识,但往往被忽视,并被视为事后的想法。此外,在像移动应用程序这样复杂的东西中实施本地化带来了一系列独特的挑战:开发人员需要分配额外的时间和精力来实现本地化框架,以实现应用程序内容的翻译,通道两侧的项目经理需要处理重要的文件格式和工作流程要求,语言学家需要处理本地化引擎所要求的通常是神秘和混乱的格式。 我写这篇文章的目的是帮助你理解Flutter如何支持你的团队的工作,不仅帮助他们构建一个更稳定的应用程序,而且促进开发人员和其他利益相关者(如文案和你选择的翻译机构)之间的互动,同时提高上市时间和迭代速度。它不仅将本地化视为其体系结构中的一等公民,而且还通过使用开发人员和其他技术倾向较低的利益相关者相对容易理解的文件格式来做到这一点。 有关最流行的移动框架的概述,特别关注其本地化支持,请查看我们的博客文章“移动应用程序开发与本地化-第1部分”。补充这一点,我们详细的文章在本地化中使用Flutter框架。 软件开发人员和LSP之间的一个摩擦点是翻译人员喜欢使用的文件格式通常与开发人员准备使用的文件格式不同。这通常是因为这两个阵营对于内容有着非常不同的用例,导致了不同的需求不能很好地结合。然而,Flutter的应用程序资源包(ARB)格式有可能成为这两个海岸之间的桥梁。 在移动应用程序中实现本地化可能涉及多个利益相关者,包括开发人员、项目经理和语言学家。Flutter的ARB格式可以通过提供标准化且易于理解的格式来管理应用程序内容翻译,从而简化工作流程。开发人员可以使用熟悉的工具和技术来创建和管理ARB文件,而项目经理可以使用支持JSON文件的CAT工具轻松地与语言学家协调翻译工作。这可以提高团队成员之间的沟通和协作效率,降低本地化过程中出现沟通不畅或错误的可能性。 在其核心,ARB只是一个JSON(Javascript对象表示法,一种相对容易阅读的描述给定结构的方式),它很适合开发人员编辑-因为它是世界上主要的数据交换格式,几乎所有开发人员都至少有一些知识-同时对于“局外人”来说相对容易阅读和理解。这意味着任何人都可以以易于跟踪的方式为应用程序的内容做出贡献,并确保翻译也保持最新(稍后将详细介绍如何做到这一点)。 Flutter使用ARB格式作为桥接语言服务提供商(LSP)的灵活和标准化方法,可以极大地改善您的开发团队和所选翻译供应商之间的交互。现在几乎每个CAT工具都对JSON文件有某种形式的支持,这也扩展到了ARB。这种原生支持允许处理ARB文件,而无需通常的、耗时的适配过程,从而节省双方的时间和金钱。您的开发人员无需通过复杂的程序来为LSP提供易于处理的文件,而LSP的本地化工程师无需花费额外的时间来过滤和调整文件以进行翻译。通过删除这些额外的步骤,Flutter可以为更顺畅的工作流程和团队与LSP之间的关系做出巨大贡献,更不用说避免不必要的工程时间节省成本。 因为Flutter是建立在强类型语言之上的(这意味着如果你声明了某个东西是某种类型,比如鸭子,你就不能试图让它表现得像另一种类型,比如狗),所以它不受可能困扰其他语言开发人员的各种bug和错误的影响。因为该语言与您的团队一起构建更安全、更稳定的应用程序,所以您的团队可以专注于真正重要的事情,比如构建新功能,而不是追逐无数的bug。 此外,Flutter开发良好的测试环境不仅提供了测试应用程序基本单元的能力,而且还能够测试应用程序在真实设备上的行为,包括它的外观以及所有内容是否在屏幕上可见(这是我不得不多次迭代的东西)。通过适当的设置,甚至可以在测试期间自动拍摄应用程序的屏幕截图,不仅用于调试目的,还可用作宣传材料。 Flutter也有超出项目管理和交互范围的优势。事实上,它可以为在项目中使用它的开发人员和工程师提供更多。 除了它具有的许多技术优势之外-这超出了本文的范围,但您可以在本文的配套文章中阅读更多关于它们的信息-有两个特别值得决策者注意:它迭代速度和它的“一次编写,到处运行”的特性。 快速轻松地向移动应用程序添加新语言的能力可以显著影响国际版本的上市时间。Flutter的ARB格式允许高效的本地化工作流,使开发团队能够轻松地并行创建、管理和更新多种语言的应用内容。这有助于加快本地化过程,并缩短在新市场推出本地化应用程序所需的总体时间。此外,Flutter的热重新加载功能允许实时更新和预览应用程序内容更改,使其更容易在开发过程中迭代和微调本地化内容。 与大多数当前框架一样,Flutter也很好地适应了持续集成/交付的自动化测试-构建-部署过程。它不仅可以将各种形式的测试自动化并卸载到外部服务,而且卸载交付过程并创建一个管道,在这个管道中,整个价值链可以完全自动化地启动并运行到完成。 与此密切相关的是,甚至可以将该过程的本地化步骤集成到所述管道中。由于Flutter强制应用声明支持的所有语言都存在本地化内容文件,因此构建系统可以-并且确实-在构建时检查它们的存在,并且如果一个或多个区域不存在,则管道失败。有了合适的工具,甚至可以自动将内容文件移交给您的语言供应商(以及检索翻译的内容),从而腾出宝贵的时间来专注于真正重要的事情。 在对Flutter进行了彻底的检查之后,我想强调两个值得注意的方面。首先,使用Flutter可以加快开发过程,更重要的是,通过将本地化步骤纳入到过程中来加速产品的交付。这使得包含本地化内容变得更容易,并确保其在最终产品中的存在。 其次,Flutter通过使用开发人员和翻译公司都能理解的文件格式简化了流程,从而节省了宝贵的工程时间,否则将花费在两个组之间手动转换文件。 最后,对于更多的工程头脑,还有另一篇文章,重点关注开发人员对Flutter优点的看法。如果你对其他观点感兴趣,你可以通过这个链接阅读。 我们一直在寻找与我们行业相关的信息丰富、有用和经过充分研究的内容。 写信给我们。

以上中文文本为机器翻译,存在不同程度偏差和错误,请理解并参考英文原文阅读。

阅读原文