Open Data Wizard 2.41.1

Ein Nachtrag zum Usability-Test: der Startwert der Qualitätsprüfung.

🐛 Fixed

• „Neuen Datensatz anlegen" startete bei 7 %, nicht bei 0 %. Zwei Ursachen, beide
  dieselbe Sorte Fehler — der Wizard rechnete sich an, was er selbst vorgibt. WordPress legt
  beim Öffnen des Formulars einen Auto-Entwurf an und feuert dabei save_post: Das
  Änderungsdatum wurde gestempelt (5 Punkte), obwohl niemand etwas gespeichert hatte. Und
  Carbon Fields liefert für ungespeicherte Felder ihren Vorgabewert zurück — die Zugriffsrechte
  stehen auf „öffentlich", das zählte als Angabe plus Vokabulartreffer (10 + 5 Punkte).
  Zusammen 20 von 295 bewertbaren Punkten. Der Bericht wertet auf einem Auto-Entwurf jetzt
  nichts als erfüllt, und set_modified_date() überspringt ihn. Der Nenner bleibt dabei
  stehen: Die Metriken sind prüfbar, sie sind nur noch nicht erfüllt — 0 von 0 Punkten ergäbe
  wieder eine überraschende Zahl. Zwei Unit-Tests und ein E2E-Test halten die 0 fest.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.41.0

Fünf Punkte aus dem Usability-Test. Hilfetexte haben jetzt je einen Ort, die Definition zeigt
ihre Struktur und verweist auf den Standard — und wo ein Feld eine feste Auswahl hat, ist es
auch eine Auswahl und kein Textfeld, das seine Optionen erst nach dem Tippen preisgibt.

✨ Added

• Merkmalsliste über jeder Definition. Das „Mehr erfahren"-Panel nennt oben in zwei Zeilen
  die DCAT-AP-Eigenschaft und die Multiplizität, darunter folgen wie bisher Alltagssprache und
  Definition. Der Tester hatte bemerkt, dass die Definitionstexte einer festen Struktur folgen,
  diese aber nur im Fließtext steht.
• cardinality als eigenes Feld im Katalog — für alle 53 Einträge. Zwei neue Tests halten
  den strukturierten Wert und die Angabe im Definitionstext zusammen; ohne sie laufen beide
  auseinander, sobald jemand nur eine Seite anfasst.
• Link auf die Spezifikation je Profil-Klasse. Am Fuß jedes Panels steht „Im Standard
  nachlesen: Datensatz" bzw. „: Distribution" mit Verweis auf den passenden Abschnitt von
  DCAT-AP.de 3.0. Bewusst je Klasse und nicht je Feld: Die feldgenauen Anker ließen sich von
  hier aus nicht überprüfen — bei den drei Klassen-Ankern führt ein Irrtum schlimmstenfalls an
  den Anfang des richtigen Dokuments. Die Zuordnung der 12 Distributions-Felder stammt aus
  odw_build_distribution_node() und wird von einem Test dagegen gehalten.
• entity als eigenes Feld im Katalog — 41 Datensatz-, 12 Distributions-Felder,
  gegengeprüft gegen die Registry.

✨ Added (Fortsetzung)

• Thema ist eine Mehrfachauswahl. dcat:theme erlaubt laut Profil 0..n Themen; das Formular
  bot ein Auswahlfeld in Tab 1 und ein Tipp-Feld unter „Erweiterte Angaben" — zusammen höchstens
  zwei, auf zwei verschiedene Arten. Beide sind durch ein Mehrfachfeld mit den EU-Themen ersetzt.
  Der Batch-Import nimmt jetzt ebenfalls mehrere Themen an (Komma- oder Zeilentrennung).
• Engagementfeld ist eine Mehrfachauswahl, Contributor-ID ein Auswahlfeld. Beide waren
  Textfelder mit einer <datalist> dahinter — man musste erst tippen, um überhaupt zu sehen,
  dass es eine Auswahl gibt, und wer daneben tippte, bekam einen Wert ohne URI. 16 bzw. 69
  Einträge passen in eine Liste. dct:subject erlaubt 0..n, deshalb ist das Engagementfeld
  mehrfach wählbar; die Contributor-ID bleibt einfach.
