Translation recovery

Glossia validates translated content before publishing it. Recovery preserves that requirement: a retry must still preserve the source structure and required placeholders, and every assembled file passes its configured validation commands.

Catalog translation

Gettext catalogs are parsed into strings before translation. Requests carry at most eight strings, with an 8,000-byte batching target. A single larger string stays intact. The model returns an array with the same number of strings in the same order. Glossia checks interpolation variables and rejects empty translations.

Headers are built in code using the target locale's plural rules. Source message identifiers, comments, and catalog structure come from the parsed source. If a batch returns malformed content, Glossia retries it once, then splits it into smaller batches. Successful neighboring batches do not need to be translated again.

Provider throttling

Workers using the same credential and model share request admission through the database, including workers on different application replicas. A rate-limit response extends their shared cooldown and increases spacing between new requests. Successful traffic gradually reduces that spacing after a minute without throttling. Already-running requests are allowed to finish.

Provider retry hints are minimum delays. Repeated failures also increase the backoff, up to a 30-second base delay plus jitter; a longer provider hint takes precedence, capped at five minutes. Together's x-ratelimit-reset header is recognized alongside retry-after.

After eight unsuccessful request attempts, the repository run stops starting new files. A delayed continuation inherits the translation branch and resumes its unfinished work. The previous attempt remains visible in session history, linked through the continuation. Delays increase from one minute to five minutes, with at most six automatic continuations. Newer active sessions take precedence, and cancelled sessions are never revived. Validation failures alone do not schedule provider recovery.

Durable progress

Completed files and their lockfiles are published to the translation branch as before. Within unfinished files, locally validated segments and recovery batches are also saved in the database for seven days. These checkpoints survive a worker process stopping. They are scoped to the account, project, document input, effective credential and model, context, and segment or repair attempt.

A resumed run can reuse a segment only when its inputs still match. It always validates the final assembled document again. Rejected model responses are not checkpoints. A document-level validation failure starts a separate repair attempt because the validator may not identify a single responsible segment.

Expired checkpoints and inactive provider pacing records are removed by the scheduled session recovery worker. These are operational records; users do not need to add them to their repository or configure them in L10N.md.