<Trans> outputs (some?) basic HTML nodes as plain-text

[igorsantos07]

🐛 Bug Report

Weird interaction between transSupportBasicHtmlNodes and transKeepBasicHtmlNodesFor, as a side-effect of the workaround for i18next/i18next-parser#264.
It causes some tags to be outputted as plain-text, others to be correctly converted, but I can't isolate the exact causes?

To Reproduce

I made a slight fork of a sandbox sample, just changing the two settings mentioned:
https://codesandbox.io/s/react-i18next-forked-p7hcsc.
You can see some tags (<code>) were correctly displayed, while br and strong weren't. code and br aren't part of transKeepBasicHtmlNodesFor, while strong is.

One workaround I found is that placing an <em> tag inside <p> solves the issue, or adding a prop - this was noticed by accident when I originally stumbled on this.

Expected behavior

1. i18next-parser should correctly output <p> when that's what react-i18next understands from <Trans> (i18next-parser's 264). With transSupportBasicHtmlNodes either true or false, missingKeyHandler() reports the key to include <p>, but the parser still stores <0>.
2. Then, disabling transSupportBasicHtmlNodes seems to have mitigated this issue for some scenarios (not so sure anymore), but in others it causes this weird side-effect described above.

Your Environment

• node 14.18.2
• React 17.0.1
• i18next 20.3.5 (also happens in sandbox's original version 15.0.6)
• react-i18next 11.11.4 (also happens in latest version in the sandbox)
• i18next-parser 4.3.0

---

Possibly related to #1240?

[jamuhl]

Just to make sure I understand correctly...the issue I can follow is that for some tags the saveMissing feature creates and logs wrong strings into the console when transSupportBasicHtmlNodes: false , like eg.:

        <Trans i18nKey="welcome">
          Hello <br /> <small>World</small>
        </Trans>

generates Hello <br /> <3>World</3> but should Hello <1></1> <3>World</3>

The result would be correct if also setting:

    react: {
      transSupportBasicHtmlNodes: false,
      transKeepBasicHtmlNodesFor: []
    }

which leads me to this line of code causing the issue: https://github.com/i18next/react-i18next/blob/master/src/Trans.js#L41

should be: const keepArray = i18nOptions.transKeepBasicHtmlNodes && i18nOptions.transKeepBasicHtmlNodesFor ? i18nOptions.transKeepBasicHtmlNodesFor : [];

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mateusvahl]

bumping this: Anyone knows a fix or work around?

cc @igorsantos07

[mateusvahl]

Found this workaround:

 <Trans
  i18nKey="my_key"
  transKeepBasicHtmlNodesFor={['br', 'strong', 'i']}
  components={{ s: <s />, b: <b /> }}
/>

[igorsantos07]

I'm not sure if this is still a problem, but I guess the previous fixes by @jamuhl weren't enough since @mateusvahl is still complaining about the same thing.

Sadly, I just found a workaround and moved along - I've spent a lot of time fiddling with the lib's problems when we should actually be focused on implementing i18n and translating stuff, rather than fixing the biggest lib on the topic for JS.

What we've been doing (rather than config guesswork, trying to care for imprevisible scenarios) is to add className="i18next-hack" to ill-behaving tags - and add a note to CCS explaining that was actually a hack related to this issue. At least it was a single place to explain the problem in our codebase, instead of guesswork or extra hours trying to debug a complex lib.