Permalinks mit Umlauten ohne o42-clean-umlauts

codestyling | 04. März 2009 | 01:54

Beiträge, die man in einem deutschsprachigen Blog mit Umlauten verfasst, sind mit der grundsätzlichen Einführung von UTF-8 in WordPress seit Version 2.5 kein Problem mehr. Man muß keine automatischen Ersetzungen im Text, Excerpt oder in den Titeln selbst vornehmen.
Das Dilemma mit den deutschen Umlauten in den Permalinks existiert jedoch weiter, seitens WordPress selbst wird nichts direkt angeboten. Plugins wie o42-clean-umlauts versuchen diese Lücke zu schließen. Dabei wäre es doch so einfach.

Während der Beschäftigung und Tests mit RTL Sprachen (rechts nach links geschrieben) wie zum Beispiel Arabisch oder Hebräisch stößt man auf Besonderheiten, die offensichtlich mit einer Sprachdatei allein nicht lösbar sind. Nachdem ich ein wenig gesucht habe, fand ich schließlich, wie diese speziellen Behandlungen durchgeführt werden.

die unbekannte PHP Datei zur Sprachdatei

Wenn man den Code von WordPress studiert, dann findet man Sachen, die man so nicht erwartet hat. Ich glaube die Wenigsten wissen, das WordPress noch mehr macht, als stur die Sprachdatei zu laden. Es wird nämlich nach eine speziellen PHP Datei gesucht, die sofern vorhanden, automatisch mit geladen wird.
Hier der Code-Ausschnitt dazu:

PHP
1
2
3
4
5
6
7
8

/**
 * The locale of the blog
 * @since 1.5.0
 */
$locale = get_locale();
$locale_file = WP_LANG_DIR . "/$locale.php";
if ( is_readable($locale_file) )
	require_once($locale_file);
timing: 0.034s

Sagen wir mal, die Locale steht auf he_IL für hebräisch definiert durch WPLANG in der wp-config.php. Dann versucht WordPress die Datei: he_IL.php zu laden, sofern sie existiert und lesbar ist.
Was genau machen aber RTL Sprachen mit diesen Dateien, die man in deren lokalisierten Kopien von WordPress finden kann ?

Es werden zum Beispiel diakritische Zeichen (Wikipedia) speziell behandelt, die Filter für wptexturize teilweise wieder aufgehoben durch zusätzliche Filter wie wpuntexturize ergänzt. Es wird sogar für spezielle Browser in den erzeugten HTML Markup eingegriffen. Wer sich dies genauer aussehen möchte, die hebräische Version der PHP Datei ist im Download mit enthalten.

Nutzung als standardisiertes Feature für deutsche Umlaute

Basierend auf der Verwendungsweise für RTL Sprachen schreibt ja niemand vor, dass man dieses Feature nicht genauso gut für Deutsch benutzen kann. In dieser Datei bräuchte man dann nur die Filter unterbringen, die man für die deutschen Umlaut-Permalinks benötigt und hätte es geschafft.
Die Vorteile davon kann man ganz leicht aufzählen:

  1. Der Filter ist nur in deutsch (de_DE) konfigurierten Blogs aktiv.
  2. Man kann sich ein zusätzliches Plugin sparen.
  3. In multi-lingualen Blogs wird das nur benutzt, wenn das Backend in dieser Sprache ist und nicht dauerhaft in allen Sprachen, wie es bei der Plugin Lösung ist.
  4. Man könnte das sogar, wie es bei anderen Sprachversionen von WP gemacht wird, in den Download mit aufnehmen.
  5. Die sprachspezifischen Korrekturen sind an einer zentralen Stelle.

Es gibt sicher noch mehr Punkte, die ich aufzählen könnte, jedoch sollte das bereits zeigen, was es am Ende bringen sollte. Ich werde versuchen, dies mit wordpress.org und auch wordpress-deutschland.org zu diskutieren, ich wäre dafür, dies in den Standard-Lieferumfang aufzunehmen.

Da man seit UTF-8 Verwendung von WordPress keine speziellen Filter mehr für Umlaute im Text selbst benötigt, reicht prinzipiell ja ein Filter, der für die Slug-Erstellung aufgerufen wird. Diesen habe ich mal in eine solche Datei de_DE.php verpackt, das Plugin deaktiviert und bei mir getestet. Außerdem wird dieser Filter nur aktiviert, wenn man im Admin-Bereich ist, denn das Frontend hat keinen Bedarf für die Erstellung von Permalinks mit Umlauten. (Falls doch jemand einen triftigen Grund für’s Frontend kennt, bitte teilt ihn mir mit.)

