Commons:Village pump/Technical

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcuts: COM:VP/T • COM:VPT

Welcome to the Village pump technical section
Technical discussion
Village pump/Technical Octicons-location.svg
 Bug reports
 Code review
Tools
 Tools/Directory
 Idea Lab


This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Technical/Archive/2023/03.

Please note
 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Hidden chars in title[edit]

https://commons.wikimedia.org/w/index.php?title=Category:Gulfstream_aircraft_by_orientation&action=history

there're some hidden chars in the original title. i thought they were all located before the G, but there were more in the middle. (because i tried to move it to a new name, which i copied from the 2nd char to the 2nd last char, and added G and n myself, but system still warned me new title had hidden chars.)

something should be in place to warn sysops not to create such things. (they can overwrite rules so this was created by User:Minorax.)

i found this as i was looking at https://commons.wikimedia.org/w/index.php?title=Special:AllPages&from=%E2%80%98tit+R%C9%99x&namespace=14 . it appeared between Category:⁋ and Category:€. RZuo (talk) 10:34, 29 January 2023 (UTC)Reply[reply]

and the original cat is added by {{Aircraft by facing}} as found in https://commons.wikimedia.org/w/index.php?curid=64140905 . i cant trace the root cause. RZuo (talk) 10:38, 29 January 2023 (UTC)Reply[reply]
I think the root cause is something in the Wikidata for d:Q1554299. There are lots of screwiness which is why the parent at Category:General Dynamics aircraft facing left breaks to Category:⁨󠀁󠁥󠁮GD󠁿⁩ aircraft by orientation (which I think had hidden characters) instead of going up into Category:General Dynamics aircraft. Ricky81682 (talk) 22:19, 4 February 2023 (UTC)Reply[reply]
This problem needs to be fixed by someone who knows how to fix it. I have encountered the same difficulty with Category:Fairchild aircraft facing right. Bahnfrend (talk) 12:34, 2 March 2023 (UTC)Reply[reply]

still collecting, takes a while, it's a rat's nest... Achim55 (talk) 15:57, 11 March 2023 (UTC)Reply[reply]

There are two problems: 1. The bad cat name above contained 4-byte chars from the tag range which are obviously not supported or entered erroneously. I created a similar one as Category:⁨󠀁󠁥󠁮Gulfstream󠁿⁩ aircraft by orientation (test for scanning). 2. d:Q1554299 contains not one but two assigned categories which keep the cat names of other projects mixing up 'Gulfstream Aerospace' as company and 'Gulfstream aircraft', it's a mess I better shouldn't have seen... --Achim55 (talk) 17:19, 11 March 2023 (UTC)Reply[reply]
Step 1: User:Achim55/Bad chars in page titles. --Achim55 (talk) 23:21, 11 March 2023 (UTC)Reply[reply]

✓ Done for now using parameter |mfrcat= as workaround. I didn't find out the source of the extra characters, the cascaded templates seem okay, the data on wikidata as well. Mysterious. --Achim55 (talk) 19:21, 12 March 2023 (UTC)Reply[reply]

the hidden chars in these titles were between the last letter of the first word and the first whitespace.
i guess the problem is in the querying of wikidata. somewhere these chars were added. if so, then i feel that this problem will emerge again and more often as wikidata will be queried more and more in future.
but i'm too lazy to bother posting this to wikidata to get more attention.--RZuo (talk) 11:05, 21 March 2023 (UTC)Reply[reply]

Crop tool[edit]

Please see Commons_talk:CropTool#White_or_transparent_instead_of_black_(added_space_in_borders) Enhancing999 (talk) 17:54, 16 February 2023 (UTC)Reply[reply]

Crop tool is unmaintained, and has more serious issues such as performing lossy cropping even when it says it is in lossless mode. Ahecht (TALK
PAGE
) 22:23, 14 March 2023 (UTC)Reply[reply]

API call to find existent Talk: pages of my uploads[edit]

Let's say I have uploaded 355 files, and on five of them users have left discussions. What's the API call that will find just those five Talk pages? Sure, I know the API call to find the 355 file names, and then all I need to do is s/File/File_talk/, but that would also get the 350 non-existent talk pages. Thanks. Jidanni (talk) 07:23, 22 February 2023 (UTC)Reply[reply]

You need to find the pages and then iterate on them to check existence. Cannot be done in a single API call. – Ammarpad (talk) 10:31, 3 March 2023 (UTC)Reply[reply]

Pattern for naming drawings[edit]

