Internationalisation

Généralité

L'internationalisation (I18N ou I est le premier caractère, N le dernier, et 18 le nombre de caractètres entre le I et le N) consiste à adapter une application à des pays ou cultures cibles. Cela se traduit souvent par la traduction des textes et le respect des conventions d'écriture et de lecture.

En dehors des compétences linguistiques, le système du I18N est surtout technique. Le framework Adventy simplifie son utilisation en proposant 2 solutions complémentaires selon les besoins : le contenu statique et le contenu dynamique.

I18N pour du contenu statique

Créer une page statique est simple, car il suffit au final de créer un fichier *.body.php dans le dossier racine /application/view/page/ et/ou ses sous-dossiers. A partir de ce dossier racine, est créé un sous-dossier par langue. Par exemple :

Chaque dossier langue devient donc un dossier racine dans lequel le contenu (les pages) sont créés. Les URL commencent alors par : /en/, /fr/, /es/, ...

Voici les correspondances entre des exemples d'URL et les ressources associées :

URLRessource
https://mydomain.com/en/folder1/folder2/mypage/application/view/page/en/forlder1/folder2/mypage
https://mydomain.com/fr/dossier1/dossier2/mapage/application/view/page/fr/dossier1/dossier2/mapage
https://mydomain.com/es/carpeta1/carpeta2/mipagina/application/view/page/es/carpeta1/carpeta2/mipagina

Avec le framework Adventy, la structure de l'URL reflète l'organisation des ressources dans le projet, sans avoir besoin de pratiquer la réécriture d'URL.

I18N pour du contenu dynamique

Ce cas arrive lorsque par exemple le contenu provient d'une base de données. Ce contenu dynamique est alors déjà traduit à la langue demandée. Cependant, il reste la partie statique de l'application qui correspond généralement à des libellés de champs, de boutons, etc. Pour la traduction de ces textes courts, au lieu de créer une vue par langue (donc duplication du code dynamique), comme c'est le cas ci-dessus pour les pages statiques, il y aura une vue unique utilisant un fichier de traduction par langue.

Les fichiers de traduction sont de 2 portées :

  1. portée d'application : les traductions définies dans ce type de portée sont visibles quelque soit la page de l'application, soit sur toutes les pages. Il faudra donc définir les traductions communes à toutes les pages, un peu comme un fichier CSS général, ou une bibliothèque Javascript utilisée par toutes les pages.
  2. portée de page : les traductions de page ne sont visibles uniquement que sur la page à laquelle elles sont associées. La portée de page étant prioritaire à celle d'application, les traductions de page écrasent celles d'application.

Les traductions de portée applicative

Ces fichiers de langues, de nom de la forme application.<isoCode2>.i18n.php, sont regroupés dans le dossier racine des langues /application/i18n/. Il ne doit en exister un par langue, avec <isoCode2> représentant un code langue en 2 caractères en minuscule (ex : en, fr, es, etc.).

Le contenu de ce type de fichier contient l'affectation d'une variable d'environnement comme le montre l'exemple ci-dessous avec des clés/valeurs :

<?php 
/**
 * Common translations for application in english.
 */
$_i18n = array(
	//Button labels
	'Validate' => 'Validate',
	'Cancel' => 'Cancel',
	'Edit' => 'Edit',
	'Remove' => 'Remove',
	'Send' => 'Send',

	//Others translations here
	...
);
?>

Cet exemple est une traduction pour du contenu en anglais sous le fichier /application/i18n/application.en.i18n.php.

Le même exemple, mais cette fois-ci en français, donnerait donc le fichier /application/i18n/application.fr.i18n.php avec le contenu suivant :

<?php 
/**
 * Common translations for application in french.
 */
$_i18n = array(
	//Button labels
	'Validate' => 'Valider',
	'Cancel' => 'Annuler',
	'Edit' => 'Editer',
	'Remove' => 'Supprimer',
	'Send' => 'Envoyer',

	//Others translations here
	...
);
?>

Comme les traductions sont stockées dans une variable membre privée, dans la vue, il suffit de les récupérer tout simplement par :

<?= $this->_i18n['<key>']?>

Les traductions de portée de page

Un fichier i18n de portée de page est associé à la ressource ayant le même nom et le même routage.

Par exemple, pour l'URL /manager/user/add-user, nous avons donc les ressources suivantes :

La stratégie du nom de domaine

Il existe plusieurs manière d'organiser les sources pour gérer une application multilingue :

  1. par nom de domaine : cela se traduit par un nom de domaine par pays, ce qui revient à avoir une extension de domaine par pays. Par exemple mydomain.fr (France), mydomain.es (Espagne), mydomain.it (Italie), etc. et enfin mydomain.com pour l'anglais comme langue internationale. Chaque langue est rattachée à un dossier, mais aussi à un nom de domaine.
    L'inconvénient de cette stratégie est l'achat de tous ces noms de domaine, mais surtout le risque que l'un de ces noms de domaine soit déjà pris.
  2. par sous-domaine : à partir d'un nom de domaine avec une extension générique telle que le .com, le nom de domaine est préfixé par le code lanque. Par exemple fr.mydomain.com, es.mydomain.com, it.mydomain.com, en.mydomain.com, etc. Chaque sous-domaine est alors lié à un dossier entier dédié à une seule langue (comme pour le cas du nom de domaine), ou à des sous-dossiers dans plusieurs dossiers génériques. Pour ce dernier cas, cela impliquera la maîtrise de la réécriture d'URL.
  3. par dossier : chaque langue dispose de son propre dossier créé dans le dossier racine de l'application. Pour le framework Adventy, le dossier racine de l'application correspond aux différents dossiers techniques. La particularité de cette technique, sans réécriture d'URL, est que l'URL reflète exactement l'organisation des ressources dans l'application.

D'un point de vue SEO, ces 3 stratégies sont différentes. Pour un petit site, la gestion des langues par dossier est plus appropriée, car les mots clés de toutes les langues réunies aideront à valoriser le métier ou l'activité du nom de domaine. Idéalement, il faudrait un site par langue, et c'est ce que propose le nom de domaine et le sous-domaine. Ces derniers ont chacun leur inconvénient :