configUi editors cannot follow the dashboard language: config:value carries no locale and an untranslated schema

[TreIngenia]

configUi editors cannot follow the dashboard language

config:value carries no locale, and the schema it sends is the untranslated one

Summary

A plugin that ships a configUi editor has no way to know which language the dashboard
is in, and receives the raw configSchema rather than the localized one. The result
is an editor stuck in whatever language its author hard-coded — or, at best, guessing from
navigator.language, which is a different thing from the dashboard's setting.

This is the same class of problem that theme solved in #860, and the fix has the same
shape: send it with the handshake.

What happens today

The handshake sends three fields (dashboard/src/pages/Plugins.tsx, L318–L323):

post({
  type: 'config:value',
  config: configUiSafeConfig(plugin, sessionId),
  schema: plugin.configSchema,   // ← raw, not localized
  theme: resolvedTheme,
});                              // ← no locale

Meanwhile the dashboard localizes everywhere else. localizePlugin(plugin, i18n.language)
(dashboard/src/utils/localizePlugin.ts) translates name, description and every
configSchema.properties[key].title / .description from the manifest i18n block, and
the generated form uses it (Plugins.tsx, L1275):

) : lz.configSchema && Object.keys(lz.configSchema.properties).length > 0 ? (
  <form ...>
    {Object.entries(lz.configSchema.properties).map(([key, field]) => (

So the two config surfaces disagree: the generated form follows the dashboard language,
the configUi iframe cannot. docs/19-plugin-architecture.md states the current
intent plainly — i18n is "Localized dashboard text per locale (dashboard-only)" — but
for a plugin with a custom editor that means its i18n block has no effect at all on the
fields the operator actually sees.

Why an editor cannot work around it

The iframe is sandbox="allow-scripts" without allow-same-origin, so it has an opaque
origin. It therefore cannot:

• read the dashboard's localStorage (where openwa_language lives) — access throws
  SecurityError, and even if it did not, storage is partitioned per origin and the
  iframe's is null;
• reach the parent DOM in any other way.

What is left is navigator.language. That is not arbitrary — it is the same fallback
the dashboard itself uses (order: ['localStorage', 'navigator'] in
dashboard/src/i18n/index.ts) — so it agrees with the dashboard in every case except
the one that matters: an operator who explicitly picked a language different from their
browser's. Which is exactly what someone does when they change the dashboard to English.

The only remaining workaround is a per-plugin language setting in the plugin's own config:
a second place to set something the dashboard already knows, and one the operator has no
reason to expect.

The precedent

theme was added for exactly this reason, and the comment above PluginConfigUi
(Plugins.tsx, L245–L248) already makes the argument:

theme is 'light' | 'dark', already resolved (so 'system' arrives as one of the two).
The iframe has an opaque origin and cannot read the parent's theme itself, so without
this an editor can only guess — which is how the Chat Flow editor ended up a glaring
white panel inside a dark modal. Additive: an editor that ignores the field renders
exactly as it did before.

Replace "theme" with "language" and the paragraph still holds.

Proposed change

Two additions in the handshake:

-  const { t } = useTranslation();
+  const { t, i18n } = useTranslation();

         post({
           type: 'config:value',
           config: configUiSafeConfig(plugin, sessionId),
-          schema: plugin.configSchema,
+          schema: localizePlugin(plugin, i18n.language).configSchema,
           theme: resolvedTheme,
+          locale: i18n.language,
         });

localizePlugin is already imported in that file, and the localized schema is already
computed a few lines away for the generated form.

Two notes on the shape:

• locale and the localized schema are both needed. The schema covers field titles
  and descriptions; locale covers the editor's own strings — tab labels, buttons,
  validation messages — which no schema can carry.
• Sending it once with the handshake is enough, for the same reason given for theme:
  the language control sits behind the modal overlay, so it cannot change while an editor
  is open, and reopening re-runs the handshake. (If a live switch is ever wanted, an
  additional config:locale message would be the natural extension.)

Compatibility

Additive on both counts. An editor that ignores locale behaves exactly as before. A
localized schema changes only title and description — the same fields the generated
form already renders from — and falls back to the untranslated values for any plugin
without an i18n block, since localizePlugin returns the plugin unchanged when there is
no matching override.

Impact

Every plugin with a configUi is affected, not only ours: today none of them can honour
the dashboard's language, and any i18n block they ship is silently ignored for the
fields the operator edits. Ours (an Odoo Helpdesk bridge) ships Italian and English and
currently has to expose its own language selector to work around this — which is the part
that feels wrong, since the dashboard already knows the answer.

[rmyndharis]

Implemented in #1711, as proposed here: config:value now carries locale (the dashboard language code) and a schema whose field titles and descriptions are localized from the manifest i18n block. The bridge table in docs/19-plugin-architecture.md documents both, including the fallback to navigator.language on an older host. It is on main and not in a release yet.

Thanks for the precise write-up; it made the change a four-line one.

[rmyndharis]

Status update: this shipped in v0.24.0, released today. The config:value handshake now carries locale, the dashboard's language code, and the schema it delivers has field titles and descriptions localized from the manifest i18n block, matching what the generated form already showed. An editor that ignores locale renders exactly as before, and docs/19-plugin-architecture.md documents both fields, including the navigator.language fallback on an older host. Thanks again for the precise proposal.