[Bug] macOS Desktop ships without CFBundleLocalizations, so system dialogs and menus stay English on Chinese systems

[qkmaosjtu]

Cause

728d561 split the one macOS extendInfo object into two extendInfo keys of the same object literal (apps/desktop/scripts/electron-builder-config.mjs):

       // macOS matches the application locale against this bundle, not Electron Framework resources.
-      extendInfo: {
-        CFBundleLocalizations: ['en', 'zh_CN'],
-        NSMicrophoneUsageDescription: 'DeepSeek Harness uses your microphone to transcribe speech into message drafts.',
-      },
+      extendInfo: { CFBundleLocalizations: ['en', 'zh_CN'] },
       identity: macOSSigning?.signingIdentity,
       forceCodeSigning: true,
       hardenedRuntime: true,
+      extendInfo: { NSMicrophoneUsageDescription: 'DeepSeek Harness uses your microphone to transcribe speech into message drafts.' },

In a JavaScript object literal the later key replaces the earlier one, so only the microphone description survives and CFBundleLocalizations is lost. 942e496 had added it so that macOS matches the application language to the user's preferred languages, and the Desktop README still describes that. Both keys are still in 687f282. The installed 0.2.1-rc.2 Info.plist has no CFBundleLocalizations, and Contents/Resources has no .lproj directories, so macOS treats the application as English-only.

Neither check caught it. .oxlintrc.json ignores **/*.mjs, so no-dupe-keys never runs on this file; running that rule on it reports Duplicate key 'extendInfo' at line 163. macos-signature.spec.ts asserts only the microphone description.

What it affects

On macOS with Simplified Chinese as the preferred language, Desktop shows its own interface in Chinese, but everything that macOS and Chromium localize on the application's behalf stays English.

The folder dialog of "Add workspace" (file names, the home folder and tags blurred):

The same build with CFBundleLocalizations restored:

Menu items that macOS adds:

Menu	0.2.1-rc.2	With CFBundleLocalizations
DeepSeek Harness	Quit and Keep Windows	退出并保留窗口
Edit	AutoFill, Start Dictation…, Emoji & Symbols	自动填充、开始听写…、表情与符号
Window	Minimize All, Zoom All, Fill, Center, Enter Full Screen, Move & Resize, Full Screen Tile, Remove Window from Set, Arrange in Front	全部最小化、全部缩放、填充、居中、进入全屏幕、移动与调整大小、全屏幕平铺、从组中移除窗口、排在前面

Text that Chromium formats with the application locale is English too. navigator.language is en-US instead of zh-CN, and the Trajectory timeline tooltip, which formats times without a locale in formatRecordedTime, shows 12:10:13.208 AM while the Conversation view shows the same message at 00:10:

With CFBundleLocalizations restored, the tooltip shows 00:10:13.208.

We checked on macOS 26.7 with preferred languages Simplified Chinese, then English, launching each build normally through Launch Services. The comparison builds are copies of the installed application with a different bundle identifier, ad hoc signed with the installed entitlements. They differ only in CFBundleLocalizations, and the re-signed copy without it behaves exactly like the installed build. The titles Edit and Window and role items such as Undo, Copy and Minimize stay English in every build; they are Electron's default role labels, a separate gap.

Fix

Merge both values back into one extendInfo and assert the localizations in macos-signature.spec.ts: mobile-dev-harness/deepseek-harness@9462b56 (compare with master). Without the merge, the new assertion fails with expected undefined to deeply equal [ 'en', 'zh_CN' ]. It is MIT-licensed like DSH; please take it as-is or reimplement it.

Device permissions for plugins

We are building Mobile Preview Plugin, an open-source DSH plugin for mobile developers that shows and controls Android devices, iOS Simulators and USB-connected iPhones in the side panel. We found this while reviewing Desktop's signing configuration for a related need: macOS exposes the screen of a USB-connected iPhone only as a camera capture device, and it attributes camera requests from Desktop's child processes, including plugin helpers, to Desktop. Desktop's hardened-runtime signature includes com.apple.security.device.audio-input but not com.apple.security.device.camera, so macOS denies these requests without a prompt, and Desktop never appears under Privacy & Security › Camera. Some of our plugins will need camera access this way.

Is there a plan for how Desktop grants device permissions such as the camera to plugins? Adding the camera entitlement, as 846afdf did for the microphone, would unblock this. We would appreciate it if you could consider it, and we are glad to share our measurements or a reference change.

cc @LegGasai

[PerryLink]

Confirmed, and it is a one-key mistake, not a build-configuration subtlety. apps/desktop/scripts/electron-builder-config.mjs now has two extendInfo keys in the same object literal:

163:      extendInfo: { CFBundleLocalizations: ['en', 'zh_CN'] },
168:      extendInfo: { NSMicrophoneUsageDescription: 'DeepSeek Harness uses your microphone to transcribe speech into message drafts.' },

In a JavaScript object literal the second wins, so CFBundleLocalizations never reaches the bundle and the microphone description does. That is exactly the failure you describe, and the commit you cite is where it started.

Two notes that make the fix easier to land.

The comment that was attached to the original object is still the right statement of intent, and it is now orphaned above a key that gets discarded: macOS matches the application locale against this bundle rather than against the Electron Framework resources, which is why the key has to be in extendInfo at all. Whatever merges these two entries should keep that comment with the merged object.

The merge itself is mechanical: one extendInfo carrying both CFBundleLocalizations and NSMicrophoneUsageDescription. The reason it is worth a regression guard rather than just a fix is that duplicate keys in an object literal are legal JavaScript — the linter accepts them, node accepts them, and the only symptom is a signed bundle that quietly lost a plist key. A test that reads the built Info.plist (or the config object's own shape) would catch the next one.

One thing I would keep out of the report: this is not an Electron or electron-builder bug. The later key silently replacing the earlier one is ordinary JS semantics; electron-builder never saw two entries.