-
Notifications
You must be signed in to change notification settings - Fork 65
Must use Type.FullName
for resource files found using default IStringLocalizer<T>
#296
Comments
In order to fix this without adding new information storage a la |
@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 We also decided to try a variation on it, exchanging a long filename for a deeper path, so instead of:
we went with:
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:
and their resources are at:
HTH EDIT Actually I just noticed from your screenshot that resources for _Layout view were listed as well without |
This issue was moved to dotnet/aspnetcore#2647 |
Behind our default

IStringLocalizer<T>
,ResourceManagerStringLocalizerFactory
removes a prefix matchingIHostingEnvironment.ApplicationName
orAssemblyName.Name
(in some cases) fromT
'sFullName
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 useT
's entireFullName
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 aType
.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.)
The text was updated successfully, but these errors were encountered: