Languages

The languages that ship

English and Arabic, in all three apps. Arabic lays the whole interface out right to left, with Arabic faces for the text and the headings, and figures and prices stay in Latin digits in both languages.

English is the default. A property's title, short description, description, city and SEO texts, and a neighborhood's name and description, are stored in both languages and entered side by side in the dashboard; English is required, and the Arabic can follow later. The seed fills in the Arabic for the demo agency.

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.

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.
• Amenity, property type and status labels are messages too: messages/amenities on the website, messages/dashboard/domain in the dashboard.

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, common, lead, neighborhood, property, roles, settings, viewing.
• Properties and neighborhoods 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 and description in src/config/brand.config.ts.
5. Code that picks a stored text by language, such as src/lib/utils/pickLocalized.ts, the date and time formatting of the viewing request and the calendar, 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 and the seed.