Martin Aspeli schrieb:
> All,
>
> I want to breathe some more life into the nascent effort to improve our
> multilingual content story. In particular, I'm interested in an approach
> that is so not tied to Archetypes, and possibly something that works
> with a smaller, simpler, framework-agnostic core, with "policy" for
> Archetypes, CMF, Dexterity and whatever else (including, possibly,
> things like portlets) being plugged in with separate packages.
>
> Some work has been done on this already in the form of
> plone.app.multilingual. It's languished in a separate repository for
> some time, but I'm reserving the right to move it back to the Plone
> repository.
>
> I would like to see who may be interested in working on this. Right now,
> I'm trying to figure out where plone.app.multilingual is at and whether
> this is still the solution, or if we need something else, or if we need
> something a little smaller.
>
> Some thought on the subject are here:
>
http://code.google.com/p/dexterity/wiki/Multilingual>
> See also
http://code.google.com/p/multilingualplone for the current code.
>
> So - who's interested in this? Who's got opinions on the best approach
> to take? :)
>
> Cheers,
> Martin
>
>
We run a site with 22 languages and maintaining it requires some special
attention. We would definitively like to be part of the work towards the
next solution.
- Language Fallback
I made the similar experiences as Robert. Only the first 2-3 levels of
the tree tend to be fully translated. Afterwards its either only the
default language or only a subset. Nevertheless it must be signalled to
the user that there is information available in another language,
otherwise the user assumes he has seen it all while he only got a few
translated docs. I have heard voices speaking against the mixing of
languages, and we indeed do currently use BlueLinguaLink to maintain
stubs in all languages where no translation is available. They allow the
navigation and overview pages to be built properly and inform the user
that there is additional information available in another language.
Drawback: We have a lot of them and it is hard to be consistent.
- Language folders
We also use language folders. We think it's more transparent when trying
to find information in another language, you simply switch the language
abbreviation in the path. And the language in the path is an indicator
for the content's language that will show up.
- Freshness of translations
On freshness of translation there is often the problem of budget to
update translations. Usually once the translations are done, the page is
never touched again. Sometimes the page is touched, and the problems
start. Either it is silently accepted that the other languages are out
of date, or the other languages are actually deleted to avoid presenting
old information. For the first case, a note to the user would be great
saying that the main language version is more up to date and for the
latter case, this note may remove the need to delete (expensively
created) translations.
- Canonical Content
From our point of view it makes very much sense to keep the notion of
canonical content because the quality of translations, especially for
more specialised topics, tends to be very poor. When reworking a
document it is vital to work on the original language.
- Language Independent Fields
Another important aspect is a clear yes to language independent fields.
With 22 languages, we use a lot of automatisms to keep them in sync.
Obviously a content manager defining a relation to another document does
not want to do it 22 times. So either he does it only on the canonical
and the rest looks it up there or he needs to use some customised
helperscript to propagage the values. The latter usually does not work
good for content managers.
- Independent Language versions
It is not there yet, but in the future we definitively want to reach the
situation where a content manager is keeping the rights on the canonical
while translators/translation-checkers have only rights to edit in their
language domains. So we would want completely independent language
version objects.
All together there are a lot of scenarios for multilingualism and
perhaps it even makes sense to offer different mechanisms depending on
the type of translations to expect. I'd definitively like to join forces
here.
best,
alex
------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
