Bonnes pratiques de localisation logicielle : 10 étapes avec des exemples

Ce guide vous accompagne tout au long du processus de localisation logicielle, du début à la fin, avec des meilleures pratiques et des exemples de code concrets.

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 est coupé. Les menus de navigation s’affichent sur deux lignes. Votre interface utilisateur, pourtant soigneusement conçue, 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 vos logiciels. Vous apprendrez :

Qu’est-ce que la localisation logicielle ?

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

L’objectif est de faire en sorte que votre logiciel donne 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 :

C’est un petit exemple de ce que gère la localisation logicielle. Multipliez cela par les dates, les devises, les formats et les références culturelles, et vous commencerez à voir l’ampleur du travail.

Localisation logicielle 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 logicielle

La localisation logicielle n’est pas une étape unique que vous terminez avant le lancement. C’est un processus continu qui accompagne le développement. Voici un aperçu de son déroulement habituel :

La plupart des équipes gèrent 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 la construction, puis vous transmettez tout pour traduction en un seul lot. C’est simple à gérer, mais cela retarde votre sortie 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 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 transmissions 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 automatiquement pour traduction. Lorsque la traduction est prête, elle est fusionnée automatiquement.

Meilleures pratiques de localisation logicielle

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 logicielle.

Lorsque vous codez du texte en dur directement dans votre code source, les outils de traduction ne peuvent pas le trouver. Ces outils fonctionnent en scannant des fichiers de ressources comme JSON, PO ou YAML pour y trouver des chaînes à traduire. Si votre texte est enfoui dans vos fichiers JavaScript, PHP ou Ruby, le scan 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 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 dans 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, info-bulles et placeholder
• 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 :

<button>Submit</button>

<button>Submit</button>

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

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

WordPress :

echo 'Submit';

echo 'Submit';

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

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

Ruby on Rails :

flash[:notice] = "Profile updated successfully"

flash[:notice] = "Profile updated successfully"

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

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 au 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 les chaînes qui ont été externalisées et de repérer celles qui manquent.

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 dans votre code. Cela ne fonctionne pas dans d’autres langues.

Voici pourquoi :

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

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 place à 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 placeholders résolvent ce problème en gardant la phrase entière. Vos traducteurs ou votre outil de traduction reçoivent la phrase complète, y compris un marqueur indiquant l’emplacement de la variable. Ils peuvent placer ce marqueur là où la grammaire de leur langue l’exige.

Voici à quoi ressemblent les placeholders dans différents formats de fichiers :

JSON :

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

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

YAML :

greeting: "Hello, %{name}!"

greeting: "Hello, %{name}!"

PO :

msgid "Hello, %s!"

msgid "Hello, %s!"

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

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

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

Certains mots peuvent s’étendre bien au-delà de ces moyennes. « FAQ » devient « Preguntas frecuentes » en espagnol — c’est une augmentation de 567 %.

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

button { width: 120px; }

button { width: 120px; }

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

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 plus tard, 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 de la flexibilité dès le départ.

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 » pourrait 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 signifie une mauvaise traduction.

Rédigez des phrases complètes avec un sujet et un verbe clairs.

"No items"

"No items"

"You have no items in your cart."

"You have no items in your cart."

Expressions idiomatiques

« This is a piece of cake » 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 « supprimer » au lieu d’« éliminer » et « utiliser » au lieu d’« utiliser ». En cas de doute, choisissez le mot le plus court et le plus courant.

Les formats de date et de nombre varient considérablement d’un pays à l’autre. Coder ces formats en dur cause le même problème que coder du texte en dur : cela fonctionne sur un marché et échoue sur d’autres.

Utilisez les utilitaires de localisation intégrés de votre framework pour formater ces éléments automatiquement en fonction des paramètres régionaux de l’utilisateur.

JavaScript :

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

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

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

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

Ruby on Rails :

"$#{price}"

"$#{price}"

number_to_currency(price, locale: I18n.locale)

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 supportez.

