IViewLocalizer not working when used from a external assembly with a resource file

[cwishva]

Functional impact

There is no way to load localization culture for views with a resource file in a external assembly or part mvc application (MVC Module)

Minimal repro steps

Use a MVC part application and try to localize the view in the part application to load from a resource file

1. Create a Default MVC app
2. configure Localization
3. Add a new Class library
4. Register the new Class library assembly to Mvc AddApplicationPart
5. Register the new Class library assembly to Mvc AddRazorOptions as a FileProvider
6. Create a sample controller in the Class library
7. Create a Resource file under Resource folder in Class library
8. Check if the sample controller loads with the Resource file values

Using the Demo app

1. Cone the Repo and run
2. Home page will show Home > Index , the main application gets localized with both IStringLocalizer and IViewLocalizer (string will contain (Localized to en-US))
3. Click the menu item "External assembly" to load the ExternalResource > index , the MVC part application will show only IStringLocalizer getting localized.
4. Rename the "working-Index.en-US.cshtml" to "Index.en-US.cshtml" and run the 3rd step then the localized view works.

Sample Demo Git Repo

Expected result

The view should load with the en-US culture values from the Resource folder

Actual result

View loads with default values

Further technical details

1. The (IStringLocalizer) Controller resources loads without any issue in the external assembly.
2. View loads with the Resource file in the Main application but not the External assembly
3. The view loads when it is under the Views folder (Index.en-US.cshtml) in the external assembly.

FYI : not sure if im doing something wrong i think it must be a bug. Thanks in advance

[ryanbrandenburg]

@chanaka1 we feel this is a problem of abstraction that's not really solvable in general. Your ViewLocalizer will look for resx files, but maybe that library has po files instead. In your specific case you can make that assumption because you're the author of both, but in general it's making assumptions about implementations outside the current project.

We think the correct way to go about this would be to get a IStringLocalizer from some method internal to the library hosting the views, so:
@ExternalLibrary.GetLocalizer(viewPath) instead of @inject Microsoft.AspNetCore.Mvc.Localization.IViewLocalizer Localizer. If it's very important to you that this come from the IViewLocalizer for some reason you'll have to write your own implementation.

[cwishva]

@ryanbrandenburg

I went trough the current implementation of ViewLocalizer

The problem is that, to generate the path it is using the hostingEnvironment.ApplicationName. where if the view is loaded from a different assembly the generated path is wrong for the _localizerFactory

_localizer = _localizerFactory.Create(BuildBaseName(path), _applicationName);

I have my own IViewLocalizer implementation getting the current assembly name from ControllerActionDescriptor

var controllerActionDescriptor = viewContext.ActionDescriptor as ControllerActionDescriptor;
if (controllerActionDescriptor != null)
  {
     var currentApplicationName = controllerActionDescriptor.ControllerTypeInfo.Assembly.FullName.Split(',').First();                
     _applicationName = currentApplicationName;
  }

Is there a better way that this can be implemented ?

[ryanbrandenburg]

If you mean is there a better way to get the AssemblyName off the ControllerType you could do something like new AssemblyName(contorllerTypeInfo.Assembly.FullName).Name rather than parsing that string yourself. If you mean is there a better way than getting the assembly off the controllerActionDescriptor that heavily depends on the constrains of your program.

[Jenan]

@chanaka1 Can you share working sample, please? I've tried download your sample repo, but IViewLocalizer still not working. I think that will be very useful.