Bonnes pratiques de localisation de logiciels : 10 étapes avec exemples

Ce guide vous accompagne tout au long du processus de localisation de logiciels, du début à la fin, avec des bonnes pratiques et des exemples de code réels.

Votre application vient d'être lancée en France. Les inscriptions affluent, puis les tickets d'assistance commencent à inonder votre boîte de réception. Les utilisateurs ne peuvent pas cliquer sur le bouton « Acheter maintenant » car il est tronqué. Les menus de navigation sont cassés et s'affichent sur deux lignes. Votre interface utilisateur, conçue avec soin, semble complètement cassée.

C'est ce qui arrive lorsque vous passez directement à la traduction sans localiser correctement votre logiciel. Le texte est traduit, mais l'application n'a pas été conçue pour le gérer.

Ce guide couvre tout ce dont vous avez besoin pour réussir la localisation de logiciels. Vous apprendrez :

• Ce qu'est la localisation de logiciels
• La différence entre la localisation, la traduction et l'internationalisation
• Comment se préparer au processus de localisation de logiciels
• Les bonnes pratiques pour le contenu dynamique, l'expansion du texte, le formatage spécifique à la locale et les tests
• Le coût de la localisation de logiciels
• Comment configurer un flux de travail de localisation qui ne casse pas à chaque publication

Qu'est-ce que la localisation de logiciels ?

La localisation de logiciels est le processus d'adaptation de votre logiciel à un marché spécifique. Cela va au-delà de la traduction du texte. Cela signifie ajuster tout ce qui affecte la façon dont les utilisateurs du marché cible perçoivent votre logiciel : les formats de date et de nombre, la devise, la mise en page de l'interface utilisateur, les images et les références culturelles.

L'objectif est de donner l'impression que votre logiciel a été conçu pour ce marché dès le départ.

Voici un exemple qui montre comment la même date peut signifier deux choses différentes selon l'endroit où se trouve votre utilisateur :

Ce n'est qu'un petit exemple de ce que gère la localisation de logiciels. Multipliez cela par les dates, les devises, les formats et les références culturelles, et vous commencez à voir l'ampleur du travail.

Localisation de logiciels vs Traduction vs Internationalisation

Beaucoup de gens utilisent ces trois termes de manière interchangeable, mais ils signifient des choses différentes et interviennent à différentes étapes du développement.

Le processus de localisation de logiciels

La localisation de logiciels n'est pas une étape unique que vous terminez avant le lancement. C'est un processus continu qui se déroule en parallèle du développement. Voici un aperçu de la façon dont il se décompose généralement :

La plupart des équipes exécutent le processus de l'une des trois manières suivantes :

1. Waterfall (en cascade) La localisation commence une fois le développement terminé. Vous finissez de développer, puis vous transmettez le tout pour traduction en un seul lot. C'est simple à gérer, mais cela retarde votre publication dans d'autres langues et rend les bugs coûteux à corriger à ce stade.
2. Localisation Agile La localisation s'exécute en parallèle du développement. Au lieu d'un seul gros lot à la fin, vous envoyez des chaînes pour traduction tout au long du cycle de développement. Le timing est meilleur, mais le processus reste manuel. Quelqu'un dans votre équipe doit exporter les chaînes, gérer les transferts manuels et réimporter les traductions.
3. Localisation continue La localisation est entièrement automatisée. Votre dépôt se connecte directement à votre outil de traduction, de sorte que lorsqu'une chaîne change, elle est envoyée pour traduction automatiquement. Lorsque la traduction est prête, elle est fusionnée automatiquement.

Bonnes pratiques de localisation de logiciels

Chaque projet est différent, et vos besoins en localisation dépendront de votre stack technique, de vos marchés cibles et de votre équipe. Cette liste couvre l'essentiel de ce qui fait fonctionner la localisation de logiciels.

Stockez tout votre texte traduisible dans des fichiers séparés

Lorsque vous intégrez du texte en dur directement dans votre code source, les outils de traduction ne peuvent pas le trouver. Ces outils fonctionnent en analysant des fichiers de ressources tels que JSON, PO ou YAML à la recherche de chaînes à traduire. Si votre texte est enfoui dans vos fichiers JavaScript, PHP ou Ruby, l'analyse ne donne rien.

