Page MenuHomePhabricator
Feed Advanced Search

Thu, Jun 20

Thgoiter awarded T179884: Files occasionally getting uploaded to Commons without file pages. a Burninate token.
Thu, Jun 20, 11:26 AM · Multimedia, UploadWizard, media-storage, Commons
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

I still see them occasionally, such as: these two:

Thu, Jun 20, 5:00 AM · Multimedia, UploadWizard, media-storage, Commons

Feb 9 2019

Ghouston added a comment to T29280: Deleted page is shown at "File usage on other wikis".

Is this the same thing? https://commons.wikimedia.org/wiki/Commons:Village_pump#Wrong_link_in_globale_usage

Feb 9 2019, 10:04 AM · Multimedia, GlobalUsage

Jan 28 2019

Ghouston added a comment to T27707: Allow "html" in exif tags.

It's a bit hard to find information about this problem online, since it affects browsers that became obsolete in 2009 when a newer version of IE was released. Perhaps Microsoft even patched the bug in the old versions, if they supported them for several years afterwards?

Jan 28 2019, 10:23 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jan 26 2019

Ghouston added a comment to T27707: Allow "html" in exif tags.

Editing Exif without potentially breaking something is difficult. A lot of extensions have been added to JPEG over the years, and some of them contain pointers to data outside their own segments. Things like maker notes (proprietary and not fully documented) and Multi-Picture Format (which allows putting multiple images in a single JPEG file). They all need to be unpacked, adjusted, and repacked. The only practical method is probably to use ExifTool, and even that isn't perfect.

Jan 26 2019, 8:12 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
Ghouston added a comment to T27707: Allow "html" in exif tags.

I suppose I misinterpreted the comment about disabling logins. The idea would be that somebody would craft a JPEG (or other file type, presumably) file with some embedded Javascript, and some other user would come along with some old version of IE that would bizarrely ignore the MIME type when displaying the full-size file, execute the Javascript, and do some stupid thing under their account?

Jan 26 2019, 7:30 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading
Ghouston added a comment to T27707: Allow "html" in exif tags.

At what point does this IE security issue manifest itself, during the upload process? The file is being uploaded, not being sent to the browser to be displayed.

Jan 26 2019, 7:03 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Security, Multimedia, MediaWiki-Uploading

Jan 17 2019

Ghouston added a comment to T213975: Link page from wikimedia.Commons with page exisiting on en.wikipedia with no existing item on wikidata fails.

I also noticed this recently. I attempted the work-around of creating the link from Wikipedia instead, but that also fails because there doesn't seem to be any way of selecting Commons as the link target. Maybe that should be another issue raised in Phabricator.

Jan 17 2019, 9:05 PM · Patch-For-Review, User-Ladsgroup, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Wikidata, Commons

Aug 26 2018

Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

A small batch of 6:

Aug 26 2018, 1:36 AM · Multimedia, UploadWizard, media-storage, Commons

Jun 28 2018

Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

It may be caused by T198350, in this latest case.

Jun 28 2018, 4:30 AM · Multimedia, UploadWizard, media-storage, Commons
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

Here's another recent mini-surge:

Jun 28 2018, 3:38 AM · Multimedia, UploadWizard, media-storage, Commons

Jun 7 2018

Ghouston added a comment to T196674: Stop using "century" and "millennium" in association with Wikidata datetime data.

The actual bug is that some software (such as the Wikidata user interface) doesn't seem to be following the definition of the "precision" field in a date.

Jun 7 2018, 11:51 PM · Wikidata

Jun 5 2018

Ghouston added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

Yeah, I was wrong about the values getting set to zero, the insignificant digits are retained internally.

Jun 5 2018, 11:43 PM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Jun 1 2018

Ghouston added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

I agree with Jc3s5h. Wikidata dates are represented in JSON with ISO 8601 strings with associated precisions, and a "century" precision value looks like:

Jun 1 2018, 6:28 AM · patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Apr 10 2018

Ghouston added a comment to T191940: Investigate 2018-04-10 global traffic drop.

And now dead again. Affects www.wikipedia.org, commons, wikidata, wiktionary.

Apr 10 2018, 11:28 PM · Wikimedia-Incident, Traffic, Operations
Ghouston added a comment to T191940: Investigate 2018-04-10 global traffic drop.

Just started working again.

Apr 10 2018, 11:21 PM · Wikimedia-Incident, Traffic, Operations
Ghouston added a comment to T191940: Investigate 2018-04-10 global traffic drop.

Well, phabricator is fine.

Apr 10 2018, 11:18 PM · Wikimedia-Incident, Traffic, Operations
Ghouston added a comment to T191940: Investigate 2018-04-10 global traffic drop.

They still don't load for me. I think this is about April 10, not April 11.

