I believe that would happen under the current model. The validate
servlet is keyed to the user's locale, and would returns the language
elements for that locale regardless of where the error originated.
The validator servlet understands that the properties may have different
labels in different locales, but the programtic property name remains
the same. The property may be "nomme", but the label may be "name" for
the EN locale.
Michael was pointing out that someone might select ES as their "locale",
since they speak Spanish, but may be living in California. So there
needs to be a distinction between language and location.
Jonathan Asbell wrote:
>
> 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/
> >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
