Closed cmlenz closed 3 years ago
I've seen some HTML frameworks (jade/pug) generate a translate="translate"
attribute, which might break due to this. Might need a special case for that.
I've seen some HTML frameworks (jade/pug) generate a
translate="translate"
attribute, which might break due to this. Might need a special case for that.
Good point, that'd basically the XHTML form for boolean attributes. Not quite correct, but it doesn't hurt to handle that.
What'd be preferable: whitelisting "yes" and "no", or blacklisting "translate"?
Also, not sure why the tests failed on Travis, running them locally seems okay.
I have updated the PR to whitelist the "yes" and "no" values, so all other values will let the normal processing continue as before.
Great!
Yeah Travis... :man_shrugging:
Somebody needs to look into that but I don't have the time to do it sadly.
Looks good otherwise, thanks a lot! Will publish to NPM
Thanks!
Update the translate directive to gracefully handle the native HTML translate="yes|no" attribute.
This change will bypass the normal
angular-gettext
processing when thetranslate
attribute has a value.We ran into this problem because sticking a
translate="no"
attribute onto the body element to disable the Chrome translate toolbar from showing up broke the whole application :)