Multilingual Authentication for Agentic Engineering — 82-Language Login & Registration Forms

Fractera is an Agentic Engineering Infrastructure — an agentic engineering platform where AI agents build and run your project on your own server. No matter which region you work in, you should not have to stop and think about how to translate the sign-up form on your site so your customers can register comfortably in their own language. So we extended the starter templates to do it for you.

Today's update is about the registration page — specifically the login form and the registration (password) form. From now on, no matter what country you are in, the moment your project is deployed you will see these forms in your own language. The same is true for the users of your site: if you turn on sign-in for them, they automatically see the form in their own language too.

How it works

The form reads the language of the visitor's browser and shows the matching words. Only the words are localized; the input fields themselves stay exactly as they were. Because every translation is baked in at build time, the page is served as plain static HTML — fast, light, and the same for everyone, with English as the natural fallback when a browser asks for something we have not translated.

All 82 languages, by default

Out of the box, the forms ship with translations for the following languages:

You decide the build cost — by the languages you activate

Here is the part worth understanding, because it is yours to control. Every language you keep alive is a set of pages your server builds; the more languages, the longer each build takes. You curate the set in your workspace — open the Languages settings panel and you see the full catalog of available languages as a checklist. Tick the ones your audience actually uses; English stays on, always, as the guaranteed fallback. Saving applies the choice by rebuilding the app, which statically generates the pages for exactly those languages. For your content pages this already works today: fewer ticked languages mean fewer pages and a faster build. (Under the hood this is one environment list, `NEXT_PUBLIC_SUPPORTED_LANGUAGES`, but you never edit it by hand — the checklist does it for you, and an invalid code can't slip in.)

These sign-in forms are the next thing to follow that exact rule, and it is worth being precise about how. Right now the forms carry all 82 languages on purpose: at the moment your server is built, we cannot yet know which language you — the very first account — will register in, so every language has to be present. In the next step the build will read the *same* checklist you tick in Languages settings, and a small build-time generator will emit the form dictionary for only those languages, with English always kept as the fallback. Nothing in the form changes for you; you will not edit a line of code — you tick your languages, and the build that produces your login and registration forms contains exactly those. So the build cost of your authentication becomes proportional to your real audience, not to the whole catalog — the same principle the rest of the platform already follows: generate only what you actually use.

This is the same instinct that runs through the rest of the platform: a capability appears, and we fold it into the standard so you never have to rebuild it yourself — like the multilingual content architecture for your pages, or the autonomous development loop that turns a request into shipped code.

The takeaway: building the technology is the easy part. First you have to work out what you are going to sell, who you are selling it to, and how much they are willing to pay for it. A form that greets every customer in their own language is a small thing — but it is exactly the kind of small thing that decides whether someone in your region trusts you enough to sign up. Good luck building your business.