Als begeisterter iPod-Fanboy Ich habe mich nun mal daran gemacht, meine Drupal-Website für mobile Endgeräte zu optimieren. Will sagen: Ein eigenes Theme für mobile Geräte, ein wenig Logik für die Auswahl des gewünschten Themes und ein wenig Feinschliff bei der geräteabhängigen Theme- und Block-Konfiguration.

Einen guten Leitfaden findet man im Blog von redpanda.ch, damit kommt man gut an das Ziel. Ich habe als Mobile Theme für mobile_garland entschieden, das sah IMHO auf iPod touch und Nokia E51 am besten aus. Leider hatte ich vorher noch ein paar andere Themes probiert, nur weil mich das “Garland” abgeschreckt hatte ;)

So habe ich http://m.niebegeg.net angelegt, mobile_tools und mobile_garland installiert und aktiviert, und: Fertig. Ich habe die Blöcke für mobile_garland noch ein wenig umgeschichtet und eine Vielzahl von ihnen deaktiviert, dann war schon alles erledigt.

Das war ja einfach. Und trotzdem war der Abend nach der ganzen Bastelei rum…

—

Den Screenshot habe ich interessanterweise mit http://www.testiphone.com/ und mobileSafari als Useragent im Safari aufgenommen. Besser als ein Foto ;)

Nun habe ich mich dazu entschieden, meine Fotos unter CC-Lizenz auf Flickr einzustellen und über das beeindruckende flickr.module hier auf meiner Homepage zu integrieren. Und der Link im Hauptmenü bleibt.

Was ist daran besser: Meine Homepage ist technisch wiedermal verschlankt worden und ich habe Aufgaben delegiert, mit denen ich nicht wirklich zu tun haben wollte. Meine Bilder stehen auch Anderen zur Verfügung. Und mein Bildverwaltungsprogramm lädt meine Bilder bei Bedarf auf Mausklick zu Flickr hoch. Aber das ist schon wieder eine neue Geschichte ;)

Aufgefallen ist mir Blogbuzz in einem anderen und sehr interessanten Blogbeitrag: http://mogdesign.eu/blog/21-fresh-stunning-drupal-themes/

Rostock wählte. Nun wollte ich mir — mit etwas Abstand zum Wahltag — die Sitzverteilung und eine Liste der zukünftigen Abgeordneten der Rostocker Bürgerschaft ansehen. Und fragte die Google. Auf Rostock.de nachzusehen habe ich erst gar nicht gewagt. Das Ergebnis: Ganze 3 Seiten beschäftigten sich wohl mit der Wahl und schon der dritte Link zeigte auf den Server im Rathaus, mit einem Link auf einen Beitrag mit einem Link auf das Wahlergebnis. Echt geheime Wahl eben.
Ich hätte bei meiner Suche jedenfalls ein paar Links auf Reflektionen der angetretenen Parteien auf die Wahl und ihr Ergebnis erwartet.

Wiedermal eindrucksvoll schnitt jedoch meine lokale “Lieblingsseite” http://rostock.de ab. Wer findet auf der Seite (siehe aktuellen Screenshot) die Erwähnung der “Wahl 09”? Tipp: Mit aktiviertem AdBlocker wird es einfacher!

Was ich bei der Suche aber fand war ein interessanter lokaler Blog: http://www.blog-8.de/. Der sollte unbedingt in http://www.rostock-blogs.de/ aufgenommen werden!

Die Seite http://drupal-in-rostock.org/ werde ich weiter betreiben, jedoch “eher” als Weiterleitung zu g.d.o. Als Migrationszeitraum stelle ich mir die nächsten ~2 Monate vor.

PS: ich bin gerade dabei meinen ISP zu wechseln und muss dabei all die Websites anfassen. Eine gute Gelegenheit für Richtungsentscheidungen.

PS2: Original-Post hier: http://drupal-in-rostock.org/node/34

Rostock hat seit einiger Zeit einen erneuerten Webauftritt: http://rostock.de. Das war auch bitter nötig, für den vorherigen habe ich mich als (Neu-)Rostocker geschämt¹.

Nun ist alles neu, aufmerksam wurde ich darauf via Bannerwerbung auf der FC-Hansa-Website. Ich war natürlich neugierig und zur offiziellen Visitenkarte unserer Hansestadt gleich hin gesurft. Und war ziemlich enttäuscht!

Zwischen all der Werbung ist kaum redaktioneller Anteil auszumachen. Die Seite ist unübersichtlich und in erster Linie Werbeplatz für Ostseewelle-Hitradio², Norddeutsche Neueste Nachrichten, Yachthafenresidenz und Warnowtunnel.

Die großflächigen, patchworkartig angeordneten Werbeflächen sind teilweise kaum als solche erkennbar (siehe den Block “Luxus-Immobilien” im schmalen Inhaltsbereich).

