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 <[email protected]> > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments > http://www.wikilovesmonuments.eu >
_______________________________________________ Wiki Loves Monuments mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.eu
