Plone: Uebersetzung von Inhalten abseits von LinguaPlone

Hallo allerseits,

im Rahmen eines Projekts schlagen wir uns seit längerer Zeit mit der
Übersetzung von Inhalten herum. Wir haben versucht, unseren
Anwendungsfall auf LinguaPlone abzubilden, stoßen aber immer wieder auf
neue Probleme.

Damit möchte ich nicht LinguaPlone kritisieren, auch wenn es bekanntlich
Schwächen hat, sondern vor allem daraufhinweisen,

a) dass wir es ernsthaft versucht haben, uns mit LinguaPlone zu arrangieren
b) trotz Anpassungen von LinguaPlone zu Ergebnis gekommen sind,
langfristig damit mehr Probleme zu schaffen als zu lösen.

Bekanntlich ist LinguaPlone so konzipiert, dass Übersetzungen
vollständige Content Objekte sind, insbesondere haben sie einen
individuellen Workflow (State), individuelle Local Roles und einen
individuellen Ort (und damit URL) in der Objekthierarchie.

Das ist sicherlich ein geeigneter Ansatz, wenn man Übersetzungen als
vollwertig ansieht (mit eigenen Freigabeprozess) und vielleicht sogar
mit  gesonderten Redakteuren für die verschiedenen Sprachen arbeitet.

Andererseits macht es Aspekte wie einen Language-Fallback schwierig und
Abfragen über die Content-Hierarchie "eigenwillig", insbesondere, wenn
man einen Language-Fallback hat.

Aktuell haben wir folgende Anforderungen:

a) Wir brauchen einen gemeinsamen Workflow State, gemeinsame Local Roles
und identische Permissions auf einem Objekt und seinen Übersetzungen
(mit folgender wichtiger Ausnahme:)

b) Es muss in bestimmten Workflow Stati möglich sein, Übersetzungen zu
löschen, die Ausgangsversion (in LinguaPlone "Canonical") jedoch nicht.

c) Wir brauchen einen Language Fallback, d.h. jedes Objekt soll bei
Suche in der sinnvollsten Sprachversion gefunden werden.


Bis hierher konnten wir die Probleme durch erhebliche Eingriffe lösen,
nämlich:

* Unterbinden des (Un)Link-Translations-Features von LinguaPlone
* Synchronisation von Worflow und Local Roles durch Monkey-Patches und
Subscriber.
* Eigene Permissions und eigenes UI für "Delete Translation".
* Language Fallback, zumindest bei Catalog Queries (versagt bei
Containment-Fragen, also auf den Index "path" und natürlich, wenn man
sich das Folder Listing durch direkten Zugriff statt per Catalog Query
holt.)


Wir vermuten jedoch, dass in der Praxis die Beabeiter und auch die
Besucher verwirrt werden, da sehr viele wichtige Elemente (Folder
Listing, Navigationsbaum, Sitemap, Breadcrumbs) auf der der Hierarchie
basieren und sich mit (/news vs. /news-de vs. /news-fr völlig
unterschiedliche Bäume öffnen.)

(Anm.: Technisch ist das Konzept von LinguaPlone nachvollziehbar, ich
argumentiere leidglich in die Richtung, dass LinguaPlone nicht auf
unseren Fall passt.)

Wir sind daher insgesamt der Ansicht, dass LinguaPlone viele Features
bringt, die wir nich benötigen, andererseits einen Implementationsweg
gewählt hat, der unserer (projektspezifischen) Sicht von Übersetzung so
erheblich unterscheidet, dass man, wenn man sich damit arrangieren will,
immer mehr Anpassungen von Kernkomponenten benötigt und damit Gefahr
läuft, vermutlich früher als später nicht updaten zu können.


Wir erwägen daher ernsthaft uns von LinguaPlone (für dieses Projekt) zu
trennen und Übersetzungen innerhalb des Content Objects abzuwickeln,
statt Hacks und Anpassungen eine saubere "andere" Implementation zu
wählen oder zu entwickeln.


Fragen:

a) Ist unser Problem nachvollziehbar oder gibt es einen
(offensichtlichen, vermuteten o.ä.) Denkfehler?

b) Gibt/Gab es bereits Versuche (wir konnten keine ernsthaften finden),
Übersetzungen im Objekt zu speichern?

c) Seht ihr grundsätzliche Probleme dabei? (Etwa warum ein solcher
Ansatz mit der Plone-Infrastruktur vom Grundsatz her nicht verträglich
wäre.)

(Anmerkungen:

Eine Implementation, etwa auch Archetypes-Basis könnte ich mir
folgendermaßen vorstellen:

Die Übersetzungen der Felder müssten in einer Art Array oder Dictionary
gehalten werden. Die "Getter" müssten die richtige Sprachversion des
jeweiligen Feldes auswählen.

Probleme bereiten für mich die Indizierung (z.B. kann FieldIndex nur
einen Wert speichern) und die Brains (die offensichtlich nur einsprachig
sind.)

Viele Grüße

Michael


_______________________________________________
zope mailing list
[email protected]
https://mail.dzug.org/mailman/listinfo/zope