Anforderungen, zu mehrere Sprachen für ein Dokument angeben zu können

[j3nsch]

Mehrsprachige Dokumente: Anforderung der UB Potsdam am Beispiel für ein Dokument in deutsch und englisch https://doi.org/10.25932/publishup-42654

Zwar gibt es extra für diesen Fall eine in Standard-OPUS eingerichtete Notfallvariante mit der Zuweisung von "mehrsprachig", aber das wäre für die Auslieferung über OAI reichlich unpräzise, wird von uns auch nicht genutzt, zumal man dann auch den Titel und das Abstract die Sprachoption "mehrsprachig" zuweisen müsste. Titel und Abstract haben aber immer eine konkrete Sprache, so wie die Publikationen selbst natürlich auch Texte in konkreten Sprachen enthalten und nicht einfach mehrsprachig sind.Korrekt wäre es, wenn man einer Publikation mehrere Dokumentsprachen hinzufügen könnte. Das geht aber leider nicht und ist in der Datenbank so auch nicht vorgesehen, da die Dokumentsprache direkt in der Tabelle documents hinterlegt wird.

Intern: https://tickets.zib.de/jira/browse/OPUSVIER-4069

[j3nsch]

XMetaDissPlus Referenzbeschreibung Version 2.2, deutsch urn:nbn:de:101-2012022107

21 Sprache der Hochschulschrift
Bezeichnung: dc:language
Attribut: obligatorisch: xsi:type (dcterms:ISO639-2)
Kardinalität: 1..n
Beschreibung Inhalt: Die Angabe der Sprache/n der Hochschulschrift erfolgt als Elementinhalt.
Hinweis: Die Codierung erfolgt gemäß ISO 639-2; d. h. für "deutsch" ist "ger" einzutragen.
XML-Syntax: <dc:language xsi:type=“dcterms:ISO639-2“>“dreistelliger Sprachencode“</dc:language>
Beispiel: <dc:language xsi:type=“dcterms:ISO639-2“>“eng“</dc:language>

OpenAire 4.0 Application Profile Overview [https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/application_profile.html] Field Language [https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_language.html#dc-language]

A specific resource (an instance of scientific output) is either written in one human language or more. In these cases all used languages are used in the DC element language. If a specific resource (an instance of scientific output) is written in one human language and is translated into other human languages, each translation does have its own record. ... If necessary, repeat this element to indicate multiple languages.

Dublin Core (Simple): http://www.dublincore.org/specifications/dublin-core/collection-description/collection-application-profile/

Language [dc:language]
...
Maximum Occurrences:    unbounded 

[j3nsch]

Die Sprachoption mehrsprachig sollte bestehen bleiben, auch um kompatibel zu bestehenden Dokumenten in OPUS 4 Instanzen zu bleiben.

Welche Erwartungen beim Browsen/Filtern sind sinnvoll, wenn wir Dokumente haben die mehrsprachig verwenden und Dokumente, für die mehrere Sprachen angegeben wurden. Vermutlich sollten diese auch als mehrsprachige Dokumente findbar sein. Wie kann man das am effizientesten umsetzen?

Für Dateien, also die Volltexte, müsste man dann auch mehrere Sprachen angeben können. Welche Auswirkungen hat das auf das User Interface?

[j3nsch]

Für die Teilaufgaben müssen weitere Issues in den jeweiligen Repositorien angelegt werden.

Der erste Schritt wäre die Erweiterung des Datenmodells für mehrere Sprachen. Das sollte nach oder für OPUS 4 v5.0, also die Version mit Doctrine und Laminas, gemacht werden.

[j3nsch]

Im Code von Opus\Document finden sich Hinweise, dass ursprünglich geplant war mehrere Sprachen für ein Dokument angeben zu können. Die Funktion _storeLanguage fast mehrere Sprachen als Liste mit Kommas zusammen, um die Werte in einer Datenbankspalte speichern zu können. Der Rest von OPUS 4 wurde aber später dafür nicht geschrieben. Es wurde irgendwann beschlossen nur eine Angabe zu erlauben. Mehrere Werte können in der neuen Implementation der Datenbankanbindung berücksichtigt werden. Der Aufwand steckt in den notwendigen Anpassungen im User Interface, Index, Export, OAI, um mit mehreren Sprachangaben umgehen zu können.

[j3nsch]

Bisher kann eine Sprache in einem Select-Element ausgewählt werden. In den meisten Fällen wird es bei einer Sprache pro Dokument bleiben. Es wäre unschön, den Aufwand für diese Fälle zu erhöhen. Wie kann man beides unterstützen?

Ein völlig freies Eingabefeld wäre unbequem und anfällig für Fehler bei der Eingabe. Ein Select mit einem Add Button würde es ermöglichen nacheinander mehrere Werte zu setzen. Die GUI müsste auch das Entfernen von ausgewählten Werten erlauben. Eine Liste mit Checkboxen für alle erlaubten Sprachen wäre schnell bedienbar und leicht umzusetzen. Es gibt aber Instanzen bei denen diese Liste sehr lang wäre (30+).

Am elegantesten wäre eine Popup-Checkbox-Liste, bei der direkt im Formular nur die ausgewählten Werte angezeigt werden. Mit einem Click auf das Element bzw. einen Button würde ein Popup angezeigt mit der Checkbox-Liste für die Sprachen. Auf diese Weise hat man eine einfache Bedienung und verbraucht nicht mehr Platz im Formular. Die Liste würde ähnlich wie bei einem Select-Element angezeigt. Solche Formularelemente werden z.B. auch in JIRA bei den Filtern für die Suche eingesetzt.

Es muss evaluiert werden, wie ein solchen Element umgesetzt werden kann. Nach Möglichkeit sollte eine eigene Entwicklung vermieden werden. Eine gute Lösung würde sich vermutlich auch an einigen anderen Stellen einsetzen lassen. Es muss auf Barrierefreiheit geachtet werden, insbesondere im Publish-Formular und in der Suche.

@alw-bsz FYI

[j3nsch]

Ein solches "Checkbox-Select" könnte man auch im Dateimanager für die Auswahl von Rollen verwenden, um die Anzeige dort übersichtlicher zu machen. Ich denke der Aufwand würde sich lohnen, aber Barrierefreiheit ist ein Problem über das nachgedacht werden muss. Idealerweise sollten die Formulare auch ohne Javascript funktioniert, eben so wie jetzt auch. Für die Sprachen müsste dann eben eine lange Liste direkt angezeigt werden. Das wäre auf jeden Fall bedienbar.