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

[Shane Hathaway]

Philipp von Weitershausen wrote:
> Shane Hathaway wrote:
>> - Every i18n-aware string in ZCML files should be contained in an 
>> attribute called "text".  All message IDs should be in an attribute 
>> called "msgid".  This makes it easy to write a tool that scans for 
>> translatable strings in ZCML.
> 
> 
> This means you're turning nearly every attribute into subelements. That 
> makes it harder for the machinery to figure out what needs to be passed 
> to the directive handler. Same applies for schema definitions.

Ok, but I'm only looking at configuration file readability right now.

>> Incidentally, another rule I'm introducing is that all Python dotted 
>> names should use the same XML attribute, "src".  This will make it 
>> easier to recognize and find dotted names.
> 
> 
> You're basically introducing new semantics with some strong rules like 
> special namings of attributes. I'm not sure I like that.

Is there a reason *not* to use fixed attribute names?  I think it would 
help readability significantly.  For instance, when I see 
'src="zope.Foo"', I'd know that the file imports zope.Foo, but when I 
see 'id="zope.Foo"', I'd know that it doesn't.  Right now it's hard to 
tell which attributes represent imports.

>> In general, I want ZCML to be more modular.  I don't know how well the 
>> current ZCML machinery would support this, but I'd rather ignore 
>> implementation issues for now.
> 
> 
> You would have to define 'modular' a bit more. ZCML can be fairly well 
> extended with new schema fields. There are complex directives that have 
> subdirectives; even new metadirectives can be defined, as the 
> zope.configuration.backward module demonstrates.

Modular in the sense that developers learn a few concepts, then reuse 
them in many kinds of directives.

> Making the semeanics you suggested above work would require some 
> modification to the xmlconfig machinery, though.

Yes, it probably would.

Shane