Editions ENI Livres | Vidéos | e-Formations
Internationalisation des applications Symfony
Introduction
1. Culture, internationalisation et régionalisation
Tout site web contient beaucoup de données textuelles qui sont destinées à être lues par l’utilisateur. Si l’on retirait tout le code informatique de votre projet, il resterait tout de même une partie non négligeable de messages, textes et contenus en français, éparpillés entre vos templates, contrôleurs et bases de données, par exemple.
Si vous souhaitez transformer votre site web exclusivement en français en un site web multilingue, les couches de l’application à modifier sont donc nombreuses. La tâche peut rapidement devenir ardue, voire rendre votre projet illisible, si vous ne choisissez pas les bons outils.
Heureusement, Symfony dispose d’un composant chargé de gérer les traductions d’un site avec souplesse et simplicité. Avant de le découvrir, il convient tout de même de définir certains termes.
a. La culture (Locale)
La culture (en anglais Locale) est un identifiant qui représente principalement la langue de l’utilisateur, mais potentiellement d’autres paramètres linguistiques, comme le pays.
La valeur de l’identifiant de culture est libre. Cependant, Symfony recommande l’utilisation du code langue ISO639-1, puis optionnellement, d’un underscore et d’un code pays...
Détecter la culture d’un utilisateur
1. Les techniques
a. Négociation de contenu
Le protocole HTTP supporte un mécanisme appelé la négociation de contenu. Il permet de retourner différentes représentations (on parle de variantes) d’une ressource en fonction d’un certain nombre de critères, dont la culture de l’utilisateur. Ces critères sont envoyés dans des en-têtes HTTP au moment de la requête du client.
Cette technique peut cependant nuire au référencement de votre site ; elle est d’ailleurs déconseillée par Google, qui préconise plutôt une URL distincte pour chaque langue d’une page donnée.
b. Par l’URL
La seconde technique consiste à utiliser une URL par langue.
La culture de l’utilisateur peut être placée de différentes manières dans une URL ; voici quelques exemples d’URL pour une page d’un site web en italien :
-
http://mon-projet.it/ma-page : utilisation d’un domaine national de premier niveau (ou ccTLD). Contrairement au domaine de premier niveau générique (comme .com, .org, .net, etc.), le ccTLD est associé à un pays. Cette structure d’URL est néanmoins assez contraignante ; elle vous force à acquérir un nouveau nom de domaine pour chaque...
Activation des traductions
1. Le composant translator
Pour mettre en place le système de traduction de Symfony, il est d’abord nécessaire d’installer le composant translator. Si vous avez créé votre application en utilisant le modèle d’application (symfony/skeleton) alors il est déjà installé ; dans le cas contraire, il faut exécuter la recette Flex appropriée en utilisant la commande :
composer require symfony/translation 2. Configuration du framework
Le système de traduction apporté par le composant translator fournit le fichier de configuration config/packages/translation.yaml ; son contenu par défaut est le suivant :
# config/packages/translation.yaml
framework:
default_locale: en
translator:
default_path: '%kernel.project_dir%/translations'
fallbacks:
en On y trouve la locale par défaut (default_locale) ainsi que le répertoire par défaut des traductions (default_path). Ce répertoire est le répertoire translations situé à la racine de votre projet.
Une première adaptation importante de ce fichier consiste évidemment à ajuster la locale...
Les routes et les traductions
Nous avons précédemment expliqué que pour créer un site web multilingue, il fallait renseigner la culture de l’utilisateur dans l’URL. Symfony rend cela possible grâce au paramètre spécial de routage _locale :
home:
path: /{_locale}/home
controller: App\DefaultController::home
requirements:
_locale: en|fr Ici, nous définissons une route multilingue pour l’action home d’un de nos contrôleurs. Cette action sera accessible par deux URL :
-
http://mon-projet.local/en/home
-
http://mon-projet.local/fr/home
En accédant à l’une ou l’autre de ces routes, Symfony place la culture de l’utilisateur sur en ou fr, pour respectivement anglais et français.
Les fichiers de traductions
1. Organisation et règles de nommage
Les fichiers de traductions doivent être enregistrés dans le répertoire translations/ du projet et doivent suivre des règles de nommage strictes.
Règle de nommage
Les noms des fichiers de traductions suivent une certaine syntaxe : domaine.locale.format.
locale
La locale correspond à la culture des traductions contenues dans le fichier. Chaque fichier ne peut contenir qu’une seule culture. En clair, vous ne pouvez pas définir des traductions anglaises et françaises dans un même fichier.
format
Les fichiers de traductions de Symfony peuvent utiliser différents formats. Pour les traductions des routes, nous avons utilisé YAML car c’est le plus simple à configurer, mais il existe aussi XLIFF et PHP.
Le XLIFF est une extension du langage XML spécifique à la régionalisation ; ce format est plus standard que le YAML mais beaucoup plus verbeux. Une fois que vous serez familiarisé avec les traductions, nous vous recommandons de troquer le YAML pour le XLIFF.
domaine
Le domaine est une manière d’organiser ses traductions ; il est en quelque sorte l’équivalent de l’espace de noms pour les classes PHP : il permet principalement d’éviter les conflits.
Le domaine par défaut est messages ; nous verrons plus loin comment...
Traduction d’un message
1. Le service translator
Le service translator sert à traduire des messages. Voici comment il doit être utilisé depuis une action :
...
use Symfony\Contracts\Translation\TranslatorInterface;
...
public function bonjour(TranslatorInterface $translator)
{
$message = $translator->trans('Bonjour');
return new Response($message.'!');
} Pour traduire le message en anglais par exemple, il faut créer le fichier de traductions suivant :
# translations/messages.en.yaml
Bonjour: Hello Si vous ouvrez cette page avec la culture en dans l’URL, vous verrez « Hello! » s’afficher à l’écran.
Si ce n’est pas le cas, essayez de vider votre cache.
Le fichier utilise le domaine messages (et donc le fichier messages.en.yaml) car c’est le domaine par défaut. Voici comment en utiliser un autre au moment de la traduction :
$translator->trans('Bonjour', array(), 'le_domaine'); Ici, c’est le domaine le_domaine qui sera pris en compte. Nous allons maintenant nous pencher sur le rôle du tableau vide passé en deuxième paramètre.
2. Les paramètres de substitution (placeholders)
Les paramètres de substitution permettent de créer des messages dynamiques....