C'est la raison la plus courante de l'échec des projets de localisation. Les équipes ne découvrent le problème que lorsqu'elles essaient de traduire et réalisent qu'elles doivent d'abord refactoriser des milliers de chaînes.

C'est pourquoi il est préférable de déplacer tout le texte destiné aux utilisateurs vers des fichiers de ressources dédiés dès le départ. Cela inclut tout ce que vos utilisateurs peuvent voir :

• Étiquettes d'interface utilisateur, boutons et éléments de menu
• Messages d'erreur et texte de validation
• Modèles d'e-mails et notifications
• Texte d'aide, infobulles et texte d'espace réservé
• Messages de succès et de confirmation

Le format de fichier que vous utilisez dépend de votre framework :

Voici un avant et un après pour chaque framework majeur.

React :

Avant

<button>Submit</button>

Après, en utilisant react-i18next

<button>{t('submit_button')}</button>

WordPress :

Avant

echo 'Submit';

Après, i18n de WordPress

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails :

Avant

flash[:notice] = "Profile updated successfully"

Après, en utilisant Rails I18n :

flash[:notice] = t('profile.update_success')

Il est également important de donner à vos chaînes des clés claires et descriptives. Une clé nommée checkout.submit_button indique exactement à un traducteur où cette chaîne apparaît et ce qu'elle fait. En revanche, string_147 ne lui dit rien, ce qui conduit à des erreurs de traduction. Des clés descriptives permettent également à votre propre équipe de suivre plus facilement quelles chaînes ont été externalisées et de repérer ce qui manque.

Utilisez des espaces réservés pour les noms, les nombres et les dates

Lorsque votre texte inclut des données variables comme le nom d'un utilisateur ou un numéro de commande, il est tentant de construire la phrase en joignant des morceaux de texte ensemble dans votre code. Cela casse dans d'autres langues.

Voici pourquoi :

const message = 'Hello, ' + name + '!';

Cet exemple divise la phrase en trois fragments. En anglais, l'ordre des mots fonctionne. Mais dans des langues comme le japonais, le nom se trouve à une position différente dans la phrase. Vos traducteurs ne peuvent pas réorganiser les fragments, la phrase finit donc par être grammaticalement incorrecte.

Les espaces réservés résolvent ce problème en gardant la phrase entière. Vos traducteurs ou votre outil de traduction obtiennent la phrase complète pour travailler, y compris un marqueur indiquant où va la variable. Ils peuvent placer ce marqueur là où la grammaire de leur langue l'exige.

Voici à quoi ressemblent les espaces réservés dans différents formats de fichiers :

JSON :

{ "greeting": "Hello, {name}!" }

YAML :

greeting: "Hello, %{name}!"

PO :

msgid "Hello, %s!"

La syntaxe varie selon le format, mais le principe est le même.

Concevez votre interface utilisateur pour gérer des textes plus longs

La plupart des langues sont plus longues que l'anglais. Un bouton qui s'intègre parfaitement dans votre interface utilisateur en anglais sera souvent tronqué en allemand, en français ou en espagnol. Si vous avez conçu votre mise en page autour de largeurs fixes, vous aurez une interface utilisateur cassée dans chaque langue que vous ajoutez.

Voici les taux d'expansion typiques avec lesquels vous travaillez :

Certains mots individuels peuvent s'allonger bien plus que ces moyennes. « FAQ » devient « Preguntas frecuentes » en espagnol, soit une augmentation de 567 %.

La solution est de concevoir des mises en page flexibles plutôt que fixes. Au lieu de définir une largeur fixe pour un bouton, laissez-le s'agrandir avec son contenu :

Avant — la largeur fixe casse dans les langues plus longues

button { width: 120px; }

Après — s'agrandit avec le texte traduit

