@MZMcBride: Do you plan to add more information for a completely new MediaWiki contributor to the task description, or why did you add good first task?

In T208315#4709703, @Aklapper wrote:

@MZMcBride: Do you plan to add more information for a completely new MediaWiki contributor to the task description, or why did you add good first task?

Hi @Aklapper. Thank you for volunteering to help resolve this task! This task is about adding an HTML class such as mw-user-can-probably-edit or similar to the page HTML output. We're already doing something very similar currently in the HTML output with "wgIsProbablyEditable":false,"wgRelevantPageIsProbablyEditable":false. You can re-use this check or do the same check to add a class to the HTML output. This is what @Krinkle is describing in T207648#4701665. Please let us know if you need any further help to get started.

Thanks a lot MZ, that's helpful info!

Hey there, this is an interesting idea. Can you please document where there is discussion about this being a good idea, and what the use cases are? I assume that T207648 is the principle use case, but an on-wiki gadget on Wikidata could achieve the same for all desktop users who run JS today (using wgIsProbablyEditable). This specific proposal would bloating all Wikimedia traffic by ~13GiB a day (25 bytes/req x ~540 M reqs/day). We should be spare in expenditure of readers' bandwidth.

The first purpose is to provide the Wikipedias the possibility of hiding links to a Wikidata item from users who can't edit its corresponding article. But I assume this HTML class is a totally useful feature for any MediaWiki installation.

If the expenditure of readers' bandwidth is a relevant problem, I'm sure I can easily save you some bytes in the Spanish Wikipedia to compensate. ;-) Right now the content (wikitext) of most Wikipedia pages isn't optimized at all but I don't see any special care in reducing the size of the most used templates, site notices, etc. Wouldn't the use of JS be also an expenditure of readers' bandwidth?

In T208315#4715615, @abian wrote:

The first purpose is to provide the Wikipedias the possibility of hiding links to a Wikidata item from users who can't edit its corresponding article.

Oh, so the use case is on Wikipedias (and other Wikimedia sites), not on Wikidata.org? We could just alter the code that inserts the Wikidata link into the "Tools" section, couldn't we?

But I assume this HTML class is a totally useful feature for any MediaWiki installation.

Yeah, I'm looking for other reasons to do this specific idea. :-)

If the expenditure of readers' bandwidth is a relevant problem, I'm sure I can easily save you some bytes in the Spanish Wikipedia to compensate. ;-) Right now the content (wikitext) of most Wikipedia pages isn't optimized at all but I don't see any special care in reducing the size of the most used templates, site notices, etc.

We developers can't do much about the content people write, so we focus on everything else.

Wouldn't the use of JS be also an expenditure of readers' bandwidth?

Yes, but only readers of Wikidata.org, which is a tiny fraction of the number of people affected if we change something for all users. However, now you've explained your idea (hiding the link to Wikidata rather than hiding the edit labels on Wikidata), doing things in JS on Wikidata.org only wouldn't achieve that goal.

In T208315#4715897, @Jdforrester-WMF wrote:

Oh, so the use case is on Wikipedias (and other Wikimedia sites), not on Wikidata.org? We could just alter the code that inserts the Wikidata link into the "Tools" section, couldn't we?

It's more complex. We should, for instance, hide the links with a pencil icon at https://es.wikipedia.org/wiki/Douglas_Adams?uselang=en and the links at the bottom of infoboxes, which are great sources of vandalism (the "Tools" section would be less relevant). This has to be done wiki by wiki, so it's important to give the communities an easy mechanism (the HTML class) to hide or show content depending on if someone can edit a page or not.

Lydia Pintscher explains on T205783 the pattern that we should mitigate:

When contentious topics show up in the news vandalism on the Wikipedia articles related to it usually shows up pretty quickly. The article then might be protected for some time in order to prevent more vandalism. A pattern we are seeing now is that people then move over to Wikidata and continue their vandalism there. (This might then in turn lead to vandalism showing up in the article anyway if it uses the data.) This especially happens when an infobox has "edit on Wikidata" links or something similar.

In the past we already wondered how to hide these links, but it was only possible (or known) to show or hide the links depending on the protection status of each article (and by using expensive Lua functions).

In T208315#4715897, @Jdforrester-WMF wrote:

Yeah, I'm looking for other reasons to do this specific idea. :-)

It would be probably good for some MediaWiki installations to show different instructions as a part of the page content depending on if users can edit the page (how to, or what to edit) or not (where to request a change, how to sign up, etc.). Maybe other users could provide more ideas. Clearly, the application that matters the most to me (and other volunteers) right now is the one about showing/hiding links to Wikidata.

Sounds good enough for me. Let's do it.

Change 472589 had a related patch set uploaded (by Abián; owner: Abián):
[mediawiki/core@master] Add class mw-editable in body element

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

Change 472589 merged by jenkins-bot:
[mediawiki/core@master] Add class mw-editable in body element

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