Repo Onboarding

Adding a repo

Open the Repos screen and paste a repo reference into the input. The app accepts:

owner/name (e.g. vercel/next.js)
https://github.com/<owner>/<name> (with or without a trailing .git)
git@github.com:<owner>/<name>.git
ssh://git@github.com/<owner>/<name> (with or without .git)

Click Add and the app runs gh repo clone for you. You don’t need to clone the repo yourself, and there is no folder picker — the app manages the clone end to end.

Other Git hosts are rejected with a “GitHub repositories only” error.

Where the clone lives

On macOS, clones are stored under the app’s data directory:

~/Library/Application Support/io.stape.your-last-translation-tool/repos/<owner>/<name>/

This is an implementation detail. You don’t normally need to open or edit anything in there — the app drives git for you. It’s documented here so you know where to look if you’re curious or debugging.

Configuring projects

The first time you open a repo, the app runs the config wizard. It saves to local app storage, not to the working tree, so adding a repo never produces stray files in your git status.

The wizard collects, per project:

Project name — a label for this set of locales (e.g. web, marketing).
Locales directory — relative to the repo root (e.g. apps/web/locales).
Source language — the language you translate from (e.g. en).

Discovery seeds these defaults from the on-disk folder layout, so for a typical monorepo you can usually accept the suggestions and move on. You can add more projects from the wizard before saving.

`.translations.json`

The local store is the source of truth for repo configuration. The app does not write .translations.json into the working tree by default, and /.translations.json is in .gitignore.

The schema still exists — see the .translations.json reference — because the file is used by the optional Export to repo flow described below.

Export to repo

If your team wants to share project defaults so a teammate’s first run skips the wizard, the wizard exposes an opt-in Export to repo as .translations.json action. It writes the file into the working tree as an unstaged change — the app does not commit it. Commit and push it through your normal git flow (typically the same PR as the change that introduced it).

Use this when the defaults are stable and you want them tracked alongside the code. Skip it for one-off setup or anything you’d rather keep on your machine only.

Editing the config later

The Repo Overview screen has an Edit project config button that re-opens the wizard with the current values pre-filled. Save again to update the local store. Changes take effect immediately — no restart, no branch switch needed.

Removing a repo

The trash/X button next to a repo opens a Remove clone confirmation that names:

the owner/name of the repo,
the on-disk size of the clone,
how many drafts you have for it,
how many viewed-marks you’ve recorded.

Confirming deletes the local clone only. The GitHub repository is untouched — drafts and viewed-marks tied to the local clone are removed along with it. To start over, add the repo again from the picker.

Validation errors

If a saved config fails to parse (most often after a manually-edited .translations.json is imported), the app shows a list of per-field issues with dotted paths — e.g. projects[0].localesDir is required.

Fix the offending fields and click Recheck. The app re-validates without needing a restart.