Was mich immer wieder erstaunt - nicht nur bei Textpattern, aber das muss jetzt halt mal dran glauben weil ich es ausprobieren wollte - ist die Ignoranz von Punycode in Software. Ok, ich weiss, Punycode (die internationalisierten Domainnamen) ist krank. Das weiss ich. Nur die komplette Ignoranz dieses - leider recht kranken - Standards macht manches nette Paket kaputt.
Bei Textpattern ist das ganze jetzt besonders witzig: einige Teile funktionieren tadellos, einige andere absolut nicht. Mal wird eine gültige URL generiert, mal eine kaputte. Zum Beispiel tun es weite Teile des Admins absolut tadellos, nur die kleinen Popupfenster in der Präsentationsadministration kommen nicht mit Umlaut-Domains klar.
Klar, ich könnte da jetzt die xn-... Form der Domain einbauen. Aber dann würde diese auch nach außen sichtbar, weil TXP scheinbar diese auch teilweise absolut generiert und damit diese Basis-URL mit reinrutscht. Hmm. Unschön.
Update: auf jeden Fall sollte man den Aufruf zum Setzen des Zeichensatzes auf utf-8 auch in der textpattern/index.php Datei machen. Diese ist für das Admin-Interface verantwortlich, wenn man das nicht macht, gibts Konflikte zwischen den Admin-Seiten und den Content-Seiten. Denn bei den Content-Seiten wird der entsprechende Call gemacht, diese werden also mit utf-8 als Zeichensatz in den Serverheadern ausgeliefert. Die Adminseiten aber nicht - also wird das iso-8859-1. Ergebnis: viele moderne Browser ziehen (korrekterweise) den Zeichensatz vom HTTP-Header dem vor, der in der Datei selber angegeben ist. Und schon gibts komische Umlaute.
Was ich zugefügt habe, ist die folgende Zeile:
header("Content-type: text/html; charset=utf-8");
Und zwar vor dem $textarray = load(.....) Call. Damit wird dann wenigstens dieses Problem behoben. Am besten einmal die vorhandenen Elemente aufrufen und neu speichern, damit die richtig im utf-8 Zeichensatz sind. Das gilt bei internationalen URLs auch für die Preferences, wo man die Domain der Site eingibt.
Was immer noch klemmt, sind die Tagbuilder Fenster - die Popups werden falsch aufgerufen, scheinbar mit falsch kodierten Umlauten. Leider kann ich das aufgrund eines Bugs im Camino nicht verifizieren, der weigert sich Seiteninhalte von internationalen Domains im Source anzuzeigen 
Internationale Domains sind ein Hack. Und wie bei jedem üblen Hack, gibts haufenweise üble Probleme.
Update 2: wie um zu beweisen wie Hacky Punycode und vor allem dessn Unterstützung in Browsern ist, ich hab heute mal diverse weitere Browser getestet. Zusammen mit denen von gestern:- Safari auf Jaguar kann überhaupt kein Punycode
- Camino 0.8 kanns weitestgehend, kann aber keinen Source anzeigen und die Tag-Popups in TXP tuns nicht (wie ich mitlerweile weiss ist es ein Browser-Bug)
- Mozilla Firefox 0.8 kommt ebenfalls weitgehend damit klar, nur tuns Popups und Sourceanzeige nicht - gleicher Bug wie bei Camino (war zu erwarten, ist ja die gleiche Sourcebasis)
- IE kann eh kein Punycode, braucht dafür ein Plugin. Weiter hab ich mit dem Misthaufen nicht getestet.
- diverse Textbrowser (lynx, w3m, links) tuns auch nicht mit Punycode.
- Opera kommt mit allen Aspekten klar.
Klarer Sieger: Opera. Wer also mit internationalen Domains arbeiten will (vor allem halt mit Textpattern - aber nicht nur dort), sollte Opera benutzen. Denn sonst gibts Probleme an allen Ecken und Enden, wo Hostnamen ermittelt/generiert werden - z.B. die JavaScript-Links für die Popups in TXP enthalten keinen Hostnamen. Der wird vom Browser intern dazugepappt. Und zwar falsch - aber nur, wenn das Popup gemacht wird. Wird statt dessen über das Kontextmenü der Link in einer neuen Registerkarte geöffnet, funktioniert alles bei Firefox und Camino.
Sorry, aber das ganze Thema ist absolute Moppelkotze.
