Multilingual Storyblok: Which structure fits your website?

Fields, folders or separate spaces: Storyblok offers different ways to manage multilingual websites. The right structure depends on your content and the people responsible for it.

Before translating your website, decide what should stay the same in the next language. Does your company offer the same services everywhere? Or do products, campaigns and local contacts differ by market?

Translation alone does not establish who may change regional content, which information is maintained centrally or what happens when something changes. A language version can be technically available and still be out of date.

Start here: if your pages share a similar structure, assess field-level translation in Storyblok. If markets need different content and structures, consider separate folders. Separate spaces suit environments that require greater independence. The number of languages alone does not determine the approach. Storyblok: Internationalization

Language and market are two different decisions

A language determines how you communicate. A market also determines which offer is relevant and which conditions apply. An English-language website can serve several countries. It can also describe an offer that is available in only one of them.

Consider a simplified example: a manufacturer sells the same machine in Germany and France. Its technical specifications and product structure remain the same. Descriptions and operating instructions need translation; local contacts differ. The company then enters another market, where it offers only spare parts and maintenance. A fully translated product page would present the wrong offer there.

The problem is not translation quality. It is the assumption that every market needs the same content.

Our recommendation: examine a few representative pages before configuring the system. A product page, a campaign page and a contact page are enough for an initial structure test. Mark what stays identical, what needs translation and what each market must decide for itself. This turns an abstract discussion about multilingual content into specific editorial requirements.

For our fictional manufacturer, a completed structure test could look like this:

Record who approves each local decision. If almost everything belongs in the translation column, your project team should assess a shared structure. If a market needs different pages and offers, the model must accommodate those differences. The table is a brief for that assessment, not a finished CMS configuration.

What options does Storyblok offer?

In Storyblok, a “story” is a content entry, such as a page. Three approaches matter for planning: translations within shared content, separate content structures in folders, or separate spaces. A space is an independently managed environment in the CMS. Storyblok: Internationalization

Field level: one shared page, several language versions

With field-level translation, the source text and translated field values belong to the same content entry. A text field must be configured as translatable. The German and French headings are then language-specific values, not two independently structured pages. Storyblok: Internationalization for Stories

For the manufacturer in our example, we would first assess this approach for the shared product presentation. What the team primarily needs here is reliable translation. If a local campaign requires a different page structure, the structural decision needs revisiting. “We need another language” and “we need a different page” are different requirements.

Folder level: room for different market websites

Storyblok supports alternative page versions in different folders. The Dimensions app can connect these variants. Storyblok: Dimensions

For the market where our manufacturer offers maintenance only, we would assess a separate content entry. That page should help visitors choose a service, not sell a machine unavailable locally. Translating a shared product page does not solve that problem.

This flexibility has an editorial cost: the team must track which versions belong together and which changes affect several markets. Greater independence requires deliberate maintenance. A linked variant is not necessarily an up-to-date variant.

Space level: separate environments for independent requirements

Separate spaces offer another approach for complex projects where teams, markets or channels need greater independence. Storyblok: Internationalization

We would not separate our manufacturer's environments just because one market offers an additional service. First, the project team needs to explain which responsibility a separate environment would actually simplify. Does a market need to develop its content model independently? Who then checks shared components and brand rules? Without answers, separation simply moves the problem elsewhere.

Use these questions to prepare the decision:

This is our planning recommendation, not a rigid rule based on company size. Storyblok also supports combinations, such as separate market folders containing several languages. Storyblok: Internationalization

Do not choose maximum separation just in case. Every additional degree of independence raises an organisational question: who keeps the shared rules binding? Equally, do not force real differences into a shared model simply because centralised maintenance sounds easier.

For your website planning, this means the content model should support how people actually work. It should not depend on collaboration that nobody in the team can sustain.

Amtico: a language switch changes more than navigation labels

Amtico’s English homepage offers quick links to samples, a room visualiser and a retailer search. The German version uses the corresponding area for samples, brochures and a room visualiser. The main navigation differs too: the English site gives retailer search a direct link, while the German version includes an “About Amtico” menu. Amtico: German website

Our observation reveals an editorial decision, not just a change of wording: which next action should each site make easy? It does not reveal whether Amtico uses a field, folder or space for that purpose. For your brief, the first task is to identify these differences and allow for them in the model.

What to inspect: compare the quick links in the page header and the pages they lead to. A language switch does not have to copy every feature, but it should offer a useful path for that market. Amtico: English website

What stays central, and what gets decided locally?

A brand's language is more than individual words. It also shows in the problems a company takes seriously, how it explains its solutions and the promises it makes. That is the level international websites need to manage deliberately.

We recommend separating binding foundations from local flexibility. Product specifications, substantiated claims and core positioning need a shared foundation. Regional examples, contact people or the opening message of a campaign may need different answers.

Set this out in a simple editorial agreement. Who may change a brand promise? Who verifies a technical statement? Which examples can the local team replace independently? And who decides when a literal translation is accurate but confusing in the target market?

These questions are not extra work to deal with after launch. They determine whether a brand remains recognisable across languages without forcing the same copy into every market.

Plan for changes, not just the first translation

Launch has a date. Maintenance needs a process. Products, contacts and service descriptions keep changing. Every change raises a new question: which language versions does it affect?

Our suggested editorial workflow: the person responsible marks what has changed in the source copy and which markets need the update. Translation comes next, followed by subject-matter review and an in-context page review. Only then is that version approved for publication. Your project team must check separately which steps your setup already supports.

Distinguish between types of change. Correcting a phone number needs a different check from making a new product claim. Replacing a campaign opening does not necessarily require the same subject-matter approval as changing a technical specification. Clear responsibilities are more useful than an identical process for every piece of copy.

Also decide what happens when a translation is missing. Should the page remain unpublished? Is there a deliberately chosen fallback language? Or is the information not needed in that market? A technical fallback must not silently replace an editorial decision.

Check the publishing logic for field-level translations too: according to Storyblok, publishing a story publishes all its language versions by default. Individual translation publishing can be enabled separately. An existing language version is not automatically an independently scheduled launch. Storyblok: Internationalization

AI can produce a draft. Approval is a separate task

Storyblok offers AI-assisted translation and a separate feature for generating image alt text. Our recommendation: check asset descriptions, captions and rights information separately. A translated article does not prove that every media field has been localised correctly. Storyblok: AI Assistance

We recommend three separate editorial checks. First: is the meaning accurate? Second: does the translation sound natural and fit the brand? Third: does it work on the actual page?

The last point is easy to underestimate. A longer button label can change a layout. A technical term that needs explaining may work in body copy but confuse people in navigation. A translation that reads well on its own can promise something different when combined with an image and a headline.

Test the process with a small, deliberately varied set of pages. Do not assess only how quickly the first draft appears. Record which corrections are needed and who can reliably spot them. That gives you the basis for a useful review process. The number of generated translations does not.

Multilingual content needs the right delivery

A multilingual content model alone does not make the finished website discoverable in every language. Its publicly accessible pages also need a suitable structure.

Google recommends separate URLs for different language versions and appropriate signals for language or regional alternatives, such as hreflang. Visible content and navigation should be consistent in language. Google Search Central: multilingual websites

Check buttons, forms and subsequent pages as well as the language switcher. The pilot test at the end brings these checks together with editorial tasks.

This connects editorial work with web design and user journeys. A language switcher is only useful if the path that follows it works too.

Education First: consider country and language together

EF’s international website combines market and language in its country selector. Canada has separate English and French entries, for example; Switzerland has German, French and Italian entries. Global language versions are also available. EF: country and language selection

The concrete example is the selector behind “Global Site / English” in the footer. It shows why a language list alone may not be enough: French does not identify a particular market, and one country may need several language versions. This is an observation of the visitor interface, not evidence of EF’s internal content model or approval processes.

Apply this to your pilot: can a French-speaking visitor clearly find the site intended for Canada? Does the relevant market remain identifiable when moving from the homepage to an offer and a contact page? First establish which combinations you need. Then decide how Storyblok should represent that content.

Technical delivery and subject-matter approval remain separate tasks. Even a language version delivered quickly can show the wrong offer. Check the visitor's task and editorial ownership, not merely whether a URL loads.

How to prepare the decision with your team

Before configuring multilingual content, record five decisions:

1. Which languages and markets do you actually need?

2. Which content is shared, translated or managed independently by each market?

3. Who owns the source copy, translation and subject-matter approval?

4. What happens when content changes or translations are missing?

5. How will you check the finished language version on the website?

With these answers, your team can select an approach and test it on your three example pages. Before implementation, also check that your plan, configured roles and publishing logic support the intended work. This guide prepares the decision; it does not replace an assessment of your specific setup.

For the pilot, we recommend three observable tasks. A local editor edits the intended content and completes the agreed approval process. A second person finds the relevant offer and the right contact on the finished language version. Then change a shared piece of information, such as a technical specification, and track which versions need updating.

The test only passes when responsibilities are clear, affected versions can be found and no market shows the wrong offer. If any of those points fails, fix the structure or process first. More languages would only multiply the same mistake.

An international website does not need identical content everywhere. It needs a clear rule for what holds the brand together and what each market may shape independently. That is the starting point for multilingual content you can maintain reliably after launch.