Append ApplicationName and RelativePath doesn't make sense for types from class library in ResourceManagerStringLocalizerFactory

[martinba1]

See:
https://github.com/aspnet/Localization/blob/dev/src/Microsoft.Extensions.Localization/ResourceManagerStringLocalizerFactory.cs#L72

It is useful to append _applicationEnvironment.ApplicationName, _resourcesRelativePath to baseName only for types from the main application assembly. It makes impossible to use this factory for resources shared in class library assemblies.

[Eilon]

If the type name being requested doesn't start with the app name then we shouldn't use any fancy prefix logic. This way the application's configuration for localization won't interfere with class libraries doing their own localization.

[joeaudette]

this is kind of a bad bug, only solution at the moment is to fork ResourceManagerStringLocalizerFactory and change the logic, wondering why this is backlog, thought it would be fixed in rc2 but backlog suggests it won't even be fixed in RTM

For example if I have a class library with a FooController like this:

    using Microsoft.AspNetCore.Mvc;
    using Microsoft.Extensions.Localization;
    namespace WebLib.Controllers
    {
        public class FooController : Controller
        {
            public FooController(
                IStringLocalizerFactory localizerFactory
                )
            {
                _localizer = localizerFactory.Create("MyResources.Controllers.FooController", "WebLib"); ;
            }

            private readonly IStringLocalizer _localizer;

            public IActionResult Index()
            {
                ViewData["Title"] = _localizer["Foo"];
                ViewData["Message"] = _localizer["Greetings ya'll"];

                return View();
            }
        }
    }

and in the project.json I embed the MyResources folder which contains Controllers.FooController.fr.resx

"buildOptions": {
    "embed": [ "Views/**", "MyResources/**" ]
},

It works if the main web app is configured like this:

services.AddLocalization();

but as soon as the web app decides to use this configuration:

services.AddLocalization(options => options.ResourcesPath = "Resources" );

It breaks the localization in FooController even though I'm using the factory and asking for exactly the correct name of my resource

[joeaudette]

and a further note, it is currently not possible in a class library to get a working IStringLocalizer like this:

    using Microsoft.AspNetCore.Mvc;
    using Microsoft.Extensions.Localization;

    namespace WebLib.Controllers
    {
        public class OtherController : Controller
        {
            public OtherController(
                IStringLocalizer<OtherController> localizer
                )
            {
                _localizer = localizer;
            }

            private readonly IStringLocalizer _localizer;

            public IActionResult Index()
            {
                ViewData["Title"] = _localizer["Otherwise"];
                ViewData["Message"] = _localizer["this is the other one"];

                return View();
            }
        }
   }

seems like with this approach there should at least be a convention where to put my resx files and how to name them so they work, but currently it just cannot work at all, so at the moment it is not possible to localize a controller that lives in a class library using IStringLocalizer, unless you fork the factory and change the logic

If it is not intended to work and we are supposed to do localization differently in a class library then it should be documented as such