docs(openspec): schema-metadata-i18n — translatable schema titles/descriptions#2085
Merged
Merged
Conversation
…criptions OpenRegister's i18n stack covers object CONTENT (translatable property values, Accept-Language negotiation, source-language tracking). It does not cover schema METADATA: Schema::$title is ?string and oc_openregister_schemas.title is varchar(255) NOT NULL, and register-i18n explicitly scopes itself as 'distinct from the app UI string translations ... for interface labels'. Those property titles are what consuming apps render as index column headers and form labels, so whatever language the schema was authored in is what every user sees. Live evidence (2026-07-24, admin lang=en, NC chrome in English): DocuDesk's tables render NAAM / CATEGORIE / PAGINAFORMAAT and DOCUMENTNAAM / MODUS / NIVEAU, because docudesk_register.json authors the titles in Dutch (ConductionNL/docudesk#341). A leaf app cannot fix this alone — authoring in English just strands Dutch users, while ADR-005 mandates NL+EN and SDG 2018/1724 requires English for cross-border services. Specs a per-language map for schema/property title+description, resolution via the EXISTING Accept-Language negotiation with a deterministic fallback chain, the NOT NULL scalar-column invariant, an unresolved `_metaLanguages=all` read for editors/round-trip, and BCP 47 + register-languages validation. Plain strings keep working, so no existing schema needs migration. 5 requirements, 11 scenarios; openspec validate --strict clean.
Contributor
Quality Report — ConductionNL/openregister @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| composer | ❌ | ✅ 174/174 | |||
| npm | ✅ | ✅ 555/555 | |||
| PHPUnit | ⏭️ | ||||
| Newman | ⏭️ | ||||
| Playwright | ⏭️ |
Quality workflow — 2026-07-24 18:12 UTC
Download the full PDF report from the workflow artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gap
OpenRegister's i18n stack covers object content (translatable property values,
Accept-Languagenegotiation, source-language tracking). It does not cover schema metadata:lib/Db/Schema.php:144→protected ?string $title = null;oc_openregister_schemas.title→varchar(255) NOT NULLregister-i18n/spec.mdscopes itself as "distinct from the app UI string translations … for interface labels"Property titles are exactly what consuming apps render as index column headers and form labels, so whatever language the schema was authored in is what every user sees.
Live evidence
Admin account
lang=en, Nextcloud chrome correctly in English, DocuDesk on the shared dev instance (2026-07-24):…because
docudesk_register.jsonauthors those titles in Dutch (ConductionNL/docudesk#341). A leaf app can't fix it alone — authoring in English just strands Dutch users, while ADR-005 mandates NL+EN and SDG 2018/1724 (already the driver forregister-i18n) requires English for cross-border services.What this specs
Per-language maps for schema/property
title+description; resolution through the existing Accept-Language negotiation with a deterministic fallback chain (requested → base → register default → first non-empty); theNOT NULLscalar-column invariant so listing/sorting/indexing keep working; an unresolved_metaLanguages=allread so editors and import/export round-trip every language; and BCP 47 + register-languagesvalidation.Backwards compatible by construction — plain strings keep working and resolve to themselves, so no existing schema needs migration and no consumer app is forced to change.
5 requirements, 11 scenarios.
openspec validate --strictclean. Markdown-only.🤖 Generated with Claude Code