前兩篇把機制與流程講完了：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 在這裡只負責「認出這是哪一個實體」與驗證行政隸屬關係，名稱本身不從它身上取。
在字形處理上，專案全面改以韓國官方漢字表記為準。如同日本資料保留日式新字體（如「県」、「浜」），南韓也刻意保留韓國官方使用的康熙字典舊字形（如「淸州市」而非「清」、「尙州市」而非「尚」）。
同時，這套機制也清除了過去因為 Wikidata 繁中標籤品質不穩所造成的長期錯誤。
一級行政區走 handler 內建的對照表。 這一層固定為 16 個，寫死比查詢可靠，也避免結果在不同版本之間漂移。
這份對照表也直接跟進了南韓 2026-07-01 的最新行政區改制：全羅南道與光州廣域市合併設立「全南光州統合特別市」（一級行政區由 17 個減為 16 個）；仁川廣域市的中區、東區、西區重組為濟物浦區、永宗區、西海區與黔丹區。
比較值得說的是，對照表放的不是官方全稱，而是慣用的簡稱：
- 首爾特別市 → 首爾市
- 釜山廣域市 → 釜山市
- 世宗特別自治市 → 世宗市
- 全南光州統合特別市 → 全南光州市
那些行政類別的修飾詞在日常裡幾乎不會出現，放進相簿的地點欄位只會增加閱讀負擔。
道的部分也一樣，一律輸出「X道」，例如 경기도 就是京畿道。
統一成「X市」「X道」的好處是，16 個一級行政區在相簿的地點欄位裡呈現一致，不會一下子出現「特別自治道」、一下子出現「廣域市」。
這條規則也解釋了幾個看起來像沿用舊稱的輸出。강원특별자치도 去掉修飾詞得到江原道、제주특별자치도 得到濟州道，剛好與兩者改制前的名稱相同，那是巧合而不是刻意保留舊名。唯一需要額外處理的是 전북특별자치도：韓文本身用的是「全北」這個縮寫，機械套用規則會得到不成詞的「全北道」，所以對照表展開成完整的「全羅北道」。
泰國與印尼：只能翻譯，以及「City」層級的抉擇#
泰文與印尼文都不是漢字系統，นครราชสีมา（那空叻差是瑪）與 Kecamatan Ubud（烏布）沒有「原本的漢字寫法」可以沿用。這兩國因此只能走翻譯路線，用 Wikidata 解析行政區實體後取繁體中文名稱。
既然是翻譯，就必須準備好翻不出來的情況。兩國的處理都是分層回退：
- 泰國：Wikidata 繁中 → COD-AB 官方英文 → 官方泰文。
- 印尼：對照表繁中（NAER → Wikidata → OSM） → BIG 官方印尼文。
印尼的層級抉擇：為什麼是「郡」（Kecamatan）？#
在 Immich 的 國名・一級行政區・城市 三格介面下，印尼若對應到二級行政區（Kabupaten，縣），雖然中文名稱的覆蓋度較高，但其管轄範圍往往過大，會失去相簿定位的意，例如在知名景點烏布拍照，若只顯示「印尼・巴釐省・吉亞尼亞爾縣」（Gianyar），多數人根本無法從中辨識出照片在哪裡。
為了讓地點真正具備辨識度，專案選擇將印尼下切至更細緻的三級行政區 Kecamatan（郡）。然而下切面臨一項關鍵取捨：層級越細，權威中文譯名的覆蓋率必然急降。
專案的設計哲學是以「辨識度」為最高優先：
- 熱門景點與主要城區，透過官方譯名表與開放圖資補齊中文郡名。
- 未收錄中文的地區，則直接回退至官方印尼文原文（例如
印尼・巴釐省・Ubud）。
回退到原文看似妥協，實則是刻意的取捨：顯示 Ubud 原文不僅正確且一目瞭然；若為追求表面上的全中文化而硬湊品質不明的翻譯，反而會讓錯誤地名隱蔽難察。這個取捨會在下一篇：Wikidata 譯名的六種失效形態詳談。
馬來西亞的延伸：收斂雜亂層級至縣（Daerah）#
同樣的層級一致性原則也延伸到 LocationIQ 處理的地區。以馬來西亞為例： 若直接套用一般的逆地理查詢，常會將不同層級的地址屬性提拔為城市名，導致同一區域內混雜著建案名稱、英里樁或門牌。 專案將馬來西亞統一收斂至 daerah（縣） 層級，絕大多數地點均有對應的官方繁體中文縣名，徹底解決了層級跳躍與名稱破碎的問題。
其他地區：三層 fallback#
沒有專屬 handler 的地區，走的是全球通用流程：
- 國家教育研究院《外國地名譯名》：官方臺灣譯名，目前收錄六萬多筆，優先採用。
- GeoNames 的中文資料：國教院沒收錄時使用。
- 保留原文：兩者都沒有時，維持來源語言。
所以冷門地點在 Immich 裡仍然可能顯示英文。這是刻意的。與其硬翻，不如讓使用者看到一個至少可以拿去搜尋的原名。
同一個依據，五種結果#
回頭看，各個地區的差異其實都來自同一個問題：臺灣使用者看到什麼最自然：
- 臺灣、日本、南韓的地名以漢字書寫，讀者不需要翻譯就看得懂，因此直接採用官方寫法。差別只在於臺灣是中文、日韓是各自的官方漢字。
- 泰國、印尼的文字對臺灣讀者不具可讀性，因此翻譯，並準備好回退到官方原文。
- 其他地區沒有專屬圖資，只能靠譯名資料庫補，補不到就保留原文。
值得一提的是，這幾個決定沒有一個是「哪種做法比較正確」的問題，而是「哪種做法對使用這份資料的人比較好用」。
下一篇：用 Wikidata 翻地名，以及它如何安靜地出錯會進到這條路線最麻煩的部分：用 Wikidata 翻地名時，它出錯的方式往往不會讓流程中斷，而是安靜地產出一個看起來很合理的錯誤中文名。
參考資源#
- 支援地區與語言策略 - 專案 README 的對照表
- 各地區處理文件 - 臺灣、日本、南韓、泰國、印尼的完整處理邏輯
- 国土数値情報ダウンロードサービス - 日本行政区域資料
- admdongkor - 南韓行政洞界資料
- COD-AB Thailand - 泰國行政區邊界
- 印尼地理空間資訊局（BIG） - 印尼村級行政區圖資
- 國家教育研究院《外國地名譯名》 - 全球地名的官方臺灣譯名