What is internationalization (i18n)? Ten i18n tutorials to learn on the go

In this article, we’re going to talk about internationalization (i18n), learn what it’s all about, why it’s important, and why you should care. We’ll also cover some common pitfalls, learn useful tips, and answer common questions.

What is internationalization (i18n)?

Internationalization (or “i18n” because of the number of letters between the “i” and “n”) involves designing and developing applications to allow for adaptation and localization for different cultures, regions, and languages.

I18n entails designing products with language and cultural differences in mind, removing obstacles to localization and international deployment. This involves utilizing Unicode, appropriately handling legacy character encoding, avoiding hard-coded text, leaving enough space for text expansion, and accepting varying user input. Support for diverse linguistic preferences, including date formats, calendars, number systems, and sorting, is crucial.

When an app is internationalized, it’s much simpler to adapt it for different language versions, edit texts, and replace images. As a result, it will provide better user experience while maintenance will be more cost-effective.

Internationalization vs. localization

You should be aware that internationalization is not the same as localization (or “l10n” because there are 10 letters between the “l” and “n”), even though people sometimes use these words interchangeably. The former is the process of designing and developing software or products that can be adapted to different languages and cultures. The latter is the process of adapting an existing product or content to a specific locale or market.

Internationalization usually occurs first, before localization. You could say that i18n is only done once (when applied properly, that is), and it enables localization. It is important to note that the app source code stays the same but the text can then be translated, the dates and times formatted, and the images replaced with more relevant ones. I18n is performed by programmers and engineers, and l10n is done by translators, editors, designers, and perhaps marketers.

In contrast to i18n, localization typically involves translating texts, picking appropriate visuals, colors, and icons, and adapting formats, as well as following any target market legal requirements. If you are interested in learning more about l10n principles and approaches, you can also check out my article on Implementing Product Localization for International Markets.

Why is i18n important?

Internationalization and localization are important for businesses that want to expand their reach globally, as they allow companies to provide a more personalized and relevant experience to their customers in different regions.

In fact, this process is absolutely crucial when expanding globally. For example, according to various studies, people are more likely to make a purchase on a website that is translated into their native language, even if the translation is imperfect. And here’s the thing: before you can translate a website or an app, it should be internationalized! On top of that, your app should be able to work with different date and time formats, currencies, and other data like postal codes, phone numbers, or units of measurement.

Without i18n, adapting or localizing software to different regions and languages would be hard and time-consuming work. Of course, you might create separate app versions for different languages and markets, but this is way too complex and costly: remember that you’ll also need to support all these versions. Therefore, developers typically create a single app that can then be adapted to the target region with relative ease. In other words, the codebase stays the same and only the content changes: this approach is much more cost-effective.

Internationalization (i18n) issues

There are a few typical issues and pitfalls people might face when implementing i18n in their apps. Let’s take a look at these:

