In order to export XLIFF as part of a workflow action, the following actions need to be taken:

Pre-Processing: Translation Items

A translation item represents a content item during the translation process. It is meant to contain only those properties or partial properties (for Structs) which should be translated. Any filtering for example of empty properties (and deciding what empty actually means) is done here.

Map<Locale, List<TranslateItem>> getTranslationItemsByLocale(
        Collection<ContentObject> masterContentObjects,
        Collection<Content> derivedContents,
        Function<ContentObjectSiteAspect, Locale> localeMapper) {

    ContentToTranslateItemTransformer transformer =
            getSpringContext()
                    .getBean(ContentToTranslateItemTransformer.class);

    return transformer
            .transform(
                    masterContentObjects,
                    derivedContents,
                    localeMapper,
                    ITEM_PER_TARGET
            )
            .collect(
              Collectors.groupingBy(TranslateItem::getSingleTargetLocale)
            );
}

In Example 5.15, “Transforming to Translation Items” you see a typical example used within some workflow action to generate a representation as translation items. It uses the Spring context of the workflow server (retrieved via getSpringContext() from SpringAwareLongAction) to retrieve a bean of type ContentToTranslateItemTransformer.

The ContentToTranslateItemTransformer is prepared for typical translation workflow scenarios, where you have a set of master content objects (contents or versions) to translate and a set of target contents which should receive the translation result.

As configuration options the transformation process takes a strategy to determine the language from the master content objects as well as from the derived contents and a flag how to group the results (see TransformStrategy). For XLIFF export the recommended flag is ITEM_PER_TARGET.

The result in the given example will be grouped by target locale, which allows combining all translation items into one XLIFF document for one common target locale.

static Locale preferSiteLocale(ContentObjectSiteAspect aspect) {
  Site site = aspect.getSite();
  if (site == null) {
    return aspect.getLocale();
  }
  return site.getLocale();
}

In Example 5.16, “Function to Determine Locales” you see a recommended function used as localeMapper passed to the method defined in Example 5.15, “Transforming to Translation Items” to determine the locale (source as well as target) to set within XLIFF. The method prefers the site locale over the locale within a content item.

Generating XLIFF Document

Just as the ContentToTranslateItemTransformer the XliffExporter bean is available in Spring context.

Path exportToXliff(Locale sourceLocale,
                   Map.Entry<Locale, List<TranslateItem>> entry)
        throws IOException {

  XliffExporter xliffExporter =
          getSpringContext().getBean(XliffExporter.class);
  String targetLanguageTag = entry.getKey().toLanguageTag();
  List<TranslateItem> items = entry.getValue();

  // Provide some meaningful name.
  String baseName = ...;

  Path xliffPath =
    Files.createTempFile(
          baseName,
          "." + sourceLocale.toLanguageTag() + "2" +
          targetLanguageTag + ".xliff"
    ).toAbsolutePath();

  try (Writer xliffWriter =
          Files.newBufferedWriter(xliffPath, StandardCharsets.UTF_8)) {
    xliffExporter.exportXliff(
            items,
            xliffWriter,
            XliffExportOptions.xliffExportOptions()
                    .option(XliffExportOptions.EMPTY_IGNORE)
                    .option(XliffExportOptions.TARGET_SOURCE)
                    .build());
  }

  return xliffPath;
}

In Example 5.17, “Exporting XLIFF” you see how you may transform the translation items generated above into an XLIFF document which you may then upload to the translation service.

The parameter sourceLocale is just required to generate some meaningful, easy to debug filename. If your translation service preserves these filenames, it may be useful to generate a name, which can easily be identified later on. That is why the filename in the example contains information such as the source as well as the target language.

When invoking the XliffExporter you have several options to choose from, to control the output of XLIFF. In the given example empty trans-unit nodes should be ignored (they will not be part of the XLIFF export) and the target nodes will contain the same value as the source node, which is recommended by some translation services. For additional options have a look at XliffExportOptions.