Hi,
More drawings for the old marine engines are ready for upload. Refer to Category:Easthope_Engines.

Before uploading, a question about file names.

The existing pattern is
"Easthope" digit "HP" name drawingNumber "." extension.
For example, Easthope4HPGearCaseCover4023.jpg.

An alternative naming pattern is
"Easthope" digit "HP" drawingNumber name "." extension.
The example becomes
                     Easthope4HP4023GearCaseCover.jpg.

Question
Does anyone recognize an advantage of one naming pattern over the other? The obvious practical effect is on sort order.

Thanks, ... PeterEasthope (talk) 18:23, 24 February 2023 (UTC)Reply[reply]

Sorting could be done with sortkeys in categories if there is a need.
Following the general idea of descriptive filenames, personally, I'd have chosen:
File:Easthope 2 H.P. Engines - Gear Case Cover Plate, drawing number 4023, 1939.jpg (assuming the model is "2 H.P. Engines" and what is shown is "Gear Case Cover Plate". Year is 1939, drawing number is 4023. If had a better idea of the drawing, maybe I'd add that too.
This instead of File:Easthope4HPGearCaseCover4023.jpg. Obviously, there are many files that following schemes like the ones you plan. Enhancing999 (talk) 20:44, 24 February 2023 (UTC)Reply[reply]
Thanks for noting sortkeys. Yes the model referred to is "2 H.P. Engine".
The name you suggest has the information content of the proposal with addition of drawing number and year. Conventional abbreviations for drawing number are "Dwg", "Dwg No", "Dwg. No.", "Dwg #", and etc.
File names in MacOS and MS Windows commonly contain spaces. Nevertheless spaces can introduce difficulties for automated processing and security vulnerabilities.
https://tldp.org/HOWTO/Secure-Programs-HOWTO/file-names.html
Third bullet point, "Filenames with spaces".
camelCase is a less familiar but functional alternative.
https://en.wikipedia.org/wiki/Camel_case
Dates appear in the title block of the drawing. The year is listed with other information in Commons. How necessary is the year in the file name?
Is a compromise acceptable?
File:Easthope4HP.GearCaseCoverPlateDwg4023.jpg
or
File:Easthope4HP.GearCaseCoverPlateDwg4023.1939.jpg
PeterEasthope (talk) 19:16, 25 February 2023 (UTC)Reply[reply]
Like spaces, periods in filenames (except to indicate the file extension) can also lead to problems. In any case, so long as the file is sufficiently captioned/described, the file name pattern is not too important from a searchability point of view. --HyperGaruda (talk) 07:12, 26 February 2023 (UTC)Reply[reply]
Please give an example or cite an explanation about a period in a file name causing a problem. Thx, ... PeterEasthope (talk) 14:07, 1 March 2023 (UTC)Reply[reply]
https://records-express.blogs.archives.gov/2017/08/22/best-practices-for-file-naming/ --HyperGaruda (talk) 08:50, 11 March 2023 (UTC)Reply[reply]

File pages without files[edit]

Doing some cleanup I stumbled in the past several times upon file pages without files that in some cases have been caused by some unknown technical error during upload (example1, example2). If one tries to fix that by adding the missing file the given link leads to the standard upload procedure. That's bad, as one has to fill the forms again and gets the note that there is already such a file (-page). Two possible solutions:

  • During upload the file page is stored only if there is an accompanying file (filesize > 0)
  • The given upload link on a file page having (filesize = 0) is extended by adding the parameter &wpForReUpload=1 which is used for overwriting existing files (that works, I checked it adding it by hand) so that one can conveniently add the missing file.

--Achim55 (talk) 17:49, 26 February 2023 (UTC)Reply[reply]

Issue 1 is intentional. Without the current behavior, redirects like File:Untitled.gif cannot be created.
Issue 2. There were no uploads in your examples in the first (hence no reupload link). See issue 1, for why there were no uploads. These 'File' description pages were directly created, not through upload process. – Ammarpad (talk) 18:52, 26 February 2023 (UTC)Reply[reply]
They were created during upload tries by (probably misconfigured) bots. Anyway, the reupload variant of the link would be helpful. --Achim55 (talk) 18:58, 26 February 2023 (UTC)Reply[reply]
I believe the problem is there's no way to reliably differentiate fileless description pages created intentionally and ones created through botched upload. You can request to change the reupload link at phabricator. – Ammarpad (talk) 15:19, 1 March 2023 (UTC)Reply[reply]

Tech News: 2023-09[edit]

MediaWiki message delivery 23:45, 27 February 2023 (UTC)Reply[reply]

Bot?[edit]

Is there no bot that tags files in Category:Media uploaded without a license with {{No license since}}? If not, why isn't there? Jonteemil (talk) 22:18, 2 March 2023 (UTC)Reply[reply]

Unwanted email notifications[edit]

For example, I receive emails from SchlurcherBot even though I have turned it off in my "Global preferences > User profile > Prohibit these users from emailing me:". How can I prevent this flood of emails? F. Riedelio • 💬 07:33, 4 March 2023 (UTC)Reply[reply]

"Collapse captions" not working properly[edit]

For me, the effect of "Collapse captions" is indistinguishable from "Hide captions". Unless, of course, a means to uncollapse on a given page is hiding somewhere I don't know to look: nothing here shows what it should look like if it is working correctly. FWIW, using Monobook skin on Firefox. (Please ping me if responding, I don't watch this page.) - Jmabel ! talk 16:15, 6 March 2023 (UTC)Reply[reply]

