何罗鱼国际货运业务管理系统设计最初就考虑到了多语种的使用场景，在表结构设计、前端控件选择以及报表显示上都做足了准备，但即便如此，在着手开发配置多语种功能时，仍然是非常挠头，可谓是心力交瘁！

专业术语翻译

首先这是个繁琐的工作，近5000个字段名、菜单名、按钮名、提示语等等都需要一一对照翻译；其次你还别嫌多，关键是你可能还不会，语义翻译外加专业术语，别说你是英文几级，那个此时不好用。比如做保险系统的同行会来问，基本生命表，费率厘定怎么译成英文？

结论是你得找专业的人来做这个繁琐的体力活。老板们可能会说，我们本就是这个行业的，这有什么问题吗？问题会少些，但不会没有，比如进仓编号到底怎么写才能让所有国家的人都看得懂？比如主管审核和财务审核都是审核，可以用同一个词表达吗？比如综合考虑应收账，应付账还有代理账后，你认为账单号码要怎么翻译才最合适？还有一些需要合并的情况，比如需要在同一个格子里显示 Vessel Voyage/Flight No/Train No，怎么译才合适？有人说了不翻译，就这样写，相信我，你看了列表布局后就不会那么想了。

这活，费体力，也绝不省脑子，还急不来。

配置文件

这个就只有繁琐了，字段匹配繁琐，测试繁琐。

首先要把5000个字段根据显示页面排好队，中英文逐一对照着做成配置文件，打包在系统里供前端调用显示。

然后就是来来回回、反反复复的测试了，看是否有漏译Lable, Alert, Notification, Message, Button 等控件，是否有自定义的但调用了共用字段，是否保持了系统全局统一标准等。

前端控件选择

如果表单控件选择了上图左右结构显示的样式，即字段名在左，文本框在右，恭喜你中奖了，很多情况是显示不开的，举例子：运输方式=Transport Mode=модель транспортировки(白俄)，没啥好办法，要么忍受换行样式，要么全局换控件。

另外像下拉选择框与自动填充的选择框在初始化的时候，最好都统一做自适应宽度的封装处理，否则逐一处理起来也是相当头痛。

Table 列表

配置文件里有提到共用的字段名，比如运输方式，在表单上显示可以译为 Transport Mode, 但到了列表里，这就太占空间了，最好只用Mode显示就好了，那么问题就来了，这种字段就要使用自定义的，无法共用了，要逐一找出来，单独对应译文，而又不能和表单里显示的完全不一样，不然用户就不懂了！

内容与报表显示

内容处理起来要麻烦得多，比如一些维护的基础数据值，像港口表，币种表，承运公司表等，就要求显示取值要规范化处理，取“USD”的千万不取“美元”，取“New York”不要取“纽约”，那个基本上调到你全身哪哪都疼。

报表处理需要考虑最多的还是扩展性问题，如将来会不会有更多语种接入，用户自定义的报表如何让系统能够匹配系统语言等。

同时就是考虑多语种对照报表的显示，比如何罗鱼系统里同一个账单支持分别打印中文费用确认单和全英文的 INVOICE， 这得益于数据库本身还设计了中英对照字段，切换报表语种的同时，还支持取用不同的字段值。

用户体验

比如对齐方式的调整，中文相同的字数，对齐很工整，但切换成英文就长短不一了，特别严重就可能要扩展整个控件类的CSS样式；比如通过Cookie自动判断用户上一次登录时使用的语言；比如切换系统语言时页面刷新机制的设置；再比如大小写字母的使用规则等。