中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導讀：隨著全球化浪潮的不斷演進，中國企業已經不再滿足于只在國內發展，很多企業把目光放向了海外，研究如何做好一個全球化的產品。當一個全球產品在面向全球用戶時，如何能去為用戶盡量做好產品的多語言服務？本文作者對此進行了分析，希望對你有幫助。

隨著全球化浪潮的席卷和深化，中國企業可以說是前赴后繼地加入出海大軍當中，其中不乏像TikTok之類的產品在海外做得風生水起，與此同時大家也在花費越來越多的時間精力，關注并研究如何去做好一個全球化的產品。但是無論是專做出海還是做全球市場覆蓋，一定程度上都會面臨一部分在純國內市場中很少去面臨的問題。特別是當產品一次性面向了多個國家多個語種的用戶時，將會面臨來自不同政治環境、文化環境、商業環境的挑戰。

不過今天我們暫且撇開其他問題，先來看一看在產品常見挑戰中，當一個全球產品在面向全球用戶時，如何能去為用戶盡量做好產品的多語言服務？筆者就拿有一定復雜度的平臺型產品（Google Play）為例子，來和大家來聊一聊。

思考如下問題：

這里我們先嘗試以Google Play的截圖做個例子，當大家第一眼看到圖示1里的這張圖的時候，可以嘗試快速地想一下，這里Google Play團隊是如何做該產品在不同語言設置下的多語言展現的？

圖示1. Google Play商店多頁面截圖

可以這樣看待，其實所有你在截圖中可以看到的事物都是一種數據，無論是文字數據還是圖片數據甚至是視頻數據，但其數據的填充鏈條（來源鏈），卻是有多種情況的，來充分保障不同語言用戶能盡量去看到對應語言的數據。

一、多語言數據分類

不同語言的數據來源的情況雖多，但是我們總歸是可以做一下分類。某類數據，其實在這個產品的大框架之內可以分類成為：

• 產品獨管型數據
• 產品混管型數據

那么下邊我們就兩類數據的細節情況做一下深入介紹。

1. 產品獨管型數據

產品獨管型數據，指的是完全由產品官方進行掌控的數據，這里數據的修改是無法經由B端或者C端用戶參與修改的。

圖示2. Google Play的商店首頁不同語言環境下的展現（左為西班牙語，右為繁體中文）

根據圖示2其實可以看見，同一個位置（例如左邊上方的”Descubrir juegos recomendados”對比右邊的”發掘推薦的遊戲”），在不同語言環境下Google Play會映射出對應語言文案，而這些文案往往相對固定，文案的生產一般由產品所屬公司團隊內部直接供應。這一類文案其實就是比較常見的UI界面上屬于固定性質的UI文案與UI用圖，其創建與修改均只有平臺官方有權限改動，無論B端用戶和C端用戶均不參與到文案數據的創建編輯工作中，分類上就可以對應地稱為產品獨管型的數據。

圖示3. 產品獨管型數據&混管型數據對比舉例

那么這類產品獨管的數據，一般以何種方式做的填充實現呢？比較常見三種方式：

• 純本地：直接以純數據文件的形式附帶在App本地文件中的，可以說是非常純粹的UI類文案填充
• 純遠程：文案數據是儲存在服務器上遠程下發給App，這種跟第一種比較接近
• 遠程+運營配置能力：文案數據同樣是遠程下發，但是增加了后臺運營配置頁面，往往相比前兩種文案數據在修改上對于運營來說更加快速靈活，一般應用于運營類配置數據

圖示4. 固定文案 – 安卓App可以將翻譯文案寫入到xml文件中

更細節一些，如圖示4所示，安卓客戶端可以將翻譯文案寫入到XML文件中，這一類是便是上邊提到的最基礎的『固定文案』的實現方式，屬于第一種純本地的填充方式。另外稍微靈活一些的方式便是通過服務端下發『固定文案』來實現，相比第一種本地填充的方式，第二種好處是可以不通過發版就實現文案修訂。

圖示5. 配置文案 – 往往通過后臺運營配置實現

圖示5（圖為僅Demo需要，不包含額外的后臺細節）為筆者推演出的Google Play編輯團隊需要配置編輯推薦專題時，所需要給予的后臺配置頁面的展示形態，即上文中提到的第三種方式（遠程+后臺運營配置）中的配置端樣式。公司內的編輯或者內容運營只需要將準備好的文案與圖片材料填充進入對應語言的表單即可，最終按語言下發到對應語言的用戶手中進行瀏覽。這種形式的好處在于相比第二種更進一步的文案修訂靈活性，同時也會支持到運營活動的開展。

特別注意無論哪種填充方式，前端數據展現前都必須要先確定用戶語言（可以通過提取用戶系統語言來鎖定）來根據語言調取對應的數據進行展示哦。

2. 產品混管型數據

產品混管型數據，指的是數據本身的創造與修改，除了公司的運營團隊（這里的名稱為泛指，同樣包含公司其他被賦予權限的角色）本身可以做到之外，權力是同樣開放給B端或者C端用戶的。那么根據實際參與方的類別，我們可以將數據填充類別分為如下：

• 平臺運營 & B端用戶參與
• 平臺運營 & C端用戶參與

然后我們再來根據分類深入分析差異。

平臺運營 & B端用戶：

圖示6. Google Play Console當中的多語言配置項

運營團隊或者B端用戶同時有權限修改的，但同時其他角色例如C端用戶無權修改的數據，比較常見的就是平臺商品的各項數據例如名稱、簡介、截圖等等，可以參見圖示6所示的Google Play Console的App詳情數據填充（商品在Google Play當中就是一個App，）。實際上，這些字段在谷歌的官方人員后臺（雖然我們看不見），是會有對應的編輯位置的，谷歌官方工作人員作為平臺方，需要有能力在必要時候進行干預修改。

