Applications multilingues : concevoir dès le départ
Ajouter une langue à une application conçue pour une seule est un chantier de reprise. Quelques choix faits au démarrage rendent l'ajout d'une langue presque indolore.
L’erreur la plus coûteuse en matière de multilinguisme se fait au tout début : on conçoit l’application dans une seule langue, en se disant qu’on « ajoutera les autres plus tard ». Plus tard, c’est quand le client demande l’arabe, et que l’interface entière se disloque parce que le texte va dans l’autre sens. Ou quand le partenaire allemand signale que les montants sont illisibles parce que la virgule et le point sont inversés. Ou quand la traduction française, plus longue que l’anglais d’origine, déborde de chaque bouton. L’internationalisation des applications n’est pas une traduction ; c’est une architecture.
Ce que couvre l’internationalisation
L’internationalisation (abrégée i18n) prépare le code à recevoir plusieurs langues sans qu’on ait besoin de le modifier. La localisation (l10n) adapte ensuite le contenu à chaque langue et région. La première est un travail d’ingénierie, fait une fois ; la seconde est un travail de contenu, fait pour chaque langue ajoutée.
| Sujet | Ce que l’i18n prépare | Ce que la l10n adapte |
|---|---|---|
| Textes de l’interface | Externalisation dans des fichiers de ressources, séparation du code et du contenu | Traduction de chaque chaîne, adaptation du ton et des conventions |
| Formats régionaux | Utilisation de bibliothèques de formatage (ICU, Intl), paramétrage par locale | Dates (JJ/MM/AAAA ou MM/DD/YYYY), nombres (virgule ou point), devises, unités |
| Encodage | UTF-8 partout : code, base de données, échanges, fichiers | Caractères spécifiques : diacritiques, idéogrammes, abjads |
| Sens d’écriture | CSS logique (inline-start/end), attribut dir, contenus bidirectionnels | Mise en page miroir pour l’arabe, l’hébreu, le persan, l’ourdou |
| Espace dans l’interface | Mise en page flexible, pas de largeurs fixes sur les textes | Expansion du texte (le français est 15 à 30 % plus long que l’anglais, l’allemand davantage) |
| Images et icônes | Séparation du texte et de l’image, pas de texte incrusté | Remplacement des images culturellement marquées, inversion des icônes directionnelles en RTL |
Cinq choix techniques à faire au démarrage
UTF-8 partout
Le code source, la base de données, les fichiers d’échange, les en-têtes HTTP, les formulaires : tout en UTF-8. C’est le seul encodage qui couvre toutes les écritures sans conversion. Un champ de base de données en latin-1 tronque un nom arabe ou un idéogramme chinois sans prévenir.
Externaliser les chaînes de texte
Aucun texte visible par l’utilisateur ne doit être écrit en dur dans le code. Chaque texte est une clé qui renvoie à un fichier de traduction (JSON, XLIFF, PO, selon l’écosystème). Les bibliothèques standard existent dans tous les langages : gettext, react-intl, vue-i18n, angular/localize, NSLocalizedString.
Ne pas concaténer les phrases
« Vous avez » + nombre + « message(s) » ne se traduit pas. Les langues ont des règles de pluriel différentes (l’arabe a six formes), et l’ordre des mots change d’une langue à l’autre. Utiliser les fonctions de pluralisation et de formatage de la bibliothèque i18n, qui prennent un patron et des variables.
Utiliser les propriétés CSS logiques
margin-inline-start au lieu de margin-left, padding-inline-end au lieu de padding-right. En mode RTL, les propriétés logiques s’inversent automatiquement. Les propriétés physiques ne bougent pas, et l’interface est cassée.
Prévoir l’expansion du texte
Un bouton « Save » devient « Enregistrer » en français et « Speichern » en allemand. Si la largeur est fixe, le texte déborde ou est tronqué. Concevoir avec des largeurs flexibles et tester avec une pseudo-langue qui allonge chaque chaîne de 30 à 40 %.
L’internationalisation n’est pas un coût supplémentaire au démarrage ; c’est une économie sur chaque langue ajoutée ensuite.
Tester avant de traduire
La pseudo-localisation est une technique simple et révélatrice. On remplace chaque texte de l’interface par une version allongée et truffée de caractères accentués (« Ṡàṿê » au lieu de « Save »), et on vérifie que l’interface reste lisible, que rien ne déborde, que les caractères s’affichent correctement. On ajoute des crochets autour de chaque chaîne ([Ṡàṿê]) pour repérer les textes encore écrits en dur dans le code.
Ce test ne coûte rien, ne nécessite aucun traducteur, et révèle la majorité des problèmes d’internationalisation en quelques heures. Il devrait être exécuté dans l’intégration continue, à chaque livraison.
Ce que le guide ne couvre pas
La traduction elle-même — choix du prestataire, gestion de la mémoire de traduction, validation terminologique, adaptation culturelle — est un métier distinct. L’internationalisation prépare le terrain pour que ce métier s’exerce sans reprendre le code.
Notre expertise en équipes déployées accompagne les organisations qui construisent des applications pour plusieurs pays. Pour le cadre plus large de la gouvernance de ces projets, voir notre offre Gouvernance.
Pour approfondir : Gouvernance & traçabilité