Bug 2028160

I've removed the i18nKey from the Trans component, but now it seems that the rare parser issue occurred, because the key contains now HTML tags.

I've looked through the console-app.json file and saw three other keys, where there are also HTML tags inside the translation key. How should I continue on this? 
  - Use the i18nKey property, but instead of applying something like "netpolicy_peers_preview_affected_pods" apply a key like "Show a preview of the affected pods that this will apply to"
  - keep the html tags in the key (this f.e. also done in the network-policy-form.tsx)?

Yeah, it has to do with the third-party parser we use to scrape the code rather than what i18next actually supports. The code in network-policy-form.tsx didn't hit the parser bug; it's only happened a couple of times.

I would replace the Trans component with something like this in this case (the RuleName component the author used isn't a good practice because it hides the context the text is in from the translators):
{ props.direction === 'ingress' ? 
        <Trans ns="console-app">
          Show a preview of the{' '}
          <Button
            data-test={`show-affected-pods-${props.direction}`}
            ref={podsPreviewPopoverRef}
            variant="link"
            isInline
          >
            affected pods
          </Button>{' '}
          that this ingress rule will apply to.
        </Trans>
        : <Trans ns="console-app">
          Show a preview of the{' '}
          <Button
            data-test={`show-affected-pods-${props.direction}`}
            ref={podsPreviewPopoverRef}
            variant="link"
            isInline
          >
            affected pods
          </Button>{' '}
          that this egress rule will apply to.
        </Trans>
}

I tried this locally and ran yarn i18n. I didn't see any resulting missingKey errors on the NetworkPolicy creation page.

Steps:
1. Search for NetworkPolicy on the Search page in the nav
2. Click Add Ingress Rule
3. Select "Allow pods from inside the cluster" from the dropdown

Forgot to add - we have a story open to see if we can fix the parser bug at the source (they haven't been maintaining it for React), but it hasn't been a priority yet. Feel free to reach out to me with any questions on i18n stuff!

This bug has been verified on 4.10.0-0.nightly-2021-12-23-153012

Verification step:
1. Login OCP, add "?pseudolocalization=true&lng=en" at the end of the URL
2. Navigate to Networkpolicies page, and create networkpolicy
3. Click "Add Ingress Rule" and "Add Egress Rule" 
4. Click 'Allow pods from inside the cluster' from the dropdown
5. Click 'affected pods', check the list of pods
6. Verify if upon part has been translate correctly and within i18n mode

Result:
6. all parts have been translated correctly and in i18n mode

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:0056