Page MenuHomePhorge

Help link in Metrolook sidebar takes you to MediaWiki's Help:Contents
Open, NormalPublic

Description

This should point to the local Help:Contents, instead.

Event Timeline

Some background info on this: a while ago (when? I can't remember and I'm too lazy to look it up) a bunch of system messages (which link to help pages) were changed to point to MediaWiki.org help pages by default. This makes sense (for most MediaWiki users), because MW.org's help pages are "licensed" into the public domain, are guaranteed to be at least somewhat up-to-date and that way users don't necessarily have to copy the pages to their local wiki(s).
Currently (as of MediaWiki 1.26.3) there are 11 matches for Special:MyLanguage and 28 matches for mediawiki.org in /languages/i18n/en.json. Of these, the following are "user-facing" and might need to be customized for ShoutWiki:

  1. MediaWiki:Edithelppage (used on action=edit)
  2. MediaWiki:Helppage (used on the sidebar, MediaWiki:Sidebar, by default, IIRC)
  3. MediaWiki:Helplogin-url (used on Special:UserLogin)

Now for the complicated part...

So the default value of MediaWiki:Helppage is an external URL pointing to MediaWiki.org. In PHP code this isn't a problem as MediaWiki uses Skin::makeInternalOrExternalUrl to figure out what kind of a link it should generate. Unfortunately for the average user, the Parser isn't quite that smart, and with the default value of MediaWiki:Helppage, this won't quite fly:

[[{{MediaWiki:Helppage}}|{{int:help}}]]

The intention here, of course, is to provide a link to the help page with the link's title (MediaWiki:Help, which has the default value of Help, surprisingly!) localized to the user's prefered language, but [[link URL|link title]] is not valid wikitext syntax when talking about MediaWiki's wikitext (Phabricator is a different beast, of course, as it uses that exact syntax for external links...d'oh).
A real-world use case for this is the various [[http://mwmsg.shoutwiki.com/wiki/MediaWiki:Recentchanges-summary/es|MediaWiki:Recentchanges-summary messages, such as this Spanish one]].

So what do we do?

We've customized the default value of MediaWiki:Helppage so that it uses an interwiki link instead of an external link. This preserves the MediaWiki software default behavior without breaking the way how we use that message in the MediaWiki:Recentchanges-summary messages.

It all boils down to languages. For a few select languages, namely English (en) and Finnish (fi), we've customized the language-appropriate MediaWiki:Helppage messages to point the help link to the local page (Help:Contents) instead of MediaWiki.org.

Currently our CreateWiki is available in 5 languages: English (en), Finnish (fi), French (fr), Dutch (nl) and Chinese (zh-hans/zh-hant). So if you want to start a wiki on ShoutWiki, you need to know one of those languages. But you can use ShoutWiki in any language supported in MediaWiki core: German (de), Spanish (es), Russian (ru), Arabic (ar)...and many, many more. So eventually we have users who need help in using MediaWiki/ShoutWiki in their language, but for whatever reasons we're not able to provide that (for example, we don't have an Arabic speaker in the staff team right now). Should we be linking these users to our English help pages at ShoutWiki Hub, which they probably won't understand, or to a useless redlink on their local site, or to MediaWiki.org? In my opinion, MediaWiki.org is the smartest choice out of these three options.

To "fix" the underlying problem properly, we need to figure out a way to make the local ShoutWiki Hubs more active and motivate people into translating our English help pages into their language, after which we can activate that language in SharedHelpPages. (But before that, we should probably go through all these help pages and review 'em. Anyway, that's for a different ticket...) Right now ShoutWiki Hub is available in a handful of languages, and even of those, only the Finnish (fi) site has enough translated help pages that we've been able to activate that language in SharedHelpPages' configuration.

tl,dr: There probably isn't a technical issue to be fixed here, real the above wall of text to find out why.