Related issues: T329961: Sort media by date captured in MediaSearch and T71417.

Maybe it got changed in the meantime then. Sent you a mail with the day and further info.

Saw your reply too late and prefer to also send you the answer on that as mail: I've made a screenshot but I think only the question before or after the one I'm talking about in the issue: it was on 25 September where it asked questions about 24 September in English. If I'm not mistaken regarding the screenshot, another question there was asking about the Second Council of Nicaea (https://en.wikipedia.org/wiki/Second_Council_of_Nicaea).

What about enabling HotCat by default?

This is what is proposed in this issue – particularly showing the caption in one's language in addition or instead of the file-title if the title is not in one's language and a caption exists. The caption exists only for a small <5% fraction of files. The problem isn't – or rather the problems aren't – easy to describe in short words but it's well-defined here – to put it in other words: many file-titles are in languages other than the one(s) the user understands and a lack of metadata about file-title language impedes any addressing of this such as for example that captions display idea.

No, it doesn't solve this problem at all. It doesn't specify the language of the file title. The captions which are set on a tiny fraction of files, often only as a subtitle complementing the file-title, is for example not what's displayed on category pages. Filenames are not "rather irrelevant" at all as explained in the issue already (edit: and saying they are irrelevant is a rather shocking display of ignorance imo).

For internationalisation. Please read the issue first before commenting and also take a look at the linked page(s).

The full implementation depends on T404955 to be implemented first

Would be better to upgrade the entire audio player; see https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/A_proper_audio_player

I think the solution is the so far best solution to it. Moreover, please do not stop allowing comments while supporting – if anything incentivize or facilitate them more: votes are much stronger and much more valuable, useful if they are explained. Instead, one could highlight or integrate the wish's talk page more.

Can one click the module to see more than the top 3 categories?

Just a minor note: it would be great if links to phab code issues linked like [[phab:Tid]] across the Wikimedia projects (such as here) would also show the issue title, for example when hovering over the link. This is pretty similar to what's suggested here but since phab is not a wiki, it may not be readily possible and if it is possible probably in a quite different way than for wishes. If however there is a way to implement this, please let me know so a separate issue can be created.

Okay, thanks for identifying the responsible team and for the link to the instructions on how to report this. I'll create a separate security task as described in these instructions.

Maybe I shouldn't have written that I also use a VPN. The site is exempt from the VPN. I'm not using a VPN for it. Because of the inappropriate bans of VPN IPs I couldn't even edit otherwise. All other sites like Youtube load just fine, it's just Commons (maybe also other Wikimedia projects) that load slowly. It often works perfectly fine but right now also images and even just any kind of Commons pages barely load, making it near-unusable. The site is broken now and it was working great without any issues for 3+ years.

In T405760#11231467, @Aklapper wrote:

What does the load chart in the network tab of your browser's developer tools show? Is there a specific call which takes longer?

Reopening: 1. the "🌎 Use this file" button is displayed by default also for logged-out users so I think such issues are also to be tracked here and fixed by devs even if it's from a gadget 2. various other gadgets are tracked here, at least default-enabled ones 3. if it isn't yet tracked then again it probably should be (and especially so if its issue are not tracked in some other issue tracker which would only make it more complicated) 4. it does seem like its issues are tracked here when searching, see for example T317699 T368190

I don't know if the removal of the searchbox was intentional; I think it was very useful and would be good to re-add either way.

@The.ed17 Thanks, I had already pinged dschwen (and Krinkle) right after it was down again here. The short summary is please check what's causing this, for example by improving the logging and/or looking into the logs etc. It's a pretty useful tool and all buttons displayed on so many Commons pages really should be functional.

Yes I know that's just the upper layer. Just mentioning this and the speed is much faster than what's needed to play Commons videos. Thanks for the elaborations nevertheless. As said, I'm not even using the VPN for Wikimedia and also other websites as well as the speed test are fast with the VPN. I know VPNs are not sufficient for privacy but I think they're required for it (and especially so for people that use laptops on the go) but that's going offtopic.

• Right now the load quickly again but the whole day it was slow and it was often like the past days. I'll update this with info on which call takes long to load. This variability is also quite strange, it's not slow all the time.
• I also did an Internet speed test and it was as fast as it should be and again other sites like YouTube videos load quickly. Today and I think for shorter times a few times the past days loading images or even just Wikimedia sites was quite slow too.
• I'll briefly ask if somebody else is also having similar issues.
• I'm using a VPN and because of Wikimedia's super annoying bans of VPN IPs, I had to configure routes so Wikimedia sites are exempt (no other site needs this). I was wondering whether it's an issue with how I configured the routes. Recently, I think I had to reconnect sometimes to make things load but then other times things run smoothly for days or at least many hours. Guidance on how to sign up or contribute to Wikimedia sites without having to give up privacy (in the modern world Internet privacy which requires a VPN) would be great like info on how to configure these routes or allow VPN IPs for registered users. For example, I had to ping various sites to know which IPs to exempt. This worked fine for years - these problems only started relatively recently.

Videos used to start quickly and to load quickly. Since a short while they aren't anymore. Maybe I should ask on a Commons board whether other users also have this problem or if it's something about my connection if you don't have this issue and it's not clear that some/many other users have this too. My connection speed is fast enough and I can load YouTube videos for example very quickly. To answer your question, in the cogwheel of videos, the resolution is set to HD 720p.

First of all here's a screenshot of how it looks like. Ok, thanks again. I'll send you a pm. I think other apps have similar issues but there usually the text is readable albeit at times barely – if other apps somewhat fail with this and/or it's caused by the device's software then that doesn't mean the Wikipedia app can't make it better and have all texts readable also on my type of very popular device.

I would suggest the person who coded the text simply takes a quick look at the UI element to check how the background color is set. Other than that: would it help if I send you my device model name in a private message?

I tried it with the latest version 2.7.50549 and it's the same there. I have a device many people have so I don't think I'm the only having this even if many devices don't have this problem. Maybe the background needs to be defined explicitly for dark mode. It could be similar to the issue T362471 which is solved by now. Android version 11.

I wonder why this is solved. Just FYI it does display the colors properly now even with dark mode enabled and I don't know since when. Maybe a device issue; it's strange. This issue lasted for quite a while when I had this.

Who would benefit from grouping results per page by day? I don't get it. It just makes the Watchlist even more cluttered and harder to go through for basically everybody on an active Wikipedia with a normal count of watched articles.

Solved to some extent now that specifying searchengine = Search makes search boxes use SpecialSearch. In some way that's a workaround – as described these meta page searches should also work with MediaSearch so the issue remains. In any case, that's why those example templates are working again in case somebody was wondering.

Nikerabbit Okay but then it shouldn't be linked like a page showing all translations made. It's linked as "Translations" in the profile dropdown which has just few items. And there it's presenting itself as the only way to translate articles and to show all translations one has made when under "Published translations" it really only shows "Translations published with this tool".

Are there any news yet what the cause of this problem is or how it could be solved? FastCCI (again a super useful gadget if it works) has just been removed from the default gadgets and is now not showing anymore for most users and all logged-out visitors due to this problem of it frequently not loading.

it does sound like InputBox needs a way to set MediaSearch's type, perhaps searchtype=(image|audio|video|other|page)?

Yes, "and some parameter(s) for the tab that should be opened which is "Images" by default)" in T378756. If one specifies pages, then as described The prefix search operator is not applied anymore so this would need fixing first before MediaSearch->Pages could be used instead of SpecialSearch for pages like Help:Contents that search through certain discussion pages with a specified prefix.

I disagree this is low priority and think this it's medium priority with probably not super much effort required to at least add some input box with autocomplete where one can enter the location by its name (like a city name). With that I mean it would probably have a high impact ratio.

Have you read https://www.mediawiki.org/wiki/Extension:NearbyPages ?

in the docs:

It is also possible to manually specify a location by including its latitude and longitude as URL parameters. For example, this URL will generate a list of articles near the w:Statue of Liberty in New York City, US:

https://en.wikipedia.org/wiki/Special:Nearby#/coord/40.69,-74.04

Yes. Seems like a relatively urgent problem. Probably would be best to have a separate issue for this. Created T399476

Okay many of these seem broken since: 1. Categories and Pages isn't preselected and 2. even when manually going to that tab, it somehow dropped the prefix search option (tested with the VillagePump search box). Are there prefix option (/ equivalent options) in MediaSearch?

In T378756#10996219, @GPSLeo wrote:

I am not aware of any usage of inputbox on Commons where using MediaSearch does make sense. The default should be the old search and MediaSearch should only be used when a parameter is set.

Could something like this short text be added to the confirmation mail? I think it would substantially increase newcomer engagement, help get more things done, and help users get started:

@Samwalton9 Thanks! No, there isn't afaik except if the default is SpecialSearch which it shouldn't be.

@Samwilson Under "Choose your search interface" I already have MediaSearch selected but it still doesn't use it. I don't know if that's the default setting (and the setting for users who are no registered&loggedin) but if not it really should be by now. So if the inputbox was changed to use whatever is configured there and mediasearch was the default, then this would be solved.

That extension is only about the OWID Gadget. Maybe info should about the importer should be added there too (@Doc_James ?).

I don't know if it's possible to set a priority lower than Low but I think this would be suitable to be set to something like it:

• I meant to report that I don't get notifications when pages where I clicked "Subscribe" get updated but later learned Subscribe is only meant to show a notification when a new section is added.
• Listeria updates relevant pages so frequently (once per week) that notifications would probably be too distracting / too frequent
• Currently, there aren't so many bots editing on Wikidata so that I just changed my Watchlist to also show bot edits so that the updates by the ListeriaBot show up in it

Now this may very per case and user or at some later time but probably it's not that needed or useful. Also there are alternatives such as enabling the user to specify which thing they'd like to get a notification for when clicking Subscribe (just new sections or any change etc).

Thanks very much for looking into it. I think there is two routes: 1. one can download the subtitles with yt-dlp and add them to the TimedTexts which would require some change to video2commons and/or some tool that does it for videos imported with it from YT retrospectively 2. doing something like ffmpeg -i video.webm -map 0:s:0 subtitles.srt on the server.

"all pages" is very ambiguous – you probably don't mean the articles right? This would mark the changes as seen but not show a diff of what has changed. So is it the revision history page or a diff of all changes since last seen? I think a diff of all unseen changes is what would be most useful. I think the Wikipedia Watchlist is broken because it does not have a button to see a diff of unseen changes per article with one click. So lots of time wasted and it's exhausting to go through the Watchlist and I can't understand why editors are not calling for this is hordes since I can't even use the Watchlist without such a button which I had added via some script.

Yes; should have removed EN, I meant to refer to English Wikipedia but then changed it to mean multilingual wikis mainly Wikidata, Commons, and MetaWiki where also most comments are in English and quite a fraction of talk pages get quite many pageviews. If this was being used on Commons VillagePump, it would result in thousands of the same requests where it would be sufficient to just check once with the subsequent same requests being redundant.

The Charts extension has now been deployed also to English Wikipedia. For those interested in re-enabling interactive charts by converting graphs to the new Chart extension, see this tool graphDataImport which makes this quick & easy and also the alternatives in the See also section there. Anything related to any of this can be asked in this new WikiProject.

@Samwilson I suspect this would need to be revisited at some later point then. Most EN talk pages get quite a few views per month so it would make much more sense to only load and set the language the first time it's loaded and then store/cache it somehow. It has been already loaded when the next user visits the page. It's relatively rare currently that people comment with nonenglish comments and there probably will be doubts whether so many duplicate API requests are adequate.

@Samwilson In the description of that change (would be really useful) it says "When the page loads, a request is made to the Lift Wing API to get
a prediction of each thread's language. If the result is different from the current interface language, the translation button is shown." but wouldn't that lead to many unnecessary requests, longer page-load and server costs? I think it would be better if it just always showed that button or if talk page comments were labeled with the language just once (probably when users post a comment with the Reply tool).

The problem remains: How to find out in a technically feasible way that you translated a page if there is no trace in any log which shows that you wrote a translation (means: text source was another Wikimedia wiki) instead of writing a non-translation?

@Aklapper The full link is https://de.wikipedia.org/w/index.php?title=Special:ContentTranslation&campaign=contributionsmenu&to=de

@Samwilson In my opinion yes. Thanks for looking into it.

• Images gallery elements aren't necessarily small
• I think a main benefit of the Charts is that these are interactive so showing some static cached version would entirely negate that. Much of the whole point of using charts in the first place is that these are interactive; and if this is done the problem of including charts in galleries would still be there.
• In regards to performance etc it could be best to load and show a cached static thumbnail by default but load the chart when the e.g. the user hovers over it or clicks some button on it like [toggle interactivity] – I think that's an issue relating to improving performance, reduce server costs, make pages load faster and be less data-heavy; and not relating to enabling charts to be included in various types of containers

Salino01 thanks for those examples! @Tkarcher That was just an example chart. Even then, having an interactive chart is or can still be advantageous as one can hover over the individual year points. I think a main benefit of the Charts is that these are interactive so showing some static cached version would entirely negate that. However, in regards to performance etc it could be best to load and show a cached static thumbnail by default but load the chart when the e.g. the user hovers over it or clicks some button on it like [toggle interactivity]. That's not really about this issue though. Again the much of the whole point of using charts is that these are interactive; and if this is done the problem of including charts in galleries would still be there.

Well the reason for why I reopened this issue is that it seems to be the same problem (again or still). It's not about MediaSearch, it also doesn't work (anymore iirc) with SpecialSearch. However, now results are showing again so it seems like it was a temporary problem that's fixed now.

What happened now? Didn't this work just two days or so ago – see T391876

Is it within the scope of this issue to enable charts to be included in <gallery> s? For an example, see https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Data_Visualization#Examples – I'd like to include that chart in the gallery next to the images.

Great that this works now. EBernhardson, is there a way to leave things as they are but give the user the option to click a button to load more files (larger depth)? e.g. [click here to load more]