Page MenuHomePhabricator

Way in VisualEditor to initiate Commons file uploading, and insert image on completion
Closed, ResolvedPublic40 Estimated Story Points


Our traditional editor toolbars have buttons to insert a [[File:Foo.png]] or similar, but not that would help you with the actual editing process.

A button that launches the UploadWizard -- possibly uploading to Commons -- and ends with inserting the image(s) into the article would be a big leap forward.

User journey:

  1. User clicks on "insert media"
  2. In the dialog, user clicks on "upload new"

Screen Shot 2015-06-08 at 16.09.21.png (460×629 px, 76 KB)

… or 'User drags a file into the editor', see T40031

  1. Dialog is launched

Screen Shot 2015-06-08 at 15.59.27.png (552×475 px, 189 KB)

  1. User confirms that the media file is theirs, and accepts that it will thus be under the default licence (CC-BY-SA-3.0); file starts uploading with a progress bar (indeterminate for now)

Screen Shot 2015-06-08 at 16.10.48.png (361×385 px, 148 KB)

… or user is directed to Special:Upload if local uploads are available.

"To upload a file which cannot be freely re-used, please use the __restricted form__."

… or user is directed to Special:UploadWizard on Commons.

"To upload a file created by someone else, or under a different licence, please use the __advanced form__."

  1. User enters a title.

Screen Shot 2015-06-08 at 16.11.27.png (473×508 px, 235 KB)

  1. User enters a description (default in the user's interface language, with a control to set the language to something else).

tux.png (479×400 px, 40 KB)

  1. User optionally over-rides the date of creation from 'today'.

tux.png (479×400 px, 40 KB)

  1. User optionally enters (Commons) categories.

Screen Shot 2015-06-08 at 16.10.28.png (787×651 px, 378 KB)

  1. User clicks "Publish and Insert", and file is un-gated on the stash and published on Commons, and inserted locally as a thumb|right (or |left on RTL) at default size with the description as the caption (if the description is in the content language).

Screen Shot 2015-06-08 at 16.35.53.png (306×993 px, 291 KB)

… or user clicks "Cancel Publishing" and the file is left in the stash for garbage collection, never published.

  1. Done.

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:46 AM
bzimport set Reference to bz38030.

This is not on schedule for before the next big release; noting as such.

  • Bug 64158 has been marked as a duplicate of this bug. ***
Jdforrester-WMF set Security to None.
Jdforrester-WMF updated the task description. (Show Details)

Comments from the product pitch meeting today

  • @Esanders: inline inspectors are there for things that probably shouldn’t be easily dismissed
  • Need to think about when information should be required - some things can be postponed
  • Can we use a non-linear workflow for this? Additional information is recorded non-modally
  • Doesn’t provide any user education about what’s allowed on Commons and what’s not
    • @Jdforrester-WMF: almost all users skip straight past that page in the UploadWizard anyway

Comments from the pitch meeting last week

  • Show a preview of the image in the dialog? Easier in VE but useful for WE.
  • Licensing imposition info and user click-through
    • Let them choose? Danger of choice turning into what we have with UW?
  • Build a preview whilst you go through the steps – show where the caption will be rendered, anticipate the final result.
  • Description and caption. If we’re doing it in an article, do users have that distinction? Hard to provide them as separate things?
    • Separation between local information and global information? Do local activities after the ‘publish’ step?
    • Show caption as part of preview?
    • Just use caption as description?
    • Call out “how it will appear in the article” vs “how it will appear to re-users”?
    • Each step may have a different license, need to split them by those lines
  • Split licences – possibly CC0 for description/etc. but CC-BY-SA-3.0 [or whatever] for the image and possibly CC-BY-SA-3.0 or CC-BY-SA-4.0 or PD or … for the caption (and may be different)

I had a discussion with @Nirzar, on how we can integrate the upload dialog in core with VisualEditor. @Nirzar explained to me the expectations of the user when in VE, and how a simplified workflow would work best. @MarkTraceur was talking about a bare bones version for the first iteration too, more in my next comment. In simplifying the workflow, we wanted to cut some details currently required to upload, but aren't sure if it is acceptable from a product or legal point of view—

  1. Isolate global and local information to avoid cognitive overload.
  2. Pick sane license defaults and don't give the user too much choice
  3. Auto-categorize the image to— from-VE, or some such, making it easier to find these images on Commons.
  4. Hide where the image is going (local wiki vs commons). Inform user later that the image went to commons — Thanks for uploading to Commons. Learn More.

When uploading through VE there would be two entry points—

  1. An Add more button in the Insert Media (Media settings) dialog [1].
  2. Dropping a file into VE.

The first option would lead to the first pane of the upload dialog [2]. The second option would jump straight to the second pane [3]. For VE we'll always skip the last, Usage pane and directly insert the image on the page.

@Nirzar wanted the local editing to be more inline in VE, but, it currently opens up a dialog [4] (this isn't exactly in the purview of making upload work with VE, but deserves mentioning). We need to decide whether we want to automatically open up this dialog or let the user initiate the action.
He has also requested User Research for this workflow, but I don't know much about that yet.

  1. F1359538
  2. F1359743
  3. F1360116
  4. F1360346

Notes from #wikimedia-multimedia, with @matmarex and @MarkTraceur (logs are edited to keep only relevant messages):

1prtksxna: MatmaRex: How do I write a plugin for VE? Couldn't find any docs on mw, but I didn't try to hard…
2MatmaRex: hm
3MatmaRex: prtksxna: this doesn't seem to actually be documented, heh. there is documentation on writing plugins as gadgets ( to write them as MW extensions, it looks like you ne\
4ed to register your RL module in $wgVisualEditorPluginModules. examples are in Citoid and SyntaxHighlight_GeSHi
5MatmaRex: prtksxna: hmm, but don't we actually want to do this in VisualEditor proper?
6prtksxna: Hmmm
7MatmaRex: as i understand it:
8MatmaRex: * we have mw.Upload.Dialog in core, that provides a barebones interface suitable for small third-party wikis without weird licensing requirements
9prtksxna: I am still confused about where files go and where the user thinks they go — commons vs local wiki
10MatmaRex: * we will have an extended upload dialog in UploadWizard, that puts in the million boxes required for commons
11MatmaRex: * we will have some integration in VisualEditor, that will use UploadWizard's or core's upload dialog.
12MatmaRex: hmm.
13prtksxna: And marktraceur pointed out that the user sometimes would want to explicitly upload to the local wiki due to some licensing stuff I don't understand.
14MatmaRex: yeah, true. i hadn't considered that
15MatmaRex: so… i guess we need to make sure that mw.Upload works for cross-wiki uploads, and add a selector to mw.Upload.Dialog to let the user choose whether to upload locally, or to foreign repo, if any is confugred
16MatmaRex: i'm not sure if we can do this magically. there is $wgForeignFileRepos…
17MatmaRex: and the entries can have a 'apibase' property… so maybe
18prtksxna: How often do users make that choice? Is it a power user thing? Can we hide this complexity from the others? Maybe James_F|Away knows.
19MatmaRex: prtksxna: afaik for Wikimedia there are two cases, first is users who think Commons people are generally not nice and want nothing to do with them, and second is users who want to upload copyrighted fair-use media to the\
20 few Wikipedias that allow them (including en.wp)
21MatmaRex: largely things like movie posters, logos, book covers
22MatmaRex: it should probably default to Commons. i'm not sure how visible the option should be.
23prtksxna: So in the license picker we should be asking them if this is copyrighted fair-use media and silently switching them over to local wiki (if allowed).
24MatmaRex: hmm. that sounds neat
25prtksxna: s/./?
26MatmaRex: yeah, that actually sounds like a good idea to me, but we should check iwth marktraceur in case that's not possible for some bizzarre reason
27MatmaRex: we just need to come up with a sane way to separate this between core, VisualEditor and UploadWizard
28prtksxna: I think we'll move to the UW dialog next
29prtksxna: The VE plugin will in some cases skip the first, and last step. The file might get dropped anywhere and call the dialog, and once the save is complete we can switch back to VE instead of showing the stupid usage panel.
30marktraceur: MatmaRex, prtksxna: OK, let's see if I can clarify what I have in my head and if it makes any sense to you guys
31marktraceur: MatmaRex, prtksxna: My current priority is to get a tool into VisualEditor, and secondarily WikiEditor, that uploads a file from enwiki to Commons, with a default license choice, and sends the user to WP:FUW or COM:UW if\
32 someone doesn't like it.
33marktraceur: MatmaRex, prtksxna: I believe we can add licensing choices or whatever else (local vs. remote choice) in later iterations, I don't think they're necessary for the base case we're trying to address
34marktraceur: MatmaRex, prtksxna: I think the Commons-specific mw.Upload and mw.Upload.Dialog subclasses will go into CommonsMetadata, because I dislike the idea that UploadWizard is Commons-specific, and I even more hate the idea of \
35then loading it outside of Commons
36marktraceur: MatmaRex, prtksxna: Those classes will add fields and getters/setters for descriptions (the model will have support for multilingual, I'm not sure we ever came to a decision about that in the UI), licenses (in text form,\
37 it has no clue about them though), categories, date, locations, and so on
38marktraceur: Basically "mw.CommonsUpload" is a euphemism for "{{information}}-enabled upload model class"
39marktraceur: As well as hard-coding the mw.Api URL to
40marktraceur: I haven't yet tried to subclass mw.Upload.Dialog to add fields. That somewhat concerns me but I'll go do that now I think
41marktraceur: prtksxna, MatmaRex: Also I definitely think that the upload dialog can go into VE-mediawiki at the end
42marktraceur: Maybe we could make that more palatable by putting CommonsUpload into core, and not calling it CommonsUpload but MediaRepoUpload or something
43MatmaRex: hmm.
44MatmaRex: marktraceur: there is some precedent for hardcoding Commons in core, like $wgUseInstantCommons, so i think it could go in core. from the technical side, the only difference between uploading to Commons and any other fore\
45ign repo is just the API URL, right?
46MatmaRex: marktraceur: we might want to separate these concepts. a local upload vs foreign upload, and a simple form vs {{information}}-enabled form.
47MatmaRex: i haven't tried to subclass mw.Upload.Dialog either, but it looked well-engineered for subclassing. you override some render*() and get*() methods, and presto.
48marktraceur: Urgh. InstantCommons.
49MatmaRex: marktraceur: soo… we just put everything in core, and say "foreign file repository" when we really mean "Commons"? ;)
50marktraceur: Something like that
51marktraceur: It's what we've always done!
52MatmaRex: i think it's sensible
53MatmaRex: more than splitting the code over four places
54marktraceur: MatmaRex: "foreign file repository" almost universally means Commons, anyway
55marktraceur: At least in the context of the things that we're writing
56marktraceur: MatmaRex: I'll explore the code again with an eye towards refactoring, maybe we can get the dialog merged today at least
57MatmaRex: mw.Upload.Dialog? i just merged it. :P
58marktraceur: Oh.
59marktraceur: Well shit!
60marktraceur: Exciting times

Our first step is to make a tool that can upload a file from enwiki to commons with a default license. The local vs remote and license choices can come later.
The commons specific subclass of mw.Upload.Dialog can go to CommonsMetadata. The mw.CommonsUpload model will take care of the {{information}} template on Commons.
This new code could live in VE-mediawiki, or in core, after naming it MediaRepoUpload instead of CommonsUpload.

@Nirzar, @matmarex, @MarkTraceur, please clarify if I've missed or misunderstood anything.

Jdforrester-WMF renamed this task from VisualEditor: Button to initiate UploadWizard and insert image on completion to Button in VisualEditor to initiate Commons file uploading, and insert image on completion.Sep 21 2015, 3:32 PM
Jdforrester-WMF assigned this task to Esanders.
Jdforrester-WMF moved this task from Next up to Doing on the Multimedia board.

Change 240116 had a related patch set uploaded (by Esanders):
[WIP] Image uploading

Jdforrester-WMF renamed this task from Button in VisualEditor to initiate Commons file uploading, and insert image on completion to Way in VisualEditor to initiate Commons file uploading, and insert image on completion.Oct 2 2015, 3:38 PM
Jdforrester-WMF raised the priority of this task from Low to High.

Change 240116 merged by jenkins-bot:
Add image upload tab to media dialog