Administration der Sprachen entfernen

[j3nsch]

Die Verwaltung der in OPUS 4 verfügbaren Sprachen ist eigentlich unnötig. Es werden die Informationen aus ISO 639 für die Sprachen, die lokal verwendet werden sollen abgebildet.

https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes

Verwendet werden eigentlich nur die Namen, die 2-er und die 3-er Abkürzungen. Diese könnten in OPUS 4 verfügbar gemacht werden, ohne das Sprachen manuell hinzugefügt werden müssen.

Die Auswahl der lokal verwendeten Sprachen könnte über einen einfachen Konfigurationsparameter erfolgen, der optional auch die Reihenfolge der Anzeige bestimmen kann (Siehe #721).

Der Bereich für die Verwaltung der Sprachen könnte komplett entfernt werden.

[j3nsch]

@alw-bsz, @sigwei, @vgerlach Für das Mapping von Sprachen beim DeepGreen Import sind ISO 639 Informationen notwendig. Dabei können immer Sprachen auftauchen, die lokal nicht definiert wurden. Eine Datei mit den Informationen für "alle" Sprachen löst das Problem. Wenn wir eine solche Datei haben, macht das lokale anlegen von Sprachen aber noch weniger Sinn. Die konfigurierten Sprachen würden lokal in den Formularen angeboten werden. Beim Import und Export könnten aber alle Sprachen verarbeitet werden (#866).

Die Verwaltung der Sprachen ist sicherlich kein komplizierter Teil der Administration, aber so könnte der Code und Aufwand reduziert werden. Es wäre eine erste, relativ unkritische Sache, die entfernt werden könnte.

Seht Ihr Probleme?

Ich würde die Liste der Languages evtl. auf welche mit 2-er Code beschränken. Die Liste sollte in opus4-i18n abgelegt werden.

Eine JSON-Datei würde Sinn machen, aber ich denke am Ende sollte es ein in PHP-Code definiertes Array sein. Der Vorteil ist, dass die Ausführung von PHP-Dateien von der Laufzeitumgebung optimiert werden kann, während eine JSON-Datei bei jedem Request erneut eingelesen werden muss. Deshalb wurde bei Zend 2+ und Laminas die Konfiguration auch in PHP-Dateien verlagert.

[alw-bsz]

Ich halte das für sinnvoll und sehe keine Probleme.

Wir haben tatsächlich in einer Instanz, die ausschließlich für automatisierte Importe aus einem anderen System vorgesehen ist, alle Sprachcodes in die Datenbank eingetragen. Falls Dir das irgendwie hilft - z.B. als Grundlage für eine JSON-Datei oder PHP-Array - kann ich das gerne zur Verfügung stellen.

[j3nsch]

Vielen Dank! Schickt mir mal bitte Eure Tabelle als CSV-Datei oder auch als SQL-Dump. Ich werde dann daraus PHP Code generieren, um, wie oben beschrieben, das Laden einer Datei zu vermeiden. Wahrscheinlich lasse ich die Namen der Sprachen weg, um Platz zu sparen. Wir sind, soweit ich das überblicke, nur an den Codes interessiert und die Namen kennt die PHP-Klasse Locale. Das verwenden wir auch jetzt schon für die Übersetzungen im Language-Select.

[alw-bsz]

languages.sql
languages.csv

Die Sprache "Dogri" hat das Kürzel "doi". Das führt aktuell zu einem Konflikt mit dem Übersetzungsschlüssel "doi" für den DOI-Import (in default/doctypes.tmx).

[j3nsch]

Danke. Eigentlich wollte ich ja nur die Sprachen nehmen, die auch einen zweier Code haben, aber dann werde ich die komplette Liste übernehmen.

Die Sprachen sollen dann auch alle im Metadaten-Formular auswählbar sein? Der Gedanke oben ist ja die aktiven Sprachen in einer Option aufzulisten. Das sollte für die meisten Instanzen eine relativ kurze Liste sein. Es geht dabei auch nur um das Language-Select in den Formularen. Wenn alle Sprachen auswählbar sein sollen, würde ich dafür einen separaten Schalter bauen, damit nicht 485 Codes in eine Liste geschrieben werden müssen.

[alw-bsz]

Ich denke, es genügt eine Option, um die auswählbaren Sprachen aufzulisten. Die Instanz mit den vielen Sprachen ist ein singulärer Ausnahmefall. Dort werden die Datensätze ausschließlich per Import eingespielt, die Publish-Formulare überhaupt nicht und die Dokumentenverwaltung nur in Ausnahmefällen verwendet.

[j3nsch]

Die Sprache "Dogri" hat das Kürzel "doi". Das führt aktuell zu einem Konflikt mit dem Übersetzungsschlüssel "doi" für den DOI-Import (in default/doctypes.tmx).

Danke für die Info. Die Übersetzungsschlüssel für die Dokumenttypen brauchen einen Präfix (#915). Der "DOI" Dokumenttyp ist auch ein Hack. Die Übersetzungsschlüssel für Sprachen, wenn überhaupt notwendig, brauchen auf Präfixe. Letzteres werde ich im Rahmen dieses Issues mit angehen. Ich denke der Präfix language_ sollte ausreichen, opus_language_ wäre noch besser, mit opus_ als Präfix für globale Übersetzungen, die keinem Modul zugeordnet sind (sonst default).