From adffaces-dev-return-1535-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Thu Oct 26 05:29:02 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 34454 invoked from network); 26 Oct 2006 07:24:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Oct 2006 07:24:03 -0000 Received: (qmail 15533 invoked by uid 500); 24 Oct 2006 21:37:07 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 15497 invoked by uid 500); 24 Oct 2006 21:37:07 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 15464 invoked by uid 99); 24 Oct 2006 21:37:07 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 14:37:06 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of awiner@gmail.com designates 66.249.92.171 as permitted sender) Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 14:16:47 -0700 Received: by ug-out-1314.google.com with SMTP id y2so1857933uge for ; Tue, 24 Oct 2006 14:16:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jeURzWQBy0Bq0eWuqWQjtAlpxfwhcY0pfG+LT3cOLfwnrOE5MW/Kpv13dCBwl9dIKOkrCI6ynyKugzz1wiMah2mzD29ZD8IeBIMDviJBJRd1W7+R0deyAT/tvUCHrYyLO8DaQ8YeLXfGuuyRquJ0Pu0ttMOuY2Ti77EKjIocyb4= Received: by 10.67.93.7 with SMTP id v7mr9216208ugl; Tue, 24 Oct 2006 14:16:25 -0700 (PDT) Received: by 10.67.99.17 with HTTP; Tue, 24 Oct 2006 14:16:25 -0700 (PDT) Message-ID: <6dac79b90610241416m50ae6310md7f8eed70104b946@mail.gmail.com> Date: Tue, 24 Oct 2006 14:16:25 -0700 From: "Adam Winer" To: adffaces-dev@incubator.apache.org Subject: Re: Re: Re: Formatting locale vs. translation locale In-Reply-To: <70a0d9080610240214j94c759am170f7185710efde6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6dac79b90610231324k63ba7f1fu5a33701307721783@mail.gmail.com> <70a0d9080610231357v698a2f2es4606296f150b850d@mail.gmail.com> <6dac79b90610231649w6b1666f3o1695907f92b1a95f@mail.gmail.com> <70a0d9080610240214j94c759am170f7185710efde6@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Arash, No, there isn't a conflict. Code looking for translations will all use UIViewRoot.getLocale(). BTW, for reading direction, we already have a RequestContext getReadingDirection() that can be overridden using trinidad-config.xml. -- Adam On 10/24/06, Arash Rajaeeyan wrote: > Hi Adam, > > let me clear that I think separating Formatting locale and translation > locale is a very good idea. > > there are lots of methods in JSF to get current locale, > my point is to make sure these methods don't return some thing in conflict > with each other. > for example we must make sure the other components on the page you mentioned > are not searching for German translation of texts. > > the same concept can also be extended to direction, users whose language is > written from right to left like Hebrew, Arabic and Farsi may prefer their > menu, trees, tabs, etc to be right aligned, and behave how they expect even > if the text is still in English. > for example scroll bars in left side is common in right to left languages, > and if your browser has put one scroll bar in left, and a JSF page displayed > in the browser has put scroll bar in right side of the page it becomes very > confusing. > > > > On 10/24/06, Adam Winer 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 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 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 > > > > > > > > > > > > -- > Arash Rajaeeyan > >