openclaw - 💡(How to fix) Fix [Feature]: Control UI config page fields should support i18n translation

Summary

The config page renders field names from JSON Schema keys using the yn() utility, which always produces English labels (e.g., "Server Max Payload" from serverMaxPayload). These labels should go through the i18n translation system so that the zh-CN, zh-TW, de, es, pt-BR translation files can override them.

Problem to solve

The Control UI already has full zh-CN, zh-TW, pt-BR, de, es translation files, and most UI elements correctly use the L() translation function. However, the Config page is the only major section that remains partially English regardless of the selected language.

This happens because config field labels are generated dynamically from JSON Schema keys using the yn() utility function (in assets/index-*.js), which converts camelCase to human-readable English text on the fly. It completely bypasses the i18n system, so there is no way for translation files to override these labels.

This means:

• Non-English users see a mix of translated page structure + English field labels
• The config page feels unfinished in non-English locales
• Contributors maintaining translation files have no way to fix this

Proposed solution

Instead of rendering labels purely through the yn() utility (which converts camelCase to English), the Config page should look up field labels via the existing L() translation function first, falling back to yn() only when no translation key exists.

Proposed approach:

1. In the Control UI's i18n system, add a new top-level translation namespace (e.g., config.fields) for config field labels.
2. When rendering a config field, try L('config.fields.' + path) first; if no translation is found, fall back to the current yn() behavior.
3. Translation files can then add keys like config.fields.gateway.serverMaxPayload, config.fields.agents.list, etc.
4. Optionally, the translation system could support a flat map of fieldKey → localizedLabel for simplicity.

This is backward-compatible: existing translation files need no changes, and the English fallback remains identical to current behavior.

Alternatives considered

1. Server-side translation: Adding translations on the gateway side is possible but would mix concerns and require a separate client-server translation protocol. The Control UI already has a working i18n system — better to leverage it.

2. Hardcoding a Chinese name map in the yn() function: Works locally but doesn't scale across contributors and is lost on every Control UI rebuild. Translation files are the proper place for this.

3. Using uiHints from the config schema: The schema already has a uiHints mechanism that can override field labels, but these hints are defined in the Go code on the server side and cannot be translated per-locale. The frontend i18n system is the right layer for multilingual labels.

Impact

Affected: All non-English OpenClaw Control UI users. The project already ships translation files for 5+ locales including zh-CN, zh-TW, pt-BR, de, es.

Severity: Medium. The config page is usable but visually inconsistent — most UI is translated but field labels remain English.

Frequency: Every visit to the config page.

Consequence: (1) Reduced usability for non-English speakers who need to configure the gateway; (2) Translation contributors currently have no way to translate an entire page; (3) The config page stands out as the only untranslated section, undermining the otherwise excellent i18n coverage.

Evidence/examples

The yn() function responsible for rendering raw English labels can be found in the Control UI's compiled index-*.js file at dist/control-ui/assets/:

function yn(e){return e.replace(/_/g,` `).replace(/([a-z0-9])([A-Z])/g,`$1 $2`).replace(/\s+/g,` `).replace(/^./,e=>e.toUpperCase())}

This is called when rendering config field labels and does not consult the L() translation function. The L() function and the i18n framework (fe class in the same file) are already working correctly for all other parts of the UI.

Relevant code sections from index-Ij2djnNX.js:

• yn() function (line ~2, areas where field labels are rendered)
• The ab() function also shows the labeling pattern: let r=vn(e,n),i=r?.label??t.title??yn(String(e.at(-1))) — demonstrating that uiHints and title are checked before yn(), but L() translation is never consulted.

Additional information

The fix is frontend-only, no server-side changes needed. The core change is modifying how config field labels are resolved in the Control UI source, likely in just 1-2 functions.

I'd be happy to help with a PR if the approach is agreed upon. Happy to translate config field keys to zh-CN as well.