You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Widen the editor's UI localisation so that every country contributing to the European
software catalogue can use it in its own language. Five locales are missing — Spanish,
Portuguese, Swedish, Finnish and Greek — and each is tracked as a sub-issue of this one,
so they can be picked up independently by different translators.
This issue covers the work that is not per-language:
Make locale registration less manual. Each locale is currently wired in by hand,
with both a JSON import and an entry in the resources map in src/i18n/index.ts.
Doubling the number of locales is the moment to fix that, so adding a further language
is a matter of dropping in a file.
Catch incomplete translations automatically. Locales drift out of sync with en.json and nothing detects it — missing translations in French 🇫🇷 #429 and Check the Italian localization #270 both exist for that reason. A missing
key should fail CI, not reach production as an untranslated string.
State how translations are maintained. Ten locales cannot be kept current by
ad-hoc effort; the project needs a documented path for contributing and reviewing a
translation.
Bring the existing locales up to the same bar (de, fr, it, nl), or file
their gaps separately.
The requirement is about UI string coverage, not about the language metadata the form
offers for publiccode.yml itself, which already comes from locale-codes.
Affected areas
src/i18n/index.ts — imports and the resources map; supportedLngs is derived from
it, so the language picker and getSupportedLanguages() follow automatically.
src/i18n/locales/ — currently de, en, fr, it, nl; en.json (~23 KB) is the
reference for the key structure.
.github/workflows/test.yml — where the completeness check should run.
RNF-PCE-006 — Long-term sustainability: this is the whole point of the
infrastructure work above. Without a completeness check and a contribution policy,
ten locales become ten sources of drift.
Acceptance criteria
Adding a locale no longer requires editing the resources map by hand
An automated check fails when a locale is missing keys present in en.json, and
runs in CI
The way to contribute and review a translation is documented
Existing locales (de, fr, it, nl) pass the completeness check, or their
gaps are filed separately
Context
Derived from requirement RF-PCE-002
Scope
Widen the editor's UI localisation so that every country contributing to the European
software catalogue can use it in its own language. Five locales are missing — Spanish,
Portuguese, Swedish, Finnish and Greek — and each is tracked as a sub-issue of this one,
so they can be picked up independently by different translators.
This issue covers the work that is not per-language:
with both a JSON import and an entry in the
resourcesmap insrc/i18n/index.ts.Doubling the number of locales is the moment to fix that, so adding a further language
is a matter of dropping in a file.
en.jsonand nothing detects it — missing translations in French 🇫🇷 #429 and Check the Italian localization #270 both exist for that reason. A missingkey should fail CI, not reach production as an untranslated string.
ad-hoc effort; the project needs a documented path for contributing and reviewing a
translation.
de,fr,it,nl), or filetheir gaps separately.
The requirement is about UI string coverage, not about the language metadata the form
offers for
publiccode.ymlitself, which already comes fromlocale-codes.Affected areas
src/i18n/index.ts— imports and theresourcesmap;supportedLngsis derived fromit, so the language picker and
getSupportedLanguages()follow automatically.src/i18n/locales/— currentlyde,en,fr,it,nl;en.json(~23 KB) is thereference for the key structure.
.github/workflows/test.yml— where the completeness check should run.formatLanguageLabel()uppercases theIntl.DisplayNamesoutput, which interactswith Use the target language in the language picker #538 and deserves a look once a non-Latin script is in the list.
Non-functional constraints
infrastructure work above. Without a completeness check and a contribution policy,
ten locales become ten sources of drift.
Acceptance criteria
resourcesmap by handen.json, andruns in CI
de,fr,it,nl) pass the completeness check, or theirgaps are filed separately
Related