Documentation

GitHub sync

Connect a repository and let ParlanceKit open pull requests with your translations.

Repository sync fetches your source file, translates what has changed since the last run, and opens a pull request with the updated translation files. Nothing merges without your review, and your translated files live in your repository — not on our servers.

Connect

  1. In Settings, connect GitHub and authorize the ParlanceKit app for the repositories you want.
  2. Add a repository configuration: the source file path, a target file pattern, and your target languages.
  3. Optionally link a saved configuration so tone, glossary, and context apply to every sync.
  4. Press Sync. The job is queued and a worker picks it up.

Where settings come from

A sync resolves its translation settings in this order. The first source that exists wins.

  1. parlancekit.config.json committed at the root of the repository.
  2. The configuration linked to the repository in the dashboard.
  3. Built-in defaults — neutral tone, default formality, your organization's provider.

When a config file is present, it is the source of truth for that repository — its source file, target pattern, and target languages take precedence over anything set on the repository in the dashboard. Committing a config file also means your CLI runs and your syncs behave identically.

Editing config from the dashboard

You do not have to hand-edit parlancekit.config.json. The repository card in Settings is an editor on top of that file: change the source path, target languages, pattern, tone, glossary, skip and preserve rules — anything the file can hold — and save.

Saving does not commit to your branch directly. ParlanceKit opens a pull request that adds or updates parlancekit.config.json, exactly the way translations arrive. You review the diff — including changes that matter, like dropping a language from the target list — and merge when you are ready. The next sync reads the merged file.

Config changes travel the same review path as translations because they can be consequential — changing target languages, for example, changes what future syncs translate. A pull request gives you that checkpoint, and it works with protected branches, which a direct commit would not.

Editing config and then syncing can open two pull requests: one for the config change, one for the translations. They are separate concerns on separate branches. Merge the config PR first if you want the sync to pick up the new settings.

You can also download the file instead of opening a pull request — useful if you would rather commit it yourself, or keep it alongside a CLI workflow. Either way, the committed file is what every sync reads.

Who can change what

Configuring a repository, editing its config, opening a config pull request, and deleting a repository configuration are limited to organization admins and owners. Downloading the config file is available to anyone, since it only produces a file locally and changes nothing.

Incremental syncs

ParlanceKit keeps a snapshot of your source strings from the last sync. On the next run it compares against that snapshot and translates only what is new or changed. Strings you have not touched are left alone and are not billed again. Keys removed from the source are pruned from the targets.

The snapshot holds source strings only. It is overwritten on every run rather than accumulated into history, and it is deleted when you remove the repository, the configuration, or your account.

Reliability

Syncs run as background jobs. If a worker restarts mid-sync the job is requeued and retried, and billing is applied exactly once regardless of retries. Only one sync runs per repository at a time; pressing Sync while one is in flight returns the job already running.