Discussion :

[toham]

Bonjour tout le monde,

Sur une très grosse application, je dois mettre en place la gestion de l’internationalisation. Un collègue a déjà implémenter la majorité des tokens de traduction, cependant la sémantique des tokens utilisés ne me semble pas optimisés.

Ma question est simple, comment bien nommer mes tokens ? Avez-vous des bonnes pratiques ?

Mon collègue a tout centralisé dans le dossier app/Resources/translations, j'ai trouvé dommage de ne pas scindé par Bundle (environ une trentaine), cependant on retrouve forcément des traductions similaires (genre les boutons d'actions : valider, retour...) et du coup si on doit traduire ces boutons la, on doit se retaper toutes les traductions dans chaque bundle, perte de temps. Donc tout centraliser ne me dérange pas, il a réussi à me convaincre, mais je n'arrive pas à trouver la bonne syntaxe pour nommer mes tokens.

Voici quelques exemples :
alert.order.order.success : Message de retour lors de la prise de commande.
title.order : Titre de la page "Commander".
action.valid : Bouton "Valider"
word.group : Mots "Groupe" qui peut se trouver un peu n'importe où

Mais ça ne me plait pas tellement, j'aimerai trouver la syntaxe parfaite. Je suis un peu perdu et avant de reprendre le chantier du nommage de token, j'aimerai avoir quelques avis la dessus. On parle la d'une application assez énorme et j'aimerai pas me foirer sur ce petit détail.

Merci d'avance.

[Nico_F]

Hello,

Ça n'a pas vraiment de sens de chercher une norme "parfaite" pour tes clés de traduction, surtout si tu te diriges vers l'utilisation de l'emplacement du texte comme clé au lieu d'utiliser sa fonction. label.username est une meilleure clé que edit_form.label.username (voire inclure le bundle et le type de ficher pour certains : user.form_type.edit_form.label.username).

Travaillant également sur un gros projet, je peux te dire que nous avons commencé en utilisant cette mauvaise solution (norme par rapport à l'emplacement, au bundle etc.), elle devient vite impossible à gérer. Dès que tu as à faire du refactoring, tu es susceptible de déplacer ces clés de traduction ; deux possibilités s'offrent alors à toi :
1. Tu perds un temps précieux à faire un travail chronophage qui n'apporte aucune valeur en renommant toutes tes clés pour qu'elles correspondent à une norme établie arbitrairement et tu refais le même travail pour mettre à jour les traductions avec les nouvelles clés.
2. Tu ne modifies pas les clés de traduction, et tu te retrouves avec des clés qui ne correspondent plus à la syntaxe de départ par rapport au fichier dans lequel elles se trouvent (c'est ce qu'on s'est résigné à faire).

C'est (entre autre) pour ça que sur cette page http://symfony.com/doc/current/best_practices/i18n.html on recommande d'avoir des clés qui décrivent la fonction du texte et non l'emplacement.

Maintenant, si tu as déjà un paquet de clés de tard suivant une norme différente, n'y touche pas, laisse les comme elles sont ce n'est pas grave. Ce n'est pas du mauvais code, c'est du code utilisant une norme différente, et un projet (surtout un gros) ne pourra pas être homogène en tout point.

Dernier tip, je ne sais pas si vous avez déjà choisi un outil pour gérer vos traductions, mais avec le recul que nous avons, je pense que si c'était à refaire nous nous dirigerions vers une solution comme celle proposée par Happyr => http://developer.happyr.com/how-happ...y-translations, ils y décrivent également leur définition d'une "bonne clé de traduction".

Pas testé mais on aurait aimé tomber dessus plus tôt

Bonne chance,
++

[toham]

Merci Nico_F,

N'ayant jamais fait de trad sur Symfony jusqu'à présent, mon collègue m'a expliqué plus ou moins la même chose que toi. Donc comme tu le suggère, je ne vais rien touché à ce qui a été fait et quand j'aurai du temps à perdre, reprendre petit à petit, étant perfectionniste, ça m'agace quand tout n'est pas uniforme

Bref merci pour ces conseils.

[Nico_F]

Je suis (ou plutôt j'ai été) un peu comme toi : très pointilleux sur certaines choses, parfois des détails.
Et je sais qu'aucun conseil, aucune phrase ne pourra te faire changer ça parce que même avec le recul, tu sais que même si ça n'apporte pas de valeur, même si personne d'autre à part toi ne le verra, il faut que tu le fasses pour être serein.

N'empêche qu'avec un tout petit peu de recul, le temps passé à renommer tes clés de trad, réorganiser tes 'use' par ordre alphabétique et réaligner toutes les étoiles des phpdoc du projet, etc. pourrait être utiliser à des fins plus utiles comme l'écriture de tests ou ce genre de choses

Le jour ou tu bosses sur un projet de 100K lignes, tu ne peux plus te permettre de tout ré-homogénéiser à chaque changement de norme, de standard de quoique ce soit que tu fais.