• Die CESSDA-Vorschläge öffnen sich beim Anklicken. Mit mehreren hundert Konzepten bleibt
  hier eine Vorschlagsliste richtig — aber eine, die zeigt, was zur Auswahl steht. Sie ersetzt
  das native <datalist> durch eine eigene Liste mit Tastaturbedienung (Pfeiltasten, Enter,
  Escape). Nebeneffekt: Das Verhalten ist in allen Browsern dasselbe und im E2E-Test überhaupt
  prüfbar — ein datalist-Popup ist Browser-Chrome und für Playwright unsichtbar.

🎨 Changed

• Tooltip und „Mehr erfahren" haben getrennte Rollen. Das ⓘ trägt nur noch den DCAT-AP-Begriff,
  alles Erklärende steht im Panel. Vorher stand beides an beiden Orten — beim Herausgeber sogar
  mit unterschiedlichen Beispielen. Betrifft 42 Felder.
• Fünf Felder hatten gar keinen Fachbegriff im Tooltip, sondern schon dort Prosa: die drei
  Kontaktfelder, die eigene Lizenz-URI und die HVD-Kennzeichnung. Sie tragen jetzt ihren
  tatsächlich ausgegebenen Begriff (vcard:fn, vcard:hasEmail, vcard:hasURL, dct:license,
  dcatap:applicableLegislation).
• Das Schlagwort-Beispiel widersprach seiner eigenen Regel. Der Text verlangte ein Wort je
  Zeile und nannte dann ein Beispiel mit Kommas — wer nur den Katalog las, tippte genau die
  falsche Form.

🐛 Fixed

• Migration der Themen, damit nichts verlorengeht. Carbon Fields legt Mehrfachwerte unter
  eigenen Meta-Keys ab (_odw_theme|||0|value), die alten flachen Zeilen wären unsichtbar
  geworden. Eine einmalige Umschreibung überführt beim ersten Aufruf des Backends alle
  Datensätze — über carbon_set_post_meta(), nicht über selbstgebaute Schlüssel, weil deren
  Format ein Interna der Bibliothek ist.
• Themenfilter und Sortierung wären still kaputtgegangen. Beide fragten die Datenbank auf
  _odw_theme ab und hätten Mehrfachwerte nicht mehr gefunden. Das Plugin schreibt die Auswahl
  deshalb zusätzlich flach: _odw_theme_index (eine Zeile je Thema) für den Katalogfilter,
  _odw_theme_sort für die Spaltensortierung. Der bestehende E2E-Test auf ?theme=Bildung
  prüft das mit — und fand dabei gleich noch, dass der Katalogfilter den Parameter anders
  auflöste als der Index geschrieben wird: resolve_theme_uri() kennt nur die EU-Bezeichnungen,
  und „Bildung" heißt dort „Bildung, Kultur und Sport". Der Filter nimmt jetzt dieselbe
  Auflösung wie das Speichern, damit Harvester mit dem alten deutschen Kurznamen weiter
  Treffer bekommen.
• Das Engagementfeld hätte seinen Wert verloren. Wie beim Thema ändert die Mehrfachauswahl
  das Speicherformat; dieselbe einmalige Umschreibung überführt jetzt beide Felder und löst
  dabei einen von Hand eingetippten Namen zur Vokabular-URI auf.
• bin/check-i18n.py übersah config/. mqa-metrics.php und dcat-ap-fields.php führen
  ihre Beschriftungen über __(), standen aber nicht in der Dateiliste der Prüfung — für 31
  Zeichenketten hätte eine fehlende Übersetzung also nie jemand gemeldet. Aufgefallen ist es,
  weil ich beim Aufräumen der Kataloge beinahe genau diese Einträge gelöscht hätte.

🧹 Removed

• Das generische Vokabular-Autosuggest (data-odw-vocab) ist entfallen — mit Thema,
  Engagementfeld und Contributor-ID hatte es keine Nutzer mehr. Damit entfällt auch die
  Auslieferung der drei Vokabulare an jede Admin-Seite; die Optionen stehen jetzt im Formular
  selbst. Die Vokabulardateien unter config/vocabularies/ bleiben unverändert.

