+

Search Tips   |   Advanced Search

Multilingual - IBM Web Content Manager


Types of sites

Site Description
Base Site structure and shared content that will be translated. Some base sites are continually updated, and fresh translations are made. Other base sites are created once, and used as templates for new sites in other languages.
Translated In most cases, the entire content and structure of a base site are replicated to a translated site. In some cases, only a subset of the original base site is reused on the translated site.
Regional Similar to a translated site, but involves no translation. Reuse content from a base site. Content is updated for each region. For example, different states in a single country.
Translated Regional Reuse and update content from a base site. Translate the updated content.
No base-locale Content is written separately in different sites for different languages, but then synchronized and translated to all the sites and languages.
Mixed language Includes content written in multiple languages, but stored in a single site. Content is grouped by category, not language.

See: Overview of a multilingual site


Centralized deployment

All locales are served from the same environment and all localized content is syndicated. Web server mappings to each locale home page should be created, either as domains or as paths. These mappings provide easily remembered URLs for users to link to a localized version of the site.

For a single domain name, each path is mapped to the home page in a localized library, using URLs like...

For multiple domain names, each domain is mapped to the home page in a localized library, using URLs like...

Your localized navigation links should change the domain, not just the path, and should use a fully qualified path, not a relative path.


Decentralized deployment

In a decentralized deployment, locales are served from separate environments, one per environment, or potentially multiple locales per environment. Multiple domains must be used, where each locale or combination of locales is served from it's own domain.

When implementing a decentralized deployment, users either switch between localized content on an item by item basis, or users select the locale to use and are taken to the home page for that locale.

To support a decentralized environment, you need to have all content in all locales deployed to every locale environment. The navigation code can then check which content is available before rendering links, and the user can navigate to that localized version without losing their session.

If this is an anonymous site, we can redirect to the localized version of a site on another server. This requires fully qualified links to be generated.


Locale home page navigation

If the site only requires a link to go to the home page of each locale instead of item-by-item navigation, we can create links in the site that navigate to the other servers. The advantage of implementing the site this way is that you do not need to deploy all content to all servers. You only need the content for the locale you intend to serve out of that environment and any shared assets.

The links to the other localized domains need to be hard coded because these links cannot be automatically generated.


Install multilingual extensions

  1. Set WasPassword and PortalAdminPwd passwords in wkplc.properties

  2. Run...

      cd PROFILE_HOME/ConfigEngine
      ./ConfigEngine.sh register-wcm-mls
      ./ConfigEngine.sh deploy-wcm-mls
      ./ConfigEngine.sh import-wcm-mls-data -DVirtualPortalHostName=VirtualPortalHostName -DVirtualPortalContext=VirtualPortalContext

  3. Repeat these steps on every server and cluster node.

See also: Re-install MLS manually


