xx 的博客

国际化软件开发的最佳实践 ​

背景 ​

《国际化软件开发规范》内网链接无法访问 是17年出台的，中间做了几次的调整（但调整内容不得而知），我重新review了一下这个规范，发现一些改动点，以及我认为在软件中的最佳实践想说明一下。

有关多语言的命名问题，之前有讨论过，2023 多语言规范调整

前后端的多语言存放 ​

我已经忘记了是之前的开发规范有限制，还是说我们最早的设计就如此，我们一些请求返回的 message，都是key，然后前端根据这些 key，去写匹配项：

比如有个多语言是 vms.message.fail ，后端会将这个多语言的字符串放到，请求的message里面，前端根据这个key，以及多语言文件 translate.json 中的 vms.message.fail: '失败' 去实现错误框打开的中文显示。跟有甚者，前端直接拿message返回的值，去判断一些业务的逻辑，非常恐怖。

js
// 后端返回
if (message === 'vms.message.fail') {
  // 业务处理
}

之前好像有说接口返回内容也不能带中文，但最新的开发规范没看到有这个限制了

这里其实有一个问题，就是 vms.message.fail 这个错误信息，只有在前端工程的 translate.json 中有，这就会存在维护的问题，比如

  • 后端工程中需要使用这个错误信息，就需要前端提供。定制还好说，后端写死中文即可，基线会存在不必要的沟通成本
  • 前端找不到key在代码中的用途，就容易漏掉；比如现在经常出现整个菜单迁移到另一个组件的情况，那我们多语言也需要整个迁移。但这里如果前端没有找到key在代码中的用途，就容易漏掉。（然后所有前缀都得改，真不知道搞规范的人怎么想的）
  • translate.json 后续的维护成本，现在一个项目的多语言文件中的翻译存在大量的老代码，后续的维护成本会很高

所以我个人建议是，后端在接口中直接返回错误信息，前端直接负责展示，这样就避免了维护的问题。

这里存在另一个问题，国际化多语言规范是不能删除和修改的，所以我觉得老的代码，可以保留，但新写的代码，可以考虑说服后端，直接返回中文。

我觉得渐进式的修改才是软件开发的正道，所以尽可能还是在新加的代码中，去遵守这个最佳实践

文字过长的最佳实践 ​

在《国际化开发规范中》，有这么一条，如果文字过长，那需要进行...处理，并在鼠标移动上去的时候，进行展示所有内容。

在最早的 hui 开发中，我们为了遵守规范引入了很多类似这样的功能，即使 element-plus 的 el-table 也还是有 show-overflow-tooltip 这样的功能。

但这里有个问题就是，业务开发的过程中，就不管这些，直接展示，然后就出现了很多文字过长的现象。其实很多页面如果出现大量的 ... ，那这个页面就很难看或者难用了。

规范确实没有错，规范只是一个底线而已，如果不出现... 和 鼠标移动上去展示所有内容，那很多功能就无法正常使用。

作为开发者来说，可能要考虑更多的边缘场景，来让这个产品更健壮。但过度依赖规范，不去思考可用性，那这个产品就很难用。

HUI-VUE 3 将会移除这个规范 ​

HUI-VUE 3 将会移除这个规范的内部实现，但会保留更多的 slot 插槽，以及其他方案，来让开发者有更多的自定义空间。但一些比较常用的，比如 table 里面的 show-overflow-tooltip 这样的功能，还是会保留。

国际化开发杂谈 ​

最早其实并没有一些跨国开发的经验。但实际开发后发现，其实多语言的开发，水很深，并不是说规范遵循了，我们的产品去了国外就能正常使用。

比如：

  • 我们H5的开发，更多的是用于 微信公众号，微信小程序，hatom，场景。但国外基本用不上。
  • 我们的支付，更多的也是对接微信，支付宝。在这块其实无法说你本地化做了，业务上就能用起来的。这块其实也完全不用国际化的。
  • 我们的车牌，更是无法适配本地化。甚至很多车牌，比如港澳，更是明确在国际化开发上有限制的。
  • 还有些看不到的，比如还有 手机号码，身份证的校验规则等
  • ...

所以一套代码适配多端，这件事情的合理性，其实需要重新思考的。

在一些国际化合规性上面，可以通过邮件申请，报备的方式来说明，我们为什么不处理。或者如果知道他们底层的合规工具逻辑，可以完全规避检测的问题的。（这个稍微动下脑子，其实就知道了，实在不知道可以来问我）

这几年下来我也渐渐发现，海外更多的还是说，拿我们的代码去适配本地化，并做二次开发而已。所以我个人觉得，规范的遵守也只是一个度的问题。如果有场景，有需求，可以再去执行。但你不做这块业务的时候，其实怎么做都是错的，还是那句名言 --- 提前优化是万恶之源。

所以如果真的哪天，有海外产品需要集成，我们那时候再做翻译与业务的适配，其实会更好。