Découvrez les meilleures pratiques de localisation de logiciels : préparez le code, gérez le contenu dynamique et créez des mises en page d’interface utilisateur flexibles pour les marchés mondiaux. Guide complet avec des exemples et un outil de traduction gratuit.
Votre application vient d’être lancée en France. Le trafic est en hausse, les inscriptions affluent, et puis les tickets de support commencent à inonder votre boîte de réception. Les utilisateurs ne peuvent pas cliquer sur le bouton « Acheter maintenant » parce qu’il a été coupé. Les formulaires ne sont pas envoyés. Les menus de navigation se cassent sur deux lignes. Votre interface utilisateur soigneusement conçue semble complètement cassée.
Voilà ce qui arrive lorsque vous sautez le processus de localisation de logiciels et passez directement à la traduction. Le texte est traduit, mais votre application n’a pas été conçue pour le gérer.
Voici à quoi pourrait ressembler le problème :
La raison ? Parce que votre code ressemble à ceci :
<button style="width: 120px">Save Changes</button>Ce guide vous explique exactement ce qu’il faut faire avant de traduire une seule chaîne de caractères. Vous apprendrez comment :
- Utilisez des fichiers séparés pour le contenu localisable
- Gérez les espaces réservés et le contenu dynamique
- Préparez l’interface utilisateur pour l’expansion du texte
- Chargez la bonne langue pour vos utilisateurs
- Mettez en place des traductions automatisées
À la fin, vous saurez comment livrer des logiciels localisés qui fonctionnent réellement, et pas seulement des logiciels qui ont été traduits.
Étape 1 : Commencez à utiliser des fichiers séparés pour le contenu localisable
Voici ce qui se passe lorsque vous codez en dur des chaînes de caractères : les outils de traduction analysent votre base de code à la recherche de texte à traduire dans des fichiers de ressources comme JSON, PO ou YAML. Ils ne trouvent… rien. Parce qu’ils ne peuvent pas détecter les chaînes de caractères enfouies dans vos fichiers JavaScript, PHP ou Ruby.
C’est l’erreur la plus courante dans la localisation de logiciels. La plupart des projets de localisation échoués meurent ici parce que les équipes réalisent trop tard qu’elles doivent refactoriser des milliers de chaînes de caractères codées en dur.
Qu’est-ce qui est considéré comme du texte visible par l’utilisateur ?
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/confirmation
Tout cela doit être placé dans des fichiers séparés.
Exemple React :
// Wrong - hard-coded
<button>Submit</button>
// Right - using react-intl
<button>{t('submit_button')}</button>
Exemple WordPress :
// Wrong - hard-coded
echo 'Submit';
// Right - using WordPress i18n
echo __( 'Submit', 'your-textdomain' );
Exemple Rails :
# Wrong - hard-coded
flash[:notice] = "Profile updated successfully"
# Right - using Rails I18n
flash[:notice] = t('profile.update_success')
Quel format de fichier devez-vous utiliser ?
Sélectionnez le format de fichier de ressources en fonction de votre framework :
- .
json– Frameworks JavaScript (React, Vue, Angular) .po/.pot– WordPress, PHP, Python (gettext).yaml/.yml– Ruby on Rails.xml– Android (strings.xml).xcstrings– iOS/macOS
Étape 2 : Gérez correctement les espaces réservés et le contenu dynamique
Lorsque vous incluez des données utilisateur dans des chaînes de caractères, comme des noms, des chiffres ou des dates, n’utilisez pas la concaténation de chaînes.
Différentes langues ont des ordres de mots différents. La concaténation brise cela en divisant les phrases en fragments qui ne peuvent pas être réorganisés.
L’exemple ci-dessous crée trois éléments distincts que les traducteurs ne peuvent pas réorganiser. Dans les langues comme le japonais où l’ordre des mots diffère de l’anglais, la traduction devient grammaticalement incorrecte.
Exemple incorrect (concaténation de chaînes)
const name = 'John';
const message = 'Hello, ' + name + '!';Utilisez plutôt des espaces réservés qui permettent aux traducteurs de contrôler la phrase complète :
Exemples corrects
Fichier PO :
msgid "Hello, %s!"
msgstr ""Fichier JSON :
{
"greeting": "Hello, {name}!"
}Fichier YAML :
greeting: "Hello, %{name}!"Assurez-vous d’utiliser une syntaxe de placeholder qui fonctionne avec votre framework :
| Format de fichier | Syntaxe courante des placeholders | Utilisé dans |
|---|---|---|
.json | {name} | JavaScript (React, Vue) |
.yaml | %{name} | Ruby on rails |
.po | %s, %d, %1$s, %2$d | WordPress, PHP |
.xml | %1$s, %2$d | Android |
.strings | %@, %d, %f | iOS/macOS |
Étape 3 : Concevez pour l’expansion du texte
Vous vous souvenez de ce bouton de l’introduction ? Celui qui disait « Save » en anglais mais qui a été coupé en français ?
C’est l’expansion du texte, et ce n’est pas rare. Voici à quoi vous êtes confronté :
- Le texte allemand est généralement 30 % plus long que l’anglais
- Le français est environ 20 % plus long
- Le chinois et le japonais sont souvent plus courts (mais ont d’autres problèmes)
Ce sont des moyennes, et les mots individuels peuvent gonfler. « FAQ » devient « Preguntas frecuentes » en espagnol, soit une expansion de 567 %.
Avant de commencer à coder, réfléchissez à l’impact des différentes langues sur l’espace pendant la phase de conception. Utilisez des modèles flexibles, afin que les boutons puissent grandir avec le texte au lieu d’être coupés. Cela permet de gagner du temps lors du débogage des problèmes de mise en page.
Pour un examen plus approfondi des modèles de mise en page, consultez comment éviter les problèmes de mise en page avec les longues traductions.
Étape 4 : Rédigez un contenu qui soit réellement traduisible
Votre style d’écriture compte plus que vous ne le pensez. Un anglais vague, intelligent ou idiomatique peut devenir absurde dans d’autres langues.
✓ Rédigez des phrases complètes
Une chaîne de caractères comme « No cart items » pourrait signifier plusieurs choses. Il n’y a pas de panier ? Les articles ne sont pas dans le panier ? Votre traducteur (ou outil de traduction) doit deviner.
Un sujet clair avec un verbe clair rend le sens clair, ce qui rend également la chaîne de caractères facile à traduire.
Exemple correct
"You have no saved items in your cart."
Cela indique clairement ce qui est vide (panier) et ce qu’il devrait contenir (éléments enregistrés).
Évitez les expressions idiomatiques
« This is a piece of cake » est souvent utilisé en anglais, mais ne se traduit pas bien dans d’autres langues. Si elle est traduite littéralement, vos utilisateurs allemands seront très confus quant à la raison pour laquelle votre application parle de dessert.
Faites simple
Ne dites pas « éliminer » quand « supprimer » fonctionne. Ne dites pas « utiliser » quand vous pouvez dire « utiliser ». Les mots simples se traduisent plus facilement et plus clairement.
Étape 5 : Configurez la détection de la langue
Une fois que vos chaînes de caractères sont externalisées et que votre interface utilisateur est flexible, vous devez détecter quelle langue afficher à chaque utilisateur.
La plupart des frameworks incluent des bibliothèques i18n qui gèrent cela automatiquement :
- React avec react-i18next
Installez react-i18next avec npm, puis configurez-le pour détecter la langue du navigateur et charger vos fichiers de traduction.
- Ruby on rails
Rails inclut I18n par défaut. Configurez-le dans config/application.rb. Ensuite, détectez la langue de l’utilisateur dans votre ApplicationController.
- WordPress
WordPress gère automatiquement la détection de la langue. Les utilisateurs définissent la langue de leur site dans Réglages → Général, et WordPress charge le fichier .mo correspondant à partir de wp-content/languages/. Pour les sites multilingues où différents utilisateurs ont besoin de langues différentes, vous aurez besoin d’une extension comme WPML pour gérer la sélection de la langue par utilisateur.
Définir une langue de repli
Définissez votre langue de repli sur votre langue principale. Lorsqu’un fichier de traduction n’existe pas ou que des chaînes sont manquantes, les utilisateurs voient le repli au lieu du texte cassé ou des clés de traduction.
Ajouter un sélecteur de langue (si nécessaire)
La plupart des applications doivent respecter automatiquement les paramètres de langue du navigateur ou de l’appareil de l’utilisateur. Mais si vous voulez permettre aux utilisateurs de remplacer cela manuellement (courant pour les applications Web), ajoutez un sélecteur de langue et stockez leur choix :
// Save user's manual language selection
localStorage.setItem('userLanguage', selectedLanguage);
// Check for manual selection first, then use browser default
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;
Les applications mobiles n’incluent généralement pas de sélecteurs de langue, car les utilisateurs s’attendent à ce que les applications suivent les paramètres de leur appareil.
Étape 6 : Automatisez votre processus de traduction de logiciels
Si votre processus de localisation ressemble à ceci, vous vous y prenez mal :
- Exporter les chaînes de caractères vers une feuille de calcul
- Envoyer la feuille de calcul au traducteur par e-mail
- Attendre 3 jours
- Récupérer la feuille de calcul
- Copier manuellement les traductions dans des fichiers JSON
- Découvrir que vous avez oublié 12 chaînes de caractères
- Répéter
C’est lent, sujet aux erreurs et ne s’adapte pas.
Voici ce que vous devriez faire à la place : utilisez un outil de traduction qui fournit une localisation continue.
PTC est un outil de traduction IA qui automatise le processus de traduction. Vous pouvez l’intégrer à votre référentiel GitHub, GitLab ou Bitbucket, ou utiliser l’API pour l’intégration CI/CD. Lorsque vous mettez à jour des chaînes de caractères, les traductions se font automatiquement.
C’est gratuit pour 20 000 mots en 2 langues, puis vous ne payez que ce que vous traduisez. Pas d’abonnement, et la mise en route prend moins de 5 minutes.
Étape 7 : Testez les versions localisées avant le lancement
Vous ne devez pas vous contenter de vérifier si le texte traduit s’affiche. Testez la fonctionnalité réelle dans chaque langue.
- Mise en page : Le texte tient-il sans être coupé ? La navigation fonctionne-t-elle toujours, ou voyez-vous un dépassement ?
- Fonctionnalité : Les formulaires sont-ils envoyés ? Les messages d’erreur s’affichent-ils dans la bonne langue ? La recherche gère-t-elle les caractères accentués (é, ñ, ü) ?
- Mise en forme : Les dates sont-elles dans le bon format (JJ/MM vs MM/JJ) ? Les nombres sont-ils formatés correctement (1 000,00 vs 1.000,00) ? La devise est-elle dans la bonne position (100 € vs €100) ?
Testez cela avant de passer à la production. Découvrir que votre flux de paiement allemand est cassé lorsque les utilisateurs commencent à laisser des commentaires négatifs n’est pas la façon dont vous voulez découvrir les bogues de localisation.
Vous êtes prêt pour la localisation de logiciels
C’est tout. Si vous avez fait ces 7 choses, votre application est prête pour la localisation. Traduisez maintenant vos fichiers de ressources avec PTC et livrez des logiciels qui fonctionnent dans toutes les langues.
Traduisez votre logiciel à l’aide de l’IA
Obtenez des traductions contextuelles en quelques minutes
Téléchargez des fichiers, ou automatisez via l’API ou l’intégration Git
1
Commencez un essai gratuit de 30 jours
Traduisez 20 000 mots gratuitement.
2
Ajoutez rapidement les détails du projet
Donnez du contexte sur votre application et vos utilisateurs.
3
Obtenez des traductions
Téléchargez un ZIP, ou fusionnez dans votre dépôt.
