Support for multilingualism in web projects - basic implementation options

When dealing with projects related to web development, I came across various options for implementing support for several languages ​​for sites, portals and web applications. Here I described the basic options for implementing the database architecture that I met most often.
I think this article will be useful for beginners in web development, and I invite those who already have experience in building multilingual systems to discuss the options that you prefer.

1. Creating fields for each language

Implementation: for each field for each language, a separate column is created 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 fields that are independent of a particular language and a table containing fields requiring translation. Also, a table is created in the database with a list of available languages.
Features: this approach allows you to implement quite flexible extensibility of supported languages. The structure of this option is a bit more complicated than the previous one and involves the creation of a satellite table for each table containing localized fields.

3. Using serialized data of complex structure

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

4. Separate entry in the table for each language

Implementation: in each table that describes the entity, a field requiring localization indicating the language to which the record belongs. Also, a table is created in the database with a list of available languages.
Features: this option is noteworthy in that in fact one object of the subject area can correspond to several objects in the database and several relationships. That can complicate the business logic quite a lot.

5. Lack of localization at the database level. Using external localization tools

This option does not directly relate to the topic of the article, but I think it's worth mentioning.
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 option can only be considered as very budgetary (when there are no resources for the translation of each publication) and before its application I would recommend to think carefully - is it worth it to implement it at all?

6. Creating a translation table for each language

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

Storage of "static" text information

A few words about storing static text information. By it I mean button labels, footer information and the rest of the text of a type that in most cases is not changed by the content manager, and when implementing monolingual sites it is entered directly into the template. In the case of a multilingual site for storing such a text, there may be several options:

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

Other options

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

Helpful information

• Creation of multilingual sites (sharepoint)
• ASP.NET MVC Lesson C. Multilingual Website
• Six tips for building sites for a multilingual audience from Google Web Studio
• Zend Framework and multilingualism
• LilacServer - box for creating sites in Java
• Localization of the site interface using PHP, Smarty and Gettext
• Multilingual Django Starter Models
• ASP.NET MVC 2 Localization complete guide
• Multilingual WordPress