La langue et les paramètres régionaux ne sont pas la même chose. L’espagnol est une langue. L’espagnol du Mexique (es-MX), l’espagnol d’Espagne (es-ES) et l’espagnol d’Argentine (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ètres régionaux, vous risquez d’afficher le mauvais contenu aux utilisateurs de régions spécifiques.

Prenons l’exemple du français :

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 des contenus différents à des régions différentes sans avoir à restructurer votre configuration plus tard.

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 se réfère ou de quel espace dispose la traduction.

Une chaîne comme « Cancel » pourrait se référer à l’annulation d’une commande, d’un abonnement ou de l’envoi d’un 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 :

{
  // 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."
}

{
  // 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 uniquement à partir du texte.

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']
    }
  });

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

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 secours (fallback). Lorsqu’un fichier de traduction est manquant ou qu’une chaîne n’a pas encore été traduite, votre application affiche la langue de secours au lieu d’une clé cassée comme auth.login_error.

Pour les applications web, vous pouvez également laisser les utilisateurs outrepasser manuellement la langue détectée. Enregistrez 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;

// 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.

Un flux de travail de localisation manuel ressemble à 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 qu’il manque 12 chaînes et recommencer. Ce n’est pas évolutif.

Un outil de localisation logicielle gère l’ensemble du flux de travail pour vous. 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 centralisé 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 gratuitement les 20 000 premiers mots dans 2 langues, et la mise en route prend moins de 5 minutes.

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

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

Combien coûte la localisation logicielle ?

Une bonne localisation logicielle n’a pas besoin d’être coûteuse. Le facteur le plus important de votre budget n’est pas le nombre de langues que vous supportez. 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 de 15 000 mots, cela représente 1 500 $ à 4 500 $ par langue, avant de prendre en compte les tests, la gestion de projet ou les futures mises à jour à chaque modification de votre produit.

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

Après l’essai gratuit, PTC fonctionne sur un modèle de paiement à l’utilisation. Vos 500 premiers mots chaque mois sont gratuits. Plus vous traduisez, plus votre tarif par mot diminue, et une fois que vous atteignez un tarif inférieur, vous le conservez pendant trois mois même si votre volume baisse.

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

Configurez votre processus de localisation logicielle en 3 étapes

Les meilleures pratiques de localisation logicielle ci-dessus couvrent beaucoup de terrain. Certaines, comme la rédaction de textes traduisibles ou la planification des paramètres régionaux, 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 changements 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.

01

S’inscrire à PTC

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

Ensuite, ajoutez du contexte sur votre application : ce qu’elle fait et à qui elle s’adresse. C’est ce qui rend les traductions de PTC précises plutôt que génériques. Vous pouvez également 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.

PTC les traduit automatiquement, en appliquant votre contexte et votre glossaire à chaque chaîne. Toute la configuration prend moins de 5 minutes.

02

Visualisez et affinez les traductions

Une fois les traductions prêtes, examinez-les depuis votre tableau de bord. Vous pouvez modifier manuellement des chaînes individuelles ou ajouter des membres d’équipe pour gérer les révisions dans des langues spécifiques.

Si vous remarquez une traduction qui pourrait être améliorée, signalez-la et indiquez à PTC quel est le problème. PTC la retraduit gratuitement et applique ce qu’il a appris aux futures traductions de votre projet.

PTC vérifie également automatiquement la longueur de la traduction. Les chaînes qui pourraient être trop longues pour votre interface utilisateur sont surlignées en jaune. Vous pouvez demander à PTC de les retraduire pour qu’elles s’adaptent, ou ajuster les limites de longueur pour correspondre à ce que permet votre interface utilisateur.

Exemple de localisation logicielle : Traduire WPML avec PTC

WPML est l’une des extensions multilingues les plus utilisées pour WordPress. Le maintenir traduit dans 23 langues n’est pas facultatif. Cela fait partie de chaque version.

Pendant des années, l’équipe a procédé de manière traditionnelle : embauche de traducteurs humains professionnels, gestion de fichiers de glossaire et coordination des mises à jour dans toutes les langues pour chaque version. À chaque fois, ils devaient réexpliquer le produit, la terminologie et les attentes à partir de zéro. Le coût variait de 1 000 $ à 8 000 $ par version.

Ils ont essayé des alternatives : crowdsourcing, flux de travail automatisés et 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 frais de coordination et sans retard.

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 mise en route prend moins de 5 minutes.

Commencer votre essai gratuit