Improve discover-ability and installation experience of satellite packages through the Nuget gallery

Topics: General
Jan 3, 2013 at 1:37 AM


Today Nuget supports creating satellite packages(

However it is fairly hard to discover and add these satellite packages to your project by going through the Manage Nuget packages or PM console


Let's say you have German(language code DE) VS and want to install german version of MVC so that as a developer you get the DE resources for MVC. Today you have to go to Manage Nuget Packages and search for "Microsoft.AspNet.MVC.ja" and install it which installs MVC libraries as well as DE resources

General Solution

A possible solution to improve this workflow is to have Nuget show satellite packages in the Manage Nuget packages windows based on the VS locale. Following are some ways where this experience could be made better

Implementation #1

In the above scenario the developer only searches for MVC and Nuget checks if there is a satellite package for MVC, itshows the satellite package in the result list before the english package. The benefit of doing this is that the package metadata and description will be in German since the satellite package has all the localized resources

Apart from showing the satellite package as the first link, in the description pane on the right, Nuget shows other satellite packages available for MVC as well. This is useful in cases where developers still have the option of installing a satellite package of any language that they want to

Implementation #2

In this scenario if you search for MVC, and you get select the english MVC package, since Nuget knows that the VS locale is german and the MVC package has a satellite package for german, it installs the satellite package as well

Implementation #3

There is filter in the Manage Nuget packages dialog where you can filter the packages by language. This option will only list packages which are applicable to that language

Jan 3, 2013 at 6:00 PM

I think some attention in this area is sorely needed. The user experience for installing localized versions of packages today (and having them upgrade seamlessly) is far from pleasant. I think all your implementation ideas have merit and some combination of them should be doable.

Jan 3, 2013 at 6:17 PM
Edited Jan 3, 2013 at 6:18 PM

I'm in Turkish locale and I would never use a Turkish version of a binary. This shouldn't be the default behavior and the dev needs to opt-in for that IMO.

Jan 3, 2013 at 7:33 PM

Interesting. Would you like your developer experience in VS to be in Turkish though? i.e. the Manage NuGet Packages dialog show package descriptions in your native language if possible?

Jan 3, 2013 at 9:09 PM


God, no. Not sure what other devs would think about it but I believe that the development environment should be all in English. My personal OS is also English and I even set my locale to US, too but at work, we sometimes don't have a chance to control these settings.

NuGet satellite package feature is nice but if those package will be added as default according to my locale, it would be bad as I might not want that.

Jan 3, 2013 at 9:43 PM

To clarify, this experience would be based on the language version of VS you have installed. So if you use US-English VS on US-English Windows, this wouldn't affect you at all. What we're trying to do is improve the experience for developers using non-English versions of VS.

Jan 4, 2013 at 8:47 AM

First of all, we shouldn't assume that the main package is in English. It can be any language.

I agree with @tugberk that we should never install satellite packages automatically. It should be an opt-in feature. I can think of many cases where people simply don't want to localize the app.

Jan 4, 2013 at 4:40 PM

Yep. I'm imagining some type of smart discovery feature in the NuGet client that could show you that other languages are available for a given package. If you install a package and it knows another language exists that matches the current VS language, it could prompt to ask whether to install that instead, perhaps with a checkbox that let's you disable the prompt (or auto-confirm it) from then on.