Комментарии 25
Спасибо за статью. А в чём отличие от того же PolyglotJS?
А вы сможете ввести в 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), без всяких регулярок.
А насколько востребованы такие сложные шаблоны формата? Я это к чему: в действительности у нас есть DOM. Обычно интерактивные элементы (типо счётчиков) находятся в собственных элементах и манипуляция с ними производится какой-то MV-либой, либо аналогичным ей самописным участком в кодобазе. То есть на практике может стать так, что нам нужно максимум зарегать функции из такой локализационной либы в качестве фильтров в MV.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
Интересная статья, спасибо. А как вы решили проблему наличия html кода во фразе? Например вам нужно локализировать
Привет, <a href='/user/'>#{username}</a>
мы предпочитаем Markdown-разметку.
Или как-то так. Никто не мешает вставлять и HTML, но не одобряется.
Посмотрите демку: regru.github.io/babelfish-demo/
Привет, (/user/)[#{username}]
Или как-то так. Никто не мешает вставлять и HTML, но не одобряется.
Посмотрите демку: regru.github.io/babelfish-demo/
А инструменты переводчика есть готовые?
Подходят те, что для мира Rails, например, www.localeapp.com/, webtranslateit.com/en, www.smartling.com/, 99translations.com/.
Сейчас есть задача по созданию инструмента на Node.JS, но пока не дошли до.
Сейчас есть задача по созданию инструмента на Node.JS, но пока не дошли до.
Расскажите, как осуществляется подстановка одних кусков фраз в другие, когда обе содержат разметку? Как осуществляется экранирование спецсимволов, в том числе при подстановке пользовательских данных и одних кусков фраз в другие?
Например,
или,
Например,
// 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>" });
Метод t имеет опциональный параметр с объектом-хэшем переменных (любой вложенности).
Тут вызываем t('outer', { inner: t('inner'));
Тут вызываем t('outer', { inner: t('inner'));
Спасибо, это я понимаю. Вопрос был про экранирование разметки при таком вкладывании переводов друг в друга.
Не совсем понял вопроса. У нас в словарях обычно нет HTML-разметки, только markdown и подстановки переменных. Даже типографика и то отрабатывается автоматически.
Обычно — нет. А если всё-таки есть?
Приведу пример из жизни. Пользователю в веб-приложении отображается инструкция к части его интерфейса, структура инструкции задается в файле перевода (то есть код, выводящий строку с инструкцией, не знает, какая именно инструкция там написана). В этой инструкции присутствует изображение кнопки, которое должно в точности соответствовать внешнему виду кнопки в веб-приложении. Стиль кнопки задается CSS-темой оформления, которых множество, то есть скриншотить кнопку и вставлять картинку каждый раз, когда меняется или добавляется новая тема — не вариант. Соответственно, нужно вставить кусок разметки, представляющий собой кнопку, к которой автоматически применятся стили темы. Этот сценарий как-то предусмотрен?
Второй пример из жизни: вывод данных, введенных пользователем, в подстановке. Данные пользователя теоретически могут содержать разметку, которую нужно экранировать. На каком уровне вы это делаете? Экранируете ли от разметки всё, что попадает в подстановку? Тогда как избегаете двойного экранирования при вложенных подстановках?
Спасибо.
Приведу пример из жизни. Пользователю в веб-приложении отображается инструкция к части его интерфейса, структура инструкции задается в файле перевода (то есть код, выводящий строку с инструкцией, не знает, какая именно инструкция там написана). В этой инструкции присутствует изображение кнопки, которое должно в точности соответствовать внешнему виду кнопки в веб-приложении. Стиль кнопки задается CSS-темой оформления, которых множество, то есть скриншотить кнопку и вставлять картинку каждый раз, когда меняется или добавляется новая тема — не вариант. Соответственно, нужно вставить кусок разметки, представляющий собой кнопку, к которой автоматически применятся стили темы. Этот сценарий как-то предусмотрен?
Второй пример из жизни: вывод данных, введенных пользователем, в подстановке. Данные пользователя теоретически могут содержать разметку, которую нужно экранировать. На каком уровне вы это делаете? Экранируете ли от разметки всё, что попадает в подстановку? Тогда как избегаете двойного экранирования при вложенных подстановках?
Спасибо.
первый пример — чистка пользовательского ввода (sanitize) идет еще до попадания данных в базу. более того, современные интерфейсы внедряемые рассчитаны на ввод markdown вместо html.
второй пример — экранируется обычно весь результат уже после трансляции (возможно, перед процесссингом в Markdown), если так надо.
второй пример — экранируется обычно весь результат уже после трансляции (возможно, перед процесссингом в Markdown), если так надо.
чистка пользовательского ввода (sanitize) идет еще до попадания данных в базу
А если данные из стороннего API и не известно, были ли они очищены?
экранируется обычно весь результат
Вместе с нужной разметкой, которая была в переводах? (см. пример с кнопкой)
Спасибо. Извините, что докучаю, но вопросы системного характера, хотелось бы понимать, есть ли системные решения, или каждый отдельный случай нужно огораживать костылем.
Например, по нашим правилам некоторые ссылки должны иметь rel=«nofollow» class=«b-link» target="_blank". Это все описывается в конфиге БЭМ, и некий БЭМ-фильтр согласно конфигу накладывает эти атрибуты на срендеренный HTML. Опять-таки без необходимости вводить это все вручную.
Есть еще github.com/twitter/twitter-cldr-js (на его основе я написал враппер для своего приложения, в виде MyApp.tt(...) ) могу выложить gist, если интересно.
github.com/nodeca/babelfish/issues/24
Для ангуляра никто не оборачивал?
Для ангуляра никто не оборачивал?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BabelFish — полиглот в мире JavaScript