I've updated i18n from version 1.3 to 1.4.

If I want to translate a block, I get

The submitted string contains disallowed HTML:

error message. In 1.3 this worked without any problems. I've done it a few hours before updating the module.

I've found a similar issue: #1298440: Translate block with full html input type ERROR (The submitted string contains disallowed HTML).

Files: 
CommentFileSizeAuthor
#41 page-view-test.txt5.5 KBtrigdog
#41 result.png21.08 KBtrigdog
#35 i18n_relax_translation_validation-05.patch46.69 KBJose Reyero
PASSED: [[SimpleTest]]: [MySQL] 2,095 pass(es).
[ View ]
#33 i18n_relax_translation_validation-04.patch42.13 KBJose Reyero
FAILED: [[SimpleTest]]: [MySQL] 1,933 pass(es), 178 fail(s), and 65 exception(s).
[ View ]
#28 i18n_relax_translation_validation-02.patch41.33 KBJose Reyero
FAILED: [[SimpleTest]]: [MySQL] 2,034 pass(es), 99 fail(s), and 0 exception(s).
[ View ]
#19 i18n_relax_translation_validation.patch13.86 KBJose Reyero
PASSED: [[SimpleTest]]: [MySQL] 1,893 pass(es).
[ View ]

Comments

It seems that the img tag is causing problems.

The submitted string contains disallowed HTML: <p style="margin-bottom: 1em;"><img src="/sites/cabane-diablerets.ch/files/images/alternatives-wandern.ch/369473_Cabanediablerets_ext_front1.jpg" alt="Cabanes des Diablerets" class="img-center" height="413" width="800"></p>

img is not allowed in locale_string_is_safe.

A block translation with a text like <p>Hello world.</p> is working with i18n version 1.4.

I'm using the block with images on my front page of the MAYO theme. I translated the text below the image.

I've reverted i18n to version 1.3. The translation of the block with the image works now again.

Priority:Normal» Major

The block translation with a text like <h1>Hello world.</h1> is working with i18n version 1.4. But when I want to add some style like <h1><span style="color: #A40000;">Hello</span> world.</h1>, i18n version 1.4 doesn't work, it only tells " The submitted string contains disallowed HTML". It seems "color: #A40000" is not supported in i18n version 1.4.

Same problem with <img> ! any advance?

Same here.
I am using wysiwyg/CKEditor with specific profiles for filter HTML, plain HTML and plain text. When translating a block, I noticed that though the indicated text format matches the translated text format, the interface is the "Plain text" interface instead of being the specific editing profile. Just a simple plain text editing field.

Same here: inserting a swf video causes this error too.

Possible workaround:

1. open file includes/locale.inc
2. find function locale_string_is_safe($string)
3. replace current code function with "return 1;"
4. edit your block translation
5. immideatly revert the change to prevent easy attacks from untrusted users

Category:bug» support
Priority:Major» Normal
Status:Active» Closed (works as designed)

I don't think we've changed anything about that in this (1.4) release, though maybe the validating function (in core) has changed, I don't know.

This shouldn't be a problem for block body as it has 'text format' but for block title we are just using this string for validating.

In your examples, it is not about the tags but the attributes (class, style). See http://api.drupal.org/api/drupal/includes!locale.inc/function/locale_str...

So I think this is just worked as expected (maybe it was not before).

Priority:Normal» Critical
Status:Closed (works as designed)» Active

I'm having the same error after updating to 1.4 and I have allowed translation of all text formats. But Jose you say that it works as designed does that mean that one only can translate plain text and not html?

Category:support» feature
Priority:Critical» Normal

Being a bit to quick I can see that Jose is right, since the tags img and div has been omitted. But wouldn't it be nice if these where allowed?

So were do you guys think we should put a request?

I even tried to use filter html text format and in the Limit allowed HTML tags tab I put every possible html tags in there and it still didn't work.

Seems like using img tag is messing things up.

And don't want to either hack core or use a custom module, this should be fixed in core.

Hello, having same problem:

