incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Re: Formatting locale vs. translation locale
Date Wed, 25 Oct 2006 18:39:06 GMT
Yes, and no... It depends on your users really. When I buy something from
USA I know how to enter the date because I'm used to it, all other sites
work that way.

If the site was somehow "intelligent" enough to see that I'm French Canadian
and to switch its date format accordingly, I would be quite lost if the
application was not giving any clue about the format used. However, new
Internet users will probably find it nice because they won't be used to
usual behavior.

My 2ยข,

~ Simon

On 10/25/06, Matthias Wessendorf <matzew@apache.org> wrote:
>
> Right!
>
> I am able to read english content, but I have no idea how english
> speaking guys enter their
> dates. Or more true, I don't care. In a *corperate* application, I am
> fine w/ reading english content, but want my German date format :)
>
> -M
>
> On 10/25/06, Gabrielle Crawford <gabrielle.crawford@oracle.com> wrote:
> > What's the problem with running in German with fr_ca formatting locale?
> > Basically if you're entering dates you want to let the user enter them
> > in the way they are used to, if the help can support it. If I'm German
> > and go to an English page, I think I would be quite happy if I could
> > enter the date, numbers, etc in the way I'm used to.
> >
> > I guess I think the reason locale was put on converters was to let users
> > format data in the way they are used to, even if the language/country is
> > different.
> >
> > Thanks,
> >
> > Gab
> >
> > Simon Lessard wrote:
> >
> > > It's true that en_US and en_GB can cause a problem. However this will
> > > hold
> > > true only if the language is the same. So, if we implements that maybe
> we
> > > can limit the valid formatting locales to those sharing the same
> language
> > > and only switch the country? That way it will be impossible to get in
> a
> > > state of German translation with fr_ca formatting.
> > >
> > > On 10/25/06, Gabrielle Crawford <gabrielle.crawford@oracle.com> wrote:
> > >
> > >>
> > >>
> > >>
> > >> Simon Lessard wrote:
> > >>
> > >> > I'm so divided on this issue that I think I'll call a +0 on my
> side.
> > >> > When I
> > >> > go on a site in English, I expect the date to be formatted
> > >> > accordingly. On
> > >>
> > >> I couldn't tell from the comment what you meant exactly. It may be
> > >> obvious when you switch languages, but you may not switch languages.
> If
> > >> I'm in the UK running in English I will expect UK date formatting,
> which
> > >> I think means day-month-year, and not month-day-year. I think it's
> > >> pretty subtle that you're actually running in en-us and not en-gb, I
> > >> don't expect the user to know that.
> > >>
> > >> > the other hand, some user are... well... hmmm... not so comfortable
> > >> with
> > >> > computers and could completely ignore that date can even appear in
> > >> > more than
> > >> > one format. Anyway, whatever decision is taken, I agree with Martin
> > >> that
> > >> > we'll need to indicate it clearly.
> > >>
> > >> So I suggested we use a config param, the default is 1, but you can
> 'buy
> > >> in' and set it to 2. What do people think of that?
> > >>
> > >> Thanks,
> > >>
> > >> Gab
> > >>
> > >> >
> > >> >
> > >> > Regards,
> > >> >
> > >> > ~ Simon
> > >> >
> > >> > On 10/25/06, Martin Marinschek <martin.marinschek@gmail.com>
wrote:
> > >> >
> > >> >>
> > >> >> I believe that #1 is what we should do. If you do #2, then the
> locale
> > >> >> will be changed away from what the view-root offers (and which
> might
> > >> >> be derived from the accept-header of the request, so you have
the
> > >> >> possibility to implement #2) somehow "automagically" - without
the
> > >> >> developer really knowing.
> > >> >>
> > >> >> - First (that's the same issue as you had) - existing applications
> > >> >> behave differently.
> > >> >> - Second - also as a user, I'm expecting US-date format when I'm
> > >> >> looking at an application I18nized in en-US. If you give me German
> > >> >> date formats, you'll need to indicate this clearly, and that's
> > >> >> something a developer has to do manually and consciously (except
> > >> >> Trinidad has some automatic way of indicating date, time and
> > >> >> number-format to the user). So as a German-speaking user, this
is
> not
> > >> >> the way I'd want the application to behave automatically.
> > >> >>
> > >> >> regards,
> > >> >>
> > >> >> Martin
> > >> >>
> > >> >> On 10/25/06, Gabrielle Crawford <gabrielle.crawford@oracle.com>
> > >> wrote:
> > >> >> >
> > >> >> >
> > >> >> > Arjuna Wijeyekoon wrote:
> > >> >> >
> > >> >> > > On 10/24/06, Adam Winer <awiner@gmail.com> wrote:
> > >> >> > >
> > >> >> > >>
> > >> >> > >>
> > >> >> > >> On 10/24/06, Arjuna Wijeyekoon <arjuna@gmail.com>
wrote:
> > >> >> > >> > I like #2 because:
> > >> >> > >> > 1. no new public apis.
> > >> >> > >>
> > >> >> > >> Maybe I didn't explain #2:  in either case, we have
a new
> public
> > >> >> > >> API.  There's no way to add this feature without
adding a
> public
> > >> >> API.
> > >> >> > >> The question is entirely what the behavior of that
public API
> > >> is.
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > ok, I see.  you will still need the
> > >> >> > > RequestContext.getFormattingLocale   but
> > >> >> > > not the setFormattingLocale.
> > >> >> > >
> > >> >> > >
> > >> >> > >> 2. correct behaviour out-of-the-box
> > >> >> > >>
> > >> >> > >> But what is "correct" behavior?  Is it the current
JSF
> behavior
> > >> >> > >> (formatting locale is always exactly translation
locale), or
> is
> > >> >> > >> it that formatting locale is always exactly the
user's
> locale,
> > >> >> > >> irrespective of the translation locale.
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > ok, I see the problem.
> > >> >> > > Personally, I feel that the user's locale is always
correct.
> > >> >> > > But if it is in conflict with the translation locale,
I am not
> > >> sure
> > >> >> > > what to
> > >> >> > > do.
> > >> >> > > Using a date field as an example, often there is a hint
> > >> >> underneath the
> > >> >> > > field
> > >> >> > > indicating what the pattern is.
> > >> >> > > does this hint come from a translation bundle? If so,
then it
> > >> >> would be
> > >> >> > > wrong
> > >> >> > > to use the user's locale instead of the
> > >> >> > > translation locale.
> > >> >> >
> > >> >> >
> > >> >> > That's a very good point. If they only have US
> translations,  the
> > >> help
> > >> >> > uses US formatting, now we come along and actually use UK
> > >> >> formatting, so
> > >> >> > the help is wrong.
> > >> >> >
> > >> >> > That does seem like a major problem for #2. Could we have
a
> config
> > >> >> > setting to switch on #2, because I think #2 is very useful,
but
> > >> maybe
> > >> >> > they need to buy in, it's still a much less painful buy in
than
> > >> they
> > >> >> > have now with the converter 'locale' attribute....
> > >> >> >
> > >> >> > Thanks,
> > >> >> >
> > >> >> > Gab
> > >> >> >
> > >> >> > >
> > >> >> > >
> > >> >> > >> 3. we won't get into a weird state where locale
is
> > >> english_uk, but
> > >> >> > >> someone
> > >> >> > >>
> > >> >> > >> > programmatically sets formatting locale to
english_us.
> > >> >> > >>
> > >> >> > >> That's a complete legal state;  maybe unusual, but
legal.
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > It is more than unusual.  It is completely wrong. If
I expect
> my
> > >> >> dates
> > >> >> > > to be
> > >> >> > > in (UK) dd-MM-yyyy, and I am actually getting
> > >> >> > > (US)  MM-dd-yyyy, that could cause me to miss my flight.
> > >> >> > > --arjuna
> > >> >> > >
> > >> >> > > -- Adam
> > >> >> > >
> > >> >> > >>
> > >> >> > >>
> > >> >> > >> > --arjuna
> > >> >> > >> >
> > >> >> > >> > On 10/23/06, Adam Winer < awiner@gmail.com>
wrote:
> > >> >> > >> > >
> > >> >> > >> > > Arash,
> > >> >> > >> > >
> > >> >> > >> > > ViewHandler.calculateLocale() is used
to set the Locale
> on
> > >> >> > >> > > the UIViewRoot;  so no conflicts really.
 They're
> different
> > >> >> > >> > > Locales.
> > >> >> > >> > >
> > >> >> > >> > > There's two possibilities here, though,
for the default
> > >> >> behavior:
> > >> >> > >> > >
> > >> >> > >> > > (1) RequestContext.getFormattingLocale()
defaults to just
> > >> >> returning
> > >> >> > >> null;
> > >> >> > >> > >   so, UIViewRoot.getLocale() - and, therefore,
> > >> >> > >> ViewHandler.calculateLocale()
> > >> >> > >> > > -
> > >> >> > >> > >   always wins, unless someone explicitly
calls
> > >> >> setFormattingLocale()
> > >> >> > >> for
> > >> >> > >> > >   a given request.
> > >> >> > >> > >
> > >> >> > >> > > (2) The formatting locale defaults independently
of
> > >> >> > >> > > ViewHandler.calculateLocale()
> > >> >> > >> > >   and the "supported-languages" list,
based on the user
> > >> agent
> > >> >> > >> "Accepts".
> > >> >> > >> > >   So, for example, if you only had English
as a supported
> > >> >> > >> language, a
> > >> >> > >> > > German
> > >> >> > >> > >   user would see English text, but German-formatted
dates
> > >> >> > >> out-of-the-box.
> > >> >> > >> > >
> > >> >> > >> > > I'm leaning towards #1, because it doesn't
change any
> > >> existing
> > >> >> > >> behavior,
> > >> >> > >> > > and even if we implement #1, and application
developer
> can
> > >> >> still
> > >> >> > >> choose
> > >> >> > >> > > to make an application behave like #2.
 But #2 is more
> like
> > >> how
> > >> >> I'd
> > >> >> > >> > > want my applications to behave...
> > >> >> > >> > >
> > >> >> > >> > > -- Adam
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > > On 10/23/06, Arash Rajaeeyan < arash.rajaeeyan@gmail.com>
> > >> >> wrote:
> > >> >> > >> > > > Hi adam
> > >> >> > >> > > >
> > >> >> > >> > > > I have some experience of using ADF
in countries which
> > >> >> English
> > >> >> is
> > >> >> > >> not
> > >> >> > >> > > > primary language and their software
needed to support
> more
> > >> >> than
> > >> >> > >> one
> > >> >> > >> > > language
> > >> >> > >> > > > at the same time.
> > >> >> > >> > > >
> > >> >> > >> > > > having a   RequestContext.getFormattingLocale()
looks
> > >> like a
> > >> >> nice
> > >> >> > >> idea
> > >> >> > >> > > to
> > >> >> > >> > > > me, and it makes it easier to add
internationalization
> and
> > >> >> support
> > >> >> > >> for
> > >> >> > >> > > > different locales to components.
> > >> >> > >> > > >
> > >> >> > >> > > > I think t is much better that components
act
> intelligently
> > >> >> > >> according
> > >> >> > >> to
> > >> >> > >> > > > their users clients.
> > >> >> > >> > > >
> > >> >> > >> > > > it would be great if you could be
sure this is no
> conflict
> > >> >> with
> > >> >> > >> method:
> > >> >> > >> > > >
> > >> >> > >> > > > abstract  java.util.Locale     calculateLocale(
> > >> >> > >> > > > javax.faces.context.FacesContext
context)
> > >> >> > >> > > >
> > >> >> > >> > > > in following class of 1.1 API:
> > >> >> > >> > > >
> > >> >> > >> > > > javax.faces.application.ViewHandler
> > >> >> > >> > > >
> > >> >> > >> > > >
> > >> >> > >> > > > On 10/23/06, Adam Winer <awiner@gmail.com>
wrote:
> > >> >> > >> > > > >
> > >> >> > >> > > > > JSF currently has support for
one Locale, off of
> > >> >> > >> > > FacesContext.getLocale().
> > >> >> > >> > > > >
> > >> >> > >> > > > > It's also possible to override
the locale on a
> > >> >> per-converter
> > >> >> > >> basis
> > >> >> > >> by
> > >> >> > >> > > > > explicitly setting the "locale"
attribute on various
> > >> >> converters.
> > >> >> > >> > > > > This is useful for cases when
you have, for example,
> > >> only
> > >> >> > >> translations
> > >> >> > >> > > > > into a limited set of languages
(for example, just
> > >> American
> > >> >> > >> English),
> > >> >> > >> > > but
> > >> >> > >> > > > > need to show users dates formatted
in the user's
> > >> locale so
> > >> >> > >> > > > > there is no accidental misinterpretation
of dates (
> e.g.,
> > >> >> British
> > >> >> > >> > > > > English or German).  I've gotten
some internal
> > >> requirements
> > >> >> for
> > >> >> > >> > > > > using this functionality, but
setting it on every
> single
> > >> >> > >> converter
> > >> >> > >> > > > > gets to be painful.
> > >> >> > >> > > > >
> > >> >> > >> > > > > To make this easier, I'd like
to expose a new Locale
> on
> > >> >> > >> > > RequestContext:
> > >> >> > >> > > > >
> > >> >> > >> > > > >   Locale RequestContext.getFormattingLocale()
> > >> >> > >> > > > >   void RequestContext.setFormattingLocale(Locale
> locale)
> > >> >> > >> > > > >
> > >> >> > >> > > > > ... and have the DateTimeConverter
and
> NumberConverter
> > >> >> overrides
> > >> >> > >> > > > > that Trinidad supplies automatically
default to the
> > >> >> formatting
> > >> >> > >> locale
> > >> >> > >> > > > > if it is set to a non-null value.
> > >> >> > >> > > > >
> > >> >> > >> > > > > Comments?
> > >> >> > >> > > > >
> > >> >> > >> > > > > -- Adam
> > >> >> > >> > > > >
> > >> >> > >> > > >
> > >> >> > >> > > >
> > >> >> > >> > > >
> > >> >> > >> > > > --
> > >> >> > >> > > > Arash Rajaeeyan
> > >> >> > >> > > >
> > >> >> > >> > > >
> > >> >> > >> > >
> > >> >> > >> >
> > >> >> > >> >
> > >> >> > >>
> > >> >> > >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> http://www.irian.at
> > >> >>
> > >> >> Your JSF powerhouse -
> > >> >> JSF Consulting, Development and
> > >> >> Courses in English and German
> > >> >>
> > >> >> Professional Support for Apache MyFaces
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message