Try our conversational search powered by Generative AI!

Loading...
Area: Optimizely CMS
Applies to versions: 12 and higher
Other versions:
ARCHIVED This content is retired and no longer maintained. See the version selector for other versions of this topic.

Localizing the user interface

Recommended reading 
Note: This documentation is for the preview version of the upcoming release of CMS 12/Commerce 14/Search & Navigation 14. Features included here might not be complete, and might be changed before becoming available in the public release. This documentation is provided for evaluation purposes only.

This topic describes how the localization of the user interface works in Optimizely CMS. The default localization service uses a provider system to retrieve translated resource files from a predefined location in the project folders.

In this topic

How it works

The provider is configured to look for XML string resource files in a folder under the content 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.

The default is that the user interface is localized according to the editor’s Language Settings > Personal Language. However, if you want something more sophisticated, you can create your own localization provider and add some more conditions there. To do this, you have to inherit from LocalizationProvider and register it as described in Configuring a custom localization provider.

Setup

Custom localization providers are registered using LocalizationOptions. You can use extension methods AddLocalizationProvider and AddEmbeddedLocalization to IServiceCollection to register custom localization providers. The following example adds an embedded localization provider for the assembly containing the Startup class:

services.AddEmbeddedLocalization<Startup>();

When you add the provider, you can add one or more language files in XML format to that location (or as embedded resources if EmbeddedXmlLocalizationProvider is used), such as ContentTypeNames.xml.

You can give the language file any name and you can have each language in a separate file (or all in one file). In the language file, however, you need a certain structure, as follows.

One language:

<?xml version="1.0" encoding="utf-8"?>
  <languages>
    <language name="English" id="en">
    </language>
  </languages>

Two languages:

<?xml version="1.0" encoding="utf-8"?>
  <languages>
    <language name="English" id="en">
      ...
    </language>
    <language name="Swedish" id="sv">
      ...
    </language>
  </languages>

Adding localized text

You can localize the text shown in the user interface for your content types by adding localized texts in a convention-based format. The following code example shows how to add localized texts for the StandardPage content type, such as the attribute name and description or properties for the standard page like MainContentArea.

[ContentType(Description = "This text can you have in XML instead")]

public class StandardPage : PageData
  {
    [Display(
              GroupName = SystemTabNames.Content,
              Name = "This text can you have in XML instead",
              Description = "This text can you have in XML instead" 
            )]
       public virtual ContentArea MainContentArea { get; set; }	
  }

If you have a StandardPage content type with the attributes and properties as in the example above, the structure in the language file would be as follows:

<language name="en">
  <contenttypes>
    <standardpage>
      <description>A description of the page type</description>
      <properties>
        <maincontentarea>
          <caption>Name text from XML</caption>
          <help>Description text from XML</help>
        </maincontentarea >
      </properties>
    </standardpage>
  </contenttypes>
</language>

Reusing localization for properties between content types

It is also possible to add common translations to an inherited type, for instance pagedata or icontentdata.

public class StandardPage : PageData
  {
    public virtual string Name { get; set; }	
  }
<language id="en" name="English">
  <contenttypes>
    <pagedata>
      <properties>
        <name>
          <caption>Name text from language file</caption>
        </name>
      </properties>
    </pagedata>
  </contenttypes>
</language>
<language id="en" name="English">
  <contenttypes>
    <icontentdata>
      <properties>
        <disableindexing>
          <caption>Disable indexing</caption>
          <help>Prevents the page from being indexed by search engines</help>
        </disableindexing>
      </properties>
    </icontentdata>
  </contenttypes>
</language>

Note: If you have your own base classes that are not registered as content types, and you want to add translations to these classes, you must create a UIDescriptor for the base class.

Localizing headers

You can localize headers, such as tabs that are used to group properties, in the top-level section groups.

public class StandardPage : PageData
  {
    [Display(GroupName = SystemTabNames.Content,)]
    public virtual ContentArea MainContentArea { get; set; }	
  }

public static class SystemTabNames
  {
    public const string Content = "Information";
  }

Group name on the property MainContentArea is referred to SystemTabNames.Content and, as shown in the previous example, SystemTabNames.Content is referring to "Information".

The correct way here is to add <groups> and then the property name.

<language name="en">
  <groups>
    <information>Group name from XML file</information>
  </groups>
</language>
Do you find this information helpful? Please log in to provide feedback.

Last updated: Jul 02, 2021

Recommended reading