Uh oh!
There was an error while loading. Please reload this page.
fix(studio): pillars follow the active locale instead of hardcoded zh-CN - #2203
Merged
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
StudioDesignSurface pinned `const locale = 'zh-CN'` in its Interfaces / Data / Automations pillars, so the WYSIWYG builder always rendered Chinese even when the console ran in English — the Home page and the rest of the app followed the user's active locale, the Studio did not (F1, found dogfooding the pillar Studio). - Add `useMetadataLocale()` to metadata-admin/i18n.ts: derives the Studio locale from the live `useObjectTranslation().language` (the source the LocaleSwitcher drives), not `navigator.language` — so an in-app language switch re-renders the Studio in lock-step. Replaces the 3 hardcoded `'zh-CN'` and threads locale into every component that had inline strings (PackageSwitcher, the header/app-bridge, StudioNavItemInspector, all four pillars). - Extract every inline Chinese UI string in StudioDesignSurface into the `engine.studio.*` catalog (English + Chinese); pillar tab labels localize too. - Localize AppNavCanvas via `engine.appNav.*`: its hardcoded English "NAVIGATION" (the rootKey token), "Add nav item", "Remove nav item", item count, and empty states now follow the active locale (it renders in both the Chinese Studio and the English metadata-admin App preview). The "New item" default is localized with a locale-robust placeholder check kept back-compatible with the sentinel. - Add studio-locale.i18n.test.tsx: pins catalog EN/ZH resolution and asserts AppNavCanvas renders English under an English provider and Chinese under a Chinese one (the shared pillar wiring), so the regression can't return. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a dynamic case to studio-locale.i18n.test.tsx: render AppNavCanvas under an
English i18n instance, call `changeLanguage('zh')` (what LocaleSwitcher does), and
assert the DOM re-renders to Chinese in place (导航 appears, Navigation gone) — the
exact "switch locale → Studio follows" behavior, verified live in the browser too.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>os-zhuangforce-pushed
the
fix/studio-pillar-locale
branch
from
July 4, 2026 03:09
553738e to
861d44aCompareContributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem (F1)
The pillar Studio (
StudioDesignSurface) pinnedconst locale = 'zh-CN'in itsInterfaces / Data / Automations pillars, so the WYSIWYG builder always rendered
Chinese — even when the console ran in English. The Home page and the rest of
the app follow the user's active locale; the Studio did not. Found dogfooding the
pillar Studio end-to-end (building a recruitment app) after the blocking
dead-ends were fixed in #2198 / #2199. Non-blocking, but a real UX rough edge.
AppNavCanvascompounded it with hardcoded English strings ("NAVIGATION","Add nav item", "Remove nav item", empty-state) sitting amid the otherwise-Chinese
Studio.
Fix
Thread the real active locale. New
useMetadataLocale()inmetadata-admin/i18n.tsderives the Studio locale from the liveuseObjectTranslation().language— the same source theLocaleSwitcherdrives — rather than
navigator.language(which never changes on an in-appswitch, so
detectLocale()would have been a latent half-fix). The 3hardcoded
'zh-CN'are replaced, andlocaleis threaded into everycomponent that had inline strings (PackageSwitcher, the publish/app-bridge
header, StudioNavItemInspector, and all four pillars).
Extract the inline strings.
StudioDesignSurfacehad zero i18n — ~130inline Chinese UI strings. All are now
engine.studio.*keys with English +Chinese entries in the metadata-admin catalog (the Studio's real i18n home,
where sibling panels like
RuntimeDraftBaralready resolveengine.*keys —not
packages/i18n/src/locales). Pillar tab labels localize too.Localize
AppNavCanvasviaengine.appNav.*. It renders in both theChinese Studio and the English metadata-admin App preview, so it now follows
the active locale in both. The
'New item'default is localized with aplaceholder check kept back-compatible with the legacy sentinel.
Verification
pnpm --filter @object-ui/app-shell type-check— clean.ObjectFieldInspectorfailures are a
client.listDraftsmock gap onmain, confirmed viagit stash).studio-locale.i18n.test.tsxpins EN/ZH catalog resolution and assertsAppNavCanvasrenders English under an English provider and Chinese under aChinese one (the shared pillar wiring) — the exact "switch locale → Studio
follows" behavior, as a permanent regression guard.
🤖 Generated with Claude Code