Next generation multilingual support

[Martin Aspeli]

Okay, here are some thoughts on the subject based on the comments so
far. This is pretty comprehensive, but I think it represents workable
options.

My thinking right now is that we should maybe break the core of
plone.app.multilingual out into a new package, plone.multilingual, which
will be devoid of Plone specific policy and UI. This will have some
"policy" adapters and will try to provide sensible defaults.
plone.app.multilingual will then provide additional Plone-specific
policy + UI on top of this package. There may also need to be plug-ins
for Archetype specific stuff and Dexterity specific stuff.

So:

[1] There are multiple possible scenarios:

  (1) Mono-lingual site

  (2) Multi-lingual site, which has independent content for each
specific language (technically these are multiple mono-lingual sites)

  (3) Multi-lingual site, which has a common navigation / structure and
where only some of the content is translated

  (4) Multi-lingual site, which has shares some common structure and
translated content, but where also a locale-dependent structure exists
with unique content for a language

  (5) Multi-lingual site, where all content is translated to all languages

I'll ignore (1) and (2), since that just means the absence of any of
this stuff.

[2] We have multiple ways to store translations.

All of these assume that we have a canonical object and zero or more
translations. Translations are always of the same type as the original
object, starting out as a direct clone. The canonical objects don't
always have to be in the same language, but there is always one
canonical version for a given content object. There's a bi-directional
reference between the canonical object and all translations (although we
may store the references in a central place to avoid having to figure
out which object is canonical all the time).

  (a) All content co-exists in the same structure. When an item is
translated, the translation clone is added as a sibling of the canonical
object. Catalog based navigation can hide content in languages other
than the current language, but if you look behind the scenes (e.g. in
the ZMI) it's all interleaved.

In this case, folders are probably not translated (but default pages
are, and will require some new code in Plone, I think). I'm not quite
sure how logical it is to want to translate a folder anyway. :)

I'm also not sure how this approach would work if we make all pages
folderish in Plone 4 or 5. Probably at this point, you end up with the
translations being siblings at the top level only. When you translate
/foo/bar that's English into German, the system looks for the
translation of /foo first (let's say that's /foo-de) and then adds a
translation under it (/foo-de/bar-de). This is of course fine, but at
this point you almost have per-language folders.

  (b) Content exists in different top level structures, each being an
INavigationRoot. The top level folder is named by the language code, so
we have /en and /de. Under each, there is an identical/mirrored
structure, although the content may be actually have different ids to
reflect the title in the translated language.

  (c) A variation of (b) where there is only a partial mirror of the
canonical language.

[3] Policy should be pluggable. By default, we may not need to support
all of the scenarios and options, but we should make sure it's possible
to do all of them.

My thinking is that the default should be to support (3)+(c) and
(4)+(c). That is, we have top level language folders, and we don't
automatically create all content in all languages: we only do that when
translation is actually requested.

This approach can also support (5)+(b), where all content is translated
in all languages. It may be nice to have an option to automatically
create translations for all languages when a content object is
published, but that's probably going to be workflow-dependent.

We should support (a) by having a different "where does the translation
copy go" policy available.

In both cases, we can use a catalog restriction to only search in the
current language by default. This means you don't accidentally get
content from /en if you're doing a search and your language is 'de'.

[4] Language fallback

I think by default, we want this be disabled. It's hard even to think
about how it can work in theory let alone making a decent UI that would
respect it. That said, here are some thoughts:

The LanguageIndex in LinguaPlone has support for fallback between e.g.
en-GB and en-US. It may be possible to extend it so that it supports
fallback with different rules, e.g. always falling back on the canonical
language. This could be combined with storage model (a) so that fallback
content would be shown in a meshed site structure.

Again, though, this breaks down if you start translating folders. If we
get folderish pages, I don't think it's going to work.

Another option is to always create stubs in all languages, all the time.
Again, this could be done on a workflow trigger. The stubs would then
contain the canonical text until translated. This is wasteful, but would
work with storage model (b) or (c).

[5] Canonical content

As already hinted, we want to be able to mark content as "canonical",
and make sure that every translation has a reference to a canonical
object. However, not all canonical content has to be in the same
language. You can have a page /en/foo that's in English and a German
translation at /de/fu, and then a page in German at /de/bar that's
translated to /en/bar.

[6] Translation workflow

We should manage translation via a specific workflow. In some cases, it
can be the only workflow for translated objects, but it should be
possible to have some other approvals workflow that takes place after
translation. In this case, the translation workflow would be the second
workflow in a workflow chain.

The translation workflow should have states like "untranslated",
"translated" and "outdated". The transition to "outdated" could be
automatic, triggered when the canonical object is modified. There may
also be an approval step there.

[7] Security

There are two options here:

  - Translation copies have a translation workflow only. They get the
same security as canonical objects as soon as the translation workflow
goes to "complete". Before that, they are shown to translators only.

  - Translation copies have two workflows: a default workflow, and a
translation workflow. The translation workflow controls state and UI
only. All security is handled via a standard workflow.

I think the first option makes more sense as a default.

[8] Signalling

When looking at a content item, it should be possible to see what
translations exist, and what translations are missing. This can use the
flags GUI that LinguaPlone users.

It should also be signalled if a content item is possibly outdated,
allowing the user to switch languages and be redirected to the canonical
object.

When switching languages (or arriving at an item in a language you're
not supposed to see) a redirect should take you to the correct content item.

[9] Language independent content

Some content types or instances need to be marked as language
independent. With storage options (b) and (c) these can be stored
outside the language tree (e.g. you have /images and /en and /de) and
referenced.

If you're using storage options (b) and (c), then language independent
content in general becomes more limited, and it needs to be possible to
"translate" (actually, just clone) content to a given language. With
option (a) you could possibly mark some instances as language
independent (e.g. via a menu option). In this case, catalog navigation
would always show it, and translation would be impossible.

[10] Language independent fields

Certain field may be marked as language independent. In this case, they
are not shown in the translation UI. They are copied into the
translation copies when the translation is made, and if they are later
modified.

We may need some cleverer handling of blobs here to save copying large
objects around.

Phew... that was long. Have I covered everything?

Martin


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

hi martin,
thanks for this extremely well written resumé. I cant help to gape open-mouthed
at your productivity.

It is only the handling of the fallback language I am not happy with.
I know it is hard. Specially in view of the fact, that lots of the visible site
structure is driven by catalog search.
however, there is no (no with an emphasis) corporate, multilingual intranet that
 is not in sore need of good fallback language support. if it is missing (or
rather because it is missing) the multilingual part of an intranet quickly
dwindles into "quasi not existent".
"multilinguality" is as much a result of community efforts as the "up to
dat"-nes  or "it is interesting for me to consult"-nes of a site and needs good
language fallback.

to have "multilinguality" thrive an effective and elegant way to deal with
language fallback is esential.

our way to deal with language fallback so far is to have all content "language
independent", but with an additional "original-language" attribute set on the
"canonical" document. so if a translated document exists for users having this
language as default the translationed one is shown. the neutral one for the rest.
only when all translations are effected the language of the original document is
set according to its original-language attribute.

robert


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[pepe]

@robert: very elegant and logical language fallback mechanism!! 1+

@martin: i didnt understand if there will be :
a) one plone.multilinagual which incorporates all the different scenarios,
b) one or more scenarios will be chosen and implemented in the mechanism
c) a multilingual core and depending on my usecase there will be more
additional modules i can choose to install.

andreas

robert rottermann wrote:

> hi martin,
> thanks for this extremely well written resumé. I cant help to gape open-mouthed
> at your productivity.
>
> It is only the handling of the fallback language I am not happy with.
> I know it is hard. Specially in view of the fact, that lots of the visible site
> structure is driven by catalog search.
> however, there is no (no with an emphasis) corporate, multilingual intranet that
>  is not in sore need of good fallback language support. if it is missing (or
> rather because it is missing) the multilingual part of an intranet quickly
> dwindles into "quasi not existent".
> "multilinguality" is as much a result of community efforts as the "up to
> dat"-nes  or "it is interesting for me to consult"-nes of a site and needs good
> language fallback.
>
> to have "multilinguality" thrive an effective and elegant way to deal with
> language fallback is esential.
>
> our way to deal with language fallback so far is to have all content "language
> independent", but with an additional "original-language" attribute set on the
> "canonical" document. so if a translated document exists for users having this
> language as default the translationed one is shown. the neutral one for the rest.
> only when all translations are effected the language of the original document is
> set according to its original-language attribute.
>
> robert
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>  

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Hi Robert,

> thanks for this extremely well written resumé. I cant help to gape open-mouthed
> at your productivity.

Probably gasping for air after reading it all.. :)

> It is only the handling of the fallback language I am not happy with.

Heh, I thought as much. :)

> I know it is hard. Specially in view of the fact, that lots of the visible site
> structure is driven by catalog search.

I actually think this makes things easier, in some ways. But that's detail.

> however, there is no (no with an emphasis) corporate, multilingual intranet that
>  is not in sore need of good fallback language support.

That's probably quite a strong statement. But I agree it's an important
use case. It may be that "corporate multilingual intranet" isn't the
first use case we support here (just as it isn't with LinguaPlone), for
the fact that it's hard to get this right. It's worth exploring more,
though.

> if it is missing (or
> rather because it is missing) the multilingual part of an intranet quickly
> dwindles into "quasi not existent".

Well, I think that depends on the use case and the processes around it.
For example, I could imagine an intranet where a certain section (like
/corporate-policies) was always translated, but other content was not.
This could be handled via specific organisational policies and
allocation of resources. The problem is more acute when translation is
ad-hoc and it's no-one's priority to translate into a given language.

> "multilinguality" is as much a result of community efforts as the "up to
> dat"-nes  or "it is interesting for me to consult"-nes of a site and needs good
> language fallback.

:)

> to have "multilinguality" thrive an effective and elegant way to deal with
> language fallback is esential.

I don't think it's always essential. But I see how it's important to you
and for many use cases.

> our way to deal with language fallback so far is to have all content "language
> independent", but with an additional "original-language" attribute set on the
> "canonical" document. so if a translated document exists for users having this
> language as default the translationed one is shown. the neutral one for the rest.
> only when all translations are effected the language of the original document is
> set according to its original-language attribute.

How did you actually implement this? Don't you get a situation where,
until the canonical document is translated to each language, users
always see both the canonical object and the object in their own
language? How does that work with navigation?

Actually, I think the thing that makes it most confusing is where
content is stored. Do you always store a translation in the same folder
as the canonical object? If so, do you ever translate folders?
Presumably you have to, but then how do you deal with navigation when
you have /foo-en, /foo-en/bar-en, and /foo-de, but no /foo-de/bar-de?

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

pepe wrote:
> @robert: very elegant and logical language fallback mechanism!! 1+
>
> @martin: i didnt understand if there will be :
> a) one plone.multilinagual which incorporates all the different scenarios,
> b) one or more scenarios will be chosen and implemented in the mechanism
> c) a multilingual core and depending on my usecase there will be more
> additional modules i can choose to install.

I have no idea. I'm interested in solving this problem. I'm not sure I
want to be the one writing the code or making the decisions. We'll see.
But my gut feel is that a smaller plone.multilingual with enough hooks
to allow these policies and a sensible default will at least be
managable and testable. plone.app.multilingual would have Plone UI and
other integration.

I think some of the scenarios would probably be left up to individual
installations/customisations or other third party products to support.
Trying to support "everything" in one package is normally a recipe for pain.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Clearly this post wasn't long enough....

Let's think about this a bit more:

[2] We have multiple ways to store translations.

   (a) All content co-exists in the same structure.
   (b) Content exists in different top level structures, i.e.
per-language folders

I'm going to outline a few scenarios and I want to make sure we agree on
what the result of various translation operations would be. I want to
see what makes sense. In this, I'll assume the canonical content is
English (en) and translations are German (de). I'll name content by path
and type, e.g. /folder1-en/folder11-en/doc111-en. The -en and -de suffix
indicate that the name is likely to change so that the URL makes sense
in the given language.

Scenarios
---------

(1) Translating a simple document at the site root.

Before (a): /doc1-en

  After (a): /doc1-en
             /doc1-de

Here, the translation is located in the same parent as the canonical object.

Before (b): /en/doc1-en
             /de

  After (b): /en/doc1-en
             /de/doc1-de

Here, the translation is located in the corresponding folder under the
target language root folder.

(2) Translating a document in a folder. Parent folder has not been
translated.

Before (a): /folder1-en/doc11-en

  After (a): /folder1-en/doc11-en
             /folder1-en/doc11-de

This is similar to (1), except that we are in a subfolder. Note that
since the parent folder is not translated, the German content appears in
side a folder with an English title and name. Effectively, /folder1-en
is being treated as language neutral.

Before (b): /en/folder1-en/doc11-en
             /de

  After (b): /en/folder1-en/doc11-en
             /de/folder1-en/doc11-de

Here, we are forced to create the corresponding parent folder by
creating a stub translation. If we're clever, we can probably invoke
title-to-id renaming if and when the parent folder translation is
completed, thus renaming it to /de/folder1-de/doc11-de. There's a risk
of links breaking if this is done "late" though.

Q: Perhaps we should insist that content is translated top down always,
and effectively disallow translating doc11-en until folder1-en is
translated?

A slight easing of this would be that we disallow translation of
doc11-en until folder1-en is translated *or* it has been explicitly (and
irreversibly) marked as language neutral. In this case, a language
neutral folder becomes a virtual "translation root" in scenario (a).

(3) Translating a document in a folder. Parent folder has been translated.

Before (a): /folder1-en/doc11-en
             /folder1-de/

  After (a): /folder1-en/doc11-en
             /folder1-de/doc11-de

This is more straightforward than (2) because it's clear where the
document goes. We look at the parent of the object to be translated,
find its translation, and put the new translation in this container.

Before (b): /en/folder1-en/doc11-en
             /de/folder1-de/

  After (b): /en/folder1-en/doc11-en
             /de/folder1-de/doc11-de

Again, this is relatively straightfoward.

(4) Translating a folder with no children.

This is identical to (1) at the site root and (3) in a sub-folder.

(5) Translating a folder with children. No children are already translated.

Before (a): /folder1-en/doc11-en

  After (a): /folder1-en/doc11-en
             /folder1-de/

This is similar to (1) at the site root and (3) in a sub-folder. Child
objects can now be translated separately.

Before (b): /en/folder1-en/doc11-en
             /de/

  After (b): /en/folder1-en/doc11-en
             /de/folder1-de/

Again, similar to (1) at the site root and (3) in a sub-folder.

Q: Should translating a folder with children create translation stubs
for all children as well?

(6) Translating a folder with children. All children are already
translated as per (2).

Before (a): /folder1-en/doc11-en
             /folder1-en/doc11-de

  After (a): /folder1-en/doc11-en
             /folder1-de/doc11-de

In this case, we've created a new folder /folder1-de for the translation
and then *moved* the doc11-de object into it. I suspect this could
become complex if we have nesting and a partial subtree has been
translated, but not all the way. Still, it's probably not too hard to
come up with an algorithm that'll be able to find the appropriate parent.

Before (b): /en/folder1-en/doc11-en
             /de/folder1-en/doc11-de

  After (b): /en/folder1-en/doc11-en
             /de/folder1-de/doc11-de

In this case, we created a stub /de/folder1-en, which we've now renamed.

Note: In both cases, we're changing existing URLs so links may break.

Note: If we disallow (2) then this will be a non-issue.

(7) Translating a folder with children. Some, but not all children are
already translated as per (2).

Before (a): /folder1-en/doc11-en
             /folder1-en/doc12-en
             /folder1-en/doc11-de

  After (a): /folder1-en/doc11-en
             /folder1-en/doc12-en
             /folder1-de/doc11-de

This is a variant of (6).

Before (b): /en/folder1-en/doc11-en
             /en/folder1-en/doc12-en
             /de/folder1-en/doc11-de

  After (b): /en/folder1-en/doc11-en
             /en/folder1-en/doc12-en
             /de/folder1-de/doc11-de

Again, this is a variation of (6).

Q: Should we create translation stubs for the untranslated items in the
folder? See (5).

Note: If we disallow (2) then this will be a non-issue.

Language fallback
-----------------

This all has a pretty direct impact on language fallback, if we
implement this.

With option (b) - top level language folders - language fallback gets
pretty difficult. The only way to do it that I can see would be to
create translation for every (published?) item, all the time. This is
not really "fallback", but it means that you'll get a "translation" that
just happens to be written in the canonical language.

The problem with this approach is that it'd be moderately hard to keep
in sync in case of changes to the original object. It's also pretty
wasteful if you're not actually foreseeing much content being translated.

With option (a) - interleaved content - the situation may not be much
better. In theory, you can show the canonical object in the navigation
if there's not a translation for the current language. But what happens
once you translate folders? Let's try an example:

  Before (a): /folder1-en/doc11-en
              /folder2-en/doc21-en
              /folder2-en/doc22-en
              /folder2-en/folder23-en/
              /folder2-en/folder23-en/doc231-en
              /folder3-en/doc31-en

              /folder1-de/
              /folder2-de/doc21-de

Here, we have a pretty complete English structure, and a pretty sparse
German one. Someone has translated two of the three top level folders.
Therefore, the top level navigation in German may show:

  [ folder1-de ] [ folder2-de ] [ folder3-en ]

Here, we have fallback to folder3-en. Going into that folder, the user
will see doc31-en, since there's no translation for that one either. So,
fallback works here.

But what if we go into folder2-de? The navigation can show doc21-de
since that's there. But it can't show doc21-en, doc22-en or folder23-en,
all of which are only in the sibling folder. To solve that problem, we'd
either need stubs here too (so translating a folder means you get stubs
of all children, recursively).

A variant of this would be to create some kind of proxy. That's very
hard to do right in Plone, though. Security becomes an issue, and links
would break when things were finally translated and the new item got a
different URL. Also, believe it or not, but there's no good way to suck
"the body" of an arbitrary content item into a page. There are various
heuristics based on METAL macros, but they are not particularly good and
rely on brittle messing with the context.

Another option may be to heuristically look for untranslated objects and
merge them into the search results, but that cannot be sensibly
generalised to any content listing and would be quite expensive. You'd
also have the problem that clicking on a link here would take you to the
English /folder2-en, where you may see some English content (but not
all, since objects for which there was a translation would be hidden),
and no German content (or you'd have the problem in reverse).

As it is, I'm not really seeing a good option for language fallback. I
hpoe I'm wrong. But I wonder if it makes more sense to solve this with
process, e.g. you only translate part of your site, and decide to keep
most of your content language neutral. That content which isn't language
neutral gets translated all the time by means of workflow and
organisational policy. I do realise this is just avoiding the problem. :)

...

What do you think? Does this all make sense? Got better options?

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

>> however, there is no (no with an emphasis) corporate, multilingual intranet that
>>  is not in sore need of good fallback language support.
>
> That's probably quite a strong statement. But I agree it's an important
> use case. It may be that "corporate multilingual intranet" isn't the
> first use case we support here (just as it isn't with LinguaPlone), for
> the fact that it's hard to get this right. It's worth exploring more,
> though.

Agreed, "corporate multilingual intranet"  this is not the topmost on the list
of usecases. nevertheless it is an important one.
But I do believe we need to think on a (do I repeat myself?) elegant and easy to
use fallback language suport.
the user should never be forced to make a distinction between the languages.
only when she sees need to (because maybe the canonical document is spanish, but
she preferes the english one that is also available)

>
>> to have "multilinguality" thrive an effective and elegant way to deal with
>> language fallback is esential.
>
> I don't think it's always essential. But I see how it's important to you
> and for many use cases.

I agree with you. in theory it is not necessary.
however I live in a county where multilingual is the norm, and not the exception.
there is practically no company here in switzerland that is not only working for
the geographically very near neighborhood, that does not face such problems.

>> our way to deal with language fallback so far is to have all content "language
>> independent", but with an additional "original-language" attribute set on the
>> "canonical" document. so if a translated document exists for users having this
>> language as default the translationed one is shown. the neutral one for the rest.
>> only when all translations are effected the language of the original document is
>> set according to its original-language attribute.
>
> How did you actually implement this? Don't you get a situation where,
> until the canonical document is translated to each language, users

yes, we have to filter search results

> always see both the canonical object and the object in their own
> language? How does that work with navigation?

the navigaion is mostly done with an augmented folderlisting, where flags for
all languages the document exists in, are shown.
there is no navigation portlet.

>
> Actually, I think the thing that makes it most confusing is where
> content is stored. Do you always store a translation in the same folder
> as the canonical object?

yes

 If so, do you ever translate folders?

no, newver

> Presumably you have to, but then how do you deal with navigation when
> you have /foo-en, /foo-en/bar-en, and /foo-de, but no /foo-de/bar-de?

they are all in the same folder. as the user only sees folderlisting (which
knows about canonical/translations) she never sees a document twice.
the language-flags give access to the translated documents

robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Ricardo Alves-2]

Hi,

Thank you Martin for doing this! Multilingual support really needs a push.

I added some notes below.

Martin Aspeli wrote:

> Okay, here are some thoughts on the subject based on the comments so
> far. This is pretty comprehensive, but I think it represents workable
> options.
>
> My thinking right now is that we should maybe break the core of
> plone.app.multilingual out into a new package, plone.multilingual, which
> will be devoid of Plone specific policy and UI. This will have some
> "policy" adapters and will try to provide sensible defaults.
> plone.app.multilingual will then provide additional Plone-specific
> policy + UI on top of this package. There may also need to be plug-ins
> for Archetype specific stuff and Dexterity specific stuff.
>
> So:
>
> [1] There are multiple possible scenarios:
>
>   (1) Mono-lingual site
>
>   (2) Multi-lingual site, which has independent content for each
> specific language (technically these are multiple mono-lingual sites)
>
>   (3) Multi-lingual site, which has a common navigation / structure and
> where only some of the content is translated
>
>   (4) Multi-lingual site, which has shares some common structure and
> translated content, but where also a locale-dependent structure exists
> with unique content for a language
>
>   (5) Multi-lingual site, where all content is translated to all languages
>
> I'll ignore (1) and (2), since that just means the absence of any of
> this stuff.
>
> [2] We have multiple ways to store translations.
>
> All of these assume that we have a canonical object and zero or more
> translations. Translations are always of the same type as the original
> object, starting out as a direct clone. The canonical objects don't
> always have to be in the same language, but there is always one
> canonical version for a given content object. There's a bi-directional
> reference between the canonical object and all translations (although we
> may store the references in a central place to avoid having to figure
> out which object is canonical all the time).
>
>   (a) All content co-exists in the same structure. When an item is
> translated, the translation clone is added as a sibling of the canonical
> object. Catalog based navigation can hide content in languages other
> than the current language, but if you look behind the scenes (e.g. in
> the ZMI) it's all interleaved.
>
> In this case, folders are probably not translated (but default pages
> are, and will require some new code in Plone, I think). I'm not quite
> sure how logical it is to want to translate a folder anyway. :)
>

I think it makes sense in most cases. Folders have title, description
and other metadata that should be translated.

> I'm also not sure how this approach would work if we make all pages
> folderish in Plone 4 or 5. Probably at this point, you end up with the
> translations being siblings at the top level only. When you translate
> /foo/bar that's English into German, the system looks for the
> translation of /foo first (let's say that's /foo-de) and then adds a
> translation under it (/foo-de/bar-de). This is of course fine, but at
> this point you almost have per-language folders.
>

This is how LinguaPlone works by default. But it may get weird when the
parent folder is not translated. If you have the following content:

/foo/bar/doc1
/foo-de/

Folder "bar" has no translation and so the translation of "doc1" will be
created at

/foo/bar/doc1-de

I'm not sure how LinguaPlone works around this, but there are some
possibilities:

- When creating a new translation, also create the whole missing parent
folders to replicate the structure, so in the previous example a folder
"bar-de" would be created and the new translation would be located at:

/foo-de/bar-de/doc1-de

It has a problem of course: the automatically created folders need to be
actually *translated* and should be approved via workflow, before
they're made public. Maybe the translation form should have some
message: "Remember to also translate the parent folders that were
created automatically" or the translation process could be made by
several steps to translate each needed parent folder, and only at the
end translate the desired content (permissions will most likely be a
problem here).

- Keep the default behavior, but if some folder within the tree is
translated, move all translated content to it. Again in the previous
example, when creating "bar-de", "doc-de" would be moved to to the
correct parent.

>   (b) Content exists in different top level structures, each being an
> INavigationRoot. The top level folder is named by the language code, so
> we have /en and /de. Under each, there is an identical/mirrored
> structure, although the content may be actually have different ids to
> reflect the title in the translated language.

Although I see an advantage in terms of content organization, I don't
see a technical reason to use top-level language folders...

>
>   (c) A variation of (b) where there is only a partial mirror of the
> canonical language.
>
> [3] Policy should be pluggable. By default, we may not need to support
> all of the scenarios and options, but we should make sure it's possible
> to do all of them.
>
> My thinking is that the default should be to support (3)+(c) and
> (4)+(c). That is, we have top level language folders, and we don't
> automatically create all content in all languages: we only do that when
> translation is actually requested.

I agree. I'm just not sure about top-level language folders.


> This approach can also support (5)+(b), where all content is translated
> in all languages. It may be nice to have an option to automatically
> create translations for all languages when a content object is
> published, but that's probably going to be workflow-dependent.
>

As I said before, translations automatically created are useless until
somebody actually makes the real translation of the content.

> We should support (a) by having a different "where does the translation
> copy go" policy available.
>
> In both cases, we can use a catalog restriction to only search in the
> current language by default. This means you don't accidentally get
> content from /en if you're doing a search and your language is 'de'.
>
> [4] Language fallback
>
> I think by default, we want this be disabled. It's hard even to think
> about how it can work in theory let alone making a decent UI that would
> respect it.

+1.

> That said, here are some thoughts:
>
> The LanguageIndex in LinguaPlone has support for fallback between e.g.
> en-GB and en-US. It may be possible to extend it so that it supports
> fallback with different rules, e.g. always falling back on the canonical
> language. This could be combined with storage model (a) so that fallback
> content would be shown in a meshed site structure.
>
> Again, though, this breaks down if you start translating folders. If we
> get folderish pages, I don't think it's going to work.

Maybe we can extend the ExtendedPathIndex, making it perform the search
also within the path of the translated folders.

>
> Another option is to always create stubs in all languages, all the time.
> Again, this could be done on a workflow trigger. The stubs would then
> contain the canonical text until translated. This is wasteful, but would
> work with storage model (b) or (c).
>
> [5] Canonical content
>
> As already hinted, we want to be able to mark content as "canonical",
> and make sure that every translation has a reference to a canonical
> object. However, not all canonical content has to be in the same
> language. You can have a page /en/foo that's in English and a German
> translation at /de/fu, and then a page in German at /de/bar that's
> translated to /en/bar.

This is something that I think should be configurable. i.e. having a set
of languages that may be used for the canonical version. By default
these would be the same set of "available languages", but based on the
content management and translation policies used for each project, it
may make sense to simply consider some language as *the canonical one*.

>
> [6] Translation workflow
>
> We should manage translation via a specific workflow. In some cases, it
> can be the only workflow for translated objects, but it should be
> possible to have some other approvals workflow that takes place after
> translation. In this case, the translation workflow would be the second
> workflow in a workflow chain.
>
> The translation workflow should have states like "untranslated",
> "translated" and "outdated". The transition to "outdated" could be
> automatic, triggered when the canonical object is modified. There may
> also be an approval step there.

+1

> [7] Security
>
> There are two options here:
>
>   - Translation copies have a translation workflow only. They get the
> same security as canonical objects as soon as the translation workflow
> goes to "complete". Before that, they are shown to translators only.
>
>   - Translation copies have two workflows: a default workflow, and a
> translation workflow. The translation workflow controls state and UI
> only. All security is handled via a standard workflow.
>
> I think the first option makes more sense as a default.
>

Alhoutgh I think both configurations should be possible, I'd go for the
second. Keep content completely independent. This way we can easily have
different security policies for the different language structures
without magical security changes happening behind our back.

> [8] Signalling
>
> When looking at a content item, it should be possible to see what
> translations exist, and what translations are missing. This can use the
> flags GUI that LinguaPlone users.
>
> It should also be signalled if a content item is possibly outdated,
> allowing the user to switch languages and be redirected to the canonical
> object.
>
> When switching languages (or arriving at an item in a language you're
> not supposed to see) a redirect should take you to the correct content item.

+1. For individual content objects, LinguaPlone does a good job
identifying the existing translations. The main problem is when we're
looking at a folder listing/contents and we have no idea which ones are
translated. So an improved, translation-aware folder_contents, showing
in which languages some object is available, should do the trick.

>
> [9] Language independent content
>
> Some content types or instances need to be marked as language
> independent. With storage options (b) and (c) these can be stored
> outside the language tree (e.g. you have /images and /en and /de) and
> referenced.
>
> If you're using storage options (b) and (c), then language independent
> content in general becomes more limited, and it needs to be possible to
> "translate" (actually, just clone) content to a given language. With
> option (a) you could possibly mark some instances as language
> independent (e.g. via a menu option). In this case, catalog navigation
> would always show it, and translation would be impossible.

Another option for storage options (b) and (c), would be to create
language independent content wherever they are created at the content
structure, then catalog based navigation shows language independent
content in all langaguges, e.g. with language support in ExtendendPathIndex.

>
> [10] Language independent fields
>
> Certain field may be marked as language independent. In this case, they
> are not shown in the translation UI. They are copied into the
> translation copies when the translation is made, and if they are later
> modified.
>
> We may need some cleverer handling of blobs here to save copying large
> objects around.
>

The way LinguaPlone works here is a bit different because, AFAIK, there
is no copy. LinguaPlone generates a specific accessor for language
independent fields. It basically gets the canonical object and returns
the field value.



Ricardo

--
Ricardo Alves <[hidden email]>
Eurotux <http://www.eurotux.com>


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Hi Robert,

> Agreed, "corporate multilingual intranet"  this is not the topmost on the list
> of usecases. nevertheless it is an important one.
> But I do believe we need to think on a (do I repeat myself?) elegant and easy to
> use fallback language suport.
> the user should never be forced to make a distinction between the languages.
> only when she sees need to (because maybe the canonical document is spanish, but
> she preferes the english one that is also available)

I'm not saying you're wrong. I'm just saying it's hard. :)

> I agree with you. in theory it is not necessary.
> however I live in a county where multilingual is the norm, and not the exception.
> there is practically no company here in switzerland that is not only working for
> the geographically very near neighborhood, that does not face such problems.

Yep. Switzerland is particularly tricky. :)

