Enhancing the Translation Process

Prepublish Translations

An imperfect translation is often better than no translation at all. Smartling’s standard behaviour is to use ‘published’ translations, meaning that could be stuck with English until any editing and review steps are completed. Prepublishing provides a way around this.

Prepublishing translations results in them being considered published, even though they’re still in an earlier step of the translation workflow. Prepublished translations are displayed on GDN pages; and are included when downloading ‘published’ translations via API, Connector, or Drag & Drop. They also can be used by SmartMatch.

Prepublishing is most suitable for situations where translations can easily be updated, such as websites; it’s not a good fit for translated emails which can’t be changed after they have been sent.

Behavior of Prepublishing

Prepublishing with the GDN

The GDN includes prepublished translations when rendering web pages. This is one of the strongest use cases for prepublishing as the effect of the action takes place straight away, i.e., the prepublised translation appears on the website, and it’s easy to update prepublished translations.

GDN Static Cache

The Static Cache system will cache whatever translations the GDN displays at the time of caching, and so it can cache a page with prepublished translations. Furthermore, the Static Cache system will consider prepublished translations as published when determining whether to refresh the cache. The cache will be refreshed with the latest copy of the page if all translations on the page are either published, prepublished or excluded. The refresh process takes place approximately every 10 minutes for frequently accessed pages.

Prepublishing with File Downloads (Drag & Drop and API)

Downloading files manually from the Files tab in a project, or via API, will include prepublished translations when the ‘published’ download option or retrieval type is chosen.

Dashboard download

Screenshot_2020-07-08_at_10.38.47.png

 

API download parameter

Screenshot_2020-07-08_at_10.51.07.png

This provides a way to download published and pre-published translations only, while using the source string for all other translations. The "current" or "pending" option will download all saved translations whether prepublished or not, and is more appropriate for testing rather than production use.

Prepublishing with Connectors

When a Connector delivers translations, it includes prepublished translations if the ‘Published’ retrieval type is selected in the Smartling connector settings when the download actually occurs. This setting is only visible to Smartling admins for hosted connectors. 

unnamed__2_.png

However, it’s important to understand what triggers connector downloads to occur. The various possibilities and the effect on prepublished translations are in the table below.

 

Trigger

Connector Behavior

Prepublish Results

Manual (user-initiated) export of translated item.

Connector downloads according to retrieval type setting.

Prepublished translations are downloaded.

Standard callback

When it receives a callback, the connector downloads according to retrieval type setting

Since the standard callback is not sent until all translations reach the published state, pre-published translations are not downloaded until moved to the Published step.

Polling

Connector periodically checks string workflow state and only downloads when all authorised strings are in the Published step.


For Sitecore, we download the results of the ‘recently published’ API endpoint, but this endpoint does not include files that were only prepublished--they need to be fully moved to the published step to be identified here.

Pre-published strings are not downloaded until moved to the Published step.

Prepublished callback (see below)

When it receives a callback, the connector downloads according to retrieval type setting

Prepublished translations are downloaded.

Job callback
(Github connector)

The Github connector is unusual in that it waits for a job-completion callback rather than the file-based callback to trigger file downloads. 

Since the job-completion callback is not sent until all translations reach the published state, pre-published translations are not downloaded until moved to the Published step.

 

In summary, manual export of translations is the best option for making ad-hoc prepublished translations are available for use. If prepublished translations are needed regularly, then the prepublished callback might be an option, but this requires careful technical consideration.

Callback on Prepublish (for connector or API)

The standard callback notification is sent when all authorized strings in a file reach the Published step in a particular language. If callback handling has been configured for the connector (which it is for all hosted connectors), the callback triggers the connector or API integration to download translations.

It’s also possible to configure a project to send callback notifications when all authorized strings either reach the Published step or are prepublished in a language. This ‘prepublished’ callback can trigger the download of translations sooner than might otherwise have happened. When the prepublished callback is enabled, the standard callback will also be sent when all authorized translations reach the Published step of the workflow.

Use of this option should be considered carefully and tested to ensure that the integration will still work well and pick up the subsequent publishing of the translations. Some connector platforms or API integrations might not handle this well. Consult your Solution Architect in assessing. 

Prepublishing with Smart Match and Leverage

A side-effect of prepublishing is that the prepublished translations are treated as Published from a translation-memory perspective, and as a result could be used in SmartMatches. This may or may not be desirable, so some consideration should be given to it prior to prepublishing. For example, it probably makes sense to avoid Smart Matching to Published from TMs that could contain prepublished translations. 

How to Prepublish Translations 

There are three ways to prepublish translations:

  • Action menu in Strings View. Simply select the translations you want to prepublish and go to Actions > Prepublish. This option is useful for ad-hoc prepublishing.

 

  • Workflow Step Configuration. Under Manage Step > Automation > Prepublish, select either:
    • On Save. Will prepublish translation anytime changes are saved.
    • On Submit. Will prepublish translation when the translation is submitted to the next step. (Note that ‘moving’ the translation to the next step will not prepublish--it has to be ‘submitted’.)

workflow_config.png

 

  • Smart Match Configuration. When enabling SmartMatch to any step other than Published, you have the option to also prepublish the translation. This results in the translation getting populated by the SmartMatch, being moved to the appropriate workflow step, and also being prepublished.

unnamed__3_.png

Moving a string to the Published step of a workflow, and then moving it back again has similar effects to prepublishing; although it is not identified in the UI as prepublished. 

Viewing Prepublished Translations

Filters

It’s possible to filter for strings that are prepublished, or available to be prepublished in the Strings View:

strings_view_filter.png

Prepublished strings are also identified with a small dot indicator in the Strings View:

unnamed__4_.png

 

If an earlier version of a translation was prepublished, and subsequently changed but not prepublished, this indicator will not be shown, even though the string has a prepublished translation. This should be visible in the string history.

String History

Prepublishing of strings is noted in the string history:

unnamed__5_.png

Job Progress

Prepublishing of strings is not reflected in job progress indications. The actual workflow step of the translations is used to calculate progress.

Considerations

  • Make sure prepublishing is only used in situations where the translations can be updated later if they’re amended after prepublishing. A good example of when prepublishing is not appropriate is email translation because the translations can’t be updated after the emails are sent.
  • If enabling prepublish on a workflow step, prepublish-on-submit is the preferred option for the first prepublish step because:
    • It reflects the final version from that step
    • It will catch all content that moves through the step (whereas prepublish-on-save only prepublishes translations that were modified in the step)
    • It avoids prepublishing intermediate work that is saved in the step.
  • If prepublish-on-submit is enabled for a workflow step, then it probably makes sense to enable prepublish-on-save on any subsequent workflow steps so that any changes are picked up and prepublished as they move through the workflow.
  • Resources working in steps with prepublish-on-save should be made aware of this, as it could result in intermediate work being prepublished (i.e., anytime they save a translation, even if it’s not ready).
  • If the aim is to use translations that tend to languish in a Review step, the appropriate approach is to enable prepublish-on-submit in the prior step (or to manually prepublish as needed).
  • Make sure the customer understands that prepublished translations can be used for Smart Matching. 
  • Perhaps ensure that TMs that could contain prepublished translations are not used in ‘Smart Match to Published’ mode in any leverage configurations.
  • Make sure users of static cache are aware that they might need to manually refresh cached pages if they contain prepublished translations.

Some Additional Details

Smartling keeps track of two translations for each string: 

  • Current Translation (also called ‘pending’ when using the API). As long as a string is active and in progress in the workflow, the current translation is the most recently saved version of a translation. If a string becomes inactive, e.g., due to its source file being deleted, the current translation is removed.
  • Published Translation. This is the most recent translation that was either prepublished or moved to the Published workflow step. If neither of those things has happened, then the published translation is a copy of the source string. Published translations are what the GDN displays and what the ‘Published’ option delivers when downloading via Dashboard, API or Connector; and they include prepublished translations.

The published translation exists even before any translations have reached the Published step of the workflow.

Note that the published translation is not updated when:

  • a prepublished, pending translation is subsequently updated (unless prepublished again)
  • a translation in a Published step is moved back to an earlier step of the workflow and modified in that step. (It is updated when changes are made in the Published step.)

Thus, the published translation might not be visible in the list view, but it is, nevertheless, the one that will be used by the GDN and published-translation downloads.

If a string becomes inactive (e.g., source file deleted) while ‘in progress’ in the workflow, then the published translation is removed (though remains in the TM); if it becomes inactive while in the Published step of a workflow, it is retained and will automatically reappear if the string becomes active again.

 

Was this article helpful?