فهرست یادداشت‌ها را ساخته‌ایم، اما اولین متن واقعی چنین است: «نسخه v2.4 را برای support@example.test بفرست؛ مهلت ۱۴۰۵/۰۸/۰۶». حالا عنوان راست‌چین است، ولی نشانی ایمیل، عدد نسخه و علامت‌ها ممکن است در جای ناخوانا دیده شوند. رابط فارسی با جابه‌جاکردن لبه چپ و راست کامل نمی‌شود.
در بخش قبل، نمایش، منطق و داده اپ یادداشت را جدا کردیم. این بخش سراغ لایه نمایش می‌رود: جهت متن، قلم، عدد، تاریخ و ویرایش دوزبانه. مثال تاریخ با JavaScript است و در محیط Node اجرا می‌شود؛ رفتار نهایی کیبورد و انتخاب متن باید روی دستگاه و موتور اجرای اپ هم بررسی شود.
جهت چیدمان با جهت متن فرق دارد
در رابط راست‌به‌چپ، جای بعضی اجزا و مسیر خواندن تغییر می‌کند. اما محتوای هر قطعه ممکن است جهت دیگری داشته باشد. یک یادداشت فارسی می‌تواند حاوی ایمیل یا مسیر فایل باشد و یک یادداشت انگلیسی می‌تواند چند واژه فارسی داشته باشد. نباید صرفاً به‌دلیل زبان رابط، جهت همه ورودی‌ها را یکسان تحمیل کنیم.
در ابزار رابط، مفهوم شروع و پایان را تا جای ممکن به‌جای چپ و راست ثابت به کار ببرید. بااین‌حال همه نمادها نیاز به آینه‌شدن ندارند: پیکان حرکت در مسیر ممکن است تغییر کند، ولی لوگو، علامت پخش یا یک تصویر واقعی را نباید کورکورانه برگرداند. هر مورد را با معنای عمل بسنجید.
قطعه‌های دوزبانه را در مرز درست جدا کنیم
در جمله نمونه، ایمیل یک واحد مستقل است و باید ترتیب داخلی‌اش حفظ شود. الگوریتم دوجهته بسیاری از حالت‌ها را مدیریت می‌کند، اما نشانه‌های خنثی مثل پرانتز و خط تیره می‌توانند در مرز دو جهت ابهام ایجاد کنند. جداکردن قطعه با ابزار مناسب نمایش، از افزودن فاصله‌های تصادفی بهتر است.
در وب، عناصر و ویژگی‌هایی مثل bdi و dir برای این کار وجود دارند؛ در رابط بومی باید قابلیت متن و جهت همان پلتفرم را بررسی کرد. راهنمای W3C درباره متن دوجهته، مفهوم مرزبندی قطعه را توضیح می‌دهد، اما شکل HTML آن را نباید مستقیماً نسخه قابل اجرا برای همه چارچوب‌های موبایل دانست.
محتوای کاربر را فقط برای درست‌شدن یک تصویر، با نویسه‌های کنترلی پنهان پر نکنید. این کار ممکن است کپی‌کردن، جست‌وجو و ویرایش را دشوار کند. متن ذخیره‌شده و تصمیم نمایش باید تا جای ممکن از هم قابل تشخیص باشند.
قلم مناسب را با متن واقعی بسنجیم
یک واژه کوتاه برای ارزیابی قلم کافی نیست. یادداشت چندخطی، نیم‌فاصله، اعداد فارسی، واژه انگلیسی و نشانه‌ها را کنار هم امتحان کنید. ارتفاع سطر نباید باعث بریده‌شدن نقطه‌ها یا بخش پایین حروف شود. وزن‌های مختلف نیز باید در اندازه کوچک خوانا بمانند.
فونت جایگزین را هم بررسی کنید. اگر قلم اصلی دیر بارگذاری شود یا گلیف موردنظر را نداشته باشد، ترکیب قلم‌ها می‌تواند ارتفاع سطر و عرض متن را عوض کند. در موبایل، افزایش اندازه متن از تنظیمات دستگاه اهمیت دارد؛ کارت یادداشت نباید با بزرگ‌شدن فونت، دکمه اصلی را پنهان یا متن را قطع کند.
عدد نمایشی را با داده قراردادی یکی نکنیم
نمایش تعداد یادداشت‌ها با رقم فارسی می‌تواند با زبان رابط هماهنگ باشد. اما شناسه، ایمیل، کد نسخه و مقدار ارسالی به API الزاماً نباید به رشته فارسی تبدیل شوند. داده باید نوع و قرارداد روشن داشته باشد؛ فارسی‌سازی در مرز نمایش انجام می‌شود.
| مقدار | نمایش پیشنهادی | نکته |
|---|---|---|
| تعداد یادداشت | متناسب با زبان رابط | در مدل داده عدد باقی بماند |
| نشانی ایمیل | با ترتیب داخلی چپ‌به‌راست | رشته معتبر را تغییر ندهیم |
| شناسه پیگیری | قابل کپی و بدون ابهام | قرارداد شناسه حفظ شود |
| متن آزاد | مطابق محتوای کاربر | اعداد داخل نوشته را سراسری بازنویسی نکنیم |
برای ورودی عددی نیز مشخص کنید چه نویسه‌هایی پذیرفته می‌شوند و تبدیل در کجا انجام می‌شود. اگر کاربر با کیبورد فارسی عدد وارد کرد، پیام «عدد وارد کنید» بدون راهنمایی مناسب آزاردهنده است. در عین حال، تبدیل ورودی نباید محدودیت نوع، بازه و اعتبارسنجی سرور را حذف کند.
تقویم، منطقه زمانی و زبان سه تصمیم مستقل‌اند
فارسی‌بودن رابط الزاماً همه تصمیم‌های تاریخ را تعیین نمی‌کند. باید معلوم باشد تقویم نمایش چیست، منطقه زمانی کدام است و مقدار اصلی چه معنایی دارد. زمان ایجاد یادداشت یک لحظه مشخص است؛ تاریخ تولد یا روز انجام یک کار ممکن است فقط یک تاریخ تقویمی باشد. تبدیل بی‌دلیل هر تاریخ روزانه به نیمه‌شب UTC می‌تواند روز نمایش را عوض کند.
برای یک لحظه مشخص، نمونه زیر قالب نمایش فارسی و تقویم هجری شمسی را صریح انتخاب می‌کند. در موتورهایی که داده و قابلیت لازم را دارند، Intl این قالب‌بندی را انجام می‌دهد. پشتیبانی را در موتور واقعی اپ بررسی کنید؛ موفقیت نمونه در Node تضمین رفتار همه دستگاه‌ها نیست.
const createdAt = new Date('2026-10-28T08:30:00Z');
const formatter = new Intl.DateTimeFormat('fa-IR-u-ca-persian', {
timeZone: 'Asia/Tehran',
dateStyle: 'medium',
timeStyle: 'short',
});
console.log(formatter.format(createdAt));
این کد رشته تاریخ نمایشی تولید می‌کند، نه قالب ذخیره‌سازی. رشته خروجی محلی را دوباره به‌عنوان قرارداد API استفاده نکنید. برای نمایش «دیروز» یا «چند دقیقه قبل» نیز سیاست تازه‌سازی لازم است؛ برچسبی که فقط هنگام بازشدن صفحه محاسبه شده، ممکن است بعد از مدتی نامعتبر شود.
ویرایشگر را با حرکت نشانگر امتحان کنیم
نمایش درست یک جمله کافی نیست. باید بتوان وسط متن دوزبانه کلیک کرد، بخشی را انتخاب کرد، جایگزین کرد و دوباره ادامه داد. حذف یک قطعه انگلیسی در انتهای جمله فارسی و جابه‌جایی نشانگر کنار پرانتز، نمونه‌های خوبی برای آزمون‌اند.
اگر با هر تغییر ورودی، متن را پاک‌سازی و دوباره جایگزین کنیم، ممکن است نشانگر جابه‌جا شود یا ترکیب ورودی کیبورد به هم بخورد. پاک‌سازی داده باید زمان و محدوده مناسبی داشته باشد. در متن آزاد، حفظ نوشته و موقعیت کاربر از اصلاح نمایشی تهاجمی مهم‌تر است.
جست‌وجو به سیاست نرمال‌سازی نیاز دارد
در فارسی ممکن است شکل‌های مختلف ی و ک یا فاصله و نیم‌فاصله در جست‌وجو مطرح شوند. می‌توان برای کلید جست‌وجو تبدیل کنترل‌شده داشت، اما نباید متن اصلی یادداشت را بدون تصمیم روشن بازنویسی کنیم. کاربر ممکن است به شکل دقیق متن برای کپی یا نقل‌قول نیاز داشته باشد.
محدوده تبدیل را ثبت کنید و نمونه‌های مثبت و منفی داشته باشید. اگر دو عبارت برای جست‌وجو هم‌ارز محسوب می‌شوند، این تصمیم باید قابل توضیح باشد. تبدیل سراسری همه نویسه‌های شبیه به هم ممکن است در متن چندزبانه نتیجه نامطلوب بدهد.
برچسب‌ها و پیام‌ها را با فضای واقعی بنویسیم
عبارت ترجمه‌شده ممکن است از متن انگلیسی بلندتر باشد. دکمه‌ای که با عرض ثابت طراحی شده، با متن فارسی یا فونت بزرگ‌شده می‌شکند. پیام خطا نیز باید روشن بگوید چه چیزی لازم است؛ ترجمه تحت‌اللفظی اصطلاح فنی همیشه بهترین انتخاب نیست.
متن‌ها را از کد منطق جدا نگه دارید تا اصلاح واژه یا زبان، رفتار ذخیره را تغییر ندهد. در اپ یادداشت، نام عملیات و پیام نتیجه باید هماهنگ باشند: اگر ذخیره هنوز تمام نشده، پیام قطعی «ذخیره شد» نشان ندهیم. این همان مرز نمایش و منطق بخش قبل است.
یک فهرست آزمون کوچک برای رابط فارسی
پیش از انتشار، چند یادداشت ثابت بسازید: فارسی کوتاه، متن چندخطی، ترکیب ایمیل و عدد، متن کاملاً انگلیسی و نوشته دارای نیم‌فاصله. همه را در حالت روشن و تیره، اندازه متن بزرگ و صفحه باریک بررسی کنید. برای انتخاب متن و کیبورد، دستگاه واقعی لازم است.
نمونه قالب‌بندی تاریخ این مقاله اجرا شده است، اما آزمون رابط روی گوشی در این مرحله انجام نشده؛ فهرست بالا برنامه بررسی آن است. تمرین بعدی این است که وضعیت بارگذاری، ذخیره و خطا را هم با همین داده‌ها مرور کنید. بخش چهارم درباره انتخاب مدیریت State است: چه چیزی محلی می‌ماند و چه داده‌ای باید میان صفحه‌ها هماهنگ باشد.