Skip to content

Internationalization ​

Render interface text through stable translation keys. Preserve business names, branding, agreements, and user input as written rather than changing them with the interface language.

Add page translations ​

LocationChange
src/locales/langs/zh-cn.tsChinese page resources
src/locales/langs/en-us.tsMatching English keys and structure
src/typings/app.d.tsExtend the relevant App.I18n.Schema branches
Vue templates / scriptsUse $t; scripts import it from @/locales

Extract large business resources into a separate file and merge them into the existing objects. Merely creating a file does not load it. Translate pages, validation, empty states, errors, and menus together. See the notes tutorial for complete resource and type wiring.

Use computed values or the existing reactive pattern for translated table columns and options. Calling $t only during initialization can leave old text after a language change.

Built-in names and user content ​

Menus use i18nKey; roles, AI assistants, and other built-in data use i18nKeys metadata. APIs return both raw content and translation keys. Web can display them through localizedText(rawText, key). Editing and submission still use raw values rather than writing rendered translations back to the database.

When users customize a built-in name or description, its translation binding is removed. Repeated seeding preserves explicit customizations. Do not duplicate roles, menus, or business primary keys per language.

Add a language ​

  1. Add complete resources, including ordinary pages and corresponding builtin-*, settings-*, and account-* content.
  2. Update App.I18n.LangType and the registry in src/locales/locale.ts.
  3. Add localeOptions in src/store/modules/app/index.ts, plus date and component-library language mappings.
  4. Register the same code in the backend settings catalog's default_locale options; adjust deployment DEFAULT_LOCALE if needed.
  5. Update resource-completeness tests and verify switching, persistence, defaults, and missing-key fallback.

A new language requires coordinated client resources and backend options, not just another menu choice. Desktop and App maintain separate resources and registration points.

Fallback and validation ​

Preserve the user's selected language. Without a selection, use tenant defaults, with deployment defaults providing base configuration. Missing translations fall back to English or raw text according to client rules. Match error text through stable errorCode values, not arbitrary backend msg strings.

Check language switching, translated built-in names in tables, unchanged custom names, persistence after reload, and missing keys. Multilingual business content is a separate requirement needing explicit fields and editing workflows.