Working with Localized Content

In Agility CMS, your content can exist in more than one language. A blog post can exist in English, French and Japanese. A campaign can go live in five markets on the same morning.

This guide introduces how localized content works in Agility, what you can build with it, and where to find the steps for each task.

What you can build

A multilingual site from one set of content. Write once in your primary language, then copy each item into your other locales and let DeepL translate it as part of the copy. Editors stay in one place, and every language shares the same structure, components and workflow.

Regional variants of the same language. en-us and en-ca, or es-es and es-mx, let you vary spelling, legal wording, imagery or local detail per market without duplicating your site. Agility recognises these as the same language and copies the content across untranslated, ready for you to adjust the few things that actually differ.

A market launch on a deadline. Select a whole content list, copy it into your new locale with translation enabled, and you have a complete first draft rather than a blank page. Your team then refines the translation.

Translate a single field, mid-edit. Sometimes you do not need a whole workflow. You need this one paragraph in German, now. The DeepL panel sits beside the content editor and translates the fields you choose, without leaving the page.

Launch languages independently. Each locale publishes on its own schedule, so English can go live today and Japanese next month, from the same content and the same site.

For developers, the delivery model stays simple. Every locale is served from the same APIs with the locale code in the path, so one front end serves them all. Route by URL path, by domain, or by cookie, whichever suits your architecture. See the Multi-Locale Guide.

What a locale actually is

A locale is a parallel space for your content, not a translation of it. Adding Spanish to your instance does not translate anything on its own. It creates a place where Spanish versions of your content can live, alongside the originals rather than instead of them.

Content appears in a locale when you put it there, by copying an item across or by initializing a page. A new locale starts empty, and that is by design.

Choosing your locales

A locale combines a language and a region, such as English (United States) as en-us or Spanish (Spain) as es-es. That choice is not cosmetic. It decides what Agility does for you automatically when you copy content.

• Different languages are translated. Copying from en-us to es-es can translate the content with DeepL as part of the copy.

• Same language, different region, is copied as-is. Copying from en-us to en-ca does not translate anything, because there is nothing to translate. You get an identical copy, ready to adjust for regional differences.

You can mix both freely. Select every locale at once and Agility works out which ones need translating and which just need copying.

From setup to publish

Localizing a site in Agility involves these steps, in this order:

1. Set up your locales. An administrator adds them under Settings > Locales, and orders them so the most-used appear first in locale dropdowns.

2. Initialize your pages in each new locale, so the site structure exists there.

3. Copy content across, one item at a time or in bulk, translating as you go.

4. Review and refine. Read the translated content and adjust it before publishing.

5. Publish per locale, on whatever schedule each market needs.

6. Keep them in sync. When source content changes, the other locales do not update themselves. Decide who is responsible for updating them, and how often.

Connected copies

When you copy an item into another locale, the two versions stay linked. Agility understands them as the same piece of content in two languages, rather than as two unrelated items.

In practice that means switching locale while editing takes you to that item's counterpart in the other locale, rather than back to a list.

Editing one locale's copy does not change the others. The exception is any field your developers have marked as Constant across all languages in the content model, such as a reference code or a sort order. Those are shared deliberately, so the value stays identical in every locale.

Who does what

Administrators add and order the locales, and install the DeepL app if you want in-editor translation.

Editors work inside the locales: copying content across, translating, reviewing and publishing each market.

Developers decide how the front end picks a locale and fetch content per locale from the same APIs.

Where to go next

• Locales, to add, rename, reorder and disable locales

• Copying and Translating Content Across Locales, for Save & Localize, bulk copy, and initializing pages

• Translating Content with DeepL, to translate individual fields while editing, and for what does and does not get translated

• DeepL app, for administrators setting up translation

• Multi-Locale Guide, for developers building against the API