Internationalization (i18n) is the process of designing and developing software so it can be adapted for users of different cultures and languages.

Akio Morita, Sony’s co-founder, coined a phrase that’s the mantra of some of the most successful entrepreneurs: “Think globally, act locally.”

Local cultures are about much more than just language. Much like how different groups in the US have their own in-jokes, dialects, idioms, and customs, different countries have their own ideas about how to do things, their own sets of rules about what’s acceptable and what isn’t.

That’s why software, be it a web or mobile app, needs to be developed with internationalization (i18n) in mind—but what exactly is i18n?

What is internationalization (i18n)?

Internationalization (i18n) is the process of designing and developing a software product so it can be adapted for users of different cultures and languages.

Internationalization doesn’t just involve enabling different languages—it also entails adapting the software to accept different forms of data and settings to match local customs and process them correctly.

The W3C Group defines internationalization as follows:

Internationalization is the design and development of a product, application, or document content that enables easy localization for target audiences that vary in culture, region, or language.

Internationalization usually includes:

  • Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode, ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependence in code of user-interface string values, etc.
  • Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language. Or adding to CSS support for vertical text or other non-Latin typographic features.
  • Enabling code to support local, regional, language, or culturally related preferences. Typically, this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats, and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.
  • Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user’s international preferences as needed.

What is localization (l10n)?

Although similar at first sight, localization isn’t the same as internationalization. Localization is the act of adapting software—from content, UI layout, colors, and images to measurement units, date formats, and currencies—to suit a specific locale. The term “locale” defines a geographical region with a specific language (e.g., fr_CA means French from Canada, fr_FR means French from France, etc.).

Internationalization always comes first, and it’s what makes localization easier. In many ways, internationalization can be thought of as building the structure of a piece of software so that it can be adjusted for different target markets, and localization is the process of actually doing so for a specific market. Both are integral parts of a localization strategy.

The W3C Group refers to localization as follows:

“Localization refers to the adaptation of a product, application, or document content to meet the language, cultural and other requirements of a specific target market (a locale). Localization is sometimes written as l10n, where 10 is the number of letters between l and n. Often thought of only as a synonym for translation of the user interface and documentation, localization is often a substantially more complex issue.

Localization can entail customization related to:

    • Numeric, date, and time formats
    • Use of currency
    • Keyboard usage
    • Collation and sorting
    • Symbols, icons, and colors
    • Text and graphics containing references to objects, actions, or ideas that, in a given culture, may be subject to misinterpretation or viewed as insensitive
    • Varying legal requirements, and many more things…

Localization may even necessitate a comprehensive rethinking of logic, visual design, or presentation if the way of doing business (e.g., accounting) or the accepted paradigm for learning (e.g., focus on individual vs. group) in a given locale differs substantially from the originating culture.”

Why is i18n important?

Internationalization plays a crucial role in the success of any software product as it greatly impacts the customer experience.

For example, in a number of Asian countries, the family name comes first, followed by the given name. In Spain, people have two family names, one from the father and one from the mother; in Germany, you can even hyphenate your last name. Your software needs to be able to understand these and other vastly different conventions and present information accordingly.

Another example is ZIP and postcode formats, which can differ substantially among countries:

  • In Canada, for example, a postcode takes the form X0X 0X0, where X is a letter and 0 is a number.
  • In the United Kingdom, however, a postcode can take the form X00 0XX, XX00 0XX, XX0, 0XX, or X0 0XX.
  • In Brazil, postcodes take the form 00000-000.

When implemented properly, internationalization can create software that is capable of handling multiple inputs. Even better is when the software automatically checks those inputs to ensure that the right format is used for the right country.

All these are important aspects of developing software that consumers can relate to and use appropriately. A business that can’t accept orders through its software because that software can’t properly render postcodes may not last in the international market for very long.

The case of Baidu and Google

Baidu, the number one search engine in China, has been flourishing because it resonates more effectively with people within China than Google. It’s able to do better than Google because of its specific targeting and understanding of local cultures, restrictions, and, possibly most importantly, government requirements, such as access to user information and, reportedly, censorship.

However good Baidu’s localization strategy is, it isn’t particularly well internationalized, and it hasn’t been able to break into any markets outside China. Although this is unlikely to be a concern in a country with more than one billion potential users, it does limit potential future growth.

Google, on the other hand, has been out to break into most markets thanks to its internationalized software. Because it’s easily adaptable to a wide variety of locales, it can present interesting information that meets the searcher’s requirements, whether that person is in South Africa, the United States, or Russia.

