Localization and Publishing Operations

Adding a second language is where content operations stop being a single stream and become a set of parallel ones, each with its own state, its own owner, and its own chance to drift out of date.

This lesson covers how localization works in Cosmic, how to translate at volume without translating by hand, and the two safety nets worth having in place before more people can publish.

---

Before You Start

• Bucket Admin or Developer access, since this involves editing object types

• The Localization add-on. It is enabled at the project or workspace level under Billing > Add-ons, and feature add-ons include a 14-day free trial. Without it, the localization settings show Upgrade to use Localization

---

Step 1: Turn On Locales for an Object Type

Locales are configured per object type, not per bucket, so you can localize your posts without localizing your internal settings.

1. Open Object types in the sidebar and click the cog on the type you want

2. Go to the Additional settings tab

3. Find the Localization section

4. Use Select locale(s) to choose the languages you want

5. Set a Priority locale

6. Click Save

The locale list is fixed rather than free text, and covers over 400 options. Codes follow the standard pattern: , , , , , , .

Choose between and deliberately. Regional codes are the right call if you will genuinely write different copy for Spain and Mexico. If you will not, the generic code saves you from maintaining two identical translations forever.

The Priority locale matters more than it looks, and the next section explains why.

---

Step 2: How Localized Content Is Actually Stored

Getting this wrong causes most localization confusion, so it is worth being precise.

Each locale is a separate object with its own ID. They are not fields on one object, and they are not versions of one object. What ties them together is a shared slug: in English and in Spanish are two distinct objects with the same slug and different locale values. Uniqueness is enforced on the combination of slug, object type, and locale.

Three consequences follow from this:

Each locale has its own status. The English version can be published while the Spanish one sits in draft. That is a feature, but it means "is this page live" is a question you have to ask per locale.

Each locale is edited independently. Changing the English copy does not flag the Spanish version as stale. Nothing tells you the translation has drifted, so keeping them in sync is a process problem, not something the CMS solves for you.

Each locale counts as an object against your plan's limits. Five hundred posts in four languages is two thousand objects.

---

Step 3: Create a Localized Version

Open an object. In the sidebar there is a Localization section.

If the object has no locale yet, click Enable Localization to bring it into the system.

From the locale dropdown you then have two ways forward.

Add new locale creates an empty version in the locale you pick, for you to fill in. Use this when a market needs its own copy rather than a translation, which is often true of landing pages where the argument itself differs by region.

Generate new locale uses AI to translate every field into the target language. A Confirm Auto Translation dialog appears first, and the result is saved as a draft rather than published.

That draft behavior is the important part. Machine translation is a strong first pass and a poor final answer, particularly for product names, idioms, and anything legal. The draft is where a native speaker earns their keep.

Back in the objects list, a Locale column appears on localized types, and Locale is available as a filter. That filter is how you answer "what is still missing in German."

---

Step 4: Request a Locale from the API

Add to your query:

There is no fallback. If you ask for and no Spanish version exists, you get a 404, not the English one. Cosmic will not silently serve a different language than the one you requested, which is correct behavior but means your code has to decide what to do about it:

Decide the fallback policy before you build the pages. Serving English to a Spanish visitor is one reasonable answer; a 404 with a language switcher is another. Silently doing neither, and crashing, is the one you get by default.

If you omit entirely on a localized type, you get objects with no locale set plus the priority locale. That is what the Priority locale setting controls, and it is what keeps existing queries working when you add localization to a type that already has content.

---

Step 5: Translate at Volume

Translating a hundred posts one Generate new locale click at a time is not a process.

Cosmic has an agent template for this: Lina, Translator & Localization Manager. Go to Agents, click New Agent, find her on the Use a template tab under the content category, and click Hire Lina. Her stated job is translating content into multiple languages and managing localized versions.

Two ways to use her:

Give her a batch directly, such as translating everything in a category into two locales, and review the drafts she produces.

Or put her in a workflow. A step that translates after a post is published turns localization from a project into a background process. Lesson 10 covers the triggers, and an approval gate before publishing keeps a person in the loop.

---

Step 6: The Safety Net

More languages and more people mean more ways to publish something wrong. Two add-ons address different failure modes.

Revision History keeps prior versions of every object. In the object sidebar, a History section lists recent revisions, and opening one gives you Restore draft, which brings that version back as a draft rather than overwriting what is live. Enabling it unlocks versions from before you turned it on, which is a pleasant surprise the first time you need it.

This is the everyday recovery tool: someone overwrote a section, a translation replaced the wrong field, an agent did something unhelpful.

Automatic Backups works at bucket scale. Under Settings > Backups, snapshots are taken daily at 12AM UTC covering all content including drafts, though not revisions. You can also click Create snapshot before doing anything risky, like a bulk import or an agent run against production. Each snapshot offers Download and Restore.

This is the disaster tool: a bad import, a wrong bucket, a delete that went further than intended.

They solve different problems and you probably want both. There is an Add-ons Bundle that includes Webhooks, Localization, Revision History, and Automatic Backups together, which is worth comparing against buying two of them separately.

---

A Tip on Running Multiple Locales

The technical part of localization is a few hours. The operational part is ongoing, and one habit prevents most of the pain.

Give every locale an owner. Not a translator: an owner, one person responsible for whether that market's content is current. Without this, locales decay in a predictable way. Everyone updates English because that is where the traffic is, the other languages fall a few weeks behind, then a few months, and eventually you have a German site describing a product that changed twice.

Take a snapshot before your first bulk translation run. It is the cheapest insurance available, and bulk operations are exactly where a mapping mistake multiplies.

---

Do This in Your Project

1. Open an object type's Additional settings and add one locale under Localization

2. Set a Priority locale and save

3. Open an existing object, click Enable Localization, then Generate new locale

4. Read the draft it produced and note what a native speaker would need to fix

5. Query the API with for both languages and confirm you get different content

6. Turn on Revision History and open the History section on an object you have edited

The API check in step 5 is the one worth doing carefully. Seeing two objects with the same slug return different content is what makes the data model click.

---

Up Next

You have finished the curriculum.

You have gone from a single agent producing a draft to a deployed site, a content model, a migration path, integrations, chained workflows running on their own, analytics telling you what works, and a team structure that scales past one person.

The next step is not another lesson. Pick the one part of your own operation that is still manual and automate it.