Translation module

Summary

Adds the ability to localize strings in the backend side.

Closes #1529 (closed)

⚠ ⚠ IMPORTANT ⚠ ⚠

See that I've updated the docker php image with the php-intl extension

How it works

All translation files must be saved to engine/translations, with the xliff format. I've included one in this MR as an example which will later be removed when we start implementing this to email templates.

Files (at least for now) must be named with the following format: messages.LOCALE.xliff. e.g.: messages.es.xliff

After adding your new file, make sure to add it to settings.php and settings.example.php under the i18n key, with the following format:

$CONFIG->set('i18n', [
    'languages' => [
        'en' => 'English',
        'es' => 'Español',
    ],
]);

How to use

// get the translator
/** @var Core\I18n\Translator $translator */
$translator = Di::_()->get('Translator');

// set your desired locale (in the future we'll take this from either the Accept-Language header or the User's configured language)
$translator->setLocale('es');

// translate the string
echo $translator->translate('Test'));

Updating translations

There's a CLI called I18nTranslator which updates engine/translations/messages.en.xliff which is the one that will be uploaded to Crowdin for them to translate to different locales.

Important

• The extractor will only detect calls to $translator->trans()
• If you pass a variable to the trans method, it won't be detected either. This means that, if you need to use a variable, you'll have to assign it the translated value. e.g. $var = $translator->trans('Test');

Possible regressions

I had to remove mongodb and comment out Boost\Network\Metrics, and I also had to update the ext-redis virtual package. So far I haven't experienced any issues locally, but it's definitely something to pay attention to.