Problemkind: Window Live Writer und co.

Wenn man die Offline Blogging Software Windows Live Writer verwendet, wird man feststellen, dass es noch nicht ganz reicht, nur die Slugs zu beherrschen. Die Applikation sendet deutsche Umlaute in Überschriften grundsätzlich als Entitäten wie zum Beispiel Ü als Ü zu WordPress. Wenn man jedoch ein UTF-8 Blog betreibt, was ja nun Standard sein sollte, dann ist es mehr als unschön, wenn diese Entitäten statt korrekter UTF-8 Umlaute abgespeichert werden. Und für den den Body der Posts macht man es natürlich ganz anders, dort werden dann numerische Zeichenkodierungen verwendet, super! Beides ist nun in der Datei berücksichtigt und als erneuerter Download bereitgestellt.

visueller Editor TinyMCE - Rechtschreibprüfung

Der visuelle Editor bringt ja eine Rechtschreibprüfung mit, die man benutzen kann, wenn man gerade kein Firefox zur Verfügung hat, der dies schon eingebaut hat (wenn man das entsprechende Wörterbuch installiert). Allerdings ist im TinyMCE Editor standardmäßig Englisch vorausgewählt und man muß immer umschalten, wenn man die Rechtschreibprüfung benutzen will.
Deshalb wird durch die Datei de_DE.php jetzt auch die Rechtschreibprüfung auf Deutsch für TinyMCE voreingestellt.

Damit man sich ein Bild davon machen kann, habe ich die beiden hier erwähnten PHP Dateien in ein Archiv zum Download verpackt. Die Dateien gehören in das gleiche Verzeichnis wie die Sprachdateien von WordPress selbst, im Normalfall also /wp-content/languages/.

Mich würde interessieren, was ihr davon haltet, einen genormten und ggf. mit den WordPress Vertretern abgeklärten Weg zu beschreiten anstatt dafür Plugins benutzen zu müssen.

Download: languages-php-dateien.zip (951 downloads)

Kategorien
Deutsch, WordPress (DE)
RSS Kommentare
RSS Kommentare

« WordPress 2.8 ändert Sprachdatei-Zugriffe WordCamp Vortrag “Lokalisierung” als PDF Download »

51 Antworten    Schreib einen Kommentar

oliver

oliver

04.03.2009 | 08:47

Super Ansatz - finde das sollte man unbedingt weiterverfolgen. Fand ich immer schon total unverständlich, warum das mit den Umlauten nicht irgendwie “eleganter” zu lösen ist …

Antworten »

Putzlowitsch

Putzlowitsch

04.03.2009 | 09:37

Ich finde das sehr gut.

Bin sowieso nicht so der Freund davon, für jeden Dreizeiler ein extra Plugin zu installieren. Meist haue ich dann solche Sachen in die (angeblich schon seit Jahren veraltete) my-hacks.php rein. Wenn es sich aber direkt ins System integrieren läßt, um so besser.

Man findet so manche “Schätze” in den Tiefen von WP versteckt, meist aber sogar ganz vorne in der wp-settings.php :-)

Antworten »

Blogging Magazin

Blogging Magazin

04.03.2009 | 11:01

Ich finde es eigentlich nicht sooo schlimm o42 zu nutzen. Installation dauert wenige Sekunden und gut ist. Man hat keine Sorgen und alles super.

Antworten »

DJBase

DJBase

04.03.2009 | 11:51

Ich hatte bisher die Permalinks bei Umlauten immer manuell angepasst. Schön, wenn sich dafür nun ein besserer Weg findet, der sich elegant ins System einpflegen lässt.

Antworten »

Thomas Scholz

Thomas Scholz

04.03.2009 | 14:56

Du benutzt in $umlaut_chars['html'] Entities. Da es aber immer noch ein paar Leute gibt, die XHTML benutzen, wären numerische Zeichenreferenzen besser. Entities sind kein direkter Bestandteil der XHTML-DTD und werden auch nicht von allen UAs aufgelöst, die den MIME-Typen application/xhtml+xml unterstützen.

