-
Notifications
You must be signed in to change notification settings - Fork 65
Reconsider resource naming rules #343
Comments
I'm agree with the 2nd point, regarding the first one why we don't create an option to throw or use the default resource if the value is not there, if that's you point i'm totally agree and this will be a big plus 👍 |
@DamianEdwards, @Eilon and I talked about this and we think the thing to do (in addition to some docs fixes which I've already made) is to add an option to throw if the resource isn't found with a detailed error message about where the resource was being looked for. We could then update the docs to advise that anyone having trouble finding their resource should set that option temporarily so they can debug and look at the name being looked for vs name of their resource. @DamianEdwards would like to get this for 2.0.0 since it would be new API surface. |
👍 Sound looks good |
FYI this is already suggested by @DamianEdwards long time back, you can checkthe issue #13 |
This issue was moved to dotnet/aspnetcore#2644 |
Uh oh!
There was an error while loading. Please reload this page.
Right now if your full class name starts with the name of the assembly it will be trimmed. So for a project with assembly
Project.Name.dll
the classProject.Name.Startup
would have the resourceStartup.resx
.This seems to cause a lot of confusion and trouble (#318, #314 and many more). Previously the documentation in this area was incorrect, which likely lead to a lot of this confusion, but problems still persist and this is the most common type of issues filed on Localization.
We've already added
SearchedLocation
toLocalizerString
to help with this, but people still seem to be having trouble so here are some of the options I've come up with.ResourceManagerStringLocalizer
which will throw an exception (with a detailed error message about where it looked) when a resource isn't found instead of returning the key as a result. The idea here is that it makes it clearer when a resource isn't found rather than "hiding" that behind "the key as default".Project.Name.Startup
would always beProject.Name.Startup.resx
no matter what the AssemblyName is. We could roll this out slowly by allowing fallback to the "trimmed" name for some time (or forever). The idea here is to reduce the complexity of figuring out what to name resource to the simplest possible thing, even if it means having longer resource names (or more deeply nested resource folders).The text was updated successfully, but these errors were encountered: