Completing i18n coverage across the app

[everysingletear]

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?

---

Status update — 3 Aug 2026 (audited against develop @ 412faf4)

A lot landed on develop these last two weeks — the modal/button unification, unified empty states, the project-management rework (#186), the onboarding reshape (#185). My fork branched before all of it, so rather than send PRs and discover the collisions during review, I re-audited every file first. Everything below is derived from that audit, and the ordering it implies is the ordering I'd like to follow.

129 components on my fork call t() today. Measured against current develop:

• 51 are untouched by develop and by every open branch — these can land as-is and will not need a rebase.
• 2 are clean on develop but sit in an open branch (ActivitesCard.jsx, SubTask.jsx) — leaving them alone.
• 75 need re-extraction on top of your refactors before they're worth reviewing.

Coverage map

Zone	t() on fork	Ready now	Blocked by
Settings (incl. Payments, SSE/RealTime)	20	16	in-app feedback (#176)
Shared components (views/components)	27	13	modal/button unification, #186
Chores list & filters	22	9	#186, empty states (#184)
Standalone views (Home, Error, Overview, SummaryCard)	4	4	—
ChoreEdit	5	2	#186, attachment refactor
Hooks & misc components	8	6	attachment refactor, modal unification
History / Points / Projects / Circles	5	3	#184, #186
Modals	22	0	modal/button unification (21 of 22)
Authorization	6	0	login/signup revamp + #185
Things / Labels / Filters / Timer	5	0	empty states (#184)

Proposed order

Each PR below contains only files develop hasn't touched, so none of them should ever need a rebase. The first three extend namespaces that already exist, which means no src/i18n/config.js change and therefore no conflicts between my own PRs either.

1. i18n: extract the task-form picker fields (Part of #145) #155, narrowed — 5 files. Already open; I'll cut it down to the task-form fields develop hasn't touched so it stops being a red PR (details at the bottom).
2. settings — 16 files. Extends the existing namespace. Lowest-risk of the new ones.
3. common — 14 files. Shared inputs, calendar, nav, loading, error states.
4. chores — 13 files. List controls, filter builder, repeat/trigger sections. The four picker fields that would otherwise appear here are in i18n: extract the task-form picker fields (Part of #145) #155 instead, so the two never touch the same file.
5. New namespaces — history, points, projects (1 file each). These do touch config.js, one line apiece.

Then, as your refactors settle, the blocked zones in the same shape — largest first (Modals, then Chores, then Authorization).

Namespace and key conventions

This is the part I'd most like you to push back on, because it's cheap to change now and expensive after twenty PRs. What I've been doing:

• Namespaces are feature-scoped and lowercase, extending yours: common, settings, chores, plus auth, history, points, projects, things, filters, labels, timer as each zone lands. Anything reused across zones goes to common rather than being duplicated.
• Keys are camelCase, nested one level by section, e.g. settings:circleSettings.copyCode. Generic actions stay flat in common (common:save, common:cancel).
• Interpolation uses named variables — {{name}}, {{count}} — never positional or concatenated fragments.
• Plurals use i18next suffixes on the English source (reminder_one / reminder_other) with t(key, { count }), replacing the hardcoded n === 1 ? 'task' : 'tasks' pattern. Other locales then add whatever forms their language needs without touching the component.
• English is the only value shipped in these PRs. No translations ride along, so every PR is a pure refactor.
• <Trans> is avoided. Where a sentence contains a link, the string is split into separate keys rather than embedding markup in the dictionary.

If you'd rather have flat keys, different namespace boundaries, or everything in common, say so and I'll rework the fork to match before sending more.

Out of scope

• MFAVerificationModal — entangled with the MFA flow logic; deserves its own pass rather than being folded into a mechanical extraction.
• The Go backend (donetick/donetick) — server-side strings are a separate problem and I'm not touching them.
• Anything you'd rather keep hardcoded — tell me and I'll skip it.

Claiming a zone

To avoid a repeat of the collision on the auth screens: if you or anyone else is about to work in one of the zones above, drop a comment here and I'll mark it taken and route around it. I'll do the same before I start each PR.

Open PRs affected by this audit

• i18n: extract authorization screen strings (Part of #145) #168 (auth) — extracted against the pre-revamp login screens, so it no longer applies; the zone was rewritten twice and Reshape onboarding v1.3 #185 is still in flight. I'd rather not re-extract into a moving target, so I'm marking it blocked instead of force-pushing something that may need doing a third time. Happy to close it if you prefer a clean slate.
• i18n: extract the task-form picker fields (Part of #145) #155 (task creation) — I audited this one too. Six of its twelve files were rewritten under you: DueDatePickerField lost 522 lines to Enhance project management UI and handle bulk changes #186, AddTaskModal gained 233, and RepeatPickerField / NotificationPickerField went through the modal unification. That's about 70% of the diff, which is why GitHub has been showing it as conflicting. The other six files — the task-form pickers — are untouched. I'd rather not leave a red PR sitting in your queue, so unless you object I'll force-push it down to just those (minus SubTask.jsx, which is clean on develop but sits in an open branch) and retitle it accordingly. The rewritten half goes back in the queue behind the modal work.

[everysingletear]

Status update — 12 Aug 2026 (re-audited against develop @ 7eba12e)

Another 79 commits landed since the 3 Aug audit, so the picture moved again. Re-running the same audit before sending anything, as promised.

auth is unblocked and sent

#168 is closed; the replacement is #208, extracted fresh against current develop. The zone has been stable since #185 merged, and the drift since my base was small enough that redoing the extraction was an afternoon rather than a rewrite.

It also covers Authenticating.jsx and MFAVerificationModal, both of which I'd previously listed as out of scope. The MFA modal turned out not to be entangled after all — the diff there is string replacement only — so I'd like to strike it from the "out of scope" list above unless you'd rather it stayed separate.

settings is yours — dropping it from my list

I see 8c9bf0d localized the settings views. That was next in my queue (16 files), so I've removed it. For what it's worth, my fork had extracted the same zone with different key names — where a key exists on both sides I'm adopting yours, since your code is the one shipping.

That's now twice that work has been lost to a collision: the auth screens to the revamp, settings to this. That's on my ordering, not on you — which is why I'm changing how I sequence it, below.

Claiming zones before starting, not after

From here I'll comment in this issue naming the zone before I begin extracting it, and wait a beat in case it's already in flight on your side. If you're planning to localize a zone yourself, say so and I'll route around it — I'd rather spend the effort where it lands.

Zones I'd like to take next, in this order, unless you say otherwise:

1. common — the shared strings namespace, extending what's already there
2. chores — the task list and card, minus anything sitting in an open branch
3. history / points / projects — one small namespace each

#155 (task creation)

Still red, and the sync moved its files again. Rather than guess, I'll re-check each of its twelve files against current develop and force-push it down to the ones that still apply, with the exact list in the PR description. The rewritten half goes back in the queue behind your modal work.

One thing worth knowing regardless of i18n

While reconciling the merge I found a latent bug on my side that's worth mentioning because the same shape can happen to anyone extracting strings: a file can end up with import { useTranslation } present but the hook call gone, so every t() in it throws at runtime. A check that only greps for the import will not catch it. Mine didn't, and a file upload error path was throwing ReferenceError instead of showing its notification. Not present in anything I've sent you — flagging the failure mode, not a bug in develop.

[everysingletear]

Coverage map — everything I have that applies to current develop

Following on from the update above: rather than trickle these out over weeks and risk another zone being done twice, here is the whole of my fork's extraction work that still applies to develop @ 7eba12e, split into independent PRs. Six PRs, all green, all MERGEABLE, no dependencies between them — merge in any order, at whatever pace suits you, or tell me to close any of them.

The point of sending them together is visibility, not pressure: you can see what is already done and skip those zones rather than extracting them a second time.

PR	Zone	Files	Keys	Touches config.js?
#208	Authorization	8	103 (auth, new)	yes
#209	shared strings	14	+28 common	no
#210	chore list, archive and modals	23	+185 chores, +15 common	no
#211	settings screens 8c9bf0d didn't reach	8	+59 settings	no
#212	things, history, projects, labels, filters, timer, points	14	180 across 7 new ns	yes
#155	task-form picker fields (narrowed)	7	+16 chores, +1 common	no

Only #208 and #212 touch the ns: array, and they add disjoint entries, so even those two do not conflict with each other.

How "no behaviour change" is established

For each PR, every t() value is checked mechanically against the base: the English string must appear character-for-character in the code it replaces. That is 727 call sites across the six PRs. It is not a claim about care taken — it is a check that fails loudly if a string was reworded in passing, and it caught real mistakes in my own work while I was preparing these.

Six values are matched loosely, and each PR body names its own. They are all the same shape: the base builds a sentence around a ternary — {showDetails ? 'Hide' : 'Show'} error details — so no full phrase exists contiguously in the source, only one branch of it. Each key holds exactly what one branch renders. I kept those sentences whole rather than splitting them around the ternary, because a sentence assembled from fragments can't be reordered by a translator. If you'd rather I split them, say so.

Your Playwright suite is the second, independent check, since it selects by visible English text.

One finding worth passing on

Reusing a key in two places is the trap in this kind of work. Two examples I had to undo in my own branch:

• typeHere was used by both TextModal and AutocompleteInput. Your source has 'Type in here…' in one and 'Type here...' in the other — deliberately different. One shared key silently rewrote one of them.
• badge.onTime was used by both HistoryDetailModal ('On Time') and UserActivities ('On time'). Same thing.

Neither is visible in review: the diff looks like a clean literal→t() swap on both sides. Only comparing each value back against the original catches it. Worth knowing if you extract further zones yourself, and worth knowing for Crowdin, since a merged key also merges the two translations forever.

Separately, extraction can quietly eat markup. BackupRestoreModal renders <strong>Warning:</strong> Restoring a backup will…; pulling the whole sentence into one key drops the bold. In #211 the label and the sentence are separate keys and the <strong> stays in the JSX.

What I am deliberately NOT sending, and why

My fork localizes 130 files. 74 are in the PRs above. The rest are held back on purpose:

• 21 files — you localized them yourself, or they don't exist upstream. Nothing for me to send.
• 26 files — my branch carries non-i18n changes in them (CalendarCard, CalendarMonthly, SSESettings, RepeatPickerField, RepeatSection…). Those are my own edits and don't belong in an extraction PR. They need separating first.
• 6 files — the English genuinely differs and I haven't reconciled it yet: ChoreEdit, MyChoreHeader, Settings.jsx, ThingsView, AddTaskModal, NativeCancelSubscriptionModal. Sending them would reword the UI.

I'd rather name these than quietly include them. Both zones I've lost so far went that way because coverage was assumed rather than checked, and a stale string slipping through in an "extraction" PR is exactly the kind of thing that is invisible in review.

Two small things in develop that the extraction surfaced

Neither file is in any of these PRs, so nothing here touches them. Noticed while reading the source, and both would be a one-line dictionary change once their zones are extracted:

• Settings.jsx renders You part of {name} and You circle code is:.
• NativeCancelSubscriptionModal has section on our website. using a web browser.

Zones still genuinely uncovered

If you're deciding where to spend your own i18n time, these are the places where nothing of mine applies and I'm not working: the onboarding vignettes, the global search palette you just added, ErrorReportModal, JoinCircle, and the voice capture panel. I'm happy to take any of them — just say which, and I'll claim it here first as agreed.