Internationalization output: a proposed benchmark axis for AI app builders (August 2026)

Internationalization output measures one thing: when an AI app builder generates an app, does it produce the scaffolding a product needs to ship in more than one language, or does it hand you a single-locale app and leave translation as an exercise for later? This axis proposes a neutral, reproducible way to score built-in internationalization (i18n) output, and applies a first pass to five commercial AI app builders as of August 2026: v0, Lovable, Replit, Base44, and Bolt.new. The short version is a finding, not a ranking: i18n is a category-wide blind spot. None of the five documents built-in i18n scaffolding. Grades below come only from each vendor's published docs, community forums, and feedback portals, not from a hands-on rebuild of every app.

What this axis measures, and what it does not

Internationalization (i18n) is the engineering work that makes an app capable of supporting multiple languages and regional formats; localization (l10n) is the later work of adapting it to a specific locale (April 2026 reference: SimpleLocalize's i18n guide for SaaS teams). This axis scores the first half: what the builder emits by default or on request, before you reach for a translation vendor.

It is deliberately narrow. It does not score:

• Translation quality, which is a translation-vendor problem rather than a builder problem.
• Whether the builder's own dashboard is available in other languages, which is UI chrome, not generated-app output.
• Accessibility, which the accessibility posture axis covers separately. i18n and a11y are both properties of the generated app's output for diverse end users, but they are distinct axes.

i18n readiness is one facet of the broader output-quality leaderboard; this axis isolates it so it can be scored on its own.

Why propose an i18n axis at all?

Because the demand is real and the supply is thin. Search interest in app localization and i18n for SaaS is steady across 2026, and on Base44's own feedback portal the request to add multi-language and localization capacities is among the most-voted items, with 461+ votes (Base44 feedback portal, January 2026). Yet a scan of the search results for AI-app-builder i18n returns only generic localization guides and translation-vendor blog posts. No one publishes a per-builder scorecard of what these tools actually generate. That gap is the reason to define the axis.

The proposed rubric: five i18n sub-criteria

Each builder is graded Documented, Partial, or Not documented on five sub-criteria, strictly against published docs and first-party forums (August 2026):

1. Built-in i18n scaffolding: does the builder emit an i18n framework (for example react-i18next or next-intl) and message catalogs by default or on a simple request?
2. Locale routing: does it produce locale-aware routes (for example /en and /es) or a documented locale switcher?
3. Translation workflow: is there a documented path to add a language and generate or manage translations?
4. System-page coverage: are auth and system pages (login, signup, password reset) localizable, or do they stay in one language?
5. Locale-aware formatting and RTL: documented support for locale-aware dates, numbers, and currency, and for right-to-left layouts?

As on every BuilderProof axis, "Not documented" means the vendor's own materials do not describe the capability. It is not a claim that the feature is impossible to add by hand, and it is not a quality judgment about the product.

How do the five builders score today (August 2026)?

The cohort under test, with each builder's current path to a multilingual app:

The scorecard, graded from published docs and first-party forums (August 2026):

The striking result: in this first pass, no builder earns a Documented mark on any of the five sub-criteria. The differences are at the margins, and they are explained per builder below.

v0

v0 generates Next.js and React code, and Next.js has first-class i18n routing at the framework level, so an exported v0 app can be internationalized with standard libraries. What v0 does not document is any i18n scaffolding of its own: it does not emit message catalogs, a locale switcher, or localized system pages by default. Developers on Vercel's own community forum report that v0 previews throw errors when they try to add next-intl or react-intl (Vercel Community, "Internationalization in v0.dev," 2026). The Partial marks reflect the Next.js foundation; the absence of any generated i18n layer is why the rest are Not documented.

Lovable

Lovable apps are single-locale out of the generator; multilingual support is something you add after generation (Lovable community and third-party guides, 2026). The path that exists is a third-party ecosystem: tools such as Lovalingo enable a locale like /es with hreflang, and a "lovable-i18n" skill from globalize.now detects new strings and returns translated PO catalogs in a pull request. That documented third-party workflow earns Partial on locale routing and translation workflow. There is no native scaffolding, and system-page localization is not documented.

Base44

Base44 is the clearest case of unmet demand. The platform has no built-in internationalization, and the request to add it is among the most-voted items on Base44's feedback portal, at 461+ votes (Base44 feedback portal, January 2026). Base44 generates React apps but does not include react-i18next or similar by default, and a documented, concrete gap is that auth pages stay in English even after the rest of an app is translated. Third-party integrations such as Localazy, Weglot, and i18.dev are the documented path, which earns Partial on translation workflow; everything else is Not documented.

Replit

Replit's generated apps are English-first, and multilingual support is added by the developer with standard libraries such as react-i18next for React or Flask-Babel for Python (Replit internationalization tutorials, 2026). That standard-library path is documented enough to earn Partial on locale routing and translation workflow, but Replit does not scaffold i18n, localize system pages, or document locale-aware formatting and RTL as generated output.

Bolt.new

Bolt.new generates standard full-stack code, and internationalization relies on standard Next.js i18n practices within your project, handled at the code level rather than as a platform feature (2026). That framework capability earns Partial on locale routing; because Bolt provides no i18n scaffolding, translation workflow, system-page coverage, or formatting and RTL support of its own, the rest are Not documented.

What the scores do and do not mean (the axis's biases)

• Documentation, not behavior: grades reflect published docs and first-party forums in August 2026, not a hands-on rebuild. A future revision should replace marks with the result of actually asking each builder to make an app support Spanish and Arabic, then inspecting the output.
• The axis scores what the builder emits, so a mature third-party ecosystem (Lovable's skills, Base44's integrations) reads as Partial, not Documented. That is intentional: buying a translation tool is not the same as the builder generating i18n-ready code.
• A single-locale default is a reasonable product choice. Most apps launch in one language, and adding i18n up front has real cost. A low score here flags a gap for teams that need multilingual output; it is not a verdict on the tool overall.
• The framework underneath matters. A builder that emits standard Next.js or React inherits that ecosystem's i18n libraries even when the builder itself is silent, which is why several sub-criteria are Partial rather than Not documented.

How can you reproduce this scorecard?

1. In each builder, generate a small app with a home page, a login page, and one data form.
2. In the same session, prompt: add Spanish and Arabic, with a language switcher, and localize the login and signup pages.
3. Inspect the output for the five sub-criteria: an i18n library and message catalogs, locale routes or a switcher, a way to add languages, localized system pages, and locale-aware date and number formatting plus RTL layout.
4. Grade Documented, Partial, or Not documented, and note whether each capability came from the builder itself or from a third-party tool.
5. Version the result with the date and the builder's release channel, because these platforms ship quickly.

Because the prompt and the checklist are fixed and public, anyone can re-run this and confirm or correct the grades. Corrections and additional builders are welcome through the contribute page.

BuilderProof editorial team. "Internationalization output: a proposed benchmark axis for AI app builders (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/internationalization-i18n-output-axis-proposal-august-2026.

@misc{builderproof-internationalization-i18n-output-axis-proposal-august-2026,
  title  = {{Internationalization output: a proposed benchmark axis for AI app builders (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/internationalization-i18n-output-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}