This is embarrasing... I edited trans_real.py as you suggested, and went to test. Seemed to output the right lang. So I created a very minimalistic template that would just output a translated string so that I could easily see what lang my tests gave me. I then ran compile- messages.py again, and restarted the server. Bam!
compile-messages.py seems to have solved my problem. I have no idea why it acted up like it did (the files must have been intact seeing how I was able to translate the site using settings.LANGUAGE_CODE right?), but since setting up i18n I have not touched compile- message.py but once, and that was to create the .mo file in the first place. Thanks for your time Rajesh, ultimaly your advice helped me as I wouldn't have recompiled for quite some time otherwise. :) //Magnus On 14 Dec, 19:38, Rajesh Dhawan <[EMAIL PROTECTED]> wrote: > On Dec 14, 1:10 pm, Magnus B <[EMAIL PROTECTED]> wrote: > > > I've introduced i18n for about a week or so ago, and have updated the > > svn trunk daily. Right now I'm on 6917, but no version have worked. > > > As for the server, I'm running the internal dev-server on OSX for > > developing, and mod_python under apache for testing. Same problem on > > both. > > OK. I think tracing through trans_real.py would probably be the > quickest way to find the area of Django where it's falling back to > your settings.LANGUAGE_CODE instead of respecting the currentThread's > LANGUAGE_CODE. > > -Rajesh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