Configure MLS

  1. Log into WebSphere Portal as an administrator.

  2. Create a new group for your locale owners:

      Administration > Access > Users and Groups

    Create a new group for your locale owners. For example: Locale Owners. The base locale owner must belong to this group.

  3. Modify the security of the MLConfiguration_v7 library:

      Administration > Portal Content > Web Content Libraries

    Assign the Locale Owners group to the Editor role on the library. Assign the Locale Owners group to the Contributor role on the library.

    To hide all sections in the authoring portlet, except the content and component views, disable inheritance for all item types except content and components.

    Assign the Administrators group to the Administrators role on the library and all item types.

  4. Run the Update Member Fixer tool
    cd wp_profile_root/ConfigEngine
    ./ConfigEngine.sh run-wcm-admin-task-member-fixer \
                      -DPortalAdminId=username \
                      -DPortalAdminPwd=password \
                      -DWasUserId=username \
                      -DWasPassword=password \
                      -Dlibrary=MLConfiguration_v7 \
                      -Dfix=true \
                      -DinvalidDn=update \
                      -DmismatchedId=update \
                      -DaltDn=update
    

  5. Go to the authoring portlet and update the Configuration settings to add the MLConfiguration_v7 library to the list of selected libraries.

  6. Create multilingual configuration file for each set of localized or regionalized libraries.

    1. From the authoring portlet, navigate to the MLConfiguration_v7 library and create a new content item:

      Use the LocalizedConfigurationFileAT content template for localized sites. Use the RegionalizedConfigurationFileAT content template for regionalized sites.

    2. Type a name and display title to represent the set of multilingual sites.

    3. Complete the following fields:

      Base Content Library Type the name of the library used to store items from the default locale, or leave the field blank to indicate that no base locale will be used.
      Content Libraries Type the names of all the libraries in your multilingual system, including the base content library, separated by commas. This list must not include any shared design libraries. The order that the libraries are entered in this field determines the output of the render-time and edit-time extensions, so IBM recommends to place the base content library first then add the remaining libraries in the order you want them to be displayed.
      Has Regionalizations Used for localized sites only, this setting determines whether any of the localized sites have associated regionalized versions. Change this setting to true if any regionalized sites are associated with the current set of libraries.
      Content Library Owners For each library listed in the Content Libraries field, specify the library name and email address of the user who will be the owner for that library, placing each entry on a new line. For example: MyLibraryFR=wpsadmin@portal.com

      Examples...

      Site Type Language Tree Libraries Configuration files
      Localized site English Spanish English Spanish Localized Configuration file

      • Base Content Library: English
      • Content Libraries: English, Spanish
      Regionalized site English

      • English US (Primary)
      • English Australia

      Spanish

      • Spanish Spain (Primary)
      • Spanish Mexico
      English
      English US
      English Australia
      Spanish
      Spanish Spain
      Spanish Mexico
      Localized Configuration file

      • Base Content Library: English
      • Content Libraries: English, Spanish

      Regionalized Configuration file 1 (English)

      • Base Content Library: English
      • Content Libraries: English, English US, English Australia

      Regionalized Configuration file 2 (Spanish)

      • Base Content Library: Spanish
      • Content Libraries: Spanish, Spanish Spain, Spanish Mexico

    General settings...

      # URL to the Authoring Portlet
      authoringUIURL=http://:///wcmAuthoring

      emailServer=
      emailFromAddress=
      emailCharset=UTF-8

      # Indicates if the destination site area / folder should be autocreated if it doesn't exist
      autoCreateDestination=true

      # Indicates the workflow suffix to use (appended to the current workflow name) when
      # searching for localized/regionalized workflows
      translationWorkflowSuffix=_Translation

      # Indicates whether to store the original workflow on document when localizing/regionalizing workflow
      # (required if using the ML Workflow Switcher)
      storeOriginalWorkflow=false

      # The name of the element on each document to store ML workflow settings, if using the ML Translation table
      # then the element name should be the name of the ML Translation table element
      settingElementName=ML Translations

  7. For each library referenced in each multilingual configuration file, create a link component that references the multilingual configuration file:

    • For references to a localized multilingual configuration file, the link component name must be MLConfFileReference.
    • For references to a regionalized multilingual configuration file, the link component name must be RegionalizedMLConfFileReference.
    • The ALL_USERS group must be assigned to the User role in the component access controls.

  8. This step is optional. Activate email notifications for the workflow synchronization extensions:

    1. Open a multilingual configuration file from the MLConfiguration_v7 library.

    2. Update the following settings in the General Workflow Synchronization Settings section:

      emailServer Name of your email server.
      emailFromAddress Email address entered here is used to set the "From" address on all email notifications. This field must be set to a valid email address.
      authoringUIURL URL of the Authoring server. For example, http://localhost:10045/wps/myportal/wcmAuthoring

    3. Enable email notifications for each multilingual extension:

      Localized Sites Set localize.emailNotificationsEnabled field in the Localize Workflow Synchronization Settings section to true.
      Regionalized Sites Set regionalize.emailNotificationsEnabled field in the Regionalize Workflow Synchronization Settings section to true.
      Synchronized publishing Set SyncPublish.emailNotificationsEnabled field in the SyncPublish Workflow Synchronization Settings section to true.
      Synchronized expiration Set SyncExpire.emailNotificationsEnabled field in the SyncExpire Workflow Synchronization Settings section to true.
      Synchronized deletion Set SyncDelete.emailNotificationsEnabled field in the SyncDelete Workflow Synchronization Settings section to true.

  9. This step is optional. To enable project integration for synchronized publishing, set the SyncPublish.useProjects field in the SyncPublish Workflow Synchronization Settings section to true.

  10. Enable syndication for the MLConfiguration_v7 library.


Framework for multilingual site management

Use one library per locale

A library should be created for the base site, and one library for each localized site, and another library for shared templates and components. When creating libraries, ensure that the correct locale is specified during the creation process, as this locale is used during search and in the multilingual user interface extensions.

