چگونه از وردپرس چندزبانه استفاده کنیم؟

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

چرا چندزبانه شدن فقط نصب افزونه نیست؟

وقتی می‌گوییم سایت چندزبانه، سه لایه مختلف را باید هماهنگ کنیم:

1. لایه رابط کاربری: ترجمه رشته‌های قالب و افزونه‌ها.
2. لایه محتوا: ترجمه پست‌ها، برگه‌ها، محصولات و فایل‌های رسانه.
3. لایه فنی: ساختار URL، hreflang، sitemap چندزبانه، و تنظیمات سئو.

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

سایت چندزبانه، محصول یک تصمیم معماری است، نه نصب یک افزونه.

سه معماری چندزبانه و مقایسه فنی

پیش از انتخاب افزونه، باید ساختار معماری مشخص شود. سه معماری اصلی وجود دارد:

معماری اول: نصب واحد + افزونه ترجمه

یک نصب وردپرس، یک دیتابیس، چند زبان. ساختار URL معمولاً به این شکل‌هاست:

example.com/          → فارسی (زبان پیش‌فرض)
example.com/en/       → انگلیسی
example.com/ar/       → عربی

مزایا:

• مدیریت متمرکز در یک پیشخوان.
• افزونه‌های سئو و ووکامرس معمولاً یکپارچگی آماده دارند.
• هزینه هاست کمتر.

معایب:

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

معماری دوم: Multisite چندزبانه

هر زبان، یک زیرسایت مستقل روی شبکه Multisite. ساختار URL:

example.com/          → فارسی
example.com/en/       → انگلیسی
example.com/ar/       → عربی

یا با زیردامنه:

fa.example.com
en.example.com
ar.example.com

مزایا:

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

معایب:

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

راهنمای تفصیلی این معماری در وردپرس مولتی‌سایت آمده است.

معماری سوم: نصب‌های کاملاً جدا

هر زبان، یک دامنه مستقل و یک نصب کامل وردپرس:

example.ir   → فارسی
example.com  → انگلیسی
example.ae   → عربی

مزایا:

• جدایی کامل زیرساخت و داده.
• امکان انتخاب هاست و لوکیشن متفاوت برای هر زبان.
• مناسب برای برندهای مستقل در هر بازار.

معایب:

• مدیریت کامل مستقل هر سایت.
• نیاز به اشتراک‌گذاری دستی محتوا یا استفاده از ابزارهای مهاجرت.
• هزینه نگهداری چند برابر.

جدول مقایسه سه معماری

قاعده سرانگشتی من: سایت‌های تا ۵۰۰ صفحه، معماری اول؛ سایت‌های ۵۰۰ تا ۵۰۰۰ صفحه با ترافیک متعادل، معماری دوم؛ پروژه‌های سازمانی با بازارهای مستقل، معماری سوم.

ساختار URL و سئوی بین‌المللی

انتخاب ساختار URL، تصمیمی برگشت‌ناپذیر است. سه الگوی رایج:

1. زیرپوشه: example.com/en/ — ساده‌ترین، یکپارچه‌ترین از نظر سئو.
2. زیردامنه: en.example.com — جدایی بیشتر، ولی نیازمند تنظیم SSL Wildcard.
3. دامنه جداگانه: example.com برای انگلیسی، example.ir برای فارسی — بیشترین جدایی، بهترین برای برندهای مستقل.

از نظر سئو، توصیه رسمی گوگل این است که هر سه الگو قابل‌قبول‌اند اگر به‌درستی پیاده شوند. تفاوت اصلی در سه نقطه:

• انتقال اعتبار (Link Equity): زیرپوشه و زیردامنه، اعتبار را در یک دامنه متمرکز می‌کنند؛ دامنه‌های جدا، اعتبار را تقسیم می‌کنند.
• هدف‌گیری جغرافیایی: با دامنه‌های کشوری (ccTLD — Country Code Top-Level Domain) مثل .ir، .ae، می‌توان هدف‌گیری جغرافیایی قوی‌تری داشت.
• پیچیدگی فنی: زیرپوشه ساده‌ترین، دامنه جدا پیچیده‌ترین.

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

یک نکته مهم: پیش از راه‌اندازی، ساختار URL را روی محیط تست پیاده کنید و در Google Search Console به‌عنوان یک پراپرتی جدید ثبت کنید. تغییر ساختار URL بعد از ایندکس شدن هزاران صفحه، هزینه‌ای جدی دارد. راهنمای ریدایرکت در رفع خطای حلقۀ ریدایرکت و بهترین افزونه‌های ریدایرکت.

مقایسه افزونه‌های ترجمه

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

WPML

قدیمی‌ترین و شناخته‌شده‌ترین افزونه ترجمه وردپرس. مزایا:

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

معایب:

• سنگین در دیتابیس.
• هزینه سالانه متوسط به بالا.
• در بعضی سایت‌ها روی سرعت اثر دارد.

Polylang

رقیب اصلی WPML. مزایا:

• سبک‌تر در دیتابیس.
• نسخه رایگان مناسب سایت‌های کوچک.
• رابط کاربری ساده.

معایب:

• یکپارچگی محدودتر با ووکامرس در نسخه رایگان.
• ابزارهای ترجمه حرفه‌ای کمتر.

TranslatePress

رویکرد متمایز: ترجمه بصری از پیش روی فرانت‌اند. مزایا:

• ترجمه بدون رفتن به پیشخوان.
• مناسب برای سایت‌های متوسط.
• پشتیبانی خوب از سئو.

معایب:

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

Weglot

سرویس ابری: ترجمه به‌صورت خودکار با هوش مصنوعی و ویرایش انسانی. مزایا:

• راه‌اندازی سریع.
• ترجمه خودکار محتوا و رابط.
• مناسب سایت‌های پرمحتوا.

معایب:

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

جدول تصمیم انتخاب افزونه

قاعده سرانگشتی: اگر سایت شما بیش از ۵۰۰ صفحه دارد و از ووکامرس استفاده می‌کند، WPML انتخاب اول؛ اگر سایت کوچک است و به سرعت اهمیت می‌دهید، Polylang یا TranslatePress.

در انتخاب افزونه ترجمه، مسئله امکانات نیست؛ مسئله ظرفیت شما برای مدیریت آن امکانات در سه سال آینده است.

مدیریت محتوا در سایت چندزبانه

ساختار سایت آماده شد، اما مدیریت محتوا بخش اصلی کار است. سه مدل مدیریت محتوا در سایت چندزبانه:

مدل اول: ترجمه کامل همزمان

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

مدل دوم: ترجمه انتخابی

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

مدل سوم: محتوای مستقل

هر زبان، محتوای مستقل و متفاوت دارد. مناسب سایت‌هایی که هر بازار، محصول و محتوای اختصاصی دارد.

در همه سه مدل، یک قاعده مشترک است: هرگز از ترجمه ماشینی بدون ویرایش انسانی استفاده نکنید. ترجمه خام AI، در بعضی محتواها (سئو، فروشگاهی) به‌سرعت قابل‌تشخیص است و به اعتبار برند آسیب می‌زند. ترکیب درست: ترجمه اولیه با AI، ویرایش نهایی با انسان. مسیر تفصیلی در استفاده از ابزارهای هوش مصنوعی برای ترجمه.

ساختار دیتابیس در ترجمه محتوا

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

رویکرد اول: هر ترجمه، یک پست مستقل

در WPML و Polylang، هر ترجمه یک پست مستقل با ID جداگانه است. ارتباط بین ترجمه‌ها از طریق جدول‌های اضافی نگه داشته می‌شود:

wp_posts:
  ID 100 → پست فارسی اصلی
  ID 101 → پست انگلیسی (ترجمه)
  ID 102 → پست عربی (ترجمه)

wp_icl_translations (WPML):
  element_id 100 → trid 5، lang fa
  element_id 101 → trid 5، lang en
  element_id 102 → trid 5، lang ar

مزیت: هر ترجمه، متادیتای مستقل، تاریخ انتشار مستقل و تنظیمات سئو مستقل دارد.

عیب: با هر ترجمه، حجم دیتابیس به‌طور خطی رشد می‌کند.

رویکرد دوم: ترجمه در متادیتا

بعضی افزونه‌ها، ترجمه را در متادیتا ذخیره می‌کنند:

wp_postmeta:
  post_id 100، meta_key _tr_en_content → محتوای انگلیسی
  post_id 100، meta_key _tr_ar_content → محتوای عربی

مزیت: تعداد پست‌های اصلی کمتر، ساختار ساده‌تر در کوئری‌ها.

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

در تجربه من، رویکرد اول (پست مستقل) برای سایت‌های بزرگ پایدارتر است، ولی نیازمند سرور قوی‌تر و بهینه‌سازی دیتابیس است. راهنمای تفصیلی در بهینه‌سازی جداول MySQL.

hreflang و سیگنال‌های سئو

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

ساختار استاندارد:

<link rel="alternate" hreflang="fa" href="https://example.com/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

سه نکته کلیدی در پیاده‌سازی:

1. هر صفحه، باید همه نسخه‌ها را اعلام کند: همه صفحات یک گروه، باید یک لیست hreflang یکسان داشته باشند که همه زبان‌ها را شامل شود.
2. x-default: نشان می‌دهد کدام نسخه، پیش‌فرض برای کاربران با زبان نامشخص است.
3. هماهنگی با سitemap: hreflang را می‌توان در sitemap هم اعلام کرد.

