Re: I18N with drop-in languages
Thanks.
As a brief related question, since the eval() function is slower than
native JSON support, does that mean it is faster to do
var i18nString = "{ /* some JSON */ }";
var i18n = JSON.parse(i18nString);
or
var 18n = { /* some JSON */ );
Or would the prior be faster and just use more memory?
On Jun 26, 10:10 am, Thomas Broyer wrote:
> On 26 juin, 15:40, Jason wrote:
>
> > Thanks for the tip; I think that's what I'm going to end up doing.
> > I'm just worried that since we're using an in-house library with
> > localized strings as well, I may be downloading strings that I don't
> > need. Not the end of the world, but I was wondering if anyone had
> > some better solutions.
>
> If you really worry about this, then you could make your own Constants
> interface with a generator to generate code that calls the Dictionary
> *and* emit the list of keys that you are actually using in the app.
> Then, use whichever language your want to make a script/program that
> builds the "dictionary JS file" from that file and the localized
> strings, keeping only the keys that are actually used by the app.
> Before deploying a new/modified locale, just run the script to make
> sure you're not deploying more localized strings than needed.
> (of course, the "script" might be the thing that respond to HTTP
> requests and generates the javascript "on the fly")
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: I18N with drop-in languages
On 26 juin, 15:40, Jason wrote: > Thanks for the tip; I think that's what I'm going to end up doing. > I'm just worried that since we're using an in-house library with > localized strings as well, I may be downloading strings that I don't > need. Not the end of the world, but I was wondering if anyone had > some better solutions. If you really worry about this, then you could make your own Constants interface with a generator to generate code that calls the Dictionary *and* emit the list of keys that you are actually using in the app. Then, use whichever language your want to make a script/program that builds the "dictionary JS file" from that file and the localized strings, keeping only the keys that are actually used by the app. Before deploying a new/modified locale, just run the script to make sure you're not deploying more localized strings than needed. (of course, the "script" might be the thing that respond to HTTP requests and generates the javascript "on the fly") --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: I18N with drop-in languages
Thanks for the tip; I think that's what I'm going to end up doing. I'm just worried that since we're using an in-house library with localized strings as well, I may be downloading strings that I don't need. Not the end of the world, but I was wondering if anyone had some better solutions. On Jun 26, 4:50 am, Thomas Broyer wrote: > On 25 juin, 17:11, "Jason.Sadler" wrote: > > > > > > > Hello all, > > I have a fair bit of experience with GWT but am by no means an expert > > - I have a question about I18N. > > I am trying to introduce GWT UIs into a very large existing web > > application where there is a requirement that language packs be > > installable by the administrator of the web app. > > Using static I18N like Messages and Constants is (at least on the > > surface) not tenable because it requires a recompile every time a > > locale is added or edited, and I'm not willing to make the GWT SDK (or > > Java, for that matter) a server-side requirement. I suppose I could > > make some modifications to the bootstrap process to support hot- > > swapping of localized compiled JS in and out of the server. This > > would obviously require getting rid of the strong hashing naming stuff > > that gets applied to the GWT JS files, and I think this would require > > a significant amount of work. > > Going with the dynamic Dictionary method is also not ideal since the > > app is very large and so a lot of strings might have to be downloaded > > each time the page is loaded. > > How is it different than GWT-I18N? > > If I were you, I'd use Dictionary and have the JS dict loaded in an > external JS that's cacheable (if you can include some sort of "version > number" in the URL, then use "inifinite caching" just like with your > *.cache.html generates files). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: I18N with drop-in languages
On 25 juin, 17:11, "Jason.Sadler" wrote: > Hello all, > I have a fair bit of experience with GWT but am by no means an expert > - I have a question about I18N. > I am trying to introduce GWT UIs into a very large existing web > application where there is a requirement that language packs be > installable by the administrator of the web app. > Using static I18N like Messages and Constants is (at least on the > surface) not tenable because it requires a recompile every time a > locale is added or edited, and I'm not willing to make the GWT SDK (or > Java, for that matter) a server-side requirement. I suppose I could > make some modifications to the bootstrap process to support hot- > swapping of localized compiled JS in and out of the server. This > would obviously require getting rid of the strong hashing naming stuff > that gets applied to the GWT JS files, and I think this would require > a significant amount of work. > Going with the dynamic Dictionary method is also not ideal since the > app is very large and so a lot of strings might have to be downloaded > each time the page is loaded. How is it different than GWT-I18N? If I were you, I'd use Dictionary and have the JS dict loaded in an external JS that's cacheable (if you can include some sort of "version number" in the URL, then use "inifinite caching" just like with your *.cache.html generates files). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
I18N with drop-in languages
Hello all, I have a fair bit of experience with GWT but am by no means an expert - I have a question about I18N. I am trying to introduce GWT UIs into a very large existing web application where there is a requirement that language packs be installable by the administrator of the web app. Using static I18N like Messages and Constants is (at least on the surface) not tenable because it requires a recompile every time a locale is added or edited, and I'm not willing to make the GWT SDK (or Java, for that matter) a server-side requirement. I suppose I could make some modifications to the bootstrap process to support hot- swapping of localized compiled JS in and out of the server. This would obviously require getting rid of the strong hashing naming stuff that gets applied to the GWT JS files, and I think this would require a significant amount of work. Going with the dynamic Dictionary method is also not ideal since the app is very large and so a lot of strings might have to be downloaded each time the page is loaded. Has anyone done hot-swappable I18N in GWT before? Any tips? Thanks, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
