Add Language

Adding a language to Econumo

Both stacks share the same translation catalogues: locales/{en,ru,...}.json is embedded into the Go binary (locales/embed.go, //go:embed *.json) and imported by the SPA via Vite JSON imports. Adding a language is therefore one new catalogue file plus a handful of small wiring edits — everything else (the Accept-Language middleware, the update-language endpoint's validation, the i18ntest guard's language list) derives from i18n.Supported automatically.

Work through the steps in order; step 5 is the safety net that catches any slip in steps 1–4.

1. Author locales/<lang>.json

<lang> is the lowercase two-letter ISO 639-1 tag (de, es, pl).

Copy the exact key tree of en.json and translate only the values. The guard tests enforce key parity and {placeholder} parity per key, so:

• Keep every {name} placeholder verbatim — translate around it, never rename it.
• Add no keys, drop no keys, restructure nothing.

Translate all namespaces, including errors.* (the localized error catalogue the SPA renders from error codes) and emails.* (backend-rendered mail). The frozen English strings in the API envelope live in Go code and are a separate, untouchable contract — they are not part of this task.

Plurals are authored as a single pipe-joined value (i18next plural suffixes are NOT used). web/src/lib/plural.ts splits on " | " and picks:

• 2 variants ("{count} item | {count} items"): first when count === 1, last otherwise. Use for languages that only distinguish one/other (German, Spanish, French, ...).
• 3+ variants: Intl.PluralRules category — variant 0 for one, variant 1 for few, the last for everything else. Use 3 variants for languages with a few category (Russian, Polish, ...), ordered one | few | many.
• Languages with richer plural systems than one/few/other (e.g. Arabic) must collapse into these three slots — pick the most natural collapse and say so in the PR description.

Find every plural key by grepping en.json for " | " and make sure your translation has the right variant count for the target language — placeholder parity won't catch a missing variant.

Quality — translate from BOTH en.json and ru.json, not en alone. English UI strings are short and often ambiguous out of context: "Clear" could mean erase or transparent, "Transfer" could be a noun or a verb, "Balance" has several senses in a finance app. The Russian translation was written by someone who knew the intended meaning, so reading the two side by side pins down what each key actually says — when your translation of a key wouldn't agree with both sources, you've probably misread the English. ru.json also answers questions en.json can't:

• Register: Russian addresses the user formally («Вы уверены…», «Ваше имя»), so the app's established voice is formal — pick whatever register is conventional for software UI in the target language, but let ru's formality inform the call for languages where it's a real choice (German Sie, not du).
• What stays untranslated: the "Econumo" brand, currency codes, icon names, format strings — visible in what ru left alone.

Pick one term per app concept (budget, envelope, payee, tag, ...) and use it consistently across all namespaces; inconsistency across the ~1200 lines is the most common quality failure.