Formality

Many languages have two ways to say "you": German Sie / du, French vous / tu, Spanish usted / tú. Apps choose on purpose, and often differently per language: a consumer app may use du in German but vous in French. Formality sets the form per language, so the translator never has to guess and never mixes the two.

Levels

The translator is told the concrete forms for the language, including verb forms and possessives (for example "Klicken Sie" vs "Klicke", "Ihr" vs "dein"), which a glossary entry can't express. Languages without the distinction (English, Arabic, Hebrew, …) ignore the setting.

A setting for a base language covers its regional variants: de applies to de-AT and de-CH, unless they have their own entry.

Formality applies to LLM translation (your own key, or Babelize-hosted with an LLM). The NLLB translation model can't be told a form of address.

Setting it

Dashboard: open the project and pick a level per language in the Form of address card. Only languages with a formal/informal split are listed.

CLI and MCP, local runs: add formality to .babelize/config.json, or pass it per run:

{
  "formality": { "de": "formal", "fr": "formal", "it": "informal" }
}

npx babelize translate --to de,fr,it --formality de=formal,it=informal

The babelize_translate MCP tool takes the same map as its formality parameter. Flags and parameters are merged over the config file.

Cloud projects from the terminal: babelize projects formality <id> --set de=formal.

What changes on the next run

Setting a language to formal or informal, or changing it, re-translates that language's strings that Babelize wrote. Strings you or your translators wrote into your own locale files, and edits made in the dashboard, are kept. Going back to auto from a language that never had a setting changes nothing.

Translations for a language with a set form of address get their own cache entries and stay out of your shared translation memory, so another project with a different setting never reuses them.

Detected from your existing translations

When Babelize translates an app's existing i18n setup and a language is on auto, it reads that language's current translations. If they clearly use one form (for example most German strings say "Sie" and "Ihr"), new and updated strings follow it, and the summary says so:

de formality: formal (detected from the existing translations). Set "formality" in .babelize/config.json to change it.

Checking for mixed forms

babelize check and babelize review warn (mixed_formality) when a locale mixes both forms: strings using the minority form are listed, or, with a level set, strings using the other one. New translations get the same QA note in the run report.

Brand voice

The brand voice sets tone and style; formality sets the form of address. When both are set and disagree, the formality setting wins for the form of address. Locally, set the brand voice with brandVoice in .babelize/config.json or --brand-voice:

{
  "brandVoice": "Warm, direct and encouraging. Short sentences.",
  "formality": { "de": "informal" }
}