在页面加载和大小方面,javascript中的翻译策略

时间:2013-12-20 17:26:20

标签: javascript json underscore.js translation

我有一个与其他API对话的JS应用程序。没有服务器端处理javascript,即服务器端没有模板生成。

我对大约30个资源有大约50个视图。资源有5-6个属性(平均10%),如“名称”,“作者”,“总数”,“金额”等。

我使用通用编译模板(下划线)进行渲染。如下所示 -

<dl>
  <% _.each(schema, function(attr, key){ %>
    <dt><%= attr.title %></dt>
    <dd><%= data[key] %></dd>
  <% }) %>
</dl>

我需要将这些标题本地化。

遵循两种翻译策略对我来说没有多大意义 1.使用一些DOM操作插件后渲染将字符串转换为本地化字符串[因为我首先使用JS进行渲染,为什么在渲染后有额外的代码来转换字符串]

  1. 为不同的资源使用不同语言的不同模板。 [我不喜欢为15种不同的语言设置50种不同的模板]
  2. 我正在使用语言文件(基本上是包含属性键的本地化字符串的JSON文件),我有以下权衡要做 -

    首选 为单独的视图/资源保留单独的语言文件(json中的对象)

    • 这具有快速查找的优点,我可以简单地将语言文件与我的架构对象合并。
    • 但缺点是重复常用键,例如'name','total'

    第二选择 有一个包含所有键的大文件   - 这具有尺寸和避免重复的优点,但我需要执行键的查找

    第三选择具有公用密钥的通用文件,并且针对资源特定密钥分开。但这种失败检查查询再次昂贵。

    **在所有这些中,我确实需要一些通用文件,例如“你确定”,“是”,“否”等字符串 **上面的文件我的意思是不同的结构,它可以来自不同的文件到包管理器和JS。但一旦处理完毕,它们本质上就是不同

    考虑资源/视图编号以及每个资源/视图的属性是可变的并且取决于登录用户,哪种选择更好。

    或者我正在做一些可怕的错误。

    **也适用于笔记 - 它是一个backbone.js app。

0 个答案:

没有答案