Esposter
Esposter
Overview
Architecture
Products
Packages
Proposals

Internationalization

A translation layer for the interface: @nuxtjs/i18n (or bare vue-i18n), locale message files, every user-visible string moved behind a key, and locale-prefixed routing with a language switcher.

None of that exists. Neither @nuxtjs/i18n nor vue-i18n is a dependency of any package or an entry in the workspace catalog, there is no locales/ directory and no $t anywhere, and every label, placeholder, empty state, and error message in the app is an English literal written inline. The document declares itself English once, in configuration/app.ts (htmlAttrs: { lang: "en" }), and nothing contradicts it.

The one i18n string in the repo is a false positive worth knowing about so nobody reads it as a foothold: ajv-i18n, used in configuration/plugins/fixAjv.ts to localize JSON-schema validation messages for Vjsf-rendered forms. That is a form-validation concern inside one library, not an app translation layer, and it carries no infrastructure the UI could reuse.

Why deferred

  • The cost is not the plugin, it is the corpus. Adopting i18n means extracting every literal in the app at once — and, more expensively, accepting a permanent obligation that every string written afterwards gets a key and a translation. That is a standing tax on every feature, paid forever, for an audience that is currently one language.
  • Translation is content work, not engineering work. Without someone committed to producing and maintaining non-English copy, the layer ships with exactly one locale populated and every other locale falling back to English — all of the tax, none of the reach.
  • Half-adopting is worse than not adopting: a keyed layer covering some surfaces and literals covering the rest gives a language switcher that visibly half-works, which reads as broken rather than untranslated.

Revisit when

A non-English audience actually exists — a sustained share of users whose browser locale is not English, or a specific deployment/community that requires another language — and someone is committed to maintaining the translations rather than machine-generating them once.

Not the same thing

Message translation is a separate deferred idea: translating user-authored messages on demand via a paid translation API. It shares no machinery with translating the UI, and neither one unblocks the other — a translated chat message still renders inside an English interface, and a translated interface still shows messages in whatever language they were typed.