多語系網站不是換翻譯字典：從中英文字體度量幾何（Font Metrics），解密排版崩塌與語系感知排版架構

前言：週四下午的跨國品牌電商重構現場

前幾天我們在為一個高階戶外裝備品牌的跨國電商重構獨立站前端。這個品牌的歐美官網視覺極具張力，設計師為了營造純粹、堅固且極具工業精準感的視覺風格，Hero 區塊的大標題選用了窄體無襯線字體 Barlow Condensed，全大寫字母，搭配 font-size: 72px 與 line-height: 0.94。

在英文環境下，這種小於 1 的緊繃行高表現堪稱完美。單詞上下排列緊湊，像是一整塊由航太金屬洗削出來的工藝銘牌，完全沒有多餘的留白鬆散感。

問題出在品牌準備拓展亞洲市場，當我們在後台串上多語系翻譯，把語系切換到繁體中文（系統預設調用蘋方 PingFang TC 或思源黑體）的瞬間，整個首頁首屏直接陷入災難。

原本緊湊俐落的標題，在中文狀態下，上一行的「越」字底部的走之旁，直接插進了下一行「野」字頂部的日字頭裡。筆劃在垂直方向完全重疊黏死，墨跡糊成一團。更致命的是，中文字串長度與英文單詞的折行邏輯不同，最後一個字被孤零零擠到了第三行，形成所謂的「孤字掉行（Widow）」，下方原本對齊的 CTA 按鈕直接被推擠出可視區域。

行銷主管在通話裡納悶地問：「翻譯外掛不是都跑完了嗎？字型也都有抓到，為什麼中文排版看起來像十年前山寨網站？」

問題的核心不在於翻譯文字本身，真正的根源在於團隊把本地化當作純字串替換（String Substitution），忽略了中英文在字體度量幾何（Font Metrics）上存在不可逆的物理維度落差。

一、物理底層：為什麼同一個 line-height，在中文會撞成一團？

要理解為什麼 line-height: 0.94 在英文能成立、在中文會撞車，我們必須把瀏覽器渲染文字的幾何模型放大來看。

在網頁排版中，字體並不是憑空漂浮在矩形盒子裡的，西文與漢字遵循著完全不同的幾何基準系統：

1. 歐文的四線三格基線系統（Baseline System）

西文字體是建立在手寫拉丁字母的傳統之上。一個標準的西文字體度量包含四條水平基準線：

基線（Baseline）：所有字母坐落的基礎地平線，就像小學英語作業簿上的第三條線。
主線（X-Height）：小寫字母 x 的頂部高度。
大寫線（Cap Height）：大寫字母如 H、E、R 的頂部高度，通常低於上升部。
上升線與下降線（Ascender & Descender）：字母 d、b 向上延伸的天花板，以及 g、y、p 往下垂掛的底部界限。

當設計師在歐文大標題全部使用「全大寫（ALL CAPS）」時，所有字符的高度都被嚴格限制在 Baseline 與 Cap Height 之間。字母根本不會動用到 Descender（下方留白區）與 Ascender（上方頂部空間）。

換句話說，西文大寫字體在 Em-box（字身框）內部，天生就自帶了超過 30% 的內建安全緩衝區。即便你在 CSS 將 line-height 強制設定為 0.94 甚至是 0.9，文字上下依然保留了足夠的視覺呼吸縫隙，不至於發生幾何筆劃碰撞。

2. 漢字的方塊字身格（Grid Em-box System）

漢字完全是另一回事。漢字源於雕版與活字印刷，每一個字都是獨立且實心的正方形方塊。

在字體設計規範中，漢字沒有基線、沒有 X-Height、更沒有上下延展的字尾。中文字體設計師在繪製每一個字時，是將筆劃均勻佈局在整個 Em-box 之中，並且透過嚴格的「第二中心線」維持重心穩定。

這就帶來了兩者在度量幾何上的核心物理差異：字面率（Face Ratio）。

| 度量維度 | 歐文無襯線（如 Barlow / Inter） | 繁體中文黑體（如 PingFang / 思源黑體） | 跨語系排版衝擊 |
|---|---|---|---|
| 基準對齊系統 | 四線系統（依賴 Baseline 基線） | 矩形網格（依賴 Em-box 與中線） | 混排時基線易錯位，文字上下沉浮 |
| 平均字面率 | 65% 至 70%（大寫字母） | 90% 至 95%（頂天立地） | 相同字級下，中文視覺體積顯著膨脹 |
| 極限行高容忍度 | 0.90 至 1.05（緊繃侵略感） | 1.15 至 1.25（低於 1.1 即筆劃重疊） | 沿用歐文行高會直接導致中文字筆劃黏死 |
| 單詞邊界與斷行 | 依賴 Space 空格作為斷詞邊界 | 無空格連續漢字（字字皆可獨立成節點） | 斷行失控，容器邊緣極易產生孤字 |

