Getting only needed resources on nuget install

[MehdiK]

@hmemcpy raised a valid concern:

how can I prevent from copying all the language-specific resource to the output dir with Humanizer? Don't want 'em :)

NuGet supports two localization approach: single & satellite localized packages. Humanizer currently uses single localized package & I don't think it's possible to achieve this in this mode.

I think it's a good idea to switch to satellite packages even though it's a breaking change for this and other benefits.

To Do:

• Create a nupsec for each locale, currently 39
• Create script to update versions correctly on resource packages
• Create script to push all packages to NuGet from the MyGet feed

[DanAtkinson]

Is this related to the large number of potentially unnecessary resource.dll files being added by Humanizer? It's made my bin directory a bit of a mess and clients are asking why so many separate DLLs are needed?
http://i.imgur.com/La7CZwN.png

[MehdiK]

Correct. This is going to be a breaking change to implement; so we're leaving it for V2. In the meantime, the only way to get a clean output folder is to delete the resources after build.

[jeremysimmons]

For what it's worth, I'd like to see the languages separated as separate localization packages too.
Does anyone have a workaround in the meantime?

[jeremysimmons]

A workaround for this issue is to add the following to your pre-build event.

<PreBuildEvent>forfiles /P &quot;$(SolutionDir)packages\Humanizer.1.36.0\lib\portable-win+net40+sl50+wp8+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10&quot; /c &quot;cmd /c if @isdir==TRUE rmdir /s/q @file&quot; &amp;&amp; EXIT /B 0</PreBuildEvent>

The encoded characters are correct. Double Quote and Ampersand have to be XML Escaped inside of the

[clairernovotny]

Question for everyone asking to split this out -- what's really driving this? I just checked and the localization files are about 325 KB...overall, not huge.

The benefit of the current approach is that "it just works" for all downstream consumers. If you create a library that uses Humanizer, which language dependencies would you choose? Do you force that choice on your consumers who might not know that there are localization packages available?

I guess I'm partially trying to understand what the concern or care is about, what's driving it?

[jeremysimmons]

We're a corporate software shop. We cater to US clients that speak ubiquitiusly english. My build engineers freak out whenever a new DLL shows up in the BIN directory for the asp.net app, much less 38 new folders. These folders aren't needed, at all for our scenario which caters exclusively to english, which is already the assembly neutral language. [assembly: NeutralResourcesLanguage("en")]

While you're right, the overall size of files is 325 KB, the number of extra files/folders is excessive.
When we want a utility library like this we want one file.

[clairernovotny]

Okay, so I'm thinking that the NuGet localization strategy would work. MyGet may have support for this already too.

I don't think it'll make the cut for 2.0 beta 1 but hopefully should be fairly soon after.

[clairernovotny]

So here's a question re the structure. I was going to have a "meta-package" that includes all of the locales for convenience. This would be essentially v1 behavior.

The question is which should be the "default"? I.e., should the Humanizer be slimmed down to not pull in the locales by default? This is a change from v1.

The alternative is that Humanizer becomes the meta-package that pulls in everything, retaining its v1 behavior. The main contents of Humanizer goes into a new package called Humanizer.Core making the locale packages Humanizer.Core.<locale>. For people that just want English, you'd just pull in Humanizer.Core. For people that want a specific lang, you'd pull the right core locale, like Humanizer.Core.ar and it'll pull in Humanizer.Core for you.

Thoughts? FWIW, I'm leaning towards the non-breaking change, making Humanizer a meta package and moving the implementation into the Humanizer.Core package.

[mexx]

Non-breaking change sounds good. GFI

[jeremysimmons]

Is there a non Core sub-library of humanizer? Why add the name core?
I'd suggestion retaining Humanizer and adding a new package Humanizer.Localized

Another option would be to add a targets file to the distribution that would support keeping the satellite resource directories you want to include, and deleting the ones you dont.

That would allow you to always have a single package, and allow users to customize which localiztion packages they want...

[clairernovotny]

So NuGet has very specific naming conventions for doing "the right thing" with packages containing just satellite assemblies. They have to be in the form <package>.<locale>. What that means is that there will be 39 locale packages for Humanizer as there are a lot of supported languages. If we're going to split out languages, then it stands that some people may only want some languages and not all. You can pick-and-choose which languages you want.

That said, if you want them all, you can also take the main package which is a meta-package now. The idea of a meta-package is that it contains no files itself but just pulls in other packages.

