-
Notifications
You must be signed in to change notification settings - Fork 210
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
Problem with using some HTML tags in locale file #125
Comments
Is this something we should file for webL10n instead? |
Probably, but this restriction was probably made deliberately. |
That’s because this string: <span style="display: block;" class="question" data-l10n-id="c-intro">
So you think OOP is for hipsters?
That’s cool, we all get nostalgic sometimes.
You could work on
</span> is translated to this: <span style="display: block;" class="question" data-l10n-id="c-intro">
Quindi trovi che la <abbr title="Programmazione orientata agli oggetti">POO</abbr>
sia per gli <span lang="en">hipster</span>?
Bene, capita a tutti un po' di nostalgia.
Ti propongo
</span> because the Italian translation has been done like this: c-intro.innerHTML = Quindi trovi che la <abbr title="Programmazione orientata agli oggetti">POO</abbr> sia per gli <span lang="en">hipster</span>? Bene, capita a tutti un po' di nostalgia. Ti propongo The problem is that the Italian translation uses That’s the reason why locales should use Note that you could allow l10n contributors to use Note also that webL10n doesn’t reset a node content by default in order to preserve some edge cases like this one, where we want to keep the <li data-l10n-id="wifi-level">
Signal strength <span class="wifi3"></span>
</li> This is handy in a lot of cases but the major drawback is that it doesn’t allow localizers to use Last but not least: in the real world you probably don’t care much unless you leave the language selector in the production page (which I doubt). ;-) |
Probably is follow up to gh-86.
Steps to reproduce:
onhover
. It uses<abbr>
HTML tag for this purpose.This artifact most likely appears due to webL10n library's ignorance of non-TEXT_NODE DOM nodes (see source code)
The text was updated successfully, but these errors were encountered: