25 interface languages, one booking prompt

The Typelessity chat window comes in 25 languages with one English-language prompt template, one per-business config, and about 150 translated widget strings per locale. There is no per-language codepath, no language-detection branch, and no regex grammar. The model — OpenAI, currently gpt-5.4-mini — handles normalization and extraction in a single round-trip. The assistant replies in the language set for the business; the customer can write in another language, and we have not measured extraction quality per language. Adding a new language is a translation of widget strings. See how it works for the four phases.

When engineers hear that the Typelessity chat window comes in 25 languages, the next question is always the same: "How big is your i18n team?" Zero. There is no i18n team. There is one prompt template and per-business configs. Languages are an emergent property of the model (OpenAI, currently gpt-5.4-mini), not a feature built per market.

What is the trap of per-language code?

The instinct most teams have is: detect the user's language, route to a per-language handler, maintain a regex/grammar/intent set per locale. This works at small scale and collapses at large scale. Every new language is a new codebase to maintain. Every new field in the schema is N coordinated changes — once per language. The cost of adding the 26th language is higher than the cost of the 25th.

Typelessity made the opposite bet. The prompt is in English. The user input is in any language. The output is structured JSON in a stable schema. The model handles translation, normalization, and extraction in one shot.

Bottom line: lean harder on the model than feels comfortable. The places where you still need code are smaller than you think.

What is actually in the config?

A config is stored on our side, one per widget. The business builds it in the Webappski portal wizard or pastes it in as JSON. It defines:

• Required fields — what must be extracted (e.g. service, date, time_window).
• Optional fields — preferences (preferred_mechanic, courtesy_car).
• Enrichment APIs — endpoints to call when a field is set (e.g. service=brakes → GET /mechanics?service=brakes).
• Cascade rules — when field A changes, which downstream fields to clear. See Cascade corrections in conversational booking.
• Confirmation copy — per-locale strings for the review step. This is per-language, but it is just labels.

What is the language-detection step you do not write?

There is no language-detection step. The reply language is the one set in the business's configuration; the user can write in any supported language, and the model extracts the fields from whatever they wrote. The orchestration layer never branches on the user's language.

The other place language matters is the widget's own text — buttons, the consent notice, review and error messages. Typelessity keeps those in one TypeScript module per locale: about 150 short strings each, across 25 locales. That is the translation effort.

Bottom line: the model is the language layer. Code is the labels layer.

How much does latency vary across languages?

Token counts vary across languages — the same meaning can take more tokens in some scripts than in English. We have not measured what that does to latency per language, so we quote no numbers; the one-second figure in A one-second latency target for AI booking is a target, not a measurement.

No language has required a separate codepath.

What still needs language-specific code?

Less than this post used to claim:

• Phone numbers and dates — there is no phone-number or date-parsing library in the engine; dates go through the model and our own date utilities.
• Widget text — the per-locale strings described above.

Everything else is the model.

When per-language code is the right choice

Typelessity's bet pays off when:

• The output schema is stable across languages (booking fields are universal: who, what, when, where).
• The extraction surface is bounded (intake forms, not open-ended dialogue).
• Latency and cost can absorb a slightly larger model than a regex.

If the use case is open-ended advisory dialogue with deep cultural nuance — therapy, customer support across dramatically different markets, multilingual education — then per-language tuning, glossaries, and human review still beat the single-prompt approach. For structured booking, single-prompt extraction fits.

FAQ

How does Typelessity serve 25 languages without a per-language codepath? One English-language prompt template plus per-business config. The model handles translation, normalization, and extraction in one round-trip and returns structured JSON.

What is actually translated by hand? About 150 short widget strings per locale — widget text, consent notice, review and error messages — in one TypeScript module per locale.

Does Typelessity detect the user's language? No. The reply language is set in the configuration; the user can write in any supported language and the model extracts from it.

How much does latency vary across languages? Token counts vary, but we have not measured latency per language, so we quote no numbers. No language requires a separate codepath.

What still needs language-specific code in Typelessity? Only the per-locale widget strings. There is no phone-number or date-parsing library; dates go through the model and our own date utilities.

For the single-call extraction architecture, see Replacing a booking form with one GPT call. For voice input in the chat window, see Whisper vs Web Speech API for booking voice. For the latency budget that constrains all of it, see A one-second latency target for AI booking.

— Alex Isa, founder of Typelessity. Also founder of Webappski and TypelessForm.