La localisation d’un logiciel métier couvre les textes, dates, nombres, devises et règles de saisie utilisés par chaque marché.
Traduire les boutons ne suffit pas. Une date comme 04/05 peut être comprise différemment, une virgule peut représenter un séparateur décimal et un texte français peut être plus long que son équivalent original. Les règles doivent être testées dans le parcours réel.
Séparer les textes
Placez les textes dans des ressources versionnées et utilisez une clé stable. Évitez de construire une phrase en assemblant des fragments dont l’ordre change selon la langue. Les paramètres et les pluriels doivent être gérés par le mécanisme de traduction.
Un message d’erreur doit rester compréhensible après traduction. Les libellés métiers doivent correspondre au vocabulaire utilisé par les équipes. Faites relire les mots sensibles dans les critères d’acceptation.
Gérer les formats
Stockez les dates dans un format non ambigu et affichez-les selon la préférence de l’utilisateur. Conservez le fuseau lorsque l’heure influence une échéance. Les nombres et montants doivent suivre une règle partagée avec les exports et les APIs.
Les textes peuvent changer la largeur d’un bouton, d’un tableau ou d’un PDF. Testez les écrans longs et les valeurs manquantes. Une traduction absente ne doit pas afficher une clé technique à l’utilisateur final.
Tester la recherche et les imports
Les accents, apostrophes et caractères propres à une langue doivent être testés dans la recherche. Un import doit préciser son encodage et son format de date. Les imports CSV doivent appliquer une règle explicite plutôt qu’une interprétation locale.
Sources : W3C, internationalisation, Unicode, bonnes pratiques.
Préparez un cas de recette par langue avec une date, un montant, un statut, une erreur et un export. Comparez les valeurs métier, pas seulement l’apparence. Un texte traduit doit rester compréhensible avec un rôle limité et un compte appartenant à plusieurs espaces.
Conservez la version des ressources et la date de publication. Une correction de traduction ne doit pas changer un document déjà validé. Vérifiez aussi les noms longs, les accents, les formats de devise et les messages d’erreur avec les rôles utilisés par les équipes.
Ajoutez un cas de recette par langue et par rôle. Comparez le contenu, les formats et la capacité à accomplir l’action. Une traduction doit rester correcte dans les exports, les notifications et les fichiers générés.
Le support conserve les termes approuvés et signale les divergences. Une mise à jour de ressource est livrée avec le code correspondant afin d’éviter un écran partiellement traduit.
Organiser les traductions
Une clé de texte doit décrire son usage et rester stable lorsque le libellé change. Les phrases avec variables doivent respecter la grammaire de chaque langue. N’assemblez pas un nom, un verbe et une unité dans un ordre imposé par le français.
Les messages d’erreur, états et permissions doivent utiliser le même vocabulaire que l’interface. Un statut traduit de deux manières peut faire croire à deux états. Le propriétaire métier valide les termes importants et conserve un petit glossaire.
Gérer les données
Stockez dates et nombres sous une forme non ambiguë, puis affichez-les selon la langue et le fuseau. Les exports doivent documenter le format choisi. Les calculs monétaires gardent l’unité et la devise même si l’interface change.
Les noms et adresses peuvent contenir des caractères inattendus. Testez les longueurs, apostrophes, accents, alphabets et directions d’écriture utiles à votre clientèle. Un champ prévu pour une langue ne doit pas couper une valeur valable dans une autre.
Vérifier les parcours
Testez connexion, recherche, formulaire, export, notification et PDF dans chaque langue supportée. Vérifiez les messages longs, les boutons, les tableaux et les erreurs. L’accessibilité clavier doit rester correcte après traduction.
Une langue absente doit produire un comportement prévu, comme une langue de secours signalée. N’affichez pas une clé technique à l’utilisateur final. La version des ressources doit être liée à la version du logiciel pour expliquer une différence de texte.
Prévoir les variations de longueur
Un bouton ou un tableau doit accepter un libellé plus long sans couper l’action. Testez les messages d’erreur, les titres, les menus et les PDF. Les nombres de résultats et les pluriels doivent utiliser une règle propre à la langue, y compris pour zéro.
Les noms d’entreprise et de personne ne doivent pas être tronqués dans les exports. Une colonne peut afficher une version courte à l’écran tout en conservant la valeur complète dans le détail. Le format des exports doit documenter cette différence.
Organiser la revue
Le propriétaire métier relit les textes qui touchent la facturation, les statuts et les droits. Le support signale les termes qui prêtent à confusion. Une nouvelle traduction doit être testée avec un compte et un jeu de données représentatifs avant son activation.
Conservez les versions des ressources et la date de publication. Une correction de traduction ne doit pas modifier l’historique d’un document déjà validé.