[Zope3-dev] Re: Adapter that determines request.locale is hard-wired

[Philipp von Weitershausen]

Philipp von Weitershausen wrote:
> Hello all,
> 
> I've discovered a problem in the way zope.publisher chooses the 
> request's locale object (accessible via request.locale).
> 
> In an ideal circumstance, the number of languages that a user client 
> prefers (in order) is retrieved by adapting the request to 
> IUserPreferredLanguages. The language negotiator in zope.i18n does so, 
> for example. When choosing the appropriate locale object for the 
> request, the request is not adapted to IUserPreferredLanguages, though, 
> but the default implementation (zope.publisher.browser.BrowserLanguages) 
> is hard-wired, making it impossible to override the negotiation of the 
> locale (this takes place in zope.publisher.http.HTTPRequest.__setupLocale).
> 
> I have a good example that demonstrates this. My book website, 
> http://worldcookery.com, runs on X3.0. I have overridden the 
> IUserPreferredLanguages adapter to always return 'en' as the preferred 
> language (see the downloadable source of the website software if you 
> want to double-check). So, for mere translations, the browser's 
> Accept-Language header is totally ignored, which is what I want. Now pay 
> attention to the *News* section on the front page. Every news item has a 
> creation date that is shown. I used the locale's date formatter to 
> present the datetime object returned by the DublinCore adapter. If the 
> locale would use my custom IUserPreferredLanguages adapter to choose the 
> locale, the date formatting would always be according to the default 
> (U.S.) locale. But it isn't. Try setting your browser's preferred 
> language to German. You'll see the date format changes.
> 
> So, I propose to turn that hard-wiring into an adaption to 
> IUserPreferredLanguages. I'll make that change some time next week if 
> noone objects.

Actually I had time today and nobody objected, so I went ahead with the 
fix. It's in now (r29779).

Philipp