-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it possible to upload new files to Wikimedia Commons #4682
Comments
After receiving a question re: how we will actually implement this (at which stage will the structured data be added to the file, and how can this process be made as simple as possible?): this Phabricator ticket may be of interest. (Basically, UploadWizard adds SDC after a file was uploaded, if I understand correctly) |
I think we would want to perform the batch process as efficiently as possible with existing API's? A. upload all files So then on the user facing side in OpenRefine, I can envision 2 ways to show progress to a user:
@wetneb Also, I'd like to see a link to @lozanaross' design in the original comment, because I didn't see any design for OpenRefine here: https://phabricator.wikimedia.org/T294938 |
It's not just about efficiency, but the 2-step approach probably introduces some risk and more complicated workflow to avoid problems they can cause. I am not 100% sure of OpenRefine's plans here, but I think you have a lot of similar needs to what I expressed in my comment on Phabricator just now at https://phabricator.wikimedia.org/T224214#7846111 I suggested a way of how this could be implemented in the MediaWiki API. Would be great if the OpenRefine team could also comment on that ticket from your perspective to help WMF prioritize. |
On my side I was just planning to add the SDC straight after uploading the file (indeed with two API actions, which is a priori not a big deal for us, although I can totally see the point of wanting a single API action). |
@DominicBM I also felt the same way and agree the 2 step approach, while aligned to file transport mechanisms with HTTP/FTP on the far backend, does run the risk of putting things "out of sync". |
@lozanaross could you post a link to your wireframes for this workflow? |
@wetneb Yes - so to answer some of the comments above, I've now closed & updated the phabricator issue, which somehow was lingering even though the results of the research were published a long time ago. For what you're describing here - i.e. how the API calls work "in the background" - I'm not sure what wireframes are best to be linked - wireframes only show the "user-facing" side of things, not how things are done in the background. We have the "lo-fi" versions which were published back in January & linked to in the midpoint report and the phabricator ticket now. And we have the "high-fi" versions, but they are more about presenting distinct design patterns than showing a complete workflow. I'll be updating these anyway, based on some of the feedback from the recent user sessions + survey. Should have a new and more complete version next week. |
@lozanaross Thanks, very helpful |
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
* Initial support for file upload. Closes #4682.
When editing MediaInfo entities, we should also be able to create new ones. As a first prototype, we would add a field to specify a path to a local file (to be then generalized to remote URLs), which:
This interface would then be aligned to @lozanaross' design, which requires the introduction of a notion of template.
This will cover the generation of Wikitext.
The text was updated successfully, but these errors were encountered: