Item13093: NatSkin Attachments cannot be retrieved when attached to Topic with Umlaut

The Problem: I change the skin of a vanilla Foswiki 1.2.0_999 to NatSkin, create a Topic, lets say DünenRöcke, and save an attachment (HäuserBauen.txt) to it. When I try to access the attachment, I get an error message that the attachment doesn't exist. The problem seems to stem from a double encoding - the failing link to the attachment is

.../pub/Main/D%C3%BCnenR%C3%B6cke/H%E4userBauen.txt?t=1415669510

but it should be

.../pub/Main/D%fcnenR%f6cke/H%e4userBauen.txt

Note the wrong encoding is just on the topic name; the name of the attached file is encoded correctly.

What's interesting is that when I choose "Create a link to the attached files at the end of the topic" in the attach dialog, the link that's added to the topic text works just fine. It's only the link in the attachments section that doesn't work.

My configuration:

I created a vanilla Foswiki installation of the git trunk using git clone (just now - commit c0b73dd217188f331940199cbce92b059870f9a4), then added NatSkin and all the extensions listed as required for NatSkin (commit 3213e88ac7f21e72a3126d0606bab5c3a0904356), also from github. I have a script that reproduces this installation on a Ubuntu linux host if anyone needs it. I left all the configure settings at their default values except the store (RcsWrap). AfAIK, I have all the dependencies I need - at least there are no error messages in any of the logs. Since I didn't change any settings, my Foswiki is using an iso8859-1 site charset (I did try to change this to utf8 to maybe get rid of the problem but then things started breaking badly within NatSkin (that would be another bug report in itself), so that doesn't seem to be an option). What might be relevant is that my linux installation is using utf8 for all the installed locales, not iso-8859-1, but I'm not sure if this matters when Foswiki's UseLocale setting is 0.

-- PascalSchuppli - 11 Nov 2014

How did you create the DünenRöcke topic?

Using the "New" button on NatSkin should rewrite any free-form text while you type creating a proper WikiWord.

Topics with umlaute in them should be avoided at all cost. There are a lot more problems than the ones that you've found.

That's why NatSkin supports the notion of "TopicTitles".

TopicNames (aka WikiWords) appear as part of the URL (source of problems), as well as part of the filename on the operating's filesystem (source of problems).

TopicTitles are stored as a preference setting and are used to render a link to the topic.

-- MichaelDaum - 11 Nov 2014

I entered the DünenRöcke right in the Text (like here) and then clicked on it to create it.

I'm aware of the pandora's box of Umlauts and I would never create Topics with Umlauts in them myself (I've been wrestling with Umlaut problems in Fowsiki/TWiki for more than 8 years now...), and I appreciate your NatSkin efforts greatly; they make Foswiki very user-friendly. However, I can only discourage my user base, not enforce the "never create Topics with Umlauts in them directly" rule in my organization and the problem with these Umlauts is noticeable enough that people will use it as a reason not to trust/use the Wiki - "if it can't even do something that simple,...." So I'm trying to eliminate all the obvious encoding problems. I'm not worried about other things that aren't so noticeable.

Maybe the best solution in such an environment would be to use a cronjob to periodically rename all Umlaut topics, and I might do that, but it seems to me that in my setup iso8859-1 umlauts mostly work without creating serious problems except for this fairly common use case I describe, and it would be great if that could be made to work, too. If you can give me a hint on where to look for the double encoding problem, I can probably create a patch that works for me, at least.

-- PascalSchuppli - 11 Nov 2014

Try TopicNameValidationPlugin maybe.

-- MichaelDaum - 11 Nov 2014

Oh. So I can enforce the "no Umlaut in Topic names" rule. Thanks for the hint. It's not quite as good as working Umlauts, but it helps.

-- PascalSchuppli - 12 Nov 2014

Just tested on 1.2.0 (unicode) and it works fine there, so closing.

-- Main.CrawfordCurrie - 24 Jun 2015 - 15:41

Commenting is disabled while not logged in