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

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

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

下面是王聰的正文。

---

我身邊的朋友中追求個性的人很多，但我最佩服的是我表弟小周。他的人生處處都把“酷”作為唯一的行事準則，甚至反映在了高考報考這種人生大事上。

“我要學最酷的專業。”

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

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

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

“先不說這個專業多冷門，就這個名字，說出來，酷不酷？”

“酷酷酷！”我連聲附和。

可後來我才知道這真的是一門極其冷門極其古老的語言，甚至古老到了仍在大量使用象聲詞的程度。比如鴨子就叫“啊呱呱”(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/German_grammar

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

如果覺得wiki太難讀懂了，那就對比一下下面四句話，會發現定冠詞和形容詞居然是一直在變的。

所以永遠不要低估語言的複雜性，再回想一下“啊呱呱啊呱呱”，真的無法想象其他的語言到底是什麼樣的邏輯。所以在進行文字拼接的時候一定要慎重。

不要過度限制使用者的輸入

有些時候我們習慣對於使用者的輸入進行一定的限制，以保證資料的質量和一致性。但是限制要有度，比方說如果對於“名字”這個欄位限制為僅接受大小寫英文字母以及一些標點符號，那這樣的限制在未來就很可能會出現問題。

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

搜尋和排序是兩個極其常用的資料處理操作，而且往往都是在一個應用架構的設計初期就被納入考慮。所以，如果我們能夠在架構設計階段就充分考慮一些潛在問題出現的可能性，那麼將來很有可能就能避免收到一些Globalization的ticket。

搜尋

關於字串的搜尋，我們比較常用的是“equals”和“contains”這兩種策略。但其實這兩種策略都應該基於不同的語言做出不同的反饋。舉一個例子，德語中的“ö”同時可以表現為“oe”，所以如果使用者想要搜尋德國球星厄齊爾（可惜今年俄羅斯世界盃他和德國國家隊整體一樣狀態低迷），無論輸入是“Özil”還是“Oezil”，我們的搜尋都應該命中到資料庫中的同一條記錄。幸運的是大多數資料庫都支援這樣的行為，只不過我們要記得去配置。

排序

“Apple”應當被排在“Banana”之前，因為“A”比“B”靠前。那如果我要將“Apple”、“Banana”、“安全”、“崩潰”四個文字在資料庫中排序呢？你覺得正確的順序是什麼？我認為這個跟使用者的使用語言是相關的。對於一個英文使用者你把“安全”放在“Apple”和“Banana”中間是顯然不合理的，但是對於某些中文使用者他們又會覺得從拼音的角度就應該把“安全”放在那裡啊。所以在資料庫設計初期，應當儘量考慮到對於多語言排序的支援。

好的註釋是i18n檔案的靈魂

使用註釋是一個良好的程式設計習慣，尤其是在i8n檔案當中。請永遠記得，當一個翻譯人員在翻譯您的i18n檔案的時候，閱讀註釋是TA獲取文字含義的唯一方式。一個不好的註釋往往會對翻譯人員造成困擾。比如如果沒有註釋，“Order”這個詞可能有很多種翻譯：

• 訂單

• 順序

• 命令

所以，在維護每一個i18n條目的時候，都請認真仔細地去寫一條註釋，這樣有幫於避免未來的許多麻煩。在產品標準中對於i18n的註釋有如下建議：

您在實際工作中，是否也才踩過一些和Globalization相關的坑呢？歡迎留言，說出您的故事。感謝閱讀。

更多閱讀

• Jerry的Fiori原創文章合集

• Jerry的UI5框架程式碼自學教程

• SAP成都研究院非典型程式猿，菜園子小哥：當我用UI5診斷工具時我用些什麼

要獲取更多Jerry的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2213916/，如需轉載，請註明出處，否則將追究法律責任。