New in Symfony 5.1: Translation improvements

Allow to configure the enabled locales

Contributed by
Javier Eguiluz
in #32433.

Most Symfony applications are available in one or just a few languages. However, Symfony generates the translation files for the validation and security messages in all languages.

In other words, Symfony generates tens of (small) translation files that your appplication will never use. In Symfony 5.1 we've introduced the enabled_locales option to control this behavior:

1
2
3
4

# config/packages/translation.yaml
framework:
    translator:
        enabled_locales: ['en', 'fr']

This config tells Symfony that the application is available only in English and French, so those will be the only files generated by Symfony. This can improve performance a bit.

This option is unlocking other optimizations, such as #35590, contributed by Nicolas Grekas, which uses it to restrict the possible values of the default value of the _locale parameter in routes.

Improved the translation debug command

Contributed by
Arun Philip
in #29139.

The debug:translation command helps you find missing or unused translation messages in your Symfony applications. In Symfony 5.1 we've improved the command to return different exit codes depending on the found issues.

For example, in previous Symfony versions, the command returned 1 when there was any issue. In Symfony 5.1, if there are missing translations it returns the value stored in TranslationDebugCommand::EXIT_CODE_MISSING, if there are unused translations it returns TranslationDebugCommand::EXIT_CODE_UNUSED, etc.

You can also combine these values to check for multiple issues:

1
2
3
4
5

use Symfony\Bundle\FrameworkBundle\Command\TranslationDebugCommand;

if (TranslationDebugCommand::EXIT_CODE_MISSING | TranslationDebugCommand::EXIT_CODE_UNUSED) {
    // ... there are missing and/or unused translations
}

Added support for name attributes in Xliff2

Contributed by
Baptiste Clavié
in #35373.

When using XLIFF2 to manage your translations, it's common to use the original content as the translation key. In Symfony 5.1 we added support for using the name attribute, if defined:

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en-US">
    <file id="f1" original="Graphic Example.psd">
        <unit id="1" name="the_translation_key">
            <segment>
                <source>The original content</source>
                <target>The translated content</target>
            </segment>
        </unit>
        <!-- ... -->
    </file>
</xliff>

Allow to translate language names

Contributed by
Javier Eguiluz
in #32388.

In multilingual applications, it's common to list the available languages translated into the current language. For example, display "English, Spanish, Japanese, etc." when browsing the application in English and display "anglais, espagnol, japonais, etc." when browsing the application in French.

However, other multilingual applications prefer to display each language translated into its own language (e.g. "English, Español, 日本語, etc.") regardless of the current application locale. In Symfony 5.1 we added a new choice_self_translation option to the LanguageType form field to enable that.