Active projects on Commons

List overview All Threads
Download

newer

older

Use labels in Commons and increase...

Born of the monument portuguese...

Lars Aronsson

28 Oct 2010 28 Oct '10

8:21 p.m.

Today I attended yet another workshop where a brave volunteer tried to explain the usefulness of Wikimedia Commons to teachers/scientists. During the following exercise, a very computer literate senior geneticist tried to access wikimedia.org and landed on the Wikimedia Foundation website. After this mistake was corrected, she soon found category:genetics, but from there couldn't find anything about DNA. Category:DNA exists, but is hidden some levels down. The immediate subcategories to Genetics are not the obvious ones to a geneticist. People who are very excited and want to learn, constantly run into these stupid mistakes. Can we please get rid of the name Wikimedia? The M-and-P confusion is among the very worst. Call it "Wikipedia Foundation". Rename Commons to be "Wikipedia Pictures". These two simple changes would save sooooooooooo much time. Yes, I know Wikimedia is more than just Wikipedia, that it also covers Wikisource, Wikibooks and all the other side projects. I also know that Commons is more than just pictures. I've been with Wikipedia since May 2001. But the everyday struggle of having to explain M-and-P is taking all the fun out of it. Is it really worth that? Now, the second part. Finding pictures in Commons is really hard. It seems that categories and textual descriptions are added by the uploader, and rarely modified or enhanced by others. Finding a map of bird migration paths across Europe might be easy, but finding a plain and simple map of Europe is hard. Images that appear directly in top categories (such as Category:Maps of Europe) are a very random mix, and not the most useful generic maps of Europe. The "next 200" navigation is a total disaster, that not a single newcomer understands. Anything that is beyond the first 200 (e.g. subcategories that start with M-Z) are not found. Is there any topic category on Commons that is actively maintained for easy searching, i.e. where subcategories are well defined and where new images are systematically monitored and recategorized with enhanced descriptions? If I could find such an example, perhaps it could provide inspiration for other topics where a specialist with some extra time (or a grant application) could improve the actual usefulness of Commons. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Show replies by date

geni

28 Oct 28 Oct

10:04 p.m.

On 28 October 2010 21:21, Lars Aronsson <lars(a)aronsson.se> wrote:

...

Now, the second part. Finding pictures in Commons is really hard. It seems that categories and textual descriptions are added by the uploader, and rarely modified or enhanced by others. Finding a map of bird migration paths across Europe might be easy, but finding a plain and simple map of Europe is hard. Images that appear directly in top categories (such as Category:Maps of Europe) are a very random mix, and not the most useful generic maps of Europe.

The relevant search term is "blank map of europe". In practice if you are thinking of commons as wikipedia pictures by far the best attack line is http://en.wikipedia.org/wiki/Europe http://en.wikipedia.org/wiki/File:Blank_map_of_Europe_%28polar_stereographi… http://commons.wikimedia.org/wiki/File:Blank_map_of_Europe_%28polar_stereog… http://commons.wikimedia.org/wiki/Category:Blank_SVG_maps_of_Europe

...

The "next 200" navigation is a total disaster, that not a single newcomer understands. Anything that is beyond the first 200 (e.g. subcategories that start with M-Z) are not found.

That can I think be addressed through {{category tree}}

...

Is there any topic category on Commons that is actively maintained for easy searching, i.e. where subcategories are well defined and where new images are systematically monitored and recategorized with enhanced descriptions?

Not categories. Any attempt to do that gets flooded by bots. Closest would be http://commons.wikimedia.org/wiki/Flowers http://commons.wikimedia.org/wiki/Felis_silvestris_catus -- geni

John Vandenberg

11:42 p.m.

On Fri, Oct 29, 2010 at 7:21 AM, Lars Aronsson <lars(a)aronsson.se> wrote:

...

commons.wikipedia.org works.

...

.. Can we please get rid of the name Wikimedia? The M-and-P confusion is among the very worst. Call it "Wikipedia Foundation". Rename Commons to be "Wikipedia Pictures". These two simple changes would save sooooooooooo much time.

