I just noticed: "Form submission guidelines" in a form block always appear in the sites default language.
(on the stand alone form, translation works fine).

FIeld labels translate just fine.

Looking into it, if I find it I'll post back here

Comments

rv0’s picture

Status: Active » Patch (to be ported)

Found and tested the following fix, seems to work nice:

in formblock.module, line 135, change the line to:

      $block['content']['help'] = array('#markup' => !empty($node_type->help) ? '<p>' . filter_xss_admin(t($node_type->help)) . '</p>' : '');

just added a t() tag.

Greg Boggs’s picture

Issue summary: View changes
Status: Patch (to be ported) » Reviewed & tested by the community

This works for me. Possibly related I couldn't translate the form string above the help. Luckily, I just hid that field and used the help field as the title.

mikey_p’s picture

The documentation for t() indicates that user content should not pass through t():

You should never use t() to translate variables, such as calling

t($text); 

, unless the text that the variable holds has been passed through t() elsewhere (e.g., $text is one of several translated literal strings in an array). It is especially important never to call

t($user_text); 

, where $user_text is some text that a user entered - doing that can lead to cross-site scripting and other security problems.

mikey_p’s picture

Status: Reviewed & tested by the community » Needs work
Greg Boggs’s picture

In this case, the string goes through filter xss admin which prevents JavaScript from being entered as a translation or as a user value.

Does t() really circumvent admin_xss_filter()?

cs_shadow’s picture

As far as I can tell, since the string passes through filter_xss_admin(), its safe to use t() function in this case.

rv0’s picture

If it is user-entered text, it should never, ever run through t().. regardless of what I said above in 2011 ;)

Greg Boggs’s picture

There are lines of code not 3 lines below this one where user text is run through t(); Perhaps we should fix both?

I'm familiar with the code for a Drupal global variable translation, but this is a local function variable only used to temporarily store a string for output. So, I'm not sure how to approach translating that if not the t(); function.

mikey_p’s picture

joseph.olstad’s picture

To fix this would have to check module_exists for entity_translation and module_exists for the tid approach to translation and then check to see which version of translation is being used by the node then load the translated node through tid if it's the tid approach or load the entity translation by the current interface language if it's the entity_translation approach just prior to the "['content']['help'] code in function formblock_get_block($type)

this way you'd not have to use the t function at all.