A propos d'internationalisation

Version imprimable

22/12/2010, 13h31
jblecanard

A propos d'internationalisation

Bonjour à tous

Ce sujet est plus un débat qu'une question. Je voulais discuter d'internationalisation. Pas au sens "std::locale" du terme, mais au sens "gettext", je veux dire par là, gérer les fichiers de ressources, les charger/parser, etc.

Gettext est assez répandu mais ne me plaît guère, pour les raisons suivantes:
- Phase de "compilation" lourde et sans intérêt à mon sens
- Pas de chargement dynamique de la langue (redémarrage obligatoire)
- Multiplateforme pas top, je n'ai pas encore réussi à faire du gettext proprement dans un environnement purement windows.

En fait, je trouve gettext un peu obsolète, comme le sont les autotools comparés à CMake (ou équivalent). On se prend pas mal le chou avec, pour une opération qui est structurellement parlant simple.

N'existe-t-il pas un outil générique qui fait un travail similaire, uniquement dédié à cela (j'exclus par là les outils internes à certains frameworks comme Qt) ?

Qu'en pensez vous ? Comment faites vous ?

J'envisage pour l'instant m'écrire mon système maison et d'ouvrir le code pour ceux à qui ça pourrait servir.
22/12/2010, 14h54
Emmanuel Deloget

Citation:

Envoyé par jblecanard

Bonjour à tous

Ce sujet est plus un débat qu'une question. Je voulais discuter d'internationalisation. Pas au sens "std::locale" du terme, mais au sens "gettext", je veux dire par là, gérer les fichiers de ressources, les charger/parser, etc.

Gettext est assez répandu mais ne me plaît guère, pour les raisons suivantes:
- Phase de "compilation" lourde et sans intérêt à mon sens

Quelle phase de compilation ? Celle qui te sors toutes le chaines que tu as défini ? Je ne considère pas ça comme étant sans intérêt, puisque du coup, tu n'as pas besoin de le faire à la main. C'est plutôt une bonne chose, non ?

Citation:

Envoyé par jblecanard

- Pas de chargement dynamique de la langue (redémarrage obligatoire)

C'est possible (encore que j'ai un doute). Si tu le faisais - dans une application GUI - comment t'y prendrais tu pour que ça soit multiplateforme ?

Citation:

Envoyé par jblecanard

- Multiplateforme pas top, je n'ai pas encore réussi à faire du gettext proprement dans un environnement purement windows.

La lib est multiplateforme. Par contre, elle se base sur la locale courante. Et le format des noms de locale n'est pas le même sous Windows.

Citation:

Envoyé par jblecanard

En fait, je trouve gettext un peu obsolète, comme le sont les autotools comparés à CMake (ou équivalent). On se prend pas mal le chou avec, pour une opération qui est structurellement parlant simple.

Pour avoir travaillé le sujet il y a quelques années, je peux t'assurer que c'est tout sauf simple. Et que l'interface de gettext est l'une des meilleures.

Citation:

Envoyé par jblecanard

N'existe-t-il pas un outil générique qui fait un travail similaire, uniquement dédié à cela (j'exclus par là les outils internes à certains frameworks comme Qt) ?

Pas à ma connaissance (mais en même temps, tout le monde utilise gettext)

Citation:

Envoyé par jblecanard

Qu'en pensez vous ? Comment faites vous ?

gettext :)

Citation:

Envoyé par jblecanard

J'envisage pour l'instant m'écrire mon système maison et d'ouvrir le code pour ceux à qui ça pourrait servir.

C'est une valeureuse initiative. Je te souhaite de réussir.
22/12/2010, 15h17
Jean-Marc.Bourguet

Citation:

Envoyé par jblecanard

- Pas de chargement dynamique de la langue (redémarrage obligatoire)

Code:

setlocale(LC_MESSAGES, ...);

ne change pas la langue?

Citation:

On se prend pas mal le chou avec, pour une opération qui est structurellement parlant simple.

J'ai l'impression qu'ou tu sous-estimes la complexite de la chose, ou tu ne l'envisages pas dans son ensemble.

Citation:

N'existe-t-il pas un outil générique qui fait un travail similaire, uniquement dédié à cela (j'exclus par là les outils internes à certains frameworks comme Qt) ?