Insgesamt finde ich dein Vorgehen sehr gut. Sollte das nicht Bestandteil des deutschen Sprachpaketes werden?

Antworten »

codestyling

codestyling

04.03.2009 | 15:03

Die Aufnahme als Bestandteil des deutschen Sprachpaketes (lokalisierter WordPress Download) ist ja das dahinterliegende Ziel. Deswegen kläre ich ja auch gerade ab, was man ggf. noch alles brauchen oder beachten sollte.
Die Einträge im html array werden ja ersetzt durch die transliteral Schreibweise für Permalinks und nicht umgekehrt. Somit wird aus ü ein ue sofern das so im Titel stehen sollte.

Antworten »

Tobias

Tobias

06.03.2009 | 13:56

Hallo Heiko!

Coole Sache, vielen Dank!

Achso: Wir hatten uns auf dem WordCamp in Jena nach deinem Vortrag ein bißchen unterhalten. Dort sagtest du, dass du deine Präsentation evtl. in deinem Blog veröffentlichst.
Konnte den bisher aber leider nicht finden :-( Würde gerne nochmal reingucken, weils sehr interessant war.

Gruß
Tobias

Antworten »

codestyling

codestyling

06.03.2009 | 15:05

Das Tutorial ist in Arbeit nur bin ich beruflich im Moment derart ausgelastet, daß nicht sehr viel Zeit übrig geblieben ist. Es gibt aber auf ScreenPress.de den Video Mitschnitt des Vortrags. Ich bemühe mich, das Tutorial so schnell wie möglich online zu bekommen, wird aber vermutlich noch bis nächste Woche brauchen.

Antworten »

Friederike

Friederike

18.03.2009 | 11:59

Hervorragender Ansatz. Ich kenne nicht die Details (entities etc.) - aber die deutschen Umlaute als Sonderzeichen zu verstehen, wie sie in Sprachen mit nicht-lateinischen Buchstaben vorkommen, finde ich gut. Noch nicht erschlossen hat sich mir Folgendes:

Außerdem wird dieser Filter nur aktiviert, wenn man im Admin-Bereich ist, denn das Frontend hat keinen Bedarf für die Erstellung von Permalinks mit Umlauten. (Falls doch jemand einen triftigen Grund für’s Frontend kennt, bitte teilt ihn mir mit.)

Das Frontend erstellt selbst natürlich keine Permalinks - aber dort sind die Permalinks (die während des Bloggens / Schreibens im Admin-Bereich ist erstellt werden) sichtbar … richtig? Wie ist es mit Blogs, in denen unregistrierte Nutzer/innen Beiträge einreichen können? Dies geschieht wenn, dann über Formulare im Frontend (wenn ich keinen Denkfehler mache, derzeit betreibe ich noch kein solches Blog, es ist aber eins in Planung)

Ich hoffe, dass die Umlaute bald standardmäßig gelöst sind. Nach all den Jahren… ;-)

Es grüßt
Friederike

Antworten »

codestyling

codestyling

18.03.2009 | 17:29

Das hängt davon ab, wie die Beiträge gespeichert werden sollen. Wenn das normale API von WordPress (also Beträge speichern) benutzt wird, könnte es dazu führen, das die Permalinks u.U. nicht korrekt sind. Das müsste ich mir ansehen, denn eine Frontend-Speicherung der Daten aktiviert keine Backend Kennung.

Antworten »

Thomas Scholz

Thomas Scholz

21.03.2009 | 05:26

Ich habe deine Lösung jetzt eine Weile in zwei Blogs in Betrieb: Funktioniert sehr gut. Danke nochmal.
Ich habe nur eines ergänzt: € wandle ich in URLs zu »euro«. Das sollte eigentlich in den Core, finde ich, denn es betrifft viele Sprachen.

Antworten »

codestyling

codestyling

21.03.2009 | 19:04

Die Umwandlung von € in euro ist eine interessante Idee, werde mal schauen, dies in die Datei aufzunehmen. Es stellt sich allerdings dann auch die Frage, ob mal $ in dollar und ₤ in pound oder allgemein sämtliche Währungszeichen in geschriebener Form aufnimmt.

Antworten »

Ivan

Ivan

21.03.2009 | 11:07

