Solve these Localization Issues and Keep Your Expansion on Track
“An ounce of prevention is worth a pound of cure.” Or, are we supposed to be using kilograms? Wherever you are trying to localize your application, software, or website, there is a myriad localization issues you should be prepared for that go beyond simple translation. Here’s how to solve them:
1. Putting off Localization until the Software Is Developed
It is the little things that will prevent your software from being global-ready. When you have mistakes in your source content, it will be replicated or amplified as you try to enter foreign markets. Fixing the localization bugs can cause months of rework.
The Solution:
Internationalization is a necessary first step in making your software global-ready. It involves identifying which parts of your source code can remain the same for various languages and which will likely need to change for each new locale.
You are not going to get it perfectly right the first time, but when you keep the localization process in mind as you design your software, it will save you frustration down the road.
It is also important to test for localization issues early and often. Your developers can utilize automated tests of character encoding and translation files for your localized software. Test your patches for code errors, inconsistencies, grammar errors, capitalization, and other localization issues.
2. How Are Time Zones Localized?
You know how tough it can be to implement time zones in software if you have ever gone through that process before. There are 40 time zones on the planet, and not all of them are offset by a full hour. Some locales even have multiple time zones in one geographic spot.
Time zones also change over time, which is another reason why they can lead to serious localization issues. Daylight saving time is the obvious example, but there are also countries like Samoa and Venezuela who changed their time zones in the last decade. Here’s a more detailed video about why time zones are a developer’s nightmare:
The Solution:
Basically, you don’t need to reinvent the wheel. Use Google’s CCTZ. This is a C++ open source library that represents time in two ways: absolute time, which is similar to a timestamp in that it represents a universal and specific point in time, and civil time, which represents a region’s absolute time.
Absolute time is the same for everyone, and civil time accounts for time zones. As long as you know the time zone that civil time is based on, you can convert from absolute time to civil time and vice versa. Other options include java.util.TimeZone, pytz, and DateTime.
3. Getting Translations to Fit on the UI
Depending on characteristics like the size of words and sentence structure, languages tend to have different lengths. The length of your text will expand or contract by up to 40 percent as you localize your content.
At its face, it may not seem like a big deal to have longer text. However, it becomes one of the biggest localization issues when you want to fit the translated text into your user interface (UI) space, which was designed for text that was 40 percent shorter.
The Solution:
Before you get started translating, research the length changes you might expect to see with the language pair. Based off of this research, let your translators know of any word limit recommendations you may have. If they need to cut down on content to stay in the limit, let them know what to keep.
Another solution is to build your UI so that there is plenty of white space. This will allow the text to increase or decrease in length without looking weird and will save you from one of the most common localization issues.
4. Translating Text Embedded in Graphics
A picture is worth a thousand words. And, that’s a thousand words you don’t need to translate. Unless, of course, you have text embedded in the picture. This can be a real headache for translators who may have to rebuild your graphics from scratch with the localized language.
The Solution:
To avoid yet another one of the most common localization issues, try to make the text a separate layer if you must associate words with an image. Managing localized versions is much easier when the text is its own component.
Graphics would ideally not have any text at all since there would then be no need to translate it. And, since not all symbols and images have the same meaning across borders, you must be aware of cross-cultural differences when using graphics.
5. Supporting Characters in Every Language
Does your software handle input from users in Egypt, Russia, India, and Japan? Can it read dates, numbers, and characters from different locales and from right-to-left languages? How well do your external databases handle this data?
The Solution:
If you have any of the above localization issues, you should consider using Unicode. 85 percent of websites utilize UTF-8 for character encoding. Your software and the applications that support it will be able to interpret characters in just about every written language thanks to UTF-8.
