Requirements for a Second Language on a Builder Site

A builder site, in the context of software, is any web application that lets a non-programmer assemble something by choosing parts and placing them: a page, a form, a workflow, a storefront, a dashboard. The category is broad, and the term is loose. But the requirement that matters here is narrow and often ignored. When such a site serves users who speak more than one language, the language toggle is treated as decoration. It is added last, tested once, and shipped. The result is a product that technically supports a second language while failing every user who actually needs it.

The interesting problem is not translation. Translation is a vendor contract and a spreadsheet. The interesting problem is what a builder site has to do structurally before a second language is even possible. Most teams learn this the hard way, usually after a launch in a new market produces support tickets that all say the same thing in slightly different words.

The Difference Between a Label and a Data Field

Consider a button. In English it reads "Save draft." A translator renders it in German as "Entwurf speichern." That is fine as long as the button is a label, a piece of interface chrome that the system controls. The trouble starts when users build things inside the builder site and give those things names.

A user creates a form field called "Company size." That label is user data. It lives in a database row. If the site is to display a second language, someone has to decide whether "Company size" gets translated, who translates it, and where the translated string is stored. A label owned by the product is one problem. A label owned by the customer is a different problem entirely, and most builder sites have no model for it.

The requirement, then: every string in the system needs a clear owner. Product strings get localized by the product team. User strings either stay in the language the user typed or get a translation slot the user fills in. A site that blurs the two will produce a French interface with English field labels in the middle of it, and no one will be able to explain why.

Why String Concatenation Breaks First

English is forgiving about word order. "3 items selected" can become "Selected: 3 items" with a small code change. Many languages are not forgiving. The number, the noun, and the verb may need to agree in gender, case, or count. A builder site that assembles interface text by gluing pieces together will produce sentences that are grammatically wrong in half the languages it claims to support.

The practical fix is boring and well documented: every string that combines a variable with prose needs to be a single translatable unit with a placeholder, so the translator can move the placeholder wherever the target language demands. "Selected {count} items" is a unit. "Selected" plus a number plus "items" is three units pretending to be one. The first travels; the second does not.

This sounds like an engineering detail. It is really a product decision about how much of the interface can be assembled at runtime versus authored in advance. Builder sites lean heavily on runtime assembly, which is exactly why they break here.

The Builder's Own Vocabulary Has to Be Translated Twice

Here is a distinction that trips up even experienced teams. A builder site has two vocabularies. The first is the language of the product itself: "component," "block," "section," "layer," "template," "publish," "revision." These words are metaphors, and they carry the mental model of the tool. Translating "block" as the ordinary word for a physical block can strip away the meaning the product intended.

The second vocabulary is the language of the artifacts users create and share. If a user publishes a template and another user in a different locale opens it, the template's internal labels need to travel. A well-built site separates the two, so the product's metaphor can be localized by people who understand the product, while the user's content stays intact.

Sites that skip this distinction end up with a Japanese interface that calls a section a "section" in English because the translation memory had no entry and the fallback was the source string. The user sees a mixed-language screen and concludes the product is not really localized, which is correct.

Layout Has to Survive the Text Getting Longer

A short English label often grows by a third when rendered in German, and can grow more in Finnish or Hungarian. Builder sites are especially exposed because their canvas is a grid of small controls: toolbar buttons, property panels, dropdown menus, inline hints. A button designed at exactly the width of "Publish" will clip or wrap when the same button says "Veröffentlichen."

Two requirements follow. Controls need to size to their content rather than to a fixed pixel width, and the layout needs a strategy for the longest plausible string in any supported language, not just the English one. This is a design constraint that has to be present in the component library, because retrofitting it after the fact means auditing every screen. The screens that pass are usually the ones where someone deliberately typed a long fake German string during development, looked at it, and fixed what broke.

Text Direction Is Not a Setting, It Is a Second Layout

Supporting Arabic, Hebrew, or Persian means the entire interface flips: navigation on the right, alignment reversed, iconography mirrored where direction carries meaning. Many builder sites handle this by adding a direction attribute and hoping. The result is a right-to-left skeleton with left-to-right muscle memory baked into the components, so arrows point the wrong way and progress bars fill from the wrong edge.

The honest requirement is that direction is a property of the locale and the component library respects it from the start, using logical properties for spacing and alignment rather than hardcoded left and right. A site that treats right-to-left as a post-launch patch will spend years fixing individual components one at a time, and the tickets will never quite stop.

Locale Is More Than Language

A second language comes bundled with a second set of conventions: date order, currency, number separators, first day of the week, address format, name order. Builder sites surface all of these because users configure forms, tables, and pricing components. A date picker that starts the week on Sunday is wrong for most of Europe. A price field that assumes a dot for decimals will mangle a user's input in markets that use a comma.

The requirement is that locale is a first-class value passed through the whole system, not a language code bolted onto the translation file. The product needs to know, for any given user session, which language to speak and which conventions to apply, and those two decisions are related but not identical. A user in Switzerland may want French interface text with Swiss number formatting, and the site has to be able to honor that without a code change.

Content the User Enters Needs a Language Tag of Its Own

Builder sites generate a lot of content: page titles, form submissions, template descriptions, comments, published pages. Each of those objects should carry a language tag, so the system knows what it is looking at later. Without one, search inside the product mixes languages, filtering gets confused, and any attempt to offer "show me only pages in French" is impossible.

The tag also matters for text handling. Hyphenation, line breaking, spellcheck, and font selection all depend on knowing the language of a given block of text. A site that stores user content as an undifferentiated blob will render Japanese with a font stack chosen for English, and the characters will look wrong in a way that is hard to name but easy to see.

Translation Is a Workflow, Not an Export

Every builder site eventually needs to answer a small set of questions. Who translates this string? When does the translation go live? What happens if a string changes after it was translated? Where does the fallback go when a translation is missing? These are workflow questions, and the answers determine whether the second language stays current or drifts into a half-translated state that everyone quietly stops trusting.

A workable setup has a source locale, a pipeline that exports new and changed strings, a place where translators work, and a review step before publishing. It also has a visible fallback rule, so a missing translation shows the source language rather than an empty box or a raw key like "form.field.label.primary." That last detail is small and it is the one users notice most, because a raw key on screen reads as a bug even when everything else works.

The Test Plan Has to Run in the Second Language

The final requirement is the one most likely to be skipped. If the test suite, the QA checklist, and the demo script all run in English, the second language will break in ways nobody catches until a customer does. The plan needs a locale pass: a short list of flows exercised in each supported language, with the interface set to that language and the system locale set to match. It does not have to be exhaustive. It has to exist.

A builder site that treats a second language as a translation file will ship something that looks local until a user tries to type a date, read a button, or publish a page in their own script. The requirements above are not exotic. They are the ordinary cost of promising a second language, paid up front or paid later in tickets that keep arriving long after the launch party.