• Hardcoding texts — this is probably the most common issue out there. It happens when developers simply put all the text right into the source code of the app and call it day. While it works as a minimum value product, it’ll be a big problem when expanding to global markets. This is because translators usually don’t work directly with the source code — they need all the texts to be exported into separate files to edit them properly. This becomes an even bigger problem when you want to perform machine translation or utilize artificial intelligence to pre-translate text.
• Relying heavily on concatenations — even if you extract all your texts into separate translation files and use keys in the source code, you might still have issues when using too many concatenated keys. For example, suppose that you initially have the text “View the item”. What you could do is create three individual keys, one for each word, and then use these keys as building blocks, like t("view") t("the") t("item") where t is a function for translation. Is that a good idea? On the one hand, you can now use the same keys in other areas of the app without having to create duplicate entries. However, with the above approach you assume that the translated text always follows the pattern “Verb – article – noun”. Unfortunately, that’s where the problem lies: not all languages use this pattern. For example, in Russian you would omit the article altogether (though it still can be fixed by giving an empty translation), whereas in some other languages the overall word order should be different! Therefore, you have to be very careful when doing this. Perhaps, it would be a better idea to store the whole phrase under a single key.
• Using an overly rigid design — your design should flexible enough to adapt to varying text lengths and directions. For instance, did you know that English text is generally shorter than the corresponding German translation, and the difference can be as large as 35%? Moreover, certain languages (like Arabic) use a right-to-left direction, and if your application is not designed to support such scenarios, you’ll have a tough time.
• Disregarding datetime and currency formatting — i18n is not limited to extracting hard-coded texts. If you display any date and time or currency information, it’s vital to prepare it for localization. Don’t forget that different countries have different currencies (dollars, pounds, euros, etc.) and date and time formats (day-month-year, month-day-year, and so on).
• Using fonts that support only a very limited number of glyphs — unfortunately, some fonts, while looking beautiful, might only support certain languages, typically those that utilize Latin glyphs. While this will work for languages like English or French, you will have problems when the app language is switched to Japanese or Russian.
• Not using Unicode — back in the day, ASCII was the only standard for character encoding. While it worked nicely with Latin characters, there were serious issues when trying to display glyphs from other languages simultaneously. In fact, it was nearly impossible to work with both, say, Greek and Japanese on the same PC at the same time. But these days are long gone and now people use a newer Unicode standard that makes working with different locales a breeze. Therefore, make sure to use Unicode strings—you’ll thank me later.
• Not processing locales properly — locale information might arrive in your app in different formats. Of course, the simplest scenario is when just you get the language code, like en or fr. Unfortunately, that’s not always the case because typically locales will also contain regional codes, like en_GB and en_US (to make things more complex, there can be either _ or - separators). Thus, you’ll need to properly process these codes and provide fallback locales for when the requested language is unavailable.
• Not planning key naming and organization — as your application grows, you might have dozens or hundreds of translation keys. If you don’t have a clear strategy on how to name and where to store them, things will rapidly descend into chaos. Thus, we recommend planning how exactly your keys will be organized before doing any i18n.
• Adding internationalization as an afterthought — adding i18n to an already built application used by real customers is probably one of the most painful and annoying things to do. The worst-case scenario might mean rewriting half the app while fixing any bugs that will inevitably arise.

I18n and developers

Here’s the deal: it’s your responsibility as a developer to prepare your software for global expansion! At the very least, you will need to extract hard-coded texts into separate translation files and use special placeholders in the source code. Why? Because later you’ll probably hire translators to work on the texts, and it’s highly unlikely they will be willing to edit the source code directly. Frankly, I don’t think you’ll want that to happen either.

Next, you’ll need to make sure that the chosen fonts can actually support the target languages, and that the strings are in Unicode (or some customers will see fancy question marks instead of proper words). Also, don’t forget about date and time and currency formats, which will definitely vary from country to country. The actual approaches depend on the programming language and framework, but most likely there will be built-in functions to help with these processes.

If the app works with measurements, phone numbers, postal codes, and the like, don’t forget to introduce a certain level of flexibility for these as well. Make sure to work closely with designers so that the app’s pages (screens) can adapt to texts of varying lengths or with different reading directions.

Of course, remember to introduce language detection or at least a mechanism to serve the proper language version of the app. Usually adding a language switcher won’t hurt.

Finally, you might think about adding a simple way of replacing images (for example, banners) because certain images could require adaptation for some markets.

The benefits of internationalizing your software, app, or website

Even if your initial product design and launch are for an English-speaking audience, internationalization allows you to support other languages and cultures if you do decide to expand to additional markets in the future.

As we already know, i18n enables l10n. So, before translating anything you have to lay the groundwork, right? Even if currently you aren’t planning to expand, it’s still a very good idea to develop with internationalization in mind: after all, you never know what tomorrow will bring.

An internationalized app means reduced localization costs in the future, better user experience, and shorter time to market.

Tips for successful internationalization

Here are a few useful tips:

• Allocate budget for internationalization — you should understand that i18n is a separate process that requires time and effort. Therefore, make sure you have enough resources to implement this process.
• Build with internationalization in mind — as mentioned above, adding internationalization after the app is already up and running is really not advisable. Plan ahead for i18n. Study and follow the recommended practices.
• Think about good user experience — you are adding internationalization not because this article told you so or because your boss instructed you to. You’re adding it for a better user experience. After all, happy customers mean higher revenue.
• Be emphatic — analyze and research the target market. Keep an open mind.
• Use proper tools and approaches — modern languages and frameworks typically have built-in mechanisms for introducing i18n without any additional hassle. Even if they don’t, chances are you’ll be able to find third-party solutions solving this problem. Be sure to do some research, see what tools are available to you, and pick the ones that are the best fit.

