Skip to content
This repository was archived by the owner on Nov 29, 2018. It is now read-only.

Reconsider resource naming rules #343

Closed
ryanbrandenburg opened this issue Mar 15, 2017 · 5 comments
Closed

Reconsider resource naming rules #343

ryanbrandenburg opened this issue Mar 15, 2017 · 5 comments
Assignees

Comments

@ryanbrandenburg
Copy link
Contributor

ryanbrandenburg commented Mar 15, 2017

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).
@hishamco
Copy link
Contributor

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 👍

@ryanbrandenburg
Copy link
Contributor Author

ryanbrandenburg commented Apr 5, 2017

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

@hishamco
Copy link
Contributor

hishamco commented Apr 6, 2017

👍 Sound looks good

@hishamco
Copy link
Contributor

hishamco commented Apr 6, 2017

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

@aspnet-hello
Copy link

This issue was moved to dotnet/aspnetcore#2644

@aspnet aspnet locked and limited conversation to collaborators Jan 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants