-
Notifications
You must be signed in to change notification settings - Fork 8.6k
Spec: Introduce a mini-specification for localized resource use from JSON #5280
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,94 @@ | ||
--- | ||
author: Dustin L. Howett (@DHowett-MSFT) | ||
created on: 2020-04-07 | ||
last updated: 2020-04-07 | ||
issue id: #4476 | ||
--- | ||
|
||
# Localizable Profile Names | ||
|
||
## Abstract | ||
|
||
One of the profiles we ship by default, "cmd", should be named "Command | ||
Prompt". Unfortunately, "Command Prompt" is a localizable name in Windows. If | ||
we ship with it as-is, we will be breaking with the display name used for cmd | ||
in Windows. | ||
|
||
It would be, broadly-speaking, possible to generically localize the entire | ||
`defaults.json` file and the user settings template. To do so would add untold | ||
burden on the localization team as they would have to maintain the structure of | ||
the file, and the Terminal engineering team as we would need to make sure that | ||
all localized copies of `defaults.json` and the user settings template match in | ||
non-string content. | ||
|
||
If we want to properly localize profile names (and other resources that will | ||
eventually be used in our JSON settings), we will need to support resource | ||
loading from JSON. | ||
|
||
## Solution Design | ||
|
||
I propose that we augment our JSON object model deserializer to support | ||
_objects containing the `resourceKey` member_ and treat them as resource key | ||
lookups at the time of loading. | ||
|
||
We would then use this functionality when deserializing profile names. | ||
|
||
### Profiles, Before | ||
|
||
```json | ||
{ | ||
"name": "Command Prompt" // not localizable. | ||
} | ||
``` | ||
|
||
### Profiles, After | ||
|
||
```json | ||
{ | ||
"name": { "resourceKey": "CommandPromptDisplayName" } | ||
} | ||
``` | ||
|
||
## Capabilities | ||
|
||
### Accessibility | ||
|
||
Localizable names are inherently more accessible. | ||
|
||
### Security | ||
|
||
A user would be able to set, as a display string, any resource from the | ||
Terminal application resource compartment to appear as a profile name. Given | ||
that all of our strings are intended for UI use, this does not represent a | ||
significant concern. | ||
|
||
### Reliability | ||
|
||
This will not impact reliability. | ||
|
||
### Compatibility | ||
|
||
A change in profile name, especially one that happens after the product ships | ||
(due to a changing i18n setting on the system), will impact users accustomed to | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Industry-accepted term for “Internationalization” |
||
`wt -p profile`. I have no answer for how best to resolve this, except "get | ||
used to it". | ||
|
||
Since we also emit the name `cmd` in the user's settings template, we will want | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yikes I think a comment would probably be best here, I don't think we want to have to burden users with using the longer form in |
||
to either remove that field (move it to a comment) or switch it to | ||
`resourceKey` as well. | ||
|
||
Existing users will not see localization changes in default profiles, as their | ||
settings templates included hardcoded `name` fields. | ||
|
||
### Performance, Power, and Efficiency | ||
|
||
## Potential Issues | ||
|
||
As above in Compatibility. | ||
|
||
We need a fallback in case a resource cannot be found. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "name": { "key": "CmdDisplayName", "default": "cmd" } maybe? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure about having a default. Things we specify should actually assert during DEBUG that they don’t exist, because it’s very important that we land all the resource keys right. Things the user specifies that don’t exist should return something like Either way, I’ll include it in the spec |
||
|
||
## Future considerations | ||
|
||
If we allow the command palette's contents to be driven through JSON | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. oh man if only there was a spec for that |
||
configuration, localized resource strings will become important. |
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.
Do we want
resourceKey
or justkey
?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.
+1 to key as it’s more concise