prd: Add extensible frontend internationalization support

[lirl-cn]

Problem

Label Studio's open-source frontend is currently English-only and does not provide a built-in internationalization framework or language selector. This makes the product harder to adopt for annotators and administrators who are not comfortable working in English, and it also means community translations cannot be added or maintained in a consistent way.

There is clear prior interest in this capability:

• internationalization #5498 requests frontend internationalization and Chinese language support.
• i18n #8828 confirms that the community edition currently has no built-in i18n system.
• I18n label-studio-frontend #1409 was an earlier i18next-based attempt that demonstrated feasibility, but it was closed before decisions were made about language selection and preference persistence.

The current React frontend is split across the Label Studio application shell, Editor, and Data Manager. Introducing localization across all of these areas in one change would create an overly large and difficult-to-review pull request. This PRD proposes an incremental approach.

Proof of Concept Notes

No implementation PR has been opened yet. Before preparing code, I would like to align with the maintainers on scope and product decisions.

A small proof of concept would:

1. Add a shared frontend i18n initialization layer.
2. Keep English as the default and fallback language so existing behavior remains unchanged.
3. Add Simplified Chinese (zh-CN) as the first validation locale.
4. Migrate only one small, representative application-shell surface.
5. Add unit tests for language selection, interpolation, missing-key fallback, and persistence.
6. Add a focused end-to-end test covering language switching and page reload.

i18next with react-i18next is one possible implementation because it supports React, pluralization, interpolation, namespaces, and incremental migration. This is a proposal rather than a fixed requirement; I am happy to follow the maintainers' preferred library or abstraction.

User Stories

• As an annotator, I want to use Label Studio navigation and actions in my preferred language so that I can label data without relying on English proficiency.
• As an organization administrator, I want the UI language choice to remain stable across page reloads so that users have a consistent experience.
• As a contributor, I want a documented translation structure and fallback behavior so that I can add or improve a locale without changing application logic.
• As a maintainer, I want localization to be introduced incrementally with English fallback and automated tests so that existing workflows are not disrupted.

Proposed Scope

Phase 1: Foundation PR

• Introduce a shared localization module for the React application.
• Define stable translation-key conventions and locale namespaces.
• Provide English resources and a small zh-CN resource set for the migrated surface.
• Detect a supported browser locale when no explicit preference exists.
• Persist an explicit language choice locally, without requiring a backend or database change.
• Configure safe fallback to English for unsupported locales and missing keys.
• Document how contributors add and test translations.
• Migrate one small application-shell surface only.

The foundation PR should remain small and reviewable. Editor, Data Manager, and broad string migration would be submitted as separate follow-up PRs.

Follow-up PRs

• Language selector placement, after maintainer/product confirmation.
• Label Studio application shell and project workflows.
• Data Manager.
• Labeling Editor.
• Ant Design and date/date-fns locale integration where required.
• Server-rendered Django templates, using the appropriate Django localization mechanism.

Out of Scope for the Foundation PR

• Translating user-provided project names, task data, label values, or labeling configuration content.
• Translating every frontend string in one pull request.
• Changing API payloads or backend-generated error contracts.
• Adding a database field for language preference.
• Localizing server-rendered Django templates in the same change.

Proposed Behavior

1. English remains the default and canonical fallback language.
2. On first visit, a supported browser language may be selected automatically; unsupported languages fall back to English.
3. An explicit user selection overrides browser detection and survives reloads.
4. Missing translation keys render the English value rather than an empty string or raw key.
5. User-generated content is displayed exactly as stored.
6. Locale-sensitive component text, dates, and plural forms use the active locale where supported.

Acceptance Criteria

• When an existing user opens Label Studio without a saved language preference, then the application continues to render successfully with English fallback.
• When a user selects Simplified Chinese, then the migrated UI surface updates without requiring a full application restart.
• When the user reloads the page, then the explicit language choice is retained.
• When a locale or translation key is unavailable, then the equivalent English text is shown.
• When translation strings include variables or plural forms, then interpolation and pluralization are covered by unit tests.
• When the frontend is built and tested, then existing lint, unit, and end-to-end checks continue to pass.
• When a contributor adds a locale, then the documented workflow explains resource placement, naming, fallback, and required tests.

Open Questions for Maintainers

1. Is i18next / react-i18next acceptable, or is another library/abstraction preferred?
2. Where should the language selector live: account settings, the user menu, or another location?
3. Is browser detection plus local persistence acceptable for the first phase, or should language preference be stored on the user model from the beginning?
4. Which application-shell surface would be the best first migration target?
5. Should zh-CN be included in the foundation PR as a validation locale, or submitted immediately afterward as a separate translation PR?

If this direction is accepted, I can prepare the small foundation PoC and split subsequent migrations into independently reviewable pull requests.