你的项目刚刚启动？是时候考虑Globalization了！

今天继续由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...

（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的原创技术文章，请关注公众号"汪子熙"或者扫描下面二维码: