Page MenuHomePhabricator

Add the sidelink to the Commons category, in absence of the gallery
Closed, InvalidPublic

Description

In this discussion we've just decided that among the sidelinks of a it.wiki article, in absence of a respective gallery on Commons, there should be a link to the main category related to the article (see property p373 on Wikidata).
I don't know if it's already such this, but I noticed that in it:Vittorio Emanuele II di Savoia the sidelink to commons:Category:Victor Emmanuel II of Italy doesn't appear.
Conversely, in it:Domenico Tarsitani it does appear.
In both of them the Template:Interprogetto (similar to Commonscat but suitable for all the link to the WM projects) doesn't have parameters and takes the data from Wikidata. And in the respective Wikidata items the link to Commons is defined by the property p373 and not in the "Other sites".
I don't think the problem is in the template:Interprogetto, since its synthax is pretty simple and I don't see why it should behave differently.
Can the problem be fixed?

Related Objects

Event Timeline

Horcrux92 raised the priority of this task from to Low.
Horcrux92 updated the task description. (Show Details)
Horcrux92 subscribed.

Hi @Horcrux92, could you attach screenshots what exactly should be seen where exactly, and a comparison? I'm not sure I understand what is requested in this task. Thank you!

Ah, so this seems to be about a link to "Wikimedia Commons" under "Altri progetti". Alright!

Aklapper set Security to None.

https://it.wikipedia.org/wiki/Vittorio_Emanuele_II_di_Savoia links to https://www.wikidata.org/wiki/Q168691
https://commons.wikimedia.org/wiki/Category:Victor_Emmanuel_II_of_Italy links to https://www.wikidata.org/wiki/Q7367480 which defines Q168691 as "category's main topic".
The two pages do not have the same name if you strip the namespace.

https://it.wikipedia.org/wiki/Domenico_Tarsitani links to https://www.wikidata.org/wiki/Q3713260
https://commons.wikimedia.org/wiki/Category:Domenico_Tarsitani has no "Wikidata item" shown under "Tools".
Both pages have the same name if you strip the namespace.

So the Wikipedia article and the category of Commons must have the same name? It seems a bit superficial and potentially misleading. Wouldn't it be simplier and more consistent to rely on the property P373 of the Wikidata item?

I believe it is https://it.wikipedia.org/wiki/Modulo:Interprogetto ? Since it's a Lua module it should not be hard to add fetching from WD. Actually it should work entirely basing on WD imho. Both for commonscats and galleries. If it doesn't yet. I am bad at both Italian and Lua.

I believe it is https://it.wikipedia.org/wiki/Modulo:Interprogetto ? Since it's a Lua module it should not be hard to add fetching from WD. Actually it should work entirely basing on WD imho. Both for commonscats and galleries. If it doesn't yet. I am bad at both Italian and Lua.

Modulo:Interprogetto merely generates the links on page, not in the side-skin, and it is already capable to catch the links to the Commons categories from WD. For what I know, sidelinks instead are generated by the MW software depending on the interwikis specified on the page (manually or by template/Lua) and on the Wikidata item. Am I wrong?

I may be wrong but RenderLeftBar looks like actually changing the Sidebar. It gives some explanation in its luadoc (or whatever it is named in lua) about how it works. In Italian. Besides I, with uk interface lang on itwiki, see the message in Italian not in English or Russian or Ukrainian (the fallback sequence for uk) which proofs it to be some hardcoded stuff like this Module rather than proper Mediawiki interface part.

Yes! The problem was in JS page it:MediaWiki:InterProject.js (called by commons.js), that dinamically takes data from the html generated from the function RenderLeftBar of the module Interprogetto.

The problem was that I didn't know that the sidelinks was generated locally and not centrally from the software.

Thank you so much and sorry for misplacing.

Aklapper claimed this task.

No problem. Glad you found the reason!
Closing this task as "invalid" as this was an on-wiki code issue.