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

Investigate how to best unbundle prepackaed langauges #45663

Closed
dbaeumer opened this issue Mar 13, 2018 · 42 comments
Closed

Investigate how to best unbundle prepackaed langauges #45663

dbaeumer opened this issue Mar 13, 2018 · 42 comments
Assignees
Labels
l10n-platform Localization platform issues (not wrong translations) on-testplan plan-item VS Code - planned item for upcoming
Milestone

Comments

@dbaeumer
Copy link
Member

With VS Code 1.21 we started to support language packs. We should now start to think about how to best unbundle pre-packaged language and used language packs instead. This transition period should be for existing users as smooth as possible. So may be we still ship the pack and installed it if shipped. For new users it is OK to ask them to download a language pack.

@dbaeumer dbaeumer self-assigned this Mar 13, 2018
@dbaeumer dbaeumer added the plan-item VS Code - planned item for upcoming label Mar 13, 2018
@dbaeumer dbaeumer added this to the March 2018 milestone Mar 13, 2018
@dbaeumer
Copy link
Member Author

dbaeumer commented Mar 21, 2018

I propose to do the following to un-bundle the prepacked languages:

  1. for the core languages we also create language packs and publish them to the market place except for English. This will always ship pre-bundled.
  2. we ship all core languages bundled as well for the next n months.
  3. when VS Code starts and the UI is in one of the core languages we download the translation from the market place and install the extension in the background. This requires work from @sandy081
  4. when VS Code starts and detects an extension for one of the core languages we use the extension instead of the bundled one. We could even do some A/B testing here but since the translations should be the same there is no win. This requires work from @dbaeumer
  5. after n months we remove the core languages from VS Code (except English). This require work from @dbaeumer (change build scripts)

This approach ensures a smart transition for users that already use a UI other than English. They basically don't see any differences to today.

For users that install a fresh version of Code at a point in time were we only ship English the experience would be as follows:

  1. UI comes up in English.
  2. a message is shown that there is a language pack for the UI language used by the OS and whether the user wants to install it. This message must be in English and the UI language used by the OS (the user might not speak English and with our current solution the UI would come up in the UI language of the OS). This requires work from @ramya-rao-a especially around the fact that we would need to present the string in English and the UI language. Ideas to get to the UI language strings would be:
    1. hard code them in the VS Core
    2. Use hidden tags in the market place (@sandy081 would this be feasible. Is there a size limit to tag values). This also requires to be online.
    3. Download the extension and have the strings in the package.json file of the extension. This also requires to be online.
  3. if the user accepts the installation we will install the language pack and switch the UI language.

@dbaeumer
Copy link
Member Author

@ramya-rao-a @sandy081 can you please read and comment.

@ramya-rao-a
Copy link
Contributor

Sounds good. Hard coding the message in the core languages is the simplest way to go. Hidden tags for just one message feels like an overkill

@dbaeumer
Copy link
Member Author

In my model we need to have the messages for all languages. Would be cool if someone runs in Bulgarian and he sees a message in Bulgarian and English. This is how Windows behaves as well.

@sandy081
Copy link
Member

  1. when VS Code starts and the UI is in one of the core languages we download the translation from the market place and install the extension in the background. This requires work from @sandy081

If this is when VS Code is bundled with core languages then Why do we need to download from Marketplace? I think this should be needed when VS Code is not bundled with core languages and user had set up VS Code before with one of the core languages.

When VS Code is not bundled with core languages, Downloading during start up will impact the start up performance (only the time we download) and what do we do if user is offline? I think we have two cases here:

Users with VS Code installed before and go through update cycle

  • While updating, download the lang pack if the user is using a core lang pack. This will regress the behaviour that user cannot simply set the locale to other core languages. User has to install the language pack before setting.

  • While updating, download all core language packs

Users with VS Code installed before and install/download VS Code again
Users with fresh install of VS Code

  • Have the same experience as for new User?
  • Did we think about a Installation wizard asking the language to pick?

Regarding message in OS Language, I would not go for tags. Hardcoding them for all languages is not practical. As @dbaeumer said, it can help for some (core+known) languages but not if there is a new. I think reading it from the package.json is a good option in which case we should come up with a property in package.json to be used. What if the extension does not provide the message in package.json? We might need a validation check while generating the vsix.

@dbaeumer
Copy link
Member Author

If this is when VS Code is bundled with core languages then Why do we need to download from Marketplace?

To have a smooth migration for existing users. So we will switch them to language packs without them noticing and difference in the UI. If we first unbundle all core language then they will be promoted to download their language pack. This is to avoid that prompt.

We though about doing this in update, but we have different update stories for Mac, Windows, Deb, RPM and I was trying to come up with one solution instead of 4 :-).

New users will get a different experience (even for the current core language) since at some point we will ship English only. For them I think it is important that they see at least the 'language pack instsall message' in their UI language.

@dbaeumer dbaeumer modified the milestones: March 2018, April 2018 Mar 29, 2018
@sandy081
Copy link
Member

To have a smooth migration for existing users. So we will switch them to language packs without them noticing and difference in the UI. If we first unbundle all core language then they will be promoted to download their language pack. This is to avoid that promp

I think it is a good idea to download the lang pack extensions from Marketplace while they are bundled with VS Code to prepare for next step. This would need confirmation from user to download. Downloading without asking might not be good. I think this can also be done while checking for the VS Code update and inform the user that update to next version of VS Code need to install so and so language pack extensions.

@dbaeumer
Copy link
Member Author

dbaeumer commented Apr 3, 2018

Agree on the fact that we need to let the user know that we are donwloading language packs.

@sandy081 sandy081 self-assigned this Apr 23, 2018
@sandy081 sandy081 added the l10n-platform Localization platform issues (not wrong translations) label Apr 23, 2018
@dbaeumer
Copy link
Member Author

@ramya-rao-a I assume now work has happened for the messages. I will move the item to Mai to keep it so that we can finish things up.

@waldyrious
Copy link
Contributor

Just a quick note, in case it helps with task tracking related to this issue: if I'm understanding correctly, after this change is completed, the wiki page Visual Studio Code Community Localization Project (particularly the Language set section) will have to be updated to reflect the new setup, right?

@sandy081
Copy link
Member

sandy081 commented May 7, 2018

@waldyrious Yes, thanks for bringing this up

@ramya-rao-a
Copy link
Contributor

ramya-rao-a commented May 22, 2018

@dbaeumer @sandy081

@kieferrm and I have the below proposal for the message that prompts the user to search/install the language pack corresponding to their display UI language

  • There are 3 such strings. One the actual message, and the other 2 for the actions on the notification.
  • Include the message and the accompanying text on the actions, as strings to be localized in the product, such that they get picked up by folks over at transifex. This is especially helpful for new languages over time
  • During endgame, pull these localized strings into the product.
  • When the language being shown is English, but users display language is different and we have the above strings localized in the display language, the prompt will say something like There are extensions in the Marketplace that can localize VS Code using the ${0} language
  • The first action would be Search Marketplace which will pre-fill the search text in the Extensions view with the tag for corresponding locale. Example: tag:lp-pt-br. The second action would be Don't show again
  • The reason I suggest Search Marketplace instead of Install extension is that in the future there can be multiple extensions providing localization for the same language. Instead of taking sides, we let the user decide.

43d48b1 is how it would look like if we pulled these localized strings into the product.json file.

The decision still pending in this proposal is the place where we pull this strings. Is product.json ok or we have a dedicated json file for this. Thoughts?

@sandy081
Copy link
Member

  • Showing Search Marketplace is a good idea but I am bit concerned that Extensions view will not have translated strings and actions will be shown in English when we show language packs in the Extensions view. Also for core languages, suggesting Install Extension makes more sense (which is also same at present). So, I think it will be helpful to have an Install Action.

Include the message and the accompanying text on the actions, as strings to be localized in the product, such that they get picked up by folks over at transifex. This is especially helpful for new languages over time

Looked at the code. I understood how it works with bundled languages, but not sure about other languages. Does the VS Code still need to build and ship out of the box translations? If not, how does the translations get applied?

@ramya-rao-a
Copy link
Contributor

Yes, we can show the Install instead of Search Marketplace in the below cases

  • For languages packs of the form MS-CEINTL.vscode-language-pack- i.e the ones from the https://github.com/Microsoft/vscode-loc repo. This would include the core languages plus anything that we publish from transifex
  • Run the search before hand behind the scenes and show "Install" if there is only 1 result.

In my commit, the "bundled" languages do not refer to the bundled languages as we know and understand today. They are hard-coded localized strings that we should ship in product (either as a separate json file or in product.json).

@ramya-rao-a
Copy link
Contributor

btw the work done for #44012 was pointless. The recommendation there is based on the platform.language which never is non English for non core languages unless there is a language pack installed.

So the prompt there appeared when the user has already installed an language pack and the platform.language wasnt an exact case match with the locale used in the package json file of the extension

@dbaeumer
Copy link
Member Author

OK. Now I understand it. There is one thing to it though: currently we don't enforce a language pack to be complete. That means if these strings aren't translated they will be replaced with their English version when generating them. So it could easily happen that these strings might not be there in Bulgarian. Forcing them into package.json made it more obvious that these strings are mandatory in the Bulgarian language for example.

@sandy081
Copy link
Member

sandy081 commented May 25, 2018

I would say the approach of merging these special strings into regular translations is interesting and good. But I agree with @dbaeumer here that making these special strings part of regular translations will be confusing. Because, when you are creating a Language pack extension it is not clear about these special strings and not sure what happens if I do not provide translations to these strings. I think these strings are special in a way and extension authors should know what these strings are and when they are used.

I am also worried that vsce will now have knowledge of these translation files for reading the strings.

To be simpler and clear, How about having an optional property extensionRecommendationPromptTranslations (or something appropriate) to the schema

"localizations": [
      {
        "languageId": "abc",
        "languageName": "abc",
        "languageNameLocalized": "abc",
        "translations": [
          {
            "id": "vscode",
            "path": ""
          }
        ],
        "extensionRecommendationPromptTranslations": {
          "recommendatonMessage": "",
          "searchMarketplaceActionLabel": "Search MarketPlace in abc language",
          "installAndRestartActionLabel": ""
        }
      }
    ],

This property can be written into the vsix manifest and will be read while recommending the extension in VS Code. I think this will be clear to the author why and when this property is needed and will not overlap with general translations.

@ramya-rao-a
Copy link
Contributor

ramya-rao-a commented May 25, 2018

@dbaeumer

if these strings aren't translated they will be replaced with their English version.

The vsce tool already has many other validations in place. We can add one more to check. If there are translations for the main vscode type, but they do not contain any for the vs/platform/node/minimalTranslations.ts file, the tool fails with something like: "The strings in the file vs/platform/node/minimalTranslations.ts are the bare minimum you need to translate for this extension to be a valid language pack"

@sandy081

How about having an optional property extensionRecommendationPromptTranslations?

If its optional, then we still don't avoid the case of the strings not being translated.
We can't make it mandatory as there can be language packs that just want to do translations for say the built-in extensions

The recommendation message differs based on whether we are asking the user to install or search. So, in total there are 5 strings. Install msg, Search msg, Install label, Install & Restart label, Search label. I have a feeling it will get complicated to describe each of these.

