Showing text per language or brand with Liquid

A case statement lets one trigger send different wording per language or brand. Useful, and usually the second-best answer.

A case statement lets one trigger send different wording per language or brand. Useful, and usually the second-best answer.

How it is built

1. Edit the trigger's message.
2. Open a case statement on the value you are switching over, such as the requester's language or the ticket's brand.
3. Write a branch per value.
4. Add a default branch. This is not optional.
5. Test each branch with a real ticket.

Always write the default

Without one, a customer whose language you did not anticipate receives nothing where the text should be. With one, they get your main language, which is imperfect and infinitely better than a blank.

For languages, prefer dynamic content

Liquid works, but dynamic content was built for exactly this. The text lives in one place with a version per language, a translator can edit it without touching a trigger, and adding a language does not mean editing every rule.

Use Liquid for language only where the difference is structural rather than a translation, such as a paragraph that should not appear at all in some markets.

For brands, Liquid often wins

Two brands with slightly different wording in one message is easier to keep aligned as one rule with a case statement than as two rules that will diverge. Beyond three or four brands, separate triggers per brand become more readable again.

Keep it shallow

A case statement on one value is readable. Conditions inside branches inside conditions is a program in a text field with no way to test it except by sending mail.

See also

• Creating and using dynamic content
• Business rules for multiple brands
• Liquid markup: what it is and when you need it