internationalisation avec un seul fichier

Voir le message du 16.04.
Pourquoi vouloir réinventer la poudre. Java a les properties
et les fonctions ad hoc.
http://java.sun.com/docs/books/tutorial/i18n/index.html
Personnellement, j'utilise Netbeans pour gérer les langues.
Salut.

Jean-Marie a écrit :

Bonjour

j'ai une application que j'internationalise en créant
autant de fichiers qu'il y a de langue ;
les lignes de chaque fichier correspondent à des messages
apparaissant dans l'application et ayant la syntaxe suivante :

variable=valeur

les noms des fichiers sont de la forme applimess.LANG
où LANG récupère la valeur de la propriété user.language
au lancement de l'application

la gestion de plusieurs fichiers n'étant pas très pratique pour un
traducteur,
notamment pour faire correspondre des traductions pour une même variable ,
je voulais m'orienter vers la gestion d'un seul fichier ;
par exemple un fichier Excel est pratique pour faire une telle
correspondance ;
de plus l'ajout d'une ligne se fait automatiquement sur toutes les
colonnes ; et on peut mettre en évidence les nouvelles entrées

mais bon je n'ai pas envie vraiment envie de lire un fichier Excel
en java même s'il existe une librairie pour cela

à côté de cela, créer et gérer une base de données me semble un peu lourd

si quelqu'un a une idée je suis preneur

merci d'avance

Jean-Marie

--
Christian Laborde
La Révolution citoyenne, c'est sur : http://c.lab.over-blog.com/
Le forum des électrons libres :
http://electrons-libres.forumactif.fr
Les citoyens qui voient Net : http://www.netoyens.info
True E-mail : remove -no-spam-
Sentier des Vinches
CH 1091 Grandvaux
Suisse

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)


JM


Christian Laborde a écrit :

Voir le message du 16.04.
Pourquoi vouloir réinventer la poudre. Java a les properties et les
fonctions ad hoc.
http://java.sun.com/docs/books/tutorial/i18n/index.html
Personnellement, j'utilise Netbeans pour gérer les langues.
Salut.

Jean-Marie a écrit :

Bonjour

j'ai une application que j'internationalise en créant
autant de fichiers qu'il y a de langue ;
les lignes de chaque fichier correspondent à des messages
apparaissant dans l'application et ayant la syntaxe suivante :

variable=valeur

les noms des fichiers sont de la forme applimess.LANG
où LANG récupère la valeur de la propriété user.language
au lancement de l'application

la gestion de plusieurs fichiers n'étant pas très pratique pour un
traducteur,
notamment pour faire correspondre des traductions pour une même
variable ,
je voulais m'orienter vers la gestion d'un seul fichier ;
par exemple un fichier Excel est pratique pour faire une telle
correspondance ;
de plus l'ajout d'une ligne se fait automatiquement sur toutes les
colonnes ; et on peut mettre en évidence les nouvelles entrées

mais bon je n'ai pas envie vraiment envie de lire un fichier Excel
en java même s'il existe une librairie pour cela

à côté de cela, créer et gérer une base de données me semble un peu lourd

si quelqu'un a une idée je suis preneur

merci d'avance

Jean-Marie

Pourquoi ne pas écrire un petit programme avec un Jtable et
des fonctions d'entrée-sortie de et vers les fichiers
properties ?

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)


JM


Christian Laborde a écrit :

Voir le message du 16.04.
Pourquoi vouloir réinventer la poudre. Java a les properties et les
fonctions ad hoc.
http://java.sun.com/docs/books/tutorial/i18n/index.html
Personnellement, j'utilise Netbeans pour gérer les langues.
Salut.

Jean-Marie a écrit :

Bonjour

j'ai une application que j'internationalise en créant
autant de fichiers qu'il y a de langue ;
les lignes de chaque fichier correspondent à des messages
apparaissant dans l'application et ayant la syntaxe suivante :

variable=valeur

les noms des fichiers sont de la forme applimess.LANG
où LANG récupère la valeur de la propriété user.language
au lancement de l'application

la gestion de plusieurs fichiers n'étant pas très pratique pour un
traducteur,
notamment pour faire correspondre des traductions pour une même
variable ,
je voulais m'orienter vers la gestion d'un seul fichier ;
par exemple un fichier Excel est pratique pour faire une telle
correspondance ;
de plus l'ajout d'une ligne se fait automatiquement sur toutes les
colonnes ; et on peut mettre en évidence les nouvelles entrées

mais bon je n'ai pas envie vraiment envie de lire un fichier Excel
en java même s'il existe une librairie pour cela

à côté de cela, créer et gérer une base de données me semble un peu
lourd

si quelqu'un a une idée je suis preneur

merci d'avance

