Background
The i18n setup (i18next + HttpBackend + LanguageDetector, namespaces common/settings/chores) is in place, but only a handful of components actually call t() — most of the UI renders hardcoded English. As a result, selecting a language today localizes only a small part of the app: login, the chore list, the chore editor, and most settings still render in English regardless of the chosen language.
I've been adding a Russian locale (#143) and, in the process, mapped the gap: the large majority of user-facing strings live outside i18next. I'd like to help close that gap and contribute it back incrementally.
Goal
Make the whole user-facing UI translatable through the existing i18next setup, so a locale actually localizes the app — without any framework change or architectural churn.
Approach (feedback very welcome before I go wide)
- Feature-scoped namespaces: keep
common/chores/settings, add auth, history, things, points, filters, notifications as needed. Generic strings stay in common and are reused.
- English stays the source: each string moves into
en/<ns>.json; the component keeps only t('ns:key'). Language-agnostic — other locales then just copy-and-translate.
- Pluralization done right: replace hardcoded English plural logic (
${n === 1 ? 'task' : 'tasks'}) with i18next count forms via Intl.PluralRules (this also addresses the hardcoded-plural issue I'm filing separately).
- Small, reviewable PRs: one namespace / cohesive feature area per PR, referencing this issue, in priority order (daily screens first). No mega-diffs.
Status
Work has started on my fork. I'll open PRs feature-by-feature and reference this issue so coverage lands in reviewable pieces. I'll aim to take this as far as I can toward the app being genuinely multilingual.
Does this approach (feature-scoped namespaces, English-as-source, incremental PRs) work for you? Any preferences on namespace naming or ordering before I start submitting?
Background
The i18n setup (i18next + HttpBackend + LanguageDetector, namespaces
common/settings/chores) is in place, but only a handful of components actually callt()— most of the UI renders hardcoded English. As a result, selecting a language today localizes only a small part of the app: login, the chore list, the chore editor, and most settings still render in English regardless of the chosen language.I've been adding a Russian locale (#143) and, in the process, mapped the gap: the large majority of user-facing strings live outside i18next. I'd like to help close that gap and contribute it back incrementally.
Goal
Make the whole user-facing UI translatable through the existing i18next setup, so a locale actually localizes the app — without any framework change or architectural churn.
Approach (feedback very welcome before I go wide)
common/chores/settings, addauth,history,things,points,filters,notificationsas needed. Generic strings stay incommonand are reused.en/<ns>.json; the component keeps onlyt('ns:key'). Language-agnostic — other locales then just copy-and-translate.${n === 1 ? 'task' : 'tasks'}) with i18nextcountforms viaIntl.PluralRules(this also addresses the hardcoded-plural issue I'm filing separately).Status
Work has started on my fork. I'll open PRs feature-by-feature and reference this issue so coverage lands in reviewable pieces. I'll aim to take this as far as I can toward the app being genuinely multilingual.
Does this approach (feature-scoped namespaces, English-as-source, incremental PRs) work for you? Any preferences on namespace naming or ordering before I start submitting?