Multilingual Moderation: Why Translating Is Not Enough to Detect Toxicity

Every growing platform eventually gets the same request from the engineering team: "Can we just translate user messages to English first, run the moderation model, and translate back if needed?" It sounds efficient. It is also a great way to build a moderation system that misses exactly the things you need to catch.

What translation strips out

Machine translation optimizes for meaning preservation. Moderation needs signal preservation, and those are not the same goal.

• Slang and slurs. A slur in Catalan may translate to the literal English word ("donkey", "goat") and lose the offensive weight entirely. The model then sees innocent text.
• Register and tone. Sarcasm, threats, and escalation often depend on verb forms, diminutives, and particles that translation flattens.
• Intentional obfuscation. Users evade filters with character swaps, spacing, and mixed scripts. Translation "cleans up" the obfuscation on the way to English, and the flag goes with it.
• Context-specific harm. Threats that encode local political or ethnic context routinely translate to generic statements.

We ran a small internal benchmark on 12,000 labeled Spanish harassment messages. A well-known English-only model behind Google Translate dropped from 0.89 F1 (on English data) to 0.62 F1 after translation. A native Spanish model trained on in-language data hit 0.87 F1 on the same test set.

Why native models win

Native-language moderation models are trained on labeled data in that language, with annotators who are native speakers. This lets them learn:

1. In-language norms. What counts as "polite disagreement" vs. "insult" varies. Brazilian Portuguese and European Portuguese disagree. So do Mexican and Argentinian Spanish.
2. Morphology. Languages like Finnish, Turkish or Russian pack a lot of meaning into word endings. Tokenizers trained on English throw half of it away.
3. Script and orthography. Arabic, Thai, and Chinese have no spaces in the same way Romance languages do. Obfuscation patterns are different.

The "language dispatch" pattern

The pattern we recommend, and the one ToxicFilter uses internally, is:

1. Detect language first. Cheap, fast (sub-millisecond with modern detectors).
2. Route to a language-specific model. Different model weights for the top N languages you serve. Fallback to a multilingual model for the long tail.
3. Keep a multilingual safety net. For code-switched content (Spanglish, Hinglish) and languages with too little training data, a multilingual model handles the last 5% to 10% of traffic.

This dispatches the expensive inference only where it is justified, and keeps latency low because each specialized model can be much smaller than a "one model to rule them all" megamodel.

Cultural context is not language

Even with native-language models, you are not done. Tonto is a mild word for "silly" in Spain but a harsher insult in parts of Latin America. Chunga is a casual adjective in peninsular Spanish, but can be taken literally elsewhere. Regional dialects matter.

We cover this in detail in our post on the cultural context problem, but the short version: language detection is not enough. You also want region- or dialect-aware scoring when it matters.

What to ask a vendor

If you are evaluating moderation APIs for a multilingual product, the checklist is:

• Which languages have native models (not translated pipelines)?
• What is the F1 score on in-language test sets, not translated ones?
• How do they handle code-switching and mixed scripts?
• Is there a region parameter, or is it one model per language worldwide?
• How is data from minority languages sourced and labeled (this is where biases hide)?

If a vendor cannot answer these, they are probably using translation under the hood. Which is fine for some use cases, just not for moderation.