Skip to content

ADR-005: Universal `getI18n()` Runtime Model

A recurring source of complexity in JavaScript i18n tooling is splitting runtime access across multiple patterns:

ADR-005: Universal getI18n() Runtime Model

Status: Accepted Date: 2026-03-17

Context

  • hook-like APIs for components
  • direct runtime objects for non-component code
  • separate client and server access paths

That tends to create several problems:

  • users must choose between overlapping abstractions
  • transform output becomes harder to standardize
  • the runtime contract depends too much on framework-specific expectations
  • server behavior becomes harder to explain and validate

Palamedes needs one runtime primitive that transformed code can target consistently.

Decision

Palamedes uses a single runtime access primitive: getI18n().

The model is:

  • transformed code targets getI18n()
  • runtime consumers may also use getI18n() directly when appropriate
  • client and server differ in how the active instance is installed, not in the public runtime access primitive

Operationally:

  • on the client, getI18n() resolves the active client-side instance
  • on the server, getI18n() resolves the active request-local instance
  • if no active instance exists, the runtime should fail loudly rather than returning an incorrect fallback

Palamedes does not adopt a split public model like:

  • hook-shaped access for one environment
  • direct runtime access for another environment

Alternatives Considered

1. Separate client and server runtime APIs

Rejected because it complicates transform output and makes the mental model harder to teach.

2. Hook-shaped public runtime primitives

Rejected because the core problem is active-instance lookup, not component hook semantics.

3. Silent fallback behavior when no runtime is installed

Rejected because returning the wrong locale or stale runtime state is a correctness bug, not a recoverable convenience path.

Consequences

  • Transform output can standardize on a single runtime target.
  • Framework adapters must install the active i18n instance correctly for their host environment.
  • Server-side correctness depends on explicit request-local runtime setup.
  • Palamedes stays closer to a portable runtime contract than to framework-specific runtime idioms.