Translate fails if string contains &

[mpiasta-ca]

Suppose we have a case like this:

<span translate>Test & Execute</span>

If we extract strings, the extraction will appear in your *.pot file, as expected.

But when you make translation (ie. "tester et exécuter") and generate Json files, if you load the website and select the translation, the translated string will not appear.

Instead, you will still see "Test & Execute" where you expect "tester et exécuter".

This works:

<span translate>Test &amp; Execute</span>

Writing "&" was required in HTML4 specifications, but it's no longer the case. According to HTML5 specifications, using "&" is valid (see: ambigious ampersands).

[padawin]

I faced the same issue. This issue has been introduced by the #131: by calling html(), the special characters are encoded (eg & into &) and the keys are then changed. What I will say next might be very opinionated, but here it is. Using html in gettext keys (as well as using angular code, or php variable, or any logic related information) is a bad practice. Gettext is here to localise an application and to move hard coded text (which is just a data as any other) in a data storage system (the POT/PO/MO files). Those values should not contain logic, otherwise, it means that people in charge of localising have the power of adding some style for example. If a part of localised text needs dynamic data, or styling (strong for example), sprintf is the best friend:

sprintf(translate('HEADER_NEW_MESSAGES_NUMBER_%s'), '<strong>' + messagesNumber + '</strong>')

Which would render, with no localisation:

'HEADER_NEW_MESSAGES_NUMBER_<strong>' + messagesNumber + '</strong>'

And once the string would be localised, it could do something like:

'You have <strong>' + messagesNumber + '</strong> new messages'

Now, regarding this issue, I would like to say that gettext should not modify the provided keys, but look for their localisation as they are. If a key contains a &, it must not be modified in the process and look for a key containing &, or any other changes.

[intellix]

Just looked into this on our site as well. I've found that it varies between directive/filter:

<span translate>Login &amp; Play</span> <!-- translates correctly -->
<span translate>Login & Play</span> <!-- fail -->
<span>{{ 'Login & Play' | translate }}</span> <!-- translates correctly -->
<span>{{ 'Login &amp; Play' | translate }}</span> <!-- fail -->

[rdeslonde]

Can we get some help on this one?

[rdeslonde]

What's funny is fixing a bug in IE8 (a backwards system) broke current and future correct functionality (& in html text). I'll look at making a PR fix.

[rdeslonde]

Added a PR for this here, #352.

[jcperez-ch]

I think the bug appears in IE11 too