Endlich mal ein Lösungsweg ohne eine veraltetes Plugin (o42-clean-umlauts)! Die integrierte Umschaltung des Wörterbuches auf Deutsch, sollte eigentlich schon als Standard sein. Ich würde es auf jedenfall befürworten, wenn es direkt in die nächsten Wordpress Versionen integriert würde.

Gruss Ivan

Antworten »

Thomas Scholz

Thomas Scholz

25.03.2009 | 15:01

Beim Dollarzeichen bin ich mir nicht sicher – das wird ja in Perl und PHP auch zur Kennzeichnung von Variablen genutzt (ob das ein guter Titel ist, sei mal außen vor).

₤ sollte in der deutschen Variante in pfund gewandelt werden. Man könnte auch weitergehen und die übrigen Währungszeichen umwandeln, die nicht durch den Euro aufgehoben wurden, ebenso ‰ nach promille, ± nach plusminus, ℃ nach grad-celsius, ℉ nach fahrenheit, № nach nummer und ∞ nach unendlich.

Irgendwo muß natürlich Schluß sein – wer allzu exotische Zeichen verwendet, wird sicher selbst nochmal die URL prüfen.

Antworten »

Stefan Graupner

Stefan Graupner

31.03.2009 | 17:00

Sehr interessante Idee. Noch schöner wäre allerdings für die (fernere) Zukunft, wenn Wordpress die “Macht” der Mediawikis verliehen bekommt und auch URLs mit UTF-8-Zeichen korrekt interpretieren würde. Damit würde man dann sicher auch einiges an Code-Ballast in den diversen Lokalisierungen streichen können und das System könnte etwas schlanker und damit für alle Beteiligten Schneller werden.
Allerdings ist mir bei der Wikipedia momentan nicht so ganz klar, wie diese UTF-8-URLs von Clients die kein UTF-8 unterstützen behandelt werden. Sowas könnte man zwar theoretisch serverseitig abfangen, bräuchte dann aber wieder Ausweichmöglichkeiten. Ergo bleibt, bis zur weltweiten vollständigen UTF-8 Konvertierung wohl vorerst nur diese sehr praktikable Lösung. :)

Antworten »

Ricarda

Ricarda

30.04.2009 | 23:29

Salut!
Habe die beiden Dateien nun auch mal integriert funktioniert alles bestens. Naja fast alles.
Ich benutze auch den Windows Live Writer und lasse meine Überschriftentitel per TTF-Titles ausgeben. Kannste ja oben bei meinem Link sehen.

Wenn ich nun also mit dem Live Writer nen Artikel verfasse und danach abschicke erscheint im Titel zwar der Umlaut jedoch zB bei meinem letzten “Neue schÖne Wordpressthemes” also der Umlaut praktisch groß obwohl er klein sein soll. Wenn ich den Beitrag einmal öffne, speicher und neu aufrufe, ist alles wieder okay.

Antworten »

codestyling

codestyling

05.05.2009 | 17:54

Das ist ein interessantes Phänomen. Ist ggf. im Live Writer eingestellt, das er Titel im Großschreibung an WP sendet ? Ich wüsste sonst nicht, warum das in Großbuchstaben gewandelt wird. Zur Sicherheit schau ich aber nochmal den Code durch, ob das ein Lapsus meinerseits ist.

Antworten »

Ricarda

Ricarda

25.06.2009 | 20:03

Nach einigen Testdurchgängen ist das Problem zumindest in Blog 1 nicht mehr aufgetaucht.
In Blog 2 hingegen muss jeder Titel mit Umlaut manuell korrigiert werden.

Es tritt nur in Verbindung mit TTF Titles auf. Mit Standardschriftarten funktioniert alles bestens.

Antworten »

codestyling

codestyling

25.06.2009 | 21:18

Dann schaue ich mir mal TTF Titles an. Welchen Font hast du hochgeladen, damit die Bilder erzeugt werden können ?

Antworten »

Sebastian

Sebastian

03.06.2009 | 11:44

Hi,

ich arbeite gerade an den Permalinks mit deutschen Umlauten. Natürlich bin ich auch über das o42-clean-umlauts-Plugin gestolpert, allerdings finde ich den Ansatz eher ungünstig, für jede kleine Anpassung ein eigenes Plugin zu installieren. Auf meiner Suche nach Alternativen bin ich auf diesen Ansatz gestoßen, die Funktionen direkt in den Core zu integrieren, was ich für deutlich sauberer halte.
Also habe ich die hier vorgeschlagenen Änderungen mal in unser Blog integriert, allerdings passt exakt … gar nichts?!

Ich verwende Wordpress 2.7.1, meine Spracheinstellungen stehen auf UTF-8, meine Permalink-Struktur steht auf “benutzerdefiniert” (/%postname%/). Trotzdem wird aus der Überschrift “Ein Täst” der Link “/ein-tst”, statt “/ein-taest”.

Gibt es dazu hier Ideen? Bin für Vorschläge dankbar.

Viele Grüße aus Bielefeld*,
Sebastian

*) ja, uns gibt’s wirklich ;-)

Antworten »

codestyling

codestyling

04.06.2009 | 02:37

Das hängt davon ab, ob dein Blog mit einem der vielen Mehrsprachigkeits-Plugins (Gengo, qTranslate etc) läuft und ob deine wp-config.php eine deutsche Sprache installiert hat.

PHP
1

define ('WPLANG', 'de_DE');
timing: 0.032s

Falls deine Sprachkennung davon abweicht, fehlt oder durch ein o.g. Plugin modifiziert wird, kann die entsprechende de_DE.php natürlich nicht mehr geladen werden.
Kannst du das bitte prüfen ?

Antworten »

Sebastian

Sebastian

04.06.2009 | 09:53

Hi noch mal,

vielen Dank für den guten Hinweis! Die Sprache war in der wp-config definiert und ein Mehrsprachigkeits-Plugin hatten wir nicht im Einsatz. Aber das Plugin “SEO Slugs” war installiert und hat die Umlautersetzung erfolgreich vereitelt ;-) Also Plugin deaktiviert und es klappt alles, wie es soll. Vielleicht hilft’s noch mal jemand anderem.

Viele Grüße,
Sebastian

Antworten »

bassoprofondo

bassoprofondo

21.06.2009 | 06:00

hi, habe die beiden Dateien seit einigen Tagen im Einsatz und DANK Deiner Entwicklung nun perfekte Umlaute in den Permalinks. Klar bin ich dafür, dass die WP-Macher Deine Anregung in den Core aufnehmen.

Was passiert eigentlich, wenn die das dann tatsächlich aufnehmen, sind dann Probleme / Konflikte mit Deinen beiden Dateien zu erwarten, kann man sie einfach (aus Vergesslichkeit z.B.) im Language-Ordner liegen lassen, oder sollte man bei einem Upgrade von wp (2.9, 3.0, …) dieser Sache ein besonders Augenmerk schenken? LG

Antworten »

codestyling

codestyling

21.06.2009 | 13:36

Im Falle WordPress nimmt das mit in den Lieferumfang auf, wird es ebenso eine Datei sein, wie die bereits von mir bereit gestellte de_DE.php im Ordner wp-includes/languages/.
Erfolgt dann also ein Update auf die entsprechende Sprachversion, dann wird vermutlich die Datei überschrieben. Denn direkt in den Core einbauen kann man das nicht, denn andere Sprachen haben deutlich andere Anforderungen.

Antworten »

Volker

Volker

08.07.2009 | 16:50

Ich wollte die Datei gerade in WP2.8 testen - kann aber nicht sagen, ob sie funktioniert oder nicht: WP scheint ja die deutschen Umlaute bei den Permalinks mittlerweile schon automatisch richtig umzuwandeln!? Mein Problem sind jedoch noch die 3 skandinavischen Zeichen. Habe den Code deshalb wie folgt erweitert:

PHP
1
2
3
4
5
6
7

