Сравнение локальной и внутренней стратегий локализации

Я разрабатываю приложение, основанное на интерфейсах Sails JS и интерфейсах Web и Mobile. Мои планы для интерфейсных фреймворков заключаются в следующем:

Web fronend - AngularJS + Bootstrap
Мобильный интерфейс - AngularJS + Ionic с более поздним портом от Apache Cordova

Что касается приведенного выше краткого объяснения, я должен добавить функцию локализации в приложение. И вот здесь возникает мой вопрос - поскольку обе Sails JS и AngularJS поддерживают локализацию, какой из них подходит для моего проекта?

Теоретически я могу иметь:

полная локализация - я буду использовать встроенные возможности Sails JS и поместим все локализованные ресурсы в виде json файлов на бэкэнд
полная локализация интерфейса - я мог бы добавить надстройки и локализовать интерфейсы AngularJS на интерфейсе или
смешивание внутренних и локальных локализаций.

Я был бы признателен, если бы люди с большим опытом работы подробно обсудили эту тему, рассмотрев архитектуру приложений и предоставив мне некоторое просвещение о возможных плюсах и минусах доступных опций.

Ответ 1

Я предпочитаю что-то вроде 1.

Мы работаем над довольно огромным приложением Angular.js SPA, которое также поддерживает i18n. Сначала мы использовали полную локальную локализацию (если я правильно помню этот)

Но когда приложение стало больше и больше, стало сложно управлять файлами i18n, загружая их на страницу (и вам нужно всего лишь загрузить нужные строки, потому что файл i18n огромен!) и т.д.

Кроме того, пользователь редко меняет язык, ему не нужно быть динамичным, быстрым, двусторонним или другим. Это нормально, если мы перезагружаем все приложение.

Так почему мы думали? Нам не нужно i18n в интерфейсе. Нам нужно 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")); }
    }
  })

Ответ 2

Я предпочитаю интерфейсную локализацию. На серверной части вы можете выбросить любое исключение, которое содержит код исключения и пояснения на английском языке - это для разработчиков. Во внешнем интерфейсе вы можете использовать каждый файл JSON (или другой) для каждого языка локализации на основе кодов, которые вы получили от внутреннего интерфейса или на основе логики архитектуры вашего внешнего интерфейса.

Почему я нахожу интерфейсную локализацию лучше - потому что интерфейс ближе к пользователю, чем сервер, и вы можете предоставить ему пакет ваших файлов одним файлом локализации его языка. Поскольку внешнее приложение может вызывать несколько внутренних операций в одной или даже из нескольких служб (как внутренних, так и внешних), локализация сообщений является избыточной, поскольку пользователь должен получить любое понятное и лояльное к пользователю сообщение (но не любое). например, "невозможно вставить данные в таблицу" или "внешний сервер не отвечает") - вы игнорируете это сообщение и предоставляете свое. Более того, в наши дни бэк-энд написан для связи со многими другими службами (не людьми), и локализация здесь избыточна, поскольку каждый разработчик понимает английский.