Has anyone talked to commons.org ? we could buy wikicommons.org -- John Vandenberg

Neil Kandalgaonkar

29 Oct 29 Oct

1:11 a.m.

As for the Wiki(p|m)edia thing, I have to say I agree 100%, although I don't know what other complications there might be. On 10/28/10 1:21 PM, Lars Aronsson wrote:

...

I was just talking about this with some other people at the WMF... I don't fully understand the ramifications of the debate, but it seems obvious to me that categories as implemented are not useful. The debate I see on Commons and elsewhere focuses on trying to fix Categories, but frankly IMO it would be better to migrate them to some other systems entirely. I've been mumbling about creating a design doc or mockups for my ideas to a few people at the WMF... is anyone else interested in working on this? What I'm thinking: I believe that we have a unique opportunity to make an amazing media curation system, far better than Flickr or Facebook can even dream of doing, and possibly of interest to scientists and other people that need to manage collections of media. Our main advantage is the wiki model -- anyone can curate, and changes are easily revertible. At the other big image hosting sites, media are private by default and it's *hard* to build community tools, since everyone's concerned about unauthorized changes. (Of course, our main *disadvantage* is also MediaWiki, since random templates do not add up to a real indexing system. That's the main thing we need to build). -- Neil Kandalgaonkar (| <neilk(a)wikimedia.org>

John Vandenberg

2:11 a.m.

On Fri, Oct 29, 2010 at 12:11 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

As for the Wiki(p|m)edia thing, I have to say I agree 100%, although I don't know what other complications there might be. On 10/28/10 1:21 PM, Lars Aronsson wrote:

I agree.

...

I've been mumbling about creating a design doc or mockups for my ideas to a few people at the WMF... is anyone else interested in working on this?

IMO, the problem is not how it looks, but the utility of the information. If the metadata was more accessible, more people would fill it in. see e.g. http://strategy.wikimedia.org/wiki/Proposal:Dublin_Core -- John Vandenberg

Gnangarra

5:18 a.m.

Galleries need to be encouraged to higher degree, these galleries work well as a guide but also as a way for potential contributors to identify areas where theres a short fall in available media. http://commons.wikimedia.org/wiki/Banksia --- which then links to the species categories directly http://commons.wikimedia.org/wiki/Western_Australia then steps down to; http://commons.wikimedia.org/wiki/Perth,_Western_Australia What about a bot reading descriptions identifying keywords then adding it to those categories as a way to reduce the reliance on editors to select the categories. The other thing is the search results try commons search for canoe http://commons.wikimedia.org/w/index.php?title=Special%3ASearch&search=… google images search for canoe http://www.google.com.au/images?hl=en&source=imghp&biw=1680&bih… Commons search returns a list most people will see the category link and only 4-6 images initially, compared to google 32 images and 5 alternative search options -- the layout of the results on commons could be alot better. Even simple things like the first return is a link to the category:Canoe the information it gives on the category is "*28 B (1 word) - 04:37, 27 September 2009*" thats not really enticing people to even look there, then click on the link and you hit a soft redirect to "Canoes" another click then returns 196 images, plus 8 subcat with a further 10 subcats and 290+ photos. That initial search should have return the category of Canoes(because thats what is used) and the descrition should be something like "*196 images, +27 subcats containing 472 images*" now that would entice people to explore the category If you search for the intiial example of Genetics<http://commons.wikimedia.org/w/index.php?title=Special%3ASearch… get first on the list a link to the category its description is "2 KB (19 words) - 11:05, 10 November 2009" it does nothing to indicate the depth of information available, click on the category it lists just 5 subcats but theres 14 more if you page to the next 200 each with multiple subcats including one cat that has 25256 files. We need a search result screen that coveys the availablility information when a search occurs so that people are able to understand whats actually available. Whie the M/P issue is annoying most people once they are enter past the differences wont encounter it again. Commons could benefit with an address that is uniquely commons but commons function is as a repository to all projects maybe call it "Wikilibrary" to On 29 October 2010 10:11, John Vandenberg <jayvdb(a)gmail.com> wrote:

...

On Fri, Oct 29, 2010 at 12:11 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

As for the Wiki(p|m)edia thing, I have to say I agree 100%, although I don't know what other complications there might be. On 10/28/10 1:21 PM, Lars Aronsson wrote:

I agree.

I've been mumbling about creating a design doc or mockups for my ideas to a few people at the WMF... is anyone else interested in working on

this? IMO, the problem is not how it looks, but the utility of the information. If the metadata was more accessible, more people would fill it in. see e.g. http://strategy.wikimedia.org/wiki/Proposal:Dublin_Core -- John Vandenberg _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com

Gnangarra

5:22 a.m.

oops wrong button hit when new message appeared [?] On 29 October 2010 13:18, Gnangarra <gnangarra(a)gmail.com> wrote:

...

or "Wikirepository" which would give some difference to the Foundation to help stop the M/P confusion

...

On 29 October 2010 10:11, John Vandenberg <jayvdb(a)gmail.com> wrote:

On Fri, Oct 29, 2010 at 12:11 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

As for the Wiki(p|m)edia thing, I have to say I agree 100%, although I don't know what other complications there might be. On 10/28/10 1:21 PM, Lars Aronsson wrote:

I agree.

I've been mumbling about creating a design doc or mockups for my ideas to a few people at the WMF... is anyone else interested in working on

-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com

Andrea Zanni

8:07 a.m.

...

If the metadata was more accessible, more people would fill it in. see e.g. http://strategy.wikimedia.org/wiki/Proposal:Dublin_Core I definitely agree.

A good metadata system could really improve the situation: moreover, a Metadata/Dublin Core extension could be implemented also in Wikisource, solving the same issue in two different projects. Aubrey Wikimedia Italy Board

Michael Snow

5:15 a.m.

On 10/28/2010 6:11 PM, Neil Kandalgaonkar wrote:

...

At any rate, I don't know that they can be fixed without at least being forked. Right now, categories are being used to serve two purposes, tagging and hierarchical organization. By being pulled in two directions, it's impossible to do either all that well, and sometimes the tensions have other undesirable consequences. For example, categorization awkwardness gets in the way of good management of potentially offensive images. --Michael Snow

Otourly Wiki

7:03 a.m.

New subject: Re : Active projects on Commons

Michael Snow wrote: On 10/28/2010 6:11 PM, Neil Kandalgaonkar wrote:

...

I assume Commons will be greater if Categories are localised. We should have the possibility to set by fault English language for categories, and add on it the translations as if they are a template. That's could be really powerfull, the multilingual search on commons will be improve by this way. Currently a search in French, in Italian, in Portuguese or English don't give the same results because of false friend words or inexisting description in another language than English. Since commons is a multilingual web site, "a way of a good management of potentially offensive images" is to improve the search tool. Florian Farge aka Otourly Sur lesprojets wikimédiens et l'Association française,sur OxyRadio, OSM, et sur MOVIM Socio di Wikimedia Italia _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

David Gerard

7:32 a.m.

On 29 October 2010 02:11, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

The debate I see on Commons and elsewhere focuses on trying to fix Categories, but frankly IMO it would be better to migrate them to some other systems entirely.

:Let me precis several years' wishlisting on the topic: * Tagging would be vastly helpful. * Tags would need to be able to be queried with possibly quite complex Boolean queries. * Categories as tags would make a transition feasible from the content side. * A mockup in Postgres worked great, but MySQL was crippled by it. * Thus, mooted workarounds using Lucene. * There's something on the toolserver that does this, but it's not integrated into how Commons works at all unless you know it's there. (Anything I've missed?) - d.

Gerard Meijssen

7:45 a.m.

Hoi, Yes, tags can be translated too. Thanks, GerardM On 29 October 2010 09:32, David Gerard <dgerard(a)gmail.com> wrote:

...

On 29 October 2010 02:11, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

The debate I see on Commons and elsewhere focuses on trying to fix Categories, but frankly IMO it would be better to migrate them to some other systems entirely.

Magnus Manske

8:13 a.m.

On Fri, Oct 29, 2010 at 8:32 AM, David Gerard <dgerard(a)gmail.com> wrote:

...

On 29 October 2010 02:11, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

The debate I see on Commons and elsewhere focuses on trying to fix Categories, but frankly IMO it would be better to migrate them to some other systems entirely.

Done: http://commons.wikimedia.org/w/index.php?title=File:Vernomia_altissima_(Com… Works with categories prefixed with "TAG:". Check "flower" and "pink", click on "subset". This leads to the toolserver, and there's only one result, but that could be "prettyfied" (dialog on Commons, previews, etc.) Click on the "+" to add a tag without reloading the page, and on the "x" after the tag to remove it, also without reloading. Everything's still a "normal" edit, so the usual revert options apply. Note that it's still experimental, and showing twice for me for some strange reason when I'm logged in, but so what... Cheers, Magnus

Krinkle

12:25 p.m.

Op 29 okt 2010, om 10:13 heeft Magnus Manske het volgende geschreven:

...

On Fri, Oct 29, 2010 at 8:32 AM, David Gerard <dgerard(a)gmail.com> wrote:

On 29 October 2010 02:11, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

The debate I see on Commons and elsewhere focuses on trying to fix Categories, but frankly IMO it would be better to migrate them to some other systems entirely.

I've seen the tagging suggestion come by a lot of times and always found it a great idea. The importance is though, in my opinion, that it should not use the category system (not even temporarily). I asumt it was done now as a proof-of-concept. I think an extension could be written for MediaWiki (if not existing already I might be able to do it myself) that will add tags to MediaWiki, similar to categories but with a few differences. For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will). In there a syntax would be a syntax representing the tagname in different langauges. Example (dont pay attention to the exact syntax, it's just an idea) # Tag:100 <tagname> {{en:flower}} {{nl:bloem}} {{de:Blume}} </tagname> It would generally be saved as a page with wikitext and a history etc. When saving the tagname translations could either be saved to page_props or to a newly created tag_i18n table containing tag_id, tag_lang and tag_name When on a file page there'd be a sidebar gadget listing the current tags. (WHERE tag_from=pageid, just like categories) And instead of fetching the pagetitle from the page table entry it would either fetch it from page_props or from tag_i18n with fallback to English. When adding tags autosuggest would be used like the Search-function has. Searching through the different tagnames where tag_lang is 'en' or where tag_lang is the user's language. Just an idea, let me know what you think -- Krinkle

Bryan Tong Minh

12:36 p.m.

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

...

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

I would store the tag-i18n definitions in a separate Tag: namespace. Then you don't need to create the history tracking etc. all by yourself. You will need a unique identifier though, but I don't see a problem making the unique identifier equal to the content language. Bryan

Krinkle

12:50 p.m.

Op 29 okt 2010, om 14:36 heeft Bryan Tong Minh het volgende geschreven:

...

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

Now that I re-read my mesage I see I didn't use the word Namespace litterly but that's what I meant, yes. A seperate Tag: namespace that contains 'pages' that are either titled by numbers or by a name in the main content language. (in contrary to the interwiki-transclusion thing the title of the Tag- pages are pretty much hidden from everybody) I just read another discussion about seperating license/author information from page-text. This brought me on another idea. If Tags are stored seperatedly, there's no need to have any 'wiki- text' at all. Atleast not visible to the end user. A tag:-page could simply contain a form with the current translations (editable) and a [+]-button to add a translation. roughly shaped: Pagename: [[Tag:Flower]] <form> <table> <tr> <td>English</td> <td><input>flower</input></td> </tr> <tr> <td>Nederlands</td> <td><input>boem</input></td> </tr>> <tr> <td>Deutsch</td> <td><input>Blume</input></td> </tr> </table> <select> ...languages not translated yet ...</select> <input type=submit value='Add translation for this language' /> <input type="submit" value="Save" /> </form> Saving would extract the info and store it in the tag_i18n table (or page_props if that's more appropiate - anyway) Since we like keeping history of everything it may be wise to also store this as wikitext for the Tag:Flower page as something like: {{en:flower}} {{nl:bloem}} {{de:Blume}} but that would only be visible in diff-views and history. -- Krinkle

