سند جامع اجرایی و نقشه راه مهندسی زیرساخت چندزبانه متارنگ (MetaRang Enterprise i18n V3)

با گسترش متارنگ به بیش از ۶۰ صفحه، صدها پنجره و تب، کاتالوگ‌های بزرگ املاک و اسناد VOD، مدیریت ترجمه‌ها به یک معماری منسجم و بهینه نیاز دارد. نبود این ساختار می‌تواند باعث افزایش درخواست‌های متنی به پایگاه داده و کاهش عملکرد فرانت‌اند و شاخص‌های حیاتی وب (Core Web Vitals) شود.

معماری i18n Enterprise V3 با هدف مدیریت یکپارچه زبان‌ها، افزایش سرعت دسترسی به ترجمه‌ها، کاهش فشار بر پایگاه داده، حفظ ترجیحات زبانی شهروندان و بهبود سئوی بین‌المللی طراحی شده است.

مهم‌ترین اهداف این معماری عبارت‌اند از:

• انتقال دیکشنری‌های ثابت رابط کاربری به حافظه کش Redis و توزیع داده‌ها در لایه Edge، با هدف حذف درخواست‌های مستقیم پایگاه داده برای این محتواها.
• استفاده از مدل ترکیبی در دیتابیس V3 برای ذخیره اطلاعات کوتاه چندزبانه و محتوای متنی طولانی.
• ثبت زبان انتخابی شهروند در بک‌اند Go برای حفظ تنظیمات در دستگاه‌ها و کلاینت‌های مختلف.
• مدیریت صفحات چندزبانه با استفاده از تگ‌های hreflang ، سایت‌مپ‌های تفکیک‌شده و سیاست بازگشت به زبان فارسی در صورت نبود ترجمه.

۲. طبقه‌بندی محتوا و معماری کش Redis

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

محتوای ثابت رابط کاربری شامل منوها، دکمه‌ها، پیام‌ها و پنجره‌های سامانه است. این داده‌ها از طریق دیکشنری‌های زبانی در Redis نگهداری می‌شوند تا برای نمایش آن‌ها نیازی به مراجعه مستقیم به پایگاه داده اصلی نباشد.

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

۲.۱. ساختار دیکشنری‌های زبانی

تمام رشته‌های رابط کاربری بر اساس شناسه‌های عددی یکتا، از 1 تا 1821 ، سازمان‌دهی می‌شوند. این شناسه‌ها در فایل‌های زبان مختلف یکسان باقی می‌مانند تا ارتباط میان ترجمه‌ها حفظ شود.

برای نمونه، شناسه‌های مهم عبارت‌اند از:

• شناسه ۱: ورود به متاورس
• شناسه ۴۵: قیمت‌گذاری PSC
• شناسه ۷۸: شناسه شهروندی
• شناسه ۴۸۲: معرفی تمدن متارنگ
• شناسه ۱۷۴۴: اسناد مالکیت VOD

در فاز نخست، چهار زبان فارسی، انگلیسی، عربی و روسی از طریق فایل‌های fa.json، en.json، ar.json و ru.json پشتیبانی می‌شوند. این فایل‌ها با پیشوند i18n:dict:{lang} در Redis بارگذاری خواهند شد و ساختار کلیدهای آن‌ها باید در تمام زبان‌ها یکسان باشد.

۲.۲. به‌روزرسانی زنده ترجمه‌ها

برای تغییر ترجمه‌ها، نیازی به ساخت مجدد پروژه یا راه‌اندازی دوباره سرور نیست. هنگامی که مترجم متنی را در پنل مدیریت ویرایش می‌کند، مقدار جدید مستقیماً در Redis ثبت می‌شود.

سپس بک‌اند Go از طریق یک وب‌هوک امضاشده با الگوریتم HMAC-SHA256، رویداد به‌روزرسانی را به فرانت‌اند ارسال می‌کند تا کش مربوط به زبان موردنظر با استفاده از سازوکار revalidateTag به‌روزرسانی شود.

طبق مشخصات سند، هدف این فرایند آن است که تغییرات ترجمه در کمتر از ۱۰۰ میلی‌ثانیه در اختیار کلاینت‌ها قرار بگیرند؛ بدون آنکه فرایند Build یا استقرار مجدد انجام شود.

۳. مهندسی اسکیما در پایگاه داده V3

محتوای چندزبانه متارنگ از نظر حجم و نوع دسترسی یکسان نیست. اطلاعات کوتاه املاک به دسترسی سریع نیاز دارند، درحالی‌که مقالات، اخبار و اسناد رسمی ممکن است شامل متن‌های طولانی باشند. به همین دلیل، معماری V3 دو الگوی مکمل برای ذخیره‌سازی اطلاعات در نظر می‌گیرد.

