Le composant de traduction
Symfony dispose d'un composant de traduction permettant de définir les traductions de vos textes dans plusieurs langues. Ces traductions seront stockées dans des fichiers (yml, xlf ou autre, par exemple messages.fr.yml
).
Les domaines de traductions
Le composant de traduction dispose également d'une notion de domaine de traduction (translation_domain
). Par défaut, toutes les traductions se trouvent dans le domaine messages
, c'est pour cela que le fichier de traduction porte ce nom. Mais il est possible de répartir ses traductions dans plusieurs domaines et donc plusieurs fichiers.
Pour indiquer le fichier à utiliser, un peu partout dans Symfony existent des paramètres ou des options permettant d'indiquer le domaine de traduction.
Les filtres Twig trans
et transchoice
disposent d'un paramètre permettant de préciser le domaine de la traduction :
<h1>{{ 'title'|trans({}, 'myDomain') }}</h1>
Dans les formulaires :
class MyType extends AbtractType
{
public function configureOptions(OptionsResolver $resolver)
{
$resolver->setDefaults(['translation_domain' => 'myDomain']);
}
}
Dans le service translator
:
$this->get('translator')->trans('title', [], 'myDomain)
Toutes les traductions utilisant le domaine myDomain
se trouverons dans les fichiers myDomain.fr.yml
pour la locale fr
et le format yml
.
Diviser pour mieux régner
J'ai donc pris l'habitude de répartir mes traductions dans plusieurs fichiers en fonction de leur utilisation :
messages.fr.yml
pour les traductions des textesforms.fr.yml
pour les traductions des labels de formulairesinterface.fr.yml
pour les traductions des éléments d'interfaces redondants (bouton retour, suivant, annuler, ...)validators.fr.yml
pour les traductions des messages de validationsflashes.fr.yml
pour les traductions des messages flashmenu.fr.yml
pour les menus- ...
Cela me permet d'organiser plus simplement mes traductions, de les retrouver plus rapidement, de maintenir des fichiers plus petits, de séparer et de trier les traductions.
Astuces
Malgré les avantages qu'apporte l'utilisation de plusieurs domaines de traductions, le gros inconvénient est de devoir indiquer quel domaine utiliser à chaque appel au translator
. Voici quelques astuces qui m'ont simplifié la tâche :
Pour les formulaires, créez une extension qui paramètre l'option translation_domain
sur tout les formulaires :
class TranslationDomainExtension extends AbstractTypeExtension
{
public function configureOptions(OptionsResolver $resolver)
{
$resolver->setDefaults(['translation_domain' => 'forms']);
}
public function getExtendedType()
{
return FormType::class;
}
}
Je vous conseil par ailleurs fortement l'utilisation du génial bundle ElaoFormTranslationBundle qui permet de générer automatiquement des clés de traductions pour les labels de vos formulaires.
Si vous utilisez le KpnMenuBundle pour vos menus, lisez cet article sur la documentation de Symfony indiquant comment paramétrer le translation_domain
.
Pour les messages flash, je les inclus dans toute l'application depuis le même template dans lequel j'indique le domaine à utiliser :
{% for type, messages in app.session.flashbag.all %}
{% for message in messages %}
<div class="alert alert-{{ type }}">{{ message|trans({}, 'flashes') }}</div>
{% endfor %}
{% endfor %}
Les commentaires