Seite 1 von 1

cherrypy/cheetah + internationalisierung

Verfasst: Donnerstag 26. März 2009, 08:00
von Bitzkit
Hi,

wollte mein projekt, das ich in cherrypy und cheetah verwirkliche, internationalisieren. es soll zuerst in englisch und deutsch, später evtl. auch in anderen Sprachen verfügbar sein.

Kann mir da jemand ein paar tipps geben und evtl. einen link mit einem guten tutorial ?

Verfasst: Donnerstag 26. März 2009, 10:07
von Leonidas
Babel bietet sich für sowas an.

Re: cherrypy/cheetah + internationalisierung

Verfasst: Donnerstag 9. April 2009, 13:58
von gerold
Bitzkit hat geschrieben:wollte mein projekt, das ich in cherrypy und cheetah verwirkliche, internationalisieren. es soll zuerst in englisch und deutsch, später evtl. auch in anderen Sprachen verfügbar sein.
Hallo Bitzkit!

So wie es aussieht, werde ich in den nächsten Wochen an so einem Projekt arbeiten. Ich teile dir dann hier mit, welche Struktur ich dafür verwenden werde.

Ein paar Punkte weiß ich schon, da ich schon ein paar Nächte darüber geschlafen habe. Die gewünschte Sprache wird auf keinen Fall über den Querystring, sondern über den Pfad übergeben.

Standardsprache --> http://halvar.at/
Englisch --> http://halvar.at/en/
Deutsch --> http://halvar.at/de/

Übermittelt der Browser kein Cookie für die Sprache, dann wird die Sprache des Browsers verwendet. Irgendwo (wahscheinlich rechts oben) wird es auf der Website eine Sprachauswahl geben. Diese setzt ein Cookie und leitet sofort zur neuen Sprachseite weiter.

Auf dem Server wird es wahrscheinlich so eine Vorlagenstruktur geben:

Code: Alles auswählen

/ordner1/de.index.tmpl
/ordner1/en.index.tmpl
Da sich in den Cheetah-Vorlagen hauptsächlich Text (reStructuredText) befindet, halte ich es für besser, gleich den ganzen Text zu übersetzen und nicht mehrere Textteile irgendwo zusammenzuklauben.

Die Hauptvorlage wird aus mehreren Vorlagen zusammengesetzt, die für sich übersetzt werden.

Das ist zumindest mal der vorübergehende Plan. Ob er so funktioniert, weiß ich wenn das Projekt fertig ist.

mfg
Gerold
:-)

Verfasst: Donnerstag 9. April 2009, 18:33
von gerold

Verfasst: Samstag 11. April 2009, 09:32
von sma
Laut http://www.audettemedia.com/blog/seo-gu ... chitecture, was mir zufällig vor einigen Tagen über den Weg gelaufen ist, ist die Sprache hinter dem Hostnamen in der URL zu haben, übrigens die schlechteste Alternative. Besser wären aus SEO-Überlegungen Subdomainen oder eigene TLDs. Ganz schlecht es ist, unter ein und der selben URL abhängig von einem Cookie unterschiedliche Sprachen zu benutzen.

Stefan

Verfasst: Samstag 11. April 2009, 10:10
von gerold
sma hat geschrieben:die Sprache hinter dem Hostnamen in der URL zu haben, übrigens die schlechteste Alternative
Hallo Stefan!

Warum so abwertend? Natürlich ist das nicht so ideal wie eine eigene TLD je Sprache. Aber die "schlechteste" Alternative ist es sicher nicht. Cookies und Browser-Spracheinstellung kann man komplett ausschließen. So etwas ist nicht von Suchmaschinen indizierbar. Schließe die Möglichkeit verschiedener Domänen oder Subdomänen aus -- was bleibt dann noch an sinnvollen Alternativen übrig?

mfg
Gerold
:-)

Verfasst: Samstag 11. April 2009, 10:17
von sma
Der Autor des von mir zitierten Artikels nennt es nun mal die schlechteste von drei aufgeführten Alternativen bzgl. SEO. Nur das wollte ich zusammenfassen. Vielleicht ein bisschen zu knapp.

Es ist nicht die absolut schlechteste Alternative oder ein persönlicher Fehler, es so zu machen. Es ist in jedem Fall noch besser als, wie ich auch schrieb, bei gleicher URL die Sprache abhängig von einem Cookie (oder einem URL-Parameter) unterschiedliche Seiten anzuzeigen. Somit mag es die schlechteste aber dennoch die einzig praktikable Alternative sein.

Stefan

Verfasst: Samstag 11. April 2009, 13:27
von Leonidas
sma hat geschrieben:Es ist in jedem Fall noch besser als, wie ich auch schrieb, bei gleicher URL die Sprache abhängig von einem Cookie (oder einem URL-Parameter) unterschiedliche Seiten anzuzeigen.
So mache ich das. Über den Language-Accept-Header (+ Cookie wenn man dennoch die Sprache ändrn will). Pfft. Ist von der Usability IMHO am besten - keine Fähnchenklickerei, eine kanonische URL und brauchbare Sprachauswahl.

Verfasst: Montag 13. April 2009, 18:10
von sma
Leider verletzt dieses Vorgehen das REST-Prinzip. URLs sollen ja auch (unveränderliche) Ressourcen verweisen. Zusätzlich noch HTTP-Header und/oder Cookies mit einzubeziehen, macht die URLs nicht mehr eindeutig. Und das mögen Suchmaschinen gar nicht. Ob das egal ist oder nicht, hängt sicherlich vom Einzelfall ab. Ich würde dieses Vorgehen nicht empfehlen.

Stefan

Re: cherrypy/cheetah + internationalisierung

Verfasst: Donnerstag 16. April 2009, 18:10
von gerold
gerold hat geschrieben:So wie es aussieht, werde ich in den nächsten Wochen an so einem Projekt arbeiten. Ich teile dir dann hier mit, welche Struktur ich dafür verwenden werde.
Hallo Bitzkit!

Das angekündigte Projekt werde ich erst ab Mai entwickeln. Einen ersten Erfahrungsbericht kann ich also frühestens Mitte Mai schreiben.

mfg
Gerold
:-)

Verfasst: Sonntag 19. April 2009, 08:15
von Leonidas
sma hat geschrieben:Leider verletzt dieses Vorgehen das REST-Prinzip. URLs sollen ja auch (unveränderliche) Ressourcen verweisen. Zusätzlich noch HTTP-Header und/oder Cookies mit einzubeziehen, macht die URLs nicht mehr eindeutig.
Also würdest du sagen, dass wenn man auf einen Accept-Encoding-Header in dem gzip akzeptiert wird, auch gzip schickt verletzt das REST? Ich finde ja dass gerade das auswerten der Header die genau dafür gedacht sind eine nützliche Sache sind. Zudem die Header ja auch in der Regel auf die entsprechende Sprache eingestellt sind.

Verfasst: Sonntag 19. April 2009, 08:45
von sma
Nein. Das Encoding gzip ist ja eine Sache des Transports und beeinflusst die Ressource selbst nicht. Die Sprache ist etwas anders. Das diese als Header mit übermittelt wird, war mal gut gemeint, aber Suchmaschinen und der Wunsch, es diesen möglichst einfach zu machen, damit man einen guten Platz in der Ergebnisliste bekommt, haben dieses Feature obsolet gemacht.

Stefan

Verfasst: Sonntag 19. April 2009, 08:52
von Leonidas
Suchmaschinen bekommen halt die englische Version.