Langue de l’interface
Une chaîne courte
peut exiger une longue explication
« Open » peut décrire un état ou commander une action. « Save » peut enregistrer une donnée ou renvoyer à une économie. Une liste de chaînes sans contexte masque ces distinctions. La localisation de logiciels exige la fonction du texte, l’objet auquel il se rapporte et l’écran où il apparaît.
Les captures d’écran, les identifiants de chaînes stables et les commentaires des développeurs aident à établir ce contexte. Un commentaire utile explique le comportement : si une commande ouvre une fenêtre, crée un fichier ou envoie un enregistrement. Il signale aussi les restrictions que les mots ne permettent pas de deviner, comme une largeur d’étiquette fixe ou une variable insérée à l’exécution.
Le travail linguistique relie les libellés d’interface au contenu d’aide, aux guides d’utilisation et aux notes de version. Une fonctionnalité doit conserver le nom convenu sur tous ces supports. Les manuels connexes relèvent de la traduction technique ; les pages produit publiques ont leurs propres exigences de traduction de site web.
Contraintes de localisation
Protéger la fonction
autant que le sens
| Caractéristique de la chaîne | Risque linguistique | Exigence de briefing |
|---|---|---|
| Variables et espaces réservés | Un nom ou un nombre inséré peut modifier la grammaire de la phrase environnante. | Identifier les éléments protégés et expliquer les valeurs qu’ils représentent. |
| Messages au pluriel | Toutes les langues ne répartissent pas le singulier et le pluriel de la même façon. | Fournir la structure complète des messages et expliquer les formes prises en charge. |
| Libellés courts communs | Un même mot source peut exiger des traductions différentes selon le contexte. | Identifier chaque écran ou fonction utilisant la chaîne partagée. |
| Limites de longueur | Une traduction correcte peut occuper plus d’espace que le texte source. | Indiquer les limites réelles et distinguer le nombre de caractères de la largeur visuelle. |
| Dates et nombres | Un format source familier peut être ambigu dans d’autres paramètres régionaux. | Indiquer quels formats sont gérés par l’application et lesquels sont du texte modifiable. |
Les exemples décrivent des considérations de localisation. Les formats de fichiers acceptés, la préparation technique et les contrôles de mise en œuvre sont définis pour chaque projet.
Décisions terminologiques
Nommer la fonctionnalité
une fois, puis l’employer de façon cohérente
La terminologie de l’interface fait partie du comportement du produit : elle indique ce qui peut être sélectionné, modifié, supprimé ou confirmé.
Un glossaire doit distinguer les noms de produits des noms de fonctionnalités traduisibles et expliquer les termes à plusieurs sens. Un « espace de travail », par exemple, peut désigner une zone de compte, un dossier partagé ou un lieu physique. Un équivalent approuvé sans définition peut reporter la même ambiguïté sur chaque écran traduit.
La cohérence exige aussi du jugement. Une commande de menu et une phrase d’un article d’aide peuvent exiger des formes grammaticales différentes tout en désignant la même fonctionnalité. Réutiliser un terme ne signifie pas recopier mécaniquement un mot fléchi. Des traducteurs locuteurs natifs peuvent maintenir le concept stable tout en rendant chaque occurrence grammaticale.
Babylon Translations utilise des outils de TAO, dont Trados, et un logiciel dédié d’assurance qualité. La mémoire de traduction fournit des segments bilingues réutilisables ; les fiches terminologiques identifient les concepts approuvés. Ni l’une ni les autres ne dispensent de lire le message en contexte. Le processus de traduction de l’agence comprend une relecture et une révision avant la livraison.
Préparation de la publication
Constituer l’ensemble linguistique
prêt pour une version
Identifier la version source
Le dossier doit porter une référence de version et distinguer les chaînes nouvelles, modifiées et retirées. Des identifiants stables permettent de relier les questions de traduction au bon message. Les traductions approuvées antérieures sont des références précieuses, surtout lorsque la formulation anglaise a changé alors que la fonctionnalité sous-jacente est restée la même.
Résoudre les questions produit
Désignez un référent produit capable d’expliquer le comportement et d’approuver la terminologie. Un registre de questions concis doit comprendre l’identifiant de la chaîne, le contexte et la décision. Les réponses concernant les commandes partagées peuvent toucher plusieurs langues ; ces décisions doivent donc parvenir à chaque équipe linguistique concernée avant l’approbation.
Vérifier le texte implémenté
La revue linguistique compare la traduction à sa source. Les contrôles de l’équipe produit dans l’application répondent à d’autres questions : texte tronqué, texte manquant, mauvais placement des chaînes et comportement à l’exécution. Le cahier des charges doit répartir la responsabilité de chaque contrôle et prévoir du temps pour les corrections de texte qui en résultent.
Localiser la tâche, et non une suite de fragments
Une phrase assemblée à partir de plusieurs fragments traduits peut devenir agrammaticale lorsque la langue cible modifie l’ordre des mots, le genre ou le cas. Des messages complets donnent généralement aux traducteurs un meilleur contrôle du sens. Lorsque l’application impose des fragments, le brief doit montrer les combinaisons qui peuvent réellement se produire.
Chaque marché apporte ses propres contraintes : écritures, foisonnement du texte, formats de date et de nombre, formes d’adresse. Les 32 langues et variantes proposées par Babylon Translations comprennent des formes régionales distinctes de l’anglais, du français, de l’espagnol et du portugais. Choisir les paramètres régionaux visés avant la traduction évite des conventions linguistiques contradictoires au sein d’une même version.
Questions sur la localisation de logiciels
Avant que les chaînes
quittent le développement
De quels fichiers a-t-on besoin pour la localisation de logiciels ?
La localisation de logiciels exige un texte source modifiable, suffisamment structuré pour relier chaque message à sa fonction. Le format de fichier et le mode de remise doivent être convenus avant la traduction. Des identifiants stables, des captures d’écran, des commentaires de développeurs, des limites de caractères et des traductions antérieures rendent le dossier plus utile ; le seul nom d’un format n’établit pas que le contexte est complet.
Comment les variables sont-elles gérées dans un logiciel traduit ?
Les variables doivent rester reconnaissables comme des éléments techniques protégés, tandis que la langue environnante reflète les valeurs qu’elles représentent. Le cahier des charges doit distinguer le texte modifiable des éléments protégés et expliquer toute restriction d’ordre. Un contrôle des variables peut repérer des écarts techniques, mais un linguiste a encore besoin de contexte pour juger si le message complet sera grammatical et exact.
Pourquoi les traducteurs ont-ils besoin de captures d’écran pour les chaînes de logiciels ?
Les captures d’écran montrent le rôle et le contexte d’une chaîne qui serait sinon ambiguë. Elles aident à distinguer les commandes des états, à identifier l’objet décrit et à révéler les contraintes d’espace. Elles sont plus utiles lorsqu’elles sont liées aux identifiants de chaînes et accompagnées d’explications sur les interactions qu’une image statique ne peut pas montrer.
Une mémoire de traduction peut-elle appuyer les versions logicielles ultérieures ?
La mémoire de traduction peut appuyer les versions ultérieures en présentant des segments déjà traduits pour les réutiliser ou les comparer. Les chaînes nouvelles et modifiées doivent encore être évaluées dans leur contexte actuel. Une phrase source identique peut désormais décrire une autre fonction, tandis qu’une petite modification de la source peut changer le sens au point d’exiger une nouvelle décision de traduction.
La localisation de logiciels est-elle la même chose que le test de logiciels ?
La localisation de logiciels concerne la langue et les exigences régionales ; les tests logiciels examinent le comportement de l’application. Une revue linguistique ne démontre pas qu’une version traduite affiche correctement toutes les chaînes ni qu’elle gère toutes les saisies. Les contrôles d’implémentation doivent porter sur l’interface réelle, et le brief doit indiquer qui fournit le contexte, valide la langue et vérifie la version obtenue.
Comment la localisation de logiciels est-elle tarifée et planifiée ?
Une estimation de localisation de logiciels dépend du volume de texte, des combinaisons de langues, des traductions existantes, de la qualité du contexte et des contraintes techniques. Les chaînes courtes peuvent exiger des clarifications substantielles ; le nombre de mots seul ne décrit donc pas l’effort. Une date de sortie, un lot source stable et des responsabilités de révision claires fournissent la base d’un périmètre et d’un calendrier pertinents.