افزونه‌های ترجمه معمولاً hreflang را خودشان اضافه می‌کنند، ولی در بعضی موارد نیاز به تنظیم دستی است. بررسی خروجی hreflang در مرورگر (View Source) ضروری است. ابزارهای تست hreflang در بهترین ابزارهای تست سرعت سایت و ابزارهای سنجش Core Web Vitals آورده شده است.

چالش‌های قالب و RTL/LTR

در سایت‌های چندزبانه که شامل زبان‌های RTL (Right-to-Left — راست‌به‌چپ) و LTR (Left-to-Right — چپ‌به‌راست) هستند، قالب باید هر دو حالت را پشتیبانی کند. سه رویکرد:

رویکرد اول: قالب‌های RTL-native

قالبی که از ابتدا با پشتیبانی RTL طراحی شده. سایت‌های فارسی معمولاً از این دسته استفاده می‌کنند. اضافه کردن انگلیسی به این قالب، نیازمند فایل LTR مکمل است.

رویکرد دوم: قالب‌های LTR-native

قالبی که برای انگلیسی طراحی شده و RTL را با فایل CSS مکمل یا افزونه پشتیبانی می‌کند. اکثر قالب‌های بین‌المللی این دسته‌اند.

رویکرد سوم: قالب‌های دوحالته

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

در انتخاب قالب، سه چیز را چک کنید:

1. فایل rtl.css اختصاصی دارد؟
2. فونت‌های فارسی و لاتین هر دو پشتیبانی می‌شوند؟
3. جهت آیکون‌ها و فلش‌ها در حالت RTL آینه می‌شود؟

راهنمای تفصیلی در آماده‌سازی قالب برای فارسی و تفاوت قالب فارسی و انگلیسی.

چندزبانگی در ووکامرس

فروشگاه چندزبانه، پیچیده‌ترین سناریو در سایت‌های چندزبانه است. چهار مسئله اصلی:

مسئله اول: ترجمه محصولات

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

مسئله دوم: قیمت‌گذاری به‌ازای هر زبان

در بعضی سناریوها، هر زبان نیاز به قیمت متفاوتی دارد. مثال: قیمت به ریال برای ایران، به درهم برای امارات. WPML و Polylang پشتیبانی از قیمت‌گذاری مستقل دارند، ولی نیازمند تنظیم دقیق است.

مسئله سوم: ارسال و پرداخت

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

مسئله چهارم: سبد خرید چندزبانه

کاربری که با زبان فارسی محصولی به سبد اضافه می‌کند، اگر به انگلیسی سوئیچ کند، سبد نباید گم شود. WPML و Polylang پشتیبانی از حفظ سبد بین زبان‌ها دارند، ولی نیازمند تست دقیق است.

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

اشتباهات رایج در راه‌اندازی چندزبانه

1. انتخاب افزونه پیش از تصمیم معماری: تصمیم معماری (نصب واحد، Multisite، نصب‌های جدا) اول، افزونه دوم.
2. تغییر ساختار URL بعد از ایندکس: تغییر از زیرپوشه به زیردامنه بعد از شش ماه، همه لینک‌های ایندکس‌شده را می‌شکند.
3. نبود hreflang: سایت‌های چندزبانه بدون hreflang، دچار مشکل محتوای تکراری می‌شوند.
4. ترجمه ماشینی بدون ویرایش: ترجمه خام AI، در متن‌های فروشگاهی و سئویی، به‌سرعت قابل‌تشخیص است و به اعتبار برند آسیب می‌زند.
5. نادیده گرفتن RTL در قالب: انتخاب قالب انگلیسی بدون فایل RTL، باعث به‌هم‌ریختگی سایت فارسی می‌شود.
6. راه‌اندازی روی سایت زنده: همه تغییرات ساختاری چندزبانه، ابتدا در محیط تست.
7. فراموش کردن بکاپ قبل از نصب افزونه: نصب افزونه ترجمه روی سایت پرمحتوا، نیازمند بکاپ کامل است. راهنما در بکاپ وردپرس.
8. نادیده گرفتن عملکرد با گذشت زمان: سایت چندزبانه با گذشت زمان، دیتابیس سنگین‌تری می‌سازد. پایش منظم و بهینه‌سازی دوره‌ای، ضروری است.
9. ترجمه محتوای کم‌ارزش: همه محتوا نیاز به ترجمه ندارد. انتخاب استراتژیک محتوای چندزبانه، زمان و هزینه را ذخیره می‌کند.
10. نادیده گرفتن سئوی محلی: سایت چندزبانه در بازارهای مختلف، نیاز به سئوی محلی هر بازار دارد. مسیر در اجرای سئوی محلی برای کسب‌وکار.

جمع‌بندی مسیر

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

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

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