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

Getting only needed resources on nuget install #59

Closed
MehdiK opened this Issue Jan 14, 2014 · 24 comments

Comments

Projects
None yet
8 participants
@MehdiK
Member

MehdiK commented Jan 14, 2014

@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

@MehdiK MehdiK added this to the V2 milestone Apr 19, 2014

@DanAtkinson

This comment has been minimized.

Show comment
Hide comment
@DanAtkinson

DanAtkinson Jun 17, 2014

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

DanAtkinson commented Jun 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MehdiK

MehdiK Jun 17, 2014

Member

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.

Member

MehdiK commented Jun 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Jul 2, 2015

Contributor

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?

Contributor

jeremysimmons commented Jul 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Jul 14, 2015

Contributor

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

Contributor

jeremysimmons commented Jul 14, 2015

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

@onovotny onovotny self-assigned this Oct 24, 2015

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 24, 2015

Member

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?

Member

onovotny commented Oct 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Oct 27, 2015

Contributor

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.

Contributor

jeremysimmons commented Oct 27, 2015

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 27, 2015

Member

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.

Member

onovotny commented Oct 27, 2015

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 29, 2015

Member

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.

Member

onovotny commented Oct 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mexx

mexx Oct 30, 2015

Collaborator

Non-breaking change sounds good. GFI

Collaborator

mexx commented Oct 30, 2015

Non-breaking change sounds good. GFI

@jeremysimmons

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Oct 30, 2015

Contributor

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...

Contributor

jeremysimmons commented Oct 30, 2015

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...

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 30, 2015

Member

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?

Member

onovotny commented Oct 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Oct 30, 2015

Contributor

@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.

Contributor

jeremysimmons commented Oct 30, 2015

@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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 30, 2015

Member

@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.

Member

onovotny commented Oct 30, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Oct 30, 2015

Contributor

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

Contributor

jeremysimmons commented Oct 30, 2015

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 30, 2015

Member

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.

Member

onovotny commented Oct 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Oct 30, 2015

Contributor

@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?

Contributor

jeremysimmons commented Oct 30, 2015

@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?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 30, 2015

Member

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.

Member

onovotny commented Oct 30, 2015

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Nov 30, 2015

Member

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.

Member

onovotny commented Nov 30, 2015

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Nov 30, 2015

Member

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

Member

onovotny commented Nov 30, 2015

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

@onovotny onovotny closed this Nov 30, 2015

@jeremysimmons

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Dec 1, 2015

Contributor

hard to contain the joy. THANK YOU!

Contributor

jeremysimmons commented Dec 1, 2015

hard to contain the joy. THANK YOU!

@i3arnon

This comment has been minimized.

Show comment
Hide comment
@i3arnon

i3arnon Dec 1, 2015

Contributor

@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?

Contributor

i3arnon commented Dec 1, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@jeremysimmons

jeremysimmons Dec 1, 2015

Contributor

@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

Contributor

jeremysimmons commented Dec 1, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@MonsterMMORPG

MonsterMMORPG Mar 3, 2017

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

MonsterMMORPG commented Mar 3, 2017

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

@adelzorrolight

This comment has been minimized.

Show comment
Hide comment
@adelzorrolight

adelzorrolight May 29, 2018

how can I use arabic language in Humanizer

adelzorrolight commented May 29, 2018

how can I use arabic language in Humanizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment