›_ Codex Issues
Codex Issues / #24741

i18n is disabled by default, preventing bundled translations from loading for all locales

Open 💬 3 comments Opened May 27, 2026 by Saber-CC
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.81530 (3178)

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex Desktop ships bundled translations and locale files for multiple locales, but the UI stays in English because i18n is gated behind the enable_i18n Statsig flag and its local fallback defaults to false.

This affects all bundled non-English locales, not only zh-CN. Even when the system locale is a supported locale, or localeOverride is set, the translated UI does not load unless the remote Statsig config explicitly enables enable_i18n.

I verified this locally by inspecting the packaged app. The i18n provider in the webview bundle reads the flag with a false fallback:

get(`enable_i18n`, false)

Changing only that fallback to true allows bundled translations to load.

What steps can reproduce the bug?

1. Install Codex Desktop version 26.519.81530 (3178).
2. Use a supported bundled non-English locale, for example:
   - Set macOS system language/region to zh-CN, ja-JP, fr-FR, de-DE, etc.
   - Or set Codex `localeOverride` to a supported locale such as `zh-CN`.
   - Or launch with `ELECTRON_LOCALE_OVERRIDE=zh-CN`.
3. Restart Codex Desktop.
4. Observe that the UI remains English.

This is not tied to a specific conversation/session. It happens before any Codex session is needed.

What is the expected behavior?

When the system locale or localeOverride is set to a supported bundled locale, Codex Desktop should load that locale's translated UI by default.

Since the locale files are already bundled with the desktop app, users should not need a remote Statsig flag to be enabled before translations can appear.

Additional information

This bug has existed for a long time. I noticed that no one has attempted to fix this vulnerability yet, and this vulnerability has occurred multiple times in the issue section. I would like to submit a pull request to fix this issue.

I wrote a Python script to patch the local app.asar file, and then I was able to switch languages correctly.

https://gist.github.com/Saber-CC/9c990d06f6a4c485de10851586cad818

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23431
  • #23815

Powered by Codex Action

tangnomad · 2 months ago

I can still reproduce this on the latest Codex Desktop release.

Environment:

  • Codex Desktop: 26.609.71450, released Jun 16, 2026
  • Codex CLI: 0.140.0-alpha.2
  • macOS: 26.5.1, build 25F80
  • Architecture: arm64, Apple M1
  • Auth mode: API key
  • Selected UI language: zh-CN / 中文（中国）

What I observed:

  • Settings > General > Language shows 中文（中国）.
  • ~/.codex/config.toml contains [desktop] localeOverride = "zh-CN".
  • Codex renderer/service processes are launched with --lang=zh-CN.
  • The app bundle includes zh-CN frontend translation assets and native-menu-locales/zh-CN.json.
  • Reinstalling Codex, fully restarting the app, and clearing Chromium/Electron cache did not help.
  • The visible app UI remains English.

Additional diagnosis:
The selected locale appears to be saved and propagated correctly. The problem looks consistent with the i18n provider not loading translated messages unless the remote Statsig gate/dynamic config enables enable_i18n. This also explains why another user on the same Codex version and also using API key auth can see Chinese UI, while this machine/account cannot.

Expected behavior:
If a supported locale is selected in Settings and localeOverride is set, Codex Desktop should load the bundled locale messages without requiring a per-account/per-device remote rollout flag.

shilei-openclaw · 2 months ago

Update / re-scoping after further investigation

After looking through existing issues, it turns out Codex Desktop already ships with a fairly complete zh-CN translation bundle (~6,000+ strings in webview/assets/zh-CN-*.js plus native-menu-locales/zh-CN.json). The original framing of this issue ("introduce an i18n layer") is therefore inaccurate — the i18n layer exists and the translations exist; they just don't load.

The actual root cause, already documented by other reporters, is that the i18n system is gated behind the Statsig flag enable_i18n, whose local fallback defaults to false. So even with:

  • OS locale set to zh-CN
  • localeOverride = "zh-CN" in config.toml
  • launching with --lang=zh-CN
  • ELECTRON_LOCALE_OVERRIDE=zh-CN

…the renderer still falls back to English because the i18n init code never activates.

Concrete asks (revised)

  1. Flip the local fallback for enable_i18n to true, or remove the gate entirely now that the translations are shipped.
  2. Make the web UI's i18n init read localeOverride / app.getLocale() / navigator.language instead of hard-coding en-US.
  3. Document the supported locales and the localeOverride config key in user-facing docs.

Related / likely-duplicate issues

  • #24741 — i18n disabled by default (root cause)
  • #23431 — Enable built-in Chinese (zh-CN) UI support
  • #25037 — [i18n] Enable zh-CN locale by default
  • #27411 — Bug: localeOverride does not take effect (with technical analysis)
  • #19239 — Desktop UI does not update language despite localeOverride/--lang
  • #24686 — Improve zh-CN localization coverage
  • #26780 — Windows: Statsig bootstrap failure also disables i18n

Happy for maintainers to close this as a duplicate of whichever of the above they consider canonical (likely #24741). Leaving it open meanwhile in case the consolidated framing helps triage.