Connectors

What it does#

Most translatable content does not live in uploaded files, it lives in Airtable, Jira, a CMS, a help center. Connectors reach into those systems, translate content in place, and write each language back as the source system's own per-locale version, either on a one-click "Translate now" or on a signed webhook when content changes.

The differentiator is source-context harvest: when a connector ingests content, it captures the source system's own metadata, the article title, its section, its labels, directly into the translation context, so the model translates knowing what kind of content it is looking at. That context is allowlisted, sanitized, and layered below anything you set explicitly.

A connector kind can be individually enabled or disabled per install without touching the connections themselves. The Connectors section overall is core and always on; only individual kinds toggle.

Getting started#

Pick a kind on the Connectors page and fill in its fields, or create one from the CLI:

connector create --kind airtable --name "Support base" \
  --config base_id=... --secret api_token=...

Then translate the matched content:

connector sync 5

That pulls the content, translates it, and pushes each language back in one step. You can also wire a webhook so the system is notified automatically when content changes, or set a schedule, instead of running it by hand.

Works with#

• Documents: a connector pulls external content into an ordinary document, so parsing, the editor, QA flags and export all apply exactly as they would to an uploaded file.
• Workflows: translating a connection's content runs through the normal machine-translation workflow, with the same run view and spend safety as any other translation.
• Glossaries: harvested source metadata enriches the translation context alongside glossary and content-type context.
• Engines: a connection can override the provider for its content; otherwise it uses the project's engine.

Current limits#