Localization Best Practices 7 tips, illustrated




Greater than 3 minutes, my friend!

I can’t believe it took me so much time to share my first story here! For my first post here, I would like to share one of my most popular articles, which I recently updated with a few extra tips and an illustration. I hope you will enjoy it. While these localization tips are mostly aimed at end-clients (developers), I feel we share the responsibility of spreading them around.

Software, application and game developers often make a serious mistake when they approach localization by assuming it can be handled once the coding is done in native language. Here are a few best practices that any developer should follow to avoid issues down the road.

If you like this article, you may also want to check my post with tips to reduce localization costs.

Localization Best Practices

1. First of all, internationalize your software. Your source code should be written in a way that your software can be localized without touching a single portion of code. To achieve this, place all the content (text strings, images, sound files), including those in the application’s original language in separate files and folders, which can then be translated appropriately by linguists in a different software. In your code, pick up the translated depending on the language selected and a string ID (which can be the original string itself). XML works great for this, but there are plenty of options available. Also, try to keep a clear structure for your localizable resources. You can have separate folders for images and sounds that will require localization.

2. Translated strings can occupy a much larger screen space than their original counterparts. A Japanese string translated into German can easily get 2 or 3 times longer than the original. Design your applications with sufficient space to accommodate long strings, especially if you are working on small screens (smartphone, handheld game devices, etc.). Plan your software as if it was going to be localized in every language on Earth, and use the worst case scenario as a reference.

3. Be wary of local standards and cultural differences. Imperial versus metric system is an obvious one if you are manipulating units, but there are local differences you may not even suspect. For example, weeks start on Mondays in some countries, and Sunday in others. This is why you need to have local experts on board as early as possible: only them will be able to let you know about these specifics. If you realize too late that a code portion needs to act differently depending on the location, or that visual elements should be replaced altogether, it can be extremely painful to go back and make the appropriate edits. The sooner you are aware of local norms, the better.

Have your app/game tested by native users from the target markets before going any further. Never assume you know everything about each and every culture. Ask locals to test your product and report anything that could be considered inappropriate.

4. Be careful when you are trying to put localized strings together. Let’s suppose you have an error message in your software that says “The job cannot be added because there is no job with ID x”. If you have many error messages starting with “The job cannot be added because” and many ending with “there is no job with ID x”, it can be tempting to ask the localization team to translate these two strings separately only once and then put them together when needed. It would work in English and (most?) Romanic languages, but not in Japanese for example, no matter how you put the two parts together.

5. Having the above in mind, you have to make sure translators can put words in any order they want, and, as much as possible restrict substitution to a single word or number. While avoiding redundancies is a good practice, it can be a tricky one when it comes to localization.

6. Provide as much context as possible. To avoid confusion, comment your text strings to ensure the translators will understand where and how they will be used. Make it clear that variables are part of the string and shouldn’t be altered. Also, explain what they will be replaced with, even if it seems obvious to you. If some bits mustn’t be altered, make a note of it, especially if they otherwise look like plain text. When possible, provide your translators with screenshots, videos or, even better, the actual product.

7. Make sure you can easily track source text changes. Nowadays, most software and applications are updated on a regular basis, thus requiring extra translations. Not only will this help you save on costs by not ordering the same strings twice (or more!), but you will also avoid headaches when merging translations. If you are planning to release frequent updates, for example additional content for games, this point can be critical.

Thanks for reading through! Are there any other localization tips you feel should be mentioned?

Anthony Teixeira

About Anthony Teixeira

3 thoughts on “Localization Best Practices 7 tips, illustrated

  1. Awesome tips, Anthony and congrats on publishing your first Open Mic story, I hope it wasn’t super difficult 🙂

    All advice you give here is absolutely invaluable and I don’t think I can really add much… oh.. wait… got one!

    Dear developers: can you please go easy on the puns? I mean, they’re fun and all, but, gosh, among all the localization challenges rendering puns and word play in your native language is probably the hardest one. Not all puns have adequate equivalent in other languages. Most of the time there’s no equivalent 🙂

    Report comment
      1. Haha! Yeah, sometimes it’s a fun challenge, but some developers can overdo it making video games impossible to localize adequately (for example when the pun suggests hints on beating the level.

        Report comment

Leave a Reply

The Open Mic

Where translators share their stories and where clients find professional translators.

Find Translators OR Register as a translator