On Tue, 5 Jun 2001, Michael Westbay wrote:
>
> But what kind of compexity are you looking at? Let's take a small example of
> languages and countries to cover:
>
> Languages: English, Spainish, Japanese
> Locales: U.S., England, Spain, Japan
>
> Now you need resources:
>
> en, en_US, en_UK, en_ES, en_JP
> es, es_US, es_UK, es_ES, es_JP
> ja, ja_US, ja_UK, ja_ES, ja_JP
>
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
>
> And most of the strings will be repeated over and over ad. nasuim.
>
I'm not totally caught up on this thread, so someone else might have noted
this already -- but the resource bundle classes do not (and our
validator mechanism should not, if based on locales) require repeating the
message strings in every single case. For example, if the current user
has selected locale xx_YY, the message will be looked up in
* xx_YY (if it exists), else
* xx (if it exists), else
* the default Locale for the server.
Thus, for messages and formats that are common to all English speakers
independent of location, should be placed only in the resources for the
"en" Locale.
> It seems to me that the target locale (meaning place) should be separate with
> some sort of formatted strings like "(###)###-####".
>
> Units of measure (dollars, yet, pesos) etc. can be localized in the language
> file, as well as display order. For example:
>
> Language_en.properties:
> usdollar_value=US$ {0}
> yen_value={0} yen
> peso_value={0} pesos
>
> Language_ja.properties:
> usdollar_value={0}ドル
> yen_value={0}円
> peso_value={0}ペソ
>
> This way, the formatting/format checking "0.00" or "#.##" can be written
> once, and used by all of the languagues.
>
> This still doesn't cover the problem with providing a choice of two
> currencies (as in the EC). Any suggestions?
>
It's also more complicated than that in another direction. If I've
selected the "en_US" Locale for myself, but I'm entering an address in
France, wouldn't I want to use the French postal code format strings? In
other words, validation formats for one field might depend on the data
content of another field.
> Michael Westbay
Craig McClanahan