Le C++ a une interface pour ca dans <locale> et POSIX a un systeme aussi, mais je ne les ai jamais vu utilises, gettext etant en pratique nettement mieux...
22/12/2010, 15h45
jblecanard

Citation:

Envoyé par Emmanuel Deloget

Quelle phase de compilation ? Celle qui te sors toutes le chaines que tu as défini ? Je ne considère pas ça comme étant sans intérêt, puisque du coup, tu n'as pas besoin de le faire à la main. C'est plutôt une bonne chose, non ?

Celle la oui, mais je parlais de la génération des msg catalog. Il me paraît logique d'ajouter ça à ma chaîne de compilation et de ne pas versionner les catalogues. Je n'y arrive pas autrement qu'en faisant une sorte de "exec(commande système)", et je ne trouve pas ça très propre.

De plus je ne sais pas comment installer les commandes correspondantes sur windows sans gettext for win32 (http://gettext.sourceforge.net/) et la dernière release date de 2004. J'ai tendance à me méfier des outils qui n'ont pas l'air maintenus. Je veux éviter d'utilise MinGW si possible.

Citation:

Envoyé par Emmanuel Deloget

C'est possible (encore que j'ai un doute). Si tu le faisais - dans une application GUI - comment t'y prendrais tu pour que ça soit multiplateforme ?

Effectivement, il faut reconstruire la GUI. Soit redémarrer le soft pour la plupart. Je n'avais pas bien réfléchi à ça.

Citation:

Envoyé par Emmanuel Deloget

La lib est multiplateforme. Par contre, elle se base sur la locale courante. Et le format des noms de locale n'est pas le même sous Windows.

Ca c'est pas très grave, on doit pouvoir s'en tirer avec des define ou bien std::locale.

Citation:

Envoyé par Emmanuel Deloget

Pour avoir travaillé le sujet il y a quelques années, je peux t'assurer que c'est tout sauf simple. Et que l'interface de gettext est l'une des meilleures.

Merci c'est ce genre de retour que je cherche. Mais qu'en est il maintenant ? Est ce toujours bien maintenu ?

Au final, c'est vraiment le premier point (de ce message) qui me gêne encore.
22/12/2010, 16h13
Emmanuel Deloget

Citation:

Envoyé par jblecanard

Merci c'est ce genre de retour que je cherche. Mais qu'en est il maintenant ? Est ce toujours bien maintenu ?

Tu sais, tout ce sur quoi on travaille n'est pas nécessairement open source :)
22/12/2010, 16h15
jblecanard

Citation:

Envoyé par Emmanuel Deloget

Tu sais, tout ce sur quoi on travaille n'est pas nécessairement open source :)

D'accord, alors rajoutons une contrainte :mrgreen: Je cantonne le débat aux outils open source !
22/12/2010, 16h20
ac_wingless

Je suis assez d'accord avec jblecanard: c'est une problématique plutôt simple, qui n'a curieusement pas à ma connaissance de solution standard (au sens où cela pourrait être inclus dans le standard du C++, par exemple).