button {
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

Pensez-y lors de la phase de conception. Si vous concevez d'abord pour l'anglais et traduisez ensuite, vous passerez plus de temps à déboguer les problèmes de mise en page dans chaque langue que vous n'en auriez passé à intégrer la flexibilité dès le départ.

Écrivez un texte facile à traduire

La façon dont vous rédigez votre texte source affecte la qualité de la traduction. Les formulations vagues, les expressions idiomatiques et les jeux de mots astucieux produisent souvent des traductions confuses ou incorrectes.

Les problèmes les plus courants à éviter :

Phrases incomplètes

Une chaîne comme « No items » (Aucun article) peut signifier plusieurs choses. N'y a-t-il aucun article dans le panier ? Une recherche n'a-t-elle donné aucun résultat ? Votre traducteur doit deviner, et une mauvaise supposition entraîne une mauvaise traduction.

Écrivez des phrases complètes avec un sujet et un verbe clairs.

Avant — ambigu

"No items"

Après — sens clair

"You have no items in your cart."

Expressions idiomatiques

« This is a piece of cake » (C'est du gâteau) a du sens pour un anglophone natif. Traduit littéralement en allemand, vos utilisateurs se demanderont pourquoi votre application parle de dessert. La plupart des expressions ne fonctionnent que dans la langue donnée, il est donc préférable de les éviter complètement.

Vocabulaire complexe

Les mots simples se traduisent de manière plus fiable. Écrivez « remove » (supprimer) au lieu de « eliminate » (éliminer) et « use » (utiliser) au lieu de « utilize » (employer). En cas de doute, choisissez le mot le plus court et le plus courant.

Gérez correctement les dates, les nombres et les devises

Les formats de date et de nombre varient considérablement d'une locale à l'autre. Le codage en dur de ces formats pose le même problème que le codage en dur du texte : cela fonctionne sur un marché et casse sur les autres.

Utilisez les utilitaires de localisation intégrés de votre framework pour les formater automatiquement en fonction de la locale de l'utilisateur.

JavaScript :

Avant

const price = '$' + amount.toFixed(2);

Après

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails :

Avant

"$#{price}"

Après

number_to_currency(price, locale: I18n.locale)

De cette façon, le même code gère correctement le formatage pour chaque locale que vous prenez en charge.

Prévoyez la locale, pas seulement la langue

La langue et la locale ne sont pas la même chose. L'espagnol est une langue. L'espagnol mexicain (es-MX), l'espagnol d'Espagne (es-ES) et l'espagnol argentin (es-AR) sont des locales. Les différences entre elles vont au-delà du vocabulaire. Les formats de date, la devise, les références culturelles et le ton peuvent tous varier.

Si vous spécifiez uniquement un code de langue sans locale, vous risquez de montrer le mauvais contenu aux utilisateurs dans des régions spécifiques.

Prenez le français comme exemple :

Lorsque vous configurez vos fichiers de ressources, utilisez des codes de locale complets plutôt que des codes de langue seuls. Cela vous donne la flexibilité de fournir un contenu différent à différentes régions sans restructurer votre configuration plus tard.

Donnez aux traducteurs le contexte dont ils ont besoin

Si vous décidez de travailler avec des traducteurs humains, gardez à l'esprit qu'ils travaillent directement à partir de vos fichiers de ressources. Sans informations supplémentaires, tout ce qu'ils voient est la chaîne elle-même. Ils n'ont aucun moyen de savoir où elle apparaît dans l'interface utilisateur, à quoi elle fait référence, ou de combien d'espace dispose la traduction pour s'insérer.

Une chaîne comme « Cancel » (Annuler) pourrait faire référence à l'annulation d'une commande, d'un abonnement ou de la soumission d'un formulaire. Chacune de ces actions pourrait se traduire différemment selon la langue.

Ajoutez des commentaires à vos fichiers de ressources pour expliquer ce que fait chaque chaîne et où elle apparaît :

JSON avec commentaires de contexte

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

Si vous utilisez un outil de traduction, la plupart des plateformes vous permettent de joindre des captures d'écran qui montrent où ces chaînes apparaissent. Cela permet aux outils de traduction de produire des traductions nettement plus précises que lorsqu'ils travaillent uniquement à partir de texte.

Configurez la détection de la langue

Une fois que vos chaînes sont dans des fichiers de ressources et que votre interface utilisateur est flexible, vous devez afficher automatiquement la bonne langue à chaque utilisateur. La plupart des frameworks gèrent cela avec des bibliothèques i18n intégrées.

React avec react-i18next :

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails :

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

Définissez toujours une langue de repli. Lorsqu'un fichier de traduction est manquant ou qu'une chaîne n'a pas encore été traduite, votre application affiche la langue de repli au lieu d'une clé cassée comme auth.login_error.

Pour les applications web, vous pouvez également laisser les utilisateurs remplacer manuellement la langue détectée. Stockez leur choix pour qu'il persiste d'une session à l'autre :

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Les applications mobiles n'ont généralement pas besoin d'un sélecteur de langue. Les utilisateurs s'attendent à ce que les applications mobiles suivent les paramètres de leur appareil.

Choisissez un outil de localisation

Un flux de travail de localisation manuel ressemble à peu près à ceci : exporter les chaînes vers une feuille de calcul, l'envoyer à un traducteur, attendre plusieurs jours, la récupérer, copier les traductions dans vos fichiers, découvrir que vous avez oublié 12 chaînes, et recommencer. Cela ne passe pas à l'échelle.

Un outil de localisation de logiciels gère l'ensemble du flux de travail pour vous. Un bon outil va :

• Se connecter à votre dépôt, détecter les chaînes nouvelles et modifiées, et maintenir les traductions à jour en continu
• Donner à votre équipe un endroit central pour gérer toutes les traductions
• Inclure des fonctionnalités de TAO intégrées comme la mémoire de traduction, la détection des limites de longueur et la gestion terminologique

PTC fait tout cela. De plus, l'essai couvre vos 20 000 premiers mots dans 2 langues, et la prise en main prend moins de 5 minutes.

Découvrez comment PTC gère la localisation de logiciels

Testez chaque version localisée avant le lancement

La traduction n'est pas la dernière étape. Avant de publier une version localisée, testez-la de la même manière que vous testeriez n'importe quelle autre version.

Mise en page : Le texte s'intègre-t-il sans être tronqué ? La navigation fonctionne-t-elle toujours, ou observez-vous un débordement ?

Fonctionnalité : Les formulaires sont-ils soumis correctement ? Les messages d'erreur apparaissent-ils dans la bonne langue ? La recherche gère-t-elle les caractères accentués comme é, ñ et ü ?

Formatage : Les dates sont-elles dans le bon format pour la locale ? Les nombres et les devises sont-ils formatés correctement ? Le symbole de la devise est-il dans la bonne position ?

Langues écrites de droite à gauche : Si vous prenez en charge l'arabe ou l'hébreu, testez la disposition RTL complète séparément. La prise en charge RTL affecte plus que la direction du texte. Elle affecte toute la mise en page de votre interface utilisateur.

Intégrez les tests de localisation dans votre processus d'assurance qualité dès le départ. Découvrir un parcours de paiement cassé en allemand via les avis des utilisateurs coûte nettement plus cher que de le repérer avant le lancement.

Combien coûte la localisation de logiciels ?

Une bonne localisation de logiciels n'a pas à être coûteuse. Le facteur le plus important dans votre budget n'est pas le nombre de langues que vous prenez en charge. C'est la façon dont vous traduisez.

La traduction humaine professionnelle pour les logiciels coûte généralement entre 0,10 $ et 0,30 $ par mot. Pour une application de taille moyenne avec 15 000 mots, cela représente 1 500 $ à 4 500 $ par langue, avant même de prendre en compte les tests, la gestion de projet ou les futures mises à jour à chaque fois que votre produit change.

La traduction par IA avec un outil comme PTC coûte une fraction de ce prix :

Après l'essai, PTC fonctionne sur un modèle Pay-As-You-Go. Vos 500 premiers mots chaque mois sont gratuits. Plus vous traduisez, plus votre tarif au mot baisse, et une fois que vous atteignez un tarif inférieur, vous le conservez pendant trois mois, même si votre volume diminue.

Pour obtenir un chiffre exact pour votre projet, utilisez le calculateur de coûts de PTC ou téléversez directement votre fichier de ressources pour voir le coût avant de vous engager.

Calculez votre coût de traduction

Configurez votre processus de localisation de logiciels en 3 étapes

Les bonnes pratiques de localisation de logiciels ci-dessus couvrent beaucoup de terrain. Certaines d'entre elles, comme la rédaction de textes traduisibles ou la planification des locales, nécessitent des décisions délibérées de la part de votre équipe. Mais une grande partie du travail technique, comme la détection des modifications de chaînes, la gestion des fichiers de traduction, le signalement des problèmes de longueur et la synchronisation des traductions, peut être automatisée avec le bon outil.

Voici comment mettre en place un processus de localisation fonctionnel avec PTC.

Inscrivez-vous à PTC

Créez un projet dans PTC, téléversez vos fichiers de ressources et sélectionnez vos langues de traduction. Pendant l'essai, vous pouvez sélectionner 2 langues.

PTC génère automatiquement une description de votre application en fonction du fichier téléversé. Examinez la description et conservez-la ou modifiez-la. Vous pouvez également téléverser des traductions existantes et ajouter un glossaire de termes qui doivent toujours être traduits d'une manière spécifique, comme les noms de produits ou la terminologie technique.

L'ensemble de la configuration prend moins de 5 minutes.

Affichez et affinez les traductions

Une fois les traductions prêtes, au lieu de modifier les chaînes individuelles manuellement ou d'ajouter des membres de l'équipe pour gérer les révisions dans des langues spécifiques, vous pouvez effectuer une relecture de traduction par IA avec PTC.

L'AI Visual QA pousse le processus standard de révision au niveau des chaînes plus loin en examinant votre interface utilisateur réelle dans chaque langue cible.

Ce que vous arrêtez de faire :

• Ouvrir manuellement votre produit dans chaque langue cible pour vérifier les problèmes d'affichage
• Coordonner des relecteurs d'assurance qualité qui parlent les langues cibles
• Découvrir des mises en page cassées ou des chaînes manquantes après une publication

Ce que vous obtenez à la place :

• PTC examine visuellement votre interface utilisateur traduite et trouve des problèmes que l'inspection des chaînes ne peut pas détecter
• Les problèmes trouvés dans les traductions générées par PTC sont corrigés automatiquement
• Chaque langue est révisée avant la publication, en quelques minutes plutôt qu'en plusieurs heures

Pour commencer, accédez à l'onglet AI Visual QA depuis votre tableau de bord. Selon le type de logiciel que vous traduisez, vous pourrez soit téléverser des captures d'écran de votre interface utilisateur, soit utiliser l'extension de navigateur PTC Visual QA pour enregistrer les écrans à réviser.

PTC recherchera les problèmes qui n'apparaissent qu'une fois votre application en cours d'exécution. Il corrige automatiquement les problèmes au niveau de la traduction, comme les formulations maladroites, le mauvais ton ou le texte qui ne correspond pas au contexte. Les problèmes au niveau du code, tels que les clés manquantes, les chaînes en dur et les bugs de formatage, sont signalés pour que votre équipe les résolve dans la source.

Connectez votre flux de travail de développement

Lorsque vous êtes à l'aise avec le fonctionnement de PTC, passez au Pay-As-You-Go pour accéder aux fonctionnalités Pro, comme la connexion de PTC à votre dépôt GitHub, GitLab ou Bitbucket. Grâce à cette intégration, PTC détecte automatiquement les chaînes nouvelles et modifiées et maintient vos traductions à jour sans téléversement manuel de fichiers.

Si vous souhaitez aller plus loin, l'API PTC vous permet d'intégrer la traduction directement dans votre pipeline CI/CD, afin que les versions localisées soient toujours prêtes à être publiées en même temps que votre langue source.

Commencez à utiliser PTC pendant 30 jours

Exemple de localisation de logiciels : Traduire WPML avec PTC

WPML est l'un des plugins multilingues les plus utilisés pour WordPress. Le maintenir traduit dans 23 langues n'est pas optionnel. Cela fait partie de chaque publication.

Pendant des années, l'équipe a procédé de manière traditionnelle : embaucher des traducteurs humains professionnels, gérer des fichiers de glossaire et coordonner les mises à jour dans toutes les langues à chaque publication. À chaque fois, ils devaient réexpliquer le produit, la terminologie et les attentes depuis le début. Le coût variait de 1 000 $ à 8 000 $ par publication.

Ils ont essayé des alternatives : le crowdsourcing, les flux de travail automatisés et les modèles hybrides. Rien n'a résolu le problème.

Depuis le passage à PTC, les publications sortent à temps. Les traductions sont complètes, précises et cohérentes dans les 23 langues, sans gel des chaînes, sans surcharge de coordination et sans retards.

Avant PTC

Après PTC

Commencez à localiser votre logiciel dès aujourd'hui

L'essai de PTC couvre vos 20 000 premiers mots dans 2 langues. La prise en main prend moins de 5 minutes.

Commencez votre essai