Skip to content

feat: Alle 24 EU-Amtssprachen zur Auswahl (v2.37.0) - #100

Merged
daimpad merged 1 commit into
mainfrom
claude/fix-data-prep-errors-kJYpl
Aug 7, 2026
Merged

feat: Alle 24 EU-Amtssprachen zur Auswahl (v2.37.0)#100
daimpad merged 1 commit into
mainfrom
claude/fix-data-prep-errors-kJYpl

Conversation

@daimpad

@daimpad daimpad commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Problem

get_language_options() lieferte fest im Code genau zwei Sprachen: Deutsch und Englisch. Diese Liste speist nicht nur das Sprachfeld des Datensatzes, sondern auch alle drei Übersetzungs-Repeater (Titel, Beschreibung, Schlagworte) und die Standardsprache in den Einstellungen.

Mehrsprachige Metadaten waren damit praktisch auf Englisch beschränkt — obwohl das Plugin Mehrsprachigkeit in README und Feld-Referenz als Funktion führt. Für eine Organisation, die etwa polnisch- oder rumänischsprachige Zielgruppen erreicht, war das eine harte Grenze.

Der Befund dahinter

Die Begrenzung lag ausschließlich in der Auswahlliste. odw_resolve_language_tag() setzte alle 24 EU-Sprachcodes bereits korrekt nach BCP-47 um (DEUde, POLpl, HRVhr …). Die JSON-LD-Ausgabe war also längst vorbereitet — das Formular bot die Sprachen nur nicht an.

Änderung

  • config/vocabularies/language.json nach dem Muster der bestehenden Vokabulare (access-right, data-theme, contributors, engagementfeld). Deutsch und Englisch stehen vorn, die übrigen 22 alphabetisch darunter.
  • get_language_options() lädt daraus über load_vocabulary() und fällt auf Deutsch/Englisch zurück, falls die Datei fehlt oder unlesbar ist — ohne mindestens eine Sprache ließe sich weder eine Übersetzung pflegen noch eine Standardsprache wählen.

Keine Datenmigration nötig: Gespeichert wird weiterhin die EU-Authority-URI, bestehende Datensätze sind unberührt.

Verifiziert

Ein Prüfskript hat das Vokabular gegen den BCP-47-Umsetzer gehalten:

  • alle 24 angebotenen URIs haben eine Zuordnung — keine Sprache, die im Formular wählbar wäre, aber in der JSON-LD-Ausgabe verloren ginge
  • keine doppelten URIs
  • jedes ISO-Kürzel im Label stimmt mit der Zuordnung überein (kein „Polnisch (PT)")

Dazu php -l, JSON-Syntax, bin/check-i18n.py bei 0, Katalog-Abdeckung beidseitig leer, Feld-Referenz unverändert.

Bewusste Einschränkung

Wie bei den anderen gebündelten Vokabularen stehen die Bezeichnungen in der JSON-Datei und durchlaufen damit nicht die Übersetzungsdateien — auf einer englischen Installation steht „Polnisch (PL)" statt „Polish (PL)". Das ISO-Kürzel macht den Eintrag trotzdem eindeutig. Die Alternative wären 24 weitere __()-Aufrufe in class-fields.php, was dem etablierten Vokabular-Muster widerspräche.

Nebenbei

Die Roadmap in CLAUDE.md führte access-right und die EU-Sprachliste als offen. Das access-right-Vokabular liegt seit Längerem vor und wird verwendet; beide Punkte sind jetzt als erledigt vermerkt.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq


Generated by Claude Code

get_language_options() lieferte fest im Code nur Deutsch und Englisch —
und speiste damit nicht nur das Sprachfeld des Datensatzes, sondern auch
alle drei Übersetzungs-Repeater und die Standardsprache in den
Einstellungen. Mehrsprachige Metadaten waren praktisch auf Englisch
beschränkt, obwohl das Plugin Mehrsprachigkeit als Funktion führt.

Die Begrenzung lag ausschließlich in der Auswahlliste:
odw_resolve_language_tag() setzte alle 24 EU-Codes bereits korrekt nach
BCP-47 um. Die JSON-LD-Ausgabe war also vorbereitet, das Formular bot die
Sprachen nur nicht an.

- config/vocabularies/language.json nach dem Muster der bestehenden
  Vokabulare; Deutsch und Englisch vorn, die übrigen 22 alphabetisch.
- get_language_options() lädt daraus und fällt auf Deutsch/Englisch
  zurück, falls die Datei fehlt — ohne mindestens eine Sprache ließe sich
  weder eine Übersetzung pflegen noch eine Standardsprache wählen.
- Roadmap in CLAUDE.md geradegezogen: Sie führte access-right und die
  EU-Sprachliste als offen; access-right liegt längst vor.

Verifiziert: Alle 24 angebotenen URIs haben eine BCP-47-Zuordnung, keine
doppelten URIs, jedes ISO-Kürzel im Label stimmt mit der Zuordnung
überein. Dazu php -l, JSON-Syntax, check-i18n.py bei 0,
Katalog-Abdeckung beidseitig leer, Feld-Referenz unverändert.

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq
@daimpad
daimpad merged commit cdabe0d into main Aug 7, 2026
12 checks passed
@daimpad
daimpad deleted the claude/fix-data-prep-errors-kJYpl branch August 7, 2026 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants