How we made the automation of translation into 29 locales: assembling the zoo in a well-organized system

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

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

• A master text in English (USA) appears. It rolls out to all sites as a "golden" image.
• If there is a direct translation into the locale language, it is used.
• If there is no direct translation into the locale language, but there is a translation into the inheritance language, the text in the inheritance language is used.

That is, in Mexico (where they speak a language derived from Spanish), the chain will be as follows: check Mexican; if not, take Spanish; if not, put English to USA. In the UK, the sequence is shorter: classic English, then American English. At the same time, the price is inherited in a different way: first, the local is checked, then the American, and not the European, is taken.

The second important thing is to break all entire pages into pieces 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 Drupal made everything out of the box where it was “wooden” and simpler.

Introductory information

A lot of content, transparent, but not a short editing process, review of translations and proofreading. About 30 people editing the site. Just one Drupal 7 instance. Different content on the 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 writes code, content is born

Perhaps it should be, but it doesn’t always happen, right? We, frankly, in this regard, everything is very orderly and debugged.

• We build on the base language (English) and it is on it that we form translatable strings, field contents, and pictures.
• This content is adjusted in the process of posting on the site, undergoes the initial review and becomes the starting point for further actions.
• At the exit, we have fully finished pages, in layout, with content in English. It is worth noting 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 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 overloaded way using the locale module . We went along the second path - Entity Translation, due to which we do not have as many records in the node table as it could be .

It wasn't good right away

• We went through a huge number of incredible adventures to find random, strange and sometimes frightening bugs in Entity Translation.
• We found such a beautiful and tidy code that we were forced to become morally more stable.
• All this is very fast and stable and worked 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.

And finally built ...

We tried very hard to do everything so that our colleagues could translate taxonomy terms, and taxonomy term reference widgets could show localized term headers. We managed to teach Drupal to bypass the entire chain of candidate languages ​​for translation in different situations exactly the way we want it. It was also possible to make a very accurate and expandable system for processing currency formats with its own separate inheritance mechanism. We have several of our own Entity types, which are also perfectly managed, translated in the same style. We managed to make flexible menu functionality, the functionality of which went very far beyond the limits of "node /".



We copied a little modified the well-known project Translation Management Tool and taught it the trickstranslate all of our entities, process our own tokens, upload case transfers to XLIFF with dependencies, as well as a couple of tricks.

We also had to write our own options for hiding / showing entities for the necessary locales, which can correctly return access material at the request stage (approximately the way 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. Hidden pages were followed by their own delivery callback , so as not to give 403 clients indiscriminately.

Tokenize it!

It so happened that we liked using tokens. Changes are good, and we decided 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. Remove or change the phone on 20 pages on 1 locale? - Easy! Remove some options from an offer in Australia? - Of course!



We implemented our tokens to set the correct URL links in the content with our own algorithm of work aimed at always returning a localized link to the client, even if there is a redirect from the specified page, but it itself does not exist.

The most important thing is localization

And all that we talked about for the sake of this moment. Our localization team from Moscow is able to interact perfectly with Drupal. This is precisely what we were going to - the process has become almost parallel. The guys create tasks for downloading data from all fields of the selected pages, indicating which language a translation is required in, and take XLIFF files to start their work. Translators into rare languages ​​themselves, as a rule, are remote employees or agencies with native speakers, so the unloading is simply transferred outside. There it is translated, again driven into the software of our translators, and from there, after verification, it is imported into Drupal, where new translations for each Entity are automatically created and the values ​​of the translated fields are added. It remains to send a link to the translated version of the page to the regional manager.

Conclusion

We have very good experience working with a multilingual and very complex structure within the same system instance. We, stably with Zero Downtime, update the site releases. We intentionally did not break the site into a whole mass of small sites, because it is really more correct, at least from the point of view of service. An important point of our conclusion is that we managed to achieve all of the above successes without hacking the Drupal core at all .