As we did automate the translation to 29 locales: build the zoo into a coherent system

Acronis is an international company with a major R & D in Russia, but our main language is English. Regional products have their own languages, and there are quite a lot of them. Site languages ​​are even more than software languages.

Therefore, we have made such a system on Drupal, and not without distortions:

• The master text in English (US) appears. He rolls on all sites as a "golden" image.
• If there is a direct translation into the locale, it is used.
• If there is no direct translation into the locale language, but there is a translation into the language of inheritance, the text in the language of inheritance is used.

That is, in Mexico (where they speak the language derived from Spanish), the chain will be: check Mexican; if not, take Spanish; if not - put the US English. In the UK, the sequence is shorter: classical English, then American English. In this case, the price is inherited along a different path: first, the local one is checked, then the American one is taken, and not the European one.
')
The second important thing is to break all whole pages into chunks and tokens in order to ensure the dependence of variables (prices, date formats, product names, individual button names, and so on). Perversions were needed, because out of the box Drupal was doing everything where “wooden” and simpler.

Introductory information

A lot of content, transparent, but not a short editing process, review of translations and proofing. About 30 people editing the site. Only one Drupal 7 instance. Different content on locales - special offers, discounts, currencies and its format, as well as the availability of products and pages depending on certain conditions. Interesting, right?

While someone is writing code, content is born.

Perhaps it should be, but it does not always happen, right? To be honest, we have everything in a very orderly and streamlined manner.

• We start from the base language (English) and it is on it that we form translatable strings, the contents of fields, and pictures.
• This content in the process of posting on the site is adjusted, passes the primary review and becomes the starting point for further action.
• At the exit we have completely finished pages, in layout, with content in English. It should be noted that this work is divided into 2 processes: simple placement of text in the Drupal interface and layout, writing JavaScript code and template files containing translatable strings using the D (t) Drupal function.

How to translate?

As you know, in Drupal 7 there are only two options to translate content: make a full copy of any entity or translate fields. The first is a more “nuclear”, but less flexible and frankly overloaded method using the locale module. We took the second path - Entity Translation, so that in the node table we do not have as many records as we could have .

It was not good right away

• We experienced a huge number of incredible adventures to find random, strange and sometimes frightening bugs in Entity Translation.
• We found such a beautiful and neat code that we were forced to become morally more stable.
• All this is very fast and stable and works well under load.
• Uploading translations was very convenient .
• Like all boxed systems, Drupal 7 was initially not very convenient and pleasant, but its flexibility gave us a chance.

Finally built ...

We tried very hard to do everything so that our colleagues could translate taxonomy terms, and the taxonomy term reference widgets knew how to display localized term headings. We managed to teach Drupal to bypass the whole chain of candidate languages ​​for translation in different situations exactly the way we want it. We also managed to make a very accurate and extensible system for processing currency formats with its own separate inheritance mechanism. We have several of our own Entity-types, which are also well managed, translated in the same style. We managed to make a flexible menu functionality, the functionality of which went very far beyond the “node /” limits.



We rewrote a little modified the famous Translation Management Tool project and taught it tricks to translate all our entities, process our own tokens, upload translations of cases to the XLIFF with dependencies, as well as a couple of tricks.

We also had to write our own options for hiding / showing entities for the required locales, which can correctly return access to the material at the request stage (approximately as it is organized in the access system), which made this option “pass-through” to the menu itself - links to hidden Pages disappear from the menu for the desired locale. The “hidden” pages were followed by their own delivery callback , in order not to give 403 customers indiscriminately.

Token it!

It so happened that we liked to use tokens. Changes are good, and we thought up to put tokens, for example, in templates or body parts of pages. Tokens, as a rule, are entities of another, our own type - Template. This allowed us to organize ourselves, develop a standard for the name and arrangement of these tokens and not be afraid of changes. To remove or change the phone on 20 pages for 1 locale? - Easy! Remove some of the options from the offer in Australia? - Of course!



We implemented our tokens to set up the correct URLs in the content with our own algorithm, aimed to always return the localized link to the client, even if there is a redirect from the specified page, and the link itself no longer exists.

The most important thing is localization

And everything we talked about for this moment. Our localization team from Moscow is able to perfectly interact with Drupal. We went to just that - the process became almost parallel. The guys create tasks to upload data from all the fields of the selected pages, indicating which language is required to translate, and take XLIFF files to start their work. The translators themselves into rare languages ​​are usually remote employees or agencies with native speakers, so the upload is simply transferred outside. There it is translated, it is again pushed into the software of our translators, and from there, after verification, it is imported into Drupal, where new translations are automatically created for each Entity and the values ​​of the translatable fields are added. It remains to send a link to the translated version of the page to the regional manager.

Conclusion

We have a very good experience in working with a multilingual and highly complex structure within one instance of the system. We are stable with Zero Downtime, update site releases. We deliberately did not break the site into a whole mass of small sites, because this is indeed more correct, at least in terms of service. An important point of our conclusion is that we managed to achieve all the successes listed above without hacking the core Drupal.