What about wikis already have such a help link in the UI like dewiki (see https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/MediaWiki:Specialpage-helplink&limit=500&hidelinks=1 for all usages)

They should switch to the usage of indicators, using the same ID. This *should* suppress the default link.

What about the local help pages like linked from https://www.wikidata.org/wiki/Q395887?
Why hard linking to mw.org? There should be a way to allow the local community to override the target of the help page.

Local help pages are available on very few languages, but sure, customisation should be possible for wikis which care about it. Are the provided CSS class+id and the indicator system insufficient for customisation?

on de.wikipedia.beta.wmflabs.org we have changed the id, but it does not override it, see http://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Verschieben/MediaWiki:Movepage-summary for the place where the wrong help link is shown and http://de.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Movepage-summary for the message where the indicator is used.

This seems to be happen because OutputPage::setHelpLink is called later than SpecialPage::outputHeader and than override the indicator ("In case of duplicate keys, existing values are overwritten."). OutputPage::setIndicators needs a explicit not-overwrite-option which than can be used from OutputPage::addHelpLink.

Or we can switch the order. Did you try CSS, though?

Switching order needs to be checked for each call in core.

Hiding with css would work, but not tested yet.

Change 195045 had a related patch set uploaded (by Nemo bis):
Don't require JavaScript for addHelpLink styles

https://gerrit.wikimedia.org/r/195045

Change 195045 merged by jenkins-bot:
Don't require JavaScript for addHelpLink styles

https://gerrit.wikimedia.org/r/195045

In T45591#1088866, @gerritbot wrote:

Change 157497 merged by jenkins-bot:
Add top help link to MediaWiki.org in several pages via indicator

https://gerrit.wikimedia.org/r/157497

This uses a non-standard icon that doesn't match the any skin and did not go through Design. It also does not have an SVG or High-resolution version available. Thus regressing from our state of having HiDPI-friendly pages by default.

The icon would be okay for a local gadget, but not MediaWiki core.

I don't know further context, but I imagine if this is not changed it will need to be reverted and further worked upon for the next deployment window.

In T45591#1102455, @Krinkle wrote:

I imagine if this is not changed it will need to be reverted and further worked upon for the next deployment window.

That strikes me as somewhat of an overreaction. If the icon irks you, then it's a one-line change to remove it. It would be almost as easy to replace it with a different one, too.

I agree the icon needs to be improved. Do you have suggestions for a SVG-ready icon to use?

That's the icon closest to a "standard" that we currently have in the codebase for this purpose: it's used in a MediaWiki extension already, for several special pages. We must improve it before we extend its usage to more visible places, of course.

Are you talking about the blue "?" for 'help'?

For what is worth, WikiFont has an icon from @violetto called Sun help. I couldn't find any incon with "?" in the collection.

Needless to say, in Commons there are many SVGs of question mark signs in a blue circle, but... See https://commons.wikimedia.org/wiki/File:Blue_question_mark_icon.svg & friends.

Indeed, it seems that a "Help" icon was not considered for the new icon set.

VisualEditor / OOjs UI has a icon for this, though:

https://tools.wmflabs.org/oojs-ui/oojs-ui/dist/themes/mediawiki/images/icons/help.svg
https://tools.wmflabs.org/oojs-ui/oojs-ui/dist/themes/mediawiki/images/icons/help.png

Presumably that could be used. If you need it now, the file will have to be just copied into mediawiki/core, as the work on making the icons available has stalled a bit. (It is MIT-licensed, like the rest of OOjs UI.)

In T45591#1103929, @matmarex wrote:

In T45591#1102455, @Krinkle wrote:

I imagine if this is not changed it will need to be reverted and further worked upon for the next deployment window.

That strikes me as somewhat of an overreaction.

It needs improvement before deployment. It wasn't my feature to implement and would not have been merged as-is in that case. As such, a revert is just returning status quo and enforcing quality criteria.

Change 194411 merged by jenkins-bot:
Add help link to three other "minor" special pages

https://gerrit.wikimedia.org/r/194411

Change 197667 had a related patch set uploaded (by Bartosz Dziewoński):
mediawiki.helplink: Use standard SVG PNG icon

https://gerrit.wikimedia.org/r/197667

In T45591#1104151, @matmarex wrote:

Indeed, it seems that a "Help" icon was not considered for the new icon set.

That's T90414: Use consistent help icon in VE, Echo, and elsewhere

VisualEditor / OOjs UI has a icon for this, though: . If you need it now, the file will have to be just copied into mediawiki/core,

FWIW the icon is reachable, https://bits.wikimedia.org/static-1.25wmf21/resources/lib/oojs-ui/themes/mediawiki/images/icons/help.svg, so url(../../lib/oojs-ui/themes/mediawiki/images/icons/help.svg) works. I guess there's no cleaner path to library resources.

as the work on making the icons available has stalled a bit.

? They're all available if you use OOjs UI (cool demo). If we're making them available to non-OOjs UI code I look forward to documenting how-to.

One small question on https://gerrit.wikimedia.org/r/#/c/197667/2

FWIW, aside trivia:

• There's also a SVG version of the current help.png, but it's not a native one (014b5632fcc6a4200d519cf7f86e94c09639af8f).
• Personally I prefer a more "standard" (i.e. common) blue, but it doesn't matter.
• VE is not "standard", both are icons taken from extensions and made by WMF.

Change 197667 merged by jenkins-bot:
mediawiki.helplink: Use a SVG PNG icon

https://gerrit.wikimedia.org/r/197667

In T45591#1129825, @Spage wrote:

FWIW the icon is reachable, https://bits.wikimedia.org/static-1.25wmf21/resources/lib/oojs-ui/themes/mediawiki/images/icons/help.svg, so url(../../lib/oojs-ui/themes/mediawiki/images/icons/help.svg) works. I guess there's no cleaner path to library resources.

True, but we were never doing that in the past (I think we even have duplicate copies of some files used in mediawiki/core, in different directories). We never had url(…) paths that refer to parent directory, and I think we should keep it this way, easier to figure out what depends on what.

as the work on making the icons available has stalled a bit.

? They're all available if you use OOjs UI (cool demo). If we're making them available to non-OOjs UI code I look forward to documenting how-to.

Yes. From T92551: "Map to .mw-icon-<whatever> classes in addition to .oo-ui-icon-<whatever>".

In T45591#1134815, @Nemo_bis wrote:

• Personally I prefer a more "standard" (i.e. common) blue, but it doesn't matter.
• VE is not "standard", both are icons taken from extensions and made by WMF.

OOjs UI's icons are supposed to become "MediaWiki UI" icons, and thus be pronounced the standard ones. There are bumps along the way because the OOjs UI team (subset of WMF Editing) and the MediaWiki UI team (subset of WMF Design) have been disagreeing about which icons should be a part of this set, and how they should be drawn. You can see the current status at https://tools.wmflabs.org/oojs-ui/oojs-ui/demos/#icons-mediawiki-vector-ltr – this has both the old OOjs UI icons (known from VisualEditor) and the new MediaWiki UI icons (known from Flow), and it is quite obvious that these are separate sets. (The 'help' icons comes from the old set, since for some reason it was not considered for including in the new one.) The current status is that Trevor is beating some sensworking with the designers to iron it out.

Outstanding patches:

• https://gerrit.wikimedia.org/r/#/c/194418/ "[WIP] Add link to Meta-Wiki help pages from several special pages"
• https://gerrit.wikimedia.org/r/#/c/194414/ "Add help link to three rather important pages"

In T45591#1139318, @matmarex wrote:

Outstanding patches:

• https://gerrit.wikimedia.org/r/#/c/194418/ "[WIP] Add link to Meta-Wiki help pages from several special pages"

This is the one which needs most discussion/help. MediaWiki help pages can't lack coverage of RecentChanges and Watchlist... either they are rewritten on MediaWiki.org or we should change the rules to adopt/incorporate Meta-Wiki docs.

This is an interesting feature for small WMF wikis and external sites, but would confuse users on wikis with well equipped user guidance (e.g. English or German Wikipedia).

• Most confusing are two offers, which might happen in German Wikipedia right now.
• Local pages often provide local policies (deletion!) and specific links to related project pages which cannot be achieved with a world wide non-WMF general explanation.
• https://www.wikidata.org/wiki/Q395887 shows present local support just for one issue. I count 60 existing local pages. (The 61st would be: mw:Help:Moving_a_page)

