The Translation Tax: What AI Localisation Changed for Local Business

The Customers You Can Already See

Walk into a restaurant in a Mediterranean resort town on an August evening and count the languages at the tables. Spanish, English, German, French, Dutch, a Scandinavian language or two, Russian, Arabic. Now look at the menu: Spanish and English, possibly a French column set in smaller type because the designer ran out of room.

The gap between those two lists is a cost, and it is invisible because it never appears on an invoice. Nobody bills you for the guest who ordered the one dish they recognised instead of the tasting menu, or the couple who looked at the laminated card, could not tell which of four rice dishes contained shellfish, and walked on to the next place. This is the translation tax: not what you spend on languages, but what you lose by not having them.

It applies well beyond restaurants. Clinics, marinas, ski schools, bike hire, dental practices in retirement regions, any business whose customers arrive from somewhere else. For decades the tax was simply accepted, because the two available ways of paying it were both bad.

The Two Bad Options

Professional translation priced itself out of the use case. Not because translators overcharge — because the unit economics of a small business are wrong for it. A menu of 60 items into six languages is a real project with a real invoice. Then the chef changes eight dishes in October, and you either pay again, or you paste the new dishes in one language and hope. Within two seasons the translated versions have quietly drifted out of sync with what the kitchen actually serves, which is worse than not translating at all: now the German menu is confidently wrong.

Free machine translation failed exactly where it mattered. The old statistical engines handled ordinary sentences acceptably and mangled the specific vocabulary that small businesses run on. Dish names became literal and absurd. Regional products lost their names entirely. Preparation methods turned into unrelated verbs. And crucially, the engines had no way to know that some words carried consequences — that mistranslating a garnish is a joke and mistranslating an allergen is not.

Anyone who has seen a translated menu offering “grilled octopus to the gallega” or a dessert rendered as a piece of hardware knows the failure mode. It undermines confidence in the whole business: if they cannot spell the food, what else are they careless about?

What Actually Changed

Large language models did not fix translation by being better at grammar. They fixed it, for this use case, in three specific ways.

They translate in context rather than by the sentence. A model that can see the whole menu knows that this is a restaurant, that the section is desserts, that the previous eleven items were also Andalusian, and that pescaíto in this setting is a small fried fish dish and not a diminutive to be rendered literally. Context is what the old engines did not have, and it is most of the difference.
Terminology can be pinned. A glossary of your own terms — dish names, house specialities, local products, your brand voice for descriptions — can be held constant across every language, so the fideuà stays fideuà everywhere with an explanation attached rather than becoming a different noun in each column.
The cost per update collapsed. This is the part that changes behaviour rather than quality. When retranslating the entire menu into nine languages costs minutes rather than an invoice, it happens every time the kitchen changes something. The versions stop drifting apart. Consistency, not elegance, was always the real failure of translated small-business content, and it was a cost problem the whole time.

The same shift applies to everything else a local business publishes: treatment descriptions, opening hours and holiday notices, booking confirmations, the answers to the questions every visitor asks. We have written separately about the discipline of working with AI-generated text — the same rules apply here, with one addition specific to this domain, below.

Translation Is the Easy Half

Localisation is the harder half, and it is where automated output still needs a person.

Conventions differ, not just words. A British guest reads allergen information expecting the fourteen named categories in a particular order. An American guest looking at a price expects to know whether service is included, because the answer differs from home. Portion descriptions, temperature, measurement units, the very concept of a menú del día — all of these need explaining rather than translating for some audiences.

Dietary and religious categories are not interchangeable. “Vegetarian” does not mean the same thing to every guest who selects it, and halal, kosher, and “no pork” are three different statements. A system that maps them onto one another because the words appear in similar contexts is producing a confident error.

Tone travels badly. Warm informality that reads as hospitable in Spanish can read as presumptuous in German and stiff in Dutch. This is a judgement call, and it is the reason you want a native speaker to read the output once per language, even if they never write a word of it.

Names should sometimes stay put. The instinct to translate everything is wrong. A guest who has heard of pulpo a la gallega wants to see it on the menu, with a line of explanation underneath. Full translation destroys the thing the guest came for.

Where a Bad Translation Stops Being Embarrassing

Food businesses in the EU have a specific reason to take this seriously. Under Regulation (EU) No 1169/2011 on the provision of food information to consumers, allergen information for the fourteen designated allergens must be made available to the consumer — and the requirement covers non-prepacked food sold in restaurants and catering, not just packaged products. The European Commission’s guidance on the regulation sets out how member states implement the details, which vary.

The practical consequence for a multilingual menu is blunt: allergen data is not content, it is compliance. It should be structured per dish, held in one place, and rendered into each language from a fixed, reviewed mapping rather than passed through a general-purpose translation step every time. An allergen list that goes through a paraphrasing model is a mechanism for producing a medical incident. Treat those fields as data, lock them, and have a human sign off on each language once.

This is the single hard rule in an otherwise flexible process, and the reason to prefer a platform that models allergens as structured fields over one that treats the menu as free text.

What Being Readable Is Worth

The evidence on language preference is older than the current technology and has not been contradicted by it. The European Commission’s Eurobarometer survey on user language preferences online, conducted across EU member states, found that around nine in ten internet users preferred to access websites in their own language, that 44% felt they were missing interesting information because pages were not in a language they understood, and that only 18% would buy products online in a foreign language.

That last figure is the commercially interesting one. People will read in a second language and remain reluctant to transact in it. The gap between browsing and buying is exactly where a local business loses money to language — the guest who understood enough to stay, then ordered defensively; the visitor who read the treatment page in English, was not quite sure, and did not book.

The survey is from the desktop era and concerns online purchases rather than restaurant tables, so treat the exact percentages as directional. The direction has been consistent for fifteen years.

Choosing a Platform

If the content in question is a menu, the practical question is which platform holds your dish data and what it does with it. The established options differ in emphasis.

FineDine is strong on menu management and white-label branding, with a mature editor for operators running several venues. MENU TIGER covers the QR and ordering basics well at the lower end of the market and is a reasonable starting point for a single site.

Disho approaches it as a content generation problem rather than a publishing one: from what the restaurant uploads, it produces the dish imagery and the translated menu across twelve languages, keeping the per-dish record as the source of truth so a change to a dish propagates to every language rather than needing to be re-entered. It also handles per-table QR codes, in-menu ordering, and payment with a kitchen status board. It runs the restaurant-facing side of several venues on the Costa del Sol, which is a market where the multilingual requirement is not theoretical. At the time of writing it is free during beta.

Whichever you assess, ask the three questions that separate a working multilingual system from a demo: Does a change to one dish update every language, or does it create nine tasks? Are allergens structured fields or free text? Can you override an individual translation and have your override survive the next regeneration? A platform that answers those well will stay correct in October. One that does not will drift out of sync by the second menu change, which is where the old system failed too.

A Rollout That Does Not Produce Nonsense

Pick the languages from data, not intuition. Your booking system, your card terminal’s issuing countries, and your own analytics already know who your guests are. Most businesses find their actual mix differs from the one they assumed — often a language they never considered sits third.
Build the glossary before the first translation. Twenty to forty terms: dish names that must not be translated, house specialities, local products, the two or three phrases that carry your brand. This one document does more for output quality than any model choice.
Lock the allergen fields separately. Structured, reviewed once per language, excluded from any regeneration step.
Get one native read per language. Not a retranslation — a read. Fifteen minutes each, flagging anything that sounds wrong rather than anything that could be phrased better. A regular guest or a staff member usually counts.
Test on the second-biggest language first. Publish it, watch what those guests order for two weeks, and compare against the period before. The biggest language is usually the one you already served adequately, so it will show you the least.
Re-check after the first menu change. This is the moment the old process broke. If the change propagated to every language without anyone re-entering it, the system works. If it did not, you have bought a nicer-looking version of the same problem.

The underlying point generalises past menus. For a decade, small businesses in international markets accepted a permanent revenue loss because serving customers in their own language had a fixed cost that only chains could absorb. That fixed cost is now mostly a setup cost. The businesses acting on it are not doing anything sophisticated — they are just no longer paying the translation tax, which is a quieter advantage than it sounds and compounds across every guest who can finally read what you actually sell. If the language question is already solved and the next constraint is how the menu itself presents the food, that is a separate problem with its own economics.