I18n seems not to work with mod_wsgi

[oyvind....@gmail.com]

I have a project running on django trunk using mod_wsgi in dev and
mod_python in production.

In production translation gives the expected results, in my own code
and in the admin.

Dev is set up exactly the same way, the only difference is that it is
running mod_wsgi, but no strings are translated at all.

Is this a real problem or is something wrong with my setup?

http://code.djangoproject.com/ticket/5623

[Graham Dumpleton]

You are going to have to provide more information.

Stating versions of mod_python/mod_wsgi and the configurations/script
files used would be a start. Some example code of what triggers the
problem and any relevant Django configuration, plus, exactly which
version of Django or revision number from Subversion checkout would
would also help.

Graham

On Sep 27, 10:44 pm, "oyvind.salt...@gmail.com"

[oyvind....@gmail.com]

Django revision: 6426
Mod_wsgi revision: Revision: 489
Mod_python 3.2.7

To test just set up the admin interface and see if it is translated or
not.

----------

startup script

#!/usr/local/bin/python
import sys, os

paths = [
'/home/hvalsluken/code']

if paths not in sys.path:
for path in paths:
sys.path.insert(0, path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'hvalsluken.settings'

from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandler()

--------

settings

INSTALLED_APPS = ['emmet.conf', 'emmet.emmetbase', 'emmet.emmetpages',
'emmet.emmetcontact', 'emmet.emmettextileeditor', 'emmet.emmetimages',
'emmet.emmetregistration', 'emmet.emmetgallery',
'emmet.emmetfilearchive', 'emmet.emmetnews', 'emmet.emmetprofile',
'tagging', 'django.contrib.auth', 'django.contrib.contenttypes',
'django.contrib.sessions', 'django.contrib.sites',
'django.contrib.humanize', 'django.contrib.admin']
LANGUAGE_CODE = 'no'
MIDDLEWARE_CLASSES = ('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware')

---
vhost

<VirtualHost *:80>
ServerAdmin webm...@mainframe2.cylon.no
ServerName hvalsluken.cylon.no
ErrorLog /var/log/hvalsluken.cylon.no-error.log
CustomLog /var/log/hvalsluken.cylon.no-access.log common
WSGIDaemonProcess hvalsluken user=hvalsluken group=www processes=2
threads=25 maximum-requests=500
WSGIScriptAlias / /home/hvalsluken/code/hvalsluken/hvalsluken.wsgi

<Location "/">
WSGIProcessGroup hvalsluken
WSGIApplicationGroup %{GLOBAL}
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all

</Location>

---

On Sep 28, 1:54 am, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:

[oyvind....@gmail.com]

Updated mod_wsgi to revision 561

No change

On Sep 28, 10:25 am, "oyvind.salt...@gmail.com"

> ServerAdmin webmas...@mainframe2.cylon.no

[Ramiro Morales]

On 9/28/07, oyvind....@gmail.com <oyvind....@gmail.com> wrote:
>
> Updated mod_wsgi to revision 561
>
> No change
>
> On Sep 28, 10:25 am, "oyvind.salt...@gmail.com"
> <oyvind.salt...@gmail.com> wrote:
> > Django revision: 6426
> > Mod_wsgi revision: Revision: 489
> > Mod_python 3.2.7
> >
> > To test just set up the admin interface and see if it is translated or
> > not.
> >

It works here:

Windows XP

[Fri Sep 28 09:15:38 2007] [notice] Apache/2.2.4 (Win32)
mod_auth_sspi/1.0.4 mod_wsgi/1.0 Python/2.4.4 configured -- resuming
normal operations

mod_wsgi is bibary downloaded from
http://adal.chiriliuc.com/mod_wsgi/revision_467-1.0/mod_wsgi_py24_apache22/
running on embedded mode.

Django is SVN r6431, setup based on
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

Regards,

--
Ramiro Morales

[oyvind....@gmail.com]

I will try apache 2.2 I am currentry running 2.0.58 on freebsd 6.1

On Sep 28, 2:20 pm, "Ramiro Morales" <cra...@gmail.com> wrote:

> On 9/28/07, oyvind.salt...@gmail.com <oyvind.salt...@gmail.com> wrote:
>
>
>
> > Updated mod_wsgi to revision 561
>
> > No change
>
> > On Sep 28, 10:25 am, "oyvind.salt...@gmail.com"
> > <oyvind.salt...@gmail.com> wrote:
> > > Django revision: 6426
> > > Mod_wsgi revision: Revision: 489
> > > Mod_python 3.2.7
>
> > > To test just set up the admin interface and see if it is translated or
> > > not.
>
> It works here:
>
> Windows XP
>
> [Fri Sep 28 09:15:38 2007] [notice] Apache/2.2.4 (Win32)
> mod_auth_sspi/1.0.4 mod_wsgi/1.0 Python/2.4.4 configured -- resuming
> normal operations
>

> mod_wsgi is bibary downloaded fromhttp://adal.chiriliuc.com/mod_wsgi/revision_467-1.0/mod_wsgi_py24_apa...
> running on embedded mode.
>
> Django is SVN r6431, setup based onhttp://code.google.com/p/modwsgi/wiki/IntegrationWithDjangohttp://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
>
> Regards,
>
> --
> Ramiro Morales

[oyvind....@gmail.com]

Still the same using Apache/2.2.2 and mod_wsgi 1.0

On Sep 28, 2:37 pm, "oyvind.salt...@gmail.com"

> > Django is SVN r6431, setup based onhttp://code.google.com/p/modwsgi/wiki/IntegrationWithDjangohttp://cod...
>
> > Regards,
>
> > --
> > Ramiro Morales

[Graham Dumpleton]

What does your mod_python Apache configuration look like?

Only difference at this point is that mod_wsgi hosted app would run as
distinct user whereas mod_python would run it as Apache user.

Need to see how you set PythonPath in mod_python configuration.

Also, I am ignorant of a lot of what Django does, so what is the
specific Django code construct that you are using where you expect
language selection to be adhered to?

Graham

On Sep 28, 6:25 pm, "oyvind.salt...@gmail.com"
<oyvind.salt...@gmail.com> wrote:
> Django revision: 6426Mod_wsgirevision: Revision: 489

> ServerAdmin webmas...@mainframe2.cylon.no

> ServerName hvalsluken.cylon.no
> ErrorLog /var/log/hvalsluken.cylon.no-error.log
> CustomLog /var/log/hvalsluken.cylon.no-access.log common
> WSGIDaemonProcess hvalsluken user=hvalsluken group=www processes=2
> threads=25 maximum-requests=500
> WSGIScriptAlias / /home/hvalsluken/code/hvalsluken/hvalsluken.wsgi
>
> <Location "/">
> WSGIProcessGroup hvalsluken
> WSGIApplicationGroup %{GLOBAL}
> Options Indexes FollowSymLinks
> AllowOverride None
> Order allow,deny
> Allow from all
>
> </Location>
>
> ---
>
> On Sep 28, 1:54 am, Graham Dumpleton <Graham.Dumple...@gmail.com>
> wrote:
>
> > You are going to have to provide more information.
>

> > Stating versions of mod_python/mod_wsgiand the configurations/script

> > files used would be a start. Some example code of what triggers the
> > problem and any relevant Django configuration, plus, exactly which
> > version of Django or revision number from Subversion checkout would
> > would also help.
>
> > Graham
>
> > On Sep 27, 10:44 pm, "oyvind.salt...@gmail.com"
>
> > <oyvind.salt...@gmail.com> wrote:

> > > I have a project running on django trunk usingmod_wsgiin dev and

> > > mod_python in production.
>
> > > In production translation gives the expected results, in my own code
> > > and in the admin.
>
> > > Dev is set up exactly the same way, the only difference is that it is

> > > runningmod_wsgi, but no strings are translated at all.

[oyvind....@gmail.com]

Found it, LocaleMiddleware is having some issues on mod_wsgi, i'll try
figuring out why.

On Sep 30, 1:55 am, Graham Dumpleton <Graham.Dumple...@gmail.com>

[oyvind....@gmail.com]

Doh, it was not mod_wsgi, or localemiddleware, it was the
set_language_view() that after rev 6177 requires a post request

On Sep 30, 4:29 am, "oyvind.salt...@gmail.com"

[Sandro Dentella]

On Sat, Sep 29, 2007 at 08:01:12PM -0700, oyvind....@gmail.com wrote:
>
> Doh, it was not mod_wsgi, or localemiddleware, it was the
> set_language_view() that after rev 6177 requires a post request

I see in the Backwards-incompatible changes says:

The old behaviour meant that state (the locale used to display the site)
could be changed by a GET request, which is against the HTTP specification's
recommendations.

I'm no expert of these specifications and would like to better
understand. Firstly I'd appreciate a link to relevant part, secondly,
reading the follow-up in the backward incompatible changes is:

This means you can no longer use a link to access the view, but must use a
form submission of some kind (e.g. a button).

Isn't this just making it (a little bit) more difficult to obtain the same
thing? My (admittedly ignorant) point of view was simply that modification of
data should be done via a POST not just the state.

If I implemented traslations with different URLs (mysite/en|it/...) if would
be ok to use GET but not if I use sessions?

sorry if this becomes a little bit OT...

sandro
*:-)

[Jacob Kaplan-Moss]

On 10/1/07, Sandro Dentella <san...@e-den.it> wrote:
> I'm no expert of these specifications and would like to better
> understand. Firstly I'd appreciate a link to relevant part, secondly,
> reading the follow-up in the backward incompatible changes is:

It's section 9.1 of RFC 2616, where "safe" and "idempotent" methods
are discussed: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.
Specifically, note that "GET and HEAD methods SHOULD NOT have the
significance of taking an action other than retrieval" -- changing the
users locale is certainly "an action other than retrieval".

Be sure to read the rest of that section, as well as the definitions
of GET and POST in sections 9.3 and 9.5.

Jacob