یک قالب را راست‌چین می‌کنید؛ منو از راست باز می‌شود و متن فارسی به نظر درست می‌آید. بعد کاربر کد رهگیری را کپی می‌کند و ترتیب نویسه‌ها عوض می‌شود، پیام خطای شماره موبایل راه اصلاح را نمی‌گوید، «تومان» کنار عدد اشتباه خوانده می‌شود و فونت دیرهنگام کل صفحه را جابه‌جا می‌کند. این‌ها مشکل سلیقه نیستند؛ شکست قرارداد زبان، داده، جهت و تعامل‌اند.
پاسخ کوتاه: طراحی سایت فارسی فقط direction: rtl نیست. باید زبان و جهت در Markup، متن دوزبانه با Bidi isolation، فونت و Fallback، اعداد/تاریخ/واحد، فرم و جست‌وجو، CSS logical properties، دسترس‌پذیری، Performance و QA با داده واقعی ایران هم‌زمان طراحی شوند.
این راهنما برای طراح محصول، توسعه‌دهنده Frontend، Content designer و مدیر سایتی است که می‌خواهد تجربه فارسی را از چند Patch موردی به یک Design/Engineering contract قابل آزمون تبدیل کند.
طراحی سایت فارسی چه مسئله‌ای را حل می‌کند؟
«فارسی» چند بُعد مستقل دارد. اگر آن‌ها را یکی فرض کنید، خطاهای پنهان ایجاد می‌شود:
| بُعد | نمونه | تصمیم طراحی |
|---|---|---|
| Language | فارسی در برابر انگلیسی | lang، واژگان، لحن و زبان هر بخش |
| Script | خط فارسی/عربی در برابر لاتین | Glyph coverage، Font و ترکیب حروف |
| Direction | RTL در برابر LTR | dir، Bidi isolation و ترتیب Component |
| Locale | fa-IR و نیاز بازار ایران | تاریخ، عدد، پول، آدرس، تلفن و اصطلاح |
| Region/Market | شبکه، پرداخت و خدمت داخل ایران | Integration، Performance، پشتیبانی و قوانین قابل اعمال |
| Content domain | فروشگاه، بانکداری، سلامت یا B2B | واژگان، خطا، Evidence و حساسیت داده |
جهت ویژگی Script است، نه خود Language؛ متن فارسی عمدتاً RTL است اما URL، ایمیل، کد و عبارت لاتین داخل آن LTR باقی می‌مانند. یک «حالت RTL» عمومی تمام این ترکیب‌ها را حل نمی‌کند.
قرارداد پایه سند: lang، dir و UTF‑۸
برای صفحه فارسی، زبان و جهت پایه را در عنصر HTML اعلام کنید:
<html lang="fa" dir="rtl">
...
</html>W3C برای سندی که جهت غالب آن راست‌به‌چپ است، افزودن dir="rtl" به عنصر html و استفاده از Unicode/UTF‑۸ را توصیه می‌کند. Direction را فقط با CSS یا جابه‌جایی بصری متن تعریف نکنید؛ Markup معنا را به Browser و فناوری کمکی می‌رساند.
اگر بخشی انگلیسی است، زبان و در صورت نیاز جهت همان بخش را مشخص کنید:
<p>راهنمای <span lang="en" dir="ltr">Core Web Vitals</span> را بخوانید.</p>این Markup به تلفظ Screen reader، انتخاب Font/Fallback و پردازش متن کمک می‌کند. lang و dir جای یکدیگر نیستند.
از Content stress شروع کنید، نه Lorem Ipsum
قالبی که با دو کلمه انگلیسی زیباست، با عنوان فارسی طولانی، نیم‌فاصله، قیمت و نام محصول مختلط ممکن است بشکند. در Design system یک Dataset ثابت بسازید:
- عنوان کوتاه، معمولی و بسیار بلند؛
- پاراگراف با نیم‌فاصله، گیومه فارسی، پرانتز و درصد؛
- نام فرد/محصول فارسی، عربی و لاتین؛
- URL، ایمیل، IP، نسخه نرم‌افزار و کد رهگیری؛
- عدد منفی، اعشار، بازه، درصد، ریال و تومان؛
- تاریخ شمسی و میلادی با Label روشن؛
- حالت Empty، Error، Loading، Offline و Permission denied؛
- متن دکمه در حالت Normal، Pending، Success و Retry.
این Dataset را روی Card، Table، Modal، Toast، Form، Chart، Navigation و موبایل اجرا کنید. طراحی فارسی یک فعالیت آخر پروژه نیست؛ باید در Prototype و Component acceptance حضور داشته باشد. فرایند تحقیق، Journey و تست کاربردپذیری در راهنمای تجربه کاربری UX توضیح داده شده است.
انتخاب فونت فارسی: نام فونت کافی نیست
«بهترین فونت فارسی» پاسخ واحد ندارد. Font باید با نقش محتوا، برند، دستگاه، Browser و محدودیت Performance Fit باشد. یک Scorecard بسازید:
| معیار | آزمون | Failure رایج |
|---|---|---|
| خوانایی | Body کوچک، تیتر، عدد، جدول و موبایل | تمایز کم حروف یا فشردگی در اندازه کوچک |
| Glyph coverage | فارسی، عربی، لاتین، علائم و ارقام | Fallback داخل یک کلمه یا نماد گمشده |
| Weight/style | وزن واقعی موردنیاز و Italic policy | Bold/Italic مصنوعی Browser |
| Metrics | x-height/line box و Fallback نزدیک | Layout shift هنگام تعویض Font |
| License | مجوز Web، Domain، App و Embed | استفاده خارج از مجوز یا نبود فایل به‌روزرسانی |
| Performance | حجم WOFF2، تعداد فایل و زمان دریافت | دانلود چند وزن/Subset غیرمصرفی |
| Operations | Version، Owner و Rollback | تعویض فایل بدون Regression test |
Typography token به‌جای تنظیم صفحه‌ای
اندازه، Line-height، Weight، Measure و فاصله پاراگراف را در Token تعریف کنید. مقدارها را از روی تصویر ثابت کپی نکنید؛ با متن واقعی و Zoom آزمایش کنید:
| Token | تصمیم | پذیرش |
|---|---|---|
| Body | Size/line-height/weight | خوانا در موبایل و ۲۰۰% Zoom |
| Heading | Scale و Wrap | عنوان بلند قطع یا Overlap نشود |
| Label | اندازه و Contrast | Placeholder جای Label نباشد |
| Numeric | رقم و Alignment | جدول و قیمت قابل مقایسه بماند |
| Code/ID | Monospace/Fallback و LTR | کپی مقدار، ترتیب منطقی را حفظ کند |
Font loading و Layout shift
فقط وزن‌ها و Styleهای مصرفی را ارسال کنید، از WOFF2 و Subset معتبر استفاده کنید و Fallback نزدیک به Metrics فونت اصلی انتخاب کنید. font-display را با نیاز محصول بسنجید؛ نمایش سریع متن مهم است، اما تعویض دیرهنگام نباید CTA یا Form را جابه‌جا کند. راهنمای web.dev استفاده از Subset/unicode-range و کنترل Font display را برای کاهش دانلود و Layout shift شرح می‌دهد.
اندازه‌گیری را روی صفحه واقعی با Font فارسی، شبکه و Device واقعی انجام دهید؛ Demo انگلیسی یا Cache گرم معیار نیست.
فاصله‌گذاری و Justify در متن فارسی
Line-height و فاصله پاراگراف باید با Font و Measure آزمایش شوند. مقدار ثابت پیکسلی که با بزرگ‌شدن متن تغییر نمی‌کند، احتمال Cut/Overlap را بالا می‌برد. WCAG ۲.۲ می‌خواهد تغییر Text spacing باعث از دست‌رفتن محتوا یا عملکرد نشود.
Justify در ستون باریک یا متنی با واژه‌های بلند می‌تواند فاصله‌های نامتوازن بسازد. آن را Default عمومی نکنید؛ روی طول‌های مختلف و Zoom تست کنید. هدف «تراز کامل دو لبه» نیست، خواندن بدون گم‌کردن خط است.
RTL در CSS: Start/End را جای Left/Right بنشانید
Component دو جهته را با CSS logical properties بسازید تا جای Patchهای جدا کم شود:
.card {
padding-inline: 1rem;
border-inline-start: 4px solid var(--accent);
text-align: start;
}
.icon-label {
margin-inline-end: .5rem;
}از margin-left، right و Borderهای فیزیکی فقط وقتی واقعاً به جهت فیزیکی وابسته‌اند استفاده کنید. Flex/Grid visual order را برای تغییر ترتیب معنایی به کار نبرید؛ DOM باید ترتیب منطقی خواندن و Focus را حفظ کند.
چه چیزهایی Mirror می‌شوند؟
| عنصر | Policy معمول | دلیل |
|---|---|---|
| Back/Forward arrow | متناسب با Navigation mirror شود | جهت حرکت در جریان |
| Breadcrumb chevron | با ترتیب مسیر هماهنگ شود | رابطه والد/فرزند |
| Stepper/Timeline | با منطق Progress محصول | شروع و پایان باید روشن بماند |
| Play/Pause | معمولاً Mirror نشود | نماد رسانه‌ای جهانی، نه جهت متن |
| Logo/Trademark | Mirror نشود | هویت ثابت |
| Phone/Email/Search icon | معمولاً Mirror لازم نیست | جهت‌پذیر نیستند |
| Chart axis | بر اساس معنای داده | زمان/مختصات را کورکورانه معکوس نکنید |
قانون را در Icon registry ثبت کنید: directional، non-directional یا product-specific. چرخاندن کل Container با CSS می‌تواند Text، Shadow و Gesture را هم ناخواسته تغییر دهد.
متن دوزبانه و Bidi؛ جایی که ظاهر فریب می‌دهد
Unicode Bidirectional Algorithm اغلب ترکیب متن را درست نمایش می‌دهد، اما رشته‌های مستقل مانند نام کاربر، کد، URL و مقدار Dynamic می‌توانند روی علائم اطراف اثر بگذارند. برای محتوایی با جهت ناشناخته از bdi یا dir="auto" استفاده کنید:
<p>
سفارش <bdi>AB-1405-92</bdi> با وضعیت «ارسال‌شده» ثبت شد.
</p>
<input name="search" dir="auto">اگر جهت مقدار را می‌دانید، آن را در یک عنصر نزدیک و مشخص Isolate کنید. فاصله اضافی، جابه‌جایی دستی کاراکترها یا تبدیل کل جمله به تصویر، راه‌حل پایدار نیست. داده باید در ترتیب منطقی ذخیره و Markup مسئول نمایش باشد.
مواردی که باید جدا تست شوند
- پرانتز و گیومه کنار عبارت انگلیسی؛
- علامت منفی، درصد و واحد کنار عدد؛
- URL با Query parameter و Hash؛
- Email و نسخه نرم‌افزار؛
- کد رهگیری، شماره سفارش و شناسه تراکنش؛
- نام کاربر Dynamic در Table و Notification؛
- Copy/Paste به پیام‌رسان، Excel و فیلد پشتیبانی.
ی و ک، نیم‌فاصله و Normalization
تفاوت «ی/ی» و «ک/ک»، نیم‌فاصله، فاصله معمولی و ارقام فارسی/عربی/لاتین می‌تواند Search، Dedup، Sort و Validation را خراب کند. راه‌حل، تغییر کور همه داده نیست.
| لایه | Policy | هشدار |
|---|---|---|
| Display | Style و شکل مورد انتظار مخاطب | معنا یا شناسه فنی را تغییر ندهید |
| Input | فرمت‌های رایج را تحمل و راهنما بدهید | مقدار کاربر را هنگام خطا پاک نکنید |
| Normalization | برای Search/compare یک Canonical form مشخص | نسخه خام را در صورت نیاز Audit نگه دارید |
| Storage | Schema و Encoding ثابت | Display formatting را در داده اصلی نریزید |
| Identifier | Exact و بدون تبدیل غیرمجاز | Tracking، Token و Password را Normalize نکنید |
Policy را Field-specific بنویسید. نام محصول برای Search با Token یا شناسه امنیتی یکسان نیست. Normalize در Client برای UX کافی نیست؛ Validation و قواعد اصلی باید در Server نیز اعمال شوند.
اعداد، قیمت و واحد پول
«فارسی یا لاتین بودن رقم» یک انتخاب برند عمومی نیست. Context تعیین می‌کند:
- محتوای خواندنی می‌تواند ارقام فارسی داشته باشد؛
- کد، URL، نسخه، IP و شناسه فنی معمولاً باید Exact بمانند؛
- فیلد موبایل باید ورودی فارسی/عربی/لاتین و فاصله/خط تیره رایج را طبق Policy تحمل کند؛
- Table عددی به Alignment و Font numeric مناسب نیاز دارد؛
- علامت منفی، درصد و اعشار در RTL جدا تست شوند؛
- Copy value باید Machine-readable و بدون نویسه تزئینی باشد.
ریال و تومان را مبهم نگذارید
واحد را کنار هر مبلغ یا در Header روشن نشان دهید. اگر Backend ریال و UI تومان است، تبدیل باید یک تابع مرکزی، تست‌شده و بدون Double conversion باشد. در Checkout و Invoice، مبلغ اجزا، تخفیف، ارسال و Total باید همان واحد و Precision را داشته باشند. فقط تغییر Label بدون تغییر مقدار، خطای جدی است.
برای ورودی مبلغ، جداکننده هزارگان را از مقدار ذخیره‌شده جدا کنید. Screen reader و Copy/Paste را نیز تست کنید؛ یک رشته بصری زیبا ممکن است برای فناوری کمکی مبهم باشد.
تاریخ، زمان و تقویم
تاریخ شمسی و میلادی را با Context انتخاب کنید، اما Storage و Exchange را از Display جدا نگه دارید. Timestamp سرور، Timezone و تبدیل تقویم باید قرارداد روشن داشته باشند.
| سناریو | نمایش پیشنهادی | ریسک |
|---|---|---|
| مقاله | تاریخ خوانا با سال کامل | ابهام روز/ماه و محتوای قدیمی |
| مهلت پرداخت | روز/ماه/سال + زمان و Zone لازم | برداشت متفاوت از Deadline |
| گزارش فنی | فرمت ثابت قابل Sort/Export | Sort لغوی یا تبدیل چندباره |
| رزرو | تقویم مورد انتظار کاربر + ISO در Backend | Offset، DST یا روز اشتباه |
| دوزبانه | Label تقویم/Locale روشن | نمایش دو تاریخ بدون توضیح |
فرم فارسی: Label، Keyboard، Validation و Recovery
فرم نقطه‌ای است که زبان، داده، دسترس‌پذیری و کسب‌وکار به هم می‌رسند. W3C توصیه می‌کند هر Control برچسب مرتبط داشته باشد؛ Placeholder جای Label نیست.
قرارداد هر فیلد
| فیلد | باید تعریف شود | تست ایران |
|---|---|---|
| نام | محدوده نویسه، طول و Trim | نیم‌فاصله، نام مرکب و عربی/لاتین |
| موبایل | کشور، Format canonical و Verification | ۰۹، +۹۸، رقم فارسی و Paste |
| کد پستی/شناسه | Exact length/type و privacy | Leading zero و تبدیل‌نشدن رقم |
| آدرس | Fieldهای لازم و Optional | پلاک/واحد، خط چندگانه و RTL/LTR |
| Email/URL | dir="ltr" یا auto و type مناسب | Copy/Paste و علائم اطراف |
| توضیح آزاد | طول، Escape، newline و direction | متن دوزبانه و dir="auto" |
Input mode و Autocomplete
type، inputmode و autocomplete را بر اساس معنای فیلد تنظیم کنید؛ نه برای تغییر ظاهر. Keyboard موبایل را روی Android/iOS واقعی تست کنید. Autocomplete استاندارد می‌تواند ورود نام، تلفن و آدرس را ساده کند، اما فیلد حساس و نیاز امنیتی باید جدا ارزیابی شود.
خطا باید راه اصلاح را بگوید
- خطا را کنار Field و در خلاصه قابل Focus نشان دهید؛
- نام Label و فرمت مورد انتظار را ذکر کنید؛
- فقط رنگ قرمز یا Icon کافی نیست؛
- مقدار درست دیگر Fieldها را حفظ کنید؛
- Focus به اولین خطا یا Summary مدیریت شود؛
- پیام Dynamic برای Screen reader اعلام شود؛
- Client و Server validation هم‌راستا باشند؛
- برای پرداخت/ثبت نهایی، Idempotency و Unknown state در نظر بگیرید.
مثلاً «شماره نامعتبر است» ضعیف است. پیام بهتر می‌گوید «شماره موبایل را با ۰۹ یا +۹۸ وارد کنید؛ فاصله مجاز است.» البته فرمت پذیرفته‌شده باید با Validator واقعی یکسان باشد.
جست‌وجو و فیلتر فارسی
Search فارسی با ترجمه Placeholder حل نمی‌شود. Pipeline را در سطح Query و Catalog طراحی کنید:
- Trim و Normalization تعریف‌شده برای ی/ک و فاصله؛
- مدیریت نیم‌فاصله و شکل‌های رایج واژه؛
- تحمل ارقام فارسی/عربی/لاتین در Field مرتبط؛
- Synonym و اصطلاح بازار با Owner و Evidence؛
- Typo tolerance کنترل‌شده، نه Match بی‌ربط؛
- Zero-result log، Query reformulation و پیشنهاد قابل فهم؛
- Sort/Filter سازگار با Label و داده واقعی؛
- اندازه‌گیری Search→Result click→Outcome.
در فروشگاه، Search و Filter مستقیماً بر کشف محصول اثر دارند. طراحی Journey از Query تا پرداخت در راهنمای UX فروشگاه اینترنتی آمده است.
Navigation، Breadcrumb، Stepper و Carousel
در RTL، فقط Alignment عوض نمی‌شود؛ معنای Start/End و حرکت باید بررسی شود:
- ترتیب DOM با ترتیب خواندن و Focus هماهنگ بماند؛
- Breadcrumb از والد به فرزند معنای روشن داشته باشد؛
- Tab/Carousel با Arrow key و Gesture قابل پیش‌بینی کار کند؛
- Previous/Next را فقط به Arrow بدون Label واگذار نکنید؛
- Stepper شماره و نام مرحله را هم‌زمان نشان دهد؛
- Table در موبایل Header association و دسترسی به ستون‌ها را حفظ کند؛
- Chart legend، Tooltip و Axis با داده LTR/RTL تست شوند.
برای Taxonomy، Navigation و Breadcrumb قابل آزمون، راهنمای معماری اطلاعات سایت را ببینید. Homepage نیز باید پیام و Route درست برای مخاطب فارسی بسازد؛ راهنمای کامل آن در طراحی صفحه اصلی سایت است.
دسترس‌پذیری سایت فارسی
RTL جای دسترس‌پذیری را نمی‌گیرد و دسترس‌پذیری نیز فقط Alt تصویر نیست. WCAG ۲.۲ را در سطح Task و Component بررسی کنید:
| حوزه | تست | Failure فارسی رایج |
|---|---|---|
| Language | lang="fa" و Language of parts | تلفظ عبارت انگلیسی با صدای فارسی |
| Structure | Heading، Landmark، Label و Table header | ظاهر تیتر بدون Markup |
| Keyboard | Tab/Shift+Tab، Escape و Arrow | Focus order برخلاف ترتیب بصری RTL |
| Focus | Visible و unobscured | Outline حذف‌شده یا زیر Header ثابت |
| Contrast | Text، icon، border و state | رنگ خاکستری کم‌رنگ برای Label |
| Reflow | ۳۲۰ CSS px و ۴۰۰% Zoom | عنوان/دکمه بریده یا Scroll دوبعدی |
| Text spacing | افزایش line/word/letter/paragraph spacing | Overlap یا Cut در Card ثابت |
| Target | اندازه یا فاصله کافی | Icon کوچک نزدیک کنترل دیگر |
| Error/Status | Screen reader announcement و recovery | تغییر رنگ بدون پیام |
آزمون خودکار فقط بخشی از خطاها را پیدا می‌کند. Keyboard، Zoom، Screen reader و کاربر واقعی را اضافه کنید. برای تبدیل Failure به Evidence، Cause و Acceptance از چک‌لیست اشتباهات رایج طراحی سایت استفاده کنید.
Responsive فارسی: عرض متن، Zoom و State
Breakpoints را بر اساس شکست محتوا انتخاب کنید، نه مدل دستگاه. فارسی ممکن است طول Button یا Label متفاوتی نسبت به English داشته باشد. تست را روی Viewport، Container، Zoom، Orientation، Input، Locale، Network و State ترکیب کنید.
موارد حساس:
- Nav و CTA با متن بلند؛
- Table و مقایسه قیمت؛
- فرم آدرس، OTP و Keyboard باز؛
- Toast/Modal در Zoom؛
- Card با نام محصول دوزبانه؛
- Sticky control که Focus یا Error را نپوشاند؛
- Skeleton و Loading در همان اندازه محتوای نهایی.
قرارداد کامل CSS، تصویر تطبیقی، Reflow و Device testing در راهنمای طراحی ریسپانسیو آمده است.
Performance در شبکه و دستگاه واقعی ایران
فونت فارسی تنها هزینه نیست. Tag manager، Chat، نقشه، ویدئو، Captcha، Review و درگاه Third party می‌توانند Journey را کند یا شکننده کنند. آزمایش کنید:
- موبایل میان‌رده، Cache سرد و چند شبکه/اپراتور؛
- فونت Self-hosted یا Provider با Fallback؛
- صفحه با محتوای واقعی، نه Template خالی؛
- Critical path فرم و پرداخت با Third party؛
- قطع/Timeout سرویس ثالث و Fallback؛
- Lab برای تشخیص و RUM/Field برای تجربه واقعی؛
- Segment بر Template، Device، Network و Locale.
Performance budget برای JS، CSS، Font، Image و Third party بسازید. اگر افزودن Widget سقف را می‌شکند، Owner باید ارزش و هزینه را مقایسه کند.
سئوی سایت فارسی و نسخه چندزبانه
RTL سیگنال مستقیم رتبه نیست؛ اما Markup، Render، IA و محتوای ضعیف می‌توانند کشف و استفاده را خراب کنند. برای صفحه فارسی:
- Title، H1، Meta و متن واقعاً فارسی و منطبق با Intent باشند؛
- URL پایدار، Canonical و Internal link روشن باشد؛
- متن مهم در Rendered HTML و Linkها Crawlable باشند؛
lang="fa"برای دسترس‌پذیری درست باشد؛ گوگل زبان را از محتوای قابل مشاهده تشخیص می‌دهد؛- Schema با محتوای نمایش‌داده‌شده و داده واقعی هم‌خوان باشد؛
- تصویر دارای Alt متناسب با نقش باشد، نه Keyword stuffing.
برای فارسی و انگلیسی URL جدا بسازید
Google برای نسخه‌های زبانی URL مستقل را توصیه می‌کند و در صورت وجود نسخه‌های معادل، hreflang می‌تواند رابطه را اعلام کند. محتوا را فقط با Cookie، Browser language یا IP روی یک URL تغییر ندهید؛ Crawler ممکن است همه نسخه‌ها را نبیند. Selector زبان قابل دسترس و لینک واقعی داشته باشد.
هر نسخه باید Self-canonical و Hreflang reciprocal/valid داشته باشد. Canonical را به نسخه زبان دیگر نفرستید مگر واقعاً Duplicate نامناسبی باشد؛ هدف Hreflang جایگزینی Canonical نیست. Release فنی Metadata، Render، Canonical و Hreflang را با چک‌لیست سئو طراحی سایت کنترل کنید.
Design system دو جهته
RTL را در سطح Foundation و Component حل کنید:
| لایه | Artifact | Acceptance |
|---|---|---|
| Foundation | Type، spacing، color، motion و icon policy | Tokenها LTR/RTL-aware |
| Content | Glossary، number/date/unit/error policy | نمونه و Owner دارد |
| Component | States و Bidi behavior | Story/fixture برای fa/en/mixed |
| Pattern | Form، table، navigation و checkout | Keyboard/Zoom/Screen reader پاس |
| Template | Home، Article، Category، Product | Content stress و Performance budget |
| Release | Regression suite و visual diff | Failure owner و Rollback |
ساخت سایت با Builder نیز این Requirementها را حذف نمی‌کند. اگر پلتفرم انتخاب می‌کنید، RTL/Bidi/Font/Export را در Pilot واقعی مطابق راهنمای سنجش SEO Fit سایت‌ساز آزمایش کنید.
ماتریس QA سایت فارسی
| محور | نمونه‌ها |
|---|---|
| Content | کوتاه/بلند، نیم‌فاصله، عدد، Mixed، Empty/Error |
| Viewport/Zoom | 320px، موبایل/تبلت/دسکتاپ، ۲۰۰%/۴۰۰% |
| Input | Touch، Keyboard، Screen reader، Voice input |
| Browser/OS | موتورهای اصلی و نسخه‌های تحت پشتیبانی |
| Network | Cache سرد، کند/ناپایدار، داخل/خارج و Third party timeout |
| Locale | fa، en، mixed و User-generated content |
| State | Loading، Success، Error، Retry، Offline و Permission |
| Data | رقم سه‌گانه، تاریخ، پول، تلفن، آدرس، URL و Export |
همه ترکیب‌ها را Exhaustive تست نکنید. بر اساس ریسک، Journey حیاتی و تغییر اخیر انتخاب کنید. نمونه ثابت Persian torture test را در CI/Visual regression نگه دارید و برای Form/Payment/Search آزمون دستی دوره‌ای داشته باشید.
چک‌لیست پذیرش طراحی سایت فارسی
- صفحه
lang="fa" dir="rtl"و UTF‑۸ درست دارد. - ترتیب DOM، خواندن و Focus با ظاهر RTL سازگار است.
- Componentها از Logical properties و Icon policy استفاده می‌کنند.
- مقدار Dynamic با
bdi/dir="auto"در صورت نیاز Isolate می‌شود. - Font با مجوز، Glyph، Weight، Fallback و Performance آزموده شده است.
- Text spacing، Zoom/Reflow، Contrast، Keyboard و Screen reader پاس شده‌اند.
- عدد، تاریخ، پول و شناسه Display/Storage policy جدا دارند.
- Form ورودی رایج ایران را تحمل، Label/Autocomplete مناسب و خطای قابل اصلاح دارد.
- Search normalization و Zero-result measurement تعریف شده است.
- Responsive روی متن بلند، Keyboard باز، Modal و Table تست شده است.
- نسخه‌های زبانی URL مستقل، Selector و Hreflang معتبر دارند.
- Performance با Font/Widget/Network/Device واقعی سنجیده می‌شود.
برنامه ۳۰روزه بهبود تجربه فارسی
| بازه | کار | خروجی |
|---|---|---|
| روز ۱ تا ۵ | Inventory Template/Component و نمونه خطا | Risk map RTL/Bidi/Data/A11y |
| روز ۶ تا ۱۰ | Policy زبان، جهت، Font، عدد/تاریخ/پول | Locale contract و Token |
| روز ۱۱ تا ۱۵ | ساخت Content stress dataset و Storyها | Fixture fa/en/mixed و States |
| روز ۱۶ تا ۲۰ | اصلاح Foundation/Form/Search پرتکرار | Componentهای پذیرفته‌شده |
| روز ۲۱ تا ۲۵ | Keyboard/Zoom/Screen reader/Device/Network tests | Evidence و Defect priority |
| روز ۲۶ تا ۳۰ | Release محدود، RUM/analytics و Retrospective | Keep/Change/Rollback و Backlog |
پرسش‌های متداول طراحی سایت فارسی
بهترین فونت فارسی برای سایت کدام است؟
پاسخ عمومی ندارد. خوانایی Body و عدد، Glyph coverage، وزن واقعی، مجوز Web، حجم، Fallback و هماهنگی با برند را روی محتوای واقعی و موبایل امتیاز دهید. نام محبوب فونت به‌تنهایی Evidence نیست.
آیا فقط با direction: rtl سایت فارسی می‌شود؟
خیر. جهت پایه را با dir="rtl" در Markup تعریف کنید و زبان، Bidi، DOM order، Logical CSS، Font، فرم، داده، دسترس‌پذیری و QA را نیز حل کنید. CSS direction جای Semantic markup را نمی‌گیرد.
اعداد سایت فارسی بهتر است فارسی باشند یا لاتین؟
به Context بستگی دارد. متن خواندنی می‌تواند فارسی باشد، اما URL، کد، نسخه و شناسه باید Exact بمانند. ورودی‌های رایج را تحمل و برای Storage یک Format canonical تعریف کنید؛ تبدیل کور ممکن است داده را خراب کند.
چگونه متن فارسی و انگلیسی را بدون به‌هم‌ریختگی نمایش دهیم؟
ترتیب منطقی متن را حفظ کنید؛ جهت سند و قطعه را با dir مشخص و مقدار Dynamic/ناشناخته را با bdi یا dir="auto" Isolate کنید. URL، پرانتز، درصد، کد و Copy/Paste را جدا تست کنید.
RTL چه اثری بر سئو دارد؟
RTL تضمین یا فاکتور مستقیم رتبه نیست. اما Markup درست، محتوای قابل Render، IA، URL مستقل زبان، Canonical/Hreflang و UX قابل استفاده به کشف و فهم کمک می‌کنند. گوگل زبان را عمدتاً از محتوای قابل مشاهده تشخیص می‌دهد.
منابع رسمی برای پیاده‌سازی و QA
- W3C: راهنمای HTML برای Scriptهای راست‌به‌چپ و Bidi
- MDN: ترجیح dir در HTML بر CSS direction
- استاندارد WCAG ۲.۲ برای Reflow، Text spacing، Input و Target
- W3C WAI: فرم، Label، Validation و Notification دسترس‌پذیر
- web.dev: Font loading، Subset و کنترل Layout shift
- Google Search: سایت چندزبانه، URL مستقل و Hreflang
تجربه فارسی خوب از یک فونت زیبا یا Flipکردن Layout ساخته نمی‌شود. وقتی Language، Direction، Data، Component و Quality قرارداد مشترک دارند، تیم می‌تواند خطا را پیش از کاربر پیدا کند، تغییر را در سطح سیستم اعمال کند و نتیجه را روی Journey واقعی بسنجد.
