io.github.AronSoto/verbaly

Diagnose a Verbaly project end to end (what `verbaly doctor` does). It checks the config file, the catalogs and their JSON, the bundler plugin for the detected framework, the generated types, files the parser could not read, a t imported from a package that never exports it, orphan keys, and every failure `verbaly check` would report, and it reports them all at once instead of stopping at the first. Run it first when something does not work. Read-only. For the missing or broken translations themselves, use verbaly_missing.

Every machine translation still waiting for a human, each with the source text and what the provider wrote, so a person can read both and decide. Read-only. Approving is deliberately not a tool here and never will be: a machine translation is unreviewed by definition, so accepting one is `verbaly review --approve`, run by a human. For how many drafts each locale has, verbaly_status is enough; verbaly_missing lists them next to the gate.

Scan the source files, add new messages to the locale catalogs and refresh the generated types (what `verbaly extract` does). It writes the catalogs unless dryRun is set, and with the same code a second run changes nothing. prune also drops keys the code no longer references, translations included, and waits while any source file fails to parse. In a project without Verbaly, run verbaly_init first; for text still hardcoded in JSX, verbaly_wrap.

Create the config file and the locale catalogs, and detect the bundler or meta-framework so the answer names the package to add and the line to wire (what `verbaly init` does). A file already there is kept, never overwritten, so running it again is safe. Use it when verbaly_doctor finds no config; once the project is set up, verbaly_doctor is the one to run.

The gate `verbaly check` runs in CI, as lists: missing translations, unknown keys, keys written with two texts (collisions: every place shows the first text) and translations that cannot render what the source renders. A dropped {param}, a lost rich tag or a flattened plural block is that last kind. Warnings never fail the gate and are listed too: an incomplete plural set for the locale, keys only a translation has (extra), texts the code and the source catalog disagree on (divergent: the text in the code ships) and translations written for an older source text (outdated). With drafts set, it also lists the machine translations awaiting review. Read-only. For counts use verbaly_status, to review drafts with their source text verbaly_drafts, and for setup problems verbaly_doctor.

Translation coverage of the Verbaly project as numbers per locale: total messages, translated, machine translations awaiting review (drafts), broken, and translations written for an older source text (outdated). It scans the source like verbaly_extract but writes nothing. Read-only. For the entries behind the numbers, use verbaly_missing (what is missing or broken) or verbaly_drafts (each draft with its source text).

Fill missing translations with the configured provider (what `verbaly translate` does). The default provider is Claude, which needs @anthropic-ai/sdk and ANTHROPIC_API_KEY. Every new translation is saved as a draft awaiting human review (`verbaly review`), which no tool here can approve. A batch the provider never answers is reported in failed and everything else stays written, so a retry only asks for what is left. dryRun lists what would be translated without calling the provider. To see what is missing first, use verbaly_missing; to save translations you wrote yourself, verbaly_write_drafts.

Find hardcoded user-visible text in JSX/TSX files and wrap it in a t tagged template so the compiler can extract it (what `verbaly wrap` does). This is how an existing codebase is onboarded, and verbaly_extract then adds the wrapped texts to the catalogs. It only reports unless write is set, and text already wrapped is skipped, so running it again is safe. Text it cannot wrap safely (a sentence split across markup, an expression rendering JSX) is listed as needing a human. A file that does not bind t is never written, because the rewrite would not compile. It comes back in blocked, with whether it is a client component, so you can add the binding and run again.

Save translations you wrote yourself, so neither a catalog nor the state file is ever edited by hand. Each one is checked the way verbaly_translate checks a provider (params, rich tags and plural cases must survive), written only for keys the source catalog has, and marked as a draft awaiting human review. Existing translations are kept unless overwrite is set, which is how an outdated one gets rewritten. Approving is not a tool here: a human reads the drafts (verbaly_drafts lists them) and runs `verbaly review --approve`.