italia / italia/publiccode-editor

Add new localisations

Open
#647 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
TypeScript
Stars
32
Forks
33
Avg merge
3d 15h
Merged PRs (30d)
16

Description

## 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:

- **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 — #429 and #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.
- `formatLanguageLabel()` uppercases the `Intl.DisplayNames` output, which interacts
with #538 and deserves a look once a non-Latin script is in the list.

## Non-functional constraints

- **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
- [ ] All five sub-issues closed

## Related

- #429 — missing French translations; the completeness check here would have caught it
- #270 — Italian localisation quality review
- #538 — language picker labels, same surface touched here

Contributor guide

Open the contributing guide

Research direction

Read src/i18n/index.ts and compare src/i18n/locales/en.json with the existing locale files; inspect .github/workflows/test.yml and the related issues #429, #270, and #538. Trace how supportedLngs and formatLanguageLabel() are affected. Done means locale registration, completeness validation in CI, translation contribution guidance, and existing-locale coverage meet the acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
ci-cd, documentation, localization
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.