RE: New design documents

[Carl W. B. <cb...@xn...>]

Mark,

>
> - Possible approach to dealing with orthogonal types of resources
> http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/cumu
> lative_fallback.html
>
>

I was playing around with a variant if ICU (no pun intended) and started
testing the following:

I more realistic locale would be: "es_ES_EURO-TRADITIONAL"  This format
converts better into "es_ES@EURO-TRADITIONAL" or
"es_ES.iso-5589-15@EURO-TRADITIONAL" for POSIX compliance.

It would iterate as follows:

es_ES_EURO-TRADITIONAL              Exact variant combination
es_ES_EURO                          Locale variants
es_ES_TRADITIONAL
zz_ES_EURO                          Country variants
zz_ES_TRADITIONAL
es_ES
zz_ES
es_ZZ_EURO                          Language variants
es_ZZ_TRADITIONAL
es

I abandoned the idea on 1.4 because of the high overhead of reading new
bundles and building new hash tables.

You would only need the zz_ES_EURO bundle for all languages such as Spanish,
Catalan, Basque and Galician.  You would only need the es_ZZ_TRADITIONAL for
all Spanish dialects.  The locale data for Spain would be in zz_ES.  The
base Spanish would be in es.  The only reason that you might want a es_ES
resource is for LocaleID.  If you change the way that you generate LCIDs you
could get rid of a lot of bundles.  You also do not need the LocaleString.
In fact you have not been adding it to the new bundles.  You can get the
same information with ures_getLocale.

I will have to change my code that validates locales but that is doable.
Besides you get locales like "ca_FR" for free and it works for EURO.

If you have more than two variants you must decide if they are language or
country variants.  If they are both country or language variants then they
should be combined.

en_US_CALIFORNIA-NORTH

en_US_CAROLINA-SOUTH

This could be more of a mess than it solves.  Instead use :

en_US_NORCAL

en_US_SOUTHCAROLINA

One issue that concerns me it that there are limits to all other locale
fields but variant.  I would like a limit to the size of the variants.

Carl