DEV Community: Rafał Przetakowski

Smart Language Detection in Django Using Middleware and Domain/Subdomain Configuration

Rafał Przetakowski — Thu, 03 Apr 2025 18:34:41 +0000

When building a multilingual Django application, choosing the right language for your users can make or break their experience. Instead of asking users to select a language every time, we can auto-detect it using domain names or subdomain prefixes.

In this article, you'll learn how to:

Configure your Django app to support multiple languages.
Set language based on domain (example.pl, example.com) or subdomain (pl.example.com, en.example.com).
Keep everything clean and declarative — no messy if/else logic.

This is a beginner-friendly guide. Let’s dive in.

📁 1. Project Setup and Language Configuration

Start by enabling multiple languages in your settings.py:

LANGUAGE_CODE = "en"

LANGUAGES = [
    ("en", "English"),
    ("pl", "Polish"),
]

You also need to add a fallback configuration:

USE_I18N = True
USE_L10N = True
USE_TZ = True

🌐 2. Define Your Language Rules in `settings.py`

We'll store language-to-domain mappings in a declarative way:

LANGUAGE_BY_DOMAIN = {
    "whathappensnext.online": "en",
    "cobylodalej.online": "pl",
}

LANGUAGE_SUBDOMAIN_PREFIXES = {
    "en": "en",
    "pl": "pl",
}

USE_SUBDOMAIN_LANGUAGE = True  # Enable subdomain-based resolution

This way, you don’t need any if statements — all the logic is in settings.

⚖️ 3. Create the Language Detection Middleware

Now, let's build the middleware to read the host and determine the language:

from django.utils import translation
from django.conf import settings

def get_language_from_domain(host: str, fallback: str) -> str:
    domain = ".".join(host.lower().split(".")[-2:])
    return settings.LANGUAGE_BY_DOMAIN.get(domain, fallback)

def get_language_from_subdomain(host: str, fallback: str) -> str:
    parts = host.lower().split(".")
    if len(parts) < 3:
        return fallback
    return settings.LANGUAGE_SUBDOMAIN_PREFIXES.get(parts[0], fallback)

LANGUAGE_RESOLVERS = (
    get_language_from_domain,
    get_language_from_subdomain,
)

class SmartLanguageMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        self.fallback_language = getattr(settings, "LANGUAGE_CODE", "en")

    def __call__(self, request):
        host = request.get_host().split(":")[0]
        use_subdomain = getattr(settings, "USE_SUBDOMAIN_LANGUAGE", False)
        resolver = LANGUAGE_RESOLVERS[use_subdomain]
        lang = resolver(host, self.fallback_language)

        translation.activate(lang)
        request.LANGUAGE_CODE = lang

        response = self.get_response(request)
        translation.deactivate()
        return response

➕ 4. Register the Middleware

In your settings.py, add your new middleware before Django’s default locale middleware:

MIDDLEWARE = [
    "your_project.middleware.SmartLanguageMiddleware",
    "django.middleware.locale.LocaleMiddleware",
    ...
]

🪡 5. Example Use Cases

With this setup, users visiting:

https://przykladowyserwis.com will see Polish.
https://someservice.com will see English.
https://pl.someservice.com will see Polish (if USE_SUBDOMAIN_LANGUAGE = True).
https://en.someservice.com will see English.

You can always extend or modify the resolver logic to suit your needs.

🚀 6. Summary

By using a smart, declarative middleware, you:

Detect languages based on host or subdomain automatically.
Avoid hard-coded logic.
Keep things clean and scalable.

This technique is great for multilingual SaaS apps or platforms where each region or market has its domain.

How to Add Multilingual Support in Django with Django-parler

Rafał Przetakowski — Thu, 03 Apr 2025 12:37:09 +0000

If you're building a Django app that needs to support more than one language, Django's built-in internationalisation (i18n) is a decent start. But if you want to go further — like translating model fields, managing multilingual content, and switching language context dynamically — Django-parler is the tool you want.

This guide is aimed at beginners and covers everything from installation to usage, with best practices and practical examples.

🌍 Why Use `Django-parler`?

Django itself provides tools for translating strings in templates and Python code. Still, it doesn't offer a clean way to make database models translatable — to have fields that store multiple language versions.

Django-parler solves this with a well-designed API and seamless integration into Django admin and queries.

🔧 Installation and Basic Configuration

First, install the package:

pip install django-parler

Then, add it to your INSTALLED_APPS in settings.py:

INSTALLED_APPS = [
    ...
    'parler',
]

Set your supported languages:

LANGUAGE_CODE = 'en'

LANGUAGES = [
    ('en', 'English'),
    ('pl', 'Polski'),
]

PARLER_LANGUAGES = {
    None: (
        {'code': 'en'},
        {'code': 'pl'},
    ),
    'default': {
        'fallbacks': ['en'],
        'hide_untranslated': False,
    },
}

🧱 Making a Model Translatable

Let's say you want to create a Category model in which each language's name and slug should differ.

Here's how to do it with parler:

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

class Category(TranslatableModel):
    translations = TranslatedFields(
        name=models.CharField(max_length=200),
        slug=models.SlugField(max_length=200, unique=True),
    )

    def __str__(self):
        return self.safe_translation_getter('name', any_language=True)

Key points:

Use TranslatableModel as your base class.
Define translatable fields inside TranslatedFields().
Use safe_translation_getter() to safely get the translated value.

🛠 Using Translations in the Admin

Django-parler provides an admin mixin to show translation tabs automatically:

from django.contrib import admin
from parler.admin import TranslatableAdmin
from .models import Category

@admin.register(Category)
class CategoryAdmin(TranslatableAdmin):
    list_display = ('__str__',)

You'll now see tabs for each language when editing an object in the admin.

🔍 Querying Translatable Models

To avoid duplicate entries or incorrect results, always use .translated() when querying:

from .models import Category

# Only get categories that are translated into the current language
Category.objects.translated('pl').filter(translations__is_published=True)

Or to get only those that exist in the current request's language:

from django.utils.translation import get_language

Category.objects.translated(get_language()).all()

⚠️ Avoid using .filter(translations__...) without .translated(...) or .distinct() — this can lead to duplicate rows in querysets.

🎯 Rendering Translations in Templates

Use safe_translation_getter() to access values in templates:

{{ category.safe_translation_getter:"name" }}

Or use the standard property (like category.name) if you're sure the model is correctly translated in the context.

🧪 Testing Translations

Use Django's override context to test translations:

from django.utils.translation import override

with override('pl'):
    category = Category.objects.first()
    print(category.name)  # Should be in Polish

🧹 Best Practices

Use safe_translation_getter to prevent NoneType errors.
Always use .translated() when filtering by translatable fields.
Never mix translated and untranslated queries unless you use .distinct().
Use admin mixins to have a smooth experience when editing translations.
Don't duplicate logic — define fallbacks and supported languages in one place (settings.py).

✅ Summary

Django-parler is a powerful tool for multilingual content in Django. With minimal configuration, you can:

Translate model fields.
Filter and fetch content in the current language.
Provide a seamless admin experience.

Stay tuned, and happy translating! 🌍