What's So Special About Translating Software?
Software Internationalization and Localization as a Company-Wide Process
A presentation by Tiziana Perinotti, TGP Consulting founder.
Summary written by H.Tamler, BayCHI (Bay Area Computer Human Interface) Organization.
What's so difficult about translating software?
In response to this opening question, several language-related issues were raised:
- Because of grammatical & semantic differences, languages can't be translated 1-to-1. For example, metaphors often can't be translated, or are especially difficult. As another example, English is non-contextual, whereas Arabic is contextual -- i.e., the same letter is written differently, depending on its context.
- Different languages have widely different space requirements -- e.g., a German word may be much longer than its English equivalent. Also, complex Chinese characters need to be much larger than English letters. Text grows an average of 30% when translated from English.
- Directionality differences between different writing systems -- western, middle eastern, and far eastern. For example, Semitic languages go from right to left, while Japanese and Chinese can be vertical or horizontal.
- Other languages have different punctuation from English, lack blank spaces between words, or are not written in a straight line.
- Cultural differences in style, approach, the meaning of images and colors, etc.
Furthermore, when you translate a document, the end result is a static object --- the translated document doesn't perform any function. In contrast, when you translate a software program, the result is active in that it can process data (text and numbers). For this reason, software translation always consists of two fundamental processes:
- The conversion of the application's UI (everything the user sees on the screen) into the target language
- The conversion of the program's logic so that it can handle the special processing requirements of the target writing system.
Given this fact, Tiziana's main thesis is that for software translation to be maximally effective and efficient, a 2-step process of internationalization and then localization must be employed. To support this, she carefully defined and distinguished between these two processes:
- Internationalization is the process of designing and enabling a software product up front in such a way that it can support all the linguistic features of different locales. In other words, internationalization is the set of processes, procedures, tools, and technologies that facilitate the localization process.
- Localization is the specific adaptation of an internationalized software product to a locale or multiple locales/writing systems, without the need to re-design the underlying foundation of the original product.
In other words, an internationalized software application has an English UI, but also has built-in support for all the languages/writing systems of the countries where the application will be sold.
This built-in support involves many software development issues that no translation process can resolve. For example, the standard keyboard shortcut Ctrl-C for "copy" can't be simply replicated in a language with a different word for "copy."
Some of the most important engineering guidelines for building in this support are:
- Support character sets for all the locales where the product will be sold
- Support double-byte for languages such as Japanese, Chinese, & Korean
- Deal with sorting, case conversions, and arithmetic functions (the problem of "rounding" as an example of arithmetic function that needs to be redesigned to include different rounding rules used in other countries) and country conventions such as dates, times, calendars, etc.
- Design menus, dialogs, screens, and status bars that can accommodate the translated text. This means leaving extra space for text to expand, rather than filling the screen with objects.
- Number all error messages for easy identification and reference
- Extract all of the graphics, text strings, and other UI objects' positions and sizes from the code, and put them into resource files from which they can be easily translated, rather than hard-coding them. Putting all items needing translation into resource files allows simple replacement of these files for each locale, without impacting functionality.
Again, all of these issues should be part of the product specification and dealt with up front, since postponing them till the time of localization is much more expensive. While this level of internationalization may somewhat compromise the quality of user interfaces in some cases, it's still more cost-effective overall. Finally, because of the level of commitment needed to do internationalization effectively, it needs to be a company-wide effort.
What are the ultimate benefits of doing internationalization prior to any translation?
- Shorter time to market: The localization process requires only the translation of the user interface, thereby avoiding repeated development and QA cycles for each localized version. Localized products can be released right after the US version ships, and you can release the internationalized English version everywhere in the world where a fully translated product is not necessary.
- Maintenance: It's less expensive and easier to maintain one set of source code than multiple sets for each locale.
- Revenue: The earlier you can release localized products after the date when the US product is shipped, the more you can exploit the initial sales spike which is typical of any successful product launch.
Companies which fail to internationalize, and hence take longer to localize, miss this window of opportunity for maximizing early sales, and lose substantial amounts of revenue. Unfortunately, there are still many companies, from startups to large corporations, that are unclear on the benefits of internationalizing their products.
