By Devfood Team — who we are
Multi-Language Ordering Is Included
Multi-language storefronts were a $499 pack. They are now in every Devfood subscription — what is translatable, how RTL works, how to roll a language out.
Until 31 August 2026, multi-language support on Devfood was a one-time pack that cost $499. It is now included in every subscription, at every tier and in every market. This post is about why that changed and, more usefully, what “multi-language” actually covers — because the phrase is used loosely across the industry and a buyer in Hyderabad or Dubai deserves the specifics.
Why the pack was wrong
Devfood’s pricing is set per market, and the markets it is built for — India, Brazil, the Philippines, South-East Asia, MENA, Africa — are the ones where a single-language storefront is a handicap. A Mumbai café serves customers who read Hindi, Marathi and English; a Manila counter serves Filipino and English in the same queue; a Dubai delivery kitchen needs Arabic and English on every screen, one of them right-to-left.
Selling a language pack to those customers meant charging the most for the feature in the places where it was least optional. That is backwards, so the pack went and the feature moved into the base plan alongside the native apps. Nothing on the pricing page gates it.
What is translatable
There are two halves, and they are managed separately. It helps to know which one you are looking at.
The app’s own wording. Every button, label, error message and empty state in the customer app, the restaurant app, the driver app and the counter devices. Each app has its own translation editor, organised by area and screen, and each supports CSV export and import — which is how the job actually gets done: export, send the file to a translator, import it back.
Your content. Menus, categories, items, add-ons, variants, coupons, banners, walkthrough screens, custom pages, cancellation reasons, and every notification template. These are translated where they are created rather than in a central list: each carries a language section, and you fill in the languages you have chosen.
Order notifications deserve their own line. Status updates go out by SMS, email, push and voice — plus WhatsApp — from templates you write per language, so the “your order is on its way” message arrives in the language the customer ordered in.
How the storefront behaves
You pick your languages from the full standard list and set one as primary. The primary is the fallback: anything you have not translated yet appears in the primary language rather than blank. A customer picks their language and the storefront switches — menu, checkout and notifications together, across the web storefront and the native apps.
Right-to-left languages are supported, and the apps lay out accordingly. Arabic, Hebrew, Urdu and Persian storefronts mirror the layout rather than just flipping the text direction. If you add one, look at the result on a real device before launch — RTL affects far more than text, and a screen that reads correctly with mirrored icons and a mirrored cart is the thing to check.
Rolling a language out without regretting it
Three things the operators who have done this would tell you.
Adding a language is not one job. It is the app strings, plus every piece of content you have created since launch, plus every piece you create afterwards. New content needs translating as you go, or it silently appears in the primary language for everyone else.
Translate the money-making surfaces first. Item names and descriptions, checkout, and order notifications. A customer will forgive an untranslated settings screen; they will not order from a menu they cannot read.
Do not translate everything at once. Customer app first, then the app your staff use, then the counter devices. A partly translated kiosk is worse than an English one, so finish each before starting the next.
Four markets, four shapes of the same feature
India. English as the primary, with Hindi and one regional language on the customer app. Staff apps often stay in English. The notification templates matter most here — an SMS in the customer’s own language is read; one in the wrong language is deleted.
Philippines. English and Filipino side by side, with many customers switching between them mid-sentence. A short, plain English primary with a Filipino translation of the menu covers most of it.
MENA. Arabic and English, one of them right-to-left. This is the market the RTL support exists for, and the one where checking the layout on a real device before launch is not optional.
Brazil. Portuguese as the primary, with English for tourist-heavy neighbourhoods. The Portuguese storefront is the product; the English one is a courtesy.
What is deliberately not claimed
Multi-language does not mean the platform writes your translations for you. Your content is yours to translate — that is what the CSV round trip and the per-item language sections are for — and a menu description a translator wrote will always beat one a machine guessed at. What is included is every mechanism to publish, switch and fall back between the languages you provide, on every surface a customer or a member of staff touches.
It also does not change billing currency. You are billed in your own market’s currency at a price set for that market, and your customers pay you in the currency your payment gateway settles in, as before.
Getting started
Choose your languages and a primary in the dashboard, export the customer app strings, and start with the menu. The features page lists the rest of what ships in the base plan; if you want to see a bilingual storefront switch languages live, book a demo and ask for one.