Summary
I'd like to propose adding an internationalization (i18n) infrastructure to the frontend so the UI can be translated into multiple languages by the community.
Motivation
imgcompress is used globally, but all UI strings are currently hard-coded in English. An i18n layer would allow community members to contribute translations without touching component logic.
Proposed approach
- Library:
react-i18next + i18next (fully client-side, compatible with output: 'export' static builds — no middleware needed)
- New dependencies:
i18next, react-i18next (~50 kB gzipped combined)
- Structure:
frontend/src/i18n/
index.ts ← initialisation, reads saved locale from localStorage
types.ts ← TypeScript compile-time guard (all keys must be present)
locales/
en.ts ← English strings (source of truth, as const)
hu.ts ← Hungarian translation (example of community contribution)
frontend/src/context/I18nProvider.tsx ← keeps <html lang> in sync
frontend/src/components/LanguageSwitcher.tsx ← dropdown (Radix UI Select)
- Adding a new language: one new
locales/<code>.ts file + one entry in the LANGUAGES array — no changes to component logic
- Persistence: selected language stored in
localStorage
What I have ready
I have a working implementation of the above on my fork. It covers all ~280 UI strings across every component (forms, toasts, dialogs, footer, splash screen, etc.) with full TypeScript structural type-checking. I can open a PR if this direction sounds good to you.
Questions before opening a PR
- Is i18n something you'd want in the project?
- Should the initial PR include only English (infrastructure only), or is it fine to bundle the Hungarian translation as a first example?
- Are there any architectural constraints I should be aware of?
Happy to adjust the approach based on your feedback.
Summary
I'd like to propose adding an internationalization (i18n) infrastructure to the frontend so the UI can be translated into multiple languages by the community.
Motivation
imgcompress is used globally, but all UI strings are currently hard-coded in English. An i18n layer would allow community members to contribute translations without touching component logic.
Proposed approach
react-i18next+i18next(fully client-side, compatible withoutput: 'export'static builds — no middleware needed)i18next,react-i18next(~50 kB gzipped combined)locales/<code>.tsfile + one entry in theLANGUAGESarray — no changes to component logiclocalStorageWhat I have ready
I have a working implementation of the above on my fork. It covers all ~280 UI strings across every component (forms, toasts, dialogs, footer, splash screen, etc.) with full TypeScript structural type-checking. I can open a PR if this direction sounds good to you.
Questions before opening a PR
Happy to adjust the approach based on your feedback.