Skip to content
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

Missing i18n Translation Keys Causing UI Inconsistencies #10401

Open
rajku-dev opened this issue Feb 5, 2025 · 9 comments · May be fixed by #10463
Open

Missing i18n Translation Keys Causing UI Inconsistencies #10401

rajku-dev opened this issue Feb 5, 2025 · 9 comments · May be fixed by #10463
Assignees
Labels
needs-triage question Further information is requested

Comments

@rajku-dev
Copy link
Contributor

rajku-dev commented Feb 5, 2025

Describe the bug
Several translation keys used in the t function throughout the codebase are missing from the en.json file. This results in inconsistencies in the UI, where untranslated strings may appear instead of the expected localized text.

Example

Image

Image

Expected behavior
All translation keys used in the codebase should have corresponding values in en.json to ensure a consistent and fully localized UI.

Click here to reproduce

Desktop (please complete the following information):

  • Windows 11
  • Chrome Version 132.0.6834.160
@tellmeY18 tellmeY18 added this to Care Feb 5, 2025
@tellmeY18 tellmeY18 moved this to Triage in Care Feb 5, 2025
@rajku-dev
Copy link
Contributor Author

rajku-dev commented Feb 5, 2025

If valid, I would like to take this issue up,
I have made most changes

@rajku-dev rajku-dev changed the title i18n translations not defined for used keys Missing i18n Translation Keys Causing UI Inconsistencies Feb 5, 2025
@rithviknishad
Copy link
Member

@rajku-dev can we add a lint rule to error out if there are missing i18n translations? so that the build fails if key is not found.

@rithviknishad rithviknishad moved this from Triage to Up Next in Care Feb 5, 2025
@tellmeY18 tellmeY18 moved this from Up Next to In Progress in Care Feb 5, 2025
@rajku-dev
Copy link
Contributor Author

@rajku-dev can we add a lint rule to error out if there are missing i18n translations? so that the build fails if key is not found.

got it!
i found a plugin for that
https://www.npmjs.com/package/eslint-plugin-i18next-no-undefined-translation-keys

@AdityaJ2305
Copy link
Contributor

@rajku-dev , I think there is already a plugin configured for i18 in eslint config file and missing translation as warning. Could you check with that . I am not 100% sure btw

@rajku-dev
Copy link
Contributor Author

@rajku-dev , I think there is already a plugin configured for i18 in eslint config file and missing translation as warning. Could you check with that . I am not 100% sure btw

yeah but i think it doesn't offer that particular check we need?

@github-actions github-actions bot added needs-triage question Further information is requested labels Feb 5, 2025
@rithviknishad
Copy link
Member

why not? all i had to do was change from warn to error, and it converts those warnings to errors

Image Image

@AdityaJ2305
Copy link
Contributor

why not? all i had to do was change from warn to error, and it converts those warnings to errors

Image Image

Exactly 💯

@rithviknishad
Copy link
Member

one additional thing pending would be to get incorrect key usages. t('a_key_that_does_not_exist') should also throw an error ideally.

@rajku-dev
Copy link
Contributor Author

rajku-dev commented Feb 5, 2025

We can definitely track the errors like that but,

these errors are for the "hardcoded-strings"
it is not including the translation keys that are undefined in en.json

Refer : https://www.npmjs.com/package/eslint-plugin-i18next

  1. without undefined check - only hardcode string errors - count 1429

  2. with undefined check - include undefined keys errors - count 1453 (24 extra)

  3. only undefined check - count 24

24 undefined strings output using a script

to solve the issue before build we should be doing the third check only right, because first check has no significance because it is also checking for hardcode strings inside className, variant, size, href etc.

so should we use the no-undefined-translation-keys plugin or both? @rithviknishad

rajku-dev added a commit to rajku-dev/care_fe that referenced this issue Feb 7, 2025
@rajku-dev rajku-dev linked a pull request Feb 7, 2025 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage question Further information is requested
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants