Dialects

Dialects define the output format for structured data. They control how values are serialized when delivered or exported — everything from date formatting and number locale to CSV delimiters and character encoding. A dialect can be shared across schemas or defined inline for a specific schema. Configure dialects in the Schema → Delivery tab. Shared dialects ensure consistent formatting across all your exports without duplicating configuration on every schema.

For example, to configure date formatting for a European accounting system: set date_format to DD.MM.YYYY so dates render as 15.03.2025 instead of the default YYYY/MM/DD. Pair this with number_locale: "de-DE" for comma-decimal formatting (1.234,56) and delimiter: ";" so CSV files open correctly in Excel on European locale machines. Save this configuration as a shared dialect named "EU Accounting" and attach it to every schema that feeds into that system — all future exports and deliveries will use consistent formatting without per-schema configuration.

When working with international data, configure the dialect to match your downstream system requirements. For example, set number_locale to fr-FR for European comma-decimal formatting, switch the delimiter to semicolon for CSV compatibility, and choose UTF-8-BOM encoding if your data will be opened in Excel. Creating a shared dialect and reusing it across schemas ensures consistent formatting across all your exports.

Dialect settings are applied during Phase 4 of the extraction pipeline and during CSV/XLSX export. The dialect does not affect how values are stored internally — it only controls the serialization format when data leaves the platform. This means you can change a dialect at any time without re-running extractions; the new format applies to all future exports and deliveries.

For best results, create a shared dialect for each downstream system or regional office you deliver to, and name it descriptively (e.g., "SAP Europe" or "US Accounting"). Avoid defining dialects inline on individual schemas unless you have a one-off formatting requirement. Shared dialects reduce maintenance burden and ensure consistency when you add new schemas later.

curl -X POST https://api.talonic.com/v1/dialects \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "EU Accounting",
    "date_format": "DD.MM.YYYY",
    "number_locale": "de-DE",
    "delimiter": ";",
    "null_representation": "",
    "boolean_format": "yes/no",
    "encoding": "UTF-8-BOM"
  }'

# Response:
# {
#   "id": "dial_eu_001",
#   "name": "EU Accounting",
#   "created_at": "2025-04-18T12:00:00Z"
# }

curl -s https://api.talonic.com/v1/dialects \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Response:
# {
#   "dialects": [
#     { "id": "dial_eu_001", "name": "EU Accounting", "date_format": "DD.MM.YYYY" },
#     { "id": "dial_us_002", "name": "US Standard", "date_format": "MM/DD/YYYY" }
#   ]
# }

Dialects can be managed programmatically through the full CRUD API: create with POST, retrieve with GET, update with PUT, and delete with DELETE on the /v1/dialects endpoints. This is useful for teams that manage multiple workspaces and want to synchronize formatting conventions across environments. You can export a dialect configuration from one workspace and import it into another by replicating the JSON body, ensuring consistent output formatting across your entire organization.