Braze multi-language messages let a campaign or Canvas deliver different copy to recipients according to configured locales, but the workflow introduces risks that are easy to miss in ordinary translation review. A beautifully written German email can remain invisible because its text was never marked for translation, a French push can receive English fallback, or a campaign can pull a promotion from the wrong catalog. The practical Braze localization QA job is to validate what each intended recipient actually receives before and after a send, not merely what appears in the message editor.
Searches for Braze multilingual campaigns, Braze translation tags, Braze multi-language composition, Braze locales in messages, Braze Liquid translation, and Braze localized catalogs point to a concrete workflow: define recipient language, mark translatable message content, maintain approved variants, preview with realistic profiles, then verify that rendering, personalization and navigation preserve the intended action. This guide owns those Braze-specific composition and release controls. General email or SMS translation, channel-length principles and glossary theory belong to other guides.
Begin with one real campaign purpose, one controlled test profile per supported locale, a missing-language profile and a profile whose preferred locale has only partial content. Identify the message type, base-language copy, translation-tag IDs, localized variants and any catalog lookups. Preview the exact rendered message for each profile before reviewing typography or tone. Without this evidence, the team may spend hours improving text that the delivery configuration never selects.
Quick answer: keep audience, translation and data separate
Braze localization has three different sources of truth. Recipient locale determines which language should be chosen. Message composition contains the approved free-form copy and translation blocks. Data or catalog content supplies personalized items, values, images or URLs. A message can fail even when two of these are correct: the user may have the right locale and approved text, but a catalog field may be blank; or a populated catalog may be paired with an English-only button outside the translation block.
Use one test case to prove each boundary. Preview a simple text-only message with no personalization; preview the same message with a valid catalog row; then preview a row missing one translated field. Record which fallback is intentional. In multi-language composition, test the platform’s configured locale selection as it applies to the real profile, not a made-up language label in a spreadsheet. A message is ready only when the selected locale, final words and user action agree.
For free-form campaign copy in supported channels, Braze documentation recommends multi-language messages rather than treating product catalogs as a universal translation database. Catalogs remain useful for structured localized product information and asset URLs. Choose the appropriate owner so a seasonal campaign editor does not accidentally maintain permanent product terminology in copied campaign text.
1. Define one message job before translating
A marketing campaign should have a single user-facing purpose: announce a new course, explain a membership benefit, confirm an appointment or invite a student to an event. Translation becomes unreliable when the source combines several competing actions and the team permits each locale to emphasize a different one. Before opening Braze, write a two-sentence brief stating what happened and what the recipient can do next. Then identify which parts can legitimately vary by market.
Consider a class-registration reminder: “Your place is reserved until Friday. Confirm to keep it.” Its truth depends on an actual reservation status and deadline. A French version must not imply the place is permanently confirmed, while a Japanese version must not turn “confirm” into “apply again.” Mark the reservation fact and action as invariant. Tone, sentence order and politeness may change naturally.
This simple brief also prevents uncontrolled expansion. A translator might otherwise add a discount that appears in a catalog for one region but is unavailable in another. Brand voice is adaptable; eligibility and promised benefits are not. The product or campaign owner must approve the source claim before any locale-specific copy is considered final.
2. Configure the supported locale set explicitly
Braze locale configuration is not the same thing as a list of languages someone wants someday. A locale should map to an actual recipient attribute or configured selection rule, an approved message variant and a tested fallback. A campaign can be fluent in English, French and German while silently reaching users with fr_CA, de_AT or a blank language attribute through a different route. Build the list of supported inputs before importing translated strings.
Record the exact locale keys and user-attribute values used in the workspace. Language-only and language-region tags need a documented normalization decision. Do not assume device language equals the user’s preferred communication language; the attribute may be derived from SDK data, account preferences or custom profile logic, depending on the implementation. For users living in multilingual markets, regional location is not a substitute for their chosen language.
Test three kinds of profiles: one matching a supported locale exactly, one matching a related but not identically coded locale, and one with no reliable language data. The fallback behavior must be deliberately chosen and communicated to the reviewer. A missing locale should not cause a silent blank message, and it should never be guessed from an unrelated personal attribute when the organization has not authorized that inference.
3. Use translation tags as content boundaries
Braze multi-language composition uses Liquid translation blocks to mark text that can have localized versions. An example of the documented pattern is {% translation greeting %}Hello!{% endtranslation %}. The identifier is part of the content contract. If a new heading is outside its intended translation tag, a translation connector may fail to extract it, leaving that heading in the base language even when every returned target segment is approved.
Choose meaningful identifiers such as registration_subject, registration_intro and confirm_button rather than arbitrary strings that become impossible to audit. The IDs must remain distinct in their relevant message context. A translation block should contain a coherent unit of language; splitting every individual word into a tag can make word order impossible to adapt. Conversely, placing an entire complex template in one unreviewable block may complicate variable protection and review. Match boundaries to grammatical and editorial ownership.
Inspect the source in the actual editor after adding tags. Some editing surfaces provide helpers for translation blocks, while rich editors and templates can behave differently. Verify that the opening and closing syntax survives saving and that the correct IDs are visible to the translation workflow. The presence of a French spreadsheet column proves little if the source message has no extractable translation boundary.
4. Treat translation IDs like stable message identities
A translation-tag ID tells the workflow which source unit and target variants belong together. Reusing an ID for a different meaning, renaming it casually or duplicating it within the message can create confusing imports and stale data. An editor might change “Register for the workshop” to “Confirm the workshop booking” and leave the same ID, which may be reasonable if it represents one continuing button role. But changing the tag’s purpose from confirmation to cancellation is a semantic change that needs a deliberate review and perhaps a new identity.
Keep the source copy revision paired with the translation ID. Translators should be told when source meaning changes, not merely when source text differs by punctuation. A seemingly small edit from “May attend” to “Must attend” should reopen every target language. A formatting-only change may require less review, but that conclusion must be intentional.
Build a simple extraction test: make one controlled source change, sync it to the translation workflow and verify that the expected unit is marked for re-review. Then restore or finalize the content. This catches integrations that retain older target states while treating the new source as already approved.
5. Keep Liquid logic separate from target prose
Liquid can insert personalization, select catalog values and make conditional choices. Translators should understand the user-visible result without accidentally changing executable syntax. Supply a sample rendered message for every important branch, document which variables may move within the sentence and explain when a variable represents a person, amount, code or date. Do not ask translators to preserve English word order merely to keep a placeholder in its original position.
If the message says “Alex, your booking for Tuesday is confirmed,” the variables for name and event time remain attached to their data types. A target language may place “Alex” elsewhere or change grammatical cases. The template should support natural complete sentences and use the correct formatting for locale data. In a channel where only fragments are independently translated, concatenation can create an ungrammatical target even while each fragment looks acceptable alone.
Test blank or missing personalization. A message that prints a raw variable or an awkward comma before an empty first name is not release-ready. The fix may involve an explicit conditional variant or an approved neutral greeting. Do not fabricate a name or fallback address in target text to conceal missing recipient data.
6. Separate free-form messages from structured catalogs
Braze catalogs are useful when a campaign needs localized product names, promotion details, image URLs or other repeatable structured data. Official guidance describes several patterns, including locale-specific fields within one item and per-language catalogs. It also cautions that free-form email or push copy is often better handled through multi-language message composition when supported. The distinction reduces duplicated translations: product data can be updated once while campaign-specific persuasion remains with its message.
A catalog item may contain stable product ID course-103, approved display names in several languages and locale-specific destination links. The message template can use that record while expressing an invitation in the reader’s preferred language. Do not copy a course fee or course availability into every translation block. A fee is a data fact; its presentation is localized, but its validity must come from the appropriate business system.
When choosing a catalog structure, consider who maintains it, how missing fields are represented and what happens when a new language is added. A single row with many locale fields is convenient for a limited set of languages but can become unwieldy. One catalog per language isolates content ownership but requires careful allowlisting of dynamically constructed catalog names. The right pattern is the one the team can validate and maintain safely.
7. Normalize language keys before dynamic catalog access
Dynamic catalog lookups often build a field or catalog name from the recipient’s language attribute. A data row might have header_en and header_fr, while the profile reports FR, fr-FR or a missing value. Unless the Liquid implementation normalizes and constrains those values deliberately, the lookup can return an empty string or refer to a resource that does not exist.
Braze’s localized-catalog example emphasizes checking locale formatting and using approved fallback values. In one described pattern, an absent catalog can abort the message, which is materially different from one missing field returning blank content. Test those states separately. An unexpectedly absent campaign message is a delivery incident, while an empty button label can be a comprehension incident. Both are serious, but their root causes and signals differ.
Maintain an allowlist of supported locale codes before building names from profile attributes. Then test a malicious-looking or malformed input as a defensive case, even if the system usually controls the values. User profiles can be imported from several systems over time. Treat language metadata as typed data with a validation rule, not an arbitrary string to concatenate into resource names.
8. Design fallback field by field where appropriate
A catalog row may have a French product title but no French image alt text. A blanket rule that says “French record exists, therefore every field is complete” can produce a partially blank message. Braze documentation illustrates field-level fallback for catalog values such as names and prices. In a structured catalog, checking each required field independently can be safer than switching the whole campaign to English as soon as one value is absent.
But a mixed-language sentence can also be damaging. A French heading with an English legal limitation may imply that the offer has fully supported French terms when it does not. Define which fields permit fallback and which require a complete locale package before sending. In a critical confirmation, an essential instruction missing in target language may justify suppressing the campaign for that profile until content is approved.
Test a partially translated row intentionally. Confirm the rendered subject, header, paragraph, CTA, image, alternative text and destination. The reviewer should know which fallback is visible and why. Avoid silently treating fallback as a completed translation; report it separately so coverage metrics remain truthful.
9. Verify every channel surface, not just the main paragraph
A multilingual email consists of subject, preheader, body, CTA, image text, footer and possibly preferences or unsubscribe messaging. A push notification has title, body and navigation target. An in-app message may include buttons and a close control. Translating one visible paragraph is not the same as translating the communication object. Build a surface map for the specific Braze channel and mark which text belongs to message variants, shared templates, catalogs or client-side localization.
Do not invent a universal set of supported localization controls across all Braze channels and editor types. Features and composition interfaces can vary; confirm the documented capabilities available in the workspace before writing operational instructions. The QA principle is stable: every recipient-visible string needs an owner and every action must be tested in the channel that will actually deliver it.
A footer may be legally required but maintained through a global template rather than the campaign. If campaign editors cannot translate it, route the request to its owner instead of pasting a duplicate footer inside the body. Duplication can produce two unsubscribe links, inconsistent terminology or conflicting regulatory claims.
10. Preserve the source action in translated calls to action
Calls to action are short and easy to distort. “View details,” “Reserve a place,” “Join the waitlist” and “Complete payment” are different actions. A target phrase that sounds enthusiastic but moves the user into another workflow is not an acceptable localization. Define what clicking the button does and what commitment, if any, that click creates. Translators need that context more than they need an arbitrary maximum character count.
A campaign about school consultations illustrates the difference. If the actual page requests an enquiry, the button should not promise an instant confirmed appointment. If seats are scarce, avoid adding “guaranteed” in one language while other versions correctly say availability will be checked. A linguist can write a natural CTA only when the page’s action and user journey are clear.
Inspect the rendered button and test the destination with an appropriate language profile. A French CTA leading to an English registration form may be a routing error, a missing target page or an intentional fallback; the campaign owner must know which. The success criterion is a coherent action across message and destination, not just a correct isolated button label.
11. Keep locale targeting and audience eligibility distinct
A campaign may target parents in a specific programme, customers with an active membership or users who have consented to marketing. Locale is one dimension of that eligibility, not a replacement for it. A user can speak French and still be ineligible for a French-market promotion. Conversely, a customer in France may have chosen to receive English messages. Keep business eligibility and communication language as separate rules with explicit precedence.
Build a matrix containing consent or subscription status, campaign eligibility and language selection. The QA fixtures should include someone who matches language but is excluded by business policy, and someone who is eligible but needs a different language. Verify that the translated version does not accidentally broaden the target population. Segment definitions are not prose and should never be edited as though they were translation strings.
If the campaign is international, check currencies, shipping regions, dates and legal conditions. A translated message can be linguistically accurate and commercially false when shown to the wrong audience. The send decision belongs to campaign governance; translation QA provides evidence that the recipient will understand the selected message if the send is authorized.
12. Preview as user with intentional test profiles
Braze guidance for localized catalogs recommends using Preview as User with profiles containing different language values and checking fallback. Use that idea systematically for multi-language messages: construct safe test profiles with known attributes rather than previewing only the marketer’s own account. Each profile should have a clear expected locale, personalization and catalog row. Capture the rendered result that a human recipient would receive.
A preview of raw Liquid syntax or a static editor field is not enough. The final string may differ after content blocks, personalization and conditional logic resolve. Test one ordinary profile, one with a long name, one with a missing optional field, one regional language variant and one unsupported language. If a message depends on time or an event state, set representative values deliberately rather than relying on whichever sample data happens to be present.
Record a test result with the profile’s synthetic identifier, active variant, expected meaning and observed message. A team can then reproduce the result after source edits or a connector sync. This makes multilingual campaigns reviewable by people who did not create the original translation project.
13. Know when a preview is not enough
A preview demonstrates rendering under one simulated context. It does not prove that the campaign’s actual audience filters, frequency caps, scheduled delivery or Canvas branches will select the intended recipients in production. For complex journeys, QA must also consider how a person enters the journey, which step they reach and whether the message remains appropriate at that point. A sentence correct for an abandoned-cart reminder may be wrong after the purchase is completed.
Test the triggering event and its state transitions with authorized test users. Verify that the message scheduled for a particular step remains tied to the correct source claim. A language variant can be perfectly translated yet be sent after the condition that made it true has expired. This is a campaign logic problem, not a request for more polite language.
Before launch, compare the planned audience and action to the test profiles. After launch, review safe delivery and error signals without exposing real customer data unnecessarily. A successful preview should be treated as one layer of evidence, not as an all-purpose delivery guarantee.
14. Translate dynamic deadlines and values from authoritative data
A multilingual promotion often includes “Ends on Friday,” “Save 20%” or “Only 10 places left.” Those are business facts. If translators manually rewrite each locale’s number or deadline, the copies can diverge. Pass typed values from an authoritative source when the workflow supports it, and localize display using the intended audience context. Where a static claim is unavoidable, tie every locale variant to one approved campaign specification.
Dates deserve particular care. A campaign sent across time zones may expire at one global instant but display a local calendar date for each recipient. “Friday” can be wrong for some regions even if the original English message was true where it was drafted. Decide whether to include time zone, region or an absolute date, and verify rendered examples near the boundary. Currency symbols likewise need a market decision, not a translator’s assumption.
A good reviewer compares the rendered target sentence with the authoritative event, price and deadline. If the message says a discount applies to all products but the catalog excludes some categories, the problem is factual regardless of language. Translation quality includes preserving the eligibility conditions that make the message true.
15. Keep localized links and assets under control
A localized message may need a language-specific landing page, image, video or downloadable guide. Braze catalogs can hold URLs or image references alongside localized strings, but a valid URL does not prove it resolves to the appropriate audience experience. Confirm the destination’s locale, content version, availability and privacy behavior. Never create target URLs by translating opaque path segments unless the website actually publishes those routes.
For image assets, distinguish decorative photography from images containing words or culturally specific claims. If an English image embeds the message “Register by 5 PM,” a correct French text block can still be contradicted by the image. Either replace the asset with an approved localized version or redesign it so the important information is real text outside the image. Test alt text or accessible names independently.
At least one QA case should open the CTA from an actual sent test message, not only the editor. Email-client tracking and redirect behavior can differ from a preview. Verify the target page on mobile and desktop where relevant and confirm that the user does not lose the chosen language after authentication or a redirect.
16. Consider message length and layout without deleting meaning
A German button may require more space than an English one. A French subject may wrap differently on mobile. Japanese, Arabic and Hindi scripts have different rendering needs. The correct response is to inspect the actual email client, push preview or in-app component, then adapt layout or wording while preserving the essential action. Do not impose one English character count as a universal linguistic rule.
Separate hard technical limits from visual preferences. An SMS segment count has a real encoding and delivery-cost dimension; an email subject preview is a design and scanning constraint. A shorter translation can be better when it remains clear, but the decision should be informed by the channel and native usage. Avoid abbreviations that make a safety or payment instruction ambiguous merely to fit a dashboard metric.
Test representative clients and text sizes rather than assuming the campaign designer’s desktop preview is definitive. Include a long product name from the catalog and a recipient name with non-Latin characters. These dynamic inputs often create layout failures that are invisible in a tidy static example.
17. Ensure fallback never hides missing coverage
A campaign with twenty locales may report that all variants exist, yet five contain English source text copied as temporary placeholders. A completion metric based only on non-empty fields would call those locales complete. Add a linguistic coverage check that distinguishes approved target-language content from identical-source words that are intentionally preserved, such as brand names or product codes.
Source–target identity checks require judgment. A short term may legitimately be the same in French and English. An entire paragraph that matches the source exactly deserves review unless the project is a same-language adaptation. Track the actual translation approval state and source revision rather than inferring quality from whether a cell has text.
When coverage is incomplete, choose a truthful launch policy: restrict the campaign to approved locales, use a documented fallback, or delay launch. Do not silently claim that every recipient has a fully localized experience while exposing mixed-language messages under one language label.
18. Prevent connector imports from changing unrelated copy
Translation connectors can accelerate work by extracting Braze message content, creating target variants and returning approved strings. The integration’s extraction boundaries, source ownership and available permissions still need testing. A documented Lokalise integration, for example, expects appropriate Braze multi-language support and translation tags; without them, content may not appear for translation. A successful connection does not mean every message was extracted.
Before the first large sync, create a no-change round-trip fixture. Export a small message with a heading, body, placeholder, button and one catalog reference; reimport it unchanged; then compare the rendered base and target variants. Look for altered Liquid, missing text blocks, unexpected HTML changes and changes to the base language. This is more informative than processing a thousand strings before discovering the connector’s assumptions.
After a source edit, confirm that target translations tied to outdated meaning are reopened for review. Avoid letting a sync job silently republish an older approved target over a newer manual correction. Establish which system is authoritative for each field and how conflicts are resolved.
19. Manage version changes across a Canvas journey
A Canvas can contain messages at different steps, reached days apart. A campaign launch with revised copy on Monday does not guarantee that everyone already inside the journey experiences the same sequence of wording. A user may have received an older English introduction and later receive a newer French reminder after changing their language preference. Decide whether that cross-version experience is acceptable for the journey’s purpose.
Use stable event identities and terminology across steps. If the programme renamed “introductory session” to “consultation,” update dependent content deliberately so a recipient is not asked to confirm something they were never told about. Where legal or price claims changed, the campaign owner may need more than a translation update; the underlying journey conditions and timing may require review.
Test profiles entering at different stages and under different locale settings. A step-specific preview cannot show the entire narrative continuity. The reader’s journey is the final communication unit, even if the platform stores it as multiple messages.
20. Use post-launch checks to detect wrong-language delivery
After launch, look for controlled signals that indicate a problem: unexpected fallback frequency, high abort rates from missing catalog resources, unusual clicks from language-mismatched profiles, or complaints that a message arrived in the wrong language. The exact telemetry available depends on the Braze implementation and its privacy design. The aim is to investigate targeted failures, not collect more personal information than needed.
Review the live and draft translation state when the platform exposes version distinctions. Braze’s translation API documentation includes retrieval of campaign translations and a parameter to request post-launch draft versions in relevant endpoints, with feature availability and permissions varying. Confirm the account’s current capabilities rather than assuming an early-access endpoint is universally enabled.
A correction to a live message may need its own test and publish boundary. Do not conflate “updated draft translation” with “updated language received by everyone.” Record the test message, active version and changed IDs so the team can say exactly which recipients or future sends are affected.
21. Worked example: the French subject is still English
A campaign body has French translation blocks and renders naturally in Preview as User, but its email subject remains English. The team asks the translator to create another version of the main paragraph. That cannot fix a subject outside the extraction scope. Inspect how the subject field is localized in the actual composition workflow and whether it was marked and approved through the appropriate supported mechanism.
The repair is to add the subject to the locale review surface, import or enter its approved target version, and test the final delivered test email including subject, preheader and body. The critical lesson is that channel metadata can be user-visible language. A complete localized campaign includes the text surrounding the message body.
22. Worked example: a catalog lookup aborts a German message
A multilingual promotion builds a catalog name dynamically from ${language}. The workspace has promo-en and promo-fr, but a German user’s profile resolves to de, yielding a catalog that does not exist. The sending mechanism aborts the message. Adding a German translation in a separate spreadsheet does not create the missing catalog or change the dynamic lookup.
Apply a supported-locale allowlist before constructing the catalog name, define a safe default and test what happens when the catalog exists but an item is missing. Those are two different fallback cases. Braze’s localized catalog documentation explicitly distinguishes absent catalogs from absent item data. Once the message renders, review its language and destination rather than treating delivery success alone as quality.
23. Worked example: one language receives the wrong discount
An English campaign advertises a 15% price reduction while a French variant says 20%. Both are fluent. The campaign owner discovers that a translator copied the discount from an old French promotion rather than the current event specification. This is a content-truth error with potential commercial consequences, not a grammar issue. The value should be checked against the authoritative offer and the correct market.
Move variable campaign facts into structured data when feasible, or enforce a shared source specification with review for every locale. Compare actual test sends across languages and check the landing page’s offer. If the promotion genuinely differs by market, the business rule must state that difference explicitly; it should not emerge accidentally from translation history.
24. Worked example: an old English string reappears after sync
An editor corrects a Japanese headline directly in Braze. A localization connector later runs and restores an older target from its translation memory because the project has no clear conflict owner. The team sees the regression only after launch. Everyone believed they were editing the authoritative version, but the pipeline had two writers with different states.
Decide whether Braze or the translation platform owns the approved target. Tie approvals to source revisions and reconcile manual hotfixes back into the source of truth. Test a changed target round trip before enabling automated publication. The winning version should be predictable, reviewable and demonstrably the one the recipient receives.
25. Worked example: French CTA opens English registration
A French-language consultation invitation says “Réserver une consultation,” but the CTA uses a catalog URL field populated only for English. The email looks fully localized until the user clicks. The destination is an English form; its date selector and confirmation copy do not match the message. The translation was not wrong; the localized experience ended at the link.
Add or resolve the correct destination for the supported locale, then test the entire journey through submission with a safe test account. If the French form does not exist, use a declared fallback message rather than implying a language experience the product cannot deliver. CTA QA owns the action beyond the first tap.
26. Worked example: a short translation changes the commitment
A mobile push needs to fit a small preview. The English message says “Confirm your place by Friday,” while the translated short version says “Your place is confirmed.” The shortening removes the required user action and changes status. A layout pass would call the line elegant; an intent review must reject it.
Ask what minimum information the user must know in the notification: status, action and deadline. Shorten secondary framing, not the event truth. Then check the target screen, where complete detail can be shown. Brevity is valuable only when it preserves the instruction the channel exists to deliver.
27. Worked example: the regional language mapping is inconsistent
One ingestion process stores fr_CA, a second stores fr-CA, and the campaign locale configuration expects another form. Some French-speaking users receive French while others fall back to English. A translation editor sees the same correct French wording in every test, so the issue appears random until someone compares raw profile attributes.
Create a normalization policy at profile ingestion or in the approved selection layer. Test supported region variants and unsupported values rather than assuming case and punctuation will always be normalized for you. Keep user preference separate from geographic eligibility, then preview all mapped cases with synthetic profiles.
28. Worked example: a catalogue image contradicts translated terms
An education campaign promoting a new Mathematics class uses a French email headline but an English graphic stating a different age level. The campaign body and link are correct; the image asset came from the source catalog entry. The user receives conflicting information about which students the class serves. The fix is not to rewrite the email until it matches the wrong image.
Verify the approved class eligibility, then supply a localized asset or remove embedded words from the graphic. Include accessible alternative text and a final image preview in the locale checklist. Images carrying facts are communication content, not mere decoration.
29. Worked example: two Canvas steps call the same action different things
A two-week onboarding Canvas begins with a “Welcome session” email and later sends a “Consultation reminder.” A source copy revision renamed the event, but only the later step’s translation was updated. The customer wonders whether they registered for one meeting or two. Neither sentence is ungrammatical; the multi-step narrative is inconsistent.
Map the event’s stable concept across all message steps and locales. Review linked terms, dates and destinations side by side, including what an existing journey participant may already have received. A stable glossary helps, but the decisive evidence is continuity of the real event through the user’s communication sequence.
30. A compact multilingual Braze release gate
Before launch, confirm that every supported locale is configured intentionally, recipient attributes map to those locales, translatable message surfaces are marked, translation-tag IDs are stable, personalization renders safely, catalogs have controlled fallback, destinations exist, eligibility rules match the offer, and every locale has appropriate review. Test unsupported and missing-language profiles; do not define success only as “all translated cells are non-empty.”
Send actual test messages for the highest-risk channels. Inspect email subjects and footers, notification previews, dynamic values, images and links. For Canvas journeys, verify the action and wording at relevant steps. Preserve a record of the source revision, target approval, message version, selected test profiles and sign-off. That record makes later edits safer and faster.
After launch, keep watch for specific failure patterns rather than chasing every fluctuation in campaign performance. Wrong-language rendering, missing catalog data, aborted sends and link failures are actionable localization incidents. Investigate them at the correct layer and correct the smallest safe configuration set.
31. Transfer exercise: localize one consultation campaign across three channels
Imagine an education centre inviting parents to book a Mathematics consultation. The campaign sends email first, an in-app reminder two days later and a push on the final booking day. English, Malay and Simplified Chinese are supported; other users receive an approved English fallback. Create the stable event brief: a consultation request, not an instant confirmed appointment, and one deadline for a particular offer. Define the source-language terms and approved locale outputs.
Now design the Braze message boundaries. Each channel needs its own complete translatable message, while the destination and event facts should be shared. Add one synthetic parent profile for each language, one missing-language profile, one unavailable-consultation profile and one with a long surname. Preview every relevant step and click each action. If a profile can reach a fully booked event, decide what the message should truthfully say rather than letting translation hide the availability problem.
The transfer principle is that a campaign’s language is not stored in one place. The user experiences an assembled object: recipient selection, message variant, content data, timing, media and destination. Test the assembled object with the same rigor used for the sentence itself.
32. Summary: speed follows trustworthy language boundaries
Braze makes multilingual campaigns practical when teams keep content selection, translation blocks, personalization data and delivery governance in separate but connected layers. Correct translation IDs prevent extraction gaps; controlled locales prevent wrong-language delivery; catalog fallbacks prevent blank fields; and realistic previews reveal the message the user will actually read. A launch gate then makes sure the text describes a true offer and sends the reader toward the promised action.
This article deliberately stops at Braze multi-language composition and QA. Detailed SMS encoding, general grammar rules, translation memory maintenance and website localization have their own owners. The objective here is not to produce more words about translation, but to make one campaign’s approved language reliably reach the right audience with the right meaning.
Frequently asked questions
What are Braze translation tags?
They are Liquid translation boundaries used in supported multi-language message workflows, for example {% translation greeting %}Hello!{% endtranslation %}. Each block needs a suitable identifier and must be verified in the actual editing and extraction workflow.
Should I keep every translated product name in campaign copy?
Not usually. Structured reusable values such as product names and localized links may belong in catalogs, while free-form channel messages belong in multi-language composition when supported. Test how those layers combine.
Why is one localized message empty?
Check recipient locale mapping, supported variants, extraction tags, missing catalog fields, fallback conditions and rendered personalization. An empty field and an aborted message can have different causes.
Can a translation connector publish everything automatically?
Integrations differ in capabilities. Verify what they extract, which locale variants they can update, how they handle source revisions and whether they modify live or draft content. Keep an approval boundary before an important send.
Is a Preview as User result sufficient to launch?
No. It proves rendering under one profile. Also verify audience eligibility, campaign or Canvas path, timing, supported channels, fallback and click destinations.
How do I prevent English text from appearing in French messages?
Map all user-visible fields, keep proper translation boundaries, confirm selected locale, test a French profile and deliberately test missing data. Some fields may be managed outside the central campaign body.
References and further reading
- Braze: Manage localized content with catalogs — official guide to locale-key patterns, fallback, catalog selection and preview.
- Braze: Translation endpoints — API availability and translation-management capabilities; documentation noted early-access limitations in October 2026.
- Braze: Campaign translation retrieval — locale and post-launch draft distinctions where supported.
- Lokalise: Braze integration — example integration requirements for multi-language support and translation tags.
- eduKateSG: How People Translate Quickly series index — related localization QA owners.