Traduire le site

Salut,

J'ai un peu hésité entre posté ici ou faire ZEP pour ma proposition, mais au final je me suis que ça vallait peut être le coup d'être discuté ici avant

Avec Eskimon, on a souhaiterai experimenter la création d'un site basé sur Zds, seulement on se trouve en face d'un petit problème. Le code contient du Français directement dans le code, or nous souhaiterions plutôt nous orienter vers un site en anglais, il y a donc 2 solutions possible.

• On fork le projet et on traduit tout, mais nous pourrons plus profiter de la branche principale du dévellopement actuelle, et c'est le niveau 0 d'un point de vue réutilisation plus tard.
• C'est au niveau de Zds de permettre cette possibilité en utilisant les outils de multi-langue de Django, le but n'étant pas de changer le site actuel mais juste, ouvrir cette voie dans le framework. Dans ce cas, nous profiterions de l'avancé du dévellopement.

Cependant ce deuxième point apporte une interrogation, est-il pertinent de modifier Zds, pour faciliter le dévellopement d'un autre site ? Sachant que dans le cas actuelle c'est seulement utile pour un projet, mais que sur le long terme cela peut être plus utile.

Autre problème, cela mobilisera du temps de dev, même si Eskimon et moi-même pouvons sûrement nous en occuper en partie, cela risque de poser des problèmes, modifier l'organisation du code.

Bref, je lance un débat pour savoir ce que vous en pensez, comment cela doit-il être mis en place, si on a le temps pour cela.

PS: En aucun cas, il est question de traduire le contenu du site, voir de traduction tout court, mais mettre en place le code nécessaire pour pouvoir le faire.

EDIT Eskimon : Voici le lien pour aider à la traduction via transifex : https://www.transifex.com/projects/p/zestedesavoir/

Ca avait discuté à une époque (ptet meme dans github) mais je sais plus ou

Il y a une issue sur Github, qui vise à rendre le code plus ouvert vers d'autres site (#1520). Peut-être que parler de la possibilité des langues multiples là-bas ne pourra pas être mal.

Pas vraiment : l'internationalisation est un problème à part entière.

Le problème c'est que quand on en avait discuté (il y a longtemps et je ne sais plus où) on s'était dit que le temps que quelqu'un veuille utiliser une version non-francophone de ZdS, on aurait le temps de voir venir, et que donc ce n'était pas la peine de se prendre la tête à gérer ça…

Donc aujourd'hui la politique de développement est "on s'en fiche, tout en français" donc on a plein de chaînes en dur dans le code.

Autrement dit, tout le boulot de d'internationalisation est à faire depuis 0. Il est tout à fait bienvenu dans le projet à mon avis, mais bon courage.

Faites un ticket, il n'y a aucun soucis la dessus. Pour autant j'ai peur que vous deviez faire le boulot vous même. Entre autre parce que on a pas des tonnes de dev en ce moment. Si l'un d'eux veux s'en occuper, tant mieux, mais dans l'absolu ça ne va être qu'une killer feature de plus a trainer dans les tickets !

Sinon on peut en savoir plis sur votre projet ?

Je laisse l'honneur a Tick d'en parler avec notamment toute la discussion cross-IRC qui a fait venir l’idée

_{Par contre Tick je t'ai prévenu je n'ai pas non plus masse de temps !!}

Au passage un bout de discussion sur la traduction : https://github.com/zestedesavoir/zds-site/issues/523

Bon au passage, il n'y a pas que internationalisation a mettre en place, ce serait peut être le bon moment pour commencer à commiter en anglais, voir de faire de même pour tickets et PR (ou on accepte les deux ?)

voir de faire de même pour tickets et PR (ou on accepte les deux ?)

Dans l'absolu c'est une bonne idée.

Mais très honnêtement, à titre personnel, ça me les briserait menu de devoir me taper les tickets et PR en anglais surtout quand il n'y a que des francophones autour.

