Prepared by the Nadali editorial team using AI.
An English message contains the date 03/04, a familiar currency symbol and a meeting time with no location attached. Everything looks fluent. Yet the customer may understand a different month, currency or city’s time. Good grammar does not establish that someone will arrive at the intended place and moment.
In brief: give AI the language draft, not the authority to decide dates, currencies or addresses. Keep approved facts separate from their presentation. Before sending, inspect the actual email, PDF or page the customer will receive.
This guide is for small hotels, service businesses and shops sending multilingual confirmations, reminders and notices. It proposes an editorial workflow with a fictional example, not findings from testing a translation product or a guarantee against mistakes.
1. Specify the reading context, not just the language
“English” does not settle every formatting decision. Agree the language, audience, channel and location of the event. An English message about a visit to a Ukrainian workshop does not move the workshop to another country or change its currency.
Create a release card for one template:
- Message ID and purpose, such as confirming an already approved appointment.
- Source version and the person responsible for confirming its facts.
- Language and approved date and amount presentation.
- Event location or the time zone for an online event.
- Protected fields: links, reference number, telephone and address components.
- Channels to inspect and the person authorised to approve sending.
This is not another database of every customer. Fictional values and approved public contact details are enough to work on a template. Do not add booking histories or private addresses to an AI request merely to check style.
2. Preserve the date’s meaning, not its ambiguous spelling
W3C explains that numeric dates can be interpreted differently. Where ambiguity is likely, it recommends explicit month names and four-digit years. That is a better starting point for customer copy than asking AI to “make the format international.”
If the source says 03/04/2026, ask its owner what it means before translating. Do not ask the model to choose the most likely interpretation. Once 3 April is confirmed, the text could say “3 квітня 2026 року” and “3 April 2026”. This is an editorial choice for clarity, not a requirement for every English message.
Keep approved year, month and day components beside the display text. Compare them after translation. Do not add a weekday for decoration: it creates another fact to verify. If the business uses weekdays, check them independently in a calendar rather than relying on the AI answer.
3. Do not turn local time into an assumption
W3C distinguishes a time zone from a UTC offset: a zone provides rules, including possible seasonal changes. One fixed offset therefore cannot stand in for every future date.
For an in-person visit, attach the time to the venue: “14:30 local time at the workshop in Lviv.” Do not automatically convert it to an assumed customer location. For an online event, establish the approved instant and display zones; verify conversions in a correctly configured calendar, not through a confident model statement.
Check the calendar invitation separately from the message. Correct prose does not prove that an attached invitation is correct. Repeat the check after a date change: the previous result does not verify a new conversion. A message with an unresolved time zone is not ready.
4. Separate amount formatting from currency conversion
Unicode CLDR describes number and currency presentation rules, including separators, symbol placement and spacing. Presentation rules do not authorise a change in economic meaning.
Keep the amount and currency code as separate control values. If the approved amount is 1250.50 Ukrainian hryvnias, the English version must not become 1250.50 dollars or a rounded 1251. Choose an unambiguous currency designation approved by the business for an international audience; do not leave a bare dollar sign when the intended dollar is unclear.
Do not ask AI to convert prices on its own. Conversion, rounding, taxes and payment conditions are separate decisions for responsible staff. This workflow does not change them. Translation must likewise not turn an estimate into a final price or a deposit into full payment.
5. Addresses and phone numbers are not ordinary prose
W3C documents international address variation: components and their order are not identical across countries. Our practical conclusion for outgoing messages is to use an approved address record, not ask a model to “correct it for English.”
Preserve building numbers, blocks, units and postal codes. When Latin-script wording is needed, use the version approved by the business and retain the local-script address alongside it when useful. Do not invent a missing postal code or a replacement street name. A map is an additional way to find a location, not a substitute for a checked address.
Verify the telephone number against the approved contact record. Do not let AI guess a country code or remove digits as an “unnecessary zero.” In a test message, compare the displayed number with the number opened by the call link. This is a proposed implementation check; we have not performed it on a real service.
6. Worked example: the same appointment in two languages
Everything below is fictional. A workshop has approved an appointment for 3 April 2026 at 14:30 local time in Lviv. The estimated amount is UAH 1250.50; the final price is not yet confirmed. Address and telephone details would come from approved fields not provided in this example.
Ukrainian draft: “Ваш візит погоджено на 3 квітня 2026 року, 14:30 за місцевим часом у Львові. Орієнтовна сума — 1250,50 UAH; остаточну вартість ще не підтверджено”.
English draft: “Your visit is confirmed for 3 April 2026 at 14:30 local time in Lviv. The estimated amount is UAH 1,250.50; the final price has not yet been confirmed.”
The control values match: year 2026, month 4, day 3, time 14:30, Lviv, amount 1250.50, currency UAH and estimated-price status. The numeric presentations are editorial choices for this example, not results from testing a particular formatter. An address, telephone number or completion deadline cannot appear without a source.
7. Give AI a narrow task, then inspect the release
Draft an English version from the approved Ukrainian message and fact card. Do not change the meaning of dates, time, amount, currency, confirmation status or conditions. Do not convert currency or time zones. Flag unresolved fields. Preserve source contact details and links. Return the draft and a separate list of control values. Do not send anything.
Compare the draft directly with its source, not just a back-translation. Then open a test message in the intended channel: is the whole currency designation visible, is the address clipped, are links correct, and does the calendar show the approved time? Record version, language, channel, observations and reviewer. Mark an unperformed check as unperformed.
Takeaway: start with one template, preserve its facts and inspect the final presentation in both languages. AI helps with wording; sending approval rests on reconciled values. The workflow does not require a new paid service, although formatting and preview capabilities depend on the tools you already use.
For incoming spreadsheets, use our separate CSV data-fidelity guide; for field copy, see checking enquiry forms. This article covers outgoing messages, not imports or changes to form rules.
Author: Nadali. Prepared using AI. Primary sources checked on 29 October 2026. The example and workflow were not tested on real customer correspondence.
Cover: a reused original Nadali AI illustration of fictional forms, not a real customer message.
