Commons:Village pump/Technical/Archive/2022/10

Language bug in heavily-used template

Hey, I found a bug with how languages are handled in {{Valid SVG}}, and I was wondering if someone could look at it and try to fix it. Please see my note at Template talk:Valid SVG#Bug: language set incorrectly if style=none. Many thanks, IagoQnsi (talk) 02:04, 10 October 2022 (UTC)

Bug has been fixed. — Speravir – 03:40, 15 October 2022 (UTC)

This section was archived on a request by: --Speravir 03:40, 15 October 2022 (UTC)

How to change a file name?

This section is resolved and can be archived. If you disagree, replace this template with your comment. Hi

I have uploaded File:Bathurst War Cemetery-A.J. Landon. (Sulight).jpg and need to change the file name to Bathurst War Cemetery-A.J. Landon (Sunlight) (drop the dot after Landon and change sulight to sunlight).

How should I do that? Should I submit a request? Shkuru Afshar (talk) 08:40, 18 October 2022 (UTC)

@Shkuru Afshar: If you're using the usual desktop interface, there's a "Move" entry in the "More" menu that will allow you to request renaming. Choose criterion 1 (original uploader's request). For more information, look at Commons:File renaming. --bjh21 (talk) 10:42, 18 October 2022 (UTC)

Thank you for your help :)

I did it as you said. Shkuru Afshar (talk) 11:04, 18 October 2022 (UTC)

Cat-a-lot error

I just got two insteances of upstream connect error or disconnect/reset before headers. reset reason: overflow (neat error screen, b.t.w., really the hallmark of helpful UI!) while using Cat-a-lot — which have been hiccupy these last few days. Centralized login has also been working (even) worse recently. Hey WMF, can you please drop all the nonsense about an audio logo and all other meaningless branding shannenigans and focus on your actual job, which is to make sure we can work? Thanksmuch. -- Tuválkin ✉ ✇ 17:31, 2 October 2022 (UTC)

Commons:Flickr2Commons

Looks like this tool is not well maintained these days. Could somebody take over maintenance and add/fix detection of duplicates (both existing and deleted) before uploading? Just preventing unnecessary deletion of majority of Category:Duplicate content. EugeneZelenko (talk) 04:48, 3 October 2022 (UTC)

Coolest Tool Award 2022: Call for nominations

The fourth edition of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December.

MediaWiki message delivery 18:30, 3 October 2022 (UTC)

Tech News: 2022-40

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• Kartographer maps can now show geopoints from Wikidata, via QID or SPARQL query. Previously, this was only possible for geoshapes and geolines. [1] [2]
• The Coolest Tool Award 2022 is looking for nominations. You can recommend tools until 12 October.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 October. It will be on non-Wikipedia wikis and some Wikipedias from 5 October. It will be on all wikis from 6 October (calendar).
• Talk pages on the mobile site will change at the Arabic, Bangla, Chinese, French, Haitian Creole, Hebrew, Korean, and Vietnamese Wikipedias. They should be easier to use and provide more information. (Last week's release was delayed) [3] [4]
• The scribunto-console API module will require a CSRF token. This module is documented as internal and use of it is not supported. [5]
• The Vector 2022 skin will become the default across the smallest Wikimedia projects. Learn more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 00:21, 4 October 2022 (UTC)

extracted images - I can't get the coding right

Hi Y'all. I extracted 2 images from Archives of American Art - Federal Art Project Artists - 3006. I tried to note that on the different files, but, well, I can't figure out exactly what's gone wrong. I've done it in the past, but cant do it now. Could someone figure this out? Thank you so much! Best, WomenArtistUpdates (talk) 21:10, 4 October 2022 (UTC)

• 
  Archives of American Art - Federal Art Project Artists - 3006 - original
• 
  Archives of American Art - Federal Art Project Artists - 3006 (cropped) - extracted 1
• 
  Jean Goodwin Ames - extracted 2

I think I have this figured out. If anyone wants to check my work., please feel free. WomenArtistUpdates (talk) 22:57, 4 October 2022 (UTC)

@WomenArtistUpdates: If you haven't already discovered it, the Commons:CropTool is really quick and handy for uploading crops, which faithfully transfers file description, templates, categories, licenses, and most metadata (with the exception of structured data, I believe) to the cropped image. It also adds {{Image extracted}} to the original. Then you can modify the new file as appropriate (tailoring descriptions, removing obsolete categories, etc.) after cropping. Cheers, --Animalparty (talk) 04:34, 6 October 2022 (UTC)

Hi Animalparty, No I did not know about the crop tool! Looking forward to using it. Thank you for the info :) WomenArtistUpdates (talk) 16:31, 6 October 2022 (UTC)

