Document Actions

#108: Use Zope3 MessageID's through FiveTranslationService

Contents

by Hanno Schlichting — last modified June 11, 2006 - 00:21

Starting with version 1.1 Five provides access to Zope3's TranslationService, but still falls back seamlessly to PlacelessTranslationService or Localizer. Using this FiveTranslationService allows us to use Zope3 MessageID's without any adjustments to PTS. Language negotiation will still be handled through PTS.

Proposed by

Hanno Schlichting

Proposal type

Architecture

Assigned to release

Plone 2.5

Repository branch

plip108-five-translationservice

State

completed

Definitions

Starting with Five 1.1 the FiveTranslationService can be found in Five/i18n.py. It mimicks Zope3 i18n machinery for Zope 2.
MessageID's are a core part of Zope3 and can be found in zope.i18nmessageid.
Future note: Starting with Zope 3.1 Messages will be introduced in Zope which are immutable MessageID's. For a short explanation look at http://svn.zope.org/Zope3/trunk/src/zope/i18nmessageid/messages.txt?view=markup.

Motivation

Zope3 Message ID's are an easy and future proof way to internationalize strings in Python code. As most of the current Python scripts need an overhaul regarding i18n it is easier and certainly much less waste of time to get this right straightaway, instead of using context.translate() calls everywhere.

This will be of even more importance as we move more functionality into Python code through the use of Five technologies as view classes, adapters etc.

Assumptions

Currently Zope 2.8.x ships with the Five 1.0 series which will most likely not change.

As the approach depends on the FiveTranslationService first available in Five 1.1, we will have to ship this as a dependency. Five 1.0 won't be a supported platform.

Proposal

Note that the original scope of this proposal has changed :)

Use MessageID's in CMFPlone to i18nize any text in Python code. This will remove all 'translate()' calls in favour of this new approach.

Benefits of this approach are:

Using the new syntax all these messages are automatically extractable by tools like i18ndude, which will greatly reduce the time needed for keeping the manually extracted list of all these texts up-to-date.
You can use these MessageID's at places where you have no access to the translation service, for example for type names or descriptions. As this way these have a translation domain attribute it will be possible to have any text in a product specific domain, not requiring add-on products anymore to put some texts into 'plone'-domain.

Not covered anymore in this proposal is the move to a new folder layout (locales instead of i18n) and thus the move to not using PlacelessTranslationService anymore. This should be considered for the Plone release following the one this PLIP is implemented in but will require some extra work worth its own PLIP.

Implementation

The implementation is pretty straightforward. In __init__.py we added:

# Import "PloneMessageFactory as _" to create message ids in the plone domain
# Zope 3.1-style messagefactory module
# BBB: Zope 2.8 / Zope X3.0
try:
    from zope.i18nmessageid import MessageFactory
except ImportError:
    from messagefactory_ import PloneMessageFactory
else:
    PloneMessageFactory = MessageFactory('plone')

and provided a small messagefactory_.py with the wrapper for the old MessageIDFactory API. By adding this little wrapper instead of using the old API directly, we are able to use the immutuable Message syntax now, so we won't have to touch any scripts when we can finally require Zope versions including Zope 3.1 or higher.

In all Python code files where a text needing translation is found, we have to add a:

from Products.CMFPlone import PloneMessageFactory as _

Now this enables us to write something like:

message = _(u'title_not_copyable', default=u'${title} is not copyable.',
            mapping={u'title' : context.title_or_id()})

The actual translation will happen at the PageTemplate level triggered by the usual i18n:something statements.

This way it will finally be possible to have type titles or action names in the own product domain, not requiring two pot files per product for product-domain and plone-domain anymore.

Risks

This move will break backwards compatibility, requiring Zope 2.8 with at least Five 1.1, so we won't be able to move all 'Plone Core' products to this new approach at once.

As this new approach requires unicode in all cases we might hit even more UnicodeDecodeErrors as we currently have, but these obviously have to be fixed :)

Progress log

All Python code (scripts, tools, ...) have been converted to use MessageID's.
All existing tests pass (AT, ATCT, Plone, ...).
Written some new tests to explicitly test the MessageID translation.

Participants