公司的现在做的外贸平台，需要连接国外客户与国内工厂，未来还会连接东南亚工厂，那这就对平台提出了多语言的要求，不仅是简单的页面国际化，还有内容的多国语言翻译，这是一个比较大的挑战，因为To B的业务信息对准确传达要求很高，所以不能简单的使用机器翻译，也就意味着不能使用浏览器翻译，那就要求后台使用自动翻译接口+人工校验的方式，同一份数据不仅有多个浏览方，还要进行交流，新的数据进来或数据有变更还要及时提醒翻译人员去翻译，目前业务线上有两百多张表，还没算上征信数据的几百张，这么多数据如果都要翻译，那真是一个浩大的工程。
我们今天主要说动态数据翻译，针对这样大数据量的翻译，我们一定要考虑多语言扩展性、各种语言推给翻译待办、甚至是付费翻译（提供翻译服务，不同用户可以找不同的翻译）、不同端展示不同语言甚至多个语言都要展示做翻译校正，这样五花八门的需求不知道哪天就出现了，如果这些需求都考虑到那对前期的数据库设计要求非常高，我们要花费很久来平衡利弊，甚至要找到业务部门必须做出取舍，然后一轮又一轮的议论，最后大家疲于考量，在一方先妥协下暂且用一个方案，说等需求出现时再评估再改，即使做出大的改动也没办法，因为当时就是这么定的……
那如果用我现在的低代码平台是怎么做的呢？
首先有一点是毋容置疑的，所有的多语言实现方案都是有适用场景的，无论是加语言列、多语言表、多语言数值字典转换，传统硬编码的方式，英文开发和变更的工作量都很大，尤其是业务线长、系统多、接口更多的场景，在没有能力和资源搭建中台的情况下更是雪上加霜。
而使用低代码的方式，正是量变发生质变的反向思维，当变更工作量可以很小时，那我们是不是就可以不用关注过于长远需求的兼容性，就可以将更多精力放在当下紧急、当下最佳的、最简单的实现方案上，来进一步提高效率，产生效益。
就拿多语言举例，当大家还在纠结选哪种方案的时候，我已经选择了最直白的加列方案，对低代码SQL引擎做了个小改动，在动态生成CRUD SQL时，判断是否为多语言列，如果是，就追加多语言标识，这样就实现了最简单的多语言CRUD，如果需要订阅通知，只需要针对添加和编辑接口做改造，当有多语言列被添加或编辑时，往消息队列推一条消息，剩下的交个个性化业务去消费做通知就好了，未来当觉得这个方案不适合大表的时候，那还可以继续改造SQL引擎为多语言列添加新的方案，一次添加，所有业务表都可以使用、切换，如此顺滑、低价的迭代、变更成本，难道不是对传统开发思维的颠覆吗？难道不会改变我们看代码质量问题、提升开发效率、看待变更的角度吗？
我坚信，低代码的思想必然颠覆传统开发模式，让大家从繁杂的CRUD中解放出来，从变更管理、运维灾难中解放出来，会让大家有更多时间思考，如何解决业务问题、激发更多的设计灵感，让我们的生活与工作更美好与从容。
