RTL 是从第一张线框图就要承担的约束，而非 CSS 镜像

团队说他们“支持阿拉伯语”，意思往往是他们把字符串过了一遍翻译。然后布局翻转过来，接缝就显露了：箭头指向错误的方向，内边距卡在它被硬编码到的那一侧，数字在句子中间错乱。从右到左不是您在最后翻转的一面镜子。它是一项您从第一张线框图就要承担的约束。

在我们的构建中，它真正需要的是：文档的方向在服务端就被决定，并随首屏（first paint）一同交付——locale 会在任何东西渲染之前就设定 dir="rtl" 和 lang，因此不会出现从左到右的布局在水合（hydration）之后才突兀翻转的闪烁。方向性的视觉提示按含义而非偶然地镜像：箭头通过一次刻意的 transform 翻转，布局使用逻辑属性（start/end，而非 left/right），从而让外边距、边框和对齐跟随阅读轴向，而不是某个被硬编码的一侧。内嵌的拉丁单词、数字与等宽 token 经过 bidi 隔离，因此“Brief #A7F3”或“LCP < 2.5s”能在一句阿拉伯语中保持完整而不重新排序；为拉丁大写字母设定的字母间距被中和，使相连的阿拉伯文字不会在视觉上被打断。就连事务性邮件也以从右到左的方向发出。

这不仅仅关乎阿拉伯语。本站还以俄语和中文提供了完整翻译的内容，因此那些访客读到的是母语文案——而不是英文上拼接了一些别的词。翻译是入场的基本门槛；方向感知的布局才是大多数团队跳过的那部分。

我们拒绝这样做：机器翻译后直接发布，把 RTL 当作 CSS 的事后补救，或者让一套只在英文中呼吸过的布局来决定其他每一种语言如何排布在页面上。我们不以“它能渲染”来衡量质量——阿拉伯语必须读起来像是它最先被设计出来的那样。

原则是：一种语言不是一张字符串表，而是一套阅读系统。对从右到左而言，这意味着方向要在首屏就确定、逻辑属性要优先于硬编码的一侧、数字要经过 bidi 隔离——而不是在最后拼上一张翻转的样式表。当阿拉伯语读起来像是有意为之而非移植而来，您就是为它而构建了站点，而不是绕着它构建。