你的項目剛剛啓動？是時候考慮Globalization了！

時間 2019-11-15

標籤項目剛剛啓動時候考慮 globalization 简体版

原文原文鏈接

今天繼續由SAP成都研究院非典型程序猿, 菜園子小哥王聰給你們帶來分享。程序員

關於這個很長的定語的由來，請參考這篇文章，裏面有王聰的背景介紹，包括他種菜的特長：當我用UI5診斷工具時我用些什麼。數據庫

秋天到了，娃娃們開學了，又是一個收穫的季節。雖然過去的8月，成都雨水偏少，可是對於王聰來講這些都不是事，他的莊稼同樣得到了豐收。有圖爲證：編程

下面是王聰的正文。安全

我身邊的朋友中追求個性的人不少，但我最佩服的是我表弟小周。他的人生到處都把「酷」做爲惟一的行事準則，甚至反映在了高考報考這種人生大事上。架構

「我要學最酷的專業。」app

深知他個性的我明白這事擋不住，只能順着。因而給他推薦長沙民政職業技術學院的殯儀學院，裏面的專業隨便說一個出來都是讓人目瞪口呆。何止是酷，簡直酷到口吐白沫！框架

他爸媽聽了個人建議巴不得打死我，只有小周眼放金光，做勢就要把志願填了且不服從調劑。全家人一致決定剝奪我提出建議的權利，並經過各類威逼利誘、恐嚇威脅終於把小周的殯儀夢想扼殺於搖籃之中。數據庫設計

可強權暴政鎮壓不住一顆紅彤彤的嚮往個性的心，最終小周仍是報考了一個極其冷門的專業——北外的豪薩語專業。工具

「先不說這個專業多冷門，就這個名字，說出來，酷不酷？」佈局

「酷酷酷！」我連聲附和。

可後來我才知道這真的是一門極其冷門極其古老的語言，甚至古老到了仍在大量使用象聲詞的程度。好比鴨子就叫「啊呱呱」(agwagwa)，兩隻鴨子就叫「啊呱呱啊呱呱」。感嘆這孩子真有個性之餘，我也在心裏暗暗替小周祈禱，畢業千萬別去了當地的養鴨場工做。實在沒法想象他用豪薩語驕傲地給客戶介紹「咱們公司年產50萬隻鴨子」會是怎樣磅礴的景象。

今天的文章跟鴨子無關，我只想談一談語言。

文章目錄

愛TA，就給TA足夠的空間
拼接文本是把雙刃劍！
也許……您硬編碼了標點符號囧
即使您的客戶是馮紹峯，也不要隨便把人家的名字倒過來寫
當心使用大小寫轉換
語言的複雜性，遠遠不止如此
不要過分限制用戶的輸入
你真的瞭解搜索和排序嗎？
好的註釋是i18n文件的靈魂

據統計世界上已存在的語言多達5000多種，即使不考慮豪薩語這種冷門語言，被普遍使用的語言也有幾十種。把溫暖（chǎn pǐn）灑滿人間是每個程序員的夢想，可又不能期望每個客戶都使用英語，這時便產生了軟件Globalization這一律念。

做爲SAP九大Product Standards（產品標準）之一的Globalization，不僅僅是指文本的翻譯，還包含支持多貨幣、支持各國相關法律、支持不一樣國家業務流程等要求。爲了知足這一系列的標準，不但須要開發人員有過硬的業務知識，有時還須要花大把精力實現一些枯燥複雜的功能（好比爲知足阿拉伯語，須要UI支持從右向左的排布）。

可是在產品的設計和開發初期，若是開發人員願意花費一些精力去留心一些方面，那麼就能夠大大下降將來出現Globalization問題的機率。下面咱們就列舉SAP UI5開發的幾個和Globalization相關的例子，特別感謝Ray Ding和Vicky Chen同窗對文中部份內容的研究。

愛TA，就給TA足夠的空間

