If you are managing a global brand on Optimizely CMS, you know that "going live" in a new market is rarely as simple as clicking a single button. Usually, it’s a marathon of clicking into every individual block, header, and teaser to ensure the content is localized.
But what if you could translate the entire page and every block nested within its Content Areas in one fell swoop?
That’s where the TranslateOrCopyContentAreaChildrenBlockForTypes configuration comes in.
This was a feature added to the language manager in version 5.3 but it passed me by, and it might of done the same for you
The Problem
By default, the Optimizely Language Manager is great at translating page-level properties (like Page Name or Meta Titles). However, Content Areas are essentially just lists of pointers to other pieces of content (Blocks).
Without specific configuration, the Language Manager often ignores the actual content inside those blocks during a page translation. This leaves editors stuck in a loop
Translate the Page.
Open the Page.
Navigate to Block A -> Translate.
Navigate to Block B -> Translate.
Repeat until coffee runs out / have mental breakdown
The Solution
You can automate this behavior in your appsettings.json. By defining specific namespaces or types, you tell Optimizely: "When I translate this page, look inside the Content Areas. If you find these types, translate them too."
Here is the configuration snippet you'll need
"CmsUI":
{
"LanguageManager":
{
"TranslateOrCopyContentAreaChildrenBlockForTypes":
[
"MySite.Models.ContentTypes.Pages**"
]
}
},Alternatively you can set this up in your program.cs / startup file
public void ConfigureServices(IServiceCollection services)
{
services.Configure<LanguageManagerOptions>(o =>
{
o.TranslateOrCopyContentAreaChildrenBlockForTypes.Add("MySite.Models.ContentTypes.Pages**");
});
}What is this doing?
LanguageManager
We are targeting the settings for the Optimizely Language Manager add-on.
TranslateOrCopyContentAreaChildrenBlockForTypes
This is the heavy lifter. It tells the UI to include "child" content (the blocks sitting in your Content Areas) in the translation or copy process.
The Wildcard (**)
By adding ** at the end of the namespace, you are applying this rule to every content type within that folder. In this case, any block or page type under that namespace will be processed
Why This Matters for Editors
Massive Time Savings
Instead of 20 manual actions to translate a complex landing page, it becomes one. The system identifies the blocks, creates the new language branch for them, and carries over the content (or sends it to your translation provider) automatically.
Consistency
Manual translation is prone to human error. It’s easy to miss a small "Call to Action" block at the bottom of a page. Automating the process ensures that every piece of the puzzle moves to the new language simultaneously.
Streamlined Machine Translation
If you are using an external provider (like Lionbridge or Azure Text Translation), this setting ensures the provider receives the entire context of the page, including the nested blocks, in a single package.
While it’s tempting to use a wildcard for your entire project, be mindful of Shared Blocks. If a block is used on 50 different pages, you might not want it re-translated every time a different page is processed. Usually, it's best to target the namespaces where your "Local" or "Page-Specific" blocks live.
Conclusion
Configuring TranslateOrCopyContentAreaChildrenBlockForTypes is one of those "small effort, high impact" tasks. It moves the CMS out of the editor's way and allows them to focus on what actually matters creating great localized content.