Traduire le site

En fait pour préciser un peu plus. Voici les paramètres tels que je les vois mis à la disposition de l'administrateur du site.

1
2
3
4
5
6
7
8
9

# site en plusieurs langue ou pas
USE_L10N = True
# langue par defaut du site
LANGUAGE_CODE = 'fr-fr'
# langues proposées par le code source
LANGUAGES = (
('fr', _('Français')),
('en', _('Anglais')),
)

Si le premier paramètre est à False le site s'affiche uniquement dans la langue par défaut, sans les ajouts du choix de langue dans le footer (ça sera le cas de ZdS dans un premier temps). Si le premier paramètre est à True, hop tout les petits plus liés à la traduction seront visibles.

ça permet d'internationaliser le code (et donc de permettre à d'autre personne de l'utiliser dans d'autre langue) sans forcer les sites qui l'utilisent à passer au multilingue. Tout est bien décorrélé.

Ce que je reproche ici c'est de permettre cette option. C'est prématuré. Tu ne devrais permettre de ne choisir qu'une seule langue. Car la gestion d'un même site supportant plusieurs langues en même temps posent d'autres contraintes. Ça ne peut pas être fais facilement donc pourquoi rajouter cette option alors qu'elle sera inutilisable pendant très longtemps ? Il faudrait revoir tout le reste du site pour que ça marche correctement comme être capable de préciser la langue du contenu, etc.

Je pense que internationaliser le code était déjà un assez gros morceaux sans avoir besoin de rajouter une micro gestion de site multilingue qui ne sera pas utilisable.

Je ne suis pas convaincu que le paramètre standard Django USE_L10N soit prévu pour ça. La doc à ce sujet m'a l'air un peu bordélique… https://docs.djangoproject.com/en/1.6/topics/i18n/

Sinon pour moi tu ne peux pas avoir une "localisation générique" du site. Avec ton système, tu vas devoir forcer soit un "site multi-langue" avec toutes les ressources traduites, soit un "multi-site" avec les ressources différentes. Pour moi, c'est clairement un choix de développement qui ne peut pas se retrouver dans un logiciel.

J'entends pas là que la plateforme doit permettre les deux choix, mais chacun d'entre eux a des impacts majeurs : on ne peut donc pas faire quelque chose qui s'active ou non via un paramètre sans forcer l'un des deux choix.

D'autre part, et là je mets ma casquette de DTC : c'est génial que tu t'intéresses au sujet ; d'autant qu'on a besoin de l'internationalisation (support du site en français ou dans une autre langue).

