[codex] add react-i18next app localization - #5
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This change adds app-wide localization using
react-i18next, with English and Ukrainian locale catalogs stored as JSON resources and loaded through a shared i18n bootstrap. The app now detects the initial locale fromlocalStoragefirst and the browser language second, persists the resolved language choice, and exposes a shared language picker so the interface can be switched without reloading.From a user perspective, the homepage, import flow, progress states, viewer controls, sidebar copy, and axis labels now all update when the language changes. The homepage and viewer sidebar also gained a compact, shared language selector so the chosen locale is visible and adjustable in both entry points.
Problem
Before this change, all interface copy was hard-coded in English across the import screen, loading flow, and viewer UI. That made the app harder to use for non-English speakers and forced text updates to be done directly in components and worker progress code.
The app also had no concept of a persisted locale, so even a minimal language toggle would have required threading state manually through the app and reconstructing many strings in place.
Root Cause
The codebase had no centralized translation layer, no locale resource files, and no app-wide mechanism for resolving or persisting the current language. Strings were embedded directly in components, progress helpers, and import/worker flow code, which made localization a cross-cutting change rather than a contained configuration problem.
Fix
The fix introduces an i18n bootstrap under
src/i18n/backed byi18nextandreact-i18next, plus locale catalogs insrc/i18n/locales/en.jsonandsrc/i18n/locales/uk.json. The app root now initializes i18n once, resolves the starting locale from persisted storage or browser language, and writes language changes back tolocalStorage.The UI was updated to consume translated strings throughout the import page, folder picker, import status component, viewer page, 3D viewport controls, axis viewport labels, and sidebar panels. Import progress now uses translation keys and interpolation values instead of raw English text, and the homepage disclaimer/support copy was moved into locale resources.
A shared
LanguageSelectcomponent was added and integrated into the homepage and viewer sidebar. The control uses the compact layout by default, shows native language names, and keeps the viewer sidebar layout scrollable while leaving the navigation buttons pinned at the bottom.Validation
I verified the change with:
npm run format:checknpm run lintnpm run buildThe build still reports the existing Vite chunk-size warning for the Three.js bundle, but no new validation failures were introduced.