Thobias, Since this doesn't involve changes to GWT proper, have you thought about creating a google code project. I'm sure there are others who would like to use what you have created. And who knows, one day it might be included in GWT proper.
Thanks, Chris.... On Oct 21, 5:14 pm, Thoka <[email protected]> wrote: > I don't think that you guys are seeing the whole picture. By making > the string replacements part of the compiled code you actually bind > the internationalization into the code. Trust me, when a web > application is supporting 20+ languages, the translations will never > be absolutely flawless, and the JIT string replacements/formatting > that you are complaining about is a very small factor when dealing > with large applications. Compare the time taken for dynamically > creating, say 200 DIV elements within a DOM tree, with time taken for > replacing 2000 internationalized strings using "JIT" and you'll find > out that this is absolutely NO extra time spent and just a VERY small > overhead comparing to a web application with the strings compiled into > the nocache-files. > > In a perfect world, the texts would be flawless from project startup, > but when creating one major application per month to different > companies (using different translators) for 40+ languages, they won't > be flawless, even when going live due to dead lines. > > If nobody sees the business value with server side I18N, I'll rest my > case. > > On Oct 20, 6:08 pm, Ray Ryan <[email protected]> wrote: > > > On Tue, Oct 20, 2009 at 8:32 AM, John Tamplin <[email protected]> wrote: > > > On Tue, Oct 20, 2009 at 11:21 AM, Ray Ryan <[email protected]> wrote: > > > >> I'll bet a lot that the cross section of "40+ languages" and "nuanced > > >> pluralized translations" is vanishingly small. A first cut that simply > > >> required status quo for plurals support would still be a big win. Or for > > >> that matter I don't most apps would actually notice if their tiny > > >> handful of > > >> pluralized strings became a runtime entity instead of baked in. > > > > The problem is that it is more than just that. Take this for example: > > > > - "Folder name: {0} File name: {1}" in English > > > - "xxx {1} yyz {0} xkx" in some other locale > > > > The code generated is different and there is no piece of text in the > > > English output that can be changed to produce the other locale, and that > > > is > > > because we actually parse the format string at compile time. > > > Out of curiosity, could you post a sample of the generated code? > > > > If we instead just substituted those strings, you would have to have all > > > the format parsing code in the compiled output, which will be essentially > > > String.format. In addition, right now we just generate calls to > > > NumberFormat/DateTimeFormat for actual formatting and they parse their > > > pattern at runtime, but I have work in progress to move the parsing of the > > > pattern to compile time. > > > > Beyond this, there are things like: > > > > @DefaultStringValue("lb") > > > > String weightUnit(); > > > > and code that does if ("kg".equals(constants.weightUnit())) { weightFactor > > > = 2.2; } and then that factor would get inlined all over the codebase by > > > the > > > compiler where it is used. [Note, I don't recommend this pattern, but I > > > have seen it used]. > > > Ick. There are so many other ways to accomplish that, I don't see it as a > > valid use case for something that would likely be opt in. > > > > So, it isn't as simple as doing string substitution on the compiled > > > output. > > > Even discounting plural forms (and frankly, I think any properly > > > localized > > > app needs to use them), there are other cases where it would be rather > > > expensive to be able to do string substitutions on the compiled output. > > > > One possible approach would be extending the runtime locales approach > > > (similar to Bob's soft permutations) to cover Messages/Constants. That > > > way > > > the code is optimized for each one, but there is basically a switch for > > > the > > > proper implementation for the current locale, and that choice is made > > > once. > > > You still lose inlining and you are downloading code you will never > > > execute, but perhaps there could be some runAsync integration to reduce > > > the > > > download penalty. > > > > -- > > > John A. Tamplin > > > Software Engineer (GWT), Google > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
