feature request: better localization or a way to plugin IStringLocalizer without external di

[joeaudette]

great work on this library!

I understand the localization was based on the MS SiteMapProvider system used in WebForms, but hope you are open to taking it beyond that.

My specific need is to be able to pull resource strings from a separate class library project that has the public compiled resx files. The current implementation is limited to resx files in App_GlobalResources.

I found examples of plugging in custom IStringLocalizer to do what I want
https://github.com/NightOwl888/MvcSiteMapProvider_ExternalResources

but, it required using external di, which is pretty complicated and after a day of thrashing I could not get it to work in my scenario with ninject, owin startup with ninject webhost, doing manual integration of the code as configuration module based on the readme

so I'm hoping you might consider either improving the built in StringLocalizer.cs to be able to support a syntax for specifying the assembly class and key? maybe borrowing from the above example?

or if not, then a way to plugin a custom IStringLocalizer based on configuration, ideally done in a way such that you could pass in the mvcContextFactory to a custom implementation the same as it is passed into the current one.

the relevant code seems to be at line 81 in SiteMapNodeFactoryContainer.cs
private ILocalizationServiceFactory ResolveLocalizationServiceFactory()
{
return new LocalizationServiceFactory(
new ExplicitResourceKeyParser(),
new StringLocalizer(this.mvcContextFactory));
}

Thanks for your consideration of this request!

[NightOwl888]

Thanks for the feedback.

Actually, this is already a priority. There are 2 parts to this issue:

1. Formalizing the localization extension point.
2. Creating an alternative to requiring a DI container.

The first issue is not that complicated. My thought is to create an alternative implementation of IStringLocalizer that has a dependency that will be the new localization extension point, and would appreciate any feedback on exactly what input parameters it should have. I am considering getting rid of the "implicit localization" (or at least discouraging it), since the rules of that game are clearly violated when loading nodes dynamically.

The second issue is something that I started a few months ago, but have since been sidetracked on other things (I have to make a living, too). Basically, it involves creating a fluent configuration API to replace the whole "internal vs external DI" concept. My plan is to add it using a builder pattern in addition to the existing API, so the external DI that some people are currently using won't just fall apart, but people can migrate to the new API when they have the time to do so.

Essentially, this optional configuration API will sit in the composition root of the application, and you will be able to extend it by only specifying the piece that you want to extend, as done in DI friendly library.

// pseudo-code
configuration
    .AddSiteMap("MySiteMap")
    .WithLocalizationProvider(new MyLocalizationProvider(TheAssembly, "SomeResourceName"));

I am still working on the details, but the general idea is that you will be able to use either a DI container or the new keyword to inject your dependencies, and you will be able to specify only the dependency that you need to inject, all others will use the default. I am using DI Friendly Framework and DI Friendly Library as guides.

But with my current schedule, and a mostly-finished implementation of XML Sitemap taking priority, this is probably several months off from becoming a beta release.

In the meantime, I recommend using external DI to configure MvcSiteMapProvider. If there are any specific problems you are having with the DI setup, please post code to reproduce the issue. Or better yet, create a demo project and either post it where it can be downloaded or put it on GitHub, then open a new issue.

I recommend reading the book Dependency Injection in .NET, because it provides details about how to refactor to design patterns to make DI possible in a wide variety of applications.

But for now, I am closing this issue, because it is basically a duplicate of #344.