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
| job | |
|---|---|
| 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:
| job | |
|---|---|
| id | uuid PK |
| posted_date | date |
And our fields that need localization are:
| job_translation | |
|---|---|
| title | varchar(50) |
| description | varchar(250) |
Then we need to add a couple of columns to link the translations with the localization.
| job_translation | |
|---|---|
| job_id | uuid FK |
| locale_id | uuid FK |
After i18n
The final design for our localized database would be as follows:
Entity
| job | sample data | |
|---|---|---|
| id | uuid PK | 1111-2222-3333-4444 |
| posted_date | date | 2020-26-04 19:52:44 |
Entity-Translation
| 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 |
Locales
| 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!
Top comments (0)