Localization Sweep

Locale variants, not duplicate objects

A translation in Cosmic is a separate object that shares the original's slug and carries a different locale. That is what links it to its source and what drives the locale switcher in the dashboard and the locale parameter in the API. The workflow never creates a slug like shipping-and-delivery-es, which is the shape you are stuck with when translation is bolted onto a CMS that has no locale model.

The prompt

Translate published pages into {{target_locale}} as locale variants, leaving the originals untouched.

How Cosmic locales work, because this is the part that is easy to get wrong: a translation is a separate object that shares the original's slug and carries a different locale. Never create a new slug like "shipping-and-delivery-es". The shared slug is what links a translation to its source and what makes the locale switcher work.

Prepare.
1. Call get_object_types and read the localization settings of the type you are translating. If "{{target_locale}}" is not in its locales, call update_object_type to add it: localization true, locales set to the existing list plus "{{target_locale}}", and priority_locale left as the source language.
2. If the type has published objects with no locale at all, they predate localization. Stamp each one with the priority locale using update_object so it is recognized as the source of its translations.

Find what needs translating.
3. Call get_objects for published objects in the source locale, then again with locale "{{target_locale}}". Any slug in the first list and missing from the second needs a translation.
4. Translate at most {{max_objects}} objects on this run. Stop at that number even if more remain: translation is output-heavy, and this cap is what keeps the run affordable.

Translate.
5. Translate the title, the body, and any SEO or excerpt fields. Every field, not just the body: a translated page with an English meta description is worse than an untranslated one.
6. Write naturally in {{target_locale}} rather than word for word. Adapt dates, currencies, units, and idioms to what a reader in that locale expects. Leave proper nouns, product names, and code samples in the original.
7. Create each variant with create_object: the same slug as the original, locale "{{target_locale}}", status draft. Drafts, because a human who reads the language should approve the first batch.

Log it.
8. Create one object in the translation-log type recording run_date, target_locale, objects_translated, a markdown summary listing each page you translated, and details as a JSON array of { slug, title_translated }.
9. If a translation already exists but its source has changed since, do not overwrite it. Note it in the summary as needing review, so a human edit is never silently replaced.

Before you point it at your own content

The workflow adds your target locale to the type it is translating on the first run, and stamps the source locale onto any published objects that predate localization so they are recognized as the source. Translations land as drafts: have someone who reads the language approve the first batch before you raise the cap.

Cost

Every translated page produces a full page of output tokens, which makes this the most expensive template in the library per object. Two or three pages a week is a realistic Free plan pace.