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

未关闭
#10,954 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
58/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
react, typescript

调研方向

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 小时
30 天内合并 PR
42

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

adobe/react-spectrum 的其他 Issue

查看 adobe/react-spectrum 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。