New in Symfony 5.1: Translation improvements
March 26, 2020 • Published by Javier Eguiluz
Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.
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.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
Great improvments 👍