A business runs a WordPress site with three language versions through a translation plugin. It works well and traffic from two additional countries has grown.
The enquiries arrive in three languages into one inbox. The site's chat widget answers in the default language regardless of which version somebody is reading, which is more jarring than having no widget at all.
The translation was the expensive part and it stops at exactly the point where the visitor wanted to interact.
Step 1: check which language versions actually get traffic
Before configuring anything, since effort spent on a version with almost no visitors is effort not spent on the one that matters.
Step 2: make the assistant follow the page language
The most important setting. A visitor on the French version should be greeted and answered in French without having to ask.
Step 3: keep one source of answers
Written once, with the language versions derived from it, rather than three separate sets that diverge as the business changes.
Step 4: record the facts that differ by market
Delivery, payment, returns and tax, since translating the domestic answer produces a fluent and incorrect one.
Step 5: check how the plugin handles urls
Language versions sit at different paths or subdomains depending on the setup, which affects both configuration and reporting.
Step 6: test the widget on every language version
Including the less used ones, which is where a misconfiguration survives unnoticed for months.
Step 7: check the page speed impact
Which is the concern in page speed questions before adding anything, and matters more where a translation plugin is already adding weight.
Step 8: watch for conflicts with the translation plugin
Two plugins manipulating the same page can interact badly, which is the ground in plugin conflict questions wordpress owners ask.
Step 9: decide the handover route per language
Who takes a conversation in each language, or what is said when nobody can, which should be honest rather than implied.
Step 10: set the register per language deliberately
Formality conventions differ, and a correct translation in the wrong register reads worse than an awkward one in the right one.
Step 11: report separately by language
Volume, questions and outcomes per language version, which is the measurement in measuring what visitors asked and never found.
Step 12: keep the untranslated pages in mind
Most multilingual sites have pages that were never translated, and an assistant reading them may answer from content the visitor cannot see.
Step 13: review after any plugin or theme update
Which is when configurations break quietly, and when a language setting reverts without anybody noticing.
Step 14: decide what happens on the default version
A visitor arriving on the English pages whose browser is set to another language should be offered a switch once rather than answered in a language they did not choose. Getting this wrong is more jarring than not detecting anything at all.
Step 15: answer in the language of the page they are reading
An assistant that follows the page language, draws from one maintained answer source, carries the market specific facts and hands over honestly turns three translated language versions into three markets that can actually be served. The installation detail sits in how to add a chatbot to wordpress, connect through integrations, see features, start at try, and the sector view sits under small business.