مسئله‌ای که باید حل می‌کردم
برای فارسی، ترجمهٔ رشته فقط بخشی از کار بود. اتصال حروف، ترتیب دیداری و عددهای داخل متن می‌توانستند پیام درست را به شکل ناخوانا نشان بدهند.
پیاده‌سازی در نسخهٔ فعلی
PersianGlyphShaper.Fix ابتدا فرم‌های نمایشی را عادی می‌کنه و اتصال حروف را شکل می‌دهد. PreserveNumericRuns با علامت جهت، ترتیب عددها را نگه می‌دارد؛ حالت پردازش از PersianTextProcessingMode می‌آید.
تصمیم و هزینهٔ طراحی
مسیر ShapeLettersAndReverse یک fallback هست و قطعه‌های لاتین یا عددی را دوباره به ترتیب خودشان برمی‌گرداند. متن ترجمه‌شده را با متن شکل‌داده‌شدهٔ رندر یکی نگرفتم.
مرزهای فعلی
این ابزار یک موتور کامل Unicode BiDi نیست. متن آمیخته، نشانه‌گذاری، font و تنظیم RTL در TextMeshPro باید با هم بررسی بشن؛ اسم تابع تضمین همهٔ حالت‌های زبان نیست.
از کلید JSON تا فونت و اتصال حروف
در پست دو‌زبانه‌سازی، سیستم با فایل‌های JSON و کلید یکتا برای متن معرفی شده؛ کد LocalizationService این مسیر را با Resources/Localization/en و fa نشان می‌دهد. فایل‌ها فهرستی از key و value دارن و GetText نخست جدول JSON زبان خواسته‌شده را جست‌وجو می‌کنه، سپس سراغ LocalizedTextTable یا fallback می‌رود. این مرز برای نگهداری مهم هست: متن ترجمه‌شده نباید به جای کلید پایدار استفاده بشه. TryGetTextBySourceText نیز نگاشت را عمداً از متن منبع انگلیسی انجام می‌دهد؛ جست‌وجو از روی فارسی نمایش‌داده‌شده می‌تواند پس از باز شدن دوبارهٔ صفحه زبان‌ها را مخلوط کنه.
انتخاب متن تنها نیمی از مسئله هست. LocalizationTextStyleSet برای هر زبان می‌تواند TMP_FontAsset، alignment، isRightToLeftText و override فاصلهٔ حرف یا کلمه داشته باشد. ApplyTo این ویژگی‌ها را روی TMP_Text می‌گذارد و برای سبک گمشده امکان fallback داره. داشتن فونت فارسی ضروری هست، اما صرف اختصاص فونت تضمین نمی‌کنه شکل‌های ارائه‌شدهٔ حروف و تمام نشانه‌های مورد استفاده در atlas آن حاضرند. خوانایی باید با ترکیب دارایی فونت، حالت پردازش و تنظیم راست‌به‌چپ بررسی بشه؛ یک رشتهٔ درست در JSON ممکنه با اتصال یا فاصلهٔ نادرست در رابط دیده بشه.
PersianGlyphShaper بر اساس همسایه‌های حرف، فرم مستقل، آغازین، میانی یا پایانی را انتخاب می‌کنه و نیم‌فاصله و نشانه‌ها را مرز اتصال می‌داند. برای عددی مثل 200 یا نسبت 3/10، PreserveNumericRuns علامت جهت نامرئی اضافه می‌کنه تا ترتیب داخلی عدد حفظ بشه. ShapeLettersAndReverse نیز راه‌حل سبک برای بعضی چیدمان‌هاست، نه موتور کامل bidi. LocalizationBootstrapper متن‌های دارای binder یا NonLocalizedText را می‌تواند از پردازش خودکار کنار بگذارد تا فارسی از قبل شکل‌گرفته دوباره پردازش نشود. این احتیاط مخصوص تغییر زبان و بازگشایی صفحه هست؛ پوشش همهٔ جمله‌های مخلوط باید با نمونه‌های واقعی جدا ارزیابی بشه.
چیزی که از این مرحله یاد گرفتم
برای من، خوانایی فارسی بخشی از تجربهٔ بازی هست. بازیکن باید امتیاز و پیام انتخاب را همان بار اول بفهمد، بدون اینکه مجبور بشه عدد معکوس یا حروف جدا را تفسیر کنه.
مثال عملی فارسی‌سازی یونیتی
یک روش کاربردی برای بررسی فارسی‌سازی یونیتی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. متنی با عدد، نام انگلیسی و عبارت فارسی را روی دکمهٔ باریک و صفحهٔ کوچک نمایش بده. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
ترجمهٔ درست با ترتیب حروف نادرست یا بریدگی متن همچنان تجربهٔ نامفهوم می‌سازد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. انتخاب فونت و چیدمان راست‌به‌چپ بخشی از طراحی رابط هستند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
جهت متن، اتصال حروف، اعداد و فونت جایگزین را روی دستگاه واقعی ببین. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | متنی با عدد، نام انگلیسی و عبارت فارسی را روی دکمهٔ باریک و صفحهٔ کوچک نمایش بده. |
| ریسک اصلی | ترجمهٔ درست با ترتیب حروف نادرست یا بریدگی متن همچنان تجربهٔ نامفهوم می‌سازد. |
| روش بررسی | جهت متن، اتصال حروف، اعداد و فونت جایگزین را روی دستگاه واقعی ببین. |
| مرز نتیجه‌گیری | انتخاب فونت و چیدمان راست‌به‌چپ بخشی از طراحی رابط هستند. |
پرسش‌های کاربردی دربارهٔ فارسی‌سازی یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: متنی با عدد، نام انگلیسی و عبارت فارسی را روی دکمهٔ باریک و صفحهٔ کوچک نمایش بده. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. جهت متن، اتصال حروف، اعداد و فونت جایگزین را روی دستگاه واقعی ببین. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. انتخاب فونت و چیدمان راست‌به‌چپ بخشی از طراحی رابط هستند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
