TheDJ
Userboxes | ||
---|---|---|
|
Babel user information | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
Users by language |
Scripts
edit- User:TheDJ/tabularImportExport.js - A script to import CSV or Excel files into Tabular Data.
Problem list
edit- Consider hiding mw-filepage-other-resolutions on mobile under 720px wide (clutters, not really as useful as on desktop)
- {{Information}} has plain table cells for the row headers. These should be th / ! with a scope="row"
- {{Information}} is 100% wide, but does not have box-sizing: border-box; set.
- {{Information}} uses the cellpadding attribute.
- {{Location}} is 100% wide, but does not have box-sizing: border-box; set.
- {{Location}} does not vertical-align:top it's header
- {{Location}} uses deprecated cellpadding attribute
- {{Assessments}} is 100% wide, but does not have box-sizing: border-box; set.
- {{Assessments}}, can probably use autotranslate, so we could do away with that ugly list of languages ?
- {{Picture of the day}} is 100% wide, but does not have box-sizing: border-box; set.
- {{Picture of the day}} uses JS translations, which don't work on mobile.
- {{VI}} is 100% wide, but does not have box-sizing: border-box; set.
- {{VI}} can probably use autotranslate, so we could do away with that ugly list of languages ?
- Commons needs massive templatestyles'ification
- Information template and licenses are all not compatible with mobile
- License templates should verify commons structured data information
- Things like {{NASA-image}} should be moved/copied to structured data
- Coordinates template + Structured Data coupling
- Concepts for derivative files, like {{Image extracted}}, {{Retouched picture}} and {{Derived from}}
- Concepts for multiple copyright owners via derivative files
Commons dev wishlist
editThe purpose of this list is for me to reduce the hundreds of items in phabricator to something more understandable. It is incomplete, evolving and personal. Commons has a maintenance and code quality problem, due to being very different from our other projects and thus requiring a certain level of domain knowledge. You need dedicated staff to learn and forward that knowledge.
Additionally, it has an audience problem. It is good in ingesting and administrating media, but bad at sharing, reusing, remixing and reporting on media. There is no vision for this and no way to execute the vision because it is such a different audience than wikipedia itself.
MediaWiki API
- Deal with the long time discrepancy with history vs current between revisions and file revisions
- Add new user right to view deleted files
- Versioned urls for thumbnails, so you won't see old thumbnails in articles after updating a file
- Add stable urls for images, to be used by InstantCommons etc (with textual links as fallback?)
- Increase supported file size beyond 4GB (major open swift work required)
- MediaHandler classes
- Make thumbnails proper fragments so that they can be connected to their CSS and JS modules (this now happens in multiple places, which is very confusing)
- allow media handlers to update the file params width/height/filetype etc when needed.
- cleanup of the File related classes, the way we split up Title/TitleValue/PageIdentity etc.
Core media items:
- Support thumbor
- Upgrade it
- Support it 24/7
- make sure dependencies regularly get upgraded
- merge outstanding patches for new formats like mpeg
- Improve chunked uploading
- Increase reliability
- Add it to Special:Upload for files that need it.
- Make the metadata api as used by MediaViewer able to source information from CommonsData
- MediaViewer itself needs some cleanup, it's 8 years old
- The metadata api has problems with several media annotations it should handle but cannot
- The
- IIF / big image support
Media format support:
- Improve SVG render support with a new renderer
- Support 360 panoramas
- Color 3D models
- GIF to video conversion
- Including a UI to play/stop gifs/videos
- Support importing and exporting of CSV/Excel to the Data namespace
- Add a better PDF viewer, which allows you to browse PDFs straight from embedded thumbnail.
- MediaHandlers should support multiple thumbnail formats. Currently you can only declare support for 1 thumbnail format. But instead of just .png, you might also want to support webp, avif, and possibly even one format in one situation, and another in the other situation (lossy vs lossless).
Video support:
- Make transcoding of A/V a standalone service
- Add support for DASH/HLS
- VTT subtitle support
- MP4 ingest, but non-publish support
Usability:
- Redesign the File page to be functional for both readers and editors
- Focus on the media
- Have a control bar (beneath the media) for share/download/embed/crop/like etc (with appropriate credits for share/embed) get rid of stockphoto gadget and assortment of text controls below the current media.
- Make Information and License templates mobile compatible
- Make information and license templates better translatable
- Add features to explore and discover data better (Frank Schulenburgs idea)
- Add features to follow collections, topics and photographers (Frank Schulenburgs idea)
- Create a holding cell for images so
- metadata can be provided after upload (opens up possibility for less experience users to contribute, especially on Mobile)
- To deal with OTRS licensing releases that need to be verified before the image can be used
- Remind users of how many images they have in holding cell and how to complete
- Admins have access to all of holding cell (to be able to deal with abuse)
- Create an embed.php endpoint for external sites to iframe media (replacing embedplayer=true)
Commons data
- Add bidirectional constraints between templates/categories and certain wikidata properties to keep them in sync
- Add better concepts for derivatives to track reuse, modification and remix and the licensing and crediting that comes with it.