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]

Reported at https://bitbucket.org/magnusmanske/glamtools/issues/291/info-on-glamorous-2-to-glamorous-tool

I don't think I have a bitbucket account. I think very few people on Commons have. Could Manske please move it on GitHub like most external Wikimedia tools and for which at least many and maybe most issue-reporting issues have an account? Having it on Bitbucket makes things hard and makes this difficult to find etc. Alternatively, consider whether Phabricator could be used for this.

Great, thanks for solving this! Has something changed about this or is this not applied for some cases?: I was looking for example photos of factory interiors for a new photo challenge proposal and tried to use deepcategory:"Manufacturing by product" but it does not show any results in the MediaSearch. Why is that? The special search does show results with the note "A warning has occurred while searching: Deep category query returned too many categories. Only a subset of categories has been applied." but the MediaSearch doesn't. Maybe a separate bug should be filed about it – iirc it did show results in MediaSearch for other categories of that type.

In T353659#10724203, @tstarling wrote:

Yes, exactly. The requirement to upload MP4 videos via an unsupported tool is the result of the Commons community's commitment to patent purity. We can't just integrate V2C as Yann requests.

@HNordeenWMF Thanks for explaining. That's very understandable and I was not suggesting that it seems like you'd prioritize iOS over Android or anything of that sort. As I linked this issue at the meta wishlist proposal about an iOS I thought I should at the same time also leave a note about the Android app.

Aklapper: Please move your comment to forums, thanks. Also you misquoted my small relevant good-intentioned friendly ontopic comment.

If there is WMF support / development of an iOS, I think there should be at least as much support / development for the Android app. That is because (probably) a much larger share of users and especially contributors is using Android vs iOS, fairness, and that Android is more open source than entirely closed-source iOS. Issue in the Android app repo is here.

When uploading a SVG from OWID I first need to open it in the text editor, remove the problematic line, and then can upload it.

This seems to be about some sort of new type of tags, not Wikimedia categories. "Only one category can be selected per wish" – categories would be so that one could have multiple categories for a Wish. Please enable adding multiple categories.

Should have added this was when logged out on the mobile Web site of Commons. I don't have any preferences set so this is just the default displayed to all logged out users. Again I'm not even logged in.

Does this include resolving redirect categories so that if the user enters a redirect, it adds the category the page redirects to (and not the redirect) like HotCat does it too?

Finally at least a workaround has been found: replacing the [ with &#x5B; and ] with &#x5D;. (This can be done with the wikitext search and replace in the top right of the source editor.)

Please let me know if something did come out of this that could be used to set the given name and last name properties for Wikidata items that are instances of human on Wikidata since I made a bot request for that where this issue got linked.

This would be quite simple to fix: just don't show this entirely unnecessary large sea of blue next to each item (removing the code that does that). Alternatively (the better option): make this a setting with the default being set to not showing this sea of blue.

Another example, I could not link this https://glamtools.toolforge.org/glamorous.php?doit=1&category=Creative_Commons_videos_by_German_public_broadcasting&use_globalusage=1&ns0=1&depth=10&show_details=1&projects[wikipedia]=1 here: https://meta.wikimedia.org/wiki/Wiki_Loves_Broadcast/Media#Examples_in_articles

Well it could also be below the Maximum file size: line.

None of those strings, I will attach an image to the issue to visualize an example of the change requested here.

Is this the same issue since this bug report here does not include that same error message? If it is here is another way this can occur:

I don't fully understand what is meant. This is about the info in this box shown in the page that is shown when clicking on Upload a new version of this file (see below). I don't know how its content is set but it apparently can't be edited as wikitext.

Where is this launcher shortcut? I don't see a widget for places nor do I have a second shortcut for Places. Is this about some link to the Places map within the map and if so why then does the Feature summary say "directly from their home screen" which I think refers to the Android home screen?

The focus area including this task / proposal is now open for voting along with a few other Commons-related areas: https://meta.wikimedia.org/wiki/Community_Wishlist/Focus_areas/Media_formats,_editing,_and_display

This would be very useful. For example to have video timestamp links for sections of a spoken Wikipedia article audio. Please see https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Video_%26_audio_chapters_(jump_to_timestamp)

I don't see any re-use tab, could you clarify? How should the source appear if it does not have that URL? If it's linked to the URL, it already shows up when you ctrl+f search in the wikitext editor.

@TJones Sounds great. Yes ways to narrow the results would be very useful. So it would be best if it showed partial results and along with at the top showed some ways to narrow these down.

1. A slider to change depth (I think FastCCI has one such but I can't check since it doesn't load; one could also add a search-operator like depth:x in addition)
2. Ways to filter out various types of subcategories such "xyz in fiction" and "xyz in art" categories (these are named in always-the-same standardized ways and are in the same category and one could exclude them for example by appending -deepcategory:"the relevant subcat found in this branch"). There would be filters to select from and people could add more of these filters (3. is also useful for new filters).
3. A way to filter out categories depending on the results – there could be some info at the top with the subcategories sorted by how many files they contain like:

1. CDC videos in English (3503 files) x
2. Videos in English (2700 files) x
3. Wikimedia videos in English (980 files) x
[show 50 more; 214 categories in total]

where one can exclude a category/ies by clicking on the x and then refreshing the search. This way one can exclude various large or unrelated categories which may often get excluded via the 2. filters (often because of particular types of subcategories like the in art subcats – e.g. a deepcategory search of cat Maps of the world does not contain only instances of world maps and due to miscategorizations cat Microscopic images also contains various files/subcats that aren't microscopic images).

@Izno No, it's not the same problem or the same code issue. It's not about the last unseen diff here like you just described. It's about a convenient button in the Watchlist to see a diff of all unseen changes. I don't know how people can use the Watchlist without it, I think the Watchlist is broken. Those two issues are not about the two same thing. If there is something that they have in common create a new subtask or create a new issue where these two are subtasks but the issues themselves are very different.

@Izno please don't close so quickly or more thoroughly compare: these are not the same – the other issue is about seeing all unseen diffs in one view like with the Watchlist showing edits directly in the Watchlist via the "Expand watchlist to show all changes, not just the most recent" option. In contrast, this issue here is about the normal Watchlist that shows one item per page but has an extra button to directly see a diff of all unseen changes for that page (one item in the Watchlist per watched article, not dozens of items per watched page),

This problem also exists for DuckDuckGo. Also videos on Commons are not shown in the videos tab of search engines. I don't think there is any other as important Commons issue. See Community Wishlist proposal Do something about Google & DuckDuckGo search not indexing media files and categories on Commons with 3 concrete things that could be done. Please change the Importance rating of this issue.

@TJones I'll remove that example. Thought I had it fixed here but it must have been somewhere else.

I think "Edits made at Wikidata" are something different than Structured Data edits on Commons. Also as noted in this related wish, one can already ignore AC/DC & Depictor & DepictAssist edits (which based on my watched pages make up most SD edits which are ~redundant to file categories anyway) by clicking on Tagged edits at the bottom then selecting it then selecting Exclude selected and saving the watchlist settings as default.

A basic way to implement this would be some "Request edit to title" button in the Toolhub that then links to a prefilled post on the respective user's talk page or however one is supposed to request this (and no extra moderation or anything needed). In any case I don't see why anybody ever would see it as acceptable that problems with titles just can't be fixed. A better way to solve this would be to just allow users to edit titles but as that seems "designed" to not be the case some request system is needed. Thanks for all the constructive info though and also for reopening. I don't see why anybody would see a way to change titles of tools as not an absolutely necessary component if Toolhub is to be live & used (which seems to be the case).