Hi Animalparty, Back again...is this a gadget I have to install? WomenArtistUpdates (talk) 01:56, 7 October 2022 (UTC)

@WomenArtistUpdates: There should be a CropTools option in the Gadgets menu of your Preferences. Once it's activated (and maybe after a page refresh or cache clearing), a CropTool icon should appear in the left side toolbar of the screen when viewing a file, somewhere near "Cite this page". --Animalparty (talk) 20:44, 7 October 2022 (UTC)

Animalparty, Got it. Thanks! :) WomenArtistUpdates (talk) 00:26, 8 October 2022 (UTC)

Can't change file

Hello. I uploaded this map (File:Physical map of Ancient Greece-ru.svg), and later changed a couple of names in it, started uploading a new version, but the changes do not appear on the map. What to do? Tell me please. You can see the changes in the history of the file, it does not change.

P.S.: This map (File:Settlement map of the Greek tribes before the start of the Peloponnesian War-ru.svg) has been changed. Changes are taking place in the Attica region. Пётр Тарасьев (talk) 07:35, 5 October 2022 (UTC)

Add ?action=purge to the url and purge the cache, then reload a few times. It should already look like a new image for other people. BoxOfNotes (talk) 02:17, 6 October 2022 (UTC)

Thank you Пётр Тарасьев (talk) 17:38, 8 October 2022 (UTC)

Tech News: 2022-41

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 October. It will be on non-Wikipedia wikis and some Wikipedias from 12 October. It will be on all wikis from 13 October (calendar).
• On some wikis, Kartographer maps in full size view will be able to display nearby articles. After a feedback period, more wikis will follow. [5][6]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

14:06, 10 October 2022 (UTC)

Illegal user talk page moves

i noticed some users moved their user talk pages, e.g. User talk:Bk2k22 User talk:Nat Christian. this should be prevented by the software. RZuo (talk) 08:49, 2 October 2022 (UTC)

• Is this a problem sufficiently common to need a technical fix?

Would the obvious fix to it cause more trouble, given that it would also prevent the creation of mainspace or gallery pages, from a userspace draft?

As this appears to be a rare problem, would it be better handled by a review process, such as making an automatic page listing such moves that have happened, so that they can be reviewed manually? Andy Dingley (talk) 10:39, 2 October 2022 (UTC)

I think it should be possible and not that difficult to create an abuse filter for this. --GPSLeo (talk) 18:49, 3 October 2022 (UTC)

How? It would pick up [7] but if it blocked [8] as well, then that could also affect some legitimate moves. Are we happy to lose those, or to require admin intervention to achieve them? Andy Dingley (talk) 23:03, 3 October 2022 (UTC)

thx User:GPSLeo for looking into this!

i'd like to clarify a bit. i think the best practice is to restrict moving 'user talk' to non-'user talk' by non-experienced users, because there is legitimate use of moving user talk pages, but we can safely assume such usage would only be carried out by experienced users. "experienced" should be defined by edit counts instead of length of usership. RZuo (talk) 14:02, 15 October 2022 (UTC)

Tech News: 2022-42

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• The recently implemented feature of article thumbnails in Special:Search will be limited to Wikipedia projects only. Further details are in T320510. [9]
• A bug that caused problems in loading article thumbnails in Special:Search has been fixed. Further details are in T320406.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 October. It will be on non-Wikipedia wikis and some Wikipedias from 19 October. It will be on all wikis from 20 October (calendar).
• Lua module authors can use mw.loadJsonData() to load data from JSON pages. [10]
• Lua module authors can enable require( "strict" ) to add errors for some possible code problems. This replaces "Module:No globals" on most wikis. [11]

Future changes

• The Beta Feature for DiscussionTools will be updated at most wikis. The "reply" button will look different after this change. [12]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:43, 17 October 2022 (UTC)

Did the Special:Search display change and break?

Tracked in Phabricator
Task T320459

Tracked in Phabricator
Task T306883

I still prefer to use Special:Search over the newfangled Special:MediaSearch. In the past 24-48 hours, the display of the search results seems to have changed, in that it now only displays cropped, squared thumbnails of the media content, rather than a full thumbnail. Was this change announced (e.g. part of the "MediaWiki 1.40" rollout), or is it a glitch or experimental change? Depending on the composition of an image, this can obscure large amounts of significant elements (e.g. a portrait may be be missing the lower half of the face or body, or a group portrait may cut off people on the far right or left), and also reduces the efficiency of browsing: it makes many files appear incomplete or poorly-cropped, (this is a square thumbnail in Special:Search results) and one is now required to click on the file to see the uncropped image and true dimensions. Is there a setting to change the display of results? Thanks, --Animalparty (talk) 04:22, 6 October 2022 (UTC)

Hi I noticed the change too. Plus one more bug. None of 3 tested browsers shows all thumbs of a search query list with 500 items. 10 or 20 percent don't show. It's not my connection speed and no repeated ctrl F5 refresh helps. Its a show stopper to this way of searching and hinders a productive workflow. And a request for a rollback of the 'update', if it was that. Also the cat thumbs look weird. . Peli (talk) 01:46, 7 October 2022 (UTC)

