Internationalization in .net core

Question

I am currently in the process of developing an ASP.NET Core application which requires internationalization to Russian.

I have been reading over the documentation that Microsoft provide for .NET Core internationalization, which requires wrapping your strings in the IHtmlLocalizer and IViewLocalizer interfaces.

My biggest question is why? Static resource files seem to work and allow for internationalization as they did in the .net framework, so what advantage is there to using the .net core interfaces?

The .net core interfaces seem very dangerous to me. If I internationalize a string, for example "foil", the meaning of that English word changes depending on context and the translated word is almost certainly different based on context ("wrapped in foil" vs "acted as a foil"). Not only that, but if a change to a string creeps into the code (for example - "it's" becoming "its" due to a grammar correction), the translated string will go "missing".

Using the new .NET Core internationalization, one would internationalize "foil" by using Localizer["foil"]. Using the old static resources method, you would define "foil" as a resource and then use Resources.Foil in code. This lets you separate different meanings by the use of different resource keys. I could use Resources.WrappingFoil and Resources.ActingFoil to differentiate the two words. These could then be internationalized separately.

So why would anyone use the new interfaces instead of simply directly using the resource strings in their code? All of the potential problems disappear with static resource files.

• Robert Harvey: If I internationalize a string, for example "foil", the meaning of that English word changes depending on context and the translated word is almost certainly different based on context ("wrapped in foil" vs "acted as a foil"). -- No internationalization schemes are smart enough to address this sort of context. How do static resource files solve this problem?
• Robert Harvey: If you're going to dismiss Microsoft's scheme out of hand, at least have the courtesy to provide some specific examples that can be refuted.
• Stephen: @RobertHarvey The .net framework internationalization you would use Resources.Foil and Resources.ActingFoil for the two strings, which could then be translated differently. What I'm after is any specific advantages to Microsoft's new way of doing things.

Answer 1

I have zero experience with .Net Core, but I am working at an application where we have wrapped localizable strings by using their English pendants as a reference index. This is quite comparable to the technique described in the question.

The idea here is to avoid usage of Localizer["foil"], but instead using larger phrases like Localizer["wrapped in foil"] to provide enough context. Note this is only required in case the same piece of text appears in more than one place in different meanings (which are, at least in our case, surprisingly few cases).

We also have some automated tests to check if all localizable strings have a proper translation. If someone makes a grammar correction and forgets to modify the translation file, the test reveals it.

For us, this worked quite well (currently, there are about ~1000 phrases to translate), but YMWV.

• Stephen: Have you ever internationalized a .net framework application?
• Doc Brown: @Stephen: the application I mentioned is a .NET framework application.
• Stephen: Why did you choose that method over the standard static resources method?
• Doc Brown: @Stephen: a bunch of reasons, and I think I had to go way too deep into the details of that applications, more than I am willing to disclose here. I can say it was the way which fitted best to our overall requirements, giving us high flexibility for the smallest possible development effort. It allowed us to localize huge parts of the unlocalized application without replacing any existing strings by those resource constants.