Multi-Language Agents

How It Works

Each user has a Language set on their Salesforce User record (the field is technically LanguageLocaleKey — values like fr, de, es_MX, ja, zh_CN). The platform reads this at the start of every conversation and uses it to decide whether to inject a language directive into the agent’s system prompt.

The Two Placeholders

Custom prompts can reference the running user’s language with two placeholders:

Either placeholder can be used in any custom prompt — not just the language directive. They’re especially useful when you want the agent to behave differently for specific locales (e.g. apply a different signature style for French-Canadian users than for European French users).

The Built-In Language Directives

Four small language-directive prompts ship with REDA AI — one per channel — and are seeded on install. They are ordinary Custom Prompt records and can be edited like any other.

The two channels with no signed-in human are the long ones, and they deliberately carry no placeholder. On External Widget the running user is a Sites guest; on API it is the integration or Automated Process account. {USER_LANGUAGE} there would resolve to the service account’s language and force it on every counterparty — so instead of a placeholder those two spell the policy out in words: answer in the language of the message you are replying to, ignore the language of the account or site that sent the request, fall back to the previous message when a greeting is too short to identify, and English only if there is nothing to go on. That written policy is what makes them roughly 70 tokens rather than 20.

The Internal directive is the one that adds the parsing carve-out: respond in the user’s language but keep API names, record Ids and structural tokens (suggestion markers, alert tags, internal links) in English, so the parts of the reply the platform routes on survive translation.

The English-Skip Optimisation

Language directives only help when the user’s language isn’t English. For English users, the platform skips the directive entirely:

• The directive prompt isn’t loaded
• Its tokens aren’t added to the system prompt
• The model doesn’t spend attention on instructions it already follows by default

This is automatic. There’s nothing to configure. For an English-speaking user base the language-directive feature has zero cost.

What Stays in English

The built-in internal directive explicitly tells the model to leave certain elements untranslated:

• API names — field, object and tool names stay in English so they match the Salesforce schema and the agent’s tool definitions
• Record Ids — obviously not translatable, but worth being explicit
• Structural tokens — suggestion chip markers (SUGGESTIONS:), alert tags ([ALERT]), internal link patterns ([[links]]), and similar markers used by the chat UI to render the response correctly

The community, external and API directives keep this rule simpler — they only state “translate all human-readable text” without enumerating exceptions, since most non-internal channels don’t use the same UI markers.

Customising the Directives

The seeded directives are good defaults but can be edited like any Custom Prompt. Common customisations:

• Tone per language. Add language-specific stylistic notes — e.g. instructions to use formal address (vous in French, Sie in German) on customer-facing channels.
• Untranslatable terms. If your domain uses English terms that should stay in English even on customer channels (brand names, product SKUs, legal phrases), spell them out in the directive.
• Quote formatting. Different locales prefer different number, date and currency formats — an explicit instruction saves the model from guessing.

Edits are persisted on the Custom Prompt records. The English-skip behaviour still applies — English users never see the customised directive.

Beyond the Directive

Language-aware behaviour can extend further:

• Language-conditional prompts. Add a custom prompt with content like For users speaking {USER_LANGUAGE_CODE}, do X. Use the placeholders directly in any prompt.
• Translated suggestion chips. Suggestion chips support Custom Labels for translation, so the chat’s empty-state buttons are localised automatically by Salesforce’s translation infrastructure.
• Localised content fields. If the agent reads context fields from records that have translated values, the model sees them in the right language — no special configuration needed.

See Prompt Context Variables for the full list of merge fields available in custom prompts.

Channels and Languages

Each channel uses its own language-directive prompt because the trade-offs differ:

• Internal — the running user’s Salesforce language is authoritative. Internal users typically have a stable language preference set on their User record.
• Community — portal users have language preferences too; the same mechanism applies.
• External Widget — the user is a guest on a public website. The widget’s host page can configure the language explicitly; otherwise the platform falls back to the guest user’s configured language.
• API — the running user is whichever user the Flow or integration runs as. For multi-language messaging integrations, run the Flow as a user whose language matches the recipient, or use a custom prompt that conditions on the conversation’s known language.

Best Practices

Don’t hand-translate persona prompts. Maintaining one persona per language is a maintenance trap. Write the persona once in English and trust the language directive to handle translation at runtime.

Test the API-name carve-out. If the agent is mistranslating field labels or breaking structural markers, the internal directive’s English-only carve-out may need a tweak.

Use the placeholders sparingly outside the directive. A single language directive plus the model’s built-in multilingual capability handles most cases. Reach for per-language conditional logic only when you have a specific stylistic or legal requirement.

Verify with the Conversation Debugger. The Debugger shows the assembled system prompt for a real conversation — the fastest way to confirm that the directive was (or wasn’t) applied for a given user.

Watch credit consumption per channel. The internal directive is ~40 tokens; widget and API directives are ~20. Across high-volume channels this matters less than a verbose persona prompt, but it’s worth being aware of.

Changes included in 1.16000

For API and External Widget agents, language instructions follow the incoming message. User placeholders remain meaningful only on the authenticated Internal and Community routes. Review the shared API/external language directives and the API core instructions: rules for a concise automation response must not make a tool-delivered message to a person greeting-less or abrupt. Preserve custom instructions while merging defaults.

Client upgrade checklist

Frequently Asked Questions

Next Steps

Read Prompt Context Variables for the full list of merge fields, or Custom Prompts per Agent to add language-conditional behaviour to specific agents.