Yeah, I see a lot of broken links, and sometimes only slivers of the thumbnails. Looks like Wikidata is also implementing a similar change: simple searches (say for "John Smith") now bring up tons of square thumbnails: which is unhelpful for the millions of items without a value for image (P18), and also causes lots of mistaken clicks (if you click the very prominent thumbnail, you get the image, not the Wikidata item you're presumably searching for). --Animalparty (talk) 01:59, 7 October 2022 (UTC)

I see what you mean and agree, It counts for a search like "Cat:NN" too, the blanco thumbs are neither informative nor clickable. Max line numbers of the descriptions could better be set in a different way, I think. I suspect the current errors lead to network lag, already due to people reloading it several times. Very useful for the workflow are more simple ways to sort the table of randomly displayed search-results by: 1. alphabetically or 2. filetype or 2a. filesize or 3. date of upload or 4. uncategorised (or maincat) - This could make it so much faster to select and recategorize groups of similar items. Peli (talk) 10:42, 7 October 2022 (UTC) Peli (talk) 02:14, 7 October 2022 (UTC)

The same issue is now at Commons and English Wikipedia. Probably soon to be everywhere. I just want to know when and how it was approved. I admit I don't read every Wikimedia news bulletin, but when a huge change of this magnitude occurs, I expect at least a fairly visible announcement. It feels like the invisible powers-that-be decided to change things from high atop their lofty mountain, and didn't bother to tell anyone or solicit feedback (of course I could be wrong, but if so, where's the announcement?) --Animalparty (talk) 20:37, 7 October 2022 (UTC)

This issue is being discussed at en:Wikipedia:Village_pump_(technical)#Images_with_search_results, Wikidata:Wikidata:Project_chat#changes_in_search_result_display, and phab:T306883. --Animalparty (talk) 23:44, 8 October 2022 (UTC)

Ok, thanks for that link to the discussion on en.wp. But here on Commons it is not about disabling thumbs of files, but rather about how to get them displayed well (in proper aspect ratio) and completely (all thumbs on a page of 500 results should load). As for categories: the arbitrary thumbs are not needed. The different indent made them easy to spot. I don't think a developper introduced bug should be patched on user level to regain functionality it had 'yesterday', and it can't be a feature request either to make special (image) search do what it was designed for. Peli (talk) 12:24, 9 October 2022 (UTC)

It is a nice idea to add the thumbnails. It's just that the broken ones look bad. Instagram format isn't the rule here. Enhancing999 (talk) 14:32, 9 October 2022 (UTC)

Hi everyone, I'm the Community Relations Specialist for the Structured Data Across Wikimedia project, which also is responsible for the deployment of this new feature of article thumbnails. I'm deeply sorry for the lack of proper announcement about the deployment of this feature, and the least I can promise is that this will not happen again for next deployments.

Also, I'm collecting your feedback about bugs and problems you're having with this feature, and I already shared them with the development team. I will keep you posted about them. Meanwhile, feel free to ping me and let me know any problem you're noticing. Thanks a lot and again sorry for the disruption. --Sannita (WMF) (talk) 11:53, 10 October 2022 (UTC)

Hi Sannita. Today I noticed an issue with loading search results with mini's of 500 svg files, cropped to tiles as if it where icons to click on, it takes 25 seconds on my en to load that page. Und I thought vector graphics are faster to load than bitmaps. Anyway 25 seconds to load a page is not acceptable. load 500 svg Note also the missing bottoms of the images. Peli (talk) 12:08, 10 October 2022 (UTC)

@Pelikana Thanks, I added this problem to the list I already identified from your previous feedback. I'll try to let you know ASAP about it. Sannita (WMF) (talk) 12:11, 10 October 2022 (UTC)

Hi all, I have some news from the development team about the bugs and problems you raised here. First of all, thank you again for noticing them.

About how thumbnails are displayed: thumbnails are made to fill the required square, so any overflow is not visible. Unfortunately, this is not fixable at code level (there would be multiple cases to support and this would impact negatively on code), but if you want this could be fixed with a wiki-specific CSS override, in order to restore the traditional way of rendering the full image within the available bounding box.

About thumbnails not loading correctly: looks like there's a bug. A ticket has been filed about it (phab:T320406) and a patch is currently in code review, so this should be fixed in the next couple of days.

If you notice other problems, please let me know here or on my talk page. I'll try to get back at you as soon as I have an answer. Thanks again for your help and patience. --Sannita (WMF) (talk) 18:05, 10 October 2022 (UTC)

These three images have nearly identical thumbnails in Special:Search

These two images have identical thumbnails in Special:Search. Users won't know which is which until they click one.

Thumbnail. Is Amun:

standing?

or sitting?

The user won't know until they click

This stunning, Featured Picture

looks like this forgettable piece of junk

@Sannita (WMF): I'm curious as to what was the purported benefit of this change to Commons? phab:T306626 states:

As a casual reader, I want to have an inviting search experience to

-Be able to assess relevance of results

-Easily scan search results

To find content that I am looking for.

The changes may have beneficial use on Wikipedia, but none of those goals are met on Commons. I find it absolutely backwards and counter-productive to not show the full aspect ratios in SpecialSearch. On a project that is supposedly dedicated to helping users find quality media (not articles), this change will likely only cause more confusion, more false positives, and reduced efficiency, especially when there are multiple versions of an image with different dimensions. For example, a Special:Search for "William Shakespeare" Cobbe gives several nearly identical thumbnails for different dimensions or versions which are not visible until viewing the file page. A Special:Search for "J. L. Nichols engraving" results in two indistinguishable thumbnails, whereas the actual images are substantially different in content. And panoramic skylines of New York City should not appear like fuzzy squares. Hiding the true dimensions and image content until after someone clicks will almost guarantee a lot more clicking on unwanted content, which can be frustrating. Finding decent content from a text search should not be like a game of chance (maybe this image will wor- no, it has bad borders... Maybe this im- no, unwanted text.. How about thi-- no, poorly composed...). Some examples included. I'm glad to see this being looked at at phab:T320337, but hopefully they will consider the unique role of images at Commons. --Animalparty (talk)

@Sannita (WMF), Animalparty, and Pelikana: : I think it's obvious that this change does not make sense for Commons at all and that it should be undone as soon as possible. I have started phab:T320459 for this. --El Grafo (talk) 07:23, 11 October 2022 (UTC)

• Isn't this a misuse of Commons images at Wikipedia? Commons media a presented in way that doesn't adequately present them. Has the Commons community been consulted on this? Even if there is a requirement for Facebook developers to present them in that format at Instagram, why would Wikimedia's dedicated developer team follow that? Enhancing999 (talk) 13:50, 11 October 2022 (UTC)

  Not quite sure I understand your concerns correctly, but per COM:L that should be a non-issue as all files on Commons may be used in in pretty much any way, including cropping. El Grafo (talk) 09:35, 14 October 2022 (UTC)

Regarding Sannitas statement “this could be fixed with a wiki-specific CSS override”:

Put the following style rule either into your favorite userstyles manager browser addon (I use Stylus) or inside of wiki universe into your common.css for Commons only, or your global.css for all Wikimedia projects:

/* Display full thumbnails in Special:Search, again */
.searchResultImage-thumbnail .image img {
  object-fit: contain;
  object-position: center;
  border: none;
}

In addition, I want to point to my addendum to the technical Village pump in enwiki regarding the new behaviour at CSS Hacks:

/* Remove search thumbnails except for file searches */
.mw-search-result:not(.mw-search-result-ns-6) .searchResultImage-thumbnail { display: none; }

— Speravir – 20:01, 11 October 2022 (UTC)

Thanks, but I don't think that this is something that should be left for the individual users to fix for themselves. It should go into Commons' default CSS definitions. Is that something admins can do locally? Making this a Commons-wide setting should be entirely uncontroversial, as it simply fixes collateral damage that was done when developers were trying to improve other projects. El Grafo (talk) 07:12, 12 October 2022 (UTC)

@El Grafo the dev team agrees, this should go directly into Commons' CSS. I was about to say the same thing. Sannita (WMF) (talk) 08:36, 12 October 2022 (UTC)

Hope a severside css code change, and / or fetching overhoal, will improve the loading of all thumbs for lists of 250, 500 items and more. The local css hack does not fix that. I added a line to the css above to make the full thumbs show without borders, which was found here. Peli (talk) 13:55, 12 October 2022 (UTC)

Thank you, Peli. (Also Pinging @Animalparty, El Grafo, Sannita (WMF)) I asked in COM:AN for an addition of this rule in MediaWiki:Common.css, cf. Special:Diff/696047589/696058356.— Speravir – 22:02, 12 October 2022 (UTC)

To see if special search works well enough, I will search for "SVG" in some combinations like svg+paris and notice that a page with a file list of 500 results may take 30 seconds to load. list 500 svg results Svg+Paris. Thats too long. A more realistic search would be 500 jpg list Here the page loads fast enough but it fails to show all thumbs in one go. Peli (talk) 13:00, 13 October 2022 (UTC)

@Pelikana Thanks for your comments, I'm copypasting this to the dev team. Sannita (WMF) (talk) 13:10, 13 October 2022 (UTC)

(Pinging @Sannita (WMF), again.) Pelikana, I think, the issue is not related to the thumbnails. Your query, apparently SVG+Paris and then restricted to some namespaces, is probably not what you wanted to search and too general, look in m:Help:CirrusSearch for grey space. Without namespace limitation (actually with automatic default limitation) the query SVG+Paris works slowly for me, but the right/much better query would actually be SVG Paris, and with namespace limit: search for SVG Paris in Gallery, Commons and File namespaces. The same for the other query: right/better Breitner "RP-T" without limitation, Breitner "RP-T" in Gallery, Commons and File namespaces, and if you only want to get JPEG files as result you should first limit to file namespace and second to JPEG Mimetype: JPEG files with file: Breitner "RP-T" in title or description, though apparently you will get almost the same results in this case (the only difference is the gallery page about the paitings in the Rijksmuseum Amsterdam found by excluding JPEGs from second query: Breitner "RP-T" -filemime:jpeg. Edit 01:52, 14 October 2022 (UTC): Well, now there are two search results ). — Speravir – 01:47, 14 October 2022 (UTC)

How could I forget myself: If you actually intended to search for SVG files containing the string paris (or longer like parisien, but also parish) in title or description then same applies, the search query should better be file: paris filemime:svg. — Speravir – 02:07, 14 October 2022 (UTC)

Given the recent reply by @Mmullie (WMF) at phab:T320459, I have requested an edit to MediaWiki:Common.css. Hope that'll fix the cropping issue. El Grafo (talk) 09:49, 14 October 2022 (UTC)

 Done by @Raymond. Works fine for me; might need to clear your browser cache if it doesn't. I guess with that we can consider the cropping part of this resolved. El Grafo (talk) 10:55, 14 October 2022 (UTC)

The CAO search started just as an example of how sad and ridiculous it is to set a default crop for thumbnails disregarding original proportions. It never wil do justice to the intentions of the creators, unless specially prepared as a square image ofc. As I noticed the huge lag on 500 SVG items lists, I thought it was worth mentioning it, since it seemed to prove that the new way of fetching and composing indeed has lag glitches. Idk what or how I should search better but thanks for the explanations. I will look into it. For now, I just wanted to enjoy a list of 100 - 500 or even 1000 items to load without failures in one go. Here is a test of 500 jpg's that still does not do well for me. Peli (talk) 03:30, 14 October 2022 (UTC)

Pelikana, oh I forgot the setting for image amount. This said I have set it in my preferences to 500 and all queries above work with this setting – also you latest example, I got the results in tenths of a second. More than 500 results on a page is not possible anymore. — Speravir – 00:28, 15 October 2022 (UTC)

The merely hypothetic large "coa+svg" search result is still a bit slow (btw. what is intake-analytics-wikimedia.org ? is that site doing well?). But yes and yay! the extended jpg searches do well now, especially after I cleared local browser cache. Thank you everyone. Peli (talk) 13:14, 15 October 2022 (UTC)

I still do notice some glitchy behavior. All thumbs loading easily in paging through categories of a few thousand items, but when I want to load the same images trough special search, 500 items per view, always a few, say 10%, refuse to show despite of several times reloading the page. This makes it hard to scrutinize the complete batch. Peli (talk) 00:25, 18 October 2022 (UTC)

@Pelikana you might want to take a look/report this problem in phab:T321006. Sannita (WMF) (talk) 14:31, 18 October 2022 (UTC)

Poll about de-instagramification

It would be good to do a poll among Commons media creators to determine if this should be fixed or not, rather than add complicated css hacks to make it look unbroken in some context. Afterall, it's Commons media creators' contributions that get instragramified and incorrectly rendered. Enhancing999 (talk) 11:54, 15 October 2022 (UTC)

Can you define 'this'? Do you mean the cropping on 3 sides of the "mini previews", I would not call these true "thumbs" anymore. Will the poll be for Commons only, or for giving these mini previews on all projects? Or do you mean speed of loading of large pages with search results. I could imagine the mini previews being specifically prepared (f.e. manualy cropped to the most meaningful part) plus a way to set these as preferred square 'thumb-icon' in wikidata. Peli (talk) 13:14, 15 October 2022 (UTC)

@Enhancing999: This has already been fixed server-side. Everything is back to normal, nothing to poll about. If you still see thumbnails cropped to squares at Special:Search, clear your browser cache. El Grafo (talk) 08:44, 16 October 2022 (UTC)

Nothing has been fixed. This is just a css hack here on Commons, Commons media are still mis-rendered on many Wikipedias. Instagram format all over. Enhancing999 (talk) 09:52, 16 October 2022 (UTC)

How other projects display images is not for us to decide. If they want to crop them, of course they can crop them. There's even a heavily used template for that at en:Template:CSS image crop. A poll on Commons won't do anything. If you don't like the change I'd suggest to join the resistance on en:. El Grafo (talk) 10:31, 16 October 2022 (UTC)

The questions is what the default should be. This is a content decision that needs to be done by media creators or uploaders. Commons provides these media and fairly detailed rules about the way a given image can be cropped. Enhancing999 (talk) 10:39, 16 October 2022 (UTC)

I need help

Hello!

Every day, it happens to me for a moment that I no longer have access to any wikimedia project while I navigate easily on other sites. But it happens to me especially after a visit to commons. I would like someone to check for me if it comes from the administration of the IP addresses. Kitanago (talk) 11:16, 19 October 2022 (UTC)

i notice that recently (for about 1-2 months?) when i work on firefox on windows 10 as usual, while logged in at one project and going to another, very often i remain logged out and have to log in there again.--RZuo (talk) 12:38, 21 October 2022 (UTC)

National flag for each country in each year

is there a module or template that can return the correct image file, given the country and the year? it's needed to improve Template:Videos from country by year/layout.--RZuo (talk) 12:38, 21 October 2022 (UTC)

Android app

Apparently there is a Commons Android app out there spitting out these nonsensical DR rationales:

• It is Nonsense
• It is Blurry
• It is A selfie

The resulting DRs consist entirely of one of the phrases listed above, and have been driving contributors crazy for as long as I can remember. There is a discussion at Commons talk:Deletion requests#Commons Android App problems. Brianjd (talk) 13:20, 22 October 2022 (UTC)

Tech News: 2022-43

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• There have been some minor visual fixes in Special:Search, regarding audio player alignment and image placeholder height. Further details are in T319230.
• On Wikipedias, a new preference has been added to hide article thumbnails in Special:Search. Full details are in T320337.

Problems

• Last week, three wikis (French Wikipedia, Japanese Wikipedia, Russian Wikipedia) had read-only access for 25 minutes. This was caused by a hardware problem. [13]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 October. It will be on non-Wikipedia wikis and some Wikipedias from 26 October. It will be on all wikis from 27 October (calendar).
• Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 25 October at 07:00 UTC (targeted wikis) and on 27 October at 7:00 UTC (targeted wikis).
• Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Assamese Wikipedia, Bashkir Wikipedia, Balinese Wikipedia, Bavarian Wikipedia, Samogitian Wikipedia, Bikol Central Wikipedia, Belarusian Wikipedia, Belarusian (Taraškievica) Wikipedia, Bulgarian Wikipedia, Bhojpuri Wikipedia, Bislama Wikipedia, Banjar Wikipedia, Bambara Wikipedia, Bishnupriya Wikipedia, Breton Wikipedia, Bosnian Wikipedia, Buginese Wikipedia, Buryat Wikipedia, Indonesian Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [14]
• Starting on Wednesday October 26, 2022, the list of mentors will be upgraded at wikis where Growth mentorship is available. The mentorship system will continue to work as it does now. The signup process will be replaced, and a new management option will be provided. Also, this change simplifies the creation of mentorship systems at Wikipedias. [15][16][17]
• Pages with titles that start with a lower-case letter according to Unicode 11 will be renamed or deleted. There is a list of affected pages at m:Unicode 11 case map migration. More information can be found at T292552.
• The Vector 2022 skin will become the default across the smallest Wikipedias. Learn more.

Future changes

• The Reply tool and New Topic tool will soon get a special characters menu. [18]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:20, 24 October 2022 (UTC)

Tech News: 2022-44

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• When using keyboard navigation on a Kartographer map, the focus will become more visible. [19]
• In Special:RecentChanges, you can now hide the log entries for new user creations with the filter for "⧼rcfilters-filter-newuserlogactions-label⧽". [20]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 November. It will be on non-Wikipedia wikis and some Wikipedias from 2 November. It will be on all wikis from 3 November (calendar).
• The maps dialog in VisualEditor now has some help texts. [21]
• It is now possible to select the language of a Kartographer map in VisualEditor via a dropdown menu. [22]
• It is now possible to add a caption to a Kartographer map in VisualEditor. [23]
• It is now possible to hide the frame of a Kartographer map in VisualEditor. [24]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:13, 31 October 2022 (UTC)

Previously used, but currently unused, files

Sometimes a file is nominated for deletion as out of scope, but kept because it is in use (and therefore in scope). Later, the file is no longer in use and is nominated for deletion again.

When responding to such deletion requests (especially when one is soon after the other), it would help if we knew the circumstances in which the file was removed. See Commons:Deletion requests/File:Salam 501 — jilat jari.jpg.

Is there a way to determine what those circumstances were (without knowing in advance where the file was used)? Brianjd (talk) 03:53, 24 October 2022 (UTC)

To clarify, ‘removed’ means ‘removed from the page(s) where it was used, causing it to no longer be in use’. Brianjd (talk) 03:55, 24 October 2022 (UTC)

it's difficult to track down where files were used.

on the other hand, i dont agree with the "in use/not in use" reasoning for deletion. if something is educationally useful, it doesnt become useless because it's not in use. if it's some junk and out of scope, it doesnt become "in scope" because it's merely in use (on whatever pages, very often in user namespace).

i never use this argument and i never take other users' arguments of this kind seriously. RZuo (talk) 07:02, 24 October 2022 (UTC)

@RZuo It does become ‘in scope’ merely because it’s in use (on another project, outside of talk and user spaces). That’s Commons policy. In fact, the policy (linked in my message above) says:

It should be stressed that Commons does not overrule other projects about what is in scope.

That is the way it should be.

Regarding the opposite situation, where a file is not in use, I agree that this is not a valid argument for deletion. Brianjd (talk) 12:32, 24 October 2022 (UTC)

whether something is "educationally useful" (the definition of scope here), doesnt change merely because anyone puts or removes it on any page. i have seen lots of incidences of self-promotion, advertising, hoax and whatnot. RZuo (talk) 12:39, 24 October 2022 (UTC)

i'm speaking based on common sense, rather than "bureaucratic commons procedures". if to follow the procedures brainlessly, yes, a junk image put on a spam page on an unattended small wiki by a vandal is also in scope on commons. RZuo (talk) 12:42, 24 October 2022 (UTC)

@RZuo My previous comment is qualified by this line of the same policy: In the sections below, any use that is not made in good faith does not count. I think that covers the exceptions you mentioned.

Where a file is legitimately in use, we should not delete it. That would be overruling the other project; it would be the equivalent of, for example, an enwiki editor removing material from eswiki because they don’t think it meets enwiki standards. That’s not OK, nor is it OK for Commons to overrule other projects. Brianjd (talk) 13:05, 24 October 2022 (UTC)

most people who use this argument never check whether it's legitimately in use. i just encountered one yesterday: Commons:Deletion requests/File:BLT Baselland Transport AG.svg. it's just a sloppy and lazy argument which is often cited by people who dont care about the truth. RZuo (talk) 13:41, 24 October 2022 (UTC)

@RZuo I don’t see any evidence that this use is not legitimate. (It seems to be widely accepted that a dispute over the accuracy of a file does not prevent any use from being considered legitimate.) Brianjd (talk) 14:01, 24 October 2022 (UTC)

so you think that incorrect image is "educationally useful", when the correct version already exists on commons? but if someone edits the last page that image is being used on, that "educationally usefulness" will immediately disappear? 👎--RZuo (talk) 14:05, 24 October 2022 (UTC)

@RZuo By the definition set out in Commons policy, yes. Should we take this discussion to Commons talk:Project scope? (But before doing so, we should review Commons talk:Project scope/Archive 2#"A media file that is in use on one of the other projects of the Wikimedia Foundation is considered automatically to be useful for an educational purpose,".) Brianjd (talk) 14:18, 24 October 2022 (UTC)

this argument is flawed. and if people like Brianjd can stop proliferating this nonsensical argument it becomes unnecessary to worry about where a file has been used but removed.--RZuo (talk) 09:59, 1 November 2022 (UTC)

@RZuo Which argument? (Which comment are you replying to?) Brianjd (talk) 11:09, 1 November 2022 (UTC)

@Brianjd: I don't know of any way to find this out. This is why when I mention in a deletion discussion that a file is in use, I also cite some of the pages where it's in use. Maybe someone somewhere keeps historic MediaWiki database dumps? --bjh21 (talk) 15:58, 24 October 2022 (UTC)

@Bjh21 Having learnt this lesson the hard way, I try to preserve relevant information (including links to pages where a file is used) in deletion requests.

I know that the Wikimedia Foundation makes database dumps (including non-deleted history) available for download, but these databases really are massive – so massive that Wikimedia asks users not to download them unless they really need them. I suspect that few organisations have the motivation or ability to archive them, and I do not know of any organisations that actually do so. And even if they did, I suspect that getting answers from them won’t be easy (if it were easy, then it should also be easy on Wikimedia’s own sites). Brianjd (talk) 16:05, 24 October 2022 (UTC)

On https://dumps.wikimedia.org/commonswiki/20221101/, I see a file named commonswiki-20221101-globalimagelinks.sql.gz (8.8 GB). I didn’t try to download it, but it looks like what we need. As long as dumps are available (currently going back to July), historical data can be extracted from it. If you wanted older data, an option would be maintaining a database of all-time historical data by adding new entries, say, once a day, but never deleting old ones. This would take up quite some place (I don’t know if WMF would be happy storing this e.g. on Toolforge), but probably much less than the combination of all dumps, as most files stay on pages once inserted, which means only one row, however much time we have data about. —Tacsipacsi (talk) 20:50, 13 November 2022 (UTC)