Danny_B added a comment.
In https://phabricator.wikimedia.org/T127673#2056749, @Izno wrote: > In https://phabricator.wikimedia.org/T127673#2056580, @Danny_B wrote: > > > In https://phabricator.wikimedia.org/T127673#2055528, @Izno wrote: > > > > > That doesn't seem like a very good use case to select to imply that we should allow customization. Cross-wiki vandal fighters may find that to be a good x-wiki link. I'm sure I can think of a good case on a per-user basis why we should just show all of them on all wikis on all pages, and etc. > > > > > > You are turning the dependencies upside down. CVWFs use their own tools. They have never had this feature thus you can't say that it's needed for them. > > > I am considering uses cases which may provide for x-wiki Foobar happenings; x-wiki vandal fighters was only one of them. Some might consider that "making up use cases" (and they might be right), but it seems clear to me that someone will use these. Is support of customization so valuable to inhibit that user's potential uses...? Clearly you think 'yes'; my suggestion is 'no'. 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? >> MediaWiki.org links are in most cases irelevant to any //content// project, same with Meta links. > > If the links associated with a particular wiki are not relevant to the rest of the links in the item, they will not be attached to it in Wikidata. 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... 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. > I can trivially point to cases where this can be observed. MediaWiki help pages and a number of essays on en.WP/Meta are the first off the top of my head where they //will// be attached. OTOH some pages will not be because either the Wikidata community disagrees with their inclusion (e.g. user/most special pages, which should be dealt with in the software) or because the page contents differ so-significantly (with a same/similar title) that the Wikidata community has policed the links away into another item. 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. >> ??? Interlanguage links were sort in abc order by lang code since the beginning, so there is nothing new in its sorting. > > This is a wrong statement. EN.WP if no-other wikis had custom sort orders in the editable text which subsequently reflected in the order displayed by the page. So you judge by one single exceptional wiki entire global feature? In fact, the order in wikitext could have been various, but IW bots were enforcing the abc. And most majority of wikis had that as either unwritten habit or even written at least in help or in policy. TASK DETAIL https://phabricator.wikimedia.org/T127673 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Danny_B 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
