User:Aude/Multimedia
Uploading[edit]
- 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[edit]
- 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[edit]
- 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[edit]
- 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[edit]
- 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[edit]
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[edit]
- Global Usage Extension enabled on Commons