今天繼續由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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。