-
Notifications
You must be signed in to change notification settings - Fork 29.3k
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
Pass display language as a locale to Electron #159958
Conversation
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 like this change but I have small concern for this fix being shipped as candidate.
The change impacts ICU's default locale for both chromium and node, also affects Accept-language
header. Although I agree that these values should match the display language set in VSCode, is there a history for why we haven't done this since the beginning ? Did we have any bugs when we configured the locale of Electron ? @bpasero do you know anything on this ?
I am not aware of the reasoning why we never did this, maybe @dbaeumer, @joaomoreno or @TylerLeonhardt know of a reason. However, we do set the vscode/src/bootstrap-window.js Lines 96 to 103 in 4f69cdf
One thing to keep in mind is that |
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 feel this is a bit too heavy for a candidate and would rather suggest to do this on insiders and disable WCO on stable as the candidate fix.
This would only impact the render process in which it was changed, main process would remain unaffected. WCO rendering depends on the locale of the main process. Ideally, to change the application locale of chromium, application has to configure the
Thanks for the pointer, Do we use system locale for any scenarios ? Other cases we can default to same value as |
Yup this sounds better 💯 |
I am not sure I understand the difference between Yes we use Lines 552 to 568 in 4f69cdf
|
@rzhao271 we can continue this PR to address the locale of the runtime after connecting with @TylerLeonhardt and @dbaeumer . But for resolving #159813 as a candidate, can you open a separate PR that disables WCO. Thanks! |
Here is what I can remember:
|
@dbaeumer which components of the UI or core does this value affect ? Especially in cases where language pack and locale value are different. |
The |
For #159958 (comment), the reason that One issue with this approach is I'm unsure what happens when the language pack doesn't represent a valid locale, such as with the pseudo-language extension pack. In that case, I'd hope that the locale would default back to |
Based on the Given we want
@dbaeumer @TylerLeonhardt does this make sense ? |
Sounds great! I was just saying to @rzhao271 that we needed an API for "give me whatever the OS says, not anything else" |
Makes perfect sense to me. It is basically locale and lang in out model. |
Great, thanks for the feedback. @rzhao271 lets start with adding the Electron API as next step. |
b66a86a
to
970ba2c
Compare
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 thought we wanted to exclude this in stable? If so, please use product.quality !== stable
around the new code.
Use app.getSystemPreferredLanguages rather than app.getSystemLocale because the former returns much more accurate results.
4ac2ed6
to
da06988
Compare
I did some sanity checking on Windows and noticed that when I had no |
Another round of sanity testing:
|
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.
What does this change actually mean for our support to run code --locale
? I just now found out that we advertise for it when you run code --help
. This probably should then override whatever is in argv.json
?
85e0f46
to
422fce8
Compare
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 am a bit confused by your last change, I was not suggesting to remove the locale
check, just consolidate it in one place. Why is it removed now? Do we no longer have to check for argv.json
and locale
?
I consolidated the checks—the check for the locale arg already happens at Line 584 in 0f9b263
|
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.
Your last change makes good sense 👍
Can we also test what happens when you pass a bogus value to the lang
switch, will the startup continue normally or do we have to validate the input?
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.
LGTM on the Electron changes.
I just tested this with electron-v22.0.0-beta.5 which has my API change merged in. On Windows 11, it seems to default to the system language which I currently have set to Chinese (first preferred language: fr-CA, regional format: fi-FI, system language: zh-CN) |
Ref #159813
Passing the locale to Electron fixes how the WCO is rendered, otherwise, Electron decides the locale based on the system language. The WCO should be rendered based on the display language, not the system language.
Ref #161218
Fixes #163458
TODO:
The screenshot below shows that the WCO has been moved out of the way with the fix.