the moment I use attributes, the error comes.

<table> is ok, <table class="extra-table" style="vertical-align: top; width: 240px; "> for instances, gives error

waiting for solution or new update

Cheers

I found a workaround. As describe in this
https://drupal.org/node/1298440

Go to Administration » Configuration » Regional and language » Translate interface.
Search for the block, translate and save.

If I went to the block and translate it I got the error above.

This doesn't just apply to blocks: I'm getting the same error with translating a Views header through the Translate Interface page. I've enabled translations on the required Text formats already. I have a DIV with a class that is causing the problem. If I change it to a P with the same class, it works fine. This is also on 1.4.

Component:Blocks» Strings
Category:feature» bug

Still looking for where the actual change was made but I can confirm this issue.

The problem exists in i18n_string.pages.inc in function i18n_string_validate_submission().

This function calls locale_string_is_safe() without any condition except for checking for empty form fields in the calling function i18n_string_translate_page_form_validate().

As shown in locale.admin.inc in locale_translate_edit_form_validate() and #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups, locale_string_is_safe() should only be ran on strings in the "default" textgroup.

The fix is changing i18n_string_validate_submission() in i18n_string.pages.inc

From:

<?php
function i18n_string_validate_submission($formkey, $value) {
 
// Validation based on locale_translate_edit_form_validate.
 
if (!locale_string_is_safe($value)) {
?>

To:

<?php
function i18n_string_validate_submission($formkey, $value) {
 
// Validation based on locale_translate_edit_form_validate.
 
if (strpos($formkey, 'default') === 0 && !locale_string_is_safe($value)) {
?>

Patch to come.

Status:Active» Closed (works as designed)

This is not a bug. We need some validation for strings and the best one we have atm is locale_string_is_safe().

Maybe if you want strings to be run through some other filter you should work on #1238642: Strings should be able to be runned through filter_xss(_admin)

And anyway I don't really understand your issue because block title is run through check_plain() always.

So definitely no, we are not contributing to hacks that may open up security holes. Maybe what you need here is a module that allows adding some html, with proper text format to blocks.

Status:Closed (works as designed)» Active

I disagree. This is in core and is not considered a security issue so why is it a security issue for i18n?

Can you support your position with actual use cases that this creates a security hole that has not been discussed and agreed upon in #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups?

Please also address why i18n is trying to enforce HTML related security on text that is ran through Drupal's text filters that are there to handle security as decided upon by the site admin?

Translators are not site administrators.

Anyway, after reading this carefully, it seems maybe they are so, well... we should ease these restrictions, https://drupal.org/node/1471870

Status:Active» Needs review
StatusFileSize
new13.86 KB
PASSED: [[SimpleTest]]: [MySQL] 1,893 pass(es).
[ View ]

This patch should fix two issues:

- Strings with format not being properly checked on form submission, thus going through locale_string_is_safe()

- Relaxing validation for strings without text format. Now they bypass locale_string_is_safe() is the source string doesn't validate either.

I hope this makes everybody happy. Let me know whether it works.

Status:Needs review» Needs work

The last submitted patch, i18n_relax_translation_validation.patch, failed testing.

Status:Needs work» Needs review

In order to allow img you need to:

  1. open file includes/locale.inc
  2. Go to line 500 - function locale_string_is_safe($string) which contains the list of safe strings
  3. Add string 'img',

Save and translate your block(s).

If you are concerned about the security, revert to original locale.inc, once you're done with translation.

Status:Needs review» Needs work

@Jose Reyro - Thanks for agreeing to put this in. When applying the patch #19, blocks can now be translated ok. The "The submitted string contains disallowed HTML:..." error does not occur anymore and the translated content is displayed properly, which is great!

However, now there is a problem with the display of the block in the original language. In my case, I can save the block in its original language correctly, but when I view it then the HTML is displayed instead of displaying the content properly. Can you please check?

Steps to reproduce:
- Create block, add content and save. The block is saved ok.
- Translate the block and add some tags such as for a table. The translated block is saved ok (enabled by this patch).
- View the block in the translated language. The block contents are displayed properly.
- View the block in the original language. The block contents are not displayed properly but instead the full HTML is shown.
- Revert the patch and the original block is displayed properly.

@dimitriseng,

Do you mean the proper text format is not applied to block body?
Or that it is run through check_plain so you can actually 'see' html tags?

Thanks for trying the patch.

@Jose - The text format I use actually does not limit the allowed HTML tags so when the block is displayed the formatting should be shown properly and not the tags I am not sure why this is happening, it might be that the text format is not applied to the body of the block. Is this working for you? Happy to test another patch, I think this is very close to being resolved!

Once this is resolved, we can also test the patches at #1252144: Support Wysiwyg editors for string translations (Wysiwyg Javascripts don't get loaded for block translations) and we will then have fully functional block translation functionality using WYSIWYG editors! :)

Thanks for your great work on this module, it is appreciated!

Status:Needs work» Needs review

Patch from http://drupal.org/node/1437146#comment-5745060 works. I am now able to save a block translation with HTML including inline styles without receiving the "The submitted string contains disallowed HTML:" error I experienced prior to applying the patch.

Title:After 1.4 update, block translation disallowed HTML errorRework string translation access. (After 1.4 update, block translation disallowed HTML error)
StatusFileSize
new41.33 KB
FAILED: [[SimpleTest]]: [MySQL] 2,034 pass(es), 99 fail(s), and 0 exception(s).
[ View ]

This patch fixes the issue in #25 (default string not being filtered properly) but also it goes a little further.

It is a complete rework of string/translation validation:
- Introduces new permission to translate user-defined strings (translate user-defined strings) so it can be granted on top of 'translate interface'.
- Introduces new permission to allow translating anything to trusted users: translate unsafe strings.
- Replaces locale_string is safe by our own validation function.
- Centralizes format & permission checking so it can be applied equally to all translation forms.
- Handles special formats like FILTER_XSS_ADMIN and adds a permission to translate it.

Status:Needs review» Needs work

The last submitted patch, i18n_relax_translation_validation-02.patch, failed testing.

Version:7.x-1.4» 7.x-1.x-dev

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, i18n_relax_translation_validation-02.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new42.13 KB
FAILED: [[SimpleTest]]: [MySQL] 1,933 pass(es), 178 fail(s), and 65 exception(s).
[ View ]

Simplified previous patch and updated tests.

One permission should be enough (translate user-defined strings).

Status:Needs review» Needs work

The last submitted patch, i18n_relax_translation_validation-04.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new46.69 KB
PASSED: [[SimpleTest]]: [MySQL] 2,095 pass(es).
[ View ]

Some tests were failing because of the new permissions.

Status:Needs review» Fixed
Issue tags:+Needs change record

We need to move on with this. So I've committed the patch.

Now it's time to test before a new release, which I'd like to do soon.

@Jose Reyro - I have tested the dev version and this seems to be working ok now! Great work, many thanks!

As per my comments in #25, now that we have this working, if possible it would also be great to get #1252144: Support Wysiwyg editors for string translations (Wysiwyg Javascripts don't get loaded for block translations) working before the next version of i18n is released. We will then have fully functional block translation functionality using WYSIWYG editors! :)

I am building a Spanish install of Drupal and it also has an English translation. I was having the disallowed HTML issue with my div tags in views translations so I installed the latest 7.x-1.4-dev (2012-Apr-03) and I was able to save my html tags in the translations with no errors but when I went to view the page the html tags were display as text and not rendered as html. I went back to my previous version of i18n 7.x-1.4-dev (2012-Feb-23) and all of my html elements were rendered properly again but again I can not save them without the disallowed HTML error.

@trigdog,

Could you post some more details, please? Which strings? Post an example?

Fixed some related issues:
- Unsupported operand types in i18n_string.pages.inc when translating string groups.
- Disabled strings being updated (wrong count of updated strings).

StatusFileSize
new21.08 KB
new5.5 KB

@Jose Reyero,

Sorry for the delayed response but I wanted to test it on a fresh install of Drupal just to make sure it wasn't something wrong with just my site. I was able to reproduce the same problem with just the following installed:

Drupal 7.12
Chaos tool suite (ctools) 7.x-1.0
Internationalization 7.x-1.4+35-dev (2012-Apr-11)
Internationalization Views 7.x-3.x-dev (2012-Jan-08)
Localization update 7.x-1.0-beta3
Variable 7.x-1.1+19-dev (2012-Mar-22)
Views 7.x-3.3

I then created two language neutral test pages (Basic Pages) and created the attached view with two fields: the title and a Global: Custom text field. In the Global: Custom text field I just put the following for the text:

<div>&nbsp;</div>

This works fine in the original view but when I go to "translate view" and translate it for Spanish and save the html is just displayed as text. See result image to see the result. Thanks!

@Jose - Do you need more tests on this?

It's a bit rewrite of the functionality. We've got some HTML strings that we need translated (that were working fine in 1.3).

Status:Fixed» Postponed (maintainer needs more info)

@trigdog,

So the problem is with Views (i18nviews) ?

Are all the strings translated only with i18n modules (blocks, fields, etc..) working?

@mgifford,

Which are these strings? (i.e. block body, ... ?)

Priority:Normal» Critical

We need to take care of this and also produce a new release ASAP so marking as 'critical',

It looks like the problems are coming from i18nviews implementation of i18n_string so please give a try to #1534454: Update text handling and filtering using latest i18n features (permissions, filter_xss_admin)

And, unless someone tells me this affects i18n modules (not other plug-ins), we should be closing this issue.

Full documentation for this (change record) here, https://drupal.org/node/1534468

Status:Postponed (maintainer needs more info)» Closed (fixed)

This change is already in latest stable release.

I have updated to 1.5 (came from 1.4) and now am facing a special character issue..
menus and taxonomies containig chars like '&' are now shown as '& amp;'

Can somebody please help me? in 1.4 everything was working fine.

Version:7.x-1.x-dev» 7.x-1.5
Status:Closed (fixed)» Needs work

Nobody is facing this issue? Since the update to 1.5 my whole site is showing '& amp;' everywhere instead of just '&'
Looks like a critical one for me, but tell me if the solution is right here.. I found the issue http://drupal.org/node/1526000 but directs it to this one.

And have you solved it? cause i can't understand the changes mentioned in all topics. Sincs 1.5 they made 2 filtering methods and default everything is now filtered as plain text? This is a hard change not? Everybody updating now will see all plain text instead of html?
Sorry that i can't understand it yet what to do.. for me at first sight it only looks like only the '&' is changed into '& amp;' for me. other html and caracters seem to be normal (since i'm running a dutch and french website..)

As for timmetj and kerios83, when i have a single quote (or an ampersand) in block title, it shows ' for the single quote or & for the ampersand.

I don't have internationalization views installed so i don't think it concerns only internationalization views.
I've got this issue in translated block title and translated vocabulary terms but not in original language.

thank you for your help.

Status:Needs work» Fixed

Fixed filtering issues with taxonomy terms and block titles.

(Remember latest i18n-dev needs variable 2.x branch)

Status:Fixed» Active

it's possible this issue has generated another bug? see #1604760: i18n_taxonomy_term_name() duplicate ampersand

Status:Active» Fixed

Please check out latest dev version before re-opening bugs.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

While this is a different module etc., the whole issue has somehow reminded me of http://drupal.org/node/1458574 and http://drupal.org/node/1282018. On the fundamental side, this issue is yet another example of a mindset based on the idea of asymmetrical translation workflow, rather than a symetrical/truly multilingual one.

@Maksym, FYI you can make dynamic references to modules by placing the issue number between square brackets, preceded with a hash sign (eg. [#123456]). This will show all the important information at a glance: the issue number, title and current state of the issue.

For convenience, these are the issues that were referenced in the previous post: