[Zope3-dev] Re: Use case not covered for translation of message ids

Philipp von Weitershausen philipp at weitershausen.de
Wed Sep 29 04:51:21 EDT 2004


Stephan Richter wrote:

> On Tuesday 28 September 2004 10:10, Jim Fulton wrote:
> > As I've mentioned before, we could redefine message ids so that they are
> > not strings.  This would be a huge change that it would take time to
> > understand all of the implications of.  It *might* be a good change.
> > I'll
> > admit that I feel some discomfort in using message ids in schemas.  I
> > question whether the dubious benefit of implicit translation justifies
> > such
> > a huge change.  What *is* the benefit of implicit translation?  Does it
> > make anything possible that isn't possible now?
> 
> Shrug, I hope this never happens. Every other Open Source I18n system I know,
> uses message ids the same way we do. They do not translate in the same way 
> usually, since they are simple applications where there is only one user with
> one locale, so they are free to translate immediately in the app and do so.
> So in other applications making something a message id translates 
> immediately. Maybe this is the reason it feels so natural for Godefroid and
> Martijn to think about automatic translation. I like Zope 3's idiom though,
> which separates the declaration of something being translatable and actually
> translating something.

I absolutely agree. It is very natural to think of messages (the new spelling 
of message ids as of TurningMessageIDsIntoRocks) as strings with some added 
notion of a domain and an explicit identifier. Messages should be used whenever 
a system wants to display system-relevant text to the user (as opposed to 
content which is managed by the user itself).

IMO, we can easily apply the rule of separation of powers here. IMO, marking 
text as messages is the application layer's job, translating them is the job of 
the presentation layer. I realize that that isn't a fine line because all 
messages essentially are presented; I'm just thinking about the ISized adapter 
and similar use cases where a component that by itself has little to do with 
the presentation machinery returns user messages while some other component, a 
ZPT view for instance, displays them.

Summary: -1 for making messages not strings.

Philipp



More information about the Zope3-dev mailing list