-
Notifications
You must be signed in to change notification settings - Fork 21
Fix: Improve Chinese app name indexing and search #226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
- 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
📝 WalkthroughWalkthroughAdds 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
Sequence Diagram(s)mermaid MdFind->>FS: locate app bundle and read files Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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. Comment |
- Fix dependency order mismatch in apps/nexus/package.json - Update vue-sonner to use catalog reference - Mark @libsql/darwin-arm64 as optional
There was a problem hiding this 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
mdlscommand uses string interpolation with an unescaped path, which can break on special characters or be exploited. UseexecFilewith an argument array instead, following the pattern already established elsewhere in the codebase (seeeverything-provider.tsandfile-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.
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
InfoPlist.stringsfiles often use UTF-16 encoding, but the code was reading them as UTF-8, causing localized names to fail parsingkMDItemDisplayNameprovides the most reliable localized app names, but was only used during update scans, not initial scansnameoverdisplayName, missing Chinese names for pinyin conversionSolution
1. Add Spotlight Metadata Query
kMDItemDisplayNamefrom Spotlight during initial app scan2. Support Multiple Encodings
iconv-litefor UTF-16 BE decoding when available3. Prioritize displayName in Keyword Generation
displayName4. Ensure displayName Quality
undefinedto avoid invalid entriesChanges
darwin.tsgetLocalizedDisplayName()to support multiple encodingsgetAppInfoUnstable()to query Spotlight metadataapp-provider.tsdisplayNameTesting
The fix should be tested with:
weixin,wxshould find 微信微信should find 微信Impact
Related Issues
This PR addresses the Chinese app name indexing problem reported by users.
Summary by CodeRabbit
Bug Fixes
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.