The preferred way to retrieve localized string resources is through the LocalizationService API. To retrieve the currently configured and active EPiServer.Framework.Localization.LocalizationService, use the EPiServer.Framework.Localization.LocalizationService.Current static property or request it from the service locator using the EPiServer.ServiceLocation.ServiceLocator.Current property and GetInstance method.

Retrieving a localized string

To retrieve a localized string, call the GetString method with a key that represents the requested resource. The key normally starts with a forward slash (/) and can consist of several sections, each separated by a forward slash. Alternatively, the key can start with the hash character (#), indicating that the key should be prefixed with the current request path. For example, calling GetString with the #myKey key from the template located at /templates/page.aspx is equivalent to calling it with the key /templates/page/myKey.

Example:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
    <language name="English" id="en">
        <mystring>my string</mystring>
        <subnode>
            <myotherstrin>my other string</myotherstring>
        </subnode>
    </language>
</languages>

Getting the resource strings using the LocalizationService:

LocalizationService.Current.GetString("/mystring");
LocalizationService.Current.GetString("/subnode/myotherstring");

If you want the resource string for a specific language, provide the language in the form of a CultureInfo to the GetStringByCulture method. If no culture is given, the current UI culture is used. If a string is not found in the provided or implied language, the localization service traverses up the culture chain and looks for the resource in the neutral (if the given language is not neutral). Then, the invariant culture is tried.

Fallback values

If no resource matching the given key is found, and the key starts with one of the identifier characters described above (/ or #), GetString returns an empty string. Otherwise, the key itself is returned.

To change this behavior, modify the FallbackBehavior property, either through the API or the web.config. You can specify multiple fallback behaviors, but the order and logic will always be the same.

If the FallbackCulture flag is set, the LocalizationService tries to get the resource from a fallback culture for any missing resources. By default, the fallback culture is set to English (en), but you can set it explicitly using the FallbackCulture property in the API or the web.config. This behavior is activated by default.

The Echo flag represents the behavior of returning the key itself. If not set, keys are not returned. This behavior is activated by default.

If you add the MissingMessage flag, it returns an error message for missing resources, which can be convenient in a development environment.

Adding the Null flag (New in CMS 9.11) will change the default behavior and return null rather than an empty string for any missing resources, which can be useful if you want to use a custom fallback behavior for a specific case.

You also can provide a fallback string using one of the GetString method overloads. If the fallback requires more than just a simple string, use one of the TryGetString methods instead to get a clear response if the resource string was found or not.

Lists of localized strings

If you need all resource strings under a certain section, use the GetAllStrings method because (when providing the base key) it returns all strings under that base key for the culture chain in question, or all strings if the provided base key is empty. GetAllStrings returns a list of items that contain the localized string, key and the specific culture where the string was specified. Note that the order of the list is not guaranteed to be the same as it was specified.

Available languages

Languages available through the localization service are also available through the AvailableLocalizations property, which only indicates that localized strings exist in the returned cultures; not that the localization includes the whole system.

Localization providers

The default localization service implementation is the ProviderBasedLocalizationService. This class uses a provider system to retrieve localizations. By default a single provider, in addition to the system ones, is configured to look for XML string resource files in a folder under the web root named lang. By adding files to this location, you can add your own localizations or override system strings. Translations added to an XML file in the lang directory override system-defined resources.

Last updated: Sep 21, 2015