Summary
openclawcode proactive notifications currently derive locale from the gateway process environment instead of the recipient or notification target. This makes notification language depend on systemd/shell locale, which is not the right source of truth for chat-facing messages.
We also now have mixed localization coverage: some proactive setup / welcome messages are localized, while several run-status notifications are still hardcoded in English.
Problem
1. Proactive notification locale follows process env, not user / target intent
Current locale resolution in extensions/openclawcode/index.ts uses:
OPENCLAWCODE_LOCALE
OPENCLAWCODE_LANGUAGE
LC_ALL
LC_MESSAGES
LANG
- fallback
zh-CN
This means a gateway launched with something like LANG=en_US.UTF-8 will send English proactive notifications even when the operator expects Chinese.
Observed behavior:
- Feishu operator binding welcome notification was sent in English
- The gateway process environment was
LANG=en_US.UTF-8
- The message content therefore followed host/process locale instead of the operator's intended notification language
2. Not all proactive notifications are localized
Some proactive notification paths already use localized builders, but other paths still emit inline English strings. Examples include run-status notifications such as:
openclawcode is starting ...
openclawcode failed on ...
openclawcode finished ..., but could not parse ...
This creates an inconsistent experience even if locale selection is fixed.
Proposed solution
Product behavior
Add an openclawcode proactive notification default language during onboarding.
Rules:
- The setting only affects openclawcode proactive messages
- It does not change model output language, CLI language, or general OpenClaw behavior
- During
openclaw onboard, let the user choose a default proactive notification language
- If the user does not choose one, default to English (
en) because it is the most universal fallback
Suggested config shape:
plugins.entries.openclawcode.config.defaultNotificationLocale
Suggested initial supported values:
Locale resolution for proactive notifications
For proactive openclawcode messages, use this precedence:
- Session-level explicit locale
- Notification target / binding-level locale
openclawcode.config.defaultNotificationLocale
- fallback
en
Important:
- Do not use
LANG, LC_ALL, or other process-level env as the primary source for chat notification locale
- Process env can remain a legacy fallback only if we explicitly still want it, but the cleaner direction is to remove it from proactive notification locale resolution entirely
Localization architecture
Centralize proactive notifications behind message builders / template ids instead of inline strings in workflow logic.
Examples:
setup.awaiting_github_auth
setup.ready
setup.failed
setup.recovery
feishu.binding_welcome
run.started
run.failed
run.completed_parse_error
This makes it possible to:
- audit localization coverage
- keep wording consistent
- add languages without hunting inline strings across runtime paths
Acceptance criteria
openclaw onboard prompts for openclawcode proactive notification default language
- If skipped, the stored default for proactive notifications is
en
- Proactive
openclawcode notifications no longer depend on gateway/system LANG
- A Chinese-targeted setup / welcome notification can be sent from an English-host locale without switching to English
- An English-targeted notification can be sent in the same running process to another target without affecting the Chinese target
- Current proactive notification paths are routed through localized builders instead of inline English strings
- Existing welcome/setup/run-status notifications use the resolved notification locale consistently
Notes
Relevant current code paths include:
- locale resolution in
extensions/openclawcode/index.ts
- localized setup / welcome notifications in
extensions/openclawcode/index.ts
- inline English run-status notifications in
extensions/openclawcode/index.ts
Summary
openclawcodeproactive notifications currently derive locale from the gateway process environment instead of the recipient or notification target. This makes notification language depend on systemd/shell locale, which is not the right source of truth for chat-facing messages.We also now have mixed localization coverage: some proactive setup / welcome messages are localized, while several run-status notifications are still hardcoded in English.
Problem
1. Proactive notification locale follows process env, not user / target intent
Current locale resolution in
extensions/openclawcode/index.tsuses:OPENCLAWCODE_LOCALEOPENCLAWCODE_LANGUAGELC_ALLLC_MESSAGESLANGzh-CNThis means a gateway launched with something like
LANG=en_US.UTF-8will send English proactive notifications even when the operator expects Chinese.Observed behavior:
LANG=en_US.UTF-82. Not all proactive notifications are localized
Some proactive notification paths already use localized builders, but other paths still emit inline English strings. Examples include run-status notifications such as:
openclawcode is starting ...openclawcode failed on ...openclawcode finished ..., but could not parse ...This creates an inconsistent experience even if locale selection is fixed.
Proposed solution
Product behavior
Add an openclawcode proactive notification default language during onboarding.
Rules:
openclaw onboard, let the user choose a default proactive notification languageen) because it is the most universal fallbackSuggested config shape:
plugins.entries.openclawcode.config.defaultNotificationLocaleSuggested initial supported values:
enzh-CNLocale resolution for proactive notifications
For proactive
openclawcodemessages, use this precedence:openclawcode.config.defaultNotificationLocaleenImportant:
LANG,LC_ALL, or other process-level env as the primary source for chat notification localeLocalization architecture
Centralize proactive notifications behind message builders / template ids instead of inline strings in workflow logic.
Examples:
setup.awaiting_github_authsetup.readysetup.failedsetup.recoveryfeishu.binding_welcomerun.startedrun.failedrun.completed_parse_errorThis makes it possible to:
Acceptance criteria
openclaw onboardprompts foropenclawcodeproactive notification default languageenopenclawcodenotifications no longer depend on gateway/systemLANGNotes
Relevant current code paths include:
extensions/openclawcode/index.tsextensions/openclawcode/index.tsextensions/openclawcode/index.ts