L’internationalisation

La variable locale

La variable d’environnement locale par défaut est définie dans le fichier de configuration config/packages/translation.yaml :

framework: 
    default_locale: en 
    translator: 
        default_path: '%kernel.project_dir%/translations' 
        fallbacks: 
            - en  

Ici, par défaut, la locale est « en ». C’est l’anglais qui sera utilisé. Les différents codes des langues sont définis par la norme ISO 639. Vous trouverez leurs valeurs sur le site de Wikipedia : https://fr.wikipedia.org/wiki/Liste_des_codes_ISO_639-1

Cette variable locale peut être dynamiquement modifiée dans les routes.

Imaginons que vous souhaitiez utiliser des routes différentes pour chaque langue, vous pouvez définir la locale utilisée pour la page en la mettant en paramètre dans la route.

Syntaxe :

 #[Route("/langue/{_locale}/"... 

Le paramètre _locale détermine la variable locale utilisée dans la route. La valeur sera automatiquement affectée à la variable locale de votre application.

Prenons un exemple. Dans le contrôleur TestController que nous avons créé...

Les catalogues de traduction

Les catalogues de traduction sont définis dans le dossier /translations. Si vous installez un package particulier (sous forme de bundle), vous pourrez définir les catalogues de traduction dans le dossier Ressources/translations à l’intérieur du bundle que vous avez créé (tout ça dans le dossier vendor, bien sûr).

Chaque catalogue de traduction a un nom particulier. Tous les noms de catalogues suivent la syntaxe suivante : domain.locale.loader.

La signification de cette syntaxe est la suivante.

Nous allons par exemple, créer un catalogue français pour la locale fr. Créez, dans /translations, le fichier messages.fr.yaml (nous utilisons le domaine standard : messages).

À l’intérieur, nous allons par exemple définir une traduction pour le texte : « Welcome...

Les éléments à traduire

Comment dire à Symfony : « traduis moi ceci » ?

Il est possible, par exemple, d’effectuer des traductions dans un contrôleur : il suffit d’injecter le service $translator de l’interface TranslatorInterface dans la méthode désirée.

Syntaxe :

use Symfony\Contracts\Translation\TranslatorInterface; 
public function methode(TranslatorInterface $translator) 
{ 
    ...$translator->trans('texte à traduire'); 
} 

Prenons un exemple. Dans notre méthode langue() dans le contrôleur TestController, insérez ce code :

use Symfony\Contracts\Translation\TranslatorInterface; 
... 
#[Route("/langue/{_locale}", name:"langue", requirements : 
["_locale"=> "en|fr|de"])] 
    public function langue(Request $request, 
TranslatorInterface $translator) 
    { 
        $texteTraduit = $translator->trans('Welcome to Symfony'); 
        return new Response( $texteTraduit); 
    }   

Si vous essayez d’exécuter cette requête : localhost:8000/langue/fr, vous tomberez bien sur le texte traduit :...

Welcome to Symfony: Bienvenue sur Symfony 
say_hello: Bonjour %name%: 

<h1>{% trans %}Welcome to Symfony{% endtrans %}</h1> 
<h2>{{ 'say_hello'|trans({'%name%': 'Yves'}) }}</h2>  

 php bin/console translation:extract --dump-messages fr 

 php bin/console translation:extract --force fr 

L’organisation des catalogues

Afin de mieux nous y retrouver dans nos catalogues, qui risquent d’être très gros, il est possible de les structurer.

Une des pratiques est d’utiliser des mots-clés plutôt que du texte pour les chaînes source à traduire.

Par exemple, au lieu de traduire :

Welcome to Symfony: Bienvenue sur Symfony 

nous allons utiliser une abréviation du type :

test.titre: Bienvenue sur Symfony 

test est le nom de la page sur laquelle doit se faire la traduction et titre l’intitulé de la traduction.

Par exemple, dans le template test/index.html.twig, nous utiliserons ce texte :

<h1>{% trans %}test.titre{% endtrans %}</h1> 

Ceci peut simplifier grandement vos templates et vos catalogues, surtout si le texte à traduire est conséquent, comme tout un paragraphe par exemple.

Une extension de cette possibilité est de construire des sous-niveaux dans le catalogue.

Il sera plus clair et plus facile de gérer des catalogues organisés en fonction des pages par exemple.

Vous pouvez construire votre catalogue messages.fr.yaml de cette manière :

test : 
    titre: 
        bienvenue:  Bienvenue sur Symfony 
    auteur: 
        bonjour:    Bonjour...

La gestion du pluriel

Il se peut qu’on ait besoin de plus de souplesse dans les traductions, notamment pour la gestion des pluriels.

Imaginons, par exemple, que nous souhaitions renseigner le nombre de produits disponibles lors de la commande passée.

Le message différera selon le nombre de produits disponibles :

Bien entendu, il est possible dans le template, avec l’instruction {% if ...%} de tester le nombre de produit disponibles et d’afficher le message correspondant. 

Mais si ce message doit être affiché à plusieurs endroits, cela nous oblige à dupliquer du code uniquement pour la traduction.

Symfony propose une gestion du pluriel automatiquement dans le catalogue.

Mais pour profiter de ce type de traduction, Symfony utilise un format particulier : le format ICU.

Ce format est disponible en PHP. Vous trouverez plus d’informations sur ce type de format sur la page http://userguide.icu-project.org/formatparse/messages. 

Afin de bénéficier de ce format, il vous faudra renommer le fichier catalogue en ajoutant +intl+icu.

Voici des exemples de conversions de noms de fichiers catalogues de base en nom de fichier au format ICU :

Par exemple, nous allons renommer notre fichier translations/messages.fr.yaml en messages+intl-icu.fr.yaml

Du coup, nous pouvons...

La traduction des messages des contraintes de validation

Traduire les messages dans les contrôleurs et dans les vues c’est bien, mais vous avez d’autres messages qui peuvent apparaître sur votre application et qu’il serait bon de traduire aussi. C’est le cas des messages d’erreurs dans les validations de formulaires par exemple (voir chapitre Les formulaires, section Validation des formulaires).

Pour traduire ces messages, vous allez utiliser le domaine validation au lieu du domaine messages dans votre catalogue.

Créez un fichier translations/validators.fr.yml et insérez à l’intérieur les traductions de vos messages d’erreurs de validation.

Nous allons prendre l’exemple du message d’erreur de validation sur la taille minimum ou maximum du nom des produits.

Modifions le message sur les annotations de $nom dans l’entité Produit :

#[ORM\Column(length: 200)] 
    #[Assert\Length( 
        min: 2, 
        max: 50, 
        minMessage: 'produit.nom.min', 
        maxMessage: 'produit.nom.max', 
        groups: ["all"] 
    )] 

En fonction de la locale nous créerons...

say_thanks: Merci {name} 

<h2>{{ 'say_thanks'|trans({'name': 'Yves'}, 'test') }}</h2>