Localization can be done in two ways:

1. Through .resx resource files
2. Through Kentico Xperience Localization -> Resource Strings

Currently, Kentico Xperience only supports Resource Strings for internal localization (forms, widget dialogues, etc), but provided no support for .Net Core's IHtmlLocalizer, IStringLocalizer, or IViewLocalizer.

We created a package XperienceCommunity.Localizer which adds fallback support for the baked in localizers, that if they cannot localize a string, it will look to the Resource Strings in Kentico Xperience to resolve.

Data Annotation Attributes are also already set to use Resource Strings as a fall back.

The Baseline already has this enabled. It also has SharedResources.resx configured for shared resource localization, and an example of HomeViewComponent.resx (used here) as an example of a feature specific resource file.

Localization Hierarchy

Translations will operate as follows:

1. Matching key in a _____.lang-Region.resx (ex: SharedResources.es-MX.resx)
2. Matching key in a _____.lang.resx (ex: SharedResources.es.resx)
3. Matching key in a _____.resx (ex: SharedResources.resx)
4. Matching Resource String for the specific lang-Region
5. Matching Resource String for the site's default language
6. Parse with ResHelper.LocalizeString(key) which will handle strings with localization keys nested (ex: "Hello {$ generic.world $}")

Resource Strings are cached per requested culture on a whole, so for each culture it will make 1 database call getting all the keys + values (defaulting to the default site culture if not defined).