Quelques considérations techniques

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

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 standards¹. 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.

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

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.

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.

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

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.

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.

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…