User:crb

System components should be built as packages and installed using dpkg/apt, not installed from source in /opt. Aside from the implications of security updates, you are causing customers to require a full compiler toolchain on their machine.

http://bugs.developer.mindtouch.com/view.php?id=8716

@marcmuylaert: in LocalSettings.php, add the line $wgDisabledDekiPlugins[] = 'page_content_rating';

As Debian Etch is no longer supported, the instructions for installing on this version should be removed.

I could have sworn MW did it the way I expected. Maybe it was another product. :) (P.S. it seems every edit you make triggers the email notification. Thought I was going mad, getting these all twice...)

@crb from what I can tell, MindTouch has the same (inherited) behavior as mediawiki in the sense that the redirects are followed transparently. The URL on browser is the same as what you clicked by the content comes from the redirect target. Looks like thats still the current behavior in fact: http://www.mediawiki.org/wiki/User:Maxim11/myredirect I do agree that it is a little confusing. You do get a message saying that a redirect was followed but it may not be enough. As long as we still have a mechanism to allow users to modify the redirect, I don't see a reason to not use a 301 and have the real page URI reflect what your browser URI reports.

@crb from what I can tell, MindTouch has the same (inherited) behavior as mediawiki in the sense that the redirects are followed transparently. The URL on browser is the same as what you clicked by the content comes from the redirect target. Looks like thats still the current behavior in fact: http://www.mediawiki.org/wiki/User:Maxim11/myredirect I do agree that it is a little confusing. You do get a message saying that a redirect was followed but it may not be enough. As long as we still have a mechanism to modify the redirect, I currently don't see a reason to not use a 301 and have the real page URI reflect what your browser URI reports.

The standard MediaWiki way seems acceptable: you end up at the new page (in the URL - which was previous MT behaviour iirc?) with a note saying "Redirected from X". You could make it say "Redirected via X -> Y -> Z" if you wanted a chain, and have each part clickable. I don't care just for SEO benefits - it's confusing when you start a page under your user page, and then move it to the regular hierarchy; people who hit the old URL still see the old URL, leading them to think the page isn't new or authoritative.

@crb, agreed -- the forwarding behavior can get some consideration as part of this spec. I think it's important to let a human user know one way or another that the link they clicked bounced them to another location. And the UI needs to allow a way to make changes to the redirect which means it has to know which redirect was followed. The location header in the 301 response can include a query parameter describing which link was clicked. Would that reduce the SEO benefits if the 301s leading to the definitive page had different values of a query param?

@crb, agreed -- the forwarding behavior can get some consideration as part of this spec. I think it's important let a human user know one way or another that the link they clicked bounced them to another location. And the UI needs to allow a way to make changes to the redirect which means it has to know which redirect was followed. The location header in the 301 response can include query parameters describing which link was clicked. Would that reduce the SEO benefits if the 301s leading to the definitive page had different values of query params?