User:Aude/Multimedia

Uploading

 * people don't need to be lectured extensively about copyright law
 * could use help with setting metadata, perhaps as a staging area before putting in commons
 * from editing, need to get out of editing form, go elsewhere then upload
 * also don't tell how to put image with wikitext into article
 * adding image should be single process, without moving off of edit page (e.g. add media wizard)
 * if user uploads from Flickr, it has location data, license data, etc., and don't need to ask all that from user, it is already available and can be pre-filled into upload form
 * new uploads to wikipedia should go to commons, but not need to tell user about fair use images needing to go to enwiki, others going to commons.
 * people also were hacking, michael dale on add media wizard and drag and drop upload in firefox, bryan worked on global usage extension, brion worked on extracting metadata
 * mass uploading, have a staging area where museum can check files, information
 * glam
 * commons users
 * images already on web (e.g. FEMA)
 * flickr
 * don't need to upload one-by-one (e.g. multi-upload, ftp, ...)
 * copyright verification, important for flickr
 * handle metadata, both machine readable and human-entered
 * how to organize and integrate images into wikimedia projects
 * how to interact with community to get help with organizing images, etc.
 * making bots easier to make, with shared components
 * documenting how mass uploading is done
 * capacity, have enough storage space
 * issues very specific to museums and galleries, to report back to them on how images are being used
 * also issues of role accounts, this may be needed for libraries, etc. to do uploads
 * provide recognition for institutions, through attribution and other ways
 * long uploads, perhaps unsupervised, then something goes wrong and account may get blocked; use separate account for mass upload? how to manage all this? staging server could help address this, with wikimedian acting as a coordinator

Existing tools

 * commonist
 * commonplace
 * upload api
 * kaldari's external upload tool
 * flickr (as staging area)
 * drop.io (as staging area)
 * imagecopy built by multichill
 * flickrripper - transfer multiple flickr images at once
 * custom bots, with pywikipedia, erik's upload script

Possible solutions

 * enhance commons
 * 3rd party front-end sites
 * staging server, housing files that need metadata, categories, etc. added
 * could host custom upload interfaces tailored to specific institutions
 * use client programs like commonist

Search

 * there are language "markers" that indicate what language an image description is in, would be good to utilize that
 * look at metadata embedded in files, as well if things like video subtitles
 * not have just full-text search, but search by image properties (e.g. size, format), by license
 * multi-lingual search terms

Internationalization

 * translation of user interface
 * auto-detect of language preferences is not supported
 * rtl support not available
 * translation communities are scattered and need central hub
 * page titles on commons are pretty much all in english, good to have multilingual category structures
 * file names
 * multilingual support for searching

Outreach and education
Target groups:
 * museums
 * contextualization, take content to other places, engagement, more visibility for museum to attract more visitors, re-assurance that nothing can replace the real thing.
 * libraries, wikipedia is a knowledge repository, power of volunteers (e.g. OCR on wikisource, wikimedians checking and improving metadata), wikipedians giving classes, broaden demographics of users, case study (multilingualism, annotation, disambiguation - sj; jeffdelong, saved collection while library intern)
 * archives - preservation, materials are accessible online, available in other place, metadata can be reviewed and improved, case study: durova

additional information for chapters


 * common pitfalls
 * most common objections

Wrap up

 * Global Usage Extension enabled on Commons