【问题标题】:why store internationalization "words" in separate (xml) files?为什么将国际化“单词”存储在单独的(xml)文件中?
【发布时间】:2011-05-11 03:09:26
【问题描述】:

我一直在阅读有关人们如何进行国际化的一些信息。似乎普遍的共识是将这些字符串保存在一个单独的文件(通常是 xml)中,并在必要时加载它。

我想知道为什么不直接将这些字符串存储在数据库中呢?这样不是更好吗?

顺便说一句,我的应用本质上是一个网站应用。

【问题讨论】:

  • 使用 xml 文件要容易得多(我的意思是在我们翻译的时候)

标签: c# java javascript .net


【解决方案1】:

最重要的是将字符串表存储在编译单元之外,以便合并更新的翻译不需要重新构建。这允许在以后合并新的或更新的翻译,而不会有太多麻烦。

当然,这些字符串表可以存储在任何地方。如果您想将它们放入数据库中,请自行淘汰。只要您的申请可以到达他们那里,并且您的翻译人员知道如何将它们交付到正确的地方,就没有什么不同。

【讨论】:

    【解决方案2】:

    Serious Internationalization 始终是一个涉及很多部分和参与者的大项目。正如@zerkms 所暗示的那样,翻译任务通常是由世界各地的个人和团队进行的离线活动。

    因此,拥有一个翻译团队可以生成的干净的工作产品(翻译后的 XML 文件)是有意义的。

    文件翻译完成后,您可以自行决定如何处理软件中的翻译。将它们保存在内存中很常见,因为您经常需要将变量替换为占位符。

    【讨论】:

      【解决方案3】:

      如果您确实存储在数据库中,那么每次“区域设置”切换时都会引入额外的查询数据库的开销。

      这就是资源包的原因。您将它与源代码一起打包,但您不必更改代码以添加对语言的支持。

      您也可以自己子类化 resourcebundle 类并实现 jdbc 支持,以便将特定于语言环境的字符串存储在数据库中。

      http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/

      【讨论】:

      • 我的意思是这个问题不是专门针对java的
      • 顺便说一句,当我访问外部 xml 文件时不会有开销吗?
      • 在启动时将翻译文件加载到程序内存或内存缓存中。两者都比使用 dbms 更好。
      猜你喜欢
      • 2023-01-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-02-25
      • 2022-12-21
      • 2013-08-27
      • 1970-01-01
      相关资源
      最近更新 更多