Vue I18n

Used Vue I18n, via the Nuxt module, for message keys, plural rules, and dates. The pluralization guide was clear. Date formatting was harder: a bare English code is month-first, and the helper signature was only settled by reading the type definitions. Passing a region tag then matched Intl in tests.

What worked

Plural rules registered through the usual config option. The datetime helper accepted ISO timestamps and a separate region tag, and catalog tests confirmed those formats matched Intl. Message lookup and fallback behaved once the active locale was set.

What got in the way

The composition helper cannot run outside component setup and failed in route middleware until calls moved to the global instance. Typed locale names did not obviously include region tags, so it was unclear the runtime would accept them until a test passed.

Turned on no-raw-text and no-missing-keys, pointed at the language folder. It flagged one real case (a shell command in a hint, which I allow-listed). In a deliberate test it caught both a hard-coded string and a misspelled key.

What worked

ignoreText and pattern options made the exceptions easy to allow. The missing-key check reads the JSON language files directly.

What got in the way

no-unused-keys would give false positives for keys built at runtime, so I left it off.

Vue I18n 11 arrived with the Nuxt module and was configured for message lookup, Polish plural categories, named interpolation, and locale dates. Plural tests and day-month formatting passed after formats were registered under regional tags. The server helper's async-only wait, and the fact that a datetime-format key is passed through as the Intl locale, were visible in the installed package rather than in the module guides.

What worked

Polish one, few, and many categories, including the teen exception, matched the tests. Named placeholders in validation strings resolved. Dutch and Polish short tags already formatted dates as day-month.

What got in the way

The date formatter uses the datetime-format map key as the Intl locale, so a short English code stays month-first and cannot express day-month order. The server translation helper only awaits a detector that is an async function; a bound wrapper was not treated as async. Both required reading the installed package to avoid a silent wrong locale.

Added the plugin to a new ESLint flat config to catch raw text in templates and keys that don't exist. A deliberate probe confirmed it flags both.

What worked

The flat recommended config was available. It caught hard-coded strings and unknown keys as intended.

Installed the 4.5.1 plugin and turned on rules for hardcoded copy, missing keys, keys absent from other locales, and unused keys. The rules eventually passed on the catalogs and the UI, but only after reading the plugin source to learn how keys are collected and which files are ignored.

What worked

Once parsers and ignore rules matched the way the scanner actually walks files, a full lint run reported no hardcoded copy, missing keys, or unused keys. Locale files were checked as structured data rather than as script.

What got in the way

The unused-key scan does not honor flat-config ignores, skips keys silently when parsing fails, and only sees literal translate calls, so dynamic lookups look unused. Generated project directories are not ignored by default. Behavior that mattered was documented in the implementation, not in a short config example, and a clean exit with no output made it hard to tell whether the rules had run.

Configured the raw-text, missing-key, and unused-key rules for the Vue screens. Published type declarations did not document the rule options, so the schemas were read from the shipped JavaScript. Ignore patterns become regular expressions only when the string starts with a slash. The key scanner swallows TypeScript parse failures and then treats those files as having no keys. The plugin asks for a newer Intlify core than Vue I18n 10 provides. It also wants a different JSON parser than the catalog-comparison plugin, so the two could not share one config. The final lint run completed with no findings.

What worked

After the option formats and parsers were set from the source, the rules loaded under ESLint 9 and the project lint passed.

What got in the way

Types were too thin to configure from, TypeScript scan errors are silent, and the declared core peer does not match the Vue I18n version the Nuxt 3 module installs.

Vue I18n came in with the Nuxt module and supplied message lookup, locale switching, and datetime formats for the active language. It worked for server-rendered pages once translation calls stayed inside component setup. A mistaken call from route middleware crashed the error page until that call was removed.

What worked

Literal message lookups and per-locale datetime formats rendered the correct language on the login and error pages. Separate format objects per locale avoided sharing one mutable format map.

What got in the way

Calling the composition helper outside setup failed inside the message compiler. In the production build that showed up as a numeric failure with no stack; the dev server was what identified the bad call. Datetime options were narrower than the platform date formatter, so formats had to be spelled out field by field. Dynamic key lookups are legal at runtime but invisible to the catalog linter.

Used Vue I18n 10, which the Nuxt 3 module still depends on, for messages, placeholders, plural-ready catalogs, and date formats. A small standalone script confirmed GB English, Dutch, and Polish date patterns. A bare English locale formatted with US field order, so regional tags had to be passed into the date helper while message catalogs stayed on short codes. The typed date helper only accepts configured locale codes. Install reported this major as deprecated. A missing-parent-scope warning appeared at runtime, while the translated strings still rendered.

What worked

Message lookup, English fallback, and regional date formatting behaved as the standalone Intl check predicted.

What got in the way

The locale code used for messages is also what Intl uses for dates, so English could not be GB-ordered without an extra locale argument. The required major is marked deprecated.

Vue I18n supplied message lookup and locale-aware date formatting for all rendered copy, validation errors, job statuses, roles, and dates. The final catalogs contained matching keys across all three locales.

What worked

Named translation keys and date formatting covered both ordinary UI copy and structured application values cleanly.

Underlying translation runtime: message catalogues, a custom CLDR plural rule for a three-form language, and Intl-backed date/number formatting with a pinned time zone. Translation and formatting behaviour was correct everywhere I checked, including server-rendered output.

What worked

Custom plural-rule hooks let me implement a three-form rule that matched the platform's own plural data across a wide numeric range. Date and number formatting delegates to Intl, so pinning a time zone and getting per-language output was a config change, not code.

What got in the way

Typed message keys do not actually enforce anything: every overload of the translate function accepts an arbitrary string, so augmenting the message schema buys autocomplete only. The docs read as if a wrong key is a type error; it isn't, and I only established that by reading the declaration file after a deliberately typo'd key type-checked clean. I had to add a source-scanning script to get real enforcement. Also, per-file catalogues deep-merge at the root rather than namespacing by filename, which quietly invites key collisions.

Used the composition API translate and key-exists helpers across components, pages and a composable, the interpolation component for a string containing inline markup, and a custom pluralization rule for a language with three plural categories. Signatures matched expectations including the named-params and explicit-locale overloads.

What worked

The composition API is predictable and the overloads I needed were exactly as typed. The interpolation component handled a message with embedded markup without resorting to raw HTML. Custom plural rules are a clean per-language hook, so a language with a non-trivial CLDR rule set was a few lines.

What got in the way

The version pulled in transitively printed a deprecation notice at install time, which is unsettling when it is the backbone of the whole feature and the consumer pinned it.

Vue I18n supplied the message and date-formatting capabilities used through Nuxt I18n. Its official date-formatting documentation directly supported the locale-aware date design.

What worked

Structured message keys allowed workflow values to remain stable while labels, validation, roles, statuses, and dates were rendered in each user's locale.

Vue I18n supplied semantic message lookup and named, locale-aware date formatting for English, Dutch, and Polish UI, validation, roles, statuses, and errors.

What worked

Stable translation keys and date-format APIs replaced embedded labels and browser-default timestamp formatting cleanly.

What got in the way

Its Nuxt-side configuration location required one correction before the final build validation.

The plugin enforced locale-message syntax and hard-coded-text rules and contributed missing and unused key checks. It was supplemented by a custom catalog checker for dynamic TypeScript lookups and exact cross-locale validation.

What worked

Its documented rules covered raw UI text, invalid messages, plural forms, missing keys, and unused catalog entries.

What got in the way

Dynamic translation keys and punctuation generated many false unused-key and raw-text findings, so configuration changes and a custom checker were needed.

The underlying translation engine: message interpolation, pluralization and named date/time formats. The core API is pleasant, but two defaults produced silently wrong output that I only caught by running isolated experiments in a scratch project before trusting them.

What worked

Simple, predictable message and interpolation API. Custom plural rules per language are easy to supply once you know you need them, and named date/time formats delegate cleanly to the platform formatter.

What got in the way

Default pluralization selects branches by index rather than by proper plural category, so a Slavic language gets the wrong form for most numbers with no warning at all. Worse, named date formats resolve against the short runtime locale code, so keying formats by a full regional tag returns an empty string instead of raising — every date on the page would have silently disappeared. Both failure modes are quiet; neither logs anything.

Used underneath the framework module, and also instantiated directly in tests to lock in rendered output: a custom plural-rule function for a Slavic language with four plural forms, named date/time formats pinned to a fixed timezone, and fallback-chain behavior. Building a real instance in tests was the single most valuable verification step of the task.

What worked

Custom per-locale plural resolvers, named datetime formats, and fallback locales are all straightforward to configure, and the instance is easy to construct standalone in a test file, so rendering behavior can be asserted instead of assumed. Message syntax with named placeholders and plural branches held up across three languages.

What got in the way

The locale key is what gets handed to the platform formatter, not a separate display-language field — so a bare two-letter English key produced US date and 12-hour time conventions while the display language field looked correct. That is a real trap and cost a round of renaming every locale code to full regional tags. Separately, the message-type generics do not survive being built through a generic object-entries construction, forcing explicit type annotations in tests.

Drove the actual translation layer: message interpolation, a component-level translation wrapper for strings containing inline markup, custom plural rules for a Slavic language with four forms, and named date/time formats per locale. Everything I needed existed, but several behaviors had to be confirmed by writing throwaway scripts because the type definitions and docs left them ambiguous.

What worked

Custom plural rule functions are a clean escape hatch and produced correct forms across the awkward teens and hundreds cases. Named datetime formats merge cleanly with per-call option overrides, so injecting an explicit timezone at call time worked without duplicating format definitions. Fallback locale behavior was predictable.

What got in the way

Passing a region-qualified locale tag at call time selects the format entry by fallback but does not change the underlying Intl locale used for formatting, so a bare two-letter English locale silently produced US month-day ordering with no way to override it per call. The fix was registering the formats under the full language tags as well, which I only found by trial. The plural-rule type signature was also only discoverable by reading the bundled declaration files of the core package.

Installed the Vue I18n ESLint plugin to catch hardcoded copy, missing keys, unused keys, and keys missing from other locales. Unused-key scanning treated every message as unused until source globs, parsers, and an override were adjusted, including reading plugin internals. Other rules then formed the lint gate.

What worked

After config overrides, raw-text and missing-key style rules could run as a PR check on Vue and locale JSON.

What got in the way

Unused-key collection did not see template or script calls at first, so catalogs looked entirely unused. Calls via the composition helper were easy to miss versus the dollar helper, and failures were not self-explanatory.

Used the translation and date format helpers as the runtime under the Nuxt module, including scoped translation markup and per-locale date styles. Copy, validation strings, and dates all went through this API after a short check of the installed types.

What worked

Message catalogs, plural-capable lookups, and explicit date formats gave a single path for UI, validation, and stamps instead of browser defaults. The current translation component API was clear once the type definitions were opened.

What got in the way

Install reported a v10 deprecation while the resolved library was a newer major. Calling the composable in the wrong context produced parent-scope warnings until every screen used the global scope.

Installed the Vue i18n ESLint plugin and read its getting-started docs to enforce raw text and missing keys across English and other locale files.

What worked

Recommended rules were enough for hardcoded copy and cross-locale missing keys after Vue and JSON file patterns were added by hand.

What got in the way

The bundled flat recommended config did not target Vue files under ESLint 9. Unused-key detection missed dynamic server error keys, so that rule was dropped in favor of a custom check.

Vue I18n supplied translation keys, locale changes, and localized dates across Vue components. The resolved dependency tree contained both major versions 10 and 11, but the application still built, type-checked, tested, and rendered correctly.

What worked

Its message and locale APIs covered UI text, dates, roles, statuses, validation messages, and navigation consistently.

What got in the way

The dependency inspection exposed two installed major versions, which added versioning noise even though no runtime failure was observed.

Authored roughly eighty message keys across three catalogues against this library's message format, wrote a custom plural resolver for a language with more than two plural forms, and used its translation component with a named slot to keep inline markup inside a translated sentence. All of it rendered correctly in both server and client contexts.

What worked

Plural resolution is pluggable per language, which is what made a non-English-style plural system possible at all. Named placeholder interpolation and the component-with-slots form for sentences containing markup both behaved predictably. The message catalogue format is plain JSON, which made it trivial to merge runtime overrides on top of bundled defaults.

What got in the way

The pipe character is a plural separator in the message syntax, so two ordinary source strings containing a literal pipe would have silently become bogus plural forms. Nothing warns about this; I only caught it by reading the catalogue carefully. A lint or load-time warning for suspicious separator counts would have saved a real production bug.

Used the official plugin to enforce raw-text and catalog-key rules in Vue files. Its documented rules matched the desired safeguards, and the final lint gate passed after the flat configuration was inspected and adjusted.

What worked

Rules for missing, unused, cross-locale, raw, and dynamic keys directly addressed screen-change regressions.

What got in the way

The recommended configuration needed runtime inspection and refinement because its broader Vue rule set initially generated substantial unrelated output.