Hi,
I would like to uhhh... start the discussion? ask for opinions? about the future of UploadWizard.
It is a rather special extension, that was from the start made mostly for Commons' very specific needs and getting it to work anywhere else presents some challenges (some of which I attempt to tackle here https://phabricator.wikimedia.org/T256616). Interestingly, it still is used by many third-party wikis https://wikiapiary.com/wiki/Extension:Upload_Wizard and although some of them don't need its full set of capabilities related to describing licenses, authors and sources, there are wikis that do need that. The wiki I maintain, Nonsensopedia, has a Commons-like file description system based on Semantic MediaWiki (see example here https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg) and UploadWizard has been a *blessing* for us, greatly simplifying the task of file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the authorship of files that they use, to meet the licensing requirements. IMO Wikimedia Foundation as the maintainer of MediaWiki and a foundation dedicated to dissemination of free culture should provide a usable tool for properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained https://phabricator.wikimedia.org/T261589#6674315 since the Multimedia team was dissolved and I've been rather surprised to discover that patches improving third-party support were met with uhm... very limited enthusiasm? https://phabricator.wikimedia.org/T256616#6264584 There are a few obvious features lacking like mobile support (seriously, try opening https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen device, it's been like this since.. always) and configurability (you have to jump through some serious hoops https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl to just add a license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want to embark on something that will be rendered redundant or obsolete in a year, so my question is: are there any plans for UploadWizard? What makes me suspect that things may change is primarily Structured Data on Wikimedia Commons, which in the future will maybe (?) supersede the description system around the {{Information}} template. Are there any rough roadmaps or outlines of anything resembling a plan for that? If Commons was to implement full, structured file descriptions in the upload tool, that code would be probably hardly usable outside Commons, given that Wikibase is not something easy to install or maintain, it is also awfully overkill for the vast majority of applications. In such a situation, would it make sense to consider completely separating the "Wikimedia Commons Shiny Upload Tool" from a more general extension that would be usable for third parties, stripped of any Commons-specific code? A lot of things could be much simplified if the extension was to target just the needs of third parties and not Commons.
I ask about this because I really don't see any sort of interest of the extension's *de facto* owner (and that is WMF) in developing it, there are also no public plans for it, as far as I know. Yes, I can make a fork anytime, but first I'd prefer to know if I'm not missing something. Well, actually, I already did make a fork of UW https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa over a year ago, but this particular version of it is tailored for a wiki I manage, making it useless for others. At the time that was the only reasonable way we could get a good upload tool that was capable of properly describing licensing information. I probably don't have to tell seasoned open-source developers why this type of approach is not optimal for the future of the project. :)
Any opinions on the topic are very welcome.
-- Ostrzyciel (he/him)
As the deafening silence of this thread probably shows, a discussion is not really possible. The WMF has had 0 interest in making uploads easier in the last few years.
To be fair, faced with furios opposition from the Commons community for even basic improvements such as allowing imports from other sites except Flickr and requests to stop cross-wiki uploads, this decision does not seem out of place.
As one of the few people that has enabled UW in another Wikimedia wiki, I would like to encourage you to follow on your plan to improve the wizard as much as possible. Plans at the WMF change often and not necessarily for the better. A responsive design would be awsome news for wikis that need to guide their users through the mess that is freedom of panorama.
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
Andrei
Pe duminică, 31 ianuarie 2021, Ostrzyciel Nożyczek < ostrzycielnozyczek@gmail.com> a scris:
Hi,
I would like to uhhh... start the discussion? ask for opinions? about the future of UploadWizard.
It is a rather special extension, that was from the start made mostly for Commons' very specific needs and getting it to work anywhere else presents some challenges (some of which I attempt to tackle here https://phabricator.wikimedia.org/T256616). Interestingly, it still is used by many third-party wikis https://wikiapiary.com/wiki/Extension:Upload_Wizard and although some of them don't need its full set of capabilities related to describing licenses, authors and sources, there are wikis that do need that. The wiki I maintain, Nonsensopedia, has a Commons-like file description system based on Semantic MediaWiki (see example here https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg) and UploadWizard has been a *blessing* for us, greatly simplifying the task of file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the authorship of files that they use, to meet the licensing requirements. IMO Wikimedia Foundation as the maintainer of MediaWiki and a foundation dedicated to dissemination of free culture should provide a usable tool for properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained https://phabricator.wikimedia.org/T261589#6674315 since the Multimedia team was dissolved and I've been rather surprised to discover that patches improving third-party support were met with uhm... very limited enthusiasm? https://phabricator.wikimedia.org/T256616#6264584 There are a few obvious features lacking like mobile support (seriously, try opening https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen device, it's been like this since.. always) and configurability (you have to jump through some serious hoops https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl to just add a license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want to embark on something that will be rendered redundant or obsolete in a year, so my question is: are there any plans for UploadWizard? What makes me suspect that things may change is primarily Structured Data on Wikimedia Commons, which in the future will maybe (?) supersede the description system around the {{Information}} template. Are there any rough roadmaps or outlines of anything resembling a plan for that? If Commons was to implement full, structured file descriptions in the upload tool, that code would be probably hardly usable outside Commons, given that Wikibase is not something easy to install or maintain, it is also awfully overkill for the vast majority of applications. In such a situation, would it make sense to consider completely separating the "Wikimedia Commons Shiny Upload Tool" from a more general extension that would be usable for third parties, stripped of any Commons-specific code? A lot of things could be much simplified if the extension was to target just the needs of third parties and not Commons.
I ask about this because I really don't see any sort of interest of the extension's *de facto* owner (and that is WMF) in developing it, there are also no public plans for it, as far as I know. Yes, I can make a fork anytime, but first I'd prefer to know if I'm not missing something. Well, actually, I already did make a fork of UW https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa over a year ago, but this particular version of it is tailored for a wiki I manage, making it useless for others. At the time that was the only reasonable way we could get a good upload tool that was capable of properly describing licensing information. I probably don't have to tell seasoned open-source developers why this type of approach is not optimal for the future of the project. :)
Any opinions on the topic are very welcome.
-- Ostrzyciel (he/him)
That comment may be referring to improving the core uploader so the extension can be depreciated.
Has UW gone under a code stewardship request?
On Thu, 4 Feb 2021, 8:33 am Strainu, strainu10@gmail.com wrote:
As the deafening silence of this thread probably shows, a discussion is not really possible. The WMF has had 0 interest in making uploads easier in the last few years.
To be fair, faced with furios opposition from the Commons community for even basic improvements such as allowing imports from other sites except Flickr and requests to stop cross-wiki uploads, this decision does not seem out of place.
As one of the few people that has enabled UW in another Wikimedia wiki, I would like to encourage you to follow on your plan to improve the wizard as much as possible. Plans at the WMF change often and not necessarily for the better. A responsive design would be awsome news for wikis that need to guide their users through the mess that is freedom of panorama.
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
Andrei
Pe duminică, 31 ianuarie 2021, Ostrzyciel Nożyczek < ostrzycielnozyczek@gmail.com> a scris:
Hi,
I would like to uhhh... start the discussion? ask for opinions? about the future of UploadWizard.
It is a rather special extension, that was from the start made mostly for Commons' very specific needs and getting it to work anywhere else presents some challenges (some of which I attempt to tackle here https://phabricator.wikimedia.org/T256616). Interestingly, it still is used by many third-party wikis https://wikiapiary.com/wiki/Extension:Upload_Wizard and although some of them don't need its full set of capabilities related to describing licenses, authors and sources, there are wikis that do need that. The wiki I maintain, Nonsensopedia, has a Commons-like file description system based on Semantic MediaWiki (see example here https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg) and UploadWizard has been a *blessing* for us, greatly simplifying the task of file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the authorship of files that they use, to meet the licensing requirements. IMO Wikimedia Foundation as the maintainer of MediaWiki and a foundation dedicated to dissemination of free culture should provide a usable tool for properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained https://phabricator.wikimedia.org/T261589#6674315 since the Multimedia team was dissolved and I've been rather surprised to discover that patches improving third-party support were met with uhm... very limited enthusiasm? https://phabricator.wikimedia.org/T256616#6264584 There are a few obvious features lacking like mobile support (seriously, try opening https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen device, it's been like this since.. always) and configurability (you have to jump through some serious hoops https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl to just add a license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want to embark on something that will be rendered redundant or obsolete in a year, so my question is: are there any plans for UploadWizard? What makes me suspect that things may change is primarily Structured Data on Wikimedia Commons, which in the future will maybe (?) supersede the description system around the {{Information}} template. Are there any rough roadmaps or outlines of anything resembling a plan for that? If Commons was to implement full, structured file descriptions in the upload tool, that code would be probably hardly usable outside Commons, given that Wikibase is not something easy to install or maintain, it is also awfully overkill for the vast majority of applications. In such a situation, would it make sense to consider completely separating the "Wikimedia Commons Shiny Upload Tool" from a more general extension that would be usable for third parties, stripped of any Commons-specific code? A lot of things could be much simplified if the extension was to target just the needs of third parties and not Commons.
I ask about this because I really don't see any sort of interest of the extension's *de facto* owner (and that is WMF) in developing it, there are also no public plans for it, as far as I know. Yes, I can make a fork anytime, but first I'd prefer to know if I'm not missing something. Well, actually, I already did make a fork of UW https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa over a year ago, but this particular version of it is tailored for a wiki I manage, making it useless for others. At the time that was the only reasonable way we could get a good upload tool that was capable of properly describing licensing information. I probably don't have to tell seasoned open-source developers why this type of approach is not optimal for the future of the project. :)
Any opinions on the topic are very welcome.
-- Ostrzyciel (he/him)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4/2/21 6:33 am, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
I guess it means this: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Upload.Dialog
Which I think is only used in the WikiEditor extension. Maybe the dialog is in core because there was a plan to move WikiEditor into core?
While we're at, I would like to mention that these upload dialogs really don't help with enforcing any kind of image description standard. They allow users to just drag and drop files, which is intuitive and nice, but also does not ask them to specify the source of the media. In my practice, this leads to users just ignoring the wiki's rules and throwing in whatever media they find. We actually hacked both WikiEditor and VisualEditor to disable these upload dialogs and redirect people straight to UploadWizard, so that any kind of standard could be enforced.
To be honest, I'm rather surprised that nobody on e.g. enwikipedia has picked up on this issue. They have a complex wizard in place https://en.wikipedia.org/wiki/Wikipedia:File_Upload_Wizard, full of explanations of what is free and non-free media, where to upload it and under what circumstances it can be used. These simple upload dialogs in the editor lack this back-and-forth dialog with the user, explaining rules and asking for information, step by step. Also, that enwikipedia non-free wizard looks very much like a simplified version of UW, which just shows how much needed is a robust solution to uploading media with precise descriptions.
czw., 4 lut 2021 o 03:55 Sam Wilson sam@samwilson.id.au napisał(a):
On 4/2/21 6:33 am, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
I guess it means this: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Upload.Dialog
Which I think is only used in the WikiEditor extension. Maybe the dialog is in core because there was a plan to move WikiEditor into core?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2021-02-03 23:33, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
It's accessible from both the visual and wikitext editors (unless you disabled the toolbar), though their dialogs to insert image thumbnails.
În joi, 4 feb. 2021 la 16:54, Bartosz Dziewoński matma.rex@gmail.com a scris:
On 2021-02-03 23:33, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
It's accessible from both the visual and wikitext editors (unless you disabled the toolbar), though their dialogs to insert image thumbnails.
Thanks to all who enlightened me. :)
We're basically talking cross-wiki uploader here in the Wikimedia world (although I'm sure it can be used for other things). I agree with Ostrzyciel's assessment that it lets anyone upload anything - that's what prompted the request to disable cross-wiki uploads in the first place. The UW, in collaboration with campaigns, remains the most powerful web uploader the Wikimedia community currently has.
Strainu
-- Bartosz Dziewoński
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey Folks, I just wanted to flag that we heard the question and had circle up to get you an informed answer as the answer spans several teams. The most literal answer to Ostrzyciel's email is: "no, there are no plans or resources allocated to doing anything other than fix breaking upload wizard bugs on Commons". The longer answer is that we know we have to improve the upload wizard and it's a matter of resourcing and prioritization. The caveat is that it is unlikely that the WMF will work on an upload wizard that is specific to the needs of 3rd party wikis, anytime soon. For the Commons use case, I think it's much more likely.
Many of us in product have been pushing for a team dedicated to multimedia improvements for several years, but as I hope you can understand, other priorities have taken precedence. You are free to disagree that project X is more important than UW, as these are decisions for which there is plenty of educated opinion, but no right answer. Even on this year's community wishlist https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Multimedia_and_Commons, upload Wizard improvements did not fit in the top 5 most-voted improvements for multimedia. Again, we want to work on this, it's just that other work has been prioritized above it and, believe it or not, at our size, we are stretched pretty thinly.
I don't have the answer to the stewardship question, K Peachey. I'm copying Jean-Rene who chairs that group in case he has any insights.
Thanks,
Jon Katz Director of Product
On Thu, Feb 4, 2021 at 7:09 AM Strainu strainu10@gmail.com wrote:
În joi, 4 feb. 2021 la 16:54, Bartosz Dziewoński matma.rex@gmail.com a scris:
On 2021-02-03 23:33, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark Traceur: "It might be better to look at something (slightly) more modern, like the upload dialog in core". Does anyone know what that dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed
in
decades, except maybe for the look of the buttons. Its usability is rubbish compared to UW. Wikis used to (no, actually they still do) customize it using the uselang param,which messes with the user's settings. I can't really understand how that would be better...
The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
It's accessible from both the visual and wikitext editors (unless you disabled the toolbar), though their dialogs to insert image thumbnails.
Thanks to all who enlightened me. :)
We're basically talking cross-wiki uploader here in the Wikimedia world (although I'm sure it can be used for other things). I agree with Ostrzyciel's assessment that it lets anyone upload anything - that's what prompted the request to disable cross-wiki uploads in the first place. The UW, in collaboration with campaigns, remains the most powerful web uploader the Wikimedia community currently has.
Strainu
-- Bartosz Dziewoński
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thank you Jon for taking the time and effort to give a comprehensive answer. :) Honestly, this is what I expected and I won't question the priorities set by WMF. I'm just looking into how the UploadWizard project could be continued in the future, and with what parties involved.
Would it make sense to create a community-maintained fork of UW that would ditch Commons-specific features such as structured captions? IMO there's enough third-party interest for this to be viable and a fork would have two major advantages. First, there would be no need for WMF to be involved, so the extension could be developed at its own pace, independent of Wikimedia's strategy and work allocation. Secondly, Commons has a very large number of specific requirements that make adapting the tool to be usable by both it and third parties a rather difficult task. An example of this are image-based tutorials that are very hard to maintain, especially for small communities. Features related to Structured Data are great, but completely useless for third parties. I also wouldn't be surprised if Wikibase integration becomes stronger in the future and some other parts of the wizard could become redundant for Commons. In such a case, with a community-dedicated fork, WMF could have greater freedom when it comes to cutting features it doesn't need anymore. That last part is pure theorizing, though. :)
IMO, in this case, the potential benefits coming from making a fork outweigh the disadvantages. I see two different sets of requirements and the division between them is likely to only increase in the future.
If we were to make a fork, I have an entire backlog of features / fixes waiting to be implemented. Some of these stuck in review, some were already started, and others have been patched haphazardly locally in the past, so it's not starting from absolutely nothing. The things that I have on mind are:
- Rework config handling to make it more consistent (now only campaign configs are parsed, the main config is not) and robust (unit testing included!). - Simplify the task of including more licenses in UW (message loading based on config), add more built-in icons to make that even simpler for site admins. - Change the tutorial from an image to wikitext, which should be much easier to edit. - Restructure documentation to be third-party centric, maybe make a brief configuration guide (configuring UW now requires one to carefully study a not-so-friendly PHP file). - Add a few quick hacks to make the UI responsive, at least to some degree (that is very much possible with just CSS). The solution can be polished later. - Remove Wikibase-related code and other Wikimedia-specific stuff that will just make testing harder. - Improve configurability for all fields in the wizard, ensure sensible default settings. - Add an option to use single-language fields. Multi-language fields are unnecessary on most wikis. - Look into how different stages of UW could be streamlined / improved to make the upload process faster, especially on wikis requiring less detailed information. - Make all kinds of file description syntax configurable. - (Maybe) prepare and package a few ready-to-use configuration sets, together with the templates necessary to make it work. That would really simplify the process of bringing UW to a wiki.
...and more! This may be a bit ambitious, but I think it's doable with just a few people interested in the project and some spare time. I am certainly on board. :P
În joi, 4 feb. 2021 la 21:31, Ostrzyciel Nożyczek ostrzycielnozyczek@gmail.com a scris:
The things that I have on mind are:
Rework config handling to make it more consistent (now only campaign configs are parsed, the main config is not) and robust (unit testing included!). Simplify the task of including more licenses in UW (message loading based on config), add more built-in icons to make that even simpler for site admins. Change the tutorial from an image to wikitext, which should be much easier to edit. Restructure documentation to be third-party centric, maybe make a brief configuration guide (configuring UW now requires one to carefully study a not-so-friendly PHP file). Add a few quick hacks to make the UI responsive, at least to some degree (that is very much possible with just CSS). The solution can be polished later. Remove Wikibase-related code and other Wikimedia-specific stuff that will just make testing harder. Improve configurability for all fields in the wizard, ensure sensible default settings. Add an option to use single-language fields. Multi-language fields are unnecessary on most wikis. Look into how different stages of UW could be streamlined / improved to make the upload process faster, especially on wikis requiring less detailed information. Make all kinds of file description syntax configurable. (Maybe) prepare and package a few ready-to-use configuration sets, together with the templates necessary to make it work. That would really simplify the process of bringing UW to a wiki.
Just a quick note to say that out of the 11 items you list above, 8 would also improve the Wikimedia experience :)
Strainu
...and more! This may be a bit ambitious, but I think it's doable with just a few people interested in the project and some spare time. I am certainly on board. :P
-- Ostrzyciel (he/him) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It's also worth mentioning that WMF is early in the process of adopting vue. Hopefully we do this in a sane way, porting the good things from OOJS-UI into a centralized design system with a comprehensive component library. I mention it because you may want to keep an eye on that progress and see how your plans here might line up. I think this is the place to look: https://www.mediawiki.org/wiki/Vue.js/Migration_Project_Charter
I'll also add that you're awesome and the list of fixes you mention looks amazing :)
On Thu, Feb 4, 2021 at 5:00 PM Strainu strainu10@gmail.com wrote:
În joi, 4 feb. 2021 la 21:31, Ostrzyciel Nożyczek ostrzycielnozyczek@gmail.com a scris:
The things that I have on mind are:
Rework config handling to make it more consistent (now only campaign
configs are parsed, the main config is not) and robust (unit testing included!).
Simplify the task of including more licenses in UW (message loading
based on config), add more built-in icons to make that even simpler for site admins.
Change the tutorial from an image to wikitext, which should be much
easier to edit.
Restructure documentation to be third-party centric, maybe make a brief
configuration guide (configuring UW now requires one to carefully study a not-so-friendly PHP file).
Add a few quick hacks to make the UI responsive, at least to some degree
(that is very much possible with just CSS). The solution can be polished later.
Remove Wikibase-related code and other Wikimedia-specific stuff that
will just make testing harder.
Improve configurability for all fields in the wizard, ensure sensible
default settings.
Add an option to use single-language fields. Multi-language fields are
unnecessary on most wikis.
Look into how different stages of UW could be streamlined / improved to
make the upload process faster, especially on wikis requiring less detailed information.
Make all kinds of file description syntax configurable. (Maybe) prepare and package a few ready-to-use configuration sets,
together with the templates necessary to make it work. That would really simplify the process of bringing UW to a wiki.
Just a quick note to say that out of the 11 items you list above, 8 would also improve the Wikimedia experience :)
Strainu
...and more! This may be a bit ambitious, but I think it's doable with
just a few people interested in the project and some spare time. I am certainly on board. :P
-- Ostrzyciel (he/him) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thank you all for all the valuable input! I think I'll move forward with the fork in the second half of February (I'm a bit short on time for now). I'll notify Wikitech-l once I have a repo and a list of tasks set up. :)
As for Vue – yes, I'll definitely keep an eye on that. For now I'm postponing major UI work, as Vue + ES6 (that I heard is coming to RL, wheee) could help with that a lot.
Hi, just a quick update to let you know that I've started working on the forked extension – MediaUploader https://www.mediawiki.org/wiki/Extension:MediaUploader. Currently I'm cleaning up the codebase, renaming things and restructuring a few mechanisms, you can see the details in this task https://phabricator.wikimedia.org/T274891. I hope to have an initial release ready in a few months.
If you are interested in the project, you can help just by commenting on any of the issues https://phabricator.wikimedia.org/tag/mediauploader/ and presenting your view/experiences/requirements. Any constructive input will allow me to better understand what are the expectations for the extension and how to structure it. Help with writing code, documentation and reviewing is always welcome :) If you are unsure about where to start from, get in touch with me, I'll be happy to explain things.
wikitech-l@lists.wikimedia.org