django: i18n und caching...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
jens
Moderator
Beiträge: 8481
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
mkesper
User
Beiträge: 919
Registriert: Montag 20. November 2006, 15:48
Wohnort: formerly known as mkallas
Kontaktdaten:

Mittwoch 16. April 2008, 15:41

jens hat geschrieben: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...
Im Cache landet ja nur das, was auch abgefragt wird, daher sehe ich das nicht so kritisch mit den Varianten.
jens hat geschrieben: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.
Ja, daß jemand türkischen Inhalt, aber deutsche Menüs haben will, ist irgendwie...Quark.
Antworten