Consider surfacing additional diagnostics information as part of LocalizedString when a resource is not found.

[pranavkm]

It might make it easier to diagnose why a specific resource string isn't located. Perhaps as part of the debugger display?

[hishamco]

Is there any reason that resource is not found except the resource file doesn't exist or the resource entry is not found?

[pranavkm]

Probably one of the two. But it's still a guessing game where the instance of IStringLocalizer<T> is looking for a particular resource.

[hishamco]

We may log where the APIs is looking for resources, this very helpful, it would be nice if we can see something like what MVC did when it doesn't find the view

[BrainCrumbz]

@hishamco just because you asked for, we're not able to figure out what should be the correct naming/location of a resource file mapping a nested class within a static wrapper class.

Say we have a file at path xxxx\ProjectRoot\Feature\Outer.cs, defining:

namespace ProjectRoot.Feature
{
  public static class Outer
  {
    // ...

    public class Inner
    {
      public Inner(IStringLocalizer<Inner> localizer)
      {
        // ...
      }
    }

  }
}

We tried the following resource files, all withouth luck. Resources top directory has been setup during startup (and it works with other simple cases).

1. xxxx\ProjectRoot\Resources\Feature\Outer\Inner.it.resx
2. xxxx\ProjectRoot\Resources\Feature\Outer.Inner.it.resx
3. xxxx\ProjectRoot\Resources\Feature\Outer+Inner.it.resx

What's the correct way to accomplish this?
If I should create a brand new issue about this, please just tell me. Thanks

[BrainCrumbz]

Ok. Apparently we've been bitten by #296 .

Nonetheless, I was not able to find any specific info on nested classes related to resource location & naming. It might be worth considering adding something about it to the docs.

EDIT BTW, correct solution was the last: xxxx\ProjectRoot\Resources\Feature\Outer+Inner.it.resx

[ryanbrandenburg]

It appears that nothing in Localization is using DiagnosticSource, so writing out debug logging might be a large and potentially unwanted change, but we could very easily add a "LocationSearched" property to LocationString which users could examine.

[hishamco]

Even the localization doesn't using DiagnosticSource at least we need to use a logging APIs, that let the user know what's going on. So in that case we don't need a new to add a new property because we know the searched locations