If a language does not exist in the list of languages available when creating a library, we can add that language to the list of supported Web Content Manager languages.


Same site structure in each locale

For content to be recognized as being equivalent between sites, they must have the same URL path. This means the names and structure of all the site areas and content items in your site framework must be identical in each site if they are to be equivalent. The display titles can be different, but the names must match.


Use workflow for all modifications

Creating, updating, publishing, expiring, deleting, and even moving content and components should be performed using workflow. This allows code to be triggered by the workflow to notify localized sites owners, automate parts of the localization process, and synchronize important stages in the workflow.

Workflows can be localized by creating an equivalently named workflow in each locale library. Localizing the workflow allows separate approval processes to be executed per locale and is also a requirement for regionalized sites. Localizing the workflow is part of synchronization process, and the provided extension for workflow synchronization has this ability.


Use shared templates and components

Authoring templates, presentation templates, and components should be shared across locales as much as possible. Variability can be built in using workflows or workflow code that differs across locales, and presentation components that are picked up from the current locale.

Presentation templates can be different across locales by having different mappings in each locale. While it should be avoided to ensure consistency across locales, major differences in layout or branding in some locales may necessitate this.

Authoring templates should be shared across localizes whenever possible with text providers used to provide localized template display titles, element names and help-text.


Localization of authoring content

While the initial creation of both the base locale item and any localizations can be done manually using the authoring portlet, IBM recommends to use either a custom authoring field or workflow synchronization code to automate the initial creation of localized documents in the base locale language that are then translated by the appropriate team.


Names and display titles

The Name field in the Identification section must not be translated. Doing so breaks the link between the translated item and its base copy. Translators are free to translate the Display Title field. This is recommended so that links are displayed using the correct translation of the content name.


Other fields

Other fields can be different between locales, but for the purposes of consistency of availability and access, typically many of the metadata fields would be kept in sync, including: authors, categories, publish date, expiry date, and security.

The owner field may be localized to indicate the owner of the specific localization. This could be used during automated workflow code to notify the appropriate users of updates.

The multilingual extensions do not resynchronize fields during updates, nor does it use the owner field. This can be done using additional custom workflow actions added to the Localize and Regionalize workflow stages.


Authoring Templates

There are multiple ways in which authoring templates can be set up in a multilingual environment. The common authoring template model is recommended.


Common Authoring Templates

Common authoring templates should be created in the common library and used for all locales. Text providers can then be written to provide localized template display titles, element names and help-text. The default values of elements cannot be translated. We can work around this limitation by moving the recommended default value into the element help text.


Localized Authoring Templates

Each locale uses separate authoring templates with manually translated element names. This approach is not recommended for the following reasons.

Querying of content is more complicated. Each separate authoring template must be selected in queries used by menus or personalization rules. Content creation is more complicated. Users must choose the appropriate template not just for the type of content, but also for the appropriate language or locale.

Maintaining localized authoring templates is more complicated than maintaining common authoring templates. Changes to the base authoring template will need to be duplicated in each of the localized authoring templates, although the multilingual workflow extensions can help with coordinating these changes.

If there is a valid reason to translate the default values of the base authoring template, IBM recommends implementing through creation of localized authoring templates in each localized site library that all have the same name, and then for each multilingual configuration file, set properties...

...in the sections...

...for each multilingual configuration file.


Single Authoring Templates

This approach involves the use of a single authoring template with fields for each locale. This approach is not recommended for the following reasons:


Previewing

To preview content to see how it will look in a specific locale or language, including the appropriate encoding, preview the content from within the appropriate library.


Create, update and move translated content and components

To keep content and components synchronized between locales, a special workflow stage that runs after the approval stage is created in the base library. This is used for the updating, moving, and creation of content. If the current content item has already been published, the action should be an update or move action. Translated content is treated as new content if no published version exists.


Creating

When new content and components are created in the base library, one of the following actions should be run against each configured localized library and a notification sent to localized content owners:


Updating

When content or components are updated in the base library, draft copies of existing published localized items are created and a notification sent to localized content owners.


Moving

When moving content in the base library, rather than move the published content, a draft copy of the published content should be created first and then the draft moved to the correct location. When the draft content is detected as moved within the base library, draft copies of the existing published localized content should be created and moved to the corresponding location in the localized library. A notification should then be sent to localized content owners.


Publishing synchronization

To ensure that the base item and localized items are published at the same time, project integration can be enabled for the Update Notification workflow synchronization extension. When project integration is enabled, then all associated draft localized documents are added to a temporary project that is automatically published when all documents have been approved. When the project is published, a notification is sent to all localized content owners. When the project is successfully published, the project is deleted.


Expiry synchronization

To ensure that the base item and localized items are expired at the same time, another special workflow stage is required. This workflow stage is run after the publish workflow stage. If every published localized copy is in the publish workflow stage, and all their expiry dates are in the past, then items are moved to the next stage containing the expire action. A notification is sent to all localized content owners when documents leave this stage.


Deletion synchronization

If a base item is deleted the localized content should also be deleted. To handle this, another special workflow stage is required. This stage should be either be placed after the expire stage if content expiration is used, or after the publish stage if content expiration is not used. To delete an item, you need to push the item to the final workflow stage. In most systems, only an administrator will have access to do this. When processing documents in this stage, if the base item is detected, or no base item exists, then all draft, published and expired localized copies are removed and a notification sent to all localized content owners informing them of the deletion. If a localized item is detected and the base item is in another stage, then a deletion request notification is sent to the localized content owners informing them that various localized copies are ready to be deleted.


Presentation templates

In many cases the same presentation templates are used in all locales, with fragments of the template being varied by using one of these two options:

In other cases however, a locale will require such different presentation that an entirely different template is required. For example, to support locales with languages that read right to left, or for locales with very different branding.

These strategies can all be used together, by setting up template mappings appropriately in each localized site, and using site area elements or dot notation where appropriate.


Site area elements

Using site area elements to vary the locale presentation is used for parts of the presentation that are site specific content.

Reasons to use site area elements:

Reasons to not use site area elements:


Using dot notation to reference components from the current library

The name="./item" parameter is used in component tags for locale specific design variations in a presentation template.

Reasons to use dot notation in tags:

Reasons to not use dot notation in tags:


Localized navigator components

When creating a navigator, if the Current site area or Current content options are used, we can reuse navigators across multilingual sites.

Navigators that use selected start positions cannot easily be shared across locales. To use these types of navigators, the name="./item" parameter must be used to retrieve localized components.

Another way of localizing a navigator is to use a JSP fragment to set a different context prior to rendering the navigator. The navigator would be set to use the Current site area as the starting point, and by changing the context we can manipulate this start area using code. Because the code uses a path lookup, the same JSP fragment will work in all of your localized sites.

In this example:


Localized menu components

Menus that use the Current content site area option can be reused across multilingual sites.

Menus that use selected site areas cannot easily be shared across locales. To use these types of menus, the dot notation parameter must be used to retrieve localized versions.

Another way of localizing a menu is to use a JSP fragment to allow a list of site areas to be specified at render time. Because the path is the same for each locale, the same JSP fragment will work in all of your localized sites.

In this example:


Localized text within common design components

If you have common design components to reference localized text into, then IBM recommends to write a Rendering Plugin that wraps a Java Resource Bundle, with the Resource Bundle Key name and the bundle name supplied to the plugin as arguments.


Localized site searching

  1. Create a search collection for each locale specifying the appropriate language.
  2. Create a content source for each site.
  3. Create a search component for each locale library selecting the relevant search collection, or use the Search and Browse portlet.


Automatic localization

Automatic localization is when there are different versions of a page for each page and a user is automatically redirected to one of them, based on their locale. The locale may be determined by the following methods:


URL

The url may contain the locale. For example, ibm.com.au or ibm.co.uk.


Browser preference

Browsers allow us to specify your language preferences. Language preference information is then sent by the browser in the Accept-Language http header. For example:


Portal

The portal determines the language for rendering portal content by a search process along the following sequence at login time:

  1. If the user has logged in, the portal displays the preferred language selected by the user.
  2. If no preferred user language can be found, the portal looks for the language in the browser. If the portal supports that language, it displays the content in that language. If the browser has more than one language, the portal uses the first language in the list to display the content.
  3. If no browser language can be found, for example if the browser used does not send a language, the portal uses its own default language.
  4. If the user has a portlet that does not support the language that was determined by the previous steps, that portlet is shown in its own default language.


User selected localization

User selected localization is when the user selects a language manually from a link or selection list. The selection may then be stored in a cookie for subsequent visits to the website.


Locale selection page

