聊聊前端國際化文案該如何處理

背景

最近接到一個海外項目業務需求，項目最終會被來自不一樣國家的客戶所使用，指望能讓客戶有一個良好的用戶體驗，所以前端須要適配國際化。

面臨的挑戰

乍一聽，這個海外項目需求並無什麼特別的地方，彷佛就多了一個國際化適配。但細細一想，事情可沒這麼簡單，前端開發面臨了不少新的問題。下面梳理一下國際化開發中一般會面臨的挑戰： 頁面文案所有可配置

• 須要配置的文案大體有四種：label、placeholder、字段校驗提示信息、超連接。

• 頁面文案樣式處理 文案樣式須要特別注意，不一樣語言的文字，可能會有不一樣的表現。例以下面兩張圖所示：

英語（頁面樣式正常)

俄語（頁面樣式異常）

• 日期、數字格式處理 頁面上展現日期或數量的地方，也是須要作國際化適配。
• LTR／RTL 不少中東國家的語言習慣都是 RTL，能夠嘗試使用 direction 和 transform 來解決。
• 圖片（banner）國際化 若是你想把國際化作的足夠精細，那麼圖片國際化也是須要考慮的。
• 第三方 UI 組件 若是使用了第三方 UI 組件，如：elementUI、ant design UI 等，這些 UI 框架一般都宣稱支持國際化，但支持的國際化語言數量有限，並不必定能知足業務需求。
• 前端開發工做量和後期維護成本激增 大量的文案須要被提取出來，被提取出來的文案最終會被合併到一個文件中去，如：en-US.json。這些工做若是經過手工完成，那麼工做量會是很是巨大的。

國際化文案的處理思路

以上列舉出了不少挑戰，但實際上「頁面文案處理」纔是最主要的矛盾，由於它直接致使前端開發工做量和維護成本的激增。下面咱們重點來討論文案處理思路，其實從實現國際化的角度來看，jQuery、Vue、React 等都只是載體而已，實現思路都是相通的，所以國際化文案處理與具體的技術框架並不耦合。接下來將會拋出幾種國際化文案處理思路，每種思路對生產力和生產關係的要求有高有低，姑且將其分別對應爲石器時期、青銅時期、黃金時期。

石器時期

傳統的國際化開發流程：前端開發到必定階段，將文案提取到資源文件（一般爲 en-US.json），而後將資源文件發送給翻譯團隊，翻譯團隊翻譯出各國語言版本的文案，每種語言對應一個資源文件，最後將這些資源文件發回給前端開發人員，前端開發人員更新到本身本地。以下圖所示：

• 適用場景

1.頁面上要提取的文案很少

2.支持的國際化語言較少，好比：只須要支持中文和英文

3.項目需求較固定，後期只作簡單維護，不會新增大的需求

4.分析 這是國際化開發的基本流程，「前端開發」和「翻譯團隊」是必不可少的兩個節點，但它們相互之間依賴的過重。「提取文案」的過程本質上是在重複勞動，所以能夠考慮由程序來完成。

5.代碼示例

6.App.js

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;
複製代碼

en-US.json

{
  "welcome": "Hello world!"
}
複製代碼

青銅時期

前面分析了「提取文案」的過程本質上是在重複勞動，那咱們看看有沒有辦法進行改進。咱們能夠先對比一下「無國際化需求」和「有國際化需求」時的前端開發流程。如圖所示：

能夠看出右邊多了三個過程：

• 將文案提取爲變量
• 爲變量命名，要合乎其場景
• 將變量和文案信息存到資源文件

這裏咱們提出一個指望或願景：但願能像開發普通業務同樣去開發有國際化需求的業務！

爲了達成這一願景，咱們須要有一個工具：它可以掃描指定的文件，並能識別出文件中的字符串，而後能根據字符串的含義生成變量名，並用變量表達式替換掉原來的字符串，最後可以將提取出來的變量自動追加到資源文件中。

如何實現這樣的工具？咱們能夠用 Babel 將js文件解析爲一顆語法樹，而後遍歷並找出字符串節點，接下來調用 Google Cloud Translation API 將字符串翻譯爲英文，並以此做爲變量名獲得變量表達式，最後用變量表達式替換掉原來的文本便可。以下圖所示：

幸運的是，i18n-pick 已經有那麼點味道了~

分析: 這是站在開發層面，對前端開發體驗和開發效率提出的改進辦法，將重複的事情交給程序去完成。

黃金時期

有了石器時期的生產方式做爲鋪墊，咱們能夠在此基礎上繼續作改進。既然「前端開發」和「翻譯團隊」之間依賴的過重，那咱們能夠在中間加一個節點「文案配置平臺」。前端將提取的文案直接上傳到「文案配置平臺」，翻譯團隊直接在「文案配置平臺」上進行文案翻譯，前端直接從「文案配置平臺」獲取翻譯後的最新文案。

• 文案配置平臺應當具有的基本能力

1.面向前端開發人員：文案錄入、輸出

2.面向翻譯團隊：文案翻譯、發佈

3.其餘：文案版本控制

4.適用場景

• 有大量的國際化業務需求
• 但願將其沉澱爲通用能力平臺，提高業務開發效率
• 分析

這是從架構層面對國際化開發方式進行優化和提效，通常大的互聯網公司由於其自身業務的複雜度，都早已沉澱出不少的通用能力平臺。

總結

以上每種思路都有各自適用的場景，實際生產中須要從開發成本、開發體驗、後期維護、能力沉澱等多維度進行考慮。這篇文章旨在拋磚引玉打開思路，各位看官能夠將本身的思路拋出來一塊兒討論。

轉載地址： www.yuque.com/es2049/blog…