Question

When developing apps for use in multiple languages, I see a real benefit to using localization over trying to build some ad hoc localization library specific to your application. I’m working on a website that will have 16 languages, and each language will have different images in various places, as well as full text translations for each page’s content, each language residing on a different URL (www.example.com/en/, etc). Django’s internationalization framework seems very magical, and tricky. My idea was to do something basic, like:

class Language(models.Model):
    name = models.CharField(max_length=50)
    code = models.CharField(max_length=2)  # (e.g. "FR")


class ContentSection(models.Model):
    page = models.ForeignKey('mysite.Page')
    name = models.CharField(max_length=50)  # (e.g. ("main body text")
    content = models.TextField(max_length=5000)

    class Meta:
        unique_together = (('name', 'page'),)


class ContentTranslation(models.Model):
    content_section = models.ForeignKey(ContentSection)
    language = models.ForeignKey(Language)
    content = models.TextField(max_length=5000)

    class Meta:
        unique_together = (('content_section', 'language'),)

I would use middleware to set the current language based on the first URL segment, and in my views I would pull the content for a given page in a view with something like:

# In views.view_page
left_content = ContentSection.objects.filter(page=current_page, name='left column text')
if not request.language.code == 'EN':
    left_content = ContentTranslation.objects.get(content_section=left_content, language=request.language)

Of course, in production I’d probably create a template tag that gets a content (with the correct language) by name, instead of explicitly pulling each content area in the view.

Does this seem so ridiculous to do this instead of using i18n? Am I missing the bigger picture with internationalization?

(keep in mind: the site will be browsed by users in other languages, but all admin stuff, including inserting translations, will be done in the US)

Answer 1

This is a sound approach if what you need is to be able to have your users change the content in all the different languages. You also get to create a nice interface for everything.

However, you are not using the Django i18n framework. So what is your question? 🙂

I have tried both using the i18n framework for content and using your approach. Storing translations in po-files is great for “system” text as you can use all your tools, like version control, bug tracking, etc. However, it is a pain in the ass if you have users who actually want to change the content all the time, which I believe is the case for almost any web site of some size.

As a side note, including the language in the URL makes it easier to cache the pages on the front end varnish proxy that everybody should be using, so +1 for that decision.