Quick answer: You have two ways to run multilingual campaigns. Translation ops renders one campaign body at send time and hopes the right language lands on the right handset. Language ops stores a language preference on each contact and resolves the template variant written for that language — so the CSAT question, the promotional offer, and the delivery update all arrive in the language the customer actually reads. On Devotel Orbit, the contact record carries a language field, every template carries a language value per variant, and surveys in the Customer Experience (CXaaS) pillar already ask the CSAT or NPS question in each customer's language — this post is about wiring the same per-contact decision into your campaign templates.
Why language ops beats translation ops
Translation ops treats language as a rendering step: write one body, run it through a translator at blast time, send. Three failures follow. First, the translation pipeline has no memory — a customer who wrote to you in Portuguese gets the same Spanish blast as everyone in the segment, because nothing on their record says otherwise. Second, machine-rendered copy drifts off voice: your brand's German tone is a decision, not a translation-model default, and blast-time translation makes that decision anonymously, per send, with no review. Third, nothing is recorded about which language was rendered, so post-campaign analytics cannot answer the one question that matters — did the right variant reach the right contact.
Language ops inverts that: the preference lives on the contact, variants are authored and reviewed per language ahead of the campaign, and resolution picks deterministically at send time. Blast-time translation has one legitimate use — a brand-new contact with no preference on file, where a fallback guess beats skipping the send. Everything beyond that first touch should be deciding which variant a human approved.
The economics differ per contact, not per blast. A European B2C list skews toward GSM-7-friendly Latin scripts (French, German, Spanish, Portuguese) where the budget is 160 characters per segment; an APAC list concentrated in CJK or Arabic is UCS-2 by construction, capped at 70. Translation ops has no way to price that difference per recipient; language ops prices it at the contact level because the preference field tells you which script the body will actually render in before the campaign goes out.
Segment-by-language economics — GSM-7 vs UCS-2 per variant
Encoding is decided per rendered body, and rendered bodies differ per language variant — so the two encodings bill differently across your variants. The mechanics are covered in depth in the SMS encoding and segment economics explainer; the summary that matters for language ops:
- GSM-7 carries 160 characters per segment (153 in multipart), and holds ASCII, digits, common punctuation, plus a block of national characters — é, è, ß, Ä, Ö, Ü, å, and the Greek capitals.
- UCS-2 carries 70 characters per segment (67 in multipart) and is forced by the first character outside the GSM-7 alphabet — CJK, Arabic, Cyrillic, Devanagari, emoji, curly quotes, em dashes.
Per language, this changes your copy budget. Spanish and French variants stay GSM-7 for the price of an é or a ñ that the alphabet already contains. Polish copy like "zażółć" flips to UCS-2 on the Ż; unaccented Polish stays GSM-7 — a brand decision, not an encoding rule. Chinese, Japanese, Arabic, and Russian variants price as UCS-2 from the first character on. Greek variants fit GSM-7 only if the copy survives on the capital-letter block; lowercase η or ς takes the whole body to UCS-2.
So a four-variant campaign (English 180 chars, French 175, Polish 182, Japanese 90) does not cost four identical segment counts. English and French render GSM-7 in 2 segments; Polish may render UCS-2 in 3 (182 ÷ 67, rounded up) if you kept the accents; Japanese renders UCS-2 in 2. Segment the budget per variant, not per campaign, and let the worst case over recipients set the campaign ceiling — the same rule the encoding explainer gives for template variables.
Per-contact preference and variant resolution on Orbit
The pattern the CXaaS pillar ships — "ask the CSAT, NPS, or CES question in each customer's language" — generalizes past surveys, and it rests on three shipped pieces:
- Per-contact preference. Every contact record carries a
languagefield alongside country, timezone, channel preferences, and custom attributes. Set it from an import column, a form answer, or an agent's read of the transcript; once set, it outranks every blast-time guess. - Per-variant language tagging. Messaging templates and content templates each carry a
languagevalue per variant, so resolution is a lookup, not a heuristic. Build the four variants of a body, tag each with its language, and the send path resolves by the contact's preference field. - Variant fallbacks. Author-declared fallback chains let you define what a contact with no preference (or a missing variant) receives — either the organization-level default or an explicit template-level chain. Resolution is deterministic and recorded, which is the difference between language ops and translation ops.
The survey side of this shipped first: CSAT and NPS questions in CXaaS already render per the contact's language and cap how often any customer is asked, and the same preference-or-fallback pattern resolves there. This post extends that idea to campaigns, where variant authoring and segment budgets interact.
Tenant-owned controls — set the preference, build fallbacks, record the rendered language
These controls belong to the tenant; no provider or platform gate is involved:
- Set the preference field. During import, map a column to the contact's language; in a list update, bulk-set it from a segment; in forms or bot flows, ask explicitly and write the answer to the field. The dashboard exposes it on the contact detail panel under channel and attribute preferences.
- Build variants with explicit fallbacks. Each template variant names its language, and the fallback chain on the template (or the org-level default) names what unresolved preferences get. Review per-language copy before the campaign, not after.
- Record which language rendered. Resolution is deterministic at send time, so the rendered variant's language is a logged fact, not an inference. Post-campaign analytics group sends by rendered language — the answer to "did the right variant reach the right contact."
- Keep compliance tenant-owned. Language preference is a contact attribute you control; consent, quiet hours, and opt-out handling apply unchanged per variant. There is no regional or country gate in language resolution — the decision is the contact's preference and nothing else.
FAQ
Should I use machine translation at blast time for contacts with no preference?
Only for the very first touch, and only if the fallback chain says so. After that touch, record the language the contact actually responds in and resolve deterministically from then on.
Does setting a contact's language change what SMS segments cost?
It changes which variant renders, and the variant decides the encoding. Spanish and French variants tend to stay GSM-7 at 160 chars per segment; CJK, Arabic, and Cyrillic variants bill as UCS-2 at 70. The per-segment price is encoding-independent — the segment count per variant is what shifts.
Can a contact have more than one language preference?
The field holds a single preference. Contacts comfortable in two languages resolve to one variant per send, chosen by the current field value. Multilingual regions usually pick the stronger reading language.
Where does the survey-language pattern come from?
It is a shipped Customer Experience platform (CXaaS) capability — CSAT, NPS, and CES surveys ask in each customer's language, and the same preference-plus-fallback pattern resolves which variant renders.
Language preference is one axis of the omnichannel decision — the channel-selection matrix frames the per-contact channel choice the same way this post frames the per-contact language choice. Segment economics build on the SMS encoding explainer, and the contact-level preferences that drive resolution live on the Customer Data Platform pillar, where a contact's attributes and preferences are first-class fields.