In this scenario, a launch page is shown when a user first comes to the site that shows what locales are available and user then selects the appropriate one.


Equivalent page navigation

In this scenario, navigation is displayed that allows the user to see the same page in a different locale on every page in the site.


Encoding

UTF-8 (Unicode) is recommended as the encoding for your page, since this encoding supports all the characters you will need. If we cannot use UTF-8, then use escapes to represent characters that are not supported by the encoding of your page. As all content is stored in the JCR database with UTF-8 encoding, character data will be preserved.

WebSphere Portal sites should use the encoding set up in the administration portlet. A servlet rendered site should use the encoding specified within WebSphere Portal. If a site needs to have more than one encoding, multiple servers will be required each with the different encoding settings. A gateway is then used to convert the encoding.


Font face considerations

If implementing a multilingual site, it is worth considering what font to use. There are a few font faces in windows that are installed automatically and can show multilingual characters. One of the best font faces is Tahoma. It is easy to read and contains all the Unicode characters.


Create additional multilingual sites

In many cases, the number of languages or regions you require for a site is fixed, but there are times when you need to roll out new locales as your organization grows.

  1. Use the ML Library Copy portlet to copy either the base locale site or one of the translated sites that more closely matches the new site, assigning it a new name and locale during the copy.
  2. Translate the copied items as required.
  3. Update the relevant multilingual configuration file to reference your new library.

Once the initial translation is complete, we can run user acceptance tests before deploying your new site and going into the day to day maintenance that is enabled through automated processes.

We can temporarily disable the automated syncing of this new site while it is going through its initial translation and testing phases.


Mixed language site navigation

In a mixed language site is the navigation is structured to make it possible for users to easily discover what content is available for them in their preferred language, while maintaining the structure of the base language.


Side-by-side preview when authoring

Side by side previews could be built using a special preview page with two Web Content Viewer portlets.


Side-by-side editing

Side by side editing could be built using a special editing page with containing one authoring portlet and one web content viewer portlet.


Write our own context processor

Provide our own processing whenever the web content viewer portlet renders items.


Customize the workflow synchronization email notifications

Modify the default email notifications to provide our own wording.

  1. Navigate to...

      wp_profile_root/paa/wcm_mls/components/wcm_mls/shared/app/

  2. Extract the contents of wcm.ml.emailnotifications.jar to...

      wp_profile_root/wcm/prereq.wcm/wcm/shared/app

  3. Remove the directory...

      wp_profile_root/wcm/prereq.wcm/wcm/shared/app/META-INF

  4. Customize the workflow synchronization email notifications:


    Localize / Regionalize email notifications (syncupdate.properties)

    Message Key Description
    NEWDOCCREATED Notification when a new translation is created.
    LINKCREATED Notification when a link is created within a localized or regionalized library.
    DRAFTCREATED Notification when a draft is created of existing localized or regionalized item.
    DRAFTEXISTS Notification when a draft already exists within a localized or regionalized library.
    DRAFTRENAMED Notification when a draft is renamed within a localized or regionalized library.
    DRAFTMOVED Notification when a draft is moved within a localized or regionalized library.
    FAILED_NOPROCESSSETTING Notification when no processing setting is found for a given localized or regionalized library
    FAILED_CREATENEWDOC Notification when a new translation fails to be created.
    FAILED_CREATEDRAFT Notification when a draft of an existing translation fails to be created.
    FAILED_CREATELINK Notification when a link fails to be created.
    FAILED_CALBASELOCALEDOCPATH Notification when the path to the current base locale path can't be determined.
    FAILED_RENAMEDRAFT Notification when a draft fails to be renamed.
    FAILED_MOVEDRAFT Notification when a draft fails to be moved.


    Publishing Synchronization email notifications (syncpublish.properties)

    Message Key Description
    ITEM_PUBLISHED Notification when a translation is published.


    Expiry Synchronization email notifications (syncexpiry.properties)

    Message Key Description
    ITEM_EXPIRED Notification when a translation is expired.


    Delete Synchronization email notifications (syncdelete.properties)

    Message Key Description
    ITEMDELETED Notification when a translation is deleted.
    SENTFORDELETION Notification when a translation is sent for background deletion.
    DELETEREQUEST Notification when a localized translation is being requested to be deleted.
    REGIONAL_DELETEREQUEST Notification when a regionalized translation is being requested to be deleted.
    DELETEFAILED Notification when a translation deletion fails.

  5. Modify the message using any of the following multilingual tags:

    Message Key Description
    [LOCALE] Locale of the current item.
    [ITEM_ID] API ID of the current item.
    [ITEM_LIBRARY] Name of the library that the current item is in.
    [ITEM_PATH] Path of the current item.
    [ITEM_PATH_LINK] A link to open the current item within the authoring UI using the path of the item as the link name.
    [ITEM_NEW_NAME] New name of the current item, if the item was renamed.
    [ITEM_OLD_NAME] Old name of the current item, if the item was renamed.
    [ITEM_NEW_PATH] New path of the current item, if the item was moved.
    [ITEM_OLD_PATH] Old path of the current item, if the item was moved.
    [BASELOCALE_ITEM_ID] API ID of the current base locale item.
    [BASELOCALE_ITEM_LIBRARY] Name of the library that the current base locale item is in.
    [BASELOCALE_ITEM_PATH] Path of the current base locale item.
    [BASELOCALE_ITEM_PATH_LINK] Link to open the current base locale item within the authoring user interface using the path of the item as the link name.
    [ERRORS] Current list of errors processing the current item.

  6. Save your changes.

  7. Translate your message and update the localized versions of the properties files.

  8. Restart the server.


