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.
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.
How to translate?
As you know, in Drupal 7 there are only two options to translate content: make a full copy of
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 tidycode that we were forced to become morally more stable.
- All this is
very fast and stableand worked well under load.
- Uploading translations was
- 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 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.
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.
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 .