webEdition - Forum

Dieser Wunsch soll laut neuem Workflow für Featurewünsche hier bitte zunächst diskutiert werden.

Es steht im Original in der Bugbase und wird dann auch dort weiter bearbeitet, wenn sich hier eine positive Lösung herausstellt.

Originaltext von Dominik Bößl:

"Wenn wir für einen Kunden eine zweisprachige Website umsetzen und bei Bildern eine Beschreibung ausgeben möchten, so nutzen wir meist die Titel- und Alt-Felder direkt beim Bild und geben dann je nach Workspace ein anderes Feld aus. An sich schon nicht besonders elegant, aber problematisch wird es, wenn es noch weitere Sprachen gibt. Unsere bisherige Lösung ist entweder je Sprache das Bild separat zu integrieren und hier wie vorgesehen die entsprechende Felder zu nutzen. Oder je Bild ein verknüpftes Objekt anlegen, in welchem die Inhalte stehen. Beides keine besonders benutzerfreundlichen Lösungen. Unser Wunsch wäre die Integration eines neuen Features bei den Bildern, mit der man je Sprache individuelle Felder für zusätzliche Texte definieren kann."

Wir fanden das in der Gruppe gut und haben uns auf den webEdition-Intensivtagen folgende Lösung ausgedacht:

• Titel, Alt und longdesc sind beim Bild pro installierter Systemsprache pflegbar

• Die Sprachen sollen per Accordeon zum öffnen/schließen sein, dort dann die drei Felder pflegbar. Das verhindert bei vielen Sprachen einen sehr langen Bereich.

• Ausgabe der beim Bild gepflegten Texte dann abhängig von Dokumentensprache. Ist das Dokument also englisch, wird automatisch der englische alt, title und longdesc verwendet.

• Es muss ein sprachunabhängiges Default geben, das immer ausgegeben wird, wenn nichts sprachspezifisches gepflegt wurde. Die Sprachoption ist also zusätzlich.

• Bei nur einer Sprache im System keine Anzeige der sprachspezifischen Optionen (also dann so lassen, wie es jetzt ist).

• Frage: Macht es Sinn, dann eventuell auch custom fields diesem Mechanismus hinzufügen?

• Die sprachspezifischen Texte müssen bei den Eigenschaften des Bildes selbst, im we:img und bei im Tiny platzierten Bildern bei der Ausgabe berücksichtigt werden.

ich finde das stark abhängig davon, welche Möglichkeiten webEdition allgemein für die Übersetzung in Zukunft bieten möchte. Dies betrifft z.B. Texte in Templates und auch die Sprachabhängigkeit von Objektfeldern. Wenn Properties grundsätzlich eine Lokalisierung bekommen können, könnte die Logik sowohl für die alt/title Texte beim Bild, aber auch z.B. Textfeldern bei Objekten eingesetzt werden.

Bei Bildern als auch Objekten stellt sich dann auch die Frage der Url in anderer Sprache. Möchte ich in einem finnischen Auftritt, deutsche Bildpfade haben? Eigentlich nein. Gleiches gilt dann für SEO-URLs bei Objekten. Ich würde denken der Feature Request ist durchaus beachtenswert, sollte aber bzgl. Lokalisierung umfassender gedacht werden.

Timo

Ja, das ist ein generelleres Thema. In webEdition ist nun mal bisher die Devise: pro Sprache ein Objekt / Dokument. Folgerichtig müsste das auch für Bilder, PDFs etc. gelten, die dann eben doppelt angelegt werden müssen. Hier bricht webEdition mit der eigenen Logik.
Ich rate da zu einer Konsequenz:
entweder weiterhin pro Sprache ein Objekt/Dokument etc. eine Sprache, dann aber auch für Bilder, Navi etc. überall so durchziehen
oder aber den Ansatz allgemein ändern und die Sprache in dem jeweiligen Objekt / Dokument / Bild etc. bearbeitbar machen.

Beides hat Vor- und Nachteile. Ich schaue da immer gern auf andere Systeme und die Erfahrungen dort. In ProcessWire (https://processwire.com/docs/multi-language-support/) wird z.B. der zweite Ansatz verfolgt. Das führt dann aber ggf. bei jedem Feld zu x Eingabefeldern, eben eines pro Sprache. Es macht auch unterschiedliche Seitenbäume eher komplexer. Für Redakteuer ist das aber oft bedeutend leichter.

Also eine richtige Entscheidung kann ich hier für wE noch nicht treffen, dazu müssten die Wege klarer sein. Nur die Bilder zu betrachten halte ich aber für zu kurz gesprungen.

Da Mehrsprachigkeit ein durchaus zukunftsträchtiges Thema ist, lohnt es sich vielleicht, hier mal mehrere FR dazu zu sammeln und ein kleines Bundle für einen kommenden Release zu schnüren.

Die Frage hier bei den Bildern geht ja quasi in die Richtung die auch processwire nimmt - also mehrere Sprachen pro Feld.

Beim Ansatz pro Sprache ein Dok/Objekt paßt eigentlich alles noch in WE. Jetzt aber die Bilder zu duplizieren, die evtl. nicht Sprachabhängig sind, nur um die Felder so anzulegen wäre blöd. Daher denke ich schon, das es hier Sinn machen würde bei den Bildern mehrere Sprachen zu ermöglichen.

Ich denke auch, dass Mehrsprachigkeit hier Sinn macht und finde einen Ansatz auf Basis der Felder verfolgenswert.

Ein paar Sonderfälle die mir in dem Zusammenhang einfallen:

• Ev. notwendige Fallbacks, wenn eine Sprache nicht befüllt ist.
• Mache Felder brauchen in der Regel auch keine Übersetzung (z.B. Copyright).
• Manchmal kann es auch notwendig sein, dass das Bild bzw. Dokument übersetzt werden muss (z.B. Bild mit Schriftzug).

PS: Falls das Verfolgt wird, könnte man das auch gleich für die Kategorien mitdenken bzw. mitnutzen (sh. https://qa.webedition.org/view.php?id=10265).

Bei Bildern gibt es doch die Metadatenfelder. Damit lässt sich das jetzt schon abbilden. Man könnte die Felder und we:metadata eventuell noch auf Mehrsprachigkeit erweitern.

Wir machen das aktuell auch über die Metadatenfelder, da das recht flexibel funktioniert und die je nach Projekt individuell angepasst werden können. Daher weiß ich nicht, ob eine Erweiterung hier wirklich notwendig ist.

Das sind halt keine Lösung vom System, sondern mit dem System. Jeder wird dann eine "eigene" Lösung haben. Besser wäre es doch, wenn das von webEdition schon mitgebracht wird. Ist ja - wie schon geschrieben - nicht nur für die Bilder interessant.

Ich könnte mir das auch wie Sprachvarianten vorstellen, die befüllt werden können (z.B. DE/EN/FR). Je nach aktueller Seitensprache (z.B. EN), wird dann für jedes Feld automatisch der richtige Sprachwert zurückgegeben (z.B. für das englische Alt-Attribut). Da muss man die Namen der Metadaten-Felder nicht extra zusammenstückeln, sondern kann einfach den Feldnamen verwenden.