angularjs – 前端vs后端本地化策略比较

我们正在开发一个非常庞大的Angular.js SPA应用程序,它也支持i18n.首先我们使用完整的前端本地化(如果我记得正确的this one)

但是当应用程序变得越来越大时,管理i18n文件,将它们加载到页面中变得很麻烦(你只需要加载所需的字符串,因为i18n文件很大！)等等.

此外,用户很少会改变语言,它不需要动态,快速,双向绑定或其他任何东西.如果我们重新加载整个应用程序就可以了.

所以我们想为什么？我们在前端不需要i18??n.我们在“app”中需要i18??n.然后,我在node.js上编写了一个构建系统,基本上它是一个预处理器,它解析我们拥有的所有* .html和* .js文件,从中提取字符串,使用i18n文件查找它们,放置本地化字符串并创建每种语言计数的文件副本.

基本上,我们创建n个应用而不是1个,所有这些都是以编程方式生成的,每个都使用不同的语言.

它工作得很好.当用户更改语言时,我们重新加载页面并包含另一个本地化文件集,并且语言被更改！

示例源html文件：

<header>@message("string.to.be.localized.1"i "{{name}}")</header>

示例js文件：

angular.module("app",[])
  .directive("x",function(i18n) {
    return {
      templateUrl: "@HTML/templates/a.html",link: function() { console.log(i18n("string.in.js","Umut")); }
    }
  })

编译后：

source.en.html

<header>Hello {{name}}</header>

source.tr.html

<header>Merhaba {{name}}</header>

sample.en.js

angular.module("app",function(i18n) {
    return {
      templateUrl: "/templates/a.en.html",link: function() { console.log("Hello {0}","Umut")); }
    }
  })

sample.tr.js

angular.module("app",function(i18n) {
    return {
      templateUrl: "/templates/a.tr.html",link: function() { console.log("Merhaba {0}","Umut")); }
    }
  })