+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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to