How to develop your software with localization in mind

如何利用本地化思想开发软件

2021-01-21 00:00 Smartcat

本文共1296个字,阅读需13分钟

阅读模式 切换至中文

In this guide, we’ll discuss why it makes sense to develop your product with localization in mind, what approaches exist, some dos and don’ts, and a few tips to get you started. Part 1. Preparations In this first of three parts, we will talk about 1) how to explain the importance of localization to your management, 2) what to ask your QA team for and 3) how to provide the team with the right tooling. So, you are a manager. You have your product team behind you, and you know that it is very important to provide that product with good quality and support. Moving forward, where do you think your product will be in five years — is it possible that your product will be shipped in 20 different languages? If the answer is yes, then you should definitely want to start preparing for that. So how do you do that? Let’s break it down: 1. Explain the importance of planning localization in advance to the team Explain to your teammates and leadership that if you don’t build your product with future localization in mind, it will become a real pain to do later. Things such as hardcoded strings or mere time formats might appear at first like tiny problems to fix, but they will soon snowball into an army of errors to deal with. 2. Ask your QA team for localization test cases For the development of a fully localized product, you should consider asking the QA team for some tests. This will allow you to check for the correct behavior of the strings once they are localized. You should ask the QA team for tests that prove that the strings do not take too much space, are legible and are consistent from one language to another. 3. Provide the team with the right tooling Localization is a mature industry, and there are many tools that your team can use to help you with the localization process. Choosing the tool for the task will also allow you to spend much less of your time on non-productive work. We suggest that you take a look at Smartcat, a platform that enables CI/CD localization scenarios. Part 2. Setting up the localization organization With the right tooling and consistent project management, the localization of your product code should become much faster and more efficient. But who exactly has to work on the localization of your software? Can it be outsourced to an external translation agency? Or directly to freelancers? Can it be done in-house? What is the best approach? Let’s dive into the details. 1. Do you need a dedicated localization manager? It is possible to leave the localization of the product to your development or projec product team. However, it is important to lay out the responsibilities of all the people who operate that project. This will help you avoid any misunderstandings on the topic. Some tips: Get written agreements from your team members — make sure that everybody knows what the roles and responsibilities of each team member are. Give your team A LOT of latitude to come up with their own way to do the work. As long as your team meets their own goals, they know how to get the job done best. Make sure to bring change to the localization process after every localization iteration. There are many ways to make localization as efficient and streamlined as possible. Asking your team for their ideas and finding out what works best for them will help you keep the project in shape. 2. Do you need an outsourced agency? For big enterprises, outsourcing the work of translating and localizing software to an external agency can be a very cost efficient option. An outsourcing agency can be hired with a complete localization manager and translator team on board. These teams act as your internal teams are acting, and they are capable of delivering the same quality level and latency as if the work was done in-house by the localization team. However, there are some drawbacks to the outsourcing agency model. In outsourcing, the translation agency acts as a service provider for you. They might also not care about your products, to make sure they are translated and localized correctly. Always make sure to rigorously choose your outsourcing agency, and consider using curated marketplace such as Smartcat’s to avoid pitfalls such as these. 3. Can you do the work in-house? For small teams or young startups, it can be a good idea to hire a localization manager and a team of tested, professional translators on board. These can and most often will be part-time or freelance resources, but they can also become full-time team members. If you opt for the former, make sure to source a permanent, professional team of freelancers and not just temporary resources. The Smartcat freelancer marketplace is a good place to start looking for a team that suits your requirements and expectations. 4. A mixed approach: outsourcing when you need more work done, in-house when you can do it yourself With all the above in mind, it’s not like you have to decide whether you are going to outsource or not. With the right tools at hand, such as Smartcat, you can manage your translations and decide if you need more work done or if you can handle it from your team on a case by case basis. Part 3. Technicalities In this part, we will discuss what internationalization frameworks to use, where to keep your strings, and some concrete no-no’s. 1. Which frameworks should you use? When it comes to choosing the internationalization framework, it is mostly a matter of preference and comfort rather than a hard technical requirement. Some common-sense tips are to make sure the framework is well-supported, preferably open-sourced, and has good documentation and tutorials. 2. Where to keep the localized strings? The prevailing option is to use your own code repository such as Github in combination with centralized TMS such as Smartcat. The file formats used for storing the translated strings will depend on your chosen localization framework. Some common formats are JSON, YAML and XML. 3. No-no’s and yes-yes’s If you are working on a project with lots of strings, the following are some dos and dont’s of which you should be aware. Don’t use hard-coded strings. This will make an automated, continuous localization process almost impossible. Don’t edit translated strings in place. Always use the TMS/CAT tool to keep your translations consistent and store them in your memory. Don’t publish your localized strings without proper QA. You don’t want to get a bunch of users to test your app and see incomprehensible letters, slashes, punctuations or wrong symbols appear. Make your texts clear and unambiguous. It should be very clear what each string means and how it should be used. Use meaningful string ids. This will make it much easier for translators to understand what they are to translate. Add the element type to the string id. Depending on whether it’s a button or a header, for example, the translation might be different in some languages. Add comments whenever possible. Let future translators know exactly what each string is supposed to mean. Add plenty of screenshots. A picture is worth a thousand words, and this will make it easier for translators to understand what each element is supposed to do. Talk to your translators! You will be surprised how much they value good communication. Work with them, not against them. So, there you have it. Make your app speak multiple languages, and make sure you do it right. If you’d like to give Smartcat a try, you can sign up here.
我们将在本指南中讨论产品开发本地化意义存在的的原因、需要的方法、该做和不该做的事,以及一些让你开始工作的提示。 首先是做好准备工作。 在这里,我们先讨论1)如何令管理层明白本地化的重要性,2)QA团队需要具备什么能力,3)怎样为团队提供恰当的解决途径。 假设你是个经理,身后有自己的的产品团队,非常清楚产品质量和为其提供支持的重要性。设想一下,你认为你的产品在五年后能销往哪里?你的产品有可能翻译为20种不同的语言销往其他国家吗?如果答案是肯定的,那么你肯定要开始做准备了。那到底要怎么做到呢?一起来看看吧: 1.向团队说明提前规划本地化思想开发软件的重要性 向队友和领导说明不考虑构建产品的本地化将带来的后果。像硬编码字符串或单纯的时间格式这样的东西起初看起来像是只需要修复的小问题,很快就会滚雪球般地变成需要处理的大错误。 2。要求QA团队本地化测试例 对于一个完全本地化产品的开发,你应该要将要求QA团队做一些测试纳入考虑,以便检查字符串本地化后的正确行为。QA团队还应该测试以证明字符串不需占用太多空间,清晰可辨,并且从一种语言到另一种语言是一致的。 3.为团队提供恰当的解决途径 本地化是一个成熟的行业,你的团队可以使用许多工具来帮助你进行本地化过程。为任务选择合适的工具也能帮你在非生产性工作上节省更多时间。我们建议您看一看Smartcat,这是一个支持CI/CD本地化场景的平台。 其次,设置本地化所需的相应机构。 有了正确的工具和一致的项目管理,你的产品代码的本地化应该会变得更快更高效。但是到底是谁必须为你的软件本地化工作呢?是否可以外包给外部翻译机构?还是直接给自由职业者?是否可以在内部完成?最好的办法是什么?让我们深入探讨一下。 1你.需要专门的本地化经理管理吗? 可以将产品的本地化工作留给你的开发或项目产品团队。不过,最重要的是要明确操作该项目所有人的职责,这可以避免关于这个主题的任何误解。一些提示如下: 你要从团队成员那里获得书面协议,确保每个人都清楚彼此的角色和职责。在工作中给他们提供更多的自由发挥空间。对于他们来说,自己的目标得到了满足,他们就知道如何把工作做得最好。 确保在每次本地化迭代之后本地化过程能有所改变。有许多方法可以使本地化尽可能地高效和精简。向你的团队询问他们的想法,找出什么对他们最有效,这将有助于你保持项目的状态。 2.你需要外包代理吗? 对于大企业来说,将翻译和本地化软件的工作外包给外部代理是一个非常划算的选择。外包机构可以雇佣一个完整的本地化经理和翻译团队。这些团队就像你的内部团队一样,他们能够交付相同的质量级别和延迟,就像本地化团队在内部完成的工作一样。 然而,外包代理模式也存在一些缺陷。在外包中,翻译公司是你的服务提供者。他们可能也不关心你的产品,以确保它们被正确翻译和本地化。始终确保严格选择外包代理,并考虑使用Smartcat等精心策划的市场,以避免此类陷阱。 3.你能在内部完成工作吗? 对于小型团队或年轻的初创公司来说,聘请一名本土化经理和一支经过测试的专业翻译团队是个不错的主意。这些人通常是兼职或自由职业者的资源,但他们也可以成为全职团队成员。如果你选择前者,确保你拥有一个永久的、专业的自由职业者团队,而不仅仅是临时资源。Smartcat自由职业者市场是一个寻找适合你需求和期望的团队的好地方。 4.混合方式:当你需要做更多的工作时,外包;当你可以自己做时,内部外包 考虑到以上所有因素,你就不需要决定是否外包了。使用合适的工具(如Smartcat),您可以管理您的翻译,并决定是否需要做更多的工作,或者是否可以根据具体情况由您的团队处理。 第三部分:技术细节 在这一部分中,我们将讨论使用什么样的国际化框架,在哪里保存你的字符串,以及一些具体的no-no。 1.你应该使用哪些框架呢? 在选择国际化框架时,这主要是一个偏好和舒适度的问题,而不是一个硬性的技术要求。一些常识性的技巧可以确保框架得到良好的支持,最好是开源的,并拥有良好的文档和教程。 2.本地化字符串保存在哪里? 大多数人会选择将自己的代码存储库(如Github)与集中式TM(如Smartcat)相结合使用。用于存储翻译后的字符串的文件格式将取决于你选择的本地化框架。一些常见的格式是JSON,YAML和XML。 3.反对和赞成 如果你正在做一个有很多字符串的项目,下面是一些你应该关注的注意事项。 不要使用硬编码字符串。这将非常不利于自动化的,连续的本地化过程。 不要在原地编辑已翻译的字符串。坚持使用tms/cat工具来保持你所做翻译的一致性,并将它们存储在个人库中。 没有适当的QA,就不要发布本地化字符串。你也不想让一群用户来测试你的应用程序,然后看到无法理解的字母,斜线,标点符号或者错误的符号出现吧。 让你的文章清晰明了,简单易懂。所以应该非常清楚每个字符串的意思以及使用它方法。 使用有意义的字符串ID能令翻译人员更容易理解他们要翻译的内容。 将元素类型添加到字符串ID中。例如,它是一个按钮还是一个标题,在某些语言中翻译可能是不同的。 尽可能添加注释。让之后的翻译人员明确每个字符串的含义。 添加大量的截图。一张图片胜过千言万语,这将使翻译人员更容易理解每个元素的作用。 和你们的翻译官谈谈!那么也许会惊讶于自己是多么看重良好的沟通。和他们一起工作,而不是反对他们。 所以,就是这些了。让你的应用能说多种语言,并确保自己做到这一点。如果你想试试Smartcat,你可以在这里注册。

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

阅读原文