[Answered ]-Django: django-transmeta – sorting comments

by

2👍

I tried the approach of transmeta for translation of dynamic texts and I had the following experience:

  • You want another language, you need to change the database model which is generally undesirable
  • You need every item in both languages, which is not flexible
  • You have problems linking with other objects (as you point out in your question)

If you take the way of transmeta you will need two solutions:

  • The transmeta solution for translating fields in a model
  • For objects connected to a model using transmeta you will need an additional field to determine the language, say CharField with “en”, “de”, “ru” etc.

These were major drawbacks that made me rethink the approach and switch to another solution: django.contrib.sites. Every model that needs internationalization inherits from a SiteModel:

class SiteModel(models.Model):
    site = models.ForeignKey(Site)

Every object that would need transmeta translation is connected to a site. Every connected object can determine its language from the parent object’s site attribute.

I basically ran the wikipedia approach and had a Site object for every language on a subdomain (en., de., ru.). For every site I started a server instance that had a custom settings file which would set the SITE_ID and the language of the site. I used django.contrib.sites.managers.CurrentSiteManagerto display only the items in the language of the current site. I also had a manager that would give you objects of every language. I constructed a model that connects objects of the same model from different languages denoting that they are semantically the same (think languages left column on wikipedia). The sites all use the same database and share the same untranslated User model, so users can switch between languages without any problem.

Advantages:

  • Your database schema doesn’t need to change for additional languages
  • You are flexible: add languages easily, have objects in one language only etc.
  • Works with (generic) foreign keys, they connect to an object and know what language it is. You can display the comments of an object and they will be in one language. This solves your problem.

Disadvantages:

  • It’s a greater deal to setup: you need a django server instance for every site and some more glue code
  • If you need e.g an article in different languages, you need another model to connect them

You may not need the django Site model and could implement something that does the same without the need of multiple django server instances.

I don’t know what you are trying to build and what I described might not fit to your case, but it worked out perfectly for my project (internationalized community platform built upon pinax: http://www.bpmn-community.org/ ). So if you disclose some more about your project, I might be able to advise an approach.

To finally answer your question: No, the generic comments will not work out of the box with transmeta. As you realised you will have to display comments in both languages for the article that is displayed in one language. Or you will have to hack into the comments and change the model and do other dirty stuff (not recommended). The approach I described works with comments and any other pluggable app.

To answer your questions:

  1. Two Django instances can share one database, no problem there.
  2. If you don’t want two Django instances, but one, you will have to do the following: A middleware checks the incoming request, extracts desired language from URL (en.example.com or example.com/en/ etc.) and saves the language preference in the request object. The view will have to take the request object with the language and take care of the filtering of objects accordingly. Since there is no dedicated server for the language (like in the sites approach where the language is stored in the settings.py file), you can only get the language from the request and you will have to pass attributes from the request object to Model managers to filter objects.

You could try to fake a global language state in the django application with an approach like threadlocals middleware, however I don’t know if this plays out nicely with django I18N engine (which is also does some thread magic).

If you want to go big with your site in multiple languages, I recommend going for the sites-approach.

👤stefanw

Leave a comment