二、Hero 大標中英文字高光學等高（Optical Height Equalization）

1. 為什麼會產生「字高視覺不一樣」的違和感？（字體度量幾何差異）

在實際案例（如大標題中英文混排）中量測，兩者存在顯著的物理與視覺落差：

西文大寫字高（Cap-Height）：標題第二行英文品牌詞採用窄體 Barlow Condensed，其大寫字母（如 C, R, A, G, Y）的字高僅佔 Em-box 的 約 70%（畫面上實際呈現約 55px）。
漢字字面率（Face Ratio）：第一行的動詞「加入」採用系統繁體中文字型（如蘋方 PingFang TC），中文字為實心方塊字格，字面率高達 88%–90%（畫面上實際呈現約 70px）。
視覺失衡結論：在相同 font-size 下，「加入」在畫面上比第二行英文大寫物理高出整整 27%（70px vs 55px）。且因中文字型筆畫較寬扎實，像是一方巨大笨重的印章壓在細長緊湊的英文品牌字上方，形成強烈的視覺失衡。

2. 解決方案：Liquid 語義換行切分 + 0.80em 光學校正

為了在不破壞英文字體原本完美度量比例的前提下達到兩者平衡，我們採用動態結構切分與光學係數校正：

Liquid 結構升級：在主題 Hero 模板（如 hero-banner.liquid）中自動將多行標題拆解為 .hero__title-line--1 與 .hero__title-line--2，並透過大小寫比對（CJK 無大小寫特性）動態注入 .hero__title--cjk-opt 標記。
CSS 光學校正代碼實作：

.hero__title--cjk-opt .hero__title-line--1,
:lang(zh) .hero__title-line--1,
html[lang*="zh"] .hero__title-line--1 {
  display: inline-block;
  font-size: 0.80em;      /* 70px * 0.80 = 56px，與英文大寫 55px 視覺字高 1:1 精確等高 */
  letter-spacing: 0.08em; /* 釋放中文字距呼吸感，與下方的長條英文寬度配比平衡 */
  line-height: 1.15;
  margin-bottom: 2px;
}
.hero__title-line--2 {
  display: inline-block;
  line-height: 1.02;
}

3. 光學校正前後的實際視覺效果

1:1 視覺等高達成：「加入」的視覺字高降為約 56px，與下方英文大寫字高（約 55px）達成 1:1 視覺等高。
字距舒展與層次平衡：0.08em 的字距讓「加入」兩字張力展開，不再孤零零緊縮，與下方英文形成和諧且極具工業設計質感的標題主副階層。
零副作用零污染：純英文標題（如 JOIN THE<br>ADVENTURE CLUB）則自動維持 1.0em，不產生任何副作用。

三、純換文案必然摧毀設計系統的連鎖反應

許多團隊在做多語系時，往往是把英文字串丟進翻譯系統，再把產出的 JSON 字典丟回前端渲染。這種純文字替換的思維，會在真實頁面上引發一連串連鎖破版：

1. 按鈕組件與膠囊標籤爆版（Button Wrapping）

在英文介面中，設計師習慣為按鈕設定精簡的高度與內距，例如 padding: 12px 24px; height: 48px;。英文文案如「GET STARTED」或「VIEW SPECS」能夠漂亮置中。

但是切換成德文時，單詞往往會變成超長的複合名詞（例如「SPEZIFIKATIONEN」）；切換成中文時，雖然字數變短，但文字的字重厚度與垂直高度完全不同。如果按鈕內部容器使用了 white-space: nowrap，按鈕會直接被字體撐破父層容器；若未鎖定，文字在行動端寬度不足時直接折成兩行，按鈕高度瞬間膨脹成兩倍，徹底摧毀網格卡片的垂直對齊。

2. 語意斷行節奏破碎（Cadence & Widow）

西文排版依賴空格進行斷詞，瀏覽器預設不會在單詞內部任意折行。但漢字是表意方塊字，如果沒有額外配置樣式，瀏覽器的預設行為是「到達容器邊界就強制折行」。

這會導致慘不忍睹的閱讀體驗：一個四字成語或產品專有名詞，前三個字在第一行，最後一個字孤零零掉到第二行開頭。這種「孤字寡行」不僅極度破壞視覺重心的穩定度，也嚴重干擾訪客的資訊獲取節奏。

3. 多欄等高卡片的骨牌效應（Equal-Height Card Collapse）

