Replying in your customer's actual language, dialect included
A business will say it supports three languages, and mean that it has three versions of its website. Customer messaging is a different problem. People do not write to you in clean textbook language — they write the way they speak.
What real messages look like
One customer writes in French. The next writes Darija in Arabic script. The next writes the same Darija in Latin letters with numbers standing in for sounds. A fourth opens in French, gets comfortable, and switches to Darija halfway through a sentence. All four are the same market, and a system that only handles the first is failing three of them.
Matching the script matters as much as the language
Answering Arabic-script Darija in Latin letters is technically the same language and still reads as wrong, like being answered in a different accent than the one you used. It is a small detail customers notice immediately, and one of the clearest ways to tell whether a model genuinely handles a dialect or is approximating it.
Where automated replies usually break
- Defaulting to the business's language rather than the customer's.
- Handling a dialect in one script but not the other.
- Losing the thread when a customer code-switches mid-conversation.
- Translating a product name that should have been left alone.
How to actually check
Take real conversations in the messiest language mix you get and replay them. Read the replies with someone who speaks the dialect natively — not to grade the grammar, but to answer one question: would a customer think a person wrote this?
It is also worth testing more than one model. Language coverage varies far more between models than benchmark scores suggest, and the cheapest model is sometimes the better one for a specific dialect.
whacl matches the customer's language and script automatically, and lets you compare how different models handle your real conversations before you pick one.
