Plan requirement
| Subscription | Any plan |
| Access | Admin |
A case statement lets one trigger send different wording per language or brand. It is useful, and usually the second-best answer.
The syntax
Four parts: the case that opens on a value, a when per branch, an else, and the endcase. The value itself sits inside {% %} without the usual double braces; placeholders inside a branch keep them.
{% case ticket.requester.language %}
{% when 'Italiano' %}
Ciao,
La tua richiesta (#{{ticket.id}}) è stata ricevuta.
{% when 'Nederlands' %}
Hallo,
We hebben je aanvraag (#{{ticket.id}}) ontvangen.
{% else %}
Hello,
Your request (#{{ticket.id}}) has been received.
{% endcase %}The two values you switch on
ticket.requester.language |
The language name written in that language: Italiano, Nederlands, Deutsch |
ticket.brand.name |
The brand name exactly as it is spelled in Brand management |
The value is the language in its own language
This is what catches people out. ticket.requester.language holds Italiano, not Italian, and Nederlands, not Dutch. A branch written with the English name never matches, the customer silently falls through to the else, and everything looks like it is working.
Check the value on a real user before you write the branch, rather than after somebody reports the wrong language.
Always write the else
Without it, a customer whose language you did not anticipate receives nothing where the text should be. With it, they get your main language, which is imperfect and infinitely better than a blank message.
The same thing per brand
For brands the value is ticket.brand.name, and the placeholder works inside the branches too, so the else can name the brand rather than guessing.
{% case ticket.brand.name %}
{% when 'Noord' %}
Met vriendelijke groet, team Noord
{% else %}
Met vriendelijke groet, {{ticket.brand.name}}
{% endcase %}For languages, prefer dynamic content
Liquid works, and Zendesk recommends it for simple messages in a few languages. Beyond that, 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 drift apart. 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. Test each branch with a real ticket before you rely on any of it.
Comments
0 comments
Article is closed for comments.