I18nProvider: allow a direction prop that overrides the locale's derived text direction
维护者通常 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, becauseisRTLmaximizes 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 readinguseLocale().localesee a tag the app never chose, locales whose default numbering system is Arabic-Indic (ar-EG, barear) switch digits unless the rewrite also carries-u-nu-arab, and a future change to howisRTLdecides would silently break it. - Setting
<html dir="ltr">only covers CSS. The JavaScript half (placements, key swaps, painteddiron overlays) still follows the locale. - A nested
I18nProvidercannot 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
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
adobe/react-spectrum 的其他 Issue
-
Declare @types/react as an optional peer dependency可能已有人在做 @Sophran-fbj 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
adobe/react-spectrum#10940 ·
维护者通常 1 天内回复
-
@internationalized/number: NumberParser misparses Arabic-digit numbers that use . , or ، (sd parses ١٬٢٣٤.٥ as 12345)可能已有人在做 @itsrayeedscodespace 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
adobe/react-spectrum#10936 · 3 条评论 ·
维护者通常 1 天内回复
-
PreviewTrigger: the preview dialog has no accessible name可能已有人在做 @therealemmanueloppong 于 6 天前认领。 未关闭accessibility bug PreviewTrigger
难度 2/5 1-3 小时 新手友好度 76/100
adobe/react-spectrum#10917 · 3 条评论 ·
维护者通常 1 天内回复
-
S2 quiet Picker menu is always 192px wide: its width calc() has no unit可能重新可做 @darshpatel1052 于 9 天前认领,目前没有进行中的 PR。 未关闭waiting on author
难度 2/5 1 小时以内 新手友好度 88/100
adobe/react-spectrum#10909 · 3 条评论 ·
维护者通常 1 天内回复
-
DatePicker omits timezone for initially empty fields despite zoned placeholderValue可能已有人在做 @mrlexcoder 于 9 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 68/100
adobe/react-spectrum#10900 · 2 条评论 ·
维护者通常 1 天内回复
查看 adobe/react-spectrum 的全部 Issue
相似的 Issue
-
maintenance
难度 2/5 1-3 小时 新手友好度 73/100
assistant-ui/assistant-ui#10499 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug server-sequentialthinking v2
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/servers#5526 · 1 条评论 ·
维护者通常 1 天内回复
-
app-server bug CLI
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
better-auth/better-auth#12458 · 1 个 reaction ·
维护者通常 1 天内回复