Similarly, its Android operating system, Google Chrome browser, and numerous other products are all effectively internationalized, so they can be easily converted to meet the user’s cultural and personal requirements.

How does i18n affect developers?

Drilling down into code a little more, there are several good practices that go into reliable and trustworthy internationalization.

For illustration purposes, let’s take a brief look at WordPress. Around a third of all WordPress downloads are for localized non-English versions, so developers who build the various WordPress plugins need to do it with localization in mind, ensuring they’re fully internationalized.

This means, for example, that they shouldn’t use PHP variables inside the strings of a translation function, because translation software typically scans all the strings and pulls out the parts that need to be translated, designated by __().

If you have a PHP variable within that, translation software might try to pull it out as translatable content, possibly resulting in an accidental deletion by a translator. This, in turn, can render the entire line of code worthless—an error that can be difficult to track down.

This is just one example of how internationalization can affect a developer, but there are many more situations where the incorrect application of internationalization can cause the software to malfunction or produce unexpected results.

Other practices that have been standardized as part of internationalization include:

  • Keep software components external to the source code (e.g., user interface controls, user messages, user input methods, etc.)
  • Using Unicode
  • Avoiding language-dependent code wherever possible
  • Moving the code into separate resource files for each locale before it gets deployed
  • Considering different text lengths between languages
  • Supporting all language directions (left-to-right, right-to-left, etc.)
  • Avoiding the hard-coding of culture-sensitive elements (date and time formats, number formats, etc.)
  • Avoiding string concatenation

For example, if you had an Android app, a hard-coded string in your code would look like this:

<TextView
android:layout_width=“match_parent”
android:layout_height=“wrap_content”
android:text=“I am a hard coded string”
/>

What you’d like to do instead is set a reference to a string instead of an actual string so that the value of the string can change dynamically when the user chooses another language. So, in our example, we’d have:

nameTextView.text = getString(R.string.reference)

Equally important, make sure that all your strings are located in folders for each language separately. That way adding and modifying strings becomes much easier. In doing so, you won’t need to chase each specific string in every location across the code. It also allows for a translated version to be used without having to recompile your app’s code.

Many of these practices are straightforward enough to be immediately applicable, while others can require a little more time to consider. However, all will help to ensure your software is as effective and as user-friendly as possible.

Internationalization (i18n) gone wrong

Bad internationalization (i18n) typically means bad localization. A classic example is when only prices are localized on an ecommerce site, while the product descriptions, weights, and measurements remain in the original language.

The list of potential pitfalls continues—let’s take a look at some of the more common ones.

Incorrect measurement units

For many, pounds, feet, inches, and ounces are not easily convertible, so this turns the customer off the website because they don’t understand what they’re being offered.

Take clothing retailers: The same number can mean vastly different sizes in different countries. A size 10 in the United Kingdom would be a 38 in Europe. A size 38 in the United States, however, would be vastly different—the European size 38 is actually a size 6.

Good coding would allow automatic conversion of data so that it appears in the target language and cultural context—at least for the website’s prime markets—and good coding has to start at the beginning of the development process.

Incorrect date and number formats

In addition, different parts of the world use different date formats. In the United States, January 2 would be written 1/2. In the UK, that would mean February 1. This can make a big difference to delivery dates and could be a big factor as to whether your customer wants to purchase from you.

Number localization is another challenge. Some countries use commas while others use periods for decimal places, and some languages require a space between the thousand and million separators. If you get it wrong, you can produce really odd and confusing results that your clients might attribute to a lack of care for detail.

User interface controls that don’t work in all languages

And while we’re at it, let’s consider language-dependent UI controls. What happens when the user’s keyboard doesn’t include the button they’re using to denote a certain part of their interface? It’s likely that they’ll simply move on and find another website or app—one that does work for them.

Using language-independent controls is far more user-friendly and will yield far better results.

Incomplete translations

Partial translations are often the result of bad internationalization as well. In some cases, menus may be untranslated, or perhaps essential contact information may only be in English.

Layout and design

Different layouts are also required for different cultures. Typically, a minimalist layout is fine for many countries, but in some, such as Japan, a much denser layout is more common.

Good internationalization means that you can present different products, layouts, and even colors for different audiences, whereas bad internationalization means you have to use exactly the same layout for everyone. Bad translation is often an example of bad localization rather than internationalization, but it’s still important to know that these two are highly interlinked subjects.

The Leanest, Fastest, and Most Reliable Localization Platform. Simple translation management for software projects. Translation hosting, collaboration and machine translations for your multi-language project.
img 11 1 1

Copyright © 2022 AZBox