[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Hi Florent!


Florent Guillaume wrote:
> 
> yuppie wrote:
> 
>> 4.) Adding i18n support for settings loaded from profiles:
>>
>> This is the most difficult part and so far I just have some ideas.
>>
>> One issue is extracting message strings. I hope to find a way to use 
>> the i18n namespace in profile XML files. This would allow to use the 
>> standard tools.
> 
> You still would have to store this somewhere in the ZODB after the 
> loading, to allow the user to change the domains.

Sure. Talking about 'extracting' I just had creating *.pot files in mind.

For importing/exporting domain settings we have to extend CMFSetup and 
need new properties in the ZODB. Thinking a bit more about this we might 
have some trouble to write XML files containing i18n attributes. Is 
there an easy way to tell PageTemplateFile *not* to interpret i18n 
attributes?

>> The other issue is handling some settings like 'Title' and 
>> 'Description' fields as MessageIDs. AFAICS a first step would be 
>> adding a 'domain' field to Actions and TypeInfos. Don't know if we can 
>> just use the old attributes and return MessageIDs instead of strings 
>> or if we need new attributes. This depends on possible backwards 
>> compatibility issues.
> 
> Here we're talking about content or meta-content, right? So the i18n 
> problem is different than for the code -- you have to decide if a Title 
> field (for instance) is a msgid or not. Maybe an empty i18n_domain could 
> mean "don't translate", and a non-empty one would mean "translate using 
> this domain". Another option would be a checkbox is_i18n that would 
> change the interpretation of title/description from text to msgids. Or 
> you could have i18n_msgid and i18n_domain, that would be used if 
> i18n_msgid is not empty, otherwise the normal title field is used. They 
> are many choices. But you can't say by fiat that all Title and 
> Decription fields will become mandatorily i18ned, some people will want 
> to go in the ZMI and directly change action titles or description in 
> their own single language.

The only problem I see with making these fields i18ned are encoding 
issues. Besides of that your use case should work with msgids as well: 
If there are no translations the default string is used.

Nevertheless I like your idea to use an empty i18n domain for the 
backwards compatible "don't translate" mode.

If there are no important use cases for more fine grained settings I'd 
like to add *one* i18n_domain property per TypeInfo / Action and 
hardcode the set of properties that are delivered as msgids if 
i18n_domain is not empty.


Cheers, Yuppie