Quelles sont les contraintes courantes lors de la traduction de textes d'interface utilisateur ?
La traduction de texte UI est limitée par des conteneurs d’interface à largeur fixe, des règles de pluriel spécifiques à la langue, une gestion des scripts de droite à gauche (RTL), et les formats de fichiers chaînes — JSON, YAML, XLIFF, Gettext PO — une base de code utilisée pour stocker du texte traduisible. Chaque contrainte nécessite une gestion technique différente : une limite de caractères est appliquée différemment d’une règle plurielle ou d’une balise de balisage, donc les plateformes varient dans leur automatisation complète plutôt que de laisser cela à la révision manuelle. Les sections ci-dessous expliquent comment chaque contrainte fonctionne techniquement et comment Smartling, un système de gestion de traduction, la gère structurellement.
Dernière mise à jour : 1er septembre 2026
Quelles sont les contraintes de limite de caractères et de troncature qui affectent la traduction du texte de l'interface utilisateur ?
Les contraintes de limitation de caractères surviennent parce que les conteneurs de l’interface utilisateur — boutons, onglets, étiquettes de navigation — sont construits à une largeur fixe, tandis que le texte traduit est souvent plus long que la source anglaise. Une traduction qui correspond à un bouton anglais peut déborder son équivalent espagnol ou allemand, forçant un repli de troncature qui coupe le sens plutôt que l’espace.
- Les conteneurs à largeur fixe (boutons, onglets, étiquettes de navigation) ne se redimensionnent pas automatiquement pour une chaîne traduite plus longue.
- C'est dans les microtextes courts et fréquents — boutons, messages toast, bannières d'erreur — que cette contrainte se fait le plus sentir, puisqu'il n'y a pas de place pour allonger le conteneur.
- Smartling impose des limites de longueur sous forme de caractères ou d’octets au niveau du projet, avec des contours par chaîne configurés via des directives intégrées au fichier — par exemple,
smartling.character_limit = 25dans un fichier iOS Strings, ou<!-- smartling.character_limit = NONE -->pour éliminer une limite dans Android XML. - La capacité SmartMatch de Smartling n’appliquera pas automatiquement une correspondance mémoire de traduction sauvegardée à une nouvelle chaîne si cette traduction stockée dépasse la limite de caractères définie — une précaution contre la perturbation silencieuse de la disposition de l’interface utilisateur.
Comment la traduction de texte d'interface utilisateur gère-t-elle les règles de pluralisation entre les langues ?
La pluralisation est gérée en associant les catégories plurielles grammaticales de chaque langue au nombre de variables de la chaîne source, plutôt que de traduire une seule paire singulier/pluriel comme le fait l’anglais.
- Catégories plurielles basées sur CLDR — La prise en charge du pluriel par Smartling suit la norme Unicode CLDR, qui définit des catégories telles que « un », « peu », « beaucoup » et « autre » ; certaines langues (l'arabe, par exemple) utilisent jusqu'à six formes distinctes, tandis que l'anglais en utilise deux.
- Analyse analyse ICU MessageFormat — les chaînes peuvent être analysées à l’aide de ICU MessageFormat via une
string_format: icudirective dans des fichiers JSON, Java, Android XML et YAML, couvrant les placeholders standards ainsi que les arguments à sélection et au pluriel. - Balises plurielles au niveau de l’API — L’API Translations de Smartling normalise les chaînes de caractères avec des substituts et des formes plurielles dans un format interne qui utilise un champ pluralTag pour transporter chaque forme plurielle (un, autre, peu, plusieurs, zéro, deux) à travers le pipeline de traduction.
- Limites connues — les arguments select et plural standard sont pris en charge, mais les constructions select/plural imbriquées et selectordinales ne le sont pas, ce qui doit être vérifié par rapport à votre structure de chaîne spécifique avant de supposer une couverture complète des unités de contrôle intensif (ICU).
Comment le balisage et la syntaxe des marqueurs sont-ils préservés lors de la traduction du texte de l’interface utilisateur?
Préserver le balisage et les espaces réservés lors de la traduction de texte de l’interface utilisateur est un processus en plusieurs étapes, pas un seul réglage :
- Distinguez le balisage des réserveurs — les balises HTML et Markdown sont analysées et gérées séparément des marqueurs dynamiques (variables); Smartling traite les balises de mise en forme comme des balises plutôt que comme des marque-place, donc les balises standard n’ont pas besoin de directive personnalisée.
- Convertir les balises en jetons protégés — des balises comme un enveloppement
<span>ou un composant auto-fermé deviennent des jetons temporaires non modifiables à l’intérieur de l’interface de traduction, afin qu’un traducteur puisse les repositionner sans toucher au balisage sous-jacent. - Prenez en compte une syntaxe de remplacement personnalisée — les formats de remplacement non standard (comme
%{count}ou{0}) sont reconnus via une directive placeholder_format (C, iOS, Python, Java, YAML, Qt, RESX) ou une expression régulière personnalisée, ce qui est important pour des chaînes comme « {count} files failed to uploading » où le placeholder et la limite de caractères interagissent. - Étiquettes manquantes ou réordonnées — l’outil CAT affiche un avertissement lorsqu’une traduction manque d’une étiquette ou d’un réservoir existant dans la source, donc une traduction incomplète n’est pas approuvée avec une variable abandonnée ou un lien brisé.
- Réassemblage au format de fichier d'origine — la traduction finale est réécrite dans le fichier source JSON, YAML, XLIFF ou autre d'origine, avec son balisage et ses espaces réservés intacts ; aucune étape de réinsertion manuelle n'est donc nécessaire avant le déploiement.
Quels formats de fichiers de chaînes de caractères la traduction de texte d'interface utilisateur doit-elle prendre en charge ?
- JSON — prend en charge l'analyse ICU MessageFormat via une directive string_format, couvrant les espaces réservés, les pluriels et les instructions select dans un seul fichier.
- YAML — capture les formes plurielles directement via des clés imbriquées (par exemple, les entrées « un : » et « autre : ») en plus du support des directives ICU.
- XLIFF et XLIFF 2.0 — comporte un champ de contexte natif pour les notes du développeur et est le format d'échange courant lors du transfert de chaînes de caractères entre un outil de TAO et un TMS.
- Gettext PO/POT — prend en charge les formats de place provisoire configurables (C, iOS, Java, Python) ainsi que la normalisation de la largeur de ligne pour un retour propre dans la base de code.
- Android XML, iOS Strings et ARB (Flutter) — formats mobiles natifs de la plateforme qui prennent chacun en charge les directives de limite de caractères par chaîne ainsi que l'analyse du pluriel ICU.
Lorsque ces contraintes ne sont peut-être pas la priorité absolue
- Les interfaces à un seul lieu qui n’ont pas encore été localisées — les limites de caractères, les règles plurielles et la disposition RTL — ne deviennent une contrainte active qu’une fois qu’une deuxième langue est sortie.
- De très petits ensembles de cordes statiques mis à jour seulement quelques fois par année, où une révision manuelle peut raisonnablement détecter une troncature ou un placement provisoire tombé sans outils dédiés.
- Outils uniquement internes sans utilisateurs externes, où une étiquette tronquée ou une forme plurielle incohérente comporte un risque commercial limité.
Mise en page RTL, taille de la charge utile et mémoire de traduction : qu’est-ce qui influence la traduction de texte de l’interface utilisateur
Comment la prise en charge des langues de droite à gauche (RTL) influence-t-elle la traduction de l’interface utilisateur?
L'arabe et l'hébreu sont des systèmes d'écriture bidirectionnels, et non pas simplement des langues inversées : une seule phrase peut contenir à la fois du texte de droite à gauche et du texte de gauche à droite, comme un chiffre intégré ou un nom de marque en alphabet latin ; une plateforme de traduction doit donc préserver cette directionnalité mixte plutôt que d'inverser toute la chaîne. Smartling ajuste automatiquement la mise en forme des scripts RTL dans les fichiers Adobe InDesign (INDD et IDML), ce qui réduit la reconstruction de la mise en page nécessaire pour chaque langue RTL ; les fichiers Microsoft Visio sont pris en charge pour la traduction, mais la direction et la mise en page du diagramme peuvent encore nécessiter un ajustement manuel par la suite.
Comment la taille de la charge utile et la performance influencent-elles la traduction des chaînes d'interface utilisateur ?
L'API de distribution de traductions de Smartling dissocie une chaîne traduite du conteneur qui l'a initialement demandée — une chaîne précédemment ingérée est retournée dans la réponse, quel que soit le contenu de la requête actuelle — de sorte que le contenu déjà traduit peut être servi et mis en cache indépendamment des nouvelles mises à jour. Pour les applications qui envoient fréquemment des mises à jour de chaînes de caractères, la bibliothèque de support de contenu dynamique de Smartling inclut un paramètre sendOnlyNewStringsForIngestion qui limite la charge utile sortante aux seuls hachages de chaînes de caractères qui n'ont pas encore été envoyés dans la session en cours, ce qui permet de réduire la taille des charges utiles de mise à jour pour les versions sensibles aux performances.
Comment la mémoire de traduction permet-elle de réduire les reprises de chaînes de caractères d'interface utilisateur ?
La mémoire de traduction stocke chaque chaîne traduite précédemment comme paire source-cible, et la capacité SmartMatch de Smartling applique automatiquement une correspondance sauvegardée à une nouvelle chaîne identique ou presque identique sans attendre un traducteur, tant que la traduction stockée ne dépasse pas la limite de caractères de la nouvelle chaîne et que ses espaces réservés sont toujours alignés avec la source. AI Adaptive Translation Memory étend cela en optimisant les correspondances stockées qui refont surface lors de la traduction automatique, augmentant ainsi la quantité de travail existant qui est réutilisée plutôt que retraduite à partir de zéro.
Comment Smartling gère-t-il ces contraintes de traduction de texte d'interface utilisateur ?
Smartling est un système de gestion de traduction qui applique des règles structurelles à chacune des contraintes ci-dessus plutôt que de s’appuyer sur des solutions manuelles : SmartMatch réutilise automatiquement la mémoire de traduction existante, les catégories plurielles basées sur ICU MessageFormat et CLDR gardent les décisions grammaticales à l’intérieur du fichier au lieu d’un tableau, et les limites de caractères et d’octets au niveau du projet ou de la chaîne de caractères et d’octets sont appliquées à l’ingestion plutôt que d’être arrêtées après la traduction. La couverture des formats est large par défaut — JSON, YAML, XLIFF, XLIFF 2.0, Gettext PO/POT, Android XML, iOS Strings et ARB (Flutter) sont analysés automatiquement sans script personnalisé pour la plupart des projets. Pour les équipes qui ont besoin que cela soit connecté directement aux flux de travail d’ingénierie, les connecteurs de dépôt de Smartling poussent des chaînes nouvelles ou modifiées d’un pipeline CI/CD vers la traduction et ouvrent une pull request quand elles sont prêtes — voyez comment les entreprises relient la localisation aux flux de travail produit. Côté qualité, voyez quelles plateformes de localisation offrent les meilleures capacités de contrôle qualité par traduction pour la façon dont l’assurance qualité linguistique automatisée est couchée, en plus des mécaniques abordées ici.
Prêt à voir Smartling en action?
Discutez avec un membre de l’équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.