C'est une question d'efficacité : si la réflexion se fait dans ma langue native, je ne suis pas limité par la langue. Et comme c'est déjà parfois assez compliqué de se mettre d'accord, je n'ose pas imaginer ce que ça peut donner avec des incompréhensions dues à la langue en plus.

On peut, au moins pour le moment, simplement "autoriser" les PR et tickets en anglais. Tout comme on devrait autoriser la traduction de la doc en anglais en plus du français. Mais rien ne nous oblige actuellement a tout traduire direct.

D'autant que j'imagine que si ce projet voit le jour, ils auront leur propre dépot qui lui pourra recevoir des PR en anglais, et qui aura aussi sûrement des tickets en anglais.

Mais en attendant on pourrait simplement assouplir la regle et autoriser les deux.

Là ça me va

Pour les messages de commits 100% en anglais, ça me va aussi : y'a pas de réflexions à y mettre et ils sont beaucoup moins critiques que les tickets / PR.

Bon donc je pense que Tick tu va avoir l'honneur d'ouvrir un ticket sur l’internationalisation du site !

Voilà https://github.com/zestedesavoir/zds-site/issues/1621

Micro-note quand même : loin de moi l'idée de vouloir jouer les donneurs de leçons tout ça, mais si un amateur passe par là un de ces 4 : l'i18n (internationalisation) il faut toujours essayer de l'intégrer au site le plus tôt possible (i.e. externaliser les messages dans des fichiers ne contenant que ces messages). Honnêtement, on croit toujours "bof on verra plus tard c'est chiant on n'a pas le temps), au final c'est QUE DALLE (ou quasi) à faire au début du projet, et ça fait gagner un TEMPS FOU si on l'a fait dès le début.

Bref, c'est pas grave ici, on va s'en sortir mais ça m'avait déjà interpellé pendant la bêta que les messages soient en dur dans le code. Pour le coup ça m'a énormément surpris de la part de l'équipe de dev de ZdS. Aller fouiller dans un template pour modifier un intitulé franchement tout le monde ici a déjà du se casser la tête et maudire une bonne centaine de développeurs pour le na pas avoir externalisé la gestion des messages, non ? :\

En fait la raison est dans ton message : ça n'a pas été fais dès le début. Dès le premier commit, qui était à la louche un fork de pdp, c’était déjà le cas. On avait déjà dépassé le cadre du "dès le début". Les discussion qui avaient eu lieu pendant la bêta concernaient déjà une étape de transition, qui a été choisi d’être repoussé, a tord ou a raison. On était pas dans la beta à une étape de conception. Et en fait dès le premier commit on ne l'etait pas puisqu'on partait d'une grosse base de code.

edit: pour étayer mon propos - le premier commit c'est 247 fichiers représentant 10,099 lignes de codes.

Bon vu que l'idée me plait bien et que ça va dans le sens de tout ce que j'aime (ouverture, multi compétence, partage ), je pense que je vais m'y coller. Pas forcément pour traduire mais pour poser les bases de l'internationalisation de tout le code du site. ça permettra à certaines personnes de mettre en pratique leurs compétences en traductions.

Voici ce que j'ai en tête (dites moi si ça vous parait viable) fonctionnellement.

• Au départ les bases seront posées uniquement pour l'anglais (les autres langues seront facilement ajoutable)
• Rajouter dans le footer du site un truc (je ne sais pas encore quoi) qui permet de choisir la langue dans laquelle on veut consulter le site
• Prévoir un paramètre au niveau du fichier de configuration du site (settings.py pour ceux qui connaissent) pour sélectionner la langue par défaut du site et les langues que proposera le site. Le code peut supporter plusieurs langues, mais le site qui utilise le code ne veut pas forcément proposer toutes les langues disponibles.
• Rajouter dans le footer aussi un lien vers une page appelée "Contribuer au site" avec un mini résumé sur les différentes manières de contribuer a site (Au niveau du contenu, au niveau du code, au niveau de la traduction du site, etc.) en précisant les compétences nécessaires pour chacune des taches. Sur la page en question à la fin des mini-résumés, un lien qui pointe vers une doc/tuto qui explicite mieux.
• Rajouter dans le readme du projet un paragraphe sur "comment proposer une traduction du site" avec son détails dans la documentation en ligne

