How MenuLens Translates a Menu: Target Language, Region, and Preferences

The short answer

MenuLens translates a captured menu into 40+ target languages, defaulting to your system language and switchable at any point after capture. The target language is independent of the language the menu is written in, so a Japanese menu can go straight into Spanish. Switching re-runs the AI request rather than re-rendering a stored string, which is why the same photo can read slightly differently each time.

Three things beyond the target language change the output: optional region context, the preferences you set once, and the quality of the photo. Everything runs through an OCR pass and a language model, and both need a connection. And none of it is medical, allergy, or religious-dietary advice — for that you still ask the person holding the menu. MenuLens runs on iOS 17 and later.

Why people search for this

The query is almost always "how do I translate a menu," but translation is not the problem. The problem is a decision with a very short deadline.

You are standing at a table with a page of script you cannot read, a waiter who may not share your language. You have perhaps ninety seconds of patience before you point at the first plausible-looking line. What you need is not a vocabulary — it is the answers to three questions: what is this, is it safe for me, and what do I say to order it.

Literal translation fails at the second question specifically. A word-for-word rendering of a dish name tells you nothing about whether it contains shellfish or pork, and menus in tourist districts are often worse than useless, because the English gloss was written to be short rather than accurate.

The target language is a setting, not a lookup

Source and target are independent. The OCR pipeline reads menus in 40+ languages, including Chinese, English, Japanese, Korean, French, German, Spanish, Portuguese, Italian, Russian, and Arabic. The target list matches the system-supported language list. Neither constrains the other.

The default is your system language. You can change the target after capture or after recognition finishes, and the result reloads.

Switching regenerates rather than relabels. A recognized menu is stored with its source language, target language, region, currency, exchange rate, dish count, and category count. Changing the target re-runs the model over that menu, producing fresh ingredient inference and flavor notes — not a swapped caption on the previous result. That is why two runs of the same photo can differ slightly.

The menu carries more than dishes. The model also returns an optional cuisine style, price range, restaurant type, restaurant name, an overall note, and any footer text. Each is nullable — an absent price range is a normal state, not a failure.

Region context changes the answer, not the wording

Region-based recommendations are optional and off unless you enable them. Once on, the app resolves your approximate position and adds it as prompt context so the model can identify the cuisine better. The resolved region is stored on the menu session, so it travels with the result rather than being consulted per dish.

This is the setting most people never touch, and the one that changes flavor notes. The same dish can be annotated differently in different regions — a dish named one way in Sichuan and the same name elsewhere will not read identically. That is intended behavior, not an inconsistency.

Two honest limits. It is network-based rather than precise GPS, and it is a hint about cuisine, not a claim about the restaurant you are sitting in. A menu already written for tourists in a global-food district will often contradict the regional hint.

When location fails, MenuLens says so rather than guessing: authorization denied, services restricted, and reverse-geocoding failure each get their own message with a pointer to iOS Settings.

Preferences are injected into the prompt, not applied as a filter

This is where most competing pages get it wrong. Your dietary restrictions, allergens, taste preferences, and budget range are not a checkbox list the app filters against after translation completes — they are injected into the recognition and recommendation prompts. So they change what the model writes about each dish, its inferred ingredients and spice description, rather than hiding rows from a finished list.

The taste vocabulary is more granular than a typical translator offers. Staples and proteins are distinct options: Rice, Noodles, Beef, Pork, Chicken, Seafood, Vegetables, Bean Products, Vegetarian, No Meat. Heat is not a single slider either — Mild, Medium, and Extra Spicy are separate, and so are Numbing Spicy and Fragrant Spicy. Style covers Light, Heavy, Sour, Sweet, and Salty Fresh. Numbing and fragrant being distinct matters more than it sounds: they describe genuinely different dishes, and an app offering only a one-to-five scale will call both simply "spicy."

Selection is explicitly multi-select, Number of Diners sits in the same panel, and onboarding can be skipped and adjusted later. Budget range influences the pricing of recommended dishes rather than the translation text.

Allergens are informational by design. Setting a peanut allergy changes what the model is told to look for; it does not make the app an authority on whether a dish is safe for you.

What the translation quality actually rests on

OCR comes first, and it is the ceiling. Ingredient inference is downstream of how well the menu text was read. Handwriting, non-standard fonts, and dim or reflective environments all reduce accuracy.

Dish names are never discarded. The original and its translation sit side by side, so you can point at the original when ordering even if the model's rendering is wrong. That is the most useful failure behavior here: a wrong translation costs you a sentence, whereas one that replaced the original would cost you the ability to order at all.

Prices keep their original currency and figure whenever possible. Conversion runs on a static USD anchor table covering 60+ currencies, refreshed once at launch from a public rate endpoint and cached for 24 hours. When no usable rate exists the service signals no-data and the original price is displayed — deliberately, because a confidently wrong converted number is worse than showing none.

A dish with no photo on the menu gets a generated reference image derived from its description. It is a depiction of the text, not a photograph of the food.

One version caveat worth knowing: the dish reference text is Wikipedia original text, and translating it through the system requires iOS 18, while the app itself runs on iOS 17.

The limits to design around

• It is not advice. MenuLens states plainly that AI output does not constitute medical, allergy, or dietary advice. For allergies, religious dietary law, or health restrictions, ask restaurant staff directly and rely on the actual ingredients.
• Everything needs a connection. OCR, translation, dish explanation, and image generation all require network access.
• Free scans are counted. The quota is on scans, and re-shooting a blurry menu or splitting a long one across several shots draws on it. Pro stops counting scans entirely. A day pass covers seven days without renewal; the US base price is $4.99 monthly or $24.99 yearly, and the figure shown live in the app is the one that applies in your storefront.
• Re-translating is a new generation. Changing the target language or the preferences produces a fresh result each time. Correcting the input and re-running is the fix for a bad translation — but on a free quota it is a scan you spend.

What MenuLens does differently

Most menu translators answer the question you typed. MenuLens is built around the one you actually have.

• It produces explanations, not glosses. Each dish gets inferred ingredients, typical preparation, flavor notes, and pairings, alongside the translation.
• Preferences shape the output rather than filter it afterward, so the reasoning shows in the dish text instead of appearing as a silent exclusion.
• It keeps the original. The source name is one tap away, turning a translation error from a blocker into a detail.
• Region and preferences are editable after the fact, under Dining Preferences in your profile, without re-photographing anything.
• It says what it is not. The allergy and dietary caveat is part of the product, which is the right posture for a tool that reads ingredient lists for people who cannot read them.

The honest limit on all of this: the accuracy ceiling is the photograph, the safety ceiling is your own verification, and every improvement is a network call away.

When a menu app is the wrong tool

It is not for everyone:

• If you have a serious allergy, treat the app as a starting point for the conversation, never as the conversation. Ask the staff what is actually in the dish.
• If you read the language, a competent camera translation tool will usually lose to your own eyes.
• If the menu is hand-lettered on a chalkboard in fading ink, no amount of model quality fixes the OCR input.

For everyone else the bar is low and the payoff is concrete: you get to the decision without performing a linguistics problem in front of a waiter. If you want to see the mechanics on the other side of the capture step, the dish detail and recommendation flow covers what happens once a menu is recognized, and the FAQ covers subscription, privacy, and account questions.

MenuLens turns menus in unfamiliar languages into dish explanations you can act on, then helps you order — without pretending the output is something it is not.