Repo Onboarding

Opening a repo

When you launch your-last-translation-tool and pick a folder, the app expects a local git clone of a GitHub repo. It does not clone repos for you — clone first, then open.

The app checks:

The folder is a git repository (git rev-parse --show-toplevel succeeds).
The repo has a GitHub remote (so PRs can be created).
.translations.json exists and is valid.

`.translations.json`

This file lives at the repo root and tells the app where your translation files are. See the .translations.json reference for the full schema.

Minimal example

{
  "projects": [
    {
      "name": "web",
      "localesDir": "apps/web/locales",
      "sourceLanguage": "en"
    }
  ]
}

Multi-project example

{
  "projects": [
    {
      "name": "web",
      "localesDir": "apps/web/locales",
      "sourceLanguage": "en"
    },
    {
      "name": "marketing",
      "localesDir": "apps/marketing/i18n",
      "sourceLanguage": "en"
    }
  ]
}

When `.translations.json` is missing

The app shows the config wizard — a short form that collects the required fields for one or more projects.

Fill in the project name, locales directory (relative to repo root), and source language.
Click Add project to add more projects if needed.
Click Save. The file is written to your working tree but not committed — it appears as an unstaged change in git.
Committing and pushing the file happens through the regular save/PR flow.

When `.translations.json` is invalid

The app shows a list of per-field errors with JSON-pointer paths (e.g., projects[0].localesDir is required).

Fix the offending fields in the file, then click Recheck. The app re-validates without needing a restart.

Language autodetection

You do not declare languages in .translations.json. The app scans <localesDir>/* and treats every subfolder matching the BCP 47 pattern (en, uk, pt-BR, etc.) as a language. To add a new language, create the folder.

Folders like _archive/ or files like README.md are ignored automatically.