Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't click language files from /rosetta/ in non chrome browser on osx. #51

Closed
ulchm opened this issue Oct 3, 2012 · 29 comments
Closed

Comments

@ulchm
Copy link

ulchm commented Oct 3, 2012

On the main listing page for the language files I can' click on a file to go to the next page. It just reloads the current page over and over again, I can make it go by repeatedly and rapidly clicking the link.

Chrome doesn't appear to have this issue but firefox and safari both do on OSX 10.8.

THe link appears to go to http://<my_domain>.com/rosetta/select/fr/0/ however clicking it just reloads /rosetta/.

Have I included URLs improperly somewhere?

@ulchm
Copy link
Author

ulchm commented Oct 3, 2012

Update:

After I said this I started having hte same issue in chrome, leading me to believe it's some sort of misconfiguration with the URLS. I also noticed that after I do get the link to work the url is still just /rosetta/ is that normal behaviour?

@JimmyVT
Copy link

JimmyVT commented Nov 6, 2012

I'm using python2.7, django1.4 and developing in OSX 10.6 and have the exact same issue. Has anybody found a workaround this?

@mbi
Copy link
Owner

mbi commented Nov 6, 2012

Hi.

First off, it's normal that the url changes back to /rosetta/ after you've selected a language, that's normal behaviour. I've just tried reproducing this issue with Firefox and Safari, but both let me edit my translations as expected.

I wonder if this could be a server-side cache issue… could both of you please be a little more specific on how you're serving your Django? I.e. is this on the dev server, or an actual "real" server (nginx, apache)?

Also, is django.middleware.cache.UpdateCacheMiddleware in your settings.MIDDLEWARE_CLASSES? And if yes, what is the value of settings.CACHE_MIDDLEWARE_ANONYMOUS_ONLY?

Thanks for your help debugging this.

@JimmyVT
Copy link

JimmyVT commented Nov 6, 2012

Hi,

I'm on the dev server and 'django.middleware.cache.UpdateCacheMiddleware' is not in my settings.MIDDLEWARE_CLASSES.

I've only added ROSETTA_STORAGE_CLASS = 'rosetta.storage.CacheRosettaStorage' to my settings.py file.

On a side note, what I ended up doing (to move forward with my translations) was to install the previous django-rosetta version ( 0.6.6 ) and things work as expected.

@mbi
Copy link
Owner

mbi commented Nov 6, 2012

Alright, even with ROSETTA_STORAGE_CLASS = 'rosetta.storage.CacheRosettaStorage' I can't really reproduce this. What is your CACHE backed, pray tell?

@JimmyVT
Copy link

JimmyVT commented Nov 6, 2012

Hmm... I've set my cache as follows:

CACHES = {
'default': {
'BACKEND':
'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}

is that what you mean?

@mbarkhau
Copy link

I am also having this issue and do not have any kind of caching configured.

@kitsunde
Copy link
Contributor

kitsunde commented Dec 3, 2012

Me too. It seems like the user needs to double click the language to get to it for reasons beyond me.

@mbi
Copy link
Owner

mbi commented Jan 9, 2013

Darn, I'm really struggling trying to reproduce this bug.

I'm testing with:

ROSETTA_STORAGE_CLASS = 'rosetta.storage.CacheRosettaStorage'

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11222',
        'KEY_PREFIX': 'ROSETTA_TEST'
    }
}

Rosetta 0.6.8, Django (1.3.5, 1.4.2, 1.5c1) … and all my tests pass.

EDIT: Chrome, Firefox, Safari on OS X 10.8.2

mbi added a commit that referenced this issue Jan 9, 2013
@kitsunde
Copy link
Contributor

kitsunde commented Jan 9, 2013

I hadn't set CACHE when I was testing this. Also I was running two different (somewhat recent) versions of nginx (dev and prod).

@mbi
Copy link
Owner

mbi commented Jan 9, 2013

@CelC no cache set up defaults to LocMem AFAIK, so it should work… I'm writing additional tests, I'd love to get you to test the latest HEAD (in a few minutes)

@kitsunde
Copy link
Contributor

kitsunde commented Jan 9, 2013

Also my client was reporting this issue on Windows, I was just confirming it on OSX. I probably can't test anything until tomorrow.

@mbi
Copy link
Owner

mbi commented Jan 9, 2013

Thanks, I really appreciate your help. I just committed bb0c774. You will probably get an ImproperlyConfigured error, it'll be interesting to see which specific test fails.

@mbi
Copy link
Owner

mbi commented Jan 15, 2013

Anyone willing to re-reproduce this with the latest commits? I'd really like to fix this issue before Django 1.5 lands to release a compatible point release. Cheers.

@ludovic-gasc
Copy link

Hi,

if I add rosetta on a project where CACHES isn't defined in the settings.py, I've also this bug.
If I add in my settings.py: ROSETTA_STORAGE_CLASS = 'rosetta.storage.SessionRosettaStorage', now it works has excepted.

@mbi: I've installed rosetta from github, I've no errors in the Gunicorn logs.

Regards.

@mbi
Copy link
Owner

mbi commented Jan 22, 2013

Thanks @GMLudo.

I think I see where your particular problem lies: gunicorn spawns multiple processes, and each process has its own LocMem cache instance (the default backend if you define none) so this would make sense: one process writes and another one reads the content but finds none.

Is anyone here experiencing this using the stock (single-process) runserver development server?

@thongly
Copy link

thongly commented Feb 20, 2013

I WAS also getting this on Ubuntu 12.04 on both Chrome and Firefox. I am using Rosetta 0.6.8 with memcache on a production server.

HOWEVER... As with GMLudo, after excplicitly declaring the ROSETTA_STORAGE_CLASS...

ROSETTA_STORAGE_CLASS = 'rosetta.storage.SessionRosettaStorage'

and then restarting, it is fine. This leads to me to believe it is how the default is being treated when nothing is explicitly declared.

@mrooney
Copy link
Contributor

mrooney commented Feb 25, 2013

I ran into this as well, until I upgraded to the latest HEAD which raised an ImproperlyConfigured because I had specified the wrong CACHES['default']['LOCATION']. Thanks for adding that!

@Glideh
Copy link

Glideh commented Dec 23, 2013

I confirm I can reproduce the issue in my mod_wsgi prod server but not with the default Django dev one.
With ROSETTA_STORAGE_CLASS = 'rosetta.storage.CacheRosettaStorage' or not

@Glideh
Copy link

Glideh commented Dec 23, 2013

Fixed with

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
        'KEY_PREFIX': 'ROSETTA_TEST'
    }
}

@mbi
Copy link
Owner

mbi commented Dec 23, 2013

@Glideh thanks, what was your CACHES before the fix?

@Glideh
Copy link

Glideh commented Dec 23, 2013

None defined

@mbi
Copy link
Owner

mbi commented Dec 23, 2013

Alright, thanks everyone. Proper CACHES is needed, as clearly stated in the readme.

@mbi mbi closed this as completed Dec 23, 2013
@gabejackson
Copy link

This is not CLEARLY stated in the README.

@mbi
Copy link
Owner

mbi commented Dec 29, 2013

@gabejackson it says "if you run Django with gunincorn, mod-wsgi or other multi-process environment, the Django-default CACHES LocMemCache backend won't suffice: use memcache instead, or you will run into issues."

Now, I'm not a native speaker of English, so any suggestion on how to rephrase that sentence (or any other) to make it clearer, would be highly appreciated.

@gabejackson
Copy link

The phrasing is not so much an issue, it is just located in the wrong place. I would clearly put this under the section "Installation" and also make a note that in such an environment memcached is required and the following setting must be used:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

@aasensiog
Copy link

As my colleague @gabejackson says in the comment above:

#59 (comment)

@crazyzubr
Copy link

I have this problem. I propose to add the appropriate observation and problem solving in the installation instructions.

@iMakedonsky
Copy link

I support @crazyzubr with this suggestion. It should be mentioned in installation readme. @mbi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests