Commons:Village pump/Technical

Shortcuts: COM:VP/T • COM:VPT

Welcome to the Village pump technical section

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/2022/12.

COMMONS DISCUSSION PAGES (index)
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.

File pages ask for confirmation when closing them, even when there are no unsaved changes (bug)Edit

Sometimes pages ask for permission to close it or refresh it, even when the user did not edit anything. see example and try to navigate to another page or click the "File" tab to reload the page. example If someone understands what is happening here and knows a fix, please let me know. I would want to fix it on the pages whenever I see this behavior. But if it is a template error, the template should be checked and repaired. Tx Peli (talk) 04:11, 8 December 2022 (UTC)

@Pelikana Keeps happening to me too (Firefox), I'm wondering if that might be connected to COM:SDC somehow ... El Grafo (talk) 08:37, 8 December 2022 (UTC)
I have been getting that a lot in recent months. At first I though it was a matter that the page takes a little longer to fully load than usual, but even if it’s that, it’s still bad. (Fireforx on Win10 here). -- Tuválkin 22:21, 21 December 2022 (UTC)
The section was poorly worded; I have changed the heading. It is not really about ‘permission’, but rather about confirmation that the user wants to abandon their unsaved changes. This behaviour is a bug, because there are no such changes to abandon. It occurs when closing the existing page, which includes refreshing it or navigating away.
I have also observed this bug many times (on Firefox); it seems to occur during a specific stage of loading the page (it doesn’t occur very early in loading and doesn’t occur after the page has finished loading). I just noticed that if I choose to stay on the page, then the page continues displaying this buggy behaviour until I choose to close it. This might help someone (with access to non-minified code?) with debugging. Brianjd (talk) 09:14, 25 December 2022 (UTC)
Everyone can access the non-minified code – first, all source code is available on Git with several frontends (Phabricator, Gerrit/Gitiles, GitHub); second, you can avoid minifying the JavaScript codes by appending ?debug=1 to the URL (or &debug=1 if it already contains a question mark). —Tacsipacsi (talk) 15:13, 25 December 2022 (UTC)
@Tacsipacsi Of course, I just didn’t know how to get it in a production environment. The debug=1 parameter works; it also seems to make it so only one thing loads at a time, which is also useful here.
When I used this parameter, initially, the ‘file information’ and ‘structured data’ screens displayed together, then ‘structured data’ disappeared behind a non-selectable tab (clicking it did nothing). When the tab became selectable, immediately refreshing the page triggered the bug. Stepping through the code in the debugger revealed that property P1259 seemed to have a problem and, sure enough, property P1259 (along with property P1949 – these are both coordinates properties) had its edit screen open. Brianjd (talk) 15:21, 26 December 2022 (UTC)
@Brianjd: Thanks for debugging! I found phab:T312315 about this issue, so I left a comment there about your results. —Tacsipacsi (talk) 10:40, 29 December 2022 (UTC)
@Tacsipacsi I just happened to open the structured data on another file (Naked in the streets.jpg, though I don’t think it matters) before it finished loading, and saw the ‘depicts’ section switch to edit mode, then back to normal, all by itself. I suspect it happens with all properties, but haven’t been able to verify this. Brianjd (talk) 06:32, 13 January 2023 (UTC)
  • I don't know if it's relevant but I've been experiencing this with Chrome too for some time now, Always thought it was related to me for some reason, Good to know it's not, –Davey2010Talk 02:01, 14 January 2023 (UTC)
I have got this a lot for quite a while, too. It's really annoying. I mostly use Firefox, but I believe it has happened in Chrome as well. Blue Elf (talk) 10:35, 18 January 2023 (UTC)
  • I've been experiencing this problem since the introduction of "File captions" (Structured Data on Commons version), probably since late 2020 or something. I use the Ecosia browser which runs on Chromium. I do experience this a lot more on "Mobile mode" more and I almost exclusively get it on file pages. It didn't bother me enough to file a report. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:59, 18 January 2023 (UTC)

Template:Year at airport automatically categorizes into "Category:YYYY at airports by location" (YYYY=year). It should use "Category:YYYY at airports by country" if existing. If this category does not exist, use "Category:YYYY at airports by location" instead (as it is now). I am not too much into template programming, so can anyone please do this for me? --2001:4652:FBAF:0:B4CB:3ECC:59F6:6FA1 20:10, 12 December 2022 (UTC)

