Licence CC BY

Quelques considérations techniques

Dernière mise à jour :

C’est bien beau de parler d’internationalisation, de mettre des grands mots et de pointer des pièges ; mais techniquement ça implique quoi ?

Eh bien… ça dépend énormément du type de logiciel et de la technologie utilisée. Néanmoins il existe un certain nombre de constantes que l’on va passer en revue.

Utilisez des outils pour faire le boulot à votre place !

C’est sans doute le conseil le plus important de cette section, alors je vous le remets en bien visible :

Utilisez des outils pour faire le boulot à votre place !

Une grande partie de ce que je vous ai présenté est déjà géré par tout un tas de composants et de bibliothèques, voire parfois directement dans les standards1. Employez ces outils au lieu de réinventer la roue, ça vous évitera de la concevoir carrée.

Mais si vous choisissez une bibliothèque tierce, assurez-vous qu’elle fasse le travail correctement.


  1. Les sélecteurs de date en HTML gèrent beaucoup de spécificités de dates ; les bibliothèques standards des bons langages de programmation gèrent les dates, les fuseaux horaires, les encodages ; etc. Renseignez-vous !

Éléments traduits ou langues porteuses d'éléments ?

S’il y a une décision à prendre le plus tôt possible dans le développement du logiciel, c’est celle-ci :

Est-ce que chaque élément de l’application sera traduit ; ou bien est-ce que chaque langue sera porteuse d’éléments non traduits ?
Autrement dit, est-ce que le résultat sera une application strictement identique dans toutes les langues, ou est-ce que chaque langue aura des contenus spécifiques ?

L’interface de l’application est naturellement traduite dans toutes les langues – ou alors disponible dans une seule langue d’administration. La question se pose pour le contenu qui peut être importé ou contribué :

  • Soit chaque élément (article, etc.) existe dans toutes les langues. La navigation est similaire dans l’application quelle que soit la langue, et chaque « page » de l’application est visible dans toutes les langues.
  • Soit chaque langue a son propre ensemble d’éléments, et donc l’application peut présenter des données et des parcours utilisateurs différents selon la langue.

Ceci implique des choix techniques forts, d’où l’importance d’une décision rapide dans le processus de développement.

Clés de traduction et la langue « développeur »

Tôt ou tard, le développement de l’application nécessitera d’employer des clés de traduction, des chaines de caractère qui permettent de dire : « Ici, tu affiches ce texte dans la langue sélectionnée par l’utilisateur ».

Clés signifiantes, clés techniques et mutualisation

Il faut choisir si les clés de traduction sont plutôt signifiantes (le texte qui sert de clé est lui-même humainement lisible, comme Bouton de connexion), ou plutôt technique (le texte est une représentation purement technique, comme commons.button.login).

L’outil d’internationalisation peut influencer vers l’une ou l’autre des solutions, sans qu’il n’y en ait de meilleure. Une clé de traduction signifiante pose moins de problèmes en cas de traduction manquante, mais rend la détection de tels oublis plus complexes.

L’autre question qui se pose est celle du découpage et du regroupement des clés entre elles. Généralement, la majorité des clés de traductions seront uniques et évidentes à associer (toutes celles qui concernent la page d’accueil, etc.) mais certaines se retrouvent un peu partout et donnent très envie d’être réutilisée.

C’est tout à fait possible si l’on respecte deux conditions :

  1. Les clés réutilisables sont clairement identifiées comme telles, en particulier par l’équipe de traduction.
  2. Toute modification de la valeur de la clé ou de son attribution implique une vérification de cohérence de tous les usages de la clé.

Sans quoi on se retrouve avec des blagues comme cet outil de virtualisation qui indique qu’un serveur est démarré depuis « 0 deuxièmes », parce que la même clé a servi à traduire « second », la seconde comme unité de temps, et « second », la deuxième place…

La langue « développeur »

Les développeurs ne sont ni des linguistes ni des ergonomes. Mais ce ne sont pas non plus des machines et ont besoin d’une version lisible du logiciel pendant l’élaboration, et donc d’avoir une langue par défaut.

