The preferred way to retrieve localized string resources in Optimizely, 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 add a constructor dependency to LocalizationService if your class is created by the service container.
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.
<?xml version="1.0" encoding="utf-8" standalone="yes"?> <languages> <language name="English" id="en"> <mystring>my string</mystring> <subnode> <myotherstring>my other string</myotherstring> </subnode> </language> </languages>
Getting the resource strings using the LocalizationService:
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.
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 configuring LocalizationOptions or the web.config. If the DefaultCulture is set, the LocalizationService tries to get the resource from a default 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 on LocalizationOptions or in the web.config.
If you add the MissingMessage flag, it returns an error message for missing resources, which can be convenient in a development environment. If the Echo flag is removed, the key is never returned.
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.
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.
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: Dec 18, 2017