On Wed, May 13, 2009 at 10:03 AM, Freeland Abbott <[email protected]>wrote:
> Why did I know you'd check in and respond before morning? ;-)
>
I get some of my best work done after midnight :).
> Sorry, I should have specified this: the idea is that for development you
> would generate only one locale permutation, namely "default," (i.e. as
> people tend to do now anyway), which would merely acquire useful bindings by
> the configuration property. My worry in pointing out that default was still
> there was for production, where we're losing an opportunity to prune 1 Nth
> of the permutations....
>
> Also, I think there are many other places that would need to be changed,
>> such as all the runtime locale handling. One complication is that classes
>> we don't control, such as user-supplied output formatters, would need to be
>> changed as well.
>>
>
Actually, the output formatters don't create the output file, so we could
handle all the changes before we run them.
> We're a little bit hosed either way there, though: either we are no longer
> generating default at all (and people who expected it lose), or we're lying
> to formatters and generators (saying that we're making default when we're
> really making the chosen default locale, and there is no literal "default"
> at all), or we, as here, generate default but with associations.
>
Let's think about how we would ideally like it to work in different use
cases, and then figure out how to make it fit into what we have:
- *locale selector*
You want to list only the real locales (ie, not default) and you want to
include the actual locale that is treated as the default in the list. This
implies we cannot simply map the chosen default locale to "default" (ie,
remove en_US from the list and have default mean the same thing as en_US).
- *translations/etc*
If you have no match for the requested locale, you want everything to
work exactly as if the user had requested your default locale, including
currency symbols, number formatting, translations, etc.
- *generated files*
- *You want to only generate the source messages to make available for
translation*
In this case, you want to be able to specify a fixed filename in
@Generate and have only a single locale. It would be better to have some
indication that the default locale should be used rather than having to
change all these annotations if the default locale changes, so
continuing to
use "default" there is good.
- *You want to export all translated messages into a different format,
perhaps for use by server-side code or other tools*
In this case, you generally are not going to list any locales, and you
will have a pattern for the output file name. You do not want a
"default"
file generated here which is identical to one of the other
files, though it
wouldn't be a big deal if it were generated.
- *user/library code using Localizable
*Users who have only used Localizable implementations shouldn't have to
modify their code to take advantage of a default.locale mapping. It should
just happen that Foo_en_US gets used if no other
- *other generators using locale*
Other generators that may have a locale reference from some external
source (such as an annotaiton) will have to be modified to handle this
behavior if they want it. I don't see any way around that to add new
functionality to code we have no control over. We can make it
easier like locale
= LocaleUtils.substituteDefaultLocale(locale) so the modification could
be minor.
I think this set of use cases argues for not including "default" in the list
of locales at all, but changing the locale property provider to return the
selected value instead of "default" as a last resort. Inside the i18n
generator, "default" would still be in the generated search list from
GwtLocale, but would need to be handled specially.
Applications that also localize things on the server would also benefit from
this (those with more complicated requirements are already going to define
their own locale property provider and do locale selection in the server).
Do you agree with this assessment?
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
