低代码平台的国际化改造，应该分为三个部分：低代码组件/sdk内置文字国际化改造，配置schema的国际化改造和数据的国际化改造。
组件/sdk国际化改造
组件/sdk内置文字国际化改造，采用内置语言包的方式，与主流国际化方案并无差异。
schema的国际化改造
配置schema国际化是改造重点。
原schema增加i18nKey
配置schema中需要对每一项展示文字，增加i18n的key，即原结构中类似配置：
{
columnName:'创建时间'
}
改造后如下
{
columnName:'创建时间',
columnName_i18nKey:'14b6b8e12acfa'
}
对应语言包：
| i18nKey | zh-CN | en-US |
|---|---|---|
| 14b6b8e12acfa | 创建时间 | Creation Time |
schema的解析
schema中i18nKey的使用大致有三种方式：
方式一：使用i18nKey逐个替换展示字段
改造前：
<span>{setting.columnName}</span>
改造后：
<span>
{setting.columnName_i18nKey ? t(setting.columnName_i18nKey):setting.columnName}
</span>
这种方式改造成本较高，工作量大也容易出错。
方式二：拉取配置后替换原展示字段
拉取配置后，根据i18nKey找到对应语言文字，然后替换原字段。 这种方法简单高效，主要逻辑都在配置解析层，不用修改核心逻辑，但问题是，如果用户切换了语言，就必须要重新触发配置的初始化流程，即页面需要整体刷新。
方式三：对配置相关字段设置getter
拉取配置后，对应字段设置getter，getter中根据i18nKey找到对应语言文字，然后返回。
Object.defineProperty(setting,'columnName',{
get(){
return setting.columnName_i18nKey ? t(setting.columnName_i18nKey):setting.columnName
},
enumerable:true
})
这种方式也不需要改造原代码逻辑，而且切换语言可以做到近乎无感刷新。
国际化i18nKey的生成和绑定
国际化改造一般滞后于视图配置，即视图配置结束后，再开始国际化改造。 可以通过解析整个应用下的对象、视图、流等所有配置，抽取出中文，并对每一个不同的中文生产随机i18nKey，再反写入配置的i18nKey字段中，形成自动绑定，同时生成语言包。这种批量操作能极大简化配置人员的工作量。
另外在视图配置中，对应的展示文字，都需要给出i18nKey手动绑定方式，以便配置人员进行微调。
实践中配置人员更多的是对语言包增加i18nKey，因为他们也并不清楚这些key到底在哪些地方使用了，最稳妥的就是不断新增，然后绑定。
我们犯过的错误
- 使用ai翻译 虽然成本上ai翻译更低，但实践下来，翻译耗时、准确率都远远不能达到预期。估算下ai部署和相关接口开发的成本，远高于采用阿里云或百度的翻译接口。
- 用资源代替语言包 底层以资源的概念承载，而资源是一个非常小的可配置可复用对象。好处是所有用到自定义描述的地方都可以引用资源，但并不适用于国际化场景。即使以资源来实现，国际化功能仍然需要将资源组装为语言包，两者使用场景完全不一致。
对数据的国际化改造
数据的国际化，最容易想到的是时间的国际化。但只要数据库里存的是时间戳，就不用关注时区的问题，反而是时间格式可能有不同的要求，比如可能有小部分客户要求月日年格式展示。 严格来说，数据的国际化改造，应该叫做应用的本地化改造。名字有中文、英文，交易有不同币种和汇率计算，这种偏业务的改造平台力所不及，只能在配置层面，提供语言和国家地区的上下文环境变量，以便于配置人员进行调整。
