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
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
