Bug 2028160 - Remove i18nKey in network-policy-peer-selectors.tsx
Summary: Remove i18nKey in network-policy-peer-selectors.tsx
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.10
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.10.0
Assignee: Tim Grein
QA Contact: Xiyun Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-01 15:52 UTC by ralpert
Modified: 2022-03-10 16:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-10 16:31:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 10642 0 None open Bug 2028160: Remove i18nKey in network-policy-peer-selectors.tsx 2021-12-09 15:01:23 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:31:20 UTC

Description ralpert 2021-12-01 15:52:19 UTC
Description of problem:
When reviewing some of the new translations, I noticed a key for "netpolicy_peers_preview_affected_pods" in console-app.json. I dug into the code and it appears that someone has defined an i18nKey on their Trans component. This is incorrect and results in our inability to have the phrase translated.

We need to remove the i18nKey and generate the correct key for translation purposes. 

Version-Release number of selected component (if applicable):
4.10

How reproducible:
Always

Steps to Reproduce:
1. Search network-policy-peer-selectors.tsx in the console-app package for "netpolicy_peers_preview_affected_pods" to find the Trans component

Actual results:
There is an i18nKey applied to the Trans component, which overrides our ability to translate the phrase. The translators are only able to see the i18nKey.

Expected results:
There is no i18nKey applied to the Trans component and the console-app locales JSON files contain the correct phrase.

Additional info:
The optional i18nKey property on the react-i18next Trans component should only be used as a last resort. There is a known (rare) issue with the parser, where it will sometimes incorrectly generate a key that contains HTML tags. If this is the case, you will see a missingKey error in the developer tools of your browser or in our end to end tests. It is important to look for these after making the update.

Comment 1 Tim Grein 2021-12-02 13:23:10 UTC
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)?

Comment 2 ralpert 2021-12-02 17:59:09 UTC
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

Comment 3 ralpert 2021-12-02 18:03:39 UTC
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!

Comment 6 Xiyun Zhao 2021-12-28 01:27:52 UTC
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

Comment 10 errata-xmlrpc 2022-03-10 16:31:07 UTC
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


Note You need to log in before you can comment on or make changes to this bug.