Nobody? --2003:D0:3F0C:6892:40AC:94CA:8694:13DC 16:19, 22 December 2022 (UTC)
Where to get support in regards to templates? --88.128.92.26 12:21, 4 January 2023 (UTC)
This would be the correct place. You just need be lucky that a volunteer feels like digging into the code. I have implemented your request, but I am not going to sort out what relevant categories are now double-categorised through both the template and [[:Category:YYYY at airports in InsertCountry]]. It has no further effect on the result, but just looks a bit messy/redundant in the wikicode of the affected categories. --HyperGaruda (talk) 13:06, 4 January 2023 (UTC)
Thank you so much. --2001:4652:FBAF:0:892D:A144:2B0C:BEE4 18:44, 6 January 2023 (UTC)

MediaviewsEdit

How exactly the Mediaviews tool counts views of a given image at Commons, e.g. here? When an image is clicked through the relevant WP article, when the image is clicked at Commons or somehow else? Brandmeister (talk) 15:31, 21 December 2022 (UTC)

This count every visit of page where the file is on the page. The file does not need to be visible for the visitor, if the file in on the bottom of the page and the visitor does not scroll down this is also counted as a mediaview. --GPSLeo (talk) 19:00, 21 December 2022 (UTC)
Wow. That explains some high viewcounts of uploaded images. Brandmeister (talk) 12:59, 22 December 2022 (UTC)

File usageEdit

If a file is used at a Wikidata item, and that item is linked from another page, then that page is listed as using that file. Examples are given at File talk:Sunburn flickr 01.jpg#File usage, where I claimed that this is a bug. It is certainly very confusing. Is it the intended behaviour? Brianjd (talk) 06:14, 22 December 2022 (UTC)

This in intended. File usage shows every page where the file is visible. The file does not have to be in the Wikitext of the page. GPSLeo (talk) 06:29, 22 December 2022 (UTC)
@GPSLeo For the examples I cited, the images are not visible on those pages. In one case, even the Wikidata link is not visible; the only connection I can find is a Wikidata ID in the page’s markup. Brianjd (talk) 06:32, 22 December 2022 (UTC)
I can see the image in the box on all these Wikipedia pages. Only on the Wikivoyage page I could not fine this photo in my quick search. --GPSLeo (talk) 18:20, 22 December 2022 (UTC)
@GPSLeo The Wikipedia pages are fine. I specifically asked about the Wikivoyage page, then gave a second example on Wikivoyage. In both cases, the photo is not shown on the page. Brianjd (talk) 12:28, 23 December 2022 (UTC)
As a bureaucrat/administrator on Wikivoyage, I strongly agree that we do not need to be informed except when an image visible on a Wikivoyage page has been nominated for deletion or tagged for speedy deletion. We really don't care about Wikidata images that are not shown as thumbnails or pagebanners in Wikivoyage articles. -- Ikan Kekek (talk) 13:27, 23 December 2022 (UTC)
If you edit wikivoyage:Tunisia, you'll see that the "Wikidata entities used in this page" list includes "sunburn: Statement: P625, Statement: P18, Title", so something on the page is querying the image (P18) for sunburn (Q649717) even if it's not rendering it on the page. And indeed that's what wikivoyage:Module:Marker does: it queries image (P18) for every marker with a Wikidata link even though it only uses the result when the Wikidata item also has co-ordinates (which sunburn (Q649717) does not). Possibly this is a bug in MediaWiki, and uses of image (P18) by a script shouldn't cause the image to be marked as being in use unless the image is actually included in the page. But it could be worked around by modifying wikivoyage:Module:Marker to only query image (P18) where it's actually going to use the result. --bjh21 (talk) 15:39, 19 January 2023 (UTC)
Regarding the wikivoyage:GlasgowFile:Wfm barrowland ballroom.jpg link mentioned by Brianjd, that one really does appear on the page. Click the "2" next to the words "The Barrowland Ballroom" and a map will open up. Click the "2" on the map and it will sprout a label containing File:Wfm barrowland ballroom.jpg. --bjh21 (talk) 15:48, 19 January 2023 (UTC)
@Bjh21 I had no idea that the numbers were links or that such a map existed! Brianjd (talk) 07:12, 20 January 2023 (UTC)
@Ikan Kekek It’s interesting that you were apparently unaware of this too. How many Wikivoyage users actually know about this? Brianjd (talk) 07:15, 20 January 2023 (UTC)
Very few, I imagine. Ikan Kekek (talk) 07:26, 20 January 2023 (UTC)
@Ikan Kekek It might be time to redesign the interface then. Brianjd (talk) 07:29, 20 January 2023 (UTC)
Wait: No, I know this, and I think a lot of users do. The whole point of the numbers, which are geocoding numbers, is to represent specific points on dynamic maps. -- Ikan Kekek (talk) 07:30, 20 January 2023 (UTC)
No. Wikivoyage users don't need to know they can click the numbers in order to see them on the map. This does not have to be redesigned. -- Ikan Kekek (talk) 07:32, 20 January 2023 (UTC)
I think the first time I looked at that page, I went straight to the markup and searched for the Wikidata ID, then went back to the rendered page and went straight to the list where that Wikidata ID was referenced. I never actually saw the map. But even if I did, I am not sure that I would have made the connection because: (1) The map is so far away from the lists. (2) The numbers in the lists do not look like map pins.
I do know the connection between numbers and maps, having seen it elsewhere (but always on embedded Google Maps, I think). Brianjd (talk) 07:38, 20 January 2023 (UTC)
I think most users who wanted to use a dynamic map would click on the map, see the numbers, look at the article and see that they represent listings in the article. -- Ikan Kekek (talk) 08:14, 20 January 2023 (UTC)

