Skip to content

Conversation

@TalexDreamSoul
Copy link
Contributor

@TalexDreamSoul TalexDreamSoul commented Jan 26, 2026

Problem

Chinese application names were not properly indexed and could not be searched using pinyin input. This affected the user experience for Chinese-speaking users who rely on pinyin search to find applications.

Root Cause Analysis

  1. Encoding Issue: InfoPlist.strings files often use UTF-16 encoding, but the code was reading them as UTF-8, causing localized names to fail parsing
  2. Missed Spotlight Metadata: macOS Spotlight's kMDItemDisplayName provides the most reliable localized app names, but was only used during update scans, not initial scans
  3. Incorrect Priority: The keyword generation prioritized name over displayName, missing Chinese names for pinyin conversion

Solution

1. Add Spotlight Metadata Query

  • Query kMDItemDisplayName from Spotlight during initial app scan
  • Use it as the primary source for display names (most reliable)
  • Fallback to other methods if Spotlight query fails

2. Support Multiple Encodings

  • Detect file encoding by BOM (Byte Order Mark)
  • Support UTF-16 LE, UTF-16 BE, and UTF-8
  • Use iconv-lite for UTF-16 BE decoding when available

3. Prioritize displayName in Keyword Generation

  • Reorder the names array to prioritize displayName
  • Ensure Chinese names are used for pinyin keyword generation
  • Convert pinyin to lowercase for consistent matching

4. Ensure displayName Quality

  • Trim whitespace from display names
  • Convert empty strings to undefined to avoid invalid entries

Changes

darwin.ts

  • Modified getLocalizedDisplayName() to support multiple encodings
  • Modified getAppInfoUnstable() to query Spotlight metadata
  • Updated display name priority: Spotlight > localized > plist > bundle name
  • Added proper trimming for display names

app-provider.ts

  • Reordered names array to prioritize displayName
  • Ensured pinyin conversion uses lowercase

Testing

The fix should be tested with:

  1. Chinese applications (e.g., 微信 WeChat, 钉钉 DingTalk)
  2. Pinyin search: weixin, wx should find 微信
  3. Chinese search: 微信 should find 微信
  4. Mixed language apps should work correctly

Impact

  • ✅ Improves Chinese app name detection
  • ✅ Enables pinyin search for Chinese apps
  • ✅ More reliable localized name handling
  • ✅ Better user experience for Chinese-speaking users
  • ⚠️ Requires re-scanning apps to rebuild index (existing users)

Related Issues

This PR addresses the Chinese app name indexing problem reported by users.

Summary by CodeRabbit

  • Bug Fixes

    • Fixed macOS app name and localized string handling so app names display correctly.
    • Normalized keyword generation to reduce case-sensitivity and improve search consistency.
  • Improvements

    • Prefer native system metadata (Spotlight) for more reliable app name resolution and discovery.
    • Updated prerender exclusions and adjusted content storage behavior to align with deployment needs.

✏️ Tip: You can customize this high-level summary in your review settings.

- Add Spotlight metadata (kMDItemDisplayName) as primary source for app display names
- Support multiple encodings (UTF-16 LE/BE, UTF-8) when reading InfoPlist.strings files
- Prioritize displayName over name in keyword generation for better Chinese pinyin indexing
- Ensure displayName is properly trimmed and not empty string

This fix addresses the issue where Chinese app names were not properly indexed
and could not be searched using pinyin. The changes improve the reliability of
localized app name detection on macOS.

Related issue: Chinese app name indexing problem
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 26, 2026

📝 Walkthrough

Walkthrough

Adds Spotlight-based display name resolution and MdFind discovery for macOS, improves InfoPlist.strings BOM-aware decoding, and reorders/normalizes app keyword generation to favor displayName and lowercase pinyin results.

Changes

