Hanno Schlichting wrote:

As far as I understand there is really a bug. The code should deal with
the situation where msgid is a Message object. What it does right now is
to look up a translation for that Message object in the translation
domain of the current TranslationDomain (self). The line you mention is
part of the code that should make sure that the Message object is looked
up in its own domain instead, but as you noticed this never happens.

sx.translations has this bit:

        # MessageID attributes override arguments
        if isinstance(msgid, (Message, MessageID)):
            if msgid.domain != self.domain:
                util = getUtility(ITranslationDomain, msgid.domain)
                return util.translate(msgid,mapping,context,

There is even a test for this in tests/test_translationdomain.py
testMessageIDTranslateForDifferentDomain but it seems, it doesn't find
the problem.

Indeed, sounds like the test's author didn't make sure it failed before fixing this ;-)

OK, just so people know, I now have a sx.translations package which is complete and available as open source but which I haven't had a chance to release.

It has the following features:

- "translations" objects which implement both ITranslationDomain and ILanguageAvailablility

- a "missing" mode which spits out .pot to a specified file for any msgids that aren't found

Here's a sample ZCML snippet for configuring it from the tests:

<configure xmlns='http://namespaces.zope.org/zope'
  <configure package="zope.i18n.tests">
    <i18n:registerTranslations locales="./locale"

If anyone's interested in using this, please drop me an email, I'll likely get around of officially releasing it in early September but it is already live in a customer project so is seeing real world use ;-)



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to