The easier way to do this is to just add categories as sitelinks. Commons is fine with it. If you get reverted on Wikidata, just use the standard interwiki syntax on Commons.

That's fine by me but is there some way to automate this? All those categories are stored in the Wikidata items already. Manually adding 47000+ links is not something I look forward to, and that's just for English. (that's the total article count for enWV so in practice it'll be a bit less but it's in the ballpark)

@Acer: what is your "reasonable, valid, correct, ethic reasons to do so" ? Making your purpose less clear make not more reasonable, valid, correct an ethic.

Current situation

Wikimedia Commons is not like any other project which Wikidata supports. Instead of ns-0 being the ones with the most content or relevance, it is the Category namespace which is 'the main thing'. This causes some problems when it comes to Wikidata and interwiki-linking. The question has been raised numerous times, but never has a clear result on both Wikidata and Commons been provided on how the category vs ns0 linking on Wikidata should be.
Example: Subject X does not have a Commons gallery (ns0) and is only has a category on Commons. Some user would create a new Wikidata item for that category since it is a non-ns0/article page. Some other user would just add it as a normal article link on the Wikidata item that already exists for the subject X. Also, someone would add it as a Commonscategory propery as well.
Subject Y has both a Commons category and a Commons gallery (ns0), and in this case the category would need a new item to be added on WIkidata, and added as a Commonscategory property.

Wikimedia Commons' categories has many categories which has "old timey" interwiki links which links to Wikipedia (ns0) articles, to circumvent them beeing needed to be added to Wikidata as a link on the subjects item, since they are not a ns0 page, but a category in the Proprty-31 sense. This causes Commons to have interwiki links to some wikis about the subject, but not all, since new articles are created, and not all wikis may have been interwiki linked (manually).

Commons vs Wikidata

One issue is that Commons users, as @Nemo_bis says, "don't care" about the guidelines which Wikidata might have about categories, and simply add it as a sitelink about the topic. The reason: It's the only known way to make sure Wikipedia articles get a link to Commons.

Way forward

• We need a better guidelines on how Commons categories should be handled on Wikidata
• We need "Propery Commons Category" as well as items with "topics main subject" be treated as a interwiki link. That way when on articles on (small) Wikipedias, Commons categories could be "found" just as if they were added as a "oter sites"link. And on Commons all WIkipedias could be listed as "In WIkipedia", even if the category hasn't been added as a "other site page" to the item about the subject and not the category.

After that

We can start to import old interwiki links as "property Commons category" and they could make sure that small wikis have links to Wikimedia Commons.

@Josve05a If I understand well, it is just a matter of wikidata policy, if Category would be treated as a valid interwiki for commons, it is not a technical issue (I mean there is no need of new development). So it would be relevant discussion on wikidata, but not here. (Anyway, before a development, a consensus on political issue must be reached first)

The only work would be if you wanted that the property Common category would be treated as an interwiki. but as there is a technical valid solution without this new development, I don't see the point to make a new development.

That's the point of this ticket, to use the Commonscat property to generate interlinks. This would solve everyone's problem in a simple, elegant way.
The Wikidata folks are concerned about internal consistency, so they want Articles paired with Articles and Categories paired with Categories. That's fine, I understand their desire to be consistent. Everyone else, the other projects, are not interested in the way Wikidata organizes itself and just want the links to show up because Commons categories function, in practice, as their main articles. The real articles (Galleries as they call them) are not very common, especially for less known subjects.
These two perspectives are not inherently mutually exclusive. The problem is that currently the only way to make interwiki links show up in the Commons category page is to add that category page to the other sites list in the Wikidata item, which breaks symmetry. This solution would solve the linking problem without breaking symmetry.

Also, it should be noted that the solution I am proposing here is already half implemented. The commons category property is already being used to generate intewiki links, but it only generates them on one side of the equation.
If you add a Commonscat property to a Wikidata item the interwiki link to that category will show up on the respective Wikipedia, Wikivoyage, whatever project article page. But the reverse is not true, those articles will not be listed as interwikis links on the Commons category page. See Konanur on Wikipedia and the corresponding Commons category on Konanur. Also notice how the "Wikidata Item" link in the Tools section of the sidebar only shows up on the Wikipedia page and not on the Commons category page. (If this goes forward that link should be added also)

I am not asking for anything new or revolutionary here, just that the current, existing functionality is implemented in full and not halfway as is currently happening. I am asking that you balance the equation. Thanks,

@hoo Can you give an evaluation from the technical side please? If that has no problems I am ok with doing it.

Manually adding 47000+ links is not something I look forward to, and that's just for English.

You can probably add all sitelinks with interwiki.py without any manual effort, simply by matching articles and categories which have the same name. There isn't much ambiguity for the names of places (and the ambiguities are managed approximately in the same way by Wikivoyage and Commons).

In T145279#2632186, @Lydia_Pintscher wrote:

@hoo Can you give an evaluation from the technical side please? If that has no problems I am ok with doing it.

If I get this right, we need T99899 to implement this (as we need to get the Item that has the commons category statement with the commons category name).

(Note: https://www.wikidata.org/wiki/Property:P373 is not an external identifier, that would need to change)

In T145279#2631645, @xcombelle wrote:

@Josve05a If I understand well, it is just a matter of wikidata policy, if Category would be treated as a valid interwiki for commons, it is not a technical issue (I mean there is no need of new development). So it would be relevant discussion on wikidata, but not here. (Anyway, before a development, a consensus on political issue must be reached first)

That's kind of correct. However, as I understand the consensus and policy has been established already on Wikidata to have category sitelinks with category sitelinks, and ns0 sitelinks with ns0 sitelinks on separate items. The problem arises when that happens, that they are not "Interconnected" on the wikis, making them "separate" and the users on the wikis (Commons and Wikipedia) goes against WIkidata-policies and add these category site links to article items. So, if there was a technical way to ensure that category items with "Main topic" was treated as a "Normal sitelink" when displayed on Wikipedia and Commons in the left menu, but leave them as separate items on Wikidata, then all would be fine. (if the process to "create" these wikidata-category-items were easier thatn just add them as sitelinksto the subject item) perhaps.

The only work would be if you wanted that the property Common category would be treated as an interwiki. but as there is a technical valid solution without this new development, I don't see the point to make a new development.

Well that property, and "Main topic" property on category items be interconnected as a sitelink but...not...
Currently a lot of Wikipedia articles could have links to Commons, and a lot of Commons categories could have links to WIkipeida, but Wikidata is failing to serve this as "wanted" for the wikis needs.

Scratch that, I misunderstood. Repurposing the example below.

Was this implemented? (I stumbled upon the task whilst searching for something else)
It appears to already be working.

E.g.

• https://en.wikipedia.org/wiki/Anastigmat (Does not contain any links pointing to Commons, yet the site-sidebar contains the "In other projects: Wikimedia Commons" link, which points to the Commons category)
• https://www.wikidata.org/wiki/Q487226 (This has the P373 for the Commons category, and no entries for Commons in the Sitelinks section.)
• https://commons.wikimedia.org/wiki/Category:Anastigmat (However, this page does ''not'' contain any links to the Wikipedias. That is what is desired.

Nope. You got it backwards. The issue here is that the Commons Category:Anastigmat page does not interwiki-link back to Anastigmat on Wikipedia.

I made a sitelink on Commons Category:Anastigmat and now the links are fine. There has been some discussion on Wikidata in the past about whether this is the right way to do it, but no consensus was reached. However the software is set up to support it ("Add Links" in the sidebar) and it's the only way to make all the sidebar links appear on the Commons side, including the link to the Wikidata item.

Actually in this case there's a category item on Wikidata, so the Commons category can link to that. It makes it slightly harder to set up, because it needs a template on the category to pull in the links from the main Wikidata item.

Also, if someone could find a way we could get rid of thse cats from this maintenance cat without breaking Wikidata's policies, that would be swell...https://commons.wikimedia.org/wiki/Category:Biology_pages_without_wikidata_link

Those are also fixed by making sitelinks. The only relevant Wikidata policy that I know of is Wikidata:Notability, which says "an item with only a sitelink to a category page in Wikimedia Commons is not allowed on main article items", which I believe means you can't create new Wikidata item which is linked only to Commons. That won't be an issue for most of the biological categories.

Another advantage of sitelinks is that when a Commons category is renamed, the sitelink is fixed automatically, but the P373 link is left pointing to the old name.

I think this is basically solved now, barring cleanup? Following from the general switch to using the sitelinks for Commons over the last year, the interwiki links now appear on Commons through the sitelinks in most cases. Where the category is linked to a category item, {{Interwiki from Wikidata}} and {{Wikidata Infobox}} sort out the relevant links. So I think this task can now be closed?

Following from the general switch to using the sitelinks for Commons over the last year...

@Mike_Peel - Could you explain this sentence? What is the "general switch"?

From my POV, this problem is not fixed, it's actually gotten worse. For example, I can't get access to the Wikidata ID from Javascript within a Category page if:

• The category page is interwikilinked from a category item instead of the regular Wikidata item (which seems to be an increasingly common practice).
• The Wikidata item is linked to a gallery instead of the category.

Just because you can work around this from within Lua, doesn't solve the problem for gadgets and userscripts which need the data available from Javascript (without being delayed by expensive round-trip API queries).

In T145279#5384625, @kaldari wrote:

Following from the general switch to using the sitelinks for Commons over the last year...

@Mike_Peel - Could you explain this sentence? What is the "general switch"?

Commons sitelinks are now used a lot more than they were before (this is what the infobox is using, so they're now in ~2.5 million categories compared to ~0.5 million 18 months ago). P373 is hopefully being used less, and I'm hoping that it will be deprecated at some point.

From my POV, this problem is not fixed, it's actually gotten worse. For example, I can't get access to the Wikidata ID from Javascript within a Category page if:

• The category page is interwikilinked from a category item instead of the regular Wikidata item (which seems to be an increasingly common practice).
• The Wikidata item is linked to a gallery instead of the category.

Just because you can work around this from within Lua, doesn't solve the problem for gadgets and userscripts which need the data available from Javascript (without being delayed by expensive round-trip API queries).

This is a problem with the Javascript tools, you probably want to open a separate ticket for that.

This is a problem with the Javascript tools, you probably want to open a separate ticket for that.

I created a new ticket here: T229593