> ## Documentation Index > Fetch the complete documentation index at: https://docs.genieforge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Languages on landings, intake, and the portal > Turn on English, Arabic, French, or another language for landings, public intake, login, and the signed-in portal. # Languages on landings, intake, and the portal Under **App Settings → Appearance → Languages**, you choose which languages people see on the public site, public intake, login, and the signed-in portal. The GenieForge builder itself stays in English. ## What you turn on Check the languages you want (English, Arabic, French) and pick a **Default language**. Save with **Save languages**. English only (the default) hides the language switcher. A single non-English language stays on, so a site can be Arabic only. Arabic (and other right-to-left languages) flip the page direction. The host sets the document language and direction for you. Arabic uses Tajawal so labels stay readable next to English names. Pick a different face under **App Settings → Appearance → Public brand fonts** if you want. You can ask Building chat to add another short language tag (for example German or Brazilian Portuguese). Extra languages show up under **Languages** so you can turn them off later. Collection list and detail paths cannot start with a language prefix (`/ar`, `/fr`, or another enabled tag). Use `/works` or `/posts`, not `/ar`. ## Where people see it * **Project landing** and **App landing** on the custom domain * **Preview** on those landing surfaces and on the portal * **Public intake** links and QR sessions * **Login, invite, and reset password** * **The signed-in portal** (pages, Work, notifications, table and form chrome, calendar controls, and the rest of the chrome) Landing URLs keep a language prefix so a link is shareable (`/ar/works/office`). The portal does not. Signed-in people pick a language from the account menu (or on login). The same cookie carries the choice from the landing into the portal on one origin. A saved profile language comes back on the next device. Ask Building chat to put the language control in your landing header, next to the other links. It looks like **EN | ع | FR**. If the landing has no header control yet, guests still get that switcher above the page. **Back to top** is a separate control on the page after you scroll down. It is not a language control. The portal does not add that bar above the app. Use the account menu or the login switcher. ## Copy and catalog Ask Building chat to translate landing copy (headlines, guest chrome) and portal copy (page titles, nav labels, optional renames of host words such as Work). You do not edit language files yourself. Page headings should be the wording people read. If a heading still shows a `$t(...)` tag, ask Building chat to put that text on the heading itself, not inside the page data a table or card reads from a record. If Building mentions files, landing chrome is stored as `locales/en.json`, `locales/ar.json`, and `locales/fr.json`. Portal pages, nav labels, and optional renames of host words are stored as `locales/portal/en.json` and the matching language files. Those portal files are private. Missing lines fall back to English, then to the key itself, so a page never goes blank. Language checkboxes are live as soon as you save. Host words such as Sign in and Work update right away. Builder copy in `locales/portal/` waits for **Publish**. **Preview → Draft** can show the draft files. Guests and published Preview wait for Publish. Published catalog rows (for example a works list) can store a translated title next to the English field, or a parallel column such as an Arabic title. Guests see the active language, then English. Forms stay one form. Labels, titles, and dropdown choices can be a locale map. Public intake follows `?lang=` and the same cookie. Preview and the portal resolve those maps when the form opens, so a translated dropdown stays readable. You do not publish a second form per language. After landing or file changes, **Publish** so visitors get the new look. Language checkboxes themselves are live. **Preview → Draft** on Project landing or App landing uses that saved list right away, including unpublished public brand colors. Guests still see the last published colors until you Publish. HIPAA-enabled apps cannot use public landings or public intake, so guest languages do not apply there. Portal languages still apply after sign-in. ## How to verify 1. Open **App Settings → Appearance → Languages**, enable English plus at least one other language, and save. 2. Open **Preview**, switch the surface to **Project landing** or **App landing**, and use the switcher. 3. On the public domain, open `/ar` or `/fr` and confirm the URL stays prefixed when you share it. 4. For intake, open the published link and use the language control if more than one language is on. The control uses the same light or dark colors as the form, so the labels stay readable on the header. 5. Sign in to the portal and change language from the account menu. Confirm Work, Sign in (after sign-out), and a translated page title follow the same choice. Forms already follow that language. Table chrome (Search, Actions, empty states), calendar controls, and date or currency formatting follow that language too.