前兩篇把機制與流程講完了：Immich 從 cities500.txt 讀地名，而那份檔案由各國圖資經過 extract 與 release 產生。技術上「怎麼換」已經沒有懸念，真正難的是另一件事：外國地名要顯示成什麼樣子，臺灣使用者讀起來才自然。
immich-geodata-zh-tw 目前處理五個地區，給出了五種不同的答案。這篇談的是那些答案背後的判斷標準。
各地區方案#
| 地區 | 顯示語言 | 圖資來源 |
|---|---|---|
| 🇹🇼 臺灣 | 繁體中文官方名稱 | 國土測繪中心（NLSC）村里界 |
| 🇯🇵 日本 | 日文原名（漢字與假名） | 国土数値情報（N03 行政区域） |
| 🇰🇷 南韓 | 一級行政區繁體中文，縣市為韓國官方漢字 | admdongkor 行政洞界 |
| 🇹🇭 泰國 | 繁體中文翻譯，官方英文與泰文備用 | COD-AB（Royal Thai Survey Department / OCHA） |
| 🇮🇩 印尼 | 繁體中文翻譯，BIG 官方印尼文備用 | 印尼地理空間資訊局（BIG）村級圖資 |
| 🌏 其他地區 | 國教院官方譯名 → GeoNames 中文 → 保留原文 | GeoNames |
五種答案看起來很雜，但依據其實只有一個：臺灣使用者看到哪一種寫法最自然。
這不是語言學上的分類。日本與韓國的行政區名以漢字書寫，臺灣讀者不需要翻譯就看得懂；而在日本地名這件事上，臺灣使用者反而更習慣看到原本的寫法（即使地名可能包含平假名或片假名）。既然如此，翻譯不會讓資訊更好讀，只會多一層出錯的機會。
反過來說，泰文與印尼文對臺灣讀者不具可讀性，那就只能翻譯。所謂「五種答案」，差別就在這裡。
日本：為什麼 Immich 直接顯示日文原名#
日本的處理最能說明這條標準。
日本的行政區名本來就是漢字寫的：横浜市、静岡県、渋谷区。理論上可以「翻譯」成臺灣慣用的字形，例如「橫濱市」、「靜岡縣」、「澀谷區」，但這麼做會產生兩個問題。
第一，它不是翻譯，是轉寫。「横浜市」與「橫濱市」指的是同一個地方、同一組漢字，只是字形不同。走機器轉換反而可能會冒出「静岡県」變成「靜岡県」這種四不像的結果。
第二，對臺灣使用者來說原文更自然。「横浜市」本來就讀得懂，「うるま市」也不至於造成理解障礙；而且看慣了日本的招牌、車站與地圖之後，看到「橫濱市」反而會有一瞬間的違和。既然原文可讀又符合習慣，翻譯就只剩下製造錯誤的風險。
所以日本的 handler（專案內負責單一地區資料處理的模組）直接沿用官方圖資 N03 欄位裡的日文原名，一個字都不改。這個決定同時省掉了整套翻譯流程要面對的所有問題。
日本的政令指定都市有額外處理：admin_2 只顯示市名（如「横浜市」），區名（如「中区」）放在中介 CSV 的 admin_3。郡轄町村則會判斷是否需要加郡名前綴，避免同名衝突。
南韓：縣市用官方漢字，一級行政區用慣用譯名#
南韓的圖資給的是韓文：관악구、청주시。但韓國的行政區名同樣以漢字構成，청주시 的官方漢字是「淸州市」、관악구 是「冠岳區」。這些漢字不是翻譯出來的結果，而是那個地名本來的寫法。
所以現在的做法分成兩層：
縣市層級取自韓文維基百科條目的漢字表記。 這一層有 200 多個行政區，逐一維護不現實，而漢字表記本身就是官方寫法，直接採用即可。Wikidata 在這裡只負責「認出這是哪一個實體」與驗證行政隸屬關係，名稱本身不從它身上取。
一級行政區走 handler 內建的對照表。 這一層只有 16 個，數量固定，寫死比查詢可靠，也避免結果在不同版本之間漂移。
比較值得說的是，對照表放的不是官方全稱，而是慣用的簡稱：
- 首爾特別市 → 首爾市
- 釜山廣域市 → 釜山市
- 世宗特別自治市 → 世宗市
- 全南光州統合特別市 → 全南光州市
那些行政類別的修飾詞在日常裡幾乎不會出現，放進相簿的地點欄位只會增加閱讀負擔。
道的部分也一樣，一律輸出「X道」，例如 경기도 就是京畿道。
統一成「X市」「X道」的好處是，16 個一級行政區在相簿的地點欄位裡呈現一致，不會一下子出現「特別自治道」、一下子出現「廣域市」。
這條規則也解釋了幾個看起來像沿用舊稱的輸出。강원특별자치도 去掉修飾詞得到江原道、제주특별자치도 得到濟州道，剛好與兩者改制前的名稱相同，那是巧合而不是刻意保留舊名。唯一需要額外處理的是 전북특별자치도：韓文本身用的是「全北」這個縮寫，機械套用規則會得到不成詞的「全北道」，所以對照表展開成完整的「全羅北道」。
之所以不直接採用 Wikidata 的中文標籤，是因為那層資料的品質相對還說不穩。實際遇過的情況包括：首爾 관악구 被輸出成區內的「新林洞」、송파구 變成區內的地鐵站「蠶室站」、함평군 的繁中標籤把「咸」轉成了「鹹」、여주시 的標籤停在升格前的舊名「驪州郡」。改以漢字表記為準之後，這幾類錯誤一次消除，也不需要為它們維護人工對照表。
這也是為什麼你在 Immich 裡會看到「淸州市」而不是「清州市」。那是韓國官方使用的漢字字形，不是錯字。
泰國與印尼：只能翻譯#
泰文與印尼文都不是漢字系統，นครราชสีมา 與 Kabupaten Ngawi 沒有「原本的漢字寫法」可以沿用。這兩國因此只能走翻譯路線，用 Wikidata 解析行政區實體後取繁體中文名稱。
既然是翻譯，就必須準備好翻不出來的情況。兩國的處理都是分層回退：
- 泰國：Wikidata 繁中 → COD-AB 官方英文 → 官方泰文。
- 印尼：Wikidata 繁中 → BIG 官方印尼文。
回退到原文看起來像是「失敗」，但它其實是刻意的選擇：顯示 Kabupaten Ngawi 至少是正確的地名，而硬湊一個來源不明的中文翻譯，反而會導致錯了也沒人看得出來。這個取捨會在下一篇：Wikidata 譯名的六種失效形態詳談。
其他地區：三層 fallback#
沒有專屬 handler 的地區，走的是全球通用流程：
- 國家教育研究院《外國地名譯名》：官方臺灣譯名，目前收錄六萬多筆，優先採用。
- GeoNames 的中文資料：國教院沒收錄時使用。
- 保留原文：兩者都沒有時，維持來源語言。
所以冷門地點在 Immich 裡仍然可能顯示英文。這是刻意的。與其硬翻，不如讓使用者看到一個至少可以拿去搜尋的原名。
同一個依據，五種結果#
回頭看，五個地區的差異其實都來自同一個問題：臺灣使用者看到什麼最自然：
- 臺灣、日本、南韓的地名以漢字書寫，讀者不需要翻譯就看得懂，因此直接採用官方寫法。差別只在於臺灣是中文、日韓是各自的官方漢字。
- 泰國、印尼的文字對臺灣讀者不具可讀性，因此翻譯，並準備好回退到官方原文。
- 其他地區沒有專屬圖資，只能靠譯名資料庫補，補不到就保留原文。
值得一提的是，這幾個決定沒有一個是「哪種做法比較正確」的問題，而是「哪種做法對使用這份資料的人比較好用」。
下一篇：用 Wikidata 翻地名，以及它如何安靜地出錯會進到這條路線最麻煩的部分：用 Wikidata 翻地名時，它出錯的方式往往不會讓流程中斷，而是安靜地產出一個看起來很合理的錯誤中文名。
參考資源#
- 支援地區與語言策略 - 專案 README 的對照表
- 各地區處理文件 - 臺灣、日本、南韓、泰國、印尼的完整處理邏輯
- 国土数値情報ダウンロードサービス - 日本行政区域資料
- admdongkor - 南韓行政洞界資料
- COD-AB Thailand - 泰國行政區邊界
- 印尼地理空間資訊局（BIG） - 印尼村級行政區圖資
- 國家教育研究院《外國地名譯名》 - 全球地名的官方臺灣譯名