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