I feel that the answers when you search on the web for this problem are not clear enough so I want to make a compilation of the steps I follow to achieve this.

When I write "interface translations" I refer to those string written always in English (even when the site we are developing has no English enabled) that are typically surrounded by a t() function, a twig trans filter or are part of some yml definition like module_name.links.menu .yml. For translating configuration the process is quite different.

The main page for information about this is the Drupal API page and its comments but those are not shared among the different versions of that page so some information gets a bit sunk as new minor versions of Drupal core are released.

The first step is to add two lines more to our example_event.info.yml file like this:

name: Example event
type: module
description: Functionality related with the date the event happens
package: Custom
core: 8.x
'interface translation project': example_event
'interface translation server pattern': 'modules/custom/example_event/translations/%language.po'

This way we are telling Drupal to look into the translations directory of the custom module for files named like "es.po" or whatever is the language code we are translating to.

Files with te .po extension are in the gettext format so it will look like this:

msgid "" 
msgstr "" 
"Project-Id-Version: Example event\n" 
"MIME-Version: 1.0\n" 
"Content-Type: text/plain; charset=utf-8\n" 
"Content-Transfer-Encoding: 8bit\n" 
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
msgid "My custom string" msgstr "Mi cadena personalizada"
msgid "Every last Thursday of the month at 20:00 in @location" 
msgstr "Todos los últimos jueves de mes en @location a las 20:00"

Then we can commit this file into the version control system to keep track of changes.

Drupal string translations live in the database not in files so to update the database we need two commands:

 drush locale-check

To check for new translations (contrib modules will be checked also).

 drush locale-update

To store the translated strings in the database based on the .po files.

Add these two drush commands to your deployment/CI to have the interface translated.

This is tested on Drupal 8.4.x but I don't think compatibility for this will be removed.

To be able to scan your code to look for translatable strings instead of creating your .po file manually the potx module can be used (or a heavily patched Drupal 8 version to be able to run it within your installation).

So that is pretty much everything you need to know to translate automatically. In general I think the process needs too much code and it should be more simple like an auto discovery of the "translations" folder.

Tags