2. Баг при импорте перевода из .po файлов, касающийся использования HTML-тэгов
Как известно, Drupal позволят импортировать перевод с помощью загрузки специальных .po файлов. В данных файлах типичными являются строковые группы вида:
#: includes/common.inc:2722 msgid "Cron run exceeded the time limit and was aborted." msgstr "Выполнение cron было прервано, потому что был исчерпан лимит времени на запуск."
Разумеется, что сообщения, которые нуждаются в переводе, в отличие от вышеприведённого примера, могут быть очень разными. Проблема возникает с сообщениями, которые содержат HTML-тэги, которые признаны разработчиками Drupal как небезопасные. Это хорошо можно увидеть на примере перевода помощи к модулю BBCode. Помощь содержит примеры, демонстрирующие возможности форматирования текста с помощью BB-кодов. Для того, чтобы показать пользователю как будет выглядеть отформатированный текст, используются HTML-тэги. В английском варианте вы всё видите без проблем, но загрузка русского перевода к этому модулю завершится с сообщением: "One translation string was skipped because it contains disallowed HTML." (Одна строка с переводом была пропущена, потому что она содержит неразрешённый HTML)
Раскопки исходников Drupal показывают, что при загрузке перевода, используется проверка загружаемых строк на допустимость с помощью функции:
<?php
function locale_string_is_safe($string) {
return decode_entities($string) == decode_entities(filter_xss($string, array('a', 'abbr', 'acronym', 'address',
'b', 'bdo', 'big', 'blockquote', 'br', 'caption', 'cite', 'code', 'col', 'colgroup', 'dd', 'del', 'dfn', 'dl',
'dt', 'em', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr', 'i', 'ins', 'kbd', 'li', 'ol', 'p', 'pre', 'q', 'samp',
'small', 'span', 'strong', 'sub', 'sup', 'table', 'tbody', 'td', 'tfoot', 'th', 'thead', 'tr', 'tt', 'ul',
'var')));
?>что автоматически приводит к невозможности использования в переводах HTML-тэгов, которые в ней не перечислены. Более того, хотя тэг span присутствует в этом списке, он проходит только если используется без параметров, т.е.
<span>текст</span>
что автоматически делает его бесполезным.
В общем-то, в какой-то степени, причина такой фильтрации понятна - разработчики постарались закрыть потенциальную брешь в безопасности, когда может быть использован вредносный HTML, содержащий JavaScript или такие настройки стилей, которые исказят оформление сайта. Однако, тут есть два больших НО:
- Почему же в оригинальном английском тексте допускаются все HTML-тэги, а в переводе нет? Почему такой двойной стандарт?
- Даже с учётом потенциальных проблем с небезопасным HTML, перевод загружает администратор сайта, а не рядовой пользователь! Администратор сайта должен осознавать потенциальные угрозы и сам производить проверку.
Но как же быть если перевод с использованием запрещённых HTML-тэгов всё-таки нужен? Ведь в итоге, разработчики Drupal не оставили никакого выбора - тупой запрет и всё! Выходов несколько:
- Прямая прогрузка перевода в базу данных с помощью SQL-запроса. Да, такой путь позволяет избежать изменения файлов самого Drupal, однако уж очень он неудобен.
- Использовать специальный, написанный мной патч к Drupal, приложенный к данной публикации. Использование этого патча добавляет на страницу импорта перевода admin/build/translate/import, дополнительную галочку, позволяющую отключить проверку валидности HTML-тэгов:
После этого вы можете загружать перевод, содержащий любые HTML-тэги.
Вопрос о данном баге даже смысла поднимать нет - он вряд ли будет поправлен, потому что разработчики всегда лучше нас знают как и что мы должны делать, часто не оставляя нам ни права выбора ни права голоса.
| Вложение | Размер |
|---|---|
| trhack.jpg | 27.19 kb |
| locale.inc_.patch | 1.57 kb |
- Тэги:
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии