Write one master description that holds every fact, then have AI adapt it for each language rather than translate it word for word, using a shared glossary. Check every version three ways: an automatic fact comparison, a back-translation by a different tool, and a native speaker's read. Publish separate own-site and marketplace versions.
Vendor guides mostly show how to write one good description and where to paste it in a booking plugin. The multilingual work is different. Facts drift between versions, idioms go wrong, and the costliest error is a promise your guide cannot keep, such as a page offering a tour "in Spanish" when only the handouts are in Spanish. This workflow is built to catch that kind of drift before a guest does.
A master description built from blocks, not paragraphs
Everything starts with a master in the language you write best. Build it from blocks so that each can be checked and reused, and so that a change to one fact touches one block. A small operator with a three-hour food walking tour for up to 10 guests, run in English every day at 18:00 and in Spanish on Saturdays at 10:30, would build its master from these blocks.
- The promise: one sentence on what the guest gets.
- The route in beats: six stops in the order a guest meets them, each in a line.
- Practical facts: duration, meeting point, group size, price basis, what is included and excluded, accessibility.
- Language of the tour: who guides it, in which language, and on which departures.
- Who should skip it: for example, anyone who needs a guaranteed gluten-free menu.
- Cancellation summary: one line pointing to the full policy.
Keep three lengths of the same master: a short version of about 25 words for marketplace cards and social posts, a standard version of about 120 words, and a long version of about 300 words for your own site. Write the short and long versions from the same facts, not from each other, so that trimming does not silently drop a qualifier.
If the master does not exist yet, AI can build it from your rough notes, provided it asks instead of guessing. The prompt below does that, and its questions are the most valuable part of the reply.
Here are my rough notes for one tour. Turn them into these blocks: promise (one
sentence), route in six beats, practical facts, language of the tour, who should
skip it, cancellation summary (one line).
Use only my notes. Where a block needs a fact I have not given, write
[QUESTION: ...] instead of filling it in. Keep the English plain and short.
NOTES: 3 hrs, 6 tastings, max 10, English daily 6pm, Spanish Saturdays 10.30,
mostly flat but steps at stop 4, vegetarian ok if told, gluten free hard, meet by
the fountain, water included.A typical reply writes the blocks it can and leaves lines such as "[QUESTION: how many steps at stop 4, and is there a step-free alternative?]", "[QUESTION: how much notice do you need for a vegetarian menu?]" and "[QUESTION: should the meeting point say more than 'by the fountain', such as a street address or a landmark photo?]". Answer them in writing. Those answers become rows in the facts table, and each one is a fact a guest would otherwise have had to email you to find out.
The facts table and glossary that every language reads from
Before any prompt runs, put the facts into a table that is the only source the model may use. It also becomes the answer key for the checks later.
| Fact | Value in the master |
|---|---|
| Duration | 3 hours |
| Distance | About 3 km on foot |
| Group size | Maximum 10 guests |
| Stops | 6 tastings |
| Departures | English daily at 18:00; Spanish Saturdays at 10:30 |
| Price | $65 per person, charged in USD |
| Included | Six tastings and bottled water |
| Excluded | Hotel transfers and extra drinks |
| Diet | Vegetarian on request with 48 hours' notice; gluten-free cannot be guaranteed |
| Accessibility | Mostly flat; one stop has 40 steps; not suitable for wheelchairs |
Next, the glossary and a do-not-translate list. This is a short sheet, usually 20 to 40 rows for a small operator, that tells the model which words are fixed. It stops one tour being called three different things across languages. The tutorial on keeping terminology consistent with AI shows how professional translators maintain the same kind of sheet.
| Item | Rule | Example |
|---|---|---|
| Place names and landmarks | Use the spelling guests will see on signs and maps | Keep as written locally |
| Your tour names | Do not translate; add a short descriptor in each language | Name stays; descriptor translated |
| "Meeting point" | The native reviewer chooses one term and every tour uses it | One term for all 12 tours |
| Times | 24-hour clock unless the reviewer says otherwise | 18:00, not 6 pm |
| Distances | Metric first; add miles only where your audience uses them | 3 km (about 2 miles) |
| Prices | Show the currency you charge; never let the model convert | $65 per person (USD) |
| Tone | Formal or informal address, chosen once per language | Informal for a walking tour |
The price rule deserves a moment. Exchange rates move daily, and a model converting "$65" to a local figure uses whatever rate it half remembers. Show the amount you charge, in the currency you charge it, and let the checkout display conversions if it offers them.
The rewrite prompt, and what a good Spanish version looks like
The prompt asks for an adaptation, supplies the facts and glossary, and forbids additions. It also asks for a FLAGS list, so the model has somewhere to put what it could not render faithfully instead of papering over it.
Adapt (do not translate word for word) the tour description below for readers
whose first language is Spanish. Use only the FACTS table and the MASTER text.
Rules:
- Keep every number, time, price and proper noun exactly as in FACTS.
- Use the GLOSSARY for set terms. Do not invent new names for our tours.
- Address the reader informally (tú).
- Say who guides the tour and in which language within the first two sentences.
- Show only the departures that are in Spanish.
- Do not add services, awards, safety or health claims, or places not in MASTER.
- Distances in km only. Price in USD as in FACTS; do not convert.
Output:
1. Headline (max 60 characters)
2. Standard description (about 120 words)
3. Short version (max 30 words)
4. FLAGS: anything you could not render faithfully, or any fact that seems to
conflict with another.
FACTS: [paste the table]
GLOSSARY: [paste the sheet]
MASTER: [paste the standard English description]This is an illustration of the shape of what comes back, trimmed for space.
Headline: Paseo gastronómico de 3 horas: seis degustaciones
Short version: Visita guiada en español, los sábados a las 10:30. Seis
degustaciones en un recorrido a pie de tres horas, en grupos de hasta 10 personas.
Standard (extract): Los sábados a las 10:30 salimos con guía en español, en un
grupo de hasta 10 personas. Durante tres horas recorremos unos 3 km a pie y
hacemos seis paradas de degustación. Incluye las seis degustaciones y agua
embotellada. Si necesitas un menú vegetariano, avísanos con 48 horas de
antelación; no podemos garantizar opciones sin gluten.
FLAGS: The master says "evening walk"; the Spanish departure is at 10:30, so I
left "evening" out.Look at what the adaptation did. It named the language of the tour and the departure in the opening sentence, dropped the English departures, kept "cannot guarantee" on gluten, and raised the evening-versus-morning conflict itself. That last point is a mistake in the master, not the model: "evening" belongs in the English departure block, not in the general description. Models that are told to flag conflicts will find these errors in your English as well, which is a useful side effect.
Write each short version per language and count its characters, rather than trimming the English short version and translating that. Text length changes from one language to another, so a marketplace limit that fits the English can cut another language off mid-sentence. Ask the prompt for the short version "to the limit" for each channel, then check the count in the finished text yourself.
Quality is not even across languages either. AI translation tends to be strongest where there is a lot of written material online and weaker for languages with less. If you plan a language where your reviewer is the only person who can judge the output, start with the headline and the first paragraph, which carry most of the first impression, and consider paying a human translator for those two blocks.
Three checks before any language goes live
A model that writes the adaptation is not the right judge of it. Use three independent checks, in this order, because each catches what the one before misses.
Check 1: compare the facts automatically
Ask a second pass, preferably a different model or tool, to extract the same fact keys from the finished Spanish text without seeing the English, then compare them with the facts table in a spreadsheet. It is quick to do and catches the errors that cause real trouble. This table shows what a first draft can look like when it fails, as an illustration.
| Fact | Facts table | What the draft says | Result |
|---|---|---|---|
| Duration | 3 hours | "tres horas" | Match |
| Group size | Maximum 10 | "hasta 12 personas" | Mismatch: fix |
| Spanish departure | Saturdays 10:30 | "al atardecer" (at dusk) | Mismatch: fix |
| Diet | Gluten-free not guaranteed | "con opciones sin gluten" | Meaning drift: reads as guaranteed |
| Price | $65 in USD | "65 $" | Number matches; add USD, since "$" alone can mean other currencies |
The same method applies to any translated document with numbers in it; the tutorial on translating terms and conditions lists the figures that change most often.
Check 2: back-translate with a different tool
Translate the Spanish back into English literally, using a different tool from the one that wrote it, such as another chat model or a dedicated translator. Compare meaning, not wording. You are looking for qualifiers that disappeared and promises that appeared. "We can adapt for vegetarians" turning into "all dishes are vegetarian" is a classic drift, and it matters because a guest with a dietary need acts on it. A second tool matters because one model's blind spot is usually repeated when it checks its own work.
Check 3: a native speaker with a checklist
The final check is a person who reads the language as a first language, ideally someone who also travels or guides. Do not ask "is it good?". Give them six questions: would a local guide write it this way; does any phrase sound machine-made; are the facts the same as the English; is the formal or informal address right; would you type these words to find this tour; and is it unmistakable which language the guide speaks? The tutorial on checking AI translations before customers see them goes further on reviewing methods. Pay for the review: it is the only check that knows what is idiomatic, and it is the one a guest's first impression depends on. Here is the kind of catch it makes, shown as an illustration. An earlier draft of the Spanish example above said "probamos seis paradas", literally "we taste six stops", which no native speaker would write, and "grupos de máximo 10 personas", which reads as spoken shorthand. The reviewer changed them to "hacemos seis paradas de degustación" and "grupos de hasta 10 personas". The fact comparison passed both lines, because every number in them was right.
Send the reviewer a small, consistent pack so that 25 minutes is enough. It holds the English standard description, the version to review, the facts table, the glossary, and the six questions. Ask them to return a list of corrections tagged "fact error", "unnatural" or "style", so you can fix errors first and decide on the rest. Reviewers also find mistakes in the English master when it reads oddly in two languages, which is worth a thank-you and a fix.
A plausible slip shows why the checks stack. A description says "guided in Spanish" because the model read "Spanish audio notes available" as the language of the tour. The fact comparison passes, since "Spanish" appears in both versions. The native reviewer catches it, because the Spanish sentence implies a live guide. Only the combination of the fact comparison and a human reading for meaning finds a problem that either alone would miss.
Finding the words travellers actually type
A faithful translation can still use words nobody searches for. Before finalising each headline, ask the native reviewer for the three phrases they would type to find a tour like yours, then compare candidates in Google Trends, which scores interest on a 0 to 100 scale and lets you put several term groups side by side. Use the winner in the headline and the first sentence, and keep the others in the body text. The same step also tells you whether a language is worth adding, since a term with almost no interest in a market is a reason to wait.
Keep the tour name itself fixed and let the descriptor around it carry the search words, for example your tour name followed by a plain phrase for "food walking tour" in that language. This is also where the master's practical blocks help: a guest searching in Spanish usually wants the departure day and the guide's language before the story.
Own-site, marketplace and print versions from one master
One master feeds several outputs, and none should be an unchanged paste of another.
| Output | Length | What changes | Watch for |
|---|---|---|---|
| Own site, one page per language | Long version plus a title tag and meta description | Room for the route, the story and the practical blocks | Linking the language versions together |
| Marketplace listing | Short and standard, to the channel's field limits | Lead with practical facts; use the language fields the channel provides | Limits and language options differ by channel, so check your supplier account |
| Brochure or printed card | Short plus route beats | Fixed layout, no links | Date and price staleness once printed |
On your own site, give each language its own page and link the versions to each other with hreflang annotations: each version lists every version, itself included, plus a fallback for everyone else. Check Google's current documentation for the exact syntax. Google's spam policy, updated in August 2026, treats mass-produced pages that add no value as scaled content abuse, whatever tool made them. A native-checked description with real facts and your own photos is the opposite of that. The risk is publishing a language for every tour in an afternoon with nobody reading it.
For marketplaces, do not assume the platform translates your text for you, and do not assume it does not. Look in your supplier account for the language options and the field limits on each listing, and write the short version to fit the smallest limit. The tutorial on rewriting Viator and GetYourGuide listings covers titles and first lines. If you sell across many pages and languages, see the guide to AI website translation tools, costs and checks for the site-wide side.
When the master changes: a log that keeps languages in step
Languages fall out of date quietly. The English page gets a new meeting point and the Spanish page keeps the old one for three weeks, so guests wait in the wrong place, and each of them writes a review about it. The fix is a plain tracking sheet with one row per tour per language.
| Tour | Language | Master version | Version translated | Native-checked on | Live on |
|---|---|---|---|---|---|
| Food walking tour | Spanish | v4 | v4 | [date] | Site, marketplace |
| Harbour walk | Spanish | v4 | v3 | [date] | Site |
Whenever "Master version" is ahead of "Version translated", that row is stale and gets a ticket. Re-run only the block that changed, such as the meeting point or the price line, then run the three checks on that block and note the date. A rule keeps it honest: no edit to the master without a log line. The second row above is the kind of gap the sheet exists to expose, and it takes ten seconds to see.
The cost of adding four languages to twelve tours
Assume 12 tours, each adapted into 4 languages besides the master, at about 450 words per tour across the three lengths (25 + 120 + 300 words). That is 48 language versions and 21,600 words to adapt. These timings and rates are assumptions, so swap in your own.
- Master descriptions: about one hour per tour, 12 hours in total, mostly spent gathering facts you should have written down anyway.
- AI adaptation and the fact comparison: about 10 minutes to run and 5 to review per version, 12 hours across the 48.
- Native review: about 25 minutes per version at an assumed $30 an hour, $12.50 each, so $600 for 48 and 20 hours of reviewer time.
- Human translation from scratch, for comparison: Gengo's published list rates were $0.09 and $0.18 a word at the September 2026 check (confirm them before you budget), which puts 21,600 words at $1,944 to $3,888.
Both routes need the 12 hours of master writing, because a translator works from the master too. Beyond that, the AI route costs about 12 of your own hours plus $600 of review, against $1,944 to $3,888 for a full human translation, before tool subscriptions. That gap does not mean AI is better than a translator. It means that a good translator's time is best spent on the lines that carry risk, and the workflow above sends the reviewer those lines in a checkable form. For long, legal or safety-critical text, the comparison runs the other way.
How to tell the pages are working
Judge each language by the enquiries it generates. Tag questions from guests by language and count the ones that ask something the page should have answered: "is the tour in Spanish?", "where do we meet?", "is it suitable for children?". If more than about one enquiry in ten on a language page asks one of those, the description is failing on a specific block, and the question tells you which. That threshold is my own rule of thumb. Also read the first 20 reviews in each language for words such as "not as described", which usually point to a drifted fact or an inflated promise.
The tutorial on AI for tour guides covers answering those enquiries in several languages. Once the descriptions are stable, adding a fifth language becomes routine: add a glossary column, run the prompt, run the three checks, pay one reviewer, and log the version.
Multilingual tour description questions
Which languages should I add first?
Start where your enquiries and bookings already come from: marketplace reports, site analytics and the languages guests use when they write to you. Then add only languages you can actually staff, because a description implies a service. A page in a language nobody on the team speaks will bring questions you cannot answer.
Will Google penalise machine-translated tour pages?
Google's spam policy, updated in August 2026, targets mass-produced pages that add no value, whatever tool made them. A description with real facts, a native check and its own details is a different thing from hundreds of untouched machine translations. Nobody can promise rankings, so focus on pages that help the reader.
Do short marketplace versions need a native check too?
Yes at first, because short versions squeeze meaning and drop qualifiers such as 'on request'. Check every short version in the first batch. After a few months of clean reviews you can move to spot checks of one in four, and always review any line that mentions safety, diet or accessibility.
Can I use AI voice or audio guides in the same workflow?
The master facts and glossary carry over, but audio needs its own checks for pronunciation, pacing and licensing. Treat it as a separate project once the written descriptions are stable, and see the tutorial on AI audio tour guide scripts for that side.
Further reads
- Can AI Handle Restaurant Menu Translation Without Mistakes? — Food and allergen wording across languages.
- Hostel Software: Can AI Handle Guest Messages in Several Languages? — Guest messages in several languages.
- AI Marketing Booklet Creator: Print a Tour Brochure From Itineraries — Print a brochure from the same itineraries.
- AI Translation vs Human Translators: What Documents Really Cost — What documents cost with AI versus a translator.
- How to Offer Multilingual Customer Support With AI Translation — Answer guest questions in several languages with AI.
- Can You Make an AI Audio Tour Guide? Scripts, Voices and Licensing — Scripts, voices and licensing for audio guides.
- Tour Booking Software Compared: What Small Operators Should Check — How to compare tour booking software on booking rules, payouts, OTA sync, waivers and fees, with a cost sum for a small operator.
- Tour Guide Scheduling Software: What to Pick for Freelance Guides — A selection checklist for freelance tour guide scheduling: availability, languages, assignment rules and confirmations, with a worked cost example.
- How to Start a Bike Tour Business: Routes, Pricing and Bookings With AI — A staged plan for a first guided bike tour: ride-test the route, price per rider from real costs, check insurance and waivers, choose a booking tool.
- 8 Examples of AI in Tourism From Guided Tours to Group Bookings — Eight practical AI uses for tour guides and attractions, each with the tool type, set-up time, a worked example and a check that it worked.
- Travel Industry AI Chatbot: What a Tour Operator Website Should Answer — What a tour operator's website chatbot should answer, look up and hand to staff: meeting points, cancellation wording, availability, refunds and safety.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Google's spam policy on scaled content abuse (updated August 2026) and its guidance on localised page versions; Google Trends help on comparing search terms; Gengo's published per-word rates (September 2026 check); illustrative timings and reviewer rates are the author's assumptions.