Traduire une IHM et les textes d'alarme d'un automate : export, longueurs, glossaire, vérification

Le principe : exporter, traduire, réimporter

Tous les ateliers logiciels courants savent exporter les textes d'un projet dans un fichier, avec une colonne ou un fichier par langue, puis les réimporter. C'est la seule méthode qui passe à l'échelle : une machine compte facilement plusieurs milliers de textes entre les écrans, les boutons, les alarmes et les commentaires du programme.

Trois règles avant de commencer :

1. Figez la langue source. Les textes doivent être complets et relus dans la langue d'origine avant l'export ; chaque correction ultérieure est à reporter dans toutes les langues.
2. Exportez tout d'un coup. Textes du projet, alarmes et localisation de l'automate d'une même machine : un texte présent dans plusieurs fichiers doit être traduit une seule fois, et de la même façon.
3. Réimportez dans une copie du projet. Jamais directement dans le projet de référence.

Où se trouvent les textes, outil par outil

Les noms de menus varient d'une version à l'autre ; voici où chercher.

Si votre outil n'apparaît pas ici, un tableau .xlsx ou .csv avec une colonne par langue, titrée par un code comme fr-FR ou de-DE, fait l'affaire dans la plupart des cas.

Ce qui ne doit pas être traduit

Un texte d'alarme contient souvent une variable qui sera remplacée par une valeur à l'exécution : le numéro d'un moteur, une température, un nom de recette. Selon l'outil, elle ressemble à <field ref="0" />, @1%d@, /N:5 {[PLC]Tank.Level} NOFILL DP:1/, %s%PLC1.MAIN.bRun%/s%, {0} ou %5.2f. Si la traduction en modifie un caractère, l'alarme s'affiche cassée, ou l'import échoue.

À protéger systématiquement :

• les variables et références de champ : présentes une fois et une seule, ni perdues ni dupliquées ;
• les balises de mise en forme ;
• les repères d'équipement (P-101, LT101), qui doivent rester identiques dans toutes les langues pour que l'opérateur et le technicien parlent du même appareil ;
• les nombres (seuils, consignes, adresses) ; seul le séparateur décimal peut changer ;
• les unités.

Un traducteur humain ou un moteur de traduction automatique ne connaît pas ces conventions. Il faut les lui signaler, puis contrôler le résultat.

Les longueurs de texte

Un texte d'IHM vit dans un champ de taille fixe : un bouton, une colonne de la liste d'alarmes, une étiquette. Une traduction est souvent plus longue que sa source ; un texte qui déborde est tronqué à l'écran, parfois au milieu du mot qui compte.

Fixez la limite de chaque texte, dans cet ordre de préférence :

1. La longueur maximale fournie par l'export, quand il y en a une : certains exports, comme les alarmes IHM de TIA Portal, ont une colonne de longueur maximale.
2. Une règle relative à la source : par exemple 1,3 fois la longueur du texte source, ou « pas plus long que la source » pour les boutons serrés.
3. Un nombre fixe de caractères pour un type de champ connu.

Comptez la longueur comme l'opérateur la voit : pour un texte sur plusieurs lignes, c'est la plus longue ligne qui compte ; un caractère chinois, japonais ou coréen occupe à peu près la largeur de deux caractères latins ; une variable occupe la place de la valeur qu'elle affichera. Quand un texte reste trop long, une abréviation usuelle d'IHM vaut mieux qu'un texte coupé.

Le glossaire

Le glossaire est ce qui distingue une IHM traduite d'une IHM compréhensible. « Acquit défaut », « Marche forcée », « Convoyeur de rejet » doivent avoir une seule traduction dans tout le projet, et de préférence dans tous les projets de l'entreprise.

• Tenez-le dans un simple CSV, une colonne par langue, avec une colonne de note pour le contexte.
• Rendez obligatoires les termes de plusieurs mots et les termes propres à vos machines ; les mots courants peuvent rester des suggestions.
• Donnez-le au traducteur, humain ou machine, avant la traduction, puis vérifiez qu'il a été respecté.
• Conservez les traductions validées dans une mémoire de traduction : la nouvelle version d'une machine ne se retraduit pas depuis zéro. Le format TMX permet de l'échanger avec une agence de traduction.

Les textes de sécurité

Arrêt d'urgence, danger, surface chaude, risque d'écrasement, protecteur ouvert : ces textes engagent la sécurité des personnes. Ils doivent être relus un par un par une personne qui maîtrise la langue cible, quelle que soit la façon dont ils ont été traduits, et jamais validés en masse.

La vérification avant et après le réimport

Avant le réimport, contrôlez chaque ligne :

Après le réimport, dans la copie du projet : basculez la langue de l'IHM, ouvrez les écrans les plus chargés, déclenchez quelques alarmes en simulation et regardez la liste d'alarmes. Les débordements et les variables mal placées se voient tout de suite à l'écran, beaucoup moins dans un tableur.

Traduire avec hmi-translate

hmi-translate applique cette méthode sur votre poste : il lit les exports de TIA Portal et WinCC, FactoryTalk View ME / SE, TwinCAT HMI, TwinCAT 3 PLC et CODESYS, Ignition et de tout tableau avec une colonne par langue, protège variables, balises, repères et nombres, traduit avec Ollama en local (rien ne quitte l'ordinateur) ou avec votre propre clé OpenAI, Anthropic ou DeepL, contrôle chaque ligne comme ci-dessus, vous fait relire les textes signalés, puis rend des fichiers au même format, avec un rapport. Un glossaire de 300 termes industriels en 8 langues est fourni, le vôtre est prioritaire. Ses limites : les formats ont été réalisés d'après la documentation des éditeurs, sans projets clients réels ; les fichiers .xls et les textes dans les images ne sont pas traités ; il ne certifie pas les textes de sécurité, il les signale. Un essai gratuit traduit jusqu'à 500 textes par projet.

Sources

• hmi-translate 1.0, guide d'utilisation (aller-retour par outil, longueurs, glossaire, contrôles)
• Documentation des fonctions d'export et d'import de textes de TIA Portal, FactoryTalk View, TwinCAT, CODESYS et Ignition, telle que résumée dans le guide ci-dessus