How to organize the database structure for multilingual CMS?

Question

MySQL

Good day, toasters!
The question is actually this.
How is it most convenient to organize the database structure for writing a multilingual CMS?
The goal is this: You need to somehow store translations of section names, translations of news, pages, and then you can organize a search on the site, and specifically on translations of a particular language.
I organized it like this (table structure with translations of news and sections in this case):

----------------------------------------------------------------
| id | section_id | news_id | lang | title | description | ... |
----------------------------------------------------------------

But with this approach, when you need to select translations in any language, then everything is super if there is such an entry, and if not, then you need to select an entry in the default language. Everything seems to be super, but if I choose, for example, News, of which there are 1000, then this is +1000 requests for translations.
There are several advantages to this approach:

1. no need to go into the database and change the structure if a new language is added
   
2. It is very convenient to implement the search
   
3. All translations are stored in one table
   

Of the minuses, only that there are a lot of requests, but maybe I don’t have the mind to organize the selection correctly.
Then can you tell me how to properly razrulit it?
An example request is below:

$news = News::get();
    foreach ($news as $nws) {
        $data[] = [
            'id' => $nws->id,
            'good' => $nws->good,
            'translates' => $nws->translations()->where('lang', App::getLocale())->get()->toArray()
        ];
    }

There is an article on Habré, but I thought maybe someone else would share their experience here.

Answer 1

For each entity, two tables are created: the main table and the table with translations. There should also be a table with a list of languages ​​(languages) For example, we have a Post entity (publication), it will have the following database structure:
id, slug, published_at
id, post_id, language_id, title, content

Answer 2

I made it a rectangle: one entry is one publication / article, and translations are in columns.

id | section_id | news_id | title[en-en] | title[ru-ru] | description[en-en] | description[ru-ru] |...

it's just that you will have more than 4-5 languages ​​- this is unlikely, but the speed of searching (filtering) in the desired language and in the required columns - this greatly affects the better. Don't forget to clearly indicate the columns that you want to display in the query results (and sometimes LIMIT too) and that's it.

Answer 3

In fact, it turns out that one piece of news is a set of records in the database. If you resort to the 1st normal form, then you get something like
And the primary key in this case is already a bunch of id + lang_id. With an incoming request, the language that the browser needs is already determined and is simply substituted for all values.
But then you will have to organize work with AUTO_INCREMENT yourself, since uniqueness already goes at the id + lang_id level