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

オープン
  • 何か問題がありますか？
#10,954 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
react, typescript
領域
frontend, internationalization

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
16k
フォーク
1.6k
平均マージ
4日 10時間
マージ済み PR（30日）
42

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

adobe/react-spectrum のほかの issue

adobe/react-spectrum の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。