What does good internationalization (i18n) mean?

So, let’s summarize. In essence, internationalization ensures broad usability across diverse regions and cultures. This entails making all text translatable and eliminating code dependency on specific languages or alphabets. Proper i18n enables your software to display prices in the relevant currency and present dates in a user-friendly format for the target market.

Crucially, employing effective internationalization through suitable software allows seamless translation without necessitating code modifications. This streamlines software development, simplifies bug resolution, and accelerates updates. By only updating the source code without altering translations, your business realizes significant time and cost savings in the long run.

If an application is appropriately internationalized, adding support for additional languages, editing multilingual texts, introducing more date and time formats and currencies, and replacing images should be straightforward. The application should function seamlessly, even when the text orientation changes or non-Latin characters are utilized, encompassing Arabic, Cyrillic letters, and the various glyphs used in Asian languages. Additionally, the software should be capable of detecting the preferred locale, delivering content in the requested locale whenever possible, and gracefully falling back to the default language if the translation is unavailable.

How to internationalize your software: i18n tutorials

Here’s a list of useful tutorials on internationalization:

• Internationalization vs. localization (i18n vs. l10n): What’s the difference? — learn about key differences between these two terms.
• Software internationalization: How to expand globally — this article presents tips for developers on performing i18n and also lists handy tools.
• 3 Signs you’re playing the internationalization (i18n) danger game — things to avoid when performing i18n.
• Going global: How to successfully translate your website — this is an in-depth tutorial that covers how exactly to internationalize and translate a website, what roles are required, what the recommended process is, and what the potential issues are.
• Crash course in localization — this course primarily focuses on localization, but still there are also useful lessons on i18n.
• I18n and l10n: List of developer tutorials — if you are a developer, then this list is a must-read. It contains links to step-by-step i18n tutorials focusing on individual languages and technologies: JS and its frameworks, Python and Django, Ruby and Rails, Go, and much more.
• Translation keys: naming conventions and organizing — learn about best practices concerning key naming and organization.
• The 9 biggest localization issues/problems developers face and how to solve them — this article lists common issues developers face when introducing i18n and then localizing their apps. Of course, it also provides ways to solve these issues!
• Decoding the digital landscape: Globalization vs. internationalization — learn about the benefits and issues of globalization and internationalization.
• Glossary of translation and localization terms — a nice compilation of common terms related to internationalization and localization.

Internationalize once. Translate everywhere.

So, in this article we have covered internationalization, its meaning, purpose, potential issues, and some useful tips. Hopefully, by now you’re feeling more confident about this term and are ready to implement it in your next project.

We at Lokalise fully understand that the process of internationalizing and translating apps is hard, so we have created a translation management system that can be a huge help to you. Upload your texts, translate into any language, hire professional translators, invite team members, take advantage of AI-powered translations and review, integrate with dozens of third-party services, and much more! Interested? Grab your free trial on the sign-up page and enjoy all Lokalise features for 14 days. No credit card required.

Frequently asked questions

What does i18n mean?

To put it simply, internationalization is the process of designing and developing software or products that can later be adapted to different languages and cultures.

Why is it called i18n?

Because the word “internationalization” is too long! Thus, people decided to shorten it by getting rid of the eighteen characters between the first “i” and the last “n”. To demonstrate that there are exactly eighteen characters, we say “i18n”.

What is an example of i18n?

Let’s say you’re internationalizing the dashboard of a software application, and you need to set up the keys for a welcome message. For now, the software will be sold in English and Spanish.

If 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 this:

confirm(t(title)); instead of confirm(“Welcome!”); or confirm(“¡Bienvenidos!”);.

On top of that, you’ll need to enable cultural formatting, including number formats and systems, time zones, personal information, and text formatting.