۳.۱. فیلدهای چندزبانه تعبیه‌شده (Embedded Map)

این الگو برای داده‌های سبک مانند نام ملک، دسته‌بندی، منطقه جغرافیایی و مشخصات اسناد مالکیت مجازی VOD استفاده می‌شود. ترجمه‌های هر فیلد در همان سند اصلی قرار می‌گیرند تا اطلاعات موردنیاز با یک درخواست قابل دریافت باشند.

برای مثال، سند یک ملک تجاری می‌تواند شامل شناسه VOD، نوع ملک، عنوان فارسی، انگلیسی، عربی و روسی، نام منطقه، مساحت و اطلاعات قیمت‌گذاری بر اساس PSC و ریال باشد.

در این مدل، اطلاعاتی مانند عنوان «فروشگاه مرکزی برج آریانا» در کنار معادل‌های زبانی آن نگهداری می‌شود. این ساختار برای اطلاعات کوتاه و پرتکرار مناسب است و نیاز به اتصال چند مجموعه داده برای دریافت فراداده‌های ملک را کاهش می‌دهد.

۳.۲. مجموعه‌های مستقل ترجمه برای محتوای طولانی

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

برای نمونه، مجموعه اصلی مقالات می‌تواند شامل شناسه مقاله، کد مقاله، شناسه نویسنده، زبان پیش‌فرض، تعداد بازدید و زمان ایجاد باشد. در مقابل، مجموعه article_translations اطلاعات مربوط به هر ترجمه را ذخیره می‌کند؛ از جمله:

• شناسه ارجاع به مقاله اصلی و کد زبان
• عنوان، نشانی اختصاصی یا slug و چکیده
• متن کامل مقاله
• اطلاعات سئو شامل عنوان متا، توضیحات متا و نشانی استاندارد صفحه

برای بازیابی سریع ترجمه‌ها نیز ایندکس ترکیبی بر اساس شناسه مقاله و زبان در نظر گرفته شده است.

این تفکیک کمک می‌کند اطلاعات مدیریتی و آماری مقاله از متن‌های طولانی ترجمه‌شده مستقل بمانند و توسعه زبان‌های جدید آسان‌تر شود.

۴. مدیریت زبان شهروند و حفظ حریم خصوصی

۴.۱. حفظ ترجیح زبانی در دستگاه‌های مختلف

با انتخاب زبان توسط شهروند، تنظیم مربوطه علاوه بر کوکی کلاینت، از طریق درخواست PATCH /api/v1/citizens/preferences به میکروسرویس Go ارسال می‌شود و در تنظیمات شهروند ثبت خواهد شد.

به این ترتیب، اگر شهروند با دستگاه دیگری مانند موبایل، هدست واقعیت مجازی یا کلاینت دسکتاپ Unity وارد متارنگ شود، آخرین زبان ثبت‌شده او بازیابی می‌شود و رابط کاربری با همان زبان نمایش داده خواهد شد.

۴.۲. پروفایل چندزبانه و تب «درباره من»

در بخش مشخصات شهروندی، امکان ثبت اطلاعاتی مانند بیوگرافی، علایق و خاطرات به زبان‌های مختلف پیش‌بینی شده است. زبان انتخابی هنگام ورود، زبان پیش‌فرض فرم خواهد بود.

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

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

۵. سیاست بازگشت به فارسی و سئوی بین‌المللی

۵.۱. سیاست جایگزینی ترجمه‌های ناقص (Fallback)

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

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

۵.۲. ساختار نشانی صفحات و سایت‌مپ‌های زبانی

برای تفکیک نسخه‌های زبانی، مسیر زبان در ابتدای نشانی صفحات عمومی قرار می‌گیرد. برای مثال، یک ملک با شناسه ۱۰۴۴ می‌تواند نشانی‌های زیر را داشته باشد:

نسخه فارسی: https://metarang.com/fa/properties/1044

نسخه انگلیسی: https://metarang.com/en/properties/1044

نسخه عربی: https://metarang.com/ar/properties/1044

سایت‌مپ اصلی در نشانی https://metarang.com/sitemap.xml به سایت‌مپ‌های اختصاصی زبان‌ها ارجاع می‌دهد. فایل‌های sitemap-fa.xml، sitemap-en.xml، sitemap-ar.xml و sitemap-ru.xml برای سازمان‌دهی صفحات هر زبان در نظر گرفته شده‌اند.

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

۵.۳. استفاده از تگ‌های Hreflang و Canonical

در لایه Server Components فریم‌ورک Next.js، تگ‌های سئو برای معرفی نسخه‌های زبانی مرتبط هر صفحه تولید می‌شوند.

