Skip to content

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

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 94 additions & 0 deletions doc/specs/#4476 - Mini-Spec for Localizable Profiles Names.md
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" }
Copy link
Member

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 just key?

Copy link
Contributor Author

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

}
```

## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i18n?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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 userDefaults. Esp. considering there's only 2 profiles in there by default, if they copy-pasta the cmd one, that might get really confusing.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"name": { "key": "CmdDisplayName", "default": "cmd" }

maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 [KEY] so they can see the error of their ways.

Either way, I’ll include it in the spec


## Future considerations

If we allow the command palette's contents to be driven through JSON
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configuration, localized resource strings will become important.