Eben dieser Inhaltsbereich (also alles außer Banner, Navigationsleiste und Werbebanner) ist recht knapp ausgefallen. Da kommen wohl auf einem “normalen” Bildschirm ~20% des sichtbaren Bereichs zusammen.

Ein Klick auf einen beliebigen Link in der Navigationsleiste bringt einen auf einen neue Seite http://rathaus.rostock.de — dabei ist Rostock doch mehr als sein Rathaus! Und http://rostock.de/ sollte kein (reines) Rathaus-Sprachrohr sein. Für die Rathaus-Seiten wird ein neues Fenster geöffnet, ich bin weg von http://rostock.de/.

Für die Suche wurde einfach Google eingebunden. Somit bin ich nach der ersten Anfrage wieder weg von der “Homepage” und im weiten Internet, denn Google bietet mir gleich jedem menge Werbelinks an, die gar nic mit Rostock zu tun haben :-/

Gebaut wrde die Seite mit dem CMS Contentpapst der Berliner Firma http://sandoba.de, die ihr CMS als Standardsoftware bezeichnen:

Contentpapst ist ein leistungsstarkes und sehr flexibles Content-Management-System (CMS) speziell für kleine und mittelständische Unternehmen, Behörden und Organisationen. Mit dem CMS Contentpapst verwalten Sie Ihre Firmen-Homepage, Ihre Vereins-Webseite etc. zukünftig komplett per Browser, ohne zusätzliche Software!

Es kostet ~300€. Dafür kommt es ohne RSS-Feed und interne Suche aus.

Ein weiterer Höhepunkt ist die Datenschutzerklärung der Seite, dort steht natürlich nicht, dass die Besucher mit Google Analytics getrackt werden.

Fazit: Ich habe immer noch keine Visitenkarte meiner Stadt im Internet. :-(

—-

¹ Wenn ich nach Infos über Rostock suchte und die Suchmaschine mir einen rostock.de-Link angeboten hatte, konnte ich ihn sicher ignorieren, weil er mit Sicherheit keine inhaltliche Relevanz für jede Suchanfrage hatte … Und das Webdesign hätte auch fast 10-jähriges Jubiläum gefeiert…

² Bei einer “unabhängigen und überparteilichen” Stadt-Visitenkarte hätte ich wenigstens ein wechselndes Banner für all die Radiostationen und Lokalzeitungen erwartet ;)

EPIC¹ ist eine hoch-frequentierte Seite:

It has over 1100 products listed and 60 service and training providers; gets about 140K+ unique visitors a month and generates about 150-200K click thrus to the sites of the listed products.

Mich freut das natürlich sehr, treffen sich dabei zwei Systeme, für die ich mich sehr begeistere!

—

¹ Für die Drupaler: EPIC ist für Eclipse so etwas wie drupalmodules.com für Drupal :)

Anmerkung: Wer es nicht kennt: Man baut einen kleinen Javascript-Codeschnipsel in die eigene Website, legt einen Google Analytics-Account an und "ab sofort" meldet die eigene Website die seitenaufrufe an den Server. der erstellt dann jede menge Metriken über das Nutzungsverhalten der Besucher. In Drupal hilft dabei google_analytics.module.

Aber all die Zeit beschlich mich ein ungutes Gefühl dabei, die Seitenaufrufe meiner Websites "ohne Not" an einen amerikanischen Datensammler zu liefern, über dessen Gier nach daten hinreichend oft berichtet wird. Während ich allerlei Infos zu den Besuchern meiner Website bekomme, erhält Google die Infos zu nahezu allen Seiten eines Benutzers (bei entsprechend großer Installationsbasis dieses Werkzeugs). Und Google kann zielgenaue Werbeprofile (und noch viel mehr) zu den Benutzern erstellen.

Auch bei Heise Online findet sich ein aufschlussreicher Artikel Datenschutzbeauftragte kritisieren Google Analytics, in dem Thilo Weichert, der Landesdatenschutzbeauftragter von Schleswig-Holstein und Leiter des Unabhängigen Landeszentrum für Datenschutz Schleswig-Holsteins (ULD) ziztiert wird, der jüngst einige Websites untersuchen lies:

Wir waren verblüfft und schockiert, wie weit Google Analytics auch in Schleswig-Holstein verbreitet ist. Renommierte Medien- und Internetunternehmen gehören zu deren Nutzern ebenso wie viele Anbieter aus der Tourismus- und der Dienstleistungsbranche; ja politische Parteien, öffentliche Stellen des Landes und Hochschulen setzen den kostenlosen, aber datenschutzwidrigen Service ein.

Nun überlegte ich, ob ich entweder auf meiner Website ausweisen sollte, dass ich Google Analytics zur Generierung von Website-Statistiken einsetze, oder die ganze Google Analytics-Datensammlung einfach deaktiviere.Ich habe mich ziemlich schnell für die letztere Alternative entschieden. Und habe beschlossen, dass ich auch kein alternatives Produkt einsetzen werde.