在三欄或四欄的產品特性網格中，每一張卡片通常包含標籤、大標題、兩行描述文案與一個價格按鈕。在英文狀態下，文案行數被精確控制在兩行。

然而，當多語系字典載入後，法文或西班牙文字數比英文膨脹 20% 到 30%，中文雖然字數縮減但垂直佔位更厚。只要其中一張卡片的標題多折了一行，該列卡片的高度就被硬生生拉長。如果前端沒有做好彈性格點或語系感知約束，頁面水平基線就會全數錯位，排版層次瞬間瓦解。

四、現代前端架構解法：建立語系感知排版階層（Locale-Aware Architecture）

面對字體度量幾何的先天物理落差，最糟糕的妥協方式是折衷折讓：為了遷就中文，把全站英文大標題的行高硬調大到 1.2，或者把中文全域字級強行縮小。這只會讓兩種語言都失去各自的美感與張力。

在專業的網站架構中，標準做法是建立語系感知排版架構（Locale-Aware Typography Architecture）。透過 CSS 自定義屬性（CSS Custom Properties）與 HTML 語系選擇器，讓設計系統能夠根據當前 DOM 的 lang 屬性，動態切換底層字體度量參數。

1. CSS 變數抽離與語系感知覆蓋

不要在組件中寫死具體的 font-size 與 line-height。將文字度量抽象為語意化變數，並在語系根節點進行動態重載：

/* 預設歐文語系度量階層 (en) */
:root {
  --font-family-display: "Barlow Condensed", sans-serif;
  --font-family-body: "Inter", sans-serif;
  
  --lh-display: 0.94;
  --lh-heading: 1.05;
  --lh-body: 1.5;
  
  --ls-display: 0.02em;
  --ls-heading: 0.01em;
  --ls-body: 0em;
}

/* 繁體中文語系感知動態調整 (zh-TW, zh-Hant, zh) */
:root:lang(zh),
[lang^="zh"] {
  --font-family-display: "Barlow Condensed", "PingFang TC", "Noto Sans TC", sans-serif;
  --font-family-body: "PingFang TC", "Noto Sans TC", "Microsoft JhengHei", sans-serif;
  
  /* 解除中文垂直碰撞的安全行高 */
  --lh-display: 1.18;
  --lh-heading: 1.25;
  --lh-body: 1.7;
  
  /* 漢字字面率大，微調字距補償視覺密度 */
  --ls-display: 0.04em;
  --ls-heading: 0.02em;
  --ls-body: 0.01em;
}

這樣一來，所有 UI 組件只需引用 line-height: var(--lh-display);。當訪客在 Shopify 或 Webflow 前台切換語言，HTML 標籤的 lang="zh-TW" 會自動觸發 CSS 變數熱替換，英文維持極具張力的 0.94 緊湊節奏，中文則自動釋放至 1.18 的安全留白，兩者各自維持頂級工藝質感，互不干擾。

2. 語意斷行控制與避頭尾法則（Text Wrap & Balance）

為了解決漢字在窄寬度容器中的斷行破碎問題，現代瀏覽器提供了原生排版屬性支援：

.hero_title,
.card_heading {
  /* 防止多語系標題產生單字孤行 */
  text-wrap: balance;
}

.body_text {
  /* 確保長文章段落結尾留白均衡 */
  text-wrap: pretty;
  /* 支援漢字適當依語意連字折行 */
  word-break: break-word;
}

對於關鍵的標題文案，善用 text-wrap: balance 可以讓瀏覽器自動平衡每行的字數長度，有效消除「最後一個字掉到下一行」的尷尬局面。

3. 組件容器的彈性防禦約束（Defensive UI Constraints）

在設計系統的組件層級，必須為文字溢出設立防禦機制：

拒絕硬寫固定高度：對於卡片、按鈕或導航列項目，避免使用 height: 48px，改用 min-height: 48px 搭配 Flexbox 的垂直置中對齊，允許文字在極端語言下安全換行。
多行截斷與提示機制：在嚴格受限的後台列表或產品預覽卡片中，使用 -webkit-line-clamp 鎖定最大行數，並配合 overflow: hidden 防止組件撐爆破版。

五、結語：給多語系出海團隊的架構共識

在跨國數位體驗的建置過程中，翻譯只是最淺層的文案轉換。真正的國際化架構，考驗的是團隊對文字排版背後的幾何度量、文化閱讀習慣與前端容錯邊界的深層理解。

當你的網站能夠在切換到任何一種語言時，依然保持堅固如磐石的排版節奏與視覺層次，你的品牌才能在國際舞台上真正傳遞出頂級的專業感與工藝價值。

Tagged in

Web Development

E-commerce