Izno added a comment.
In https://phabricator.wikimedia.org/T127673#2056952, @Danny_B wrote: > Please get back to the task description and you will see the clear reason for why the custom order should be allowed. You say you can come up with use cases for presence of irelevant wikis (please do so, I am seriously interested, becaus I can't imagine any relevant usecase for irelevant wikis (see the paragraph about relevancy below)), I can likely come up with use cases of custom order, so yes, the support of customization is so valuable. Enforcing of single preferred way is not only user unfriendly, but also against the whole community spirit and it particularly breaks current local communities habits or policies. From whose will? Why should I return to the description when I have already questioned //your// uses cases for your desire? You have declined to file a ticket for a particular wiki's needs, which leads me to believe your use case (of customization) is just as abstract as mine are. > Wikidata users are human beings, and human beings err, as known. I've seen many totally irrelevant items attached together, just because either somebody misunderstood the translation or just blind bot attaching. So this statement does not have enough weight... They //do// err. This is why Wikidata is a wiki. Clearly wikis work. {{sofixit}} > And I am talking about realtionship between MediaWiki.org & Meta vs. content wikis. Single project dedicated wikis (MW, Wikimania, Outreach...) and meta wikis are not //relevant// to content wikis (w:, wikt:, s:, q:, b:, n:, v:, voy:) at all as they do not describe any content. Wikidata does not only link content. Your understanding of how it works both technically and socially seems to be insufficient for this discussion. > I did not say that linking to MW is //always// irelevant, hence why the task description suggests namespacewide or even pagewide settings. > > And exactly - if eg. template doc pages are not considered worth to include to the Wikidata, then obviously the whole interprojects is senseless on these pages. I will restate and stand by what I said: if the interwiki/Wikidata community thinks a particular page is irrelevant to a particular set of other links, it will be removed or refactored. I see zero reason to allow customization to //remove// a link on an entire wiki, much less a particular namespace, and etc. Template documentation pages, with good reason, are not included on Wikidata. If you wish to change that long-term consensus, that's your prerogative. But now you're tossing out "oh, what about these?", which leave me just as unconvinced as before. And in the case of documentation pages, those aren't even their own namespace, so that leads me to believe that the feature asked for at a wiki-level is not desirable. At a namespace-level is not desirable. At a user level, you already have the ability to remove the specific links you want to -- each interproject link has its own class which can be hidden via CSS. If your //project// wants to hide certain ones, it can. Heck, local projects can even rearrange the links. But just as you argued elsewhere, if the wikis wanted it, they would have started building gadgets or user scripts to either rearrange or remove wikis. Where are these gadgets? > So you judge by one single exceptional wiki entire global feature? No, I'm providing an example of one case. I know there to have been others. They also got over it. "At least one" != "only one"; you seem to have argued against the strawman of the latter. Fundamentally, I'm missing out on how you can't do this now and why you think the WikidataClient software needs to change as a result. But cheers. I'm moving on from this ticket also. TASK DETAIL https://phabricator.wikimedia.org/T127673 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Izno Cc: Izno, Aklapper, Danny_B, StudiesWorld, Wikidata-bugs, aude, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