需要注意的是，B端用戶雖然有創建和修改權限，但是填充內容的提交往往會有審核和舉報機制覆蓋，平臺運營參與監控，保障不會出現平臺政策允許范圍之外的事物。

平臺運營 & C端用戶：

圖示7. Google Play當中的應用評價創建頁和瀏覽部分

運營團隊或者C端用戶同時有權限創建和修改的，但一般B端用戶無權限參與創建和修改的數據，比較常見的就是社區內容數據（例如帖子）。如果要在Google Play中尋找一個相對近似的案例，筆者認為應用評價（App Review）應該算一個比較好的樣板，仍然可以參見圖示。實際上這類UGC內容，在多語言覆蓋方面是較難做到完美供應的，同時需要利用產品邏輯進行語言對語言的內容下發。如果平臺希望A語言用戶能看懂B語言用戶的內容，往往需要額外的支持例如第三方翻譯組件。

同樣的，C端用戶雖然有創建和修改權限，但是填充內容的提交也往往會有審核和舉報機制覆蓋，平臺運營參與監控。

二、多語言數據的覆蓋與輸出

為什么第二部分需要展開談產品多語言方案的覆蓋與輸出邏輯？實際上，全球化產品當中一個比較常見的多語言方案實現阻礙，就是盡管產品多語言框架可以架設，做好數據的分類，但是有許多位置的文案是較難實現數據覆蓋的。雖然上方聊了數據，但如果數據的供應有缺陷，此時往往需要一些產品邏輯或者功能來保障數據在輸出到用戶時，是有較好的使用體驗的。

圖示8. Google Play中也會出現的語言割裂現象

特別是產品混管型的數據，無論參與方是B端用戶或者C端用戶，其實都較難實現全語言的數據覆蓋。比如Google Play支持的40+全球主要語言，要實現面向如此多語種的數據覆蓋，人力財力等各方面資源其實都較為有限。就會導致如圖8所示，盡管UI界面上對應輸出了當時筆者使用的西班牙語，但實際上游戲簡介等位置仍然使用著繁體中文和英文。在Google Play當中，其實有相當量級的這樣的產品，是不乏看見一些簡介文案語言與GP的UI語言之間直接割裂的。

那么既然談了現象，應該如何嘗試解決呢？一般來說可以從四個角度切入：

1. 公司內資源拉動

公司內資源拉動是指純粹的內容團隊組織語言翻譯工作，一般是在做特別重要的語言數據覆蓋時會采用的方案。比如產品戰略方向是特別注重日語和韓語的，那么往往會招聘對應語言的翻譯人員進入公司工作，此時的翻譯質量往往能得到較高質量的保障。

此時一個常見的拓展是翻譯工作接入外包公司，公司付費購買質量相對可控的翻譯文本，而自己的團隊內部有一定人員面向外包公司做對接和質量管理。

2. B端資源拉動

B端資源拉動，指的是當涉及數據是有B端用戶參與操控的時候，產品官方可以通過適當的提示、講解、激勵性質的方案或者直接打通翻譯服務來促進B端用戶自行填充足夠的多語言材料，來達到拉動語言數據覆蓋的目的。

圖示9、Google Play Console中直接提供了翻譯服務的接入

3. C端資源拉動

C端資源拉動，一般較為常見的方案是語言志愿者社區的建立。這樣做的好處往往是在成本上花費的代價較少，但對應的代價是翻譯質量的控制變得更為復雜，可以說一部分志愿者可能會有精妙絕倫的翻譯，但一部分志愿者可能也會給出令人吐槽的翻譯結果，一些對此無力做到全面控制的團隊需要衡量這一方面的弊端，必要的時候有所舍棄。

圖示10、Steam的多語言數據覆蓋選擇了借助用戶志愿者的力量（https://translation.steampowered.com/）

4. 智能解決方案

C端智能解決方案，指的是自動翻譯服務，比如Google Translate。如圖示11所見，Google Play內置了自家的翻譯服務來提升閱讀體驗。值得一提的是，Google Translate的翻譯質量，在歐洲各大語言之間翻譯筆者認為已經做到相當高的質量（比如英語-法語等之間互譯），但是不同語系之間的語言互譯質量還有待提高（比如英語-漢語之間的互譯），這本身與語系當中的語法邏輯和詞匯組成有關，需要持續的時間和資源投入提升翻譯質量，不在這里多贅述。

圖示11. Google Play調用了自家的Google Translate來彌補多語言數據的不足

這里需要補充一點的是，產品邏輯上要注意，當沒有對應語言文案展示給用戶時，盡量保障流行語言（例如英語）作為打底語言，提高文案的可讀性。

三、歸納與結語

在介紹完上邊的概念之后，我們可以嘗試用思維導圖對產品多語言方案進行梳理，可以得到如下圖示。

那么，在這樣的一個框架梳理下，全球化產品的多語言鋪設方面就相對清晰了。

不過海外產品其實進攻的市場類型豐富多樣，而今天我們嘗試使用的案例Google Play并不代表了所有的產品類型，例如一般的工具類產品的多語言翻譯方案會在這個基礎上簡化許多（由于一般不需要B端用戶和C端用戶參與生產內容資料），相信大家在實際面對相關項目時可以靈活應變。

最后，希望本文能夠在實際工作中更多幫助到在海外市場深耕的各位產品小伙伴，感謝閱讀！

本文由 @菠蘿飯 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。