工程實踐

前一篇：用 Wikidata 翻地名談的是沒有官方圖資可用時，翻譯要付出多少代價來換取可信度。這篇是相反的情況：臺灣有完整、免費、定期更新的官方圖資，處理流程因此可以簡單到近乎乏味，而這正是它最好的地方。 這篇同時是一個 handler 的完整走查。流程篇講過 extract 的固定管線與各國專屬的插入點，這裡看的是臺灣把那幾個點填成了什麼。

上一篇：五個地區，五種方案談到，泰國、印尼這類非漢字系統的地名只能走翻譯路線，而專案選擇的翻譯來源是 Wikidata。 這篇要談的不是「怎麼查」，SPARQL 查詢本身沒什麼難度。難的是：Wikidata 翻錯的時候，通常不會有任何跡象。流程不會中斷，日誌不會報錯，輸出是一個合法的中文字串，只是指向錯的地方。

前兩篇把機制與流程講完了：Immich 從 cities500.txt 讀地名，而那份檔案由各國圖資經過 extract 與 release 產生。技術上「怎麼換」已經沒有懸念，真正難的是另一件事：外國地名要顯示成什麼樣子，臺灣使用者讀起來才自然。 immich-geodata-zh-tw 目前處理五個地區，給出了五種不同的答案。這篇談的是那些答案背後的判斷標準。

系列上一篇：反向地理編碼是怎麼運作的拆解了 Immich 怎麼讀地理資料：啟動時把幾個純文字檔匯入 PostgreSQL，照片上傳時用最近鄰查詢找出地名。既然換掉檔案就能換掉顯示結果，剩下的問題就落在那份「更好的檔案」本身。 這篇拆解 immich-geodata-zh-tw 的資料處理流程：從各國官方圖資，到使用者下載的那包 release.tar.gz。

每當你上傳一張照片到 Immich，系統就會自動標註拍攝地點，例如「臺北市信義區」、「東京都澀谷區」。這背後並非雲端 API 的功勞，而是一套完全離線運行的反向地理編碼（Reverse Geocoding）系統。 也因為它是離線的，immich-geodata-zh-tw 這個專案才有存在的空間（實際安裝步驟見系列首篇的圖文安裝教學）：Immich 從幾個純文字檔讀取地名，那麼換掉那幾個檔案，顯示出來的地名就會跟著換。 這篇是系列的技術篇第一篇，先把地基講清楚：Immich 查到一個地名時到底發生了什麼事、它讀的是哪幾個檔案，以及這個機制留下了哪些可以動手腳的空間。後續幾篇談的各國處理策略、翻譯與驗證，全部建立在這篇的基礎上。