Development

Documentation/fr_FR/book/1.0/trunk/13-I18n-and-L10n

You must first sign up to be able to contribute.

Version 10 (modified by forresst, 10 years ago)
Encore un petit correctif

Cette partie de la documentation est en cours de traduction. Cela signifie qu'elle est traduite de manière soit incomplète, soit inexacte. En attendant que cette traduction soit terminée, vous pouvez consulter la version en anglais pour des informations plus fiables.

Chapitre 13 - I18n et L10n

Si vous avez déjà développé une application dont l'interface est en plusieurs langues, vous savez combien les traductions, la localisation des différents contenus peuvent rapidement tourner au cauchemard. Symfony gère tous ces aspects nativement.

Les développeurs font souvent référence au terme internationalisation par le raccourci i18n (vous pouvez comptez le nombre de lettres pour en comprendre la raison). De même ils font référence à la localisation par son raccourci l10n. Internationalisation et localisation couvrent l'ensemble des aspects d'une application traduites en plusieurs langues.

Une application multilangues contient plusieurs versions du même contenu dans différentes langues ou format. Par exemple, un webmail fournit les mêmes fonctionalités dans plusieurs langues ; seul l'interface change.

Une interface localisée affiche des informations différentes suivant le pays de l'internaute. Par exemple, pour un portail d'actualités, quelqu'un habitant aux États-unis vera les dernières nouvelles américaines, alors que quelqu'un habitant en France vera les dernières nouvelles françaises. Une application localisée présente une interface dans la langue de celui qui la regarde mais peut aussi présenter un contenu spécifique.

Pour résumé, une application internationalisée et localisée doit gérer :

  • la traduction des textes (interface, images, et contentu)
  • les différents formats et notations (dates, nombres, monnaie, etc)
  • les contenus localisés (plusieurs versions d'un objet en fonction du pays)

Ce chapitre va nous montrer la façon dont symfony gère tous ces aspects et comment on peut l'utiliser pour créer des applications internationalisées et localisées.

Culture de l'utilisateur

Toutes les fonctionalités internes de symfony sont basées sur une variable de session utilisateur appelé culture. La culture est la combinaison de la langue et du pays de l'utilisateur. Elle détermine la façon dont sont affichées les textes et les informations dépendant de la culture. La culture est une variable de session, elle est donc conservée de pages en pages.

Configurer la culture par défaut

Par défaut, la culture d'un nouveau visiteur est default_culture. Vous pouvez changer cette valeur dans le fichier de configuration i18n.yml, comme montré sur le Listing 13-1.

Listing 13-1 - Positionner la culture par défaut, dans myapp/config/i18n.yml

all: 
  default_culture:     fr_FR

NOTE Pendant la phase de développement, ne soyez pas surpris si un changement de la culture dans le fichier i18n.yml ne change pas la culture dans le navigateur. Cette persistance est dû au fait que la culture est présente dans la session utilisateur. Si vous voulez que votre changement soit effectif, supprimer le cookie de session ou redémarrez votre navigateur.

Garder à l'esprit que la langue et le pays sont nécessaires, vous pouvez avoir des traductions françaises différentes pour des français, des belges ou des québécois et de même vous pouvez avoir des traductions espagnoles différentes pour des espagnols ou des méxicains. Le langage est codé sur deux caractères, en accord avec la norme ISO 639-1 (par exemple fr pour français). Le pays est codé sur deux caractères en majuscules en accord avec la norme ISO 3166-1 (par exemple FR pour des français de France).

Changer la culture d'un utilisateur

Vous pouvez changer la culture d'un utilisateur - par exemple si l'utilisateur décide de passer de la version en anglais à la version en français. -, ou par exemple quand un utilisateur se connecte et que l'on veut utiliser la langue de son navigateur. Pour faciliter ces changements, la classe sfUser fournit des accesseurs à la culture de l'utilisateur. Le listing 13-2 montre comment utiliser ces méthodes dans une action.

[php]
// Culture setter
$this->getUser()->setCulture('en_US');

// Culture getter
$culture = $this->getUser()->getCulture();
 => en_US

SIDEBAR Gestion de la culture dans l'URL

Quand vous utilisez la localisation et l'internationalisation dans symfony, vos pages ont des versions différentes pour une même URL. Cela vous empêche de cacher vos pages et cela empêche un robot d'indéxer vos pages de manière correcte.

La solution est d'ajouter la culture dans toutes vos URL. Ainsi toutes les pages traduites ont des URL différentes. Pour faire cela, il suffit d'ajouter le paramètre :sf_culture dans toutes les règles du fichier routing.yml de votre application.

page: 
  url: /:sf_culture/:page 
  requirements: { sf_culture: (?:fr|en|de) } 
  params: ... 

article: 
  url: /:sf_culture/:year/:month/:day/:slug 
  requirements: { sf_culture: (?:fr|en|de) } 
  params: ...

Nul besoin, d'ajouter le paramètre sf_culture à chaque utilisation de la fonction link_to(), symfony ajoute automatiquement la culture aux paramètres de toutes les règles de routage. Le mécanisme fonctionne dans l'autre sens : symfony change automatiquement la culture de l'utilisateur si le paramètre sf_culture est trouvé dans l'URL.

Determiner la culture automatiquement

Dans de nombreuses applications, la culture est définie à la première requête, en se basant sur les préférences du navigateur. Les utilisateurs peuvent défiir une liste de langues acceptées, dans leur navigateur. Ces informations sont envoyées au serveur à chaque requête, dans l'entête HTTP Accept-Language. Dans symfony, vous pouvez récupérer ces informations à travers l'objet sfRequest. Par exemple, pour récupérer la liste des langues acceptées, dans une action, faîtes ceci :

 [php]
 $languages = $this->getRequest()->getLanguages();

Les entêtes HTTP sont en fait une chaîne de caractères mais symfony analyse automatiquement cette chaîne et la transforme en tableau. Ainsi la langue préférée de l'utilisateur est accessible par $languages[0] dans l'exemple précédent.

Ainsi on peut positionner de manière automatique la culture de l'utilisateur dans l'application en se basant sur la langue préférée de son navigateur. On peut faire cela sur la page d'accueil ou au moyen d'un filtre dans toutes les pages.