چکلیست سئوی فنی سایتهای RTL عربی و فارسی
موارد سئوی فنی که در سایتهای RTL زیاد از قلم میافتند: dir و lang، CSS منطقی، طول اسلاگ با کدگذاری درصدی، ZWNJ و قالب اعداد.
نوشته Roozbeh Nazari · CEO
نسخههای عربی و فارسی در بیشتر پروژهها لایهای هستند که آخر از همه اضافه و کمتر از همه بازبینی میشوند. از نظر بصری به نظر میرسد کار میکنند، چون مرورگر چیدن متن از راست به چپ را خودش بلد است. مشکلات در لایهٔ بصری جمع نمیشوند، در نشانهگذاری و سمت URL جمع میشوند و معمولاً هفتهها پس از انتشار متوجهشان میشوید. این نوشته مواردی فنی را که در نسخههای RTL بیش از همه از قلم میافتند فهرست میکند.
جریان کلی ممیزی را در چکلیست ممیزی سئوی فنی ما شرح داده بودیم؛ این نوشته ضمیمهٔ مخصوص RTL آن است. کل موضوع در سمت سازمانی هم در صفحهٔ خدمت سئوی فنی ما آمده است.
dir و lang: با CSS حل نمیشود
رایجترین خطا دادن اطلاعات جهت فقط در سمت استایل است. راهنمای W3C که به این موضوع اختصاص دارد در این نقطه قاطع است: برای اعمال جهت پایه در صفحههای HTML از CSS استفاده نکنید. دلیلش فنی نیست، معنایی است؛ چون اطلاعات جهت میتواند بر معنای محتوا اثر بگذارد، باید بخشی از نشانهگذاری باشد.
معادل عملیاش دو خط است. اگر جهت کلی سند راست به چپ است، به تگ html صفت dir="rtl" اضافه میشود. همان راهنما نوشتن dir روی عناصر ساختاری سطح پایینتر را فقط وقتی توصیه میکند که لازم باشد جهت پایهٔ آن بلوک عوض شود؛ چون جهت از html به پایین به ارث میرسد، در بیشتر صفحهها نیازی به نشانهگذاری اضافه نمیماند.
در سمت lang اما تمایز از چشم میافتد: برای عربی ar و برای فارسی fa. چون دو زبان از یک الفبا استفاده میکنند، تنظیماتی که با یک مقدار واحد از سرش میگذرند زیاد دیده میشوند. این هم لایهٔ دسترسپذیری و هم هدفگیری زبانی را خراب میکند.
متن با جهت مختلط
وقتی داخل جملهای راستبهچپ یک نام برند، یک واحد اندازهگیری یا یک URL چپبهراست وارد میشود، ترتیب میتواند به شکل غیرمنتظرهای به هم بریزد. در عنوانها و توضیحات متا این به جابهجایی قابل رؤیت کلمات میانجامد. وقتی بخشی با حروف لاتین به انتهای خط میافتد، لغزیدن علامت نگارشی به سمت اشتباه نشانهٔ کلاسیک آن است.
روش بررسی ساده است: سه عنوان که در آنها نام برند انگلیسی، عدد و علامت نگارشی با هم آمدهاند را روی دستگاه واقعی باز کنید و بخوانید. مشکل را در نمایش واقعی میبینید، نه در ابزار توسعهدهندهٔ مرورگر.
اسلاگ: یک حرف، شش نویسه
سختترین حد در پروژههای RTL اینجاست. حروف عربی و فارسی در URL با کدگذاری درصدی نمایش داده میشوند و هر حرف تا شش نویسه جا میگیرد. طولی که در یک اسلاگ لاتین راحت به نظر میرسد، در معادل عربی همان محتوا حد را تحت فشار میگذارد. اسلاگهایی که در حالت کدگذاریشده از دویست و چهل نویسه میگذرند، در سمت ما هنگام بیلد مشکل ایجاد میکنند.
بهعنوان قاعده، اسلاگ را به طول طبیعی ترجمه واگذار نکنید؛ از عنوان تولید کنید و دستی کوتاهش کنید. بررسی را باید پیش از انتشار خودکار کرد، چون اسلاگی که با چشم کوتاه به نظر میرسد ممکن است پس از کدگذاری بالای حد باشد.
در سمت فارسی یک مورد اضافه هست: نویسهٔ ZWNJ میتواند به اسلاگ نشت کند. چون نامرئی است متوجهش نمیشوید، پس از کدگذاری جا میگیرد و دو URL متفاوت تولید میکند. جایگزین کردن ZWNJ با خط تیره یا فاصله در تولید اسلاگ، ارزانتر از نوشتن ریدایرکت در آینده است.
سازگاری نقطهکدها
حروف ی و ک فارسی نقطهکدهایی متفاوت از معادلهای عربیشان هستند و با چشم تشخیص داده نمیشوند. اگر محتوا از منابع مختلف میآید، دو نقطهکد متفاوت میتوانند در یک صفحه کنار هم قرار بگیرند. نتیجه: همان کلمه در جستوجوی داخلی مطابقت پیدا نمیکند، اسلاگها بیسروصدا متفاوت میشوند، مقایسهها جور درنمیآیند.
جای درست، اعمال یک نرمالسازی یکطرفه هنگام درونریزی و انجام آن در لحظهٔ ذخیره است. اصلاح در لحظهٔ انتشار دیر است.
ویژگیهای منطقی CSS
راهنمای W3C توصیه میکند برای حاشیه و تراز به جای چپ و راست از معادلهای منطقی استفاده شود؛ به این ترتیب استایلها هنگام بومیسازی خودبهخود سازگار میشوند. در عمل این تضمین میکند که پدینگ ثابت چپ و آیکونهای چپچین در نسخهٔ RTL در سمت اشتباه نمانند. این شبیه یک مورد سئو به نظر نمیرسد، اما وقتی چیدمان به هم میریزد کاربر صفحه را ترک میکند و این معادلی قابل اندازهگیری دارد.
اعداد و تاریخها
در محتوای عربی و فارسی اعداد میتوانند با ارقام عربی شرقی یا فارسی نوشته شوند. این مسئلهٔ ترجیح است، اما قاطی شدن دو قالب در یک صفحه و استفاده از ارقام محلی در دادهٔ ساختاریافته مشکلی جداگانه است. فیلدهای عددی در دادهٔ ساختاریافته چون توسط ماشین خوانده میشوند باید در قالب استاندارد بمانند؛ استفاده از قالب محلی در متن قابل رؤیت آزاد است.
در سمت فارسی تقویم هم عنوان جداگانهای است: اگر در متن از تاریخ هجری شمسی استفاده میشود، فیلدهای تاریخ باید در سمت ماشین جداگانه و سازگار بمانند.
فونت، شکلدهی و بریدن
در نسخههای RTL لایهٔ بصری هم خطاهای خاموش تولید میکند. چون الفبای عربی پیوسته نوشته میشود، حروف بسته به جایشان شکل عوض میکنند؛ فونتی که شکلدهی را کامل پشتیبانی نمیکند متن را خوانا اما غلط نشان میدهد. در فارسی علاوه بر آن فونتی لازم است که شکلهای درست حروف ی و ک را داشته باشد؛ فونتی که برای عربی انتخاب شده همیشه در فارسی نتیجهٔ درست نمیدهد.
موضوع دوم بریدن است. عملیات برش بر پایهٔ حد نویسه در فیلدهای عنوان و توضیحات میتواند در خط پیوسته کلمه را از وسط ببرد و رشتهای ناخوانا بیرون بدهد. بریدن در مرز کلمه به جای نویسه، در سمت RTL حیاتیتر از سمت لاتین است.
سوم ارتفاع خط. در عربی و فارسی کشیدگیهای بالا و پایین حروف بیشتر از حروف لاتین جا میگیرند؛ ارتفاع خط تنگی که برای لاتین تنظیم شده در این زبانها حروف را روی هم میاندازد. این شبیه مشکلی زیباییشناختی به نظر میرسد، اما متنی که خوانده نمیشود خوانده نمیشود.
راه بازبینی این سه مورد یکی است: باز کردن صفحه روی دستگاه واقعی با محتوای واقعی. بررسیهایی که با متن جاینگهدار انجام میشوند هیچکدام از این خطاها را نشان نمیدهند.
hreflang و دوسویگی
هنگام پیوند دادن نسخههای زبانی به هم، قاعدهٔ پایه در مستندات نسخههای بومیشدهٔ گوگل تغییر نمیکند: هر نسخه باید به همهٔ نسخهها از جمله خودش اشاره کند و پیوندها باید دوسویه باشند. ریسک اضافه در سمت RTL نوشتن URLهای کدگذاریشده بهصورت نیمهکدگذاریشده در تگهاست؛ همان نشانی که در جایی کدگذاری شده و جای دیگری نشده، دوسویگی را بیسروصدا میشکند.
برای شکل مفصل این عنوان میتوانید به نوشتهٔ خطاهای hreflang و تشخیص آنها نگاه کنید.
فهرست کوتاه پیش از انتشار
- آیا dir در تگ html درست است و مقدار lang به ar و fa تفکیک شده؟
- آیا عنوانهای دارای بخش لاتین روی دستگاه واقعی درست خوانده میشوند؟
- آیا طول کدگذاریشدهٔ اسلاگ زیر حد است؟
- آیا ZWNJ در اسلاگ مانده است؟
- آیا نقطهکدهای عربی و فارسی در محتوا قاطی شدهاند؟
- آیا اعداد در دادهٔ ساختاریافته در قالب استاندارد هستند؟
- آیا پیوندهای hreflang دوسویه و با یک کدگذاری هستند؟
افزودن این هفت مورد به چکلیست انتشار، بخش بزرگ کارهایی را که بعداً در نسخههای RTL بیرون میآیند از ابتدا میگیرد. بیشتر موارد قابل خودکارسازیاند؛ اما گام خواندن روی دستگاه واقعی خودکار نمیشود و باید پیش از هر انتشار دستی انجام شود.