I'm having problems with an interaction between Views and i18n_strings, in trying to translate some data for a field.

The field has a rewrite/alter on it. The help/description for alter/rewrite property says "You may include HTML". However, it doesn't have a text format on it. So, when you go to export the string using unpack_translatables(), you don't have a format on that particular translatable string. Then when you go to translate it, i18n_strings tries to validate that it doesn't contain any unsafe HTML tags (it actually calls locale_string_is_safe() in core/includes/locale.inc to do the validation). If it does have "unsafe" HTML tags, you get an error like this one:

The submitted string contains disallowed HTML (and then it has the offending HTML there)

So...

What Views needs to do is to put a format value in for alter/rewrite properties on fields when they are exported for translation, so that i18n_string doesn't assume it needs to make sure the translation is "safe" text.

I can hack Views to do this, and probably will since I'm under pressure/deadline, but there probably needs to be a better way. I'll attach my hack/patch when I get it working for this site just in case...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhodgdon’s picture

For reference, here is what happens in i18n_string:

// When making the $form for translation:

function i18n_string_translate_page_form_strings( ...
//  ...
   $form[$item->get_name()] = array(
//  ...
      '#i18n_string_format' => !empty($source) ? $source->format : 0,
// ...
}

// When validating:
function i18n_string_translate_page_form_validate($form, &$form_state) {
  foreach ($form_state['values']['strings'] as $key => $value) {
    // We don't need to validate disabled form fields because those are already
    // validated by the FormAPI.
    if (empty($form['strings'][$key]['#i18n_string_format'])) {
      i18n_string_validate_submission("strings][$key", $value);
    }
  }
}

So basically, if format exists, it sets #118n_string_format on the field to non-empty, but if there is no format, ti calls string_validate_submission, which validates that the HTML is "safe".

dawehner’s picture


The field has a rewrite/alter on it. The help/description for alter/rewrite property says "You may include HTML". However, it doesn't have a text format on it. So, when you go to export the string using unpack_translatables(), you don't have a format on that particular translatable string. Then when you go to translate it, i18n_strings tries to validate that it doesn't contain any unsafe HTML tags (it actually calls locale_string_is_safe() in core/includes/locale.inc to do the validation). If it does have "unsafe" HTML tags, you get an error like this one:

So in general it is fine, at least from my perspective to have HTML without formats, as long you filter_xss it. There are many examples in drupal core which use it... for example site mission. What does i18n_string here?

There was some other issue which allowed to use formats here, because people wanted to control which kind of input format they want to use here, but then the default locale wrapper has problems as well.

Merlinofchaos means that there will be no formats on the field itself, but perhaps i18n_views could handle this ... no idea.

jhodgdon’s picture

The filter_xss that i18n_strings uses does not allow IMG tags and probably others as well.

i18n_views can't really tell the difference between a field that should not have an input format (such as a title or label) and one of these rewrite/alter fields that should allow any HTML tag (at least I think it should?). So I think that this would have to be done in the Views code and not in i18n_views.

That said... well, I didn't get this working, so instead I just commented out the error checking in i18n_strings, because I need to get these translations into the database. Sigh. So, no patch as of yet...

dawehner’s picture

Does i18n_strings somehow supports filter_xss_admin? That's what views is doing, so i18n_strings could do as well, at least from my perspective.

merlinofchaos’s picture

The problem with format values is that they are system specific. While Drupal ships with some default formats, they can be changed or removed. We can't simply use them to pretend that a field is formatted, because we have absolutely no idea what that format will actually be in reality.

Views runs filter_xss_admin() on this field. We need some way to communicate to i18n_views that that is how we're formatting it. I think i18n_views and views may need to work together to achieve this.

Maybe post an issue to i18n_views and link to here? Would be good to get an i18n_views maintainer to discuss.

jhodgdon’s picture

It would also require a patch to i18n_string, because that is what is actually setting up the form and validation. It currently passes everything through filter_xss with its own list of allowed tags, and the only way it doesn't is when the field has a 'format' on it.

dawehner’s picture

Title: Alter/rewrites on fields need formats for internationalization and don't have them » Strings should be able to be runned through filter_xss(_admin)
Project: Views (for Drupal 7) » Internationalization
Version: 7.x-3.0-rc1 » 7.x-1.x-dev
Component: Code » Strings

Move to i18n

Jose Reyero’s picture

Category: bug » feature

Yes, this looks like something that should be added.

We could use the 'filter' field and parameter with some known value, to be defined by a constant and that cannot clash with 'format names', I guess by adding some space or non letter char on it.

Then we just need to add some checks here and there so that format bypasses all the filtering.

So patches welcomed.

dawehner’s picture

Here is some initial work.

Jose Reyero’s picture

Status: Active » Needs work
FileSize
2.29 KB

Yes, the patch in #9 looks like a good start. However, it has some issues, like the format names maybe clashing with 'real' formats, so reworked it a little bit.

The machine name for text formats reads 'A unique machine-readable name. Can only contain lowercase letters, numbers, and underscores.' So we should be safe using uppercase (?). Anyway, defined them as constants so they're easy to change later.

Also improved i18n_string_allowed_format() so it returns true for these format names.

Now we just need to handle the access / UI part for the translation pages.

Attached the patch that was committed.

Jose Reyero’s picture

And one question: Should we allow anyone to translate strings to be run through filter_xss_admin() ? If not, which permission could fit here.?

webflo’s picture

dimitriseng’s picture

Hi, it would be great to get this to work as at the moment it is not possible to translate blocks properly, which is a very useful function in real life scenarios. I agree that this should controlled by permissions which should be set to off initially, but the admin should be able to explicitely define if and which roles should be able to have this capability on specific text formats. Thank you.

Jose Reyero’s picture

This patch implements some related permissions #1437146: Rework string translation access. (After 1.4 update, block translation disallowed HTML error)

Now we just need to figure out how to create strings with that format.

Jose Reyero’s picture

Status: Needs work » Fixed

The related patch has been committed. Now we should be able to add these 'filter_xss' strings and they will be formatted properly.

Summarizing:
- Two constants have been introduced to create strings to be filtered: I18N_STRING_FILTER_XSS, I18N_STRING_FILTER_XSS_ADMIN. (to be used with the 'format' property of strings).
- There's a new permission, 'translate admin strings' to translate strings that are to be run through 'filter_xss_admin'

Status: Fixed » Closed (fixed)

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