Good to know, thanks for this info. However, then this issue is about the remaining piece to set it to automatic by default like basically every other website that has dark mode. I'm not signed on mobile and I'm not saving any cookies either.

@JTannerWMF The In The News module only displays very few items. On desktop the Current events portal is quite popular and I think the In the news module is also quite popular even if not the most popular nondefault module. I don't think there is much of an overlap in content because there are only very few items in the In the news module. However, as proposed it could be integrated into this module – I think it would best be a separate module that is only informed about at the In the news module (eg via an extra option in the context menu of the three dots of that module in the feed). Using machine translation, this item could easily be made available in many languages; by default it would only be enabable if English is among the languages of the user. I think this would be one of the top ~3 ways to make the Explore feed several times more interesting, with the other being simply showing more recommended articles.

Yes, the former. See "The problem is that there doesn't seem to be any way to make it use the MediaSearch" so this is about enabling community members to adjust the template so it uses MediaSearch which is currently not possible by changing the InputBox extension.

Not a duplicate:

You misunderstood. You don’t know what meta theme-color is. theme-color makes the browsers’ theme match the theme of the website.

This was just a brief note. If it saves people's time it useful to those people. The player is not fine and not used by large companies for long audio files. Try jumping around in an hour long audio file with an audioplayer of width 30px that looks like it's 2003. I do NOT want it rewritten from scratch and I just wrote that again previously.

So if I understood correctly you'd like to have the device theme be applied to the mobile Wikipedia site so that it turns on dark mode when dark mode is enabled on your phone, right? Because the current title makes it seem like this is only about live back and forth switching between the UI mode which is also why I didn't find this issue when searching for it before creating issue "Enable applying the device theme for the mobile Wikipedia site to turn on dark mode". Please consider changing the issue title to something clearer and broader if this is not just about dynamic changing of the site theme when changing the device UI mode while the website is open(?)

@Aklapper Does not yet exist nor does it need to. A person who may look into this may be interested in learning about this and this isn't about discouraging people to just not look into this issue but to instead look into replacing the audio player more holistically instead of just tinkering with it dark mode comparability. It was a brief short comment until you made a discussion out of this.

@Aklapper Disagree. I would not comment if I would not have a good reason for why it's constructive and useful at that specific location so please don't assume I would comment for no good valid reasons. The reason here is so that people don't spend time, effort / resources on things that should instead be replaced anyway. Moreover, "rewritten from scratch" is exactly not what I'm proposing, what I'm proposing is to integrate adjusted readily available open source software like >95% of websites with audio files do.

The audio player is generally outdated, rather than fixing this issue and any other ones, one should instead add a new proper modern audio player right away.

Found this via the proposal. Please also allow specifying which languages are shown at the top so it doesn't change every now and then. There could also be a field above Suggested languages for these configured languages which could e.g. be all the languages one understands to some extent (or all languages of WPs that one frequently uses for machine translated things where eg the WP has relatively high quality/coverage and MT is good for the lang).

Thanks a lot for this heads-up. I didn't know newcomer tasks were this different from suggested edits and some links on the NT page link to suggested edit pages so I'll look into what the differences are.

The example works now after recent improvements to deepcategory (also see T376440) so here is another search query that produces the error (which the user is informed about in SpecialSearch but not in MediaSearch): deepcategory:"Audio files of music" -deepcategory:"Audio files of music by genre" (link)

Duplicate of T356244

Thanks TJones for spotting an error in the link – I think I tried this search earlier and it didn't work and didn't show an error but now it works! That's really great and probably comes from the recent work on deepcategory.

This is already possible on Talk pages – example https://meta.wikimedia.org/wiki/Talk:Community_Wishlist/Wishes/Allow_for_deeplinking_text_(quote_functionality)#h-Text_fragments-20241021043800

Another example is that it would be best if only languages are shown or shown at the top when entering a value into the language of work or name property. One could store all the languages in the one-of constraint or something similar that affects the autocompletes. For example, one could query items that are instances of languages once a week and attach them to that input box as values that should be shown in autocomplete so all the other items are shown in grey so the user can easily see which ones are (most likely) the correct ones. Prior discussion is here.

Briefly, there are more and possibly better use-cases than the ones listed, including: checking for copyvios or vandalism, replacing a batch of files, or in my case for reuploading videos that were imported below resolution at the source via video2commons. It also allows seeing galleries of files uploaded by a user via the MediaSearch which is what this gadget and categories like this are about which are also useful. I think uploader is already available in MediaWIki and this data would need to be made available for the search. However, the search operator shouldn't be called since it's about the uploader of files, not the author/creator (the latter can already be searched).

I doubt you have really read this issue. None of the use-cases can be implemented with that. That view does not allow filtering by filetype such as video and it also does not allow filtering by video size for example. This is about making search by uploader available in the search due to all its filtering options such as deepcategory search, video size, text search etc etc. That's the whole point of it.

