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

Recent workspaces: "hold ctrl+key to open in new window" shows regardless of "window.openFoldersInNewWindow": "on" #93943

Closed
Tyriar opened this issue Mar 31, 2020 · 7 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug L10N Translation issue verified Verification succeeded
Milestone

Comments

@Tyriar
Copy link
Member

Tyriar commented Mar 31, 2020

#93729

Version: 1.44.0-insider (user setup)
Commit: d7d1147
Date: 2020-03-31T08:23:56.446Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362


I have "window.openFoldersInNewWindow": "on" set and recent workspaces shows this:

image

It would be lovely if the ctrl behavior was inverted here if the setting is "on".

@bpasero
Copy link
Member

bpasero commented Mar 31, 2020

@Tyriar where is this coming from, shouldn't it look like this now:

image

???

@bpasero bpasero added the info-needed Issue requires more information from poster label Mar 31, 2020
@Tyriar
Copy link
Member Author

Tyriar commented Mar 31, 2020

I see it's changed in the code, I reinstalled VS Code. Maybe some folders had permissions issues during an update or something 🤷‍♂

@Tyriar Tyriar closed this as completed Mar 31, 2020
@Tyriar
Copy link
Member Author

Tyriar commented Mar 31, 2020

OH! I have the en-GB language pack installed...

@dbaeumer I would have thought this would invalidate the translation when the string value changes? Should we be changing the nls key if the string changes dramatically like this?

@dbaeumer
Copy link
Member

No, string values are keyed by the key we provide to the nls.localize call. This is how these translation databases work today. One idea we were discussing with them to hash the value and use it as a key but that didn't make them happy since these hash values would show up in all their tools in the user interface and they were concerned this confuses translators. So we left the key.

Bottom line: to be on the save side changing the key will fix this. But it will also be fixed when a new LP ships.

@dbaeumer dbaeumer removed their assignment Mar 31, 2020
@Tyriar
Copy link
Member Author

Tyriar commented Mar 31, 2020

@dbaeumer does changing the en-US value trigger the string to get re-localized, if not we could be building up a significant amount of strings in other languages that no longer match the English version?

@bpasero bpasero closed this as completed in 1055a53 Apr 1, 2020
@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug L10N Translation issue and removed info-needed Issue requires more information from poster labels Apr 1, 2020
@bpasero bpasero added this to the March 2020 milestone Apr 1, 2020
@bpasero
Copy link
Member

bpasero commented Apr 1, 2020

Changed the key.

@dbaeumer
Copy link
Member

dbaeumer commented Apr 1, 2020

@Tyriar yes, a string change in the nls.localize call will trigger a re-translation in all LP packs.

@Tyriar Tyriar added the verified Verification succeeded label Apr 3, 2020
@github-actions github-actions bot locked and limited conversation to collaborators May 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug L10N Translation issue verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

3 participants