Docs: Adding to CONTRIBUTE.md for translations

CONTRIBUTE.md

@@ -104,6 +104,17 @@ export default defineConfig({
 
 `boboko()` owns the Vite settings the local-mode symlink needs, so consumers don't hand-copy them: it excludes `@boboko/core` from dependency pre-bundling (otherwise Vite serves a stale cached copy after you edit core), pre-bundles `leaflet`/`@hotwired/stimulus` explicitly, and turns on `resolve.preserveSymlinks` and `server.watch.followSymlinks` so bare imports resolve from the consumer's `node_modules` and core edits trigger HMR. All of it is a harmless no-op against a real installed copy in repo mode.
 
+## Translations added in the UI
+
+Default translation lines ship in core's seeders (`StorefrontTranslationsSeeder`, `CheckoutTranslationsSeeder`, `ValidationTranslationsSeeder`), which every app runs on boot and which only ever add missing keys. Lines added while building a storefront usually start in the Filament Language Lines UI instead. To move them into core:
+
+```bash
+bin/dc-core.sh exec app php artisan boboko:translations:pull            # local mode: writes into ../boboko-core
+bin/dc exec app php artisan boboko:translations:pull --dry-run          # any mode: just list them
+```
+
+It adds every `storefront` / `checkout` / `validation` key that's in the database but not in the matching seeder, appended at the end of `lines()` under a marker comment — move them into the right section before committing. Keys the seeder already has are never touched, even if their text was edited in the UI. `bin/deploy` runs it for you.
+
 ## Releasing a version
 
 1. Bump `"version"` in **both** `composer.json` and `package.json` — they must match.
@@ -122,9 +133,10 @@ A tag alone changes nothing in production — each consumer app has to pick it u
 Production only ever runs what the app's **committed lockfiles** pin. Each consumer app ships `bin/deploy`, which:
 
 1. Refuses to run on the wrong branch, with uncommitted changes (other than the core wiring files), or behind `origin`.
-2. Runs `bin/core-mode repo` — switching from local mode if needed, restarting either way — so both lockfiles resolve the newest `0.x` tag. It warns if `../boboko-core` has a newer tag than what resolved (usually an unpushed tag).
-3. Commits the lockfile bump (`Chore: Bumping boboko/core to X.Y.Z`) if there is one, shows what will be pushed, and asks for confirmation.
-4. Pushes, then runs `vendor/bin/envoy run deploy` against the host in `.env.envoy`.
+2. Runs `php artisan boboko:translations:pull` (see [Translations added in the UI](#translations-added-in-the-ui)). In local mode, if it pulls any lines into `../boboko-core`, it stops — commit, tag and push core, then rerun. In repo mode it only checks, and stops if the database has lines core doesn't.
+3. Runs `bin/core-mode repo` — switching from local mode if needed, restarting either way — so both lockfiles resolve the newest `0.x` tag. It warns if `../boboko-core` has a newer tag than what resolved (usually an unpushed tag).
+4. Commits the lockfile bump (`Chore: Bumping boboko/core to X.Y.Z`) if there is one, shows what will be pushed, and asks for confirmation.
+5. Pushes, then runs `vendor/bin/envoy run deploy` against the host in `.env.envoy`.
 
 Envoy (`Envoy.blade.php`) then, on the server: `git reset --hard` + `git pull`, `docker compose build` (the `production` image target runs `composer install --no-dev` and `npm ci` from the committed lockfiles — this is where the core tag actually lands), `up -d`, caches config/routes/events, restarts `queue` and `scheduler`, and regenerates Stoic thumbnails. The production entrypoint skips Composer entirely and runs migrations (including core's), seeders, the Meilisearch sync, and `artisan optimize`.