Комментарии 25
Спасибо за статью. А в чём отличие от того же PolyglotJS?
+2
А вы сможете ввести в Polyglot такую фразу: «Мы поймали #{a_count} ((окуня|окуней)):a_count и #{b_count} ((плотвиху|плотвихи|плотвих))»? Да и поддержка плюрализации там, похоже, не по UCDR.
В Locale::Babelfish, например, "#{count}, не меньше!" преобразуется в код sub { return params->{count}. ", не меньше"; }->(count => 5), без всяких регулярок.
В Locale::Babelfish, например, "#{count}, не меньше!" преобразуется в код sub { return params->{count}. ", не меньше"; }->(count => 5), без всяких регулярок.
+2
А насколько востребованы такие сложные шаблоны формата? Я это к чему: в действительности у нас есть DOM. Обычно интерактивные элементы (типо счётчиков) находятся в собственных элементах и манипуляция с ними производится какой-то MV-либой, либо аналогичным ей самописным участком в кодобазе. То есть на практике может стать так, что нам нужно максимум зарегать функции из такой локализационной либы в качестве фильтров в MV.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
0
Интересная статья, спасибо. А как вы решили проблему наличия html кода во фразе? Например вам нужно локализировать
Привет, <a href='/user/'>#{username}</a>
эта фраза целиком пойдет в yaml файл в таком виде? Спасибо0
мы предпочитаем Markdown-разметку.
Или как-то так. Никто не мешает вставлять и HTML, но не одобряется.
Посмотрите демку: regru.github.io/babelfish-demo/
Привет, (/user/)[#{username}]
Или как-то так. Никто не мешает вставлять и HTML, но не одобряется.
Посмотрите демку: regru.github.io/babelfish-demo/
+3
А инструменты переводчика есть готовые?
0
Подходят те, что для мира Rails, например, www.localeapp.com/, webtranslateit.com/en, www.smartling.com/, 99translations.com/.
Сейчас есть задача по созданию инструмента на Node.JS, но пока не дошли до.
Сейчас есть задача по созданию инструмента на Node.JS, но пока не дошли до.
+1
Расскажите, как осуществляется подстановка одних кусков фраз в другие, когда обе содержат разметку? Как осуществляется экранирование спецсимволов, в том числе при подстановке пользовательских данных и одних кусков фраз в другие?
Например,
или,
Например,
// locale:
{ "inner": "<span class="b-inner">**italic**</span>", "outer": "<span class="b-outer">#{inner}</span>" }
// translation:
window.t("outer");
или,
// locale:
{ "outer": "<span class="b-outer">#{user_data}</span>" }
// translation:
window.t("outer", { "user_data": "<script>alert(document.cookie)</script>" });
+1
Метод t имеет опциональный параметр с объектом-хэшем переменных (любой вложенности).
Тут вызываем t('outer', { inner: t('inner'));
Тут вызываем t('outer', { inner: t('inner'));
+1
Спасибо, это я понимаю. Вопрос был про экранирование разметки при таком вкладывании переводов друг в друга.
0
Не совсем понял вопроса. У нас в словарях обычно нет HTML-разметки, только markdown и подстановки переменных. Даже типографика и то отрабатывается автоматически.
+1
Обычно — нет. А если всё-таки есть?
Приведу пример из жизни. Пользователю в веб-приложении отображается инструкция к части его интерфейса, структура инструкции задается в файле перевода (то есть код, выводящий строку с инструкцией, не знает, какая именно инструкция там написана). В этой инструкции присутствует изображение кнопки, которое должно в точности соответствовать внешнему виду кнопки в веб-приложении. Стиль кнопки задается CSS-темой оформления, которых множество, то есть скриншотить кнопку и вставлять картинку каждый раз, когда меняется или добавляется новая тема — не вариант. Соответственно, нужно вставить кусок разметки, представляющий собой кнопку, к которой автоматически применятся стили темы. Этот сценарий как-то предусмотрен?
Второй пример из жизни: вывод данных, введенных пользователем, в подстановке. Данные пользователя теоретически могут содержать разметку, которую нужно экранировать. На каком уровне вы это делаете? Экранируете ли от разметки всё, что попадает в подстановку? Тогда как избегаете двойного экранирования при вложенных подстановках?
Спасибо.
Приведу пример из жизни. Пользователю в веб-приложении отображается инструкция к части его интерфейса, структура инструкции задается в файле перевода (то есть код, выводящий строку с инструкцией, не знает, какая именно инструкция там написана). В этой инструкции присутствует изображение кнопки, которое должно в точности соответствовать внешнему виду кнопки в веб-приложении. Стиль кнопки задается CSS-темой оформления, которых множество, то есть скриншотить кнопку и вставлять картинку каждый раз, когда меняется или добавляется новая тема — не вариант. Соответственно, нужно вставить кусок разметки, представляющий собой кнопку, к которой автоматически применятся стили темы. Этот сценарий как-то предусмотрен?
Второй пример из жизни: вывод данных, введенных пользователем, в подстановке. Данные пользователя теоретически могут содержать разметку, которую нужно экранировать. На каком уровне вы это делаете? Экранируете ли от разметки всё, что попадает в подстановку? Тогда как избегаете двойного экранирования при вложенных подстановках?
Спасибо.
0
первый пример — чистка пользовательского ввода (sanitize) идет еще до попадания данных в базу. более того, современные интерфейсы внедряемые рассчитаны на ввод markdown вместо html.
второй пример — экранируется обычно весь результат уже после трансляции (возможно, перед процесссингом в Markdown), если так надо.
второй пример — экранируется обычно весь результат уже после трансляции (возможно, перед процесссингом в Markdown), если так надо.
+1
чистка пользовательского ввода (sanitize) идет еще до попадания данных в базу
А если данные из стороннего API и не известно, были ли они очищены?
экранируется обычно весь результат
Вместе с нужной разметкой, которая была в переводах? (см. пример с кнопкой)
Спасибо. Извините, что докучаю, но вопросы системного характера, хотелось бы понимать, есть ли системные решения, или каждый отдельный случай нужно огораживать костылем.
0
Например, по нашим правилам некоторые ссылки должны иметь rel=«nofollow» class=«b-link» target="_blank". Это все описывается в конфиге БЭМ, и некий БЭМ-фильтр согласно конфигу накладывает эти атрибуты на срендеренный HTML. Опять-таки без необходимости вводить это все вручную.
+1
Есть еще github.com/twitter/twitter-cldr-js (на его основе я написал враппер для своего приложения, в виде MyApp.tt(...) ) могу выложить gist, если интересно.
+2
github.com/nodeca/babelfish/issues/24
Для ангуляра никто не оборачивал?
Для ангуляра никто не оборачивал?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BabelFish — полиглот в мире JavaScript