Field-level vs folder-level translation in Storyblok when experiences enter the mix
We are deciding between Storyblok's two translation models before we add Croct experiences on top, and I want to compare them on that axis specifically.
Field-level translation: one story, translated fields side by side. Folder-level translation: one folder per language, duplicated stories.
Pair one: which model plays nicer with per-locale content variants in experiences? Pair two: which one makes fallbacks easier to reason about when an experience does not apply?
Curious what teams running both have concluded
2 answers
We run field-level translation with experiences on top and it has been uneventful, in a good way. The main thing to internalize is that the translation model matters less than you might expect, because Croct handles locale at fetch time: fetches accept a preferredLocale, and multi-language works without extra dev work under either model.
On your second pair, fallbacks: the Storyblok block content for each locale stays that locale's fallback. So the real question is where your fallback is authored. With field-level translation the fallback for every language lives in one story, which our editors find easier to keep in sync. With folder-level translation each language folder owns its fallback, which suits teams where locales diverge structurally.
In other words, the translation model mainly affects how the fallback is authored, not how experiences behave.
Agree with Pieter, and one addition from the Croct side of the fence: per-locale default content (their localization feature) is an add-on, so check whether your plan includes it if you want locale-specific defaults managed inside Croct as well. If not, the pattern of resolving the locale in Storyblok and passing the localized block as the fallback covers most cases fine.
We went folder-level for unrelated reasons (very divergent market content) and experiences work the same way there. Both models are workable, pick the one your editors prefer.