I would love to have the (native) feature that django-multilingual
gives. For me an many developers i know this is vital. Is it any way
that django 1.0 will support multilingual models (content) ?
On Jan 26, 2008 6:03 AM, Piotr Majewski <g00fy....@gmail.com> wrote:
> I would love to have the (native) feature that django-multilingual > gives. For me an many developers i know this is vital. Is it any way > that django 1.0 will support multilingual models (content) ?
Hi Piotr,
Unlikely. The current development focus is to get a v1.0 out the door; primarily this means completing the newforms changeover (including newforms-admin), finishing the queryset refactor, and a handful of other small bugs and features.
If we extend this list to include every feature that each user thinks is essential, we will never get v1.0 out the door. For me (and many people I know), aggregate columns are a must-have feature; multi-lingual features are less important. Everyone has different priorities, and we can't satisfy everyone at once.
I should also point out that being in the core doesn't grant code special magic powers. I haven't looked at django-multilingual myself, but if it works now, it won't work any better by virtue of being part of the Django core. If anything, being an external project is a benefit, as those developers with a particular interest in multilingual features don't need to have access to the Django core repository in order to contribute directly to the multilingual project.
I see your point, but i just wanted to post my idea for future
features of Djangos ORM. I hope that developers will consider this
usefull and important functionality.
On 26 Sty, 04:23, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On Jan 26, 2008 6:03 AM, Piotr Majewski <g00fy....@gmail.com> wrote:
> > I would love to have the (native) feature that django-multilingual
> > gives. For me an many developers i know this is vital. Is it any way
> > that django 1.0 will support multilingual models (content) ?
> Hi Piotr,
> Unlikely. The current development focus is to get a v1.0 out the door;
> primarily this means completing the newforms changeover (including
> newforms-admin), finishing the queryset refactor, and a handful of
> other small bugs and features.
> If we extend this list to include every feature that each user thinks
> is essential, we will never get v1.0 out the door. For me (and many
> people I know), aggregate columns are a must-have feature;
> multi-lingual features are less important. Everyone has different
> priorities, and we can't satisfy everyone at once.
> I should also point out that being in the core doesn't grant code
> special magic powers. I haven't looked at django-multilingual myself,
> but if it works now, it won't work any better by virtue of being part
> of the Django core. If anything, being an external project is a
> benefit, as those developers with a particular interest in
> multilingual features don't need to have access to the Django core
> repository in order to contribute directly to the multilingual
> project.
Piotr, having django-multilingual features in the core won't make them
any better. Complex models and use-cases will still need custom/manual
solutions. It will add unneeded overhead to single-language sites and
may even break the sites that use explicit custom solutions (like
mine).
I am developing several 2 language projects with Django and I don't
use django-multilingual - I do all multilingual tasks manually - and
some code is hardcoded/optimized for my Russian/English needs - no
general-purpose solution will ever help.
> Piotr, having django-multilingual features in the core won't make them
> any better. Complex models and use-cases will still need custom/manual
> solutions. It will add unneeded overhead to single-language sites and
> may even break the sites that use explicit custom solutions (like
> mine).
> I am developing several 2 language projects with Django and I don't
> use django-multilingual - I do all multilingual tasks manually - and
> some code is hardcoded/optimized for my Russian/English needs - no
> general-purpose solution will ever help.
Models that need flexibility have `lang` and `is_translation_of`
fields. Views (or custom managers) filter the output based on `lang`
and add the link to other language if translation exists. Some models
just have two separate text fields for each language and views (or
custom managers) display the text from either one or another. Some
content appears only in one language and is hardcoded into views/
templates. My multilingual projects deal only with two languages:
Russian and English - and don't have the goal to support more. I try
to customize each language version of the site to reflect both
cultural and local/international differences - any automagic solution
will fail to do that.
On 27 янв, 15:28, maco <marko.dvor...@gmail.com> wrote:
2008/1/28 Ivan Illarionov <ivan.illario...@gmail.com>:
> Models that need flexibility have `lang` and `is_translation_of` > fields. Views (or custom managers) filter the output based on `lang` > and add the link to other language if translation exists. Some models > just have two separate text fields for each language and views (or > custom managers) display the text from either one or another. Some > content appears only in one language and is hardcoded into views/ > templates. My multilingual projects deal only with two languages: > Russian and English - and don't have the goal to support more. I try > to customize each language version of the site to reflect both > cultural and local/international differences - any automagic solution > will fail to do that.
Same here. I'm currently working on a German/English-site and also just have for each field that's supposed to be multilingual actually 2 fields and an additional property for convenience:
class Document(models.Model): title_de = models.CharField(...) title_en = models.CharField(...) ... title = property(_get_title_for_current_language)
