跳到主要内容

设计

版权声明

国际化(internationalization)与本地化(localization)的解释见:

一般的本地化是指对可见的文本内容的翻译支持, 而对于需要为不同地区做页面层面的调整时,则需要设计单独的页面和交互逻辑, 在复杂的情况下,可能需要为不同地区的用户提供不同的应用服务。

  • 在页面中提供语言切换地区切换功能, 前者用于将页面上的当前语言的文本内容切换到目标语言的翻译文本, 后者用于为目标地区提供差异化的页面布局和交互体验
  • 在 Delta 层 locales 中以差量方式定制本地化页面,可以为不同地区设计不同的页面
    • 该层以本地化标识为子目录组织 DSL 文件
    • 也可新建包含本地化标识的 DSL 文件,在该 DSL 内继承默认 DSL 或者为全新内容
    • 在读取 DSL 时,自动根据本地化标识查找对应的定制文件
    • 在 DSL 设计过程中,可切换到不同语言后,再调整需要国际化的属性值为对应语言的文本, 即,在对应语言环境下国际化 DSL
    • 优点
      • 各种情况下的实现机制均与普通的差量修改一样,可保证相同机制的贯彻和统一, 特例代码更少,也不需要定义与 I18n 相关的模型
      • 可直接按对应的本地化 DSL 缓存编译结果
      • 无需倾入修改源 DSL,全程可以按默认语言环境编写 DSL, 仅在需要时再统一对其他语言编写国际化差量,在一定程度上能够降低对当前开发进度的影响
      • 不需要考虑对翻译内容的复用问题,对任意一处的修改都不影响其他位置的翻译, 降低对公共内容的维护复杂度
    • 缺点
      • 维护较复杂,需要提供更便利的 IDE 支持
      • 翻译内容的可复用性极低,易出现翻译不一致的问题
  • 在 DSL 中以命名空间 i18n 为需要国际化的属性赋值翻译后的文本
    • 对属性值的翻译也可以直接在 locales 层内以差量方式定制
    • 按树结构抽取出应用了国际化属性的各层级节点,再将国际化后的属性合并到原 DSL 树中, 抽取过程中保留节点的唯一属性(或标签名),以确保可定位到目标节点
    • 优点
      • 只需要两个文件,降低对数据的交叉管理复杂度
      • 翻译内容的位置较为集中,查看和修改都比较方便
      • 对翻译内容的可复用性较高
      • 心智负担较低,不需要依赖 IDE 工具
    • 缺点
      • 对不同情况需要采用不同的机制,逻辑的一致性较低
      • 对源 DSL 有动态修改,不能缓存解析结果
  • 根据某个值动态生成文本的情况,该如何支持对其进行国际化?
  • 后端代码返回给前端的信息若需要国际化,该如何支持?
    • 内容返回 @i18n:xx.x.xx 形式,由前端根据 i18n 字典获取结果?
  • 日志内容的国际化:不需要国际化,通过其唯一标识定位即可
    • 仅输出并保存日志内容的唯一标识及其参数
    • 在做日志分析时,再根据日志内容标识和参数,返回国际化后的内容
common.i18n.xml
<i18n lang="zh">

<trans key="common.confrim">
<zh>确认</zh>
<en>Confrim</en>
</trans>

<trans key="common.app.title">
<zh_CN>渡舟平台</zh_CN>
<en_US>Duzhou Platform</en_US>
</trans>

<trans key="common.hello">
<zh_CN>您好,${name}</zh_CN>
<en_US>Welcome, ${name}</en_US>
</trans>
</i18n>
app.i18n.xml
<i18n x:extends="common.i18n.xml">

<trans key="common.app.title">
<zh_CN>Xxx 管理系统</zh_CN>
</trans>
</i18n>

key 也可以是某种语言的文本内容,直接作为默认的语言文本

app.web.xml
<web xmlns:i18n="i18n"
i18n:use="app.i18n.xml"
>

<site i18n:title="common.app.title" />
</web>
  • 通过 i18n:use 引入 i18n 的定义路径。通过 x:extends 继承公共部分,不需要支持引入多个文件
  • 标注了 i18n 命名空间的属性,表示该属性需要国际化。 在已经有命名空间的属性,则在其值中添加前缀 @i18n: