Internationalization and localization

• 1. Two Letters, Eighteen Steps

  ›

  Internationalization and localization are the paired processes that determine whether software works for someone in Tokyo, Toulouse, or Tucson. The abbreviations i18n and l10n capture something of the industry's impatience: eighteen letters stand between the first i and the last n in internationalization, and the numeronym was coined at Digital Equipment Corporation sometime in the 1970s or 1980s. The shorthand stuck because the problem itself is genuinely vast.

  At their simplest, the two terms divide labor cleanly. Internationalization is the engineering work done once: designing a product so it can be adapted without rebuilding the core. Localization is the adaptation work done repeatedly, once per target market, translating text and adding whatever a specific region requires. One lays the foundation; the other furnishes the rooms.

  Not every company uses the same vocabulary. IBM and Oracle prefer the term globalization, abbreviated g11n, for the combination of both processes. Microsoft defines internationalization as a merger of world-readiness and localization, where world-readiness covers the ability to handle multiple scripts and cultures, and localizability refers to separating interface resources into a format that can be translated. Hewlett-Packard took a different path entirely, building a system called National Language Support for HP-UX to handle the same problem. Some vendors, including IBM, call fully localized products National Language Versions, or NLVs, a term reserved for releases that support only one specific locale rather than multiple markets.

• 2. The Translation Iceberg

  ›

  Translation is typically the most time-consuming part of language localization, but it is rarely just substituting one word for another. Film and audio require either dubbing or subtitles for spoken content. Printed materials and digital interfaces need text translation, which can include error messages and documentation. Logos and images that contain text may need to be replaced entirely with versions using translated copy or generic icons.

  Layout is a structural challenge that words alone cannot solve. Latin alphabet letters and Chinese characters differ dramatically in physical size, so a layout that works in English can break entirely when the same content is rendered in Mandarin. Sentence length varies across languages too; a phrase that fits a button in one tongue may overflow it in another.

  Dialect and register add another layer. When Tandy Corporation needed French and German translations of English error messages for the TRS-80 Model 4, the company's Belgium office and five US translators together produced six different versions that disagreed on the grammatical gender of computer components. MicroPro discovered a similar problem when it used an Austrian translator for the West German market; an executive later acknowledged the WordStar documentation did not have the tone it should have had.

  Beyond words, formatting conventions diverge widely. Numbers use different decimal separators and digit groupers. Dates may follow entirely different calendars, including the Islamic or the Japanese calendar. Technical drawing software must account for first-angle and third-angle projected views depending on region. Legal and regulatory requirements add yet another dimension: privacy law compliance, export restrictions, encryption rules, and even sensitivity to geographic naming disputes, such as India's proposed legislation that would make it a crime to depict Kashmir incorrectly.

• 3. The Data Beneath the Words

  ›

  Software generates content dynamically, which means translation alone cannot cover every difference a locale introduces. The Common Locale Data Repository, maintained by Unicode, collects and standardizes these differences. Its data is used by major operating systems including Microsoft Windows, macOS, and Debian, and by major internet projects such as Google and the Wikimedia Foundation.

  Writing direction is one of the most structurally significant variables. Most European languages run left to right. Hebrew and Arabic run right to left. Some scripts use boustrophedon conventions, alternating direction line by line. Certain Asian languages optionally run vertically. Each direction requires different text rendering logic.

  Character shape is another variable that runs deeper than simple substitution. In some languages, a character changes form depending on its position within a word or its neighboring characters, a property called complex text layout. Sorting rules vary too: alphabetical order differs between languages, and some writing systems have no concept of alphabetical order at all. Plural forms complicate any program that counts things and displays the result dynamically. French treats zero as plural; Russian uses different plural forms for quantities ending in one, two through four, and five or more. Keyboard shortcuts require rethinking when localized: a shortcut tied to the initial letter of an English word may carry no mnemonic meaning in another language, or the key itself may not exist on a localized keyboard layout.

• 4. National Conventions and Commerce

  ›

  Currency symbols, paper sizes, telephone number formats, postal address structures, measurement systems, battery sizes, and voltage standards all vary by country. The United States and Europe diverge on most of these. Time zones introduce additional complexity for any product that started life serving a single region; the standard engineering response is to store times internally as UTC and convert to local time zones only for display.

  Commercial pressure clarified what was at stake early in the industry's history. In the early 1980s, Lotus 1-2-3 spent two years separating its program code from its text strings. The delay cost the product its market lead in Europe, where Microsoft Multiplan moved in. By 1985, roughly a quarter of Ashton-Tate's eighty million dollars in annual sales came from outside the United States; the company had localized its products in eleven European languages. Those numbers made the business case concrete: access to more markets was the direct reward for doing the engineering work.

  The costs, though, extend well beyond engineering. Storage and distribution must scale to handle multiple distinct localized products, often sold in different currencies under different regulatory regimes. Sales, marketing, and technical support all need to operate in new languages. For languages spoken by relatively small populations, the economics may never justify a localized product at all, regardless of the technical groundwork already laid.

• 5. Engineering the Foundation

  ›

  The first engineering step in internationalization, whether building from scratch or adapting existing software, is to identify every part of the code, text, or data that might change across locales and isolate it into a separate module. Each module can then rely on a standard library or be replaced independently for each target market.

  The prevailing practice is to store translatable text in resource files loaded at runtime. These strings, sometimes called a message catalog, are relatively straightforward to hand off to translators. One widely used library for managing this is gettext. At runtime, an application selects the appropriate resource file for the user's locale, then draws all its displayed text from that file.

  Some localization challenges go beyond text and require deeper changes to the software itself. Writing direction and text sorting rules often demand structural rethinking rather than simple substitution. OpenOffice.org handled such cases through compilation switches. Already in the 1990s, companies like Bull were using machine translation via Systran at large scale; human translators handled pre-editing to make input machine-readable and post-editing to refine the output.

  Quality assurance is the third step in the full globalization method, following planning, internationalization, and localization proper. Teams handling these stages typically include people with both language skills and technical backgrounds, plus specialized technical writers capable of constructing culturally appropriate phrasing for complex concepts.

• 6. Open Source and Scale

  ›

  Once software is properly internationalized, localization can be distributed well beyond an internal team. Free and open-source software typically relies on self-localization by end-users and volunteers. The GNOME project organizes volunteer translation teams covering over 100 languages. MediaWiki supports over 500 languages, of which 100 are mostly complete.

  Maintaining parallel versions of translated text over a product's lifetime creates its own ongoing burden. When any message displayed to users changes, every translated version of that message must be updated to match. For large projects with fast-moving codebases, keeping translations synchronized is a continuous logistical challenge rather than a one-time task.

  The Microsoft Excel localization team illustrates a localization decision with lasting side effects. The team chose to translate the tokens used in spreadsheet formulas, not just the interface text. The result: =SUM(A1:A10) becomes =SOMME(A1:A10) in French and =SUMME(A1:A10) in German. Users with no English background could read formulas more naturally, but before machine translation of web pages became common, searching the internet for formula help across different language versions of Excel returned incompatible results. Every tutorial and manual had to include translated versions of every formula example.