Par contre je trouve dommage que tu tiennes autant à te lancer dans un développement inutile voir néfaste (cette histoire de sélection de langue pour l'utilisateur) alors qu'il y a encore des tonnes de trucs demandés, utiles et je pense plutôt intéressants à faire sur le site.

Après tu fais comme tu veux, je ne peux forcer personne. Mais je pense sincèrement que cette histoire de choix de langue pour l'utilisateur est une perte de temps.

Après tu fais comme tu veux, je ne peux forcer personne. Mais je pense sincèrement que cette histoire de choix de langue pour l'utilisateur est une perte de temps.

Il ne fait pas non plus comme il veut. Perso je ne vois pas de raison d'intégrer dans le code une "demi-option", ce que sera la possibilité du choix de la langue par l'utilisateur, puisque rien ne sera fait derrière. On rajoute pas une option si en réalité un des deux choix est inutilisable.

Dans ce sens là, je suis d'accord. Je partais sur l'hypothèse qu'il nous trouve une combine pour faire un choix de langue utilisateur générique utilisable Dans ce cas, la fonctionnalité est bien sûr acceptable sur le site… mais pas très utile.

Le truc c'est surtout que dans l'opensource, on ne sait pas qui (ni comment) le code va être utilisé. Il existe des pays qui sont plutôt bilingue (je pense au canada) ou encore des pays ou les gens parlent couramment plusieurs langues et/ou on a des déclinaisons de langues (anglais US vs anglais british) ou la langue du contenu importe peu par exemple (et qu'on peut gérer a coup de tag), mais qui aimeraient tout de même naviguer sur le site dans une langue précise.

Après mon exemple est un poil tiré par les cheveux, mais bon, dans ma philosophie de l'OpenSource, je préfère souvent donner trop que pas assez.

Après ma combobox dans le footer ne plait pas mais c'est pas très grave, au pire c'est quelques lignes de code à rajouter.

Indeed mais je suis ne pas fan des demi-fonctionnalités. La gestion d'un site multi-langue demande une vrai réflexion et beaucoup d'options sont envisageable. Je suis donc plutôt tenté d'attendre un vrai développement propre là dessus avant de mettre ça en place. D'autant que comme tu le dis, si vraiment quelqu'un veut proposer la combo-box avec le même contenu, il n'aura pas grand chose a faire pour cela.

En fait tout le problème est là :

Après mon exemple est un poil tiré par les cheveux, mais bon, dans ma philosophie de l'OpenSource, je préfère souvent donner trop que pas assez.

En ajoutant cette option, tu fermes des possibilités puisque tu contrains l'utilisateur dans un modèle qui ne lui convient pas forcément.

En ajoutant cette option, tu fermes des possibilités puisque tu contrains l'utilisateur dans un modèle qui ne lui convient pas forcément.

Là je n'ai pas compris. Les options sont justement là pour ne pas contraindre mais pour permettre d'utiliser si on veut.

Ben tu rajoutes une option qui ne correspond qu'à une partie des cas. Du coup soit tu la fais générique et ça te prends 10 ans à faire, soit elle ne sert à rien parce qu'elle est bancale.

Bon, fermons le HS.

J'ai noté que la combobox dans le footer ne plait pas. Donc ça ne sera pas developpé. Y'a autre chose ?

Hello tout le monde,

La décision ici est donc de supporter officiellement l'internationalisation sur Zeste de Savoir.

Concrètement, ça veut dire :

• Le code permet d'être utilisé dans une langue X ou Y
• Les éventuelles traductions sont non-officielles, sauf le français et peut-être (voir plus bas) l'anglais
• Le code source ne permet pas le multi-langue sur un seul site nativement¹

Donc si je reprends le code source du site, je peux facilement l'installer en FR, en EN, en WHATEVER si je fais la traduction – mais si je veux le site en 2+ langues je dois faire du développement.

Par contre, ceci soulève une question dont on avait déjà plus ou moins débattu :

Qu'est-ce que ça veut dire ? Aujourd'hui on a des textes en dur dans le code (python, templates, …). Ces textes vont être remplacés par des clés qui vont permettre de choisir la bonne traduction.

En gros, on a les possibilités suivantes :

1. Clé de trad = texte français. Super facile pour développer, super pratique pour nous, super chiant pour une éventuelle traduction, pas harmonieux avec le code qui est en anglais. Nous permet de n'avoir que le français en langue officielle.
2. Clé de trad = texte anglais. Classique, facile pour la traduction, cohérent avec le code, nous oblige à traduire tout en anglais. Nous oblige pratiquement à avoir l'anglais en langue officielle.
3. Clé de trad = machin technique (genre 123_SEND_BUTTON). Classique aussi, assez facile pour la traduction, évite les collisions de clés, on voit tout de suite s'il manque une clé de trad en front (ce qui est un avantage et un inconvénient), super chiant à gérer au jour le jour.
4. Une autre idée ?

Il faut choisir ces clés de trad avant de commencer à internationaliser.

Quel est votre avis ?

Pour moi, option 1 par élimination, car :

• l'option 2 : nous amène à tout traduire en anglais, et soyons sérieux deux secondes, c'est au dessus de nos moyens et ça ne sera jamais possible avec notre organisation.
• l'option 3 : il faut normaliser les clés, définir les normes, la documenter (nouvelle barrière à l'entrée pour le nouveau contributeur qui passe par là). Et en plus les templates risque de ressembler à une succession de clés (ce qui n'est pas pratique pour développer), on passe plus de temps à savoir quel est la signification de tel ou de tel clé, pire encore si je découvre le code pour la première fois. Bref, ça ressemble plus à de l'obfuscation de code comme on peut le faire en C avec des defines de partout.

Je citerai volontier ici la pep.

Yosh, et voilà la PR qui va bien

Quand vous parlez de traduire le site, c'est traduire son code (noms de fonctions, variables…, commentaires) ou le contenu ? Dans le premier cas, je ne comprends pas l'utilité.

Dans le premier cas, je ne comprends pas l'utilité.

Cela permettra à n'importe qui d'utiliser le code du site, qu'il soit français, anglais, polonais, russe, ou que sais-je encore. En écrivant du code en français et en le documentant/commentant en français, tu limites les personnes qui pourront réutiliser le code.

Mais si on code en anglais, ça devrait aller, non ?

C'est mettre l'interface du site traduisible pour que les personnes qui voudraient faire un autre site avec la même base puissent en faire un site anglais au lieu de français.

Donc c'est pas le code, mais le contenu, non ?

@Vayel : est-ce que tu as déjà regardé le code du site ? On dirait bien que non.

On code en anglais. On permet aux gens qui veulent faire un fork de traduire le contenu (== front) (cf http://zestedesavoir.com/forums/sujet/1095/un-zestmeeting/?page=5#p27789).

PS : Vayel est-ce que tu peux arrêter de poser des questions sans faire un minimum de recherches ?

C'est le contenu au sens interface. Ce n'est pas les articles ou tuto mais par exemple les chaines "aperçu" et "envoyer" des boutons sous la zone d'édition.

Le but est double :

• regrouper toutes les chaînes au même endroit pour faciliter leur gestion et corrections au lieu d'avoir des chaines en dur dans le code.
• permettre de traduire l'interface. Pas pour ce site mais pour d'autres qui voudraient se baser dessus notre code.

Ce n'est ni vraiment le code, ni le contenu c'est l'interface