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 de vrais exemples de code.

Votre application vient d'être lancée en France. Les inscriptions affluent, puis les tickets de support commencent à inonder votre boîte de réception. Les utilisateurs ne peuvent pas cliquer sur le bouton « Acheter maintenant » car il a été tronqué. Les menus de navigation se brisent sur deux lignes. Votre interface soigneusement conçue semble complètement cassée.

Voilà ce qui se produit 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 localisation, traduction et 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 aux paramètres régionaux et les tests
• Le coût de la localisation de logiciels
• Comment mettre en place un flux de travail de localisation qui ne se brise pas à chaque version

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 de texte. Cela signifie ajuster tout ce qui influence la façon dont les utilisateurs du marché cible vivent votre logiciel : les formats de date et de nombre, la devise, la mise en page de l'interface, les images et les références culturelles.

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

Voici un exemple qui montre comment une 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-le par les dates, les devises, les formats et les références culturelles, et vous commencez à percevoir 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 à des étapes différentes 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 parallèlement au développement. Voici un aperçu de la façon dont il se décompose généralement :

La plupart des équipes mènent le processus de l'une de ces trois manières :

1. Cascade La localisation commence après l'achèvement du développement. Vous terminez la construction, puis vous remettez tout pour traduction en un seul lot. C'est simple à gérer, mais cela retarde votre publication dans d'autres langues et rend la correction des bugs coûteuse à ce stade.
2. Localisation agile La localisation se déroule parallèlement au développement. Au lieu d'un seul grand lot à la fin, vous envoyez les chaînes pour traduction tout au long du cycle de développement. Le calendrier est meilleur, mais le processus reste manuel. Quelqu'un dans votre équipe doit exporter les chaînes, gérer les transferts 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 réintégrée automatiquement.

Bonnes pratiques de localisation de logiciels

Chaque projet est différent, et vos besoins en localisation dépendront de votre stack, 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 codez le texte en dur directement dans votre code source, les outils de traduction ne peuvent pas le trouver. Ces outils fonctionnent en analysant les fichiers de ressources comme JSON, PO ou YAML à la recherche de chaînes à traduire. Si votre texte est enfoui dans vos fichiers JavaScript, PHP ou Ruby, l'analyse revient vide.

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 tentent 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 visible par les utilisateurs dans des fichiers de ressources dédiés dès le départ. Cela inclut tout ce que vos utilisateurs peuvent voir :

• Les libellés, boutons et éléments de menu de l'interface
• Les messages d'erreur et le texte de validation
• Les modèles d'e-mail et les notifications
• Le texte d'aide, les infobulles et le texte d'espace réservé
• Les messages de réussite et de confirmation

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

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

React :

Avant

<button>Submit</button>

Après, avec react-intl

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

WordPress :

Avant

echo 'Submit';

Après, i18n WordPress

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

Ruby on Rails :

Avant

flash[:notice] = "Profile updated successfully"

Après, avec 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 à un traducteur exactement 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. Les clés descriptives permettent aussi à 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 assemblant des morceaux de texte dans votre code. Cela ne fonctionne pas 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 apparaît à une position différente dans la phrase. Vos traducteurs ne peuvent pas réorganiser les fragments, de sorte que la phrase finit 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 reçoivent la phrase complète sur laquelle 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 pour gérer un texte plus long

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

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

Les mots individuels peuvent s'étendre bien au-delà de ces moyennes. « FAQ » devient « Preguntas frecuentes » en espagnol - soit une augmentation de 567 %.

La solution consiste à construire des mises en page flexibles plutôt que fixes. Au lieu de définir une largeur fixe pour un bouton, laissez-le grandir avec son contenu :

Avant - une largeur fixe se brise dans les langues plus longues

button { width: 120px; }

Après - grandit avec le texte traduit

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

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

Rédigez un texte facile à traduire

La façon dont vous rédigez votre texte source influence 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 » pourrait signifier plusieurs choses. N'y a-t-il aucun article dans le panier ? Une recherche n'a-t-elle renvoyé aucun résultat ? Votre traducteur doit deviner, et une mauvaise supposition signifie une mauvaise traduction.

Rédigez 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 » a du sens pour un anglophone natif. Traduite 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 » au lieu de « eliminate » et « use » au lieu de « utilize ». 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 entre les paramètres régionaux. Coder ces formats en dur cause le même problème que coder le texte en dur : cela fonctionne sur un marché et se brise sur d'autres.

Utilisez les utilitaires de localisation intégrés de votre framework pour formater ceux-ci automatiquement en fonction des paramètres régionaux 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 paramètre régional que vous prenez en charge.

