The validation framework uses the Locale object placed
in session scope for the user.
This is how the ResourceBundle works.
http://java.sun.com/j2se/1.3/docs/api/java/util/ResourceBundle.html
For example, if the current default locale is en_US,
the locale the caller is interested in is fr_CH, and
the resource bundle name is MyResources, resource
bundle lookup will search for the following classes,
in order:
MyResources_fr_CH
MyResources_fr
MyResources_en_US
MyResources_en
MyResources
I've made the validation framework work the same way.
You should define a general language before you start
defining specific ones unless you don't want someone
from another region to access you're resource because
it is too specific to that region. So if you create a
resource file for english then anyone from en_US or
en_JP will first look for a specific match, but then
will look for just the language.
David
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> 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/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
