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.
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:
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:
Now that we know the difference let's see how that can apply to Software.
After reading and doing some research my personal conclusion is that there are two main areas in regards of localizing.
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.
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:
And our fields that need localization are:
Then we need to add a couple of columns to link the translations with the localization.
The final design for our localized database would be as follows:
|description||varchar(250)||Teach the english language|
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.
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).
|value||varchar(250)||Welcome to my awesome App|
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!