Languages

The languages that ship

English and Arabic, in all three apps. Arabic lays the whole interface out right to left with an Arabic face for the text, and figures and prices stay in Latin digits in both languages. A Latin run inside Arabic copy, such as a phone number, a booking reference or a price, is kept in its own direction so it never reorders.

English is the default. A stay's title, short description, description, location hint, house rules and SEO texts, a destination's name, tagline and description, the home page questions and the company's tagline, description, address line and cancellation policy are stored in both languages and entered side by side in the dashboard; English is required for a title, and the Arabic can follow later. A stay is published only once both languages are filled in. The seed fills in the Arabic for the demo company.

How the language is chosen

• The language is the first part of the address. A path without one goes to /en (the dashboard's root goes to /en/dashboard).
• The language menu swaps that part of the address and keeps the page.
• Both frontends send the page's language to the API, so its messages come back in the same language, and a booking remembers the language it was made 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.
• Status, payment and block reason labels in the dashboard are messages too, in messages/dashboard/domain.

What the API translates

• Error messages and the message of a successful write come back in the language of the Accept-Language header. ar-AE counts as Arabic; any language the API does not have falls back to English.
• Its own texts are JSON files in back-end/src/i18n/translations/en/ and ar/, one per area: admin, auth, availability, booking, common, destination, faq, inquiry, payment, review, roles, settings, stay.
• Stays, destinations and the home page questions 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 and in src/proxy.ts.
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 directionOf in src/config/i18n.ts, which only knows ar.
4. Add its texts to name, tagline and description in src/config/brand.config.ts.
5. Code that picks a stored text by language, such as src/lib/utils/pickLocalized.ts, chooses 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/locales.ts (and to RTL_LOCALES if it is written right to left) and in src/proxy.ts. A locale added there also adds its tab to every field kept in several languages.
2. Copy every messages/**/en.json to a file named after the new code, and translate the values.
3. Search src/ for "ar" for the few places that still name the two languages directly.
4. A third language in the stored texts also needs the API to accept it.

Add a language to the API

The API knows en and ar in back-end/src/i18n/i18n.service.ts. Add the new code there, copy src/i18n/translations/en/ to a folder named after it, and translate the files. Stored texts are an { en, ar } pair, validated by src/common/dto/localized.dto.ts, so a third language in the data is a change to those classes, the entities, the publishing check and the seed.