Last modified: 2011-03-13 18:06:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3712 - Use more appropriate software for the Commons (other than MediaWiki)
Use more appropriate software for the Commons (other than MediaWiki)
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
PC All
: Lowest enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-15 11:04 UTC by Théo
Modified: 2011-03-13 18:06 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Théo 2005-10-15 11:04:30 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
Comment 1 Rob Church 2005-10-15 13:43:42 UTC
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?
Comment 2 Théo 2005-10-15 19:35:26 UTC
(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).
Comment 3 Rob Church 2005-10-15 19:53:21 UTC
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?
Comment 4 kipmaster 2006-07-14 09:20:31 UTC
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.
Comment 5 Kelson [Emmanuel Engelhart] 2006-07-18 07:32:56 UTC
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.
Comment 6 Delphine Ménard 2006-07-18 13:07:36 UTC
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.
Comment 7 Daniel Kinzler 2006-07-18 13:14:22 UTC
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.
Comment 8 brianna.laugher 2006-07-18 13:45:59 UTC
(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 .
Comment 9 brianna.laugher 2006-11-08 12:19:34 UTC
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!
Comment 10 brianna.laugher 2006-12-11 08:40:11 UTC
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)
Comment 11 Guillaume Paumier 2009-12-28 22:55:54 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links