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 -~----------~----~----~----~------~----~------~--~---
