前端与后端本地化战略比较

时间:2015-02-26 07:13:21

标签: angularjs twitter-bootstrap cordova sails.js ionic-framework

我正在开发基于Sails JS后端和Web和Mobile前端的应用程序。我对前端框架的计划是:

  • Web fronend - AngularJS + Bootstrap
  • 移动前端 - AngularJS + Ionic,后来来自Apache Cordova的端口

关于上面的简要说明,我必须在应用程序中添加本地化功能。这就是我的问题出现 - 因为Sails JS和AngularJS都支持本地化,哪一个可以为我的项目提取?

理论上我可以:

  1. 完成后端本地化 - 我将使用Sails JS功能构建并将所有本地化资源作为json文件放到后端
  2. 完整的前端本地化 - 我可以在前端添加AngularJS附加组件和本地化接口或
  3. 混合后端和前端本地化。
  4. 如果有更多实践经验的人详细讨论该主题,考虑应用程序架构,并对可用选项的可能优缺点给予一些启示,我将不胜感激。

3 个答案:

答案 0 :(得分:4)

我更喜欢像1这样的东西。

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

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

此外,用户很少会更改语言,也不需要动态,快速,双向绑定或其他任何内容。如果我们重新加载整个应用程序就行了。

所以我们想为什么?我们在前端不需要i18​​n。我们需要在我们的应用程序中使用i18n。然后,我在node.js上编写了一个构建系统,基本上它是一个预处理器,它解析我们拥有的所有*.html and *.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", [])
  .directive("x", function(i18n) {
    return {
      templateUrl: "/templates/a.en.html",
      link: function() { console.log("Hello {0}", "Umut")); }
    }
  })

sample.tr.js

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

答案 1 :(得分:3)

我更喜欢后端本地化,因为:

我仍然觉得有角的i18n还不成熟,无法像没有代码转换一样处理所有用例(直到有角8)。到现在为止 用于静态数据,但不用于动态数据(错误来自服务器端)。如果我们使用占位符,则在我们的静态数据中使用了复数形式,因此 了解其翻译文件,无法翻译材料,ng bootstrap等库。

如果我们使用后端本地化,也许我们将无法解决所有这些情况,并且用户几乎没有更改其语言环境,因此可以一次重新加载应用程序(尽管使用angular i18n,我们仍然必须重新在运行时引导应用程序)

答案 2 :(得分:1)

我更喜欢前端本地化。 在后端,您可以引发任何包含英语异常代码和解释的异常-这些是针对开发人员的。在前端,您可以将每种JSON(或其他)文件用于每种基于本地化语言的代码,这些代码是从后端获取的代码,或者基于前端的体系结构逻辑。

为什么我觉得前端的本地化更好-因为前端比后端的User更近,并且您可以为他提供一批带有本地化语言的文件。由于前端应用程序可以在自己的应用程序中调用多个后端操作,甚至可以从多个服务(内部或外部)调用,因此消息的本地化是多余的,因为用户必须获得任何可理解且用户忠诚的消息(但不能获得任何消息)例如“无法将数据插入表中”或“外部服务器无法回答”)-您会忽略该消息并提供您的消息。更重要的是-如今,后端被编写为与许多其他服务(而非人员)联系,并且本地化在这里是多余的,因为每个开发人员都懂英语。