Hello!
When I use the UploadWizard extension on my MediaWiki, I get an error and it cannot be used. As shown in the picture
{F48791417}
But when I switch the language to English, it works fine. Is it a bug or my problem? Thanks!
MediaWiki version 1.41.1
PHP version 8.1.28
Upload Wizard version 1.5.0 (0451b49)
Do a quick analysis of DRs/speedy deletions on images because they're logos that are marked as "own work"
We can count an image as a logo if it's in Category:Logos or its subcats **or** if it was deleted and its DR or deletion reason message mentions logo
Let's look at all logos uploaded within the last year, and see if the ones marked as "own work" are more likely to have gotten deleted. It might be a little tricky to tell if deleted images have the `{{own}}` template because templatelinks are deleted when an image is archived - probably will have to look in the wikitext
When the user selects licence options in UploadWizard these are stored as templates, and then later a bot comes along, reads the templates, and add structured data
It'd make more sense to just add the structured data directly from UW, especially now that we're actively updating it
**Steps to replicate the issue** (include links if applicable):
* When someone upload files to Commons from Flickr licensed PDM via Upload Wizard the wizard use the license {{Cc-zero}}. Example https://commons.wikimedia.org/wiki/File:Protecting_U.S._Ambassador_Linda_Thomas-Greenfield.jpg from https://www.flickr.com/photos/statedeptdss/53575696138/
**What happens?**:
* The result is Flickrreview fail and file end in https://commons.wikimedia.org/wiki/Category:Flickr_public_domain_images_needing_human_review and humans have to fix the license and review the files
**What should have happened instead?**:
* Uploader should be asked to chose a license. If uploader think that Flickr user is the photographer it should be possible to chose {{PD-author-FlickrPDM}}. It would also be great if the uploader could chose another PD license tags like {{PD-old-70}} or {{PD-USGov}}.
**Other information** (browser name/version, screenshots, etc.):
* Reported at https://commons.wikimedia.org/wiki/Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements#Uploading_files_from_Flickr_with_PDM
**Feature summary**:
Currently the homeButton defined in UploadWizard campaigns only allows links to pages on the same wiki (in most cases Commons). It should be possible to link to other Wikis (or even external pages) too.
**Use case(s)**:
This is useful for photo contests where the main page of the contest is on Wikipedia and not on Commons.
**Benefits**:
Having a link to the contest page would help the new users participating at the Wiki Loves contests to navigate back to the origin page.
We'll need to
* create an implementation of the [[ https://apiumhub.com/tech-blog-barcelona/introduction-perceptual-hashes-measuring-similarity/ | pHash ]] algorithm that can be run inside MediaWiki (or find an open source implementation we can use)
* run this for all existing images, and store the hashes
* create a new hash and store it for every new upload
The above is covered by T167947, and will allow the community to create tools to find duplicates.
If we also gathered **deleted** images and generated and stored hashes for those this would be even more useful. Storing hashes for images on other wikis would be useful too - if those images are fair-use then they're likely to be copyrighted
Once that's done we'll need to also generate the hash for stashed uploads in UW, and match that against existing stored hashes, and alert the user if there's a match (and warn them if that match has already been deleted)
---
Some implementation details
* Trying to figure out how to store hashes that can be searched based on hamming distance is what made a previous version of this run aground (see T121797). According to [[ https://commons.wikimedia.org/wiki/User:F%C3%A6/Imagehash | User:Fæ ]]'s work on this we'll catch ~90% of duplicates just checking for identical hashes, so let's just check for identical hashes
* ~~We can possibly store the hashes in a mysql table with a flag to indicate if the original image has been deleted (that gets updated when the image is deleted/undeleted)~~
** Ideally we'd store the pHash in the new `file` table, see T28741
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
As part of this ticket we will be making some improvements to the date of creation field such as simplifying the input, using EXIF data as a starting point and provide guidance to the user.
=====[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2913-30060&mode=design&t=Byy2kCQ15DsgVEgc-4 | Link to UI ]]
[] Replace the grouped button with a single button to access the calendar as shown in the UI
[] If the file is ‘own work’ and has a date in the EXIF show that date in the date field by default with a message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2919-24030&mode=design&t=Byy2kCQ15DsgVEgc-4 | here ]]
[] If the file is ‘not own work’ do not use the date in EXIF to pre-fill the date field
[] Tapping on calendar icon shows the existing calendar widget where users will be able to choose a date
[] If the user picks a date in the future show the error message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2919-24798&mode=design&t=Byy2kCQ15DsgVEgc-4 | here ]]
[] Allow users to enter their own date or time period in the input box.
[] If the user starts typing in the input box first (before clicking on the calendar icon) show the message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2919-24392&mode=design&t=Byy2kCQ15DsgVEgc-4 | here ]]
[] If the user choses a date from the calendar widget remove the above message and replace the previously the previously typed input with date selected.
[] If the user proceeds without entering the date show the error message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2919-25170&mode=design&t=Byy2kCQ15DsgVEgc-4 | here ]]
[] Attempt to automatically convert the entered date into a format suitable for structured data. If that conversion fails, only include the date in the wikitext.
**Steps to replicate the issue** (include links if applicable):
* On your cell phone, upload a file to Commons. In fact make it a big long file that takes several minutes.
* Watch the spinner spinning, as you wonder if this upload will ever complete.
* With nothing else to do that evening, casually scroll further down on the Upload form.
**What happens?**:
Lo and behold, we discover a progress bar there at the bottom that we didn't know about all this time while we were waiting.
**What should have happened instead?**:
Well if the progress bar had been back near the top near the spinner, then we wouldn't have ever started scratching our heads wondering what was going on.
You see a cell phone has a limited view so you need to group important things together.
{F43737687}
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The current category field has many problems:
- It is difficult for users to think of categories
- It is difficult for users to understand the type of categories to enter i.e. higher level vs lower level
- It is difficult for users to find the right category to put their work in as different people may word their categories differently
- It is added work for community to correct the categories entered by users and put it in the correct tree structure
This ticket is to come up with solutions that might help solve some of the problems above.
A few ideas:
- Consider exposing category tree to the user so that it is easier to select the most specific category. [[ https://commons.wikimedia.org/wiki/Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements?useskin=vector-2022#Is_there_anything_else_you_would_like_to_see_improved_/_added_/_removed_in_UploadWizard?_If_so,_why? | (mentioned in community discussions) ]]
- Consider making it a structured task for after media is uploaded where more help can be provided
- Evaluate if using depicts to automatically arrive at categories or autosuggest categories is possible without compromising quality [[ https://commons.wikimedia.org/wiki/Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements/Archive2?useskin=vector-2022#Categories | (mentioned in community discussions) ]]
- Only select from available categories
- UploadWizard should recognise when a category is a redirect to another T359805
- etc
This task is part of improving the describe step of the Upload Wizard on Commons T358765
- The most recent updates to form by design system suggest having next/prev buttons next to each other
- Improve the CC0 warning message on describe step above the next/prev button
This task is part of improving the describe step of the Upload Wizard on Commons T358765
This ticket is to update the "copy information" feature for multiple uploads so that it matches the updated fields and its names.
=====[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2750-35280&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]
[] Restyle the existing according and group it with "[[ https://phabricator.wikimedia.org/T361061 | other information ]]" field as shown in the UI
[] Update the label as shown in the UI
[] When the accordion is opened, reveal checkboxes for each field as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2750-37266&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] None of the checkboxes will be selected by default
[] Copy the information entered in the fields of checkboxes selected by users to rest of the uploads below it.
[] The copy option only shows for multiple uploads and only under the first upload on the page
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
"Other information" field on describe step is not very frequently used. This task is to make sure the presence of this field does not confuse new users but is still available for some experienced users who are currently using it for entering things like templates.
===== [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2750-34893&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]
[] Turn the other information field into an accordion (closed by default) as shown in the UI
[] Update the label and show the optional label as shown in the UI
[] Show this field below additional information
[] Reveal a multiline input field when the accordion is opened as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-32957&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
It was noticed in the user research that many users skip the current learn step in the upload wizard not fully understanding the scope of commons.
This ticket is to evaluate the need for the learn step in upload wizard and how might we make education part of the process rather than having users invest time in reading the material.
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
Describe step improvements also includes following the new form guidelines released by design systems team. This ticket is to make sure we apply those visual changes to release right step as well for cohesive visual experience in the upload wizard
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
**Background**
Adding creation/published data of the work is currently part of the describe step. However, it fits better under release rights step rather than describe step in terms of the type of information that is being asked. The proposal is to move the creation/published data field to the release right step so that we can keep describe step more focused on describing the work itself.
- Remove the date created/published field from the describe step
- On own work flow this will be a new question on the page
- On someone else's work flow this question will replace the recently added confirmation checkbox stating the user is not violating any copyright. (We plan to add other ways of detecting copyright violations in the future that are more effective.)
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
In order to simplify the number of steps in the upload wizard we will removing "additional data" as an explicit step in the upload wizard and make the field available in a simplified way on the describe step.
===== [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2741-26996&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]
[] Remove "Additional data" step from upload wizard navigation/breadcrumb
[] Add the "Additional information" label and label description as shown in the UI (the "Additional information" section will be under the date field until it is moved to release right step)
[] Move the depicts field to describe step under the "Additional information" grouping as shown in the design
[] Add the label for the depicts input field as shown in the design
[] Show the optional label next to the depicts field label. Users can proceed without entering depicts.
[] Add the search input field with an example as shown in the design
[] Allow users to select from an autocomplete list of depicts while entering
[] When the user hits enter after typing or selects a depicts from drop down, the depict chip will be added inside the text box as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2726-30885&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Depicts can be removed by clicking on the cross on the chips
[] Show the informational warning as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-14953&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]] when users enter more than 3 depicts
[] Hide this warning if the user brings the number of depicts down to 3 or less by removing them
[] Add "copy main subjects" to the existing copy feature for multiple uploads
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
The location information for the media can be useful for determining FOP issues and also provide valuable metadata for the the media
The location field currently has a few problems:
- It is not easily discoverable
- Users may not be made aware that the co-ordinates from their camera are automatically added to location field since the field is not easy to discover, robbing them of a chance to remove the information if they wish to do so.
- The current UI asks for co-ordinates which can be a difficult for users to enter a location
The following changes aim to make the field more discoverable and easy to use.
=====[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2741-27306&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]
[] Remove the existing location field
[] Add the "Additional information" label and label description as shown in the UI (the "Additional information" section will be under the date field until it is moved to release right step)
[] Add the new location field under the "Additional information" grouping as shown in the design
[] Add the label for the location input field as shown in the design
[] Show the optional label next to the location field label. Users can proceed without entering location.
[] Add the search input field with an example as shown in the design
[] Allow users to select from an autocomplete list of location while entering in the input box
[] When the user selects a location from a drop down, the location map will be added as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-30423&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Show the location name above the map
[] Users can zoom in or zoom out and drop/move the pin on the map
[] Users can delete the location with the delete button as shown in the design which will update the location name above the map to the chosen co-ordinates
[] If the location information exists in the EXIF data then pre-load the location map and the info as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-29116&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Show the co-ordinates above the map
[] Show the copy next to co-ordinates indicating where we got these details from
[] Users can zoom in or zoom out and drop/move the pin on the map which will update the co-ordinates information above it
[] Users can delete the location with the delete button as shown in the design
This task is part of improving the describe step of the Upload Wizard on Commons T358765.
As part of this ticket we will be making some improvements to the way category field and its input is displayed. Further improvements are captured in T361149 which will require community consultation.
===== [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2747-27616&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]
[] Add the "Additional information" label and label description as shown in the UI (the "Additional information" section will be under the date field until it is moved to release right step)
[] Move the categories field under the "Additional information" grouping as shown in the design
[] Add the label and label description for the categories input field as shown in the design
[] Show the optional label next to the category field label. Users can proceed without entering categories.
[] Add the search input field with an example as shown in the design
[] Allow users to select category from an autocomplete list of categories
[] Users can create new categories by hitting enter after they finish typing
[] When the user hits enter after typing or selects a category from drop down, the category will be added as row below the input as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-31207&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Existing categories have a blue link that users can click on to view the category page
[] When user enters a non-existing category show the category in red as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2748-27927&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Non-existing categories have red link that users can click on which allows users to enter description
[] When the user enters a non-existing category show the warning message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2748-27927&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Categories can be removed by clicking on the delete button
This task is part of improving the describe step of the Upload Wizard on Commons T358765. Refer to overall design discovery and design goals in this ticket T358614
In order to simplify the information that users need to fill out describe step, the following changes to the UI are proposed
- **Visual improvements:** Improve the overall layout by following new styling and spacing for the form and its fields
- **Copy improvements:** Changing headers and helper text for each of the field
- **Required field:** Making caption a required field
- **Changes to description field:** Adding an option for users to copy their caption to description
=====
**Title**
**[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2702-56529&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]**
[] Update the label for the title field from image title to title
[] Remove the label description from the title field
[] Show a single line input box
[] Do not show any error message on load of the page. Error messages will only be shown when the user proceeds without entering required input.
[] Update the copy for the current error message for when the title is not unique as show [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2724-2419&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] If the user proceeds without a title show the error as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2726-28911&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
[] Update the copy for the current error message for when the user has not entered a descriptive title as show [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2724-20478&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]].
[] Update the copy on the "view example" dialog as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2727-27686&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
**Caption**
**[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2741-25494&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]**
[] Make the caption field a required field. Remove the optional label
[] Update the label description to the following copy: "One-line explanation"
[] Have the language selector take the full width of the input box
[] Remove the delete icon for the first caption
[] Show the delete icon for all the subsequent language captions that users adds as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2724-22543&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Show a single line caption input box
[] If the user proceeds without entering a caption show an error message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2724-23632&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
**Description**
**[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2741-25804&mode=design&t=JqnF0FEUMSUZuyUa-4| Link to UI ]]**
[] Description remains a required field
[] Update the label description to the following copy: "We recommend providing detailed information on this work if you can"
[] Automatically copy caption to description by default unless the "same as caption" box is unchecked
[] Hide the description input box and show "same as caption" checkbox selected by default as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2702-56529&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] When the "same as caption" checkbox is unselected, reveal the description blank input box as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2726-29868&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Remove the delete icon for the first caption
[] Show the delete icon for all the subsequent language descriptions that users adds as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2741-26114&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
[] Show a multi line description input box ~~with the ability for the user to expand the input box using a corner handle.~~ Keep the current functionality of it auto expanding as one needs more space.
[] If the user proceeds without entering a description show an error message as shown [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2726-30522&mode=design&t=JqnF0FEUMSUZuyUa-4 | here ]]
This task is part of improving the describe step of the Upload Wizard on Commons T358765
In order to simplify the number of steps in the upload wizard we will removing "use" as an explicit step in the upload wizard and rather make it a confirmation page after the upload is published with some changes to the layout of the page.
===== **[[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2734-19359&mode=design&t=JqnF0FEUMSUZuyUa-4 | Link to UI ]]**
[] Remove "use" step from the upload wizard breadcrumb and instead show as a confirmation page after the upload is published
[] Update the thank you message as shown in the [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2734-19359&mode=design&t=JqnF0FEUMSUZuyUa-4 | design ]]
[] Make some minor adjustments to the layout such as left aligning the image title link with the image and reducing the width of text boxes.
[] The available links and copy features on the confirmation page stay as they are
[] Multiple uploads [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=2739-19552&mode=design&t=JqnF0FEUMSUZuyUa-4 | design ]]
**problem**
# fill out the title. when i use my phone, phone input automatically leaves a whitespace after a word. if i dont remove that trailing whitespace...
# use the "copy to all" function. titles are autonumbered like
```
File:Title 01.jpg
```
there will now be 2 whitespaces. 1 is the trailing left by my input. 1 is inserted by uploadwizard.
**solution**
remove all trailing whitespaces, half-width or full-width, before "copy to all" the title.
**Steps to replicate the issue** (include links if applicable):
* I upload a file batch, choosing all necessary choices
* I then move to upload a second file batch, without closing my browser window, through the "upload more files" option
**What happens?**:
UploadWizard doesn't remember any more my "release rights" decisions, while it did in the past.
**What should have happened instead?**:
UploadWizard should have remembered the licenses choices I made during the first batch upload, avoiding me to re-click the same choices.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
Existing version on Wikimedia Commons.
**Other information** (browser name/version, screenshots, etc.):
Reformulated from [[https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback#Release_rights_resetted_for_every_upload | this discussion on Commons]].
**Feature summary** (what you would like to be able to do and where):
It would be nice to have a publish button near the function to copy the descriptions to all uploaded files. This would make the complete scrolling down the list redundant, which takes minutes with 500 files, if not needed if you only want to publish the files.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
**Benefits** (why should this be implemented?):
It saves time, if you want to upload a lot of files, where individual descriptions are not needed, and saves resources of the uploader
**Screencast**
{F42571353}
**Steps to replicate the issue** (include links if applicable):
* Go to https://commons.wikimedia.org/wiki/Special:UploadWizard
* Select any media to upload
* Click Continue
* Click "This is my own work"
* Click "I generated this work using an artificial intelligence tool"
* Type anything
* Try to put the caret to the middle of what you typed
**What happens?**:
The caret doesn't change its position.
**What should have happened instead?**:
It should.
**Other information** (browser name/version, screenshots, etc.):
Chrome, Firefox.
**My investigation**:
Since I'm developing a similar upload functionality for #convenient-discussions, I decided to dig into this.
The bad behavior comes from [OO.ui.SelectWidget.prototype.onMouseDown](https://phabricator.wikimedia.org/diffusion/EUWI/browse/master/resources/deed/uw.deed.OwnWork.js;c3742faf0c5c99a6330b17479c06563f14691dde?as=source) which prevents clicks from propagating. Basically, if we do `this.$element.off( 'mousedown' )` in the constructor of [OO.ui.RadioSelectWidget](https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/src/widgets/RadioSelectWidget.js), everything would normalize, since option clicks would be handled by the [onFocus](https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/src/widgets/SelectWidget.js;27cbcb02ac222f258d798bb3002d324204fe1fc4$190?as=source) method instead. (I didn't find any differences in behavior or visual effects, but I won't vouch that nothing stopped working as it should.)
The only reason the input is even focusable at all is the workaround added by @mfossati (see the [code](https://phabricator.wikimedia.org/diffusion/EUWI/browse/master/resources/deed/uw.deed.OwnWork.js;c3742faf0c5c99a6330b17479c06563f14691dde$242?as=source)) with a comment "I have not fully figured out exactly why or what is the culprit, but it appears that some node is preventing clicks from propagating, and it's making it impossible to access this input by mouse".
In general, given RadioSelectWidget's treatment of mouse clicks, it doesn't seem to be designed for use with additional widgets inside its option widgets, and in UploadWizard you even have a nested radio select in there. So when I press and hold any radio button of the //nested// select, the outside radio button becomes active as well:
{F42570513}
(This should be because the `label` tag is used as `$element` for option widgets.)
Another problem here (which I'm too lazy to file a separate task for) is that text of the options is not selectable by the user. Interfering with standard capabilities provided by browsers is not good. I'll just state that this selection blocking comes from the [[https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/src/widgets/SelectWidget.js;27cbcb02ac222f258d798bb3002d324204fe1fc4$226?as=source|triggering of the focus event in OO.ui.SelectWidget.prototype.onFocus]] that @matmarex has introduced a long time ago. As soon as I change `$focusOwner` to `$()`, I can select text as normal. This focus event triggered on `$focusOwner` seems to prevent the browser from proceeding with selecting text.
**Related tasks**
T347755
**Feature summary** (what you would like to be able to do and where):
UploadWizard should recognise when a category is a redirect, maybe recognising when {{Category redirect}} is used, and automatically correct the category to the right one.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
RussBot does this moving currently and the time needed to complete the backlog is of 5 to 6 hours, while on en.wp the same task needs only 5-10 minutes.
**Benefits** (why should this be implemented?):
This will reduce the backlog of file needing to be moved to the correct category by several hundreds per week.
As part of the new designs for the "describe" step we were thinking of add a "what class of image is this?" question with options like "people", "nature", "buildings", etc
Users are already adding categories to their uploads, so perhaps we can use the categories they're already adding instead
The reason for doing this is we want to spot uploads that are more likely to be copyvios earlier in the process - either directly in UW itself, or by making them easier for admins to find
So a good first step would be to dig into historical DRs and deletions-without-DRs, and see if particular categories tend to cause problems. This won't be trivial, as `categorylinks` are not preserved for archived File pages, but we should be able to retrieve the data
**Description**
The goal of this project is to reduce badly uploaded media content on Commons by making improvements to the uploading process through Upload Wizard (UW). This would help reduce moderator burden further down the Commons funnel. See [[ https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wizard_Improvements?useskin=vector-2022 | project page ]].
As part of the upload wizard improvement project we released improvements to the Release rights step of the upload wizard - See T347298 for details.
The next step is to improve the Describe step of the upload wizard. Based on the Design discovery T358614, we will focus on:
* Redesign the Describe step so that uploaders can provide us with the relevant information on their uploads more easily.
* Reduce number of steps (where possible) so that users can publish the media in fewer steps.
This may not only enrich the information associated with media but also help moderators in assessing problematic media through all the information provided by the uploader.
* Provide contextual education to users about what media they can or cannot upload so that we can reduce the number of problematic uploads.
* Explore introducing questions that could help with further moderation of FOP.
**Use cases**
As a moderator, I want that uploads to Commons contain all necessary information for assessing problematic media in an easy way.
As a user, when uploading media through Upload Wizard on Commons,
I want to understand which details I am asked to add to my upload in an easy way,
I want to add all the necessary information,
So that it complies with Commons guidelines and so that it could be easily reusable in the ecosystem.
**Scope**
* Improve the Use step in the upload wizard T361045
* Improve the Depicts field interaction in the upload wizard T361053
* Improve the file name, caption, and description fields T361049
* Improve the Categories field interaction in the upload wizard T361050
* Improve the Location field interaction in the upload wizard T361052
* Add the date created/published question to the release rights step in upload wizard T361054
* Update the 'other information' field in upload wizard T361061
* Update the footer in upload wizard T361068
* Update the "copy information" feature in describe step for multiple uploads T361062
* [NTH] Restyle the release right step to match the improved describe step form T361055
**Out of scope of this project**
* Improvements of other parts of Upload Wizard on Commons
* Improvements of other parts of Commons
* Improvements of media upload process on other projects (Wikipedia visual editor and source editor)
* Implementation of algorithms for automatically flagging potential content on upload
**Steps to replicate the issue**:
* On `commons wmf.20`, go to Special:UploadWizard and start uploading an image from Flickr
**What happens?**:
* In **Add data** step the thumbnail image will not be displayed
The Console displays
`{code: 'uploadstash-file-not-found', html: 'Key "1aqwf8a6ymjc.gd6fp6.5275083." not found in stash.', module: 'query+stashimageinfo'}`
**What should have happened instead?**:
* In **Add data** step the thumbnail image should be displayed for image files from Flickr.
|Flickr image upload| non-Flickr image upload
|---|---
|{F42224629} |{F42224640}
T355248 sought to incorporate these on-wiki CSS overrides that make UW more responsive: https://commons.wikimedia.org/wiki/MediaWiki:Gadget-uploadWizardMobile.css
Many of those changes were adopted, some were slightly altered or implemented in a different manner.
AFAICT, none of these rules serve any purpose anymore, and only risk causing bugs (because those overrides are not part of UW, and as such are not easily discovered during development or testing), so they should be removed from Commons once T355248 is complete.
{F42065598}
Maybe it would be a good idea to allow people to (optionally) add license tags if they fill in this field. Currently, there is no difference between clicking on this and saying that a work is entirely your own, but ''why'' a photographed work is in the public domain varies from subject to subject. So there could be an OPTIONAL field where people can add license tags to explain why the work is (partially) free. These license tags can then appear at the bottom with a special field below the uploader's own license.
**Feature summary**:
When uploading files, pick the location from a map and/or by entering an address.
**Use case(s)**:
When uploading a file, add the location with more ease.
**Benefits**:
Currently the only way to add the location is by entering the latitude, longitude and heading. Most people wouldn't know these numbers and/or it takes significant effort to look them up. Because of that, adding the location is more likely to be skipped. For users that do invest the effort, it's not a good use of their time.
Perhaps https://geohack.toolforge.org/ can be used for this?
**Feature summary** (what you would like to be able to do and where):
When uploading an AI-generated media, it should be available to users the possibility of adding the prompt that was used in generating such media, since it's relevant metadata that would be lost and unrecoverable later. Ideally, this prompt should be recorded through the recently introduced {{Prompt}} template.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
All uploads of AI-generated media by Commons users.
**Benefits** (why should this be implemented?):
It would save important data to be had while uploading the media, such as the prompt used.
**Feature summary**:
Upload Campaigns should be able to define what questions of the "Release rights" step in the UploadWizard are shown. It should be possible to reduce this step to a simple confirmation that the file is released under the given license.
The selections of this section should also allow prefilling through URL parameters.
**Use case(s)**:
Photo contests they are using the UploadWizard only allow own works and never had problems with not own works uploaded in the past. The question if it is the own work is therefore not necessary. Same for the question of the scope.
The prefilling is useful for cases where a dedicated campaign for every situation for every set of parameters in this section would be very inconvenient.
**Benefits**:
Make it easier for new users to upload photos without being asked so many questions and help Campaign organizers.
On page load
```
load.php?lang=en-gb&modules=ext.DarkMode%2CSimpleTooltip%2CcreatePage%2CdismissableSiteNotice%2CeventLogging%2Cpopups%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.embedVideo.overlay%7Cext.moderation.ajaxhook%2Cnotify%2Cve%7Cext.moderation.notify.desktop%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.urlShortener.toolbar%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2Ccookie%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cfeedback%2Chtmlform%2Cicon%2CjqueryMsg%2Clanguage%2CmessagePoster%2CsearchSuggest%2Cstorage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategoryMultiselectWidget%2CDateInputWidget%7Cmediawiki.widgets.DateInputWidget.styles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-accessibility%2Cicons-content%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-interactions%2Cicons-location%2Cicons-moderation%2Cicons-movement%7Cskins.vector.es6%2Cjs%7Cskins.vector.icons.js&skin=vector-2022&version=18ubh:164 jQuery.Deferred exception: Maximum call stack size exceeded RangeError: Maximum call stack size exceeded
at Map.get (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=startup&only=scripts&raw=1&skin=vector-2022:1:972)
at uw.SingleLanguageInputWidget.getDefaultLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:809)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:587)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:483)
at uw.SingleLanguageInputWidget.getDefaultLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:773)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:587)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:483)
at uw.SingleLanguageInputWidget.getDefaultLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:773)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:587)
at uw.SingleLanguageInputWidget.getClosestAllowedLanguage (https://jwmeeting.miraheze.org/w/load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:135:483) undefined
```
On clicking publish
```
load.php?lang=en-gb&modules=ext.DarkMode%2CSimpleTooltip%2CcreatePage%2CdismissableSiteNotice%2CeventLogging%2Cpopups%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.embedVideo.overlay%7Cext.moderation.ajaxhook%2Cnotify%2Cve%7Cext.moderation.notify.desktop%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.urlShortener.toolbar%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2Ccookie%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cfeedback%2Chtmlform%2Cicon%2CjqueryMsg%2Clanguage%2CmessagePoster%2CsearchSuggest%2Cstorage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategoryMultiselectWidget%2CDateInputWidget%7Cmediawiki.widgets.DateInputWidget.styles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-accessibility%2Cicons-content%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-interactions%2Cicons-location%2Cicons-moderation%2Cicons-movement%7Cskins.vector.es6%2Cjs%7Cskins.vector.icons.js&skin=vector-2022&version=18ubh:363 Uncaught TypeError: Cannot read properties of undefined (reading 'checkValidity')
at load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:215:203
at Array.map (<anonymous>)
at mw.UploadWizardDetails.checkValidity (load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:215:158)
at load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:62:657
at Array.forEach (<anonymous>)
at uw.controller.Details.valid (load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:62:605)
at uw.controller.Details.startDetails (load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:62:332)
at OO.EventEmitter.emit (load.php?lang=en-gb&modules=ext.DarkMode%2CSimpleTooltip%2CcreatePage%2CdismissableSiteNotice%2CeventLogging%2Cpopups%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.embedVideo.overlay%7Cext.moderation.ajaxhook%2Cnotify%2Cve%7Cext.moderation.notify.desktop%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.urlShortener.toolbar%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2Ccookie%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cfeedback%2Chtmlform%2Cicon%2CjqueryMsg%2Clanguage%2CmessagePoster%2CsearchSuggest%2Cstorage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategoryMultiselectWidget%2CDateInputWidget%7Cmediawiki.widgets.DateInputWidget.styles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-accessibility%2Cicons-content%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-interactions%2Cicons-location%2Cicons-moderation%2Cicons-movement%7Cskins.vector.es6%2Cjs%7Cskins.vector.icons.js&skin=vector-2022&version=18ubh:363:656)
at startDetails (load.php?lang=en-gb&modules=ext.uploadWizard%7Cext.uploadWizard.page&skin=vector-2022&version=1usqu:20:723)
at OO.EventEmitter.emit (load.php?lang=en-gb&modules=ext.DarkMode%2CSimpleTooltip%2CcreatePage%2CdismissableSiteNotice%2CeventLogging%2Cpopups%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.embedVideo.overlay%7Cext.moderation.ajaxhook%2Cnotify%2Cve%7Cext.moderation.notify.desktop%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.urlShortener.toolbar%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2Ccookie%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cfeedback%2Chtmlform%2Cicon%2CjqueryMsg%2Clanguage%2CmessagePoster%2CsearchSuggest%2Cstorage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategoryMultiselectWidget%2CDateInputWidget%7Cmediawiki.widgets.DateInputWidget.styles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-accessibility%2Cicons-content%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-interactions%2Cicons-location%2Cicons-moderation%2Cicons-movement%7Cskins.vector.es6%2Cjs%7Cskins.vector.icons.js&skin=vector-2022&version=18ubh:363:656)
```
Please consider adding the option to input all necessary information for files before they are uploaded to Wikimedia Commons. Instead of waiting for hours while uploading multiple files and then having to return to the computer to add details to each file, I would like to be able to input all the details such as file name, description, category, etc., while the file is in the process of being uploaded. This way, I can leave the computer to continue uploading files overnight without the need to come back later to input this information.
**Steps to replicate the issue (conjectured):**
* Start UploadWizard on Commons with multiple files
* Enter a description containing a wikilink
* Complete UploadWizard
**What happens?**
Wikicode produced by the UploadWizard contains unbalanced braces (note argument to template parameter `description`):
```
=={{int:filedesc}}==
{{Information
|description={{en|1=[[Wikipedia:Wikipedia:Meetup/NYC/Wikipedia Day 2024|Wikipedia Day 2024]] in NYC hosted by Wikimedia NYC and the Brown Institute at Columbia University.}}}}
|date=…
⋮
```
(See: https://commons.wikimedia.org/w/?oldid=843335998 )
**What should have happened instead?**
Wikicode should be syntactically correct.
**Other information:**
This error has consistently occurred over a set of recent Commons uploads by User:Wil540_art, but not for the uploads that immediately preceded or followed it. Those uploads, in which the UploadWizard seems to have produced correct wikisyntax, did not contain wikilinks in the descriptions, however. (See: https://commons.wikimedia.org/w/index.php?title=Special:NewFiles&offset=20240119055630&limit=50 )
**Feature summary** (what you would like to be able to do and where):
Gives back the upload progress as numeral, while uploading with UploadWizard. The progressbar shows the progress, but it can be hard to estimate if the progress is 44 % or 46 %.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
**Benefits** (why should this be implemented?):
It allows you to see the more exact progress and, for larger uploads, if progress is made at all or how fast in a disctinct interval. It can increase the user-friendliness
Sometimes the upload process on the server changes from assembling stage to publish stage even though the last byte of a file has been upload but not become part of the assembled file (last byte of the file is missing). The file never the less gets published, but no thumbs are generated because of a truncated PNG IEND chunk.
Web browsers, MS Windows, Exiftool and GIMP do display PNGs with a truncated IEND chunk, Mastodon rejects such files.
Examples:
[[File:Diversity_2023_25_(video_capture_049).png]]
[[File:Diversity_2023_25_(video_capture_194).png]]
[[File:Diversity_2023_25_(video_capture_268).png]]
[[File:Diversity_2023_25_(video_capture_529).png]]
**What should have happened instead?**:
Either these files should not be accepted for publishing at all, or thumbor should create thumbs never the less.
Sometimes (maybe more with larger files) UploadWizard fails after the "Describe" stage with "Internal error: Server failed to publish temporary file" like in the screenshot below:
{F41614764 width=800}
AIUI at this point the image has been successfully uploaded (into a temporary location?) and thumbnailed (see the thumb in the screenshot above), but then something goes wrong later in the process.
AFAICT swift and thumbor are both currently behaving themselves, so it'd be useful to know what UploadWizard is doing at this point, and if it could be made to produce and/or log a more helpful error message to aid debugging.
[this task arises from T353498 which was about failure to complete the initial upload ("Upload" step), but that seems to be working]
**Feature summary** (what you would like to be able to do and where):
Current "own work" workflow for UploadWizard presents three questions: "Is this entirely your own work?", "What license do you want to publish this work under?", and "Please select the option that best describes the purpose of this work."
Of the three questions, only the second one is automatisable by expressing a user preference in GlobalPreferences. The request is to create a GlobalPreference also for the other two questions.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
All uploads of pictures and/or other media created entirely by the user.
**Benefits** (why should this be implemented?):
It would reduce the time in uploading media created entirely by the user, by eliminating two extra clicks.
UploadWizard interface messages, like MediaWiki:Mwe-upwiz-source-ownwork-purpose-option-personal-warning, perceive localised links as erroneous.
{F41589874}
While "Publish" button is still available, the mere concept of the error is wrong as the links //should// be localisable.
I suggest adding Special:MyLanguage/ to the original messages, so that there is no need for translator to edit links.
Split from {T349760} (issue #1)
Steps to reproduce:
1. On `commonswiki wmf.19` go to Special:UploadWizard
2. On the **Upload** step, select "Share images from Flickr" option
{F40262161}
3. On the next screen, click on the Back button
{F40264191}
**What happens: **
- a user is taken back to the step 1 (**Learn** step)
- a user clicks on the **Next** button, and the next screen (**Upload** step ) doesn't have any options (or instructions) to do upload:
{F40268341}
Clicking **Back** again will bring a user to the step 1 (**Learn** step).
**What should happen: **
- "Next" button in the step 1 (**Learn** step) should always bring a user to the **Upload** step with options to be selected.
**Steps to replicate the issue** (include links if applicable):
* The error occurs after uploading a 300 MB file with the UploadWizard (might also occur via Chunked uploader)
* I use Firefox 120
*
*
*
**What happens?**:
After uploading, an error is shown with the message: "Interner Fehler: Der Server konnte keine temporäre Datei speichern" (Internal error: The server could not save the temporary file)
**What should have happened instead?**:
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
If I'm uploading an image in Iceland (a country without FoP), it's more likely that image is going to contain an FoP violation than if I'm uploading one from Ireland (a country with FoP)
It might be worth adding a warning to UW if the user is currently in an country without FoP. We check geography based on IP for central notice, so it should be do-able, but I don't think we can test historical data because we don't record IPs for logged-in users (and you need to be logged in to upload). Probably we'd need to pick a country without FoP, and run it as an A/B test
(credit to @Sadads for the idea)
The mediawiki.icon module is used in Extension:Wikibase and Extension:UploadWizard. The only purpose of this module is to serve 2 icons. These extensions should stop using the module and use [[ https://doc.wikimedia.org/codex/latest/components/demos/icon.html#css-only-version | .cdx-mixin-css-icon() ]] and `cdxIconDownTriangle` icon instead (using transform to rotate where needed).
# TODO
[x] Mark the module as deprecated (and update RecentChanges in the process)
[] Switch UploadWizard and Wikibase
[] Remove the module
# Before
{F41522395}
# After
{F41522393}
**Feature summary**
for example https://commons.wikimedia.org/w/index.php?title=File:Beef_rendang_from_Lion_City_Restaurant.jpg&oldid=819306898
the author field is now plain text "False Positives"
compare that to an upload via flickr2commons https://commons.wikimedia.org/w/index.php?title=File:Plants,_The_Musical_(15510034774).jpg&oldid=612522988
which has an author field of "[[ https://www.flickr.com/people/97171555@N00 | Ian Irving ]] from Toronto, Canada"
i propose UploadWizard do the same, linking the profile and/or including the location.
**Benefits**
it's better for archival purposes, for attribution, etc.
PS
wizard used to do better, e.g. https://commons.wikimedia.org/w/index.php?title=File:Suicide_Squad_filming_in_Toronto_2.jpg&oldid=162292407 .
**Steps to replicate the issue** (include links if applicable):
* When user uploads a picture, the preview shows it tilted 90° (or even 180°, i.e. upside down)
* User thinks something is wrong and stops/retries upload, even if everything is fine
**What happens?**:
The preview shows uploaded pictures without regards of the orientation. This affects especially pictures in portrait mode. The preview shows them tilted sideways in 90° angle (or sometimes upside down). New users that do not know about this bug often delete it and try it a second time or even multiple times before they eventually give up.
**What should have happened instead?**:
Preview is shown correctly. Alternatively, user is noticed that orientation might be skewered and that nothing is wrong with their image.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
Wikimedia Commons
**Other information** (browser name/version, screenshots, etc.):
This is a reformulation of [[https://commons.wikimedia.org/w/index.php?title=Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements&diff=prev&oldid=810681935 | this comment on Commons]].
**Steps to replicate the issue** (include links if applicable):
* New user uploads through UploadWizard more than 50 files
* User completes insertion of data, license, title, description, categories, etc.
* UploadWizard crashes at the end of the process, files don't get uploaded and user loses all work done
**What happens?**:
New users have a 50 files limitation. When they try to upload more than 50 files the UploadWizard simply crashes and no files get uploaded. This happens *after* the user has completed the insertion of names, descriptions, and categories.
**What should have happened instead?**:
The program should either block the upload of more than 50 files or inform the user about this limitations *before* they put the effort of describing the files.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
Wikimedia Commons
**Other information** (browser name/version, screenshots, etc.):
This is a reformulation of [[ https://commons.wikimedia.org/w/index.php?title=Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements&diff=prev&oldid=810677515 | this comment on Commons ]].
**Steps to replicate the issue** (include links if applicable):
* open https://commons.wikimedia.org/wiki/Special:UploadWizard
* upload this image: https://commons.wikimedia.org/wiki/File:Dog_wash_box.jpg
**What happens?**:
upload wizard does **not** detect GPS coordinates.
It does seem to detect GPS direction though, so some metadata seems to have been parsed
**What should have happened instead?**:
GPS coordinates should've been prefilled by UploadWizard (as it happens with most of my other images)
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
manually checking the images with `exiftool` however shows GPS coordinates just fine, and other geolocation enabled apps (like [[ https://wiki.openstreetmap.org/wiki/JOSM | JOSM ]] open the pictures at correct locations.
```
ExifTool Version Number : 12.57
File Name : 3945757_1.jpg
Directory : .
File Size : 330 kB
File Modification Date/Time : 2023:10:18 02:21:21+02:00
File Access Date/Time : 2023:10:20 11:53:51+02:00
File Inode Change Date/Time : 2023:10:20 11:53:33+02:00
File Permissions : -rw-------
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
Exif Byte Order : Big-endian (Motorola, MM)
Orientation : Unknown (0)
Light Source : Unknown
GPS Latitude : 45 deg 48' 26.63"
GPS Longitude : 15 deg 55' 51.78"
GPS Img Direction Ref : Magnetic North
GPS Img Direction : 73.53
JFIF Version : 1.01
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Profile CMM Type :
Profile Version : 2.1.0
Profile Class : Display Device Profile
Color Space Data : RGB
Profile Connection Space : XYZ
Profile Date Time : 0000:00:00 00:00:00
Profile File Signature : acsp
Primary Platform : Unknown ()
CMM Flags : Not Embedded, Independent
Device Manufacturer :
Device Model :
Device Attributes : Reflective, Glossy, Positive, Color
Rendering Intent : Media-Relative Colorimetric
Connection Space Illuminant : 0.9642 1 0.82491
Profile Creator :
Profile ID : 0
Profile Description : sRGB
Red Matrix Column : 0.43607 0.22249 0.01392
Green Matrix Column : 0.38515 0.71687 0.09708
Blue Matrix Column : 0.14307 0.06061 0.7141
Red Tone Reproduction Curve : (Binary data 40 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 40 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 40 bytes, use -b option to extract)
Media White Point : 0.9642 1 0.82491
Profile Copyright : Google Inc. 2016
Image Width : 1280
Image Height : 1707
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Image Size : 1280x1707
Megapixels : 2.2
GPS Position : 45 deg 48' 26.63", 15 deg 55' 51.78"
```
possibly related issue: https://phabricator.wikimedia.org/T223051
If all the categories were entered as wikitext in the additional information box then Upload wizard will incorrectly mark the file as uncategorized. Example: https://commons.wikimedia.org/w/index.php?title=File:Kolin_funikulaari_4.webm&oldid=811862074
The input field in {T347750} expects free text that may include a URL.
If we don’t enforce any validation besides the current text length, then there’s a risk that a user may input arbitrary text.
==Tasks==
[] search for a URL within the input
[] add an error message if it’s malformed
**Description**
The goal of this project is to reduce badly uploaded media content on Commons by making improvements to the uploading process through Upload Wizard (UW). This would help reduce moderator burden further down the Commons funnel. See [[ https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wizard_Improvements?useskin=vector-2022 | project page ]].
We have identified UX improvements for the first part of Upload Wizard improvements based on the extensive design discovery and data discovery work in Q1 (T337408, T344957, T344959, T340546, T337466) which included the following:
- [[ https://commons.wikimedia.org/wiki/File:Wikimedia_Commons_Image_Moderation-uploaders_report.pdf?useskin=vector-2022 | interviews with uploaders ]]
- [[ https://phabricator.wikimedia.org/T340546 | analysis of deletion requests ]]
- [[ https://docs.google.com/document/d/1qBWhT5O-47P8xzRxoLpjZ9UaoUzSAt5ZAOnrZwX8nqs/edit | interviews with moderators ]]
- [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard-(Pw%3A-commons2023)?type=design&node-id=27-521&mode=design&t=uIJt9sALOFMWMNix-0 | uncovering user mindsets ]]
- [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard-(Pw%3A-commons2023)?type=design&node-id=197-240&mode=design&t=uIJt9sALOFMWMNix-0 | exploring designs concepts ]]
- [[ https://phabricator.wikimedia.org/T344959 | usability testing of the designs ]]
- [[ https://phabricator.wikimedia.org/T337466 | baseline deletion rate data ]]
We will focus on redesign of the Release rights part of the upload process and its two steps:
- Choosing the own vs not own work step
- Specifying release right information for both own and not own work
to make the upload process more intentional so that it prevents upload of content not intended for commons and decreases future moderator burden.
**Use cases**
As a moderator, I want that uploads to Commons are made more intentionally and are conform with Commons rules so that there is less moderator burden of flagging and reviewing deletion requests.
As a user, when uploading media through Upload Wizard on Commons,
- I want to place my file in the correct own vs not own work category
- I want to ensure that my file satisfies Commons rules and choose the right license option
So that it does not get flagged and deleted in the future.
**Scope**
- Upload Wizard on Commons
- Redesign the Release rights part of the upload process
- The Release rights step are implemented as per [[ https://www.figma.com/file/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?type=design&node-id=920-10983&mode=design | designs ]] for uploads of a single file:
- Step 1: choose own vs not own work is covered in T347590
- Step 2a: Own work licences is covered in T347596
- Step 2b: Not own work licences is covered in T347598
- Same workflow is extended to multiple files upload T347705
**Out of scope of this project**
- Improvements of other parts of Upload Wizard on Commons
- Improvements of other parts of Commons
- Improvements of media upload process on other projects (Wikipedia visual editor and source editor)
- Implementation of algorithms for automatically flagging potential content on upload
**Steps to replicate the issue** (include links if applicable):
* Go to https://commons.wikimedia.org/wiki/Special:UploadWizard
* Select a file for upload
* Mark "This file is not my own work."
* Scroll down to "Another reason not mentioned above" and enter any license, I tried with {{Cc-by-2.0}}
**What happens?**:
When saving the file, this is the wikicode:
`=={{int:license-header}}==`
` `
`{{Cc-by-2.0}}`
**What should have happened instead?**:
There should be no empty line, wikitext should be.
`=={{int:license-header}}==`
`{{Cc-by-2.0}}`
Hi. I upload new versions of files many times, but yesterday it was very wrong. New file created without any sence or license or naming.
# Open Commons.
# Find two existing files, X and Y, with the same extension (.svg in my case).
# Download X to your computer (File:Moscow metro map sb.svg in my case).
# Change the downloaded file name, for example to "Phabtest.<same extension>" (Metromap.svg in my case).
# Upload it as a new version of Y (File:Moscow metro map sb draft.svg in my case).
# Get a warning "You're trying to upload a copy of existing file".
# Expected: Click on "Ignore warnings" and the new version uploads.
# Got: A new file, "File:Phabtest.<same extension>" created, with one version and empty license (File:Metromap.svg in my case).
I saw this a couple of times yesterday. Creating a file with local computer name is bad enough, not talking about creating an irrelevant file. Thank you.
The GFDL is used as a license for a lot of textual content across the movement. Just like how version 4.0 is specified for CC BY-SA, 1.3 should be specified for GFDL.
The said message documentation contains information about four parameters (the last being a user to be used with GENDER), however the English text only makes use of $1 - $3 so that TranslateWiki interface complains that $4 is not defined when I'm using it. Consequently, the translated message is permanently displayed as "out of date".
Proposed change in MediaWiki:Mwe-upwiz-patent:
from:
```
I, $2, would like to grant a permanent patent license to any users of {{PLURAL:$1|the file|the files}} and related 3D objects ([$3 legal code]).
```
to:
```
I, $2, {{GENDER:$4|would like}} to grant a permanent patent license to any users of {{PLURAL:$1|the file|the files}} and related 3D objects ([$3 legal code]).
```
This would not change the appearance of English text but will make it easier to translate it in some languages.
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=mwe-upwiz-patent&group=ext-uploadwizard-user&language=pl
Addressing this request would require making a change in the following repositories/files:
* Change `mwe-upwiz-patent`'s value in file `en.json` in repository [[ https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/UploadWizard,general | mediawiki/extensions/UploadWizard ]].
**Feature summary** (what you would like to be able to do and where):
Start campaign at midnight of local time on day 1, end campaign at 23:59 of local time of last day.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Tested with a [[ https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wllhsg2023-sandbox | testing campaign ]] on Commons
Input 'start' time with '2023-06-12T07:00+08:00' and
Input 'end' time with '2023-07-12T08:00+08:00'
On 12 June 2023, 7:01am GMT +8hrs, the campaign header in testing campaign shows as the campaign has not started. It should reflect as active.
On 12 June 2023, 8:01 am GMT +8hrs, the campaign header in the testing campaign shows as the campaign has ended.
Ideally, between 7.00am to 8:00 am, the campaign should be live.
Technically, keying 'end' time with '2023-06-13T08:00+08:00', the campaign will only be live only on 14 June 2023, until 00:00 hours GMT 0 hours. (i.e. 14 June 2023 GMT +08:00)
**Benefits** (why should this be implemented?):
Some campaigns may require a start and end time, not just the dates set to certain hours local timezones for reasons. Instructions on the [[ https://www.mediawiki.org/wiki/Extension:UploadWizard/Campaigns#start | Campaigns documentation]] states that the parameters accept any UTC time format, which some campaign editors have formatted the time for the campaign to start and end at specific time on their local timezone, as above (as evidently seen through [[ https://commons.wikimedia.org/w/index.php?search=start&title=Special:Search&profile=advanced&fulltext=1&ns460=1 | a search on Commons]].
**Feature summary and use case**: When uploading a file to Commons with UploadWizard, there is a scary warning "Personal data: EXIF metadata in this file may contain location or other personal data [...]" This implies the file does contain such identifying metadata, and that a privacy-minded user would be better off not uploading that file. After it's been uploaded, the File: page has a box at the bottom showing the metadata, which is often just the resolution or other non-identifying things. I'd like UploadWizard to show users this metadata //before// they finalize their upload (like the form already shows e.g. a preview/thumbnail of the image before they finalize uploading).
**Benefit**: Being able to see what metadata is present would allow users to A) decide "oh, dpc is not identifying" and not be scared off from uploading the file by the big (but inapplicable) warning, and/or B) notice when a file //does// have identifying metadata, and go use one of the already-linked-to Exif removal tools on it before uploading it.
**Related task**: I believe this is distinct from T22326, since that one asks to code a new ability to remove metadata, whereas this only requests to take the already-existing functionality of "show what metadata is present", which is already used on File: pages once something has been uploaded, and also display it during the upload process prior to the Publish stage.
Small discussion: https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=771803183#Let_uploaders_see_what_metadata_is_present_as_they're_uploading
**Steps to replicate the issue** (include links if applicable):
* Upload a picture to Commons, being very careful not to get it upside down.
**What happens?**:
Success! As you see we succeeded!
{F37092168}
But...
We still failed in reality:
{F37092171}
**What should have happened instead?**:
Either both pictures you see above should be right-side up.
Or both pictures should be upside-down.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
https://commons.wikimedia.org/wiki/File:Aquino_Assassination_Plaque_151054_01.jpg
Maybe fixing this bug would reduce rotation requests.
**Feature summary** (what you would like to be able to do and where):
https://commons.wikimedia.org/wiki/Special:UploadWizard , choose flickr, try https://flickr.com/photos/statephotos for example.
```
<span class="oo-ui-labelElement-label">Upload selected images</span>
```
this button should be duplicated on top.
**Benefits** (why should this be implemented?):
if you're a new user, you can upload only 4.
on the other hand, i've tried to upload 100 something photos at once, but the wizard froze and crashed.
so, very often users only upload some images of all that would be shown.
**if there is a button on top, users dont need to scroll to the bottom.**
without scrolling to the bottom, users dont need to wait for all the thumbnails to load. **when the thumbnails are being loaded, the process is very annoying and frustrating**, because loading makes the page longer and keeps moving the upload button further down.
i've finished picking what i want to upload and want to press that button, so i dont need the other thumbnails to load. a button on top will make the process way better, especially for users with slow computers and/or networks!
**Steps to replicate the issue** (include links if applicable):
* Upload at least 5 files using the upload wizard on Commons.
* Follow the wizard through to the describe page.
* Fill in all values except one required field (towards the top) and hit submit.
**What happens?**:
Apparently nothing. This is bad UX.
**What should have happened instead?**:
If something is missing, then the view should jump to the topmost value that is missing.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Firefox 111
**Steps to replicate the issue** (include links if applicable):
* Disable JavaScript
* Go to https://commons.wikimedia.org/wiki/Special:UploadWizard
**What happens?**:
The Patent permissions form appears in the fallback to Special:Upload
**What should have happened instead?**:
Special:Upload does not display the patent permissions form ({https://phabricator.wikimedia.org/source/3D/browse/master/modules/ext.3d.special.upload.less}), so the fallback to it on Special:UploadWizard shouldn't either.
It appears to be causing confusion: https://commons.wikimedia.org/wiki/User_talk:AntiCompositeBot#This_bot_marks_pages_that_are_uploaded_with_released_rights_as_having_insufficient_copyright_information.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Disable Javascript
* Go to https://commons.wikimedia.org/wiki/Special:UploadWizard
**What happens?**:
The summary box is blank.
**What should have happened instead?**:
The summary box should contain the text of the `upload-default-description` interface message.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Special:Upload works as expected with JavaScript disabled.
There is no reason to have different strings when uploading in UW vs when adding captions to an existing file.
(Realized when looking into T332492.)
`wikibasemediainfo-filepage-caption-too-short` says `X more character[s] required`
`mwe-upwiz-error-too-short` says `This entry is too short. Please make sure this entry is at least X characters.` in screaming bold letters.
{F36918347}
{F36918348}
{F36918349}
{F36918350}
Also, why is one header `Caption` and why is another header `Captions`?
**Feature summary** (what you would like to be able to do and where):
Don't chastise the user for filling in a too short title until he is through entering it.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
User typing one letter at a time will always only have 1, 2, 3, ... characters input at early points of typing.
**Benefits** (why should this be implemented?):
{F36918151}
Here we are looking at the commons uploader form. It says required field, but it is not clear if it is talking about the thing above it or the thing below it.
{F36869972}
https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback says to report this here.
I'm using a tiny cell phone. So bear with me. The template won't fit.
{F36869967}
Here we see one of the files has failed to upload. The only choice is to remove it. Even though in the words it says try again, but there is no try again button. Therefore the user must painstakingly remove it and then dig in his files and add it back in. Simply adding a try again button would avoid all that trauma.
**Steps to replicate the issue** (include links if applicable):
* Message MediaWiki:Mwe-upwiz-license-pd-art-70 is documented as:
```$2 - the URL "//commons.wikimedia.org/wiki/Commons:Licensing#Material_in_the_public_domain"; if you replace the $2 value, place it first in comments <!--$2--> before the localized URL, to avoid inserting a FUZZY resource```
* This way was applied in Russian Translation - see https://translatewiki.net/w/i.php?title=MediaWiki:Mwe-upwiz-license-pd-art-70/ru&action=edit
```Точная репродукция картины, находящейся в общественном достоянии по причине того, что художник умер более 70 лет назад ([<!--$2-->//commons.wikimedia.org/wiki/Commons:Licensing/ru#Материалы_в_общественном_достоянии узнать подробности])```
* In the TWN and Commons this message is shown correctly:
{F36524556}
{F36524558}
**What happens?**:
In the Upload Wizard (step 2) this text is shown incorrectly:
{F36524560}
**What should have happened instead?**:
Should be working hyperlink in the Upload Wizard.
The UploadWizard allows to prefill fields like the category or campaign specific fields by adding arguments to the URL. This is a very nice feature for upload tools or templates.
Unfortunately it is currently not possible to add structured data this way. I would like to have this added.
In the URL this could be a simple &property=statements like:
```
&P180=Q10884
```
https://commons.wikimedia.org/w/index.php?title=File:Bangkok_street_food_-_Thanee_Khao_Moo_Daeng_(51362795506).jpg&diff=719608451&oldid=708983056
this edit corrected an anomalous category
> [[Category:[[Category:Kitchen scales]]]]
i assumed this redundant wikitext was added when i copypasted "Category:Kitchen scales" in uploadwizard. at the time of my upload, the target category already exists, so it's unlike the error when the cat does not yet exist ( [[Category:Category:Example]] ).
**Steps to replicate the issue**
* https://commons.wikimedia.org/wiki/Special:UploadWizard
* copypaste "Category:Example" when adding categories
* somehow, i'm not sure how exactly, resultant wikitext will have one redundant layer.
**Steps to replicate the issue** (include links if applicable):
1. Visit Upload Wizard on mobile web
2. Choose "Share images from Flickr"
**What happens?**:
The textbox for typing the Flickr URL is very small, sometimes only one character wide depending on the size of the phone. This makes the information difficult to enter.
**What should have happened instead?**:
Margin should be eliminated on small screens allowing the text box to fill the entire screen width. Also, the "Get from Flickr" button could be moved to the next row to free up more space.
**Other information** (browser name/version, screenshots, etc.):
{F35697991} {F35697995}
**Steps to replicate the issue** (include links if applicable):
* Go to the Upload Wizard: https://commons.wikimedia.org/wiki/Special:UploadWizard
* Choose "Share images from Flickr"
* Pick a photo on Flickr with a long name, for example: https://www.flickr.com/photos/greecemfa/52372752360/
**What happens?**:
After the software tries to upload the file, there is a red exclamation sign and it says: "Filenames may not be longer than 240 bytes.", without letting you to continue to the next stage.
**What should have happened instead?**:
On other cases the file gets uploaded to the wizard and there is a green V, and one can continue to the next stage in which it is possible to deal and change the file's name, description, copyrights status, categories etc.. This happens even if there are other kinds of problems in the original Flickr name (the name is too short/there is another file on Commons with the same name/the name contains illegal characters...) - it won't let you to upload the file to Commons before these problems are solved, but at least it let you fix it, unlike the long name case.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
* I have encountered this problem for the first time at least 2 years ago, and I didn't get a proper response on the Commons help pages (else than manually downloading the file to my computer or use some sort of an old and inefficient version of the upload process)
*I have found a similar report on a Commons talk page from August 2017: https://commons.wikimedia.org/wiki/Commons_talk:Upload_Wizard/Archive_1#Too_long_file_names where they mentioned a very similar case dealt on Phabricator which was supposedly resolved: {T151776}
I'm trying to use this to bulk upload many images to my site but I have to enter a date for every single one, when I have hundreds of images that is going to take a long time.
I found I can use `index.php?title=Special:UploadWizard&description=Image` to set the description just to the word `Image` but I tried `&date=2022-08-04` but it did not work, nor did `&date="Thu, 11 Aug 2022"`
**Feature summary** (what you would like to be able to do and where): When an editor attempts to upload a file to Commons, automatically detect this and convert the upload into a FileImport
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Problem is editors breaking attribution/edit history by uploading files uploaded to other projects as their own.
**Benefits** (why should this be implemented?): Would help maintain CC-BY-SA 3.0/GFDL compliance by ensuring attribution/edit history is maintained across projects.
Now that {T243051} is done, this extension should migrate away from IDatabase::select() to [[https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php|SelectQueryBuilder]].
It would improve readability of the code, avoids mistakes by passing the wrong order of arguments, etc.
For more information check T243051 and [[https://www.mediawiki.org/wiki/Manual:Database_access#SelectQueryBuilder|its documentation]].
Note that query builder is a different paradigm and changes should not be one-to-one. For example, avoid using joinConds().
Remaining time seems to be based on the average speed since the upload start.
This means that if it was slow in the beginning and then speeds up, the remaining time shown will be wrong until the end.
The remaining time should be based on the last x seconds instead of the total elapsed time.
See getRemainingTime in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/UploadWizard/+/refs/heads/master/resources/mw.GroupProgressBar.js#164
== Background
Inspired by @Graham87's [[ https://wikimedia.org.au/wiki/User:Graham87/Accessibility_wishlist | wishlist item ]] from a few years ago, the way the UploadWizard's comic as explanation for how to deal with it, is completely inaccessible to screenreader users.
== Goal
Have at least alternative text to ensure the information is conveyed to assistive technology.
**List of steps to reproduce** (step by step, including full links if applicable):
* Upload file containing a '|' in the description (likely also the case for '}'), included within `<syntaxhlighlight>` tags
**What happens?**:
* The character is displayed as `{{!}}` within the code block and needs to be [[https://commons.wikimedia.org/wiki/Special:Diff/651452985|manually fixed]].
**What should have happened instead?**:
* The replacement should not have been made in this context.
It would be great if it was easier to add new licenses. I tried [[ https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl | this ]] and it doesn't work for me.
The local archive asked us to always refer to them so we added a speacial Public Domain and a special CC-BY-SA Licences for them in the standard uploader:
https://kiel-wiki.de/index.php?title=MediaWiki:Licenses
If you choose, that the upload is a third party work there shoud be an additional paragraph with our two archive licenses.
**List of steps to reproduce** (step by step, including full links if applicable):
* Visit [[ https://commons.wikimedia.org/wiki/Special:UploadWizard | Special:UploadWizard ]] on commonwiki
* Select "This file is not my own work" in phase "Release rights", jump to section "Now tell us why you are sure you have the right to publish this work:"
**What happens?**:
[[ https://commons.wikimedia.org/wiki/MediaWiki:Mwe-upwiz-license-cc-subhead | Message (mwe-upwiz-license-cc-subhead) ]] (locally overridden) displayed in wikitext form.
{F35031836}
**What should have happened instead?**:
It should be parsed and link should be properly displayed.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
`1.39.0-wmf.5 (adb92e7)`
**Feature summary**
https://commons.wikimedia.org/wiki/Special:UploadWizard
can the "copy information to all uploads" function add information rather than overwrite information?
**Use case(s)**
suppose you use uploadwizard to import these flickr images: https://www.flickr.com/photos/yann07/albums/72157719759878146 .
some photos already have descriptions, but some do not.
regardless, you want to add some descriptions to all photos. (it might be that you want to write in a language that's different from what all the existing descriptions are, like japanese.)
right now, if i do that, descriptions provided by me and copied to all uploads using the button, would erase all existing descriptions.
example: https://commons.wikimedia.org/wiki/File:Serena_swimsuit_by_Yann_C%C5%93uru.jpg i only realised its flickr description is "l'espiguette Gard" (which is the location of the photo, which is not geotagged) when i revisit the flickr page, so overwriting the description caused the loss of the location info. i overwrote the description with something useless ("woman") because another stupid design that does not allow an empty description field. (sorry for my language but this design caused all these troubles. if i could leave description fields empty then the flickr description wouldnt be overwritten.)
so, can the copy button please be additive only? or at least it gives some warning that it's overwriting something?
**Benefits**
the original descriptions at flickr often contain important details about the photo. it's important to preserve them, while utilising the copy function to add more descriptions.
----
this request is not only relevant to the description field, but also to categories, other information, etc. that can take multiple values (in contrast to fields, like title, date, that can only take a single value).
The prompt to a user to add a more descriptive image title has red parentheses around a blue text:
{F35021484}
**List of steps to reproduce** (step by step, including full links if applicable):
* I had a group of 4 photos of the Logan River to upload, all taken looking in different directions from more or less the same spot (give or take a few metres to dodge some bushes). Because such photos will have the same copyright, permissions, and similar captions (but not identical) but the same categories and other info, I find it convenient to upload them as a group and use the "Copy all information to uploads following ..." to avoid tediously typing in categories etc
* I invoked the Upload Wizard and thought I'd chosen all 4 images, but evidently clicked something wrong and only chose one and, due to a phone call, didn't realise it until I was about to do "Copy all information to uploads following ..." and realised there were no other uploads. Oh well, no problemo, I'll go Back, Back to the Upload screen and and uploaded the other 3 photos, which worked, and then back to the Describe screen and noticed none of these 3 photos had their location coordinates displaying yet the first photo uploaded on its own did have its coords displaying. Was the EXIF data missing on these files? And how could that be? Same phone took the photos from more-or-less the same spot within a couple of minutes. So I removed the 3 files on the Describe screen with the trash can button and completed the upload of the first file. All was well with that upload.
* Then I started the Upload Wizard again and uploaded one of the other 3 files. This time on the Describe screen all the coords were displaying. Clearly they did have EXIF data. I then uploaded the other 2 together, again both had coords displaying.
**What happens?**:
It seems that uploading additional files by going Back Back to the Upload screen and then moving forward again to the Describe screen, somehow the extraction of the coordinates from the image is being bypassed.
**What should have happened instead?**:
It should have extracted the location coordinates.
I repeated the process with two more files (uploaded one, moved through to the Describe screen, then Back Back and uploaded the second one), back to the Describe screen, same problem, no coords revealed for the second file. So it seems repeatable.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
The files were:
* first file: https://commons.wikimedia.org/wiki/File:Looking_upstream_along_the_Logan_River_from_northern_end_of_Loaders_Lane,_Alberton,_2022.jpg
* second file: https://commons.wikimedia.org/wiki/File:Looking_across_the_Logan_River_to_Carbrook_from_Loaders_Lane,_Alberton,_2022.jpg
* third and fourth files (uploaded together):
https://commons.wikimedia.org/wiki/File:Looking_across_the_Logan_Road_towards_Carbrook_from_Loaders_Lane,_Alberton,_2022.jpg
https://commons.wikimedia.org/wiki/File:Looking_north-east_across_the_Logan_Road_to_Carbrook_from_Loaders_Lane,_Alberton,_2022.jpg
This is an umbrella bug report for a range of high-impact, long-standing bugs which prevent sharing, finding, and collaborating on documents and data.
See also @JeanFred's original tracking bug T44725, linked to **over 200** other tickets, including hundreds of formats not covered here.
**The problem**:
- It is very hard to share data files or document files on Wikimedia projects. This limits the efficacy of community members, and of outreach to new communities (//Who would join a community that rejects every format of their work?//).
- In the rare cases where a data file (in the Commons:Data namespace) or document (as pdf) is shared on Commons, it is hard to find them, as the search interface hides them.
- Adding new format support is easy, and the highest-impact work we do, but inertia + lack of clear process has made it surprisingly rare. After two decades we have support for only [[ https://commons.wikimedia.org/wiki/Commons:Project_scope/Allowable_file_types | 20 filetypes ]]. The //only// media category where we support the most common formats (directly or via transcoding) is Images.
- Many filetypes that our communities depend on to run the projects and do daily research, are blocked from upload to our wikis -- pushing them to use non-free services (such as Dropbox or Google), or non-public ones (such as email).
**Issues blocking uploading data + documents:**
**0) Organize related tickets and data: Add FileTypes tag for new requests + analyses. **
> There are hundreds of file formats we should eventually support; the hard-to-follow response to dozens of past bugs on related issues is in part related to the lack of a single queue for related work.
> The "[[ https://www.mediawiki.org/wiki/Manual:Adding_support_for_new_filetypes | how to add support for new filetypes ]]" guide is a great start; a tag here will help. Work on things like finessing tabular-data support (into a new namespace) (on Commons only) might also merit the tag.
- 0.1) Reopen tickets for gathering relevant data. T77796 - data on what unsupported filetypes are being uploaded
**1) Add Data and Documents as categories in Commons search.**
> (Currently it has Images, Audio, Video, and Other Media -- add Documents, Data, before Other)
- 1.1) Make these search .tab and .map datasets in the Data namespace - T252327
- 1.2) Allow searching Newfiles to filter by format. - T66768
**2) Add upload support for essential document file formats **
> (Currently we support only PDF, arguable the least open of all of these, and DJVU)
- 2.1) Add .RDF support
- 2.3) Add .EPUB format - is there an underlying problem w/ zipped formats? T252250
- 2.2) Add .ODT support - T45154 (for all ODF formats)
- 2.4) Add .ODP support - T45154 (for all ODF formats), (presentations)
- 2.5) Review other OO formats - OASIS (T4089),
**3) Add upload support for essential data file formats**
> (Currently we support NO STRUCTURED DATA FORMATS AT ALL, despite using them in every technical part of our workflow)
> "There is currently a major issue with storing statistical data in Wikidata, which would be solved if we could upload the data to Commons as Tabular Data files." - @NavinoEvans on T181319
- 3.1) Add .CSV support - in use across wikimedia, just not as files
- 3.2) Add .JSON support - in use on many other MW instances, see T68036
- 3.3) Add .XML support (see also Music XML + Lilypond: T214023 , T208494)
- 3.4) Add .SQLite support (widely used, selected as an archival format by the Library of Congress)
- 3.5) Add .ODS support : T45151
- 3.6) Update related conversations. [[ https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets | How to deal with open datasets ]], [[ https://commons.wikimedia.org/wiki/Commons_talk:Project_scope/Allowable_file_types | Talk:Allowable file types ]]
**List of steps to reproduce** (step by step, including full links if applicable):
* Go to Wikimedia Commons
* Upload any file containing a Warang Citi character in the filename
**What happens?**:
* Upload fails and shows notification "Please choose a different, descriptive title"
**What should have happened instead?**:
The file should be uploaded like any other file.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
Firefox 92.0
{F34867204}
==== What is the problem?
In the CodeEditor, unicode encoded characters (e.g. `\u00f6`) are shown as having been changed (to their literal character, e.g. `ö`), even if I have made no changes to it.
==== Steps to reproduce problem
# Go to https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Campaign:wlm-de-nrw&action=edit
# Click "Show changes"
**Expected behavior:** Should show no changes (because no changes have been made)
**Observed behavior:** One change is shown
==== Environment
**Wiki(s):** https://commons.wikimedia.beta.wmflabs.org CodeEditor – (9b1bd68) 06:21, 29 October 2021.
==== Screenshots (if applicable):
{F34715256}
**List of steps to reproduce** (step by step, including full links if applicable):
* On Wikimedia Commons, go to the upload wizard
* Upload any file
* Click "continue" to the release rights page
* Select "This file is not my own work.:
* Scroll down, open "Another reason not mentioned above"
* Paste any string of text in the box labeled "The license is described by the following wikitext"
**What happens?**:
* Observe that you are unable to select any specific text in the input box using your mouse.
* You can move the cursor left and right with arrow keys, but you can't change the position of the cursor using your mouse.
**What should have happened instead?**:
* Clicking in the text box should allow you to make text selections.
* This is problematic for license tags that have parameters; users may want to copy paste the unfilled license tag and then fill in the parameters in the upload wizard, but will have issues because they cannot easily traverse the text with a mouse.
* This problem is exacerbated for mobile users, who can only click and have no arrow keys.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
Currently, on all responses mw.config includes configuration variables `wgExtraSignatureNamespaces`, `wgLegalTitleChars`, and `wgIllegalFileChars`. These are documented[1] as being
> `@internal For mediawiki.Title`
We should switch to providing them via package files instead, so that they are only loaded when the mediawiki.Title module is used.
Uses in javascript
* `wgExtraSignatureNamespaces` - correctly only used by mediawiki.Title
* `wgLegalTitleChars` - correctly only used by mediawiki.Title
* `wgIllegalFileChars` - also being used by UploadWizard extension (deployed) and MediaUploader (not deployed)
Proposal:
* Switch extensions (at least UploadWizard) to use package files with injected config
* Switch mediawiki.Title to use package files with injected config, and remove from mw.config (with a mention in the release notes just in case)
[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/3ff9183d2453413e7c8c550232918d11cfd1eb1b/includes/resourceloader/ResourceLoader.php#1977
For upload campaigns it would be useful to have an option to add check boxes as fields. Currently only drop down menus and text fields are possible to be added.
The current workaround for use cases of a single check box is a drop down menu with an ampty entry and to option on.
For multiple check boxes there is no good workaround.
**Feature summary** (what you would like to be able to do):
Allow user to choose where the server is located in the step 3, licenses. Which also means to change mwe-upwiz-license-public-domain-usa-subhead, and mwe-upwiz-license-public-domain-usa-head in ./i18n lang.json . I think should use $wgUploadWizardLocation to locate the server location.
**Steps to reproduce** (a list of clear steps to create the situation that made you report this, including full links if applicable):
* GO to step3.
* Scroll down to The copyright has definitely expired in xxx
* There is.
**Use case(s)** (describe the actual underlying problem which you want to solve, and not only a solution):
To prevent user upload a file is legal in United States, but not in the country where server locate. Most countrys ask the server owner response to the server and must be legal to the country they life in.
When tabbing past the language field for captions in the upload wizard, the focus is lost and returns to the start of the page, making it effectively impossible to fill in the form by tabbing through it.
The same happens on the structured data tab for monolingual text statements.
{F35151201}
When focusing the language selector, the ULS language selector is opened and focus is transferred to the search field of the selector. As tab unfocus'es from the search field, the focus is not returned to the originating point, but to the start of the document (likely because the ULS language selector is a top floating window at the beginning of the document structure, instead of inline of the document structure where it is being presented.
**List of steps to reproduce** (step by step, including full links if applicable):
* Upload a PDF file
* get to the Describe tab
**What happens?**:
* see "Image title" in the first prompt
**What should have happened instead?**:
* it should read "File name" or something similar, which would be more accurate for non-image files.
I've been trying to upload the one of the hackathon talks to commons for days and I haven't been able to.
With video2commons the upload failed consistently:
{F34479570}
And using Upload wizard I get the same result.
{F34479572}
The video is the original mp4 1080p 1,130,715KB (see on [[ https://www.youtube.com/watch?v=ZOj44Rbh0tM | youtube ]], which I uploaded to video2commons, which converted it to vp9 and tried to upload.
I ended up doing the conversion myself as well to webm vp8 locally, resulting in a 800,987KB video file, which I tried multiple times on Upload wizard to no success.
May be related to {T228292}?
Visit https://commons.wikimedia.org/
in the sidebar is "Upload file"
Now we are on
https://commons.wikimedia.org/wiki/Special:UploadWizard
but there is no list of valid upload file types (.jpg, .png, .ogg...).
Look around the page.
See a help link, press it.
OK, now we are on
https://commons.wikimedia.org/wiki/Commons:Help_desk
No answer there.
Must be buried even deeper.
Most other website will mention valid file types even before clicking further.
One must Google to finally find https://commons.wikimedia.org/wiki/Commons:File_types .
I often encounter images in Flickr where the uploader claims to reserve copyright (or more likely, has simply not changed the default) but where the images are scans of long-out-of-copyright works. I can download them, and upload them from my hard-drive, but that's tiresome, and does not bring in their metadata,
Trusted users (however defined and flagged) should be able to use the Wizard to import such images, stating an applicable reason for doing so.
In UploadWizard's Flickr importing interface, if you enter the URL of a single image such as https://www.flickr.com/photos/winnu/50811285123/, it sets the author as the Flickr realname (in this case "Nigel"). If, however, you enter the URL of a photostream such as https://www.flickr.com/photos/winnu/with/15715931764/, it sets the author as the Flickr username (in this case "winnu").
In both cases, it should set the author to the realname if possible (photo->owner->realname).
On commons are many wrong "{{own}}"-claims (copyright-violations) which are difficult to find, therefore the upload-wizard should always ask for source, author and license.
If own than source can be {{own}}, "self drawn", "taken with my smarthone",...
Often derivatives (hand drawing of pikachu, photo of a poster,...) are wrongly considered as own work, if the upload wizard always asked for a source this issue might get reduced.
It reduces one clicks during upload, and prevents copyright-violations. I don't see a scene in distinglishing between own and not own, since the information-template is in both cases the same.
{F34411667}
UploadWizard has a feature that allows user to import images from Flickr.
With the feature enabled, UploadWizard will connect to `https://api.flickr.com` and violate CSP if `https://api.flickr.com` is not specifically defined under `$wgCSPHeader`.
Instead, UploadWizard should add the Flickr API to CSP if the feature is being used.
UploadWizard prefills automatically the EXIF date (or even the upload date) to the "date" field as the date of the origin of the work, even in cases of obviously old works (e.g. photographs from the 19th century or scans of old paintings or maps). Such an indistinguishable statement is then misleading, even outright untrue. Occasional and one-time contributors generally do not have the courage to change or delete the pre-filled date.
Some suggestions to alleviate this defect:
- every such automatically prefilled date should be iserted every time with a template {{According to Exif data}} or {{Upload date}} , to distinguish them from {{Taken on}} which is the default meaning for photos and from intentionally filled date.
- if the device according to exif data is a scanner, not a camera or mobile phone, than the Exif date should use some specific template as {{Scan date}} instead of {{According to Exif data}}.
A more systematic solution would be for the {{Information}} template to have a different field for each of these meanings. However, for such a change, it would be difficult to ensure full backward compatibility and update any scripts that use this data. In addition, this way of entering data will probably be replaced in the future by Structured Data and therefore it is not effective to fundamentally change the structure of the template. To distinguish date meanings using standard templates as proposed above is machine-readable and transformable in the future.
It would also be useful to strengthen context-sensitive help so that the uploader is not afraid to refine, delete or replace all pre-filled data or texts.