Digisky

مهندسی زبان فارسی

جست‌وجو، پردازش متن و رابط کاربری که در فارسی کار می‌کنند، چون برای این خط طراحی شده‌اند، نه به آن ترجمه شده‌اند.

همه‌چیز بی‌صدا شکست می‌خورد

پشتهٔ جست‌وجویی که سندی را پیدا نمی‌کند خطایی پرتاب نمی‌کند. فهرست خالی برمی‌گرداند، و فهرست خالی دقیقاً شبیه پاسخ درست به پرسشی است که مصداقی ندارد. فارسی این فهرست خالی را خیلی بیشتر از آنچه انتظار می‌رود تولید می‌کند، به دلایلی که مکانیکی‌اند، نه زبانی.

دو حرف همزاد عربی دارند. ی و ک همتای عربیِ تقریباً هم‌شکل دارند — ي و ك — و هر دو املا در پیکره‌های واقعی، اغلب داخل یک سند، پیدا می‌شوند. برای پایگاه‌داده این‌ها دو نویسهٔ متفاوت‌اند. برای وکیل، یک کلمه‌اند.

سه دستگاه رقم کنار هم زندگی می‌کنند. ارقام فارسی، ارقام عربی-هندی و ارقام لاتین همگی در متن واقعی فارسی می‌آیند؛ مرتب در یک پاراگراف و مرتب داخل یک استناد.

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

و PostgreSQL هیچ ریشه‌یاب فارسی ندارد. نه در توزیع استاندارد، نه در افزونه‌های پرکاربرد جست‌وجو. این خلأیی نیست که با پیکربندی دورش زد؛ باید در لایهٔ جذب پر شود.

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

«چرا جست‌وجوی کلمه‌ای که جلوی چشممان در صفحه است هیچ نتیجه‌ای نمی‌دهد؟»

رویکرد ما

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

در ستون نرمال کن، نه در حافظه. متن نرمال‌شده کنار متن اصلی مادی و نمایه می‌شود. متن اصلی دست‌نخورده می‌ماند — همان است که کاربر می‌خواند و نقل می‌کند؛ نسخهٔ نرمال‌شده همان است که نمایه می‌بیند.

با پرس‌وجوی واقعی تنظیم کن. بازوی واژگانی‌ای که هر عبارت را الزامی می‌کند، برای یک جملهٔ واقعی هیچ برنمی‌گرداند. ما روی متنی آزمایش می‌کنیم که آدم‌ها واقعاً تایپ می‌کنند، نه روی نمونه‌های آزمون.

راست‌به‌چپ به‌عنوان پیش‌فرض سند. جهت روی خودِ سند تنظیم می‌شود تا اولین رندر هم درست باشد، چیدمان از ویژگی‌های منطقی استفاده می‌کند نه چپ و راست، و عدد و شماره و شناسه در جزیره‌های صریح چپ‌به‌راست می‌نشینند. سوار کردن جهت روی چیدمان چپ‌به‌راست، دنباله‌ای بلند از عیب‌ها می‌سازد که هرکدام جزئی به‌نظر می‌رسند و روی‌هم محصول را بیگانه می‌کنند.

تاریخ شمسی نمایش، ذخیرهٔ بدون ابهام. کاربر همان تقویمی را می‌خواند که با آن زندگی می‌کند. قالب روی سیم کسل‌کننده می‌ماند.

چه چیزی تحویل می‌گیرید

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

کجا انتخاب اشتباهی است

  • اگر متن شما از قبل تمیز، تک‌خط و یکدست وارد شده است، بیشتر این کارها لازم نیست. اول پراکندگی املایی پیکرهٔ خودتان را اندازه بگیرید.
  • اگر مسئله واژگان تخصصی است نه خط، نرمال‌سازی کمکی نمی‌کند. آنجا به واژه‌نامه، مجموعهٔ پرس‌وجوی مرجع و کسی که دامنه را می‌شناسد نیاز دارید.
  • اگر فقط ترجمهٔ رابط را می‌خواهید، یک کتابخانهٔ بومی‌سازی و یک مترجم خوب سریع‌تر از یک قرارداد مهندسی کار را تمام می‌کنند.
  • اگر منتظرید ریشه‌یاب فارسی در پایگاه‌داده‌تان ظاهر شود، نمی‌شود. صرف و اشتقاق پیش از رسیدن متن به نمایه اداره می‌شود و هر فروشنده‌ای که خلافش را القا کند، نگاه نکرده است.
  • جست‌وجوی واژگانیِ تنها در فارسی سقف پایینی دارد. اگر نمی‌توانید بازوی بازیابی معنایی را کنارش اجرا کنید، آن سقف را بپذیرید و برایش برنامه بریزید، به‌جای اینکه تا ابد تنظیمش کنید.