feat(i18n): extract shell navigation strings (batch 1)#1152
feat(i18n): extract shell navigation strings (batch 1)#1152JamieRuderman wants to merge 2 commits into
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b9dc277d6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| title: t('common.areYouSure', 'Are you sure?'), | ||
| children: t( | ||
| 'nav.testUIConfirm', | ||
| 'Enabling alpha features may be unstable. It is only intended for testing and development.' |
There was a problem hiding this comment.
In any Japanese, German, or Spanish locale, opening this confirmation dialog—or the newly translated lock and quit dialogs—shows a translated title and body alongside English Cancel and Ok buttons. ListItemSetting always supplies onDeny, while frontend/src/components/Confirm.tsx:28,48-54 hard-codes those two labels, so the confirmation controls also need to use the active translations.
Useful? React with 👍 / 👎.
| connections: counts.connections.toLocaleString(), | ||
| active: counts.active.toLocaleString(), |
There was a problem hiding this comment.
When the user overrides the app language to German or Spanish while the OS/browser remains English, counts of at least 1,000 are interpolated as strings such as 1,000 Verbindungen rather than using the selected language's number formatting. Calling toLocaleString() without an explicit locale uses the runtime default; these newly localized tooltip values should use the active app locale (available through the repository's getLocale() helper) or an i18next number formatter.
Useful? React with 👍 / 👎.
1 participant
Summary
First string-extraction batch (Phase 4): the shell navigation chrome — the sidebar nav, the avatar/account menu, and the mobile bottom nav. These labels appear on every screen, so they're the highest-visibility surface to internationalize first and the best proof of the pattern at scale.
Targets
feature/i18n, notmain— this stacks on the i18n foundation and is meant to be reviewed on its own.Changes
SidebarNav.tsx,AvatarMenu.tsx,BottomMenu.tsx— all hardcoded labels, tooltips, and confirmation-dialog copy routed throught()under a newnav.*key group (31 keys). Shared labels (Connections/Devices/Networks) reuse the same keys across sidebar and bottom nav; the "Are you sure?" confirm titles reuse the existingcommon.areYouSure.{{connections}} Connections - {{active}} Connected), and the old(testUI ? '' : 'Enable ') + 'Test UI'string-building was split into two full-sentence keys (nav.testUI/nav.enableTestUI).nav.*seeded in ja/de/es (machine-translated via Sonnet, flagged for professional review before production). Placeholder parity verified:{{connections}}/{{active}}preserved in all three locales.Tooling fix (separate commit)
Found and fixed a bug in
i18next-parser.config.js: the installed parser passes the inlinet()default as a plain string in the callback's 4th arg, but the config read it as an object (value?.usageContext?.defaultValue), so English values always came out empty. Now English catalogs populate correctly from the inline defaults. (The earlieroptions.*values had survived only because the parser preserves pre-existing non-empty values.)Verification
i18n:checkpasses — 4 locales × 3 namespaces, no missing keys, no empty English.tsc --noEmitclean; production build passes.Untranslated strings elsewhere still fall back to English, so nothing regresses.
🤖 Generated with Claude Code