Code

Opened 6 years ago

Last modified 15 months ago

#6460 new New feature

New feature : Multilingual Content

Reported by: g00fy Owned by: nobody
Component: Internationalization Version:
Severity: Normal Keywords: multilingual content i18n-nofix
Cc: nreilly@…, tolano, 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.

Attachments (0)

Change History (19)

comment:1 Changed 6 years ago by ubernostrum

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Someday/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 6 years ago by Piotr Lewandowski <django@…>

  • Component changed from Uncategorized to Internationalization

comment:3 Changed 6 years ago by anonymous

  • Keywords i18n-rf added
  • milestone set to post-1.0

comment:4 Changed 6 years ago by anonymous

  • Cc nreilly@… added

comment:5 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:6 Changed 5 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 follow-up: Changed 5 years ago by tolano

  • Cc tolano added

comment:8 Changed 5 years ago by RaceCondition

  • Cc eallik@… added

comment:9 Changed 5 years ago by garcia_marc

  • Keywords i18n-nofix added; i18n-rf removed

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

  • Cc goliath.mailinglist@… added

comment:11 in reply to: ↑ 7 Changed 4 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 4 years ago by hejsan

  • Cc hr.bjarni+django@… added

comment:13 Changed 4 years ago by blubmitsahne

Overview of current implementations and alternatives documented in ModelInterNationalization

comment:14 Changed 4 years ago by blubmitsahne

  • Cc alex.guenther@… added

comment:15 Changed 3 years ago by julien

  • Type set to New feature

comment:16 Changed 3 years ago by vzima

  • Cc vlastimil.zima@… added
  • Easy pickings unset
  • Severity set to 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 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:18 Changed 20 months ago by ojii

  • Cc ojiidotch@… added

comment:19 Changed 15 months ago by kitsunde

  • Cc kitsunde@… added

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.