Skip to content

Translation won't work if string contains & codes. #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
pySilver opened this issue Dec 5, 2014 · 10 comments
Open

Translation won't work if string contains & codes. #139

pySilver opened this issue Dec 5, 2014 · 10 comments

Comments

@pySilver
Copy link

pySilver commented Dec 5, 2014

Extraction & futher translation of the string like this one, works fine:

This is somethign & else

But for string like the following one extraction would work, but translation would not:

This is a string with → an arrow!

Workaround for now would be using special symbols directly in a source code:

This is a string with → an arrow!

So clearly there is a problem with &xxx; symbols.

@gabegorelick
Copy link
Collaborator

@pySilver How exactly is translation not working? Are you using the translate directive, filter, or the JS API? If possible, can you post some code?

@pySilver
Copy link
Author

pySilver commented Dec 5, 2014

@gabegorelick I'm using translate directive

This p would work (both extraction and translation)

<p translate>
  Configure your website by navigating to <br> <strong>Ad Tools → Configure Contextual Ads</strong>.
</p>

this p translation woul be extracted but translation won't be applied even if it exists

<p translate>
  Configure your website by navigating to <br> <strong>Ad Tools &rarr; Configure Contextual Ads</strong>.
</p>

the only difference here is html entity &rarr; vs

@rubenv
Copy link
Owner

rubenv commented Dec 6, 2014

Yup, known problem. I strongly recommend using UTF-8 instead of escaped entities for now. Every computer on the planet supports it nowadays.

@gabegorelick
Copy link
Collaborator

@rubenv What's the source of this bug? It seems very strange to me.

@rubenv
Copy link
Owner

rubenv commented Dec 6, 2014

I have no idea. There's an easy way to work around it (which is also much nicer to translators), so we never bothered looking into it. Just use UTF-8 :-).

@zeckson
Copy link

zeckson commented Mar 12, 2015

I found out that some angular template compilers convert '&', '>', '<', etc. in '&', '&gt', '&lt' ant this converted string will be passed to angular-gettext, which will be failed to match, since strings are collected on original file. In my case there was gulp html2js plugin.
So there are 3 possible solutions to workaround this problem:

  1. Fix this symbols in original templates
  2. Do not convert these symbols in your template compiler
  3. Fetch angular-gettext from compiled files (which is not possible by the way)

@michi88
Copy link

michi88 commented Jul 19, 2015

I think this is a bug and should work: <h1 translate>me & you</h1>. It get's extracted but not translated.

But... if I add <h1 translate>me &amp; you</h1> and also extract and translate then they both work. :)

@simon04
Copy link

simon04 commented Nov 9, 2015

The "use UTF-8 character instead" workaround is unhandy if the character is not visible or not distinguishable from another character. For instance, U+00AD (soft hyphen) has no visual representation, but permits hyphenation in HTML.

I used the following workaround:

<span ng-init="shy = '\u00ad'">
<span translate>foo{{shy}}bar</span>
</span>

@Carl-David
Copy link

Special characters like & inside a label cannot be translated in IE/Edge because here, the DOM is used to return the label key, which will return it encoded as &amp;. Is there any workaround for this?

tschiela pushed a commit to tschiela/angular-gettext that referenced this issue Jun 20, 2016
@adambullmer
Copy link

adambullmer commented Nov 10, 2017

Ran across this caveat myself today. The problem, as I noticed it, is that when compiling strings, the text as it was written is passed to the template.pot html entities and all.

The resulting .po file also has those entities as originally authored.

In use, the translate directive uses javascript to get the html of the element it was applied to, and sends it to the compile function for processing. At this time, the html entities have been converted into their plain text counter part. Then the lookup for a translation string fails as the msgid is different in the compiled translations and what is being used at that time.

I prayed to google for possible answers on how, with javascript, to get raw contents of an element without interpreting special characters, and it seems this is a limitation of how javascript is able to access this information.

I think a possible workaround may be to manually call the gettextCatalog.getString() method with your string in code in your controller. But that sounds truly awful.

A possible resolution this package could do is interpret these html entities when compiling strings to prepare the msgid to have the literal character in it, which sounds moderately better, but still not ideal as it limits compatibility of the characters you can use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants