I18nProvider: allow a direction prop that overrides the locale's derived text direction

Aperta
  • Qualcosa non va?
#10,954 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
58/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
frontend, internationalization

Direzione di ricerca

Start at I18nProvider and the useDefaultLocale path, then trace how the context derives direction and how useLocale() exposes it. Check the existing provider and locale tests; done means an optional override controls direction while the locale, translations, date formatting and number formatting remain unchanged, and omitting it preserves current behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Provide a general summary of the feature here

Let I18nProvider take an optional direction prop ('ltr' | 'rtl') that overrides the text direction derived from locale, so an app can keep a left-to-right layout while using a right-to-left locale for strings, dates and numbers.

🤔 Expected Behavior?
<I18nProvider locale="ar-AE" direction="ltr">
  <App />
</I18nProvider>

Everything that reads useLocale().direction (arrow-key swaps in Tabs, RadioGroup, Menu and ListBox, start/end placements and the dir attribute on Popover roots, DateField segment order, Calendar chevrons) behaves as left-to-right, while useLocale().locale stays ar-AE and the Arabic string dictionaries, useDateFormatter and useNumberFormatter output are unchanged. When direction is omitted, behavior is exactly today's.

😯 Current Behavior

I18nProvider accepts only locale. The context value computes direction from isRTL(locale) and the context is module-local, so there is no supported way to supply a direction that differs from the one the locale implies. A product that does not support mirrored layouts (its CSS is logical, but design and QA only cover left-to-right) still gets mirrored keyboard behavior, overlay placement and dir="rtl" on overlays the moment it passes an Arabic or Hebrew locale for translations.

💁 Possible Solution

Add direction?: Direction to I18nProviderProps and use it in the memoized context value:

direction: props.direction ?? (isRTL(locale) ? 'rtl' : 'ltr')

The default-locale path (useDefaultLocale) would apply the same override. No other call site needs to change, because every consumer already reads direction from the context.

🔦 Context

We tried the alternatives before asking:

  • Rewriting the locale to an explicit Latin script before it reaches the provider (ar-AE → ar-Latn-AE) works, because isRTL maximizes the locale and reads the script. Strings, dates, numbers and keyboard behavior all come out right. But it is a workaround on a derived value: consumers reading useLocale().locale see a tag the app never chose, locales whose default numbering system is Arabic-Indic (ar-EG, bare ar) switch digits unless the rewrite also carries -u-nu-arab, and a future change to how isRTL decides would silently break it.
  • Setting <html dir="ltr"> only covers CSS. The JavaScript half (placements, key swaps, painted dir on overlays) still follows the locale.
  • A nested I18nProvider cannot help: the context has no direction input.

A first-class prop makes the intent explicit and keeps the locale tag honest.

💻 Examples

Minimal reproduction of the current behavior: render <I18nProvider locale="ar-AE"><Tabs>…</Tabs></I18nProvider> with <html dir="ltr">; pressing ArrowRight on the first tab moves to the last tab, and a Popover with placement="bottom end" aligns to the trigger's left edge, although the document is left-to-right. Versions: [email protected], [email protected].

🧢 Your Company/Team

A design-system team building an accessible component library on React Aria Components.

🕷 Tracking Issue

No response

Lingua principale
TypeScript
Stelle
16k
Fork
1.6k
Merge medio
4g 10h
PR unite (30g)
42

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di adobe/react-spectrum

Tutte le issue di adobe/react-spectrum

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.