Seit einigen Tagen gibt es die Version 1.0 von Serendipity. Wenn ich denn schon keine Artikel schreibe, dann führe ich wenigstens ein Upgrade meiner s9y Installation durch.
Gibt nicht viel zu erzählen, wenn man sich an die Anleitung hält funktioniert es ohne Probleme und dauert inkl. Backup keine 5 Minuten. Beim Update einer anderen s9y Installation habe ich mir voller Vertrauen sogar ein Backup der existierenden Daten gespart und wurde nicht enttäuscht.
Artikel mit Tag weblog
Verwandte Tags
blog bloggerszene nachhaltigkeit s9y serendipity utf-8 web2.0 apache lighttpd open source linuxMontag, 19. Juni 2006
Serendipity Update
Mittwoch, 1. März 2006
Nochmal Serendipity und Umlaute
Mit Erschrecken habe ich heute morgen festgestellt, dass der Monatsname März im Kalenderblock nicht mit ä angezeigt wird. In meinem zweiten Blog Artikel habe ich mich bereits zum Thema Datumsformat ausgelassen und jetzt so etwas. Hier die Lösung:
In der Datei lang/UTF-8/serendipity_lang_de.inc.php werden die locales für LC_TIME gesetzt
@define('DATE_LOCALES', 'german, de_DE, de, de_DE.UTF-8, de_DE@euro, de_DE.ISO8859-1')
Die angebeben locales werden der Reihe nach durchprobiert bis eine gefunden wurde die installiert ist. Auf meinem System ist german vorhanden, allerdings ein Alias für de_DE.ISO-8859-1, was ja wiederrum nicht die passenden Kodierungen für UTF-8 enthält. Folglich wird der Umlaut verhackstückelt. Nun könnte man den Alias in /etc/locale.alias ändern, da ich im Moment nicht im Blick habe wo das dann wieder zu Problemen führen könnte, habe ich kurzerhand den Eintrag in der o.g. Datei geändert:
@define('DATE_LOCALES', 'de_DE.utf8@euro, de_DE@euro');
In der Datei lang/UTF-8/serendipity_lang_de.inc.php werden die locales für LC_TIME gesetzt
@define('DATE_LOCALES', 'german, de_DE, de, de_DE.UTF-8, de_DE@euro, de_DE.ISO8859-1')
Die angebeben locales werden der Reihe nach durchprobiert bis eine gefunden wurde die installiert ist. Auf meinem System ist german vorhanden, allerdings ein Alias für de_DE.ISO-8859-1, was ja wiederrum nicht die passenden Kodierungen für UTF-8 enthält. Folglich wird der Umlaut verhackstückelt. Nun könnte man den Alias in /etc/locale.alias ändern, da ich im Moment nicht im Blick habe wo das dann wieder zu Problemen führen könnte, habe ich kurzerhand den Eintrag in der o.g. Datei geändert:
@define('DATE_LOCALES', 'de_DE.utf8@euro, de_DE@euro');
Montag, 2. Januar 2006
Spracheinstellung und Datumsformat bei Serendipity
Jetzt läuft das blog noch keine 24h und schon ist mir ein Fehler aufgefallen. Bei der Konfiguration kann man die Sprache des Blogs einstellen, hier habe ich logischerweise "Deutsch" gewählt.
So weit so gut, alle Menueinträge sind dadurch auch in deutscher Sprache zu bewundern, lediglich das Datumsformat in den Artikelüberschriften und das Kalender Plugin verwenden nach wie vor die englische Bezeichnung für die Tages- und Monatsnamen.
Meine erste, zugegeben naive, Vermutung war, dass in den "lang" Dateien vergessen wurde die entsprechenden Einträge zu übersetzen. Ein wenig grep auf alle Dateien und ich musste festestellen, dass dort gar keine Übersetzungen für die Tages- und Monatsnamen vorhanden sind.
Ein wenig ratlos habe ich erstmal eine Tasse Kaffe getrunken und darüber siniert, dass eine Suche auf google nach serendipity oder s9y als Ergebnisse vor allem die Adressen von anderen blogs liefert und es wohl etwas mühsam werden könnte da etwas zur Fehlersuche brauchbares zu finden.
Wie aus heiterem Himmel fiel mir ein, dass ich so ein ähnliches Problem schon einmal vor Jahren mit "squirrelmail" hatte. Ein Kunde hatte das Webinterface auf meinem Mailsystem gesehen und wollte es unbedingt auch auf seinem Server haben. Gesagt getan, alles wunderbar, nur waren alle Zeit- und Datumsangaben immer auf Englisch. Dutzendemale habe ich die Squirrelmail-Konfiguration auf meinem Server mit der auf dem Server des Kunden verglichen und keinen relevanten Unterschied gefunden. Ich habe dann beschlossen die Ursache irgendwo zwischen Betriebssystem und Apache zu suchen. Eher durch Zufall fiel mir dabai auf, dass die Ausgaben der Shell dort auf Englisch waren, auf meinem Server (ausser für root) auf Deutsch. Siehe da, die fehlenden locales für de_DE.* waren die Ursache, also selbige nachinstalliert und den apache neu gestartet.
Lange Rede - kurze Lösung (für Debian!):
"dpkg-reconfigure locales" ausführen und dort die Sprachen
de_DE.ISO-8859-1
de_DE.UTF-8
de_DE.UTF-8@euro
de_DE.ISO-8859-15@euro
auswählen, anschliessend apache mit dem Befehl "/etc/init.d/apache2 restart " neu starten.
So weit so gut, alle Menueinträge sind dadurch auch in deutscher Sprache zu bewundern, lediglich das Datumsformat in den Artikelüberschriften und das Kalender Plugin verwenden nach wie vor die englische Bezeichnung für die Tages- und Monatsnamen.
Meine erste, zugegeben naive, Vermutung war, dass in den "lang" Dateien vergessen wurde die entsprechenden Einträge zu übersetzen. Ein wenig grep auf alle Dateien und ich musste festestellen, dass dort gar keine Übersetzungen für die Tages- und Monatsnamen vorhanden sind.
Ein wenig ratlos habe ich erstmal eine Tasse Kaffe getrunken und darüber siniert, dass eine Suche auf google nach serendipity oder s9y als Ergebnisse vor allem die Adressen von anderen blogs liefert und es wohl etwas mühsam werden könnte da etwas zur Fehlersuche brauchbares zu finden.
Wie aus heiterem Himmel fiel mir ein, dass ich so ein ähnliches Problem schon einmal vor Jahren mit "squirrelmail" hatte. Ein Kunde hatte das Webinterface auf meinem Mailsystem gesehen und wollte es unbedingt auch auf seinem Server haben. Gesagt getan, alles wunderbar, nur waren alle Zeit- und Datumsangaben immer auf Englisch. Dutzendemale habe ich die Squirrelmail-Konfiguration auf meinem Server mit der auf dem Server des Kunden verglichen und keinen relevanten Unterschied gefunden. Ich habe dann beschlossen die Ursache irgendwo zwischen Betriebssystem und Apache zu suchen. Eher durch Zufall fiel mir dabai auf, dass die Ausgaben der Shell dort auf Englisch waren, auf meinem Server (ausser für root) auf Deutsch. Siehe da, die fehlenden locales für de_DE.* waren die Ursache, also selbige nachinstalliert und den apache neu gestartet.
Lange Rede - kurze Lösung (für Debian!):
"dpkg-reconfigure locales" ausführen und dort die Sprachen
de_DE.ISO-8859-1
de_DE.UTF-8
de_DE.UTF-8@euro
de_DE.ISO-8859-15@euro
auswählen, anschliessend apache mit dem Befehl "/etc/init.d/apache2 restart " neu starten.
(Seite 1 von 1, insgesamt 3 Einträge)






