It sounds like an alternative might be to have the compiler to spit out properties files full of key value pairs with one per locale. Naturally the compile would output shortened keys etc and record a mapping file. A tool would be made available to update just these text resources and the initial bootsrap code so it now picks up the newly updated files. The exiting use of cache files as much as possible would remain, but there would be less permuTation generated files.
Comments On 22/10/2009, at 8:14 AM, 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 -~----------~----~----~----~------~----~------~--~---
