Hey, +1 for getting rid of zope.app.locales as a centralized point for translations. +1 also to have a way to *see* the translations as a single whole, with the possibility to define a message id that is used by many packages. I'm not sure I get all the details. One question is whether packages that don't have any ZMI (such as zope.container) actually need translations at all? Should it define message ids at all? And if it does, wouldn't it be the job of the application that exposes these message ids to actually offer translations? In my mind, the Zope framework should offer facilities to support translating applications. These applications can be composed out of more than a single package, and we want to support the translation memory usecase for that. If the Zope framework defines messages itself itself, it should offer a way for an application that exposes them to have translations as well. The ZMI is simply a particular application on top of the Zope framework, and in my mind not actually the most important one to many of the users of the Zope framework. So let's not get caught up in a solution that really only focuses on the ZMI. Instead, let's consider the ZMI as a particular example of our problem. Oh, and once we get a policy fleshed out we should document it in our documentation section. :) Regards, Martijn