Éviter les textes en dur dans le code

[SpaceFox]

L'idée est de centraliser les différents textes de l'application dans un fichier d'internationalisation, ne serait-ce que pour en avoir éparpillés dans tous les fichiers.

Je ne sais pas quelle est la solution standard de Django à ce sujet, en particulier avec les textes qui sont directement dans les templates.

Je suppose que ce n'est pas super compliqué, mais très long à faire.

[firm1]

Le truc avec la pratique de l'internationalisation en django c'est qu'il conserve toujours le texte en dur dans le code. Car il se base sur babel qui lui utilise des fichier .po donc le principe c'est de faire le lien entre une chaine dans la langue "de dev" et la chaine dans la langue "traduite".

Et donc dans le .po tu auras certes les chaines en Français, mais vu que c'est aussi la clé de traduction, il faudra les retrouver dans tes fichiers python, car c'est la bas qu'il faudra les traduire.

Je ne sais pas si c'est possible d'avoir des fichiers de traductions avec comme clé un simple id. ça serait cool.

[SpaceFox]

Juste un ID, ce serait illisible.

Ou alors un "ID", genre FORUM_TITLE ?

[firm1]

Oui, comme ruby

[Alex-D]

Heu, langue de dev = clé : non. Imagine, y a une faute faut aller rechanger partout \o/

Et sinon, +1 pour les labels. "FORUM_TITLE", "HOME", "TUTORIAL_VALIDATE" ça me semble cool comme nommage.

[firm1]

Heu, langue de dev = clé : non. Imagine, y a une faute faut aller rechanger partout \o/

C'est bien ce que je dis, c'est le comportement de l'i18n de django, qui se base sur getttext.

[geoffreyc]

Ce comportement est tellement chiant, Magento fait ca aussi, a chaque fois
qu'une typo est corrigé dans la langue d'origine, il faut se taper tout les
fichiers de traduction.

2014-05-21 16:55 GMT+01:00 firm1 notifications@github.com:

Heu, langue de dev = clé : non. Imagine, y a une faute faut aller
rechanger partout \o/

C'est bien ce que je dis, c'est le comportement de l'i18n de django, qui
se base sur getttext.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/523#issuecomment-43775453
.

[Alex-D]

Par contre, si cela doit être fait, merci de se baser sur la branche intégration. Autrement, il sera impossible de merger les templates et une grosse part du travail sera perdue.

[Alex-D]

Je viens de voir que c'était en V2 (donc après la V1) et donc le problème ne se posera pas...

Désolé pour le flood :/

[SpaceFox]

Ouais, "le texte anglais c'est les clés de trad", c'est génial pour garder
le code lisible... et absolument horrible pour la maintenance.

2014-05-21 17:59 GMT+02:00 DEMODE Alexandre notifications@github.com:

Je viens de voir que c'était en V2 (donc après la V1) et donc le problème
ne se posera pas...

Désolé pour le flood :/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/523#issuecomment-43776142
.

[Taluu]

clé = un vrai label ? C'est encore plus pourrii. C'était cool à l'époque ou on se bouffait de la donnée, mais autant utiliser gettext et son standard, qui utilise des vraies phrases...

Bref, autant je suis pour le fait de tout rassembler dans un / des fichiers de lang, autant je suis contre l'utilisation des ID à la con, car on sait pas forcément à quoi correspond quoi.

[Alex-D]

@Taluu tu peux me rappeler comment fonctionne Sf2 please ? :-°

Si les labels sont bien faits, on s'y retrouve.

[Eskimon]

