How to implement i18n in your WebApp? Part 1

adancarrasco profile image Adán Carrasco ・3 min read

One common denominator for Software is that it can scale, most of the time scaling comes with i18n (internationalization) and l10n (localization). This time, I'm going to show you a way on how you can implement those in your application. As i18n involves many layers I will split the posts in different parts. This part will cover the database.

What is i18n and l10n?

Internationalization better known as i18n, and localization better known as (l10n), is the part of Software where you handle the representation of your data/content depending on where it's consumed. As we know there are a lot of languages, and even in languages there are many variations.

Depending on your region, you may write: Localization or localisation; and internationalization or internationalisation.

Let's see it in an example:

Language Region Word locale tag
English United States Internationalization en_us
English England Internationalisation en_gb

In the previous example, even tough the language is the same, depending on the region the writing might be different and in some cases the meaning will be different as well.

Or we can just simply support different languages:

Language Region Word locale tag
English United States Hello en_us
Spanish Mexico Hola es_mx
German Germany Hallo de_de

Now that we know the difference let's see how that can apply to Software.

Localizing Software

After reading and doing some research my personal conclusion is that there are two main areas in regards of localizing.

1. Your app's data

The first part is your data, and this is what you have in your database that can dynamically change, it can be the products you sell, the articles you have, jobs you offer, any description, etc.

Before i18n

id uuid PK
posted_date date
title varchar(50)
description varchar(250)

If we had the necessity to add one more language, keeping this structure, all of our data would be duplicated. For this we can extract common fields and create a translation_entity table.

Where our fields that doesn't need localization are:

id uuid PK
posted_date date

And our fields that need localization are:

title varchar(50)
description varchar(250)

Then we need to add a couple of columns to link the translations with the localization.

job_id uuid FK
locale_id uuid FK

After i18n

The final design for our localized database would be as follows:


job sample data
id uuid PK 1111-2222-3333-4444
posted_date date 2020-26-04 19:52:44


job_translation sample data
job_id uuid FK 1111-2222-3333-4444
locale_id uuid FK 4444-3333-2222-1111
title varchar(50) English teacher
description varchar(250) Teach the english language


locale sample data
id guid PK 4444-3333-2222-1111
ISO varchar(5) en-us

With this we will have unique data for each language our application will support.

In this example the columns to be localized are only two but if we had 10, 50, we will be saving a lot of space as well as performance and scalability will be reflected.

2. Your app's presentation

In the other hand, there's the part that is not involved in our data. This comes from the presentation layer, such as labels, texts, alt for images, etc. That part can easily be put in a single table (it can get complex as well depending on the needs, for now, let's keep it simple).

translation sample data
id uuid PK 3333-1111-2222-4444
locale_id varchar(5) FK 4444-3333-2222-1111
locale_key varchar(100) homePage.welcomeMessage.h1
value varchar(250) Welcome to my awesome App

Ready to persist localized data

Separating your data in those two main layers will give you enough to have your App ready to scale in terms of different languages/regions.

This summarizes all regarding the database so you can translate your App. In the following posts I will be posting how to manage this data in the Application Layer as well as in the Presentation Layer.

How do you localize your apps? Do you know any other ways to do it? Feel free to share.

Thanks for reading!


markdown guide