Shipping a bilingual MDX content workflow

Many sites claim to be bilingual when what they really mean is that their buttons and menus can change language. The problem only becomes visible when long-form content enters the system.

Where bilingual workflows usually break

Three failure modes show up repeatedly:

1. both language versions live inside the same content file
2. page components become stuffed with translation conditions
3. URLs do not make the locale explicit enough to be shareable and predictable

All three are manageable when there are only one or two entries. They become painful once real content volume appears.

Why the current model is more stable

This site now treats bilingual publishing as a content-structure decision, not an afterthought:

• locale segments are part of the route model
• each locale has its own content folders
• the page template only cares about locale and slug

That keeps the rendering layer small. A template does not need to know how many languages exist or how content editors choose to work. It only needs the resolved entry.

Why that matters in practice

The practical benefit is that “adding content” becomes predictable again.

Adding a new article now mostly means:

• pick a slug
• create the matching folder
• add index.mdx
• define metadata

At that point the cost of maintaining a bilingual site is driven more by editorial effort than by fragile engineering structure. That is the right trade-off.

What still needs editorial decisions

The technical side is largely in place now. The more interesting remaining questions are editorial:

• which entries deserve bilingual treatment
• how translation timing should relate to publishing dates
• whether the list page should expose source/translation relationships

Those are good problems to have, because they only appear once the technical structure stops getting in the way.