as well as which sisterprojects will be shown (for instance it does not have any sense to show [[mw:Category:Candidates for speedy deletion]] on any language sister project, basically just on Meta (if even).

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.

There should be a way to set up the order of such links

Wikis got used to the new-and-enforced sorting for interlanguage links decently quick, so I'm not sure of providing for customization. It might be valuable to consider the global order.

In T127673#2055528, @Izno wrote:

as well as which sisterprojects will be shown (for instance it does not have any sense to show [[mw:Category:Candidates for speedy deletion]] on any language sister project, basically just on Meta (if even).

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.

MediaWiki.org links are in most cases irelevant to any content project, same with Meta links.

There should be a way to set up the order of such links

Wikis got used to the new-and-enforced sorting for interlanguage links decently quick, so I'm not sure of providing for customization. It might be valuable to consider the global order.

??? Interlanguage links were sort in abc order by lang code since the beginning, so there is nothing new in its sorting.

In T127673#2056580, @Danny_B wrote:

In 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'.

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.

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.

??? 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.

In T127673#2056749, @Izno wrote:

In T127673#2056580, @Danny_B wrote:

In 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.

In 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.