Cohort / File(s) Summary
Keyword generation
apps/core-app/src/main/modules/box-tool/addon/apps/app-provider.ts
Reordered candidate name inputs to prefer displayName over name/fileName; normalize pinyin-derived keywords to lowercase; minor formatting adjustments.
macOS app discovery & metadata
apps/core-app/src/main/modules/box-tool/addon/apps/darwin.ts
Switch discovery to MdFind; add Spotlight (mdls) displayName retrieval and prefer it in resolution chain; read InfoPlist.strings as Buffer and decode BOM-aware (UTF-16LE/UTF-16BE/UTF-8); trim/undef empty displayName; minor comments.
Config & manifest
apps/nexus/nuxt.config.ts, package.json
Set content.experimental.nativeSqlitefalse; expand prerender.ignore to include /__nuxt_content/**; package.json listed in manifest changes.

Sequence Diagram(s)

mermaid
sequenceDiagram
participant MdFind as MdFind (discovery)
participant FS as Filesystem (bundle files)
participant Spotlight as Spotlight (mdls)
participant Provider as AppProvider (keyword gen)
participant Output as AppInfo

MdFind->>FS: locate app bundle and read files
FS->>FS: read InfoPlist.strings as Buffer\ndetect BOM → decode (UTF-16LE/UTF-16BE/UTF-8)
MdFind->>Spotlight: query mdls for display name
Spotlight-->>Provider: return SpotlightName (if present)
FS-->>Provider: return plist displayName / bundleName
Provider->>Provider: select displayName priority\n(Spotlight → localized → plist → bundle)\ntrim/undef empty
Provider->>Provider: generate keywords (prefer displayName;\nnormalize pinyin results to lowercase)
Provider-->>Output: emit app info object with displayName & keywords

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Poem

🐰 I hopped through plist bytes and Spotlight's beam,
Lowercased pinyin dancing in a gentle stream,
MdFind showed the path across the macOS plain,
Names trimmed and chosen by a curious brain,
Small rabbit joys in metadata rain ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly addresses the main change: improving Chinese app name indexing and search capabilities through pinyin support and encoding fixes.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

- Fix dependency order mismatch in apps/nexus/package.json
- Update vue-sonner to use catalog reference
- Mark @libsql/darwin-arm64 as optional
@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Jan 26, 2026

Deploying tuff with  Cloudflare Pages  Cloudflare Pages

Latest commit: d77276e
Status:🚫  Build failed.

View logs

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
apps/core-app/src/main/modules/box-tool/addon/apps/darwin.ts (1)

216-246: Use execFile instead of exec to avoid shell interpolation risks.

The mdls command uses string interpolation with an unescaped path, which can break on special characters or be exploited. Use execFile with an argument array instead, following the pattern already established elsewhere in the codebase (see everything-provider.ts and file-provider.ts).

🔒 Suggested fix (execFile to avoid shell interpolation)
-import { exec } from 'node:child_process'
+import { exec, execFile } from 'node:child_process'
@@
 const execAsync = promisify(exec)
+const execFileAsync = promisify(execFile)
@@
-    const { stdout } = await execAsync(`mdls -name kMDItemDisplayName -raw "${appPath}"`)
+    const { stdout } = await execFileAsync('mdls', ['-name', 'kMDItemDisplayName', '-raw', appPath])

Fixes Cloudflare Pages build failure caused by Nuxt Content internal routes
returning 500 errors during prerender phase.

The error occurred when nitro tried to prerender:
- /__nuxt_content/docs/sql_dump.txt
- /__nuxt_content/guides/sql_dump.txt

These are internal Nuxt Content routes that should not be prerendered.

Solution: Add '/__nuxt_content/**' to the prerender ignore list to skip
these internal routes while still prerendering the homepage.
The previous fix of ignoring __nuxt_content routes didn't work because
these routes are registered by the Nuxt Content module itself, not
discovered through link crawling.

The root cause is nativeSqlite: true in the content config, which causes
Nuxt Content to try to access SQLite database files during prerender,
resulting in 500 errors for:
- /__nuxt_content/docs/sql_dump.txt
- /__nuxt_content/guides/sql_dump.txt

Solution: Disable nativeSqlite to prevent these internal routes from
being accessed during the build process.

This is a safer approach than trying to filter out these routes, as it
addresses the root cause rather than the symptom.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants