Workflow route 02

Choose a Translation Workflow

Use the manual two-round workflow when you want portable files and direct review control. Use automatic translation when you want WordPress to call your configured API provider. Use Incremental only after content has a known translated state and you need to process later changes.

Portable file workflow

Manual two-round translation gives you the most visible control.

The first round creates reviewed translations from the protected source package. The second round examines the body copy visitors actually receive after import, so it can find problems that isolated CSV cells cannot reveal.

  1. 01

    Export an AI Work Package ZIP from the default-language pages.

  2. 02

    Process the complete ZIP with translatepress-ai-work-batch.

  3. 03

    Import the returned reviewed ZIP using Standard / resumable.

  4. 04

    Create an AI Review Package from Review Export.

  5. 05

    Review it with the same Skill, import targeted corrections, and verify the live pages.

StagLingo Workflow Guide showing the manual two-round translation process
Choose this route when: package visibility, separate review, portability, and explicit import control matter more than completing everything inside the WordPress dashboard. Do not edit protected identity fields such as post_id, source_url, content_type, exact_english_source, or source_hash.
API workflow

Automatic translation runs the protected workflow inside WordPress.

Configure OpenAI, Google Gemini, Anthropic Claude, or an HTTPS OpenAI-compatible endpoint in AI Models. StagLingo then sends requests from the site to the selected provider and uses the same protected import core for accepted results.

Standard

One integrated pass

Creates an immutable source snapshot, runs the model pass, validates the result, and imports it through the protected writer.

Enhanced

Rendered second review

After the first import, fetches the translated front end, creates targeted corrections, imports again, and scores the result.

StagLingo Automatic Translation settings in the WordPress administration area
Separate provider access is required: StagLingo does not include an AI subscription, API credits, or provider usage. Existing non-empty translations are preserved unless replacement is explicitly enabled.
StagLingo Incremental dashboard for tracking changed translation identities
Maintenance workflow

Incremental translation is for content that already has a trustworthy baseline.

StagLingo inventories current page-owned English identities and language status. Later, it can export only identities that are new, changed, missing, or still waiting for front-end confirmation.

Critical baseline rule

A baseline does not scan translation quality, create translations, or validate the front end. It declares the selected scanned work complete. Never baseline a page or language that is still missing translations.

Decision table

Compare control, access, and project state.

Choose one primary route for the current task. A site can use different routes at different times—for example, manual translation for the first release and Incremental for later source-page changes.

Question Manual two-round Automatic Incremental
Primary purpose Create and independently review new translations through portable files. Create translations through a provider API from WordPress. Maintain already translated pages after source content changes.
External requirement A ChatGPT account or workspace that can use the supplied Skill workflow. A supported API provider, API key, model access, and available usage. A truthful completed state, plus either the Skill route or a compatible package process.
Package visibility Highest: export, keep, inspect, and import the packages yourself. Lower: source snapshot, model work, and protected import run inside WordPress. Exports only the tracked identities that currently require work.
Second rendered review Use Review Export and the Skill as a separate second round. Use Enhanced to perform the rendered correction stage automatically. Use Review Export when changed content needs front-end language review.
Best starting condition New, untranslated, partially translated, or audit-heavy content. New or partially translated content with configured provider access. Pages and languages that are already translated and correctly tracked.
Do not choose it when You need an entirely unattended API-driven run. You do not have suitable API access or want to inspect every intermediate file. The selected pages or languages are not actually translated yet.
Simple default: if you are unsure, start with the manual two-round workflow on one test page. It makes each handoff visible and gives you a clear front-end review stage before you scale the process.
Applies to every route

The workflow changes. The publishing checks do not.

Translation storage success and visible front-end success are related but not identical. Cache, conditional widgets, rotating content, and dynamic owners can affect what an immediate request confirms.

01

Protect unfinished URLs

Use Index Control to keep incomplete page-language versions noindex, follow until translation and review are complete.

02

Read import results correctly

Validation, backup, transaction, or storage read-back failures require action. A front-end confirmation warning requires checking the actual translated URL.

03

Verify what visitors receive

Clear relevant caches, open the target-language page privately, inspect visible copy and attributes, and use Review Export when a correction is needed.