Maîtriser la traduction (i18n) dans un projet web - Partie 2 : Conseils pour une localisation gérable et évolutive

Dans la partie 1, nous nous sommes concentrés sur la mise en place d'une base solide pour la gestion des traductions dans un projet Vue. Maintenant que votre système de traduction est opérationnel, il est temps d'examiner de plus près comment structurer, gérer et faire évoluer vos fichiers de traduction de manière efficace.

Cette partie couvrira les bonnes pratiques que nous utilisons chez Wanadev pour créer des clés de traduction maintenables, éviter les pièges courants et garantir que vos fichiers de traduction restent propres et évolutifs au fur et à mesure que votre projet grandit.

Vous lisez actuellement la 2ème partie de cet article, la 1ère partie est disponible sur notre blog à cette adresse.

Structure des fichiers de traduction

Évitez les structures de traduction imbriquées, qui compliquent la recherche et la mise à jour. Utilisez plutôt des clés de traduction à plat avec des noms descriptifs. L’avantage d’une structure de traduction aplatie est qu’elle améliore considérablement la recherche dans un IDE. Avec une structure imbriquée, chercher une clé comme "patient.profile.context" ne donne aucun résultat direct, rendant plus difficile la localisation et la mise à jour des traductions. En revanche, avec une structure plate et des clés comme "patient_profile_context", on trouve immédiatement la traduction correspondante.

Ce simple avantage permet de gagner du temps, réduit la frustration et améliore la maintenabilité, surtout dans les projets de grande envergure où les recherches rapides sont essentielles.

❌ Évitez ce code imbriqué :

{
  "patient": {
"profile": {
"context": "Contexte",
        "job": "Profession"
}
  },
  "lifeguard": {
    "flag": {
        "reason": {
            "pollution_start: "Pollution"
},
"red": "Rouge"
}
   }  
}

}

✅ Préférez plutôt une version plus lisible :

{
"patient_profile_context": "Contexte",

    "patient_profile_job": "Profession",

    "lifeguard_flag_reason_pollution": "Pollution",

    "lifeguard_flag_red": "Rouge",
}

Clés de traduction

Dans le cas où il y a plusieurs mots, nous utilisons le snake_case pour les clés. Cela rend la phrase plus facile à lire et vous permet de sélectionner la clé entière en double-cliquant dessus.

❌ Mauvais exemple (vous ne pouvez pas copier la clé en double-cliquant dessus) :

{
"project-name": "Nom du project",
}

✅ Mieux :

{
"project_name": "Nom du project",
}

Le fait de rendre les clés de traduction trop compliquées les rend non réutilisables et difficiles à maintenir. On pourrait penser que c’est une bonne idée d’ajouter du contexte dans les clés de traduction, mais avec le temps, ce contexte pourra évoluer avec le besoin métier, et vous ne renommerez pas la clé, ce qui engendrera de la confusion sur le sens de cette dernière. Les mots simples doivent avoir des clés simples. Améliorons la traduction de l'exemple précédent.

❌ Ce que nous avons :

{
"patient_profile_context": "Contexte",

    "patient_profile_job": "Profession",

    "lifeguard_flag_reason_pollution": "Pollution",

    "lifeguard_flag_red": "Rouge",
}

✅ Ce que nous devrions avoir :

{
"context": "Contexte",

    "job": "Profession",

    "pollution": "Pollution",

    "red": "Rouge",
}

Ponctuation finale

Une autre fausse bonne idée serait de ne pas ajouter les signes de ponctuation à la fin de la traduction pour la garder réutilisable, par exemple :

Peut être réutilisé :

{
"question": "Question"
}

Moins susceptible d'être réutilisé :

{
"question": "Question?",
}

Le problème avec cette approche, c'est que la ponctuation fait partie intégrante de la langue. Par exemple, en anglais, on écrit Question?, tandis qu'en français, l'espace avant le point d'interrogation est obligatoire : Question ?, et en espagnol, on ajoute un point d'interrogation inversé : ¿Cuestión?. Il vaut mieux dupliquer une traduction avec la ponctuation appropriée pour chaque langue plutôt que de risquer des erreurs de mise en forme ou de compréhension.

✅ C'est pourquoi nous incluons la ponctuation dans nos traductions :

{
"question": "Question?",
}

Pluralisation

Si vous avez besoin de formes singulières et plurielles, vous pouvez utiliser un séparateur pipe |. Les traductions ressembleront à ceci :

{
"product": "Produit | Produits"
}

En l'utilisant dans le code, cela donne :

<span>{{ $t('product', 1) }}</span>// Produit

<span>{{ $t('product', 1000) }}</span>// Produits

Lors de la gestion de la localisation, il est important de noter que certaines langues, en particulier les langues slaves comme le russe ou le polonais, ont des règles de pluralisation plus complexes que le simple singulier et pluriel. Par exemple, en russe, «1 produit», «2 produits» et «5 produits» nécessitent chacun une forme différente. Il peut être nécessaire de définir une fonction de pluralisation personnalisée. Vous pouvez en apprendre davantage sur la personnalisation des règles de pluralisation dans Vue I18n ici : Pluralisation personnalisée.

Listes

Comment traiter les traductions de listes quand elles ont un style complexe ? Vous ne pouvez pas vraiment inclure de style dans votre traduction, à moins de vous exposer à la faille XSS.

L'une des solutions serait d'avoir 3 traductions séparées. Mais ce n'est pas idéal.

❌ Pas de lien entre les traductions de la même liste :

{
"one": "one",

"two": "two",

"three": "three"
}

❌ Clés trop complexes :

{
"question_one": "one",

"question_two": "two",

"question_three": "three"
}

✅ Pour surmonter ces limitations, la meilleure approche reste l'utilisation d'un tableau :

{
questions: [

"one",

"two",

"three"
}

Vous pouvez ainsi styliser vos listes avec du CSS ou TailwindCSS comme dans notre exemple :

<ul class="list-inside list-disc">

<li>{{ $t('questions[0]') }}</li>

<li>{{ $t('questions[1]') }}</li>

<li>{{ $t('questions[2]') }}</li>
</ul>

Fournir aux clients un accès aux traductions

Pour faciliter la mise à jour des traductions par un tiers, vous pouvez utiliser des outils comme POEditor, qui permettent aux clients de modifier directement les traductions, sans intervention du développeur, avec une interface soignée et intuitive. Ces modifications peuvent être intégrées à votre processus Git et fusionnées via API, améliorant ainsi la collaboration.

Conclusion

Si vous choisissez de suivre ces conseils, vous pouvez vous assurer que votre configuration de traduction restera maintenable et évolutive au fur à mesure que votre projet évolue. Des conventions de nommage de clés claires, une gestion appropriée de la ponctuation et l'utilisation de l'automatisation pour le tri et le nettoyage des fichiers de traduction feront gagner du temps à votre équipe et réduiront le risque d'erreurs. De plus, fournir aux clients des outils comme POEditor pour modifier directement les traductions peut favoriser une meilleure collaboration et simplifier le processus de traduction.

J'espère que ces informations vous aideront à être bien équipé pour construire une application multilingue robuste qui peut croître avec les besoins de vos utilisateurs.

La 1ère partie de cet article est disponible ici.

Découvrez le quotidien d'Aleksandr (Sasha), Développeur web chez WanadevDigital dans son article "Dans les coulisses" disponible sur notre blog.