Translated e-mail body sent as plain text

Patch to follow shortly, after dentist drills my teeth

trigger testbot

Hi Daddys, can you please confirm that patch #3 solves this issue? I will give you credit for this one.

This patch reverts commit 8058b74

patch #7 I should have called 7 not 99..
This patch is to revert commit 8058b74 ( "Wrong or missing 'format' parameters in most i18n_string() calls"

Dandys , could you please try patch #3 and see if that does the trick for you?

if not , try patch #99 , these will apply to the latest dev branch

here's an instruction on how to use patch
wget can help you download the patch.

cd /path/to/webform_localization
wget https://www.drupal.org/files/issues/webform_localization-translated_emai...
#TEST THE PATCH
patch --dry-run -p1 < webform_localization-translated_email_body_sent_as_plain_text-2633966-3.patch

#output will say, check ...
#IF no failures, then apply the patch for real
patch -p1 < webform_localization-translated_email_body_sent_as_plain_text-2633966-3.patch

To reverse a patch use the same command but with the "-R" flag
so
test it first with the --dry-run flag
patch -R --dry-run -p1 < webform_localization-translated_email_body_sent_as_plain_text-2633966-3.patch

#no fails, then to reverse it for real do same thing without --dry-run
patch -R -p1 < webform_localization-translated_email_body_sent_as_plain_text-2633966-3.patch

If you are on windows, you can download patch.exe
otherwise on Linux I believe the patch program is installed by default on most distros

Hi Dandys, your feedback is invaluable, thanks again. Based on those results I think this patch could be the winner if it passes simpletest first.

You may have to re-enter the missing html into the translation again.

See related issue and the new patch, you'll have to reverse the other patch first before applying this one.

ok, try this instead.

New patch

I'm hoping that I18N_STRING_FILTER_XSS_ADMIN is sufficient for your html, otherwise if I put the option array(sanitise =­> 'TRUE') without specifying format the default kicks in and will be even more permissive and should allow all your html

If your test doesn't work with patch 15 then we may need to try array(sanitise =­> 'TRUE')
instead of array(format => I18N_STRING_FILTER_XSS)

SEE api documentation for more details:
http://www.drupalcontrib.org/api/drupal/contributions%21i18n%21i18n_stri...

Dandys, during the test, you may need to double check the translation to make sure the required html tags are put back in prior to new test.

I'll write another patch for the other option.

ok, see if this patch passes testing.

this patch (should) sanitize with default and keep all valid html , I hope

sorry, no that patch won't , I will put a new patch

this should

another

wait for test results, try #27 if its passing

triggering testbot

Patch #30 if there's no format set I'm fallbacking to I18N_STRING_FILTER_XSS_ADMIN

if this doesn't work then maybe force 'full_html'

Hi Dandys, sorry for the trouble, can you please test this one more time? I think we're close.

You might need to re-translate again the text with the html tags, I hope you have it copy paste.

Hi Dandys, yes I also got that result with patch 30..... Ok, back to the drawing board. I'll write a new patch.

Hi Dandys, can you retry patch 30 , but first go to admin settings:

/admin/config/regional/i18n/strings
Under 'translatable text formats'
make sure to add a checkmark to 'Full HTML' and 'Filtered HTML'

Needs work, just cant seem to get i18n_string filter right. see thread above.

joel_osc , can you please lend a helping hand and weigh into this? what filter format should we be using?

see :
Translatable text formats
Filtered HTML
Full HTML
Plain text

/admin/config/regional/i18n/strings
Under 'translatable text formats'
make sure to add a checkmark to 'Full HTML' and 'Filtered HTML'

and see api (contrib api for i18n_string_format)
http://www.drupalcontrib.org/api/drupal/contributions%21i18n%21i18n_stri...

We need some help with this.

Patch #16 is the closest we get, but has issues.

Original english language:

Deutch translation without patch:

Deutch translation with patch 16
Some missing fields

joel_osc, if you can weigh into this, maybe your eyes will help.

Right now I am burnt up on this and my kids are running wild.

Dandys, can you please send me your untranslated email template in a .txt file so I can have a look at what is in it? I assume you're using tokens? I'll try to reproduce your configuration in my test environment.

Hi Dandys and Joel_osc, ok, I am still working on this issue, however it looks like there may be a workaround.

see this comment:

https://www.drupal.org/node/2356791#comment-9415815

if we change the i18n_string filter to 'plain_text' , then write a tpl that decodes the html entities, this will render the html in the original format without losing stuff.

it would have to be a combination of a patch and a tpl, however I'm currently looking to see if there isn't another way to do this, maybe if needed hit the database directly and force html

https://www.drupal.org/node/2356791#comment-9415815

May have to change all I18N_STRING_FILTER_XSS to 'plain_text' , then apply workaround tpl with decode html

but looking for a better way.

Joel_osc, let me know if you have any thoughts.

Mschudders workaround was done prior to putting the I18N_STRING_FILTER_XSS in, so we may have to remove those, and then come up with a better workaround solution , ideally this should all be handled by webform_localization

we could add a special webform tpl I suppose, I'd like to hear from joel_osc see what he has to say.

see comment #46 , this patch (if passes) should not sanitize any i18n_strings , but to render the output as html a tpl MAY need to be created and call html decode function to render it in html

currently testing a few things until we can find a better solution.

oops, meant to have all at 'plain_text' one small change to this patch compared to 48 (plain_text or sanitize FALSE)

Hmm, looks like the simpletest bot isn't running through all 2000+ tests, must be due to changes on d.o

see comment #46 and patch #49 , this is a workaround, I'm not satisfied with the workaround however its the best solution until we come up with a full solution in the module.

Testing is working as designed: see: https://www.drupal.org/node/2638832#comment-10731048

Patch #49 gives me wired results where select components :
1- on webform display have <p></p> around their translated value when used as list (but not as checkboxes)
2- does not render at all on display (neither in submission page or when used with tokens)
The changes in patch attached seems to make the deal for me.

Hi Dom. , thanks for the patch, I have not yet had time to review it however perhaps Dandys would be able to review it for us? Dandys, would you be able to re-test your use case with the latest patch that Dom. submitted, you'll probably have to apply the patch, refresh the translation strings and retranslate and see what gets rendered on the other languages. If you can test this out that'd be really appreciated as I did do a lot of work and testing to get this far already , Dom. says his patch is working for him. From what I read about this issue and related issues is that perhaps a custom filter may have to be added , perhaps Dom. can elaborate on his use case and test environment.

ok lets commit patch #53 asap.

Thanks Dom and Dandys, I'll give some commit credit to you both (and me too)