Y a le tutorial de Sun sur l'internationalisation (en anglais): http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble que ça aurait été plus simple
cho7
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une opt ion fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec en identifiant le code langue, et en valeur associée un autre hashtable contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre System.out.println( (String)((Hashtable)(hashtableLangue.get("fr")).get("we lcome")) ); Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique mais j'vais pas non plus donner tout le code, le mieux c'est de faire des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un combobox au démarrage de la session permet de le switcher à autre chose .
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est relativement simple a mettre en place.
Bernard
"collinm" a écrit dans le message de news:EAZ5e.10730$
salut
quel technique utilisez vous pour que vos applications java supporte plusieurs langue?
merci
--
cho7 "Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une opt ion
fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec
en identifiant le code langue, et en valeur associée un autre hashtable
contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre
System.out.println( (String)((Hashtable)(hashtableLangue.get("fr")).get("we lcome")) );
Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique
mais j'vais pas non plus donner tout le code, le mieux c'est de faire
des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un
combobox au démarrage de la session permet de le switcher à autre chose .
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est
relativement simple a mettre en place.
Bernard
"collinm" <collinm@laboiteaprog.com> a écrit dans le message de
news:EAZ5e.10730$sj1.1645516@wagner.videotron.net...
salut
quel technique utilisez vous pour que vos applications java supporte
plusieurs langue?
merci
--
cho7
"Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une opt ion fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec en identifiant le code langue, et en valeur associée un autre hashtable contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre System.out.println( (String)((Hashtable)(hashtableLangue.get("fr")).get("we lcome")) ); Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique mais j'vais pas non plus donner tout le code, le mieux c'est de faire des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un combobox au démarrage de la session permet de le switcher à autre chose .
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est relativement simple a mettre en place.
Bernard
"collinm" a écrit dans le message de news:EAZ5e.10730$
salut
quel technique utilisez vous pour que vos applications java supporte plusieurs langue?
merci
--
cho7 "Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
Isammoc
Un exemple serait bien... ou bien un lien.
Y a le tutorial de Sun sur l'internationalisation (en anglais): http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble que ça aurait été plus simple
AMHA, XML n'était pas encore un standard lorsque sun a développé le coté international des applis.
Mais c'est vrai qu'ils auraient pu le faire depuis.
-- Isammoc Qui ramène sa fraise une fois de plus.
Un exemple serait bien... ou bien un lien.
Y a le tutorial de Sun sur l'internationalisation (en anglais):
http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble
que ça aurait été plus simple
AMHA, XML n'était pas encore un standard lorsque sun a développé le coté
international des applis.
Mais c'est vrai qu'ils auraient pu le faire depuis.
AMHA, XML n'était pas encore un standard lorsque sun a développé le coté international des applis.
Mais c'est vrai qu'ils auraient pu le faire depuis.
Niveau perf/conso mémoire je suis pas sur que ce soit une si bonne idée que ça. Pourquoi vouloir mettre de l'xml partout ?
XML sucks http://xmlsucks.org/
Thomas Escolan
XML, c'est BIEN parce que tu peux mettre toutes les traductions dans un seul fichier... Et puis tu peux gérer des attributs contextuels pour dire, par exemple, "si telle valeur dans l'environnement alors je ne prends pas telles lignes". EX : un menu arborescent qui peut se charger en mode light ou heavy, avec toutes les options.
XML, c'est MAL parce que tu peux mettre toutes les traductions dans un seul fichier... Si tu n'as que deux ou trois langues et que ça n'évoluera pas (hum), tu pourras t'en sortir, mais si tu veux avoir toute la souplesse de passer d'une langue à une autre et même d'en enlever facilement (suppression de fichier), une série de fichiers "clef=valeur" fera amplement l'affaire. D'où l'utilisation de la classe Properties qui, justement parse les fichiers "clef=valeur".
Mon conseil : fait simple, les langues c'est compliqué !
"collinm" a écrit dans le message de news: Xnc6e.856$
Nico wrote:
Un exemple serait bien... ou bien un lien.
Y a le tutorial de Sun sur l'internationalisation (en anglais): http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble que ça aurait été plus simple
XML, c'est BIEN parce que tu peux mettre toutes les traductions dans un seul
fichier...
Et puis tu peux gérer des attributs contextuels pour dire, par exemple, "si
telle valeur dans l'environnement alors je ne prends pas telles lignes".
EX : un menu arborescent qui peut se charger en mode light ou heavy, avec
toutes les options.
XML, c'est MAL parce que tu peux mettre toutes les traductions dans un seul
fichier...
Si tu n'as que deux ou trois langues et que ça n'évoluera pas (hum), tu
pourras t'en sortir, mais si tu veux avoir toute la souplesse de passer
d'une langue à une autre et même d'en enlever facilement (suppression de
fichier), une série de fichiers "clef=valeur" fera amplement l'affaire.
D'où l'utilisation de la classe Properties qui, justement parse les fichiers
"clef=valeur".
Mon conseil : fait simple, les langues c'est compliqué !
"collinm" <collinm@laboiteaprog.com> a écrit dans le message de news:
Xnc6e.856$wl6.96826@weber.videotron.net...
Nico wrote:
Un exemple serait bien... ou bien un lien.
Y a le tutorial de Sun sur l'internationalisation (en anglais):
http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble que
ça
aurait été plus simple
XML, c'est BIEN parce que tu peux mettre toutes les traductions dans un seul fichier... Et puis tu peux gérer des attributs contextuels pour dire, par exemple, "si telle valeur dans l'environnement alors je ne prends pas telles lignes". EX : un menu arborescent qui peut se charger en mode light ou heavy, avec toutes les options.
XML, c'est MAL parce que tu peux mettre toutes les traductions dans un seul fichier... Si tu n'as que deux ou trois langues et que ça n'évoluera pas (hum), tu pourras t'en sortir, mais si tu veux avoir toute la souplesse de passer d'une langue à une autre et même d'en enlever facilement (suppression de fichier), une série de fichiers "clef=valeur" fera amplement l'affaire. D'où l'utilisation de la classe Properties qui, justement parse les fichiers "clef=valeur".
Mon conseil : fait simple, les langues c'est compliqué !
"collinm" a écrit dans le message de news: Xnc6e.856$
Nico wrote:
Un exemple serait bien... ou bien un lien.
Y a le tutorial de Sun sur l'internationalisation (en anglais): http://java.sun.com/docs/books/tutorial/i18n/index.html
je me demande pourquoi sun à pas choisi l'option xml... il me semble que ça aurait été plus simple
Thomas Escolan
Si tu gardes tout en mémoire, faut espérer que t'as de la place ! Imagine que tu proposes une demi-douzaine de langues (classique, rien que dans la CEE) et multiplie par la taille de chaques chaînes (sans compter la structure de stockage/indexage). Cela ne reste intéressant que si tu veux pouvoir changer de langue sans relancer l'application.
"cho7" a écrit dans le message de news:
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une option fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec en identifiant le code langue, et en valeur associée un autre hashtable contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre System.out.println( (String)((Hashtable)(hashtableLangue.get("fr")).get("welcome")) ); Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique mais j'vais pas non plus donner tout le code, le mieux c'est de faire des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un combobox au démarrage de la session permet de le switcher à autre chose.
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est relativement simple a mettre en place.
Bernard
"collinm" a écrit dans le message de news:EAZ5e.10730$
salut
quel technique utilisez vous pour que vos applications java supporte plusieurs langue?
merci
--
cho7 "Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
Si tu gardes tout en mémoire, faut espérer que t'as de la place ! Imagine
que tu proposes une demi-douzaine de langues (classique, rien que dans la
CEE) et multiplie par la taille de chaques chaînes (sans compter la
structure de stockage/indexage).
Cela ne reste intéressant que si tu veux pouvoir changer de langue sans
relancer l'application.
"cho7" <cho7@dlfp.le.spam.ca.pu.du.ku.org> a écrit dans le message de news:
1113154178.19946.8.camel@cho7land...
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une option
fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec
en identifiant le code langue, et en valeur associée un autre hashtable
contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre
System.out.println(
(String)((Hashtable)(hashtableLangue.get("fr")).get("welcome")) );
Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique
mais j'vais pas non plus donner tout le code, le mieux c'est de faire
des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un
combobox au démarrage de la session permet de le switcher à autre chose.
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est
relativement simple a mettre en place.
Bernard
"collinm" <collinm@laboiteaprog.com> a écrit dans le message de
news:EAZ5e.10730$sj1.1645516@wagner.videotron.net...
salut
quel technique utilisez vous pour que vos applications java supporte
plusieurs langue?
merci
--
cho7
"Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
Si tu gardes tout en mémoire, faut espérer que t'as de la place ! Imagine que tu proposes une demi-douzaine de langues (classique, rien que dans la CEE) et multiplie par la taille de chaques chaînes (sans compter la structure de stockage/indexage). Cela ne reste intéressant que si tu veux pouvoir changer de langue sans relancer l'application.
"cho7" a écrit dans le message de news:
Moi pour l'appli j2ee que je développe au taf, j'ai préféré une option fichier xml, dans lequel je regroupe les messages, classé par langue.
Au démarrage du serveur websphere, un hashtable général est créé, avec en identifiant le code langue, et en valeur associée un autre hashtable contenant le couple idmessage/valeur de la langue en question.
Donc en gros pour accéder a un message, je fais un truc genre System.out.println( (String)((Hashtable)(hashtableLangue.get("fr")).get("welcome")) ); Bien entendu faut encapsuler tout ca pour que ce soit plus esthétique mais j'vais pas non plus donner tout le code, le mieux c'est de faire des tests.
Voilà pour ma solution, surement pas la plus optimale, mais ca marche.
Ah, pour le code langue, il est définit par défaut a fr, mais un combobox au démarrage de la session permet de le switcher à autre chose.
Bonjour,
J'utilise les resources bundles avec les fichiers properties. C'est relativement simple a mettre en place.
Bernard
"collinm" a écrit dans le message de news:EAZ5e.10730$
salut
quel technique utilisez vous pour que vos applications java supporte plusieurs langue?
merci
--
cho7 "Plus grosse est la pomme, plus gros est le ver" - cho7, 2005
