Start investigating the possibility of adding additional language support. Currently HomeGlow is English only
Suggested Requirements / Acceptance Criteria
Must-have (MVP)
Extract all hardcoded UI strings into namespaced JSON files under en/.
Integrate i18next + react-i18next with language detection and fallback to English.
Language preference stored and restored per device (and optionally global default in admin).
Language switcher in Admin Panel.
All core widgets (Chores, Calendar, Weather, Menu, Photos, Admin) fully translated for at least English + one other language (e.g. Spanish) as proof.
Dates, times, and relative times respect the selected locale.
No visible English strings when a complete translation is loaded.
Bundle size impact kept reasonable (lazy-loaded locales).
Should-have
Namespace isolation so widgets/plugins can ship their own translations.
Pluralization and interpolation support (ICU or i18next style).
Missing-key reporting in development (console warnings or a small debug overlay).
Backend support for Accept-Language on a few key endpoints.
Documentation for contributors: how to add a new language and how plugins declare translations.
CI check that every key present in en/*.json exists in other language files (or at least a completeness report).
Nice-to-have / Later
Community translation workflow (Crowdin, Weblate, or simple GitHub PRs with JSON).
Per-user language override (different family members on the same device).
Full RTL support + testing.
Pseudo-locale for development (to catch hard-coded strings and layout issues).
Automatic extraction of new strings (i18next-parser or similar).
Conceptualized structure:
i18n/
index.js # i18next init, detectors, fallbacks
locales/
en/
common.json
widgets.json
admin.json
chores.json
calendar.json
weather.json
...
de/
common.json
...
es/
...
namespaces.js # optional constants
hooks/
useTranslation.js # thin wrapper if needed
Start investigating the possibility of adding additional language support. Currently HomeGlow is English only
Suggested Requirements / Acceptance Criteria
Must-have (MVP)
Extract all hardcoded UI strings into namespaced JSON files under en/.
Integrate i18next + react-i18next with language detection and fallback to English.
Language preference stored and restored per device (and optionally global default in admin).
Language switcher in Admin Panel.
All core widgets (Chores, Calendar, Weather, Menu, Photos, Admin) fully translated for at least English + one other language (e.g. Spanish) as proof.
Dates, times, and relative times respect the selected locale.
No visible English strings when a complete translation is loaded.
Bundle size impact kept reasonable (lazy-loaded locales).
Should-have
Namespace isolation so widgets/plugins can ship their own translations.
Pluralization and interpolation support (ICU or i18next style).
Missing-key reporting in development (console warnings or a small debug overlay).
Backend support for Accept-Language on a few key endpoints.
Documentation for contributors: how to add a new language and how plugins declare translations.
CI check that every key present in en/*.json exists in other language files (or at least a completeness report).
Nice-to-have / Later
Community translation workflow (Crowdin, Weblate, or simple GitHub PRs with JSON).
Per-user language override (different family members on the same device).
Full RTL support + testing.
Pseudo-locale for development (to catch hard-coded strings and layout issues).
Automatic extraction of new strings (i18next-parser or similar).
Conceptualized structure: