Localization Overview

The SCCM documentation model on AdobeDocs provides a ‘Machine Translation first’ localization process. This means that once correctly instrumented, material sets authored in Git.Corp will automatically have localized content produced for every commit that is pushed through to the main branch. This article digs into how that process works, what is needed to take advantage of it and some other facts around the process. If you have questions please let the SCCM team or the Localization team know.

Localization pipeline

The starting point for the localization process is the <reponame>.en repos, such as analytics.en. The Localization team creates associated repos for each supported language, such as the analytics.ja-JP and analytics.fr-FR repos as part of their initial configuration. During this confirguration process, the Localization team will also set what files should have human translation, what languages should have their UI references localized, and what translation memories (TMs) should be used for leveraging. It is important to note that the translation memories contain only human-translated content.

Once a repo is configured for localization, any change that is made to the source .en repo is sent to our translation memories. Any 100% matches with the TM will be levereged. Anything which is not a 100% match will subsequently be sent to our trained machine translation engines. Once the MT engines have completed processing, the files are rolled into the corresponding language repos. Once in the language repo, the localized files will undergo the same processing as the source English files.

If a file is deemed to undergo human translation (HT), then the process is very similar. When a file is sent for machine translation, a copy of the source will also be sent to the translation memories. However, instead of leveraging just the 100% matches, it will leverage 75-100% matches. Anything below 75% will also be sent to the MT engine for processing. Once this is completed, the file will be sent to human translators to post-edit the content, and perform in-context proofreading. The file is sent back, the translation memory is updated for future leveraging by MT and HT workflows, and the file is submitted into the localized Git repo. Once in the language repo, the localized files will undergo the same processing as the source English files.

Localized repos are activated (pushed live to experienceleague.adobe.com) on a regular basis.

Supported languages

  • German (de-DE)
  • French (fr-FR)
  • Japanese (ja-JP)
  • Italian (it-IT)
  • Spanish (es-ES)
  • Brazilian Portuguese (pt-BR)
  • Chinese Simplfied (zh-Hans)
  • Chinese Traditional (zh-Hant)
  • Korean (ko-KR)
  • Dutch (nl-NL)
  • Swedish (sv-SE)

Screen shots and images

The Localization team creates screen shots of images that need to be localized. If writers create images that should not be localized, they can add images to a do-not-localize folder.

If writers create illustrations with text, they should include the source files (such as .ai files) in the repo at the same level as the referenced images. For example, if rules-overview.png is an illustration, an author can upload rules-overview.ai to help localization efforts. The Localization team will use these files to localize the images.

Machine translation (MT)

When localization is fully configured in an AdobeDocs repo, all text is localized through a machine translation for simultaneous release.

Once a repo is configured for localization, any change that is made to the source .en repo is rolled into the corresponding language repos. The content in the language repos then undergoes a machine translation. The amount of time it takes for this translation to occur varies.

Manual overrides of machine translation (human translation)

All text is machine translated by default. However, product teams can work with the Localization team to determine which files or locales should go through a human translation, such as in these scenarios:

  • Content for current top markets
  • Highly visited pages
  • Customer-recommended translation improvements
  • Key locales such as Japan

Decision-making workflow

translation decisions

Marketing stakeholders work with the International Experience Manager (IEM) on the Localization team to evaluate data and decide which content should be human translated.

What happens when human-translated articles are edited?

When writers edit any paragraph that has been human translated, the whole page is sent through the MT and HT processes, as described above.

human translation

Am I getting machine or human translations ultimately?

This depends on timing. When either a machine-translated or human-translated file is submitted back to the localized Git repo, then there is a check to see if the file being submitted is newer than the one that is already there. If so, then the one being submitted overwrites the one already in the Git repo. If the one being submitted is of an older version, then we do not overwrite what is in Git. However, this does mean that a human translation may not overwrite a machine translation if the MT file is newer than the HT one.

User experience in localized languages

When a user goes to a help page in a non-English locale, such as in Spain, the URL changes automatically to display localized content.

MT widget

The MT widget appears only on pages that are partially or fully machine translated. The MT widget explains that the page is automatically translated and gives users an option to toggle between the machine translation and the source content in English.

spanish page

The MT widget includes three states:

  • Page content is translated and in sync with English content

    mt in sync

  • Page content in English

    mt in English

  • Page content is translated but not in sync with English content

    mt not in sync

Language drop-down

A globe menu appears in the upper-right corner of every user guide article in which the repo has been hooked up to localization. To see an example, view any Experience Cloud user guide, such as the Target guide and select a different language.


Users can click the globe icon to select a different language.

language select


A GitHub widget that includes Edit this page icon log issue image or Log an issue icon log issue image is not yet available in localized pages. The Localization team hopes to introduce these features in 2020.

Best practices for improving localization

Writers should create content with a focus on improving localization. Utilizing certain conventions, and avoiding others, prepares documentation for effective translation and localization.

Best practices for writing content to be translated or localized include:

  • Use consistent terminology
  • Use short sentences
  • Use active voice
  • Avoid humor, idioms, jargon, regional phrases, and metaphors
  • Use relative pronouns, such as “that” and “which”
  • Utilize the standard English word order (subject --> verb --> object)
  • Remove needless words
  • Use phrases that can be repeated throughout a topic

Markdown tags

Writers should tag their UI terms and key feature names with [!UICONTROL]. When writers do this, UI strings are replaced by the appropriate localized strings from the same database used by the product teams. This prevents machine translation engines from localizing UI references for languages which do not have the UI localized (i.e., Italian in Adobe Analytics).

For details about using DNL and UICONTROL tagging, see Localization Best Practices.

On this page