Planifiez pour les paramètres régionaux, pas seulement pour la langue

La langue et les paramètres régionaux 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 paramètres régionaux. Les différences entre eux 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 paramètre régional, vous risquez d'afficher le mauvais contenu aux utilisateurs de certaines régions.

Prenez le français comme exemple :

Lorsque vous configurez vos fichiers de langue, utilisez des codes de paramètres régionaux complets plutôt que des codes de langue seuls. Cela vous donne la flexibilité de servir un contenu différent à différentes régions sans avoir à 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, c'est la chaîne elle-même. Ils n'ont aucun moyen de savoir où elle apparaît dans l'interface, à quoi elle se réfère, ou de combien d'espace dispose la traduction.

Une chaîne comme « Cancel » pourrait se référer à l'annulation d'une commande, d'un abonnement ou d'une soumission de formulaire. Chacun de ces cas 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 montrant où ces chaînes apparaissent. Cela permet aux outils de traduction de produire des traductions nettement plus précises que lorsqu'ils travaillent à partir du texte seul.

Mettez en place la détection de la langue

Une fois que vos chaînes sont dans des fichiers de ressources et que votre interface 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 le repli au lieu d'une clé cassée comme auth.login_error.

Pour les applications web, vous pouvez aussi permettre aux utilisateurs de remplacer manuellement la langue détectée. Stockez leur choix afin 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 de sélecteur de langue. Les utilisateurs s'attendent à ce que les applications mobiles suivent les paramètres de leur appareil.

Mettez en place la détection de la langue

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

Un outil de localisation de logiciels gère l'ensemble du flux de travail à votre place. Un bon outil saura :

• 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 de la terminologie

PTC fait tout cela. De plus, vous pouvez traduire les 20 000 premiers mots dans 2 langues gratuitement, et la prise en main prend moins de 5 minutes.

Découvrez comment PTC gère la localisation logicielle

Testez chaque version localisée avant le lancement

La traduction n'est pas l'étape finale. Avant d'expédier une version localisée, testez-la de la même manière que vous testeriez toute autre version.

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

Fonctionnalité : Les formulaires se soumettent-ils 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 au bon format pour les paramètres régionaux ? Les nombres et les devises sont-ils correctement formatés ? Le symbole de la devise est-il à la bonne position ?

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

Intégrez les tests de localisation dans votre processus d'assurance qualité dès le départ. Découvrir un processus de paiement défectueux en allemand par le biais d'avis d'utilisateurs est nettement plus coûteux que de le détecter 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 de 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 changement de votre produit.

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

Après l'essai gratuit, PTC fonctionne selon un modèle Pay-As-You-Go. Vos 500 premiers mots chaque mois sont gratuits. Plus vous traduisez, plus votre tarif par 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 prix 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

Mettez en place votre processus de localisation de logiciels en 3 étapes

Les bonnes pratiques de localisation de logiciels ci-dessus couvrent beaucoup de terrain. Une partie, comme la rédaction de textes traduisibles ou la planification des paramètres régionaux, nécessite 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 changements de chaînes, la gestion des fichiers de traduction, le signalement des problèmes de longueur et le maintien de 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 gratuit, vous pouvez sélectionner 2 langues.

PTC génère automatiquement une description de votre application à partir du fichier téléversé. Examinez la description et conservez-la ou modifiez-la. Vous pouvez aussi 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 des chaînes individuelles manuellement ou d'ajouter des membres d'équipe pour gérer les relectures dans des langues spécifiques, vous pouvez effectuer une relecture de traduction par IA avec PTC.

PTC Visual QA va plus loin que le processus standard de relecture au niveau des chaînes en examinant votre interface 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 version

Ce que vous obtenez à la place :

• PTC relit visuellement votre interface 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 relue avant la publication, en quelques minutes plutôt qu'en quelques 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, soit utiliser l'extension de navigateur PTC Visual QA pour enregistrer les écrans à relire.

PTC analyse 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 ton incorrect 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 codées 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 à 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 voulez 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 expédiées en même temps que votre langue source.

Commencez à utiliser PTC gratuitement 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 version.

Pendant des années, l'équipe l'a fait de manière traditionnelle : embaucher des traducteurs humains professionnels, gérer des fichiers de glossaire et coordonner les mises à jour entre les langues pour chaque version. À chaque fois, ils devaient réexpliquer le produit, la terminologie et les attentes en repartant de zéro. Le coût variait de 1 000 $ à 8 000 $ par version.

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 versions 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

PTC est gratuit pour vos 20 000 premiers mots dans 2 langues. La prise en main prend moins de 5 minutes.

Commencer votre essai gratuit