SalesOS

Custom labels and translations

Reusable tenant text and translations of your own metadata — labels, objects, fields, picklist values, flow screens and page titles — per language.

SalesOS translates its own interface (English, Spanish, French, German). What it can't know is your text: custom object and field labels, picklist values, flow screens, page titles. Translate those under Settings → Organization → Translations.

Custom labels

A custom label is a named piece of text, { name, value, description?, category? }. Use it as {!$Label.<name>} in flow screens, emails and page builder titles; it renders in the reader's language, falling back to its default value. Anyone in the org can read labels; org owners and admins manage them.

GET    /v1/custom-labels?search=&page=&limit=
POST   /v1/custom-labels          { "name": "Welcome", "value": "Welcome back" }
PATCH  /v1/custom-labels/{id}
DELETE /v1/custom-labels/{id}

Translation keys

Every translatable string has a key; its source text always comes from the metadata itself, so renaming a field shows its translation as outdated.

KeySource
label.<name>a custom label
object.<api>.label, object.<api>.pluralLabela custom object
object.<api>.field.<field>.label / .helpText / .option.<value>a custom object field and its picklist values
field.<ENTITY>.<name>.label / .helpText / .option.<value>a custom field on a standard object (LEAD, CONTACT, ACCOUNT, OPPORTUNITY, …)
flow.<api>.label, flow.<api>.<element>.<field>.label / .helpText / .text / .option.<value> / .validation, flow.<api>.<element>.label / .nextLabel / .subject / .body / .messagea flow
page.<api>.<component>.title, page.<api>.<tab>.labela page builder page

Locales are language codes (es, fr, de, pt-BR…): es, fr and de always, plus every language the org adds under Localization. An exact locale (fr-CA) wins over its language (fr).

Where translations apply

  • API responses keep the source text. A label, field or option read through the API is the text the admin typed. Clients translate with the bundle.
  • The SalesOS app loads the bundle for the user's interface language and swaps in translations by key (custom object names and fields, custom field columns), falling back to the source.
  • Server-rendered text uses the reader's locale: flow screens render in the runner's interface language; flow emails in each recipient user's language (the runner's for other addresses).
GET  /v1/translations/bundle?locale=fr       { locale, messages: { key: text }, labels: { name: text } }
GET  /v1/translations/locales
GET  /v1/translations/workbench?locale=fr&status=untranslated|translated|outdated|all&type=&search=&page=&limit=
PUT  /v1/translations/workbench              { "locale": "fr", "entries": [{ "key": "label.Welcome", "value": "Bon retour" }] }
GET  /v1/translations/export?locale=fr       CSV: key,type,context,source,translation
POST /v1/translations/import                 { "locale": "fr", "csv": "…" }

An empty value removes a translation. Import reads the key and translation columns, skips blank translations and reports keys that no longer exist. The workbench, import and export need an org owner or admin.

Metadata

Labels move as CUSTOM_LABEL components (labels/<name>.label.json) and translations as one TRANSLATION component per locale (translations/<locale>.translation.json, { locale, translations: { key: text } }). A deploy adds and updates translations; it never deletes keys the file leaves out (list the component for deletion to remove a whole locale).

On this page