國家與語言的區別在口頭上人人都懂，但一落到欄位設計與測試計畫，兩者還是經常被當成同一個東西。最典型的症狀是拿語言當格式的開關：看到某種語言，就套用某個地方的規則。這種做法在多數情況下看起來沒事，卻會在特定組合上安靜地出錯。以下說明兩個維度為什麼必須分開，以及分開之後測試矩陣該怎麼抽樣。
國家與語言為什麼不能互相推導?
一種語言可以被多個地方當成官方語言使用，一個地方也可以同時有多種官方語言。兩個維度是交叉的，而不是一對一的對應關係。既然是交叉的，任何「看到 A 就推出 B」的規則都必然在某些組合上失效。
失效的後果通常不是介面文字錯了，而是資料被錯誤地驗證。文字錯了使用者還看得懂，資料被擋下來卻沒有任何人知道原因，只會收到「格式不符」這種無法行動的訊息。
還有一個容易忽略的層面：即使是同一個地方，不同族群、不同世代、不同產業也會有不同習慣。把語言與地區當成兩個各自內在一致的維度都已經不夠精確，更不用說把它們綁成一個。
在地化其實有三層
要讓討論變得可操作，建議把在地化拆成三層，因為這三層的變動節奏與負責單位完全不同，混在一起談就會互相牽制。
- 介面語言：按鈕、標籤、錯誤訊息用什麼文字呈現，通常由翻譯流程管理。
- 內容地區：預設顯示哪些地區的內容、排序與推薦怎麼決定，通常由產品決定。
- 資料格式：日期、數字、姓名順序、地址順序怎麼呈現與輸入，通常由資料與工程決定。
三層可以各不相同。使用者可能選擇用某一種介面語言，但實際所在地與資料格式屬於另一個地區；也可能內容地區與資料格式一致，介面語言卻是第三種。設計時若把三層硬綁成一個值，就等於剝奪了使用者混搭的權利。
拆開的另一個好處是可測試。三層各自有明確的輸入與輸出，就能各自設計樣本，而不是每次都要端到端跑一遍才敢說沒問題。
還有一個常見的混淆是回退值。當使用者沒有指定地區時，系統總得選一個預設值，而那個預設值往往是「介面語言所對應的某個地區」。這種做法很方便，卻讓一個純粹的技術選擇變成事實上的產品決策；比較穩健的方式是把預設值當成一個顯式設定，並在說明裡寫出它為何被選為預設。
語言標籤與地區碼的分工
語言標籤描述的是「這段文字用什麼語言」，地區碼描述的是「這筆資料的取值與格式按哪一套約定」。兩者的用途不同，因此不應該互相替代。
常見的錯誤是把語言標籤當成資料格式的開關。這樣做在單一語言對應單一地區時看不出問題，一旦出現一種語言對應多個地區，就會開始誤判。說同一種語言的使用者，可能分屬制度完全不同的地方。
第二個常見錯誤是只用語言標籤儲存使用者的地區資訊。等到要決定日期順序或數字格式時，才發現這個欄位根本不足以決定該用哪一套規則，於是只能猜。比較穩健的做法是兩個欄位都保留，並且清楚標明各自的用途。
按語言猜格式會踩哪些坑?
第一種坑是「語言對了、地區錯了」。某個使用者的介面語言與某個地區相同，但所在地屬於另一個制度，於是被套用了不適用的規則；這種錯誤在測試環境幾乎不會出現，因為測試資料通常是整齊的。
第二種坑是「同語言不同地區的格式差異被抹平」。因為只按語言分支，所有使用同一語言的地區都被當成一樣，於是某個地區特有的欄位直接消失，或反過來被要求填寫不存在的欄位。
第三種坑是內容長度。同一種語言在不同地區的習慣用詞長度差異很大，同一段文案在不同地區會撐壞按鈕寬度、表格欄寬與截斷邏輯。這一類問題只有真的用不同地區的長文本去測才會浮現。
第四種坑是回退順序。當某個地區的資料缺漏時，系統要回退到什麼？如果回退的依據是語言，就會取到不相符的規則；如果依據是地區，至少能保證格式一致，只是文字可能不是最理想的。
測試矩陣該怎麼抽樣
矩陣應該是兩個軸的正交抽樣，而不是「每種語言配一個地方」的一一配對。語言軸的樣本用來檢查文字呈現與長度，地區軸的樣本用來檢查格式與驗證，兩者的觀察重點不同。
| 抽樣方式 | 覆蓋什麼 | 風險 |
|---|---|---|
| 語言軸抽樣 | 文字長度、翻譯缺漏、截斷 | 測不到格式差異 |
| 地區軸抽樣 | 欄位組合、格式與驗證 | 測不到文字長度問題 |
| 兩軸交叉 | 兩者同時出現的情況 | 樣本數成長快，需要挑選 |
實務上不必做完整笛卡兒積，而是挑幾個「語言與地區不一致」的組合當重點樣本。這類組合才是真實世界最常見、也最容易被測試計畫遺漏的情況。
抽取時也可以刻意納入「同語言不同地區」與「同地區不同語言」兩種對照組。前者用來驗證地區軸真的有效，後者用來驗證語言軸真的有效；少了對照組，兩個軸各自的貢獻無法被區分。
抽樣之後還要把結果寫回矩陣本身。每一次執行都記錄這一輪用了哪些組合，以及哪些組合是刻意留到下輪的；這樣矩陣就不只是設計文件，而是一份能被檢視的進度紀錄。少了這一步，兩個月後沒有人說得出某一列上一次是什麼時候被執行過。
給開發者：讓格式跟著地區走而不是跟著語言走
這條原則能解決大部分與國家和語言相關的糾纏。具體做法包括：
- 格式相關的判斷一律讀地區碼，不要讀介面語言。
- 兩個欄位都保留，並在文件中寫明各自用途，避免被當成同義欄位而合併。
- 文字呈現與資料格式分開實作，讓它們可以各自替換。
- 為「語言與地區不一致」保留明確的處理路徑，而不是讓它落入預設分支。
- 測試資料要刻意包含不一致的組合，否則這條路徑永遠不會被執行。
文中的語言與地區組合、抽樣矩陣與在地化示例都是刻意構造的合成資料，不代表真實使用者的分布，也不對應任何真實系統的設定或使用者母體。語言相關的姓名與文本形態差異，可以對照依地區而異的姓名資料；而選擇欄位本身的測試重點，則見國家選擇欄位測試。
下一步
拿起你手上的測試矩陣，把每一列標上它想驗證的是語言軸還是地區軸。如果有一列同時想驗證兩件事，就把它拆成兩列，並另外補一列刻意的交叉樣本。之後可以回到國家與地區目錄確認各地區實際的欄位組合；若要把地區軸換成分組軸再檢查一遍，可以接著讀區域分組與市場分級。