Page MenuHomePhabricator

If page title contains Umlaut the link on edit page is wrong
Closed, DeclinedPublic


Author: hj-meyer

In the German version of Wikipedia it is possible without problems to use Umlaut letters in the page title. There is only one obstacle: when you edit the page and klick the save button, not the saved page will appear but an error page saying that this page does not exist and the title is not valid. But this is not the case. The page exists an can be accessed by a normal link. It is only the edit page/save button of that specific page that produces the error page.


Page URL: .../index.php?title=Qualit%C3%A4tsmanagement

correct link: [[Qualitätsmanagement]] (which is automaticly changed into the correct URL by the system: [[.../index.php?title=Qualit%C3%A4tsmanagement]]

edit page/save button link: [[.../index.php?title=Qualit%C3%A4tsmanagement&action=submit]]

This looks as if the save button produces the correct link, but this link than is not processed in a correct way.

As Umlaut letters are very common in German language, a solution would be very helpful.

Version: 1.10.x
Severity: normal
OS: Windows XP
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:50 PM
bzimport set Reference to bz10881.
bzimport added a subscriber: Unknown Object (MLST).

If that were the case, nothing would have worked for the last several years.

So... seems to work fine.

Can you show us *exactly* where this happens and how to reproduce it?

Is it on Wikipedia?

Or is it on your own server?

What browser? What software? What server? Etc.

hj-meyer wrote:


I did not mean Wikipedia but MediaWiki, sorry for that.


It happens on my installation:

on a hosted server (1&1 Germany), MySql

I opened a temporary test account for you to enter this site:

login:Testaccount pw:redhorse

it happens with ie7 and firefox 2006


In addition to my report I have now seen, that the errorpage contains two times a useless "25":

There seems to be some kind of interference with the HTTP redirects which is adding a double-escape.

To confirm what level it's at, could you try putting up the following little PHP script?


Please let me know the URL to this script so I can poke at it and see what the returned headers are.

hj-meyer wrote:

Could my .htaccess file have caused this error:

AddType x-mapp-php5 .php

RewriteEngine On

RewriteCond %{HTTP_HOST} ^fb3-fh-frankfurt\.de$ [NC]

RewriteRule ^(.*)$$1 [R=301,L]

hj-meyer wrote:

From my point of view: not resolved!

robchur wrote:

WORKSFORME refers to the condition where things are behaving as expected for most people, and where the problem is likely due to local misconfiguration. Since BugZilla is not a support tracker, we don't keep "support bugs" open for long.

hj-meyer wrote:

I am sorry if I gave the impression that I meant this bug tracker should solve a possible misconfiguration on my server. What I meant was that from my point of view there is a bug in the German localisation (which of course could also be seen as a "local misconfigurating" not affecting "most people").

Maybe I misunderstood Brion not posting any further comment after testing my system. Did he/you find out positivly that the error is due to misconfiguration on my server and not a bug of the German localisation?

I would appreciate any hint.

There is no bug in the German localization, certainly none known.

There is probably a bug in your server's configuration or your server software. I'm still waiting for you to fix the problem I mentioned in my reply to your email so I can test that script I had you put up.

hj-meyer wrote:

I am sorry but I didn't receive your reply on my email. Could you post it here? Thank you.

Dear Brion,

Thank you for your help.

The address of the PHP script is:

Can you remove the line breaks from the strings? Those need to be on one
line each.

Could my .htaccess file have caused this error:

AddType x-mapp-php5 .php

RewriteEngine On

RewriteCond %{HTTP_HOST} ^fb3-fh-frankfurt\.de$ [NC]

RewriteRule ^(.*)$$1 [R=301,L]

Possibly, though that _should_n't be applying to the vhost.

  • brion

hj-meyer wrote:

Thank you. I have removed the line breaks, sorry.

Ok, I can confirm that the minimal script redirects correctly. With some further testing and your rewrite rule to compare against, I think we've got it figured out.

For an example without editing, first we hit the wiki with a non-normalized URL like this one -- the page title here is lowercase 'é':

The wiki sees the lowercase letter 'é' and redirects us to the canonical capital form 'É', just as it redirects us to view a page after editing:
HTTP/1.x 301 OK

The interesting thing here is that we got redirected to the hostname *without* 'www.' on the front: That would most likely be because the web server is telling PHP that '' is its hostname, so MediaWiki obeyingly uses this hostname when constructing full URLs, such as the HTTP spec requires for Location: headers in redirects.

Now, the browser makes the request:

which hits your rewrite rule and gives us back the mangled URL:

HTTP/1.x 301 Moved Permanently

There are two things you want to fix here.

First, fixing the rewrite rule which mangles your redirects; you might try the 'noescape' or 'NE' option on the rewrite line, but I'm not sure whether it'll help:

RewriteRule ^(.*)$$1 [R=301,NE,L]

Second, tweaking the setup so that you don't go through these extra redirects in the first place. I recommend setting the ServerName directive in Apache if possible:


If that's not possible, you can override the detection in MediaWiki by adding this to LocalSettings.php:

$wgServer = '';

That should send you to your preferred URL in the first place (with the www.), avoiding the extra layer of redirects.

hj-meyer wrote:

Thank you very much! I just fixed the rewrite rule adding the
'noescape' or 'NE' option on the rewrite line, and now it works.

So, in the end, it was "local misconfiguration", sorry again.