Must use Type.FullName for resource files found using default IStringLocalizer<T>

[aspnet-hello]

From @dougbu on Wednesday, October 19, 2016 7:46:53 PM

Behind our default IStringLocalizer<T>, ResourceManagerStringLocalizerFactory removes a prefix matching IHostingEnvironment.ApplicationName or AssemblyName.Name (in some cases) from T's FullName before a search of the containing assembly for requested resources. This does not help users who happen to have a different root namespace from the containing assembly / application name. They must use T's entire FullName e.g.

One important case occurs when Visual Studio creates a new project from a template and the user chooses a name that's invalid as a C# identifier. The "safe project name" used as the root namespace is created using a simple algorithm but will not match the application / assembly name.

While redoing the "safe project name" algorithm in our code may be an ugly hack, we could e.g. extend [ResourceLocation] to also specify the namespace prefix to remove when searching for resources in the containing assembly based on a Type.

---

Found while working with sample application at dougbu/Localized.1.1-preview. Screenshot above comes from VS with that solution open. (Took longer than it should for me to find the workaround.)

Copied from original issue: aspnet/Localization#296

[aspnet-hello]

From @ryanbrandenburg on Tuesday, October 25, 2016 2:33:45 PM

In order to fix this without adding new information storage a la [ResourceLocation] we would need to apply whatever transformation is used to turn the Project name into a legal C# namespace to baseNamespace here. If we did that we would successfully trim the namespace from the front of typeInfo.FullName and have the correct resource Prefix, but I understand that there's some trepidation about putting that info in here.

[aspnet-hello]

From @BrainCrumbz on Wednesday, January 4, 2017 2:34:00 PM

@dougbu we've just been bitten by this, or at least that's how it looks like.

We have ProjectName == DefaultNameSpace != ProjectFolder. When working with IStringLocalizer<> from a class (e.g. controller or other), we had to recreate the type FullName under ProjectFolder\Resources\, i.e. starting from the DefaultNameSpace. So we had a scenario like the one pictured in your screenshot.

We also decided to try a variation on it, exchanging a long filename for a deeper path, so instead of:

ProjectFolder\Resources\DefaultNameSpace.FeatureA.Whatever.Controllers.MyClass.fr.resx

we went with:

ProjectFolder\Resources\DefaultNameSpace\FeatureA\Whatever\Controllers\MyClass.fr.resx

which still works and it's easier on the eyes.

One strange (?) thing though: in the same project, resources for Razor views are localized just fine, in the way one would expect. So that we have views organized in custom locations like:

ProjectFolder\FeatureA\Whatever\MyView.cshtml

and their resources are at:

ProjectFolder\Resources\FeatureA\Whatever\MyView.fr.resx

HTH

EDIT Actually I just noticed from your screenshot that resources for _Layout view were listed as well without FullName, so this is known.

[mkArtakMSFT]

Thanks for contacting us. We're closing this issue as there was no community involvement here for quite a while now.