一文搞懂国际化（四）总结提升

专题目录

一文搞懂国际化（一）背景概览

一文搞懂国际化（二）架构设计

一文搞懂国际化（三）落地实践

一文搞懂国际化（四）总结提升

 

引子

没想到国际化系列一写就是一年....期间伴随博主的国际化项目从立项、设计、研发、交付生产全流程。目前线上韩国、俄罗斯都在使用，运行良好。但也有一些不足，特写本文记录下来。

一、总结

• 国际化是一个系统性的工作，早规划做一定比后期改造成本小太多。
• 时区时间改造工作复杂度高，非必须不建议搞。
• 一定需要产品介入。来把控版本问题，国际化也是需求。

耗时的因素有：

• 方案选择：选择UTC0改造成本远大于UTC8基座。
• 系统复杂度。调用链路长、微服务多
• 持续迭代问题。当前业务不稳定，国内版一直还在迭代开发上线，你的国际化改造就得阶段性合并到国内，陷入永远改不完的陷阱中。所以国际化改造要投入最大力量，快速上线，一刀切为佳。
• 能不搞外包，不要搞。因为一旦涉及复杂业务，外包也改不动，最后还是自己人来改，到时候会出来管理2个改造团队，出现1+1=N的难度....  不管是人员管理、项目管理、代码管理全流程都难受....
• 版本混乱。产品梳理不清楚哪些业务要国际化，哪些不要。或者不介入，介入不足，都会导致版本迭代不清楚，版本开发陷入泥潭。
• 代码分支管理。最好不要跟国内完全割裂开代码分支。如果是2个团队做国内国际需求，那就只能国际独立一套（开发、测试、预发、生产）分支。但也要用最快速改造完毕后立即合并回国内一套分支上，尽量减少功能代码不同带来的国际化改造+合并+缺陷修复成本。

 代码分支问题：

如果国际独立出一套代码分支、同时国内业务又在迭代，只能搞一个公共分支，阶段性双向合并，成本极大，且容易出错，各种合并冲突、丢失问题。两边团队甩锅....

所以，如果没办法，必须国际版单拉一个分支，一定要尽快搞定翻译尽快统一分支，搞一个大版本，国内、国际一起上线，后续就是一套代码，两边部署（代码要做兼容，个别需求可能不同，代码不一定都一样。前端也需要改造支持2套域名发布。）。

光这个大合并，博主就搞了1个月，还是下了极大的决心，跟各产品沟通的嘴皮子都冒火星了，才搞定的。

 

总之，搞国际化，特别是复杂系统，多团队，并行开发的情况，评估项目工期时  改造点工时*4倍，是一个比较理想的时间....因为前期你看到的改造成本只是冰山一角！！！！

 

二、展望未来

• 后端翻译缓存更新问题。由于采用多级依赖机制，底层某个微服务的缓存更新后，很难找到上层哪些服务的缓存需要更新，这是一个艰难的问题
• 翻译精准度。这个目前只能用人工（专业翻译人员针对产品场景，一条一条翻译）+机翻（使用工具）结合的方式。
• 目前翻译工具，不够自动化，还是需要人工介入，后续期望借助AI，实现全自动化，例如翻译打分达标后自动更新翻译。