Jean-Marie

--
Christian Laborde
La Révolution citoyenne, c'est sur : http://c.lab.over-blog.com/
Le forum des électrons libres :
http://electrons-libres.forumactif.fr
Les citoyens qui voient Net : http://www.netoyens.info
True E-mail : remove -no-spam-
Sentier des Vinches
CH 1091 Grandvaux
Suisse

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)

Bonjour,

Moi aussi j'utilise Netbeans pour gérer l'internationalisation, créer
les fichiers .properties, etc. C'est assez simple et rapide. Cela doit
exister avec d'autres IDE.
Il n'y a aucuns problèmes avec les traducteurs, les fichiers .properties
sont des simples fichiers texte qu'on peut modifier dans un banal
éditeur de texte.

--
Xavier Nayrac

Xavier Nayrac a écrit :

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)

Bonjour,

Moi aussi j'utilise Netbeans pour gérer l'internationalisation, créer
les fichiers .properties, etc. C'est assez simple et rapide. Cela doit
exister avec d'autres IDE.
Il n'y a aucuns problèmes avec les traducteurs, les fichiers .properties
sont des simples fichiers texte qu'on peut modifier dans un banal
éditeur de texte.

--
Xavier Nayrac

Salut,

Ce n'est pas si simple que ça de le faire avec un bête éditeur, parce que je
crois que ça doit forcément être de l'ISO-8859, avec pour les caractères
n'ayant pas de représentation en ISO-8859 une séquence d'échappement en uNNNN
où les N sont des chiffres hexadécimaux.

Je ne connais aucun éditeur standard qui permet de visualiser les caractères
ainsi représentés en uNNNN de façon humaine.

Personnellement j'ai l'impression que la gestion des traductions dans GNU
gettext (avec les fichiers PO) est mieux faite de ce côté là, ne serait-ce que
parce que:

1) il est possible de de choisir comme on veut le système de codage d'un
fichier PO
2) il y a un support rudimentaire de traduction en fonction d'arguments
numérique (par exemple "il y a 1 erreur" ou "il y a 2 erreurs").
3) les fichier PO sont gérés par au moins un éditeur capable de gérer
correctement l'Unicode, à savoir Emacs.
4) Les chaînes de caractères contenant les traductions sont en syntaxe C si on
veut, Java, Lisp, ou encore plein d'autre formats. Dans le cas de la syntaxe
C, je trouve que ça a l'avantage énorme que les blancs apparaissent de façon
plus explicite.

Vincent.

PS : Peut-être y a-t-il un moulinette capable de transformer un po en fichier
de propriétés ?

Vincent Belaïche a écrit :

Xavier Nayrac a écrit :

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)

Bonjour,

Moi aussi j'utilise Netbeans pour gérer l'internationalisation, créer
les fichiers .properties, etc. C'est assez simple et rapide. Cela doit
exister avec d'autres IDE.
Il n'y a aucuns problèmes avec les traducteurs, les fichiers
.properties sont des simples fichiers texte qu'on peut modifier dans
un banal éditeur de texte.

--
Xavier Nayrac

Salut,

Ce n'est pas si simple que ça de le faire avec un bête éditeur, parce
que je crois que ça doit forcément être de l'ISO-8859, avec pour les
caractères n'ayant pas de représentation en ISO-8859 une séquence
d'échappement en uNNNN où les N sont des chiffres hexadécimaux.

Oui, je me suis peut-être mal expliqué...
Voilà par exemple ce que j'ai dans xxx_fr.properties (français) :
Password=Mot de passe
Et la même ligne dans xxx_ar.properties (arabe) :
Password=u0643u0644u0645u0629 u0627u0644u0633u0631

Tu as raison, on n'y comprends rien, mais ce n'est pas un problème. Tout
ce que je demande, c'est que cela s'affiche correctement dans
l'interface, ce qui est le cas.
Entre nous, si j'avais un éditeur capable de m'afficher l'alphabet
arabe, suédois ou russe, je ne serais pas plus avancé ;-)

Je ne connais aucun éditeur standard qui permet de visualiser les
caractères ainsi représentés en uNNNN de façon humaine.

Moi non plus, je vais demander au traducteur ce qu'il utilise.

Personnellement j'ai l'impression que la gestion des traductions dans
GNU gettext (avec les fichiers PO) est mieux faite de ce côté là, ne

Je vais jeter un œil la dessus, je ne connais pas.

--
Xavier Nayrac

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)

Il existe des outils en dehors des IDE majeurs capables de gérer les
fichiers properties. Le Zaval JRC Editor m'a rendu de bons services
avant de passer à l'éditeur intégré dans IntelliJ :

http://www.zaval.org/products/jrc-editor/index.html

