+1 for getting rid of zope.app.locales as a centralized point for
+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. :)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -