Reconsider resource naming rules

[aspnet-hello]

From @ryanbrandenburg on Wednesday, March 15, 2017 11:19:44 AM

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 class Project.Name.Startup would have the resource Startup.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 to LocalizerString to help with this, but people still seem to be having trouble so here are some of the options I've come up with.

1. Create a "mode" on 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".
2. Don't do any trimming of class names. So the resource for Project.Name.Startup would always be Project.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).

Copied from original issue: aspnet/Localization#343

[aspnet-hello]

From @hishamco on Wednesday, March 15, 2017 11:36:31 AM

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 👍

[aspnet-hello]

From @ryanbrandenburg on Wednesday, April 5, 2017 2:41:34 PM

@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.

[aspnet-hello]

From @hishamco on Wednesday, April 5, 2017 6:57:38 PM

👍 Sound looks good

[aspnet-hello]

From @hishamco on Wednesday, April 5, 2017 7:02:35 PM

FYI this is already suggested by @DamianEdwards long time back, you can checkthe issue #13

[mkArtakMSFT]

We have no capacity to handle this.

[hishamco]

I think this already mentioned in the docs, also I will mention it in the troubleshooting article that I am writing..