How to reply to a support ticket in a language you do not speak

You can answer a ticket in a language you do not speak, and answer it well, provided you treat the translation as part of writing the reply rather than a step bolted on at the end. The method is short. Read the whole thread in your own language. Work out which language and which level of formality the customer is actually using. Draft the answer in the language you think in. Translate it. Then check the four things machine translation reliably gets wrong: the sign-off, names and titles, identifiers, and dates. Fix those by hand, and only then send.

Read the whole thread, not the last message

The temptation with a foreign-language ticket is to translate the newest message, answer that, and move on. It is also where most of the damage happens. The message you can see is often a follow-up, and the thing it is following up on is three messages back, in a paragraph a colleague already answered badly.

Translate everything the customer has written, in order, oldest first. Read your own team’s replies too, because a promise made in English is still a promise. If your helpdesk shows you a translated view of the thread, use it on every ticket rather than only the ones that look difficult. The cost of reading is the same either way.

Work out which language to answer in

Take the language from the customer’s own messages, not from the thread as a whole. A conversation that has six English agent replies and two Portuguese customer messages is a Portuguese conversation. This sounds obvious and is very easy to get wrong once an automated detector looks at the whole thread and reports the majority language.

Two follow-on decisions matter:

• Variant. Portuguese for Portugal and Portuguese for Brazil differ in vocabulary and in how formal address works. Simplified and Traditional Chinese are different scripts. Getting the variant wrong is not fatal, but it reads as carelessness to the person receiving it.
• Whether to switch. If the customer writes to you in English, answer in English, even if you know their first language. People choose the language they want to be answered in, and overriding that choice is presumptuous.

Decide the register before you translate

Most languages that matter here encode formality in the grammar, and a translator will pick one for you if you do not. German has du and Sie. French has tu and vous. Spanish has tú and usted. Japanese has a whole system of politeness levels that changes verb endings. English flattens all of this, so an English draft carries no signal about which form the translation should use.

The rule that works: mirror the customer. If they opened with a formal salutation, stay formal for the whole conversation. If they have been informal across several messages, follow them down, but do not lead. Write the choice into the ticket or your team glossary so the next person to touch the conversation does not reset it.

The four things to check in a translated reply

Sign-offs. These are the most exposed part of the message, because they sit alone with almost no surrounding context to disambiguate them. “Cheers” is a drinking toast as well as a farewell. “Best” is a superlative. “Regards” is an ordinary noun. Handed to a translator as a bare fragment, any of them can come back rendered by dictionary sense instead of function. Do not translate sign-offs at all. Use the target language’s standard formula: Mit freundlichen Grüßen in German, Cordialement in French, Atenciosamente in Brazilian Portuguese, よろしくお願いいたします in Japanese.

Names and titles. Each element of a signature block needs its own decision. A person’s name stays as it is, though in a language with a different script you may want to add a transliteration so the customer can pronounce it. A registered company name stays as registered, because it is a legal identifier. A team name like “Customer Success” is a description rather than an identifier, so it usually reads better in the customer’s language than left stranded in English.

Identifiers. Order numbers, invoice references, error codes, ticket keys, coupon codes and URLs must survive byte for byte. Watch the numbers next to them too: 1,500 in English is one and a half thousand, and in German the same amount is written 1.500. An amount that passes through a careless translation can change by three orders of magnitude and still look plausible.

Dates. 03/04/2026 is the third of April in Britain and the fourth of March in the United States, and there is no way for the reader to tell which you meant. Write the month as a word in the target language, and give the date rather than a weekday alone.

A worked example

A German customer writes in about a delayed order. She opens with Sehr geehrtes Support-Team, which sets the register to Sie. An internal note from a colleague says the warehouse is two weeks behind and nobody is to commit to a shipping date.

Your English draft:

Hi Anna, thanks for coming back to us, and sorry you had to. Your order 48219 has not left our warehouse yet. I have escalated it and I will write to you again by Friday with a shipping date. Cheers, Sam, Customer Success, Acme Ltd

Five things in that draft will not survive a mechanical translation. “Hi Anna” drops to informal address when she wrote formally. “Cheers” has no German equivalent as a business sign-off. “By Friday” is vague enough to be argued about later. The order number needs to come through untouched. “Customer Success” needs a decision rather than a word-for-word substitution.

The corrected reply:

Sehr geehrte Frau Keller, vielen Dank für Ihre Nachricht, und entschuldigen Sie bitte, dass Sie noch einmal nachfragen mussten. Ihre Bestellung 48219 hat unser Lager noch nicht verlassen. Ich habe den Vorgang eskaliert und melde mich bis Freitag, den 19. Juni, mit einem Versanddatum bei Ihnen. Mit freundlichen Grüßen, Sam Whitfield, Kundenbetreuung, Acme Ltd

Same content, same commitment, and the internal note is respected: a date for the next update, no date for the shipment.

When not to do this at all

Some replies should not go out in a language nobody on the shift can read. Anything with legal weight, anything touching health or safety, anything that varies a contract, and any formal complaint that could end up with a regulator. The failure mode there is not an awkward sentence, it is a commitment you did not mean to make. Hold the ticket and get a speaker, and tell the customer plainly that you are doing so.

The softer version of the same rule: if you would hedge the sentence in English, do not translate it. Hedging is exactly the thing that translates worst, because it depends on tone.

Make it routine rather than heroic

Three habits do most of the work. Keep the English original in an internal note, so the next agent can see what you meant rather than reverse-engineering it from the translation. Record the customer’s preferred language on their record the first time you learn it. Keep a short glossary of terms your team never translates, which will mostly be product names, plan names and the labels on buttons in your own interface. That last one matters more than it sounds: if the customer’s copy of your product is in English, translating a button name means telling them to click something that does not exist.

Draftly, the assistant we build, follows the same order of operations inside Jira Service Management, Intercom and Gmail. It takes the language from the customer’s own messages rather than from the English replies above them, and it writes the draft into the composer you already have open, so the checks above are still yours to run before anything goes out.