Ticket #13091 (confirmed PLIP)

Opened 21 months ago

Last modified 6 months ago

plone.app.multilingual

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

Seconder:

Motivation

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.

Assumptions

N/A

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

Deliverables

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

Documentation

Code

Tests

Risks

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.

Participants

Ramon Navarro [bloodbare]

Víctor Fernández de Alba [sneridagh]

Progress

Work is taking place.

Change History

comment:1 Changed 21 months ago by ramon

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

comment:2 Changed 21 months ago by ramon

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

comment:3 Changed 21 months ago by ramon

  • Description modified (diff)

comment:4 Changed 21 months 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 19 months 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 19 months 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 19 months 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 19 months 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 19 months ago by ramon

  • Cc ramon added

comment:10 Changed 17 months 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 17 months 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 17 months 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 16 months ago by kleist

  • Description modified (diff)

Updated link to Documentation.

Last edited 16 months ago by kleist (previous) (diff)

comment:14 Changed 10 months 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 9 months 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 8 months 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 7 months 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 6 months ago by davisagli

  • Description modified (diff)

Updated description to reflect my discussion with Ramon in Brazil.

Note: See TracTickets for help on using tickets.