聊聊前端国际化文案该如何处理

背景

最近接到一个海外项目业务需求，项目最终会被来自不一样国家的客户所使用，指望能让客户有一个良好的用户体验，所以前端须要适配国际化。

面临的挑战

乍一听，这个海外项目需求并无什么特别的地方，彷佛就多了一个国际化适配。但细细一想，事情可没这么简单，前端开发面临了不少新的问题。下面梳理一下国际化开发中一般会面临的挑战：

• 页面文案所有可配置
  须要配置的文案大体有四种：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. 项目需求较固定，后期只作简单维护，不会新增大的需求
• 分析

这是国际化开发的基本流程，“前端开发”和“翻译团队”是必不可少的两个节点，但它们相互之间依赖的过重。“提取文案”的过程本质上是在重复劳动，所以能够考虑由程序来完成。

• 代码示例

  • 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!"
  }

青铜时期

前面分析了“提取文案”的过程本质上是在重复劳动，那咱们看看有没有办法进行改进。咱们能够先对比一下“无国际化需求”和“有国际化需求”时的前端开发流程。如图所示：

能够看出右边多了三个过程：

1. 将文案提取为变量
2. 为变量命名，要合乎其场景
3. 将变量和文案信息存到资源文件

这里咱们提出一个指望或愿景：但愿能像开发普通业务同样去开发有国际化需求的业务！

为了达成这一愿景，咱们须要有一个工具：它可以扫描指定的文件，并能识别出文件中的字符串，而后能根据字符串的含义生成变量名，并用变量表达式替换掉原来的字符串，最后可以将提取出来的变量自动追加到资源文件中。

如何实现这样的工具？咱们能够用 Babel 将js文件解析为一颗语法树，而后遍历并找出字符串节点，接下来调用 Google Cloud Translation API 将字符串翻译为英文，并以此做为变量名获得变量表达式，最后用变量表达式替换掉原来的文本便可。以下图所示：

幸运的是，i18n-pick 已经有那么点味道了~

• 分析

这是站在开发层面，对前端开发体验和开发效率提出的改进办法，将重复的事情交给程序去完成。

黄金时期

有了石器时期的生产方式做为铺垫，咱们能够在此基础上继续作改进。既然“前端开发”和“翻译团队”之间依赖的过重，那咱们能够在中间加一个节点“文案配置平台”。前端将提取的文案直接上传到“文案配置平台”，翻译团队直接在“文案配置平台”上进行文案翻译，前端直接从“文案配置平台”获取翻译后的最新文案。

• 文案配置平台应当具有的基本能力

  1. 面向前端开发人员：文案录入、输出
  2. 面向翻译团队：文案翻译、发布
  3. 其余：文案版本控制

• 适用场景

  1. 有大量的国际化业务需求
  2. 但愿将其沉淀为通用能力平台，提高业务开发效率
• 分析

这是从架构层面对国际化开发方式进行优化和提效，通常大的互联网公司由于其自身业务的复杂度，都早已沉淀出不少的通用能力平台。

总结

以上每种思路都有各自适用的场景，实际生产中须要从开发成本、开发体验、后期维护、能力沉淀等多维度进行考虑。这篇文章旨在抛砖引玉打开思路，各位看官能够将本身的思路抛出来一块儿讨论。

参考

• Internationalization
• 国际化 - 通用 LTR/RTL 布局解决方案
• i18n-pick
• Babel 插件开发指南
• Google Cloud Translation API: Node.js Client

文章可随意转载，但请保留此 原文连接。

很是欢迎有激情的你加入 ES2049 Studio，简历请发送至 caijun.hcj(at)alibaba-inc.com 。