[Zope3-dev] Re: i18n domains vs. unique message ids -OR- whyShakespearean English was better

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen and Godefroid Chapelle are currently arguing on IRC, 
> that an XML namespace like i18n (as known in ZPTs) should be used.
> 
>   <permission id="zope.View" i18n:attributes="title" title="View" />

Yes, because:

  * why invent a new language; this forces people to learn a new little
    language with its own escaping rules. Someone messing about with
    i18n in ZCML is quite likely to be the same individual as the
    person messing about with i18n in ZPTs. You can expect a Zope developer
    working with ZCML to already know ZPTs.

  * the semantics of the i18n:attributes=".." etc can be picked up 
    by generic tools. You could have the same tool for extracting this
    information (to make a pot file) from ZCML as for ZPT. The proposed
    [whatever] notation does not leverage XML parsers as much.

[snip reference to voting that I didn't know was in progress :)]

> 1.) Namespaces have a different meaning in ZCML than in ZPT. In ZPT, 
> they 'hide' tal, metal and i18n commands from the xhtml namespace and 
> they are meant to be used as attributes. In ZCML, we use namespaces to 
> indicate different configuration domains, like 'zope', 'browser', 
> 'meta', etc.

This is dubious reasoning to me. Just because some namespaces are used
for one purpose doesn't mean other namespaces for other purposes
cannot be introduced.

For instance, in XHTML, there is also the idea you can use namespaces
for SVG and MathML and such. You can't go and claim you can't use those
as it's a different use of namespaces than TAL does, or the other way around. :)

Besides, in TAL the 'tal' namespace actually indicates conceptual
DOM tree manipulation (and definition), while the 'metal' namespace
refers to a macro language that operates differently, and 'i18n' contains
hints for i18n systems. So to me that's a clear example of using
different namespaces for different purposes already.

> 2.) Supporting this ZPT-like i18n namespace in ZCML would require 
> extensive changes to the ZCML XML machinery. One could argue that it 
> doesn't belong there. As stated above, schema fields contain all the 
> logic that is necessary to resolve the data provided in the XML 
> attribute. They are self-contained, so to speak.

Okay, this is an argument from implementation. I don't know how hard
this will be. But I figure a little hassle now will help users later
on.

Good semantics may make implementation easier. Easier implementation
does not however automatically lead to good semantics. :)

> 3.) Not every attribute would be allowed to be translated. In the above 
> example, the 'id' attribute would not be allowed, because it's a global 
> identifier. How would ZCML know that?

The same way as it would know about the [foo] syntax? Similarly ZCML
will have to know you cannot use the [foo] in the 'id' attribute.

> Maybe only allow MessageID fields 
> to be translated? Well, why not put that funcationally into the 
> MessageID field in the first place...?

I figure you can argue the same way for ZPT.

Regards,

Martijn