Good day; I am busy with my first Drupal project ever ( http://www.awksurvey.co.za )
This is a survey that I have developed with WebForm and have translated it to Afrikaans ( my home language )

In order to achieve left indentations for my labels eg 1.2 then 1.2.1 and 1.2.2 should be indented. I achieved this by placing some   tags in front of the labels and the English (language=en) survey presents 100% when I change my URL to language=af all the   tags are not rendered as html tags and my for shows   literally and when I view the source I see  

I have tried many solutions and even broke my site once by trying to change the htmlspecialchars code in includes/bootstrap.inc.

Your help will be so much appreciated.

Thank you kindly and warm regards.
Christopher

CommentFileSizeAuthor
#1 webform_localization-1781266-1.patch790 bytesstar-szr

Comments

star-szr’s picture

Title:   rendering as text   » Unnecessary check_plain() for radio labels and select options via i18n_string()
Category: support » bug
Status: Active » Needs review
StatusFileSize
new790 bytes

I can confirm this bug for radio labels and <select> options.

  • For radio labels, the labels should not be sanitized because they go through _webform_filter_xss() which then calls filter_xss_admin().
  • For select options, the options go through form_select_options() which runs check_plain() on every option, so if you do not pass the sanitize option to i18n_string, you end up with double encoding because the string goes through check_plain() twice.

The attached patch resolves both of these issues and I've verified that the strings still go through filter_xss_admin() and check_plain(), respectively.

star-szr’s picture

See http://drupal.org/node/1534468 for more information about why the double encoding is happening. Internationalization's i18n_string() API changed.

rv0’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #2 does what is needed, code is good.

GDrupal’s picture

@Cottser and @rv0 thanks for working on this. It looks good and I think We should go further and stop using webform_tt() in all webform_localization since i18n_string is already a dependency. Do you have any thoughts against that?

star-szr’s picture

Makes sense to me. Last I checked (which was quite a while back admittedly) webform_tt() had not been updated to use the newer version of the i18n_string API anyway.

GDrupal’s picture

Yeap that's exactly my point and perhaps would take a long time to get that update committed. So the next step will be to stop depending on webform_tt for i18n's api interaction. Thanks!

GDrupal’s picture

Status: Reviewed & tested by the community » Fixed

Committed Thanks Guys!

Status: Fixed » Closed (fixed)

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