RTL مسئله‌ی ترجمه نیست

اگه برای بازار فارسی محصول می‌سازی — یا هر زبان دومی — i18n یه مسئله‌ی سیستمی‌ست، نه مسئله‌ی استرینگ. بیشتر تیم‌ها استرینگ‌ها رو ترجمه می‌کنن و امیدوارن لایه‌آوت سر جاش بمونه. اینجوری‌ست که محصولت توی بازار خودت خراب به نظر می‌رسه.

وقتی پشتیبانی فارسی خواستم، اولش اشتباه خواستم. گفتم: زبان رو اضافه کن، جهت رو برعکس کن، فونت درست رو بذار. نتیجه سایتی بود که صفحه‌های فارسی داشت ولی سیستم طراحی نداشت. بریدکرامب‌ها جهت اشتباه می‌رفتن. ردیف‌های فلکس آینه نمی‌شدن. آیکون‌ها جهت اشتباه داشتن. حسش ترجمه‌بودن بود، نه ساخته‌شدن.

ترجمه یه مشکل محتواست. RTL یه مشکل سیستم‌طراحیه. دومینو درست نکنی، اولی دیده نمی‌شه.


IRANSansX: فونت نیست، نیازمنده

فارسی تراکم بصری‌ای داره که انگلیسی نداره. فونت باید حملش کنه.

سایت از قبل Outfit برای لاتین و JetBrains Mono برای کد داشت. فارسی به فونت متغیر خودش نیاز داشت: IRANSansX، لودشده از فایل‌های محلی با کانفیگ خاص — اکسیس DOTS روی ۷.

هفت نقطه

IRANSansX چند کانفیگ نقطه داره. DOTS ۷ هم‌خونه‌ست با اون‌جوری که فارسی امروز واقعاً خونده و چاپ می‌شه.

نگاشت وزن

تیترهای فارسی برای رسیدن به جرم بصری لاتین به وزن سنگین‌تر نیاز دارن: h1 با ۸۰۰، h2 با ۷۰۰، h3 و پایین‌تر با ۶۰۰، از طریق قواعد [dir="rtl"].

فونت به یونیکد-رنج عربی و فارسی محدود شد تا هیچ‌وقت با Outfit رقابت نکنه. دو فونت، صفر هم‌پوشانی، یک سیستم طراحی.

اگه فونت چسب‌زده باشه، متن هم چسب‌زده به نظر میاد. فارسی متراکم‌تره؛ اکسیس سنگین‌تر می‌خواد.


جهت یه توکنه، نه یه هک

صفر ml/mr/pl/pr هاردکد. همه‌چیز logical، همه‌چیز آینه‌شونده.

قانون حسابرسی مطلق بود: هیچ utility فیزیکی هیچ‌جا. نه ml، نه mr، نه pl، نه pr، نه left، نه right. هر مارجین و پدینگ از نسخه‌های logical استفاده می‌کنه — ms، me، ps، pe — تا جهت با dir="rtl" خودکار عوض بشه.

۰۱

utilityهای logical ms/me/ps/pe/start/end همه‌جا. همون کلاس توی هر دو جهت کار می‌کنه.

۰۲

وسط‌چینی ناو وسط‌چینی مطلق با left-1/2 -translate-x-1/2 که تغییر جهت رو دوام می‌آره.

۰۳

برعکس‌بودن ردیف sm:flex-row توی RTL به row-reverse تبدیل می‌شه تا justify-between درست جا بیفته.

روزی که یه مارجین برای یه جهت هاردکد کنی، همون روزه که یه سایت دوم منتشر کردی. propertyهای logical تنها مسیرن.


حسابرسی‌ای که ترک‌ها رو پیدا کرد

فلپ‌های دوبل، آیکون‌های آینه‌نشده و بلوک‌های کدی که زیر bidi خراب می‌شدن.

حسابرسی خط‌به‌خط روی همه‌ی صفحات، باگ‌هایی رو پیدا کرد که توی جزئیات زندگی می‌کنن. ناو فلپ دوبل داشت: flex-row-reverse به‌علاوه‌ی dir="rtl" که همدیگه رو خنثی می‌کردن. فوتر همون باگ رو داشت. فلش‌های اسلایدر جهت اشتباه داشتن. بلوک‌های کد — که همیشه باید LTR بمونن — داشتند با متن دوجهته خراب می‌شدن.

فلپ دوبل ناو

flex-row-reverse به‌علاوه‌ی dir=rtl همدیگه رو خنثی می‌کردن. فلپ دستی حذف شد؛ dir=rtl خودش آینه می‌کنه.

کد زیر bidi

pre و code مجبور به LTR شدن تا کد توی صفحه‌ی فارسی خونا بمونه.

RTL درست، نامرئیه. وقتی غلط باشه، هر بازدیدکننده‌ی فارسی حس می‌کنه سایت برای یکی دیگه ساخته شده.

راه‌حل‌ها سیستماتیک بودن، نه حدسی: هر قانون حساس به RTL حسابرسی شد، هر آیکون جهت‌دار با کلاس مشترک rtl-flip چرخید، هر ردیف فلکس توی هر دو جهت تایید شد. اگه با AI بومی‌سازی می‌کنی، یادت باشه: مدل می‌تونه استرینگ‌هات رو ترجمه کنه، ولی نمی‌تونه لایه‌آوتت رو از نو طراحی کنه. اون بخش کار خودته.


RTL رو درست منتشر کن

اگه برای بازار فارسی بومی‌سازی می‌کنی، از سیستم شروع کن، نه از استرینگ‌ها.

۱

اول فونت رو طراحی کن. فارسی به فونت متغیر خودش با حالت نقطه و نگاشت وزن درست نیاز داره. یه فونت لاتین که کش اومده توی فارسی، یه باگه.

۲

utilityهای فیزیکی رو ممنوع کن. با grep دنبال ml/mr/pl/pr/left/right بگرد و حذفشون کن. propertyهای logical قراردادن.

۳

جزئیات رو حسابرسی کن. ناو، فوتر، فلش‌ها، بلوک‌های کد، بریدکرامب. باگ‌های لایه‌آوت توی کامپوننت‌هایی قایم شدن که کمترین لمس رو دارن.

پشتیبانی فارسی یه پروژه‌ی سیستم‌طراحیه با یه خروجی ترجمه. همین‌جوری بسازش.

سایت از فارسی پشتیبانی نمی‌کنه؛ سیستم طراحی ازش پشتیبانی می‌کنه.

یه فونت متغیر، utilityهای logical و یه حسابرسی که فلپ‌های دوبل رو پیدا کرد. RTL پیش‌فرضه، نه استثنا.

معماری دوزبانه رو ببین