Issue Station
Sign In
Tools hereToolbox

autogen - ✅(Solved) Fix Feature: Add Internationalization (i18n) Support to AutoGen Studio [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
microsoft/autogen#7573•Fetched 2026-04-11 06:14:12
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
26wukongwudao26wukongwudao
Participants
26wukongwudao26wukongwudao
Timeline (top)
cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #7572: feat(studio): add i18n infrastructure with zh-CN language pack

Description (problem / solution / changelog)

Summary

Add internationalization (i18n) support to AutoGen Studio frontend using , enabling multi-language UI with a standard language pack system. This PR includes the i18n infrastructure and a complete Simplified Chinese (zh-CN) translation.

Related Issue: #7573

Changes

New Files

    • i18next initialization with localStorage persistence
    • English source language pack (143 keys)
    • Simplified Chinese language pack (143 keys)
    • Language selection dropdown (antd Select)

Modified Files

    • Import i18n initialization
    • Add i18next + react-i18next dependencies
    • Migrate navigation items to use t() translation calls
    • Add LanguageSwitcher, migrate Sign out text
    • Add antd locale support (zh_CN/en_US) via ConfigProvider

How It Works

  1. i18next is initialized in gatsby-browser.js with en-US and zh-CN resource bundles
  2. Language preference is read from localStorage, defaulting to en-US
  3. LanguageSwitcher component in the header allows switching between languages
  4. antd ConfigProvider receives the appropriate locale based on current language
  5. Components use useTranslation() and t() for translatable text

Translation Key Statistics

NamespaceKeysDescription
nav13Navigation menu, sidebar
build22Team builder page
playground16Chat/playground page
gallery18Gallery page
settings24Settings page
deploy12Deploy page
labs2Labs page
auth6Authentication
common13Shared components
Total143

Testing

  • English UI renders identically after migration (no regressions)
  • Chinese UI shows all translated text correctly
  • Language switch persists across page navigation
  • Language preference saved in localStorage
  • antd components show Chinese text when zh-CN is selected
  • Build succeeds with no TypeScript errors
  • CI passes

Related

This is PR 1 of 4 in the i18n series (see #7573 for full proposal). Subsequent PRs will migrate remaining page components.

Changed files

  • python/packages/autogen-studio/frontend/gatsby-browser.js (modified, +1/-0)
  • python/packages/autogen-studio/frontend/package.json (modified, +2/-0)
  • python/packages/autogen-studio/frontend/src/components/LanguageSwitcher.tsx (added, +24/-0)
  • python/packages/autogen-studio/frontend/src/components/contentheader.tsx (modified, +7/-1)
  • python/packages/autogen-studio/frontend/src/components/layout.tsx (modified, +9/-0)
  • python/packages/autogen-studio/frontend/src/components/sidebar.tsx (modified, +51/-50)
  • python/packages/autogen-studio/frontend/src/i18n/index.ts (added, +23/-0)
  • python/packages/autogen-studio/frontend/src/i18n/locales/en-US/translation.json (added, +145/-0)
  • python/packages/autogen-studio/frontend/src/i18n/locales/zh-CN/translation.json (added, +145/-0)
RAW_BUFFERClick to expand / collapse

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

NamespaceKeysDescription
nav13Navigation menu, sidebar
build22Team builder page
playground16Chat/playground page
gallery18Gallery page
settings24Settings page
deploy12Deploy page
labs2Labs page
auth6Authentication
common13Shared components
Total143

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 #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.

extent analysis

TL;DR

Implement i18n support using react-i18next and provide language packs for English and Chinese to address the hardcoded UI text issue.

Guidance

  • Review the proposed solution and PR strategy to ensure it aligns with the project's requirements and best practices.
  • Verify that the react-i18next library is compatible with the existing tech stack and does not introduce any significant performance or security concerns.
  • Consider the maintainers' preferences on the language switcher placement and PR split strategy to ensure a smooth implementation process.
  • Test the i18n implementation with the provided zh-CN.json translation pack to ensure correct functionality.

Example

No code snippet is provided as it is not explicitly supported by the issue, but the t() translation calls can be used to replace hardcoded strings, e.g., t('build.saveChanges').

Notes

The implementation of i18n support may require additional testing and verification to ensure that all translatable strings are correctly replaced and that the language switcher functions as expected.

Recommendation

Apply the proposed workaround by implementing i18n support using react-i18next and providing language packs, as it addresses the hardcoded UI text issue and follows React ecosystem best practices.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt issue#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING