Loco Translate – A solution to your translations headaches in Drupal 8

You probably already know, I live in Switzerland and - beside chocolate & cheese - this country has one another singularity: 4 official national languages. As a result, more than 90% of our web creations need to be localised in at least 2 languages.
This peculiarity makes us experts in the creation of multilingual websites.

“ Switzerland is a small, steep country, much more up and down than sideways, and is all stuck over with large brown hotels built on the cuckoo style of architecture. ”
Ernest Hemingway

At Antistatique, we work under the DSP model - Development, Staging, and Production. This model is essential for providing the checks and balances necessary for running a high-availability production server environment efficiently.

DSP model Process — Photo credit: Atlassian

The basic concept of DSP servers is simple. Developers test their code locally to see whether that application will run with other code.
Once the developer is satisfied that the application is ready for prime time, the application moves to a Staging server. The Staging server is a mirror copy of the Production server; its primary purpose is to test the completed application on the mirrored copy of production to ensure that the application doesn't break the existing production server applications.

The Staging server is the last step before the application is ready for deployment to a production server. A final approval process follows Staging to make sure that all interested parties sign off before the application goes into production. When the application has approval, it moves to Production.

As we use multiple development environments - development, staging & production - we face an obvious issue: our customer should update the same translation strings in multiple places. Plus, in some cases, they might not have access to the new translations strings on the production database, not before we've released the new version of the code.

Capture d'écran de Google translate — Let's be honest, translations in Drupal 8 is painful.

The idea behind Loco Translate comes from a need to be centralised in one single platform the translations of the same project. To achieve this goal, we chose Loco as our SaSS translations platform.

Warning, when using a single point of Translations, the same translation strings will be used in every environment, and so you should never change the meaning of an existing translation.
Example: You have a button button.article.action which has been translated Download.
Let's say, for the next release version, the same button should mean See more. I recommend you to replace your old button.article.action by a new string button.article.see_more. Otherwise your customer will translate button.article.action into Download (to match the next release desired meaning) leading to a mismatching translation on the production environment.

Translations headaches

Bonjour en plusieurs langues — Photo credit: Mozilla

As you may already know, Drupal opt-in for a Source text based translation process.

Indeed, instead of using unique Assets ID (such as Symfony or Laravel via some YAML files), Drupal opt-in for a Source text database translations.

Let's see the difference between those 2 translations paradigms using the example of a translatable button "Add to cart":

Source text: Add to cart
Asset ID: buttons.add_to_cart

What the F* are Source text translations

The Source text translation means that original translations wrote in Drupal source-code should match the default project language.

$this->('Add to cart');

msgid "Add to cart"
msgstr "Add to cart"

What the F* are Assets ID translations

The Assets ID translation means that original translations wrote in Drupal source-code does not match any language, it's a unique key to identify a translation.

$this->('buttons.actions.add_to_cart');

msgid "buttons.actions.add_to_cart"
msgstr "Add to cart"

As you may see, the Source text based translations are not very convenient for developers.
Indeed, sometimes developers are not in charge of final wording.

For this reason, we - at Antistatique - prefer to use Assets ID based translations.

How does it work

Loco Translate is pretty easy to use.

When a new translation is created by a developer in any none-production environment, the CI/CD process will push all new translation strings into Loco. By doing this, we ensure all new translations will immediately be available for customers to be translated.

Then we configure Loco Translate to periodically fetch every translations - flagged as translated - from Loco into Drupal. With this process, we ensure all development environments (staging & production, ...) are always up-to-date with the latest translations.

Schéma — Me trying to explain how Loco Translate works

I hope you enjoyed learning this interesting concept!

I would suggest you read the official documentation for the whole technical implementation of the module in your Drupal 8 project.

Sources

The official documentation.

For the most curious, here are some sources of additional information that inspired the creation of this article.

Drupal community (11 October 2019). Making Your Site Multilingual.
Retrieved from https://www.drupal.org/docs/../../multilingual...

Allen Jones (27 March 2000). The Development, Staging, and Production Model.
Retrieved from https://www.itprotoday.com/devops-...

Chizoba Ogbonna (3 February 2019). Having different variants (debug/staging/release) of your app on a single device.
Retrieved from https://blog.chizobaogbonna.me/having-different-...

Drupal translation community (11 October 2019). Translate Drupal.
Retrieved from https://localize.drupal.org

Daniel Lanz (12 April 2017). Drupal 8 – Multilanguage Improvements.
Retrieved from https://www.liip.ch/.../.../drupal-8-multilan...