App出海：關(guān)于國際化多語言那些事

越來越多的App開始出海，隨之而來必然會(huì)遇到的一個(gè)問題就是多語言。有的同學(xué)會(huì)說了，多語言，那不是很簡單嗎?

確實(shí)，要在App中支持多語言非常簡單，是個(gè)研發(fā)就會(huì)做。不過當(dāng)你的App支持的語言越來越多時(shí)，你就會(huì)發(fā)現(xiàn)，支持多語言這個(gè)事情變得非常麻煩。

原始階段

多語言對于出海雖然必不可少，但在公司剛開始出海時(shí)，大概率是沒有什么精力花費(fèi)在怎么去優(yōu)化多語言開發(fā)的流程的。畢竟這個(gè)事情看起來很簡單，假設(shè)我們只多支持一種語言的話，這個(gè)麻煩的上升程度也有限。

此時(shí)的整個(gè)工作流程大概如下：

1. 產(chǎn)品從需求中提取文案給到翻譯

2. 翻譯們翻譯完成之后給回產(chǎn)品

3. 產(chǎn)品通知研發(fā)們進(jìn)行文案替換

4. 研發(fā)手動(dòng)替換文案

5. 后期文案回歸（測試or翻譯進(jìn)行校對）

有些公司則是研發(fā)和翻譯直接對接（2,3步驟）。整個(gè)過程看起來似乎還好，但中間的幾個(gè)步驟對于人力的消耗并不小。

1. 前三步驟當(dāng)中，產(chǎn)品或研發(fā)需要一直去跟進(jìn)翻譯進(jìn)度。

2. 由于沒有地方統(tǒng)一記錄這些翻譯文案，會(huì)導(dǎo)致一些文案重復(fù)翻譯，浪費(fèi)人力。

3. 第四步當(dāng)中，由研發(fā)手動(dòng)替換文案費(fèi)時(shí)費(fèi)力，容易出錯(cuò)。當(dāng)支持的語言變多時(shí)，這個(gè)工作量和出錯(cuò)的概率也會(huì)隨之上升。

4. 由于手動(dòng)替換的不可靠性，后續(xù)也需要人力去進(jìn)一步校對文案的正確與否。

5. 當(dāng)線上文案需要替換時(shí)，需要重復(fù)該流程。

這些小問題就像鞋子里的一顆細(xì)沙，雖不至于直接讓你無法前行，但卻會(huì)影響你能走多遠(yuǎn)，走多快。

自動(dòng)化&平臺(tái)化

知道了問題的所在，我們就可以開始著手去設(shè)計(jì)解決方案。

首先, 我們先對問題進(jìn)行一下分類，發(fā)現(xiàn)可以歸為兩大類，一是流程性問題，二是重復(fù)性工作問題。

對于重復(fù)性工作，我們可以通過自動(dòng)化手段來解決:

首先很容易就可以想到并實(shí)施的一個(gè)點(diǎn)是通過腳本等自動(dòng)化工具自動(dòng)進(jìn)行文案的替換，這樣就可以節(jié)省研發(fā)手動(dòng)復(fù)制粘貼的時(shí)間。

同時(shí)通過工具替換文案大大提高了可靠性，后續(xù)的校驗(yàn)可以簡單地只查看文案是否過長導(dǎo)致截?cái)啵恍枰傩ｒ?yàn)內(nèi)容的正確性。

這一步并不復(fù)雜，而且收益極大，也是后續(xù)優(yōu)化的基礎(chǔ)，建議至少要完成這一步。

流程性問題，通過平臺(tái)來進(jìn)行管理:

以文案的自動(dòng)化替換為基礎(chǔ)，我們可以進(jìn)一步進(jìn)行擴(kuò)展，通過一個(gè)平臺(tái)來管理所有的翻譯文案，并進(jìn)行流程上的優(yōu)化。

那平臺(tái)要具備什么樣的能力呢?

1. 唯一標(biāo)識一個(gè)文案

2. 記錄每一個(gè)SDK所使用到的文案

3. 文案搜索

4. 流程的自動(dòng)流轉(zhuǎn)

在具備了這些能力之后，我們的工作流程就變成了如下的步驟：

1. 產(chǎn)品在平臺(tái)提交需要翻譯的文案（指明負(fù)責(zé)研發(fā)）

