- Add complete Japanese translation file (ja.json)
- Update frontend types and hooks to support "ja" language option
- Add Japanese tray menu texts in Rust backend
- Add Japanese option to language settings component
- Update Zod schema to include Japanese language validation
- Add test case for Japanese language preference
- Update i18n documentation to reflect three-language support
This reverts commit ba336fc416.
Reason: Found issues that need to be addressed before reintroducing
the auto-launch feature. Will reimplement with fixes.
Implement auto-launch functionality with proper state synchronization
and error handling across Windows, macOS, and Linux platforms.
Key changes:
- Add auto_launch module using auto-launch crate 0.5
- Define typed errors (AutoLaunchPathError, AutoLaunchEnableError, etc.)
- Sync system state with settings.json on app startup
- Only call system API when auto-launch state actually changes
- Add UI toggle in Window Settings panel
- Add i18n support for auto-launch settings (en/zh)
Implementation details:
- Settings file (settings.json) is the single source of truth
- On startup, system state is synced to match settings.json
- Error handling uses Rust type system with proper error propagation
- Frontend optimized to avoid unnecessary system API calls
Platform support:
- Windows: HKEY_CURRENT_USER registry modification
- macOS: AppleScript-based launch item (configurable to Launch Agent)
- Linux: XDG autostart desktop file
Fixed an issue where clicking the language switcher would cause a brief flash
and fail to persist the language change. The root cause was a dependency cycle
in useSettingsForm where readPersistedLanguage depended on i18n.language,
causing the initialization effect to re-run and reset state whenever the
language changed.
Changed the dependency from [i18n.language] to [i18n] since the i18n object
itself is stable and doesn't change when the language changes, while the
function can still access the current language value via closure.
Before optimization:
- useSettings.ts: 516 lines (single monolithic hook)
After optimization:
- useSettingsForm.ts: 158 lines (form state management)
- useDirectorySettings.ts: 297 lines (directory management)
- useSettingsMetadata.ts: 95 lines (metadata management)
- useSettings.ts: 215 lines (composition layer)
- Total: 765 lines (+249 lines, but with clear separation of concerns)
Benefits:
✅ Single Responsibility Principle: each hook focuses on one domain
✅ Testability: independent hooks are easier to unit test
✅ Reusability: specialized hooks can be reused in other components
✅ Maintainability: reduced cognitive load per file
✅ Zero breaking changes: SettingsDialog auto-adapted to new interface
Technical details:
- useSettingsForm: pure form state + language sync
- useDirectorySettings: directory selection/reset + default value computation
- useSettingsMetadata: config path + portable mode + restart flag
- useSettings: composition layer + save logic + reset logic
Jason