Local confguration needs more emphasis.

• At least a system message should be taken into account by the implementation.
• Icons might be cultural dependant (CJK, arabic, hebrew) and should be configurable per system message – a greek question mark is a semicolon.

Rather than maintaining system messages for each page by each project, a wikifarm with a wikibase could make use of that knowledge. (Okay, WMF might be the only one, but is among the top ten websites)

I would like to see in CommonSettings.php something like

$wgHelpPages = array()

That may be used explicitly to hard-code page links by any other site.

However, one entry could look like

$wgHelpPages['special-movepage']['item'] = 395887;

For performance reasons evaluation of the wikibase item is probably not desirable each time a special page is requested by readers.

• Every 24h or once a week that array might be populated and refreshed like:

$wgHelpPages['special-movepage']['pages'] = array(
          'alswiki' => 'Hilfe:Artikel verschieben',
          'dewiki' => 'Hilfe:Seite verschieben',
          'enwiki' => 'Wikipedia:Moving a page',
          ...

• Time scheduling and triggering the update might be controlled by something like

$wgHelpPages['UpdateInterval'] = 24;

• The same entries might be provided manually by external sites which happen to have their own guidance, but no wikibase and no update service.

I wonder whether the entire helppage link business should stay in core or should be turned into an extension.

• A (help/any) page mapping and linking mechanism might be used in many fields, not only with special pages.
• Various configurations done with system message today might migrate towards wikibase in the future.
• The MW TemplateData gadget e.g. could be equipped by https://www.wikidata.org/wiki/Q14505594 rather than [[MediaWiki:templatedata-helplink-target]].

In T45591#1159175, @PerfektesChaos wrote:

Local confguration needs more emphasis.

• At least a system message should be taken into account by the implementation.

This is valid point which can have it's own task.

• Icons might be cultural dependant (CJK, arabic, hebrew) and should be configurable per system message – a greek question mark is a semicolon.

This can also be a separate task. We already do localised images in couple of places. I do disagree though that it needs to be configurable per system message.

Rather than maintaining system messages for each page by each project, a wikifarm with a wikibase could make use of that knowledge. (Okay, WMF might be the only one, but is among the top ten websites)

This can already be achieved with the approach WikimediaMessages is using if we implement overrides with system messages.

I would like to see in CommonSettings.php something like

Your proposal sounds very complicated, we already have standard way to handle these as explained above.

I wonder whether the entire helppage link business should stay in core or should be turned into an extension.

It was just moved to core so that each extension does not implement a different way to do it. Definitely not to be moved to an extension.

Change 194414 merged by jenkins-bot:
Add help link to three rather important pages

https://gerrit.wikimedia.org/r/194414

Change 202968 had a related patch set uploaded (by Legoktm):
Add help link to three rather important pages

https://gerrit.wikimedia.org/r/202968

Change 202968 merged by jenkins-bot:
Add help link to three rather important pages

https://gerrit.wikimedia.org/r/202968

Thanks Legoktm! If there is interest in a backport I can work on https://gerrit.wikimedia.org/r/#/c/194418/ this week.

https://commons.wikimedia.org/wiki/Commons:Village_pump#Help_topicons_linking_to_external_help_pages_soon_displayed_everywhere.3F

In T45591#1139342, @Nemo_bis wrote:

In T45591#1139318, @matmarex wrote:

Outstanding patches:

• https://gerrit.wikimedia.org/r/#/c/194418/ "[WIP] Add link to Meta-Wiki help pages from several special pages"

This is the one which needs most discussion/help.

The pages in question are:

• https://meta.wikimedia.org/wiki/Help:User_contributions
• https://meta.wikimedia.org/wiki/Help:Export
• https://meta.wikimedia.org/wiki/Help:Import
• https://meta.wikimedia.org/wiki/Help:Linksearch
• https://meta.wikimedia.org/wiki/Special:MyLanguage/Help:Recent_changes
• https://meta.wikimedia.org/wiki/Help:Related_changes
• https://meta.wikimedia.org/wiki/Help:Watching_pages
• https://meta.wikimedia.org/wiki/Help:What_links_here

Just had a look at http://git.wikimedia.org/blob/mediawiki%2Fcore.git/0a33db75cb2afd0879512b7a3cc2ec5b63d9ae5e/includes%2FOutputPage.php#L1408 . Hardcoded url? No message? Are you serious?

Already disabled on dewp (https://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=140838650&oldid=140486784).

Including some help is a good idea, but the implementation should be improved so that the url is not hardcoded.

In T45591#1231734, @Multichill wrote:

Already disabled on dewp (https://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=140838650&oldid=140486784).

And i am inclined to switch this of on commons... It is not helpful. It is not linking to the commons policy's, but to some MW page.

Change 208378 had a related patch set uploaded (by Nemo bis):
Allow to customise addHelpLink() target via system message

https://gerrit.wikimedia.org/r/208378

Change 208378 merged by jenkins-bot:
Allow to customise addHelpLink() target via system message

https://gerrit.wikimedia.org/r/208378

Change 211100 had a related patch set uploaded (by Nemo bis):
Allow to customise addHelpLink() target via system message

https://gerrit.wikimedia.org/r/211100

Once rMW8082c5f4f0a6 is merged, this can be closed. Adding new help pages and links will then be an ongoing process as part of [[Project:PD Help]], as well as an easy matter of customisation by local wikis where needed.

Change 211100 merged by jenkins-bot:
Allow to customise addHelpLink() target via system message

https://gerrit.wikimedia.org/r/211100

Change 194418 merged by jenkins-bot:
Add help link for 8 more special pages

https://gerrit.wikimedia.org/r/194418

• https://gerrit.wikimedia.org/r/194418 (branch master): MW-1.26-release, WMF-deploy-2015-06-09_(1.26wmf9)

I've just had a third-party wiki wondering what the point of this is, and as such, how to disable it

[15:31:40] <AA-Andrew> I can't really see how it's helpful for it to Link to a media wiki help page though

Of course, hiding it with CSS isn't really disabling it, you're still loading the various assets.

Should there be some sort of config flag for it? I'm not sure...

It seems a bit blanket statement to say all of those help link are unhelpful. I would argue they are more helpful than harmful and thus there is no need to be able do disable them altogether.

In T45591#1411185, @Nikerabbit wrote:

It seems a bit blanket statement to say all of those help link are unhelpful. I would argue they are more helpful than harmful and thus there is no need to be able do disable them altogether.

Maybe, maybe not. That's a third party wiki view. I can see it both ways; especially for a wiki that's not open to the public for editing, but is for public viewing. YMMV. Literally just passing on what I was told.

Imho it is understandable, when there is a link to a help page for an action or feature that a specific wiki does not offer, or at least not to the general viewer, that they want the help link not shown. Thus we should possibly make help pages very modular and independent of one another and avoid cross-linking them for the things that are based on different user rights that can be assigned individually to users or groups. Also, help links should only appear on pages where the individual feature is available.

I do not know whether that is good and sufficient. At least, it contradicts the idea of offering the user a good and comprehensive Overview.

Last not least, we can have wikis copy the common help pages wholesale or individually as need be, and use their local copies which they can edit to their needs.

Tried to figure out why some special page has a link to a local help page, and some has help pages at Meta and some at Mediawiki, but the previous -helppage system messages does not make sense anymore? Where is the doc for this?

A local help page for WhatLinksHere has no -helppage link, so tried to move the help page to check if there was some checks on page existence, but no change, the local page is still in use somehow.

You can still use MediaWiki:Whatlinkshere-helppage to override the default help link on Special:WhatLinksHere (and similar for all other special pages). You can also use such messages for override/add help links for namespaces (e.g. MediaWiki:Namespace-0-helppage) and page actions (e.g. MediaWiki:History-helppage).

I don't know if this is properly documented anywhere, I just looked up how it works in source code.

The default value is unfortunately not shown on these pages, due to the way we use these messages. Perhaps this could be changed to make these messages behave more normally, but as a consequence, users with non-default interface language would not see the local override (currently they do).

Almost all of the built-in help links go to MediaWiki.org. There are only three exceptions: the help links for history action, Special:Import and Special:RecentChanges all go to MetaWiki. Presumably the documentation pages for these on MediaWiki.org are inferior.

I am afraid the lack of a doc in mw: is the major problem here.

Code fragments are distributed over many PHP units, and not really accessible to Wiki maintainers.