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

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to