Ok I will send an email to the tech ambassadors list. We'll enable it in January. @aude gets to decide on the actual date.

It should not be all in or all out. I would much prefer that this is within the scope of the individual in what they see, not enforcing more components into sidebars, Please have a configuration option for a user to turn it on and off; and the means for a community to set a default which a community can set their preference.

As I said on the mailing list I do not want to add a user-option for this. It would be another cut into the already bad preferences for arguably little gain.

Little gain? For whom?

This change forces You are forcing communities to choose, which usually puts unhappiness into the losing part of any consensus. Ultimately You are also practically forcing this to the default ON, yet where are the results of the use in beta that this there is a consensus that this is desired. In fact prior to taking this to rollout that this is desired by the broader community? I instead see the conversation that it is stable.

This continued forcing of more things collectively into sidebars has to stop at some spot until there is more flexibility for sidebars, and more easily manipulated, especially with orders of groups. Developers seem to can forget that many do not have the skills to customise through code, and the preferences is meant to make it easy, and now the developers don't see that value?

I repeat that

• It should be an option for users to turn it on or off in their preferences
• Communities should have the ability to set it as their default ON or OFF, which users can then themselves manipulate. Communities should not have to go cap in hand to Wikidata for that configuration.

If that cannot happen then maybe it should not rollout.

Billinghurst, this is the implementation of a long-standing feature request that was the most voted bug on bugzilla, had an RfC on Meta-Wiki and has thousands of users actively opting in. Moreover, it's the default state on multiple "top 10" Wikipedias. It is definitely something the community asked, so please avoid the aggressive language.

Nobody is forcing anything, wikis are free to opt out simply by asking. Do you suggest to make a Meta-Wiki page where a wiki can be added if the feature is undesired there?

@Nemo_bis Nowhere did I say that it was not requested, nor unwanted, however, it becomes all or nothing per community, and in our history we have provided things called user preferences to allow users to configure what they see.

Thousands have opted in, and thousands (more?!?) have not. I am only asking that it continue to be optional per user and the comment is "arguably little gain" and I don't see that as an appropriate response, terse and unsupported by commentary to justify.

Preferences may or may not be "bad" is a vague and weak argument for not exploring the option or stating how or why they should not take place.

The process about communities getting notified, and the defaults, and what happens needs to be fixed, as this regularly comes up, and that belongs in a bug of its own. While it is unresolved, it continues to be a bugbear and a point of weakness/inflammation/conflagration.

The language was not meant to be aggressive, use of second person rather than more generic. Apologies if it seemed that way.

Every preference we add adds clutter, maintenance cost and most importantly makes it harder for users to find what they actually want in the preferences. So any additional option we add needs to be very well justified and actually make things better for a significant number of people. It is death by a thousand cuts otherwise.

Some things to read up on:

• http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-higher-satisfac
• https://ux.stackexchange.com/questions/75635/when-is-configurable-options-settings-a-bad-thing-in-the-context-of-admin-super
• https://www.nngroup.com/articles/minimize-cognitive-load/

Adding #p-wikibase-otherprojects {display: none;} to your stylesheet would work if you want to opt-out once the beta pref is removed.

It's good to see this going forwards at last.

But what is the progress with two long-standing requests ?

• Moving the standard "wikidata item" link into this group, to make it easier to find ?
• Attempting by default to include a link both to a Commons category and to a Commons gallery in the group ?

On nl-wiki we have for years an alternative larger system that already shows the interwiki links to sister projects in the sidebar. Enabling this for everyone on nl-wiki is useless and in almost all the cases duplicate to the already existing ones (already shown to everyone), which is much more extensive than the current Beta system.

If you have enabled the Beta system, it is shown duplicate. Like:
https://nl.wikipedia.org/wiki/Lynes'_graszanger
https://nl.wikipedia.org/wiki/3FM_Serious_Request_2015

@Romaine You could maybe do just like Russian Wikipedia or the French Wikisource and use the Wikibase other project sidebar as a basic and add your additional links to it. With that nlwiki would have a basic sidebar for without JavaScript readers and you would be able to avoid the need of having a div hidden somewhere to fill this sidebar in cases where Wikidata contains already all the information needed (which is I think the most common case).

Moving the standard "wikidata item" link into this group, to make it easier to find ?

That's tracked at T66315.

We should probably immediately replace the code at https://commons.wikimedia.org/wiki/MediaWiki:InterProject.js with https://it.wikipedia.org/wiki/MediaWiki:InterProject.js, which AFAIK is fully compatible.

Is a date set yet?

We identified one last blocker yesterday (adding Commons category links without frying the servers). @hoo is working on that - should be quick. Once we know when that'll land in production we will have a date.

In T103102#1897161, @Tpt wrote:

@Romaine You could maybe do just like Russian Wikipedia or the French Wikisource and use the Wikibase other project sidebar as a basic and add your additional links to it. With that nlwiki would have a basic sidebar for without JavaScript readers and you would be able to avoid the need of having a div hidden somewhere to fill this sidebar in cases where Wikidata contains already all the information needed (which is I think the most common case).

Testing the feature I notice it only uses the sitelinks section of items. And then only those sitelinks that are in the language of the wiki. So statements are not taken into account.

So I think I have to disagree with you on the suggestion that in most cases Wikidata would contain all the information needed, that is simple not true. The simple reason for that is that sitelinks can only be added to one item, and a Commons category is added in preference to an item that contains categories of Wikipedia. Meaning that Commons galleries are connected to article items. So most articles items do have a Commons category statement, but do not have a Commons category sitelink.

Thousands of Commons categories are not added as sitelink to Wikidata, because of a major issue in de design of Wikidata that does not take the actual Commons situation into account.

On nl-wiki we give a preference to linking to Commons categories as those form the basic navigational system, and not to Commons galleries that are often considered not useful. If we set the Wikibase as a basic, this will override the links we have set ourselves. I am not sure if that would be considered acceptable.

I will organise a voting to see what the community has as preference.

@Romaine: We are working on making it possible to have commons categories in there right now (see T94989). We consider that a blocker for taking the sidebar out of beta, thus it will be fixed before that happens.

In T103102#1933779, @Romaine wrote:

On nl-wiki we give a preference to linking to Commons categories as those form the basic navigational system, and not to Commons galleries that are often considered not useful. If we set the Wikibase as a basic, this will override the links we have set ourselves. I am not sure if that would be considered acceptable.

The Russian Wikipedia community also prefers links to Commons categories. But at the same time "in other projects" sidebar is used from the very beginning, and it is no problem. There is an additional script that checks for the Commons category (by property 373, but you can use other methods), and replaces the link to the gallery with link to the category.

@putnik: we can not do that on more wikis. It fries the servers. We need another solution that hoo is working on right now.

@Lydia_Pintscher: I'm optimized script a little to take the Commons link from the page if it have already been displayed via Lua. But for other projects this is probably not suitable.

WE have now scheduled this for February 23rd.

Sorry. My mistake. It is the 16th of February.

Change 270939 had a related patch set uploaded (by Aude):
Take "in other projects" sidebar out of beta

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

Based on the comments here we will enable it for everyone but Dutch Wikipedia. If there are any issues we can later disable it again for any project that really doesn't want it. Dutch Wikipedia probably should think about moving to this one.

Change 270939 merged by jenkins-bot:
Take "in other projects" sidebar out of beta

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