An imperfect translation is often better than no translation at all. Smartling’s standard behavior 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 can also 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.
A string must be in progress and have a saved translation to be prepublished.
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 prepublished 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
API download parameter
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 will only trigger pre-publishing callbacks for new content going forward, meaning it will not cause content that was already translated and pre-published to be delivered.
This setting is only visible to Smartling admins for hosted connectors.
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 |
The Connector periodically checks string workflow state and only downloads when all authorized 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 |
The Github connector is unusual in that it waits for a job-completion callback rather than the file-based callback to trigger file downloads. However, prepublishing can be achieved by enabling prepublish on the workflow and in any enabled SmartMatch rules, as well as Early Delivery on a configuration set. |
Prepublished translations are delivered in an Early Delivery pull request. |
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 SmartMatch 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 before 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 when needed.
- Workflow Step Configuration: Under Manage Step > Automation > Prepublish, select either:
- On Save. Will prepublish translations anytime changes are saved.
- On Submit. Will prepublish translations 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’.)
It is important to consider if the workflow is an account workflow or project workflow. If prepublishing is enabled on a workflow step of an account workflow, strings in any project that uses that workflow will also be prepublished.
- SmartMatch 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.
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:
Prepublished strings are also identified with a small dot indicator in the Strings View:
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:
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 are 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.
- When 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).
- If prepublish is enabled for a Translation step using an MT Profile, the unedited machine translation will be prepublished to the final environment, but it will not be saved to the Translation Memory. Prepublished human translations will be prepublished to the final environment and also saved to the TM.
- Prepublished translations which are saved to the TM (i.e. prepublished human translations) can be used for SmartMatching.
- 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.