Author: [email protected]
Date: Wed Jun 3 13:14:07 2009
New Revision: 5499
Added:
wiki/DefaultLocaleBinding.wiki
Log:
Created wiki page through web user interface.
Added: wiki/DefaultLocaleBinding.wiki
==============================================================================
--- (empty file)
+++ wiki/DefaultLocaleBinding.wiki Wed Jun 3 13:14:07 2009
@@ -0,0 +1,52 @@
+#summary A design for "useful" default locale specification (and for
configuration properties in providers)
+
+= Introduction =
+
+Today, we will always generate a locale named "default", which is used if
your user agent asks for an unsupported locale (that is, any locale at all
if your app isn't internationalized, or if you internationalize for French
Canadian and German but your user asks for Japanese or Italian). We also
have a few generators that want to run in any single locale, which is
generally done by running only in default.
+
+So, in that default locale, what should be the currency symbol? There is
no good answer to that or other, similar questions.
+
+What we think we want is a way to specify that a given actual
locale---say, "fr_CA"---should be _used as_ the default locale if no better
answer can be negotiated. We might not even generate a "default" at all.
+
+Doing so, however, turns out to be more interesting than it may first
appear.
+
+
+= Usage Specification =
+
+I propose adding configuration property to I18N.gwt.xml, for
default.locale. It's a configuration property because it isn't used for
permutations; indeed, it shouldn't ever have multiple values. This would
be set to "default" by I18N.gwt.xml, but should be reset by user modules to
whatever locale they want to have as their default.
+
+So, I18N.gwt.xml would contain:
+{{{
+ <!-- Browser-sensitive code should use the 'locale' client property. -->
+ <!-- 'default' is always defined, but might not be set if -->
+ <!-- default.locale is used to specify an actual locale as default. -->
+ <define-property name="locale" values="default" />
+ <define-configuration-property name="default.locale"
is-multi-valued="false"/>
+ <set-configuration-property name="default.locale" value="default"/>
+}}}
+
+And my hypothetical app's .gwt.xml would contain:
+{{{
+ <extend-property name="locale" values="fr_CA,de" />
+ <set-configuration-property name="default.locale" value="fr_CA" />
+}}}
+
+= Implementation Requirements =
+
+The `AbstractLocalizableImpleCreator` code has to recognize generators
that operate only on "default," and decide based on whether
`default.locale` is or is not set and whether "default" is or is not in the
locales list whether and when to run a given generator; in this example,
the "fr_CA" permutation would run generators that run on all locales,
on "fr_CA" _or_ on "default". This requires access not to the defined
values (from `define-property` and `extend-property`), but to the set
values, which is currently inaccessible.
+
+More interesting changes happen in the property provider, which today can
access only selection properties _with multiple values_. I propose adding
access to configuration properties as well, using a template syntax in the
property provider JavaScript and token substitution in
`SelectionScriptLinker`, somethinglike this fragment from I18n.gwt.xml:
+
+{{{
+ while (!__gwt_isKnownPropertyValue("locale", locale)) {
+ var lastIndex = locale.lastIndexOf("_");
+ if (lastIndex == -1) {
+ locale = "/*-GWTCONFIGPROPERTY(default.locale)-*/";
+ break;
+ } else {
+ locale = locale.substring(0,lastIndex);
+ }
+ }
+}}}
+
+Note that this is a static substitution, because configuration properties
have fixed value, unlike selection properties. The substitution is used in
generated the selection script, so a request for locale "jp" will fail to
match known property values and be assigned "fr_CA" instead, as the
requested `default.locale`.
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
