Summary
Agent Orchestrator currently appears to be English-only. As Chinese-speaking users, we would like to help make the dashboard more accessible to non-English users, starting with localization infrastructure rather than an immediate full translation.
The goal is to localize display text while keeping AO's agent orchestration behavior stable by default.
Current observations
From a quick look at the current main branch:
packages/web is a Next.js dashboard and currently hardcodes <html lang="en"> in packages/web/src/app/layout.tsx.- I did not find an existing i18n layer such as
next-intl, react-i18next, i18next, useTranslation, or IntlProvider.
- The dashboard has many hardcoded English display strings across board columns, session cards, empty states, dialogs, status badges, and project/sidebar UI.
- The CLI and docs also have English output/content, but they are probably better handled after the dashboard path is clear.
Proposal
Add a phased localization foundation:
-
Dashboard UI i18n infrastructure
- Add a lightweight localization layer for
packages/web.
- Keep English as the default locale.
- Preserve current behavior when no locale is configured.
- Start with dashboard display text: navigation, board columns, buttons, empty states, dialogs, status badges, session cards, project/sidebar labels, loading/error text, and tooltips.
-
zh-CN as an initial community locale
- Add
zh-CN for the migrated dashboard strings as the first non-English locale.
- Support a simple preference mechanism, for example config/localStorage and/or a small locale selector.
- Update the document
lang attribute according to the active locale.
-
Keep machine-readable and agent-facing semantics stable
- Do not translate config keys, schema identifiers, plugin ids, agent ids, session ids, branch/status enum values, or automation semantics.
- Do not translate agent-facing prompts, task messages, review instructions, or orchestration commands in the first phase.
- Those strings can affect agent behavior, tool usage, review quality, and workflow routing, so they should probably have a separate prompt-locale design and regression tests.
-
Follow-up phases
- Website/docs localization can be handled separately after the dashboard pattern is established.
- CLI output localization can be considered later, likely controlled by config/env locale.
Why this matters
- AO is useful for a global developer audience, but the dashboard is currently English-only.
- Chinese-speaking users can start by contributing
zh-CN, while the same infrastructure would help any future locale.
- A small i18n foundation would let community contributors add translations without invasive UI rewrites.
- Keeping agent-facing text stable avoids making the orchestration layer less deterministic.
Suggested first-phase acceptance criteria
- English remains the default and existing dashboard behavior is unchanged.
- A small i18n helper/provider is added to
packages/web.
- A representative UI slice is migrated, such as:
- top-level dashboard chrome
- board/attention column labels
- common empty/loading/error states
- session card status labels and actions
- project/sidebar labels
zh-CN includes translations for the migrated strings.- The active locale updates the
<html lang="..."> attribute.
- Tests cover default-locale fallback behavior.
- Contributor docs explain how to add new locale keys.
Scope boundary
The key distinction is between display text and agent behavior text:
- Display text should be localizable.
- Config identifiers, status enum values, plugin/agent ids, session metadata, orchestration prompts, and automation semantics should stay stable in the first phase.
This should make AO friendlier to non-English users without changing how agents execute tasks.
Summary
Agent Orchestrator currently appears to be English-only. As Chinese-speaking users, we would like to help make the dashboard more accessible to non-English users, starting with localization infrastructure rather than an immediate full translation.
The goal is to localize display text while keeping AO's agent orchestration behavior stable by default.
Current observations
From a quick look at the current
mainbranch:packages/webis a Next.js dashboard and currently hardcodes<html lang="en">inpackages/web/src/app/layout.tsx.next-intl,react-i18next,i18next,useTranslation, orIntlProvider.Proposal
Add a phased localization foundation:
Dashboard UI i18n infrastructure
packages/web.zh-CNas an initial community localezh-CNfor the migrated dashboard strings as the first non-English locale.langattribute according to the active locale.Keep machine-readable and agent-facing semantics stable
Follow-up phases
Why this matters
zh-CN, while the same infrastructure would help any future locale.Suggested first-phase acceptance criteria
packages/web.zh-CNincludes translations for the migrated strings.<html lang="...">attribute.Scope boundary
The key distinction is between display text and agent behavior text:
This should make AO friendlier to non-English users without changing how agents execute tasks.