i18n vs l10n

Internationalization vs. localization (i18n vs l10n): What’s the difference?

At first glance, internationalization and localization seem interchangeable. While they are complementary concepts, they aren’t exactly the same. But it’s not an issue of internationalization vs localization — both internationalization and localization are important to the overall software localization process.

However, they do carry distinct and crucial differences.

In this guide, we’ll walk through the definitions of both internationalization and localization, why they’re important, and how they work together to help your software serve a wide variety of markets, languages, cultures, and target audiences.

Let’s start by defining the two terms.

Internationalization vs. localization

Developing multilingual software requires two phases: internationalization and localization. Internationalization is the process of designing and developing your software or mobile application product so it can be adapted and localized to different cultures, regions, and languages. Localization is the adaptation of your software or mobile application product to meet the language, culture, and other requirements of each locale.

Internationalization helps you build your software or mobile application product with future markets and languages in mind. It’s the process of neutralizing the code, content, and design so that, down the road, it’ll be easier to adapt your product to additional cultures without having to completely re-engineer it.

Localization typically follows internationalization. But — beyond adapting your software to a specific region — the localization process can also highlight any words, phrases, or user interface (UI) elements that haven’t correctly been internationalized.

For example, let’s say you’ve internationalized your product and are now conducting localization for Arabic. Arabic is a right-to-left (RTL) language, which not only requires translated content but also a different interface design. While localizing your product for Arabic, you discover your internationalization team failed to implement the correct code to allow for both LTR and RTL designs.
This is one example of how localization and internationalization are both important when preparing your product for global markets. Because of this, until you localize your product once or twice, you shouldn’t consider it fully internationalized.

Moreover, internationalization is usually executed once, at the front end of the software design and development process. Since internationalization is more or less a one-time cost, the more languages and cultures you localize your product to, the higher your return on investment.

The strongest similarity between internationalization and localization, however, is their shared goal: globalization. Globalization is when businesses and organizations develop international influence or start operating on an international scale, such as by expanding a software or mobile application product into new, international markets. Globalization is also called g11n.

Now, let’s unpack some differences between internationalization and localization.

Internationalization (i18n)

As we defined above, internationalization is essentially changing and removing any hardwiring so that your product is language- and culture-neutral. Internationalization is also called i18n (because of the number of letters, 18, between “i” and “n”).

Internationalization ensures your software is localizable and is typically done by software developers and engineers.

Even if your initial product design and launch is a source or native language of English, internationalization allows you to ensure it could support other languages and cultures if you were to expand to additional markets in the future.

Rather than hardcode each individual language, internationalization prepares your codebase to receive different configurations based on your target language(s). It replaces code with key placeholders that — when localized — automatically retrieve each target language without requiring fundamental engineering changes.

Here’s an example. Let’s say we’re internationalizing the dashboard on a software application, and we need to set up the keys for a welcome message. For now, we know our software will be sold in English and Spanish.

Let’s say the key is “title”. The English version would be “Welcome!”, and the Spanish would be “¡Bienvenidos!”

So, when coding the dashboard language, internationalization would look like confirm(t(title)); instead of confirm(“Welcome!”); or confirm(“¡Bienvenidos!”);. This same process would also work for locale-specific time formats, date formats, currency, and other components.

Instead of coding the software for each specific language, the internationalization process replaces that code with keys — this not only makes for easy localization, but it also neutralizes the code and adapts it for various languages you may introduce in the future.

In addition to creating placeholder keys, internationalization involves some other best practices:

  • Enabling cultural formatting, including number formats and systems, time zones, personal information, and text formatting
  • Organizing your source code
  • Optimizing for your code language (at Lokalise, we support all major code languages and frameworks, including Python, Vue, Java, and Rails)

Read more about software internationalization on the blog.

Localization (l10n)

Localization, on the other hand, is the process of adapting your internationalized software to meet the language, cultural, and other requirements of a specific target market, otherwise known as a locale, by adding resources and translating content. Localization is also called l10n and is typically conducted by translators on the user-facing components of the software or mobile application.

Localization goes beyond translating languages, though. It also refers to localizing time and date differences, currency, accounting standards, culturally appropriate images, symbols, and hand gestures, spelling, and other locale-specific components (including the RTL language example from above).

To optimize this process, create separate resource files for each language that store all the text outside of the code for your product. This allows you to import and export information without harming your code. Naming conventions come in handy here, as they allow translation management systems like Lokalise to pull the correct translation for each string of code. Learn more about the wide variety of file formats that Lokalise accepts.

Another helpful step for localization as it relates to internationalization is pseudo-localization. Pseudo-localization is the process of “testing” the space that different languages will take up in your finished design, allowing you to understand the expansion, contraction, or vertical space needed — without actually having to conduct a translation.

Did you know that an English to German translation can expand the text by up to 35%? Pseudo-localization allows you to recognize that needed space and take it into consideration as you build the initial code and design of your product. At Lokalise, we integrate with tools like Figma and Sketch; this shows you how your designs will change through the localization process.

Read more about software localization in our ultimate introductory guide.

Internationalization vs. localization: Both are important!

Both internationalization and localization play an important role in optimizing your software or mobile application product for different locales and different countries. By combining the two — and using a translation management system like Lokalise — you can ease the process of transforming your software or mobile application product for globalization and worldwide target markets. Try Lokalise for 14 days today.

Related posts

Sign up to our newsletter

Get the latest articles on all things localization and translation management delivered straight to your inbox.

Read also
Localization made easy. Why wait?
The preferred localization tool of 1500+ leading global companies