Opened 16 years ago

Closed 10 years ago

#6460 closed New feature (wontfix)

New feature : Multilingual Content

Reported by: g00fy Owned by: nobody
Component: Internationalization Version:
Severity: Normal Keywords: multilingual content i18n-nofix
Cc: nreilly@…, Adrian Ribao, eallik@…, goliath.mailinglist@…, hr.bjarni+django@…, alex.guenther@…, vlastimil.zima@…, ojiidotch@…, kitsunde@… Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I found django-multilingual very usefull (http://code.google.com/p/django-multilingual/), but since it is not working well with complex models I think that django should nativly support multilingual content. And by that i mean text fields that are translation. For me this is very vital feature, and in my mind it would be very helpfull for developing multilingual websites such as booking.com (where decriptions of hotels are aviable in every 16 languages). I think that django developers will consider this ticket (idea) usefull.

Change History (20)

comment:1 Changed 16 years ago by James Bennett

Triage Stage: UnreviewedSomeday/Maybe

Per mailing list discussion here, this is not likely to be integrated into Django prior to 1.0. Bumping to "Someday/Maybe" to reflect this.

comment:2 Changed 15 years ago by Piotr Lewandowski <django@…>

Component: UncategorizedInternationalization

comment:3 Changed 15 years ago by anonymous

Keywords: i18n-rf added
milestone: post-1.0

comment:4 Changed 15 years ago by anonymous

Cc: nreilly@… added

comment:5 Changed 15 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:6 Changed 15 years ago by tomgruner

It seems like for complex models you can use django-multilingual-model
http://code.google.com/p/django-multilingual-model/

This is not the same as django-multilingual. It´s much simpler.

You have to create the translation models yourself, but it is very easy to use and doesn´t limit the model complexity in any way as it not trying to be overly magical.

By not moving multilingual fields into the core, I think Django can remain flexible to different multilingual solutions, as it´s hard to come up with a one size fits all solution. I´ve developed an app with django-multilingual-model and have had no problems, since it´s based on the normal ways models are related in Django anyway. I am just a user of django, not on the dev team, but I would prefer django as is with respect to multilingual content.

Also you can see a list of current solutions here:
http://and-other-things.blogspot.com/2009/04/list-of-django-multilingual-model.html

comment:7 Changed 14 years ago by Adrian Ribao

Cc: Adrian Ribao added

comment:8 Changed 14 years ago by Erik Allik

Cc: eallik@… added

comment:9 Changed 14 years ago by Marc Garcia

Keywords: i18n-nofix added; i18n-rf removed

comment:10 Changed 14 years ago by David Danier <goliath.mailinglist@…>

Cc: goliath.mailinglist@… added

comment:11 in reply to:  7 Changed 14 years ago by SashaN

Replying to tolano:
just for curiosity: how do you solve problems with forms? I don't want to use
the admin interface for managing content in my app.

I was playing django-multilingual for a while. I've hit issue 71 there. I could come up
with kind of patch. But I'm not experienced in django/python enough to
create ultimate solution. I believe I need to create MultilingModelForm
class, which will have clean(), save() ... methods overloaded to save data
into model and translation table.

There is a django-transmeta, which solves problem with forms. I know there
is a problem with transmeta it 'messes up' model tables a bit. On the other
hand it provides (by my opinion) more simple interface than django-multilingual.

comment:12 Changed 14 years ago by hejsan

Cc: hr.bjarni+django@… added

comment:13 Changed 14 years ago by blubmitsahne

Overview of current implementations and alternatives documented in ModelInterNationalization

comment:14 Changed 14 years ago by blubmitsahne

Cc: alex.guenther@… added

comment:15 Changed 13 years ago by Julien Phalip

Type: New feature

comment:16 Changed 13 years ago by Vlastimil Zíma

Cc: vlastimil.zima@… added
Easy pickings: unset
Severity: Normal

I noticed this ticket while I am working on new version for django-multilingual-ng as old version lost support.
My branch is available at github: https://github.com/vzima/django-multilingual-ds9 it has still several issues now, but I tried to make core easy to read.

Notes to ModelInterNationalization wiki page.

  • There is probably no good way how to store language information.
    • Translations as columns in same table
    • Translations as rows in same table
    • Translations as different table First two requires duplicity of non-translatable fields, first one even requires database changes when number of supported languages increases. In my opinion this is worse than having translations as different objects and need to join them when required.
  • Easy access to translation for different language than currently active might be required by use case, i.e. display two languages on page at once or form that would contain fields for different languages to be displayed at once.

IMHO I would support solution (3) no only because I write app that works that way :)

This has several advantages

  • No copies of non-translatable fields
  • No troubles with relations because parent object is only one.
  • Enables access to different languages if required
  • Enables creation of all translations at once if required

comment:17 Changed 12 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:18 Changed 11 years ago by Jonas Obrist

Cc: ojiidotch@… added

comment:19 Changed 11 years ago by Kit Sunde

Cc: kitsunde@… added

comment:20 Changed 10 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed

There are several good third-party applications providing this feature, the most popular one being django-modeltranslation (I think).

But there's no one-size-fits all solution. As a consequence, I believe it's better to leave this feature up to third-party applications.

Note: See TracTickets for help on using tickets.
Back to Top