Full HTML Blocks cannot be translated
sun - February 2, 2009 - 21:28
| Project: | Internationalization |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | duplicate |
Description
Translating blocks containing advanced HTML with i18n is impossible. The reason is locale_string_is_safe() in locale.inc:
<?php
/**
* Check that a string is safe to be added or imported as a translation.
*
* This test can be used to detect possibly bad translation strings. It should
* not have any false positives. But it is only a test, not a transformation,
* as it destroys valid HTML. We cannot reliably filter translation strings
* on inport becuase some strings are irreversibly corrupted. For example,
* a & in the translation would get encoded to &amp; by filter_xss()
* before being put in the database, and thus would be displayed incorrectly.
*
* The allowed tag list is like filter_xss_admin(), but omitting div and img as
* not needed for translation and likely to cause layout issues (div) or a
* possible attack vector (img).
*/
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')));
}
?>Which means - no images, no DIVs, or any other extended HTML markup. AFAICS, this is a major design flaw in i18n's current translation method for blocks.
I am very surprised that there is no existing issue in the queue. (I searched extensively)
#1
Same here! When translating a block using the interface translator I get an error that there is unallowed html in my block!
#2
In general, this is a duplicate of #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups.
However, I'd like to keep this issue open until the core issue has been fixed in Drupal 6.x, because I believe that most users are not able to dig into the actual code like I was.
#3
I've applied the locale.inc patch...but it doesn't seem to solve my problem. I'm am translating a page which has javascript (insert of flash xml slideshow) and it won't display on the translated page - so I'm assuming the code isn't being allow. Any ideas on a way to fix this?
Example: http://cima.laurelterlesky.ca/shipping-logistics (english works fine / spanish won't display)
#4
Three possible solution without patching the core:
locale_translate_edit_form_validatecall.This would apply to simple site where the admin needs to translate and doesn't have to care about other people messing the HTML.
I guess should be 80% of small sites.
locale_translate_edit_form_validate.You have to think before submit so could be useful in some case. The best thing is that you'll have a reminder of the allowed code (filter) below the translation box.
locale_translate_edit_form_validateonly for blocks that are in check_plain state, otherwise it allows anything. You'll have the allowed code (filter) in this case too.Patches attached.
BTW even when the patch will be applied to the core could be useful to have the format applied to the block...
#5
thanx on patches, i needed them. its logical that block would have HTML so this must be in core. great work :-)
#6
Is it possible to have PHP in translations also? As i have some blocks that have some php that is not proccessed when translated.
#7
Looks like the D6 patch has been committed in http://drupal.org/node/352121#comment-1716228. If I understood sun correctly it will be solved if the core bug is fixed. So closing here. Please reopen if this is wrong.
Duplicate of #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups.