[dylanpulver]

Intent

Some controls take their direction from their content rather than from the reading order of the UI. A media playback bar stays left to right in an RTL UI. A manga page position bar runs right to left in an LTR UI. Today the only direction available is the locale's, so these are mirrored the wrong way with no way to opt out.

This PR started as a direction prop on Slider. Per review (#10537, and this comment) it is now an override on I18nProvider, which covers every direction-aware component instead of one, and which nests, so part of a subtree can be put back to the locale direction.

Closes the slider half of #10112. Reverses the decision in #6469.

What changed

I18nProvider takes an optional direction. When set it replaces the direction implied by the locale. The locale itself is untouched, so formatters and translated strings inside an ltr-pinned Arabic subtree are still Arabic.

SliderFill anchors with a physical left or right from useLocale() rather than with insetInlineStart. The thumb has always been positioned with a physical left against that same direction, while insetInlineStart resolves against the document, so the two disagreed under an override and the fill and the thumb landed on opposite edges. With no override the resolved edge is unchanged and only the property name differs, which is why three existing SliderFill assertions move from insetInlineStart to left.

Because I18nProvider renders no DOM, an override does not change what CSS logical properties resolve against. The prop doc and the new story both set dir on an element inside the provider, the way Provider in @react-spectrum/s2 and the I18n docs example do.

Tested

In en-US and ar-AE, with and without an override, horizontal and vertical:

• Keyboard arrows
• Mouse drag
• Track click
• Fill and thumb on the same edge

Not tested: screen readers. Nor high contrast or zoom levels.

235 passing across the 11 slider and i18n suites, 3,289 passing across the three core packages. oxlint and oxfmt --check clean. tsc --noEmit reports only the three pre-existing @mdx-js/react duplicate-JSX errors from node_modules. Reverting the override in I18nProvider fails 13 of these tests.

Written with AI assistance (Claude Opus 5). The numbers above are from runs on this machine.

[yihuiliao]

Thanks for the PR! You'll need to sign the CLA and then close/re-open the PR to trigger a re-run

[snowystinger]

Thanks for the PR. I had a chat with Adobe's i18n and linguistics, the direction of the slider isn't restricted to only being LTR in an RTL UI. There are cases where it will need to be RTL in an LTR ui.

If it represents reading or navigation order, the content's reading direction may determine it.
Therefore, a Japanese manga should typically start from the right, even within an LTR UI.

Instead of a boolean, I'm leaning more towards something like direction?: 'ltr' | 'rtl'

[snowystinger]

Thanks for the updates, we had another round of discussions today.

Since this may be necessary for other components, we want to go in the direction this comment suggested #10112 (comment) with the expectation that users would wrap their timeline sliders with an I18nProvider that overrides the direction.

We could also consider supporting a direction prop on I18nProvider as an override to the default determined from the locale. That would make it work for other components that are direction aware too.

If there are things inside the slider which should not have the direction changed (beyond just text since that already exists nesting within a dir) then they would wrap that particular portion of the control with another I18nProvider to set it back to the original.

If you don't have time to make the change, let us know. Thanks again!

noting that we're reversing the decision in Ability to manually set direction to RTL

[dylanpulver]

Made the change. I18nProvider takes direction as an override of the locale direction, the Slider prop is gone, and the slider source files are back to upstream.

One thing the approach needs, and it is a decision for you. I18nProvider renders no DOM, so an override changes what useLocale() returns but not what CSS logical properties resolve against. SliderFill was anchored with insetInlineStart while the thumb is positioned with a physical left, so under an override the fill and the thumb ended up on opposite edges. I anchored the fill physically from useLocale() too, so both come from one source of truth. With no override the resolved edge is the same and only the property name changes, which is why three existing SliderFill assertions move from insetInlineStart to left.

That hazard applies to any component that styles itself with logical properties inside an overridden subtree, so the story and the prop doc both say to set dir on an element inside the provider. Provider in @react-spectrum/s2 and the I18n docs example already do that. If you would rather I18nProvider render a dir element itself, say so and I will, though it stops being context-only.

Tested in en-US and ar-AE, with and without an override, horizontal and vertical:

• Keyboard arrows
• Mouse drag
• Track click
• Fill and thumb on the same edge

Not tested: screen readers. Nor high contrast or zoom levels.

From this machine: 235 passing across the 11 slider and i18n suites, 3,289 passing across the three core packages. oxlint and oxfmt --check are clean. tsc --noEmit reports only the three pre-existing @mdx-js/react duplicate-JSX errors from node_modules. Reverting the override in I18nProvider fails 13 of these tests.