>>> our way to deal with language fallback so far is to have all content "language
>>> independent", but with an additional "original-language" attribute set on the
>>> "canonical" document. so if a translated document exists for users having this
>>> language as default the translationed one is shown. the neutral one for the rest.
>>> only when all translations are effected the language of the original document is
>>> set according to its original-language attribute.
>> How did you actually implement this? Don't you get a situation where,
>> until the canonical document is translated to each language, users
>
> yes, we have to filter search results
>
>> always see both the canonical object and the object in their own
>> language? How does that work with navigation?
>
> the navigaion is mostly done with an augmented folderlisting, where flags for
> all languages the document exists in, are shown.
> there is no navigation portlet.

Can you look at my other post, about translation content structure,
where I elaborate on this? I'm not sure I see it working generally.

>> Actually, I think the thing that makes it most confusing is where
>> content is stored. Do you always store a translation in the same folder
>> as the canonical object?
>
> yes
>
>  If so, do you ever translate folders?
>
> no, newver

Right. So folder titles remain in the canonical language? In this case,
your approach can work. But I don't know if that's going to work generally.

If we want to support language fallback on the provisio that folders are
never translated, then I can see a solution. However, if all pages
become folderish in Plone 4 or 5, you're a bit stuffed. :)

>> Presumably you have to, but then how do you deal with navigation when
>> you have /foo-en, /foo-en/bar-en, and /foo-de, but no /foo-de/bar-de?
>
> they are all in the same folder. as the user only sees folderlisting (which
> knows about canonical/translations) she never sees a document twice.
> the language-flags give access to the translated documents

Right, I see what you mean now. I'm not sure never translating folders
is going to be a generally acceptable policy, though. It'd certainly
need to be opt-in and a tradeoff you make explicitly.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Hi Ricardo,

> Thank you Martin for doing this! Multilingual support really needs a push.

Sigh... I was hoping I wouldn't need to do the pushing, but I agree it
needs fixing. I'm going to need some actual implementation help, though.
I can push a bit, but not all the way.

> I think it makes sense in most cases. Folders have title, description
> and other metadata that should be translated.

Yeah. I was wrong about that.

>> I'm also not sure how this approach would work if we make all pages
>> folderish in Plone 4 or 5. Probably at this point, you end up with the
>> translations being siblings at the top level only. When you translate
>> /foo/bar that's English into German, the system looks for the
>> translation of /foo first (let's say that's /foo-de) and then adds a
>> translation under it (/foo-de/bar-de). This is of course fine, but at
>> this point you almost have per-language folders.
>>
>
> This is how LinguaPlone works by default. But it may get weird when the
> parent folder is not translated. If you have the following content:
>
> /foo/bar/doc1
> /foo-de/
>
> Folder "bar" has no translation and so the translation of "doc1" will be
> created at
>
> /foo/bar/doc1-de
>
> I'm not sure how LinguaPlone works around this, but there are some
> possibilities:
>
> - When creating a new translation, also create the whole missing parent
> folders to replicate the structure, so in the previous example a folder
> "bar-de" would be created and the new translation would be located at:
>
> /foo-de/bar-de/doc1-de
>
> It has a problem of course: the automatically created folders need to be
> actually *translated* and should be approved via workflow, before
> they're made public. Maybe the translation form should have some
> message: "Remember to also translate the parent folders that were
> created automatically" or the translation process could be made by
> several steps to translate each needed parent folder, and only at the
> end translate the desired content (permissions will most likely be a
> problem here).
>
> - Keep the default behavior, but if some folder within the tree is
> translated, move all translated content to it. Again in the previous
> example, when creating "bar-de", "doc-de" would be moved to to the
> correct parent.

If you see my other post today with scenarios, you'll see both of these
possibilities described.

>>   (b) Content exists in different top level structures, each being an
>> INavigationRoot. The top level folder is named by the language code, so
>> we have /en and /de. Under each, there is an identical/mirrored
>> structure, although the content may be actually have different ids to
>> reflect the title in the translated language.
>
> Although I see an advantage in terms of content organization, I don't
> see a technical reason to use top-level language folders...

It does seem to be something of an "accepted practice" on the web. I
actually think it makes more sense as a default, mainly because I think
it'll be less confusing.

It does presume a use case with no language fallback, and where you're
either browsing in one language or another (you can switch, of course),
i.e. little or no language neutral content. Again, that won't suit
everyone, but I think it's the easier-to-understand option that makes
sense for a certain set of users.

> As I said before, translations automatically created are useless until
> somebody actually makes the real translation of the content.

Yes, this is correct. But with workflow, you can leave them "pending
translation". Security should probably by default block access to
children unless the full path to the root is translated.

> Maybe we can extend the ExtendedPathIndex, making it perform the search
> also within the path of the translated folders.

That sounds really evil. :)

Then what do you link to? When you click a link that takes you to an
English page you may be in an English folder. See my other post today.


> This is something that I think should be configurable. i.e. having a set
> of languages that may be used for the canonical version. By default
> these would be the same set of "available languages", but based on the
> content management and translation policies used for each project, it
> may make sense to simply consider some language as *the canonical one*.

Well they'd be "possible canonical ones". Each item has exactly one
canonical language.

>> [7] Security
>>
>> There are two options here:
>>
>>   - Translation copies have a translation workflow only. They get the
>> same security as canonical objects as soon as the translation workflow
>> goes to "complete". Before that, they are shown to translators only.
>>
>>   - Translation copies have two workflows: a default workflow, and a
>> translation workflow. The translation workflow controls state and UI
>> only. All security is handled via a standard workflow.
>>
>> I think the first option makes more sense as a default.
>>
>
> Alhoutgh I think both configurations should be possible, I'd go for the
> second. Keep content completely independent. This way we can easily have
> different security policies for the different language structures
> without magical security changes happening behind our back.

The problem I see with this is that you'd need two approvals, possibly:
first, someone approves the translation, then the content is
re-submitted for publication approval, even though the canonical object
was approved already. Sounds annoying. :)

>> [8] Signalling
>>
>> When looking at a content item, it should be possible to see what
>> translations exist, and what translations are missing. This can use the
>> flags GUI that LinguaPlone users.
>>
>> It should also be signalled if a content item is possibly outdated,
>> allowing the user to switch languages and be redirected to the canonical
>> object.
>>
>> When switching languages (or arriving at an item in a language you're
>> not supposed to see) a redirect should take you to the correct content item.
>
> +1. For individual content objects, LinguaPlone does a good job
> identifying the existing translations. The main problem is when we're
> looking at a folder listing/contents and we have no idea which ones are
> translated. So an improved, translation-aware folder_contents, showing
> in which languages some object is available, should do the trick.

