主流的MVVM框架中如何做國際化？

01-08

在開發階段時趕進度圖方便，沒有考慮國際化，都是直接使用的中文。
現在開始做國際化，在對獨立組件（Single file component）進行國際化的時候還是挺頭疼的。
如果採用傳統方式，在客戶端定義國際化資源，雖然可行單不夠好。

給這麼多中文起個key名就夠麻煩了

一個個替換那是真累

我目前的能想到的方案就：
對最終轉換為js的文件（各種組件、模板）做預處理，不過不知道會不會有什麼難以逾越的坑。
還有就是感覺是野路子，不通用。
那麼現在主流的MVVM框架是如何做國際化的呢？

如果限制在MVVM框架這個範圍的話，這個還是比較好辦的，主要有這麼幾種情形：

混雜在HTML中的文字，主要是靜態文本，比如標題，描述文字，表單的label等等，這些是一類東西，需要提取成key，然後編寫到資源文件中，然後在HTML模板中把文本替換成這些key的佔位符，在版本發布的時候通過預處理，生成不同語言的多份模板。
提示性的文字，可以通過js對象綁定到界面上（下拉框裡面的：「請選擇」），或者被調用出來（主要是一些提示）。這個可以不用做預處理，而是把資源文字放在單獨js中，不同語言各搞一份，然後根據語言去動態獲取。
如果要對js做打包，也可以把存放資源文本的js合併進去，這樣就要生成多份js了，切換的時候不再是只重新載入資源js，而是所有都重新載入。
圖標、對齊方式之類的國際化，主要靠樣式，比如阿拉伯文
控制項的國際化，主要都是換模板，邏輯還是一致的，所以跟1比較像，但也有特例，這個最典型的是日曆，很多日曆連邏輯都是不一樣的，比如波斯日曆，尼泊爾日曆，只換模板是不可能了，所以控制項這裡可能要做個工廠方法，根據不同的語言，載入對應的日曆模板和js，這個不必構建，動態載入應該可以接受。

國際化這個事情，盡量不要放在服務端做，那會佔用運行時資源，這應該是構建階段的事情，只有很少一部分的東西可能需要在服務端做，比如數據的國際化方案。

給文字起key名是沒法避免的，用什麼方案都很麻煩。

國際化 i18n 的解決方案一般正確的做法都是把靜態文本按照一個個key對應放在資源文件裡面，然後讓後台根據需要去切換返回。

前台很多插件也提供類似功能比如jQuery.i18n.properties.

當然你也可以用笨笨的做法，目前我給一個小網站提供繁體和英文切換，用普通的國際化方案去處理覺得小題大做，畢竟沒幾個頁面。也不太想把頁面複製兩份分別維護。於是自己想了一個很低能的方式：

所有的靜態文案都這樣寫

然後載入的時候會調用一個js，判斷html的 lang屬性，如果是en就把data-en填充到標籤裡面，否則就填充中文。

當然這樣做會有局限性，比如需要處理title,alt,placeholder,這些屬性。

所以需要在替換的時候判斷標籤，然後根據標籤來判斷替換位置是標籤內容還是標籤的一些特殊屬性。

非同步載入的內容後需要調用一次來處理載入內容中的語言。當熱我這個也屬於野路子。真確的最好的還是給服務端來處理吧。

偶湊熱鬧的

按中文起key名兒又不是不行

不想一個個替換就寫個腳本掃下所有代碼文件替好了……

起什麼 key 啊，直接寫英文版的文字。可以參考 WordPress 那種基於 gettext 的處理。

不管是不是mvvm框架，起key名都得一個一個來。

我原來的經驗是做一套替換的自動化讓運營來填寫要改的東西。

然後我再在前端改改那些錯亂了的頁面。

簡單說下我們團隊目前的方案，前端是基於 Backbone + Chaplin 的。

其實原理和樓上所述一致，都是將需要翻譯的內容提取出來作為 key，只是我們將這一步自動化了。

1. 在前端模版或者 View 中直接編寫界面顯示的語言，通過 t 關鍵字提取，整成 po 文件。

2. 將 po 交由翻譯人員翻譯，之後編譯成 js 文件。

3. t 同時也是翻譯函數，會自動根據選擇的語言，或者瀏覽器定義的語言將翻譯後的內容顯示出來。

前端框架 kiwi 是開源的，歡迎來看 open-node/kiwi · GitHub

============================

前端翻譯的難點在於後端錯誤的翻譯不是很好辦，而我們通過將錯誤類型標準化解決了這一點，能夠做到精確到欄位的錯誤提示。

後端框架，也是開源的 https://github.com/open-node/open-rest

最近我也在研究這個，怎麼沒得人說get text 呢

如果是XAML的話，你可以在Visual Studio裡面要求控制項的文字都寫資源里，然後就像往常一樣開發，記得彈message box啊、顯示數字和金錢符號什麼的調用正確的函數獲取字元串，不要自繪，不要假設游標一定是從左向右（阿拉伯文字從右向左，東南亞文字是跳的），剩下的都不用擔心。

webpack i18n plugin should help.

https://github.com/webpack/i18n-webpack-plugin

默認是英文，可直接用英文的作為中文索引的鍵

kazupon/vue-i18n · GitHub Vue 的，可參考

贊同李曉凱的回答，什麼 vue-i18n 簡直不能忍。。。

強烈推薦通用的靜態資源國際化方案：https://github.com/kenberkeley/i18n-static

我來談談一種思路：

首先還是得用key-value 的形式存儲不同版本的翻譯,具體可以參考jquery i18n的做法。但是jquery i8n是在線上做的翻譯工作，效率不高。所以建議在發布前在本地編譯出不同語言版本的頁面，並做樣式適配，因為不同語言會影響排版的。然後伺服器根據客服端語言返回不同版本的頁面。當然頁面還得保留語言切換按鈕，用於容錯。

其實不同語言版本對應的文化人群不同，給不同的人群都展示相同的樣式設計，不是最好的體驗。

我是用 vuex，初始化 vue 實例的時候把對應的語言載入 store 中，中英文都是用一樣的 key，開發的時候所有要做 i18n 的文字用 vuex 存著，模板直接用 store 里的就好了。

回頭寫個插件把，vue-i18n 看了一下還是比較麻煩的。。。

有語境問題的，單複數、相對日期用 FormatJS 來生成
文案級別的翻譯，開發階段定義 key，defaultMessage 寫中文保持可讀性，通過類 babel 的 loader 掃描出所有的 defaultMessage 和 key，在用自動化工具批量翻譯
組件的翻譯一般是組件自己完成，和外部業務代碼保持語言名一致
message 看你喜好，後端返回 key 前端翻譯或者直接打包在前端都可以
l10n 本來就是個臟活累活..

其實國際化都是英文化，什麼世界上排版都要變化的語言多了去了。阿拉伯世界還好不是互聯網主流。

最終還是資源替換，一個個換麻煩？寫個腳本把js和模版parse一遍，找出所有string，都替換成i18n的api，生成一個配置文件json，key用自動生成或者拼音加哈夫曼編碼生成。交給專業的人去翻譯，之後需要加新語言都很容易。

管是mvvm還是mvx，js渲染的都可以搞。我就這麼搞過，減少人工工作重複工作不就是程序員的工作么

寫了個node工具，構建時智能將中文替換為英文，缺點是怎麼都得先有個中文版……

1、內部集中的的一些文字，應該在編譯階段去處理，編譯成多個語言版本。

2、重UI部分，做成皮膚。載入時候去讀。