Magnus Manske

12:51 p.m.

On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

...

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

First, my using the category system is a "hack" that works right now, and could be converted into a more mature solution at a later date. As to "tracking", IMHO it would suffice to just add [[Tag:XYZ]] to the pages; that's rather inelegant from a database POV, but as Bryan points out, it would take care of version tracking etc. All one would need to do is to remove them from the rendering and display them separately, like categories. Multilanguage tags, as well as synonyms, could simply be implemented as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to [[Tag:Flower]], so a search for "Blume" would know about "Flower" easily. However, the system would then have to search for both Blume and Flower internally. Also, that could be a problem with "false friends" (en:Gift=present vs. de:Gift=poison). Another approach might be to duplicate the "hidden category" mechanism and impose a special meaning there, e.g. no tags are shown on such a category page (no tagging of tags), and these categories would then be shown as tags on e.g. image pages. Magnus

Bryan Tong Minh

1:01 p.m.

On Fri, Oct 29, 2010 at 2:51 PM, Magnus Manske <magnusmanske(a)googlemail.com> wrote:

...

Multilanguage tags, as well as synonyms, could simply be implemented as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to [[Tag:Flower]], so a search for "Blume" would know about "Flower" easily. However, the system would then have to search for both Blume and Flower internally. Also, that could be a problem with "false friends" (en:Gift=present vs. de:Gift=poison).

