توسعه یک وب‌سایت تک‌زبانه چالش‌های خاص خود را دارد، اما لحظه‌ای که کارفرما درخواست می‌کند سایت به سه زبان مختلف در دسترس باشد، پیچیدگی پروژه به‌صورت نمایی افزایش می‌یابد. در اکوسیستم جنگو، ما ابزارهای قدرتمندی مثل gettext برای ترجمه رشته‌های متنی ثابت (Static Strings) داریم، اما وقتی نوبت به محتوای داینامیک دیتابیس می‌رسد، ماجرا متفاوت است. ترجمه محتوا در ادمین جنگو دیگر با فایل‌های .po انجام نمی‌شود و نیازمند استراتژی دقیق در سطح مدل‌ها است.

مدیران محتوا نمی‌توانند برای هر زبان وارد کد شوند. آن‌ها به یک پنل ادمین نیاز دارند که بتوانند عنوان، توضیحات و متن مقاله را به راحتی برای زبان‌های مختلف وارد کنند. انتخاب ابزار اشتباه در اینجا می‌تواند به کابوسی از کوئری‌های کند دیتابیس و رابط کاربری گیج‌کننده منجر شود. در این راهنمای فنی، دو غول ترجمه مدل در جنگو یعنی django-modeltranslation و django-parler را بررسی می‌کنیم و نحوه پیاده‌سازی یک content management workflow حرفه‌ای را شرح می‌دهیم.

چالش ترجمه دیتابیس در مقابل ترجمه کد

جنگو به‌صورت بومی از I18N (Internationalization) پشتیبانی می‌کند، اما این سیستم برای ترجمه رابط کاربری (مانند دکمه “ارسال” یا “خانه”) طراحی شده است. محتوایی که در دیتابیس ذخیره می‌شود، مثل عنوان یک محصول یا متن یک خبر، داستان متفاوتی دارد.

برای چندزبانه کردن دیتابیس، ما معمولاً دو راهکار داریم:

1. روش ستونی (Column-based): برای هر فیلد، ستون‌های جدیدی به جدول اضافه می‌کنیم (مثلاً title_fa, title_en).
2. روش جدولی (Table-based): یک جدول جداگانه برای ترجمه‌ها می‌سازیم که به جدول اصلی لینک شده است.

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

پکیج django-modeltranslation: ساده و سریع

محبوب‌ترین گزینه برای پروژه‌هایی که تعداد زبان‌های ثابتی دارند، django-modeltranslation است. این پکیج از رویکرد “ستونی” استفاده می‌کند. یعنی اگر شما مدلی به نام Product دارید و دو زبان فارسی و انگلیسی را در تنظیمات فعال کرده‌اید، این پکیج به‌صورت خودکار فیلدهای name را به name_fa و name_en در دیتابیس تبدیل می‌کند (یا کنار فیلد اصلی اضافه می‌کند).

نصب و راه‌اندازی اولیه

برای استفاده از این ابزار، ابتدا باید پکیج را نصب کرده و در INSTALLED_APPS قرار دهید. نکته مهم این است که باید قبل از django.contrib.admin قرار گیرد تا بتواند تمپلیت‌های ادمین را بازنویسی کند.

# settings.py
INSTALLED_APPS = [
    'modeltranslation',
    'django.contrib.admin',
    # ... other apps
]

LANGUAGES = (
    ('fa', 'Persian'),
    ('en', 'English'),
)

سپس باید یک فایل translation.py در اپلیکیشن خود بسازید (مشابه admin.py) و فیلدهایی که نیاز به ترجمه دارند را مشخص کنید:

# news/translation.py
from modeltranslation.translator import register, TranslationOptions
from .models import News

@register(News)
class NewsTranslationOptions(TranslationOptions):
    fields = ('title', 'body',)

مزیت کلیدی: پرفورمنس بالا در خواندن

بزرگترین نقطه قوت django-modeltranslation این است که برای خواندن اطلاعات ترجمه شده، نیاز به هیچ JOIN اضافه‌ای در دیتابیس ندارد. تمام ترجمه‌ها در همان سطر (Row) جدول اصلی قرار دارند. این موضوع باعث می‌شود سرعت کوئری‌ها بسیار بالا باشد و برای سایت‌های پربازدید که نگران Core Web Vitals و سرعت پاسخ‌دهی سرور (TTFB) هستند، گزینه‌ای ایده‌آل است.

پکیج django-parler: انعطاف‌پذیری بالا

در مقابل روش ستونی، پکیج django-parler از روش “جدولی” استفاده می‌کند. این پکیج برای هر مدل، یک جدول ترجمه جداگانه می‌سازد. این رویکرد شبیه به روشی است که وردپرس (با افزونه‌هایی مثل WPML) یا دروپال استفاده می‌کنند.

چه زمانی از parler استفاده کنیم؟

