search

plone / Products.CMFPlone

The core of the Plone content management system
https://plone.org
GNU General Public License v2.0
255 stars 191 forks source link

Plone 5.2.2: warning about potential translation related problems #3152

Open d-maurer opened 4 years ago

d-maurer commented 4 years ago

I file this issue to make you aware of "https://github.com/zopefoundation/Zope/issues/876": Under Python 3 (but not Python 2), the result of tal:content and tal:replace can be translated even though translation was neither requested via an i18n attribute nor was the result an i18n.MessageId.

The bug is almost always hidden because if there is no translation the translation result is the input - i.e. the result of "no translation". In typical cases, you want to translate if there is a translation available.

The bug happens only when the template is freshly compiled; it does not occur when the template comes from the chameleon cache. This means that a restart after template creation can be used as a workaround.

While it is very rare that the bug manifests itself, it likely can easily become an analysis nightmare when it does. Thanks to @viktordick for his thorough analysis.

d-maurer commented 4 years ago

"https://github.com/zopefoundation/Zope/pull/878" contains a fix for the problem.

d-maurer commented 4 years ago

chameleon has an extremely wide notion for "i18n message" (i.e. an object that gets automatically translated): anything which is not a string nor a number nor has an __html__ method; especially instances of classes derived from str are usually considered "i18n messages".

A translation function must be ready to handle any such object appropriately.

"https://github.com/zopefoundation/Zope/issues/876#issuecomment-662504447" reports for example that a Fileobject can be handed over to the translation function.

The translation function should return unchanged message ids with types it does not expect.