http://www.zaval.org/products/jrc-editor/user_guide/images/jrc-editor.gif

Jean-Marie a écrit :

Bonjour

j'ai une application que j'internationalise en créant
autant de fichiers qu'il y a de langue ;
les lignes de chaque fichier correspondent à des messages
apparaissant dans l'application et ayant la syntaxe suivante :

variable=valeur

les noms des fichiers sont de la forme applimess.LANG
où LANG récupère la valeur de la propriété user.language
au lancement de l'application

la gestion de plusieurs fichiers n'étant pas très pratique pour un
traducteur,
notamment pour faire correspondre des traductions pour une même variable ,

...

si quelqu'un a une idée je suis preneur

merci d'avance

Jean-Marie

Salut,

Le problème n'est pas nouveau. Il existe d'ailleurs un format XLIFF
spécialisé dans l'échange des fichiers à traduire.

Ce format est en réalité un zip qui contient d'un côté un fichier
squelette décrivant la structure du format original, et d'un autre côté
les parties à traduire extraites et rassemblées dans un autre fichier
qui pourra après être fusionné avec le squelette pour regénérer un
fichier traduit.

Le format d'échange sert aussi dans des éditeurs spécialisés en
traduction pour présenter la langue de départ et la langue cible, et une
fenêtre de visualisation du contexte.

Il faut chercher "Open Language Toolkit" pour voir des outils
rudimentaires qui travaillent avec ce format.

La plupart des formats informatiques classiques, comme les fichiers
que tu décris, sont déjà connus et supportés en standard par les
traducteurs.

Les officines de traduction ont déjà ce genre de base de données
qu'elles désignent par le terme "mémoire de traduction". Donc reprendre
le travail sur un fichier déjà traduit est un travail incrémental.

En résumé, les outils, les standards et l'automatisation existent déjà,
il faut simplement les utiliser sans réinventer la roue.

J-P

merci pour toutes ces infos ;
à discuter, je pense, avec les personnes chargées de la traduction

JM

Jaypee a écrit :

Jean-Marie a écrit :

Bonjour

j'ai une application que j'internationalise en créant
autant de fichiers qu'il y a de langue ;
les lignes de chaque fichier correspondent à des messages
apparaissant dans l'application et ayant la syntaxe suivante :

variable=valeur

les noms des fichiers sont de la forme applimess.LANG
où LANG récupère la valeur de la propriété user.language
au lancement de l'application

la gestion de plusieurs fichiers n'étant pas très pratique pour un
traducteur,
notamment pour faire correspondre des traductions pour une même
variable ,

...

si quelqu'un a une idée je suis preneur

merci d'avance

Jean-Marie

Salut,

Le problème n'est pas nouveau. Il existe d'ailleurs un format XLIFF
spécialisé dans l'échange des fichiers à traduire.

Ce format est en réalité un zip qui contient d'un côté un fichier
squelette décrivant la structure du format original, et d'un autre côté
les parties à traduire extraites et rassemblées dans un autre fichier
qui pourra après être fusionné avec le squelette pour regénérer un
fichier traduit.

Le format d'échange sert aussi dans des éditeurs spécialisés en
traduction pour présenter la langue de départ et la langue cible, et une
fenêtre de visualisation du contexte.

Il faut chercher "Open Language Toolkit" pour voir des outils
rudimentaires qui travaillent avec ce format.

La plupart des formats informatiques classiques, comme les fichiers
que tu décris, sont déjà connus et supportés en standard par les
traducteurs.

Les officines de traduction ont déjà ce genre de base de données
qu'elles désignent par le terme "mémoire de traduction". Donc reprendre
le travail sur un fichier déjà traduit est un travail incrémental.

En résumé, les outils, les standards et l'automatisation existent déjà,
il faut simplement les utiliser sans réinventer la roue.

J-P

Emmanuel Bourg a écrit :

Jean-Marie a écrit :

merci pour l'info mais
je trouve que cette solution est en fait trop proche de la vision
développeur
et permet difficilement à un organisme externe de faire la traduction :
je les vois mal par exemple installer un logiciel spécifique (eclipse
avec le plug-in spécifique ou encore netbeans)

Il existe des outils en dehors des IDE majeurs capables de gérer les
fichiers properties. Le Zaval JRC Editor m'a rendu de bons services
avant de passer à l'éditeur intégré dans IntelliJ :

http://www.zaval.org/products/jrc-editor/index.html

c'est un exemple intéressant puisqu'il s'installe facilement sans
être solidaire d'un IDE ; le problème est (à moins que je ne me trompe)
qu'il ne supporte pas les versions ultérieures à 1.4....

jm

http://www.zaval.org/products/jrc-editor/user_guide/images/jrc-editor.gif