/* define it global */
	$umlaut_chars['in'] 	= array(chr(196), chr(228), chr(214), chr(246), chr(220), chr(252), chr(223), chr(197), chr(229), chr(198), chr(230), chr(216), chr(248));
	$umlaut_chars['ecto'] 	= array('Ä', 'ä', 'Ö', 'ö', 'Ü', 'ü', 'ß', 'Å', 'å', 'Æ', 'æ', 'Ø', 'ø');
	$umlaut_chars['html'] 	= array('Ä', 'ä', 'Ö', 'ö', 'Ü', 'ü', 'ß', 'Å', 'å', 'Æ', 'æ', 'Ø', 'ø');
	$umlaut_chars['feed'] 	= array('Ä', 'ä', 'Ö', 'ö', 'Ü', 'ü', 'ß', 'Å', 'å', 'Æ', 'æ', 'Ø', 'ø');
	$umlaut_chars['utf8'] 	= array(utf8_encode('Ä'), utf8_encode('ä'), utf8_encode('Ö'), utf8_encode('ö'),utf8_encode('Ü'), utf8_encode('ü'), utf8_encode('ß'), utf8_encode('Å'), utf8_encode('å'), utf8_encode('Æ'), utf8_encode('æ'), utf8_encode('Ø'), utf8_encode('ø'));
	$umlaut_chars['perma'] 	= array('Ae', 'ae', 'Oe', 'oe', 'Ue', 'ue', 'ss', 'A', 'a', 'Ae', 'ae', 'O', 'o');
timing: 0.051s

Allerdings führt das immer noch nicht dazu, dass z.B. das Å in ein A umgewandelt wird. Auch eine Ergänzung in dieser Zeile

PHP
1

$invalid_latin_chars = array(chr(195).chr(133) => 'A', chr(197).chr(146) => 'OE' ...
timing: 0.036s

half nichts, Was mache bzw. verstehe ich falsch?

Antworten »

codestyling

codestyling

09.07.2009 | 11:34

Hast du zufällig ein Plugin laufen, das es ermöglicht, den Blog in mehreren Sprachen zu betreiben ?
Dann kann es sein, dass die Datei überhaupt nicht geladen wird. Denn WP lädt sie nur wenn der Dateiname mit der eingestellten (aktuellen) Sprache übereinstimmt. Beispiele:

de_DE => es wird eine de_DE.php gesucht und geladen
de => es wird eine de.php gesucht und geladen

Antworten »

Nils Niedlich

Nils Niedlich

10.07.2009 | 22:19

Huhu,
danke für Deine Ausführungen und die Dateien.

Ich nutze WP 2.8.1 und es funktioniert reibungslos :)

Gruß
Nils

Antworten »

Urgixgax

Urgixgax

14.07.2009 | 09:22

Hallo, ich bin auch gerade auf der Suche, zum lösen, des Umlaut-Problems, denn ich habe gestern die Permalink-Struktur auf /%postname%/ umgestellt und damit die “alten Permalinks” noch klappen, dass Plug-in “Dean’s Permalinks Migration” installiert. Alles klappt soweit gut, nur das Umlaute in den Permalinks, nicht zu sehen sind.
Ich bin nun etwas am rätseln, wo das Problem liegt, oder ob das normal ist. Die beiden Dateien, habe ich jetzt mal mit in das “languages-Verzeichnis” kopiert, aber es hat sich nix geändert. Wird das Problem nur behoben, wenn man neue Beiträge schreibt?

Urgixgax

Antworten »

codestyling

codestyling

14.07.2009 | 11:16

Diese Datei greift nur beim Schreiben/Ändern eines Artikels oder Seite. Ich hab mal kurz durchgesehen, was das von dir genannte Plugin macht. Da die Permalink Umleitung immer neu “berechnet” wird, wenn ein Besucher eine “alte” URL aufruft, greift diese Datei nicht, denn sie korrigiert nur im Admin Bereich.
Diese Datei modifiziert die Permalinks während der Bearbeitung der Artikel und geht dann davon aus, dass sie beim Besuch der Leser bereits korrekt sind.
In deinem Falle stimmt das aber nicht, denn du willst ja bei Besuch den Leser auf den neuen Permalink umleiten. Aus Performance Gründen ist von einem Filter für das Frontend abzuraten, deswegen ist das auch nicht in der Datei.
Im Moment habe ich keine Lösung parat, darüber muß ich nochmal nachdenken.
Nachtrag: Ich würde das hier in Betracht ziehen als Redirect Plugin, scheint mir logischer zu sein und man kann den Redirect auch abschalten, falls niemand mehr über die alten Url’s kommt: Redirection

Antworten »

Urgixgax

Urgixgax

14.07.2009 | 13:31

Hallo und danke, für die Info!
Warum in meinen Links keine Umlaute sind, hat also nix mit dem Plug-in, welches ich nutze zu tun, vermute ich mal. Deine beiden Dateien, belasse ich mal, für nachfolgende Beiträge, denn sie sind auf keinen Fall verkehrt! Da ich nicht sooo der Ahnungsbär bin, werde ich wohl ohne Umlaute, in meinen Links leben müssen. Redirection wird da sicher nix dran ändern.

