how are you handling i18n and m10l content?
Bill de hOra
I know Django has solid i18n support for templates/strings and content
negotiation in the request. But I was wondering how people are going
about managing translations of content or having a multilingual website
- eg supporting features like "read this in newspeak", or "browse this
site in klingon". More realistic examples would be Wikipedia or Plone's
ability to set the portal language.
There's no direct support for this kind of thing in the core (that's
afaik, I haven't been following the trunk in the last couple of months).
And, if there's no standard patterns or models for this, is this worth
thinking about at as an extension app? In my part of the world, being
able to run a multilingual site is often a 'checkbox' requirement.
cheers
Bill
James Bennett
> There's no direct support for this kind of thing in the core (that's
> afaik, I haven't been following the trunk in the last couple of months).
> And, if there's no standard patterns or models for this, is this worth
> thinking about at as an extension app? In my part of the world, being
> able to run a multilingual site is often a 'checkbox' requirement.
You're right that there's currently nothing built in to Django which
would cover this, but it would definitely be a great thing to add; I'm
not sure what the best way to genericize it would be, though; most of
the models I end up with whenever I think about this problem end up
being more complicated than they probably need to be (e.g., I
generally conceive of a base model which holds the core metadata of
the object, and then translated versions related to it, with a whole
scheme of access methods on the base to figure out which languages are
available and fetch them, etc. etc.).
I don't have any real experience in that area, though; what are some
general best practices for the backend design of a multilingual site?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Jacob Kaplan-Moss
*Great* question. We've talked a few times to newspapers who cross-publish
(usually in English and Spanish), and at least in the news industry there's
pretty much nothing that makes that process easy. I would absolutely love to
have a standard way of doing translatable content in Django; I think it would
really set Django well ahead of a lot of other tools out there.
Perhaps if there's enough interest we should form a small sub-group and try to
come up with something? I've certainly got ideas about how it might work, but
it would at least be fun to bounce those ideas off smart people...
Jacob
Patrick
From the time I got involved in creating Web sites, I have always
been working on multilingual sites. It has always been the most complex
part of the job, so I'm interested in a solid, simpler Django solution.
I'm sure it's a thought that many developers often had on their mind, so I
believe that there is a need, but I'm not sure if a framework should
provide a solution, or that a solution should be found by developers
themselves. It could be easier if there was one built into the framework,
but if it happens, I think it should be optional.
Could this app be connected to content_type in a way that comments are?
lbolo...@gmail.com
> I don't have any real experience in that area, though; what are some
> general best practices for the backend design of a multilingual site?
Where i work we have a concept of "channels". Different instances of
the sites (probably they could fit well in Django's site framework) are
localized for different countries/languages. News on these websites are
channelized too and are set by some backend application.
I'll try to come back with more details on how our model works.
Lorenzo
Kenneth Gonsalves
On 08-Nov-06, at 6:27 AM, lbolo...@gmail.com wrote:
> Where i work we have a concept of "channels". Different instances of
> the sites (probably they could fit well in Django's site framework)
> are
> localized for different countries/languages. News on these websites
> are
> channelized too and are set by some backend application.
>
> I'll try to come back with more details on how our model works.
eagerly waiting ...
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Bill de hOra
Yep, I'd love to? Btw, there's a related thread here from yesterday,
which I just came across:
Ivan Sagalev has code sketches, and Frankie Robertson pointed at this:
http://trac.studioquattro.biz/djangoutils/wiki/TranslationService
which I hadn't seen before; looks like it leverages the gettext
machinery for translations.
cheers
Bill
Gonzalo Saavedra
I'd been reserching and trying to come up with some ideas on this
matter, hoping to get to an elegant and simple solution since I'm
involved with two django projects which will need content translation.
Some months ago a similar thread was discused on this list:
http://groups.google.com.uy/group/django-users/browse_thread/thread/ef78a6787a98bc68/2aabccc699388fad
I think there are some interesting ideas there... so I took Georg
ideas as a starting point, what do you think about his aproach?
I'm definitely interested on working with others to see this feature
in django in the future.
gonz.
--
Gonzalo Saavedra <gonzalo...@gmail.com>
Aidas Bendoraitis
multilingual content:
http://groups.google.com/group/django-users/browse_frm/thread/13ae7f762d1d5d5e
Maybe that will help us to make the final decision.
Aidas Bendoraitis [aka Archatas]
fdb
For every model that needs to have multi-lingual content, you add two
fields: a "language" and a "translation_of" field.
Objects are created in a default language (altough this is not
required). To translate an object, you create a new page and set the
translation_of field to the object in the default language that you are
translating.
A set of helper methods allow you to get the root version of the object
(in the default language), all translations of an object, or a specific
translation. These are useful for adding translation links.
Here is the code:
http://www.bigbold.com/snippets/posts/show/2979
Note again that it's perfectly fine to add objects in another language
than the default that don't have translations in the default language.
One restriction: you cannot translate a page that doesn't have a
default language version.
Frederik
Aidas Bendoraitis
Your approach has one major problem. If the model has both
translatable and untranslatable content, just like boolean
is_published or foreign key to category, or price (if the object is a
product), then the original and it's translations must duplicate the
untranslatable data which makes the models harder to manage.
Regards,
Aidas Bendoraitis [aka Archatas]
Kenneth Gonsalves
On 08-Nov-06, at 5:22 PM, fdb wrote:
> Note again that it's perfectly fine to add objects in another language
> than the default that don't have translations in the default language.
> One restriction: you cannot translate a page that doesn't have a
> default language version.
i took a look at this - it seems to imply that there is only one
translateable field in the model (I may be wrong). But for me a
typical page model would have several Char fields and more than one
text field. How does one handle that? I was thinking having
1. languages table - longname and shortname
2. for each table a translate table with fk to languages table and fk
to the translated table. This table will contain only translateable
fields (char and text). The two fks are unique_together. Whenever the
app sees a text or char field, it searches for a translation to insert.
3. Translation would be page independant and table independant. For
any given language, the app searches for all untranslated text and
char fields and displays them, one can select to translate.
4. Provision should be made for automatically translating strings,
review of this and review of translations themselves.
Aidas Bendoraitis
Just there is no need for the intermediate table between the table
with untranslatable fields and the table with translatable ones,
because the relationship between these two tables is one to many. So
the table with translatable fields could just have a FK to the table
with untranslatable fields. So the solution is more or less the same
as I proposed some time ago.
Actually this could be integrated into the core.
When you create a model, you could add translatable=True to fields
that have to be in the language-specific table.
When you make selections, you would need to set the language name in
the following or a similar way:
MyModel.objects.by_language("EN").all()
MyModel.objects.by_language("EN").order_by('title')
which would form queries like:
SELECT * FROM myapp_mymodel INNER JOIN myapp_mymodel_translatable ON
myapp_mymodel.id = myapp_mymodel_translatable.id ORDER BY title
Regards,
Aidas Bendoraitis [aka Archatas]
Gacha
for all content. Every model realy holded only integer values and
values, that should't be translated. Fields like "title" and
"description" was virtual, they didn't exist in the table, but I was
able to call them like "Model.field" and get the value translated to
current language.
All the translations was stored in Trans table, with structure: (id |
table | field | fid | lang | value ). For example you have a model like
Category and every category has name and it should be in all languages.
To get the name of the category you do:
c = Category.objects.get(pk=1)
print c.name
In "print c.name" it will call __getattr__ function and then a helper
function witch will return a record from Trans table WHERE
table='category' AND field='name' AND fid=1 AND lang='EN'.
I think that this can be done in "django way", maybe later someone can
make a field like TransField and all other stuff would be automaticly.
I hope you get the point, sorry for bad english :)
Gacha
Aidas Bendoraitis wrote:
> MyModel.objects.by_language("EN").all()
> MyModel.objects.by_language("EN").order_by('title')
I think this would be greate.
Aidas Bendoraitis
In your suggestion there is no way to sort objects by
language-specific fields, except in the programming language level, is
there? And the other disadvantage is that value field is always of the
TEXT type whereas sometime it could be VARCHAR or CHAR, so you are
kind of wasting resources.
Regards,
Aidas Bendoraitis [aka Archatas]
Kenneth Gonsalves
sensational is the word ;-)
Gacha
figure out :) I readed your suggestion and I think it's very good and I
think it's very easy to implement in django system.
fdb
> i took a look at this - it seems to imply that there is only one
> translateable field in the model (I may be wrong). But for me a
> typical page model would have several Char fields and more than one
> text field. How does one handle that? I was thinking having
Actually, all the fields in the model are translatable. You just create
a language-specific version of your model. None of the fields have to
match, you just have to set the translation_of. That is the link to the
root language version.
I do use this to translate paths ("slugs") and titles as well, with
minimum fuss.
Carlos Yoder
> >> MyModel.objects.by_language("EN").all()
> >> MyModel.objects.by_language("EN").order_by('title')
> >
> > I think this would be greate.
>
> sensational is the word ;-)
>
Now we just need to get one of the Django-savvy developers to
implement it, since I'm sure they don't have anything else to do :-)
Now seriously, this would be fantastic. I'm in no position to help
with code (I started one of the reference threads, asking for help),
so I can only hope and cross my fingers for some guy(s) with with
enough time and skills will bite the bullet and start coding.
And now I read what I wrote. Enough time *and* skills? That could be tricky ;-)
Cheers,
--
Carlos Yoder
http://blog.argentinaslovenia.com/
Kenneth Gonsalves
On 09-Nov-06, at 4:03 PM, Carlos Yoder wrote:
> And now I read what I wrote. Enough time *and* skills? That could
> be tricky ;-)
i have been meaning to hack on django for nearly a year and a half
now - maybe it's time to get my feet wet ;-)
David Blewett
wrote:
> Actually this could be integrated into the core.
> When you create a model, you could add translatable=True to fields
> that have to be in the language-specific table.
> When you make selections, you would need to set the language name in
> the following or a similar way:
> MyModel.objects.by_language("EN").all()
> MyModel.objects.by_language("EN").order_by('title')
> which would form queries like:
> SELECT * FROM myapp_mymodel INNER JOIN myapp_mymodel_translatable ON
> myapp_mymodel.id = myapp_mymodel_translatable.id ORDER BY title
What about using generic relations for this? You could have something
like this:
class I18NText(models.Model):
language = models.ForeignKey(Language)
field = models.CharField(maxlength=25)
translated_text = models.TextField()
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
translated_object = models.GenericForeignKey()
def __str__(self):
return self.translated_text
class ModelNeedingTranslation(models.Model):
foo = models.IntegerField()
bar = models.TextField()
translations = models.GenericRelation(I18NText)
Then you can add translations of field(s) by doing:
a = ModelNeedingTranslation(1, 'nothing')
a.translations.create(field='bar', translated_text='nada',
language=Language('Spanish'))
You can get the text for a specific translation like this:
a.translations.filter(field='bar', language=Language('Spanish'))
David Blewett
David Blewett
> Then you can add translations of field(s) by doing:
> a = ModelNeedingTranslation(1, 'nothing')
> a.translations.create(field='bar', translated_text='nada',
> language=Language('Spanish'))
>
> You can get the text for a specific translation like this:
> a.translations.filter(field='bar', language=Language('Spanish'))
>
> David Blewett
Here's some links about generic relations:
http://feh.holsman.net/articles/2006/06/19/django-generic-relations
http://www.djangoproject.com/documentation/models/generic_relations/
David Blewett
Carlos Yoder
:-O
Would it be really that simple?
Aidas Bendoraitis
API of Django has to be modified, but also the administration
interface, if we stuck at this solution.
By the way, I forgot to set language in the WHERE clause of my
example, but that makes no big difference for imagining what I had in
mind:
SELECT * FROM myapp_mymodel mm INNER JOIN myapp_mymodel_translatable mmt ON
mm.id = mmt.id WHERE mmt.language = 'EN' ORDER BY title
And also perhaps we need a separate branch for implementation of
multilingual modelling.
Regards,
Aidas Bendoraitis [aka Archatas]