2. 平臺(tái)自動(dòng)給每個(gè)文案生產(chǎn)一個(gè)key, 并分發(fā)給翻譯

3. 翻譯進(jìn)行文案翻譯（可復(fù)用以前翻譯過的文案）,并在平臺(tái)上提交

4. 平臺(tái)自動(dòng)通知對應(yīng)研發(fā)，研發(fā)通過自動(dòng)化工具替換文案

5. 后續(xù)的文案長度的檢查

整個(gè)流程中，由于平臺(tái)的存在，每個(gè)人只需要關(guān)注自身部分的工作，不再需要和其他角色進(jìn)行繁瑣的對接和進(jìn)度跟進(jìn)。同時(shí)通過自動(dòng)化工具，文案的正確性有了極大的提高。

非主要流程的優(yōu)化:

上述流程是對于需求開發(fā)階段的優(yōu)化，但除此之外，我們可能會(huì)面臨的一個(gè)情況就是，線上的翻譯文案需要變更。

需要變更的原因可能很多，也許是文案錯(cuò)誤（自動(dòng)化加平臺(tái)也并不能完全保證正確）。也許是翻譯文案不符合當(dāng)?shù)亓?xí)慣。但顯然，重復(fù)一遍開發(fā)過程的流程，略微繁瑣。

開發(fā)過程中，需要研發(fā)介入的原因主要在于兩方面：

1. 文案的使用

2. 文案需要提交到哪個(gè)SDK需要研發(fā)確定

在文案變更的情況下，顯然研發(fā)的工作并不是必要的。平臺(tái)可以記錄使用到該文案的SDK, 文案的使用并不需要變更。

因此流程可以進(jìn)一步優(yōu)化：

1. 產(chǎn)品或翻譯在平臺(tái)上提交修改（需求可能來自前線運(yùn)營）

2. 平臺(tái)直接給所有的使用到該文案的SDK提交文案變更

文案動(dòng)態(tài)化

說到文案變更，那就會(huì)有一個(gè)時(shí)效問題。在上面提到的解決方案當(dāng)中，我們只對工作進(jìn)行了簡化，但還是得跟隨下一次發(fā)版。

大部分情況下，這一點(diǎn)時(shí)間差并不是什么大問題，但當(dāng)某些翻譯涉及到一些文化差異，政治問題時(shí)，問題可能會(huì)很嚴(yán)重。

如何對文案實(shí)時(shí)進(jìn)行變更呢？從端上的角度來說，方案并不復(fù)雜。

1. App啟動(dòng)后去拉取文案配置文件

2. Hook NSBundle以下方法，返回配置的最新文案

- （NSString *）localizedStringForKey:（NSString *）key 
                              value:（NSString *）value 
                              table:（NSString *）tableName;

但這個(gè)配置文件從何而來呢，最簡單的方式就是手動(dòng)配置，而這導(dǎo)致的一個(gè)問題就是，每個(gè)版本需要配置哪些文案呢？

1. 我們可以選擇簡單粗暴的方式，所有版本共用一份配置，這樣導(dǎo)致的問題就是已經(jīng)修復(fù)的一些文案還是通過配置化下發(fā)了。

2. 針對不同版本來配置，但帶來的一個(gè)問題是，確定每個(gè)版本需要配置的文案會(huì)導(dǎo)致額外的工作量。

顯然我們會(huì)更偏向于只下發(fā)所需文案，對于這個(gè)文案確認(rèn)工作，我們可以通過一些自動(dòng)化功能去優(yōu)化。當(dāng)有文案變更時(shí)，整個(gè)配置文案生成的過程大致如下:

平臺(tái)文案發(fā)生變更時(shí)

1. 文案發(fā)生變更

2. 獲取當(dāng)前線上App最新版本

3. 生成配置規(guī)則，小于等于當(dāng)前線上版本的都需要下發(fā)該文案

App新版本上線時(shí)

1. App新版本上線

2. 通知文案平臺(tái)

3. 文案平臺(tái)獲取上一個(gè)版本的配置

4. 文案平臺(tái)檢查最新版本中修復(fù)的文案，并從最新版本的配置中刪除

這樣就可以讓文案變更立即生效，同時(shí)也免去了手動(dòng)配置文案的痛苦折磨。