Локализация шаблонов на клиенте в AngularJS

[Fesor]

Меня все же немного смущает такой способ… как минимум если используются штуки типа html2js для сборки своего $templateCache, то это работать не будет. Опять же не вижу профита именно в подобном переводе темплейтов на стороне клиента, когда их можно один раз собрать на сервере в свои папочки и при помощи декораторов, например, над сервисом $sce, менять урл темплейта в зависимости от локали.

Мне больше нравится комбинация из фильтра translate. Для себя я просто написал отдельный модуль который подключает нужный мне $templateCache в зависимости от локали, а вьюшки уже собираются через grunt.

[symbix]

… использовать стандартные возможности выражений с фильтрами…
{{ 'some_english_string' | translate }}

Это, конечно, неудобно, и накладывает перечисленные ограничения. Но это можно делать директивой, и тот же angular-translate это умеет.

Что касается digest loop — а как без него сделать обновляемый без перекомпиляции plural gettext (1 файл, 2 файла, 10 файлов)?

[Helios1138]

Ну как вариант, механизм плюрализации и механизм перевода могут идти отдельно. То есть плюрализация-то достигается с помощью директивы или фильтра, но исходные данные (корень слова или разные слова на разные множители — не вдавался в подробности реализации) подставлять в нее можно уже переведенные. Это уже как словарь организуешь.

__lang.ru = {
  'file': 'файл',
  'file_plural': {
    1: 'файл',
    2: 'файла',
    more: 'файлов',
  }
}

<span some-pluralization-directive="<%= t('file_plural') %>" number-of="2"></span>

И, например, при переводе шаблонов, если перевод является объектом — функцией t() возвращать json-строку, а из директивы ее же $eval()-ом обратно превращать в объект и уже использовать эти данные для преобразования.

link: function(scope, $elem, attrs){
  attrs.$observe('somePluralizationDirective', function(attrValue){    
    var pluralData = scope.$eval(attrValue);
    // дальше идет логика плюрализации
  });
}

[Fesor]

Так а чем плох вариант через тот же underscore генерить уже обработанные шаблоны при сборке проекта? Ибо выносить это на клиент как-то совсем нелогично — операция может быть выполнена один раз.

[Helios1138]

Ну я не говорил, что этот способ однозначно лучше или хуже. Есть свои плюсы и минусы. Просто, как я сказал в посте — на том конкретном проекте как-таковой серверной части не предполагалось вовсе, только веб-хост для самого приложения. И если клиенту, допустим, нужно будет поменять что-то в переводе — возмонжости пересобирать шаблоны у него не будет, разве что только вручную редактировать. Править один файл словаря все же легче.

[rushman]

мы у себя используем директивы такого вида:

angular.module('app').directive('i18n', function(i18n) {
    return {
        restrict: 'A',
        link: function(scope, elem, attrs) {
            elem.removeAttr('i18n');
            var orig = elem.html();
            orig = orig.replace(/^\s+|\s+$/g, ''); // trim
            elem.html(i18n(orig));
            scope.$on('i18n:language_changed', function() {
                elem.html(i18n(orig));
            });
        }
    };
});

Плюрализация легко добавляется.

[tamtakoe]

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