Last modified: 2011-03-13 18:06:03 UTC
Mediawiki has not been developped for manage pistures and others media. Commons is a wiki software, not a picture managed softaware. Mediwawiki is not practical to manage so many images. A new software would be adapted better. It could managed easily the license, author and others datas wich are attached with the media. The categories could be emulate, etc. We could emulate a wiki with this new softawre, like mediawiki. The aim of this new soft is better a better classification, better management, better administration, etc. Thanks for your ideas
Can you name specific things that MediaWiki is not able to do that Commons needs it to do, and provide examples of where the workarounds are clunky?
(In reply to comment #1) > Can you name specific things that MediaWiki is not able to do that Commons needs > it to do, and provide examples of where the workarounds are clunky? 1- translation of the description -> according to the language, the description will be translated in the selected language in user's preferences. All the users can translate the desc in an other language. 2- Classify easily the medias in categories : ->Select the categories in a drop-down list. (or multi lists, ie: animals -> cat-like -> tigers) An non-english speaker can't upload any file : all the desc are in english (and eventually in the uploader's mother tongue) A new softawre could resolve that and offer the possibility to translate the desc. The look is good. We can keep it (like bugzilla : a new software with the same style).
Allowing us to have a drop-down box for categories means that the category list has to be populated, which is a potentially expensive database query. I would say that, for this, the existing means of categorisation is simple enough, and allows users to create new categories without any particular fuss. The language problem is a particular Internet cliché; how would we successfully cater for several hundred languages anyway? I suppose we could attempt to detect the locale and load the appropriate version of the message from the message namespace/message store or whatever we'd call it, but that's prone to errors. I agree that there are problems with MediaWiki making it unsuitable for this use, however, but I'm not sure that we couldn't just create certain modules for use with that particular instance of the software on the Wikimedia servers. Granted, this means that the Commons instance of MediaWiki needs to be different to that of the others - see http://wp.wikidev.org/wiki/Wiki_farm for information on how it ordinarily works - but it might be worth it. Users are somewhat used to using the software we have now, and a major change could mean serious administrative and training hassle. Having said that, there is merit in your argument, so perhaps we could garner feedback from others?
Isn't Wikidata ( http://meta.wikimedia.org/wiki/Wikidata ) a solution to the problem of a software to manage images? This http://meta.wikimedia.org/wiki/Image:Wikidata-mockup.png looks close to it, and WiktionaryZ, which uses it, is already able to manage translations of the same text into several languages.
Wikidata seems to be the best solution for me too, but who codes the soft ? always the same question ! On the french Wikipédia we needs urgently structured data to describe images (medias). Currently, it's simply impossible to publish Wikipedia with images, because it's not possible to get the author automatically for each image. What about proposing more form inputs during the image upload (author, description, license, source, ...) and filling the tem plate:information with them ? Would be much work to do that? For me, that's the shortest way to organize the infos in a systematic way.
Emmanuel seconded. As it is, there are millions of pics in the wikipedias that just display some totally inane message such as "I the author of this work, release this under the GFDL". Except that unless the author has actually provided a line that states their authorship in the description, nobody has a clue who "I" is, untill they actually get tot he commons page. Mandatory structured fields would make everybody's life easier. -Author (you could have a check box that allows you to say "I". -Licence -Source need to be mandatory -Description could be optional.
I do belive MediaWiki is the right choice for commons overall, because it's very flexible and it's what people comming from otehr projects already know how to use. On the other hand, I agree that for a media repository, it would be helpful to add some functionality to mediawiki. Key boints are, as mentioned before: * structured meta data for images (autor, source, license, etc) * internationalized description texts and page titles (esp. Category names) * A "smart" media search, allowing searches by file type, image resolution, license, etc I believe that all this can and should be integrated into mediawiki (or appropriate extensions). Maybe we should have a "tracker bug" for all things related to commons/media, and concentrate the efforts.
(In reply to comment #6) > Emmanuel seconded. As it is, there are millions of pics in the wikipedias that > just display some totally inane message such as "I the author of this work, > release this under the GFDL". Except that unless the author has actually > provided a line that states their authorship in the description, nobody has a > clue who "I" is, untill they actually get tot he commons page. This is [[bugzilla:3283]]. (In reply to comment #7) Maybe we should have a "tracker bug" for all things > related to commons/media, and concentrate the efforts. See http://commons.wikimedia.org/wiki/Commons:Bugs .
I have just been thinking about this lately, and I think one of the most immediate and useful things we could to is improve the search. Most searches on Commons would be for images, I would guess, and most searches would not have a corresponding article (just because we're not really that organised). The search output, then, is a list of text descriptions. There should really be an option to view it as a gallery. (maybe have text snippet in the gallery caption??) There is a gallery view in the search at Special:Newimages. But this search is very strange (I think it only searches image titles, and it will match partial strings like "foo" in "food", which is usually undesirable). So basically I think a gallery option should be added to the Commons' search, if not as default then as a one-click-away option. thanks!
I think we need a MediaWiki II - one that is actually developed to primarily handle media. At the moment the name MediaWiki is more ironic than descriptive. The main three things are: hugely improved search (thus requiring more structured metadata to be stored); a combined category/gallery thing to replace existing categories and articles; and proper multilingual support by better category RDRing/aliasing. Here are some fields I would like to be able to search by: Media type: image, audio, video, document/other File type: jpg, png, svg, gif, etc Uploader Date uploaded Date created License type (select or exclude any combo) Keywords (search in filename and/or description) Categories (a la MediaSearch) File size for raster images: resolution colour/bw (colour depth) Image Hash (bugzilla:1459) Average user rating (see below) To be able to search by stuff like this, I guess we have to have it stored in a structured way as Daniel says in comment #7. I would like the search results to display in a gallery format with extra info below like image description and uploader. Instead of having categories and pages, I would like some fusion of the two (or else, categories with massive extra functionality). Actually the Commons community has decided this for some long time - http://commons.wikimedia.org/wiki/Commons:Images_on_normal_pages_or_categories:Vote - but I can't find a corresponding bug report, perhaps one was never made. Category aliases/RDRs need to work properly, for multilingual names. (bugzilla:3311) On category pages, I (the browsing user) would like to control the sort key: sort by size, uploader, image title, user rating, ***date*** (esp. added to the category). Or a "natural sort" that is displayed by default and might only show the category highlights, which is actually controlled by editors who can for example sort from the general to the specific, or higher quality to lower quality. Since this kind of functionality is so different to how categories currently work, I suspect some new combination of category/gallery is needed. What is needed from categories: ability to add a file to it from the file(image) page. What is needed from galleries (articles): ability to control the display order and annotate items. I would like the option to display subcategory items within the current category I am viewing. This would make navigating the category tree to find the item you're looking for hugely easier. (I think this is bugzilla:2725) I would like batch uploading to exist natively in MediaWiki, and the ability to enable it for trusted users. (bugzilla:488) I would like the ability to rate files (a la YouTube's stars), and hence sort or search by the average rating as well. This might seem like a trivial toy rather than something essential, but this kind of instant feedback is not only gratifying for our original contributors but also offers some control over the huge number of files on some topics. I spent some time recently sorting through our cat photographs, of which there are probably at least a thousand. If I just want a nice high-quality cat photo and I don't care about the details, something like sorting by user rating is perfect. Two additional one-click flags would also be nice - 'flag as potentially offensive content' and 'flag as possible copyright violation'. (This could practically replace our deletion system, if it existed.) To my knowledge no MediaWiki extension like this exists yet, though. User galleries should be a native part of MediaWiki too, that's a bit of a no-brainer. (bugzilla:3341)
Since no other specific software is ready to replace MediaWiki, development is needed either to develop that other software or to improve MediaWiki. The latter solution is the one that's currently being worked on. Closing as WONTFIX accordingly.
