Is there a built-in typesafe way of localizing a .NET (Core) application?

Question

I've been working in .NET (Framework and Core) for years now, and I'm looking to port a .NET Framework application over to .NET Core.

In this .NET Framework application, we have .resx files with thousands of labels in it, translated in 5 languages. These .resx files have generated C# source code which allows us to statically access them in a type-safe way. The current UI culture is respected when doing so.

When I lookup the documentation for localization in .NET Core ( found here ), the rules of the game have massively changed:

• You need to inject ILocalizer, IHtmlLocalizer or IViewLocalizer
• Resource files are searched based on where and how you inject these localizers
• Labels are retrieved using magic strings

Am I the only who thinks this is massively and needlessly more complex than what we had in .NET Framework? I can understand where ILocalizer and friends came from, because everything needs to go through dependency injection now. But magic strings? Resx files all over the place?

To be honest, I'm constantly impressed with the underlying machinery of .NET Core, but the localization aspect has left me thoroughly underwhelmed. Is there anyone out there with a solid, productive solution to this issue? Having type-safe labels is probably my #1 requirement.

Thanks in advance!

Edit: this is the bounty message with better formatting:

I am looking for a solution to localization in C# that

• provides the option to have a single resx file per application (or at the very least, NOT a resx file per controller/view/...)
• provides compile time safety so my application cannot crash/misbehave at runtime because of a typo in one of the resource keys
• has a minimal feedback loop when adding a new label (e.g. add a label to a .resx file, this immediately updates the generated C# code, and now the label is immediately usable in my other C# code without having to build the whole application first)
• is not a hacky workaround

If the only solution to these requirements is the existing .resx workflow, then I would also accept an authoritative answer that draws from official documentation or a statement from a figure with authority inside Microsoft that explicitly mentions resource files with generated C# code as an acceptable, supported alternative to the ILocalizer story.

Answer 1

You can continue using the old style of creating multi-language applications with .NET Core by having multiple 'resx' files although the preferred way of managing multi-lang resources is by using those interfaces that you mentioned. But I couldn't find a document that mentions that the 'resx' files will be obsolete in the future.

I have created a sample .Net Core web api that uses two separate resource files for providing its strings. it uses a parameter for determining its Thread.CurrentThread.CurrentUICulture by this code:

    [HttpGet]
    public ActionResult<string> Get(string lang)
    {
        Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo(lang);
        return Resource.Test;
    }

as you can see in these pictures, I get two different output based on my preferred language.

for 'en':

for 'fa':