發布日期：2026-07-15
Windows 使用者現在打開程式，預設就會顯示你熟悉的介面語言，不用再自己手動去改設定了。以前如果沒有特別去設環境變數（environment variables，在系統底層預先塞給程式看的隱藏設定），系統只懂得去問 macOS 是什麼語言，在 Windows 上一律退回英文版。現在它學會了透過 locale.windows_locale 去查 Windows 的系統設定（也就是呼叫 GetUserDefaultUILanguage()），所以不管你的 Windows 是繁體中文（zh-TW）、簡體中文（zh-CN）、日文還是韓文，它一開箱就能配對到對應的語言。當然，如果你堅持要用環境變數指定，它還是會優先聽你的。就像走進國際連鎖店的台灣分店，以前店員不管三七二十一都先對你說英文，除非你胸前掛著「請講中文」的牌子；現在店員懂得看你在哪裡，一進門就直接用熟悉的母語招呼你。
Windows 使用者現在可以正常從系統列（Windows 螢幕右下角的一排小圖示）打開這個程式，它不會再默默崩潰了。以前在 Windows 上啟動系統列時，背後的程式碼會因為去拉取 macOS 專用的 objc 模組而引發找不到模組的錯誤（ModuleNotFoundError）；且由於程式的備援機制／退回路徑（fallback，指某個功能用不了時自動切換到另一個能用的模式）只認得 wintray 這個模組不見，遇到 objc 缺席就直接當作沒事般安靜閃退。此外，建立切換面板的選單時，背後的 pystray 套件會因為遇到多餘的位置參數（positional parameter，依順序傳入的變數）而引發數值錯誤（ValueError）；且將控制器暴露給 JS bridge（讓網頁前端跟背後 Python 程式溝通的橋樑）時，因為 pywebview 會把所有公開屬性（public attributes）序列化，導致在 WinForms 視窗架構中產生無窮迴圈直到當機。現在模組會延遲到真的需要時才載入，且備援機制只要發現任何模組不見就會乖乖印出名字並退回文字介面（TUI），我們也藉由將 panel-id 改為限用關鍵字綁定（keyword-only binding）解決了選單參數錯誤，並將控制器改存為私有屬性（private attribute）終結了迴圈問題。就像一台原本只要某顆螺絲不對就一聲不吭死火的引擎，現在不但順暢發動，就算哪裡故障也會在儀表板上亮起明確的警告燈。
在 Windows 系統裡，你的專案名稱終於不會再被程式讀錯了。Windows 的路徑寫法比較隨興，以前如果你的工作目錄（cwd）是用 POSIX-style cwds（指 Mac 或 Linux 上那種用正斜線 / 分隔資料夾的路徑格式，比如 C:/...）紀錄，或者用了 dash-encoded name（把斜線換成連字號以方便當作檔案名稱的格式），系統只懂得用 Windows 專屬的反斜線去切，結果就是把整串長長的路徑當成專案名稱，或者因為找不到只有反斜線的磁碟代號而放棄解碼。現在它學聰明了，在切開路徑前會先把正反斜線統一整理（normalize），並且知道要把代號鎖定在 C:\ 這種磁碟根目錄上，所以無論你用哪種格式都能完美還原正確的專案資料夾。就像郵差以前只要看到信封上用逗號代替換行，就會把整條街名連著人名當成一戶人家而送錯信；現在他們懂得先整理各種千奇百怪的地址寫法，準確把信件投遞到你的專案信箱裡。
Windows users now get the user interface in their familiar system language right out of the box, without having to tweak any settings manually. Previously, if you didn't explicitly set environment variables (hidden configurations stuffed into the system before a program runs), the language detection only knew how to ask macOS (NSLocale) for the language and always awkwardly fell back to English on Windows. It now maps GetUserDefaultUILanguage() through locale.windows_locale, so whether your Windows UI is in zh-TW, zh-CN, ja, or ko, the app matches it instantly. Environment variables still take precedence if you want to override it. It's like walking into a global chain store's local branch—clerks used to greet everyone in English unless you wore a name tag requesting otherwise, but now they simply look at where they are and speak your native language the moment you walk in.
Windows users can now successfully open the app from the system tray (the row of small icons in the bottom right of the Windows screen) without it silently crashing before it even appears. Previously, starting the tray on Windows inadvertently tried to import the macOS-exclusive objc module, raising a ModuleNotFoundError; since the app's fallback (a backup path that automatically switches to another available mode when a feature fails) only knew how to handle a missing wintray module, it just quietly aborted without showing any window. Furthermore, when building the panel-switching menu, pystray would reject the action due to an extra defaulted positional parameter (a variable passed by position), raising a ValueError; and when exposing the controller to the JS bridge (the communication link between the web frontend and Python backend), pywebview serialized every public attribute, which recursed through the WinForms window graph until hitting the limit. Now, the objc module is strictly loaded only when needed (lazy import), the fallback gracefully degrades to a text interface (TUI) while printing the exact missing module. The menu parameter bug is fixed by making the panel-id binding keyword-only, and the recursion loop is resolved by keeping the controller in a private attribute. It's like trying to start a car whose engine used to flood and die silently if a single unrelated part was missing; now the ignition purrs to life perfectly, and if something does break, it at least lights up a specific warning on the dashboard.
Project names and folder paths on Windows are no longer bizarrely misread by the app. Because Windows paths can be a bit messy, if your current working directory (cwd) was recorded using POSIX-style cwds (paths using forward slashes like C:/... typically seen on Mac or Linux) or if it used a dash-encoded name (a format that replaces slashes with hyphens to safely create filenames), the system stubbornly tried to split them strictly by Windows backslashes. This resulted in it keeping the entire long path string as the "project name" or completely failing to decode paths because a bare backslash lacks a drive letter. Now, it smartly normalizes all separators on Windows before splitting, and correctly anchors decoded paths to drive roots (like C:\), restoring your actual project folder flawlessly. It's like a mail carrier who used to get utterly confused and fail to deliver your mail if your address was written with commas instead of standard line breaks; now they automatically clean up your address format in their head and drop the package at the correct house every time.
**Windows auto-detects the interface language**: with no `USAGE_LANG`/`TT_LANG`/`LANG` set, language detection only knew how to ask macOS (`NSLocale`) and always fell back to English on Windows. It now maps `GetUserDefaultUILanguage()` through `locale.windows_locale`, so a zh-TW / zh-CN / ja / ko Windows UI gets the matching interface out of the box. Environment variables still take precedence.**The Windows tray now actually starts**: importing the tray pulled in the `panels` package, whose `__init__` eagerly imported the PyObjC-backed `panels.web_panel`; on Windows this raised `ModuleNotFoundError: No module named 'objc'`, and because the TUI fallback in `main.py` only recognized a missing `wintray` module, the windowed build exited silently with nothing on screen. The panel registry now imports `web_panel` lazily inside `all_panels()` (macOS behavior unchanged), and the fallback degrades to the TUI whenever any module in the tray's import chain is missing, printing the missing module's name.
**The tray menu and JS bridge no longer break at startup**: pystray rejects menu actions whose lambda carries an extra defaulted positional parameter, so building the panel-switch submenu raised `ValueError` before the icon ever appeared; and pywebview serializes every public attribute of the `js_api` object into the JS bridge, so exposing the tray controller on it recursed through the WinForms window graph until the recursion limit. The panel-id binding is now keyword-only, and the bridge holds the controller in a private attribute.**Project names derive correctly from POSIX-style cwds on Windows**: `usage_session_resume._project_from_cwd` and `adapters.claude.project_from_cwd` split paths on `os.sep` only, so a transcript cwd recorded with forward slashes (or a `C:/...`-style path) kept the whole path as the "project" on Windows. Both now normalize separators on Windows before splitting; POSIX behavior is unchanged, since backslashes are legal in POSIX filenames.
**Encoded project-path decoding now works on Windows**: `project_from_encoded_path` reconstructed a project's real directory from its dash-encoded name by searching from the filesystem root, but a bare Windows `\` has no drive letter and never matches a real path, so decoding always fell back to the raw encoded string. It now anchors at the drive root (e.g. `C:\`) when the encoded name starts with one; POSIX behavior is unchanged.