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.
In fact, you need to consider localization from the very moment you start designing your application – that’s internationalization. It’s not a one-man process either. You will need localization experts on board early on.
Here are a few localization good practices & tips I would like to share with you. I hope they will be helpful for your next software, application or game. If you wish to go further and ensure the success of your localization project, feel free to get in touch anytime so that we can get things started. You may also want to check my post with tips to reduce localization costs.
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.
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.
5. 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.
6. 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.
7. Pseudo-localization, a little-known step of the localization cycle, will help identify a number of internationalization issues before a single string is translated: hard-coded strings, unsupported characters, potential overflows, and more. You can save yourself a lot of trouble by identifying potential problems early on.
What if you didn’t follow the best practices and your product is already developed?
Internationalizing an existing product can be tricky but not impossible by any means. In some cases automated tools may be of help, in others you’ll have no choice but to rewrite string-related portions of your code. Overall this is more of a per-case approach, and you will probably want to hire a localization consultant to ease the process.
As you can see, getting your localization done right is a process that involves efforts from all parties, from developers to translators, which is precisely why you should start consulting the latter as early as possible. Some of the smaller tips and tricks may not be obvious at first. You can contact me anytime for all your French localization needs! I am familiar with the localization process, whether you are working on software, video games or mobile apps (iOS with Xcode, Android with Android Studio, etc.).