One way to go would be to support a second set of resources, named for
the country-code portion of the locale (_us, _ca). These would all have
the same properties, just like the language resoruces, but use different
masks and picture tokens for different countries. So we might have
something like
_us
tel = (###) ###-####
post = #####[-####]
_ca
tel = (###) ###-####
post = #@# @#@
_au
tel = ## ######
and so forth. We could put these in seperate files, or just make them
sections of the validation.xml.
<picture-tokens locale="_au">
tel = ## ######
</picture-tokens>
In practice, an i18n application like this would probably start with a
broad set of default validations, and ask the user to indicate their
location (country code), and then apply the appropriate server-side
validation or transformation based on that.
Mixing country-code resources in with language resources would not be
useful, since the core point of the language resources is that you can
hand it over to a translator, and the country-code resources would not
need to be translated by that person.
Michael Westbay wrote:
>
> 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/
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
