今天繼續(xù)由SAP成都研究院非典型程序猿, 菜園子小哥王聰給大家?guī)矸窒怼?/p>

關于這個很長的定語的由來，請參考這篇文章，里面有王聰?shù)谋尘敖榻B，包括他種菜的特長：當我用UI5診斷工具時我用些什么。

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

下面是王聰?shù)恼摹?/p>

---

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

“我要學最酷的專業(yè)。”

深知他個性的我明白這事?lián)醪蛔?#xff0c;只能順著。于是給他推薦長沙民政職業(yè)技術學院的殯儀學院，里面的專業(yè)隨便說一個出來都是讓人目瞪口呆。何止是酷，簡直酷到口吐白沫！

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

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

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

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

可后來我才知道這真的是一門極其冷門極其古老的語言，甚至古老到了仍在大量使用象聲詞的程度。比如鴨子就叫“啊呱呱”(agwagwa)，兩只鴨子就叫“啊呱呱啊呱呱”。感嘆這孩子真有個性之余，我也在內(nèi)心暗暗替小周祈禱，畢業(yè)千萬別去了當?shù)氐酿B(yǎng)鴨場工作。實在無法想象他用豪薩語驕傲地給客戶介紹“我們公司年產(chǎn)50萬只鴨子”會是怎樣磅礴的景象。

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

文章目錄

• 愛TA，就給TA足夠的空間

• 拼接文本是把雙刃劍！

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

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

• 小心使用大小寫轉換

• 語言的復雜性，遠遠不止如此

• 不要過度限制用戶的輸入

• 你真的了解搜索和排序嗎？

• 好的注釋是i18n文件的靈魂

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

作為SAP九大Product Standards（產(chǎn)品標準）之一的Globalization，不單單是指文本的翻譯，還包含支持多貨幣、支持各國相關法律、支持不同國家業(yè)務流程等要求。為了滿足這一系列的標準，不但需要開發(fā)人員有過硬的業(yè)務知識，有時還需要花大把精力實現(xiàn)一些枯燥復雜的功能（比如為滿足阿拉伯語，需要UI支持從右向左的排布）。

但是在產(chǎn)品的設計和開發(fā)初期，如果開發(fā)人員愿意花費一些精力去留心一些方面，那么就可以大大降低未來出現(xiàn)Globalization問題的概率。下面我們就列舉SAP UI5開發(fā)的幾個和Globalization相關的例子，特別感謝Ray Ding和Vicky Chen同學對文中部分內(nèi)容的研究。

愛TA，就給TA足夠的空間

在UX設計UI布局的初期，就應該將Globalization納入考慮，而這時最容易引發(fā)的問題就是空間不夠。一套布局在英文環(huán)境看上去美輪美奐，并不代表在其他語言環(huán)境中也有很好的用戶體驗，有時甚至會影響到可用性。比方說下面這個“添加”按鈕，在英文環(huán)境下看起來還不錯，但是切換到了德語就會讓人完全看不懂。

大多數(shù)情況下，一個英文單詞的長度是短于其他語言相同意義的單詞。而我們大多數(shù)的產(chǎn)品都是以英語作為第一版語言進行開發(fā)的。當用戶已經(jīng)習慣了英語的布局之后，這時再因為引入其他語言而大幅度更改頁面布局，將會是非常痛苦的事情。所以，請永遠記得給文本足夠的空間。

可是多大才算足夠呢？幸運的是我們有一個工具叫做Text Space Calculator。它能夠根據(jù)您提供的英文文本來推薦出一個能夠滿足90%以上情況的長度。感興趣的同學可以看一下它的說明文檔，也許您會發(fā)現(xiàn)它背后的邏輯非常簡單粗暴，但是的確能夠幫助到我們。同時它還有一個Bridge的版本，您可以在Bridge中搜索“UI text space calculator”然后把它添加進您的應用。

另外一個非常實用的工具就是Pseudo，它的基礎就是上面介紹的Text Space Calculator。您可以通過它快速地發(fā)現(xiàn)潛在的文本截斷問題，同時它還能夠幫助我們發(fā)現(xiàn)UI上的硬編碼以及拼接文本。

拼接文本是把雙刃劍！

拼接文本是指在UI5項目里的i18n文件中將某些固定文本以參數(shù)的形式傳入，并拼接在一起的方式。這樣做的好處是可以在運行時動態(tài)的生成一些文本。類似的代碼在我們的產(chǎn)品中屢見不鮮，可當我們開始考慮多語言的時候，可能會發(fā)現(xiàn)突然間，一切都玩不轉了。

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

一天，產(chǎn)品經(jīng)理下達了任務：“我們把所有有效的產(chǎn)品都展示給用戶吧！”于是，您可能就寫下了這樣的代碼：