Say, the extension author hand-writes the package.json file, how do we communicate what each of these strings are for? Say the extension author uses yo code` to generate the extension initially and we pre-fill these strings, how do we ensure that the extension author updates these strings? In the current approach, the strings get translated without any extra thought process by the extension author. The translation system takes care of it

We could add checks in the vsce tool similar to the one that we have that ensures that the README has been updated. But, we could do the same for the current approach in the PR as well.

I am also worried that vsce will now have knowledge of these translation files for reading the strings.

If we have the strings directly added to the package.json by the extension author, the vsce tool will now have to be aware of each of the 5 strings and validate that they get translated/changed. How is that any better than being aware of a single special file which is deemed as the bare minimum translations?

Yes, I agree that the vsce tool is now aware of the vs/platform/node/minimalTranslations.ts file, but the advantage is that this solution scales. For any which reason, in the future we need to display a message that we deem important enough to be translated, there is no extra work to be done by us. We just put that string in this file, and when it gets translated, it is available for use.

@sandy081
Copy link
Member

@ramya-rao-a

After thinking a lot and going through your comment, I would say I liked the approach of making these special strings part of general translations. I think if the language pack does not provide these language strings then showing them in default language (english) is a fair assumption. This gets applicable even to those language packs which are not up to date with latest.

I will go through the changes and push the changes by myself if there are any changes required since you have holiday today.

@dbaeumer
Copy link
Member Author

@sandy081 and I discussed it offline and we decide to go with the current solution. If possible we should warn the user about the fact that these translations are mandatory or at least document it.

sandy081 added a commit that referenced this issue May 28, 2018
@sandy081
Copy link
Member

@dbaeumer Looks like @ramya-rao-a is throwing an exception in vsce if these minimum translations are not found

@sandy081
Copy link
Member

@ramya-rao-a I updated the implementation to read the core translations file from market place. Core translations file is added as an asset to the vsix.

@dbaeumer
Copy link
Member Author

@sandy081 thanks.

sandy081 added a commit that referenced this issue May 28, 2018
@ramya-rao-a
Copy link
Contributor

@dbaeumer @sandy081 Thanks

When do we stop shipping the core languages out of the box? June, July?
Do we keep this issue open till that time? Or create a new one for it later?

sandy081 added a commit that referenced this issue May 28, 2018
@sandy081
Copy link
Member

sandy081 commented May 28, 2018

@joaomoreno FYI: I have to remove the asset types filter and ask for all asset types so that I can get locale translations assets. Please see the change set 684b7e7

@sandy081
Copy link
Member

@ramya-rao-a We would like to have insiders running without core languages for at least one milestone before going to stable. If translations team is ready, we can start 1.25.insiders without core languages and ship 1.25 stable without them.

@dbaeumer
Copy link
Member Author

Agree with @sandy081 suggestion.

@dbaeumer
Copy link
Member Author

I would close this issue and create a new one for the remaining work.

@ramya-rao-a
Copy link
Contributor

Thanks @sandy081 @dbaeumer
Logged #50588 for the June milestone to cover the rest

@ramya-rao-a ramya-rao-a added the verification-needed Verification of issue is requested label May 29, 2018
@RMacfarlane
Copy link
Contributor

@ramya-rao-a Can you provide a list of what should be verified as part of this issue? There are several scenarios mentioned here

@RMacfarlane RMacfarlane added the verification-steps-needed Steps to verify are needed for verification label May 30, 2018
@ramya-rao-a
Copy link
Contributor

@RMacfarlane Sorry about that. The test plan item covers everything. I'll remove the verification-needed label

@ramya-rao-a ramya-rao-a removed verification-needed Verification of issue is requested verification-steps-needed Steps to verify are needed for verification labels May 30, 2018
sbatten pushed a commit to sbatten/vscode that referenced this issue Jun 4, 2018
* Merge NPM Scripts: Added configuration option to change default click action microsoft#49282

* fix microsoft#50560

* Fix getmac test (microsoft#48804)

* Cleaning up some typos in vscode.d.ts and vscode.proposed.d.ts (microsoft#50533)

* yarn.lock changes

* grid - log serialized state if restoring failed

* Fixes microsoft#50382: Align .mtku with .detected-link

* debug issues back to isidorn

* Hide interactive playground commands from command palette (fixes microsoft#49706)

* grid - drop outline as focus indication and rely on dimmed state

* grid - allow to close empty group when closing all editors of a group

* grid - get preferredSize from grid

* Fixes microsoft#43003: Cannot specify a global problemMatcher in tasks.json

* cleanup integrated terminal support for debugging

* grid - action wording tweaks

* microsoft#45663 Use core translations asset

* grid - allow to close dirty diff editor if master is still opened in same group

* Support to run npm install from a package node

* grid - log previous UI state upon error

* grid - stronger border top color

otherwise when a tab is showing in a vertical split, the border collides with the sash border

* remove todo

* do not append logLevel

microsoft#47774

* Implement Go To Next/Previous Breakpoint editor actions

* Include enabledOnly in debug model interface

* remove from schema

microsoft#47774

* microsoft#45663 fix compilations

* change openBreakpointSource to use IBreakpoint

* return passed context if resourceOrContext is not useful

* fix off by one issue

* Simplify implementation

* return context if it has a groupId

* polish

* Fixes microsoft/monaco-editor#891: Focus editor when returning from context menu

* go to next / previosu breakpoint minor polish

* Add Endgame for 1.24

* fix index computing for editor close case

* Fix microsoft#49145

- Enable/Disable viewlets by views when context
- Move viewlet enablement/disablement to views service
- Fix - adopt if a viewlet extension is disabled/removed

* Avoid command palette entry (microsoft#49340)

* [handlebars] code-folding algorithm is less useful than Indentation-based one. Fixes microsoft#48457

* use upper lang id

* Fixes microsoft#49378

* microsoft#49145 Store placeholder states for all viewlets

* Add `logicalLine` argument to `mutlicursor.insertBelow` and `mutlicursor.insertAbove`

* Removed duplicate loop

* eliminate code duplication; use resolveWorkspaceFolder()

* microsoft#45663 Get all asset types

* [css] update service

* [html] update services

* grid - fix compile

* add User-Id to marketplace build requests

* Improve rendererType description

Fixes microsoft#50617

* fix microsoft#50672

* Fixes microsoft#49173

* fix microsoft#50321

* fix microsoft#50670

* Install option not needed when we have Install and Restart Fixes microsoft#50669

* Fixes microsoft#50616, Showing/hiding details in Issue Reporter resets scroll position

* Fix microsoft#50642, fix microsoft#50673

* Issue reporter and process explorer windows should close when the parent window closes, fixes microsoft#50716

* Issue Reporter should clear the error state when selecting an extension, fixes microsoft#50702

* Extracting methods

* Make sure we update the webview's state on setState

* Avoid prompting for same file type in the same session microsoft#50537

* Use language name instead of locale in the prompt microsoft#50738

* Use correct failed error code for webview resource load error

* Mark unused parameter

* Restore restart

* Try serializing webviews even if they have not called setState

Fixes microsoft#50752

* Change parameter name to match interface name

Fixes microsoft#50745

* Fix non-serializable webviews being revived if they called setState

* Include recommended extensions in telemetry events to determine success

* Fix microsoft#49777 - Emmet balance In after balance out should go back to initial selection and not first child (microsoft#49996)

* Update Emmet - balance.ts

* Cover all cases

* Update prompt msg Fixes microsoft#50738

* Fix microsoft#50632

* search-rg has no icon

* EH search - replace search.enableSearchProviders with a search-rg specific setting

* fix microsoft#50742

* fix microsoft#50691

* part of microsoft#50760

* smoke: uncomment debug suite

* smoketest: use yarn

* grid - allow to close empty groups via middle click (microsoft#50733)

* careful with path comparisons on windows

related to microsoft#50760

* smoke: run yarn verbose

* fix microsoft#50710

* Improve description (microsoft#43208)

* fix microsoft#50722

* Fix microsoft#50663

* Fix microsoft#47586

* fixes microsoft#50609

* fixes microsoft#50026

* 💄

* fix  microsoft#50773

* improve perf of findId and getElementById, microsoft#50575

* don't show outline when there are more then 7500 symbols, microsoft#50575

* fix typos

* polish for microsoft#50667

* fix microsoft#50700

* grid keep sizing after branch node demotion

fixes microsoft#50564

* grid - for now remove editorGroup.activeEmptyBackground

* fix microsoft#50726

* grid: resize views when branch is demoted

fixes microsoft#50675

* fix microsoft#50727

* fix microsoft#50734

* remove preview rant from search.location

* splitview: dont propagate white-sapce property

fixes microsoft#50720

* fix microsoft#50774

* Fixes microsoft#50296

* fix  microsoft#50207

* Fixes microsoft#24670: Add API to determine if the task service supports parallel task execution.

* fix microsoft#50741

* Fixes  microsoft#49400: Cannot read property 'then' of undefined

* Fix microsoft#50717

* Fix microsoft#48901

* polish debug.toolBarLocation

fixes microsoft#50786

* Fix microsoft#50717

* missing compilation

* Fix microsoft#48225

* fix microsoft#50711

* Fix errors installing extension from Welcome page (fixes microsoft#50753)

* fixes microsoft#50794

* fixes microsoft#50787

* continuous build: use vsts npm feed

* Fix for microsoft#50792: empty pre post scripts not rendered properly

* Fix microsoft#50728

* continuous build: use vsts feed

* Fix for microsoft#50792 npm exclude doesn´t work for folder names

* Move previewOptions, microsoft#50788

* build: remove npm auth

* better fix for microsoft#50710

* Revert "Merge pull request microsoft#49790 from usernamehw/raw_settings"

This reverts commit f92a162, reversing
changes made to fc710af.

* Remove unused variable

* Fix regression in C# TextMate grammar related to lambda parameters

This tweak fixes a regression recently introduced in the C# TextMate grammar around
implicitly-typed lambda parameters.

* dotnet/csharp-tmLanguage#119
* dotnet/csharp-tmLanguage#120

* Fix parameter not being escaped

Fixes microsoft#49057

* wip: grid.getNeighborViews

* Make sure we use normalized path for compare

Fixes microsoft#50760

(the path should already have been normalized at this point so I don't think there is any user impact)

* Clean up importModuleSpecifier wording

Fixes microsoft#50817

* Remove duplicate strings and small cleanup

* Spelling fix Ouoting -> Quoting

* Restore default settings editor keybinding

* Dont trigger emmet for # in selectors Fixes microsoft#49269

* Hide settings editor feedback button in stable

* Use better colors for markdown code blocks

* Moving webview api back to proposed for more polishing

microsoft#49022

* Shorten showUnused setting name

Fixes microsoft#50648

* fix microsoft#50678

* Don't include imports in js/ts document symbol results

Fixes microsoft#50829

* smoketest: remove verbose from yarn

* smoketest: clear state from failing search tests

* minor rename

* Fix markdown preview not setting context properly on first creation

Fixes microsoft#50558

* smoketest: update to package-lock.json

fixes microsoft#50857

* smoketest: bring back search tests

* microsoft#48901 Expand by default only in custom viewlets

* fixes microsoft#50812

* open editors: clear focus when group without editors is active

fixes microsoft#50563

* Fix MaxNumber incrementFileName bug

* Fixes microsoft#48758: Do not import standalone editor modules

* fixes microsoft#50864

* Use `MAX_SAFE_SMALL_INTEGER`

* Fixes microsoft#50858: Task api is still marked as proposed

* fixes microsoft#50737

* fix microsoft#50867

* Fix: showQuickPick keeps showing infinite progress (fixes microsoft#50863)

* Clarify for translation (fixes microsoft#50634)

* fixes microsoft#50870

* fix microsoft#50479

* grid - todo@grid => todo@ben

* grid - adopt new getNeighborViews() method

* grid - add workbench.action.closeEditorsAndGroup

* open editors: close group action

fixes microsoft#50625

* open editors: use actionRunner for contexts

fixes microsoft#50621

* [css][html] update service

* grid: getNeighborViews

* grid - adopt wrapping

* Some menu action clients (ActionBar) handle alternative actions on their own so the alternative actions should be ignored

fixes microsoft#50581

* fillInActionBarActions and fillInContextMenuActions for clarity

* Remove inconsistent use of active in terminal API

Related microsoft#48434

* Try using fixAllDescription for js/ts quick fixes

Fixes microsoft#42549

* Fixes microsoft#50828, code-insiders --status triggered exception in main process

* Pick up ts 2.9.1 final

* Fix for microsoft#50868 and microsoft#50884

* Still gray out vars even if user has disabled suggestions

Fixes microsoft#50890

* grid: fix neighbor npe issue

* grid: more getNeighborViews tests

* grid: use boundaries for neighbor finding

* grid: getNeighborViews perf

* grid: add todo

* 2018-05-31. Merged in translations from Transifex.

* Update GDPR annotation

* update message

* Add specific `refactor.move` scope for js/ts move to new file action

* Use localized language name when available

* Add proper contribution schema for ts server pluguins

microsoft#50682

* Fix extra word

* Fix microsoft#50909 - add link to new settings editor from old one

* Left-align settings editor preview prompt

* grid - fix issues with touchbar updating

* grid - use viewColumnToEditorGroup in more places

* grid - close all groups should preserve first group

* Reapply fix for microsoft#50790

* grid - assign some default keybindings for focus group

* Fixes microsoft#50763: All running Visual Studio code instances shutdown all at once

* grid - 💄

* fixes microsoft#50926

* show alternative actions when alt is pressed, not only on mouse over

* open editors: click on groups should activate them

* update description (for microsoft#50677)

* Fix microsoft#50835

* grid - tweak some groups access order

* one more time, fix microsoft#50321

* beware of keybinding command null arguments

fixes microsoft#50821

* grid - prevent multiple confirmation dialogs for the same editor to show up (for  microsoft#50539)

* smoketest: go-to-definition is flaky

fixes microsoft#50944
fixes microsoft#49107

* Fixes microsoft#50943: TSC version 2.9.x in watch mode prints different end compile message

* grid - fix bad === for editors

* 💄 grid, cleanup getViews()

* Update distro commit and third party notices

* Use localizedLanguageName instead of languageNameLocalized which doesnt exist

* Remove now unneeded any

* Make sure unused diags are still updated when suggestions are disabled

Fixes microsoft#50890

* Fix unused var

* Update version

* Update issue templates, microsoft#49380

* Fix microsoft#50893 - escape regex chars when copy search string from editor

* Fix microsoft#50985 - don't take editor text when toggling search details
@vscodebot vscodebot bot locked and limited conversation to collaborators Jul 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
l10n-platform Localization platform issues (not wrong translations) on-testplan plan-item VS Code - planned item for upcoming
Projects
None yet
Development

No branches or pull requests

5 participants