Edit-time navigation creation extension

This extension provides a way to navigate between localizations of the same item, and to create new items in localized libraries. The extension has two versions that differ only when the extension itself renders its results. The Auto Load version renders immediately, whereas the Manual Load version requires the user to click Refresh before any results are returned.

To use the edit-time navigation creation extension:

  1. Add a text element named ML Translations to an authoring template.

  2. Edit the element properties and add the following code to the custom JSP field:

    For the Auto load version

    • readMode=/wps/wcmml;/jsp/html/MLAuthorTimeRead_AutoLoad.jsp,
    • editMode=/wps/wcmml;/jsp/html/MLAuthorTimeEdit_AutoLoad.jsp

    For the Manual load version

    • readMode=/wps/wcmml;/jsp/html/MLAuthorTimeRead_ManualLoad.jsp,
    • editMode=/wps/wcmml;/jsp/html/MLAuthorTimeEdit_ManualLoad.jsp

  3. Save the authoring template and reapply the template to all content using it ensuring the Add new elements option is selected.


How it works

Every time you open a content item that uses this extension in the authoring portlet, all libraries configured in the current multilingual configuration file are searched for all matching content. To be matching it must be in the same site area path and have the same name.

If a matching content item is found, then information about the content, item including a link to open that item in read mode, is displayed. If the existing content item is a link, then information about the originating content item is displayed instead.

If no matching content items are found, and you have edit access to the content item, we can either create a copy or link of the content item in each localized library:

When performing copy or link operations against an item within the Portal Site library, any pages on the path to the item being copied will be copied as site areas in the destination library.


Update notification extension

This extension uses the settings in the workflow synchronization section of the multilingual configuration file to automate the creation of localized items.

To use the notification extension:

  1. Add either workflow stage...

    • MLConfiguration_v7 \ Localize
    • MLConfiguration_v7 \ Regionalize workflow

    ...to your workflow after the approval stage, which is the first stage after the draft stage.

  2. If any of your localized library sets do not have a base locale:

    1. Ensure that storeOriginalWorkflow is set to true within the General Settings of the associated multilingual configuration file.

    2. For each workflow used by translated content, create another workflow named WorkflowName_Translation, where WorkflowName is the name of the original workflow. This workflow must contain a draft stage, approval stage, and the ML Configuration_v7 \ Switch Workflow stage.

      • If legacy synchronized publishing is to be used, use...

          ML Configuration_v7 \ Pending Published – No Base Locale stage

        ...instead of...

          ML Configuration_v7 \ Switch Workflow

      • If legacy synchronized publishing is not being used, the ML Configuration_v7 \ Switch Workflow stage must also be added to the base workflow after the approval stage as well.

  3. If any of your localized library sets are going to use localized authoring templates, ensure that...

      supportLocalizedAuthoringTemplates

    ...in the Localize or Regionalize workflow synchronization settings of your multilingual configuration file is set to true.


How it works

When an item reaches the Localize or Regionalize workflow stage:

If no base locale library is configured, then the current item is deemed to the base item for the current processing cycle only. If the base item has been renamed or moved, then all existing and newly created draft localized or regionalized documents are also be moved or renamed


More info