اگر پروژه شما ویژگی‌های زیر را دارد، django-parler انتخاب بهتری است:

1. تعداد زبان‌های سایت زیاد است (مثلاً ۲۰ زبان).
2. ممکن است در آینده زبان‌های جدیدی اضافه کنید و نمی‌خواهید هر بار makemigrations انجام دهید و ساختار دیتابیس را تغییر دهید.
3. نیاز دارید که ترجمه‌ها را به‌صورت مستقل مدیریت کنید.

استفاده از parler کمی پیچیده‌تر است و نیاز به تغییر در تعریف مدل دارد:

from django.db import models
from parler.models import TranslatableModel, TranslatedFields

class Product(TranslatableModel):
    # فیلدهای مشترک (مثل قیمت)
    price = models.IntegerField()
    
    # فیلدهای ترجمه‌پذیر
    translations = TranslatedFields(
        title = models.CharField(max_length=200),
        description = models.TextField()
    )

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

رابط کاربری ادمین: Tabbed Interface

یکی از بزرگترین چالش‌های ترجمه محتوا در ادمین جنگو، شلوغی بیش از حد فرم‌هاست. تصور کنید ۱۰ فیلد دارید و سایت شما ۳ زبانه است. در حالت عادی، شما ۳۰ فیلد پشت سر هم می‌بینید که اسکرول کردن بین آن‌ها کابوس است.

راه‌حل حرفه‌ای، استفاده از Tabbed interface for translations است. این قابلیت فیلدهای مربوط به هر زبان را در تب‌های جداگانه دسته‌بندی می‌کند.

فعال‌سازی تب‌ها در django-modeltranslation

خوشبختانه این پکیج سازگاری خوبی با django-modeltranslation-static دارد که تب‌هایی شبیه به مرورگر را به فرم‌های ادمین اضافه می‌کند. این ویژگی باعث می‌شود مدیر سایت بتواند به‌راحتی بین “فارسی” و “انگلیسی” سوییچ کند بدون اینکه صفحه شلوغ شود.

برای فعال‌سازی دستی بدون پکیج اضافه، می‌توانید از Media کلاس در ادمین استفاده کنید و فایل‌های جاوااسکریپت سفارشی را تزریق کنید که فیلدها را گروه‌بندی کنند. داشتن یک رابط کاربری تمیز، بخش مهمی از content management workflow است که از خطای انسانی جلوگیری می‌کند.

یکپارچه‌سازی با APIهای ترجمه خودکار

در سال ۲۰۲۵، وارد کردن دستی تمام ترجمه‌ها کاری زمان‌بر و پرهزینه است. یک ویژگی پیشرفته که می‌تواند ارزش پنل ادمین شما را چند برابر کند، integrating translation services API است. تصور کنید مدیر سایت متن فارسی را می‌نویسد و با زدن یک دکمه “ترجمه خودکار”، فیلدهای انگلیسی و عربی توسط هوش مصنوعی پر می‌شوند.

پیاده‌سازی Action در ادمین

شما می‌توانید یک Admin Action بنویسید که به API سرویس‌هایی مثل Google Translate یا DeepL متصل شود.

# admin.py snippet concept
def auto_translate_content(modeladmin, request, queryset):
    for obj in queryset:
        if obj.title_fa and not obj.title_en:
            # Call translation API here
            translated_text = call_translator_api(obj.title_fa, source='fa', target='en')
            obj.title_en = translated_text
            obj.save()

auto_translate_content.short_description = "ترجمه خودکار فیلدهای خالی به انگلیسی"

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

مدیریت اسلاگ‌ها (Slugs) در سئو چندزبانه

یکی از نکات حیاتی در سئو، ترجمه URLها است. گوگل به URLهایی که به زبان کاربر باشند (مثلاً /fa/محصول-جدید و /en/new-product) امتیاز مثبت می‌دهد.

در django-modeltranslation، شما می‌توانید فیلد slug را هم ترجمه کنید. اما چالش زمانی پیش می‌آید که می‌خواهید لینک‌دهی داخلی انجام دهید. استفاده از get_absolute_url باید هوشمند باشد و بر اساس زبان فعال فعلی، اسلاگ درست را برگرداند.

اگر از django-parler استفاده می‌کنید، مدیریت اسلاگ‌ها کمی راحت‌تر است زیرا هر ترجمه رکورد مستقلی دارد. اما در هر دو حالت، باید مطمئن شوید که LocaleMiddleware جنگو به‌درستی پیکربندی شده است تا زبان کاربر را از روی URL تشخیص دهد و دیتای درست را از دیتابیس فچ کند.

مقایسه نهایی: کدام را انتخاب کنیم؟

برای اینکه تصمیم‌گیری برایتان راحت‌تر شود، بیایید این دو پکیج را بر اساس معیارهای کلیدی مقایسه کنیم:

1. سهولت استفاده (Developer Experience):

• django-modeltranslation: بسیار آسان. کافیست فیلدها را رجیستر کنید. مدل‌های شما دست‌نخورده باقی می‌مانند.
• django-parler: نیاز به تغییر ارث‌بری مدل‌ها و تغییرات ساختاری در کد دارد.

2. مقیاس‌پذیری زبان‌ها:

• django-modeltranslation: برای تعداد زبان‌های کم (زیر ۵) عالی است. افزودن زبان جدید نیاز به مایگریشن دیتابیس (تغییر ساختار جدول) دارد که در دیتابیس‌های بزرگ زمان‌بر است.
• django-parler: عالی برای تعداد زبان‌های زیاد. افزودن زبان جدید نیازی به تغییر اسکمای دیتابیس ندارد.

3. سازگاری با سایر پکیج‌ها:

• django-modeltranslation: چون ساختار مدل را تغییر نمی‌دهد، با اکثر پکیج‌های دیگر جنگو (مثل Django Rest Framework) به‌راحتی کار می‌کند.
• django-parler: ممکن است در فیلتر کردن‌های پیچیده یا کار با DRF نیاز به تنظیمات اضافی و Serializerهای خاص داشته باشد.

جریان کاری مدیریت محتوا (Workflow)

داشتن ابزار مناسب تنها نیمی از راه است. نیم دیگر، تعریف یک content management workflow صحیح است. در پروژه‌های چندزبانه، معمولاً یک زبان به عنوان “زبان مبدأ” (Source Language) در نظر گرفته می‌شود.

بهترین روش این است که فیلدهای زبان اصلی را “اجباری” (Required) و فیلدهای زبان‌های دیگر را “اختیاری” (Optional) تعریف کنید. همچنین می‌توانید با استفاده از ویژگی fallback_values در تنظیمات جنگو، مشخص کنید که اگر ترجمه انگلیسی موجود نبود، همان متن فارسی را نشان دهد تا صفحه خالی نماند.

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

نتیجه‌گیری

انتخاب بین django-modeltranslation و django-parler به نیازهای خاص پروژه شما بستگی دارد. اگر به دنبال پرفورمنس بالا و راه‌اندازی سریع برای یک سایت دو یا سه زبانه هستید، django-modeltranslation پادشاه بلامنازع است. اما اگر در حال ساخت یک پلتفرم بین‌المللی با ده‌ها زبان و نیاز به انعطاف‌پذیری بالا هستید، django-parler سرمایه‌گذاری بهتری است.

نکته مهم این است که فارغ از پکیج انتخابی، رابط کاربری ادمین را با Tabbed interface for translations بهینه کنید و تا جای ممکن فرآیندها را با integrating translation services API خودکار نمایید. سئو محتوای چندزبانه فقط داشتن URLهای متفاوت نیست، بلکه ارائه تجربه‌ای روان و سریع به کاربر در هر زبانی است که با معماری صحیح دیتابیس محقق می‌شود.

سوالات متداول (FAQ)

۱. آیا تغییر زبان پیش‌فرض سایت (LANGUAGE_CODE) باعث از بین رفتن اطلاعات ترجمه شده می‌شود؟

در پکیج django-modeltranslation، اگر زبان پیش‌فرض را عوض کنید، داده‌های ستون‌های قبلی پاک نمی‌شوند، اما ممکن است دسترسی به آن‌ها در کد تغییر کند. فیلد اصلی (بدون پسوند زبان) معمولاً به زبان پیش‌فرض اشاره دارد. تغییر زبان پیش‌فرض نیازمند یک مایگریشن دقیق برای جابجایی دیتا بین ستون‌هاست تا محتوا گم نشود.

۲. آیا این پکیج‌ها با Django Rest Framework (DRF) سازگار هستند؟

بله، هر دو پکیج راهکارهایی برای DRF دارند. برای modeltranslation، سریالایزرها معمولاً تمام فیلدها (title_en, title_fa) را برمی‌گردانند یا می‌توانید با هدر Accept-Language مشخص کنید کدام فیلد در خروجی بیاید. پکیج django-parler-rest نیز ابزارهای مخصوصی برای کار با مدل‌های parler در API فراهم می‌کند.

۳. اگر ترجمه یک مطلب برای یک زبان خاص کامل نباشد، چه اتفاقی برای نمایش در سایت می‌افتد؟

این موضوع به تنظیمات FALLBACK_LANGUAGES در settings.py بستگی دارد. شما می‌توانید تنظیم کنید که اگر ترجمه انگلیسی موجود نبود، متن فارسی نمایش داده شود یا اینکه آن فیلد خالی بماند (یا None برگرداند). مدیریت صحیح این بخش برای جلوگیری از نمایش صفحات خالی به کاربر بسیار حیاتی است.