Re: Plone: Uebersetzung von Inhalten abseits von LinguaPlone

Michael Hierweck schrieb:
> 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.
>
>   
eventuell ist hier http://pypi.python.org/pypi/slc.linguatools/1.3.5
interessant
> 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?
>   
http://pypi.python.org/pypi/raptus.multilanguagefields
sieht viel versprechend aus ;)
> c) Seht ihr grundsätzliche Probleme dabei? (Etwa warum ein solcher
> Ansatz mit der Plone-Infrastruktur vom Grundsatz her nicht verträglich
> wäre.)
>   
Es gibt ein paar Dinge die nicht gehen, z.B. hast du für alle Sprachen
die selbe URL (Objekt ID), was man aber über ne Subdomain z.B. auch
etwas verbessern kann.
Und in vielen anderen Systemen gibt es keine sprechenden URLs so das der
Umstand für alle Sprachen z.B. eine aus englishen Begriffen aufgebaute
URL zu haben vertretbar ist.

Wie gesagt schau dir mal
http://pypi.python.org/pypi/raptus.multilanguagefields an das hat zu
mindestens einige deiner Probleme nicht und ist etwas weniger komplex,
dafür hat es natürlich nicht alle Möglichkeiten von LinguaPlone.

Gruß Maik

-- 
========================================================================

Derstappen    I T  Consulting   Tel:         +49 ( 341 )   600  13  0 31
Zope/E-Mail/Backup/Monitoring   Mobil:       +49 ( 178 )   861  2    833
M a i k   D e r s t a p p e n   Fax:         +49 ( 180 ) 5 021 121 90 56
H e r l o ß s o h n s t r  12   Email:  [email protected]
0 4 1 5 5       L e i p z i g   Internet:    http://www.derstappen-it.de

========================================================================



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