Apr 10 2018, 11:18 PM · Wikimedia-Incident, Traffic, Operations

Feb 24 2018

Ghouston added a comment to T188102: 3D adds MMV handlers to thumbnail download links of File description page.

It's working OK for me today. I'm not sure if somebody changed something or if there's some other factor.

Feb 24 2018, 3:01 AM · Multimedia-Team-Working-Board, Multimedia, 3D

Feb 22 2018

Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

There are more, I think at least 400 in total, but I'm not going to list them all here.

Feb 22 2018, 11:44 PM · Multimedia, UploadWizard, media-storage, Commons
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

Here's another batch of 29 from the same day, a few minutes later. The ordering may be random.

Feb 22 2018, 11:26 PM · Multimedia, UploadWizard, media-storage, Commons
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

I just found 24 of these files, all uploaded between 2018-02-21T20:27:36 and 2018-02-21T20:28:13 UTC, by various uploaders. Here are links, ordered by upload time:

Feb 22 2018, 12:57 AM · Multimedia, UploadWizard, media-storage, Commons

Feb 18 2018

Ghouston added a comment to T187643: Search suggestions for "futher" do not include "further".

Wikidata above should read en.wiktionary.org.

Feb 18 2018, 10:11 AM · Discovery-Search, Discovery
Ghouston created T187643: Search suggestions for "futher" do not include "further".
Feb 18 2018, 10:10 AM · Discovery-Search, Discovery

Nov 10 2017

Ghouston added a comment to T32961: Run refreshImageMetadata.php --force.

It may need to be done as part of the Structured Data project. Part of that project could involve copying useful values from Exif fields into a file's data page, and there's not much point in doing that until the corrupt values are fixed.

Nov 10 2017, 1:34 AM · Wikimedia-maintenance-script-run, Multimedia, Wikimedia-Site-requests

Nov 7 2017

Ghouston added a comment to T179967: UploadWizard can overwrite existing files uploaded in the same session before clicking "Upload more files".

Maybe the non-existing category isn't significant. The file in the merged duplicate T178555 was uploaded with a valid category created in 2012.

Nov 7 2017, 8:55 PM · MW-1.31-release-notes (WMF-deploy-2017-11-28 (1.31.0-wmf.10)), Patch-For-Review, Multimedia-Team-Working-Board, Commons, UploadWizard, Multimedia
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

I never saw anything like this prior to 1 Nov. Did something change around that time, a new MediaWiki version or changes to the UploadWIzard?

Nov 7 2017, 11:03 AM · Multimedia, UploadWizard, media-storage, Commons
Ghouston added a comment to T179884: Files occasionally getting uploaded to Commons without file pages..

It can, because the first entry in the history is when the page was created by Guanaco a copule of days after the original upload. Better yet, take a look at https://commons.wikimedia.org/wiki/File:Ahora_nos_toca_a_nosotros,_ovaci%C3%B3n.jpg which doesn't have a proper page and doesn't have a history link at all.

Nov 7 2017, 11:01 AM · Multimedia, UploadWizard, media-storage, Commons
Guanaco awarded T179884: Files occasionally getting uploaded to Commons without file pages. a Meh! token.
Nov 7 2017, 12:51 AM · Multimedia, UploadWizard, media-storage, Commons

Nov 6 2017

Ghouston created T179884: Files occasionally getting uploaded to Commons without file pages..
Nov 6 2017, 11:59 PM · Multimedia, UploadWizard, media-storage, Commons

Jul 17 2017

Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

The same problem of notability will turn up if the subjects of images are going to be linked to Wikidata items, since there are plenty of images of things like buildings that may not be notable for Wikidata. At present, there's no problem having a category for the building. The X# solution does seem preferable to having Q# items hosted on both Commons and Wikidata, and you could prevent Q# items from linking to X# items.

Jul 17 2017, 9:23 PM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata
Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

Technically, I suspect this would be easiest if Wikidata was allowed to hold all the items that Commons needs to store information about. Maybe there could be a way to restrict particular Wikidata items to a limited subset of properties, so that URLs etc., could be stored without giving people a place to store arbitrary unverifiable information about themselves or others. A few bits of information are relevant for determining copyright expiration: whether an author is a person or a company (my previous comments neglected to mention the concept of "corporate authors", although they seem to be usually treated the same way as anonymous authors), and date of death.

Jul 17 2017, 12:01 PM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata

Jul 7 2017

Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

Maybe it's not even right to consider Department of Immigration and Citizenship to be the copyright holder in that example, and it's a file with Australian Government crown copyright. In that case, it's not clear what role DIAC is filling, if not the author or copyright holder.

Jul 7 2017, 1:38 AM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata
Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

