Designing Persistent Multilingual Chat in n8n: Language Selection and On-the-Fly Translation
A robust multilingual chat flow in n8n needs an explicit language-selection step, persistent session state, and a translation layer that can be invoked by HTTP and Chat nodes. Implementing this as a middleware pattern keeps runtime simple, reduces repeated prompts, and balances latency/cost with user experience.
The simplest, most reliable pattern is to capture the user's preferred language at session start and persist that as session metadata or in a lightweight datastore keyed by session ID. Ask the user once, set Accept-Language style metadata, and ensure every downstream node (Chat, HTTP, Function) reads that flag. This avoids re-prompting and gives you a single control point for language behavior across the workflow.
For automatic translation, treat translation as a service: either call a managed MT API or a dedicated LLM translation model when incoming content language differs from the user's target language. Wire translation into the entry and exit points: detect and translate inbound messages to the canonical processing language, and translate outbound responses back to the user's chosen language. In n8n this can be modularized as reusable sub-workflows or components (TranslateInbound, BusinessLogic, TranslateOutbound) so you maintain consistency and reduce duplication.
Operational considerations matter: translation adds latency and cost and sometimes alters nuance or legal phrasing. For business-critical messages, prefer deterministic translation engines or human review. Persist user preference, add fallbacks for unsupported locales, and cache translations for repeated content. Finally, instrument metrics (latency, error rate, translation quality signals) and set SLAs per tenant so leaders can balance customer experience, cost and compliance.
Original Source
n8n Community