一切看起來這么完美，多語言的情況也加以考慮了，在英文環(huán)境中測試了一下，得到了想要的結果：Your active products: “apple” “orange” “banana”。但實際上，這種解決方案忽略了一個事實，就是雙引號在不同的語言中看起來有可能是不同的。比如下圖，是雙引號在英語，漢語和德語三種語言中不同的表現(xiàn)形式：

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

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

在GitHub中隨便翻一翻，就能看到很多諸如firstName + ” ” + lastName這樣的代碼。作為習慣姓氏放在最前面的國內(nèi)讀者，我們知道這樣的寫法是十分片面的，但是這樣的問題在開發(fā)時經(jīng)常會被忽視掉。類似的問題還有日期，永遠不要讓代碼中出現(xiàn)類似下面這樣將月，日，年的相對位置進行的硬編碼：

month + “/” + day + “/” + year。

小心使用大小寫轉換

在很多的應用場景下我們會使用到大小寫轉換，比如字符串對比、字符串排序等，偶爾也會用在拼接文本中。而不恰當?shù)氖褂么笮戅D換則會引起潛在的Globalization問題。下面我們通過一個例子加以說明。

假設我們現(xiàn)在有一個客戶維護頁面，用戶可以創(chuàng)建或更改客戶的基本信息，比如姓名，電話號碼，郵箱等。頁面上會對每個字段的格式加以校驗，當校驗不通過時則會對彈出類似這樣的警告：“The field email does not match the format.”

我們當然可以給每一個字段都維護這樣一條極其類似的警告，但這時“聰明”的我們發(fā)現(xiàn)在i18n文件中已經(jīng)維護了各個字段的標簽，所以我們是不是可以只維護一條警告，然后將這些標簽通過參數(shù)傳進去呢？想一想還真是有點小激動呢，于是說干就干。

作為嚴謹?shù)墓こ處?#xff0c;我們當然考慮到了把字段標簽傳入Error Message的時候，要轉換成小寫，這樣才符合英語的語法！可是卻不知道這樣卻為日后引入Globalization埋下了隱患。并不是所有的語言都與英語有著相同的大小寫規(guī)范，比方說在德語中任何名詞在任何情況下都要保持首字母的大寫，上面這段代碼在德語環(huán)境下無疑成了畫蛇添足。

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

還是從一個案例開始，假設產(chǎn)品經(jīng)理叫我們實現(xiàn)一個購物車，當用戶之前添加的某種屬性的某種商品被下架了之后，提醒用戶商品不可用。

有了上面的種種教訓，我們終于學會了要把文本中的標點以及順序信息統(tǒng)統(tǒng)寫入i18n文件，也不能隨意更換大小寫。所以我們想出了這樣的提示信息:

這下總沒問題了吧？翻譯人員可以根據(jù)不同的語言調(diào)整參數(shù){0}和{1}的位置，我們也不會主動修改參數(shù)的大小寫。在英文環(huán)境中測試一下，“Sorry, the blue pen is not available. ”，完美。

但是后面我們還是再次栽在了Globalization上面，因為不是所有的語言都像英語這么簡單。比方說這種簡單粗暴的拼接在德語中是完全行不通的，感興趣的同學可以通過下面這個介紹德語語法的wiki了解一下：

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

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

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

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

不要過度限制用戶的輸入

有些時候我們習慣對于用戶的輸入進行一定的限制，以保證數(shù)據(jù)的質(zhì)量和一致性。但是限制要有度，比方說如果對于“名字”這個字段限制為僅接受大小寫英文字母以及一些標點符號，那這樣的限制在未來就很可能會出現(xiàn)問題。

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

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

搜索

關于字符串的搜索，我們比較常用的是“equals”和“contains”這兩種策略。但其實這兩種策略都應該基于不同的語言做出不同的反饋。舉一個例子，德語中的“?”同時可以表現(xiàn)為“oe”，所以如果用戶想要搜索德國球星厄齊爾（可惜今年俄羅斯世界杯他和德國國家隊整體一樣狀態(tài)低迷），無論輸入是“?zil”還是“Oezil”，我們的搜索都應該命中到數(shù)據(jù)庫中的同一條記錄。幸運的是大多數(shù)數(shù)據(jù)庫都支持這樣的行為，只不過我們要記得去配置。

排序

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

好的注釋是i18n文件的靈魂

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

• 訂單

• 順序

• 命令

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

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

更多閱讀

• Jerry的Fiori原創(chuàng)文章合集

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

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

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

總結

以上是生活随笔為你收集整理的你的项目刚刚启动？是时候考虑Globalization了！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。