On Commons, we currently tend to confuse author and copyright holder. It's the copyright holder who can release a file with a free license, and in practice chooses the attribution. We have a lot of files like https://commons.wikimedia.org/wiki/File:Christmas_Island_(5774557225).jpg where the author (photographer) is unknown but the copyright holder is presumably the Australian government Department of Immigration and Citizenship. This is also a good example of a file with a bad URI, since the department has been reorganised and renamed and the Flickr account is gone.

Jul 7 2017, 1:21 AM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata

Jun 23 2017

Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

I had the idea from the demo system that such records would exist (http://structured-commons.wmflabs.org/wiki/Q2). Oh well. With a system of credit string + URI it will be problematic in some cases to find all the works by a particular author. Credit string could be all over the place (G Bush on one photo, G.W.Bush on another, George Bush on a third etc., not to mention having multiple people named G Bush) so it's not very helpful. With other people you may not be able to find a URI at all, e.g., non-notable 19th century photographers, or US government employees whose work is published on their department's Flickr account.

Jun 23 2017, 1:31 AM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata

Jun 22 2017

Ghouston added a comment to T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI).

I'm not sure why you'd want a URI to an external site in a field like this. Is it not possible to assume that every person referred to will have an item either on Wikidata or on Commons? Then this field only needs to link to one of those places, where links to Flickr profiles etc., can be collected. When somebody is uploading a new file, you'd need to ask for some kind of link like that that identifies the person and allows linking to the right Wikidata/Commons record, creating a new one if needed. External links also go bad sometimes when people delete their Flickr accounts etc. There will be other complexities, like multiple people sharing a single Flickr account (e.g., if the Flickr account is for an organization and they have images from various authors), or people who have multiple Flickr accounts.

Jun 22 2017, 7:21 AM · SDC General, User-Ladsgroup, Story, Commons, MediaWiki-extensions-WikibaseRepository, Wikidata

Mar 21 2017

Ghouston created T160975: API commonmetadata doesn't work on TIFF files?.
Mar 21 2017, 4:25 AM · Multimedia, MediaWiki-extensions-PagedTiffHandler, Commons

Jan 22 2017

Ghouston added a comment to T145279: Interwiki links to articles in other projects from Commons categories via Wikidata.

Those are also fixed by making sitelinks. The only relevant Wikidata policy that I know of is Wikidata:Notability, which says "an item with only a sitelink to a category page in Wikimedia Commons is not allowed on main article items", which I believe means you can't create new Wikidata item which is linked only to Commons. That won't be an issue for most of the biological categories.

Jan 22 2017, 8:41 PM · SDC General, MediaWiki-Interwiki, MediaWiki-Categories, Commons, Wikidata

Jan 10 2017

Ghouston added a comment to T145279: Interwiki links to articles in other projects from Commons categories via Wikidata.

Actually in this case there's a category item on Wikidata, so the Commons category can link to that. It makes it slightly harder to set up, because it needs a template on the category to pull in the links from the main Wikidata item.

Jan 10 2017, 4:13 AM · SDC General, MediaWiki-Interwiki, MediaWiki-Categories, Commons, Wikidata
Ghouston added a comment to T145279: Interwiki links to articles in other projects from Commons categories via Wikidata.

I made a sitelink on Commons Category:Anastigmat and now the links are fine. There has been some discussion on Wikidata in the past about whether this is the right way to do it, but no consensus was reached. However the software is set up to support it ("Add Links" in the sidebar) and it's the only way to make all the sidebar links appear on the Commons side, including the link to the Wikidata item.

Jan 10 2017, 3:58 AM · SDC General, MediaWiki-Interwiki, MediaWiki-Categories, Commons, Wikidata

Dec 27 2016

Ghouston added a comment to T154149: Upload Wizard: Add "This file was found on the net." as a third option to "own work" and "not own work".

Did you set a default license in Preferences / Upload Wizard?

Dec 27 2016, 12:43 AM · Multimedia, Commons, UploadWizard

Dec 12 2016

Ghouston added a comment to T152839: Sometimes no js is loading on commons (CropTool gadget issue?).
Dec 12 2016, 4:03 AM · Wikimedia-General-or-Unknown
Ghouston added a comment to T152839: Sometimes no js is loading on commons (CropTool gadget issue?).

Thanks, that fixes it for me. I guess the load order was changing between the working and non-working versions, maybe depending on whether the files were cached.

Dec 12 2016, 3:58 AM · Wikimedia-General-or-Unknown

Dec 11 2016

Ghouston added a comment to T152839: Sometimes no js is loading on commons (CropTool gadget issue?).

I have more luck reproducing it with "fresh" files. Refreshing the page will fix it, and then it stays fixed when refreshed several more times. There's nothing special about that particular file I posted, it's quite easy for me to reproduce on a random file. Adding ?debug=true seems to fix it too.

Dec 11 2016, 9:12 PM · Wikimedia-General-or-Unknown
Ghouston added a comment to T152839: Sometimes no js is loading on commons (CropTool gadget issue?).

Disabling the CropTool gadget in preferences seems to help.

Dec 11 2016, 12:30 AM · Wikimedia-General-or-Unknown
Ghouston added a comment to T152839: Sometimes no js is loading on commons (CropTool gadget issue?).

One thing that stands out is:

Dec 11 2016, 12:27 AM · Wikimedia-General-or-Unknown

Oct 7 2016

Ghouston added a comment to T145953: File displaying invalid metadata in Commons, when the original Exif seems fine..

Thanks for fixing that file, but there are many others in https://commons.wikimedia.org/wiki/Category:Invalid_equipment_in_Exif (some are genuinely invalid, others are probably caused by this bug), and more are found all the time.

Oct 7 2016, 11:45 PM · Multimedia, MediaWiki-File-management, Commons
Ghouston reopened T145953: File displaying invalid metadata in Commons, when the original Exif seems fine. as "Open".

I've reopened this, since T140419 is supposedly fixed since August. I've tried purging the image description page, which according to https://www.mediawiki.org/wiki/Manual:File_metadata_handling is supposed to read the metadata again, but the metadata is still corrupt.

Oct 7 2016, 9:32 AM · Multimedia, MediaWiki-File-management, Commons

Sep 18 2016

Ghouston added a comment to T145953: File displaying invalid metadata in Commons, when the original Exif seems fine..

Hmm, maybe that fix isn't on Commons yet: T140419

Sep 18 2016, 4:53 AM · Multimedia, MediaWiki-File-management, Commons
Ghouston created T145953: File displaying invalid metadata in Commons, when the original Exif seems fine..
Sep 18 2016, 4:48 AM · Multimedia, MediaWiki-File-management, Commons

Apr 22 2016

Ghouston added a comment to T86611: API does not fail gracefully when data is too large.

I think my problems may go away if I request commonmetadata instead of metadata.

Apr 22 2016, 6:50 AM · Commons, Wikisource, MediaWiki-API
Ghouston added a comment to T86611: API does not fail gracefully when data is too large.

It seems that the entire text of a document may be embedded in djvu or pdf metadata. Apart from the problem of requests failing due to the limit, it's wasteful to need to request so much data if you are interested in a few specific fields.

Apr 22 2016, 6:06 AM · Commons, Wikisource, MediaWiki-API

Apr 20 2016

Restricted Application updated subscribers of T86611: API does not fail gracefully when data is too large.

Is this 12MB+ of metadata in any way useful? The file page in Commons doesn't show any trace of it: https://commons.wikimedia.org/wiki/File:Boiste_-_Dictionnaire_universel,_1851.djvu Maybe its corruption either in the original file or when it's imported into Commons?

Apr 20 2016, 9:23 AM · Commons, Wikisource, MediaWiki-API

Apr 3 2016

Ghouston renamed T131652: API returning unnecessary continuations in generator results from API ignoring namespace restriction in generator results to API returning unnecessary continuations in generator results.
Apr 3 2016, 7:17 AM · MediaWiki-API, MediaWiki-Categories
Ghouston created T131652: API returning unnecessary continuations in generator results.
Apr 3 2016, 6:49 AM · MediaWiki-API, MediaWiki-Categories

Mar 16 2016

Ghouston added a comment to T130091: Edits fail with "badtoken: Invalid token" after a few hours..

Thanks, I only save the initial cookies from the login. I'm curious to know why they change now.

Mar 16 2016, 8:59 PM · MediaWiki-API
Ghouston added a comment to T89702: Edits fail with "badtoken: Invalid token" after script runs for a while.

OK, I created T130091. I'm not using pywikibot, so that's not the issue.

Mar 16 2016, 5:35 AM · Pywikibot
Ghouston created T130091: Edits fail with "badtoken: Invalid token" after a few hours..
Mar 16 2016, 5:33 AM · MediaWiki-API
Ghouston added a comment to T89702: Edits fail with "badtoken: Invalid token" after script runs for a while.

I also have a problem that seems related. I save the cookies from a login request and use them in subsequent runs of a bot. Previously, it would work fine for months on end. But in recent weeks/months the bot is no longer able to edit pages after a few hours of inactivity. According to an assert=user query, it's still logged in. But fetching a new csrf token and attempting to edit a page always fails with the error: badtoken: Invalid token. It works again after a new login.

Mar 16 2016, 4:39 AM · Pywikibot

Nov 15 2015

Ghouston created T118670: Items not showing up in category they have been added to.
Nov 15 2015, 1:03 AM · MediaWiki-JobQueue, Commons