In what ways do you support the "internationality" of content on content sites?

Question

Internationalization and localization

Usually, when they talk about the localization of the site, they mean that you have files, there are all the attributes of menus, sit and translate. Okay, but these are menu items... And what if the site, for example, has sections:
1. blogs
2. books
3. tools (calculators)
Here a Spaniard came to the site in the section of calculators. Here, in general, you can get by with localization attributes, just through the keys in the files. Those. Pedro went in, saw the text in Spanish (menu items), and the tool was also in Spanish (buttons clear, submit, name, etc.).
OK. But the difficulties begin with books. A book is a record in a database (title, description, author, picture). Here's how to store it? I was offered this option here:
- one table, in which only text identifiers
- another table, this is an attribute, language, text
Yes, solves the problem, i.e. we can give information locally, but alas, this will not work quickly.
OK. What about blogs? Pedro, Vasya and Nikolay write in three different languages. How then to separate them? And what to show to the new user? Only content that matches its region?
Sorry, everything is probably chaotic, but I did not find articles either on storing such information or on the client side.

Answer 1

www.vertabelo.com/blog/technical-articles/data-mod...

Answer 2

Each framework has its own implementation. Someone prefers to manually implement this functionality. I have come across both.
At my work, a Django project now uses a self-written system in which fields of the form are automatically generated title_enfor title_zh_cneach of the defined languages ​​in settings.LANGUAGES. In other projects, I used a ready-made library for Django: django-modeltranslation .
The most advanced CMS for Django uses its own approach: Creating a multilingual site .

Answer 3

Hey!
Firstly, the examples given are completely different tasks, so their solutions are also very different.
If it is possible to pre-translate, for example, for menu buttons or for the buttons of some tools, then you need to do this in advance. Many mechanisms are self-written, but different frameworks also have their own implementations, for example, if you use npm, look at globalize npm. The point is that all texts are placed in separate files (usually on the client) and they can be edited separately and new ones can be easily added.
As for books, this is working with the database, you need to move the texts to a separate table / tables, or add a language identifier and store them in one table. In any case, you have an increase in the size of the database and an increase in the complexity of queries and the complexity of the work. Naturally, it will work slower, this is such a fee.
If we talk about dynamically generated content, as an option, if it suits you, you can split the pages. That is, there will be a forum in Russian and a forum in English, and they do not intersect.
There is another option, the offices that are engaged in translations usually have api (you can look at least Yandex Translate, at least Google Translate, there are still a lot of specialized ones). Such APIs are usually paid. Accordingly, a comment is written in Spanish, this text is run through the api (for each language used) and the result is recorded in an organized database, approximately like for books. Well, yes, this, of course, is a machine translation of so-so quality.