Auf meinen Websites surft Ihr also "meldefrei"!

Jeder Betreiber einer Website sollte deutlich sichtbar machen, wenn er Google Analytics oder ein anderes Analyse-Werkzeug einsetzt, insbesondere wenn nicht-anonymisierte Daten gespeichert oder sogar an Dritte weitergegeben werden.

PS: Weitere Infos zum Thema "Google Analytics und Datenschutz findet Ihr hier:

• http://de.wikipedia.org/wiki/Google_Analytics#Datenschutz
• http://www.akademie.de/programmierung-administration/website-administrat…
• Und eine Suche bei Yahoo

Die technische Realisierung erfolgte dann dank Drupal und dem i18n.module in  atemberaubender Geschwindigkeit. Für die 55 Seiten, 14 Views, 3 Menüs und 4 Vokabulare benötigte ich gerade mal 40 Stunden. Dabei ging natürlich die meiste Zeit auf die (ziemlich monotone) Erfassung der übersetzen Artikel drauf.

Anmerkung im Voraus: Bei der Erstellung der ursprünglischen,  deutschsprachigen Website wurden schon bei allen Beiträgen ein URL-Alias mit “de/” als Präfix erzeugt. Nun werden die englischsprachigen Versionen mit dem Präfix “en/” und sonst identischem URl-Alias erzeugt.

Ansonsten war es ein relativ einfacher Ablauf:

1. Mit Hilfe einer View wurden alle Beiträge der Website exportiert, in ein Word-Dokument eingefügt und zum Übersetzen gegeben.
2. Dann wurde das i18n.module installiert und alle “nicht-experimentellen” Module aktiviert.
3. Als nächstes habe ich alle Menüeinträge zu Beiträgen geändert, so dass sie nicht mehr auf den Node, sondern aauf den URL-Alias ohne den Sprachpräfix verweisen, z.B. von node/123 auf company/about. Außerdem habe ich die deutschen Menübeschriftungen durch englische Beschriftungen ersetzt, diese werden dann automatisch übersetzt.
4. Bei Taxonomy-Terms, sich in deutsch und englisch unterscheiden und somit die übersetzt werden müssen (z.B. Unternehmen und Company), wurden diese als German gekennzeichnet, eine englische Übersetzung erstellt. Dann wurden diese Terms noch gegenseitig als Übersetzung gekennzeichnet. Alle anderen Terms (meist Software-Technologien etc.) wurden sprachunabhängig belassen.
5. Es wurde der Translation-Block zum Umschalten zwischen den Sprachversionen einer Seite in das Seitenlayout aufgenommen.
6. In allen relevanten Views wurde ein Filter Internationalization: selection eingefügt und auf den Wert Only current language and no language gesetzt. So können die View ohne weitere Modifikation für alle Sprachen weiter verwendet werden und zeigen nur die Einträge in der jeweiligen Sprache an. Der ggf. definierte URL-Präfix “de/” wurde in allen Views entfernt.
7. Der nächste Schritt war in der Datenbank (phpmyadmin) leichter zu erledigen als mit Drupal-Mitteln: In der Tabelle {i18n_nodes} wurden Einträge für alle vorhandenen Beiträge (Nodes) nach folgendem Muster generiert:

   INSERT INTO `i18n_node` (`nid`, `trid`, `language`, `status`)<br />VALUES (50, 16, 'de', 1);

   So wurden diese Beiträge als deutsche Originalbeiträge (language=‘de’, status=1) markiert. Alternativ müsste man jeden Beitrag in Drupal  editieren und diese Werte im Formular setzen.
8. Nun wurden alle englischen Beiträge erfasst. Nach dem Speichern des Beitrags wurden die deutsche und englische Version des Beitrags im Tab Translation (neben View und Edit im Formularkopf) einander zugeordnet.
9. Im Theme (selbstgebaut) wurden einige Textausgaben (in page.tpl.php, node.tpl.php und block.tpl.php)  in die Übersetzungsfunktion t(’…’) gekapselt
10. Abschließend waren noch die zahlreichen fehlenden deutschsprachigen Vokabeln für die Menüeinträge im Abschitt Localization zu ergänzen, so dass das Menü sauber zwischen den Sprachen umschaltet.

Insgesamt eine Menge Fleißarbeit (insbesondere die ~30 Stunden zum Erfassen der Beiträge). Rückblickend finde ich Drupal+i18n eine sehr elegante, schnelle und konsequente Möglichkeit, eine mehrsprachige Website aufzusetzen. Witwere Sprachversionen sollten sich nun noch schneller und einfacher einbauen lassen. Das i18n-Framework skaliert super.

Erstaunlicherweise arbeiteten alle Module ohne Code-Modifikation mit i18n. Mit einer Ausnahme: simarterms.module. Dafür steht jedoch in der Issue queue des Moduls schon ein Patch bereit, der auch prompt (nach dem Einspielen) funktionierte.