25 апреля 2010 в 0:59
Есть перевод модуля BBCode c drupaler.ru
При импорте перевода получаем сообщение: "One translation string was skipped because it contains disallowed HTML."
Раскопки выяснили, что ему не нравятся конструкции вида:
которые есть в переводе английского оригинала. Это понятно, ведь при импорте Drupal использует проверку валидации строки:
<?phpfunction 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')));
}?>Куда как видим тэг 's' не входит. Тупой вопрос - а что делать, ведь тэг есть в английском оригинале и перевод НУЖЕН с участием этого тэга?
Тупой ответ - а хрен вам! Не будет русского перевода этой строки! Во всяком случае загруженного штатными инструментами.
Но это ещё не всё интересное!
Также при загрузке перевода, Drupal не нравятся и конструкции вида:
<span style="text-decoration:underline;">текст</span>
Но смотрим список выше и видим, что тэг span там есть. Угу, есть - на жопе шерсть. Если вы используете в тексте перевода:
оно прокатит, но кому нужен тэг span без параметров?
Вот они баги! Править их, разумеется, никто не будет, потому как не будет и всё. Просто тупо.
Точно также тупо утираемся и идём готовить SQL запрос для прогрузки перевода в БД вручную ибо не вижу других способов загрузки так нужного перевода.
Комментарии
Так это разве баг? В описании функции t() вроде так и написано, что сырой html в строках недопустим
Если дать волю пользователю будет вам
<span style="display: block; position: absolute; top: 0; left: 0; width: 2000px; height: 2000px; background: white">текст</span>со всеми вытекающими. Ну или еще хуже onevent javascript приатаченый.А что значит "сырой"?
Тэги em, strong значит не сырые, а тэги u и s сырые?
А логику включения тэга span без параметров кто мне может объяснить?
И самое главное - как быть с переводом-то, если в оригинале всё это есть? Почему в английском оригинале сырой HTML разрешается и он выводится, а в переводе - а вот вам!
Это всё понятно. Но вообще-то переводы загружает не просто пользователь, а админ и предполагается, что он знает что делает, нет? Ну фиг с ним, почему бы не предусмотреть параноидальную галочку типа "отключить проверку при загрузке перевода" для администратора?
Делаешь, для пользователей Filtered HTML. Сам пользуешься Full HTML.
Можно еще Better formats заюзать для полного счастья.
Peritus@drupal.org, вы понимаете О ЧЁМ я говорю?
Какие форматы ввода при загрузке .po файла с переводом?
Тэги <s> и <u> считаются устаревшими, поправьте если не прав. Это во-первых.
А во-вторых, давно пора забыть про инлайн стили и использовать классы. Их ф-ция filter_xss пропустит. Обещаю.
Dan, тэг u возможно и устаревший, согласно htmlbook.ru он "осуждается" разработчиками и рекомендуется заменяться как раз теми стилями которые через span filter_xss не пропускает.
Тэг s устаревшим не считается.
Dan, какие классы в ФАЙЛЕ С ПЕРЕВОДОМ?
В общем как я и говорил:
Ведь это не баг, потому что мы так считаем. И плевать что переводы не грузятся.
Как и не баг то, что я описывал при загрузке .po файла без комментариев, которые по спецификации .po файлов являются необязательными и что так и осталось без ответа:
http://drupal.ru/node/42474
Интересно также,какого хрена они убрали href из поддерживаемых тегов. В 5ке было лучше и удобнее: скажем надо показывать ссылки по языкам или картинки, просто вставляем переводимую фразу и даём в переводах нужный html
Нет, я-то для себя проблему решил. Чтобы каждый раз ручками в базу не лазить я написал маленький патч, который в итоге выглядит так на странице admin/build/translate/import:
[img]http://drupal.ru/files/trhack.jpg[/img]
Вот и всё! Ставлю галочку, патч отключает проверку и ЧИХАЛ Я - загружает всё!
Если брать за источник htmlbook.ru, то:
Для U -- Этот тег осуждается спецификацией HTML, взамен рекомендуется использовать стили.
Для S -- теги и
осуждаются спецификацией HTML, взамен них рекомендуется использовать стили.Вроде оба.
CSS.
<span class="module-class">text</span>. Чем это хуже инлайн-стилей? И как ты собираешься менять инлайн-стили, заданные разработчиком модуля?<s> = <del>
Разрешается указание аттрибутов class, что вполне достаточно.
Хуже тем, что кто-то должен потом догадаться взять .css и куда-то положить или добавить в существующий.
А главное хуже тем, что после загрузки перевода с такими конструкциями, вместо того что должно быть видно - ничего видно не будет.
<s> = <del>
Замену для цветов, шрифтов и прочего, что обеспечивает BBCode назовёте?
И главный вопрос моим оппонентам. Английский вариант, вызывается через t() и прекрасно отображается со всеми этими тэгами. Почему же такие 2-е стандарты? Либо запрещайте везде, либо разрешайте везде. Почему оригинал обрабатывается по одним правилам, а перевод по другим?
Не кто-то, а разработчик. Если разработчик не умеет работать с CSS, - его личные внутренние проблемы. А вот если в тексте будут инлайн-стили (зелёный текст на красном фоне), то придётся затратить на порядок больше телодвижений, чтобы это изменить.
Не работал с модулем BBCode, но если нельзя сделать замену [u] на <span class="text-underline">, то зачем этот модуль?
А вот это наверное баг, что текст не проходит через XSS фильтр.
А ну да. Прямые руки - это баг. Будем выкривлять
Постарайтесь понять одну простую мысль. Да, я понимаю, что в некоторых местах необходима проверка строк на HTML тэги, чтобы не допустить внедрения вредоносных тэгов и тэгов которые сбивают оформление. Но поймите и вы, что перевод загружает не простой пользователь, а пользователь, который имеет некие административные права. Администратор, по моему глубокому убеждению обязан обладать ВСЕМИ ВОЗМОЖНЫМИ полномочиями и возможностями - его не надо ни в чём ограничивать. Если администратор загружает кривой перевод - это его проблема, потому что он должен понимать что к чему - иначе он не администратор. Зато он может его загрузить, что бы там ни было! Всех ситуаций не предусмотреть и не разработчикам решать за администратора сайта как ему этот сайт делать - это не их задача. Их задача - предоставить максимально гибкий и подходящий инструмент для создания сайта. Здесь нет дыры в безопасности, потому что загрузка перевода не доступна обычным пользователям. Точно также как и PHP-фильтр ввода, может быть использован во зло и во благо и это почему-то никого не напрягает!
А если администратор домохозяйка?
Azerot, помощь модуля BBCode кривая. Там много чего криво сделано. Баг репорт есть, только вот желающих написать нормальную инструкцию на английском нет. Оно и понятно - "многабукаф"
А разве Drupal это продукт, ориентированный на домохозяек?
Я не вижу способа нормально написать на английском то, что там изображено в помощи. Т.е. если нужен пример того как это будет выглядеть - нужны полноценные HTML-тэги или предложенный Dan'ом стиль. Но стиль на мой взгляд - это подпорка. Опять же так и не понимаю - зачем?
May be, may be
Разработчик модуля - доверенное лицо. а вот переводчик может быть злоумышленником. Поэтому данная ситуация достаточно логична.
Конкретнее, с чем проблема ?
Вот с этим:
http://drupal.ru/filter/tips/1#filter-bbcode-0
Цвета, размер шрифтов, href, и т.д.
Переводчик не может САМ загрузить тот перевод, который он сделал. Перевод загружает самое доверенное лицо на сайте - администратор или наделённое полномочиями лицо.
Тогда администратор должен иметь отдельный инструментарий для проверки всех текстов на предмет запрещенного кода. Ну так вот Друпал и дает такой инструментарий, только не дает возможность выбрать разрешенные теги. В d7 вроде бы над этим работают.
У вас есть отличная возможность проявить инициативу и предложить свой патч в ядро
Он его имеет - голова на плечах не для того, чтобы туда есть.
Тогда это не инструмент проверки - это инструмент ТУПОГО запрета. Если бы было предупреждение, а затем возможность грузить или нет - я бы согласился.
Кроме того, Друпал почему-то не даёт возможность проверять корректность кода модулей, загружаемых в него, что на мой взгляд в разы опасней. И если вы считаете разработчика модуля доверенным лицом, то советую обратить внимание на работу например такого модуля как wghtml, отмеченного как рекомендованный к d5. Что он сделает с вашей базой данных и сайтом за полгода его использования - это разговор отдельный.
А вы сами пробовали что-либо предложить на d.org? Попробуйте сперва, потом поговорим. Посмотрите сколько багов открытых - какие там патчи в ядро - сперва баги пофиксят пусть.
Мой трекер. Как видите, пробовал, пробую и буду пробовать, так что мимо
Друпал ровно настолько хорош (или плох), насколько его делают таким добровольцы, и это ВЫ в том числе!
Мой опыт пока негативен. Возможно виной недостаточное знание английского.
Было несколько вопросов на форуме (не самых тупых кстати) - ноль внимания.
Один баг мной запощен - две недели тишина.
А по поводу данного вопроса я вряд ли толково на английском смогу объяснить что мне не нравится в данной ситуации и почему её необходимо менять. Тем более, если уж здесь тема воспринимается далеко не однозначно.
- Он его имеет - голова на плечах не для того, чтобы туда есть.
Администратор нужен для управления сайтом, а не работы с переводами. Ты собираешься переводить мультиязычный сайт сам? Например русско-китайский или англо-французкий. Ты полностью доверяешь людям которые будут переводить?
- Кроме того, Друпал почему-то не даёт возможность проверять корректность кода модулей, загружаемых в него, что на мой взгляд в разы опасней.
Как ты себе это представляешь?
И если вы считаете разработчика модуля доверенным лицом,
Я считаю, что разработчик в большинстве случаев более компетентен, чем администратор, на то он и разработчик. Однако это не исключает кривого кода.
Кто его заставляет переводить? Но проверить что загружаешь на сайт кто должен?
Сам переводить на китайский не буду. Но если я человек, который заботится о безопасности сайта, то проверить что же там не понравилось Друпал можно и должно! Но если я считаю, что всё в порядке, то Drupal в свою очередь должен и обязан мне позволить загрузить то, что я решил.
О! Мы на "ты" уже?
Dan, а ты что незнакомые модули сразу в продуктивный сайт устанавливаешь без проверки на тестовом сайте что ли? И доверяешь при это разработчикам? Средствами Drupal это не проверить, так на то и администратор с его умной головушкой, поставить потестить, пройтись по всем менюшкам и ручкам, убедиться, что нигде ничего не пропало и не падает.
— Кто его заставляет переводить? Но проверить что загружаешь на сайт кто должен?
Не, загружать перевод не всегда возможно. Для шлифовки переводов надо давать права на перевод и ставить localization_client. А как только ты даёшь права - сразу теряешь контроль над переводами.
— Но если я считаю, что всё в порядке, то Drupal в свою очередь должен и обязан мне позволить загрузить то, что я решил.
Мне кажется что проблема единична, где ещё она может возникнуть? Может проще изменить модуль bbcode?
— Dan, а ты что незнакомые модули сразу в продуктивный сайт устанавливаешь без проверки на тестовом сайте что ли?
Ручная проверка это понятно, я не понимаю что ты подразумеваешь под "Друпал ... не даёт возможность проверять корректность кода модулей, загружаемых в него".
Так дайте выбор администратору! ВЫБОР понимаешь? Не тупой запрет, что нельзя, а выбор решить можно или нет!
А мне кажется, что проблема может встретится и в других местах, особенно в хелпах к модулям, которые предоставляют дополнительные форматы ввода. Да и в самих переводах местами хочется что-то выделить красным, а как? Стили каждый раз свои рисовать - это подпорки.
Вот и мне понятно! И поэтому если я руками проверил и решил, что мне надо, Друпал должен позволить мне это сделать! Хотя бы потому что мне в данном случае видней, чем разработчикам.