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.

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.