New in Symfony 2.6: Improvements for the Translation component

The top languages used on Internet are English (800 million users), Chinese (650 million), Spanish (220 million) and Arabic (135 million). As companies become more global, odds are that you have to develop multilingual websites and applications. The good news is that Symfony 2.6 will include some improvements for the Translation component.

Added the target language when dumping XLIFF files

Contributed by
Clément Gautier
in #11373.

When executing the translation:update command to generate the XLIFF file, previous Symfony versions didn't set the correct target-language value:

1
$ console translation:update --force --output-format=xlf fr AcmeBundle

The result of executing that command was a XLIFF file without the target-language attribute:

<file source-language="fr" ... >

Symfony 2.6 will correctly set both the source-language and the target-language attributes:

<file source-language="en_US" target-language="fr_FR" ... >

In addition, these attributes will now use the full locale values (e.g. fr_FR instead of fr and en_US instead of en).

Added method to expose collected messages

Contributed by
Hryhorii Hrebiniuk
in #9859.

In case you want to use the same translation catalogue outside your application (e.g. use translation on a client side), Symfony 2.6 allows you to fetch the raw translation messages for the given locale.

1
$messages = $translator->getMessages('fr_FR');

The structure of the $messages variable will be the following array:

1
2
3
4
5
6
7
8
9
array(
    'messages' => array(
        'Hello world' => 'Bonjour tout le monde',
    ),
    'validators' => array(
        'Value should not be empty' => 'Valeur ne doit pas être vide',
        'Value is too long' => 'Valeur est trop long',
    ),
);

Moved translation caching to the Translation component

Contributed by
Tristan Maindron
in #11373.

Generally speaking, caching in Symfony is done within the components. However, the Translation component used the FrameworkBundle to cache its catalogues. This made cached translations hard to use outside Symfony, for instance in Silex projects.

In Symfony 2.6, the signature of the Translator constructor has changed to accept a third optional parameter that sets the directory where message catalogues are cached:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
use Symfony\Component\Translation\Translator;
use Symfony\Component\Translation\MessageSelector;

// Symfony 2.5
$translator = new Translator('fr_FR', new MessageSelector());

// Symfony 2.6 without caching enabled
$translator = new Translator('fr_FR', new MessageSelector());

// Symfony 2.6 with caching enabled
$translator = new Translator('fr_FR', new MessageSelector(), __DIR__.'/../cache');

Missing translations logging

Contributed by
Ait Boudad Abdellatif
in #10887.

One of the most important tasks of internationalizing applications is to detect all the missing translations for any given locale. In Symfony 2.6 this task will be much easier thanks to the new logging option (its default value is %kernel.debug%):

1
2
3
4
5
# app/config/config.yml
translator:
    enabled:    true
    fallback:   en
    logging:    true

When set to true, whenever Symfony doesn't find a translation for the given locale, the missing translation is added to the log file of the current environment.

Translation extraction for the global resources directory

Contributed by
Rafael Dohms
in #11254.

The translation:update command comes in very handy to extract translation strings from the templates of a given bundle. It Symfony 2.6 this command will also allow to extract strings from the global templates located in the app/Resources/views/ directory. To do so, execute the command without providing a bundle name:

1
2
# this only works in Symfony 2.6
$ console translation:update fr

Comments

It seems another addition was overlooked.

The translation update command can now be run without a bundle parameters to gather up the translations used in the Resources directory.
Missing translations logging is a really good thing (the other things too).

As the LoggingTranslator is declared as a service, it means an other service class can be used and allows really great extension possibilities.

Thanks!
@Rafael, you are right. I'm sorry for having missed your contribution. The original blog post has been updated and now it shows your contribution.
So why the translator (service 'translator') refers now to LoggingTranslator ?

I got it from php app/console container:debug :

translator:
Symfony\Component\Translation\LoggingTranslator

translator.default:
Symfony\Bundle\FrameworkBundle\Translation\Translator

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.