Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns.
This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments.
The deliverable is such an application, which shall be: * A tiny autocontained program (probably in C++), with different versions for each target operating system. * Configurable defaults for uploading to Wikimedia Commons own images as cc-by-sa with given templates and categories. * The user shall be able to change the license / categories if needed. * Request the monument id for the image. * Validation of the monument identifier through a web service if available and time permits. * Basic documentation of the competition (rules and FAQ) * Contains the WLM logo somewhere. * Localisable through translatewiki.net for at least the 28 countries of [2] * Save configuration of images description for later upload. * Asynchronous upload of the images in the background.
Opinions? Improvements? Sexy names? Mentors?
All of them are welcome!
1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
Zawartość nagłówka ["Followup-To:" gmane.science.linguistics.wikipedia.technical.]
Platonides platonides@gmail.com wrote:
Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns.
Opinions? Improvements? Sexy names? Mentors?
All of them are welcome!
1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.ht...
Odder already mentions Commonist in his email, so let me expand on this (as I was fixing older Java versions to work with a more modern MediaWikis):
You have the last Java version in our SVN:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/
as well as the next generation Commonist in Scala:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist/
Scala version solved some architectural issues with the Java version.
I would definitely recommend to build on Commonist; I actually like the tool very much (I was still using old java version until recently). It has simple UI that meets *most* of the requirements.
Actually providing some sensible defaults (or even-simpler-UI) should be enough for WLM people. Commonist is actually quite customizable (a lot can be done using property files and templates),
The only thing which I really don't like in Commonist ist that actual upload phase is done together with metadata editing. Metadata weren't saved (at least in the older versions I have used) together with images (or somewhere else - images can be on R/O medium) so you would lose them if the tool was closed.
So probably there should be three phases:
(1) metadata management/editing (that includes some defaults for WLM folk)
(2) actual upload/sync (Commonist has ability to re-upload).
(3) obtaining upload results and letting users to decide what to do with problems (force re-upload etc.)
Some users with very limited upstream bandwidth reported quite good results with Commonist when needing to upload lots of images and having to leave computer working overnight to actually transfer them.
And there is one feature that actually huge majority of people liked - Commonist can be launched from the webpage as the Java Webstart application, so - from the user's perspective - you don't really need to "install" it on your computer. I've even talked to some who didn't realize really it was a separate application, it just magically worked for them out of the browser. Huge advantage.
So from my POV - +1 for taking Commonist to the next level, even if this means learning Scala.
//Saper
Greetings,
Thank you for your work on this and interest in this year's GSOC.
Have you had a chance to write up a proposal on the MW.org wiki? https://www.mediawiki.org/wiki/GSOC#Student_applications
It would be helpful, just to avoid confusion, what OSes you plan to support once completed.
-greg aka varnent
On Apr 4, 2012, at 7:40 PM, Platonides platonides@gmail.com wrote:
Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns.
This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments.
The deliverable is such an application, which shall be:
- A tiny autocontained program (probably in C++), with
different versions for each target operating system.
- Configurable defaults for uploading to Wikimedia Commons
own images as cc-by-sa with given templates and categories.
- The user shall be able to change the license / categories
if needed.
- Request the monument id for the image.
- Validation of the monument identifier through a web
service if available and time permits.
- Basic documentation of the competition (rules and FAQ)
- Contains the WLM logo somewhere.
- Localisable through translatewiki.net for at least the
28 countries of [2]
- Save configuration of images description for later upload.
- Asynchronous upload of the images in the background.
Opinions? Improvements? Sexy names? Mentors?
All of them are welcome!
1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gregory Varnum wrote:
Greetings,
Thank you for your work on this and interest in this year's GSOC.
Have you had a chance to write up a proposal on the MW.org wiki? https://www.mediawiki.org/wiki/GSOC#Student_applications
Hello Greg, I've copied it now at https://www.mediawiki.org/wiki/User:Platonides/GSOC_proposal
This is a wiki page. I encourage everyone* to edit it adding whatever the requisites they think should be fullfilled by such an application
*Specially those organizing the WLM contest at the different levels.
It would be helpful, just to avoid confusion, what OSes you plan to support once completed.
-greg aka varnent
The ideal target are Windows, Linux and Mac, but development for the latter will be mostly theoretical (as in "this code _should_ work"), as I don't personally have a Mac OS computer, so I wouldn't be able to test it myself.
Best regards
Thank you for the info - I would suggest including the other info on your wiki page that's outlined here: https://www.mediawiki.org/wiki/Summer_of_Code_2012/Application_template
-greg
On Apr 5, 2012, at 11:53 AM, Platonides platonides@gmail.com wrote:
Gregory Varnum wrote:
Greetings,
Thank you for your work on this and interest in this year's GSOC.
Have you had a chance to write up a proposal on the MW.org wiki? https://www.mediawiki.org/wiki/GSOC#Student_applications
Hello Greg, I've copied it now at https://www.mediawiki.org/wiki/User:Platonides/GSOC_proposal
This is a wiki page. I encourage everyone* to edit it adding whatever the requisites they think should be fullfilled by such an application
*Specially those organizing the WLM contest at the different levels.
It would be helpful, just to avoid confusion, what OSes you plan to support once completed.
-greg aka varnent
The ideal target are Windows, Linux and Mac, but development for the latter will be mostly theoretical (as in "this code _should_ work"), as I don't personally have a Mac OS computer, so I wouldn't be able to test it myself.
Best regards
Platonides,
I think the application should be compiled on the most cross-platform binary format possible and, at the moment, that is Java.
Any other will imply unnecessary maintenance.
I also agree to derive the work from Commonist (I don't know it yet).
-NT
Em 05-04-2012 00:40, Platonides escreveu:
- A tiny autocontained program (probably in C++)
I have a tendency to do everything web-based; what about doing the interface in HTML, and doing it native using a simple Qt WebView? A JavaScript C++ interface could do the communications with the server. And doing the interface in HTML is much simpler than native Qt (personally).
Joan Creus.
2012/4/6 Nuno Tavares nuno.tavares@wikimedia.pt
Platonides,
I think the application should be compiled on the most cross-platform binary format possible and, at the moment, that is Java.
Any other will imply unnecessary maintenance.
I also agree to derive the work from Commonist (I don't know it yet).
-NT
Em 05-04-2012 00:40, Platonides escreveu:
- A tiny autocontained program (probably in C++)
______________________________**_________________ Wiki Loves Monuments mailing list WikiLovesMonuments@lists.**wikimedia.orgWikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/**wikilovesmonumentshttps://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.**eu http://www.wikilovesmonuments.eu
On 06/04/12 13:09, Nuno Tavares wrote:
Platonides,
I think the application should be compiled on the most cross-platform binary format possible and, at the moment, that is Java.
Any other will imply unnecessary maintenance.
I don't think having a single binary is a big win. Users are already used to download different versions a for Windows/Linux/Mac, and we can easily guess their platform to suggest the most likely one.
Java is cool for web applets but it's hard to run in the desktop. We can't provide instructions like: Download the linked file to your desktop Go to Start menu -> run, type cmd.exe and type: cd Desktop C:\Program files\Java\jre3.14\bin\javaw.exe" -jar uploader.jar
We can't provide a batch file to run it either, as we don't know the path where java is installed, even assuming that it's there somewhere (which they may not have, adding more complexity to the instructions and download time). A business IT department can deploy a common jre to all the company computers and provide a good-looking shortcut which points to fixed paths to the jre and the jar, but we're targetting the masses here.
I also agree to derive the work from Commonist (I don't know it yet).
I took a look at it, but so fat I'm unimpressed. I couldn't compile the scala one, so I went with the java version. Then I had to disable my locale because otherwise it didn't even start. The account login doesn't work (probably because it uses an old way to login, but it's still annoying). And the interface doesn't give me cool feelings either. It's interesting as an inspiration, and I'm sure it works well for people which already prepared a folder with all the files to upload, but i don't think it'd appeal our photographers. It's also a bit confusing, for instance I don't know how are the two description fields used (are they concatenated? the specific replaces the general one?). However, I admit that good UIs are hard. It's possible I wouldn't be able to produce a better one :)
Those of you familiar with them, can you describe its strong points?
Best regards
On 06-04-2012 14:23, Platonides wrote:
On 06/04/12 13:09, Nuno Tavares wrote:
Platonides,
I think the application should be compiled on the most cross-platform binary format possible and, at the moment, that is Java.
Any other will imply unnecessary maintenance.
I don't think having a single binary is a big win.
Well, the win is specially on the maintenance (both the code and the compiling). We have to keep in mind that we don't have teams focusedo n maintaining it. And you, like me, should know that time is such a precious thing, and it is always lacking...
..so yes, I still believe we would have a big win in having a single branch of code and distribution.
Furthermore, I could bet that you'll find more easily skilled Java developers willing to join you (refer to the Commonist community?), rather than C++, but this is really a wild guess...
Java is cool for web applets but it's hard to run in the desktop.
As you (should) know, I'm not a fundamentalist, but I totally disagree with you on this statement.
I wonder why you didn't think of including the JRE along with the application - although I hardly believe there is someone without the JRE installed :-)
I also agree to derive the work from Commonist (I don't know it yet).
I took a look at it, but so fat I'm unimpressed.
When I refered to "derivation" I meant to use their code, you can just add the JAR into your classpath and reuse the objects. That should give us a kick start....
On Apr 5, 2012, at 1:40 AM, Platonides wrote:
Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns.
This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments.
The deliverable is such an application, which shall be:
- A tiny autocontained program (probably in C++), with
different versions for each target operating system.
- Configurable defaults for uploading to Wikimedia Commons
own images as cc-by-sa with given templates and categories.
- The user shall be able to change the license / categories
if needed.
- Request the monument id for the image.
- Validation of the monument identifier through a web
service if available and time permits.
- Basic documentation of the competition (rules and FAQ)
- Contains the WLM logo somewhere.
- Localisable through translatewiki.net for at least the
28 countries of [2]
- Save configuration of images description for later upload.
- Asynchronous upload of the images in the background.
Opinions? Improvements? Sexy names? Mentors?
All of them are welcome!
1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
Blame me for loving front-end technology, but maybe one of these ideas are useful to you:
* Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins)
* Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension or a standalone web application. Or extend / improve UploadWizard.
* If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application, also very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc.
-- Krinkle
[1] disclaimer, disclaimer, ..
On 06/04/12 16:03, Krinkle wrote:
Blame me for loving front-end technology, but maybe one of these ideas are useful to you:
No blame, I welcome your insights, Krinkle :)
- Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins)
I'd prefer not to hardcode anything WLM-specific, but maybe there's a killer feature hard to do without it. Maybe I can get all WLM-specific things in a module, and have the application linkable with a different one. I've added a note about it at the application page.
- Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension or a standalone web application. Or extend / improve UploadWizard.
I don't find UploadWizard comprehensible enough to extend it :) We could have a web application which stored the image preferences at localStorage (not as good as an actual file, but could work), but I don't think we could load the submtited filenames from a previous run (nor would be too safe for a spec to allow that). It might be possible in Firefox by requesting higher privileges.
- If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application, also very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc.
Isn't that based on Flash? Had you proposed Prism... Still, the overhead of these approaches seems too big. Also, Adobe Air seem to have discontinued their Linux support, and reliance on that propietary system doesn't seem like a good idea.
Hi all, This sounds like a nice idea (and I love Commonist), but what happened to the idea of WLM-specific improvements for the default uploader? I like the idea of using the default uploader as much as possible, and it would be great to extend the now hard-coded maximum of 10 files per upload. I agree on the meta data bit, and how about this: If the user is instructed to name the file in a standard format, then the "mass-upload function" will recognize this and interpret accordingly.
Let's say for example I go to a rijksmonument and take pictures of the inside and outside and have at the end of the day about 40 pictures I find useful for commons. I still have a lot of work to do before I can upload them, but if I am instructed, I can rename them to include the RM number, the artist data (if it involves sculptures done by an artist) the artwork data (if it is an architectural work of art) and so forth.
This approach means that we could make easy upload instructions for street-walks doing just facade works for WLM, but also make it easy for people who have photographed a set of artworks inside such buildings.
Jane
2012/4/6 Platonides platonides@gmail.com
On 06/04/12 16:03, Krinkle wrote:
Blame me for loving front-end technology, but maybe one of these ideas are useful to you:
No blame, I welcome your insights, Krinkle :)
- Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins)
I'd prefer not to hardcode anything WLM-specific, but maybe there's a killer feature hard to do without it. Maybe I can get all WLM-specific things in a module, and have the application linkable with a different one. I've added a note about it at the application page.
- Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension or
a
standalone web application. Or extend / improve UploadWizard.
I don't find UploadWizard comprehensible enough to extend it :) We could have a web application which stored the image preferences at localStorage (not as good as an actual file, but could work), but I don't think we could load the submtited filenames from a previous run (nor would be too safe for a spec to allow that). It might be possible in Firefox by requesting higher privileges.
- If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application, also very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc.
Isn't that based on Flash? Had you proposed Prism... Still, the overhead of these approaches seems too big. Also, Adobe Air seem to have discontinued their Linux support, and reliance on that propietary system doesn't seem like a good idea.
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.eu
Theuploader is truly painful, is the 10 image limit definitely hardcoded or is it just a bug that makes the whole thing crash if you try and load more than ten images?
One of the changes that would make the uploader more helpful would be to have some metadata that you could put into the batch and which would then replicate itself on every image. If you are uploading a batch of photos about one monument then you might well have taken them all on the same day, want to put them all in the same categories and even have a common sentence or two to start every description in the batch. Of course if it was done in a way that made it even slower or more likely to crash then we'd be back where we are now.
As it is I'm struggling to justify putting images onto Commons when it is so much easier, and more reliable to bung them on Facebook. I suppose I'm insufficiently masochistic for the Commons uploader.
WereSpielChequers
On 7 April 2012 08:21, Jane Darnell jane023@gmail.com wrote:
Hi all, This sounds like a nice idea (and I love Commonist), but what happened to the idea of WLM-specific improvements for the default uploader? I like the idea of using the default uploader as much as possible, and it would be great to extend the now hard-coded maximum of 10 files per upload. I agree on the meta data bit, and how about this: If the user is instructed to name the file in a standard format, then the "mass-upload function" will recognize this and interpret accordingly.
Let's say for example I go to a rijksmonument and take pictures of the inside and outside and have at the end of the day about 40 pictures I find useful for commons. I still have a lot of work to do before I can upload them, but if I am instructed, I can rename them to include the RM number, the artist data (if it involves sculptures done by an artist) the artwork data (if it is an architectural work of art) and so forth.
This approach means that we could make easy upload instructions for street-walks doing just facade works for WLM, but also make it easy for people who have photographed a set of artworks inside such buildings.
Jane
2012/4/6 Platonides platonides@gmail.com
On 06/04/12 16:03, Krinkle wrote:
Blame me for loving front-end technology, but maybe one of these ideas are useful to you:
No blame, I welcome your insights, Krinkle :)
- Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins)
I'd prefer not to hardcode anything WLM-specific, but maybe there's a killer feature hard to do without it. Maybe I can get all WLM-specific things in a module, and have the application linkable with a different one. I've added a note about it at the application page.
- Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension
or a
standalone web application. Or extend / improve UploadWizard.
I don't find UploadWizard comprehensible enough to extend it :) We could have a web application which stored the image preferences at localStorage (not as good as an actual file, but could work), but I don't think we could load the submtited filenames from a previous run (nor would be too safe for a spec to allow that). It might be possible in Firefox by requesting higher privileges.
- If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application,
also
very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc.
Isn't that based on Flash? Had you proposed Prism... Still, the overhead of these approaches seems too big. Also, Adobe Air seem to have discontinued their Linux support, and reliance on that propietary system doesn't seem like a good idea.
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.eu
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.eu
On 07/04/12 15:53, WereSpielChequers wrote:
Theuploader is truly painful, is the 10 image limit definitely hardcoded or is it just a bug that makes the whole thing crash if you try and load more than ten images?
No crash. I think the "Add another file" button disabled itself after adding 10 files. I'm not seeing this limit now, though. It may have been lifted.
One of the changes that would make the uploader more helpful would be to have some metadata that you could put into the batch and which would then replicate itself on every image. If you are uploading a batch of photos about one monument then you might well have taken them all on the same day, want to put them all in the same categories and even have a common sentence or two to start every description in the batch. Of course if it was done in a way that made it even slower or more likely to crash then we'd be back where we are now.
Yes, I've been considering that. If you have a group of images of the same monument, you want the monument id and base description replicated automatically. However, you might also have several unrelated images, or two groups of monuments. I don't know how to make those different usecases into a UI.
As it is I'm struggling to justify putting images onto Commons when it is so much easier, and more reliable to bung them on Facebook. I suppose I'm insufficiently masochistic for the Commons uploader.
Can you describe Facebook uploader? What makes it easier? How is it more reliable?
Thanks
On 07/04/12 16:45, Platonides wrote:
No crash. I think the "Add another file" button disabled itself after adding 10 files. I'm not seeing this limit now, though. It may have been lifted.
It was increased on 30th September 2011:
Author: Neil Kandalgaonkar Date: Fri Sep 30 21:07:08 2011 +0000
up max number of uploads per wizard run to 50. this limit was setarbitrarily, so I am arbitrarily increasing it
Are we fine with that number? I can arbitrarily increase it again if needed.
On 7 April 2012 15:45, Platonides platonides@gmail.com wrote:
On 07/04/12 15:53, WereSpielChequers wrote:
Theuploader is truly painful, is the 10 image limit definitely hardcoded or is it just a bug that makes the whole thing crash if you try and load more than ten images?
No crash. I think the "Add another file" button disabled itself after adding 10 files. I'm not seeing this limit now, though. It may have been lifted.
One of the changes that would make the uploader more helpful would be to have some metadata that you could put into the batch and which would then replicate itself on every image. If you are uploading a batch of photos about one monument then you might well have taken them all on the same day, want to put them all in the same categories and even have a common sentence or two to start every description in the batch. Of course if it was done in a way that made it even slower or more likely to crash then we'd be back where we are now.
Yes, I've been considering that. If you have a group of images of the same monument, you want the monument id and base description replicated automatically. However, you might also have several unrelated images, or two groups of monuments. I don't know how to make those different usecases into a UI.
I'd suggest defaulting all the subsequent files to the categories of the first in the batch, alternatively a little toggle - "copy description and categories from first image" would save a lot of work
As it is I'm struggling to justify putting images onto Commons when it is so much easier, and more reliable to bung them on Facebook. I suppose I'm insufficiently masochistic for the Commons uploader.
Can you describe Facebook uploader? What makes it easier? How is it more reliable?
The ability to upload more images into the same gallery means that you don't have to keep repeating the same metadata.
When I'm uploading images into Facebook it asks me if I want to upload from the last directory I uploaded images from. When I upload images into commons I have to point and click through half a dozen directories for each image, even if all the images I'm uploading in that batch are in the same directory.
It is more reliable for me in the sense that I've uploaded dozens of images into Facebook without a failure. By contrast some images uploaded to commons will come up as empty files, othertimes Firefox crashes in mid upload and I lose everything
Thanks for asking, sorry if I sound snappy but I recently had a spectacularly bad experience trying to upload images.
WereSpielChequers
Thanks
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.eu
On 07/04/12 16:58, WereSpielChequers wrote:
The ability to upload more images into the same gallery means that you don't have to keep repeating the same metadata.
When I'm uploading images into Facebook it asks me if I want to upload from the last directory I uploaded images from. When I upload images into commons I have to point and click through half a dozen directories for each image, even if all the images I'm uploading in that batch are in the same directory.
That's odd. When I go to upload a new file, both from Special:Upload and Special:UploadWizard, it shows me the dialog in the last folder from which I uploaded. It may be that your browser doesn't respect that, but it seems the logic thing to do, and you seem to be using Firefox, too.
It is more reliable for me in the sense that I've uploaded dozens of images into Facebook without a failure. By contrast some images uploaded to commons will come up as empty files, othertimes Firefox crashes in mid upload and I lose everything
Interesting, I don't think Firefox has crashed to me in years. I do remember some cases when trying to upload very big files failed with an error talking about an "empty file", though.
Thanks for asking, sorry if I sound snappy but I recently had a spectacularly bad experience trying to upload images.
With no feedback, how would we be aware of those problems?
Best regards
my 2 cts, I really like the new google picture uploader, cant we have something like for mediawiki? it is really simple and easy to use. mike
wikilovesmonuments@lists.wikimedia.org