David Glick (Plone)
david.glick at plone.org
Mon Feb 18 23:00:01 UTC 2013
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
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
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
More information about the Framework-Team