Or force the user to select a language when entering the tag. This means though that we either need a pre-save transform to transform [[Tag:en/flower]] and [[Tag:de/Blume]] to their canonical [[Tag:flower]] and reject tags without language specified, or we need to have tags entered separately from the page text. But then run into the history problem again. Bryan

Krinkle

1:09 p.m.

Op 29 okt 2010, om 15:01 heeft Bryan Tong Minh het volgende geschreven:

...

On Fri, Oct 29, 2010 at 2:51 PM, Magnus Manske <magnusmanske(a)googlemail.com> wrote:

Ah, now I remember again. The reason I used "100" as example in the first mail was to basically avoid this problem. Since they will be primarily changed from the sidebar (or wherever they will appear), where the i18n applies, the page-text doesn't matter that much. In a diff-view they could be rendered aswell in the sidebar so that there isn't the issue of: " I'm in a diff-view and wonder what this means " (just like categories, page-title and wikitext is rendered below diff- view aswell) So [[Tag:Blume]] would never appear in wiki-text. Instead [[Tag:Flower]] or [[Tag:100]] (depending on the sytem we decide to use). And in sidebar (and whereever else tag_i18n is consulted) the currect language appears. - Krinkle

Magnus Manske

1:13 p.m.

On Fri, Oct 29, 2010 at 2:09 PM, Krinkle <krinklemail(a)gmail.com> wrote:

