How to develop your software with localization in mind

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.

Vova Zakharov
Vova Zakharov Smartcat’s former editor-in-chief, Vova loves g̶l̶o̶b̶e̶t̶r̶o̶t̶t̶i̶n̶g̶ staying at home with his family, playing some good old metalcore, and talking to self-aware robots.