Localization transmits the meanings of words in a way that’s culturally appropriate. Of course, you know that already, but for you, as a developer, localization is simply a process of adapting software to international markets. This is how it can be easily accessed and consumed in a global environment.
If your goal is to build software that will be easily localized into multiple languages and locales, it also means that you want to learn how to make adjustments to the product. This involves a lot of planning and implementing of changes to what you have already created, but it’s not impossible!
We want to give you a few tips on localization itself and present 5 things that every developer should know about this process. We promise that after reading this blog post you’ll have learned even more about building a product that’s ready for localization!
#1. Use a TMS
We know that your team would intuitively choose a manual method of exchanging files. But the first amendment of proper software localization is: Don’t go with spreadsheets and emails for planning your localization project unless you want this project to be unproductive and to take forever.
All of the manual work can nowadays be replaced by a Translation Management System (TMS). A proper TMS will have features that will allow you to manage, translate and monitor your translation project.
How do I pick the right TMS? Research, research, research. To make it easier for you, here are the key elements that every TMS for software localization projects should have:
- API integration, for fast and efficient workflow
- Integrations with GitHub and BitBucket which allow for direct synchronization, versioning, and continuous translation
- Translation Memory and Terminology Management
- Integrated machine translation
- Website translation
- Collaborative features (managing and communicating with your team through the platform)
- Context tools for files and strings
#2. Keep translatable content in external resource files
Keeping all translatable content in external resource files is usually the best plan for localization because it gives you a neat outlook for your project. After the files have been translated, place them into the corresponding folders and you will be able to see how the translated version will look like.
However, the strings which are saved as .xml, .json or any other file format are usually lacking context, which is important for the translators to be able to understand where the strings fit in your app. This can be done by providing screenshots. At Text United, the project manager can upload each segment individually with a reference screenshot and, additionally, reference files which are available at a project level.
#3. Plan ahead for the UI
During the research stage, remember to plan the UI for localization. The general idea is that your software has to be as polished in a localized version as in the original one. The best idea is put yourself in the mindset that these are not different versions of the app, but instead the same app that has to be adjusted to new locales.
Remember that translated content can expand up to 30% in length for language combinations like English to French or English to German. In certain languages, like Arabic and Hebrew, the text is read from right-to-left (RTL) requiring your entire design to be adjusted to the opposite side. A modular design approach will come in handy while accommodating RTL languages.
Even though it seems that it’s more work than necessary, trust us – planning the UI ahead will save you a lot of time and money. Your UI simply has to be flexible and stripped of hard-coding, unless you want to double the workload (and probably double the costs) after the product has already been translated.
#4. Watch out for line breaks and word wrapping
It’s not easy to localize your software for a country where they use the Latin alphabet, but it gets even more complicated when you localize it into East Asian languages. Latin languages use spaces to separate words but languages such as Chinese, Korean and Japanese don’t. These are character-based languages that don’t use any spaces at all, and your application cannot rely on the usual line break and word wrapping algorithms for displaying text.
This means just a little bit more work. Your UI will have to be specifically adjusted to these languages with the assistance of a linguistic expert. For example, text parsing for Japanese will require a specific Japanese word segmentation algorithm, which has to be highly accurate, as Japanese (and Chinese) words cannot simply be broken down wherever it seems convenient. That’s where your User Interface designer will need the help of a linguist. Which leads us to another point.
#5. Currency, date and time formats and units
You may think it’s trivial, but there really are specific rules for text layout, formatting and measurement units for each language. Not thinking about these is making a basic mistake. Date formats are not the same in the UK, US, and Germany for example. The use of localization libraries that can help in handling these aspects is highly recommended, including:
- Support for right-to-left scripts (Such as Arabic, Hebrew, Persian)
- Numeric and currency strings, date and time format based on the language
- Plurals (where the usage of plurals is predefined for each language)
Remember that the localization process takes a bit of time and effort in order to be done right. It may look complicated but your effort will pay you off eventually when you’ll see how many new global customers your software receives, simply as a result of proper localization!