- BLOB storage and providers
- Client resources
- Configuring episerver
- Configuring episerver.dataStore
- Configuring episerver.framework
- Configuring episerver.packaging
- Configuring episerver.search
- Configuring episerver.shell
- Configuring module.config
- Configuring staticFile
- Configuring episerver.basicAuthentication
- Configuring .NET SignalR
- Configuring Image Service
- Configuring link validation
- Reading application settings programmatically
- Page types and templates
- Block types and templates
- IContentRepository and DataFactory
- Persisting IContent instances
- ContentType attribute
- Grouping content types and properties
- EditHint in MVC
- Creating a page programmatically
- Selecting content
- Converting page types for pages
- Refactoring content type classes
- Multilingual content
- Assets and media
- Planning deployments
- Installing database schema
- Setting up multiple sites
- Content Delivery Network (CDN) Configuration
- Configuring your email server
- Automatic schema updates
- Storing UTC date and time in the database
- Database mode
- Deployment scenarios
- Dynamic content
- Dynamic data store
- Event management
- Scheduled jobs
- Search integration
- Searching and filtering
- Installing and deploying Search Service
- About Episerver full-text search client
- About Episerver full-text search service
- Configuring Episerver full-text search client
- Configuring Episerver full-text search service
- Searching for pages based on page type
- Adding search providers
- Authentication and authorization
- Virtual roles
- Configuring Active Directory membership provider
- Recommendations for ASP.NET security settings
- Securing edit and admin user interfaces
- Federated security
- Forms authentication
- OWIN authentication
- Configuring mixed-mode OWIN authentication
- Permissions to functions
- Protecting users from session hijacking
- Managing cookies on the website
- EPiServer AspNetIdentity
- Integrate Azure AD using OpenID Connect
- User interface
- Context-sensitive components
- Service locator
- Describing content in the UI
- Shell profile
- Store architecture
- Message service pool
- Publish and subscribe messaging system
- Introduction to Dojo
- Using jQuery
- Plugging in a gadget
- Creating a component
- Extending the navigation
- WebSocket support
- Dashboard gadgets
- Command Pattern
- Object editing
- User notifications
- Virtual path providers
This content is archived. See latest version here.
Last updated: Sep 21 2015
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.
<?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:
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 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.
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.