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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
wrote:
>> >
>> >
>> > Arjuna Wijeyekoon wrote:
>> >
>> > > On 10/24/06, Adam Winer <[EMAIL PROTECTED]> wrote:
>> > >
>> > >>
>> > >>
>> > >> On 10/24/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]> 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
>>
>