In this way, we can have the following split (and the naming is just for the packages, nothing has changed in the library itself):

Humanizer: Meta-package that pulls in all 39 language packages (like Humanizer.Core.ar). Each language package pulls in Humanizer.Core as is required by the NuGet conventions. Note, that there won't be 39 copies of humanizer, it all gets normalized. This package is the "give me everything" package and is essentially the current behavior of today's package. You get the package, you get all locales.

Humanizer.Core: Just the humanizer library, symbols and help xml file. This implicitly contains the neutral language (English). If you don't want any other languages, just install this one.

Humanizer.Core.<lang>: The localized resource packages. If you want to choose which languages you need, you can install these directly. Good if you want say German and French. Each of these will pull in the Humanizer.Core package for the implementation and add the chosen language resources.

Make sense?

[jeremysimmons]

@onovotny thank you for the fantastic explanation. I agree that this sounds like a viable solution and meets my needs.

Where did you read about this convention? http://docs.nuget.org/create/creating-localized-packages doesn't describe what you just specified.

[clairernovotny]

@jeremysimmons: it's in that link under the "Satellite Package Approach". For the purposes of the convention, Humanizer.Core would be the package name. Humanizer turns into a "convenience" package that pulls the others in.

[jeremysimmons]

@onovotny Unless I am missing it, Satellite Package Approach doesn't specify the naming convention that includes the RootPackage.Core and RootPackage naming contention

[clairernovotny]

No, you're correct. That RootPackage has nothing to do with localization. That's an extra for convenience. Another way to look at it is that what is today the Humanizer package is being renamed to Humanizer.Core and adding a new Humanizer package in its place. That new package also helps preserve compatibility by preserving existing behavior for people that use the package today.

[jeremysimmons]

@onovotny the naming convention was the only point I was questioning, and simply from a learning perspective to understand where the community had documented that convention. Are there other packages that use this convention that you're aware of?

[clairernovotny]

I'm honestly not sure. It's hard to search for meta packages to see how they're named. I can say that Rx uses Rx-Main, for example, to pull in five other packages. Microsoft.OData.Core exists and pulls In a couple others. Micrososoft.OData.Client pulls in Core and adds to it.

My hope was that by keeping the main Humanizer "as-is", that it'd minimize disruption. These docs definitely need updating to describe the packages before release.

[clairernovotny]

Update 1 for VS 2015 contains the fixes for UWP support for the localized packages. This has been merged and pushed to the CI MyGet feed:

https://www.myget.org/F/humanizer/api/v2
https://www.myget.org/F/humanizer/api/v3/index.json

The Humanizer 2.0.0-dev0057 package retains current behavior (pulling in all locale packages). If you just want English, use Humanizer.Core 2.0.0-dev0057 instead. If you want one or more languages, use those directly: Humanizer.Core.he 2.0.0-dev0057, etc.

The main Humanizer package does pull in a lot of packages into packages.config. If this is a concern, I'd recommend changing over to the project.json format instead. That can be used instead of packages.config for all project types in VS 2015+. The main advantage is that only direct dependencies are listed and transitive dependencies are silently pulled in. It's far easier.

[clairernovotny]

Closing this thread out but please open new issue threads if you discover issues when testing the new packages. Thanks!

[jeremysimmons]

hard to contain the joy. THANK YOU!

[i3arnon]

@onovotny Are the individual Humanizer.Core packages going to be published on nuget.org? Or is there some other way I'm missing to get them?

[jeremysimmons]

@i3arnon I imagine they will publish to Nuget when it's a stable package. Currently they are pre-release. Add the myget.org feed to your nuget feeds, and then you should be able to search for the package. This documentation on the official nuget package manager extension for visual studio may help you https://docs.nuget.org/create/hosting-your-own-nuget-feeds#creating-remote-feeds

[MonsterMMORPG]

i have installed all packages but how do i specify which language to use?
like "araba".Pluralize();

[adelzorrolight]

how can I use arabic language in Humanizer

[iamnikv]

how can I use arabic language in Humanizer

I guess this answers the question: #1002 (comment)

[Issung]

I was experiencing this issue, the problem was that I was calling .Humanize() on a collection of items that were not strings as I suspected, to be specific it was a collection of Octokit.Branch objects. Once I used LINQ to select the names of the branches it worked just fine. The exception was somewhat of a red herring (this is all using Humanizer.Core).