Le plus simple est de les laisser rédiger la véritable langue par défaut du logiciel… mais c’est le meilleur moyen d’avoir une version bancale et pleine de fautes.

Une autre solution, c’est d’avoir une langue spécifique aux développeurs, et une version « propre » de cette même langue, destinée au public, dans les fichiers de traduction. Selon l’outil d’internationalisation utilisé, cette langue « pour les développeurs » peut même ne pas être exprimée comme les autres : certains outils permettent de donner une valeur par défaut si une clé de traduction est manquante – c’est fait naturellement si on emploie des clés signifiantes.

Unicode, votre meilleur ami

Nous sommes en 2019, mais on a encore des surprises, alors je préfère le préciser.

Oubliez tous les encodages de caractères locaux, tout votre texte devrait être en Unicode.

Sauf si le système impose autre chose, employez UTF-8, éventuellement UTF-16 si votre application gère surtout des langues asiatiques.

Si vous devez vous interfacer avec d’autres systèmes informatiques qui n’utilisent pas un de ces encodages, assurez-vous que la conversion est faite le plus tôt possible pour ce qui est des entrées, et le plus tard possible en ce qui concerne les sorties. Et quoi qu’on vous dise, n’oubliez pas : le « texte brut » n’existe pas.

Le cas particulier des messages d'erreur techniques

Dans un logiciel, il y a deux choses qui ne doivent en aucun cas être internationalisées :

  1. Les noms des langues dans le sélecteur de langue, comme déjà mentionnés plus tôt ;
  2. Les messages d’erreur à destination des développeurs.

On peut avoir l’impression d’aider le développeur en lui donnant un message d’erreur dans sa propre langue. C’est une bévue : dans l’immense majorité des cas, la première étape effectuée face à un message d’erreur dont la solution n’est pas triviale, c’est de le chercher sur Internet, pour vérifier s’il n’y a pas de la documentation à ce sujet, ou quelqu’un d’autre qui a une réponse.

Si le message est traduit, il y a un fort risque que la documentation ou l’aide ne soit pas disponible dans toutes les langues, et donc la personne qui développe va perdre du temps au lieu d’en gagner. Et si jamais ce type de message doit absolument être traduit – parce qu’il peut être affiché à l’utilisateur final, par exemple – alors, assurez-vous de fournir aussi un code d’erreur non traduit.

Rendre un site internet accessible partout dans le monde

Si votre logiciel est un site internet que vous hébergez, il est naturellement disponible partout dans le monde.

Du moins, ça, c’est la théorie.

En pratique, il sera rapide dans les zones géographiquement proches d’où sont les serveurs sur lesquels il est déployé… et lent ailleurs, la faute aux lois de la physique. Or, la vitesse de chargement des pages n’est pas qu’un critère de confort pour l’utilisateur : un site trop mou peut décourager les visiteurs, ce qui peut être un gros problème – une perte de chiffre d’affaires pour un site de vente. Il faut donc choisir avec soin l’emplacement géographique de ses serveurs, y compris en cas d’hébergement dans les nuages.

De plus, si le service doit être accessible avec efficacité depuis plusieurs zones géographiques distinctes, des stratégies existent pour améliorer les temps d’accès : instances multiples CDN


En résumé, les principales considérations techniques pour l’internationalisation sont :

  1. D’utiliser des outils pour le faire – à commencer par Unicode.
  2. De décider au plus tôt qui va porter les traductions dans l’application, et quel sera le format des clés de traduction.
  3. Dans le cas d’un site ou d’une application connectée à Internet, de concevoir une infrastructure capable de délivrer une qualité de service correcte partout dans le monde.

N’oubliez pas que les messages d’erreurs ne devraient être traduits que s’ils contiennent un code d’erreur identique pour toutes les langues.

Il y aurait bien plus à en dire, mais hélas beaucoup sont spécifiques au langage de programmation voire aux logiciels utilisés…