-
Notifications
You must be signed in to change notification settings - Fork 890
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
Implement correct normalization of locales in i18n #8535
Implement correct normalization of locales in i18n #8535
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8535 +/- ##
==========================================
- Coverage 60.93% 60.93% -0.01%
==========================================
Files 3771 3770 -1
Lines 89541 89554 +13
Branches 14017 14015 -2
==========================================
+ Hits 54563 54570 +7
- Misses 31567 31572 +5
- Partials 3411 3412 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
6f49c5a
to
9fc471a
Compare
Also: * Stop examining the fragment identifier for possible locale overrides Signed-off-by: Miki <miki@amazon.com>
Signed-off-by: Miki <miki@amazon.com>
9fc471a
to
f57441c
Compare
Was this used by anything |
export function normalizeLocale(locale: string) { | ||
const { lang, script, region } = localeParser.exec(locale)?.groups || {}; | ||
// If parsing failed or the language code was not extracted, return the locale | ||
if (!lang) return locale; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the right thing to accept the bad input or default in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This guy only does the normalization; (in)validation is handled by comparing it against those that have been registered in a different place.
@@ -100,6 +100,15 @@ export class RenderingService { | |||
opensearchDashboardsConfig as OpenSearchDashboardsConfigType | |||
); | |||
|
|||
let locale = i18n.getLocale(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this always a defaulted/configured valid locale?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
defaulted: yes
valid: no
i18n starts with en
as the default locale and if configured in the YAML config, it uses that without validating that it has been registered or not; I think this is because while reading the config, the filesystem might not have been read to prime the translation registration cache. At runtime, the locale is validation and if found to not have been registered, en
is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the code, if invalid, then does it potentially lead to a translation file not being loaded? Is this okay because english translations are loaded worst case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the locale is not registered, it would just use English, yes.
@@ -55,7 +55,8 @@ import { getApmConfig } from '../apm'; | |||
*/ | |||
export function uiRenderMixin(osdServer, server, config) { | |||
const translationsCache = { translations: null, hash: null }; | |||
const defaultLocale = i18n.getLocale() || 'en'; // Fallback to 'en' if no default locale is set | |||
// `i18n.getLocale` will always return a value; the 'en' is just to accommodate tests | |||
const defaultLocale = i18n.getLocale() || 'en'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this always be comparable to a normalized locale? (given toLowerCase was dropped)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everyone now goes through normalizeLocale
, as opposed to .toLowerCase()
which is what the older normalize was doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw this PR removes getLocaleInUrl
then introduces a new way to handle locale specification in URLs by checking query parameter const localeOverride = (request.query as any)?.locale?.trim?.();
I think the previous way is to handle both standard query or non-standard one, given the two formats of current osd urls. For the URL format like (https://localhost:9200/app/home#/?locale=cn), where the locale is specified in the hash fragment rather than as a regular query parameter, it seems we can't handle.
Does it mean we will not work on such url and request the standard query format if user need this feature? Should we add some documents somewhere for user?
No. We haven’t started using any of the theme or locale overrides yet. |
That is correct. We cannot parse and handle URL fragments on the server-side and as such would rather not entertain them. A similar pattern is used for the theme. These two parameters are exclusively being introduced to temporarily override a setting and are not meant to be suffixed to every URL fragment.
I don't believe these are to be part of our public API. If we decide to make them, we should. |
The backport to
To backport manually, run these commands in your terminal: # Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch-Dashboards/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch-Dashboards/backport-2.x
# Create a new branch
git switch --create backport/backport-8535-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2b149d242cd4f7420c755fe77538b0c56f3677ab
# Push it to GitHub
git push --set-upstream origin backport/backport-8535-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch-Dashboards/backport-2.x Then, create a pull request where the |
…t#8535) * Implement correct normalization of locales in i18n Also: * Stop examining the fragment identifier for possible locale overrides Signed-off-by: Miki <miki@amazon.com> * Update relative formats and plural rules for certain locales Signed-off-by: Miki <miki@amazon.com> --------- Signed-off-by: Miki <miki@amazon.com> (cherry picked from commit 2b149d2) Signed-off-by: Miki <miki@amazon.com>
* Implement correct normalization of locales in i18n Also: * Stop examining the fragment identifier for possible locale overrides * Update relative formats and plural rules for certain locales --------- (cherry picked from commit 2b149d2) Signed-off-by: Miki <miki@amazon.com>
…t#8535) * Implement correct normalization of locales in i18n Also: * Stop examining the fragment identifier for possible locale overrides Signed-off-by: Miki <miki@amazon.com> * Update relative formats and plural rules for certain locales Signed-off-by: Miki <miki@amazon.com> --------- Signed-off-by: Miki <miki@amazon.com>
Description
Implement correct normalization of locales in i18n
Also:
Changelog
Check List
yarn test:jest
yarn test:jest_integration