Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T274150: Uploading via UploadWizard gets stuck for a 11 MB JPG
    • Task
    Hello, I just got an user report that uploading an image via UploadWizard gets stuck consistently for an JPG image that has 11 MB. The image I used to reproduce this can be found at https://people.wikimedia.org/~urbanecm/Taipei_Taiwan_Taipei-101-Tower-01.jpg. I'm pretty certain that used to work before. Did sth change in UW recently? Or am I mistaken? the network tab shows API.php requests for `action=upload&format=json&stash=1&checkstatus=true&filekey=1840w8uox9l0.gxcf5y.4351678.jpg&errorformat=html&errorlang=en&errorsuselocal=1&formatversion=2&token=REDACTED`, which consistently returns `{"upload":{"result":"Poll","stage":"queued"}}`.
  • T271968: Upload wizard should automatically update public domain year in mwe-upwiz-license-pd-old-70-1923 and mwe-upwiz-license-pd-us
    • Task
    Every year on new year, new items enter the public domain under U.S. law. When this happens, the Upload Wizard must be updated to indicate that items a year later may now be uploaded. (Go to the "release rights" step of the wizard, choose, "this is not my own work" > "The copyright has definitely expired in the USA" and note the dates.) This update currently happens manually through tasks like T326045, which results in a delay and additional work. The update should be automated by setting up [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/UploadWizard/+/cd73c05443326e786a8267e0d8ae3d71efb58da6/i18n/en.json#339 | mwe-upwiz-license-pd-old-70-1923 ]] and [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/UploadWizard/+/cd73c05443326e786a8267e0d8ae3d71efb58da6/i18n/en.json#309 | mwe-upwiz-license-pd-us ]] to use the full-protected {{[[ https://commons.wikimedia.org/wiki/Template:Not-PD-US-expired-min-year | Not-PD-US-expired-min-year ]]}} or {{[[ https://commons.wikimedia.org/wiki/Template:PD-US-expired-max-year | PD-US-expired-max-year ]]}}, or directly through the formula {{#time:Y|-95 years}}.
  • T271666: UploadWizard api test requirements.txt is out of date
    • Task
    Last changed as part of {T134730}, the file has ``` http://effbot.org/media/downloads/PIL-1.1.7.tar.gz#egg=PIL ``` And if we try and get this file... ``` $ curl -I -L http://effbot.org/media/downloads/PIL-1.1.7.tar.gz HTTP/1.1 301 Moved Permanently Content-Type: text/html Server: GitHub.com Location: https://effbot.org/media/downloads/PIL-1.1.7.tar.gz X-GitHub-Request-Id: 9E28:CFCB:D6A283:E3ABD3:5FFB9483 Content-Length: 162 Accept-Ranges: bytes Date: Sun, 10 Jan 2021 23:58:01 GMT Via: 1.1 varnish Age: 6 Connection: keep-alive X-Served-By: cache-lcy19257-LCY X-Cache: HIT X-Cache-Hits: 1 X-Timer: S1610323082.994109,VS0,VE1 Vary: Accept-Encoding X-Fastly-Request-ID: 992d78a96212a5500e6c3fe2b51dadb211dd91de HTTP/2 404 content-type: text/html; charset=utf-8 server: GitHub.com access-control-allow-origin: * etag: "5fc8edf5-32" x-proxy-cache: MISS x-github-request-id: 6B78:1A93:27B943:2AB5DE:5FFB9489 accept-ranges: bytes date: Sun, 10 Jan 2021 23:58:02 GMT via: 1.1 varnish age: 0 x-served-by: cache-lcy19274-LCY x-cache: MISS x-cache-hits: 0 x-timer: S1610323082.084637,VS0,VE103 vary: Accept-Encoding x-fastly-request-id: 2a67fc6ab942d25cefcef424e86cff84cc2a5ea1 content-length: 50 ``` Not sure if these are still actually used for anything, but obviously it would be broken
  • T270432: UploadWizard FlickrChecker fails on Flickr 'favorites' pages
    • Task
    The code for mw.FlickrChecker.js [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/UploadWizard/+/refs/heads/master/resources/mw.FlickrChecker.js#79 | suggests ]] that it supports links to user favorite pages, but testing this in the UploadWizard times out. As an example, this item https://www.flickr.com/photos/britishlibrary/50563227766/ is marked "no known copyright restrictions" and if pasted into UploadWizard is successfully recognized. It is on about twenty favourite lists; pasting any of these into UploadWizard fails, coming up with a spinning icon for an indefinite period.
  • T270272: Integrate the "Creator" template on Wikimedia Commons with the Upload Wizard
    • Task
    If I put the ''Creator page template'' into the Author (artist) field of the Upload Wizard, it would be nice if that would then automatically populate (or suggest) the wikitext for the (best and most applicable) license to use for the image being uploaded. Going on from that it would be nice if it were to suggest appropriate categories to use against the file? Can there be an option for using the ''Artwork'' template as opposed to the mandatory ''Information'' one
  • T270014: [[MediaWiki:Mwe-upwiz-upload-comment-own-work/uk]] translation issue
    • Task
    GENDER support? ---- **URL**: [[https://translatewiki.net/wiki/MediaWiki:Mwe-upwiz-upload-comment-own-work/uk]]
  • T269496: Cannot choose "of" as qualifier from suggestion box in UploadWizard
    • Task
    The issue is that when setting structured data in the Upload Wizard the suggestion box top pick is not reachable with the cursor. Recreate issue: 1. Upload a image with the Upload Wizard 2. Go to step "Add data" 3. `depicts (P180)` -> `logo (Q1886349)` 4. Write "of" as a qualifier to `logo (Q1886349)` 5. I can not choose "`of (P642)`" with the cursor from the suggestion box. Image of the issue {F33936114} Screen resolution: 1920x1200 Browser: Google Chrome (full screen)
  • T267835: UploadWizard is adding an empty line between {{Information}} and "Other information"
    • Task
    **Steps to Reproduce: ** # Upload file with UploadWizard # Add something to "Other information" **Actual Results:** There is an empty line between {{Information}} template and content of "Other information", as can be seen [[ https://commons.wikimedia.org/w/index.php?title=File:Karlovy_Vary_hospital_during_the_COVID-19_pandemic_01.png&oldid=512342780 | here ]]: {F33913818} **Expected Results:** As in the past, there should not be an empty line.
  • T267492: Upload Wizard on Commons timing out with image in queue
    • Task
    Trying to upload a 18 MB JPEG file to Commons via the Upload Wizard at https://commons.wikimedia.org/wiki/Special:UploadWizard Issue: The first time, it was always displayed as in the queue, but no progress was made. I aborted the upload; the second time, it was for a while in the queue, then a message "The server did not respond within the expected time" appeared. The third time, I immediately got that "The server did not respond within the expected time" message after trying to upload. Other user confirms having same issue, see: https://commons.wikimedia.org/wiki/Commons:Village_pump#Upload_wizard_not_working_well_at_the_moment? Browser used: Firefox 82.0.2
  • T265645: Rewrite UploadWizard's ApiFlickrBlacklistTest to not try to make HTTP requests
    • Task
    These are now skipped, but instead the tests should be re-written so that use a mock service (and pass). Follow-up to {981b8fea422fb7355dae654b56a5ab95263a00f0}.
  • T265628: Identify which extensions' tests make HTTP requests and so are now broken post-T262443
    • Task
    [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/634038 | mediawiki/extensions/Math/+/634038 ]] failed to merge with error message `HTTP request blocked. Use MockHttpTrait.` Example: ``` +'<strong class="error texerror">Failed to parse (Conversion error. Server (&quot;https://wikimedia.org/api/rest_&quot;) reported: &quot;HTTP request blocked. Use MockHttpTrait.&quot;): {\displaystyle e^{i \pi} + 1 = 0\,\!}</strong>\n ``` https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-noselenium-docker/41299/consoleFull Caused by {T262443}
  • T265580: 404 error for SVG image thumbnail in UploadWizard on Beta Cluster
    • Task
    **Steps to reproduce:** 1. Firefox 81 2. Go to https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard?debug=true 3. Upload an SVG image **Expected outcome:** A preview of the uploaded image **Actual outcome:** No preview of the uploaded image; 404 error for the thumbnail URL {F32385486} {F32385493} (Width of text is already covered in `T265560`)
  • T264488: Upload "Queued..." in UploadWizard for a significant time
    • Task
    A few uploads uploaded ok, but after the part where you add description, categories ect and hit publish, only one file uploaded and three others became "Queued..." for a few minutes but did end up completing without further issues. However the next single upload was "Queued..." for about 15 minutes in the upload stage, no issues adding description, categories ect but after I hit publish it again "Queued..." for 10 minutes until I received "Unknown server error". Hit "Retry failed uploads" but gave "Upload from stash already in progress., where the screen is still stuck with saying "None of the uploads were successful." however five minutes after the server error it uploaded as https://commons.wikimedia.org/wiki/File:Dubbo_Memorial_Drive.jpg Added a question on VP/T https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Uploads_%22Queued...%22_in_UploadWizard
  • T263307: uploadstash has columns that are never read
    • Task
    The `uploadstash` table has multiple fields that appears to be never used, only written to in `UploadStash::stashFile` (https://gerrit.wikimedia.org/g/mediawiki/core/+/d02602c59cc31bb36f668acae64f6ba3f0201deb/includes/upload/UploadStash.php#297) `us_orig_path` - codesearch: https://codesearch.wmcloud.org/search/?q=us_orig_path&i=nope&files=&repos= `us_sha1` - codesearch: https://codesearch.wmcloud.org/search/?q=us_sha1&i=nope&files=&repos= Can the columns be removed?
  • T258887: UploadWizard generates an HTTP (not HTTPS) link post-upload
    • Task
    Steps to Reproduce: Upload a file to Commons. Actual Results: the post-upload screen offers you an HTTP:// link to the file just created. It should be HTTPS. {F31948372} Expected Results:
  • T255361: Special:UploadWizard should have option for uploading from a URL like Special:Upload
    • Task
    **What's the problem ?** On commons there are 2 upload pages, Special:Upload which supports the uploading of file from a URL, and Special:UploadWizard which (currently) does not. Using Special:Upload to load a file from a URL which is larger than 100MB repeatedly fails. I was advised Special:UploadWzard undetook different approaches to support upload of larger files compard to Special:Upload, However Special:UploadWzard does not currently have an option to upload directly from a URL. (In one use case this would be a URL to a PDF file at Internet Archive or Hathi Trust.). This means having to download the file from the origin site to local storage, and then reupload to Commons using the aforementioned page. This is wasteful of bandwidth on the user side. **What's the functionality you would like?** Option in Special:UploadWizard to provide a URL to the appropriate file, rather than a local file, and to have that file load reliably, potentially by a splitting the transfer into parts, if the file is greater than 50MB, with additional integrity checks being made to ensure it uploads completely.
  • T252326: Upload Wizard "copy information to all uploads" auto numbering system not working properly
    • Task
    When the Upload Wizard copies information from the first upload to the other uploads, it automatically numbers some or all of the uploads sequentially. For years, I have been naming the first of my multiple uploads in the format "[subject], [year] (01)" and the copying system has then been correctly naming and numbering subsequent uploads automatically as "[subject], [year] (02)", "[subject], [year] (03)", etc. Some weeks or so ago, the automatic numbering system broke. Since then, apart from a few days when someone fixed it, it has been misnumbering the uploads in the following way: it adds "01" to the first upload, and then misnumbers the subsequent uploads as "[subject], [year] (01) 02", "[subject], [year] (01) 03", etc. This misnumbering is really annoying, as it has to be corrected manually. It needs to be fixed permanently.
  • T252235: Upload Wizard does not allow to publish upload: After clicking "Publish files", nothing happens
    • Task
    Hi, just reporting that today it is the 4th time I have finished the stage of describing about 40 of my photos on Upload Wizard and upon clicking Publish files, nothing happened, so I had to reload and describe everything again, upon which the same thing happened several times... Later, I managed to upload by 10 files a time, but then the same thing happened again with about ten of them, too. You can imagine how much time I have lost doing it over and over again :-( Is there a way to prevent it happening? It had only happened once before, and several uploads in between went ok. My internet connection is fine, and I use Chrome.
  • T251582: Users do not get additional warning on Special:UploadWizard when required fields are not in their viewport
    • Task
    The issue was found when testing T224890 - see this comment[[ https://phabricator.wikimedia.org/T224890#6095517 | comment ]]. Steps to reproduce: 1. With multiple files upload on Special:UploadWizard, a user skips a required field(s) (or fills out only the field that is the closest to the bottom of the page) - and scrolls to the bottom of the page (so the not-filled required field is out of the view) 2. A user clicks on the 'Publish files' - there will be no warning that some required fields need to be filled out and no action. Adding an additional warning message e.g. "Some required fields are missing" or scrolling to the place(s) where required fields are not filled would improve user experience. {F31789183}
  • T249486: Change Content Security Policy on betacommons to allow api.flickr.com
    • Task
    Required to test Flickr import features of UploadWizard on beta.
  • T246537: Incomplete uploads in Upload Wizard
    • Task
    Three recent uploads have failed to complete, leaving the bottom of the images grey. This triggers Sandbot to tell me it's an incomplete image, which is something I already know. After failing the upload it then waits for about 7 minutes then gives the "Unknown Server Error". I have now lost the lengthy description text I entered for the image because steps cannot be retraced. Fustrating in the least and I suggest someone takes this problem by the horns and actually makes Upload Wizard usable.
  • T245861: Add Structured data during file upload with Upload Wizard
    • Task
    Many SDC properties should be added to the file during upload process with Upload Wizard. At the moment Upload Wizard is hardwired to add several Commons templates, like {{Information}}, {{Own}}, {{FlickrVerifiedByUploadWizard}}, {{Location}}, {{cc-by-4.0}}, etc. Most of those should also be matched to specific SDC properties which should be added at the upload time. We should have more discussions at [[https://commons.wikimedia.org/wiki/Commons:Structured_data/Modeling|c:Commons:Structured_data/Modeling]] about how to model different cases, but Upload Wizard should handle at the minimum case of own work by the uploader under standard CC license with standard date and optional camera coordinates and heading. Initially the information would be stored in wikitext and SDC, but once {{Information}} is updated we should store such info for basic cases, in SDC only. {{Location}} template is already capable of fetching camera coordinates and heading from SDC, so if coordinates are added to SDC than all that needs to be added to wikitext is empty "{{Location}}". Examples of SDC properties that could be automatically filled in by UploadWizard: * copyright status * copyright license * inception * coordinates of the point of view * image captured with * source of file: original creation by uploader (for own works) * author user name
  • T245503: Caption shown without correct language attributes in the "Add data" step in Upload Wizard
    • Task
    To reproduce: - Use Commons with English as the user interface language. - Upload a file. - During the uploading add this caption, and make sure to select Hebrew as the caption's language: `אחת two שלוש` - When you get to the "Add data" step, the caption in Hebrew is shown. -- Observed: The HTML element that contains the caption doesn't have the correct lang and dir attributes. The text is shown with the word אחת on the left-hand end and the word שלוש on the right-hand end. -- Expected: The text must be shown with the word אחת on the right-hand end and the word שלוש on the left-hand end. The HTML element that contains the caption must have lang="he" and dir="rtl", because it's explicitly known that it's Hebrew and right-to-left. Here's a screenshot of a recent upload: {F31621132 size=full} The filename is https://commons.wikimedia.org/wiki/File:P300_vs_local_oddball_probability.svg . The caption in Hebrew is shown incorrectly.
  • T245063: UploadWizard does not recognise Flickr "user/tags/..." links
    • Task
    The "share images from Flickr" option correctly identifies user, user album, and user gallery links as "select all the files from here". https://www.flickr.com/photos/britishlibrary/ > tries to import all images from the user (but limits to first 500?) https://www.flickr.com/photos/185225596@N02/galleries/72157711542166091/ > tries to import all images in the gallery https://www.flickr.com/photos/britishlibrary/albums/72157672074712488 > tries to import all images in the album https://www.flickr.com/photos/britishlibrary/tags/sysnum000077405 > tries to import **all images from the user**, rather than that user's tag https://www.flickr.com/photos/tags/sysnum000077405 > seems to time out So `user/albums/...`, `user/galleries/...` both work OK, but `user/tags/...` falls back to being treated as "all user's pictures" and a general tag search fails. I appreciate that "try to select all files with a specific tag across all of Flickr" is probably undesirable, but some users (especially large-scale uploaders like the BL example above) use tags systematically rather than albums - would it be possible for `user/tags/...` to be supported for selecting groups of files?
  • T244676: Language selector (ULS) structured data caption form doesn't have suggested languages
    • Task
    The Language selector (ULS) in the SDC caption form in Upload Wizard doesn't show suggested languages. These could be selected similarly to the suggested languages in ULS's own Compact Language Links, for example from geolocation or the user's previously selected languages.
  • T244663: Replace hard coded 1923 logic in UploadWizard with more than 95 years ago
    • Task
    In https://gerrit.wikimedia.org/r/571050 we encountered the fact that the UploadWizard has 1923 / 1924 / 1925 hard coded in it. 1923 was a magic year for many years and since a little over a year it change to more than 95 years ago. The UploadWizard logic should be updated so that we don't have to change messages every year.
  • T244557: Large files uploaded with UploadWizard fail to post file information
    • Task
    Steps to Reproduce: Upload a very large image. Actual Results: Image posts but the description page is not created. Expected Results: File posts with description page data. Impact: Our highest quality photographs are getting tagged for deletion, which confuses newbies. Further notes: This only started in the past week or two. Examples: * https://commons.wikimedia.org/w/index.php?title=File:Npt_photography_abdelwahed_taibi_07.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Vastvision.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Lostcity.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Kodaikanal_wah.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Aleppey.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:The_Thali_of_Traditional_Bengal.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Gurjar.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Npt_photography_abdelwahed_taibi_04.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Inbound1700066280903896057.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:3000_years_old_tree.jpg&action=history * https://commons.wikimedia.org/w/index.php?title=File:Infected_chillie_or_circumstances.jpg&action=history
  • T244406: PLURAL not supported in UploadWizard upload phase
    • Task
    The message `file-exists-duplicate`, when used on the UploadWizard, is shown unparsed, like: > Questo file è un duplicato {{PLURAL:$1|del seguente|dei seguenti}} file: {F31551359} The translation is correct: https://translatewiki.net/wiki/MediaWiki:File-exists-duplicate/it
  • T243926: Have UploadWizard automatically add structured data for licenses
    • Task
    Except in cases where someone chooses a custom license (which is rare), UploadWizard should automatically create a structured data claim about the license of the work. For example, if I choose a CC0 license for an image that I'm uploading with UploadWizard, it should automatically create a claim like: ``` copyright license (d:P275): CC0 (d:Q6938433) ``` This will allow users to search for images by license more easily ([[ https://commons.wikimedia.org/w/index.php?sort=relevance&search=flower+haswbstatement%3AP275%3DQ6938433&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1&ns6=1&ns12=1&ns14=1&ns100=1&ns106=1 | like this ]]).
  • T242942: Thumb warning showing up as unknown warning
    • Task
    When trying to upload a thumb photo (starts with 800px- etc.) The upload wizard shows the error `Unknown warning: "thumb: 800px-Consejo_Nacional_Independiente_de_Campesinos_y_Ecologistas_de_México_-i---i-_(33901408324).jpg".` when it should show something like `The file you are trying to upload is a thumbnail.`. The API request the upload wizard makes the upload API returns a warning with the index `thumb` under `{upload:{warnings:{thumb:'FILENAME'}}}`. For example uploading the file `800px-Consejo_Nacional_Independiente_de_Campesinos_y_Ecologistas_de_México_-i---i-_(33901408324).jpg` returns the error `Unknown warning: "thumb: 800px-Consejo_Nacional_Independiente_de_Campesinos_y_Ecologistas_de_México_-i---i-_(33901408324).jpg".`.
  • T242676: maximum Characters per svg-tag for xml-parser unknown
    • Task
    Steps to Reproduce: Upload the file https://doc-0k-a4-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/nsu966bin5bk5uliv7mqoq4nbfsvrnnd/1578945600000/06785432790838067384/*/1N4XoAJ3gZgXMoYrNfhzVGrUsq7DxRRRm?e=download (From https://drive.google.com/drive/folders/1qSQWgj5maKIlFv9daMMCivep06bqHySI, mentioned in https://en.wikipedia.org/wiki/Wikipedia:SVG_help#Can%27t_upload_a_SVG_file_on_Wikimedia) This file contains a >15.000.000 Characters long attribute xlink:href, which seems to make problems with the parser. (Shortening the xlink:href works to upload see https://commons.wikimedia.org/w/index.php?title=File:Test.svg&diff=387267960&oldid=387256821#filehistory 21:14, 13. Jan. 2020 ) Maybe it is another bug, but https://commons.wikimedia.org/wiki/File:1_42_polytope_7-cube.svg#filehistory does not render with the merged path (~10MB), but render with ~500.000 short lines (~28MB) Actual Results: If I use https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&uselang=de I get "Diese Datei hat die Dateiprüfung nicht bestanden" (german for This file does not succeded the test.) If I use https://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=de I get "Das XML in der hochgeladenen Datei konnte nicht geparst werden." (german for The XML cant be paresed in the uploaded file.) Expected Results: (It might be wanted, since uploading 10MB large Raster-files in a SVG-Container, might be seen as a missuse of SVG.) A notice of a maximal tag-length mentioned on https://commons.wikimedia.org/wiki/Commons:Maximum_file_size
  • T241655: Commons upload warning options are ambiguously worded: "OK" and "Cancel"
    • Task
    The following warning: Warning We recommend that you properly fill in all the fields. Do you want to continue without correcting these warnings? It is recommended that you fill in some categories for your uploads. offers two buttons, "Cancel" and "OK". I don't know which button does what. I think, "OK", means, "Yes, continue", but maybe it means, "OK, let me fill in some categories"? Buttons like this should offer obvious, unambiguous, answers to the question being asked. {F31495789}
  • T241330: UploadWizard in Firefox fails uploading multiple images
    • Task
    Using Firefox 71 (multiple uploads fail), using Google Chrome 79 (works fine). With the UploadWizard in Firefox, upload multiple images : uploads fail most of the time with a red exclamation mark. I once had an invalid CSRF error message. Uploading images one by one works most of the time (but sometimes fails).
  • T241113: upwizcampaigns and mass-upload should be included in a grant
    • Task
    Currently, no grants include `upwizcampaigns` or `mass-upload`. They should be added to an existing grant, or a new one should be created by the extension.
  • T232181: On Special:UploadWizard, 'Back' button is misleading; goes back too many steps
    • Task
    Steps to reproduce: Visit https://commons.wikimedia.org/wiki/Special:UploadWizard using an account that possesses `upload_by_url` (If you are shown the 'learn' page, click 'next') Select 'Share images from Flickr' Click 'back' Expect result: User is shown the form to choose between 'Select media files to share' or 'Share images from Flickr' Actual result: User is returned to the 'learn' page
  • T232101: Incorrect suggested statements appearing for a campaign
    • Task
    Steps to reproduce: * set up a campaign with suggested statements by going to the url `/wiki/Campaign:MyCampaign` and entering this as the wikitext ``` { "enabled": true, "wikibase": { "enabled": true, "statements": true }, "defaults": { "statements": [ { "propertyId": "P276", "dataType": "wikibase-entityid", "values": [ "Q1761" ] } ] } } ``` * upload an image for the campaign via `/wiki/Special:UploadWizard?campaign=MyCampaign` * note on the metadata page that the default statements are shown as well as the campaign statements - if campaign statements exist **only** those should be shown
  • T230563: Suggested statements WITH values in UploadWizard configurable via url query string
    • Task
    Allow the user to add keys/values to the query string that will result in suggested statements with values appearing on the metadata page of UploadWizard Acceptance criteria: [] user can append wikibase property ids with one or more wikibase item id values to the the url query string for `Special:UploadWizard`, and the metadata step in UW will show an editable panel for each property id from the query string with values corresponding the the item ids from the query string ... and when a user clicks 'Publish' the structured data on the page will be saved
  • T230395: Unreachable item in a long list outside of the bodycontent div
    • Task
    Unreachable item in a long list outside of the bodycontent div Browser: Firefox 68.0.1 In case a long selection list for adding an item opens to the top of the browser the upper item is not selectable, see screenshot. Probably because it is outside of the bodycontent div?{F30014254}
  • T230258: UploadWizard Flickr on Wikimedia Commons hangs, infinitely spins on 3 pictures
    • Task
    (Not sure how well reproducible this is − but the same thing happened to me twice in a row). 1. Upload file 2. Share images from Flickr 3. Paste URL https://www.flickr.com/photos/contri/2596460783/in/photostream/ 3. Add more images from Flickr 4. Paste https://www.flickr.com/photos/contri/2597289300/in/photostream/ 5. Add more images from Flickr 6. Paste https://www.flickr.com/photos/contri/2596456363/in/photostream/ Even after 1h, one image was uploaded, the other two are still spinning. {F30005615} Nothing of interest in neither the JS console (besides the usual “A CSP report is being sent.”) nor the network console (only 200s)
  • T229966: Show thumbnails when searching depicts in structured data on Commons
    • Task
    Posted on the SDC talk page: In the Upload Wizard, I am asked to choose depictions. * Problem: It is hard to guess which is the one I meant, especially when my locale (not English) has very few Wikidata labels and even less descriptions. Imagine the screenshot at the right without the descriptions and thumbnails. * Solution: Display thumbnails based on each item's P18. Why is this important? Because people are already misclassifying pictures using the Upload Wizard. I searched for depictions of https://www.wikidata.org/wiki/Q1683601 in the Commons Android app, and observed that two thirds of the images are misclassified. All items that are often selected as depictions already have a P18, fortunately.
  • T229224: File upload on slow connection speed fails with generic unhelpful error message
    • Task
    UploadWizard: REL1_33 MediaWiki: 1.33.0 Client upload speed: 0.28 Mbit/s File format: webm File size: 8.2 MiB At ~ 60% of upload progress, indicator stops progressing and ends with only "Error" note. No record for that time at php_error.log No record for that time at apache_error.log
  • T224653: Keep original ogv file type while uploading video file with standard Upload wizard in Commons
    • Task
    I have recently uploaded [[:File:Wikimedia Hackathon 2019 Punk band.ogv]] using the standard Upload wizard. The original file type before uploading was indeed ogv. During upload this was inadvertently changed into ogg. A bot renamed the file back to ogv, as per the https://www.ietf.org/rfc/rfc5334.txt rules. How to avoid the renaming step? The upload process seems to change the original ogv extension to ogg. Why does the upload program not keep the original (and correct) file type? Could this video file naming error be possibly fixed?
  • T224081: Need Ctrl/Cmd select multiple files for "Depict" feature on Commons
    • Task
    First of all, Depict rocks and I'm loving it!! {meme, src="goat-for-it"} Steps to Reproduce: # Go to WikiCommons and use UploadWizard to upload multiple files which might have similar elements # After uploading, you'll be prompted to add objects that you see in the file. However, there is not "Select All" or "Press and hold Ctrl/Cmd to select multiple file" option Actual Results: Ctrl/Cmd holding or selecting multiple file does not work as probably for not being defined Expected Results: Ideally, such an option would be very useful.
  • T223051: EXIF location data of image file not imported to MediaWiki File information (Upload with UploadWizard)
    • Task
    The EXIF location of some files uploaded with the UploadWizard got not added to the MediaWiki file metadata (and information template). This only appears to some files of the same upload queue in the UploadWizard. Purging the page dose not help. Example files: Not added: https://commons.wikimedia.org/wiki/File:Eckerlochstieg_19.jpg Added correct: https://commons.wikimedia.org/wiki/File:Eckerlochstieg_20.jpg Not added: https://commons.wikimedia.org/wiki/File:Bodebruch_in_April_2019_17.jpg Added correct: https://commons.wikimedia.org/wiki/File:Bodebruch_in_April_2019_16.jpg
  • T222939: UploadWizard should set proper language code on input for description
    • Task
    When I upload a file with UploadWizard and enter the description in several languages, the language code (and thus the language my browser uses for spellchecking) is always the default language. Instead, UploadWizard should set the correct language code on the input field, which it does know from the language select input above the description input field.
  • T221733: Caption / description UX issues: Put required fields before optional fields and validate earlier
    • Task
    **Problem** When I upload a bunch of files, it's natural for me to describe them in captions and leave descriptions blank since the former are shown above the latter in the form, only to find out when I try to publish that descriptions are required, and now I need to go back and copy everything over. **Proposed solutions** - Reorder the fields so that required fields are grouped above optional fields - Automatically use captions as descriptions if captions are provided but descriptions are not - Surface validation signals earlier (before clicking on Publish) so that people won't make the same mistakes across all files
  • T221524: Add another copyright link in the Uploadwizard
    • Task
    The page [[ https://commons.wikimedia.org/wiki/Commons:Copyright_tags | Commons:Copyright_tags ]] has been split - [[ https://commons.wikimedia.org/wiki/Commons:Copyright_tags | Commons:Copyright_tags ]] - [[ https://commons.wikimedia.org/wiki/Commons:Copyright_tags/Country-specific_tags | Commons:Copyright_tags/Country-specific_tags ]] **Suggestion** make the second country specific page also available in the Uploader Wizard See also [[ https://commons.wikimedia.org/wiki/Commons_talk:Copyright_tags/Country-specific_tags | discussion ]] {F28722876,width=600}
  • T220474: UploadWizard requires description at least 5 characters long, does not work well in languages like Japanese or Korean
    • Task
    As reported on [[ https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback#short_descriptions | Commons:Upload_Wizard_feedback#short_descriptions ]] Latest updates force users to enter descriptions of at least five characters, which are often unnecessary in languages like Chinese and Korean. How about transforming this filter into a warning that users could override? I could confirm than indeed, entering a short description in Japanese triggers: WARNING: This entry is too short. Please make sure this entry is at least 5 characters.
  • T220472: UploadWizard “Retry failed uploads” throws upload.ui.clearIndicator is not a function
    • Task
    As I was trying to reproduce an UploadWizard, I tried started an upload process. I grabbed the first file on my laptop, a 320px thumb of [[ https://commons.wikimedia.org/wiki/File:Fire_station_Hallstatt_-_October_2017_-_02.jpg | an old upload of mine ]]. The upload step fails spins for a bit but very quickly fails with « Unknown warning: "thumb: 320px-Fire_station_Hallstatt_-_October_2017_-_02.jpg". » Clicking « Retry failed uploads » results in the following stacktrace: ``` TypeError: upload.ui.clearIndicator is not a function[Learn More] load.php:69:37 uw.controller.Upload.prototype.retry/< https://commons.wikimedia.org/w/load.php:69:37 forEach self-hosted:268:13 uw.controller.Upload.prototype.retry https://commons.wikimedia.org/w/load.php:68:947 oo.EventEmitter.prototype.emit https://commons.wikimedia.org/w/load.php:248:479 UWUIUpload/this.retryButtonAllFailed< https://commons.wikimedia.org/w/load.php:37:1 oo.EventEmitter.prototype.emit https://commons.wikimedia.org/w/load.php:248:479 OO.ui.mixin.ButtonElement.prototype.onClick https://commons.wikimedia.org/w/load.php:280:610 <anonymous> self-hosted:984:17 dispatch https://commons.wikimedia.org/w/load.php:69:22 add/elemData.handle https://commons.wikimedia.org/w/load.php:65:753 ```
  • T218156: CC0 licensing is duplicated in the UploadWizard when using a mobile browser
    • Task
    If a user is uploading a file to Commons using a mobile browser (reported, Ecosia and Edge in Windows 10 Mobile) and the UploadWizard, they may experience repetition/duplication of licensing information. https://commons.wikimedia.org/wiki/File:File_captions_CC-0_license_repetition_error_(12_D._03_M._2019_A.).png Ideally, the user will see the licensing information only once on the page.
  • T218073: UW Flickr Upload fails to upload image whose file name more than 240 bytes
    • Task
    I cannot find a similar task, so I apologize if making a duplicate. Recently, I was trying to import some interesting images from Flickr, until today I received an error saying that UW Flickr Upload cannot proceed an image which have more than 240 bytes in its file name. See the screenshot. {F28372959} The image I was trying to upload is here: https://www.flickr.com/photos/bryansjs/15797237770/ Is there a workaround for this limitation? Thank you.
  • T218057: Determine workflow to selectively purge potentially privacy-sensitive EXIF fields, such as geocoordinates, from a Wikimedia Commons file
    • Task
    On another forum, a user reported the following chain of events: * Freely-license photo is found online * Photo includes EXIF data with GPS coordinates * User uploads it to Wikimedia Commons * A bot (presumably [[ https://commons.wikimedia.org/wiki/User:DschwenBot | DschwenBot ]]) extract the GPS from EXIF data and adds a {{Location}} tempalte * Such information allows to trace back the original author * Uploader removes {{Location}} template * Bot adds {{Location}} again * Uploader strips EXIF location data, using a third-party tool (“an app”) − unclear whether mobile, desktop, or web-based − and (presumably) reuploads * (Unclear whether the older version of the file was revision deleted by a sysop afterwards) Reactions from other users on that forum seem to indicate that some tooling should solve this issue. It is unclear to me whether the better workflow would be: * //preventive// − offering at upload time (presumably in #uploadwizard − although it is unconfirmed whether this was the upload tool used in this particular case). The drawback of this is that UW is not the only upload method out there. * //corrective// − on an already uploaded file, a one-click "purge geoloc from EXIF" + reupload new version. This could easily be implemented as a web-based Toolforge tool. As EXIF data is generally appreciated on Wikimedia Commons, it is likely that such a workflow would be considered as potentially open to abuse, this should be factored in the solution (eg access restrictions) This task should be to determine which of these two workflows (or others I did not think of) is preferable. As this issue is not specific to Wikimedia Commons, it could be helpful to know how other popular image-uploading platforms (Flickr, Unsplash, 500px, etc.) tackle this issue (if at all).
  • T217605: Unable to upload files larger than ~2MB on slow connections
    • Task
    I've been hesitant to file this bug for months, but recently I was in Central America and ran into this bug constantly. Sorry I don't have more technical details. Steps to reproduce: 1. Be on a slow internet connection. I know that's vague, but let's say >500kbps for upload speed. 2. Try to upload a file that is 2MB or larger using Special:UploadWizard or Special:Upload. Expected results: File uploads successfully after about 2-3 minutes. Actual results: File uploads for about 2 minutes and then fails with the message "Could not proceed due to network connectivity issues. Make sure you have a working internet connection and try again." I have no idea why 2MB seems to be the magical threshold, but I was usually able to upload smaller files, but rarely anything 2MB or larger. I had no problems doing the same thing on other sites like Dropbox, although it might take forever. Some logs of trying to upload 2 files that are 1.7 MB and 2MB: {F28364407} If it finishes in 1.2 minutes or less, it works. If it takes longer, it fails. When it finally fails, it throws the following console error: `https://commons.wikimedia.org/w/api.php net::ERR_SPDY_PING_FAILED` This is in Chrome 72.0.3626.121 on MacOS. Download speed ~1.2 Mbps and upload speed ~0.4 Mbps.
  • T216777: User get logged out while uploading files with UploadWizard
    • Task
    **What's happening** User select files in UploadWizard and complete every steps. On the last step, while uploads are finalized, somes files are succesful but then we see a message saying "You must be logged in to upload this file.". Opening a new page indeed show we are logged out. Logging In again and retrying may result in the same behavior when pressing "Retry failed upload". The session is not expired or timed out when uploading, I tried with a fresh new session and another browser. Because of this issue I now upload in batch of ~200, and after 100 files or so the session "expires". An IRC user suggested I open an issue in case someone else eventually face the same issue. I hope I provided enough information. **Versions** MediaWiki 1.32.0 PHP 7.2.15 (fpm-fcgi) APCU 5.1.17 MariaDB 10.3.12-MariaDB ICU 50.1.2 Upload Wizard 1.5.0 https://gamewiki.kuelio.org/Special:Version (Information on this page is subject to change)
  • T210201: UploadWizard accidentally overwrote an image in 2018 on [[c:File:Андрей_Егорович_Боровых.jpg]]
    • Task
    In fact, it shouldn't be capable of overwriting at all, although I'd welcome that feature.. I searched, but couldn't find an open task. https://commons.wikimedia.org/wiki/File:%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B9_%D0%95%D0%B3%D0%BE%D1%80%D0%BE%D0%B2%D0%B8%D1%87_%D0%91%D0%BE%D1%80%D0%BE%D0%B2%D1%8B%D1%85.jpg PlanespotterA320 uploaded the file on 21:21, 23 June 2018 "User created page with UploadWizard". On 18:20, 22 November 2018, PlanespotterA320 has overwritten it "User created page with UploadWizard". I tried to do it myself, but couldn't. See also https://commons.wikimedia.org/wiki/User_talk:Yann#Accidental_overwrite_with_the_uploadwizard : "Using Chrome on a laptop. If it helps, I'm switching between Yandex and Google search engines for different language searches. From my understanding, is it true that because of this bug the old version can't be deleted?--PlanespotterA320 (talk) 19:47, 22 November 2018 (UTC)"
  • T207466: Stop logging UploadWizardExceptionFlowEvent events
    • Task
    UploadWizardExceptionFlowEvent is used to track JS exceptions that occur in UploadWizard. We shouldn't be using EventLogging for error logging, and I don't think we're currently doing anything with that data anyway. (UploadWizardErrorFlowEvent is probably fine - that is used to log errors based on user input (e.g. invalid/duplicate file names etc.) that can be used to inform us when the interface might not be clear enough. Though we might want to look into its usage as well after T191081)
  • T207336: Upload Wizard makes it non-obvious to recover from a 250-character filename
    • Task
    If I try to upload a file with a 250-character ASCII filename, the Upload Wizard allows me to submit the form but then the upload fails. If I click "Back" and then "Next" I can get back to the file description stage, but with no indication of which files failed. To reproduce: Start the Upload Wizard. Click "Select media files to share", choose a file, then "Add more images" and choose another one. Click "Continue". On the next page ("Release rights"), click "These files are my own work". Click "Next". On the next page ("Describe"), completely fill the "Image title" box for one image with 250 ASCII characters. Write a short title for the other image. Also provide a description and if necessary a date for each one. Note that there is no indication that the long title is a problem. Click "Publish". The next page will indicate that one upload has succeeded and the other has failed, with a message "Filenames may not be longer than 240 bytes." Click "Back". This will return you to the "Release rights" page. From there if you click "Continue" you will be returned to the "Describe" page, but there will be no indication which files need their names shortened and which have been successfully uploaded. What should happen is that (a) the "Describe" page should reject excessively long filenames and (b) there should be a better recovery route when uploads fail.
  • T206947: UW throws a JS "jQuery.Deferred exception" in case the "Image title" contains a hash (#)
    • Task
    Test case: 1. Select in UW a file with a filename like "Test1234.jpg" 2. Continue to tab "release rights" and select "own work" 3. Continue to tab "Describe": Change the "Image title" from "Test1234.jpg" to "Test1234#.jpg" 4. Click on "Publish" Nothing happens. No UI error message about the (now) invalid image title. Upload is impossible. Firefox console throws: jQuery.Deferred exception: extension is null Title.normalizeExtension@https://commons.wikimedia.beta.wmflabs.org/w/resources/src/mediawiki.Title/Title.js?d684a:749:4 uw.controller.Details.prototype.valid/</promise<@https://commons.wikimedia.beta.wmflabs.org/w/extensions/UploadWizard/resources/controller/uw.controller.Details.js?d4610:192:38 mightThrow@https://commons.wikimedia.beta.wmflabs.org/w/resources/lib/jquery/jquery.js?6a07d:3534:21 resolve/</process<@https://commons.wikimedia.beta.wmflabs.org/w/resources/lib/jquery/jquery.js?6a07d:3602:12 undefined Suggestion: Normalize the image title after every manual change.
  • T206831: Don't lose metadata if Upload Wizard "Describe" step is interrupted
    • Task
    Steps to reproduce the problem: 1. Upload 50 files 2. Choose license 3. Type the title, descriptions, categories, coordinates for 49 files (takes about 2 hours) 4. Two hours is enough to receive tens of messages requiring me to do other things in the browser and open various websites, also using heavy map websites to find coordinates, so after two hours the probability that the browser has crashed at least once is 50%. So, let's Assume your browser crashes (it is not a worst-case scenario, it happens often to me and just happened again right now after typing metadata for 30 files). Or maybe your OS forces you to restart, or there is a power shutdown (happens often too here). 5. Open your browser again 6. Expected: You can continue where you left. Actually: You have to start again from zero, and probably just give up. Upload Wizard should regularly save the typed metadata (and obviously the uploaded files too). Similar to https://phabricator.wikimedia.org/T113043 but that one is about being logged out, which is a more specific issue
  • T206830: Can't navigate Upload Wizard using keyboard
    • Task
    Many people prefer not using a mouse, some people even can't use a mouse. These people can not use the Upload Wizard, because the description language selection dropdown component breaks TAB key navigation. Steps to reproduce: 1. Drop a few pictures 2. Fill title 3. Try to navigate to description using TAB 4. The focus goes back to the top of the page
  • T205977: No thumbnail for TIFF upload
    • Task
    No thumbnail is created for TIFF files while uploading {F26276042}
  • T202508: Allow date prefilling in UploadWizard
    • Task
    When uploading many files without date tag, the ability to prefill the date is needed. See https://commons.wikimedia.org/wiki/Commons:Upload_Wizard/Fields_prefilling for the currently supported prefilled fields.
  • T200173: Add deletion log link to file-deleted-duplicate message
    • Task
    Commons would like to modify the system message, https://commons.wikimedia.org/wiki/MediaWiki:File-deleted-duplicate, to include a link to the deletion log for the file in question. However, certain files require the parser {{urlencode:...} to function properly. When added to the parser does not render and the system message breaks. Testing on the beta cluster, the message renders as: A file identical to this file ([[:$1]]) has previously been deleted. You should check that file's [https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Log/delete?type=delete&page={{urlencode:$1}} deletion history] before proceeding to re-upload it. If the parser could be fixed so we can update the system message to include the link it would be appreciated. We could also add the link from inside MediaWiki itself, so all wikis would benefit :)
  • T200085: Typing an existing Category name in UploadWizard now requires actively accepting the proposal
    • Task
    In the old upload wizard you could type something in the category line and if you just clicked anywhere outside the field you had you category automatically assigned. In this way you never missed any category. In the new one you must also press "enter" after you type. If you don't the text stays there, but no real category is actually assigned, the text is just ignored. As I was used to the first method for years, I am missing many categories I want to place. Can you please make it like before? (ask me if not clear) Thank you
  • T200076: 'Select a date' placeholder not vertically centered in UploadWizard
    • Task
    {F23923119}
  • T196449: Suggest master- and sub-categories when searching for a category in the UploadWizard (Wikimedia Commons)
    • Task
    When using the Wikimedia Commons mobile application this is already a thing, if you wish to add something to let's say "Skyscrapers in Colombia" it will automatically suggest "Skyscrapers in Bogota" and other sub-categories, many users are simply unaware of what the appropriate sub-category to place something in is as not everyone checks a category before they upload a medium and this will prevent a parent category from becoming "too populated".
  • T196448: Automatically redirect users to the correct category in the UploadWizard (Wikimedia Commons)
    • Task
    When you wish to upload something to Wikimedia Commons but aren't 100% familiar with the the appropriate name of the category you often get a list of categories based on what you search 🔍. However if you would add a category that's only a redirect the files you upload will end up in the redirect and will have to be moved either manually or automatically by a bot, let's say the category is called "Bridges in Brazil" but you add it to "Brazilian bridges" then the files end up in the latter category, one way for redirects to work better (and to actually be a benefit to the users rather than a sometimes confusing hassle) would be that even if you click on "Brazilian bridges" that the UploadWizard will then automatically "autocorrect" it as "Bridges in Brazil".
  • T194007: Don't warn about longitude so fast
    • Task
    The user starts typing the latitude. He then sees "The longitude must be a number between -180 and 180." Well gosh, we haven't even finished entering the latitude yet.
  • T191243: uploadwizard Vagrant has language selector broken
    • Task
    Steps: download and setup clean mw vagrant using the instructions on mww enable and provision uploadwizard role go to Special:UploadWizard and move up to the description step. See that only English language is in the languages selector. enable and provision mleb observe lack of change Expected behavior: it should provide all hundreds of languages available just as on Commons.
  • T190883: Make UploadWizard set HTTPS links for source/author metadata fields for images imported from Flickr
    • Task
    UploadWizard gives the option of uploading via Flickr link. When producing the output for the information box, it would be more efficient for it to force the links for source/author etc. to be HTTPS, instead of KolbertBot doing it after the fact : https://commons.wikimedia.org/w/index.php?title=File:March_for_Our_Lives_24_March_2018_in_Philadelphia,_Pennsylvania_-_028.jpg&diff=prev&oldid=293965447 .
  • T190258: Bug: upload button on edit toolbar only allows images with $wgStrictFileExtensions = false
    • Task
    Even if $wgStrictFileExtensions = false, upload button on edit toolbar only allows images, **Latest version reproduced:** MediaWiki core 1.31.0-alpha [(52aeaa7)](https://gerrit.wikimedia.org/g/mediawiki/core/+/52aeaa7a5fb0c233caa9f7815882f7a99cf4ece3) WikiEditor 0.5.1 [(8f6a390)](https://gerrit.wikimedia.org/g/mediawiki/extensions/WikiEditor/+/8f6a39059e52ed6a87b34343de3d176bcdc7c4db) **Steps to reproduce:** # In FTP, add following lines to LocalSettings.php and save ``` wfLoadExtension( 'WikiEditor' ); $wgStrictFileExtensions = false; ``` # Log into Wiki. # Go to Special:Upload page. # Confirm i can upload a .txt file. Works no problem. # Enter source edit-mode on a page. # Click "Embedded File" button in toolbar. # Click "Upload" button in popup. # Select a .txt file. # Check on "This is my own work". # Click "Upload". # Enter description. # Click "Save". # Receive error > Unknown warning: "{"upload":{"result":"Warning","warnings":{"**filetype-unwanted-type":["txt"**,"png, gif, jpg, jpeg, webp",5]},"filekey":"15m9ibdt6718.9j6h2t.1.txt","sessionkey":"15m9ibdt6718.9j6h2t.1.txt"}}"."
  • T189420: Accept combined lat/long coordinates
    • Task
    The Upload Wizard prompts you to enter lat and long in two boxes. It is often more convenient to enter them as a single piece of text formatted as lat/long, because you can copy-paste that directly out of a URL for most mapping applications. Examples: - https://www.google.com/maps/@42.0361168,-70.1720344,15z - https://www.openstreetmap.org/relation/2387634#map=15/42.0345/-70.1821 It would be really nice if you could paste the full mapping application URL and have the relevant data items parsed directly from that.
  • T188805: handle timezones in upload wizard
    • Task
    Set a UTC+11 (Australia/Sydney) time zone on commons. Try to upload an image. UploadWizard complains, the date you are trying to set it in the future'. This happens frequently, as often I indicate a today date for my uploads (perhaps whenever it is more than 11AM in my area? I am not sure what exactly is the time of day when this bug occurs, but this is my hypothesis). But I'd prefer it to - show my timezone - show my current time - allow me to choose the date in my timezone This way we would - ensure that the user has set their timezone correctly and is indicating the date in the correct time zone, and - have a chance to convert the date from the user's time zone to UTC or whatever standard the date is stored in. ----- **See Also:** {T42727}
  • T187356: UploadWizard does not handle correctly warning-only abuse filters for multiple uploads
    • Task
    Upload some (>1) files that will cause the commons Abuse Filter to throw an error, for instance by adding an OTRS ticket without being in the OTRS group. A warning is displayed for each file, which indicates that the user can click "Submit" again in order to ignore the warning. However, when submitting again, only 1 (random?) upload is successful, the rest fail with the same error. In total, for n images, one has to click the submit button n+1 times. For large number of files, this becomes tedious.
  • T186427: Special:UploadWizard Campaigns broken when EventLogging extension is not enabled
    • Task
    When trying to save a Campaign page on REL1_30 I am getting an error. PHP Fatal error: Class 'EventLogging' not found in .../extensions/UploadWizard/includes/CampaignContent.php on line 49 See T143092.
  • T184286: [UploadWizard] Access the licensing tutorial without enable $wgUseInstantCommons
    • Task
    Can we access the licensing tutorial without enabling $wgUseInstantCommons? If not, can we develop other ways to access it?
  • T179884: Files occasionally getting uploaded to Commons without file pages.
    • Task
    Recently, I've noticed (via a bot that I run) some files that have somehow been uploaded to Commons without the creation of corresponding file pages. The first was uploaded on Nov. 1, and I've since found 4 more. Some of the file pages have been created manually, but you can see in the dates that the files were uploaded earlier, by a different user. Here's a list of the files in time order: https://commons.wikimedia.org/wiki/File:17slemdal_efn.jpg https://commons.wikimedia.org/wiki/File:Stortinget2017efn.jpg https://commons.wikimedia.org/wiki/File:Mjstuen2017efn.jpg https://commons.wikimedia.org/wiki/File:DWCSJ_Hymn.wav https://commons.wikimedia.org/wiki/File:Ahora_nos_toca_a_nosotros,_ovaci%C3%B3n.jpg
  • T178549: "Copy information to all following" should be available for all pictures, not just the first
    • Task
    {F10307630} When people upload dozens of pictures, they are not in random order: The topic (and thus title/categories) moves slowly from one topic/place to another. Example after walking along the Seine river: 3 pictures of Notre Dame, then 4 pictures of Louvre, then 5 pictures of Eiffel Tower. Ideally I would upload these 12 pictures like this in Upload Wizard: 1. For the first picture, enter title "View of Notre Dame while walking along the Seine", and categories "Notre Dame" and "Seine". 2. Press "Copy information to all following". 3. For the fourth picture, change "Notre Dame" to "Louvre" in the title, remove the "Notre Dame" category, add the "Louvre" category. 4. Press "Copy information to all following". 5. For the eighth picture, change "Louvre" to "Eiffel Tower" in the title, remove the "Louvre" category, add the "Eiffel Tower" category. 6. Press "Copy information to all following", and you're done. That's 7 typing operations to perform. Currently, to achieve the same with the Upload Wizard I have to perform 21 typing operations. Both Vicuña and the Android Commons app have this feature. The Upload Wizard should have it too. Thanks!
  • T178546: Upload Wizard Describe step: Let me check in a popup the picture that I need to describe
    • Task
    When uploading a series of picture, at the "Describe" step I am asked to enter description and categories for each picture. It is very inconvenient that I can not zoom into each picture to see the details. With only a tiny thumbnail and a filename like DSCF1234, I can't remember exactly what that picture was about. Having to go back to the filesystem and find the exact picture that I had selected in very time-wasting and inconvenient. I should be able to click on the thumbnail to get a large preview popup, ideally with zoom ability. You could argue that I should remember what I selected for upload, but when uploading 50 post stamps it is impossible to remember each one's details just by their thumbnail.
  • T177689: UploadWizard doesn't enable to add information into Source field of Information template
    • Task
    The UploadWizard interface doesn't enable to put additional information into the "source" field of "Information" template. Such information can be a source identifier of the image, tags of grants, projects and used devices etc. This fault causes that images uploaded by UploadWizard have chaotic and unordered description pages.
  • T177687: The Category field of UploadWizard doesn't enable to go through the category tree up and down
    • Task
    UploadWizard lacks a function similar to HotCat to enable to go through the category tree up and down (↓), (↑). That causes that uploaders use categories as keywords instead as structured categorization system and cannot find appropriate categories easily.
  • T177685: The link "Add location and more information..." of UploadWizard shatters the description information.
    • Task
    The link "Add location and more information..." enables and seduces uploaders to put part of description outside the "Information" template and shatter the description information.
  • T177161: Please remove Custom License Marker from Commons Upload Wizard
    • Task
    The proposal and consensus for this request are documented in section https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2017/07#Purpose_of_Template:Custom_license_marker
  • T174914: UploadCampaign sometimes use old autoAdd configuration
    • Task
    (This can appear similar to T173642 but is distinct) The [[ https://commons.wikimedia.org/wiki/Campaign:wlm-fr | wlm-fr UploadCampaign]] was rigged to `autoAdd` the category "Images from Wiki Loves Monuments 2017 in France − early" ; this was changed on August 31st to autoAdd " "Images from Wiki Loves Monuments 2017 in France to check" − see [[ https://commons.wikimedia.org/wiki/Special:Diff/257024815 | Diff/257024815 ]]. However it has been reported that the Wizard sometimes sends uploads to the old category. See eg [[ https://commons.wikimedia.org/w/index.php?title=File:Mus%C3%A9e_Saint-Raymond_-_2017-09-02_-_4629.jpg&oldid=257543145 | this file uploaded on September 4 ]]. According to one of the organisers, this happens ~20 times a day.
  • T174757: UploadWizard does not show the field for entering a custom license tag when the uploader declares it's his own work
    • Task
    Screenshot is easier to understand than text, so screenshot first. |"own"|"not own"| |----|----| |{F9261781}|{F9261792}| (Obscured URL: [[https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=ko|this for not own]], [[https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wlm-kr|this for own]].) When you select "This file is my own work.", then you select "The license is described by the following wikitext (must contain a valid copyright tag):", no wikitext box appears. However, when you select "This file is not my own work.", then "Another reason not mentioned above", the correct wikitext box appears.
  • T173683: Special:UploadWizard without JS is misleading to the user
    • Task
    When you access Special:UploadWizard with JS turned off, you're still confronted with the link: “Try the Upload Wizard instead” After this comes long Commons introduction and not earlier than that, user sees message “Your browser is not compatible with UploadWizard or has JavaScript turned off, so we are showing you a simple upload form. (View compatibility requirements.)” {F9137907} Expected result: Last message should come first and “Try” link not visible to user at all when JavaScript is turned off.
  • T173642: UploadWizard campaigns showing cached template output
    • Task
    WLM campaigns in Wikimedia Commons use the data embedded on Template:WLM-is-running for switching its headerLabel See for instance https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-es&action=edit A couple of days ago I edited this template so it no longer showed the competitions as closed: https://commons.wikimedia.org/w/index.php?title=Template:WLM-is-running&diff=255698896&oldid=253210886 However, for the languages where it was viewed, the old output ("Wiki Loves Monuments 2017 is closed.") is still shown: https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wlm-es&uselang=en whereas if you provide a language that had not been viewed, the correct output ("Wiki Loves Monuments 2017 has not started yet.") is provided: https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wlm-es&uselang=asdf Adding &action=purge to either the Campaign page or the Special:UploadWizard url does not work. However, it can be fixed with a null edit to the Campaign page. This //might// be just a matter of the job queue not having yet processed the campaign page. The job queue has been growing since August 7th. But reading the [job wait time](https://grafana.wikimedia.org/dashboard/db/job-queue-health?refresh=1m&panelId=7&fullscreen&orgId=1&var-jobType=refreshLinks&var-jobType=refreshLinksDynamic&var-jobType=refreshLinksPrioritized), I would have expected it to have been processed by now (for refreshLinks jobs, the 95th percentile is 7 hours, although the 99th percentile goes up to 2 days). However, given that it is showed in the interface, it may //not// be a typical job queue delay. Links: [job count](https://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=statistics), [job queue health](https://grafana.wikimedia.org/dashboard/db/job-queue-health?refresh=1m&orgId=1), [job queue rate](https://grafana.wikimedia.org/dashboard/db/job-queue-rate?orgId=1)
  • T172219: Many languages names in UploadWizard are not translated to Ukrainian
    • Task
    Many languages names in UploadWizard are not translated to Ukrainian. {F8926388} Originally reported at https://commons.wikimedia.org/wiki/Commons:Help_desk#Translations_of_languages_names_in_Upload_Wizard by @Tohaomg
  • T166025: Enable AAC-LC support for Commons uploads and TMH/etc. playback (not patent-encumbered anymore since 2018)
    • Task
    Part of the MPEG-2 Part 7 Standard (1997) which is likely to be patent free in 2018. T166024 It enjoy a wide industry and hardware support. **What about HE-AAC** This format adds backwards compatible features to the AAC encoder for [[https://developer.apple.com/library/content/technotes/tn2236/_index.html|supporting low bit-rates]]. HE-AAC is typically used for bit-rates 32–80 kbps and HE-AAC v2 for 16–40 kbps.
  • T163382: Category creation during upload, using the UploadWizard
    • Task
    Would it be possible to create the category when uploading with the wizard? This would be helpful for books and for their images to be used on Wikisource.
  • T158605: upload wizard adds {{location}} instead of {{object location}} templates
    • Task
    We need a mechanism to pass **object location** via url-parameter to the UW. How can this be achieved? Object location are given in many lists - camera location cannot be given for unknown images! There are some known workarounds (bots adding object location as extracted from the lists): * Erfgoedbot adds object location to images assigned to WLM lists objects async (see T72437) * Krdbot does the same for images in Austrian WLM lists objects. (kind of duplicate work for the Austrian monument lists in the WP:de) But this does not cover all the lists. example lists not covered: * https://de.wikipedia.org/wiki/Liste_der_Naturdenkm%C3%A4ler_in_Wien/Mariahilf * https://de.wikipedia.org/wiki/Liste_der_Wiener_Gemeindebauten/Mariahilf * https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_öffentlichen_Raum_in_Wien/Mariahilf … (see the small camera icon = tailored upload button, taking coordinates from template args Breitengrad & Längengrad (= object location)) Passing object location via url-parameters lat & lon does not work: * these are overwritten by Exif location (and thus get lost) * if there is no exif location, lat & lon end in the location template, which is wrong I tried a bit to pass object location differently: https://commons.wikimedia.org/wiki/Campaign:at-Wiener-Wohnen and https://de.wikipedia.org/wiki/Vorlage:Gemeindebau_Wien_Tabellenzeile (using the UW acc. to the former campaign) passing the object location is clumsy and it is put to a less optimal position inside the information template (should be below). I did not manage to put it after the information template with given UW parameters. So what would be the proper solution (in case of lists like WLM): object location can be passed by URL-parameters camera location can be extracted from Exif data (or eventually given during upload?) Both locations might be missing independently. To not break the interface, I propose to add another set of lat / lon for object location and change the UW urls in the list templates accordingly.
  • T157319: Implement replacement for Firefogg (on-the-fly video transcoding)
    • Task
    For policy reasons, Wikimedia Commons doesn't want to host videos using proprietary file formats, like MP4 (https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video). UploadWizard used to use the Firefogg extension (https://firefogg.org/) for on-the-fly transcoding of MP4 files to OGG in the user's browser. But due to changes to how Firefox handles extensions, this is soon to stop working (https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/) and it seems already impossible to install the extension. With modern browsers' fast JavaScript engines and HTML5 file APIs, it should totally be possible to implement transcoding in JavaScript, without shelling out to external executables, like Firefogg did. As a bonus, that would work on more browsers than Firefox.
  • T156255: upload wizard hangs up when provided URL for flicker "tag"
    • Task
    I wanted to upload free images of Grey Dagger Moth Caterpillar so I pasted into upload wizard https://www.flickr.com/photos/tags/greydaggermothcaterpillar URL. The Wizard started showing rotating circle and never recovered. There are only 36 images using this tag and some are under free license.
  • T154193: Extend "copy information to all uploads following"
    • Task
    "Describe" stage in UploadWizard has an option "Copy information to all uploads following..." and clicking it allows you to copy descriptions, categories and other metadata used in the first file to all the other uploads. **When copying categories or descriptions the copied text should not erase existing text**. In case of copying categories they should be added to already inserted categories. Similarly when copying description the copied text should not erase existing one, but should be merged, or maybe if the script detects that some descriptions are already filled it could give you an option of append / prepend or replace existing text. In my case I was uploading files from Flickr and the image description always shows up as title, which is fine but I need to copy them to description field. The easiest way to do it is to prepend {{subst:PAGENAME}} to description field, which at the moment has to be done by hand. In other cases all images in the flickr album are related to a specific place and descriptions only make sense in the context of that place so I need to add first sentence explaining the location. I also think the name of the section should be just "Copy information to all uploads ...".
  • T154192: Improve display of thumbnails of images to be uploaded
    • Task
    When uploading files from a directory or Flickr album with large number of files (like [[ https://www.flickr.com/photos/52450054@N04/albums/72157626817701004 | this one ]]) it is hard to keep track of where you are in the list, what was already uploaded and what still needs to be. Current upload form allows 50 uploads at a time so I would propose to place a vertical line separating batches of 50 files on the page, maybe even with numbers: 50, 100, 150, etc. Alternative approach would be to just place a number next to each icon. If number of uploads is raised as suggested in T135085. I would still keep either the numbers or dividers every 50 or 100 files.
  • T154149: Upload Wizard: Add "This file was found on the net." as a third option to "own work" and "not own work"
    • Task
    "Own work" should not be pre-selected in the Upload Wizard and potentially other upload tools. We get lots of copyright violations that are marked as "own work" at Commons. This makes it easy to just "click through" the Wizard, without bothering to think about this issue. Selecting "own work" should always be a conscious choice. Additionally, since by far the most common copyright violation is grabbing an image from the web, I'd propose to add "This file was found on the net." as a third option to "own work" and "not own work" with additional guidance for those cases.
  • T149935: [UploadWizard] Allow upload of videos from flickr
    • Task
    UploadWizard allows upload of files from flickr and is available to authorized users as described in T77278. Unfortunately it does not work for videos like [[ https://www.flickr.com/photos/miamism/6035076567/in/photolist-5cK8Ti-4FMbYb-acim1g-6LDzdF-6egUau-7UFgj2-drtyc5-dhCafB-8Hno6r-dhBibE-dhBob8-9rVxpj-ad46sZ-9rVvc1-dhDqE5-7NFNGJ-9qdYca-sYD3yU-dhBmNw-dhC6j8-dhBmqU-dhEqHG-6C7Lyy-73SJB7-6VfskW-N5KAXP-LKevpj-MfHxtq-MwDQWL-rww75K | this file]].
  • T148447: Make UploadWizard locally configurable
    • Task
    Make it possible to customize UploadWizard locally. This includes the information collected (e.g., {T6647}) and decisions trees (e.g., if the answer to "is this a photograph?" is yes, then information about where the photo was taken could be requested).
  • T147811: Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget
    • Task
    We currently have two different widgets for editing a list of categories, with different but largely overlapping functionalities. We should only have one. `ve.ui.MWCategoryWidget` is used by VisualEditor, in the Page options → Categories dialog. `mw.widgets.CategorySelector` is used by UploadWizard on the "Describe" step, and in the file upload dialog (`mw.ForeignStructuredUpload.BookletLayout`, which is used by VisualEditor and WikiEditor). || `mw.widgets.CategorySelector` | `ve.ui.MWCategoryWidget` | |---|---|---| |Screenshot| {F4582307} | {F4582298} | |Widgets used|`CapsuleMultiSelectWidget`|`ButtonWidgets`+`TextInputWidget`+`Popup`| |API|action=opensearch|action=query/allcategories| |Can set sort key for category|{icon times color=red}|{icon check color=green}| |Can reorder categories|{icon times color=red} (requested {T108490})|{icon check color=green}| |Can edit (not just delete)|{icon check color=green}|{icon times color=red} (requested {T67518})| |Can view category page|{icon check color=green}|{icon times color=red} (requested {T56656})| |Cross-wiki|{icon bomb color=green, spin} (hacky)|{icon times color=red}|
  • T146932: Add "Jump to first error/warning" buttons on the "Details" step
    • Task
    When there is a problem with the uploads, we display error/warning messages next to each field, and also a short summary at the bottom next to the "Next" button, like: * "There are 2 errors with the form above. Correct the errors, and try submitting again." * "There is one warning with the form above. We recommend correcting it before continuing." Clicking "Next" will also scroll up to the location of the top-most error or warning. This is somewhat annoying and not very helpful, since it doesn't put focus on the field, and in case of warnings there's a message box popping up that obscures everything. So I think we should remove the current scrolling behavior, and instead add buttons like "Jump to first error" and Jump to first warning" after these summaries. Clicking them would scroll up and focus the problematic field. Screenshot for reference: {F4534070}
Prev
1
2
3
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL