Languages

The languages that ship

English and Arabic, in all three apps. Arabic lays the whole interface out right to left, with IBM Plex Sans Arabic on the website, and figures stay in Latin digits in both languages.

English is the default. Dishes, categories, the combo, kitchens and the homepage sections are stored with every text in both languages, entered side by side in the dashboard, and the seed fills in the Arabic for all of them.

How the language is chosen

• The language is the first part of the address. A path without one goes to /en.
• The language switcher swaps that part of the address and keeps the page.
• On the website, the direction is set before the first paint, so an Arabic page never flashes left to right.
• Both frontends send the page's language to the API, so its messages come back in the same language. An order remembers the language it was placed in.

Change a text

Every visible word lives in messages/<namespace>/en.json and ar.json, in each frontend's folder. Change the value, keep the key, and change it in both files.

• A key missing from ar.json shows as a missing message on the Arabic side, so keep the two files in step.
• Text inside {curly} braces is filled in by the app, such as {count} or {name}. Keep those words as they are in both languages.
• The dashboard's sidebar labels are messages too, under nav in messages/dashboard/en.json and ar.json.

What the API translates

• Error messages and the message of a successful write come back in the language of the Accept-Language header. ar-SA counts as Arabic; any language the API does not have falls back to English.
• Errors a customer sees, such as a closed kitchen, go out as keys like errors.kitchen_closed, and the website shows its own sentence for each.
• Its own texts are JSON files in back-end/src/i18n/translations/en/ and ar/, one per area: admin, auth, category, common, mail, order, product, roles, settings, users. The password-reset email is in mail.
• Dishes and the other menu records come back with both languages, as { "en": "…", "ar": "…" }, and the frontend picks one.

Add a language to the website

The two languages are written into a few files, so adding a third touches each of them. Paths are inside storefront/.

1. Add the code to locales in src/config/i18n.ts, in src/proxy.ts and in src/app/[locale]/layout.tsx.
2. Copy every messages/<namespace>/en.json to a file named after the new code, and translate the values.
3. If the language is written right to left, extend the direction check in src/app/layout.tsx, which only knows ar.
4. Add the new code to src/components/LanguageSwitcher.tsx, and its texts to src/config/brand.config.ts, which holds the names and the home page's title in en and ar.
5. Components that pick a menu text by language, such as the search results, the category bar and the kitchen map, choose between en and ar. Search src/ for "ar" and handle the new code there too.

Add a language to the dashboard

1. Add the code to locales in src/config/i18n.ts, src/proxy.ts and src/app/[locale]/layout.tsx, and to the language lists in src/components/LanguageSwitcher.tsx, the user menu and the Language setting.
2. Copy every messages/**/en.json to a file named after the new code, and translate the values.
3. The forms enter each menu text in English and Arabic side by side (src/components/ui/LanguageTabs.tsx and the two-language inputs). A third language there also needs the API to store it.

Add a language to the API

The API knows en and ar in back-end/src/i18n/i18n.service.ts and in the order and contact checks. Add the new code there, copy src/i18n/translations/en/ to a folder named after it, and translate the files. Menu records store an { en, ar } pair, so a third language in the data is a change to those records and the seed.