Module 7 — Prompts in the course language: pitfalls for English

Modules 1 to 6 built the extraction and the acknowledgement in English. The same pipeline is going to serve French and Arabic users too, and this course is written by three teams working in parallel — one per language. The temptation is to write everything in English and let the model translate. This module explains why that fails, and covers the subtler English-only traps: register, dialect, punctuation, and units.

Write the prompt in the language of the answer

The single strongest rule for multilingual prompting is: the prompt should be in the same language as the expected output. Two mechanisms explain why.

• Vocabulary alignment. Words like "customer", "urgency" and "refund" have distinct connotations in English, French and Arabic. A prompt in English that produces French output pushes the model to render French words that are the closest translations of the English ones, not the most natural French words.
• Style transfer. The prompt's own style biases the answer's style. An English prompt with English commas and periods often produces French output with Anglo-Saxon punctuation habits, including English-style quotation marks in place of French guillemets.

For the running case in English, the whole prompt — system, examples, style guide — is in English. This module documents what "the whole prompt in English" actually means beyond the obvious.

The three families of English pitfalls

English is deceptively easy: no gendered nouns, no accents to forget, consistent case rules. The traps are subtler, and they cluster into three families.

• Register: you covers what French splits into tu and vous, so a prompt that assumes formality has to say so explicitly.
• Dialect: colour or color, organise or organize, apartment or flat. Consistency matters more than choice, but silence produces drift.
• Units and dates: 12/03/2026 means March 12 for a US reader and December 3 for a UK one. 40 pounds means weight or currency depending on context.

Each family is worth its own paragraph, because each fails in a different way.

Register: formal or informal, decided once

Say nothing, and the model averages. On the running case, half the replies open with "Hi Sarah" and half with "Dear Ms Smith", depending on how the email opened. This oscillation reads as inconsistency to a support team.

Fix it in the style module from module 6:

STYLE = """Register: informal, first-name only, contractions allowed
("you're", "we've"). Never "Dear", never "Ms/Mr/Mrs" unless the
customer uses it about themselves first. If the customer signs off
formally, mirror one degree up, no further.
"""

The last clause — "mirror one degree up, no further" — is a measurable behaviour: a customer signing "Best regards, S. Chen" gets "Thanks, [team]" rather than "Yours faithfully". Without it, mirroring can escalate into full corporate registry, undoing the whole informal policy.

Dialect: pick one and enforce it

British and American spellings coexist in most training data, and models sample from both within a single reply. Two paragraphs from the model might read "organise the return" and "the color was wrong" — grammatically fine, editorially embarrassing.

The fix is a single line:

STYLE_DIALECT = "English variety: British English throughout. Use -ise, -our, and single quotation marks."

The word "throughout" is doing real work. Without it, models tend to apply the rule only to the first paragraph. Add a regex-based post-check to catch drift on the words that hurt most in your domain (colour vs color, defence vs defense, cheque vs check).

"Neutral English" is not a thing

Asking for "neutral English" or "international English" produces inconsistent output because there is no such target for the model to match. Pick British, American or a specific corporate house style, and name it explicitly.

Numbers, dates, currency

The running case has an urgency signal that depends on dates. The customer writes "I fly Wednesday". The model has no calendar unless you provide one:

from datetime import date
SYSTEM = f"""Today's date is {date.today().isoformat()}.
When the customer refers to a day of the week, interpret it as the
next occurrence of that day starting from today, unless a past tense
is used.
"""

For the acknowledgement output, the same care applies to writing dates and money:

• Dates as 10 September 2026 or 2026-09-10, never 10/09/2026 — the slash form is the ambiguity that catches half of all support systems.
• Currency with the ISO code when there is any risk of doubt: $50 USD or £40 GBP, not just $50. A "$50 refund" on an Australian order should not accidentally imply US dollars.

The rule for the reply: write times and money the way an unfamiliar reader would prefer, not the way you or your model happen to prefer.

Idioms and figurative language

Customer emails contain sarcasm ("Great, another one broken"), threats ("I'll never buy from you again"), and idioms ("this is the last straw"). Two failure modes:

• The model interprets sarcasm literally and reports high customer satisfaction, which is exactly wrong.
• The model amplifies the customer's phrasing in the acknowledgement, producing replies that sound sarcastic themselves.

For the extraction, add an explicit instruction on sarcasm:

SARCASM = """Sarcasm signal: a positive phrase in a complaint email
often means the opposite. Treat "great, another one broken" as
frustration, not satisfaction."""

For the reply, the constraint from module 6 — banned phrases, neutral opening — already protects most of the surface. What it does not protect is direct quoting of the customer, which is why the acknowledgement constraints should forbid restating the customer's phrasing verbatim.

Test on the actual worst case

Every language has a worst case: for English, it is a two-line email in ALL CAPS with a threatened chargeback and no product name. Add it to your test set explicitly. The prompt that handles it decently is robust; the one that handles only your polite emails will fail on the day it matters.

In summary

• Write the prompt in the same language as the answer; a cross-language prompt pushes the model towards literal translations and Anglo-Saxon punctuation habits.
• English pitfalls cluster into three families: register (you covers tu and vous), dialect (British vs American, pick and enforce one), and units/dates (never 10/09/2026, always the ISO or spelled-out form).
• Provide today's date in the system message when the input contains relative time expressions ("Wednesday", "next week"); the model has no calendar of its own.
• Handle sarcasm and idioms with explicit instructions on the extraction side, and banned phrasing on the reply side, or the system silently reverses the customer's sentiment.

Next module: what happens when the customer email itself contains instructions — and how not to obey them.