Antworten »

Urgixgax

Urgixgax

06.09.2009 | 19:09

Ich bin es noch einmal.
In den Permalinks scheint es nun zu klappen, mit den Umlauten usw. Nur wenn man einen mit Windows Live Writer hoch geladenen Artikel im Editor ansieht, ist der Titel wie vorher auch, mit Entitäten bestückt wenn ich das richtig deute.

So sieht das ganze dann aus:

Picture

Antworten »

Scott

Scott

25.12.2009 | 23:36

Ich bin gerade auf meiner Suche nach eine Lösung für mein Umlaut-Problem mit Wordpress über diese Seite gestolpert und finde diesen Ansatz sehr vielversprechend. Gerade wenn es die Möglichkeit gibt, dieses Problem direkt über den Core-Funktionen zu beheben, sollte das auch so gemacht werden.

Allerdings habe ich eine kleine Frage:

Diese Datei greift nur beim Schreiben/Ändern eines Artikels oder Seite.

Korrigiert deine de_DE.php auch die Permalinks von Kategorien bzw. Tags? Auch hier verhält sich Wordpress standardmäßig so, dass die Umlaute einfach in ihren „Grundbuchstaben“ umgewandelt werden.

Außerdem interessiert es mich, was denn aus deinem Vorschlag geworden ist, die de_DE.php standardmäßig in Wordpress zu integrieren!

MfG Scott

Antworten »

Andi

Andi

04.08.2009 | 10:11

vielen dank für diesen input. bin ein umsteiger auf wordpress und habe mich vor allem daran genervt, dass die vorhanderen plugins nicht nur die permalinks korrekt umwandeln, sondern gleich die ganzen umlaute der artikel in entitäten umwandelt. deine lösung ist genau das, was ich gesucht habe.

Antworten »

Fabian

Fabian

22.08.2009 | 16:15

Vielen Dank! Ich bin überrascht, dass es so einfach sein kann. Bisher kannte ich für die einfache Handhabung lediglich die Plugin-Lösung!

Ich würde mit Absprache von wordpress-deutschland auch eine Integration in die deutsche WP-Version bevorzugen. Letztlich besteht das Problem ja schon sehr lange und es gab bisher keine exzellente Lösung!

Gruß Fabian

Antworten »

Carsten Dobschat

Carsten Dobschat

19.09.2009 | 22:55

Mit der Erweiterung funktionieren vorher erzeugte Permalinks nicht mehr, die ein “…” enthalten. Wenn Zeile 43 entfernt wird, dann funktionieren diese Permalinks wieder, also scheint der Aufruf nicht nur im Adminbereich aktiv zu sein…

Antworten »

Gilly

Gilly

20.10.2009 | 09:47

Auch von mir ein herzliches Dankeschön für die Infos und das Bereitstellen der Dateien.

Antworten »

Wolf Larsen

Wolf Larsen

08.11.2009 | 17:26

Ich schließe mich meinem Vorkommentierer an und bedanke mich für die PHP-Datei und Deine Arbeit. Clean Umlauts wandelt ja wie gesagt den ganzen Artikelcode in Entitäten um, was irgendwie albern ist, wenn man “nur” richtige Permalinks haben wollte. Eine schöne Woche!

Wolf

Antworten »

Micha

Micha

29.11.2009 | 16:36

Den artikel und lösungsansatz finde ich sehr interessant und wollte ihn auch bei mit nutzen, aber meine locale.php hat deinen Codeausschnitt nicht enthalten. was mach ich da?

Antworten »

Lioman

Lioman

15.01.2010 | 10:41

So eine simple einfache Lösung, die auch noch funktioniert. Warum ist die noch nicht von Haus aus eingebaut?

Danke für Datei und Beschreibung. Wieder ein Plugin gespart.

Antworten »

Klaus

Klaus

09.03.2010 | 20:11

Hallo,
auf der Suche nach einer Lösung meines Problems mit dem Plugin o42-clean-umlauts bin ich auf Deinen super Beitrag gestoßen :-) o42-… zerhaute mir nämlich in dem Amazon-Plugin ‘Amazon Carousel’ den Beitrags-Tag [carousel keywords="rätsel"]. Das Ergebnis war, dass Amazon mit dem veränderten Umlaut “ä” im Artikel nichts mehr anfangen konnte. Das tolle richtige Ergebis ist hier zu sehen: http://tippgeber.de/tipp-43/strom-wasser-gas

