fix(i18n): unconditional Chinese in the chatbot confirm card and field inspector (#2884, #2885) - #2900
Merged
Merged
Conversation
…d inspector (#2884, #2885) Two issues split out of the #2871 survey because neither is a language *branch* — both render Chinese for every user regardless of locale. #2884 — the confirm-before-change card. Heading, buttons, hint and the verb column of each change row were Chinese literals. They now follow the same prop-with-English-default convention the plan card already uses, with the console passing translated values from `console.ai.*`. The serious half was the outbound message: clicking Confirm sent '确认修改，应用你刚才提议的改动。' unconditionally, so an English user's click told the agent in Chinese to apply the changes and the agent answered in Chinese for the rest of the thread. It now routes through the same `convZh` conversation-language switch as `planApproveMessage`. The Chinese string is unchanged, so the cloud confirm gate sees byte-for-byte what it already accepted; `i18n.test.ts` pins it against the mirrored `APPROVAL_RE`. Also here: the error banner's `Response failed` / `Details` / `Retry` were hard-coded English, and it and the quota banner used a bare `t(key)` that renders the raw key with no `I18nProvider` mounted — both now use `useSafeTranslate`. The `「…」` corner brackets are now neutral quotes. #2885 — `ObjectFieldInspector` appended a bare `(草稿)` to draft objects in the lookup picker, the only Chinese literal in a file whose other 101 strings all go through `t(key, locale)`. It now reads `engine.inspector.draftSuffix`. The 18 new keys went into all ten locale packs, so the #2872 part (a) gap held at 469/471 rather than widening. Both new guards were mutation-tested. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TubWYdWquVkS9dj733sDmC
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
❌ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
The `*/` was lost in an editing pass, so `changesTitleLabel?: string;` was swallowed into the comment and never declared on `ChatbotEnhancedProps`. `tsc --noEmit` in app-shell caught it as "Property 'changesTitleLabel' does not exist", which failed `@object-ui/app-shell#build` and left the Console Performance Budget job reporting blank metrics. The documented default was wrong too — the heading defaults to "Confirm changes"; only the button was shortened to "Confirm". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TubWYdWquVkS9dj733sDmC
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
July 28, 2026 05:01
os-zhuang
added a commit
that referenced
this pull request
Jul 28, 2026
…ght trailing locales (#2872 part a) (#2903) Backfills `console`, `home`, `topbar` and `layout` — 193 keys x 8 packs, 1,544 strings — so a ja/ko/de/fr/es/pt/ru/ar admin sees the AI console, the home screen, the top bar and the system navigation in their own language instead of silently falling back to English. The gap in those eight packs drops from 469-471 keys to 277-279; en and zh stay at exact parity. This is the "high-frequency namespaces only" strategy, not a full backfill: `grid` (101), `gantt` (58), `dashboard` (25) and the long tail stay on English fallback and remain tracked under #2872. Four keys are deliberately NOT translated, and that is the load-bearing part of this change: console.ai.planApproveMessage console.ai.planApproveDefaultsMessage console.ai.planAnswerMessage console.ai.changesConfirmMessage These are not labels — they are text a button TRANSMITS to the agent, and the cloud confirm gate (service-ai-studio confirm-gate.ts APPROVAL_RE) decides whether it reads as approval. It recognises Chinese and English, nothing else. AiChatPage picks them by the language of the CONVERSATION, not the UI, so the t() call is expected to miss in every non-Chinese pack and fall through to its English defaultValue. Translating them would make a German user's "Build it" send German, the gate stop matching, and the agent re-propose instead of building — the button looks inert while nothing visibly errors. #2900 shipped exactly that bug for changesConfirmMessage, which had been added to all ten packs; this removes it from the eight and restores the English fallback. A new guard pins the invariant in both directions and was mutation-tested against re-adding an outbound key and against dropping an ordinary label. Translations are model-generated and would benefit from native review; every string's placeholder set was verified programmatically against the English source. Claude-Session: https://claude.ai/code/session_01TubWYdWquVkS9dj733sDmC Co-authored-by: Claude <noreply@anthropic.com>
This was referenced Jul 28, 2026
fix(i18n): the change card's Confirm button sent text the cloud gate rejects, + parity ratchet
#2905
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2884, closes #2885.
Both were split out of the #2871 survey because neither is a language branch — there is no
startsWith('zh')to fix. The copy is Chinese for every user, in every locale.#2884 — the confirm-before-change card
Heading, both buttons, the reply hint, and the verb column of every change row were Chinese literals, so an English user read the entire confirm gate in Chinese. They now follow the same prop-with-English-default convention the plan card already uses (
changesTitleLabel,changesConfirmLabel,changesConfirmHintLabel,changeVerbLabels, …), withAiChatPagepassing translated values fromconsole.ai.*.The outbound message needed a different fix than the issue proposed
Clicking Confirm called:
unconditionally — so an English user's click told the agent, in Chinese, to apply the changes, and the agent answered in Chinese for the rest of the thread.
I filed that issue suggesting the outbound text be forced to fixed English. Reading the surrounding code, that would have been wrong for this codebase.
AiChatPagealready has a deliberate rule, stated in its own comment:That is what
conversationLanguage.tsexists for, and it is one of the fourzhbranches #2871 deliberately keeps. Forcing English would have broken the Chinese case symmetrically. SochangesConfirmMessagenow routes through the sameconvZhswitch asplanApproveMessage— the message matches the language actually being spoken.Why the Chinese string is unchanged
zh.tsdocuments a constraint worth repeating: these outbound strings must match the cloud confirm gate'sAPPROVAL_RE(service-ai-studio/confirm-gate.ts), which anchors Chinese approval on 确认, or the agent silently re-proposes and the button looks inert. The Chinese message here is byte-for-byte the string that was already being sent, so that path is exactly what the gate already accepted.i18n.test.tsnow asserts it against the mirrored gate regex alongside the two plan messages.Note
One residual unknown, for whoever has cloud access. The English clause of
APPROVAL_REis not mirrored in this repo, so I could not verify that it acceptsConfirm the changes — apply what you just proposed.This path was never exercised before — the button always sent Chinese — so it is new ground. The existing EnglishplanApproveMessageis sent for English conversations today and presumably matches, which is good evidence an English clause exists, but it is evidence and not proof. If it turns out not to match, the fix is a wording change inen.ts, not a redesign. The test pins only the two tokens the message is built around (^Confirm,apply) so a careless reword can't silently drop the approval verb.Also in this component
Response failed/Details/Hide/Retrywere hard-coded English → newchatbotErrornamespace.t(key), which returns the raw key when the chat is mounted without anI18nProvider— the user would readchatbotError.title. Both now useuseSafeTranslate, which degrades to English. This is the surface that renders when things are already broken, so a raw key there is the worst possible time for one. Two existing tests were failing on exactly this and are now green without being edited.「{targetApp}」→"{targetApp}", two sites. CJK corner brackets rendered for all locales.formatChangeRow's（type）full-width parens →(type).Deliberately untouched:
DEFERRED_MARKERS('待补','后续', …) at:1001-1011. Those are Chinese-keyword heuristics for parsing the agent's replies, not UI copy — the issue says don't, and existing tests cover them.#2885 — the draft-object suffix
The only Chinese literal in a 1500-line file whose other 101 strings all go through
t(key, locale). Now readsengine.inspector.draftSuffixfrom the Studio catalog, withlocalethreaded into the hook.Verification
turbo type-check: 31/31.expected 'crm_quote (草稿)' to be 'crm_quote (draft)'), then restored.Locale packs
The 18 new keys went into all ten packs, so the #2872 part (a) gap held at 469/471 instead of widening. The eight non-Chinese packs have no
console.ainamespace at all today, so this creates it holding just these keys — a later bulk backfill merges into the same object.en ↔ zh remain at exact parity: 2499 : 2499, zero difference in both directions.
Generated by Claude Code