前端多語系設計該注意的事項
慎用固定尺寸
並非全部固定尺寸都是不好的，在設計中需要理解，此物件的寬高是必要元素嗎？但在大多數情況下，都可以忽略實際設計上的高度。例如以下設計
深紫色的區塊實際上不寫入高度，高度應該隨內容決定，如果想要保持設計的還原度，使用 min-height or min-width 讓物件保持至少該有的樣貌。
可以參考某韓國網站，當我們換成別的語系，固定寬高的元素會馬上呈現內容移除或錯亂。
別將文字放在圖片上
第二種最常遇到的設計元素，就是帶有文字解釋的圖片，例如google 的 Android 開發 doc.
圖片中的文字非常難處理，除了它無法被辨識以外，還包含了其他設計元素（平面設計），就算要做一個一模一樣的圖，也並非直接把翻譯的字貼到圖上就好。而需要設計師重新排版，例如netlifx官網banner
在code大概可以是如下
import zhBanner from '...';
import enBanner from '...';const banner = {
zh: zhBanner,
en: enBanner
}<img src={banner[lang]} />
語法 & UI & 字體排序
即便我們處理以上兩個重點，雖然畫面沒有壞，我們還是有可能出現問題，就是翻譯無法完全顯示.
盡量簡化資訊更利於頁面的呈現，如果需要在畫面上實現「補充」文法的概念設計，可以改成以下的範例:
但必須承認，要做到每個語言都盡善盡美，那是不太可能的顧慮到全部語系的文法，那就把「文法」這個概念從設計中抽離，如上圖顯示的。
如果的翻譯是設計元素的一部分，typography vs CJK
CJK （Chinese–Japanese–Korean）和拉丁字母語系的差異較大，在多數形象網站設計中（英文），字體排版（typography）佔據相當重要的角色，例如以下設計。
如果那個文字排版是非常重要的設計元素 > 內容呈現，建議換成圖，但是這就和第二點說法有衝突，所以什麼情景要用什麼方式，需要視情況而定。
所以如果設計圖中含有特殊的文字排版，也務必考量進去，以免再語言轉換時導致設計變形。
也可以多利用 Web font 來完成設計，參考 google 的設計文章。
如果需要使用font-face，也要將文字檔案的尺寸考量進去，以免導致網速過慢時，無法顯示文字的窘境。
針對這個話題，網路上有很多相關的文章可以參考.
所以假設有一個多語系網站，要兼顧到字體的種類，這方面的優化必不可少。
格式
早在10年前，LUKE WROBLEWSKI 就在一篇關於地址格式的文章探討到這個話題，如今我們習以為常的地址設計欄位，在過去可不是那樣的。
我們從那篇文章中，可以感知到一件事，通用比客製化來的平易近人，針對某個國家或文化（事件）設計特有的規範，往往只會增加使用者的學習曲線，因為你無法統一全部和你做一樣事情的人，都用同一套（複雜）的流程。
但通用的流程是大家喜愛的，套用在各種情境也合適，流通性大，所以在設計網路表單、介面、流程的時候，要理解哪一些設計元素是「通用」，哪一些設計元素是「特定」
除了地址這類型沒有嚴格定義的範例以外，還有一些有標準定義的格式，例如
- 貨幣
- 時間/日期/相對時間（文字敘述，例如三天前）
- 數字
- 稱呼
方向
用中文或英文語系的網站，大部分習慣是上到下，左到右，但在其他國家或語系下，可能不是這樣子，這和我們有什麼關係呢？
有。
並非只是替換字串，就完成多語系，css寫錯，也可能導致很多不必要的髒修改。
在google的web dev網站中就提出很典型的例子，有興趣可以到官網把這篇好文想賭一番。
lang=
<html lang="zh">這個神奇的語法，會讓瀏覽器自動幫你完成許多事，例如斷行
.element { hyphens: none | manual | auto }
頁面加了lang，也會對搜尋引擎更加友善，讓機器人知道這也頁面的資訊是屬於什麼語系。
當然你可以還可以利用:lang 來控制
em:lang(zh) { text-weight: 700; }writing-mode
LTDR, 顧名思義，書寫方式，這裡就不針對這個項目細說，有興趣請查看：W3C 說明
其中有一個比較有可能會遇到的就是，中文/日文的直下排版方式。
辨識
翻譯檔的Key必須簡單易懂，直觀，避免過度細化 key。
// bad
general.users.savedata (更新）// good
general.update (更新）
key 必須是有辦法被聯想到的，例如：
// bad
doc.data.first // good
doc.description
model/domain base 命名，對應了 第一個的過度細化，會發現有很多翻譯其實都是重複的，例如。
// bad
doc.description.error（錯誤）
page.description.error（錯誤）// good
validation.error (錯誤）
過度描述，為了避免重複key，我們很常會採用「詳細」的key name去 避免這事情的發生，這反而出現了這種情況.
// bad
doc.form.section_1.block_1.title_with_login_member（稱呼）// good
login.title（稱呼）
namespace
在大部分i18n的工具中，都會有 namespace的概念，這樣可以大大減少翻譯檔案的大小，因為你可以針對特定的命名撈取翻譯資料，例如在 react.i18nex 中，也建議了採用的方式如下.
// not recommended with ns prefix when used in combination with natural language keys
i18next.t('common:look.deep');// better use the ns option
i18next.t('look.deep', { ns: 'common' })
參考資料