Vous avez jamais entendu parler des fonctions de remplacement ? En cas de fautes à corriger ca prend deux secondes hein... Et ca vous fait gagner des templates clairement lisible sans avoir à sortir des ID alakon (oui parce qu'arrive un moment pour avoir des ID uniques ca devient galère...)

[Alex-D]

J'ai déjà eu à le faire, si tu scope bien, tu peux t'y retrouve quasi au simplement qu'avec les vraies phrases :)

Après, je pige pas l'intérêt d'avoir la phrase en dur alors que dans notre cas on veut centraliser toutes les phrases dans un/des fichier(s) principal/aux. Du coup, si on met la phrase, on change rien pour finir, donc ça n'a strictement aucun intérêt vu le but initial.

Sauf si vous retrouver avec

"Demader la validaton": "Demander la validation" (suite à un fix de typo)

ne vous dérange pas.

[SpaceFox]

C'est clair qu'avec "Clé de trad" = "langue par défaut", le principal
intérêt par rapport aux textes en dur c'est qu'on oublie moins facilement
les corrections si un texte est à corriger 2x ou plus dans le code.

Par contre, le remplacement est obligatoire, puisqu'à la moindre faute, il
faut la corriger à au moins 3 endroits différents : utilisation de la clé,
définition de la clé, "traduction" de la clé.

Du coup j'ai envie de dire, si on part là-dessus, autant garder les textes
en dur tant qu'on est mono-lingue.

Le 21 mai 2014 18:17, DEMODE Alexandre notifications@github.com a écrit :

J'ai déjà eu à le faire, si tu scope bien, tu peux t'y retrouve quasi au
simplement qu'avec les vraies phrases :)

Après, je pige pas l'intérêt d'avoir la phrase en dur alors que dans notre
cas on veut centraliser toutes les phrases dans un/des fichier(s)
principal/aux. Du coup, si on met la phrase, on change rien pour finir,
donc ça n'a strictement aucun intérêt vu le but initial.

Sauf si vous retrouver avec

"Demader la validaton": "Demander la validation" (suite à un fix de typo)

ne vous dérange pas.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/523#issuecomment-43779118
.

[Taluu]

@Alex-D : je m'en fous j'utilise aps le composant de traduction de Sf. Je préfère 1000 fois gettext, que je trouve mille fois plus maintenable (une recherche / remplacer, ca prend 10 secondes)

J'ai déjà eu à maintenir des clés de trads avec des ID, et être obligé de retourner 50 fois dans les différents fichiers pour savoir à quoi ca correspond, bonjour la maintenance...

[SpaceFox]

En fait en y réfléchissant ça dépend de l'application.

L'utilisation d'ID est très intéressante surtout quand ce ne sont pas les
développeurs qui font les traductions, pour 2 raisons :

1. Quand tu vois ProductPage_ProductTitle dans ta page, tu vois tout de
   suite qu'une traduction manque ; alors qu'avec un texte anglais le problème
   est moins "visuellement immédiat"
2. Ça évite de se retrouver avec des trucs incompréhensibles, du genre
   "Acheter cette tasse" (clé) = "Commander ce mug" (trad, dans la même
   langue) - et je ne parle pas des risques de collision, du style tu as une
   autre clé "Commander ce mug" dans ton code...

Mais comme tout ce qui est arbitraire, tu dois gérer tes IDs de manière
très claire sans quoi oui, c'est l'horreur.

Le 21 mai 2014 18:25, Baptiste Clavié notifications@github.com a écrit :

@Alex-D https://github.com/Alex-D : je m'en fous j'utilise aps le
composant de traduction de Sf. Je préfère 1000 fois gettext, que je trouve
mille fois plus maintenable (une recherche / remplacer, ca prend 10
secondes)

J'ai déjà eu à maintenir des clés de trads avec des ID, et être obligé de
retourner 50 fois dans les différents fichiers pour savoir à quoi ca
correspond, bonjour la maintenance...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/523#issuecomment-43780359
.

[gustavi]

Ça le semble résolu non ? Avec le ZDS_APP et l'internationalisation.

[gustavi]

UP ! PING @firm1 tu confirmes que c'est résolu avec l'internationalisation ?

[firm1]

Résolu