fix(desktop): align workHubHelp copy across locales

[Lxr-max]

Summary

workHubHelp in zh-TW still described WorkHub as a working feature. en and zh-CN already say it is unavailable and the settings toggle is for development testing only.

WorkHub still defaults to enabled: false and stays opt-in (packages/core/src/settings.ts, packages/core/src/__tests__/settings.test.ts). The desktop toggle remains a development gate: app-shell.tsx only shows the WorkHub entry when workHub.enabled is true. #3935 rewrote en/zh-CN to that product statement; #3853 later added zh-TW from the pre-#3935 source. This PR replaces the zh-TW string with a Traditional Chinese rendering of the current zh-CN text so all three locales agree.

Chosen wording:

• en: WorkHub is not available yet. This toggle is for development testing and does not enable a usable feature. (unchanged)
• zh-CN: WorkHub 目前仍不可用。此开关仅供开发测试，开启后也不能保证正常使用。 (unchanged)
• zh-TW: WorkHub 目前仍不可用。此開關僅供開發測試，開啟後也不能保證正常使用。

Fixes #5289

Verification

• git grep -o "workHubHelp: '[^']*'" -- apps/desktop/src/renderer/locales/settings-preferences-copy.ts — en, zh-CN, and zh-TW all say WorkHub is unavailable / development-only
• Loaded getSettingsPreferencesCopy with node --experimental-strip-types and asserted the three workHubHelp strings match the values above
• npx biome check on the two changed files — passed
• Did not run full npm --workspace @maka/desktop run build:test / test:dist (needs the workspace build graph). The new assertion is in settings-preferences-copy.test.ts, which that suite already runs
• Did not run repo-wide lint / format:check / typecheck

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope:

Cursor Cloud Agent (Grok 4.6) chose the product wording from current settings defaults and #3935, wrote the zh-TW string as a Traditional Chinese rendering of the existing zh-CN copy, added a three-locale assertion, and opened this pull request.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Review: fix(desktop): align workHubHelp copy across locales

Small, well-scoped copy fix. I verified it against the product state and could not find a real problem.

What I verified

Locale coverage is complete. SETTINGS_PREFERENCES_COPY_BY_LOCALE (apps/desktop/src/renderer/locales/settings-preferences-copy.ts:275) has exactly three locales — zh-CN (:276), zh-TW (:381), en (:478) — and the diff touches the only one that was stale. No locale was missed. I also compared the general key set across all three locale blocks in the PR head: no missing or extra keys (14 in zh-CN, 14 in zh-TW, same set in en). Since workHubHelp is typed string (settings-preferences-copy.ts:173), there are no placeholders or interpolations to keep in sync in any locale.

Traditional Chinese conversion looks right. The new value at settings-preferences-copy.ts:448 uses 開/關/僅/開發/測試/保證/正常/使用. None of those are Simplified-only glyphs; the characters shared by both scripts (用, 供, 保, 也) are the expected ones. This matches the terminology already used elsewhere in the zh-TW block (測試 ×4, 僅 ×3, 專案 ×4, 網路 ×4), so the string is idiomatic for the file rather than a transliteration of zh-CN.

The product statement matches the code. packages/core/src/settings.ts:864-866 still ships workHub: { enabled: false }, and apps/desktop/src/renderer/app-shell.tsx:429-436 gates the WorkHub entry on workHub.enabled read from client settings, so "development testing only" is accurate. Consumer side is apps/desktop/src/renderer/settings/general-settings-page.tsx:277-278 (copy.workHub / copy.workHubHelp).

The test is real and would fail without the change. The assertion at apps/desktop/src/main/__tests__/settings-preferences-copy.test.ts:56-70 is byte-identical to the new copy value, and the replaced zh-TW value (在一個入口檢視已有工作，並將新輸入保守地送往普通任務。) is what main still has, so the test does pin the fix rather than restating current behavior. No encoding or CRLF issues in the diff.

Nits

• Test name casing/style (nit). apps/desktop/src/main/__tests__/settings-preferences-copy.test.ts:56 — every other test in this file uses sentence-style, locale-descriptive names ('Traditional Chinese settings copy uses Taiwan terminology', 'Traditional Chinese MCP catalog does not fall back to Simplified Chinese'). Something like 'workHubHelp says WorkHub is unavailable in every locale' would read more consistently next to them.
• Optional: mirror the Simplified-regression guard (nit). 'Traditional Chinese bot settings use Taiwan integration terminology' (:68) pairs assert.match with assert.doesNotMatch(..., /接入/). Exact equality already covers that here and is strictly stronger, so no change is needed — mentioning it only in case you want the file's idiom to be uniform.

No blocking concerns from me; 👍 on the copy itself.

[hqhq1025]

Reviewed the current head. No substantiated P0–P3 finding in the changed copy and test.

The Traditional Chinese workHubHelp now says WorkHub is unavailable and the toggle is for development testing, matching the existing English and Simplified Chinese messages (apps/desktop/src/renderer/locales/settings-preferences-copy.ts:343,448,510). The settings page displays that string beside the toggle (apps/desktop/src/renderer/settings/general-settings-page.tsx:276-284). WorkHub remains disabled by default and its shell entry is conditional on the setting (packages/core/src/settings.ts:809-811; apps/desktop/src/renderer/app-shell.tsx:2415-2418). The added test checks all three locale strings (apps/desktop/src/main/__tests__/settings-preferences-copy.test.ts:56-70); the current commit only changes its test name. No application behavior, schema, or migration changes.

This head has no visible checks and conflicts with current main in both changed files (git merge-tree failed). git diff --check passed. I did not run local tests (Node 18/no installed dependencies) or a Desktop UI smoke test. Resolve the conflicts and revalidate the resulting head before a human merge decision.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[Astro-Han]

Thank you for this contribution, and sorry to close it on process grounds rather than on its merits.

The PR's generative-tooling disclosure says Grok was used. SpaceXAI recently changed Grok's Acceptable Use Policy to bar using Grok or its output to develop, or assist anyone in developing, products or services that compete with SpaceXAI, directly or indirectly. That is a field-of-use restriction, and under the ASF's draft generative tooling criteria it would likely place Grok in Category X. It is being discussed on legal-discuss now, and until that is settled the project has been asked not to accept Grok-generated contributions. Code merged here ships under the Apache License to everyone, so the restriction matters even though Maka itself is not the concern.

This is not a judgement on the change itself. If you would like to continue, please re-create it with a different tool (or by hand) and open a new PR, noting the tool in the disclosure as usual. We will review it normally.

Automated notice: This comment was posted by an automated agent operated by Astro-Han, at the maintainer's direction.