It now returns incategory search results instead of no search results. This is better than showing no search results but not what this issue is about. I'm adding this note in case people come across this issue and think it's been implemented since now there are search results. It's also problematic that it's changed with no error message in the MediaSearch – I only found out by searching for deepcategeory:"Science" which shows just 1 image because this many files are located directly in that category instead of in subcategories of it (the search results are those of incategeory:"Science"). Note that caching could be used to display deepcategory results once people use this more widely such as via the Deepcat Gadget.

It was also proposed here (with some further input). One could enable/disable these notifications in the preferences. This feedback is needed to keep/make contributing engaging and facilitate more of the media that gets used. The Glamorous tool can already show which of one's files got used so maybe some of its code / functionality could be used. Also important to only show the first use or have a setting for that instead each and every use. It would be good if the Idea image (design mockup) could be uploaded to Commons (to here), it seems okay that if not I upload it under CCBYSA(?)

This would be a very useful feature. Please add it also to the languages the user can select an article from:

This issue is about Wikipedia but this would be much more useful for Commons, Also see Talk:Add an AI image filter to MediaSearch.

Seems like much less or no issues now. In any case, please add some info when queries are stopped.

Please prevent queries from getting stopped. One went through but the other still gets stopped all the time.

@TheDJ That doesn't seem to be the case, got a reply in the issue and getid3 does display the duration just fine. FLAC is the best audio format so this is a real problem. The examples have been downloaded from bandcamp. Maybe another version of getid3 is used which has issues? Let's keep this separate from the too long duration of the webm files – getid3 also shows a too long duration for them. So if there is no problem on the getid3 side the problem must be somewhere else and the issue be moved back from Upstream to Backlog please.

@rook Yes, I did not press the stop button for any of the queries that were stopped and it only displays the above two lines and not any further info like some error code. Other example: https://quarry.wmcloud.org/query/86864

Thanks for this info – issue now is here (depends on this issue): https://github.com/JamesHeinrich/getID3/issues/457

I like Connecting maps + lists. Please see the related task T360197 where I noted Maybe at a later point this could better integrate with WikiVoyage as well as with articles about certain subjects (for example an article about greenspaces in a region could embed the filtered Places map showing only these particular items)

The box with autocomplete suggestions should always open the bottom of the input box if the categories panel is configured to show at the top of pages and above the input box if it's configured to show at the bottom (default). I think that this would solve it / is what this issue is about, isn't it? I have this problem as well but could not reproduce it now so I guess it only happens for specific categories.

I think this is only useful for suggesting to create a category page of that name. It shouldn't show a redlink to a gallery.

@Isaac Interesting, thanks for this info. I think needed Commons infrastructure would be relatively low if it's just copied to physical hard drives and it could cover the costs via the price of the storage media.

This is not only about MIDI files so please merge the other task into this one.

This is not what "merging" is, you added a link to the task and left everything else the same. Please merge to the other task since a) the other task contains more detail and more info like ffprobe b) it's not just about MIDI files but also flac files.

Addressed these two in the separate issue. In short usually that search operator is not used for exclusion and when it's used for that, it's usually a small branch and if not there's still many cases where the partial results would be very useful and even you example doesn't mean it's useless – the user may e.g. only require more time to glance over the results to not select any images of large trees which the user may need to do anyway since many photos of large trees are not in that cat. The excluded categories could be in an auto-collapsed box (preferred) or only show them if it's fewer than 5 to name two solutions.

Okay didn't know it was a team project tag.

Amazing to see progress here which doesn't happen all too often for major issues. Thanks, this is very useful for many diverse applications such as making categories complete and preventing miscategorizations.

This means for example that people can vandalize articles as much as they want and then simply request e.g. Citation bot to fix a few minor issues in the article to hide their changes from people's watchlists. It's certainly not what many if not most users trying to hide bot edits from the watchlist through checking "Human (not bot)" think will happen. So this is really very important, can't believe it's apparently open since 2007 and was in the Wishlist in 2016 – since there is a patch what is the problem with it? Even disabling the bot edits filter until there is a better solution would be better than doing nothing.
Probably the item in the Watchlist should be sorted chronologically according to the last human edit so it would be further down and the edit summary shown there the last human edit (when one clicks on the diff button it would show the last human edit, not the latest edit which is some bot edit). A Watchlist feature to see a diff of all changes of an article with one click as well as a way to exclude edits by e.g. Citation bot, InternetArchiveBot and OAbot from diffs (esp. such large diffs) are also needed.

This functionality is already in MapLibre. A dev said:

clustering is an optional feature, you don't need to use clustering at all. I.e., it is already possible to show all dots at once, regardless of the current zoom. It is also possible to for example only have clusters appear on certain zoom levels.

Could you please add a button and/or preference to turn off clustering if it's already built in and apparently only needs to be enabled somewhere in the UI? I think it's key to making the Nearby places feature really useful and used more.

I've proposed this in the Community Wishlist. I think it's one of the two main problems that make the Nearby places map barely usable or quite difficult (and thus much less used) in real-world applications in practice.

GitHub issue at the MapLibre repo is here.