ℹ️ Eine Ausnahme mit Begründung

Das Wiederholfeld für weitere Distributionen behält seinen Hilfetext: Für dieses Feld gibt es
keinen Katalogeintrag, das Panel erscheint dort also gar nicht — der Tooltip ist die einzige
Erklärung, die es hat.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.40.2

Zwei Rückmeldungen aus dem Backend.

🐛 Fixed

• Doppelte Nummern auf der Einstiegsseite. Die fünf Schritte standen in einer <ol>, deren
  Zähler zusätzlich zu der Nummer erschien, die schon im Text steht („1 — Grundlegende
  Informationen"). Ergebnis: „1. 1 — Grundlegende Informationen". Die Liste zeigt jetzt keine
  eigenen Aufzählungszeichen mehr; die Nummern im Text bleiben, weil sie den
  Reiterbeschriftungen im Formular entsprechen.

🎨 Changed

• Menü-Icon ist wieder ein Dashicon (dashicons-database) statt der zugeschnittenen
  Logo-Fassung. Im WordPress-Menü sind alle Symbole gleich gezeichnet und werden bis zum
  Daraufzeigen gedimmt; eine Marke an dieser Stelle fällt aus der Reihe, statt sich einzufügen.
  assets/images/ODW-Icon.svg war ausschließlich dafür da und entfällt damit.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.40.1

Ein Fehler im Delta-Endpunkt, gefunden von den wiederbelebten End-to-End-Tests — und die
Absicherung drumherum: zwei Lücken in der CI geschlossen, die größte ungetestete Klasse
getestet, die brachliegenden E2E-Tests wieder in Betrieb genommen.

🐛 Fixed

• /delta?since=… wies Zeitstempel mit Sekundenbruchteilen ab. Wer den Parameter so
  erzeugt, wie es am nächsten liegt — JavaScripts toISOString() hängt immer Millisekunden an,
  Pythons datetime.isoformat() Mikrosekunden —, bekam HTTP 400 statt seiner Daten. RFC 3339
  erlaubt Sekundenbruchteile ausdrücklich (time-secfrac); die Formatliste in parse_iso8601()
  kannte sie schlicht nicht. Aufgefallen ist es, weil der neue E2E-Test genau so einen
  Zeitstempel baut. Genau dafür sind diese Tests da: Der Unit-Test prüfte bis dahin nur
  Schreibweisen, die jemand von Hand tippt.

🔧 Nur im Repository, nicht im Paket

Die folgenden Punkte betreffen ausschließlich .github/, bin/, tests/, config/ sowie
die Node- und wp-env-Dateien. Nichts davon wird ausgeliefert.

• Das Release-ZIP wird jetzt geprüft. Bisher liefen PHPCS, PHPStan, PHPUnit und SHACL
  alle gegen das Repository — das Paket, das Anwender:innen installieren, sah keine von
  ihnen an. Eine vergessene Zeile in der Allowlist von bin/build-release.sh erzeugte
  daher ein ZIP, das in grüner CI entstand und trotzdem in einer echten Installation
  Fehler warf; genau das ist bei blocks/ in v2.38.0 passiert und fiel nur beim manuellen
  Entpacken auf. Der neue Job „Release-Paket prüfen" baut das ZIP bei jedem Push und prüft
  es mit bin/verify-package.py.
• Die Prüfliste pflegt sich selbst. Das Skript liest jeden Pfad, den der Code über
  ODW_PLUGIN_DIR/ODW_PLUGIN_URL bildet, aus den im Paket enthaltenen PHP-Dateien —
  aktuell 35 — und sieht nach, ob er dort liegt. Eine handgepflegte Liste würde veralten,
  diese wächst automatisch mit. Dazu Autoloader, block.json und die kompilierte .mo,
  die kein solcher Ausdruck nennt. Bewusste Ausnahmen stehen mit Begründung im Skript.
• Versionsgleichheit wird erzwungen. Plugin-Header, ODW_VERSION und der oberste
  CHANGELOG-Eintrag werden von Hand an drei Stellen gepflegt; weichen sie ab, zeigt
  WordPress die falsche Version an und der Updater vergleicht gegen den falschen Stand.
• bin/check-i18n.py läuft jetzt in der CI. Das Skript existierte, wurde aber nur von
  Hand aufgerufen. Eine beim Umformulieren vergessene Übersetzung hätte auf englischen
  Installationen mitten im Backend einen deutschen Satz gezeigt.
• 40 Testfälle für den Batch-Import. includes/class-batch-import.php war mit 571 Zeilen die
  größte ungetestete Klasse — und die einzige Stelle im Plugin, an der fremde Dateien auf den
  Code treffen. Abgedeckt sind jetzt: Formaterkennung (auch über den ursprünglichen Dateinamen
  bei temporären Uploads), UTF-8-BOM aus Excel-Exporten, verrutschte Spaltenzahl, Leerzeilen,
  JSON-Einzelobjekt gegen JSON-Liste, Pflichtfeldprüfung, URL-Schemata (javascript: und
  data: werden abgewiesen), ganzzahlige Dateigröße, Lizenz-Kurzcodes, Formel-Injektion
  (=, +, @, Tabulator) sowie die Anlage der Datensätze samt Meta-Zuordnung, Lizenz-URI
  und Schlagwort-Normalisierung. Suite gesamt: 199 → 239 Tests.
• Drei Sniff-Ausnahmen für tests/. Tests laufen ohne WordPress: wp_delete_file(),
  WP_Filesystem und wp_parse_url() gibt es dort nicht. Fixture-Dateien werden daher direkt
  geschrieben und gelöscht, und der wp_parse_url()-Mock muss parse_url() aufrufen — das ist
  genau die Verhaltensweise, die er nachbildet.
• Drei Gründe, warum die alten E2E-Tests nie liefen — alle erst im ersten CI-Lauf sichtbar
  geworden: mappings in .wp-env.json bildet Verzeichnisse ab, keine einzelnen Dateien
  (die Saat lief deshalb nicht); mit den Standard-Permalinks gibt es /wp-json/ überhaupt nicht,
  alle Endpunkte antworteten 404; und die Reiter-Selektoren zeigten auf cf-container__tabs-nav
  / cf-tab--active, während Carbon Fields 3.6 cf-container__tabs-list,
  cf-container__tabs-item und --current rendert — was im Kommentar über dem Block
  FORMULAR-DESIGN in assets/css/admin.css seit jeher richtig steht.
• Die End-to-End-Tests laufen wieder — und prüfen jetzt etwas. tests/e2e/ enthielt zwei
  Spec-Dateien, die niemand ausführte: Es gab keine WordPress-Instanz, die Anmeldung klickte auf
  einen button[type=submit], den das WordPress-Login gar nicht hat, und die Datensatz-ID wurde
  aus einem p=-Parameter gelesen, den @id nie enthielt. npx wp-env startet nun WordPress
  samt Plugin, ein neuer CI-Job fährt Chromium dagegen.
• Keine bedingten Zusicherungen mehr. Der Großteil der alten Tests stand in einem
  if (await x.count() > 0) — sie waren grün, wenn das geprüfte Element fehlte. Genau die
  Konstruktion also, die eine kaputte Oberfläche als bestanden meldet. tests/e2e/seed.php legt
  als mu-plugin zwei veröffentlichte Datensätze an, damit die Zusicherungen unbedingt sein können:
  der Katalog enthält mindestens zwei Einträge, der Themenfilter liefert genau den passenden,
  der zweite Abruf kommt aus dem Cache, /wp/v2/odw_dataset antwortet mit 404.
• Im Backend geprüft: alle sieben Spalten der Datensatzliste, Qualitätsbadge mit Prozentwert,
  schreibgeschützter Shortcode, fünf Reiter im Formular, Reiterwechsel, blockierte Veröffentlichung
  samt Nennung des fehlenden Feldes, speicherbarer unvollständiger Entwurf, Einstiegsseite mit
  Ablaufgrafik und die Harvest-URLs auf der Einstellungsseite.
• Die version in package.json stand seit v2.1.4 still und zeigt jetzt wieder auf die
  Plugin-Version. Sie wird nicht ausgeliefert, war aber beim Nachsehen schlicht irreführend.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.40.0

Eine Ablaufgrafik, die erklärt, was das Plugin eigentlich tut.

✨ Added

• assets/images/ODW-Ablauf.svg — „Vom Formular ins Datenportal" in drei Schritten:
  Formular ausfüllen → DCAT-AP.de-Metadaten erzeugen → Portale ernten den Katalog ab.
  Eingebunden im README (unter „Die Idee") und auf der Einstiegsseite im Backend.

ℹ️ Zwei Entscheidungen dahinter

• Nur Begriffe, die das Plugin auch wirklich ausgibt. Die Vorlage zeigte unter anderem
  dct:filleout, dct:snapet und dct:name — die ersten beiden existieren im Vokabular
  nicht, und der Herausgebername ist foaf:name, nicht dct:name. Die Grafik zeigt jetzt
  dcat:Catalog, dct:title, dct:publisher, foaf:name, dcat:dataset, dct:description
  und dcat:distribution — jeder Begriff gegen class-fields.php und class-rest-api.php
  geprüft. Eine Erklärgrafik mit erfundenen Fachbegriffen erklärt das Falsche.
• SVG statt Rasterbild. Text bleibt Text: scharf auf jedem Bildschirm, durchsuchbar, und
  mit <title>/<desc> auch für Screenreader beschrieben. Die Datei ist rund 7 KB groß und
  liegt im Repository statt an einer Attachment-URL — sie funktioniert damit auch im Fork.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.39.1

Wartungs-Release. Am Plugin selbst ändert sich nichts — keine Änderung an PHP, CSS oder
JavaScript, Carbon Fields unverändert bei v3.6.9. Wer 2.39.0 installiert hat, verpasst nichts.

📝 Dokumentation

• README-Kopf auf die Bildsprache des Logos umgestellt. Das bisherige Banner hing an einer
  GitHub-Attachment-URL — an den Upload gebunden, nicht an das Repository. Jetzt zeigt der Kopf
  auf assets/images/ODW-Logo.svg aus dem Repository und funktioniert damit auch in einem Fork
  oder lokalen Klon. Badges in den Markenfarben, Zauberer-Emoji entfallen.

🔧 Nur im Repository, nicht im Paket

• main war zwischenzeitlich rot. Zwei npm-Updates von Dependabot (#106, #107) wurden
  nacheinander gemergt; der zweite nahm beim Merge die package.json-Änderung des ersten zurück,
  behielt aber dessen Lock-Eintrag. npm ci verweigerte danach den Dienst und der SHACL-Job
  scheiterte. Behoben, beide Upgrades zusammen verifiziert.
• Ursache in der Dependabot-Konfiguration abgestellt. Die Gruppen deckten nur minor und
  patch ab; ein Major-Sprung fiel heraus und bekam einen eigenen Pull Request — daher zwei
  konkurrierende Änderungen an derselben Lock-Datei. Alle Gruppen umfassen jetzt sämtliche
  Update-Typen. Carbon Fields bleibt bewusst ungruppiert und bekommt weiterhin einen eigenen
  Pull Request.
• Entwicklungsabhängigkeiten aktualisiert (PHPUnit, PHPStan, WP_Mock, php-parser,
  @zazuko/env-node 3.x, rdf-validate-shacl 0.6.x) sowie GitHub Actions. Nichts davon wird
  ausgeliefert.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.39.0

Das Logo im Backend.

✨ Added

• Logo als Menü-Icon im Backend statt des generischen dashicons-database.
• Logo im Kopf der Einstiegs- und der Einstellungsseite, neben der jeweiligen Überschrift.
• assets/images/ enthält jetzt ODW-Logo.svg, ODW-Logo.png und die zugeschnittene
  Icon-Fassung ODW-Icon.svg.

ℹ️ Zwei Entscheidungen dahinter

• Eigene Icon-Fassung fürs Menü. Menü-Icons sind 20 × 20 Pixel; die Wortmarke „ODW" wäre dort
  ein unlesbarer Fleck. ODW-Icon.svg schneidet den viewBox auf das Zeichen zu und lässt die
  drei Wortmarken-Pfade weg — dieselbe Zeichnung, anderer Ausschnitt, keine Änderung an den
  übrigen Pfaden.
• Als URL eingebunden, nicht als base64-data:-URI. WordPress dimmt Menü-Icons auf 60 Prozent
  Deckkraft, bis man daraufzeigt; ein data:-SVG behält volle Deckkraft und stäche als einziges
  Symbol im Menü heraus. Nebeneffekt: rund 7 KB Base64 weniger auf jeder Admin-Seite.

Beides wurde vor dem Einbau in einem Browser gerendert und geprüft — bei 20 Pixeln auf dunklem
wie hellem Menügrund, und die Kopfzeilen bei 40 bzw. 48 Pixeln.

🎨 Styling

• .odw-page-title / .odw-page-logo richten Logo und Überschrift aneinander aus. Nur die Höhe
  ist festgelegt — das Logo ist mit 932 × 830 nicht quadratisch, eine feste Breite dazu würde es
  verzerren.

ℹ️ Nicht eingebunden

Die Download-Karte im Frontend bleibt ohne Logo: Sie steht auf fremden Websites, dort wäre unser
Zeichen Absender statt Beiwerk. Und das README behält seinen bestehenden Kopf — zwei
unterschiedliche Logos übereinander wären Rauschen.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.38.0

Gutenberg-Block „Datensatz-Karte" — keine IDs mehr abtippen.

✨ Added

• Block „Datensatz-Karte" als Alternative zum Shortcode [odw_dataset id="123"]. Im Editor
  über das Plus-Symbol einfügen und den Datensatz aus einer Liste wählen; zur Auswahl stehen nur
  veröffentlichte Datensätze. Wer den Shortcode bevorzugt oder klassische Editoren nutzt, kann
  ihn unverändert weiterverwenden.

ℹ️ Umsetzung

• Dynamischer Block: Gespeichert wird ausschließlich die Datensatz-ID, das Markup entsteht
  beim Ausliefern über ODW_Shortcode::render(). Damit gibt es genau eine Quelle für die Karte —
  Änderungen daran wirken auf Block und Shortcode gleichermaßen —, und ein später umbenannter
  Datensatz erscheint mit seinem aktuellen Titel statt als eingefrorene Kopie im Beitrag.
• Kein Build-Schritt. blocks/dataset-card/ enthält block.json und ein Editor-Skript in
  schlichtem JavaScript statt JSX. Das Projekt hat keine JS-Build-Kette für den Admin-Bereich,
  und eine allein für diesen Block einzuführen wäre viel Apparat für wenig Ertrag.
• Auswahlliste über wp_localize_script, nicht über den Core-Datenspeicher: Der Custom Post
  Type ist bewusst nicht über die WP-REST-API exponiert (show_in_rest => false), dafür gibt es
  die eigenen Endpunkte. Die Liste wird nur im Editor aufgebaut (enqueue_block_editor_assets)
  und ist auf 200 Einträge begrenzt.
• Platzhalter statt Live-Vorschau im Editor. Eine serverseitig gerenderte Vorschau bekäme das
  Frontend-Stylesheet im Editor-Rahmen nicht mit und sähe dort kaputt aus; die Platzhalterkarte
  nutzt WordPress' eigene Placeholder-Komponente und braucht deshalb kein eigenes CSS.
• bin/build-release.sh kopiert blocks/ mit ins Paket — ohne diese Ergänzung wäre der Block in
  der Installation schlicht nicht vorhanden gewesen.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.37.0

Alle 24 EU-Amtssprachen statt zwei.

✨ Added

• Sprachauswahl als gebündeltes Vokabular (config/vocabularies/language.json). Bisher standen
  fest im Code nur Deutsch und Englisch zur Wahl — und zwar nicht nur beim Sprachfeld des
  Datensatzes, sondern auch in allen drei Übersetzungs-Repeatern und bei der Standardsprache in
  den Einstellungen. Mehrsprachige Metadaten waren damit praktisch auf Englisch beschränkt,
  obwohl das Plugin sie als Funktion führt.

ℹ️ Hintergrund

Die Begrenzung lag ausschließlich in der Auswahlliste: odw_resolve_language_tag() setzte alle
24 EU-Sprachcodes schon vorher korrekt nach BCP-47 um (DEU → de, POL → pl …). Die
JSON-LD-Ausgabe war also längst vorbereitet, das Formular bot die Sprachen nur nicht an.

Deutsch und Englisch stehen weiterhin an erster Stelle, die übrigen 22 alphabetisch darunter.
Bleibt die Vokabulardatei einmal aus, fällt die Auswahl auf Deutsch und Englisch zurück — ohne
mindestens eine Sprache ließe sich weder eine Übersetzung pflegen noch eine Standardsprache
wählen.

Wie bei den anderen gebündelten Vokabularen stehen die Bezeichnungen in der JSON-Datei und
durchlaufen damit nicht die Übersetzungsdateien. Das ISO-Kürzel im Label („Polnisch (PL)")
macht den Eintrag trotzdem eindeutig.

📝 Dokumentation

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

Installation: WordPress → Plugins → Installieren → Plugin hochladen.

Open Data Wizard 2.36.0

Überarbeitetes Formular-Design — Typografie, Abstände, Eingabefelder.

🔧 Changed

• Abstände kommen jetzt vom Raster, nicht mehr von Rändern je Feld. Das Tab-Panel ist ein
  CSS-Grid mit gap; Margins an einzelnen Feldern kollabierten oder verdoppelten sich, je
  nachdem was daneben stand. Das Ergebnis ist ein gleichmäßiger vertikaler Rhythmus.
• Zwei Spalten für zusammengehörige Felder. Format und Dateigröße, Beginn und Ende des
  Zeitraums, Name und E-Mail bei Urheber, pflegender Stelle und Ersteller sowie die beiden
  Kontaktfelder stehen nebeneinander statt jeweils über die volle Breite. Unterhalb von 782 px —
  der Bruchstelle des WordPress-Backends — wird wieder einspaltig umbrochen.
• Eingabefelder einheitlich und größer. 40 statt rund 30 Pixel Höhe, weichere Rundung,
  sichtbarer Fokus-Ring. Text-, Auswahl-, Zahlen- und Datumsfelder erbten bislang
  unterschiedliche Standardhöhen von WordPress und sahen entsprechend uneinheitlich aus.
• Reiter mit Unterstrich statt gerahmter Karteikarten-Optik.
• Wiederholbare Distributionen als Karten mit eigener Kontur und ruhigem Kopfbereich.
• Datei-Upload als getönter Block direkt unter der Zugriffs-URL — sichtbar die Alternative
  zu dem Feld darüber, nicht ein weiteres Pflichtfeld daneben.
• Hilfetexte nicht mehr kursiv und mit größerem Zeilenabstand. Betrifft die Anzeige ohne
  JavaScript; mit JavaScript wandert der Text weiterhin in den ⓘ-Tooltip.

ℹ️ Wartungshinweis

Alle Regeln, die an Klassennamen von Carbon Fields hängen, stehen gesammelt im Block
FORMULAR-DESIGN am Ende von assets/css/admin.css. Das ist nach einem Carbon-Fields-Update
die einzige Stelle, die zu prüfen ist. Die Abhängigkeit ist damit von acht auf rund zwanzig
CF-Klassen gestiegen — der Preis für die Gestaltung, dafür an einem Ort statt verstreut.

Die Zweispaltigkeit wählt Felder über ihr name-Attribut aus, nicht über ein data-Attribut:
Carbon Fields reicht data-Attribute bei <select> nicht zuverlässig ans DOM durch, der
Meta-Key steht dagegen immer im Namen. Dadurch war keine Änderung an PHP nötig — der
Umbau ist reines CSS.

🎨 Added

• Token für Abstände, Radien, Feldhöhe und Schriftgrößen in :root. Werte stehen damit an einer
  Stelle statt über 1.400 Zeilen verteilt.

Installation: WordPress → Plugins → Installieren → Plugin hochladen.