Comments 8
Меня все же немного смущает такой способ… как минимум если используются штуки типа html2js для сборки своего $templateCache, то это работать не будет. Опять же не вижу профита именно в подобном переводе темплейтов на стороне клиента, когда их можно один раз собрать на сервере в свои папочки и при помощи декораторов, например, над сервисом $sce, менять урл темплейта в зависимости от локали.
Мне больше нравится комбинация из фильтра translate. Для себя я просто написал отдельный модуль который подключает нужный мне $templateCache в зависимости от локали, а вьюшки уже собираются через grunt.
Мне больше нравится комбинация из фильтра translate. Для себя я просто написал отдельный модуль который подключает нужный мне $templateCache в зависимости от локали, а вьюшки уже собираются через grunt.
0
… использовать стандартные возможности выражений с фильтрами…Это, конечно, неудобно, и накладывает перечисленные ограничения. Но это можно делать директивой, и тот же angular-translate это умеет.
{{ 'some_english_string' | translate }}
Что касается digest loop — а как без него сделать обновляемый без перекомпиляции plural gettext (1 файл, 2 файла, 10 файлов)?
+1
Ну как вариант, механизм плюрализации и механизм перевода могут идти отдельно. То есть плюрализация-то достигается с помощью директивы или фильтра, но исходные данные (корень слова или разные слова на разные множители — не вдавался в подробности реализации) подставлять в нее можно уже переведенные. Это уже как словарь организуешь.
И, например, при переводе шаблонов, если перевод является объектом — функцией t() возвращать json-строку, а из директивы ее же $eval()-ом обратно превращать в объект и уже использовать эти данные для преобразования.
__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);
// дальше идет логика плюрализации
});
}
0
Так а чем плох вариант через тот же underscore генерить уже обработанные шаблоны при сборке проекта? Ибо выносить это на клиент как-то совсем нелогично — операция может быть выполнена один раз.
0
Ну я не говорил, что этот способ однозначно лучше или хуже. Есть свои плюсы и минусы. Просто, как я сказал в посте — на том конкретном проекте как-таковой серверной части не предполагалось вовсе, только веб-хост для самого приложения. И если клиенту, допустим, нужно будет поменять что-то в переводе — возмонжости пересобирать шаблоны у него не будет, разве что только вручную редактировать. Править один файл словаря все же легче.
0
мы у себя используем директивы такого вида:
Плюрализация легко добавляется.
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));
});
}
};
});
Плюрализация легко добавляется.
0
Первый способ не всегда плох. Например, у меня в админках подгружаются все языки (пример) и отображаются через фильтр, чтобы можно было включить несколько языков сразу (удобно при переводе). Гость же получает всегда только один язык и чтобы переключиться нужно перезагрузить страницу. шаблон всегда один и тот же, слова присылаются сервером отдельно. Поэтому, нужно всего лишь два шаблона: для админки и обычный.
0
Лично мне понравилось это решение
0
Sign up to leave a comment.
Локализация шаблонов на клиенте в AngularJS