I am still confused as to why this is all an issue if the user can select
the languange of their choice. If it is an automatic thing, like if the
server is reading the preferred language strings in the header, then maybe
you have an issue becuase the Local is not selected by the user. It boils
down to what language the user wants to see the pages displayed in. Check
out the following sites: www.terra.com www.starmedia.com
http://www.dgolpe.com In each case the user SELECTS the language of choice.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 10:32 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> 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/
>
