Just a question. Why dont you look at resolving validations the same way we
look resolving data in a database or parameter names? That is you dont
store the parameter names in i18n text, just the values. You dont store the
database columns as i18n column names, just the data. Maybe we could have a
"Local converter" which sees what local you are using, knows that text will
be entered in i18n, and converts the i18n form data into the default Local
format, THEN validate. What I'm saying is that we make a copy of the form
data, convert it first then validate, and a bad validation for a currency
separator would say in the persons language "you are missing a currency
separator", send back the original value that was copied along with the
error message in the persons language
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 8:54 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> 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/
>
