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

[Philipp von Weitershausen]

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.

Philipp