[Feature]: Dashboard UI full multi-language i18n (i18next, 11 locales)

Prerequisites

• I have searched existing issues and discussions to avoid duplicates

Searched for i18n, locale, zh-CN, internationalization, and translation. Related open requests:

• #6086 — general Dashboard i18n request
• #5550 — Simplified Chinese request

This issue proposes a concrete UI implementation (stack, persistence, namespaces, multi-locale coverage) and is accompanied by PR #6766 targeting dev. Happy to close/merge discussion into #6086 if maintainers prefer a single tracking issue.

Problem to solve

The Bifrost Dashboard (React) is English-only today. There is no language switcher and no locale persistence, which adds friction for operators who prefer non-English locales (Simplified Chinese and beyond).

Who benefits: Dashboard operators and admins in non-English locales; teams onboarding Bifrost where English-only UI slows day-to-day governance/ops work.

Proposed solution

Add full Dashboard UI multi-language internationalization with:

• Libraries: i18next + react-i18next
• Locales (11): English (en) as source/default/fallback, plus Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), Japanese (ja), Korean (ko), Spanish (es), European Portuguese (pt), French (fr), German (de), Italian (it), and Russian (ru)
• Persistence: localStorage key bifrost.locale (fallback to English)
• Detection: browser language detection for supported locales; unsupported languages fall back to English
• UX: LanguageSwitcher in the shell for all supported locales; reload/refresh keeps the selection
• Organization: translation namespaces by surface, e.g. common, shell, login, plus workspace domains (models, config, MCP, governance, observability, etc.)
• Scope: UI strings only (no gateway/API error-message localization in this change)
• Size note: The full Dashboard string coverage is larger than the usual <400-line PR guideline. This ships as one complete multi-locale PR for reviewability of the end-to-end UX; if maintainers prefer, we can split by namespace/surface in follow-ups.

Alternatives considered

• Browser auto-translate (Chrome/Edge): poor UX, often breaks layout/controls
• Docs-only translation: does not help the live Dashboard
• react-intl / other i18n libs: i18next is widely used with React and fits namespace splitting well
• English + zh-CN only: leaves other operator locales unaddressed; this issue/PR ships the full supported set instead
• Rely solely on #6086 without an implementation PR: leaves the request unactionable

Area(s)

• UI (React)

Additional context

• Default remains English — no breaking change for existing users
• No CLA/DCO changes required for this contribution path (per current contributing docs)
• Implementation PR: #6766 (targets dev per upstream contribution guidelines)