Ticket #13091 (closed PLIP: fixed)

Opened 4 years ago

Last modified 16 months ago


Reported by: ramon Owned by:
Priority: minor Milestone: 5.0
Component: Internationalization Version: 4.3
Keywords: Cc: ramon

Description (last modified by davisagli) (diff)

Proposer: Ramon Navarro Bosch



Talking about multi-language support in Plone is talk about Products.LinguaPlone. It's been the de facto standard for managing translations of Archetypes-based content in Plone through the years. Somehow its functionality never made its way into the Plone core. Nowadays, Plone faces the rise of Dexterity content types and its incoming adoption into the Plone core (4.3) and completing the transition to Plone default content types in Plone 5.

We think that Plone core needs to provide unified multilingual support out of the box.

plone.app.multilingual was designed originally to provide Plone with a whole multilingual story. Using ZCA technologies, it enables translations to Dexterity and Archetypes content types as well. Lately, the community is giving to PAM the love it deserves and it is getting mature enough for a 1.0 release.

LP also relied on monkey patching the catalog to enable multilanguage navigation, overriding the default language viewlet located in plone.app.layout and the portal_languages and its counterpart control panel view. We want to avoid all this as much as possible, providing more cohesion and coherency to multilingual components in Plone.

After some months of talks the main goal of this PLIP is to create an optional package that enables multilingual support OOTB but not installed by default. It's oriented to organize the actual mess of packages that are involved on multilingual. By default Plone should be with one language OOTB with support for multiple languages on content by activating plone.app.multilingual.



Proposal & Implementation

  • Replace PloneLanguageTool with a utility in plone.app.i18n that stores the same settings in portal_registry
  • Move the definition of the ILanguage interface from plone.app.multilingual to plone.app.i18n. This provides a standard way to get/set the language of a content item.
  • Move the language selector viewlet to plone.app.i18n, with an option to override it like now.
  • Mix plone.multilingual + plone.multilingualbehavior + plone.app.multilingual in a single package for plone5 support and maintain archetypes.multilingual as an optional package for archetypes support.
  • Add plone.app.multilingual as a dependency of Plone that is not activated by default
  • Add the option on a Plone Out of the Box to select more than one language so people doen't need to go to ZMI.
  • When p.a.m. is activated, enable the behavior for the types in plone.app.contenttypes


  • plone.app.multilingual 2.0
  • archetypes.multilingual 2.0
  • changes to plone.app.i18n





We have to plan carefully the migration process of the actual deployments using LP to PAM, and contemplate the scenario for those who still wants to use LinguaPlone along with PAM.

LP will need a refactor for adapt it to make it play nice with PAM. Otherwise, the changes to the core will collide with the LP monkey patches.


Ramon Navarro [bloodbare]

Víctor Fernández de Alba [sneridagh]


Work is taking place.

Change History

comment:1 Changed 4 years ago by ramon

  • Type changed from Bug to PLIP
  • Description modified (diff)

comment:2 Changed 4 years ago by ramon

  • Component changed from Unknown to General
  • Milestone changed from 4.x to 4.3

comment:3 Changed 4 years ago by ramon

  • Description modified (diff)

comment:4 Changed 4 years ago by kleist

  • Status changed from new to confirmed
  • Component changed from General to Internationalization

Please note that this "confirm" is just an administrative action in Trac, and does not really constitute anything.

comment:5 Changed 4 years ago by eleddy

  • Milestone changed from 4.3 to 4.4

We are considering this ticket for 4.4. The FWT is light on multi-lingual implementors so we are going to get some more opinions on this and get back to asap. tentatively approved for core.

comment:6 Changed 4 years ago by eleddy

Our main question at this point is why this should be in core. If there are monkey patches happening, can we just fix what needs to be fixed in plone to allow easy integration as an add on? What's that pain currently like?

comment:7 Changed 4 years ago by mborch

I disagree that this should be a core package.

It's a lot of code to maintain and I'm not sure if standards are being kept high enough. What's the benefit in having it as a core module? I think this needs to be established.

There's also an alternative in  collective.multilingual (shameless plug since I am the author).

But there's still an argument here that it's essentially a space that more than one add-on can exist (rather happily) in.

comment:8 Changed 4 years ago by ramon

After today talk, we been talking about this PLIP. And here are our point of view:

  • Multilingual support should be on plone as an option ( as iterate ) but out of the box. It's a more a common case using multilingual sites than iteare/discussion.
  • The actual plone.app.multilingual is designed to be a separate component and we want to change some parts of it in order to include on core:
    • Removing the catalog patch
    • Moving the external storage to catalog ( just the sore by itself and maintain the API adapters )
    • Moving to plone the ILanguage
    • Refactoring ( is involed on formlib to z3cform controlpanel ) control panel to integrate pam control panel, this should enable to have more than one language on the UI without translated content, right now is not possible throw plone control panel
    • Moving DX and AT staff to dexterity.behaviors and AT plone package.
    • merge plone.multilingual and plone.app.multilingual with the UI and policies in order to have a install profile for multilingual content enabled
    • Language Selector viewlet on plone.app.layout refactoring
    • Refactor PloneLanguageTool to registry and utility with bbb

This is the actual work we propose to go forward, based on pam.

If there is any better way to develop the dexterity UI with z3cform, it would be great to recieve help and learn more about that!

comment:9 Changed 4 years ago by ramon

  • Cc ramon added

comment:10 Changed 4 years ago by rossp

I think some sort of translation system should be in Plone core. Specifically it should be in core because it embarrasses us a lot when the so-called international CMS's translation support breaks and isn't fixed for a while after a major release. Keeping it in core adds shame based momentum to keeping it working.

Which implementation should be in core, however, is another question in my opinion. I'd like to see some discussion of the relative merits of p.a.m and c.m before I can really decide on a vote.

comment:11 Changed 4 years ago by ramon

Hey FWT,

We switched the core storage utility to catalog index to be more "core"-friendly and moved the language selector to async urls so they don't use render time on every page.

As I'm concern, it's released and used by a lot of sites (#320 downloads on pypi right now) on b3. Also pam aproach is more focused on having a high usability from the user point of view, it's our main goal.

For the DX implementation of the translation form maybe there are better ways and we can merge the c.m. implementation with p.a.m. if in any case is a better implementation.

comment:12 Changed 4 years ago by sneridagh

Hi Ross (and FTW team members),

I totally agree on the subject that Plone should have a full multilingual support OOTB. This was the main motivation for filling the PLIP and the hard work done in p.a.m.

However, I think the implementation choice is out of discussion just for one reason: c.m. does not support Archetypes, and it's stated that it's not supporting them on purpose, excluding it as an option for the core. IMHO the inclusion on c.m. from the FTW point of view only could happen on Plone 6, when it's stated that Plone will get rid of AT content types...

As Ramon said, if the FTW thinks that the DX multilingual implementation of c.m. is somehow better than p.a.m implementation, there will be no problem in merge it into p.a.m

comment:13 Changed 4 years ago by kleist

  • Description modified (diff)

Updated link to Documentation.

Last edited 4 years ago by kleist (previous) (diff)

comment:14 Changed 3 years ago by esteele

  • Milestone changed from 4.4 to 5.0

The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.

comment:15 Changed 3 years ago by ramon

  • Description modified (diff)

The goal of this PLIP has changed to create a clear multilingual scenario for plone 5.

comment:16 Changed 3 years ago by davisagli

I like the idea of turning PloneLanguageTool into configuration registry settings plus a utility, but I think this should stay in a core package like plone.app.i18n in case there are other add-ons that need to use it. (e.g. raptus.multilanguagefields)

The language selector should also probably stay separate from plone.app.multilingual...there may be cases where the site's content is language-neutral, but multiple languages are supported in the UI for editing.

comment:17 Changed 3 years ago by ramon

After talking with David we thought that the concret goals should be :

  • PloneLangaugeTool should be moved to plone.app.i18n
  • ILanguage interface should be on plone.app.i18n
  • LanguageSelector should ne on plone.app.i18n with an option to override it like now
  • Enable on p.a.m. installation the behavior for plone.app.contenttypes
  • Adding plone.app.multilingual as a shipped by default and installable on plone 5 bundle
  • Add the option on a Plone Out of the Box to select more than one language so people doen't need to go to ZMI.

comment:18 Changed 3 years ago by davisagli

  • Description modified (diff)

Updated description to reflect my discussion with Ramon in Brazil.

comment:19 Changed 18 months ago by khink

"PloneLangaugeTool should be moved to plone.app.i18n": In https://dev.plone.org/ticket/13283, plone.app.i18n is named as a candidate to be merged into CMFPlone. That makes sense to me. Why would we put that refactored PloneLanguageTool in plone.app.i18n?

comment:20 Changed 16 months ago by jensens

  • Status changed from confirmed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.