Translating Content

Chinaski treats each language version of a page or post as its own content record. This page explains the coverage dashboard that shows what’s missing, the one-click duplication of content into new languages, the workflow tracking for translation teams, and how automated stub-creation fits in.

What gets translated

Every page, post, block, snippet, navigation item, category, and redirect can exist independently per language; a slug can exist in one language, several, or all. Pages and posts can also carry a shared translation key linking their language versions together; translations use the same slug in each language by default.

Setup lives in Settings (language list and default language). The admin interface itself is available in English, Spanish, French, and Portuguese out of the box; that’s interface-language translation, separate from content translation.

The translations dashboard

The Translations page in the admin area is your coverage map. For every content area (pages, posts, blocks, snippets, navigation, categories, redirects, forms), it shows a matrix: each item you have, one column per language, and where each language version exists or is missing.

From that page you can:

Duplicate content into a missing language as a starting draft. The cloned copy carries over everything except the language-dependent work: pages arrive unpublished, posts arrive unpublished with no publish date, and you edit the text in place. Blocks, navigation, categories, and redirects can be duplicated the same way.
Create stubs in bulk: select multiple items and their target languages in one action.
Flip a translation’s published/active state right on the coverage matrix after a version is ready to go live.

Translation workflows

For teams tracking the translation process itself, the Translation Workflows section lets you define reusable workflows, then track each piece of content through statuses like pending, in progress, review, completed, or rejected, with an person assigned to each and free-form notes. Editing a page or post also shows its own coverage: which languages exist, and the current workflow status for the ones in progress.

Coverage is also queryable beyond the admin interface: an API endpoint reports translation coverage per item, and an audit tool produces a plain-text report of every page, post, block, and more, flagging which items are missing translations and which have gone stale (i.e., the source was changed after the language variant last was).

Automated workflows: what “automatic” means here

The automation in Chinaski covers the busywork, not the prose:

Auto-create missing translation stubs (API or tool): point it at any item and it finds every configured language missing that variant, then creates a copy in the default language’s content as an unpublished draft in each. Useful right before assigning translation work.
Bring-your-own translation: the API can also create a full translated copy in one call: the caller supplies the translated title and body, and everything language-neutral (featured image, author, social images) is copied from the source automatically. This is the intended attachment point for an external machine-translation tool or a professional translator’s workflow: the plumbing is yours to connect.

Chinaski does not include a built-in connection to any machine-translation service: nothing is sent to or pulled from translation vendors automatically.

Practical workflow suggestion

Set up your languages and write the source content in the default language.
Duplicate the item (or use auto-created stubs) into the target languages; review the drafts, never enable them prematurely; every clone starts unpublished.
Assign translation work using a workflow: statuses and notes keep the team honest.
When a language version is finished, flip it live from the Translations page or the content editor.
Watch for the MISSING/STALE indicators in your regular audits; stale means the source moved and a variant didn’t follow.

One nuance worth knowing: translation-matching uses the translation key first, falling back to the same-slug rule. If you deliberately give a translation a different slug, also set its translation key; otherwise the coverage map will show that language as missing even though the page exists.