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.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.