search

Geoportail-Luxembourg / geoportailv3

geoportailv3 is the implementation of the v3 of the map viewer of the luxembourgish geoportal
MIT License
25 stars 16 forks source link

Define i18n architecture #20

Closed elemoine closed 9 years ago

elemoine commented 9 years ago

This issue is about defining the global architecture for a unified (client & server) i18n system.

petzlux commented 9 years ago

Idéalement, on pourrait penser comment intégrer les fichiers de traduction de la partie CMS/catalogue dans ce système. Ceux-ci étant basés sur le systeme Django ! https://docs.djangoproject.com/en/1.6/topics/i18n/

elemoine commented 9 years ago

Je viens d'ajouter un document de specs fonctionnelles et techniques sur la partie "internationalisation" dans le wiki : https://github.com/Geoportail-Luxembourg/geoportail_v3/wiki/Internationalisation. Je vous encourage à le lire et donner votre avis sur la solution proposée.

jaykayone commented 9 years ago

Dans le texte, tu parles de "fichiers" de traduction à éditer. S'agit-il de fichiers texte? Nous préférons gérer les traductions dans une base de donnée. Si un lien direct n'est pas possible, nous devons prévoir un outil de génération de texte à partir de la base de données. Il existe déjà un tel outil aujourd'hui

elemoine commented 9 years ago

Dans le texte, tu parles de "fichiers" de traduction à éditer. S'agit-il de fichiers texte?

Oui, parce que c'est ce que les systèmes gettext et les outils comme Transifex savent gérer.

elemoine commented 9 years ago

Si un lien direct n'est pas possible, nous devons prévoir un outil de génération de texte à partir de la base de données. Il existe déjà un tel outil aujourd'hui

Je ne comprends pas comment ceci fonctionne actuellement, et comment ça peut fonctionner avec le système que nous avons commencer à spécifier. Où dois-je regarder dans le code actuel pour comprendre ceci ?

Par ailleurs, comptez-vous utiliser un système comme Transifex dans le futur ? Et si oui est-ce que la gestion des traductions dans une base de donnée reste pertinente ?

elemoine commented 9 years ago

J'ai trouvé le script : https://project.camptocamp.com/svn/geoportail_luxembourg/trunk/geoadmin/geoadmin/geoadmin/generateTranslationFiles.py. Si je comprends bien, ce script permet de générer les fichiers po (et les fichiers de traduction "client" basés sur le système OpenLayers). Mais avec ce système utilisez-vous quand même l'extraction des messages depuis le code source Python/Mako et les fichiers pot ?

jaykayone commented 9 years ago

Non, pas à l'heure actuelle ... Dans le CMS, nous utilisons rosetta (https://github.com/mbi/django-rosetta) Patrick va regarder si il pourra éventuellement être utilisé dans un cadre hors-django...

Je corrige peut-être ma première position:

Nous n'avons pas nécessairement besoin d'une base de données pour stocker les traductions. Le besoin réel est d'avoir UN et UN SEUL outil dans lequel nous pouvons gérer les traductions (et qui génère les fichiers po/mo).

elemoine commented 9 years ago

Non, pas à l'heure actuelle ... Dans le CMS, nous utilisons rosetta (https://github.com/mbi/django-rosetta)

Rosetta, si je comprends bien, offre une interface pour les traducteurs, intégrée dans l'interface d'admin de Django. Est-ce correct ?

Mais dans ce cas les traductions ne sont pas stockées en base de donnée ? Rosetta n'offre qu'une interface de traduction, au même titre que Transifex.

Patrick va regarder si il pourra éventuellement être utilisé dans un cadre hors-django...

Si Rosetta ne permet pas de traduire des messages qui sont en dehors du projet Django dans lequel Rosetta est installer l'alternative est d'utiliser un outil comme Transifex, qui est indépendant du projet.

Je corrige peut-être ma première position:

Nous n'avons pas nécessairement besoin d'une base de données pour stocker les traductions. Le besoin réel est d'avoir UN et UN SEUL outil dans lequel nous pouvons gérer les traductions (et qui génère les fichiers po/mo).

En se basant sur le standard gettext pour toutes les traductions on se met dans une bonne situation de ce point de vue là. Mais on a aussi besoin d'une interface unique pour les traducteurs. C'est là qu'un outil externe/global comme Transifex devient intéressant.

En tout cas, je ne vois pas en quoi l'utilisation d'une base de donnée nous aide ici. Dis moi si je me trompe.

jaykayone commented 9 years ago

En tout cas, je ne vois pas en quoi l'utilisation d'une base de donnée nous aide ici. Dis moi si je me trompe.

-> c'est bien pour celà que j'ai relativé mon besoin en insistant sur l'outil unique. qu'il y a une base de donnée ou pas derrière n'est pas important. Il faut éviter de bidouiller dans des fichiers comme c'était le cas dans geoadmin ..

elemoine commented 9 years ago

-> c'est bien pour celà que j'ai relativé mon besoin en insistant sur l'outil unique. qu'il y a une base de donnée ou pas derrière n'est pas important. Il faut éviter de bidouiller dans des fichiers comme c'était le cas dans geoadmin ..

Ok, donc de notre côté, on se débrouille pour utiliser gettext pour toutes les traductions du projet (client et serveur). Et de votre côté vous regardez comment fournir une interface unique à vos traducteurs. On est d'accord avec ce principe ?