Why language coverage matters more than it seems
A Shopify store selling into France, Germany, or Switzerland gets support email in the customer's own language, not necessarily the merchant's. A support process, human or automated, that only recognizes English questions simply does not see the rest of the inbox as WISMO at all, which either means a slower manual triage step or, worse, silently missed tickets.
This is easy to underweight because it is invisible in metrics kept only in English: a French WISMO email that is not recognized as one does not show up as a failure, it just looks like other traffic.
The risk of English-only support automation
Automation built around English keywords and phrasing will either ignore non-English WISMO emails entirely, which is safe but ineffective, or, worse, misclassify them and answer with the wrong reply language, which reads as careless to a customer who took the time to write in their own language.
Merchants selling cross-border should treat language coverage as a checklist item during vendor evaluation, not an afterthought — the practical question is which languages are covered today, not which are on a future roadmap.
How language detection works for support email
Reliable detection needs to work on short, informal text — real customer emails, not clean sentences — since a casual message about a missing package is a perfectly normal WISMO message in any language that a rigid keyword list built around formal phrasing would miss. Detection also has to work per-message, since a merchant with international customers gets a mix of languages in the same inbox, sometimes within the same day.
The safest approach checks both subject and body for order-support language in each supported language, rather than trying to detect the language first and then apply language-specific rules — that two-step approach adds a failure point if the language guess itself is wrong.
Templating replies per language, not translating on the fly
Real-time machine translation of a generated reply introduces exactly the kind of unverifiable text that order support should avoid — a translation error in a tracking number or date is just as damaging as a fabricated one. Pre-written, native-language templates for each reply type — shipped, delayed, not-yet-fulfilled — avoid this: a native speaker writes and approves the template once, and it is reused correctly every time rather than regenerated and re-risked on every email.
Common WISMO phrasing across languages
Order-status language varies more across languages than a direct translation suggests. English messages cluster around where is, tracking, and when will it arrive. French customers commonly write about a colis, a livraison, or ask for suivi. German customers use Sendung, Lieferung, and ask Wo ist. A detection system needs each language's own vocabulary, not a translated copy of the English one.
Expanding language coverage over time
Adding a new language is not just translation — it means new detection phrasing, new reply templates, and enough real email volume in that language to validate that detection actually works before relying on it. Merchants expanding into a new market should expect a short lag between entering the market and having reliable automated support in that market's language, and should plan manual coverage for that gap.
FAQ
- Does language detection replace the customer's browser or store locale? No — detection runs on the email content itself, since a customer's locale setting does not guarantee the language they will actually write in.
- What happens with a language that is not yet supported? The safest default is to skip the automated reply and route to manual handling, rather than guessing with an unsupported template.
- Does adding a language increase misclassification risk for existing languages? It should not, if each language's detection rules are evaluated independently rather than sharing a single blended ruleset.