Discussion :

[tchize_]

Bonjour,

dans une application sur laquelle je travaille, on manipule directement la locale pour certaines choses au lieu de passer par les interfaces de Localization de GWT. Les buts:

A) Eviter d'avoir un axe de permutation "locale" lors du process de compilation, ce qui permettrait de réduire le temps de compilation d'un facteur > 10.
B) Un autre permettre de compiler sans avoir à connaitre les locales qui seront supportée par l'équipe de traduction en aval.
Bref, le code marche en mode developpement avec le plugin eclipse, et si je change le ?locale=default en ?locale=fr, j'ai bien une locale en FR. Tout ce dont j'ai besoin dans mon code, c'est que com.google.gwt.i18n.client.LocaleInfo#getCurrentLocale() me retourne la locale en question et je me charge du reste. Et en dev ça marche.

Problème, lorsque je compile le code GWT en ne précisant pas de locale, quand je tappe ?locale=fr dans l'url, getCurrentLocale() me retourne default et non pas "fr". Du coup mon code peut se brosser en aval. La seule solution trouvée jusque là, c'est de déclarer toutes les locales possible (autrement dit on devra recompiler si on veut ajouter une locale dans le futur) à la compilation et d'utiliser

Code :

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

<collapse-property name="locale" values="*" />

pour éviter l'axe des locale.

C'est bien joli, mais du coup l'utilisateur pompe pour les composants de base de GWT une tartine de traductions donc il n'a pas besoin (même dans sa langue il n'en a pas besoin puisqu'on a besoin de ces messages de GWT). Est-ce que vous auriez une solution pour alléger le JS final ou pour pouvoir switcher vers une locale qui n'a pas été compilée, voir une procédure pour pouvoir ajouter des locales sans recompiler?

[adiGuba]

Salut,


Si ca marche en dev c'est sûrement que le compilo du mode dev rajoute automatiquement la locale en question en la compilant à la volée.
En production tu n'as plus que les locales que tu as compilé. (tu tournes sous quelle version de GWT au fait ?)



On a mis en place une solution pour pallier au premier point que tu soulèves, afin d'éviter d'avoir près de 50 permutations (on a 7 locales et 7 browsers avec ie6).
Pour cela il faut toucher au deferred-binding et aux Generators, et modifier le comportement de base.

Les Generators permettent de créer des classes à la compilation selon divers critères, comme la langue ou le navigateur.

En gros au lieu de générer une classe "MyMessages" par locale comme le fait GWT, on génère deux choses :

• Un unique classe "MyMessages" qui retourne les chaines d'un tableau.
• Un fichier json par langue, qui contient un tableau des différents messages de l'application.

(désolé je n'ai pas le code sous la main, donc pas d'exemple)

Au chargement de l'application, on télécharge ce fichier de langue avant de faire quoi que ce soit, et on le stocke en static afin qu'il soit visible.
Comme on utilise le collapse-property et un nombre fini de langue ca fonctionne.
C'est un petit peu plus limité car on ne peut pas utiliser toutes les options de formatage : java.util.Formatter n'est pas supporté par GWT, et j'ai eu la flemme de réécrire cela.
On se contente de vulgaire .replace("{0}", arg0) amplement suffisant pour notre besoin.


Sans définir de locale et en se basant sur des Map représentant les couples clef/valeur ca pourrait marcher...



Sans collapse-property et sans définir de locale ca risque d'être un peu plus compliqué :

• Il faudra utiliser autre chose que LocaleInfo.getCurrentLocale() pour déterminer la langue, car ce dernier interprètera la valeur et renverra toujours "default".
• Les classes DateFormat ou NumberFormat risque de poser problème, car pour les mêmes raisons elles ne s'adapteront pas à la locale...

a++

[tchize_]

Salut,


Si ca marche en dev c'est sûrement que le compilo du mode dev rajoute automatiquement la locale en question en la compilant à la volée.
En production tu n'as plus que les locales que tu as compilé. (tu tournes sous quelle version de GWT au fait ?)

C'est possible ça, on a des fichier dev spécifiques pour tester chaque module, possible que les locales y soient configurés, ce qui expliquerait la différence.

On a mis en place une solution pour pallier au premier point que tu soulèves, afin d'éviter d'avoir près de 50 permutations (on a 7 locales et 7 browsers avec ie6).
Pour cela il faut toucher au deferred-binding et aux Generators, et modifier le comportement de base.

C'est en gros ce que j'ai implémenté, sauf qu'au lieu de jouer avec un Generator, j'utilise le Dictionary et le ScriptInjector + changé tout ce qui étends ConstantsWithLookup dans notre code en une classe custom qui précise le json dont elle a besoin. Je dois encore améliorer ça mais c'est en gros réalisé. Mon soucis avec le collapse-property, comme je l'ai dit, c'est que les traductions de composants tiers qu'on utilise, eux, il sont tous dans le js généré et du coup, par exemple, le français hérite des noms de semaine / mois en russe, espagnol, polonais, ... utilisés par le formatteur de dates de GWT. Je dois encore faire des tests lundi, mais j'ai peur que le résultat soit une explosion de la taille du .js

Si je travaille avec un Generator comme toi, et que je le branche sur les interfaces i18n gwt plutot que les mienne, est-ce qu'il interviendra aussi sur les sous interface utilisées par les modules que je charge comme .jar? Dans ce cas là ça voudrait dire que ces mois/semaine etc pourraient aussi être transférés vers les .json. J'ignore comment marche la compilation GWT, est_ce que ça ne compile que mes source en .js et que ça y adjoint des .js précompilés venant des jar gwt, ou est-ce que lesjar gwt contiennent aussi les .java et que ces .java sont aussi recompilés par mon process de compilation?

Au chargement de l'application, on télécharge ce fichier de langue avant de faire quoi que ce soit, et on le stocke en static afin qu'il soit visible.

Quel mécanisme tu utilise pour ça? Tu met juste le chargement du json dans le jsp? Un truc qui m'ennuie avec GWT, c'est que je ne trouve pas comment lui dire proprement "tu fais rien tant que le composant de langue n'a pas chargé le json"
Pour le moment j'ai pris tout ce qui se trouve dans le "onload" des entrypoint de chaque module et je ai transféré ce code dans le "onsuccess" du script injector, mais je trouve ça très intrusif, je dois aller dans chaque module revoir la manière dont fonctionne son onload.

Se passer de LocaleInfo n'est pas une option, on utilise trop numberformat et dateformat dans le code, y a des dates et des nombres partout, ce sont des tableaux de bord


Tant que je te tiens, une question annexe. J'ai besoin, pour faire propre, que chaque module puisse lister les modules linguistiques dont il a besoin. Pas les langue, juste pourvoir dire "moi j'ai besoin des traductions pour la carte, les senseurs et le tracking, donc charge le sensor.json, le tracking.json et le map.json. Pour le moment, a nouveau, je liste ça les entrypoint et je trouve pas ça propre.

[adiGuba]

Mon soucis avec le collapse-property, comme je l'ai dit, c'est que les traductions de composants tiers qu'on utilise, eux, il sont tous dans le js généré et du coup, par exemple, le français hérite des noms de semaine / mois en russe, espagnol, polonais, ... utilisés par le formatteur de dates de GWT. Je dois encore faire des tests lundi, mais j'ai peur que le résultat soit une explosion de la taille du .js

Oui le collapse-property cumule les différentes classes dans une même permutation, donc si tu as 10 langues tu auras les 10 traductions dans chaque permutation.

On n'a pas ce problème puisqu'on n'a pas de traductions dans les librairie tiers qu'on utilise...

Si je travaille avec un Generator comme toi, et que je le branche sur les interfaces i18n gwt plutot que les mienne, est-ce qu'il interviendra aussi sur les sous interface utilisées par les modules que je charge comme .jar? Dans ce cas là ça voudrait dire que ces mois/semaine etc pourraient aussi être transférés vers les .json. J'ignore comment marche la compilation GWT, est_ce que ça ne compile que mes source en .js et que ça y adjoint des .js précompilés venant des jar gwt, ou est-ce que lesjar gwt contiennent aussi les .java et que ces .java sont aussi recompilés par mon process de compilation?

Sauf erreur les librairies tierces GWT contiennent les sources, et sont recompilé en même temps que l'application.
Donc en toute logique cela devrait utiliser ton Generator pour toutes les interfaces "Messages"...

A vérifier toutefois...

Quel mécanisme tu utilise pour ça? Tu met juste le chargement du json dans le jsp? Un truc qui m'ennuie avec GWT, c'est que je ne trouve pas comment lui dire proprement "tu fais rien tant que le composant de langue n'a pas chargé le json"
Pour le moment j'ai pris tout ce qui se trouve dans le "onload" des entrypoint de chaque module et je ai transféré ce code dans le "onsuccess" du script injector, mais je trouve ça très intrusif, je dois aller dans chaque module revoir la manière dont fonctionne son onload.

Je fais exactement cela, sauf que j'utilise un RequestBuilder plutôt qu'un ScriptInjector.
Encore une fois je n'ai qu'un seul fichier de langue donc cela ne me pose pas de problème...

Se passer de LocaleInfo n'est pas une option, on utilise trop numberformat et dateformat dans le code, y a des dates et des nombres partout, ce sont des tableaux de bord

Dans ce cas tu vas être obligé d'utiliser le collapse-property afin de fusionner plusieurs locales.
A moins que tu acceptes d'avoir le même formatage pour toutes les langues ("1,000.00" au lieu de "1 000,00" en français par exemple).

Tant que je te tiens, une question annexe. J'ai besoin, pour faire propre, que chaque module puisse lister les modules linguistiques dont il a besoin. Pas les langue, juste pourvoir dire "moi j'ai besoin des traductions pour la carte, les senseurs et le tracking, donc charge le sensor.json, le tracking.json et le map.json. Pour le moment, a nouveau, je liste ça les entrypoint et je trouve pas ça propre.

Non comme çà je ne vois pas de meilleure solution...


a++

[tchize_]

Ok, merci pour tout ces éclaircissements, je vais continuer dans le sens où je suis déjà parti et essayer de limiter l'intrusion dans les modules.