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

Don't localize command names on the command palette #4679

Closed
espresso3389 opened this issue Mar 25, 2016 · 84 comments
Closed

Don't localize command names on the command palette #4679

espresso3389 opened this issue Mar 25, 2016 · 84 comments
Assignees
Labels
important Issue identified as high-priority l10n-platform Localization platform issues (not wrong translations) verified Verification succeeded
Milestone

Comments

@espresso3389
Copy link

  • VSCode Version:
    バージョン 0.10.12-insider
    コミット ef2a1fc
    日付 2016-03-21T11:33:38.240Z
    シェル 0.35.6
    レンダラー 45.0.2454.85
    ノード 4.1.1

Even Japanese people, typing Japanese words are very painful and time-consuming because of IME composition problems.
We expects that the commands are all in English.
For example, if I want to execute git pull, I will type "git pull"; not "git プル".

Hope you can understand our situation.

image

@espresso3389
Copy link
Author

I found that the incremental search anyway does not work for IME composed texts. If I correctly type "Git: プル" it is highlighted, but "git pull" does not find anything.

animation

@Tyriar
Copy link
Member

Tyriar commented Mar 26, 2016

Related to this, it would be good to introduce aliases to some commands in the command palette. For example "Reload Window" could have the alias "Restart Window" to improve discoverability.

@Tyriar
Copy link
Member

Tyriar commented Mar 26, 2016

@espresso3389 which IME are you using? And which version of Windows?

@espresso3389
Copy link
Author

I'm on Windows 10 and the IME is ATOK; a Japanese thirdparty IME.
Even with MS-IME, the behavior is same.
Typing "git: プル" correctly works but doing "git プル" does not work.
The search function does not seem to work with Japanese characters.

@espresso3389
Copy link
Author

I totally agree with @Tyriar. What we really need is "command alias" in the case. With such aliases, I don't want to stop Japanese localization.

@Tyriar
Copy link
Member

Tyriar commented Mar 27, 2016

@expresso3389 I moved the IME bug over to #4691, this issue can discuss whether or not the command palette should be translated and to what extent.

@Tyriar Tyriar added *question Issue represents a question, should be posted to StackOverflow (VS Code) l10n-platform Localization platform issues (not wrong translations) labels Mar 27, 2016
@dbaeumer dbaeumer assigned bpasero and unassigned dbaeumer Mar 29, 2016
@dbaeumer dbaeumer removed the l10n-platform Localization platform issues (not wrong translations) label Mar 29, 2016
@dbaeumer
Copy link
Member

Not translating the command names doesn't make too much sense to me. Why only the command names? IMO we need to fix the filtering tracked in #4691. And aliases would only help if they are user definable since Restart Window would be translated as well.

In general I think the command palette filtering should be improved where the command provide can provide additional search and filter strings.

@bpasero I move this to you to consider improving the command palette with additional filter / search strings.

@bpasero bpasero assigned chrisdias and unassigned bpasero Mar 29, 2016
@bpasero
Copy link
Member

bpasero commented Mar 29, 2016

I would suggest that we do not mix english strings together with other language strings but rather ask our users to change the language to english for the entire application (F1 > Configure Language).

I leave this decision up to our PM @chrisdias

@Tyriar
Copy link
Member

Tyriar commented Mar 29, 2016

@bpasero remember though that "mixing languages" may be natural depending on the language. I imagine typing git pull is far more natural to Japanese programmers than git プル which requires an extra effort to type due to the ime change.

@bpasero
Copy link
Member

bpasero commented Mar 29, 2016

Yeah, I see the issue for commands that are really close to their terminal counter parts.

@bpasero
Copy link
Member

bpasero commented Mar 29, 2016

Maybe we should just document for those NLS strings that they should not get translated at all?

@yanxyz
Copy link

yanxyz commented Mar 31, 2016

I have just installed VS Code Insiders and found all the commands are translated. eg. when installing an extension instead of typing ext I have to type:

image

My Windows language is Chinese. I have to guess which Chinese word I should use when referring to the VS Code Docs, however which word should be used is decided by the translator. And as you can see it's too boring to input EAST Asia words. There is a Chinese idiom 过犹不及 which means too much of a good thing.

p.s. Change VS Code locale (修改 VS Code 的语言)

@Tyriar Tyriar added important Issue identified as high-priority l10n-platform Localization platform issues (not wrong translations) labels Mar 31, 2016
@lychichem
Copy link

As a Chinese user who do l10n work for Mozilla Firefox, I strongly suggest you DO NOT translate command strings in command panel. I have to try to translate all the command I want to use to Chinese exactly identical to your translation, that is very painful. You can just give out an explanation which is shown when mouse is on the command name and just translate the explanation.

@egamma egamma mentioned this issue Apr 4, 2016
68 tasks
@CrotchBurnt
Copy link

BTW, there should be a "UI language" in the User Settings, instead of only showing in the language which is the running OS' default UI language.

@chrisdias
Copy link
Member

@showerying you can set the locale from the command line or in a locale.json file, see here: https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#localization

@be5invis
Copy link
Contributor

A better solution should be show the translated version and the original version side-by-side and search the command using both of them.
When editing source code, Chinese and Japanese users will turn off the IME to avoid it affecting inputting special symbols, however the “translated” command palette will force them turn the IME on.

@lychichem
Copy link

Have you ever considered the length of a string and the width of the command palette? If both versions are shown we need to solve this problem so our users can see a full string.

@bpasero
Copy link
Member

bpasero commented Apr 21, 2016

@be5invis agree, keywords can be a useful concept in cases where you can describe the command with different words. I am fine leaving that in for matching but I would not show keywords anywhere in the UI.

@be5invis
Copy link
Contributor

be5invis commented Apr 21, 2016

@bpasero But if you decide to display English label as primary, then the keywords is less useful, but I think it still worth preserving.

@bpasero
Copy link
Member

bpasero commented Apr 21, 2016

To be clear, the keywords currently are english and are not translated. If we decide to keep keywords, the interesting challenge is that you would probably need to have both translated keywords and english. Hence I am thinking of not keeping keywords (we never had them and imho they are separate from the discussion here and just nice to have).

@be5invis
Copy link
Contributor

@bpasero My main idea is that, if users can directly see the English label clearly (which means that the primary label is in English, not translated), then the English keywords are less important. However, if what they directly see is translated, then they may come up with synonyms of the English command, and the keywords are very useful now.
Translated keywords are unnecessary.

@bpasero
Copy link
Member

bpasero commented Apr 21, 2016

Well I propose to show english always first and the translated label below less prominent, hence we both agree that keywords are not needed.

@be5invis
Copy link
Contributor

@bpasero Agree with you.

@chrisdias
Copy link
Member

Thanks everyone for the great discussion on this topic. We appreciate all of the feedback and especially the insight on how you use the tool in both english and native languages. This was valuable input into our UX design meeting @egamma mentioned above, so I wanted to share with you the results of our conversation.

Here is what we decided:

  • always show the english label
  • show the translated label below the english label IF the language is !== en-US
  • allow search on both english and translated labels
  • remove the keywords, the above experience makes these unnecessary

We only have a small window to get this into the current iteration and given the feedback here, we think we've got the right design, so we're going to push forward with this plan.

We expect to do another Insiders drop early next week and then ship this in the April release. From there, we can then make modifications to the experience in the next iteration (if necessary!).

Thanks again, we think we will have a much better and much more natural experience because of your input.

@wyntau
Copy link

wyntau commented Apr 22, 2016

Happying ending 😄

@bpasero bpasero assigned isidorn and unassigned bpasero Apr 22, 2016
@bpasero
Copy link
Member

bpasero commented Apr 22, 2016

Pushed.

@bpasero
Copy link
Member

bpasero commented Apr 26, 2016

We did a decision today in the team to show the localized command first and the english one below. @stevencl @bgashler1 @chrisdias fyi

@be5invis
Copy link
Contributor

@bpasero So, re-enable keywords?

@bpasero
Copy link
Member

bpasero commented Apr 26, 2016

No, you can still search for english labels:

image

@be5invis
Copy link
Contributor

Oh translated and English is in same size
That's good

@bpasero
Copy link
Member

bpasero commented Apr 26, 2016

The rationale for this change was to emphasize the fact that the UI is translated to a certain language. Showing the english labels enables to find and memorize the english commands for faster typing but the UI is otherwise consistently translated. Showing the english label first would draw the wrong impression about the primary language of VS Code.

@espresso3389
Copy link
Author

@bpasero
Personally, I don't totally agree to the final decision (Translated first) but anyway I appreciate VS Code team's effort to understand our situation. Thanks so much!

@bgashler1
Copy link
Contributor

@espresso3389 is it that you want the translation below? Or would you prefer to disable the translation completely and just use English. If so, we do allow you to turn it off.

@be5invis
Copy link
Contributor

@bgashler1 Make it configurable will be better

@espresso3389
Copy link
Author

@bgashler1

is it that you want the translation below?

Yes, it would be better "for me" if I can choose which one comes first.
But not so important so far.

@Tyriar
Copy link
Member

Tyriar commented Apr 28, 2016

Considering that the English version is the "primary" one, at least for CJK languages, I think it makes sense for that to come first. This may not be the same for languages that don't use an IME though.

@WhiteCat6142
Copy link

By the way,can I change font sizes?
I want to make primary keywords bigger than secondary ones.

@isidorn isidorn added the verified Verification succeeded label Apr 29, 2016
@espresso3389
Copy link
Author

Agree with @WhiteCat6142.
The current gray color is not enough to tell the actual commands from the translations.
If the translations (or, for some case, the actual commands) are smaller, it's easier to see what are on the palette.

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
important Issue identified as high-priority l10n-platform Localization platform issues (not wrong translations) verified Verification succeeded
Projects
None yet
Development

No branches or pull requests