在UX設計UI佈局的初期，就應該將Globalization歸入考慮，而這時最容易引起的問題就是空間不夠。一套佈局在英文環境看上去美輪美奐，並不表明在其餘語言環境中也有很好的用戶體驗，有時甚至會影響到可用性。比方說下面這個「添加」按鈕，在英文環境下看起來還不錯，可是切換到了德語就會讓人徹底看不懂。

大多數狀況下，一個英文單詞的長度是短於其餘語言相贊成義的單詞。而咱們大多數的產品都是以英語做爲初版語言進行開發的。當用戶已經習慣了英語的佈局以後，這時再由於引入其餘語言而大幅度更改頁面佈局，將會是很是痛苦的事情。因此，請永遠記得給文本足夠的空間。

但是多大才算足夠呢？幸運的是咱們有一個工具叫作Text Space Calculator。它可以根據您提供的英文文原本推薦出一個可以知足90%以上狀況的長度。感興趣的同窗能夠看一下它的說明文檔，也許您會發現它背後的邏輯很是簡單粗暴，可是的確可以幫助到咱們。同時它還有一個Bridge的版本，您能夠在Bridge中搜索「UI text space calculator」而後把它添加進您的應用。

另一個很是實用的工具就是Pseudo，它的基礎就是上面介紹的Text Space Calculator。您能夠經過它快速地發現潛在的文本截斷問題，同時它還可以幫助咱們發現UI上的硬編碼以及拼接文本。

拼接文本是把雙刃劍！

拼接文本是指在UI5項目裏的i18n文件中將某些固定文本以參數的形式傳入，並拼接在一塊兒的方式。這樣作的好處是能夠在運行時動態的生成一些文本。相似的代碼在咱們的產品中家常便飯，可當咱們開始考慮多語言的時候，可能會發現忽然間，一切都玩不轉了。

也許……您硬編碼了標點符號囧

一天，產品經理下達了任務：「咱們把全部有效的產品都展現給用戶吧！」因而，您可能就寫下了這樣的代碼：

一切看起來這麼完美，多語言的狀況也加以考慮了，在英文環境中測試了一下，獲得了想要的結果：Your active products: 「apple」「orange」「banana」。但實際上，這種解決方案忽略了一個事實，就是雙引號在不一樣的語言中看起來有多是不一樣的。好比下圖，是雙引號在英語，漢語和德語三種語言中不一樣的表現形式：

與之相似的還有括號，句號等。雖然在有的場合下，有的朋友並不認爲這是一個致命的問題，可是從Globalization的角度來說，它確實不是一個完美的解決方案。

即使您的客戶是馮紹峯，也不要隨便把人家的名字倒過來寫

在GitHub中隨便翻一翻，就能看到不少諸如firstName + 」」 + lastName這樣的代碼。做爲習慣姓氏放在最前面的國內讀者，咱們知道這樣的寫法是十分片面的，可是這樣的問題在開發時常常會被忽視掉。相似的問題還有日期，永遠不要讓代碼中出現相似下面這樣將月，日，年的相對位置進行的硬編碼：

month + 「/」 + day + 「/」 + year。

當心使用大小寫轉換

在不少的應用場景下咱們會使用到大小寫轉換，好比字符串對比、字符串排序等，偶爾也會用在拼接文本中。而不恰當的使用大小寫轉換則會引發潛在的Globalization問題。下面咱們經過一個例子加以說明。

假設咱們如今有一個客戶維護頁面，用戶能夠建立或更改客戶的基本信息，好比姓名，電話號碼，郵箱等。頁面上會對每一個字段的格式加以校驗，當校驗不經過時則會對彈出相似這樣的警告：「The field email does not match the format.」

咱們固然能夠給每個字段都維護這樣一條極其相似的警告，但這時「聰明」的咱們發如今i18n文件中已經維護了各個字段的標籤，因此咱們是否是能夠只維護一條警告，而後將這些標籤經過參數傳進去呢？想想還真是有點小激動呢，因而說幹就幹。

