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

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

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

原始階段

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

此時的整個工作流程大概如下：

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

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

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

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

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

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

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

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

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

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

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

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

自動化&平臺化

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

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

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

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

同時通過工具替換文案大大提高了可靠性，后續(xù)的校驗可以簡單地只查看文案是否過長導(dǎo)致截斷，不需要再校驗內(nèi)容的正確性。

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

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

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

那平臺要具備什么樣的能力呢?

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

2. 記錄每一個SDK所使用到的文案

3. 文案搜索

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

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

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

2. 平臺自動給每個文案生產(chǎn)一個key, 并分發(fā)給翻譯

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

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

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

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

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

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

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

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

1. 文案的使用

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

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

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

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

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

文案動態(tài)化

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

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

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

1. App啟動后去拉取文案配置文件

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

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

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

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

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

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

平臺文案發(fā)生變更時

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

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

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

App新版本上線時

1. App新版本上線

2. 通知文案平臺

3. 文案平臺獲取上一個版本的配置

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

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