在 macOS 底下我們可以按 Caps Lock 鍵切換輸入法，但每次按的時候都會覺得有一點頓頓的，無法立即切換過去，這不是你的錯覺！

本文分享兩個重點：

1. 讓 Caps Lock 切換輸入法「立刻生效、沒有延遲」
2. 讓這個設定「開機自動套用」，不用每次重開機都重打指令

Calibre 什麼都好，就是中文書的元資料讓人崩潰

用 Calibre 管理電子書庫的人大概都經歷過這個流程：匯入一本書，點「下載元資料與封面」，然後看著搜尋結果轉圈圈，最後跳出來的不是空白就是一堆不相關的英文書。

這不是 Calibre 的問題。Calibre 的元資料架構設計得很好，它支援多個來源同時搜尋，讓你挑最完整的那筆。問題在於，內建的來源幾乎都是英文世界的資料庫，找不到繁體中文書。

現有方案為什麼不夠用

目前 Calibre 內建能用的來源大概就這些：

• Google Books — 偶爾能找到中文書，但資料經常殘缺。簡介只有一兩句、標籤沒有、封面模糊，有時候連作者名字都是拼音。

• Goodreads — 繁中書目少得可憐，大部分台灣出版的書根本搜不到。

• Kobo Metadata Plugin — 社群有人開發了一個從 Kobo 抓資料的外掛，設定台灣區之後確實能用。不過它不是每次都能找到資料，覆蓋率有限。

有更多適合台灣讀者的來源，總是一件好事。所以我決定自己動手。

用 KOReader 看書的人大概都有同樣的經驗：讀到好段落就順手畫個重點、寫個筆記，但讀完之後呢？這些標註就一直留在閱讀器裡，再也沒打開過。

我自己用 Obsidian 管理所有筆記，一直想把 KOReader 的 highlight 也整合進來，卻找不到現成的工具。手動複製貼上太慢，寫腳本又要處理 KOReader 那套 Lua 格式的 metadata。

所以我寫了 KOHi，一個 Obsidian plugin，專門解決這件事。

KOHi 做什麼

USB 接上閱讀器，在 Obsidian 裡執行一個指令，就能把 KOReader 的 highlight 和筆記匯入 vault。每本書產生一份 Markdown 筆記，包含書籍資訊和所有標註。

核心功能：

• 自動偵測儲存模式 — KOReader 有三種存放 metadata 的方式（book folder / koreader/docsettings / koreader/hashdocsettings），KOHi 全部支援，不用自己去找檔案在哪裡。
• 模板自訂 — 產生的筆記格式完全可控。用 Nunjucks 模板語法，可以自訂 frontmatter、章節分組、頁碼、highlight 顏色等所有欄位。也提供預設模板，不想自己寫也能直接用。
• 選擇性匯入 — 可以一次匯入全部，也可以用模糊搜尋挑特定幾本書。
• 重複匯入覆蓋 — 重新匯入同一本書時，可以選擇是否要自動覆蓋舊筆記，不會產生重複檔案。

在開發 iOS 應用程式時，使用 Swift Package Manager (SPM) 來模組化程式碼已經成為主流做法。然而，當你在 Swift Package 中實作多國語言支援時，可能會遇到一個令人困惑的問題：Package 內的本地化在測試時運作正常，但整合到主專案後卻失效了。本文將深入探討這個問題的根源，以及如何透過 CFBundleLocalizations 和 CFBundleAllowMixedLocalizations 這兩個 Info.plist 設定來解決。

前言

當我實作畫面流程時，我會為一組「流程」建立一個 Coordinator。如果這組流程很複雜，它可以拆分成多個「子流程」，那每一個子流程也會有對應的 Sub-Coordinator。主流程的 Coordinator 可以管理子流程的 Sub-Coordinator。

Coordinator 用來管理流程的畫面，它負責建立畫面、傳遞資料給畫面、回應畫面的請求、移除畫面等等。如果用 tree 來理解畫面流程的話，Coordinator 就是 root，各個畫面就是 leaf。換個角度看，Coordinator 像一個容器 — 它自己不產出畫面內容，而是決定裡面放哪些畫面、什麼時候切換。

Xcode 的 project.pbxproj 檔案採用文字格式儲存專案結構，但 Xcode 在新增檔案或修改設定時，不保證項目的插入順序一致。多人協作時，即使修改不同的檔案或 target，也可能因為項目順序差異而產生 merge conflict。這些衝突往往與實際變更無關，純粹是格式問題。

我的解決方案

將 project.pbxproj 中的各個區塊按固定規則排序，確保相同內容產生相同的檔案結構。配合 git pre-commit hook，每次提交前自動排序，團隊成員的專案檔就能維持一致的順序，大幅降低無意義的衝突。

我開發了一個腳本工具來執行這個任務，也已經在多個專案上跑了好幾年，GitHub repo 放在這裡：https://github.com/chiahsien/sort-Xcode-project-file

雖然目前推崇使用 Swift Package Manager 進行模組化，Xcode 16 也引入了 buildable folders 功能來減少專案檔變更，甚至也有 Tuist 或 Xcode Gen 這類的工具來生成專案檔，但這些新技術主要針對新專案或願意大幅重構的專案。對於已經開發多年、結構複雜的舊專案，貿然改用 SPM 模組化或轉換成 folder references 風險過高。此時，這個排序工具仍是最務實的選擇，能以最小成本解決 merge conflict 問題。