Daher herzlichen Dank für diese tolle Lösung!

Antworten »

Florian

Florian

31.03.2010 | 22:39

Geniale Lösung, vielen Dank. Ein Plugin weniger, eine potentielle Sicherheitslücke weniger :)

Antworten »

Sebastian

Sebastian

29.04.2010 | 19:04

Aloha,

ja, ich möchte auch sagen: Gefällt mir sehr gut!
Ich finde es sehr beeindruckend, wie viele schöne Lösungen für die alltägliche Arbeit mit Wordpress im Netz zu finden sind. Keine Wunder, dass es Websites gibt, die sich hauptsächlich mit diesen Themen befassen.

Auf jeden Fall möchte ich dem Autor dieser Website einmal meinen Dank aussprechen, denn die hier veröffentlichten Themen waren schon mehr sehr hilfreich für meine Arbeit. Danke!

Bezüglich des aktuellen Themas wunder ich mich über die Entwickler von Wordpress, da es sich doch um eine recht praxisnahe Sache handelt. Ich habe wegen dieses ‘Fehlers’ schon oft manuelle Korrekturen an den Permalinks vorgenommen und an vielen Stellen war ich einfach zu bequem, um dies zu tun.

Ich hoffe das eine solche Lösung in einer der nächsten Wordpress Versionen enthalten ist, denn die aktuelle Situation stellt in der Tat einen Schwachpunkt in diesem sonst so fantastischen System dar.

Antworten »

norbert

norbert

02.07.2010 | 11:57

hallo!

das ist ein supertrick, funktioniert aber nicht mehr in wordpress 3.0 !

irgendeine idee was das problem ist?

Antworten »

Olaf

Olaf

05.08.2010 | 21:18

Hi Heiko,
kann es sein das es Probleme mit WP 3.0 gibt? Ich hab gerade festgestellt, dass es seit dem Upgrade die Permalinks bei einer Seite von mir nicht mehr setzt. Schön ist es hier zu sehen:
http://www.akitafreund.de/j-wurf-janes-fuenfter-wurf-j-litter-janes-fifth-litter/funfte-woche-fifth-week/
Die Oberseite 5. Wurf wurde vorher erstellt, die Unterseite 5. Woche nachher.

Ich muss dazusagen, das bei mir der LangString de ist, nicht de_DE, aber die Datei ist wie alle MOs dementsprechend umbenannt.

Antworten »

Michael

Michael

13.08.2010 | 11:47

@Olaf: die de_DE.php wurde beim Update nicht zufällig gelöscht?

@Heiko: Warum schaffte diese Modifikation noch nicht den Sprung in die deutsche WP Version? :)

Antworten »

codestyling

codestyling

13.08.2010 | 12:21

Ich teste das gerade noch und muß erstmal sehen, wie wir das mit der deutschen WP Version machen.
Da ich ca. 1 Jahr aus persönlichen Gründen inaktiv war, muß ich erstmal wieder einen Überblick bekommen, was, wer wo macht.

Antworten »

Michael

Michael

16.08.2010 | 12:17

Danke für die Rückmeldung. Schön, dass Du nun wieder an Bord bist ;-)

Antworten »

Olaf

Olaf

17.08.2010 | 16:56

@Michael: die ist definitiv da, aber heißt de.php weil in config bei mir define (’WPLANG’, ‘de’);

Antworten »

Sven Mayer

Sven Mayer

10.11.2010 | 02:31

Vielen Dank!

Der Tipp hat mir ein unnötiges Plugin erspart…

Antworten »

Jan

Jan

23.03.2011 | 21:11

Unter folgenden Link wird erklärt, wieso alle Lösungen mit WordPress gebrochen sind:
Ticket #16642

Ab Zeile 73 des Plugins Germanix sieht man, wie die aktuelle Lösung implementiert werden muss.

Antworten »

Jan

Jan

23.03.2011 | 21:13

P.S.: Zudem sollte besser

defined('XMLRPC_REQUEST')

anstatt

XMLRPC_REQUEST

benutzt werden, um PHP Warnings zu vermeiden.

Antworten »