وب فارسی: فونت، راستبهچپ و اعداد
بیشتر منابع توسعهٔ وب برای زبانهای چپبهراست نوشته شدهاند. نتیجهاش این است که مسائل ما یا اصلاً پوشش داده نمیشوند یا با راهحلهای نصفه.
این مقاله فهرست دامهایی است که در ساخت سایت فارسی مکرر به آنها خوردهایم — از جمله در ساخت همین سایت.
راستبهچپ: از ویژگیهای منطقی استفاده کنید
بزرگترین درس این حوزه در یک جمله: هرگز از ویژگیهای فیزیکی CSS استفاده نکنید.
بهجای margin-left بنویسید margin-inline-start. بهجای
text-align: left بنویسید text-align: start. بهجای left بنویسید
inset-inline-start.
چرا؟ چون ویژگیهای منطقی خودشان با جهت متن میچرخند. یعنی همان CSS در فارسی
و انگلیسی درست کار میکند و افزودن نسخهٔ انگلیسی، یک تغییر dir است نه
بازنویسی CSS.
اگر سایتتان امروز فقط فارسی است، باز هم این کار را بکنید. هزینهاش صفر است و روزی که زبان دوم اضافه شود، تفاوتش هفتهها کار است.
و dir="rtl" روی تگ html، نه روی یک div وسط صفحه.
چیزهایی که نباید بچرخند
اشتباه رایج بعدی: چرخاندن همهچیز.
اینها در راستبهچپ هم چپبهراست میمانند:
- شمارهٔ تلفن، کد ملی، شمارهٔ کارت. ترتیب ارقام عوض نمیشود.
- آدرس ایمیل و URL.
- کد و دستور فنی.
- نمادهای پخش رسانه. دکمهٔ پخش همیشه به راست اشاره میکند.
- نمودار زمانی، معمولاً.
اینها را در ظرفی با dir="ltr" بگذارید، وگرنه مرورگر ترتیبشان را به هم
میریزد — بهویژه وقتی با متن فارسی در یک خط باشند.
و نمادهای جهتدار باید بچرخند: فلش «بعدی» در فارسی به چپ اشاره میکند، نه به راست. این را در همین سایت یک بار بهسختی یاد گرفتیم: نمادی که در یک صفحه تعریف شده بود و به نظر میرسید در همهجا مشترک است، در بقیهٔ صفحات جهتش اشتباه بود.
متن مختلط، سختترین بخش
متن فارسی که در آن کلمهٔ انگلیسی یا عدد هست، الگوریتم دوجهتهای مرورگر را درگیر میکند و نتیجه گاهی عجیب است — بهویژه در انتهای جمله.
مثال کلاسیک: «فایل را در پوشهٔ src/components قرار دهید.» نقطهٔ پایان جمله
ممکن است به سمت غلط بپرد.
راهحلها:
- عبارت لاتین را در
<span dir="ltr">بگذارید. - برای موارد سرکش، از نویسههای کنترل جهت استفاده کنید.
- ورودی کاربر را همیشه در ظرف با جهت مشخص بگذارید — چون نمیدانید چه مینویسد.
فونت
فونت فارسی حجیم است. حروف بیشتر، اشکال اتصالی بیشتر. یک وزن فونت فارسی معمولاً چند برابر معادل لاتینش است.
سه قاعده:
فقط وزنهای استفادهشده را بارگذاری کنید. سایتی که پنج وزن میآورد و از دو تا استفاده میکند، بیجهت سنگین است.
font-display: swap، وگرنه متن تا رسیدن فونت نامرئی میماند و کاربر
صفحهای بدون متن میبیند.
خودمیزبان کنید. سریعتر است و به سرویسی که ممکن است در دسترس نباشد وابسته نیست.
و فاصلهٔ سطرها را بیشتر بگذارید. متن فارسی به دلیل زیر و زبر و اشکال اتصالی، به فضای عمودی بیشتری نیاز دارد. چیزی حدود ۱٫۸ برابر اندازهٔ قلم، نقطهٔ شروع بهتری از مقدار پیشفرض مرورگر است.
نکتهٔ کارایی مرتبط در چرا سایت کند است آمده.
نیمفاصله
نویسهای که در فارسی معنا دارد و در جستوجو مشکل میسازد: «میشود» در برابر «می شود» در برابر «میشود».
هر سه را کاربران مینویسند و هر سه باید همدیگر را پیدا کنند.
راهحل: نرمالسازی در دو نقطه — هنگام ذخیره، و هنگام جستوجو. هر دو طرف باید از یک تابع عبور کنند.
«ی» و «ک» عربی
شایعترین علت «چرا این رکورد پیدا نمیشود» در سامانههای فارسی.
نویسههای ي و ك عربی با ی و ک فارسی کد متفاوتی دارند و از نظر
کامپیوتر دو حرف کاملاً جداگانهاند. کاربری که با صفحهکلید عربی تایپ کرده،
دادهاش با دادهٔ بقیه تطبیق نمیخورد.
و این فقط مسئلهٔ جستوجو نیست: دو مشتری با نام یکسان ولی نویسهٔ متفاوت، دو رکورد جدا میسازند — همان مسئلهٔ دادههای تکراری که در حاکمیت داده گفتیم.
راهحل: یک تابع نرمالسازی که همهٔ ورودیهای متنی از آن عبور کنند — تبدیل نویسههای عربی به فارسی، یکسانسازی اعداد، حذف فاصلهٔ اضافه.
هزینهاش یک روز کار است اگر از روز اول باشد، و یک پروژهٔ پاکسازی داده اگر بعداً.
اعداد
سه دسته نویسهٔ عددی در گردشاند: لاتین (123)، فارسی (۱۲۳) و عربی
(١٢٣).
قاعدهای که پیشنهاد میکنیم:
- در پایگاه داده، همیشه لاتین. عدد فارسی که بهعنوان متن ذخیره شود، مرتبسازی و محاسبه را میشکند.
- در نمایش، فارسی اگر با هویت بصری میخواند.
- در ورودی، هر سه را بپذیرید و در لحظهٔ ذخیره تبدیل کنید. کاربری که با صفحهکلید فارسی شمارهٔ تلفن میزند، نباید خطا بگیرد.
و جداکنندهٔ هزارگان را فراموش نکنید. «۱۲۵۰۰۰۰۰ تومان» خوانا نیست.
تاریخ شمسی
تصمیمی که باید زود گرفته شود:
ذخیرهسازی همیشه میلادی، ترجیحاً بهصورت زمان استاندارد. تبدیل فقط در لایهٔ نمایش.
سامانهای که تاریخ شمسی را بهصورت متن ذخیره میکند، در محاسبهٔ اختلاف تاریخ، مرتبسازی و گزارشگیری به مشکل میخورد — و اصلاحش بعداً یعنی مهاجرت داده.
تقویمگزین باید شمسی باشد. کاربر ایرانی «۱۴۰۵/۰۵/۲۰» میفهمد، نه
2026-08-11.
و سال کبیسهٔ شمسی قاعدهٔ خودش را دارد که با میلادی یکی نیست. کتابخانهٔ معتبر استفاده کنید، خودتان محاسبه نکنید.
چند نکتهٔ رابط کاربری
فرمها: برچسب سمت راست، و ترتیب پیمایش با Tab از راست به چپ. اگر
چیدمان با ویژگیهای منطقی ساخته شده باشد، این خودبهخود درست است.
اعتبارسنجی شمارهٔ تلفن باید صفر اول، +98 و اعداد فارسی را بپذیرد.
پیام خطا به فارسی روشن، نه ترجمهٔ تحتاللفظی متن انگلیسی کتابخانه.
جدولها: ستون اول سمت راست. و اعداد در ستونهای عددی، چپچین بمانند تا ارقام همتراز شوند.
و یک هشدار دربارهٔ ابزارها
خیلی از کتابخانههای رابط کاربری ادعای پشتیبانی راستبهچپ دارند و در عمل ناقصاند: منوی کشویی که از سمت غلط باز میشود، اسلایدر که برعکس حرکت میکند، تقویم که چیدمانش به هم میریزد.
پیش از انتخاب هر کتابخانهای، یک نمونهٔ واقعی با محتوای فارسی بسازید و امتحان کنید. نه صفحهٔ نمایش خودشان — نمونهٔ خودتان، با متن فارسی و عدد و تاریخ.
این نیمروز کار، هفتهها دردسر بعدی را حذف میکند.