DocsExporting strings into your repo5 min read

Exporting strings into your repo

A file your framework reads directly, named by the keys you chose, built only from the strings your team approved. Inbox → Export for your codebase.

formatshapefor
json{ "checkout.pay": "ادفع" } — flat, key or source text as the namereact-intl, most web i18n
nestedgrouped by screen: { checkout: { pay: "ادفع" } }apps that namespace per screen
arbApplication Resource Bundle, @@locale includedFlutter gen-l10n
stringskey = "value"; one line eachiOS / macOS
csvkey, source, translation, status, contexta spreadsheet, a translation vendor, a diff

Keys are yours, not the SDK's

Every string has an optional key column you edit in the Inbox. It is a name for your codebase, so the SDK never writes it — you do. A dotted name: a letter first, then letters, digits, dots, dashes or underscores, up to 80 characters.

checkout.pay      ✓
checkout.pay-now  ✓
checkout.pay_now  ✓
9checkout         ✗ a letter must come first
checkout.pay!     ✗ no punctuation beyond . - _

The database enforces the same shape, so a key that looks wrong cannot be saved.

Filters

  • Language — one target per file, because that is what a build expects.
  • Include — approved only by default. A file that goes into a build should not carry machine passes nobody read. status=all and status=pending exist when you want them.
  • Screen — context said screen:checkout, so the filter can select exactly that. Name by key or by source text.

Same thing over HTTP

curl
curl -s -OJ \
  -H "authorization: Bearer $SIYAK_TOKEN" \
  "https://your-api-host/v1/projects/$PROJECT/export?format=arb&target=ar&status=approved"

This is the dashboard's own API and its session token, not the SDK key. The response names its own file.

ARB refuses a file whose keys collide and tells you which two clash, rather than shipping a bundle that fails at compile time in someone else's CI. CSV always carries the source text beside the translation, so a diff says what changed in meaning, not just in name.