[Framework-Team] plone.app.multilingual

[David Glick (Plone)]

My thoughts below...

On 1/29/13 1:21 AM, Ramon Navarro Bosch wrote:

> So, what we began to implement on plip-13091 branch:

Which package is this a branch of? Links would be useful so I can look 
at the implementation.

> * Define where ITranslatable interface should be, we've been talking 
> with timo about it, contenttype ? CMFPlone ? multilingual ?

It should be somewhere content-type-agnostic if you want to use it for 
different content type systems. So not plone.app.contenttypes. And 
probably it should be in core so items with the interface applied 
directly don't break if some add-on is removed. CMFPlone or 
plone.app.content is probably a good place.

> * Join Selector Viewlet so it's the same viewlet with different 
> policies depending on if multilingual is installed [implemented]

I found this at 
https://github.com/plone/plone.app.i18n/compare/master...plip-13091.

I like making the viewlet be a thin layer that uses an adapter to look 
up what languages are available. But I would organize things a bit 
differently. This needs to get rewritten so we aren't using the language 
tool. In that world we'll probably have a utility or adapter that 
provides methods similar to what the language tool provides currently 
(i.e. getLanguageBindings, getAvailableLanguageInformation, 
getSupportedLanguages). The "language" method of your "SelectorAdapter" 
probably belongs on that utility or adapter. And the "urlForLanguage" 
method probably belongs on an adapter of ITranslatable, since it has to 
do with a particular translatable item.

>
> * Join Language Control Panel, add again the option to select multiple 
> languages and a negotiation policy checkers so user can select how to 
> decide the language of the site

I found this work at 
https://github.com/plone/plone.app.controlpanel/compare/master...plip-13091-pam.

It would be nice to get the settings actually moved to 
plone.app.registry so we can get rid of the Language Tool.

Some of the negotiation settings are fairly advanced and won't work 
without more configuration outside Plone (i.e. serving languages based 
on subdomains). IMHO we should probably only include the common ones in 
the Language control panel, and document the rest as advanced options 
that can be found in the registry.

> * Define a way to get/set the language on contenttypes that is over 
> all the content types, somethign like an ILanguage adapter.

Seems to me like this should be part of the ITranslatable interface 
rather than inventing something else. If something is translatable, part 
of that is being able to get/set its current language.

> * Join vocabularies that are on plone.app.i18n and multilingual

What needs to happen here exactly?

> * Find a way to have a shared folder for language independent content 
> friendly with plone and without the need to have a patch on the 
> catalog ( with the LRF the patch on the catalog is not needed any more )

We can just add this patch to CatalogTool in CMFPlone, so that it 
doesn't need to be patched anymore. Right?

> I know that this matter has been a long term discussion on Plone since 
> ages and that there are opinions on both sides ( Plone should have 
> multilingual suport by default ? ) I understand that it should not be 
> installed by default but IMHO it should be delivered as an option by 
> default. On EU we are really used to have plones with LP, I can't 
> imagine a plone site without LP, so for me, and surelly for a lot of 
> plone integrators, it should be something that is really close to the 
> core from all points of view.
>
> In case the FWT decides that plone shouldn't have multilingual 
> solution maybe we should think about why there is the 
> languagetool/selector/interfaces on core right now...
>
The consensus on the framework team seems to be that we don't want to 
pick a particular multilingual add-on to be in core, but we want to make 
any changes we can to the core framework to make it easier to implement 
multilingual addons. That seems to be in line with what you're proposing 
above.

David