The invention of personal computing and software in the 1970s is one of the earliest points in time where we can trace the origins of localization. Even though these developments took place in the United States, and English was the language chosen by default, businesses decided to expand internationally and take their products to new markets that demanded new languages. This created the need for developers to establish translation best practices, at the beginning trying to find linguists that would help with the translation of textual strings, and then into the joint effort known as the GILT (Globalization, Internationalization, Localization, and Translation) process.
Bringing your software product to an international market is a two-part process: first, the software must be internationalized and, then it is localized. Software internationalization involves the preparation of your source code for the localization process. Software localization transforms the English (source language) software into one or more target languages, giving the product the look and feel of having been created in the target country.
Software localization refers to the process of adapting and translating software for a specific locale and language, and is one of the five main types of localization, along with Web localization, Video game localization, Small device localization, Multimedia localization. You are ready to release your new app, the software localization code is bug-free, and the new design is crisp – but does it work in languages other than English. If your answer is “no,” you might find yourself reworking the whole app to support other languages because you did not care about this while writing your code. Internationalization is the process of developing a piece of software or an app so that it can easily be translated and localized into other languages, and it’s much easier if you do it right from the beginning.
If you don’t want to spend months fixing software localization bugs, you should consider these common pitfalls that prevent applications from being properly translated and localized.
It will slow down the software localization process as the translator needs to read the code to determine which segments need translation and which ones do not. It will make localization more costly. You should get all of these user-visible strings out of your code and place them into resource files, giving each string a unique name.
Don’t assume every language is as concise as English. English text is often very compact in comparison to other languages – like German, and translations can vary considerably in length and density. If you don’t prepare for this and there isn’t enough space, your strings might overlap with other controls, and the interface will require editing after translation. The interface must be able to adjust the size to accommodate the length of translations provided at run time. You can solve this problem by leaving extra space after each label for the string to grow. However, by doing so, the labels and controls might appear pretty far apart from each other in compact languages. Some developers give their labels room to grow and shrink by aligning them to the right or by placing them above the controls.
Specifying a language, but not a country code, can make localization difficult. Always use a full locale property instead of just a language, which contains both the language and the country code where it’s spoken.
Some developers create concatenated sentences where the order of words and phrases is hard-coded. Splitting sentences into several keys presumes grammar rules and a certain sentence structure. Don’t assume grammar structures, and be careful with the granularity of conditional text. The structure of the sentence will often be completely different in another language. Therefore, it’s best to create strings that are complete sentences.
Whenever you use a wrong character encoding, and your source code handles strings using a data type that cannot handle Unicode, translations will break. Programming languages often store files using the system’s default encoding. However, when your server is English, and all of your users are browsing in Chinese, your characters will get corrupted. Therefore, another of our software localization best practices is to make sure you use UTF-8. It’s the best choice as it fixes this issue by standardizing the encodings across browsers and servers.
Software localization is more than just about the mere translation of words – it’s about adopting the complete culture. Hard-coded date, time, currency formats will cause trouble during the translation process, as languages and countries differ in date and time formats. 26.04.2015 or 04.26.2014? 14:00 or 2 p.m.? 1,000 miles or 1,609 kilometers? Use a Library to Support Different Locales. You can store all dates and times in a standard ISO format and use a library to format them for the given locale. It will also help to convert time to different time zones. The same applies to currencies and other number formats. So, always use a library with localized files for each of the locales your software needs to support.
Arabic, Hebrew and,
some other languages go from right to left, and East-Asian languages using Chinese or traditional Mongolian characters have a long history of vertical writing. Prepare for complex text flow. Don’t assume that the same rules apply to all languages and expect the need for implementing specialized versions for a complex text flow, e.g., vertical writing and plan for languages that read right to the left.
When strings include variables, are used in a specific context or wording is ambiguous, your translation vendor will have a hard time. Keep in mind to add comments and notes to the localizable files. Aside from glossaries and style guides, you can provide context information to translators directly in your source files—the more context you give by writing notes for translators and providing alternate phrasings, the better.
Images are a great way to save localization costs as they cut down the word count for translation and may even make your product easier to understand. However, sometimes images that contain text can be a serious pain for translators and can slow down and otherwise hinder the translation process. In some cases, it could even result in you paying more money. If a text needs to be associated with a graphic, try to separate your text from the image and create the text as a separate component. Pay also attention to cross-cultural differences, as not all images and symbols carry the same meaning across borders.
Small mistakes can prevent your software from working in other languages. Mistakes in source content can be replicated or worse, amplified in various language versions can cause months fixing localization bugs. You can save yourself a lot of trouble in the long run when you start testing for localization early and often. Always test your patches not just for code errors but also check strings for grammar errors, capitalization: inconsistencies, and localizability issues. A well prepared QA process for software localization includes Functionality testing that will make sure keys are working, hyperlinks function properly. Cosmetic testing will ensure that the appearance of the final product is visually correct and that images are consistent with the text, of good quality. Linguistic QA will spot untranslated segments, encoding errors, incorrect syntax, incongruent text/image, and formatting/layout issues. As a developer, you can use automated tests of test translation files and character encoding for the localized version of your software. If you avoid these common pitfalls and follow the best practices, your application should be fully localizable and open up your application to the international market.
This article first appeared on Harry Clark blog
Input your search keywords and press Enter.