John, you absolutely have got a point there. But since these string replacement operations is relatively small, we haven't noticed any difference at all in performance by doing this.
The initial problem was due to compile time and permutations. We just launched a GWT application with 43 languages, which generates about 43*6(?) permutations, and to get 43 languages (where each language has about 800 text and 300 configuration properties) entirely correct, this would generate a whole bunch of extra builds and server downtime each time a country wants to change even a very small thing as a misspelling. Perhaps this is not very useful when an application is perfectly in shape, configured and all texts are flawless, but while in developing/staging state it has saved us weeks of development since the customer is now able to internationalize their application "live" at staging/pre-prod state via an I18N-servlet, without the need to translate blindly and wait for the re-build and re-deploy for each batch. Perhaps this is not a feature for the common GWT developer, but as stated, it is very nice to have for larger applications. On 20 Okt, 02:44, Bruce Johnson <[email protected]> wrote: > @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 -~----------~----~----~----~------~----~------~--~---