@ 2A02:3035:C1F:5FBB:1:0:F99A:E778 18:41, 6 March 2023 (UTC)Reply[reply]

Is that somehow supposed to be a response to my question? If so I don't see how it applies. - Jmabel ! talk 04:22, 15 March 2023 (UTC)Reply[reply]

Numerals in text relating to references appear on phone but not on laptop.[edit]

Dear Jmabel,

Numerals which appear in users text to drect readers to references appear in my phone but not my laptop.

Last revisions to my sandbox were made today the 6th of March and are current.

Please could you help me with this problem.

Thank you,

Flavia Epicurus65 (talk) 19:17, 6 March 2023 (UTC)Reply[reply]

Tech News: 2023-10[edit]

MediaWiki message delivery 23:47, 6 March 2023 (UTC)Reply[reply]

Checking url before uploading[edit]

Hi. One of the problems in Commons is the existence of duplicate files and successive uploads of the same file. Before uploading a file from Tasnim news agency, some users at first cut that file and then upload it. (For example this file that duplicate of this file) With this method, many duplicate files are uploaded from the same source. When reviewing these files, how should I know this is duplicate file or not? It would be great if there was a simple tool that could just check if that image is in Commons or not (By putting url in an address box). --MehdiTalk 09:29, 11 March 2023 (UTC)Reply[reply]

Global RfC filled to enable global abuse filters on large Wikimedia projects by default[edit]

Hello!

On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the stewards. Global abuse filters are a powerful tool designed to fight against long-term abusers that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, regular blocks are significantly limited due to the IP hopping).

As of today, all small/medium Wikimedia projects (as-determined by number of articles) are automatically subscribed to global abuse filters. They are not, however, enabled on several Wikimedia projects classified as large (except several large Wikimedia projects who opted-in, such as Wikidata). This makes it possible for global long-term abusers to vandalize a project with no global filters enabled, which makes it significantly more difficult for the Stewards to fight against the abuse.

By this message, I'd like to let you know I submitted a global RfC (request for comments), where I propose enabling global abuse filters on large Wikimedia projects as an opt-out feature. This change will make global abuse filters an even more effective tool for combating long-term abuse at the global level. Please feel free to participate in the discussion, which happens at Meta-Wiki.

Thank you for your time.

Sincerely,
--Martin Urbanec (talk) 17:15, 12 March 2023 (UTC)Reply[reply]

Tech News: 2023-11[edit]

MediaWiki message delivery 23:17, 13 March 2023 (UTC)Reply[reply]

Backup of all non-deleted commons files?[edit]

https://phabricator.wikimedia.org/T331820 makes me, a regular uploader, wonder:

  1. how is wikimedia commons backed up?
  2. how many backups are there?
  3. what's the likelihood of irreversibly losing parts or all of commons data?

RZuo (talk) 09:47, 15 March 2023 (UTC)Reply[reply]

@RZuo
  1. See wikitech:Media storage/Backups (might want to read wikitech:Media storage first).
  2. There are a bunch of dedicated media backup servers, and as far as I understand they are replicated on each of the 6 data centers
  3. I'd say the chances for a catastrophic failure are close to 0 (but approaching 1 in the very long term) But there are a few rare cases where early versions of files went missing: phab:T124101
El Grafo (talk) 10:53, 15 March 2023 (UTC)Reply[reply]
so according to Media storage/Backups, there're 3 backup copies? ms-backup1001, ms-backup1002, and one of the backup100x? and all of these are in the same cluster eqiad? :/
i also dont see what mechanisms are in place to prevent fat fingers, electromagnetic pulse, malicious sabotage, or hacking... RZuo (talk) 12:32, 15 March 2023 (UTC)Reply[reply]
According to phab:T160229#7587771, "Commonswiki is now backed up on 2 geographically redundant locations". The second set (200x) seems to be running on codwf in the Texas data center (compare phab:T248934). El Grafo (talk) 14:35, 15 March 2023 (UTC)Reply[reply]
thx for the info!
i hope they dont get wiped out in one go. after i upload to commons i delete most originals and dont retain copies. if commons is lost (touchwood), 😭😭😭.--RZuo (talk) 11:05, 21 March 2023 (UTC)Reply[reply]

Inconsistencies in template {{Undeleted}}[edit]

There are two inconsistencies in {{Undeleted}} which should be fixed:

  • The first one was already noted by Brianjd on the talk page in 2021: The documentation defines the second parameter as name of the page of the undeletion request, if it's not "Commons:Undeletion requests/" + the pagename - however (unlike for deletion requests), there aren't any subpages for undeletion requests. If the parameter isn't filled out, the template actually generates a section link to Commons:Undeletion requests#pagename which is also not a good idea, as it will stop working as soon as the request (after a day) is archived. What it should do is link to the monthly archive like Commons:Undeletion_requests/Archive/2023-03#pagename.
  • For the first parameter, the template documentation defines "date of the request in ISO 8601 format". What the template actually generates is a text "This file was undeleted on <date>", so it assumes not the date of the request but the date of undeletion which aren't necessarily the same (undeletion requests often take a few days). So either the documentation should be changed to "date of undeletion" or the generated text to something like "This file was undeleted after a request filed on <date>".

As I'm not particularly experienced in template editing, I think I could do the second one myself (a simple text change), but the first point needs more technical knowledge. So, anyone feeling like fixing that? :-) Gestumblindi (talk) 15:44, 19 March 2023 (UTC)Reply[reply]

A ping also to Srittau as the creator of that template, though they were last active in January... Gestumblindi (talk) 15:46, 19 March 2023 (UTC)Reply[reply]
instead of internal links to the archive, how about just add a permalink to the revision of the closed request? i have given up on being ocd about internal links. better save minutes of my life than some bytes in diskspace.--RZuo (talk) 11:05, 21 March 2023 (UTC)Reply[reply]
A permalink to the revision of the closed request would also be fine, I agree. Gestumblindi (talk) 19:44, 21 March 2023 (UTC)Reply[reply]

Query number of unique users contributing in a photo campaign[edit]

Hello! The Albanian speaking community recently had this photo campaign. We can easily see how many images were uploaded in that link. Is there a way to see how many unique contributors uploaded them? In other words, is there a way to check the participation in the campaign? - Klein Muçi (talk) 16:07, 20 March 2023 (UTC)Reply[reply]

Tech News: 2023-12[edit]

MediaWiki message delivery 01:23, 21 March 2023 (UTC)Reply[reply]

Documentation for mw.libs.commons.ui.addEditLink?[edit]

where can i find doc about that in https://commons.wikimedia.org/w/index.php?title=User:Acagastya/LR.js&diff=464509712&oldid=464508576 ? i cant find it in https://doc.wikimedia.org/ .--RZuo (talk) 11:05, 21 March 2023 (UTC)Reply[reply]

i think addEditLink was defined here MediaWiki:Gadget-editDropdown.js.
doc about mw.libs is https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw-property-libs .--RZuo (talk) 13:21, 26 March 2023 (UTC)Reply[reply]

Protected Template:NASA-image ids no longer lead to correct image at NASA Image and Video Library[edit]