Yeah, this may be a nice option. Somewhat hard to do efficiently, though.

>> [9] Language independent content
>>
>> Some content types or instances need to be marked as language
>> independent. With storage options (b) and (c) these can be stored
>> outside the language tree (e.g. you have /images and /en and /de) and
>> referenced.
>>
>> If you're using storage options (b) and (c), then language independent
>> content in general becomes more limited, and it needs to be possible to
>> "translate" (actually, just clone) content to a given language. With
>> option (a) you could possibly mark some instances as language
>> independent (e.g. via a menu option). In this case, catalog navigation
>> would always show it, and translation would be impossible.
>
> Another option for storage options (b) and (c), would be to create
> language independent content wherever they are created at the content
> structure, then catalog based navigation shows language independent
> content in all langaguges, e.g. with language support in ExtendendPathIndex.

Yes, but again, it gets tricky when you click on a language independent
item and end up in a different top level folder.

>> [10] Language independent fields
>>
>> Certain field may be marked as language independent. In this case, they
>> are not shown in the translation UI. They are copied into the
>> translation copies when the translation is made, and if they are later
>> modified.
>>
>> We may need some cleverer handling of blobs here to save copying large
>> objects around.
>>
>
> The way LinguaPlone works here is a bit different because, AFAIK, there
> is no copy. LinguaPlone generates a specific accessor for language
> independent fields. It basically gets the canonical object and returns
> the field value.

Mmmm... This is certinly possible, but it relies on internals of AT or
whatever framework is used, so it's a big iffy to do generically. So
long as you don't have a large amount of data in language independent
fields, I think it's safer to copy.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

Martin Aspeli schrieb:
> Hi Ricardo,
>
>> Thank you Martin for doing this! Multilingual support really needs a push.
>
> Sigh... I was hoping I wouldn't need to do the pushing, but I agree it
> needs fixing. I'm going to need some actual implementation help, though.
> I can push a bit, but not all the way.

we would be glad to help.

>
>> I think it makes sense in most cases. Folders have title, description
>> and other metadata that should be translated.
>
> Yeah. I was wrong about that.

no not really.
a folder is a container and its "main purpose in life" is to provide structure.
it is probably unfortunate that it does also provide attributes like
title/description that make it "contentish".

maybe we should try to distinguish between the folderish and the contentisch
attributes of an object.
why not have a kind of internal objects (simmilar to the discussion items) that
provide the attributes needed (dublin core?) for a container? these internal
objects could the be copied and translated as needed without touching the
objects structural behavior.

for one of our first multilingual site we used i18nfolder which worked somehow
like this.

>
>
> Then what do you link to? When you click a link that takes you to an
> English page you may be in an English folder. See my other post today.
>
this is really confusing and not acceptable.
separate folder structures for the diverse languages are easy to understand and
provide a straightforward way to navigate.
this is why people tend to lean towards such a solution (i assume).
however I think this approach makes only sense when you intend to provide a
number of monolingual subsites within a parent site that provides common services.

robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Hi Robert,

> we would be glad to help.

Great :)

>>> I think it makes sense in most cases. Folders have title, description
>>> and other metadata that should be translated.
>> Yeah. I was wrong about that.
>
> no not really.
> a folder is a container and its "main purpose in life" is to provide structure.
> it is probably unfortunate that it does also provide attributes like
> title/description that make it "contentish".

I'm not really sure I agree with that analysis, but I understand how
this view of the world makes sense for your use case.

> maybe we should try to distinguish between the folderish and the contentisch
> attributes of an object.
> why not have a kind of internal objects (simmilar to the discussion items) that
> provide the attributes needed (dublin core?) for a container? these internal
> objects could the be copied and translated as needed without touching the
> objects structural behavior.

Sorry, this is really out of scope for this discussion and not something
that's likely to happen in Plone core.

> for one of our first multilingual site we used i18nfolder which worked somehow
> like this.

Understandable, but with this the usability of the whole system suffers.
We're actually trying to move away from folders as a separate type
anyway. In Plone 5, you'll probably just have "pages" that may or may
not contain sub-pages (and listings thereof).

>> Then what do you link to? When you click a link that takes you to an
>> English page you may be in an English folder. See my other post today.
>>
> this is really confusing and not acceptable.

Right, that was my point.

> separate folder structures for the diverse languages are easy to understand and
> provide a straightforward way to navigate.
> this is why people tend to lean towards such a solution (i assume).
> however I think this approach makes only sense when you intend to provide a
> number of monolingual subsites within a parent site that provides common services.

I don't think I agree with that either. Many of the deployed sites out
there have separate folder structures for each language, but with
specific one-to-many translation relationships. It works if you don't
have fallback. And it can work with fallback, but you probably need to
copy the canonical text into the body of the 'translated' document. With
events, it's possible. Norden.no works like that, I believe.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

..
>
> What do you think? Does this all make sense? Got better options?
>
> Cheers,
> Martin
>

you amply prove, that separate trees per language is not a good solution..

we must find a way to do an "inplace translation" of structural elements.


robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

> Understandable, but with this the usability of the whole system suffers.
> We're actually trying to move away from folders as a separate type
> anyway. In Plone 5, you'll probably just have "pages" that may or may
> not contain sub-pages (and listings thereof).
>

exactly what I mean.
it is unfortunate that we do have folders.

building a new translation facility should therefore avoid relaying on them.

robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Thu, Jun 25, 2009 at 9:09 PM, robert rottermann<[hidden email]> wrote:
>> Understandable, but with this the usability of the whole system suffers.
>> We're actually trying to move away from folders as a separate type
>> anyway. In Plone 5, you'll probably just have "pages" that may or may
>> not contain sub-pages (and listings thereof).
>
> exactly what I mean.
> it is unfortunate that we do have folders.

If your specific set of use-case is better served without any
hierarchical organization of content, then please don't use folders.
Just create a "large folder" and put all content into it. The
"containers without an id or title" are the BTree-nodes of that large
folder in that case - very similar to the talkback item they don't
have a user visible representation and are just system internals.

