Husted-san wrote:
> 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 resources, but use different
> masks and picture tokens for different countries. [...]
Thank you. This clarifies that the language and location are separate,
eliminating the need to permutate all combinations.
> [...] We could put these in separate files, or just make them
> sections of the validation.xml.
>
> <picture-tokens locale="_au">
> tel = ## ######
> </picture-tokens>
One file to handle the world? That'd be nice. At first I was taken back by
the idea that some may just want to target a niche market and not need to
deliver throughout the world. But then, they wouldn't need this package,
either.
One question, what's the default fall-back? With the suffixes being added,
one could have no suffix as the fall back option. But what about
picture-tokens? locale="DEFAULT"?
> 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.
That was the point I was trying to make. You make it sound much better.
Thank you.
I don't mean to be patronizing, but l10n and i18n fascinates me. It presents
a number of interesting problems, many of which can be simulated and thrown
out before a design is decided on. It's just better to catch those problems
early on, so I'm trying to get a clearer picture of what you have in mind.
I feel the design is shaping up much more clearly now. Not done, but I can't
see any major stumbling blocks (at the moment). Thank you again for the
clarifications.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
