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

[ryanbrandenburg]

@pranavkm what do you think? Is it sufficient to add a property to LocalizationString or do we need to plumb logging stuff through?

[pranavkm]

We've had instances in other areas of the stack where we've tried to use logging to present diagnostic information to the user. It's nice because you don't have to be live debugging the application to see the failure (as long as the log message was captured, you could inspect it). The issue with using logging to present details like this has been that it's not entirely obvious that the log is the place to look for when something goes wrong.

Plumbing ILogger thru the ResourceManagerStringLocalizer doesn't seem particularly extensive since the factory comes from DI., We should consider using a logger if there's useful data to log. Doing this in addition to adding metadata to LocalizedString would be really nice.

[hishamco]

I'm still wonder why we need to add a new property to LocalizedString while we already know where we are looking for the resources via ResourcesPath.
May be we can add a readonly property that uses both ResourcesPath and the CurrentCulture to list all possible locations, but still I don't think that LocalizedString is appropriate in this case