تگ hreflang ارتباط میان نسخه‌های مختلف زبانی یک صفحه را به موتورهای جست‌وجو معرفی می‌کند. تگ canonical نیز برای تعیین نسخه مرجع صفحه به کار می‌رود. در کنار این موارد، تگ x-default برای مشخص‌کردن نسخه پیش‌فرض در نظر گرفته شده است که در معماری پیشنهادی متارنگ به نسخه فارسی ارجاع می‌دهد.

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

۶. پیاده‌سازی فنی در Next.js و Go

۶.۱. بارگذاری دیکشنری‌ها در Next.js

در معماری فرانت‌اند، دیکشنری‌های زبانی در لایه Server Components و از طریق سازوکار App Router بارگذاری می‌شوند. این رویکرد با هدف کاهش انتقال کد و داده‌های غیرضروری به مرورگر کاربر در نظر گرفته شده است.

تابع getDictionary زبان درخواستی را بررسی می‌کند و دیکشنری متناسب با آن را بارگذاری خواهد کرد. اگر زبان معتبر نباشد، فارسی به‌عنوان زبان پیش‌فرض انتخاب می‌شود.

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

۶.۲. مدیریت ترجیح زبانی در میکروسرویس Go

در لایه بک‌اند، سرویس CitizenPreferenceService مسئول ثبت و بازیابی زبان انتخابی شهروند است.

هنگام تغییر زبان، ابتدا زبان انتخاب‌شده اعتبارسنجی می‌شود. زبان‌های مجاز در فاز نخست شامل فارسی، انگلیسی، عربی و روسی هستند. اگر زبان در فهرست مجاز نباشد، فارسی به‌عنوان مقدار پیش‌فرض انتخاب می‌شود.

سپس ترجیح زبانی شهروند در Redis و با کلیدی مبتنی بر شناسه او ذخیره می‌شود. زمان آخرین به‌روزرسانی نیز در کنار زبان ثبت خواهد شد.

برای بازیابی زبان فعال، سرویس مقدار preferred_lang را از Redis می‌خواند. در صورت نبود مقدار یا بروز خطا، زبان فارسی بازگردانده می‌شود.

این سازوکار با هدف کاهش تأخیر در بازیابی تنظیمات زبانی و حفظ یکپارچگی تجربه شهروند در کلاینت‌های مختلف طراحی شده است.

۷. کنترل کیفیت و معیارهای پذیرش

برای جلوگیری از بروز خطا در نسخه‌های چندزبانه، پنج آزمون اصلی در خط لوله CI/CD پیش‌بینی شده است.

آزمون اول: تطابق کلیدهای ترجمه

تمام کلیدهای فایل‌های انگلیسی، عربی و روسی باید با فایل فارسی مطابقت داشته باشند. در صورت عدم تطابق، فرایند Build متوقف شده و هشدار صادر می‌شود.

آزمون دوم: سرعت بارگذاری دیکشنری

زمان بارگذاری دیکشنری در فرانت‌اند با استفاده از کش Redis باید کمتر از ۱۰ میلی‌ثانیه باشد. عبور از این آستانه به معنای رد آزمون کارایی طبق معیار تعیین‌شده در سند است.

آزمون سوم: اعتبارسنجی سئو و Hreflang

لینک‌های متقابل میان نسخه‌های زبانی باید کامل باشند و لینک شکسته با وضعیت ۴۰۴ وجود نداشته باشد. در صورت عدم انطباق، انتشار صفحه در سایت‌مپ مسدود می‌شود.

آزمون چهارم: جلوگیری از افشای اطلاعات خصوصی

هیچ داده خصوصی یا اطلاعات رمزنگاری‌شده‌ای نباید در خروجی عمومی صفحات زبانی قرار بگیرد. هرگونه نشت اطلاعات، موجب لغو مجوز استقرار طبق سیاست سند خواهد شد.

آزمون پنجم: پایداری Fallback فارسی

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

۸. نتیجه‌گیری و وضعیت نهایی استقرار

معماری MetaRang Enterprise i18n V3 چارچوبی برای توسعه زیرساخت چندزبانه متارنگ ارائه می‌دهد که در آن دیکشنری‌های رابط کاربری، ترجیحات زبانی شهروندان و محتوای طولانی ترجمه‌شده، متناسب با ماهیت خود مدیریت می‌شوند.

ترکیب کش Redis، مدل ترکیبی ذخیره‌سازی در دیتابیس V3، مدیریت زبان در میکروسرویس Go و قابلیت‌های رندرینگ و سئوی Next.js، با هدف کاهش فشار بر پایگاه داده، افزایش سرعت پاسخ‌گویی، حفظ حریم خصوصی و گسترش دسترسی بین‌المللی طراحی شده است.

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