Is there something smaller than a full JDK-compatible String.format that would work? Dan
On Tue, Oct 20, 2009 at 11: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. 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]. > > 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 -~----------~----~----~----~------~----~------~--~---
