How would you do this on Django?
Carlos Yoder
I've been developing (in my head) a multilang, multisite, multiuser
blog application, that -at least for me- sounds like a very cool idea.
On to the details:
The project is actually a group of sister websites dealing with a
common subject, localised for different languages/cultures. It's
centered around the old "you learn a thing a day" saying, so Authors
would be able to post the thing they learned that day on a -usually
small- post. Of course, they would have to be able to post in many
different languages (initially either English, Slovenian or Spanish).
As to URLs, I'd need to support at least the following three schemes:
* Language codes mapped to directories (http://maindomain.com/en/ and
http://maindomain.com/sl/ and http://maindomain.com/es/)
* Language codes mapped to subdomains (http://en.maindomain.com/ and
http://sl.maindomain.com/ and http://es.maindomain.com)
* Completely different starting URLs (http://athingaday.com/ and
http://nekajnovega.com and httpd://algonuevo.com/
As to the post themselves, each different version would have to be
aware of its 'sister' posts in other languages, but that's already a
template thing I believe.
It goes without saying that these multiple localised versions would
have to get data off a single database.
OK, enough details for now, we all have work to do :-)
Anyway, I thought about the "sites" app on Django, but never used it
and I'm at a loss. I must admit I first too a look at Polyglot, a
plugin for Wordpress, but I really want to stay away from PHP and do
things right.
Could anyone help me a bit on how to approach this? Thanks a million,
and best regards,
--
Carlos Yoder
http://blog.argentinaslovenia.com/
Frankie Robertson
I personally know nothing about this. But I will give you some links
to get started (in order of importance):
http://www.djangoproject.com/documentation/i18n/
http://trac.studioquattro.biz/djangoutils/wiki/TranslationService
http://trac.studioquattro.biz/djangoutils
That might give you a some general ideas.
>
> --
> Carlos Yoder
> http://blog.argentinaslovenia.com/
>
> >
>
Carlos Yoder
I guess I'm OK with the i18n part of the idea. Not so sure about the
'best practises' to implement, though (that was the general idea of
this post).
But many thanks for the links anyway. Regards,
Ivan Sagalaev
> As to URLs, I'd need to support at least the following three schemes:
>
> * Language codes mapped to directories (http://maindomain.com/en/ and
> http://maindomain.com/sl/ and http://maindomain.com/es/)
> * Language codes mapped to subdomains (http://en.maindomain.com/ and
> http://sl.maindomain.com/ and http://es.maindomain.com)
> * Completely different starting URLs (http://athingaday.com/ and
> http://nekajnovega.com and httpd://algonuevo.com/
>
> As to the post themselves, each different version would have to be
> aware of its 'sister' posts in other languages, but that's already a
> template thing I believe.
I've made something similar (but not as big) on my site to have
different language versions of programs I made. Here are some thoughts.
1. I18n in Django helps but it works in an assumption that single user
works in one language at a time because language preference is related
to a user (be it a cookie or HTTP header). I needed the language to
depend solely on request URL so a user can explicitly ask for a page in
one or another language. I needed this because I believe there is no
such thing as fully translated multilingual sites: there are always
parts that don't exist in every language. And my case is a perfect
example because on whole site I have now exactly one page in different
language :-)
To deal with it you can use a middleware that looks for certain
parts of URL and decides a language base on it. To teach then Django
about the language of the request use:
from django.utils import translation
translation.activate(language)
request.LANGUAGE_CODE = language
Such a middleware may prove impractical if you have very different
URL structure across your site and in different places there may be no
language information in an URL or something. Then the code goes from
middleware into a view decorators that you assign only to those views
that need i18n.
2. There is a big gaping unexplored hole (at least in my head) about
translating content in a database. I've invented a way to do it but I
don't really excited about it myself. But it works nonetheless :-)
Models that describe multilingual things (say, Article) get two
additional fields, 'master' and 'language':
class Article(models.Model):
master = models.ForeignKey('self',
related_name='translations', null=True, blank=True)
language = models.CharField(maxlength=2, choices=LANGUAGES)
slug = models.SlugField()
categories = models.ManyToManyField(Categories, blank=True)
text = models.TextField()
The meaning of the 'language' field is obvious. 'master' is a
relation between an Article in one language (a master one) and all its
translations into other languages. Related articles contain translations
in those fields that it makes sense for (like 'text') but don't fill
other fields (like 'categories'). Values for these fields are taken from
the master record.
3. This borrowing from master item is designed to get rid of filling
translations with same repeated data by hand. But the bad part is that
in templates I now have to do like this:
{% firstof object.categories object.master.categories %}
... instead of just
{{ object.categories }}
May be I'll invent something to automate it later...
4. Getting a list of translations is also not very pretty:
def other_translations(self):
if self.master is None:
return list(self.translations.all())
else:
return [self.master] +
list(self.master.translations.exclude(language=self.language))