Published Translation
A Published Translation is a translated version of a Salesforce Knowledge article that has finished translation, been published, and is now live for readers in that language.
Definition
A Published Translation is a translated version of a Salesforce Knowledge article that has finished translation, been published, and is now live for readers in that language. It is the language-specific counterpart to the master article, sharing the same article record but holding its own body, title, and publish status in a target language like French, German, or Japanese.
In data terms it is a KnowledgeArticleVersion row whose Language is the target language and whose PublishStatus is Online. When a reader's language preference matches that translation, Salesforce serves them the published translation instead of the master-language version, so a French customer reads French and a Japanese customer reads Japanese from the same underlying article.
How a translation moves from draft to published
The master article and its language versions
Every Knowledge article starts in one default language, the master language you pick when you enable Salesforce Knowledge. That master version carries the canonical content. Translations are not separate articles. They are additional language versions attached to the same article, each tracked as its own KnowledgeArticleVersion record with its own Language value. So a single article about resetting a password can have an English master plus French, Spanish, and German translations, all sharing one article number and one set of data categories. Because each version is published independently, the English master can be Online while the German translation is still a draft. Readers only ever see versions whose PublishStatus is Online and whose Language matches their preference. This separation lets you ship the source content immediately and add languages on their own timelines. It also means a published translation can fall out of date when the master changes, which is why translation management treats source updates as triggers to re-translate. Understanding this one-article-many-versions model is the key to reasoning about why a translation shows or hides for a given user.
Two ways to produce the translation
Salesforce supports two translation methods, and both end at the same published state. The first is in-app translation. You assign an article to a translation queue or directly to a user who speaks the target language. That person opens the draft translation in Lightning Knowledge, often with the primary article and translation shown side by side, types the translated content, and marks it complete. The second method suits external vendors. You export articles for translation as a zip of files, send them to a translation agency, then import the translated files back into Salesforce. Both paths create or update a draft translation version. Neither one publishes automatically. After the translated draft exists and passes any review, someone with the right permission publishes it, and only then does it become a Published Translation. The choice between methods usually comes down to volume and language coverage. Small teams with bilingual agents lean on in-app translation. Large global programs with many languages and high article counts lean on export and import so a professional language service can work at scale.
The translation status lifecycle
A translation moves through a small set of states before it is live. It begins as a draft when the article is submitted for translation. While a translator works, the version stays in draft. Some teams add a review step so a second person checks accuracy before release. When the translated draft is approved and published, its publish status becomes Online, and that is the Published Translation. If a newer translation is published later, the prior published translation is archived as a version, keeping a history. The crucial point is that publishing a translation is a deliberate action, separate from publishing the master article. You can have a published English master and three published translations live at once, plus two more translations still sitting in draft. Each language version has its own status. This is why a customer might see fresh content in English but slightly older content in their language: their translation was published earlier and has not been refreshed against the latest master. Treat the published translation as a snapshot in that language at the moment it went Online, not as something that auto-syncs with the source.
How readers get served the right language
Once a translation is published, Salesforce decides which version to show based on the reader's language. In an Experience Cloud site or the Salesforce help center, the user's language preference drives the lookup. If a published translation exists in that language, it is served. If not, the reader falls back to the default-language version so they still see something useful rather than a blank result. Internal agents in the console see the language version that matches their settings, and they can switch to other languages from the article. Search behaves the same way. When an agent or customer searches, results favor the matching language so the snippet and the opened article are in the language they expect. This fallback behavior is what makes a partially translated knowledge base usable. You do not need every article in every language on day one. You translate the highest-traffic articles first, publish those translations, and everything else gracefully shows the master language until its translation is published too. The published status is the gate: a draft translation, no matter how complete, will not be served until someone publishes it.
Keeping published translations in sync
The hardest part of running translations is drift. When you edit and republish the master article, the published translations do not change. They stay frozen at their last published wording, which can now contradict the updated source. Salesforce helps you spot this by flagging translations whose master has been updated since the translation was last published, so reviewers know which languages are stale. A healthy program builds a loop: edit the master, mark affected translations for re-translation, route them back through the queue or the vendor, then republish. Some teams gate master changes so a content update cannot go live until translations are at least queued. Others accept temporary drift on low-impact edits and only re-translate on meaningful content changes. Either way, the published translation is only as accurate as its last publish, so the operational discipline matters as much as the initial translation. Newer orgs can also use AI Knowledge Translations to generate a first draft of the translated content automatically, which a human then reviews and publishes. That speeds up the draft stage, but the publish step and the sync discipline remain human responsibilities.
Querying and reporting on published translations
Because each translation is a KnowledgeArticleVersion record, you can find published translations with SOQL and report on coverage. A query filtering PublishStatus to Online and grouping by Language tells you how many articles are live in each language. Comparing that to the count of published master articles shows your translation coverage gaps. This data is useful for prioritizing work: if English has 800 published articles but German only 120, you know where the next translation budget should go. Reports can also surface translations whose master was updated after the translation's last publish, giving content managers a stale-translation worklist. When you build these queries, remember that the same article number appears once per language version, so counts should be grouped by language to avoid double counting articles. Validation in custom code matters too. If Apex or a flow looks up a knowledge version, it should filter by both PublishStatus and Language so it does not accidentally read a draft or the wrong language. Treating published translations as first-class queryable records, not just UI artifacts, is what lets a global Knowledge program measure itself and stay honest about coverage.
How to publish a Knowledge article translation
Publishing a translation is the final step after the translated draft exists. You enable multiple languages, get the translated draft created (in-app or via import), then publish it so it goes live for readers in that language.
- Enable multiple languages
In Knowledge Settings, turn on multiple languages and add each target language. For each one, you can set a default assignee or translation queue so submitted articles route to the right translators.
- Submit the article for translation
From the published master article, use Submit for Translation. Pick the target language, an assignee or queue, and a due date. This creates a draft translation version in that language.
- Translate the draft
The assignee opens the draft translation, often with the primary article shown side by side, and enters the translated title and body. Alternatively, import a translated file from a vendor or generate a first pass with AI Knowledge Translations.
- Review and publish
Once the translated draft is complete and reviewed, publish it. Its publish status becomes Online, and the Published Translation is now served to readers whose language matches.
The master language chosen when Knowledge is enabled. It holds the canonical content and is the fallback shown when no published translation exists for a reader's language.
A Salesforce queue that holds articles awaiting translation in a given language, so a team of translators can claim work instead of receiving direct assignments.
An optional user or queue that submitted translations route to automatically for each language, removing the need to pick an assignee every time.
An option that auto-generates a draft translation for review, speeding the draft stage while a human still verifies and publishes the result.
- Publishing a translation is separate from publishing the master. A live English master does not make its German draft visible until you publish the German version.
- Republishing the master article does not update existing published translations. They stay frozen until you re-translate and republish them.
- If no published translation exists in a reader's language, they see the default-language version, not an error. Plan coverage around that fallback.
- Code or flows that read a knowledge version should filter on both PublishStatus and Language, or they may pick up a draft or the wrong language.
Prefer this walkthrough as its own page? How to Published Translation in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Published Translation.
- Translate Articles in Lightning KnowledgeSalesforce
- Export Articles for TranslationSalesforce
Hands-on resources to go deeper on Published Translation.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Published Translation in Salesforce Knowledge?
Q2. How do translations relate to the multi-language Knowledge base feature?
Q3. When a source English article changes, how is the Published Translation typically kept current?
Discussion
Loading discussion…