...

So [[Tag:Blume]] would never appear in wiki-text. Instead [[Tag:Flower]] or [[Tag:100]] (depending on the sytem we decide to use). And in sidebar (and whereever else tag_i18n is consulted) the currect language appears.

[[Tag:Flower]] would have the advantage of being human-readable, for the English-speaking world at least. A dozen [[Tag:100]] things would be ... off-putting to many, IMHO. We could just (in)formally agree that the main tag name should always be English. Magnus

Krinkle

1:20 p.m.

Op 29 okt 2010, om 15:13 heeft Magnus Manske het volgende geschreven:

...

On Fri, Oct 29, 2010 at 2:09 PM, Krinkle <krinklemail(a)gmail.com> wrote:

It does bring the issue of renaming. Although Tags are (hopefully) less common to be renamed then categories or pages. It could happen (*) in which case numbers is easier. *On the subject, perhaps we don't want that at all. Move could be hidden / disabled on Tag:-pages. It does make sense as, well, they are tags. If you rename it it's a different tag. -- Krinkle

Krinkle

1:03 p.m.

Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:

...

On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

As to "tracking", IMHO it would suffice to just add [[Tag:XYZ]] to the pages; that's rather inelegant from a database POV, but as Bryan points out, it would take care of version tracking etc. All one would need to do is to remove them from the rendering and display them separately, like categories.

