Sometimes files have local description pages. A common example is featured pictures on wikipedia. I would suggest maybe linking to commons only if the local page does not exist.

Some wikis have gadgets to do so.

Sometimes files have local description pages. A common example is featured pictures on wikipedia. I would suggest maybe linking to commons only if the local page does not exist.

Makes sense! I've updated the description accordingly. Thanks :)

A common example is featured pictures on wikipedia. I would suggest maybe linking to commons only if the local page does not exist.

This is not what this is about. See the issue description or the wish. Not linking to Commons means the categories are excluded, there's some screw-up with the display (galleries in the file description for example), and some links are dysfunctional with the main issue being the categories and that for no reasons people are isolated from Commons so they don't learn about its existence and don't browse or use it. Maybe you meant sth else but that's not clear from your comment. For POTD images in specific there also is no benefit to link to some intermediary Wikipedia page instead of Commons when the image is opened but only major disadvantages. The wish is about linking directly to Commons and if the file is only on Wikipedia and not on Commons then that's impossible anyway.

We can add a config setting for the behaviour if we want, but I don't think it's safe to always bypass the local page. POTD is just an example, but a wiki may desire to link to the local description for any number of reasons.

the main issue being the categories [on Commons]

A counterargument is when local categorization is favoured. I do this on my third party wiki, for example.

It's not always "bypassed". Currently, the actual file page is bypassed by some unnecessary intermediary Wikipedia page that is an historic remnant and nothing of use but causing lots of very large disadvantages. If you have an example where bypassing the actual file page would be good, please elaborate. No problem with excluding POTD but even there the advantage seems to be the display of the POTD display underneath the file which is not that useful since it's largely self-explanatory when the file gets opened from POTD and additionally there are templates for this on Commons too. See for example here or here – that it has been a FP on ENWP is shown there too along with additional info. And regarding local categorization there also is Category:Featured pictures on Wikipedia, English set on these files. There are just very few local ENWP file categories and topical cats there are not useful as they don't actually have 99.99% of the files, where the files are on Commons and the users don't know so it's misleading and not actually useful. If there are exceptions it would be good maybe identify which and then make sure the extra data/info is not lost but added to the Commons pages or people can migrate it there.

This doesn't negate the value of the issue / implementing this issue. Also in the POTD case there doesn't seem to be a local "description" as you say for the file, just an additional/different template. Are there files where there is an additional description not on Commons? If so, it would probably be best to migrate these to Commons within templates like {{fr|text}} for French which then also benefits visitors of that language to Commons. Often, when things have been one suboptimal way for a while, things have been adjusted for that but that doesn't mean improving the situation would be good due to these adaptations; it would just mean some extra transition steps would be good and things like that.

Changing this to an investigation as it seems there's some inconsistency, or perhaps even a bug, with the existing code to generate description URLs.

We already have $wgRepositoryBaseUrl, which is set to Commons by default and is not overridden in the WMF config. Yet, digging through the code, I don't see where we're actually making use of the setting!

Here are my findings thus far:

• $wgRepositoryBaseUrl is set to Commons on our cluster, yet it doesn't seem to have any effect.
• $wgRepositoryBaseUrl is a shortcut to the descBaseUrl property of $wgForeignFileRepos.
• In my local environment (and presumably standard third-party MW installations), the config gets dynamically set through SetupDynamicConfig.php
  • Of note, the $wgForeignFileRepos setting for UseInstantCommons does not set descBaseUrl.
• The actual line of code where we generate the description URL (for the legacy parser) is MediaTransformOutput.php#289, which explicitly calls Title::getLocalURL(), so it would never use the Commons URL no matter what the configuration says.
• WMF production does not use InstantCommons. From wmf-config/filebackend.php, it looks like we are explicitly setting descBaseUrl to Commons.
• Foreign files will use ForeignAPIFile::getDescriptionUrl() (or ForeignDBFile::getDescriptionUrl()), both of which pull from the DB on Commons, as opposed to going off of descBaseUrl.

A simple change is to make MediaWikiTransformOutput::getDescLinkAttribs() use $this->file->getDescriptionUrl() for the href. Then all the description URLs unconditionally change to Commons – using i.e. ForeignAPIFile::getDescriptionUrl().

But, where does descBaseUrl come into play? As far as I can tell, it isn't used in any situation :/

Conclusions (which may be wrong):

• descBaseUrl / $wgRepositoryBaseUrl evidently has no effect. This is perhaps a bug of its own, or more specifically a regression, based on T27243 for example.
  • Or, descBaseUrl might be used when first storing the file, and we are always pulling from there – hence why it seems changing $wgRepositoryBaseUrl has no effect (?)
• Changing MediaWikiTransformOutput to use File::getDescriptionUrl() will give us the desired behaviour, however:
  • At least for InstantCommons, it will still use the description stored in the DB, and not descBaseUrl (though in our case they are the same)
  • This change would mean we never link to the local description, even when it does exist (which in being debated in the above comments)

