i18n
Vy UI components render their own text in only a few places — a close button's label, "Next Page" in pagination, the default screen-reader names covered in a11y. Everything else is content you pass in, so most translation lives in your app, not the library. The goal for i18n is to make the few library-owned strings overridable and to format locale-sensitive values correctly.
What translation covers on Lynx
Lynx runs your JavaScript on a real engine, so the standard Intl APIs — Intl.NumberFormat, Intl.DateTimeFormat, Intl.Collator — are available for formatting numbers, dates, and sorting. What Lynx does not give you is a built-in message catalog or a layout direction primitive, so those are the parts a UI library has to make easy.
The planned approach
- Overridable built-in strings — every library-owned label (close, pagination, clear) resolves through a small message map you can replace per locale, so a French app gets "Suivant" instead of "Next Page".
- A locale provider — set the active locale once near the root; components and the
accessibility-labeldefaults read from it reactively, the same wayuseA11yreads state. - Formatting helpers — thin wrappers over
Intlso a price or date is formatted for the active locale without each component reaching forIntlitself. - RTL — direction-aware layout for Arabic, Hebrew, and similar, so start/end spacing and icon flipping resolve from locale rather than hard-coded left/right.
What you do today
Until this lands, translate at the app level: pass already-localized text into components, and override the handful of built-in labels with the accessibility-label and slot props each component exposes.
<template>
<!-- your text, your translation layer -->
<VyButton>{{ t('cart.checkout') }}</VyButton>
<!-- override a built-in label per locale -->
<VyButton :accessibility-label="t('a11y.addToFavorites')">
<Icon name="heart" />
</VyButton>
</template>
On the roadmap
The locale provider, overridable string map, formatting helpers, and RTL support are all planned — see the roadmap.