Carlos Yoder wrote:
> 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))
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
