Feature: Add Internationalization (i18n) Support to AutoGen Studio

[26wukongwudao]

Problem

AutoGen Studio currently has all UI text hardcoded in English across ~30 React components (~143 translatable strings). This creates a significant barrier for non-English-speaking developers, especially the large and growing Chinese developer community.

Proposed Solution

Add i18n support using react-i18next (the standard i18n library in the React ecosystem) with a language pack system:

1. i18n Infrastructure: Initialize i18next with resource bundles
2. Component Migration: Replace hardcoded strings with t() translation calls
3. Language Packs: Provide en-US.json (source) and zh-CN.json (Simplified Chinese)
4. Language Switcher: Add language selection dropdown in the header
5. antd Locale: Integrate Ant Design's built-in locale system

Technical Details

• Library: react-i18next + i18next (most widely used React i18n solution)
• Key structure: namespace.semanticName (e.g., build.saveChanges, playground.newSession)
• Language detection: localStorage preference, with browser language as fallback
• Estimated scope: ~143 translation keys across 9 namespaces

Translation Key Statistics

Namespace	Keys	Description
nav	13	Navigation menu, sidebar
build	22	Team builder page
playground	16	Chat/playground page
gallery	18	Gallery page
settings	24	Settings page
deploy	12	Deploy page
labs	2	Labs page
auth	6	Authentication
common	13	Shared components
Total	143

PR Strategy

I propose splitting this into 4 focused PRs for easier review:

1. PR 1: i18n infrastructure (i18next init, en-US.json, LanguageSwitcher component) - See feat(studio): add i18n infrastructure with zh-CN language pack #7572
2. PR 2: Component migration - Build + Playground pages
3. PR 3: Component migration - Gallery + Settings + Deploy + Labs pages
4. PR 4: zh-CN translation pack + antd locale integration

Benefits

• Makes AutoGen Studio accessible to Chinese-speaking developers
• Establishes a framework for community-contributed translations (ja, ko, de, fr, etc.)
• Zero impact on existing English UI (default locale unchanged)
• Follows React ecosystem best practices

Questions for Maintainers

1. Is react-i18next acceptable as a new dependency, or would you prefer a lighter approach?
2. Should the language switcher be in the header, sidebar, or settings page?
3. Any preferences on the PR split strategy?

I have a complete zh-CN.json translation pack ready (143 keys) and PR #7572 submitted with the i18n infrastructure.