Comment concevoir une application multilingue ? Quelle architecture mettre en place pour internationaliser une application ?

Le contexte applicatif

Avant d’aller plus, loin il est nécessaire de définir les différents contextes applicatifs qui peuvent conditionner le choix d’une solution multilingue.

Les données

Les données à traduire peuvent être séparées en deux groupes :

  • les données statiques : qui correspondent aux messages de l’application[1].
  • les données dynamiques[2] : ce sont des informations, généralement stockées en base de données, qui sont saisies par les utilisateurs.

Les utilisateurs

Une application peut être mono-utilisateur ou multi-utilisateur. Pour une application mono-utilisateur, seules les données statiques ont besoins d’être multilingues. En revanche, dans une application multi-utilisateurs, deux cas sont possibles :

  • les données applicatives sont exclusivement réservées à chaque utilisateur
  • les données applicatives sont partagées entre les utilisateurs

Dans le premier cas, l’internationalisation des données applicatives n’est pas nécessaire. Car chaque utilisateur produit ses propres informations dans sa langue. Par contre, le second cas mérite plus d’attention. Surtout si les utilisateurs n’ont pas tous la même langue.

Internationalisation

Les données statiques

Pour les données statiques, il suffit seulement d’externaliser tous les messages dans des fichiers de ressources[3]. Ensuite, il suffit d’écrire autant de fichier de ressources que de langues supportées par l’application. Ainsi, lorsque l’utilisateur accède à l’application, les messages sont récupérés à partir du fichier correspondant à sa langue.[4].

Les données dynamiques

Les données utilisateurs qui doivent être traduites doivent être stockées en base de données. Et c’est la base de données qui gère les traductions. Pour cela, il faut définir une table listant les langues. Puis pour chaque entité qui peut être traduite, il faut utiliser deux tables :

  • la première contient les champs qui ne sont pas traduits
  • la seconde contient les champs qui peuvent être traduits et est liée à un enregistrement de la première table et une langue

La seconde table contient autant d’enregistrement qu’il y a de langue pour un enregistrement de la première table. De cette façon, les données à retourner par la base de données dépendront de la langue de l’utilisateur.

Les limitations

Gérer des données dynamiques dans plusieurs langues oblige à saisir ces informations dans toutes les langues. De plus, cette étude ne prend pas en compte les contextes collaboratifs multilingues.

Aller plus loin

Les devises, le format des dates et les nombres ne sont pas abordés ici. Cependant, il ne faut pas oublier de les gérer. Une piste intéressante serait de stocker en base de données ces informations dans le format d’une locale par défaut[5]. Ensuite pour chaque utilisateur, il serait nécessaire de reformatter les données que ce soit à la saisie ou à l’affichage.

L’encodage des données n’est pas évoqué non plus. Mais il faut penser à encoder correctement des données dès le départ ! Car la conversion d’un encodage vers un autre est une expérience très chaotique. 😉

De plus, cet article traite seulement des éléments textuels. Or, l’internationalisation ne dépend pas seulement du texte. D’autres éléments peuvent être pris en considération lors de l’internationalisation, comme par exemple les images, les couleurs, la mise en page[6], …

La solution proposée est une bonne base pour rendre vos applications multilingues. Cette étude ne prétend pas résoudre tous les problèmes d’internationalisation. Néanmoins, elle couvre une grande partie des cas rencontrés généralement. Le dernier travail reste de trouver des traducteurs. 😉

Notes

[1] Les libellés de l’interface, les messages d’erreur, mais aussi les libellés des états et autres status figés du modèle de données.

[2] Elles sont appelées également données applicatives dans le texte.

[3] Des fichiers .po pour le C ou le PHP, .properties pour le Java, …

[4] Définie par le navigateur, la locale du compte utilisateur, …

[5] Par exemple en anglais si l’application est codée dans cette langue.

[6] Sans parler non plus du sens de lecture !