cc @tstarling since I know you are knowledgeable in this area and added the ->toLocalUrl() line way back in August 2007 (which can then be traced to r21411 from April 2007).

I'd like to better understand $wgRepositoryBaseUrl / descBaseUrl before proceeding any further.

I think descBaseUrl will be used to pull the file description page. The overriding is kind of confusing, but File::getDescriptionText() calls FileRepo::getDescriptionRenderUrl which calls FileRepo::getDescriptionUrl() [And not File::getDescriptionUrl], thus the override in the file class doesn't apply to description fetching, it only applies to things like the message telling people to go to commons.

In T421188#11747363, @Bugreporter wrote:

Some wikis have gadgets to do so.

P896 was the list of the wikis that have a gadget for it as of 2022, with at least some (like Russian Wikipedia) enabling it by default.

In T421188#11889656, @MusikAnimal wrote:

Then there's the question of allowing linking to the local page if there's a local description. I would advise against a configuration flag, despite what I said above. Too many config settings usually === stuff will break, either here or on a 3rd party wiki.

How many of these do we have? Could we not just default to commons/the file repo all the time? (or fall back to a local description if there is one present?)

Copied from description of T426848: Local file pages are getting indexed by Google (duplicate content?):
Upside:

• These duplicates fall out of Google, because they don't really exist other than when you link to them. They are generated/displayed on-demand, much akin to a search query or Special page. There is no record of them.

Neutral:

• MediaViewer is enabled on WMF wikis by default, and in practice when you click on an image, it opens MediaViewer, instead of this link to local File page. Changing the link thus should have minimal impact on where anyone goes when they click it.
• Inside MediaViewer, there is a "More information" link that goes the File page. That link already points to the Commons version.
• There is a popular gadget, Direct_imagelinks_to_Commons, which changes these links with JavaScript from local links to Commons links. It mainly exists so that editors can get to Commons with one click instead of two clicks. Today it requires two clicks, both with MediaViewer enabled (1: click image to open MMV, 2: click More infomration), and with MediaViewer disabled (

(1: click image to open local File page, 2: click View on Commons). With this gadget, those with MMV disabled simply click the image to go to Commons, and even those with MMV enabled can get there direclty by opening the link in a new tab (thus bypassing the MMV JS click handler).

Downside:

• For most readers, the local file page is going to be in their language (local wiki content language, their default user interface language), whereas Commons will be in English.
  • On the other hand, Commons has my gadget AnonymousI18N.js enabled by default, which looks at your referrer (i.e. nl.wikipedia.org) and asks you in a localised manner to reload the page "in <X> language". For example, in private browsing mode, open https://nl.wikipedia.org/wiki/Bestand:Example.jpg and click "Bekijken op Wikimedia Commons" and notice the blue banner on top asking " Wikimedia Commons in het Nederlands".
• The local File page is the only way to quickly see where this image is used on their wiki. On Commons, they would need to query GlobalUsage and then paginate a few hundred times to their wiki.
  • https://nl.wikipedia.org/wiki/Bestand:Musa_acuminata1.jpg#filelinks
• For third-party wikis, the local File description page is cached and available within their network/intranet.
• For third-party wikis, the local File description page is the only way to find local file usage through normal navigation (i.e. not manually querying Special:WhatLinksHere). This won't be available on Commons, not even if we build a better UI or allow for a hundred paginations, because Commons/GlobalUsage only stores usage information about WMF's own wikis.

In T421188#12107510, @Soda wrote:

Then there's the question of allowing linking to the local page if there's a local description. …

How many of these do we have? Could we not just default to commons/the file repo all the time? (or fall back to a local description if there is one present?)

Falling back to a local description if one is present is what I would suggest. I've no idea how common it is, but it's certainly not uncommon, at least on English Wikipedia – i.e. featured pictures and the picture of the day.

Change #1321666 had a related patch set uploaded (by Amdrel; author: Amdrel):

[mediawiki/core@master] [WIP] Link directly to external files instead of proxy page

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

Seems that the more that this is investigated, the more complex the implementation and impact becomes, so thank you everyone for helping move the debate as this wish has been on our radar for months. I don't feel too strongly about any proposal though as an avid reader, I personally find the status quo confusing.

I do like the suggestion to just fall back to a local description if one is present since time and effort has been put into these, but I would like to hear if anyone has other counter points - besides suppressing Commons as highlighted by @Prototyperspective in the original wish? It does make an inconsistent user experience (though we don't know how common it is?) - unless the intermediate page is deprecated. This was also a closing thought in the wish; however, this would be a much larger investigation, decision (data-driven!) and implementation.

@Amdrel and I think it would be safe to make the magnify icon act as a direct link to Commons that bypasses the MediaViewer. On changing Commons file URLs to bypass the proxy page. we need some more discussion and consensus, e.g. exceptions There is a proposal tracking bypassing of the proxy page specifically in T426848 as well.

There is currently no way.to change the URL in the magnify icon and not change it in the thumbnail itself, and there hasn't been since https://www.mediawiki.org/wiki/Figure_migration (≈2022).