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 16:32:46 GMT
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
> >>
> >
>
>

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