What has always amazed me - not just with Textpattern, but it has to take the heat now because I wanted to test it - is the ignorance of Punycode in software. Ok, I know Punycode (the internationalized domain names) is sick. I know that. It's just the complete ignorance of this - unfortunately quite sick - standard that breaks some nice packages.
With Textpattern, the whole thing is particularly funny now: some parts work flawlessly, some others absolutely not. Sometimes a valid URL is generated, sometimes a broken one. For example, large parts of the admin work absolutely fine, only the small popup windows in the presentation administration can't handle umlaut domains.
Sure, I could now use the xn-... form of the domain. But then this would also be visible to the outside, because TXP apparently generates these partially in absolute form and thus this base URL slips in with it. Hmm. Ugly.
Update: in any case, you should also make the call to set the character set to utf-8 in the textpattern/index.php file. This is responsible for the admin interface, if you don't do it, there are conflicts between the admin pages and the content pages. Because with the content pages, the corresponding call is made, so they are delivered with utf-8 as the character set in the server headers. The admin pages, however, are not - so it becomes iso-8859-1. Result: many modern browsers correctly prefer the character set from the HTTP header over the one specified in the file itself. And suddenly you get strange umlauts.
What I added is the following line:
header("Content-type: text/html; charset=utf-8");
And specifically before the $textarray = load(.....) call. At least this problem is then fixed. It's best to call up the existing elements once and save them again so they are correctly in the utf-8 character set. This also applies to international URLs in the Preferences, where you enter the domain of the site.
What still doesn't work is the Tag Builder window - the popups are called incorrectly, apparently with incorrectly encoded umlauts. Unfortunately, I can't verify this because of a bug in Camino, which refuses to display page content from international domains in the source.
International domains are a hack. And like with every bad hack, there are plenty of nasty problems. Update 2: as if to prove how hacky Punycode is and especially its support in browsers, I tested various other browsers today. Together with the ones from yesterday:
- Safari on Jaguar can't do Punycode at all
- Camino 0.8 can do it largely, but can't display source and the Tag-popups in TXP don't work (as I now know it's a browser bug)
- Mozilla Firefox 0.8 also handles it largely, only popups and source display don't work - same bug as with Camino (was to be expected, it's the same source base)
- IE can't do Punycode anyway, needs a plugin for that. I didn't test any further with that mess.
- various text browsers (lynx, w3m, links) don't work with Punycode either.
- Opera handles all aspects correctly.
Clear winner: Opera. So if you want to work with international domains (especially with Textpattern - but not only there), you should use Opera. Otherwise there are problems everywhere where hostnames are determined/generated - for example, the JavaScript links for the popups in TXP don't contain a hostname. The browser adds it internally. And incorrectly - but only when the popup is made. If instead the link is opened in a new tab via the context menu, everything works with Firefox and Camino.
Sorry, but the whole topic is absolute garbage.