Support raw HTML in translation values
See original GitHub issueSay we have the next translation resource:
{foo: "<b>Bar!</b>"}
Then <div><Interpolate i18nKey='foo' /></div>
will result in the next output:
<div><b>Bar!</b></div>
, while I expect to get this: <div><b>Bar!</b></div>
, so a raw HTML in translation strings should not be escaped.
Is this an intended behavior, or is a bug?
I guess replacing this line with something like
child = React.createElement(parent, {dangerouslySetInnerHTML: {__html: match}});
will work this out.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:7
- Comments:34 (23 by maintainers)
Top Results From Across the Web
HTML tags in i18next translation - Stack Overflow
It works great on text-only content, but when I try to translate content that includes HTML markup, it is displaying the raw markup...
Read more >What are the raw HTML view and the Styled view? - Help Center
The raw HTML view allows you to see the tags as they appear in your original content or source code, so you will...
Read more >Translating HTML Content | Transifex Help Center
Learn how to translate variables and HTML content in Transifex.
Read more >Storefront locale files - Shopify.dev
Storefront locale files are JSON files with a .json file extension. They host translation strings for content displayed on the storefront throughout the ......
Read more >Rails Internationalization (I18n) API - Ruby on Rails Guides
Localization of a Rails application means defining translated values for these ... There are a few steps to get up and running with...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
it will process user input - but you can configure remarkable to not allow html tags or just defined tags - so no risk there.
So i think the solution with markdown or
<div dangerouslySetInnerHTML={{__html: t('foo')}} />
is the way to go…might be ugly - but the uglyness remembers what is going on.you might do a PR adding a prop
dangerouslySetInnerHTML=true
- but it need to be visible that people are doing somethingdangerous
Yeah, that’s clear.
Another option as for now is
<div dangerouslySetInnerHTML={{__html: t('foo')}} />
But they both are weird 😃