今天繼續由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同學對文中部分内容的研究。
在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”中間是顯然不合理的，但是對于某些中文使用者他們又會覺得從拼音的角度就應該把“安全”放在那裡啊。是以在資料庫設計初期，應當盡量考慮到對于多語言排序的支援。
使用注釋是一個良好的程式設計習慣，尤其是在i8n檔案當中。請永遠記得，當一個翻譯人員在翻譯您的i18n檔案的時候，閱讀注釋是TA擷取文本含義的唯一方式。一個不好的注釋往往會對翻譯人員造成困擾。比如如果沒有注釋，“Order”這個詞可能有很多種翻譯：
- 訂單
- 順序
- 指令
是以，在維護每一個i18n條目的時候，都請認真仔細地去寫一條注釋，這樣有幫于避免未來的許多麻煩。在産品标準中對于i18n的注釋有如下建議：
您在實際工作中，是否也才踩過一些和Globalization相關的坑呢？歡迎留言，說出您的故事。感謝閱讀。
更多閱讀
- Jerry的Fiori原創文章合集
- Jerry的UI5架構代碼自學教程
- SAP成都研究院非典型程式猿，菜園子小哥：當我用UI5診斷工具時我用些什麼
要擷取更多Jerry的原創技術文章，請關注公衆号"汪子熙"或者掃描下面二維碼: