Multilingual support in web projects - basic implementation options

Being engaged in projects related to web development, I came across various implementation options for supporting multiple languages for websites, portals and web applications. Here I described the basic variants of the implementation of the database architecture that I met most often.
I think for newbies in web development this article will be useful, and I’m inviting those who already have experience in building multilingual systems to discuss the options that you prefer.

1. Creating fields for each language

Implementation: a separate column is created for each field in each language in the table
Features: with a large number of languages, or with an unknown number of languages in advance, this approach will require changing the database structure every time you need to implement support for a new language.
When to use: when the number of supported languages is clearly known in advance, and each entity must exist in all language variants.

2. Creating a localization table

Implementation: for each entity requiring localization, two tables are created. The main table containing the fields that are independent of the specific language and the table containing the fields to be translated. A table with a list of available languages is also created in the database.
Features: this approach makes it possible to implement a fairly flexible extensibility of supported languages. The structure of this variant is a bit more complicated than the previous one and involves the creation of a satellite table for each table containing localizable fields.

3. Using serialized data of complex structure

Implementation: in each field requiring translation, information is written in a serialized form, for example, in JSON, XML, binary, etc. The object may be, for example, a dictionary, in which the key is a language, the value is a text. Or any other structure.
Features: the main feature is that data integrity depends not only on the database, but also on the serialization mechanism. In addition, in this embodiment, the normalization of the database is also greatly reduced.
')

4. A separate entry in the table for each language

Implementation: in each table that describes an entity that requires a localization field indicating the language to which the entry belongs. A table with a list of available languages is also created in the database.
Features: This option is remarkable because in fact one object of the domain can correspond to several objects in the database and several connections. WHAT can complicate business logic quite a lot.

5. Lack of localization at the database level. Use of external loklaizatsii means

This option does not relate directly to the topic of the article, but I think that it is worth mentioning it.
Implementation: the method is implemented through external plug-ins (Google translate, Bing translate, etc.).
Features: this option can be applied if the owner of the resource wants to be able to provide information to as many visitors as possible. It should be understood that the quality of machine translation often leaves much to be desired. The variant can be considered only as very budget (when there are no resources for translation of each publication) and before applying it I would recommend to think carefully about whether it is worth implementing it at all.

6. Creating a translation table for each language

The option proposed by habrapolzovatelem VolCh .
Implementation: for each language in the database, a separate table is created containing the fields to be translated.
Features: when adding a new language, you need to make changes to the database. With a large number of languages supported, the number of tables can be very large.

Storage of "static" text information

A few words about storing static text information. Under it, I mean the inscriptions on the buttons, the information in the footer and the rest of the text of this type, which in most cases does not change the content manager, and when implementing monolingual sites is entered directly into the template. In the case of a multilingual website, there may be several options for such a text:

The text is stored in the database and cached when the web application is started — the option allows you to potentially expand the number of supported languages. In fact, the text becomes not static, but quite dynamic content.
The text is stored in the resource files - the speed option is faster than the previous version, but editing the web application files is necessary to add the language
For each language variant, a separate template is created containing static text - in my opinion an unnecessarily redundant version. It has the same drawbacks as the previous one.

Other options

If you want to suggest any other options for implementing multilanguage other than those described, write to me and I will include them in the article.
Also, it would be interesting to know which arguments, other than those described above, are important for you when choosing the preferred implementation option.

Useful information

Source: https://habr.com/ru/post/192228/

All Articles