Repository navigation
Fixes #34583: Restore the Users and Admin page link in 13 locales - #35494
theluckystrike wants to merge 1 commit into
Conversation
…3 locales
The no-user/no-admin empty state messages in 13 locales dropped the second
sentence with the <0> link to the Users or Admin page. Restore it from the
current en-us text. Also restore {{count}} in de-de
message.activity-on-assets-owned-by-you-or-your-teams_one.
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically. Maintainers can bypass this check by adding the |
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
Code Review ✅ Approved🟡 Medium risk · Restoring translated Users/Admin links changes empty-state navigation; a mismatched localized link could send users to the wrong page. Restores the second sentence with the VerificationRules No rules evaluated Functional validation Not enabledAuto-approval Not enabledFor more verification details, comment OptionsDisplay: compact → Showing compact verification results. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
This branch has not been deployed
1 participant
Describe your changes:
Fixes #34583
Follow up to #34584. I restored the second sentence with the
<0>link to the Users or Admin page in 52 translated UI strings across 13 locales, because these translations stopped after the first sentence ("No users found with name ...") and dropped the link that en-us renders through the<0>Trans tag. The keys aremessage.no-user-available-with-name,message.no-user-available-with-filters,message.no-admin-available-with-nameandmessage.no-admin-available-with-filters. Each value keeps the existing first sentence and adds a translation of the current en-us second sentence, with{{searchText}}and<0></0>exactly as in en-us. The other 7 locales (ar-sa, ko-kr, pt-pt, sv-se, tr-tr, zh-tw and en-us) already have the link and are unchanged.This also covers the de-de part that @HalmSascha offered to leave with us on #34584, plus one more de-de fix:
message.activity-on-assets-owned-by-you-or-your-teams_onehad lost{{count}}, while the_otherform and en-us both use it.Only the values change. Keys, key order and file formatting are byte identical. None of these keys is changed by #34584, and none sits on a line next to one it changes, so the two PRs merge in either order without conflicts.
How I checked them. A small script parses every file in
locale/languages, flattens the keys and diffs each value against main. For every value that changed it compares the set of{{placeholders}}and<N>/</N>Trans tags with the en-us value for the same key, and it fails if the key set or key order of any file changed. Result: 20 files parsed, 53 changed values, 0 mismatches. A second pass over all 20 locales confirms the four keys now carry the same tags as en-us everywhere.Type of change:
High-level design:
N/A, small change limited to locale values.
Tests:
Use cases covered
UserListPageV1.tsxrenders<0>as aLinkthroughTransi18next).Unit tests
Backend integration tests
Ingestion integration tests
Playwright (UI) tests
Manual testing performed
sync-i18n --files '**/locale/languages/*.json' --primary en-us --space 2 --fn --check(thecheck-i18nscript, i18next-json-sync 3.1.2) on main and on this branch. Both exit 0.UI screen recording:
Not applicable, localization values only.
Checklist:
Fixes <issue-number>: <short explanation>Fixes #<issue-number>above.docs/decisions/.