"Lua error in Module:Wikidata_date at line 190: attempt to concatenate local 'adj' (a nil value)"Edit

Hello. Those the summaries of those two files show the same error ("Lua error in Module:Wikidata_date at line 190: attempt to concatenate local 'adj' (a nil value)") since I have updated the names of the files in the gallery:

Could someone fix this ? Veverve (talk) 22:35, 24 December 2022 (UTC)

It is complaining about property P4241 (refine date) being missing under P577 (publication date) on d:Q108736980. Snævar (talk) 23:14, 24 December 2022 (UTC)
@Snævar: I have added it to the Wikidata item, but it does not work. I have also tried removing P577 and it did not fix things either. Veverve (talk) 23:30, 24 December 2022 (UTC)
@Snævar: I do not know how, but now it appears to be fixed. Veverve (talk) 05:42, 26 December 2022 (UTC)

Can page titles start in lower case in non-latin scripts?Edit

if i understand correctly, all pages in all namespaces that start with a latin letter must start with A-Z, right? then what about other scripts, cyrillic, arabic, indian ones...? if those scripts have their equivalent "lower case" letters, can page titles (like filenames) start with those? RZuo (talk) 18:31, 27 December 2022 (UTC)

Firstly, only a minority of scripts employ dual letter case; of the ones you listed, only Cyrillic. Secondly, both en:w:WP:NCLOWERCASEFIRST (Latin script) and ru:w:ВП:ТЕХН (Cyrillic script) explain that it is technically impossible to start with lower case. They also describe that a work-around is needed to have the title look like it starts with lower case, even though the "base" title is still capitalised. --HyperGaruda (talk) 05:48, 28 December 2022 (UTC)
The question is valid, and what Russian Wikipedia says does not necessarily apply here – capitalization is based on the site language (which is English on Commons). For example, istanbul is normalized to Istanbul on Commons, but would be normalized to İstanbul if the site language was Turkish. However, “based on the site language” doesn’t mean that it uses a hardcoded table of lowercase → uppercase values, but the PHP functions ucfirst (which handles only English letters) and mb_strtoupper (which should handle accented Latin-script letters and other bicameral scripts) are used. (There could be exceptions set for this, but as far as I see, there are none right now.) By the way, it’s easy to see if certain file names would be capitalized: if you hover over file:москва.jpg, you’ll see that the URL contains an М instead of an м. —Tacsipacsi (talk) 10:32, 29 December 2022 (UTC)
My experience is that, upon page creation, the first character of a page name is always normalized to its upper case variant, if applicable: That would be based on the character’s Unicode property Case Mapping: Upper value (and therefore excluding specific tailorings, such as the mentioned hard dotted Turkic "i" and such others). Most characters do not have any case mapping but almost all letters of a few scripts do: Latin, Greek, Cyrillic, Armenian, Georgian, Glagolitic, Coptic, Cherokee, Deseret, Osage, Vithuqi, Caucasus Albanian, Hungarian Runic, Warang Citi, Medefaidrin, and Adlam. -- Tuválkin 08:46, 31 December 2022 (UTC)

Multilingual "References" templateEdit

Is there something like {{int:filedesc}} (=> Summary) but to display "References" in the user's preferred language? I currently use {{ucfirst:{{I18n/references}}}} (=> References) and I would prefer a simple syntax such as {{int:ref}} or a template such as {{Source}}. A455bcd9 (talk) 09:35, 30 December 2022 (UTC)

Structured data for user-created maps?Edit

On Commons, how should we tag the source(s) of maps created by users based on existing work? Examples:

Commons:Structured data/Modeling/Source says that {{Based}} is "still under discussion".

When a reference URL is available, I used it. Sometimes I used the DOI of the article but it returns an error. I also used "published in" (e.g., with Ethnologue: Languages of the World, 25th Edition (Q115923483), see File:Arabic_Varieties_Map.svg for an example).

But maybe based on (P144) is better? A455bcd9 (talk) 09:45, 30 December 2022 (UTC)

Found the answer to my question here: d:Help:Sources#Web_page: "Please note if the web page belongs to a major web site that already has an item in Wikidata, you should use publisher." and all the other qualifiers if possible (title, publication date, etc. "so the source can be tracked down if the URL changes"). A455bcd9 (talk) 08:09, 31 December 2022 (UTC)

Category:Unsupported eventEdit

where does Category:Unsupported event come from? what should be done to get rid of it from pages? afaict, it's added by {{Artwork}}? @Zolo: do you have more info about this cat? RZuo (talk) 09:46, 31 December 2022 (UTC)

Looking at one random example, it seems to come from the institution templates, i.e. from Module:Institution (or one of its dependencies), and it probably means that the module could not process some Wikidata data. Maybe someone can help on its talk page. —Tacsipacsi (talk) 10:50, 31 December 2022 (UTC)

Upload "wizard" not whizzingEdit

Upload "wizard" bugs out on 135 files. Files (name Hans_Dahlberg.xxx...) are probably still hanging around, so I probably CAN NOT just re-upload. I have applied for and not gotten FILE MOVER and FILE DELETER. It would help much if I could just zap away any uploads I have made, and re-upload. Manually touching each of the 135 files... is time I do not have. Can we get Upload-Extra-Whizz, that never checks all stuff, never matches categories, never checks if uploaded again...? no graphical, text only? That would help a lot. Now I need to fight with swedish wikimedia, I have tried to fulfill the uploads I promised, but the non-working system does not allow a swift and easy upload.... Janwikifoto (talk) 00:35, 1 January 2023 (UTC)

No need to worry. I just uploaded again (2 hours extra), and fewer pictures, now I never fill in category. Can we not get get a text-only multi-uploader, no choices, give all the info first (up front), then upload starts and I can check success later when I have time... That would be a convenient luxury! Janwikifoto (talk) 15:02, 1 January 2023 (UTC)
If you mean text-only seriously, you can go to the command line: mw:Manual:Pywikibot/upload.py. —Tacsipacsi (talk) 21:59, 1 January 2023 (UTC)
Can Pywikibot also upload LARGE (about 1 gb) video files..? Janwikifoto (talk) 00:52, 2 January 2023 (UTC)
I didn’t try, but since it has a chunked upload option, I suppose yes, as long as Commons accepts them. —Tacsipacsi (talk) 11:29, 2 January 2023 (UTC)

OGL files no longer display attribution valueEdit

It used to be the case that files uploaded under the UK's Open Government Licence could use the reuslting OGL template to display attribution information separate from the usual author information, with the syntax for this typically being {{[OGL version]|1=[Media type]: [Author]/[Organisation]}}; for a Defence Imagery file for example, the typical syntax would be "1=Photo: Pte. John Smith/MOD" (though I now prefer to say "Pte. John Smith/UK Ministry of Defence [Year]"). While it's still possible to use this syntax without producing an error, said syntax no longer seems to do anything and the only attribution visible is that given when specifying the author. Is this the result of a deliberate change, or is it just a case of weird things happening with the template at this time? - Dvaderv2 (talk) 03:25, 3 January 2023 (UTC)

@Dvaderv2: It looks like the attribution support was broken about a year ago when the templates were converted to support multiple languages. I think I've fixed {{OGL}}. I'll also take a look at {{OGL2}} and {{OGL3}}. —RP88 (talk) 03:52, 3 January 2023 (UTC)
OK, I think I've got the attribution parameter working for {{OGL2}} and {{OGL3}} as well. —RP88 (talk) 04:02, 3 January 2023 (UTC)
Thanks! - Dvaderv2 (talk) 13:24, 3 January 2023 (UTC)

Upload Wizard public domain license needs year updatedEdit

The Upload Wizard area for adding a license to a "public domain" file where it states, "The copyright has definitely expired in the USA" needs to be updated in two lines below this selection, from "... before 1927" to "... before 1928." Thank you, -- Ooligan (talk) 04:46, 3 January 2023 (UTC)

@Ooligan: A fix has been made (see phab:T326045) and is included in MediaWiki version 1.40.0-wmf.17, which is currently scheduled to be deployed to Commons on 4 January 2022 between 09:00–11:00 UTC (Commons server is in group1). —RP88 (talk) 05:04, 3 January 2023 (UTC)
@RP88: Thank you for the quick response. It is good to know that it will be updated late morning on the 4th. If you know, what is the technical reason why this Upload Wizard once-a-year update could not be deployed at 00:01 PST on January 1, 2023?
International Public Domain Day is every year on January 1st. In 2019, "the 'Grand Re-Opening of the Public Domain' that took place at the Internet Archive with the presence of members of Creative Commons, the Electronic Frontier Foundation and the Wikimedia Foundation..." Some 2023 public domain works highlighted here: "Works from 1927 are open to all!" Duke Law School’s Center for the Study of the Public Domain Ooligan (talk) 06:04, 3 January 2023 (UTC)
There is no technical reason why a manual fix couldn't have been made and then deployed sooner, it just worked out that January 4th is the first scheduled software deployment to Commons after December 31st. There is, however, a open task to make the Upload Wizard handle the year transition automatically (see phab:T271968), but no one has volunteered to make that code change yet. —RP88 (talk) 06:14, 3 January 2023 (UTC)
I hope a volunteer will complete this task before next year and that the year update will be on January 1st at 00:01 AM in the best legally compliant U.S. time zone. Thanks again for sharing your time and knowledge. Best Regards, -- Ooligan (talk) 10:42, 3 January 2023 (UTC)

My ifeq logic not correct?Edit

i edited Template:Autoarchive resolved section/layout and Template:Autoarchive resolved section/i18n to add two parameters "search" and "searchprefix". the expected outcome is if search=yes then a searchbox will show up (Commons:Village pump/zh already set search=yes), but the box doesnt show up. i tried doing without the ifeq in the layout template, then the box will show up. so i guess i didnt get the ifeq right? can you plz help me check what's wrong? cf. mw:Help:Extension:ParserFunctions##ifeq. RZuo (talk) 11:53, 4 January 2023 (UTC)

it seems the software thinks the search parameter is empty even though i set it to yes, because i tried changing ifeq to if, the box shows up, because the box is "value if test string is empty (or only white space)".
i already tried purging and null editing Village pump/zh. RZuo (talk) 12:04, 4 January 2023 (UTC)
i did further testing. strangely all the age/timeout/archive parameters are received correctly, but they think "search" is empty string even though i set it to "yes" on Commons:Village pump/zh.--RZuo (talk) 16:32, 17 January 2023 (UTC)

Help for html bugEdit

In Category:Pietro Bussolo there are two categoriess that if you click on them they are already deleted or moved away... but they still appear there because there still exist, apparently, the same categories with this simbol at the end (;) that cannot be deleted or moved due to html conflict. Is there a way to fix this? Thank you Sailko (talk) 20:24, 6 January 2023 (UTC)

The only way for me to land on the semicolon pages, is through adding a semicolon to the "commons.wikimedia.org/w/index.php?title=Category..." URLs (which shows up in e.g. the edit or history screen), instead of the user-friendly "commons.wikimedia.org/wiki/Category...". I have redirected the semicolon pages (1, 2) and upmerged any leftover images. --HyperGaruda (talk) 06:49, 15 January 2023 (UTC)

Wikidata Infobox calls in the templateEdit

Should Template:Wikidata Infobox be placed directly in the category or can it be done with a template? If you look at Category:1338 in Italy, there are two calls to WikiData infobox. The first added to Template:Italyyear, the second added by Pi Bot. This results in an error because it has two calls for coordinates, and is thus in Category:Pages with malformed coordinate tags as are many of the years in Italy category. Pinging @Mike Peel since it seems like a ridiculous request for Pi Bot to keep track of which templates also have a call to Wikidata infobox inside the template call but maybe it isn't that hard to figure out. I am against inserting it by template as it just leads to a series of automation with unintended effects if people aren't paying attention and I expect people will try to add it to templates inside templates eventually. This may be more of a policy question than a technical one but maybe there is another fix. Ricky81682 (talk) 07:16, 9 January 2023 (UTC)

The ibox call is also in Template:Poland by year, Template:SingaporeYear, Template:Bulgariayear, and Template:BrazilDecade. Also pinging @Rudolphous as that bot also does infobox additions and is creating these errors. The ibox calls were added by @Zelenymuzik and @AnRo0002. No blame, just trying to see what's the best solution here. Ricky81682 (talk) 07:24, 9 January 2023 (UTC)
@Ricky81682: {{Wikidata Infobox}} and all of its surrounding tooling (Pi bot etc.) assume that the template is always placed directly in the category. Embedding it in templates will break that, as you've demonstrated. The solution is to remove the embedding in a template. Thanks. Mike Peel (talk) 07:26, 9 January 2023 (UTC)
  • Anyone want to have their bot review the pages and put the infobox back in after it is removed from the temples? It would save a step down the line. -- Ricky81682 (talk) 05:22, 18 January 2023 (UTC)

Tech News: 2023-02Edit

MediaWiki message delivery 01:05, 10 January 2023 (UTC)

Weird thumbnailsEdit

Hello!

I haven't edited for a while but now so I don't know exactly when the change was made but now when you go to Special:Search all file thumbnails have the same height and width for some reason. When you actually go to the file page it is as before but on Special:Search there is something weird going on. m:User:Jonteemil/global.css makes the background covered with File:Checker-16x16.png but before only the background within the width and height of the file was covered. Now an entire square of the same width and height is covered. Has there been a change? Jonteemil (talk) 01:41, 13 January 2023 (UTC)

The topic was discussed after this change. The thread is here: https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical/Archive/2022/10#Did_the_Special%3ASearch_display_change_and_break%3F There is a user pref on most wikis to turn those thumbnails off, that hack has been advised as the 'solution'.
Even though correct (old-skool) thumbnail display has been restored on Commons, there is still a technical issue in loading all images of a random 500 items search. Always some images may not properly appear even after several times reloading the page. This 'artifical lag' is still an (annoying) game stopper in my experience. Peli (talk) 08:54, 18 January 2023 (UTC)

importScript deprecated? migration to mw.loader?Edit

i just learnt that importScript was deprecated mw:Topic:Ufathwjhyszsis17? it can be migrated to mw.loader mw:ResourceLoader/Migration_guide_(users)#How_to_migrate?

i have no knowledge about these things, so my questions are, is it more beneficial to migrate? are there drawbacks from migration? RZuo (talk) 11:09, 15 January 2023 (UTC)

Yes, it is depreciated. ImportScript is easier to use than mw.loader, since you have to use the full url with mw.loader. ImportScript does not work on mobile, whereas mw.loader does (that does not mean that an script will work on mobile with it, just that it will load). Mw.loader is asynchronous, but ImportScript is not, so any dependancies that the script has has to be defined using mw.loader.load.using for user scripts or in MediaWiki:Gadgets-definition for gadgets. The script will likely break if that is not done (because it will load too quickly, prior to the dependency being present). So, if you take the necessary precautions it should not have any drawbacks. Snævar (talk) 06:32, 16 January 2023 (UTC)

Tech News: 2023-03Edit

MediaWiki message delivery 01:07, 17 January 2023 (UTC)

Merging Wikidata items and the impact on Structured data in Commons filesEdit

See Wikidata:Project chat#Merging Wikidata items and the impact on Structured data in Commons files. In short: If two Wikidata items have been merged, there should be a bot on Commons to implement those changes also on Structured data in Commons files.

  1. Is there such a bot on Commons?
  2. If no: how can we get one?

JopkeB (talk) 15:35, 17 January 2023 (UTC)

why are we even supposed to take care of shit like this. WMF and the developers came up with this thing SDC and should ofc take care of any problems it brings along. shouldnt expect us to design and run a bot by ourselves to correct a fundamental flaw in their design of SDC.
sorry for grumbling. shooting this to phab: is better than asking among ourselves, i think. they get paid. we dont.🤣😡--RZuo (talk) 16:32, 17 January 2023 (UTC)
Thanks, RZuo, for your reaction. I did not know this. Shall I shoot this to phab:? JopkeB (talk) 04:03, 18 January 2023 (UTC)
yes, they should deal with it first. if a bot is the solution, they should try making the bot first.--RZuo (talk) 20:38, 18 January 2023 (UTC)
See https://phabricator.wikimedia.org/T327374. JopkeB (talk) 06:52, 19 January 2023 (UTC)
It turns out this bug was already signaled in November 2019, see https://phabricator.wikimedia.org/T237899 (latest comment in September 2021, so little progress). --JopkeB (talk) 14:57, 20 January 2023 (UTC)
  This section is resolved and can be archived. If you disagree, replace this template with your comment. --JopkeB (talk) 14:57, 20 January 2023 (UTC)

User script: add a portlet menu?Edit

i'm creating quite a few user js that add some convenience links, which i'm currently putting under p-tb. is it possible to add a portlet menu? i want to put my stuff under that so they're not mixed up with other things. sorry my js is too elementary. i have read https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.util-method-addPortletLink but dont quite understand. it seems impossible?--RZuo (talk) 00:25, 18 January 2023 (UTC)

-i---i- filenames, where do they come from?Edit

files like File:-i---i- (8171912885).jpg. take note this was uploaded this month, so it's not an old issue that gave rise to this name. it was imported from https://www.flickr.com/photos/abbers13/8171912885/ via com:flickr2commons. it seems the flickr original has no "title".

but as i tried f2c with https://www.flickr.com/photos/141868040@N06/52630799374/ or https://www.flickr.com/photos/32558319@N03/52634147592/ , filenames suggested by f2c are just "(52630799374).jpg", without "-i---i-". then where did they come from?

i ask because i'm tired of these meaningless names and want to have it included in MediaWiki:Titleblacklist, but i wanted to investigate its origin first.--RZuo (talk) 20:38, 18 January 2023 (UTC)

Yeah, I can see why you are tired of those. There is between 9k and 10k of those. 7.6k do not have an tag in the first revision, 381 is from flickr2commons (tagged by abuse filter 207), 469 from flickr2commons 1.0, 486 from CropTool 1.5, 575 from wikieditor and others have less than 50 images each. Snævar (talk) 11:46, 19 January 2023 (UTC)
the weird thing is, i dont know why i cant replicate these filenames when i try f2c. it's certainly added by code rather than by humans, but i cant find out what exactly is responsible for this.--RZuo (talk) 20:38, 19 January 2023 (UTC)

The Commons search engine is completely f-ed up!Edit

Look here. When I search for recent files depicting Magdeburg, the German city, the search engine returns billions of totally unrelated pictures from Maryland, USA. See ? What the hell is that?! Is it because of the "MD"? How could such an error even occur? I'm really - as you might have guessed - quite flabbergasted. Edelseider (talk) 20:17, 19 January 2023 (UTC)

yes it's definitely because of wikidata and stuff. i remember this was reported before, and some guy from the development said mediasearch will search not only the word you give but also its "aliases" from wikidata.
so it showed you also results of "MD", which includes File:周焯華.png because of the .md domain. hahaha.--RZuo (talk) 20:38, 19 January 2023 (UTC)
Meanwhile, try "Magdeburg" (with quotation marks) to get more relevant hits. --HyperGaruda (talk) 21:19, 19 January 2023 (UTC)
Thank you both of you. Yes, I have thought of the quotation marks. However, this should not be a necessary precaution (or measure) if that search engine was calibrated correctly. It will only get worse, if nothing changes, because there are new files coming in every day. --Edelseider (talk) 06:50, 20 January 2023 (UTC)
I think here it is about weighting of most recent uploaded files and exact matches. GPSLeo (talk) 07:03, 20 January 2023 (UTC)