Hanno Schlichting wrote:
Laurence Rowe wrote:
Quite a lot of zope3 code (zc.datetimewidget for instance) expects to be
able to access request.locale. ZPublisher does not provide this and to
get around the limitation you must manually set request.locale in your
view using Products.CMFDefault.formlib.form.getLocale. This seems
brittle. I think it would be desirable to include such functionality in
Zope 2. If there is support for this, where should it go?
ZPublisher.HTTPRequst or somewhere in Five seem like prime candidates.

My suggestion on this would be to make request.locale available in Zope
2.11. It would not be available through any of the other means like
request['locale'] or request.form['locale'] but just as a simple
property on the request itself.

You would still be able to override it, but the set method for it would
emit a deprecation warning telling you that you should not use this
specific name anymore.

The only backward incompatible change this would introduce from what I
can tell is that checking for the presence of request.locale would
suddenly give you a true value whereas it would have raised an error
before. Given the unlikelihood of this and the major benefit of being
able to use more unchanged Zope3 code, I personally would find this


Is there maybe a way we can grep the major sources (Zope 2, CMF, Plone, Silva) to look for uses of request.locale and see if this really is a big problem in practice? Or, of course, make the change in a branch and try to look for deprecation warnings.

As we're making more of an explicit effort to use Zope 3 components, including UI ones, it seems to me that what Hanno is proposing introduces an acceptable risk and a clear migration for those who were using request.local (just use request['locale'] instead).


Acquisition is a jealous mistress

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to