Ticket #8907 (closed Bug: fixed)

Opened 8 years ago

Last modified 7 years ago

Archetypes ignores the language tool's use_combined_language_codes setting

Reported by: davisagli Owned by:
Priority: critical Milestone: 3.3.5
Component: Archetypes Version:
Keywords: Cc: hannosch

Description (last modified by davisagli) (diff)

Archetypes builds its vocab for the 'language' field (in ExtensibleMetadata.py) by getting a IMetadataLanguageAvailability utility and calling its getLanguageListing method. (The standard implementation of this utility is in plone.i18n.locales.languages.) getLanguageListing takes an optional 'combined' parameter which determines if country-specific language variants should be included. In Plone we want to pass that parameter based on the use_combined_language_codes attribute of the portal_languages tool, but that's not happening. Do you have any thoughts on the best way to fix this without tying Archetypes to the PloneLanguageTool?

This becomes a particular problem when the use_combined_language_codes is True, and some country variants of languages have been selected in the language configlet. Then when you try to make a new translation into one of those languages using LinguaPlone, the new language does not appear in the Archetypes-generated language field selectbox, so the browser defaults the field to language neutral (empty string) and when the new translation gets submitted its association with the original item gets clobbered, and the new translation thinks it's canonical.


ExtensibleMetadata.py.patch Download (1.0 KB) - added by erico_andrei 7 years ago.
Gets the value of use_combined_language_codes from portal_languages and pass it as argument to getLanguageListing (MetadataLanguageAvailability)

Change History

comment:1 Changed 8 years ago by davisagli

  • Description modified (diff)

comment:2 Changed 8 years ago by limi

  • Priority changed from major to critical

As this effectively breaks LinguaPlone, I think David is a bit modest with the priority here. ;)

comment:3 Changed 8 years ago by hannosch

There are persistent variants of these utilities defined in for example:


Those are set up via componentregistry.xml inside CMFPlone.

I think it would be fine to introduce a dependency from plone.app.i18n on PloneLanguageTool and let those utilities return a combined result based on the setting in the language tool.

This is a bit of a mess, as the persistent utilities in plone.app.i18n where always meant to actually store the language information instead of the language tool, but I never got around to implementing that.

comment:4 Changed 7 years ago by davisagli

  • Owner davisagli deleted

Changed 7 years ago by erico_andrei

Gets the value of use_combined_language_codes from portal_languages and pass it as argument to getLanguageListing (MetadataLanguageAvailability)

comment:5 Changed 7 years ago by erico_andrei

  • Status changed from new to closed
  • Resolution set to fixed

Proper tests and fix commited to trunk and to branch 1.5

Note: See TracTickets for help on using tickets.