Nous n'utilisons pas gettext, pour les raisons citées mais aussi pour des raisons de licence, et parce que cela ne permet pas de paramétrer la disposition graphique des éléments de l'UI qui sont parfois affectés par la langue choisie (par exemple par le sens d'écriture). Nous avons en interne une petite infrastructure qui nous permet sans problème ceci en plus du reste attendu d'une lib d'internationalisation, validée sur les distributions asiatiques et cyrilliques/arabiques. Le chargement est dynamique, ce qui ne sert effectivement à rien pour le client mais est extrêmement utile pour les traducteurs et les développeurs. La totalité couvre moins de 2k lignes, et se trouve être mono-plateforme de par notre métier (embarqué), mais il n'y aurait pas de difficulté particulière à cibler par exemple Cocoa au lieu de VCL.

La solution dont je parle est en place depuis 8 ans, et passe tr_s bien l'épreuve du temps et des changements d'équipe. Je pense donc qu'il est tout à fait viable de développer un outil spécifique léger.
22/12/2010, 16h24
Klaim

Cette discussion (a laquelle j'ai participé) a propos de Boost::Locale (qui n'est pas dans boost, future candidate) pourrait t'interesser :
http://groups.google.com/group/boost...8f6310de0ca1a8
22/12/2010, 16h26
jblecanard

Citation:

Envoyé par ac_wingless

Je suis assez d'accord avec jblecanard

Je me disais bien que je ne devais pas être le seul !

Citation:

Envoyé par ac_wingless

La totalité couvre moins de 2k lignes.

Voilà qui est encourageant, surtout que je ne vise en rien l'embarqué et que par conséquent, je ne me gênerais pas pour utiliser boost à fond si j'écrit quelque chose. Je dis bien si car mon but est quand même de trouver quelque chose de tout fait.

Edit: Je vais lire ton lien Klaim.
22/12/2010, 16h55
Emmanuel Deloget

Citation:

Envoyé par ac_wingless

Je suis assez d'accord avec jblecanard: c'est une problématique plutôt simple, qui n'a curieusement pas à ma connaissance de solution standard (au sens où cela pourrait être inclus dans le standard du C++, par exemple).

La facette std::message<> est équivalente à gettext, sans les outils pour les traducteurs.

Citation:

Envoyé par ac_wingless

Nous n'utilisons pas gettext, pour les raisons citées mais aussi pour des raisons de licence, et parce que cela ne permet pas de paramétrer la disposition graphique des éléments de l'UI qui sont parfois affectés par la langue choisie (par exemple par le sens d'écriture). Nous avons en interne une petite infrastructure qui nous permet sans problème ceci en plus du reste attendu d'une lib d'internationalisation, validée sur les distributions asiatiques et cyrilliques/arabiques. Le chargement est dynamique, ce qui ne sert effectivement à rien pour le client mais est extrêmement utile pour les traducteurs et les développeurs. La totalité couvre moins de 2k lignes, et se trouve être mono-plateforme de par notre métier (embarqué), mais il n'y aurait pas de difficulté particulière à cibler par exemple Cocoa au lieu de VCL.

La solution dont je parle est en place depuis 8 ans, et passe tr_s bien l'épreuve du temps et des changements d'équipe. Je pense donc qu'il est tout à fait viable de développer un outil spécifique léger.

2K lignes de code pour un seul système, pour une seule GUI. Le développement d'un outil spécifique léger est toujours possible, à partir du moment où on maitrise bien tout ce qui a rapport avec les jeux de caractère (notamment les conversion UNICODE <--> non UNICODE qui peuvent se révéler nécessaire).

Je n'ai pas dit que c'était infaisable - juste que ce n'était pas trivial. La création + mise au point de notre système nous a demandé 2 x 1 mois/homme, en prenant en compte la question de l'OS (à la base, WinNT4 English ; il a évolué vers Win2k Multilingual ; mais encore faut-il le configurer correctement...) (et deux fois parce que le premier batch a supporté précisait que le Russe, on s'en moquait et qu'on ne ferait jamais de produits en Russe ; et que le deuxième batch précisait que le Russe, on le voulait, vu qu'en fait on allait vendre des produits en Russie). C'est définitivement faisable, et à un coût correct - dès lors qu'on ne vise pas le multiplateforme (et qu'on ne s'attache pas trop à des problèmes de GUI multiplateforme ; à ce propos, GTK+ a Pango, qui est très bien pour le rendu multilingue - et qui n'a pas nécessairement besoin de GTK+).
23/12/2010, 11h08
jblecanard

Ce que je comprend de tout ça, c'est qu'il n'y a quand même pas de consensus autour d'un outil donné !

J'ai l'impression que le système des facettes imaginé par la lib standard est pas si mal pour ça. Non pas qu'il fournit des outils de base, mais il permet d'étendre avec du code maison ce qu'il y a déjà en créant des facettes, et donc de se donner la possibilité de supporter "à priori" n'importe quel dialecte pour peut qu'on dispose de quelqu'un qui puisse implémenter la facette correspondante.

De plus std::message possède un wrapper sur gettext, ce qui permettrait apparemment de tourner sur une interface à base de std::message et de pouvoir choisir son backend de gestion de catalogue soi-même, et y compris d'implémenter le sien propre.