Language and localization

The website, documentation, tenant console, platform console and chat web app support Simplified Chinese, Traditional Chinese and English. Language changes presentation, not API paths, protocol error codes, CNY currency, the billing timezone or user content.

Website and documentation languages

Language	Documentation path	Identifier
Simplified Chinese	/docs/…	zh-CN
Traditional Chinese	/zh-TW/docs/…	zh-TW
English	/en/docs/…	en

Use the navigation language selector. Sidebars, internal links and search follow the chosen language. Translations may be marked draft; use the original-source link to compare Chinese content. Field names, API paths and code identifiers do not change in translation.

Console and chat language selectors are available before and after login. Precedence is: valid lang query parameter → locally saved choice → account preference → browser language → Simplified Chinese. Manual selection saves a local preference; signed-in tenant/platform accounts also save their personal preference. Switching does not clear forms.

Tags such as zh-Hant and zh-HK normalize to Traditional Chinese, zh-Hans to Simplified Chinese, and regional English tags to en. Use explicit preferences rather than inferring language from country or billing address.

HTTP requests and error text

Business servers can send Accept-Language, such as en or zh-TW. The backend negotiates language; relevant responses identify it with Content-Language and indicate language variation with Vary: Accept-Language. Do not share localized cached responses across languages.

Field	Purpose
error.code	Stable machine-readable decision input
error.details	Specific business context such as reason or field
error.message	Human-readable negotiated text; never parse it for business decisions
error.message_key	Optional stable catalog key for local rendering
error.message_params	Optional interpolation arguments; absence is not an incomplete error
error.request_id	Troubleshooting identifier independent of language

Older clients can continue reading message. New clients use code and details for behavior and localized text for display. WebSocket errors retain codes and can include message metadata. Custom rejection text from tenant callbacks is business content and remains unchanged.

Language headers do not change App Token authorization. Business apps should manage user-facing SDK language in the host rather than using platform-account preference APIs for end users.

Account language preferences

Signed-in identity	Method and path
Tenant console account	PUT /console/v1/account/locale
Platform administrator	PUT /platform/v1/me/locale

Request body:

{"locale":"en"}

Only the current account's preference changes; no other account ID is accepted. The returned profile contains locale, without overwriting concurrently edited names or other profile fields. These use console/platform sessions, not application App Tokens.

SDK localization

SDK/component	Usage
Web	Import createLocale and describeError from @deeprespond/im-web/locale; pass createLocale('en') or createLocale('zh-TW') to display helpers
Mini Program catalogs	Import @deeprespond/im-web/miniprogram/locale/en or …/zh-TW
React/Vue UIKit	Set locale="en" or locale="zh-TW" on UIKitProvider
Android	Pass DRLocale.en, DRLocale.zhTW or DRLocale.forLanguage(tag) to helper locale parameters
Flutter	Import en, zhTW, localeForLanguage(tag) from package:deeprespond_im_flutter/render.dart and pass to helpers/describeError

Web example:

import { createLocale, describeError } from '@deeprespond/im-web/locale';

const locale = createLocale('en');
const message = describeError(error, 'en');

Here error is a caught SDK error; locale can be used by summary and group-tip helpers. Catalogs are local and do not call online translation services. The host saves the choice. User messages and protocol values are not translated. Confirm the installed package actually exposes the APIs, rather than checking source version alone.

Notifications and managed content

Account preferences participate in system-notification language selection. The platform must configure mail and SMS variants with unchanged parameters, credential lifetimes and business checks. A missing requested notification variant fails explicitly rather than silently switching the language of a security code.

SMS templates require separate provider approval. Example _en and _zh_TW suffixes are not approved sending IDs. An English page does not imply English SMS is enabled. Private-deployment operators must verify actual catalogs, template IDs and delivery during upgrades.

Package descriptions, changelogs, copyright/developer names and footer HTML have platform-managed translations. Missing managed-content translations can fall back to the original; changelogs identify the actual content language. This differs from security-template failure behavior. Display language does not change prices, quotas or currency.

Troubleshooting

• Language reverts: check a retained lang parameter, saved local preference and whether a different account is signed in.
• English API text but Chinese UI text: check SDK catalog selection. User content, callback text and untranslated managed content can remain unchanged.
• An English billing page appears outdated: compare the Chinese source and report the URL; do not alter settlement based on an old translation.
• Notifications fail: check the language variant, approved SMS ID and current credential validity; generating more codes does not repair a template configuration.

See API overview and Errors for the shared contract.