django: i18n und caching...
Verfasst: Dienstag 15. April 2008, 07:24
Ich wollte jetzt nicht den i18n Thread in eine anderen Richtung lenken, deswegen noch ein neuer Thread...
Ich frage mich gerade wie man i18n und caching unter einen Hut bekommen kann.
Also z.Z. gibt es in PyLucid eine cache middleware, die die gesamte Seite cached. Das ist wohl der Effektivste Weg, weil in der middleware der frühste Zeitpunkt ist, bei dem man ein Request mit einem Cache Response beantworten kann.
Da die gesamte Seite gecacht wird, kollidiert das allerdings mit i18n Denn z.B. ist der "Login" link enthalten, der übersetzt wird. z.Z. ist halt die Übersetzte Version im Cache. Welche Sprache wählt quasi der Zufall. Ist der Cache leer und fragt einer aus China nach der Seite, landet die Chinesische Version im Cache, die dann jemand aus Deutschland sehen kann, wenn er danach auf die Seite geht...
Das ist natürlich doof.
Hinzu kommt, das es später eine Möglichkeit geben soll, das CMS Seiten in verschiedenen Sprachen vorliegen können.
Was also tun? Den Cache aufblähen, nach dem Motto:
cache_key = url + cms_page_lang + client_lang
Dann haben wir bei 100 CMS Seiten in 3 verschiendenen Sprachen und djangos 47 Übersetzungen: 100*3*47 = 14100 Varianten...
Eine Möglichkeit wäre: Die django Übersetzung nur an die vorhandenen CMS Seiten Sprachen anzugleichen. Also wenn ein User die Seite in deutsch sehen will, dann wird "Login" nach deutsch übersetzt.
naja, was meint ihr?
Ich frage mich gerade wie man i18n und caching unter einen Hut bekommen kann.
Also z.Z. gibt es in PyLucid eine cache middleware, die die gesamte Seite cached. Das ist wohl der Effektivste Weg, weil in der middleware der frühste Zeitpunkt ist, bei dem man ein Request mit einem Cache Response beantworten kann.
Da die gesamte Seite gecacht wird, kollidiert das allerdings mit i18n Denn z.B. ist der "Login" link enthalten, der übersetzt wird. z.Z. ist halt die Übersetzte Version im Cache. Welche Sprache wählt quasi der Zufall. Ist der Cache leer und fragt einer aus China nach der Seite, landet die Chinesische Version im Cache, die dann jemand aus Deutschland sehen kann, wenn er danach auf die Seite geht...
Das ist natürlich doof.
Hinzu kommt, das es später eine Möglichkeit geben soll, das CMS Seiten in verschiedenen Sprachen vorliegen können.
Was also tun? Den Cache aufblähen, nach dem Motto:
cache_key = url + cms_page_lang + client_lang
Dann haben wir bei 100 CMS Seiten in 3 verschiendenen Sprachen und djangos 47 Übersetzungen: 100*3*47 = 14100 Varianten...
Eine Möglichkeit wäre: Die django Übersetzung nur an die vorhandenen CMS Seiten Sprachen anzugleichen. Also wenn ein User die Seite in deutsch sehen will, dann wird "Login" nach deutsch übersetzt.
naja, was meint ihr?