You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce first-class internationalization (i18n) in SILO Console with two supported locales initially:
en — English, the default and fallback language
zh-CN — Simplified Chinese, available by explicit user choice
English must remain the initial language. Chinese is opt-in only; the Console must not switch languages automatically based on browser or operating-system settings.
Feasibility
This is feasible without changing the routing model. Locale selection can live entirely in client-side state and translation resources.
Complete localization is a medium-sized change rather than a single-button patch. The application does not currently include an i18n library, and user-facing English copy is hard-coded across many screen components. The implementation should therefore establish a reusable localization layer first and migrate Console-owned strings into translation catalogs, instead of adding scattered language conditionals.
User experience
Add a compact language button to the top-right action area, immediately next to the light/dark mode button.
Use a combined “文/A” language icon that remains recognizable in both themes and at the existing control size.
In English, one click switches all Console-owned UI copy to Simplified Chinese.
In Chinese, one click switches the UI back to English.
Switching must be immediate: no reload, redirect, or loss of page state.
Keep the current URL, path, query string, and hash unchanged. Do not add locale-specific routes.
Show the control on both the login screen and authenticated Console pages.
Persist an explicit choice locally so it survives reloads and browser restarts. When no valid preference exists, always use English.
Give the button an accessible name and tooltip that describe the target action, such as Switch to Chinese and 切换到英文.
Update the document lang attribute when the active locale changes.
Implementation direction
Introduce a maintained React localization solution such as i18next + react-i18next, or an equivalent provider-based implementation.
Keep locale configuration centralized and extensible; adding a third language later should require registering another catalog, not changing every component.
Use stable semantic translation keys and feature-oriented namespaces/catalogs for en and zh-CN.
Treat English as the canonical source and fallback. Missing Chinese entries must render English, never raw translation keys or blank content.
Add a reusable LanguageActivator beside DarkModeActivator in the shared page header and login action group.
Use locale-aware formatting for Console-formatted dates, times, numbers, and relative durations where applicable, without changing API payloads or stored values.
Translate Console-owned navigation, headings, field labels, placeholders, buttons, tooltips, empty/loading states, dialogs, confirmations, validation text, notifications, help text, and accessibility labels.
Do not translate user data or protocol identifiers: bucket/object/user names, access keys, policy/configuration keys, S3 terms that must remain exact, logs, or arbitrary server-provided messages.
Acceptance criteria
With no stored language preference, the Console opens in English even when the browser or OS prefers Chinese.
The “文/A” toggle is visible next to the theme toggle on the login page and all authenticated page headers.
One click switches all Console-owned visible and accessible copy between English and Simplified Chinese without reloading.
Switching languages does not change the current route, query string, hash, or in-progress page state.
The explicit preference persists across reloads; an absent, invalid, or unsupported value falls back to English.
<html lang> reflects the active locale.
No raw translation keys, blank labels, or mixed-language UI caused by missing Console-owned translations are visible in either locale.
Dynamic user/server data and exact technical identifiers remain unchanged.
English and Chinese layouts are checked on representative login, Metrics, Object Browser, IAM, and Configuration views at desktop and mobile widths in both light and dark themes.
Automated tests cover the English default, two-way switching, persistence, fallback behavior, unchanged routing, and at least one representative translated workflow.
Contributor documentation explains how to add or update translation keys and register another locale.
Summary
Introduce first-class internationalization (i18n) in SILO Console with two supported locales initially:
en— English, the default and fallback languagezh-CN— Simplified Chinese, available by explicit user choiceEnglish must remain the initial language. Chinese is opt-in only; the Console must not switch languages automatically based on browser or operating-system settings.
Feasibility
This is feasible without changing the routing model. Locale selection can live entirely in client-side state and translation resources.
The switch itself is a small, low-risk UI addition: authenticated views share
PageHeaderWrapper, where the existing theme control is already mounted, and the login header has the same action cluster.Complete localization is a medium-sized change rather than a single-button patch. The application does not currently include an i18n library, and user-facing English copy is hard-coded across many screen components. The implementation should therefore establish a reusable localization layer first and migrate Console-owned strings into translation catalogs, instead of adding scattered language conditionals.
User experience
Switch to Chineseand切换到英文.langattribute when the active locale changes.Implementation direction
i18next+react-i18next, or an equivalent provider-based implementation.enandzh-CN.LanguageActivatorbesideDarkModeActivatorin the shared page header and login action group.Acceptance criteria
<html lang>reflects the active locale.Non-goals