@Thobias: I want to make sure I'm understanding the root motivation. Is the problem that compiles are taking too long when you create permutations per locale? Perhaps the more fundamental question I should ask is: would you describe exactly what's unserviceable about the current static approach that John just mentioned?
On Mon, Oct 19, 2009 at 7:57 PM, John Tamplin <[email protected]> wrote: > On Mon, Oct 19, 2009 at 5:23 PM, Thoka <[email protected]> wrote: > >> We've been building GWT application for about 3 years now, and we've >> reached the point where compiling the internationalization strings >> into the WAR file is no longer servicable. Today the GWT I18N support >> is primarly based on Constants and Messages which is solely built on >> Java property files. >> >> How ever, we've solved this issue by putting the internationalization >> settings on the server side and by fetching these strings remotely via >> JavaScript documents. This works perfect, as we now are able to (even >> in live environment) change internationalization files without re- >> compiling the entire project and without even restarting the tomcat >> service. >> > > Realize the big cost you are paying: > > @DefaultMessage("You have {0,number,#,##0} > items totaling {0,number,currency}") > @PluralText({"one", "You have 1 item costing {0,number,currency}"}) > String getCartTotal(@PluralCount int items, double total); > > Gets converted into essentially the following: > > String getCartTotal(int items, double total) { > switch (DefaultRule.select(items)) { > case 1: return "You have 1 item totaling " > + NumberFormat.getCurrencyFormat().format(total); > default: return "You have " + > NumberFormat.getFormat("#,##0").format(items) > + " items totalling " + > NumberFormat.getCurrencyFormat().format(total); > } > } > > And things get inlined/optimized from there. If you were to fetch the > format strings from the server at runtime, you would have to include code to > parse the format string in the runtime as well. That code gets large -- > which is why String.format isn't currently included in GWT's JRE emulation. > If you wanted to allow the server strings to have plural support, then you > even have to add extra work in the client and download multiple format > strings for each message. > > Having to deploy a new compiled application when you make changes to > translations doesn't seem a large cost compared to the huge savings by doing > more work at compile time rather than at runtime. > > Much of the work on GWT is to be able to do more things at compile time > rather than runtime and this is a good example. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
