Page MenuHomePhabricator

Ability to turn off Sister project links
Closed, InvalidPublic

Description

There should be ability to turn off Sister project links completely. Either via some $wg... variable or MediaWiki message (more flexible, because it can partially solve T127673: Ability to set up order and presence of sister projects links in sidebar using eg. {{#switch:{{NAMESPACE}}|...}})

Event Timeline

Please provide a usecase for the "should be", and why personal custom CSS won't be sufficient here.

Do you mean on a per user basis? (I see no reason to add support for that, just as we don't have a toggle to turn off interlanguage links.)

Or do you mean to turn them off on an individual article, similar to the {{noexternallanglinks}} magic word to suppress Wikidata language links?

Do you mean on a per user basis? (I see no reason to add support for that, just as we don't have a toggle to turn off interlanguage links.)

Or do you mean to turn them off on an individual article, similar to the {{noexternallanglinks}} magic word to suppress Wikidata language links?

Per site as the very minimum. Further abilities are in T127673: Ability to set up order and presence of sister projects links in sidebar (there, because its solution is closer to that task than this).

Don't compare with interlanguage links - while these have never been part of the page content, sisterproject links were/are and sisterprojects in sidebar do not completely replace them and basically create the redundancy which actually can easy become confusing (see below).

In fact, if wikis wanted that feature, they would have turned on some gadget doing that ages ago, but as seen on most majority of wikis, there is none. So obviously there is no such a big need or even desire, fortiori urge for such feature. Various wikis use various ways how to display sisterproject links (infoboxes, sister project boxes, common sister projects box, "other projects" section, footer...) and they have reasons for that.

Also: While there will be support only for 1:1 linking, such feature does not have any sense at least on pages where there is either more links to one sister project or link to relevant item which is not 1:1. One example on behalf of many others: band member quotes on Wikiquote with sisterproject link to the band article on Wikipedia (because due to notability there are no articles about single members) and vice versa - band article on Wikipedia having couple links to Wikiquote to its members quote pages.

In fact, if wikis wanted that feature, they would have turned on some gadget doing that ages ago, but as seen on most majority of wikis, there is none. So obviously there is no such a big need or even desire,

That argument might be a fallacy as someone needs to have the skills to write such a gadget and maintain it.

Could you provide a usecase for the "should be", and why personal custom CSS won't be sufficient here?

why personal custom CSS won't be sufficient here?

I think we've established that. In any case, without community consensus there is really nothing to do here. AFAIK Lydia was more than happy to honor community requests to turn off this feature (this has been done on nlwiki).

In fact, if wikis wanted that feature, they would have turned on some gadget doing that ages ago, but as seen on most majority of wikis, there is none. So obviously there is no such a big need or even desire,

That argument might be a fallacy as someone needs to have the skills to write such a gadget and maintain it.

Not at all. There are bunch of gadgets used around without necessity to write them. They are simply linked from other sites. Typical example is HotCat.

Could you provide a usecase for the "should be", and why personal custom CSS won't be sufficient here?

Obviously because it is site feature and not personal, which you would have realized if you have read the task description and my previous post really carefully and thought about that a bit.

why personal custom CSS won't be sufficient here?

I think we've established that. In any case, without community consensus there is really nothing to do here. AFAIK Lydia was more than happy to honor community requests to turn off this feature (this has been done on nlwiki).

There was no community consensus to turn it on at first.

It should have been introduced as opt-in feature, not enforced (Another media-viewer and superprotect? - Paradoxically it was German community which was most sensitive to those and now it is them who do what they disliked.) nor opt-out.

Obviously because it is site feature and not personal, which you would have realized if you have read the task description and my previous post really carefully and thought about that a bit.

I refered to adding a line #p-wikibase-otherprojects {display: none} to /Special:MyPage/vector.css but I now see that @TTO already covered that in T127674#2055088 (thanks).
@Danny_B: No need to choose a tone that could come across as passive-aggressive.

Obviously because it is site feature and not personal, which you would have realized if you have read the task description and my previous post really carefully and thought about that a bit.

I refered to adding a line #p-wikibase-otherprojects {display: none} to /Special:MyPage/vector.css but I now see that @TTO already covered that in T127674#2055088 (thanks).

Again - that would be personal, not site solution which is this task about. Besides hiding via CSS isn't the same as removing from delivered HTML.

@Danny_B: No need to choose a tone that could come across as passive-aggressive.

If you feel it that way, I can only say, that there was no such tone intended in my post. Simply reacting to what I read. Because if you have read it and thought about it, you wouldn't come up (repeatedly as seen above) with personal solution while this task is all about site solution.
However, no need to continuously and repeatedly question my posts all around as well, right? ;-) (and no need to discuss any of these things in any Phab tasks, while we are both on IRC and in the same city... ;-))

There was no community consensus to turn it on at first.

The task associated with the links has been around since 2005. To suggest that a 10 year-old feature request, not disapproved, does not have some sort of consensus, is a bit disingenuous.

It should have been introduced as opt-in feature, not enforced (Another media-viewer and superprotect? - Paradoxically it was German community which was most sensitive to those and now it is them who do what they disliked.) nor opt-out.

Sister project links were added as a beta feature cross-wiki; all beta features are opt-in; the implication of which is that it was indeed opt-in to start.

But this is all offtopic.

There was no community consensus to turn it on at first.

The task associated with the links has been around since 2005. To suggest that a 10 year-old feature request, not disapproved, does not have some sort of consensus, is a bit disingenuous.

And that clearly validates what I said. Because if there was an enormous desre and urge, there would have been big push from communities to implement it. (And no, it does not depend on Wikidata, like interlanguage links were not.)

It should have been introduced as opt-in feature, not enforced (Another media-viewer and superprotect? - Paradoxically it was German community which was most sensitive to those and now it is them who do what they disliked.) nor opt-out.

Sister project links were added as a beta feature cross-wiki; all beta features are opt-in; the implication of which is that it was indeed opt-in to start.

I don't remember any post asking single communities for their consent. AKA if it is opt-in, how come it is enabled on wikis which diod not have any discussion about it thus couldn't give a green light to it?

So yeah I don't see what I can do here. It is possible for any wiki to ask for it to be turned off. It is a simple settings change. But so far I have not had any such requests or even discussions in this direction. The only exception being nlwiki due to their home-grown solution.

Marking as invalid because it is possible to turn it off.

Marking as invalid because it is possible to turn it off.

Great, please provide (the link to) the documentation. Thank you.

So yeah I don't see what I can do here. It is possible for any wiki to ask for it to be turned off. It is a simple settings change. But so far I have not had any such requests or even discussions in this direction. The only exception being nlwiki due to their home-grown solution.

That's actually opt-out mode, while the feature should be in opt-in. Keep the status quo and have wikis to decide themselves, please.

The task associated with the links has been around since 2005. To suggest that a 10 year-old feature request, not disapproved, does not have some sort of consensus, is a bit disingenuous.

And that clearly validates what I said. Because if there was an enormous desre and urge, there would have been big push from communities to implement it. (And no, it does not depend on Wikidata, like interlanguage links were not.)

The key words are "not disapproved". Nobody said "invalid", nobody said "disapproved". The bug on Bugzilla has 91 votes. So I would contend that in fact the feature does have consensus for implementation across-the-board.

Sister project links were added as a beta feature cross-wiki; all beta features are opt-in; the implication of which is that it was indeed opt-in to start.

I don't remember any post asking single communities for their consent. AKA if it is opt-in, how come it is enabled on wikis which diod not have any discussion about it thus couldn't give a green light to it?

Let me rephrase, since you may not have understood what I was referencing. At Special:Preferences, there is a Beta tab. (This is also exposed in the user-header at the top of every page view.) In that Beta tab, there was "Show interproject links", to which editors could opt-in. It was not-only announced, but apparently, thousands of users opted in, which is extraordinary reception for most beta features (per Nemo at T103102#1893580).

This discussion is largely moot, but in general, do your research before making incorrect claims of fact.

The task associated with the links has been around since 2005. To suggest that a 10 year-old feature request, not disapproved, does not have some sort of consensus, is a bit disingenuous.

And that clearly validates what I said. Because if there was an enormous desre and urge, there would have been big push from communities to implement it. (And no, it does not depend on Wikidata, like interlanguage links were not.)

The key words are "not disapproved". Nobody said "invalid", nobody said "disapproved". The bug on Bugzilla has 91 votes. So I would contend that in fact the feature does have consensus for implementation across-the-board.

Besides votes in Bugzilla were never considered relevant, they can never substitute local consensuses on and for single wikis. (AKA users from other projects can't make consensus on behalf of users of such wiki. Imagine that eg. Chinese users (assuming there will be the biggest number all around of them) would vote (thus made consensus by your way of interpretation) on Chinese Wikipedia to make Chines as a site language for all wikis having less than 1M of articles... Would you considered that enough "consensus for implementation across-the-board"?)

Sister project links were added as a beta feature cross-wiki; all beta features are opt-in; the implication of which is that it was indeed opt-in to start.

I don't remember any post asking single communities for their consent. AKA if it is opt-in, how come it is enabled on wikis which diod not have any discussion about it thus couldn't give a green light to it?

Let me rephrase, since you may not have understood what I was referencing. At Special:Preferences, there is a Beta tab. (This is also exposed in the user-header at the top of every page view.) In that Beta tab, there was "Show interproject links", to which editors could opt-in. It was not-only announced, but apparently, thousands of users opted in, which is extraordinary reception for most beta features (per Nemo at T103102#1893580).

This discussion is largely moot, but in general, do your research before making incorrect claims of fact.

Yes, so that was obviously misunderstanding (lost in translation? ;-)), I thought you were referring to different process.

Anyway, thousands opted-in where? On which wikis? It should have been taken into consideration the ratio of those who turned it on vs. number of active users on such wiki, and if it was at leas over 50 %, then turn the feature on, otherwise not and definitely wait for opt in consensus.

Note to prevent further possible misunderstanding: I do not question the principiality of the feature, I do not say, the principle is bad. But until its implementation fulfills various projects needs (as partially described by example in T127673: Ability to set up order and presence of sister projects links in sidebar), it should have never been turned on globally.

Re the claiming of fact: Was there any announcement on wikis like:
"There will be sisterproject links turned on on your wiki on <date goes here>, if you do not wish so, please <process description goes here>"
Being just an ordinary human, I could have simply missed that one, but I clearly do not remember any. Please navigate me to such announcment, thank you.

Besides votes in Bugzilla were never considered relevant, they can never substitute local consensuses on and for single wikis.

It's true that they cannot substitute local consensus on a wiki. But apparently the bug also had the most votes of any bug on Bugzilla. Contrast that with a whole bunch of other features which have been requested (or not) and subsequently enabled.... The argument you are making is attacking a strawman argument, in this case.

make Chines as a site language for all wikis having less than 1M of articles...

Sure, and the WMF would close the task as invalid because that's clearly not the point of the Wikimedia movement. Another strawman.

Anyway, thousands opted-in where? On which wikis? It should have been taken into consideration the ratio of those who turned it on vs. number of active users on such wiki, and if it was at leas over 50 %, then turn the feature on, otherwise not and definitely wait for opt in consensus.

That seems like an unreasonable requirement for any beta feature given that typical user response is around 1k users turning a feature on (some features less than that). If you have a problem with the current beta process, you should consider leaving that feedback elsewhere, since this is not the task for that discussion.

I do not question the principiality of the feature,

I never so-questioned you. To do so would have been improper etiquette.

But until its implementation fulfills various projects needs (as partially described by example in T127673: Ability to set up order and presence of sister projects links in sidebar), it should have never been turned on globally.

How can we know what the projects need without enabling-by-default working software (contrast this with Gather, which is soon-to-be-removed from en.wp)? We can ask them, but (as below) some people miss the message. Somehow.

Re the claiming of fact: Was there any announcement on wikis like:
"There will be sisterproject links turned on on your wiki on <date goes here>, if you do not wish so, please <process description goes here>"
Being just an ordinary human, I could have simply missed that one, but I clearly do not remember any. Please navigate me to such announcment, thank you.

T103102#1921345 says it was in the news on or about January 8, 2016. I do not know exactly which pages are delivered to on which wikis (on en.wp it's WP:VPT), but I'm sure you can ask the person who made the column-move about specifics for each wiki.

Anyway, I'm done discussing with you. The project manager of the Wikidata component has closed this bug as invalid. I doubt anyone is going to disagree with her decision except with specific wikis in mind.

Besides votes in Bugzilla were never considered relevant, they can never substitute local consensuses on and for single wikis.

It's true that they cannot substitute local consensus on a wiki. But apparently the bug also had the most votes of any bug on Bugzilla. Contrast that with a whole bunch of other features which have been requested (or not) and subsequently enabled.... The argument you are making is attacking a strawman argument, in this case.

And I know about bugs with many votes which have been wontfixed. So obviously you can't absolutely measure by votes in Bugzilla since not only their relevancy highly varies but also their weight in decision processes.

make Chines as a site language for all wikis having less than 1M of articles...

Sure, and the WMF would close the task as invalid because that's clearly not the point of the Wikimedia movement. Another strawman.

Yes, that was intentionally quite absurd example, but exactly to demonstrate the absurdity of claiming that there can be consensus taken by somebody else but involved community.
Btw: WMF does not override community consensus (at least they say so...), but let's not continue this into details, the purpose was to show what I said above.

PS: None are straw man - you brought Bugzilla as an supportive argument. So I am simply just rebuting it.

Anyway, thousands opted-in where? On which wikis? It should have been taken into consideration the ratio of those who turned it on vs. number of active users on such wiki, and if it was at leas over 50 %, then turn the feature on, otherwise not and definitely wait for opt in consensus.

That seems like an unreasonable requirement for any beta feature given that typical user response is around 1k users turning a feature on (some features less than that). If you have a problem with the current beta process, you should consider leaving that feedback elsewhere, since this is not the task for that discussion.

You brought beta stuff here... However, good suggestion, thanks for it. I'll consider some way how to discuss the suggestions for the change.

I do not question the principiality of the feature,

I never so-questioned you. To do so would have been improper etiquette.

I never said so ;-) I just noted that as I said to prevent possible misunderstanding (it's not only us two who can read this conversation ;-))

But until its implementation fulfills various projects needs (as partially described by example in T127673: Ability to set up order and presence of sister projects links in sidebar), it should have never been turned on globally.

How can we know what the projects need without enabling-by-default working software (contrast this with Gather, which is soon-to-be-removed from en.wp)? We can ask them, but (as below) some people miss the message. Somehow.

Simply and clearly: Ask before on "how would you like to implement it" / "what are your needs in this feature"? I don't remember any such survey not only local but even any global (though again, I might have missed it, links welcome in nsuch case). Sure people could miss it, but then you still have an argument that there was an announcement and there was a survey thhus it is not a single person (or highly narrow group of people) decision.

Re the claiming of fact: Was there any announcement on wikis like:
"There will be sisterproject links turned on on your wiki on <date goes here>, if you do not wish so, please <process description goes here>"
Being just an ordinary human, I could have simply missed that one, but I clearly do not remember any. Please navigate me to such announcment, thank you.

T103102#1921345 says it was in the news on or about January 8, 2016. I do not know exactly which pages are delivered to on which wikis (on en.wp it's WP:VPT), but I'm sure you can ask the person who made the column-move about specifics for each wiki.

I've just checked several Village pumps and it was not on any of them. So clearly the whole process was completely bad. Pity that it was driven by German community, who on the other hand was so sensitive to mediaviewer and superprotect. :-/

Anyway, I'm done discussing with you. The project manager of the Wikidata component has closed this bug as invalid. I doubt anyone is going to disagree with her decision except with specific wikis in mind.

Neither will I, if the ability exists (and that's what the task was about). This whole discussion was about the totally wrong process taken to enable it and that it should be opt-in and not opt-out.

Ok here are a few points and that is where I will stop the discussion:

  • The feature was developed by a volunteer
  • WMDE helped get it out and reviewed and so on
  • It has been in beta-features for much longer than features are supposed to
  • I announced it on the tech ambassadors list and Wikidata's weekly summary
  • It was announced in tech-news
  • I very explicitly said any project that doesn't want it can ask for it to be turned off and I stand by this
  • It was solving a ticket that has been around since 2004 and has received much support
  • I have not had any complaints besides this - quite the opposite - people really like it
  • Getting connections between our sister projects is really important if we ever want to give them a chance of real success

Ok here are a few points and that is where I will stop the discussion:

  • The feature was developed by a volunteer
  • WMDE helped get it out and reviewed and so on
  • It has been in beta-features for much longer than features are supposed to

Not relevant for what's being questioned.

  • I announced it on the tech ambassadors list and Wikidata's weekly summary
  • It was announced in tech-news

As said above - no local announcements on wikis about turning it on and possibility to opt-out found.

  • I very explicitly said any project that doesn't want it can ask for it to be turned off and I stand by this

I asked for the docs, got none yet... :-/

  • It was solving a ticket that has been around since 2004 and has received much support

This has been discussed above.

  • I have not had any complaints besides this - quite the opposite - people really like it

Again: This is not complaint about the feature in general, but about the mode of its deployment.

  • Getting connections between our sister projects is really important if we ever want to give them a chance of real success

That's not being questioned.
But sisterproject links are not the only solution and sisterproject links currently do not fully replace current way of linking to sister projects. But that's being discussed in T127673: Ability to set up order and presence of sister projects links in sidebar.