Salut, > Et naturellement, le coeur de l'application web était fait en Angleterre, > puis spécialisé dans les différents pays. Et pour cette spécialisation, nous > utilisions des ressources locales, qui étaient traduites par un mécanisme > assez baroque, mais n'utilisant pas Struts. Et globalement, le résultat > était tout à fait identique à celui qu'on peut attendre de la pire des > applications swing : comme le texte n'était pas identifié suivant la page où > il se trouvait, les traductions se faisaient hors contexte, générant du > travail supplémentaire pour les chargés de traduction, ainsi que de nombreux > cas où ce texte ne correspondait à rien. Tu souleves la un des plus gros problemes avec lesquels je me bagarre de maniere quotidienne. Il est effectivement beaucoup plus facile de foirer l'internationalisation d'une appli JSP que d'une appli Swing. Et j'avoue que c'est la un defaut de ce modele. Il est beaucoup trop difficile de reorganiser tes fichiers de ressources une fois qu'ils sont mal hierarchises, c'est la cata. Mais bon, j'aimerais penser que si c'est bien fait au depart, alors ca doit marcher mieux. Mais j'ai jamais eu l'occasion de rencontrer un cas ou c'etait bien fait des le depart...
> > D'autre part, je pense qu'il existe bien plus de pages > > HTML ecrites dans des langages differents que d'applications Swing. > > Tu m'excuseras, mais l'argument du nombre ne me convient pas du tout. La > plupart des pages web sont écrites en anglais, et elles ne sont traduites > *que* lorsque l'auteur n'est pas anglo-saxon. En fait, il me semblait avoir lu quelque part que 51% du web etait ecrit dans un autre langage que l'anglais. Mais bon, je presentais surtout ce point pour montrer que l'HTML est un bon support pour l'internationalisation. Surtout quand il faut supporter des modes d'ecriture de droite a gauche comme en Arabe ou en Hebreu. > > Enfin, > > les differents browsers HTML les plus utilises supportent en general plus > de > > methodes d'entree (IME) que les applications Swing. > > Je ne suis pas du tout d'accord. D'origine, les browsers Netscape et > Microsoft sont livrés avec le pack de langues correspondant à la zone > linguistique de la machine, ainsi, nous avons IE et NN en européen, mais > rarement en sanscrit. De plus, pour passer dans ces langues, il faut changer > le mode d'encodage du texte puisque ces navigateurs n'utilisent pas > l'UNICODE. A contrario, Opera, et Swing, utilisent l'UNICODE. Ainsi, ta > machine virtuelle Java permet de lancer des applications écrites en > japonais, tout comme Opera permet d'afficher les pages japonaises utilisant > l'UNICODE. Par conséquent, si tu consultes les apercus de NetBeans, tu > t'apercevras qu'il existe, si je me souviens bien, un écran présentant le > module d'internationalisation où du texte japonais est entouré de texte > eurpoéen, et même anglais. Le tout, sans changer de système d'encodage > (puisque c'est de l'UNICODE). A ce que j'en ai vu, HTML supporte tres bien Unicode (ou plutot les differents encodages relies a Unicode). En effet, Unicode n'est pas un encodage, mais une page de caracteres. Ce qui veut dire que UTF-8, UCS2, etc ne sont pas la meme chose qu'Unicode. En l'occurence, IE et NN supportent les pages HTML encodees en UTF-8 au moins, et te retourneront les valeurs de ton formulaire encodees en UTF-8 si tu le specifie. Donc il n'y a pas de probleme de ce cote la, si ton appli gere ca comme il le faut. Ici, je suis sous NT version Anglaise, et je peux ecrire un email sous Outlook en format HTML encode en UTF-8, qui contiendra des caracteres Japonais (entres avec l'IME Microsoft) et des caracteres accentues. > > Pour ce que j'en ai vu, > > pour gerer l'entree de texte Japonais dans une application Swing depuis > une > > station de travail dont l'OS est anglais, c'est un peu la croix et la > > banniere non? > > Tout comme il peut être invraisemblament complexe d'utiliser une application > écrite en japonais sur une machine française. L'argument n'est donc pas > réellement recevable. Si parce que tu peux entrer du texte Japonais dans une application anglaise qui supporte l'Unicode (comme mon exemple plus haut avec Outlook) si tu as le bon IME, alors que cet IME n'est pas disponible dans les applications Java ecrites par defaut sans support (c'est bien dommage, vu que Java se presente comme supportant Unicode, de ne pas pouvoir entrer de texte Unicode dedans). > > D'autre plus, Struts propose un bean permettant de gerer l'extraction de > > resources dans les pages JSP, donc tu peux utiliser le meme systeme base > sur > > les ResourceBundles que dans Swing. > > Donc, comme les jsps copient Swing, elles sont mieux que Swing, c'est bien > cela ? Les ResourceBundles ne sont pas une exclusivite de Swing. Tu peux les utiliser dans n'importe quel contexte. D'ailleurs il me semble que le package de ResourceBundle soit java.util, et non javax.swing... Enfin, bon, je ne cherchais pas a denigrer les possibilites d'internationalisation de Swing dans mon email d'origine, mais surtout a montrer qu'il y a des problemes dans les deux cas, et que proposer une vision manicheenne disant "JSP c'est super pour l'internationalisation, Swing ca pue." Le fait est que Swing comme JSP ont tous les deux de grosses lacunes, mais que la balance ne penche pas forcement a l'avantage de Swing dans tous les cas. Cordialement, Nicolas Sallembien
