Good points, Michael.
Language is one thing, location is another, and right now Java i18n does
seem to infer location from language.
In practice, this says that if they choose country XX on a
contact form, then they should get the validations for country XX,
regardless of any global XX locale setting. Of course, the same
mechanism
could apply to any number of validations, where the selection on one
field affects what is valid in another.
My first inclination would be to provide a broad validation in the
FormSet (no letters in a telephone field (*)), and then perform a more
complete validation server-side by invoking a specific validator (if I
have one) for country XX.
Of course, it would also be cool to support dynamic controls, where if
they chose a different location (or whatever) on the form, the runtime
validations on other fields would also change.
-Ted.
(*) At least telephone numbers should be letter-free now. As a child
in the US, our telephone number was expressed as EXPORT 29156, which
resolved to 3929156. Apparently we could not be trusted to remember
7 numbers back then ;-)
Michael Westbay wrote:
>
> Husted-san wrote:
>
> > The validation.xml supports creating FormSets for different locales.
>
> Wait a second. You just said "locales" right? Yet what are Java locales
> used for? Language.
>
> I live in Japan, however, if I'm browsing in English, what kind of phone
> number am I going to get? Dose the web designer need to write a en_JP
> locale? How about Spanish speakers in California?
>
> The name "locale" has always bothered me with Java, because it tends to be
> used to define a language rather than a place. Yes, there are en_UK and
> en_US versions, but even those are for differences in language expressions
> more than location.
>
> Now, let's say that my wife, born in Mexico, raised in the U.S., and now
> living in Japan, is surfing the Web in Spanish, and wants to send a present
> to a friend in Brazil. She's asked to enter a zip code. What "locale" will
> be presented to her?
>
> Perhaps I missed something somewhere along the line where "locale" was
> differentiated from "language" resources. It's probably just a semantics
> problem as you all have probably been thinking all along that the checks are
> to be done based on the country that the user enters in a form, not the
> "locale" to which (s)he is surfing. But that'll be something else that one
> must keep in mind when solidifying a spec.
>
> Sorry, but even though "locale" is probably the correct word here, it's kind
> of confusing in the context of i18n in Java.
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home: http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/