cherrypy/cheetah + internationalisierung

[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 ?

[Leonidas]

Babel bietet sich für sowas an.

[gerold]

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

[gerold]

Hallo!

In der Zip-Datei ist das, was ich im Moment habe.

http://halvar.at/krimskrams3/cherrypy_c ... en_v01.zip

Die Möglichen URLs sind:
- http://localhost:8080/
- http://localhost:8080/de/
- http://localhost:8080/en/
- http://localhost:8080/de/index.tmpl
- http://localhost:8080/en/index.tmpl
- http://localhost:8080/de/de.index.tmpl
- http://localhost:8080/en/en.index.tmpl

- http://localhost:8080/de/hallowelt/
- http://localhost:8080/de/hallowelt/index.tmpl
- http://localhost:8080/de/hallowelt/de.index.tmpl
- http://localhost:8080/de/hallowelt/en.index.tmpl
- http://localhost:8080/en/hallowelt/
- http://localhost:8080/en/hallowelt/index.tmpl
- http://localhost:8080/en/hallowelt/en.index.tmpl
- http://localhost:8080/en/hallowelt/de.index.tmpl

Man muss ja nicht jede Möglichkeit ausnutzen oder verbieten.

mfg
Gerold

[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

[gerold]

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

[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

[Leonidas]

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.

[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

[gerold]

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

[Leonidas]

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.

[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

[Leonidas]

Suchmaschinen bekommen halt die englische Version.