[Zope3-dev] Re: Make message ids into "rocks", was Re: Re: SVN: Zope3/trunk/src/zope/ Internationalized apidoc modules description.

[Philipp von Weitershausen]

Godefroid Chapelle wrote:

>>> I am going to the Plone mountain sprint before the Vienna conference.
>>>
>>> One of the tasks I had set on my plate was integration of the Z3 
>>> message ids in Plone code. I have followed this thread with interest.
>>
>> Great! I really hope that Zope 3's message catalogues and Plone's PTS 
>> can come closer, too. For example, PTS could adopt the utility 
>> approach whereas Zope 3's i18n definitely needs the new awesome RTL 
>> support!
>>
>>> I'd really like to check if there will be any interface changes to 
>>> message ids (I hope not) or if the proposal is about internal 
>>> implementation only.
>>
>> Yes, there will be interface changes, and quite dramatical, so to say, 
>> because message ids will be rocks. That means the new message id 
>> implementation will differ semantically. This, no doubt, brings 
>> backward compatability issues along.
> 
> I had understood the semantics will change ;-)
> 
> OTOH, does that imply formal/python interface changes ?

Yes, especially in this case. Before you did:

   >>> msg = _(u"${name} is a robot")
   >>> msg.mapping = {'name': 'Bender'}

We need this operation (setting the msgid mapping) to return a new 
message id object. Since the assignment of the mapping attribute cannot 
do that, we need a new operation. There are only two ways to return a 
new object:

a) a method,
b) an operator overload.

Since the % operator is well known from string interpolation, such as:

   >>> msg = "%(name)s is a robot" % {'name': 'Bender'}

it seems natural do use this one.

>>> In case any implementation would been made before the sprint, I'd be 
>>> able to be one of the first beta testers ;-)
>>
>> Sorry, I tried to come up with a C implementation but my lack of 
>> experience in this matter made it take to long. So, I'll be looking 
>> over Jim's shoulder in Goldegg.
>>
>> I'll be writing a proposal soon (I expect over the weekend) which will 
>> include the new interface and cope with backward compatability issues 
>> as much as possible. The proposal will also be a doctest for the new 
>> implementation. So, even if we won't have an implementation ready, 
>> maybe you can give the proposal/doctest a read...
> 
> Looking forward to reading it.

Sorry, meant to reply ealier. You can read it at 
http://dev.zope.org/Zope3/TurningMessageIDsIntoRocks

STX gave me a hard time. The first row of example code is somehow not 
interpreted as such; you might want to refer to the source text of the 
wiki page.

Philipp