had to update django down to revision 11938 to make it working.

I'm sorry but this will have to wait unless someone supplies a patch. I'm not
tracking django trunk, and already got my handful with other django-multilingual stuff.

If someone is willing into it though, I'll help with applying the patch.

Hello,

I tried to work on it, but the Query model changed a lot between this two versions
and there is a huge work to do in this area.

You are maybe not following the trunk, but I can tell you that this problem should be
your first priority if you want django-multilingual still be use with Django 1.2 

Ok the change was made between revision 11951 and 11952:

This should help:
http://code.djangoproject.com/changeset?old_path=django%2Ftrunk%2Fdjango%2Fdb%2Fmodels%2Fsql&old=11951&new_path=django%2Ftrunk%2Fdjango%2Fdb%2Fmodels%2Fsql&new=12265

One thing to note that compilers are backend dependent and there should be one per 
backend. Compiler is quite tightly coupled with query. So it won't be trivial change.

Ok, I check everything and the patch works actualy. So I think, we need to create two
branch one for Django 1.1 and another for Django 1.2

I patched it.

multilingual-20100123.patch 5.7 KB   View   Download

Error: cannot import name MultilingualSQLCompiler
(SVN Django, SVN Multilingual, Python 2.5)

At least current patch (even it's missing compiler code completely) abuses concept of
SQLCompiler. SQLCompiler is a database backend dependent and it is only meant to be
used when creating a new database backend.

redetin, thank you for your feedback, I am completly open to improve it. Do you see
any idea? Can you help?

The thing is that if somebody wants another backends, he can create it and improve
the get_compiler function to select the right one.

Btw I fixed your error symmetron.ru

multilingual-20100126.patch 5.8 KB   View   Download

Patch is still missing actual compiler (did you forgot to do svn add ?)

I think with 1.2 it shouldn't go deeper than queryset level. One problem is that
current approach is quite invasive and might give lot of troubles - like how it is
going to work with multilingual geodjango models? Or does it work with select_related()?

+1 Error: No module named compiler

Now Beta 1 is out this should really become a priority to be honest. Django 1.2 brings 
a lot of improvements and not being able to switch due to multilingual being 
incompatible sucks.

I attempted some patching myself but really the author of this should know best how to 
make it work since he has the best knowledge of the code base.

My patch worked but now there is another bug with a templatetag.

@hubscher.remy, your patch is missing the compiler.py file you import (from 
multilingual.compiler import MultilingualSQLCompiler). Could you please upload that 
file?

Really I didn't noticed that actually. I am so sorry !

compiler.py 2.1 KB   View   Download

query.py 24.6 KB   View   Download

thank you so much for this patch! gonna test it right away.

@hubscher.remy, your patch seems to throw no errors but not work properly. If I loop 
over all my objects with a translation in them I get all languages back instead of 
just the current one. For example if I have two objects and 9 languages installed I 
get 18 results instead of 2. I'm not quite sure why that is but I thought since you 
are more familiar with the code you might have a look at it.

fixed that issue now by using .distinct(). Gotta do some admin hacks and I think I got 
this 1.2 ready :D

Nice job, can you send a patch ?

Here's what I use...

NOTE: A lot of stuff (especially in admin) are dirty hacks to get it to work with our 
codebase which used a personal branch of an old django-multilingual version. The 
point of my patch was to get our project to work with django 1.2 and multilingual, 
not to do this in a nice or good way. Also the template tag fix is VERY hacky.

I'll probably have to spend at least one more day on this to get it to work as we 
need it to work (for example the default multilingual way to display stuff in admin 
is absolutely not acceptable for our clients).

If you're interested in further helping with this process of porting multilingual to 
1.2 please contact me (irc.freenode.net/#django-cms, I'm ojii on there).

patch.diff 15.8 KB   View   Download

@OjiiDotCh: does your patch address the NotImplementedError exceptions being 
thrown by values() and values_list() in MultilingualModelQuerySet? Would delegating the 
call to the parent class work now, as it was before r187? 

This would be covered by  Issue 95 . I offered a patch there, not sure if this'd be relevant 
here, though.

no it does not but thanks for mentioning it, all my patch did is it got the apps we 
use which depend on multilingual to work in 1.2, or at least survive some minimal 
testing.

found another issue when using count on a MLQS, new patch attached.

patch.diff 11.9 KB   View   Download

all the changes I made to multilingual went a bit far, so I just forked it and I'm 
going to maintain a django 1.2 branch (with some other improvements such as improved 
admin UI) on http://github.com/ojii/django-multilingual-ng

OjiiDotCh, so is it new official branch or it's just your own project, wich based on 
official branch?
And once more question:
"Note that since multilingual-ng does not use language_id's anymore"
Only your project "multilingual-ng" does not use language_id's anymore, or all 
future of official multilingual project won't use language_id's anymore?

Sorry for my bad English^)

Sorry for the confusion vaxxxa. It's not an "official" branch in the sense that the 
creators of django-multilingual had anything to do with it. I just took django-
multilingual trunk, applied the patch I worked out together with a lot of help from 
hubscher remy and added some extras, like a better admin.

The deprecation of languages_id's is something which is in MY version (multilingual-
ng) and not in the 'normal' multilingual (the one here on google code). I'd assume 
django-multilingual will continue to use language_id's, one of the big reasons I 
actually made the multilingual-ng project. 

OjiiDotCh, multilingual flatpages doesn't work in your version.
I can't edit title and content and got strange error.
http://img402.imageshack.us/img402/5186/admd.jpg

I didn't touch flatpages or tested it since i have no use for it. that 'strange error' 
is due to a hidden field not being filled in. did you at least 'convert' it to the new 
multilingual (using manage.py mlng_convert)?

By the way you should report this on the issue tracker of multilinugual-ng at 
http://github.com/ojii/django-multilingual-ng/issues

OjiiDotCh, hubscher.remy, sorry for question in this topic, but actually:
if I used django-multilingual and want to try django-multilingual-ng:
1) if I haven't any data in database - I must just uninstall django-multilingual and 
install django-multilingual-ng. "syncdb" and everything wiil be worked.
2) if I have some data in database - migration from django-multilingual to django-
multilingual-ng would be not easy.

yeah?

Any update on this? I try last trunk and still get this error.

Actually you have to use multilingual-hg. For migration, you can change the language_id with your language code (for instance, I change 1 with fr)

django-multilingual-ng is a good replacement for django-multilingual I heartily recommend. It is really easy to drop it in as a replacement for the latter. The only issue I had was with a few flatpages that didn't migrate successfully, otherwise it is flawless. Great piece of software!