Modulify

Multiple languages

How a site gains a second language, where the translations live, and how you switch between them while editing.

On this page

A site project can serve more than one language. There is no languages form to fill in. You ask chat for a language, the AI translates the site and sets the CMS up for it, and Modulify works out which languages the site has by reading the files afterwards.

Ask for a language

The language switcher is the short language code in the header. It sits next to the viewport icon on the Preview tab, and in the Collections header on the CMS tab. It appears on site projects only, and only on those two views.

While the site has one language, opening it shows an empty state titled No other languages reading Translations beyond English will show up here., with your own default language in place of English. Under that is an Ask AI to add a language button.

Pressing it writes I want to add a new language to my site. into the chat box and puts the cursor there. It does not send. Name the language you want, then send it like any other message.

Once the site has a second language, that same request moves to the bottom of the switcher menu as an Ask AI to add a language row.

What the AI changes

Adding a language is two pieces of work, and chat does both.

The site itself gets the routing and the translated copy, written into your project files like every other change. What that looks like depends on the framework the site is built in.

The CMS gets one extra column per language for every field worth translating. The base column keeps the default language, and the companion is named after it with the code appended after two underscores, so title gains title__fr. A regional code has its hyphen swapped for an underscore, so pt-BR gives title__pt_br.

A column is marked translatable only when it holds prose whose wording genuinely changes between languages, such as a heading, an excerpt or a rich text body. Proper nouns, slugs, prices, dates, URLs, ids and image columns stay single valued, because they read the same in every language.

You never work with those companion columns directly. The CMS collapses them into a single field that follows your language choice, described there under Multilingual fields.

How Modulify knows which languages you have

After a chat turn that changed files, Modulify re-reads the project and reconciles the list of languages behind the switcher. Nothing is recorded by hand, and there is no list for you to maintain.

It looks in two places.

Your files. Only paths that look language related are read: next.config, middleware, layout, _document, _app, root and index.html, plus any path containing i18n, locale, lang, intl, translation or dictionar. In those it looks for a locale array such as locales, supportedLocales, availableLocales or languages, for a defaultLocale, defaultLanguage or sourceLocale value, and for the lang attribute on the <html> element.

The CMS. The language recorded against each collection field, which is how the title__fr columns above are found.

A language that turns up in either place is added. A language already on the list that no longer appears in either is dropped. Files larger than 200,000 bytes are skipped, so one very large translation bundle can leave a language undetected.

The default language

The default is whatever your files declare: a single defaultLocale value, or failing that a single <html lang="...">. If the scan finds two different values it takes neither and leaves the default alone, so a half finished refactor cannot flip the site's base language. Until something is declared, the default is en.

When the default does change, the language that used to be default becomes an ordinary translation language, as long as it is still present in the site.

Which codes are accepted

Modulify knows 184 languages. A code is normalised before it is stored, and three spellings all work:

  • The language's English or native name, so German and Deutsch both become de.
  • A country name or two letter country code, so Germany, Austria, de and at all become de.
  • A BCP 47 tag such as pt-BR, kept in full as long as its primary part is one of the 184.

Anything that does not resolve to a known language is rejected rather than stored, so a typo never becomes a language on your site.

Switch language while editing

Open the switcher and pick a language. The menu lists the default first, with a check beside whichever is active, then every extra language.

Choosing one does two things. It becomes your editing language, so the CMS shows the fields for that language with the default language's text as the placeholder. And it moves the preview to the locale prefixed path, so /about becomes /fr/about and the home page becomes /fr. Going back to the default drops the prefix again.

The small cross on the language code returns you to the default in one click.

The choice is yours alone. It is stored against you and this project, so a teammate keeps whatever they had, and none of it changes what a visitor sees.

The preview follows the locale path because that is the convention the switcher builds. Whether /fr/about actually serves a French page is decided by the routing in your own site files.

Remove a language

Ask chat to remove it. The default language cannot be removed, so make another language the default first, which is itself a change to what the site declares.

Removing takes the language off the switcher and puts anyone who was editing in it back on the default. The translated pages and the per language CMS columns are your own files and your own schema, so they go only when chat changes those too.

FAQ

Why does the switcher still say No other languages?

The list is rebuilt from your files after a chat turn, so a language added outside a chat turn does not appear until the next one runs. If it still does not appear, the file that declares it is either not on a language related path or larger than 200,000 bytes.

Does switching language change what visitors see?

No. The switcher sets your own editing language for the preview and the CMS. It is stored per person per project and has no effect on the published site.

Can one collection be translated and another not?

Yes. Companion columns are added per field, not per collection, and only for fields holding prose. A collection whose columns are all names, slugs, prices and images gains nothing and reads the same in every language.

What happens to the translations when I remove a language?

The language disappears from the switcher and anyone editing in it is put back on the default. The translated content itself lives in your site files and your database columns, so it stays until chat removes it.

Next

  • The CMS covers editing a translated field row by row.
  • Use the preview covers the header the switcher sits in.
  • Site chat is the conversation that does the translating.