'Multi-language menu' shows up as a bullet point on every restaurant software page, TU2's included — but there's a real difference between a menu that technically has four languages and one where each language actually reads naturally to a native speaker.
Where the translate-button approach falls apart
Running an English menu through a generic translation API produces Arabic, Kurdish, or Turkish that's technically comprehensible but often stiff, occasionally wrong on food-specific terms, and immediately recognizable as machine-translated to a native reader. For a menu — a document meant to make a customer want to order — that's a real cost, not just an aesthetic one.
What actually needs to be entered per language, not translated
- Dish names that are genuinely local in a given language, not a literal translation of the English name — a dish might have an established Kurdish or Arabic name that isn't a translation at all.
- Descriptions written for that language's audience, not translated word-for-word from an English original that assumed different cultural context.
- Right-to-left layout handled correctly for Arabic and Kurdish — not just translated text dropped into a left-to-right template.
Why this matters more for a menu than most content
A customer deciding what to eat is making a fast, low-commitment decision — any friction, including a slightly odd translation that makes them pause and re-read, measurably slows that decision down. A multi-language menu that reads naturally in each language isn't a nice-to-have polish item, it's doing the actual job faster.
TU2's menu system lets an owner enter and edit each language directly, not auto-translate from one source language — so what a Kurdish or Arabic-speaking customer reads was actually written for them, not translated at them.