Bonne Pratique
Pour le WEB
L'utilisation de motifs Markdown améliore la lisibilité et facilite la maintenance, tant pour le traducteur que pour vos scripts de site web qui en extrairont le contenu.
Pour les ancres nommées dans un site multilingue, une approche intéressante consiste à "
hard-coder
" les liens avec un design Markdown.
Ex: pour une balise
<h2/>avec une ancre
label-in-current-language
Les LLM sont plus efficaces que les humains pour protéger les liens, et
LSDE
vous permet de détecter les problèmes entre les différentes versions linguistiques.
Ainsi, vous pouvez partager un lien qui fonctionnera dans toutes les langues et utiliser
LSDE
pour gérer le remplacement d'une ancre dépréciée.
Ambiguïté du code
Évitez les ambiguïtés lorsque vous travaillez avec des modèles orientés données.
Exemple :
Mauvaise pratique :
Le terme 'key' n'est pas explicite et rend sa recherche difficile.
tsconst PRODUCTS: Product[] = [ { id: 'fcf7o', logo: '/icons/fcf7o-icon-40.webp', label: 'FCF7O', key: 'game:fcf7o.words.game_title', }, { id: 'lsde', logo: '/icons/lsde-icon-40.webp', label: '<c1>LSDE</c1>', key: 'software:lsde.name', }, { id: 'lsge', logo: '/icons/lsge.webp', label: 'LSGE', key: 'software:lsge.name', }, ];
Bonne pratique :
Adoptez une convention unique et cohérente.
Le terme
i18nKey
est très explicite et permet une recherche précise de cette valeur via des expressions régulières (
Regex
).
tsconst PRODUCTS: Product[] = [ { id: 'fcf7o', logo: '/icons/fcf7o-icon-40.webp', label: 'FCF7O', i18nKey: 'game:fcf7o.words.game_title', }, { id: 'lsde', logo: '/icons/lsde-icon-40.webp', label: '<c1>LSDE</c1>', i18nKey: 'software:lsde.name', }, { id: 'lsge', logo: '/icons/lsge.webp', label: 'LSGE', i18nKey: 'software:lsge.name', }, ];
Paresse
Les mauvaises idées naissent de la paresse.
Ne cherchez pas à économiser des clés en effectuant des opérations pour récupérer du contenu.
Exemple :
javascriptconst [title, subtitle] = t( 'game:game.title' ).split( /[::]/ );
C'est une fausse bonne idée, car dans certaines langues, les caractères peuvent varier et l'ordre des mots peut changer.
Format des balises
Réduisez au maximum le code destiné au design directement dans le texte, afin de le contrôler depuis le codebase.
Par exemple, vous pouvez indiquer l'emplacement d'une image, mais pas son style ou la manière dont elle doit être rendue.
Si vous devez apporter des modifications de design, vous ne voulez pas être contraint de retraduire un texte dans 10 langues juste pour changer le style d'une balise !
Les balises peuvent inclure un identifiant, mais ajouter des informations supplémentaires est généralement fortement déconseillé et constitue une mauvaise pratique.
Exemple : Ne faites pas
<img src='url' left />mais plutôt
<img id=1 />Vous récupérerez ensuite l'ID de la balise image pour lui appliquer les styles nécessaires dans le codebase.
Les ID doivent être utilisés littéralement et non via leur index.
En effet, dans différentes langues, les balises pourraient être déplacées et ne plus correspondre à l'index initial.
L'utilisation d'index naturels introduit également de la complexité pour le développeur ; essayer de deviner à quel index l'image ou la balise correspond est un véritable casse-tête.
Utilisez donc des balises avec un identifiant lorsque vous souhaitez pouvoir les personnaliser après interpolation.
CSS
Pour la traduction d'un site, lorsque vous avez des paragraphes, optez pour une hauteur minimale (`min-height`) après traduction afin d'éviter les décalages visuels lors des changements de langue.
Ex: `mih={'3lh'}`
Cela vous permet de définir une hauteur minimale basée sur la langue qui occupe le plus de lignes, garantissant ainsi une expérience utilisateur (UX) cohérente et sobre.
Namespace
Incluez toujours les 'namespace' dans vos clés de traduction, même si vous n'en avez qu'un seul.
Cela facilite grandement la mise en place d'un motif Regex pour retrouver vos clés.
Ex:
game:a.b.c,
common:a.b.c