最近接到一個海外項目業務需求,項目最終會被來自不一樣國家的客戶所使用,指望能讓客戶有一個良好的用戶體驗,所以前端須要適配國際化。css
乍一聽,這個海外項目需求並無什麼特別的地方,彷佛就多了一個國際化適配。但細細一想,事情可沒這麼簡單,前端開發面臨了不少新的問題。下面梳理一下國際化開發中一般會面臨的挑戰:前端
文案樣式須要特別注意,不一樣語言的文字,可能會有不一樣的表現。例以下面兩張圖所示:node
頁面上展現日期或數量的地方,也是須要作國際化適配。react
不少中東國家的語言習慣都是 RTL,能夠嘗試使用 direction 和 transform 來解決。git
若是你想把國際化作的足夠精細,那麼圖片國際化也是須要考慮的。github
若是使用了第三方 UI 組件,如:elementUI、ant design UI 等,這些 UI 框架一般都宣稱支持國際化,但支持的國際化語言數量有限,並不必定能知足業務需求。web
大量的文案須要被提取出來,被提取出來的文案最終會被合併到一個文件中去,如:en-US.json。這些工做若是經過手工完成,那麼工做量會是很是巨大的。json
以上列舉出了不少挑戰,但實際上「頁面文案處理」纔是最主要的矛盾,由於它直接致使前端開發工做量和維護成本的激增。下面咱們重點來討論文案處理思路,其實從實現國際化的角度來看,jQuery、Vue、React 等都只是載體而已,實現思路都是相通的,所以國際化文案處理與具體的技術框架並不耦合。接下來將會拋出幾種國際化文案處理思路,每種思路對生產力和生產關係的要求有高有低,姑且將其分別對應爲石器時期、青銅時期、黃金時期。api
傳統的國際化開發流程:前端開發到必定階段,將文案提取到資源文件(一般爲 en-US.json),而後將資源文件發送給翻譯團隊,翻譯團隊翻譯出各國語言版本的文案,每種語言對應一個資源文件,最後將這些資源文件發回給前端開發人員,前端開發人員更新到本身本地。以下圖所示:babel
適用場景
這是國際化開發的基本流程,「前端開發」和「翻譯團隊」是必不可少的兩個節點,但它們相互之間依賴的過重。「提取文案」的過程本質上是在重複勞動,所以能夠考慮由程序來完成。
代碼示例
import React, { Component } from 'react'; import { IntlProvider, FormattedMessage } from 'react-intl'; import qs from 'querystring'; import logo from './logo.svg'; import './App.css'; import DEFAULT_MESSAGES from './i18n/en-US.json'; const DEFAULT_LOCALE = 'en-US'; class App extends Component { state = { messages: DEFAULT_MESSAGES, }; componentWillMount() { const search = window.location.search.slice(1); const params = qs.parse(search); const locale = params.locale || DEFAULT_LOCALE; const messages = require(`./i18n/${locale}.json`); debugger; this.setState({ messages, }); } render() { const { messages } = this.state; return ( <IntlProvider locale="en" messages={messages}> <div className="App"> <header className="App-header"> <img src={logo} className="App-logo" alt="logo" /> <p> <FormattedMessage id="welcome" defaultMessage={`Hello world!`} /> </p> <a className="App-link" href="/?locale=zh-CN" rel="noopener noreferrer" > zh-CN </a> <a className="App-link" href="/?locale=en-US" rel="noopener noreferrer" > en-US </a> </header> </div> </IntlProvider> ); } } export default App;
{ "welcome": "Hello world!" }
前面分析了「提取文案」的過程本質上是在重複勞動,那咱們看看有沒有辦法進行改進。咱們能夠先對比一下「無國際化需求」和「有國際化需求」時的前端開發流程。如圖所示:
能夠看出右邊多了三個過程:
這裏咱們提出一個指望或願景:但願能像開發普通業務同樣去開發有國際化需求的業務!
爲了達成這一願景,咱們須要有一個工具:它可以掃描指定的文件,並能識別出文件中的字符串,而後能根據字符串的含義生成變量名,並用變量表達式替換掉原來的字符串,最後可以將提取出來的變量自動追加到資源文件中。
如何實現這樣的工具?咱們能夠用 Babel 將js文件解析爲一顆語法樹,而後遍歷並找出字符串節點,接下來調用 Google Cloud Translation API 將字符串翻譯爲英文,並以此做爲變量名獲得變量表達式,最後用變量表達式替換掉原來的文本便可。以下圖所示:
幸運的是,i18n-pick 已經有那麼點味道了~
這是站在開發層面,對前端開發體驗和開發效率提出的改進辦法,將重複的事情交給程序去完成。
有了石器時期的生產方式做爲鋪墊,咱們能夠在此基礎上繼續作改進。既然「前端開發」和「翻譯團隊」之間依賴的過重,那咱們能夠在中間加一個節點「文案配置平臺」。前端將提取的文案直接上傳到「文案配置平臺」,翻譯團隊直接在「文案配置平臺」上進行文案翻譯,前端直接從「文案配置平臺」獲取翻譯後的最新文案。
文案配置平臺應當具有的基本能力
適用場景
這是從架構層面對國際化開發方式進行優化和提效,通常大的互聯網公司由於其自身業務的複雜度,都早已沉澱出不少的通用能力平臺。
以上每種思路都有各自適用的場景,實際生產中須要從開發成本、開發體驗、後期維護、能力沉澱等多維度進行考慮。這篇文章旨在拋磚引玉打開思路,各位看官能夠將本身的思路拋出來一塊兒討論。
文章可隨意轉載,但請保留此 原文連接。很是歡迎有激情的你加入 ES2049 Studio,簡歷請發送至 caijun.hcj(at)alibaba-inc.com 。