Voilà comment a première vu je vois tout ceci fonctionnellement. Vous pensez qu'il y'a des trucs sur lesquels je doit faire très attention ?

Rajouter dans le footer du site un truc (je ne sais pas encore quoi) qui permet de choisir la langue dans laquelle on veut consulter le site

"Internationalisation de la codebase" != "gestion d'un site multi-langue", même si le premier est un pré-requis du second.

Pour moi ce doit être 2 "projets" séparés.

PS : surtout que gérer un site multi-langues nécessite une attention particulière. Est-ce que c'est un seul site avec toutes les ressources disponibles dans chacune des langues, ou une version du site différente par langue, avec des ressources particulières ?

Rien que ça implique pas mal de choix différents selon la réponse.

On pourrait parler aussi de la gestion des différentes langues dans les URLs (domaines ? sous-domaines ? chemin de l'URL ? Paramètre ?)

Rajouter dans le footer aussi un lien vers une page appelée "Contribuer au site" avec un mini résumé sur les différentes manières de contribuer a site (Au niveau du contenu, au niveau du code, au niveau de la traduction du site, etc.) en précisant les compétences nécessaires pour chacune des taches. Sur la page en question à la fin des mini-résumés, un lien qui pointe vers une doc/tuto qui explicite mieux.

Je ne suis pas contre même si je pense que ça aurait surtout ça place dans un topic du forum pour que les nouveaux puissent poser des questions mais dans l'absolus je pense que c'est hors-scope, ça n'a rien a voir avec l'internationalisation.

D’où mon point qui consiste a paramétrer ceci via le setting. Et donc le choix est laissé à celui qui veut déployer le site. La gestion du site en multi langue n'interviendrait pas au moment du dev, le dev se contente de donner la possibilité de gérer ça de différentes manières. Pour que justement un autre site puisse l'utiliser différemment.

ça aussi c'est une spécificité du site qui déploie. le code n'a pas la main sur le domaine/sous-domaine. Il se contente de proposer les urls (via chemin) et c'est l'utilisateur (celui qui déploie le code) qui décide vers quoi il veut rediriger.

En effet les autres formes de participation sont hors scope ici, mais l'idée est surtout de proposer une page qui explique simplement comment proposer des traductions au code du site. Il ne faut pas forcément savoir developper ou même avoir installé zds chez soit pour ça. C'est une autre forme de participation à la vie du site. Dans un forum ça sera vite caché et ça ne sera pas repetable sur un autre site qui déploie zds.

Oui mais toi tu parle de proposer la solution de switcher de langue depuis le footer. Or cela apporte d'autres problématiques bien plus importante. A partir du moment que tu propose que l'utilisateur puisse changer de langue de l'interface, que fait on du contenu ? Est ce que le contenu français doit être exposé aux personnes ayant une interface en anglais ? Ce choix devrait revenir a l'administrateur du site (choix entre "le meme contenu pour tous" et "un contenu specifique par langue"). De là tu arrive au besoin que le contenu soit tagué par langue, ce qui implique pleins de modifs…

Bref OUI pour proposer à l'administrateur de choisir la langue utiliser par le site, NON de le permettre aux utilisateurs. C'est de la gestion de site multi-langues et ça apporte beaucoup trop de problématique en plus.

Enfin pour ma remarque, je reste persuadé que c'est hors-scope. Comme tu le fais remarquer, il n'y a pas que la traduction qui pourrait en profiter. Il faut discuter de cette suggestion a part. Est ce qu'on fait une page statique ? Une tuto ? Un topic ? Les 3 avec des liens ? Je ne vois pas de raison de faire un truc spécifique pour la traduction.

100% d'accord avec mon voisin du dessus.

J'ai des clients qui ont planté des projets sur cette histoire de gestion "site multi-langue" / "sites multiples".