How does this relate to Simple Wiki – could it be used to create article drafts the user can then improve (maybe even dynamically generated simple versions that are in sync with changes to the sources article)? I think at this point one of English Wikipedia's greatest challenges is that articles and sections are just sooo long – most people don't read all of it but removing things is usually also not due. I think adding section summaries to the top of each section is one useful approach, could the use of AI summarization be another? For example, maybe there could be a [button] to show a summary of a given section. Re "what metrics should we use to decide whether the model works well" I think editors should be able to adjust generated texts similar to what's described here and the adjustments and corrections would be used as a key metric to show how well a model works (e.g. less adjustments of checked generated texts marked as 'correction' = better model). WP articles should stay as indepth / complete as they are but at the same time people want short texts on demand and best with the option to easily see the more complete version as well if it missed some subject or is interesting.

I hope the issue was clear enough – I noticed I didn't use the word cluster but these are what I'm referring to here and I don't think it's low importance: this and the issue of not being able to exclude mundane places articles like railway stations and schools from the map (T360197) are why I can't really use this feature in practice in the real world.

@Miriam Thanks for these infos and for looking into it. I indeed found that text-2-speech applications are missing in that table. I don't know if it would make sense to deal with machine translation separately but if not that is also not yet included there despite being the one key main use-case for Wikipedia (and already widely applied).

It doesn't have to be dumps downloadable online (btw if they were online they could also be distributed via torrents). They could be cloned / copied to hard drives that people/organizations can buy and this could also generate a little bit of revenue. Moreover, I think videos are also valuable training data and Wikimedia Commons dump are definitely not only about AI training data but also have all sorts of other potential applications including making the data more resilient against data losses. Please see the proposal here and the Wikimedia Commons page about Backups and dumps linked there. For NSFW removal deepcategory:Nude people could be used and one should definitely include the metadata of the files like their categories so people can selectively remove or select such subsets afterwards. One example of how dumps can be used for other purposes than AI training is identifying essentially duplicate and very similar images and then letting a bot e.g. link the other versions in the file description or suggest duplicate files for deletion and so on (that's just one example, there's more ways this could improve WMC itself or the open source software ecosystem). Edit: seems like the main issue rather is at T298394

Interesting.

• Dumps of Wikimedia Commons would probably some of the most useful but they are not available publicly and scraping them could cause strain on servers and limit accessible open source innovation. Proposal to change that, which may even be somewhat profitable, is here. If you mention dumps and their use in AI systems, I think this should also at least be mentioned.
• One could also mention things where AI is already widely used in Wikimedia projects such as for vandalism detection + reverting via ClueBot and maybe the Read more links in the app(?)
• Generally a good way to think about AI in Wikimedia I think is by thinking about tasks people do and then how each can be boosted/improved by AI such as via that SIDE tool for adding citations
• Mainly, please do read my input here T369281#10148809 about AI for video dubbing, transcripts, and spoken Wikipedia which are applications ready for adoption in need of technical development etc. When it comes to datasets, one could e.g. consider Wikipedia text to be the dataset for AI spoken Wikipedia and raise the question of how Wikidata could eventually be or not be used in AI as it is now.
• If this proposal was implemented corrections of machine translations by Wikimedia contributors would be very valuable data for improving machine translation further which could enable some Wikimedia machine translation system to become really good. People would correct mistranslations (e.g. semantically or grammatically) or things not correctly translated but still not as intended (like translating 1905 in one language to nineteenhundredfive in English). Any or a few such corrections would sync every other instance of that flawed machine translation and would improve the translation model until the quality of the machine translation is even higher than e.g. English<->Spanish already is.

Would like to briefly mention that this would be great to make Suggested Edits more engaging and interesting by having it suggest tasks for topics the user in interested (and likely somewhat knowledgable) in (which also turns Suggested Edits into something also relevant for more experienced users rather than only new users). I don't see how the task about streamlining existing recommendation systems to incorporate topics would include that so likely a new issue would need to be created for which this is a reminder (+ pls subscribe me to it). Some more input on this (better personalized Suggested Edits etc) here.

Ok great. So I think there overall are three main ways AI can be used and while I'm likely missing some I think those are machine translation (one two), video dubbing + subtitles, and spoken Wikipedia.

Here is a file with wrong duration (much longer than actual). Maybe it's a related problem, e.g. it may improperly read the duration from some metadata.

Is this also about users naming models that are useful? I know of an AI tool that is extremely useful in practice which integrates several models and for which I'd like to have some integration into Wikimedia Commons so things are go smoother, quicker, in standardized ways, and better than already demonstrated.

Would a screenshot be helpful or are things clear enough and this problem easily reproducible on test devices? (again, third grey from left in color scheme then scroll to bottom of any article)

Thanks, no that wasn't the problem. The problem is solved now and I'll edit my mention of this tool here (I don't think this could be used for searching for similar looking images and/or detecting similar images at upload to prevent duplicates but if so that would be great).

Only shows "Search ready" after uploading a small jpeg file via Browse.

I was talking about the link I posted. Let me know if I should rather open a new issue about it. ffmpeg and all other tools show the proper duration locally. I'll add the link and the info to the issue description in case people don't see the comment.

Okay that's just a workaround then. Maybe it doesn't even fix it since the duration is already set properly locally. Moreover, it would not fix this with bulk imports or imports via video2commons once and if such becomes possible.

@Mitar how did you fix the files?