[Zope3-dev] There's something wrong with having message ids in schemas

[Jim Fulton]

Stephan Richter wrote:
> I largely agree with Martijn's response. Some more comments below.
> 
> On Wednesday 08 December 2004 07:56, Martijn Faassen wrote:
> 
>>Jim Fulton wrote:
>>
>>>I'd like to use a schema in zope.index.  But, if I do,
>>>I'll need to make the field titles and descriptions message ids.
>>>This has two problems:
>>>
>>>1. It makes zope.index depend on zope.i18nmessageid
>>
>>Can't Zope 3 message id imports go through some very small dummy package
>>which provides a dummy message id if i18nmessage id is unavailable? It'd
>>be less painful perhaps to have to just depend on that.
> 
> 
> Yes, I was about to suggest the same:
> 
> try:
>   from zope.i18nmessageid import MessageIdFactory
>   _ = MessageIdFactory('domain')
> except ImportError:
>   _ = unicode
> 
> This way you only have a soft dependence of zope.i18nmessageid

This pattern is a bug magnet.  It has been employed before
do deal with this situation (message ids) specifically and has
caused me a world of pain.

> 
>>>2. It forces me to pick a domain, which seems wrong.
>>
>>Why does this seem wrong? It's just the domain of the codebase the
>>schema is in, right?
> 
> 
> I agree with Martijn, selecting a domain is part of the I18n process. I have 
> two suggestions here:

I18n is presentation, IMO.  Here we are introducing presentation
code into code that is not otherwise about presentation.

> (a) Use a domain called "global" or "default" by default, to avoid specifying 
> a domain.

What does that gain.  We might as well not make a message id.

> (b) Use the module path as the domain by default.

I don't see what we gain here. We create a problem for
localization.  We'd have al of the translation domains that
have to somehow ne merged.

> 
>>>OTOH, there's a lot to be said for the convenience of
>>>having this information in the schema.
>>
>>Agreed. Introducing another layer might also introduce a lot of
>>developer complexity. We should be careful about that.
> 
> 
> I totally agree. Another layer would be a big burden on the developer and 
> anyone who wants to read the code, since they have to look in two places now.

Perhaps this layer could be optional.  Perhaps we'd use it in cases
where we have a schema that, for whatever reason, doesn't use
message ids (or titles or descriotions that we like).  In cases
where it's convenient not to have to create a separate component, perhaps
we'd do what we do now.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org