做爲嚴謹的工程師，咱們固然考慮到了把字段標籤傳入Error Message的時候，要轉換成小寫，這樣才符合英語的語法！但是殊不知道這樣卻爲往後引入Globalization埋下了隱患。並非全部的語言都與英語有着相同的大小寫規範，比方說在德語中任何名詞在任何狀況下都要保持首字母的大寫，上面這段代碼在德語環境下無疑成了多此一舉。

語言的複雜性，遠遠不止如此

仍是從一個案例開始，假設產品經理叫咱們實現一個購物車，當用戶以前添加的某種屬性的某種商品被下架了以後，提醒用戶商品不可用。

有了上面的種種教訓，咱們終於學會了要把文本中的標點以及順序信息通通寫入i18n文件，也不能隨意更換大小寫。因此咱們想出了這樣的提示信息:

這下總沒問題了吧？翻譯人員能夠根據不一樣的語言調整參數{0}和{1}的位置，咱們也不會主動修改參數的大小寫。在英文環境中測試一下，「Sorry, the blue pen is not available. 」，完美。

可是後面咱們仍是再次栽在了Globalization上面，由於不是全部的語言都像英語這麼簡單。比方說這種簡單粗暴的拼接在德語中是徹底行不通的，感興趣的同窗能夠經過下面這個介紹德語語法的wiki瞭解一下：

https://en.wikipedia.org/wiki...

（Jerry旁白：我看了這個wiki，看不懂，燒腦，所以對本文做者可以以中英德三語在SAP Community上寫博客表示很是佩服。固然，深受SAP成都同事愛戴的另外一位老員工，林師傅，他的德語口語流利程度就不用多說了，去年Jerry和林師傅去德國一個小鎮上買牀墊，林師傅和銷售小妹交談了15分鐘，我全程就聽懂了一個單詞：Tschuess 囧）

若是以爲wiki太難讀懂了，那就對比一下下面四句話，會發現定冠詞和形容詞竟然是一直在變的。

因此永遠不要低估語言的複雜性，再回想一下「啊呱呱啊呱呱」，真的沒法想象其餘的語言究竟是什麼樣的邏輯。因此在進行文本拼接的時候必定要慎重。

不要過分限制用戶的輸入

有些時候咱們習慣對於用戶的輸入進行必定的限制，以保證數據的質量和一致性。可是限制要有度，比方說若是對於「名字」這個字段限制爲僅接受大小寫英文字母以及一些標點符號，那這樣的限制在將來就極可能會出現問題。

你真的瞭解搜索和排序嗎？

搜索和排序是兩個極其經常使用的數據處理操做，並且每每都是在一個應用架構的設計初期就被歸入考慮。因此，若是咱們可以在架構設計階段就充分考慮一些潛在問題出現的可能性，那麼未來頗有可能就能避免收到一些Globalization的ticket。

搜索

關於字符串的搜索，咱們比較經常使用的是「equals」和「contains」這兩種策略。但其實這兩種策略都應該基於不一樣的語言作出不一樣的反饋。舉一個例子，德語中的「ö」同時能夠表現爲「oe」，因此若是用戶想要搜索德國球星厄齊爾（惋惜今年俄羅斯世界盃他和德國國家隊總體同樣狀態低迷），不管輸入是「Özil」仍是「Oezil」，咱們的搜索都應該命中到數據庫中的同一條記錄。幸運的是大多數數據庫都支持這樣的行爲，只不過咱們要記得去配置。

排序

「Apple」應當被排在「Banana」以前，由於「A」比「B」靠前。那若是我要將「Apple」、「Banana」、「安全」、「崩潰」四個文本在數據庫中排序呢？你以爲正確的順序是什麼？我認爲這個跟用戶的使用語言是相關的。對於一個英文用戶你把「安全」放在「Apple」和「Banana」中間是顯然不合理的，可是對於某些中文用戶他們又會以爲從拼音的角度就應該把「安全」放在那裏啊。因此在數據庫設計初期，應當儘可能考慮到對於多語言排序的支持。