一 顯示與傳輸分層
多語系切換不能改寫原始數據。原始溫度25.3°C，某些locale顯示25.3，另一些顯示25,3；wire應固定文化與數值欄位，不能讓小數逗號隨畫面語系進入協定。顯示locale、輸入locale與wire culture分開。
1,234是歧義輸入，在不同文化可能是一千二百三十四或1.234；文化不明時拒絕，不能猜。若允許locale輸入，要先知道欄位當下locale，再解析並保存語境。
formatter只能產生衍生顯示字串，資料庫仍保存25.3與單位°C。切換locale不應把顯示文字覆蓋canonical數值。
| 層次 | 案例 | 規則 |
|---|---|---|
| 原始 | 25.3°C | 固定保存 |
| 顯示en | 25.3 | 僅呈現 |
| 顯示de | 25,3 | 僅呈現 |
| wire | 固定schema | 不隨locale |
本文不假定任何HMI API或平台locale名稱；實際元件需核對小數位、千分位、負號與編輯事件。
數字格式還涉及負號、千分位、百分比與空值。若規格只允許小數點，不應因某個locale的formatter能顯示逗號就接受逗號輸入。wire schema應保存數值與單位，必要時另保存原始文字和語境。
同一顯示值25.3可能來自25.3°C，也可能是轉換後的°F衍生值；欄位標籤與unit metadata必須一起顯示，不能只換數字而保留舊單位。
格式化小數位與實際精度要分開。77.54顯示77.5不代表資料只有一位小數；若資料庫只保存77.5，回轉°C會產生誤差，因此應保存canonical原值或完整衍生值，再在最後一步格式化。
單位切換應在事件中記錄old_unit、new_unit、canonical_value與derived_display。這能分辨真正數值變化和單純呈現變化。
二 歧義與編輯語境
輸入25,3時locale=de可解析25.3°C並保存raw_text與input_locale；同字串在en則因逗號不在允許語法中拒絕。
輸入1,234且文化未定，畫面切locale後不能悄悄改成另一數值。應保留原文字與當時locale，要求確認或取消重輸。
| 狀態 | 文字/locale | 預期 |
|---|---|---|
| 已提交 | 25,3/de | 解析25.3 |
| 已提交 | 25,3/en | 拒絕 |
| 編輯中 | 1,234/未定 | 不猜 |
| 切換 | 25.3 en→de | 值不變 |
切換locale時未提交文字要保存輸入語境；若欄位未修改，才可用已解析數值重新格式化。錯誤訊息要說明文化格式不明確。
locale切換不應觸發未提交資料的自動送出。輸入中的25,3若尚未按確認，切換後可顯示待確認狀態；按取消則恢復切換前的原始文字或最後提交值。這能避免操作員不知道系統何時解析。
若輸入語境保存於事件記錄，至少包含raw_text、input_locale、input_unit、parsed_value、parse_status與提交時間。只存最後格式化字串，無法重現1,234當時如何判讀。
來源支持一般國際化格式概念；實際locale名稱、輸入元件與單位轉換能力仍需依目標版本文件核對。
對於正在編輯的輸入，locale切換後可提供確認按鈕；取消時恢復原文字，提交時才產生canonical數值。這是避免靜默轉換的操作契約。
°F顯示77.5是格式化結果，canonical 25.3°C仍是權威資料；若需求要保存顯示文字，應另存display_text與display_locale。
本篇提供格式與資料契約案例；實作時需核對平台的locale與單位功能。
驗收時要同時檢查數值、單位、原始文字、輸入locale、顯示locale與提交版本，缺一就難以重現歧義解析。
三 溫度offset與canonical單位
溫度不是單純倍率。25°C轉°F是25×9/5+32=77°F；25.3°C轉°F是77.54°F，顯示一位小數可為77.5，但原始25.3°C不能被覆蓋。
wire可固定°C與scale=0.1 raw253；選°F只產生衍生顯示。若使用者以°F輸入77.5，server須知道input_unit=°F，再轉回canonical°C；77.5°F約25.2778°C，不符合0.1°C步距，本例拒絕，除非另有明確捨入政策。
| 原始 | 公式 | 顯示 | 保存 |
|---|---|---|---|
| 25.3°C | C×9/5+32 | 77.54°F | 保留°C |
| 77°F | (F−32)×5/9 | 25°C | 記來源°F |
| 切換 | 不改公式 | 只改格式 | canonical不變 |
rounding只在最後顯示或明訂儲存邊界做；不要°C→°F→°C每一步round造成漂移。
溫度換算可用25.3°C→77.54°F驗證offset，並測0°C→32°F與-40°C→-40°F的交點。這些是數學案例，不代表任何HMI內建功能；平台若只支援顯示格式，轉換仍需由工程邏輯依規格完成。
反向輸入77.54°F若規格允許，應使用(F−32)×5/9得到25.3°C並保存input_unit=°F。若欄位只允許canonical°C，收到明標input_unit=°F的77.54應以單位不符拒絕，而不是猜使用者想輸入哪個單位。
顯示格式也要考慮負值，例如-2.5在使用逗號locale可呈現-2,5；負號規則不能被當成千分位或文字。解析與格式化須使用同一份locale政策。
驗收通過的條件是切換locale與unit後canonical資料不變，只有明確提交才產生轉換，歧義輸入永遠不在未定語境下自動成功。
對不同locale建立回歸測試向量，至少包括小數、千分位、負值、空值與切換中未提交內容，避免只測英文正常路徑。
所有locale回歸案例應保留raw與格式化結果，讓格式變更不會被誤認成數值變更。
格式化失敗也要保留原始資料，不能以零或空字串取代。
四 驗收與排查
固定canonical25.3°C，切換en顯示25.3、de顯示25,3、°F顯示77.5，再回°C仍為25.3。測1,234時，文化不明預期拒絕並保留原文字。
若編輯中切locale，應保存語境或取消重輸。若只在切語系後出錯，先查input_locale與unit是否隨提交保存，再查wire是否固定文化。
| 驗收 | 操作 | 預期 |
|---|---|---|
| locale | en→de | 25.3→25,3，值不變 |
| 單位 | °C→°F→°C | 25.3保留 |
| 歧義 | 1,234 | 拒絕/依明訂locale |
| 編輯 | 未提交切換 | 保存或重輸 |
語系、單位與元件支援需依目標平台文件確認。
驗收需故意在輸入後切換locale、切換unit、按取消、按提交，再讀回canonical資料。預期提交前切換不改資料，提交後只產生明確的canonical值與衍生顯示。若讀回值變成25,3字串，表示wire與display層混合。
1,234可在一個已知locale依規格解析，但測試仍要保存解析結果與locale。當使用者複製另一語系字串進入欄位時，應顯示需確認，而不是默默套用目前畫面語系。
若資料從外部CSV或報表貼入，先指定來源文化；文化不明的1,234、1.234應拒絕或要求使用者選擇，不要依目前畫面locale盲猜。
wire固定文化可採數值欄位或固定ASCII小數點文字，但兩端必須使用同一schema。畫面使用逗號不表示封包也應使用逗號。
保存輸入語境還包括時間與欄位版本。若使用者在locale切換前輸入25,3，稍後才提交，系統應依輸入時政策處理或要求重輸，不能只依提交時畫面猜測。
若報表需依不同語系輸出，從canonical數值重新格式化，不要把上一份locale的display_text再解析。這樣可避免25,3被錯當成wire資料，也能保留原始單位與版本。
五 FAQ與來源
若使用者從de畫面切到en，已提交25.3只改顯示；未提交25,3則必須保留語境，不能拿新locale重新解析後直接送出。
溫度單位的offset必須在單位轉換函式中明確列出，不能把°C與°F當作相同倍率。對0°C、-40°C等邊界測試可發現忘記加32或符號錯誤。
切換後的顯示值若需稽核，另記display_locale與display_precision，不改canonical數值或unit。
核心規則是wire固定文化、顯示依locale、原始與衍生分離；1,234文化不明時拒絕，溫度轉換含offset。
FAQ1：de顯示25,3，wire也送25,3嗎？答：不必，wire用固定schema。
FAQ2：1,234可自動猜1234嗎？答：不可，文化不明應拒絕。
FAQ3：25.3°C轉°F只乘1.8嗎？答：不可，還要加32。
FAQ4：切locale時未提交文字怎麼辦？答：保存語境要求確認，或取消重輸。
參考：Unicode LDML Part 3 Numbers：locale數字格式參考。
參考：W3C Internationalization Number Formats：多語系數字格式參考。