Localization

Settings > Localization is where you turn on translated content for a language and region, and choose which one ARCY falls back to when it cannot determine a user's own.

What a locale is

A locale is a language plus a region, written as a code like en-US or tr-TR. English (US) is enabled on every app by default and is where your content lives when you write it. Turkish (Turkey) is the only other locale supported today.

Enabling a locale here does not translate anything by itself. It makes that locale available so translated content can exist for it. You write the translations in the Translation editor further down the page.

Adding a locale

Press New locale, choose the locale from the list, and press Create locale. The only locale you can add today is Turkish (Turkey), since English (US) is already there for every app.

Passing the user's locale

Your install tells ARCY which locale a user is in in one of two ways:

• Pass the locale_code attribute into identify() (or updateUser()) once you know the user, for example right after login.
• Pass contentLocale into arcy.init(token, { contentLocale }) at load time, before you know who the user is. Use this when your app already knows the visitor's region (from the URL, a cookie, or your own settings) before login.

Both set the same thing. If you pass both, the most recent one wins, so a locale_code from a later identify() call overrides whatever contentLocale set at load. Without either, ARCY falls back to the visitor's browser language, then to your agent language, and then to English if no translation exists.

A visitor can override all of it. With two or more locales enabled, the chat panel's Settings sheet carries a Language row where the visitor picks for themselves, and that choice outranks everything above: it is the visitor answering directly, where the rest is your app's or the browser's guess about them. The choice is remembered in their browser. To move a visitor to another language, do it in your own product's settings rather than by re-sending locale_code.

contentLocale is separate from the locale option. locale only sets the language ARCY's agent replies in ("en" or "tr"); contentLocale sets which locale your translated content is served in ("en-US" or "tr-TR"). Most installs want both set to the matching language, but they can differ, for example an agent that always replies in English for a Turkish-region audience.

What language the agent replies in

Under the locales table, Agent language sets two things:

• Language: the agent's default reply language.
• Reply language policy: Match the user replies in the language the user writes in when that is clear, and uses the language above when it is not. Always use the set language replies in the language above whatever the user writes in.

This is the agent's own speech, which is not the same as your translated content: the locales above decide which translations can exist, and the editor below is where you write them. Both settings take effect as soon as you save the page, for every environment.

Translation progress

Under the locales table, Translation progress shows, for each language you have enabled, how much of your translatable content is done. Three numbers, and they mean different things:

• Translated: the text has a translation, and the English behind it has not changed since.
• Missing: there is no translation. Your visitors in that language read the English.
• Stale: there is a translation, but you have edited the English since it was written. It is still served, so it is worth reviewing rather than urgent.

Anything that is not translated is listed by name below the table, so you can see which flow or which field is waiting rather than reading the export to find out.

Writing translations

Below the progress table, the Translation editor is where you type. Pick a language, and every translatable string in your app appears as a row: the English on the left, a field for that language on the right, and the state of the two beside it.

Type in as many fields as you like, then press Save changes in the bar at the bottom of the page. An edited row is marked Unsaved so you can find it again after scrolling, and Discard drops every edit back to what is saved. Each string is written on its own, so a mistake in one never stops the other eighty-three from being saved. If one is refused, the reason appears under that field, your text stays in it, and it stays unsaved for your next press.

You cannot switch language while you have unsaved changes, since the edits belong to the language you made them in. Save or discard them first.

Rows are grouped by area, so your widget texts sit together and each flow's public name and summary sit together. The search box narrows the list by the field name or the English text. The list opens on Not completed when you have anything outstanding, so you land on what is left rather than scrolling past what is finished. A row you just finished stays where it is until you change the filter yourself.

To remove a translation, clear the field and save. The string goes back to missing and your visitors read the English again. This is not the same as leaving a cell blank in a CSV, where a blank cell means "I did not fill this in" and your existing translation is left alone.

A stale row offers Still correct. If you edited the English but the existing translation still reads correctly, press it and the row is queued as a change; the flag clears when you save, without you having to reword good text.

Every field takes attribute references, the same way the field you wrote the English in does. Type {{ and pick from the list, or press Insert attribute above the field. A reference shows as a single highlighted chip rather than raw braces, and one press of Backspace or Delete removes the whole thing.

If the English uses a variable, like a template that greets someone by name, and your translation does not, the row says so. It is a note, not a refusal: your language may not want the name in the same place the English puts it, and the translation still saves.

Editing translations takes admin access, the same as importing a file of them. A member can read the editor but not type in it.

Flow names, and why publishing can be refused

Every flow's public name and summary are translatable, for every flow in your app rather than only the ones you feature. Those two fields are what a visitor reads on a starter flow pill, in the widget's flows list, and on a pill the agent offers mid-conversation, so a Turkish visitor should not be reading English there.

Because of that, a flow cannot be published while a language you have enabled is missing its public name or summary. The refusal names the language and the field, so you know what to add. Add the translations here, then publish.

One case the check cannot reach: flows you published before you added a language. Those keep running exactly as they are, untranslated, rather than being pulled down out from under your visitors. They appear in the list above until you translate them.

The fallback language

Your app has one language setting: Agent language, on this same page. It decides two things at once, which is why there is only one control for it. It is the language your agent replies in, and it is the language a visitor reads when ARCY cannot work out which language they want.

It does not move where your content lives. Setting the agent language to Turkish does not translate anything, and every field you edit in the dashboard stays in English either way.

Removing a locale

Open the row's menu and choose Delete locale. Any saved translations for that locale stop being served, and users on it fall back to your agent language. English (US) can never be deleted, since it is where your content lives.

Don't see your language?

BETA supports English (US) and Turkish (Türkiye) only. Reach out and let us know which language you need next.