Considerations before localizing your apps and websites into multiple languages.
At first glance, localizing your app, website, or other code project seems pretty straight forward, you just have a list of words and phrases for each language and magically you make your app select the right list for the device’s current language. After dealing with localization across multiple platforms and code bases, I have learned there are a few more details and maintenance behind localizing your code bases.
How do multilingual apps work?
Generally speaking, your app detects the current user’s device language and loads a resource file full of translations for the given language. The resource file contains a key value pair dictionary of all words and phrases that there are translations for. Anytime the app needs to display any kind of text to the end user, there is code that looks up the correct translation from the resource file based on the key provided in the code.
For example, if I have a resource file that contained:
“first_name” : “First Name”,
Within the code
Existing Apps that need to be translated
If you have an app that was not designed to handle multiple languages from the beginning, you will need to hunt down any user viewable text throughout your whole code base. Anytime you add a user viewable word or phrase you should be adding it to your language resource file and properly referencing it in your code.
An app that handles multiple languages is slower to maintain but the added maintenance time is a whole lot less than if you were to maintain completely different codebases on a per language basis.
Ways to get your app’s strings translated
Use Google Translate or similar service.
Google translate is free, you simply copy and paste your list of English strings onto the web page and select which language to translate it into. With this method you would need to maintain the lists yourself and make sure it stays formatted correctly.
Like with many things in life you get what you pay for. If quality is a top priority this option, without some sort of additional quality assurance process, is definitely not the way to go.
Use built in services provided by your development platform.
Microsoft has tools that can translate text on the spot, which I believe uses the Bing Translator API behind the scenes. This option has about the same level of translation quality as the Google Translate option, but makes managing your resource files easier.
Google Android has translation options within the Google Play App management, for a price they will help facilitate your app translation. Other platforms may not have an easy way to facilitate translation so managing the translation yourself may be your only option.
Contact a 3rd party translation company directly
After using this option multiple times it is clear it provides the highest level of quality over a “computer generated” translation. This is mainly due to the fact that a human is involved. This is generally the most expensive option but if quality matters it can be worth the cost.
Ways to manage your language strings resource files
Edit your apps resource files directly.
For small projects this can be all you need, especially if you are the one in charge of the translations as well. If you are dealing with a bigger size app or a person in charge of translations that doesn’t know which characters may break your resource files, this option may get messy if you are not careful.
For some development environments, such as X Code, you can create separate versions of each view in your app for each language. This option can be very hard to maintain as a translation expert would either need to have access to your source code (yuck!), or you would have to maintain duplicate views and make sure words and phrases do not get all mixed up everywhere.
Use a Spreadsheet
Although not perfect, this option has worked out surprisingly well in my experience. you paste in your English test in one column, generate a language resource key for each row, paste your translated foreign language text in other columns, and then you can generate resource files in whatever format you need them in.
In the case that you are using a 3rd party translation company, you can hide a few columns here and there, lock down the spreadsheet so nothing gets messed up, and send it off to be translated.
Excel gives you many functions that will help facilitate good formatting and detecting duplicate keys, which for some platforms are not allowed in resource files. Some of these Excel functions that I have used include:
- CONCAT() – to build resource file entries in the correct platform specific format.
- COUNTIF() – to detect duplicate key entries
- REPLACE() – to strip out invalid characters for language keys.
Develop a database driven web portal
This seems to be the very best solution for anyone wanting the most efficient way to not only initially translate apps from various platforms, but to also maintain language strings when new features are added or when typos are identified.
The main idea here is to have a system that, when a language expert logs in, they simply see a list of strings that are in need of transition. These strings are saved to the database so that when a programmer is ready to get the next version of their app out, they can simply request the latest resource file, pulling the most up to date data from the database.
For each release cycle of all apps, this process would ensure the very latest translations are added. This option would also allow a programmer to quickly add new strings to be translated, which could trigger an event that notifies a language expert automatically that more text needs translation. This option also puts live server code (that doesn’t have to be VBA) into protecting and preserving correct formatting for resource files.
Switching language on the fly
Early on we identified the need for users to switch languages on the fly. In many cases this is not necessary and causes additional work.
For Mobile Apps
Normally mobile apps are designed for one end user in mind, and as such the built in language tools usually assume upon app launch is the only time lauange should be detected. For the majority of apps this should work just fine, but for some of the apps I have been involved with, we had the additional requirement to allow users to swith lanauges on the fly at any given time.
detect browser language. store lanauge preference in a cookie and / or database.
Example resource files and impementations for some platforms
Apple Objective-C iOS
String.Format() placeholders in your code, make sure language experts don’t mess with those or your app may crash
Managing across multiple platforms.
I don’t consider myself an expert with iOS and XCode, but working with a fellow developer that has gotten it down. …
Localization is not just languages translations
Date formats, numbers, and even layouts can play a part in a full localization scheme. Luckily the main mobile operating systems cut out most of the work for you. If
I cannot take complete credit for all the ideas in this post, as many conclusions were drawn by the help of my team members Brett Tucker and Randy Whitelaw. They basically rock and together we come up with some awesome ideas!