Real-Time Translations
Real-Time Translations is a Salesforce feature that uses AI-powered machine translation to translate content (Knowledge articles, chat conversations, case messages, and similar text) into the user's preferred language at the moment of display.
Definition
Real-Time Translations is a Salesforce feature that uses AI-powered machine translation to translate content (Knowledge articles, chat conversations, case messages, and similar text) into the user's preferred language at the moment of display. The feature works without a manual translation pipeline: the source content is authored once in a master language, and the platform translates it on demand when a user or customer requests it in a different language.
The feature lives under Salesforce's broader internationalization stack and powers both internal-facing scenarios (a global support team reading Knowledge articles in their preferred language) and customer-facing scenarios (a chatbot replying in the customer's detected language regardless of the agent's). The underlying engine uses Salesforce's AI Translation service, which is built on neural machine translation models tuned for business and technical content. Real-Time Translations is fundamentally different from the legacy Article Translation workflow, which required human translators to produce a separate translated record per language.
How Real-Time Translations works in practice
The on-demand translation flow
When a user opens a Knowledge article or starts a chat conversation, Salesforce detects the user's preferred language from their User record's Language Locale Key field. If the source content is already in that language, it is displayed unchanged. If it is in a different language, the platform sends the text to the AI Translation service, receives the translated text, and displays it inline. The original is preserved unchanged; the translation is generated for display only. For frequently accessed articles, translations are cached so subsequent reads do not require another translation call. Cache invalidation happens when the source article is edited or after a configurable expiration period.
Supported content surfaces
Real-Time Translations is supported across several Salesforce surfaces: Knowledge articles (the most common case), live chat messages between agents and customers, case description and resolution text, and Chatter posts in some configurations. Each surface has its own enablement toggle in Setup. The supported languages depend on the AI Translation service capabilities, which currently cover around 100 source-target language pairs spanning the major world languages. Specialized languages or dialects may not be supported and fall back to the source language. The list of supported languages is published in the Salesforce Help documentation and is updated each release.
Translation quality and review
Machine translation has improved dramatically with neural models, but it is still imperfect. Real-Time Translations is best for general business content: definitions, instructions, customer support messages. It is less reliable for content with heavy jargon, brand-specific terminology, or culturally nuanced messaging. For Knowledge articles in regulated industries (financial, legal, healthcare), the standard practice is to use Real-Time Translations for first-pass coverage and then have professional translators review and refine the output for high-traffic articles. The platform supports this hybrid model: an article can have machine translation by default plus optionally a human-curated version that overrides the machine version when present.
Cost and scaling considerations
The AI Translation service is consumption-priced based on the volume of characters translated. Caching translations dramatically reduces ongoing cost: a Knowledge article translated once and then read 10,000 times costs the same as a single translation call. Live chat translations are not cacheable because each conversation is unique, so chat translation cost scales with conversation volume. Most enterprises budget for translation cost as a separate line item in their Salesforce contract, and the Salesforce account team can provide volume estimates based on the org's content volume and expected access patterns. Reviewing cost monthly during the first quarter after enablement keeps surprises out of the budget conversation.
Custom dictionaries and glossaries
The AI Translation service supports custom dictionaries (sometimes called translation memory or glossaries) that tell the engine how specific terms should be translated regardless of the default machine output. For brand names, product names, and industry jargon, this is the right way to ensure consistency. The dictionary is configured per language pair and applies across all content the translation service handles for that org. Building and maintaining the dictionary is an ongoing effort: every quarter, review the actual translation output for inconsistencies and add or refine dictionary entries for terms that need control. The dictionary is what separates a credible localization program from raw machine translation.
Real-Time versus pre-translated Knowledge
Salesforce Knowledge supports both Real-Time Translations and the older Article Translation workflow. The two coexist: an article can have human-translated versions for the most critical languages and Real-Time Translations for the long tail. When a user requests an article in language X, Salesforce first checks for a published human translation in language X. If one exists, it is shown. If not, the source article is sent to the AI Translation service. This fallback model gives organizations a path to incremental localization: start with Real-Time Translations for everything, identify the high-traffic articles, commission human translations for those, and let Real-Time handle the rest.
Audit and compliance
Some organizations have regulatory requirements that translated content used in customer-facing communications must be reviewed and signed off by a qualified person. Real-Time Translations does not satisfy these requirements directly because the translations are generated on the fly without human review. The compliance path is to disable Real-Time Translations for the regulated content surfaces, route the affected articles through the standard human-translation workflow, and keep Real-Time only for internal-facing or non-regulated content. The Setup configuration supports per-surface enablement, which makes this hybrid governance practical without disabling the feature entirely.
Real-world rollout patterns
Across enterprises that have adopted Real-Time Translations, three rollout patterns emerge consistently. The phased-by-surface pattern enables one content surface at a time (Knowledge first, then Chat, then Case) so each one can be validated for quality and cost before the next goes live. The phased-by-language pattern enables one target language at a time, starting with the languages where machine translation quality is strongest (Spanish, German, French) and adding harder languages (Japanese, Arabic) only after the glossary is built out. The phased-by-audience pattern enables Real-Time Translations for internal users first (agents reading Knowledge in their preferred language) before turning it on for external customers, giving the org a chance to refine the experience without customer-facing exposure. None of these patterns are mutually exclusive, and most large rollouts combine elements of all three. The single biggest predictor of a successful Real-Time Translations program is not the technology but the governance: ownership of the glossary, monthly cost reviews, and quarterly quality reviews with native-language reviewers.
Enable Real-Time Translations
Enabling Real-Time Translations is a multi-step Setup process that spans license confirmation, language enablement, content surface selection, and cost validation. The workflow below covers a standard rollout from kickoff to live operation.
- Confirm license and supported languages
Verify that the org has the AI Translation feature licensed and that the languages you need to support are on the published supported-language list. From Setup, search for Translation Settings and confirm the configuration page is visible. Identify which user populations and which customer populations need which target languages. Document the scope before turning anything on; piecemeal enablement is harder to govern than a planned rollout.
- Enable target languages on user and content surfaces
From the Translation Settings page, enable each target language. Confirm that the relevant users have the right Language Locale Key on their User records (this drives which translation they see). For content surfaces (Knowledge, Chat, Case), toggle Real-Time Translations on for each surface where it should apply. Save the configuration. Run a quick verification by viewing a Knowledge article as a test user whose locale differs from the article's source language and confirming the translated version appears.
- Build the custom glossary
From the AI Translation glossary configuration, add custom dictionary entries for terms that need controlled translations. Brand names typically stay untranslated; product names follow brand-specific localization rules; industry jargon follows the org's terminology guide. Add entries for each language pair the org supports. Test by translating a sample article containing several glossary terms and confirming the engine respects the dictionary. Iterate the glossary monthly during the first three months as new edge cases surface.
- Monitor cost, quality, and adoption
After enablement, monitor the translation service consumption monthly. Compare to the estimated budget. If consumption is much higher than expected, investigate which content surface is driving the volume and consider whether caching settings can be tuned. Review the actual translation output quarterly with a multilingual reviewer to catch quality issues and glossary gaps. Track user adoption: are non-English users actually reading the translated content, or do they default to the source language anyway. The answer guides future investment in the localization program.
- Machine translation quality is good but not perfect. High-stakes content (legal, medical, financial) needs human review or at least a glossary that controls the most sensitive terms.
- Translation consumption is metered. Volume estimates from the account team are starting points; real costs can be higher if content access patterns differ from the estimate.
- Cache invalidation happens when source content is edited. Frequent edits on a popular article translate to higher translation costs because the cache misses each time.
- Real-Time Translations does not satisfy some compliance requirements for human-reviewed translations. Configure per-surface enablement to keep regulated content out of the feature.
- User Language Locale Key drives target language selection. Users with the wrong locale see translations into the wrong language, which is a common adoption complaint.
Trust & references
Straight from the source - Salesforce's reference material on Real-Time Translations.
- Real-Time TranslationsSalesforce Help
- Knowledge TranslationSalesforce Help
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 the primary benefit of Real-Time Translations for Salesforce administrators?
Q2. Why is understanding Real-Time Translations important for Salesforce admins?
Q3. Can a Salesforce admin configure Real-Time Translations without writing code?
Discussion
Loading discussion…