Template:NASA-image no id longer leads to the correct image at the NASA Image and Video Library (https://images.nasa.gov/). By clicking the link on the template, the user is directed to what is essentially the library's home page. The issue is documented in the Template talk:NASA-image by @Роман Рябенко. The issue may be addressed by someone with the authorization to edit the file by either changing the template to link to (https://images.nasa.gov/search?q=[ID]&page=1&media=image,video,audio&yearStart=1920&yearEnd=2030.) or having the template directly link to the image (https://images.nasa.gov/details/[ID]). An example file where you can see this is HaiseandFullertonEnterprise.jpg (1st updated example long string) (2nd updated example directly to image). Note that the 1st example is probably better as NASA's url here are case sensitive, as s71-30025 will lead to the correct image, while S71-30025 will return a 404 error, which may cause issues for Wikimedia users. Thanks - Caddyshack01 (talk) 16:03, 22 March 2023 (UTC)Reply[reply]

It is possible to convert the ID from upper-case to lower-case with the magic word {{lc:string}}. For example, the code https://images.nasa.gov/details/{{lc:S77-30025}} with upper-case ID returns a valid URL https://images.nasa.gov/details/s77-30025 with lower-case ID. So, this should not be a criterion for choosing where to link. I still wonder, whether it is better to link to the search results page or directly to the details page of the specific image. The latter seems the most sensible since it is where the reader supposedly wants to reach. Роман Рябенко (talk) 19:19, 22 March 2023 (UTC)Reply[reply]
Unfortunately it isn't guaranteed that the NASA ID (or whatever identifier string any particular image uses) will be entirely lowercase), so forcing one way or the other isn't good. I will work on this problem this evening, as I'm at work right now. Huntster (t @ c) 20:18, 22 March 2023 (UTC)Reply[reply]
@Caddyshack01 and @Роман Рябенко: I've updated the URLs so searching should work properly. Please leave a note on my talk page if you find any issues. Huntster (t @ c) 03:06, 23 March 2023 (UTC)Reply[reply]
Hey, it works great. Thanks @Huntster. One note, at the end of the string there is a date search aspect "&yearStart=1920&yearEnd=2023". I would propose making the "yearEnd" a future year like 2030, so that it continues to work with images posted in 2024 and beyond without changes. A quick test editing the url to have the "yearEnd=2030" shows that it works for image in the main post (https://images.nasa.gov/search?q=S77-30025&page=1&media=image,video,audio&yearStart=1920&yearEnd=2030) - Caddyshack01 (talk) 16:01, 23 March 2023 (UTC)Reply[reply]
@Caddyshack01: Already ahead of you. In the code, I use the {{CURRENTYEAR}} magic word so it'll always remain up to date. Huntster (t @ c) 16:10, 23 March 2023 (UTC)Reply[reply]

File page showing the wrong file[edit]

Hi. On a couple of occasions yesterday and today, I'm encountering an issue where the wrong file is displayed after uploading a new version.

I've tried purging, null edits and another browser, all without success. What's happening here? Cryptic-waveform (talk) 12:43, 24 March 2023 (UTC)Reply[reply]

@Cryptic-waveform Looks OK to me, is it working for you now? —‍Mdaniels5757 (talk • contribs) 17:33, 25 March 2023 (UTC)Reply[reply]
Thanks for looking into this. Some things still don't look right to me:

New cluster of technical pages[edit]

as a followup to Commons:Village_pump/Archive/2023/01#Commons_Developer_Group?, i created these pages:

  1. Commons:Village pump/Technical/Bug reports
    centralised page for bugs. major bugs/problems reported on VPT or elsewhere that arent resolved before being archived can be recorded there. a centralised page lets capable users look for tasks they can fulfil.
  2. Commons:Village pump/Technical/Code review
    centralised page to ask for code review. especially useful for edits to templates, modules, gadgets, etc., that are widely used.
  3. Commons:Tools/Directory
    list of basic info of tools. makes it easy to find a tools' source codes, programming languages, bug trackers, maintainers, etc.
  4. Commons:Idea Lab
    centralised page for new ideas for new tools or existing tools. lets capable users look for ideas they can realise.

please feel free to share your feedback about these pages.

please add them to your watchlists. hopefully we can build a community that can maintain commons better than before.--RZuo (talk) 13:21, 26 March 2023 (UTC)Reply[reply]

SVG preview image not updating[edit]

Hello all. At File:Canaveral.svg, the preview SVG (at least for me, it is this image) refuses to update after a new version of the SVG was uploaded. Nothing I've tried has fixed it, including purging and reuploading. Are there any suggestions? It's not a huge issue, but it may cause some misunderstandings if it shows old information. Thanks! Huntster (t @ c) 19:48, 26 March 2023 (UTC)Reply[reply]

This looks similar to what I've recently reported above: Commons:Village pump/Technical#File page showing the wrong file. Unfortunately I don't have a solution for you. The problem remains after several days. Cryptic-waveform (talk) 15:11, 27 March 2023 (UTC)Reply[reply]

Tech News: 2023-13[edit]

MediaWiki message delivery 01:11, 28 March 2023 (UTC)Reply[reply]