Skip to main content

Shared Dialects

Shared dialects define workspace-wide output formatting rules that apply across all schemas. Instead of configuring formatting per schema, set workspace defaults for date format, number locale, CSV delimiter, null representation, boolean format, and encoding.

Manage dialects from the Spec composer (/specs): open the "Manage dialects" drawer on the Data Product stage to edit workspace-level formatting. Individual schemas can override these defaults with inline dialect definitions when needed.

Opening Workspace Settings

Workspace Settings opens from the user menu at the bottom of the sidebar, between Account Settings and Team Members (route /settings). Every member can open it: below the Admin role the page renders read-only and each section gates its own writes, so a Viewer or Member can see how the workspace is configured without being able to change it. Its tabs are Workspace (ingest stages and document display names), References, Ontology, Change Review, Automation, Collections, and Archive. Shared dialects are workspace-level too, but you edit them from the Spec composer as described below, and the AI Policy is managed through the /v1/ai API.

The interface language is not a workspace setting. Each user picks their own under Account Settings (Choose the interface language): English, Deutsch, Español, Français, Italiano, Português (Brasil), or Português (Portugal). Changing it only changes the labels you see; it never changes the output format of your data. A dialect's number locale and date format stay fixed for every delivery, whichever language each reviewer reads the app in, so a team spread across countries can share one workspace and still deliver one consistent format.

Dialects ensure consistency across all your structured output. When your downstream systems expect dates in YYYY-MM-DD format, numbers with . as the decimal separator, and CSVs delimited by ;, you configure this once in the shared dialect rather than repeating it in every schema.

Most teams configure their shared dialect during initial workspace setup and rarely change it afterward. If your organization operates across regions with different formatting conventions, create separate workspaces with region-specific dialects rather than overriding at the schema level. This keeps the configuration clean and avoids inconsistencies in delivered data.

  • Date format — control how dates are serialized (e.g., YYYY-MM-DD, DD/MM/YYYY, MM-DD-YYYY).
  • Number locale — set the decimal separator and thousands grouping.
  • CSV delimiter — choose comma, semicolon, tab, or pipe for CSV exports.
  • Null representation — define how missing values appear (empty string, NULL, N/A, etc.).
  • Boolean format — a [true_value, false_value] pair, e.g. ["true", "false"], ["Yes", "No"], or ["1", "0"].
  • Encoding — set the character encoding for file exports (UTF-8, ISO-8859-1, etc.).
Manage shared dialects via API
# List workspace dialects:
curl -s https://api.talonic.com/v1/dialects \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Create a shared dialect (boolean_format is a [true, false] pair):
curl -X POST https://api.talonic.com/v1/dialects \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "US Standard",
    "date_format": "MM/DD/YYYY",
    "number_locale": "en-US",
    "delimiter": ",",
    "null_representation": "",
    "boolean_format": ["true", "false"],
    "encoding": "UTF-8"
  }'

# Update an existing dialect. PUT is a partial update: only the keys
# present on the body are patched, and the stored version is bumped.
curl -X PUT https://api.talonic.com/v1/dialects/dial_us_002 \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "encoding": "UTF-8-BOM" }'

Shared dialects are a workspace-level configuration that eliminates formatting inconsistencies across your output. Without them, each schema might use slightly different date formats or number locales, creating data quality issues when records from different schemas are combined in downstream systems. By configuring the dialect once at the workspace level, every schema inherits the same formatting rules automatically. This is particularly important for organizations with multiple teams creating schemas independently — the shared dialect ensures they all produce structurally consistent output regardless of who created the schema or when.

When a schema defines an inline dialect, it takes precedence over the shared dialect for that schema only. All other schemas continue using the workspace defaults. This lets you handle special cases without affecting the rest of your output.

Frequently asked questions

What are shared dialects?+
Shared dialects are workspace-wide output formatting rules that define defaults for date format, number locale, CSV delimiter, null representation, boolean format, and encoding across all schemas.
Does the interface language change the output format?+
No. The interface language is a per-user choice in Account Settings and only changes the labels you see. Date formats, number locales, and delimiters in delivered data come from the dialect, so every delivery stays consistent.
Can individual schemas override shared dialects?+
Yes. Individual schemas can override workspace-level shared dialect settings with inline dialect definitions when specific formatting is needed.
When should I use a shared dialect vs an inline dialect?+
Use shared dialects for workspace-wide defaults that apply to most schemas. Use inline dialects only when a specific schema needs different formatting — for example, a schema that outputs dates in DD/MM/YYYY for a European ERP while the rest of your workspace uses YYYY-MM-DD. Inline overrides apply only to that one schema, so they do not affect any other output. If you find yourself overriding the same setting in multiple schemas, consider updating the shared dialect instead.
Do shared dialects affect the extraction process?+
No. Dialects only affect output formatting — how extracted values are serialized in exports and deliveries. The extraction and validation phases work with normalized internal representations regardless of dialect settings.
How do I manage shared dialects across multiple workspaces?+
Use the dialect API (GET, POST, PUT, DELETE on /v1/dialects) to export a dialect configuration from one workspace and replicate it in another. This ensures consistent formatting across your entire organization. If different regions need different formats, create separate workspaces with region-specific shared dialects rather than managing inline overrides on individual schemas.

Related

Dialects
Delivery Pipeline
Reference Primitives