@Bryan: Ah, excuse me. You were referring to the history of the File- page. I was under the impression it was about the version tracking of the Tags. Yeah, adding to the page would be similar to categories and extracted from wikitext to a taglinks table.

...

Though that's certainly not a bad option. I was thinking not to use page-title search when searching through tags. Instead the tag-table itself which contains all the i18n versions. An option on the tag-search page could specify whether the search should cover English( and/or user-language), or all languages. Reason being that using redirects would practically mean we are supposed to keep all redirects in-sync with the tag-translations, which seems double work. -- Krinkle

Bryan Tong Minh

1:06 p.m.

On Fri, Oct 29, 2010 at 3:03 PM, Krinkle <krinklemail(a)gmail.com> wrote:

...

Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:

On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

No you were right, I was refering to the history in the Tag namespace, but history tracking equally applies to the use of tags on file pages as well. Bryan

Magnus Manske

1:10 p.m.

On Fri, Oct 29, 2010 at 2:03 PM, Krinkle <krinklemail(a)gmail.com> wrote:

...

Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:

A separate database table derived from the wikitext on [[Tag:Flower]] would certainly work as well. Another idea: Instead of inventing new syntax or pseudo-HTML tags, why not use language links? On [[Tag:Flower]] [[en:Flower]] [[de:Blume]] That is well-known syntax, and could be nicely parsed for some other applications (On [[de:Blume]] "Search for images on commons relating to Blume" generated automatically, or something) However, it would preclude synonyms within the same language, as there is only one language:title pair stored AFAIK. Magnus

Krinkle

1:17 p.m.

Op 29 okt 2010, om 15:10 heeft Magnus Manske het volgende geschreven:

...

On Fri, Oct 29, 2010 at 2:03 PM, Krinkle <krinklemail(a)gmail.com> wrote:

Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:

Sure, that works too (I was aiming at the #tag syntax, which I believe is also fairly easy parsed). Whether [[xx:Words here]] or {{#en:Words here}}. The former might confuse the few users that check the Diff (instead of editing the page with the form) as I asume the Tag:-page would not actually have langlinks. -- Krinkle

Bryan Tong Minh

1:20 p.m.

On Fri, Oct 29, 2010 at 3:10 PM, Magnus Manske <magnusmanske(a)googlemail.com> wrote:

...

Another idea: Instead of inventing new syntax or pseudo-HTML tags, why not use language links? On [[Tag:Flower]] [[en:Flower]] [[de:Blume]]

Because you want to avoid using a single syntax for multiple purposes if different contexts. We should not tell our users "[[en:*" is an interlanguage link, except when it occurs on a page that starts with [[Tag:. It is already too damn confusing that [[en: is an interlanguage link and [[w:en: an interwiki link. (Where I should add that interlanguage and interwiki links are generally used in wikispeak as synonyms for the same concept, but where the concept is ambiguous.)

Gerard Meijssen

1:21 p.m.

Hoi, Typically I am happy with hacks but this is an exception. The terminology used in the categories are not optimal. The use of plural, the use of latin names for organisms.. It is better for people to add new tags because otherwise they think "it has to be like that". Thank, GerardM On 29 October 2010 14:51, Magnus Manske <magnusmanske(a)googlemail.com> wrote:

...

On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

On Fri, Oct 29, 2010 at 2:25 PM, Krinkle <krinklemail(a)gmail.com> wrote:

For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).

Magnus Manske

1:29 p.m.

On Fri, Oct 29, 2010 at 2:21 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

...

Not sure I understand. My hack is using the category /system/, not the existing categories. Each tag is a special new category like [[Category:TAG:Flower]]. It's not pretty, and a dedicated extension like Krinkle's is much better, but it works right now, and has the pleasant side effect that it can be queried for both tags and categories simultaneously, if desired (e.g. tag X in category tree Y). Magnus

Krinkle

2:31 p.m.

New subject: Extension:Tags-idea (was: Active projects on Commons)

Op 29 okt 2010, om 15:29 heeft Magnus Manske het volgende geschreven:

...

On Fri, Oct 29, 2010 at 2:21 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

A very basic UI concept: http://toolserver.org/~krinkle/MWTags/ (not functional)

Magnus Manske

3:06 p.m.

New subject: Extension:Tags-idea (was: Active projects on Commons)

On Fri, Oct 29, 2010 at 3:31 PM, Krinkle <krinklemail(a)gmail.com> wrote:

...

Op 29 okt 2010, om 15:29 heeft Magnus Manske het volgende geschreven:

On Fri, Oct 29, 2010 at 2:21 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

A very basic UI concept: http://toolserver.org/~krinkle/MWTags/ (not functional)

Nice! Random thoughts: * Since the changes will be very limited (add a line or two at most, or change one), summary could be generated automatically * Likewise, a "minor" distinction wouldn't apply, clearing the interface even more * IMHO tags should be forced case-insensitive, at least during search, maybe even force lowercase in the entry form? * flickr has "machine tags" like "group:key=value". Should we plan for that as well? * Allow for multiple values per language to catch synonyms? * Same for common typos, like on en.wp? * Upon search, show other tags commonly used with pages in the results, for easy refinement Also, should we somehow encode tag "subgroupings"? I know that sounds like it's getting us back to the category system, but tagging an image only as "mare" will not show it when searching for "horse". We'd have to add lots of tags, which is basically no problem, but hard to do consistently, meaning we'll miss some. Associating "Mare" with "Horse" (no tree structure, more like a "see also") could then * for a search, give a list of "see also" (tag cloud?) * auto-branch into associated tags if the original search fails (a smarter variant of "did you mean...") Magnus

Orionist

6:10 p.m.

New subject: Extension:Tags-idea (was: Active projects on Commons)

Very nice indeed! I'd add to Magnus's thoughts the following: * By combining tags with categories in search we can achieve "subgrouping" without actually going through tags and doing categories all over again. Then we can use parent and sub-categories for "see also", "did you mean.." or "narrow your search" etc. * We should certainly allow for multiple values per language. Other than the reasons mentioned by Magnus there's the fact that names of people and places in non-Latin-script languages are sometimes transliterated in several ways, and the opposite is true. We could make one tag only visible (article title on WP?) and hide the other variants (redirects on WP). * For searches that need disambiguation, we can use something like "clarify your search" used on iStockphoto. My hopes rest with our valued coders to turn this into reality. It will make life on Commons a whole lot easier. On Fri, Oct 29, 2010 at 7:06 PM, Magnus Manske <magnusmanske(a)googlemail.com>wrote;wrote:

...

On Fri, Oct 29, 2010 at 3:31 PM, Krinkle <krinklemail(a)gmail.com> wrote:

Op 29 okt 2010, om 15:29 heeft Magnus Manske het volgende geschreven:

On Fri, Oct 29, 2010 at 2:21 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

A very basic UI concept: http://toolserver.org/~krinkle/MWTags/ (not functional)

Bryan Tong Minh

7:42 a.m.

On Fri, Oct 29, 2010 at 3:11 AM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

(Of course, our main *disadvantage* is also MediaWiki, since random templates do not add up to a real indexing system. That's the main thing we need to build).

Related to that: https://bugzilla.wikimedia.org/show_bug.cgi?id=25624 Store author and license information in the database. If anybody has comments about how to implement this, please comment on the bug. Bryan

4940

days inactive

4941

days old

commons-l@lists.wikimedia.org

Manage subscription

31 comments

14 participants

tags (0)

participants (14)

Andrea Zanni
Bryan Tong Minh
David Gerard
geni
Gerard Meijssen
Gnangarra
John Vandenberg
Krinkle
Lars Aronsson
Magnus Manske
Michael Snow
Neil Kandalgaonkar
Orionist
Otourly Wiki