Husted-san wrote:
> In this context, we would want the validators to be able to recognize
> _xx as the location (or have a super method that parsed that from the
> locale for them). This would allow us to continue to use the one session
> locale property to cover both situations.
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.
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?
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
