Une chaîne de caractères avec un genre codé en dur dans le texte anglais se casse dès qu'elle arrive en français. « You have 1 new message » devient un pluriel grammatical dans presque toutes les langues latines, et un fichier de ressources mal préparé oblige le traducteur à deviner si « 1 » est singulier ou si le système va réellement afficher « 1 messages » à l'utilisateur final. Ce n'est pas un détail de style. C'est un bug de localisation qui arrive en production.
Cet article couvre ce qui sépare un fichier de ressources prêt à être localisé d'un fichier qui va générer des allers-retours, des chaînes tronquées et des pluriels erronés en production.
Séparer le texte de la logique dès le départ
Une erreur fréquente chez les équipes qui localisent pour la première fois consiste à concaténer des chaînes dans le code. `"L'utilisateur " + nom + " a " + nombre + " messages"` fonctionne en anglais et échoue dans toute langue avec un ordre des mots différent ou avec un accord en genre et en nombre. L'allemand déplace le verbe en fin de proposition subordonnée. L'arabe se lit de droite à gauche. Aucune de ces langues ne respecte l'ordre fixe que le code en anglais présuppose.
La bonne pratique consiste à utiliser des chaînes complètes avec des placeholders nommés, non positionnels : `"L'utilisateur {userName} a {messageCount} messages"`. Cela permet au traducteur de réorganiser les éléments selon la grammaire de la langue cible, sans toucher à la logique du code. Des frameworks comme ICU MessageFormat, Fluent (Mozilla) ou les fichiers .resx de .NET supportent déjà ce modèle nativement.
Autre point générateur de reprises : découper des phrases en morceaux qui n'ont de sens qu'une fois réassemblés. « Cliquez » + « ici » + « pour continuer » comme trois chaînes distinctes empêche le traducteur de comprendre le contexte et aboutit souvent à une phrase grammaticalement incorrecte une fois reconstruite. Chaque chaîne doit constituer une unité de sens complète.
Les pluriels : la règle anglaise ne convient à personne d'autre
L'anglais a deux formes de pluriel : singulier et pluriel. Le français en a deux également, mais avec un accord en genre que l'anglais ignore. Le polonais a quatre formes plurielles différentes selon que le nombre se termine par 1, par 2-4, ou par un autre chiffre. L'arabe compte six catégories grammaticales de pluriel. Un fichier de ressources préparé uniquement avec `one` et `other` se casse dès que le projet doit supporter le russe ou l'arabe.
Le standard CLDR (Common Locale Data Repository), maintenu par l'Unicode Consortium, définit les catégories de pluriel (`zero`, `one`, `two`, `few`, `many`, `other`) que chaque langue utilise réellement. La plupart des frameworks modernes d'internationalisation (i18next, Fluent, gettext avec plural forms, ICU MessageFormat) implémentent déjà ces catégories. La préparation correcte du fichier source passe par les points suivants :
- Ne jamais concaténer des nombres à des chaînes fixes (« 1 article », « 2 articles » comme chaînes séparées)
- Utiliser la syntaxe de pluriel du framework choisi, pas des conditions manuelles dans le code
- Toujours inclure la catégorie `other` comme repli, même pour les langues qui ne l'utilisent pas pour tous les nombres
- Tester avec des valeurs qui exposent les catégories les moins évidentes : 0, 1, 2, 5, 11, 21, 100
Un fichier préparé avec ces catégories dès l'origine évite au traducteur de devoir demander des clarifications sur chaque chaîne numérique, et évite à l'équipe d'ingénierie de devoir rouvrir le code après la localisation.
Variables, contexte et longueur du texte
Les placeholders sans contexte constituent la deuxième cause la plus fréquente d'erreurs de localisation, après les pluriels mal préparés. `{0}` ou `{1}` ne disent rien au traducteur sur ce qui va s'y insérer. S'agit-il d'un nom d'utilisateur, d'une date, d'un montant ? Nommer les placeholders de façon descriptive (`{userName}`, `{orderDate}`, `{totalAmount}`) résout la majorité de l'ambiguïté sans coût d'ingénierie supplémentaire.
Les commentaires de contexte directement dans le fichier de ressources font la différence entre une traduction correcte du premier coup et une traduction qui revient en révision. Un commentaire simple du type `// Bouton principal de l'écran de paiement, maximum 20 caractères` donne au traducteur deux informations essentielles : où la chaîne apparaît et quelle limite d'espace respecter.
Ce point compte particulièrement dans les interfaces mobiles, où l'espace est limité et où l'allemand ou le finnois peuvent nécessiter jusqu'à 30 % de caractères en plus que l'anglais pour dire la même chose. Les équipes qui localisent des applications pour des marchés comme le Maroc ou la Côte d'Ivoire rencontrent en plus la variable du support hors ligne et de la qualité du réseau, qui peut exiger des stratégies différentes de chargement des ressources linguistiques. L'article sur la localisation d'applications mobiles pour les marchés africains francophones détaille ces conditions spécifiques.
Format de fichier et flux de travail
Le format technique choisi pour exporter les chaînes influence directement la qualité et la vitesse de la localisation. Les plus courants :
| Format | Usage typique | Remarque |
|---|---|---|
| JSON | Apps web, React, Vue | Facile à automatiser, sans support natif des commentaires |
| .resx | Applications .NET | Supporte les commentaires et métadonnées par chaîne |
| .po / .pot | Projets gettext, WordPress | Standard mature, bonne intégration avec les outils de TAO |
| XLIFF | Échange entre systèmes de traduction | Format d'échange recommandé pour les équipes avec prestataire externe |
| ARB | Flutter | Supporte nativement les pluriels ICU |
Pour les projets avec un prestataire de traduction externe, le XLIFF reste l'option la plus sûre : il préserve le contexte, les commentaires et les placeholders sans exiger que le traducteur édite directement le code source. Cela réduit le risque qu'une clé soit supprimée par erreur, ou qu'un placeholder attendu intact par le moteur de l'application soit modifié.
Les équipes qui travaillent avec des plateformes SaaS et des cycles de déploiement continu ont intérêt à automatiser cette exportation, afin que chaque nouvelle chaîne créée par les développeurs entre dans le flux de localisation sans intervention manuelle. L'article sur la localisation ISO 17100 pour plateformes SaaS explique comment structurer ce flux avec un contrôle qualité traçable.
Comment M21Global traite les fichiers logiciels
M21Global travaille avec les formats de fichiers les plus courants dans les projets de localisation logicielle, dont JSON, .resx, .po et XLIFF, en préservant les placeholders, les catégories de pluriel CLDR et les commentaires de contexte tout au long du processus. Pour les interfaces et la documentation technique associées aux produits logiciels, la solution s'adapte au volume et à la criticité du contenu : des catalogues d'aide traduits par IA jusqu'aux chaînes d'interface qui exigent une révision humaine complète.
Pour les équipes qui préparent leur premier cycle de localisation ou qui migrent d'un flux manuel vers un processus structuré, M21Global aide à définir le format d'export et les conventions de nommage avant le premier envoi de fichiers. Consultez les services de traduction et localisation de logiciels et demandez une évaluation technique de votre projet.
Services Associés
Demandez un devis gratuit de localisation de logiciels
- Demandez un devis gratuit de localisation de logiciels
- Localisation Application Mobile Angola Mozambique
- Localisation Iso 17100 Pour Plateformes Saas
- Une Quantite Surprenante De Contenu Disponible En Ligne Est Generee Par Lintelligence Artificielle
Questions Fréquentes
Qu'est-ce que le CLDR et pourquoi est-il important en localisation logicielle ?
Le CLDR (Common Locale Data Repository) est le standard de l'Unicode Consortium qui définit les catégories de pluriel, les formats de date et de nombre pour chaque langue. Préparer le fichier de ressources avec les catégories CLDR correctes évite des pluriels grammaticalement erronés dans des langues comme le polonais, le russe ou l'arabe.
Quel est le meilleur format de fichier pour envoyer des chaînes à un prestataire de traduction ?
Le XLIFF est généralement l'option la plus sûre pour l'échange avec des prestataires externes, car il préserve le contexte, les commentaires et les placeholders sans exiger une édition directe du code source.
Pourquoi concaténer des chaînes dans le code pose-t-il un problème de localisation ?
Concaténer du texte fixe avec des variables présuppose un ordre des mots qui n'existe pas dans toutes les langues. Utiliser des chaînes complètes avec des placeholders nommés permet au traducteur de réorganiser les éléments selon la grammaire de la langue cible.
Combien de formes de pluriel faut-il supporter dans un projet multilingue ?
Cela dépend des langues cibles : l'anglais en a deux, le français en a deux avec accord en genre, le polonais en a quatre et l'arabe en a six. Le fichier de ressources doit suivre les catégories CLDR de la langue concernée, sans présupposer le modèle anglais.
