Implementation and universalization of i18n in CMS / CMF

Foreword

Faced a pressing problem that automatically becomes a task:
How to implement a universal translation mechanism for site content that would satisfy the needs of both small sites and large portals?


I would like to hear the opinion of competent users who have faced this or a similar task.


')

So, we set the task:

It is necessary to implement a multilingual site that will be convenient to edit and translate. The site consists of the n-th number of static pages. The number of languages ​​is not defined, maybe 2, maybe 20.

The approximate structure of the table is as follows:

id - ( ) ;
title - () ;
description - () ;
full_text - () .


Arguments:

• There is a tool - self-made CMF, which is trained in automatic generation of admin panel, generation of content output (all generators are built on the base structure) and many other pleasant amenities to facilitate routine work.
• There are ideas for the implementation laid out below.

Result:

• Convenient administrative interface for translating site content.
• Trivial site with static pages in a large number of languages.

Let's go to the ideas

I did not think about the names of ideas, but I will subjectively characterize. So we will identify them.

1. Bad, clear and accessible:
Do not bathe with universalization and create fields with postfixes in the same table that define each language, i.e. will be like this:

id
title_ru
description_ru
full_text_ru
title_en
description_en
full_text_en


Naturally, the option has the right to life, but only when you have two or three languages. When there are more, then this structure will be very uncomfortable. And if there are more translated fields ...
Plus the fact that being on a certain page in one language, we get to the same page in another language. Administration of a large number of languages ​​is inconvenient due to the number of editable fields.

2. Clear, correct and normal:
More versatile than the previous one. We add to this table only one field:

id
title
description
full_text
culture <-


Where culture is the language identifier of the current page.
The downside is that when a user is on a certain page, the site cannot know exactly where the translation is on a specific page. With a large number of languages, language versions of the site can be completely different. Editing is simple: I chose the language in which you want to edit, and there you manage with the addition of new pages.

3. Clear, correct, normal and improved:
We add another field to the previous structure:

id
title
description
full_text
culture
parent_page_id <-


Where parent_page_id is the identifier of the original page.
Then we have the minus of the previous structure is removed. But addictive language is added. Editing is the same as in the previous model, one select is added with a large number of pages in the original language.

4. Interesting, correct, but more complex:
Table page structure:

id
, ,


Add the table page _i18n :

id
page_id - page
title
description
full_text
culture -


Accordingly, for the output will have to use a sample of two tables.
Editing such a structure is not difficult. You can even choose the direction of translation. You can translate a specific page. Find which pages there is no translation. There is a full bunch of pages on the site.

5. Interesting and complex wiki translation:
The idea of ​​the translation mechanism is taken from launchpad.net
Good for big projects where there are a lot of translators.

Just as in the past version.
Table page structure:

id
, ,


Add the page _i18n_cache table:

id
page_id - page
title
description
full_text
culture -
, ,


Create a table i18n_translate :

id
page_id - page
field - page_i18n_cache , title
translate -
user_id -
publish -
culture -
, , , . .


1. In this case, we have impeccable independence from the original, i.e. we can choose any language in the original language.
2. The "cached" scheme, i.e. To select a specific page, we need to make one sample and not merge with other tables. The cached table contains only published versions of the translation.
3. The translation interface is simple: the user sees the original string, the strings translated by other users, and the fields for entering their version.

Total

I abstractly described those 5 models to which I came. On the Internet I found information only on the first two options.
It is very interesting to hear your opinion on how to correctly implement this translation mechanism. Interesting information about translation interfaces (specifically for commercial projects).

Thanks for attention!