Discussion :

[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
- 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.

[Emmanuel Deloget]

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 ?

- 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 ?

- 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.

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.

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)

Qu'en pensez vous ? Comment faites vous ?

gettext

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.

[Jean-Marc.Bourguet]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

setlocale(LC_MESSAGES, ...);

ne change pas la langue?

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.

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...

[jblecanard]

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.

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.

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.

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.

[Emmanuel Deloget]

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

[jblecanard]

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

D'accord, alors rajoutons une contrainte Je cantonne le débat aux outils open source !

[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.

[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

[jblecanard]

Je suis assez d'accord avec jblecanard

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

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.

[Emmanuel Deloget]

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.

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+).

[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.