How you want to organize and structure your content in this scenario
is up to you. You can use all the infrastructure today to do this, it
just happens to be a rather uncommon way of doing things.

Hanno

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Ricardo Alves-2]

Martin Aspeli wrote:

>
> Language fallback
> -----------------
>
> This all has a pretty direct impact on language fallback, if we
> implement this.
>
> With option (b) - top level language folders - language fallback gets
> pretty difficult. The only way to do it that I can see would be to
> create translation for every (published?) item, all the time. This is
> not really "fallback", but it means that you'll get a "translation" that
> just happens to be written in the canonical language.

This stub solution would bring the usability problem of content (the
whole content area) being shown to the user in a different language than
the selected one.

Well, maybe we should define what does it mean to support fallback. In
general I think the main goal is to make all content available to users
who surf the website in different languages, even if content is not
available in the desired language (in this case, the canonical or the
default language must be shown).

So it means that all listings (be it search results, folder listing,
catalog based navigation/sitemap, etc) should include:

1) Content matching the search parameters that's in the "selected language";

2) Content matching the search parameters that don't have an available
version/translation in the "selected language", and so the canonical
version should be shown (or maybe the default site language if
available). Of course, listings in this case should make it clear that
the content is not available in the desired language (e.g. a flag next
to the link).

Then, if the user clicks the link for content in other language, it may:

1) Show content without changing the "selected language", which I
believe would bring even more confusion.

2) Automatically change the selected language, so all UI messages will
be in the same language as the main content. Then, ideally, if the user
navigates away from the page, the previously selected language should be
re-selected. Not sure if this can be done using the current negotiation
scheme.


Any of this would probably be acceptable in the context of language
fallback, which will always be a little messy, and so in the event of
providing fallback out-of-the-box, it should be configurable which
behavior to have.



Ricardo

--
Ricardo Alves <[hidden email]>
Eurotux <http://www.eurotux.com>


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

robert rottermann wrote:
> ..
>> What do you think? Does this all make sense? Got better options?
>>
>> Cheers,
>> Martin
>>
>
> you amply prove, that separate trees per language is not a good solution..

Robert, you need to be a little more cognizant to use cases other than
your own. I think it is a good solution for many types of sites. And
even when fallback is required, it's possible. It's just not a

> we must find a way to do an "inplace translation" of structural elements.

Perhaps. I'm just not sure I see a good solution. Separating out
"structure" and "content" into separate items (so that folders have no
metadata, and are never translated) is not a good idea from a usability
perspective, and goes against where Plone seems to be headed in terms of
content editing in general. This one use case is not so important that
all other editing must suffer as a result. :)

I think the only way to really get language fallback like this, is to
use some kind of render-time proxying. That is, there's only one content
object, and only one content tree (and all URLs reflect the canonical
language). However, upon rendering a view, we pull data from some
container (or maybe just values annotated onto the content object or
something like that).

There are lots of problems with that approach. It's been tried before
and it's hard. But it may be possible, at least if some restrictions can
be accepted.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Jean Jordaan]

Hi all

I agree with Robert's take on this. It doesn't work to have multiple
trees, one per language.

When a folder is translated, the translation should be stored as an
annotation or subobject of the folder.

In the case of a page, translations are siblings, and referenced by the
'translationOf' relationship. In the case of a folder, the reference
could be to a child object, which is the translation. The exceptional
handling required in the case of a folder, would be to make the
appropriate child object appear in the place of the folder when
rendering and editing.

Plone's model of object publishing works well if you can describe your
domain in terms of containment, but it's a problem if you're trying to
accommodate more than one domain at once. I.e. if your containment
structure models translations, there's no problem (/en/doc-en,
/de/doc-de). However, site users don't care about this. They want to
structure the site in terms of their domain (topic areas, work groups,
regions, ...), and won't like it if you foist a structure from the
domain of translations on them.

The I18NLayer route did have merits. One merit is that there is no
exceptional handling required. All translations are child objects of a
container which just groups translations, and doesn't feature as Plone
content at all. The problem is that this kind of thing (non-content
container objects) isn't used anywhere in Plone these days (even though
it's quite possible), so there aren't established practices as to how it
should work. Is it worth considering at all?

--
jean                                              . .. .... //\\\oo///\\

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

Hanno Schlichting schrieb:

> On Thu, Jun 25, 2009 at 9:09 PM, robert rottermann<[hidden email]> wrote:
>>> Understandable, but with this the usability of the whole system suffers.
>>> We're actually trying to move away from folders as a separate type
>>> anyway. In Plone 5, you'll probably just have "pages" that may or may
>>> not contain sub-pages (and listings thereof).
>> exactly what I mean.
>> it is unfortunate that we do have folders.
>
> If your specific set of use-case is better served without any
> hierarchical organization of content, then please don't use folders.
> Just create a "large folder" and put all content into it. The
> "containers without an id or title" are the BTree-nodes of that large
> folder in that case - very similar to the talkback item they don't
> have a user visible representation and are just system internals.
>
> How you want to organize and structure your content in this scenario
> is up to you. You can use all the infrastructure today to do this, it
> just happens to be a rather uncommon way of doing things.
>
> Hanno
>
>

I see, I can not make myself understood.
I do *not* say not use folders. of course we need them.
what I try to say is they should *not be used for translation support*.
like to put different translations into different folders.

we must be able to translate folders *without touching the hierarchical
structure* of a site.
so we must be able to translate a folder *without copying it*. copying a folder
changes the structure of a site. which, as martin amply showed, has lots of side
effects.

it can be advisable to have different folders for different languages.
e.g a bookstore might have very different offerings for the divers languages and
votes to have separate folder hierarchies for every language.
*but such a decision has nothing to do with translation*

robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[robert rottermann]

> Then, if the user clicks the link for content in other language, it may:
>
> 1) Show content without changing the "selected language", which I
> believe would bring even more confusion.
>
> 2) Automatically change the selected language, so all UI messages will
> be in the same language as the main content. Then, ideally, if the user
> navigates away from the page, the previously selected language should be
> re-selected. Not sure if this can be done using the current negotiation
> scheme.
>

I think, the only thing needed is to flag the Item as "not in your language".
changing the UI language is very disturbing and produces lots of confusion.

robert

------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers