Internationalization and caching not working!
I build a Dutch and English website: http://www.localpoint.nl. Traffic to the website is increasing. That is why I am looking at enabling Django caching. However, it does not seem to work! I tried different backends. The file backend for example does not store any files. I also tried memcached. That seems to be working although I am not able to check the contents of memcached itself. Is that possible? But, whenever I switch between the two languages with caching enabled the results are unpredictable. I get a Dutch page when I should get an English one and vice versa. Is there someone who has experience in setting up caching with a Django website that uses internationalization (i18n)? Thanks very much for your help. By the way these are the middleware settings I am using: # CacheMiddleware settings #CACHE_BACKEND = "locmem:///" #CACHE_BACKEND = "file:///var/www/MyDjango-cache/" CACHE_BACKEND = "memcached://127.0.0.1:11211/" CACHE_MIDDLEWARE_KEY_PREFIX = 'localpoint_' CACHE_MIDDLEWARE_SECONDS = 60 * 5 MIDDLEWARE_CLASSES = ( #"django.contrib.flatpages.middleware.FlatpageFallbackMiddleware", "django.middleware.http.ConditionalGetMiddleware", "django.middleware.common.CommonMiddleware", "django.middleware.gzip.GZipMiddleware", "django.contrib.csrf.middleware.CsrfMiddleware", #protection agains cross site scripting. "django.contrib.sessions.middleware.SessionMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "django.middleware.cache.CacheMiddleware", "django.middleware.locale.LocaleMiddleware", "django.middleware.doc.XViewMiddleware", ) But I also tried this one: # CacheMiddleware settings #CACHE_BACKEND = "locmem:///" #CACHE_BACKEND = "file:///var/www/MyDjango-cache/" CACHE_BACKEND = "memcached://127.0.0.1:11211/" CACHE_MIDDLEWARE_KEY_PREFIX = 'localpoint_' CACHE_MIDDLEWARE_SECONDS = 60 * 5 MIDDLEWARE_CLASSES = ( #"django.contrib.flatpages.middleware.FlatpageFallbackMiddleware", "django.middleware.http.ConditionalGetMiddleware", "django.middleware.common.CommonMiddleware", "django.middleware.gzip.GZipMiddleware", "django.contrib.csrf.middleware.CsrfMiddleware", #protection agains cross site scripting. "django.contrib.sessions.middleware.SessionMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "django.middleware.locale.LocaleMiddleware", "django.middleware.doc.XViewMiddleware", "django.middleware.cache.CacheMiddleware", ) Same result. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Internationalization and caching not working!
Jeremy,
Thanks for your response. But, I am using the locale middleware from
Django itself. And it automatically updates the Vary header. See:
django/trunk/django/middleware/locale.py
def process_response(self, request, response):
patch_vary_headers(response, ('Accept-Language',))
response['Content-Language'] = translation.get_language()
translation.deactivate()
return response
And when I do inspect the header response from my application it indeed
looks like this:
Vary: Accept-Language,Cookie,Accept-Encoding
However you did make me think. You suggested that the Vary header
should include Content-Language. If I look at my response header the
Content-Language header looks like: Content-Language: nl and if I
switch to English it looks like: Content-Language: en. Obviously.
Perhaps there is a bug in locale.py. Should:
patch_vary_headers(response, ('Accept-Language',))
perhaps be:
patch_vary_headers(response, ('Content-Language',))
Could it be that simple? I will check. If this is indeed the solution I
will file a bug.
Berry
On 24 dec, 04:23, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
On 12/23/06, Beegee <[EMAIL PROTECTED]> wrote:
> But, whenever I switch between the two languages with caching enabled
> the results are unpredictable. I get a Dutch page when I should get an
> English one and vice versa.The cache middleware creates it's keys based on
the initial response's
vary header.
You'll need to use vary_on_headers, presumably including
Content-Language.http://www.djangoproject.com/documentation/cache/#using-vary-headers
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Internationalization and caching not working!
Jeremy,
Thanks for your response. But, I am using the locale middleware from
Django itself. And it automatically updates the Vary header. See:
django/trunk/django/middleware/locale.py
def process_response(self, request, response):
patch_vary_headers(response, ('Accept-Language',))
response['Content-Language'] = translation.get_language()
translation.deactivate()
return response
And when I do inspect the header response from my application it indeed
looks like this:
Vary: Accept-Language,Cookie,Accept-Encoding
However you did make me think. You suggested that the Vary header
should include Content-Language. If I look at my response header the
Content-Language header looks like: Content-Language: nl and if I
switch to English it looks like: Content-Language: en. Obviously.
Perhaps there is a bug in locale.py. Should:
patch_vary_headers(response, ('Accept-Language',))
perhaps be:
patch_vary_headers(response, ('Content-Language',))
Could it be that simple? I will check. If this is indeed the solution I
will file a bug.
Berry
On 24 dec, 04:23, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
On 12/23/06, Beegee <[EMAIL PROTECTED]> wrote:
> But, whenever I switch between the two languages with caching enabled
> the results are unpredictable. I get a Dutch page when I should get an
> English one and vice versa.The cache middleware creates it's keys based on
the initial response's
vary header.
You'll need to use vary_on_headers, presumably including
Content-Language.http://www.djangoproject.com/documentation/cache/#using-vary-headers
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Internationalization and caching not working!
However you did make me think. You suggested that the Vary header
should include Content-Language. If I look at my response header the
Content-Language header looks like: Content-Language: nl and if I
switch to English it looks like: Content-Language: en. Obviously.
Perhaps there is a bug in locale.py. Should:
patch_vary_headers(response, ('Accept-Language',))
perhaps be:
patch_vary_headers(response, ('Content-Language',))
Could it be that simple? I will check. If this is indeed the solution I
will file a bug.
I made the change mentioned above. But, it simply does NOT work!
Whenever I enable global caching I can NOT switch between languages
anymore. Only one page is saved in the cache!
I enabled file based caching. And I would expect two files in the
cache. One for each language. But, what ever I do only one version of
each page is cached! The order in which the caching middleware appears
also does not seem to matter.
How do I get internationalization (i18n) and caching to work together?
Thanks. Berry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Internationalization and caching not working!
Jeremy,
Thanks for the explanation. I am using mod_python. I will check if my
browser are sending Accept-Language. But, I suspect they do. Because,
whenever caching is disabled swithing between languages works perfect.
If I change for example the language settings in my browser and make
for example Dutch my preferred language then the website
www.localpoint.nl is rendered in Dutch. And if I make English my
preferred language my website is rendered in English. So, the language
settings in my browsers (FF and IE) are correctly handled by the
Django.
But whenever I activate caching language switching is not working
anymore.
Berry
On Dec 26, 3:28 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
On 12/26/06,Beegee<[EMAIL PROTECTED]> wrote:
...
> > Perhaps there is a bug in locale.py. Should:
> > patch_vary_headers(response, ('Accept-Language',))
> > perhaps be:
> > patch_vary_headers(response, ('Content-Language',))
...
> I made the change mentioned above. But, it simply does NOT work!
> Whenever I enable global caching I can NOT switch between languages
> anymore. Only one page is saved in the cache!I apologize for mixing you up. The
vary header is "the set of
request-header fields that fully determines, while the response is
fresh, whether a cache is permitted to use the response to reply to a
subsequent request without revalidation". (rfc2616, 14.44 Vary)
Which is to say, Accept-Language is the appropriate value to place in
the Vary header, since that is the request-header field we're
interested in varying on, *not* Content-Language.
Even so, have you verified that your browsers are sending
Accept-Language as expected?
Second, are you using mod_python or wsgi? I'm asking because the
headers django.util.cache.learn_cache_key depends on are expected to
be munged into request.META on round-trip. I do see that munging
occurring in django.core.handlers.modpython, but not in
django.core.handlers.wsgi.
I haven't tested that here-- I'm not set up for trunk testing or i18n,
but if you're using wsgi, this may be your bug...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Internationalization and caching not working!
I am starting to get to understand the problem. I hope. I did the
following test.
My current middleware settings:
MIDDLEWARE_CLASSES = (
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.gzip.GZipMiddleware",
"django.middleware.cache.CacheMiddleware",
"django.middleware.locale.LocaleMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.middleware.common.CommonMiddleware",
"django.contrib.csrf.middleware.CsrfMiddleware",
"django.middleware.doc.XViewMiddleware",
"django.middleware.http.ConditionalGetMiddleware",
#"django.contrib.flatpages.middleware.FlatpageFallbackMiddleware",
)
In Firefox I have three languages enables: nl, en-us and en. I hit a
page and I get two cached files. One cache_header and one cache_page.
When I change my language setting in my browser and delete for example
the en language and hit the same page again I get a second cache_page!
Great! If I switch the remaining nl and en-us settings I get a third
cache_page. So, vary on Accept-language is working. I even get the
correct language shown on the pages. So, something is working even with
caching enabled.
I am getting closer to the problem.
I use the set_language redirect view for the user to be able to switch
between languages. This is still NOT working! From the documentation:
"The view expects to be called via the GET method, with a language
parameter set in the query string. If session support is enabled, the
view saves the language choice in the user's session. Otherwise, it
saves the language choice in a django_language cookie."
I have session enabled. So, the cache should use the vary on cookie.
Even if I do not use sessions the language choice is stored in a cookie
and thus the cache should vary on cookie.
Apparently this is not working!
Switching the order of the middelware to:
MIDDLEWARE_CLASSES = (
"django.middleware.cache.CacheMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.gzip.GZipMiddleware",
"django.middleware.locale.LocaleMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.middleware.common.CommonMiddleware",
"django.contrib.csrf.middleware.CsrfMiddleware",
"django.middleware.doc.XViewMiddleware",
"django.middleware.http.ConditionalGetMiddleware",
#"django.contrib.flatpages.middleware.FlatpageFallbackMiddleware",
)
Then the cache_header files show that the cache is also varying on
cookie. I can switch once between Dutch and English using the set
language redirect view. And I got two cache_pages for each page. But, I
can only switch once!
I am almost there. I think. But, it still is not working! Why?
On 28 dec, 11:19, "Beegee" <[EMAIL PROTECTED]> wrote:
Jeremy,
Thanks for the explanation. I am using mod_python. I will check if my
browser are sending Accept-Language. But, I suspect they do. Because,
whenever caching is disabled swithing between languages works perfect.
If I change for example the language settings in my browser and make
for example Dutch my preferred language then the websitewww.localpoint.nlis
rendered in Dutch. And if I make English my
preferred language my website is rendered in English. So, the language
settings in my browsers (FF and IE) are correctly handled by the
Django.
But whenever I activate caching language switching is not working
anymore.
Berry
On Dec 26, 3:28 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 12/26/06,Beegee<[EMAIL PROTECTED]> wrote:
> ...
> > > Perhaps there is a bug in locale.py. Should:
> > > patch_vary_headers(response, ('Accept-Language',))
> > > perhaps be:
> > > patch_vary_headers(response, ('Content-Language',))
> ...
> > I made the change mentioned above. But, it simply does NOT work!
> > Whenever I enable global caching I can NOT switch between languages
> > anymore. Only one page is saved in the cache!I apologize for mixing you up. The
vary header is "the set of
> request-header fields that fully determines, while the response is
> fresh, whether a cache is permitted to use the response to reply to a
> subsequent request without revalidation". (rfc2616, 14.44 Vary)
> Which is to say, Accept-Language is the appropriate value to place in
> the Vary header, since that is the request-header field we're
> interested in varying on, *not* Content-Language.
> Even so, have you verified that your browsers are sending
> Accept-Language as expected?
> Second, are you using mod_python or
Problem with i18n
I want my application to be i18n enabled. So, in my project directory I
ran: make-messages -l nl. Before this I created the conf/locale
directory in projectdirectory.
This all worked just fine. Compilation also worked fine.
In my settings file I have put:
LANGUAGE_CODE = "nl"
LANGUAGES = (
('en', _('English')),
('nl', _('Dutch')),
)
MIDDLEWARE_CLASSES = (
"django.middleware.sessions.SessionMiddleware",
"django.middleware.locale.LocaleMiddleware",
"django.middleware.common.CommonMiddleware",
"django.middleware.gzip.GZipMiddleware",
)
I have only mentioned the relevant parts of the settings file.
Now using Firefox 1.5 I browse to my application. But, I can not see
any translations. I have set the language I want (nl) in the
preferences of Firefox as my first language. As a test I browse to the
Django Administration site and it is in Dutch! Perfect. But, my own
application is still in English. No Dutch.
What I am missing? Does anybody have any ideas how to solve this?
Thanks.
Re: Problem with i18n
Yep. And now it works perfectly. Reading the documentation again and again I see it is actually in the documentation! You have to very carefully read the documentation. What confused me was the following part in the documentation. It is the paragraph called "How to create language files". It contains the following part: "The script [make-messages.py] should be run from one of three places: * The root django directory (not a Subversion checkout, but the one that is linked-to via $PYTHONPATH or is located somewhere on that path). * The root directory of your Django project. * The root directory of your Django app. The script runs over the entire Django source tree and pulls out all strings marked for translation. It creates (or updates) a message file in the directory conf/locale. In the de example, the file will be conf/locale/de/LC_MESSAGES/django.po." Reading this part (and also the error message from make-messages.py) made me think I had to create a conf/locale directory in my project. However, further down in the documentation in the paragraph "Using translations in your own projects" it clearly states where the code will look for language files: "* First, it looks for a locale [so NOT conf/locale!] directory in the application directory of the view that's being called. If it finds a translation for the selected language, the translation will be installed. * Next, it looks for a locale [so NOT conf/locale!] directory in the project directory. If it finds a translation, the translation will be installed. * Finally, it checks the base translation in django/conf/locale." Perhaps the paragraph "How to create language files" could be more clear about the difference of running make-messages.py in the django source or in your own project. Thanks very much for your help. Berry.
What is the right order of LocaleMiddleware and CacheMiddleware?
I have build a website in three languages and I want to use caching. I have read the documentation thouroughly. I also read the source code repository and the django newsgroups. I am very confused about the order in which to put all the Middleware classes. Does anybody know what the right order should be of the following 4 middleware classes? MIDDLEWARE_CLASSES = ( "django.middleware.sessions.SessionMiddleware", "django.middleware.cache.CacheMiddleware", "django.middleware.locale.LocaleMiddleware", "django.middleware.common.CommonMiddleware", ) Until now every order I tried does not work. When you switch to another language, the switch does not work or while browsing the site you will end up with pages in the wrong language. As soon as I switch of the CacheMiddleware everything works perfectly. Thanks, Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: What is the right order of LocaleMiddleware and CacheMiddleware?
# CacheMiddleware settings CACHE_BACKEND = "locmem:///" CACHE_MIDDLEWARE_KEY_PREFIX = 'beegee' CACHE_MIDDLEWARE_SECONDS = 60 * 5 MIDDLEWARE_CLASSES = ( "django.middleware.sessions.SessionMiddleware", "django.middleware.locale.LocaleMiddleware", "django.middleware.cache.CacheMiddleware", "django.middleware.common.CommonMiddleware", ) What ever the order of the middleware the CacheMiddleware does not seems to work correctly with the LocaleMiddleware. I keep flipping between different languages when switching between pages, while I did not push any language buttons. Also, when I switched languages it more than once does not switch at all. Does anybody have any experience in enabling cache on a multi lingual Django website? Thanks! Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
MySQL Query cache hits stay zero
Has anybody been observing the same thing? For a couple of weeks now I have a website running build with Django. I was looking for way to improve the performance. One way of improving the performance is turning on the Query Cache for MySQL. By default this is activated. It also was on my MySQL installation. However the number of Query cache hits (an indication of how well the cache is used) is always zero! And this while the number Qcache_queries_in_cache increases while I am browsing my website. So, none of the queries from django are being fetched from the MySQL Query cache! Why not? mysql> SHOW STATUS LIKE '%qcache%'; +-+--+ | Variable_name | Value| +-+--+ | Qcache_queries_in_cache | 661 | | Qcache_inserts | 474382 | | Qcache_hits | 0| | Qcache_lowmem_prunes| 0| | Qcache_not_cached | 1080657 | | Qcache_free_memory | 18609912 | | Qcache_free_blocks | 1| | Qcache_total_blocks | 1333 | +-+--+ 8 rows in set (0.00 sec) When I manually type in a query on the MySQL command line and execute it several times, the Qcache_hits indeed increases. So, the cache functionality is working. Thanks very much for your help. Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: MySQL Query cache hits stay zero
No, then it also doesn't work. When I repeat the following query:
cursor.execute('select * from wifidog_businesses limit 10')
using MySQLdb the number of Cache hits do not increase. However, the
number of Qcache_queries_in_cache also do not increase. Strange.
I did find an issue on the MySQL for Python Sourceforge website that
seems to be describing the exact same issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=1287716&group_id=22307&atid=374932
However, the issue is closed, but not because the problem was solved,
but because the problem was not described well enough. I did put a
comment at this issue describing my experience.
Berry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: MySQL Query cache hits stay zero
This is a part from the manual of MySQL: "In MySQL 4.0, the query cache is disabled within transactions (it does not return results). Beginning with MySQL 4.1.1, the query cache also works within transactions when using InnoDB tables (it uses the table version number to detect whether its contents are still current)." So, are the following statements correct? 1. Apparently all Django generated or MySQLdb generated statements are transactional. Even ordinary select statements? Because, only transactional statements are not cached. (Still, it is a bit strange because the value of Qcache_queries_in_cache does increase over time.) 2. To be able to use the query cache of MySQL when using MySQL as a backend database for Django, you need to use at least version 4.1.1. of MySQL. And you need to be using InnoDB tables. Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: MySQL Query cache hits stay zero
Currently I am using MySQL version 4.0.24. Looking at all the answers the best thing to do is to try MySQL v5. I will do some testing over the weekend and post my experiences. Thanks very much for your help. Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: MySQL Query cache hits stay zero
My test results. I installed mysql-standard-5.0.20-linux-x86_64-glibc23. Created a completely new database and restored a backup from my 'old' django database into the newly created MySql 5 instance. Restarted Apache and everthing was up and running again. Great! I checked with SHOW variables LIKE '%cache\_%'; the current settings. query_cache_size was zero. So, I set it to: set global query_cache_size = 2000; Then I browsed my website and watched this query: SHOW GLOBAL STATUS LIKE 'Qcache\_%'; And now the Qcache_hits does increase. Great! mysql> SHOW GLOBAL STATUS LIKE 'Qcache\_%'; +-+--+ | Variable_name | Value| +-+--+ | Qcache_free_blocks | 1| | Qcache_free_memory | 18626072 | | Qcache_hits | 5774 | | Qcache_inserts | 679 | | Qcache_lowmem_prunes| 0| | Qcache_not_cached | 7| | Qcache_queries_in_cache | 641 | | Qcache_total_blocks | 1293 | +-+--+ 8 rows in set (0.00 sec) So, it seems that the best thing to do to make use of the query cache of MySQL is to use MySQL 5.0. I want to thank everybody for helping me. Berry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
