On 7/3/07, Barcex barcexwiki@gmail.com wrote:
I Agree on this point, and think that the real problems why Commons is not so successful are not related to its name but to the MediaWiki software (as is now) that is very good to write encyclopedias but awful to implement an image bank. The concept of "wiki" (easy edit with full history of changes) is very useful for our needs, but the implementation with MediaWiki is far from being good.
Barcex
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Bryan
On 03/07/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On 7/3/07, Barcex barcexwiki@gmail.com wrote:
I Agree on this point, and think that the real problems why Commons is not so successful are not related to its name but to the MediaWiki software (as is now) that is very good to write encyclopedias but awful to implement an image bank. The concept of "wiki" (easy edit with full history of changes) is very useful for our needs, but the implementation with MediaWiki is far from being good.
Barcex
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Bryan
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
I believe there is already a page at [1] if that helps. --UH.
2007/7/3, Bryan Tong Minh bryan.tongminh@gmail.com:
On 7/3/07, Barcex barcexwiki@gmail.com wrote:
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Bryan
Let me say that I'm not a photo professional, but I know well that on image banks metadata is the king. Our support for metadata right now is a hack of MediaWiki templates that are very difficult to edit, and are not searchable. Then, there are professional standards like IPTC to add rich metadata to pictures. Work on that standards is already done, is professional and we should take a look to them instead of trying to reinvent the wheel. Tags (a la flickr) are a mess as our categories are, it is very hard to keep them organized following the wiki model.
Of course, editing full IPTC can be difficult as is complex (having many fields to fill in). But a simple interface could have the most important fields to edit, and have an advanced editor for experienced users. This interface should allow the edition of IPTC registering changes an versions as we do with text (so you are able to compare each version of the metadata as you do now with text, that's the wiki concept).
Once we can provide images with rich metadata, a lot of tools can be developed to generate advanced searches.
That's my contribution to this brainstroming ;)
Barcex
On 7/3/07, Barcex barcexwiki@gmail.com wrote:
2007/7/3, Bryan Tong Minh bryan.tongminh@gmail.com:
On 7/3/07, Barcex barcexwiki@gmail.com wrote:
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Bryan
Let me say that I'm not a photo professional, but I know well that on image banks metadata is the king. Our support for metadata right now is a hack of MediaWiki templates that are very difficult to edit, and are not searchable. Then, there are professional standards like IPTC to add rich metadata to pictures. Work on that standards is already done, is professional and we should take a look to them instead of trying to reinvent the wheel. Tags ( a la flickr) are a mess as our categories are, it is very hard to keep them organized following the wiki model.
Of course, editing full IPTC can be difficult as is complex (having many fields to fill in). But a simple interface could have the most important fields to edit, and have an advanced editor for experienced users. This interface should allow the edition of IPTC registering changes an versions as we do with text (so you are able to compare each version of the metadata as you do now with text, that's the wiki concept).
Once we can provide images with rich metadata, a lot of tools can be developed to generate advanced searches.
There would be a way for commons to track all kinds of metadata, a way I (and others, IIRC) have proposed a long time ago: Store the values passed to each template on each page in a database table.
With an IPTC template on many image pages, and assuming that data is actually filled in, one could then search for, say, all images taken in Berlin on July 3, 2006. Or all images I took of flowers. Or... (you get the point).
Of course, this was dismissed at the time, because WikiData would take care of all of that. Which eventually lead to a tool by kolossos on the toolserver which tries to replicate this function. [1] shows all biographies on de.wikipedia of people who were born in London.
Of course, that functionlality should really come as a MediaWiki extension. The parser does generate the needed data anyway, it is merely a question of storing (and searching) it.
Magnus
[1] http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Per...
On 04/07/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On 7/3/07, Barcex barcexwiki@gmail.com wrote:
I Agree on this point, and think that the real problems why Commons is not so successful are not related to its name but to the MediaWiki software (as is now) that is very good to write encyclopedias but awful to implement an image bank. The concept of "wiki" (easy edit with full history of changes) is very useful for our needs, but the implementation with MediaWiki is far from being good.
Barcex
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Well part of the point is that we need certain functionality as native MediaWiki functionality. - Check-usage - CommonsTicker - image-focused search engine - User Gallery - much-enchanced newimages patrol - Deletion work queue - Wikimedia image transfer tool
You won't be surprised to notice that all of these tools exist as external tools on the Toolserver. The first three in particular NEED to be native MW. It is ridiculous that every time the toolserver falls over, Commons deletions go back to the dark ages (a couple of years ago) where literally admins deleted stuff blind, with no idea about who it would affect and no way to find that information out.
- Flickr transfer tool
(OH WAIT WE HAVE THAT BUT YOU NEED MAGIC SKILLS TO GET EXTENSIONS ENABLED)
If you want to know what functionality Commons needs, look at what our external tools do and what our bots do.
- category moving/renaming - image renaming (well, bots don't do this, and it's promised to be coming soon)
If you want to know about what functionality Commons needs, dream about what might be possible.
- Might it ever be possible we could sort categories by date added to category? - Might it ever be possible we could 'auto-collapse' subcategories of a category with one click? - Might it ever be possible we could union/intersect categories? (also promised at one time, not sure what the status is now) - Might it ever be possible we could have properly multilingual category names? - Might it ever be possible we could search on strutured metadata fields like date or author? - Might it ever be possible we'd be able to rate images two ways, for both general quality, and for 'copyright believablity' (for want of a better phrase)? And from there, be able to easily find and view unrated images, poorly rated images and highly rated images? - Might it ever be possible that Commons was as easy to use as Flickr?
This bug http://bugzilla.wikimedia.org/show_bug.cgi?id=3712 also has some more thoughts/ranting from me on the subject.
Commons: Bugs is as Uber Halogen said, a good start; Commons:Tools is another one.
cheers Brianna
On 7/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
- Might it ever be possible we could sort categories by date added to category?
Yes. The categorylinks table contains a key cl_timestamp, which gives the timestamp a page is added to a category. In the past, when I was working on [[Commons:ExtendedWatchlist]], I was about to implement this, but then unfortunately the watchlist code got disabled in the API, and I haven't had the time yet to look at it again.
- Might it ever be possible we could have properly multilingual category names?
Category redirects is what we need. This would also solve the problem with renaming categories.
- Might it ever be possible we'd be able to rate images two ways, for
both general quality, and for 'copyright believablity' (for want of a better phrase)? And from there, be able to easily find and view unrated images, poorly rated images and highly rated images?
A general property/metadata system is what we need. Admins should be able to setup some properties you could easily change in the Mediawiki namespace, and then those properties should magically appear on an image, and can be set by anyone, with revision history recorded, etc.
Bryan
"Bryan Tong Minh" wrote:
On 7/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
- Might it ever be possible we'd be able to rate images two ways, for
both general quality, and for 'copyright believablity' (for want of a better phrase)? And from there, be able to easily find and view unrated images, poorly rated images and highly rated images?
A general property/metadata system is what we need. Admins should be able to setup some properties you could easily change in the Mediawiki namespace, and then those properties should magically appear on an image, and can be set by anyone, with revision history recorded, etc.
Thank you for showing us the current status. Could you please be a little more precise about the property/metadata system?
Thanks in advance,
Flo
On 04/07/07, Florian Straub Flominator@gmx.net wrote:
"Bryan Tong Minh" wrote:
On 7/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
- Might it ever be possible we'd be able to rate images two ways, for
both general quality, and for 'copyright believablity' (for want of a better phrase)? And from there, be able to easily find and view unrated images, poorly rated images and highly rated images?
A general property/metadata system is what we need. Admins should be able to setup some properties you could easily change in the Mediawiki namespace, and then those properties should magically appear on an image, and can be set by anyone, with revision history recorded, etc.
Thank you for showing us the current status. Could you please be a little more precise about the property/metadata system?
We need to be able to define certain properties that are stored as separate database fields, so that they can be searched as separate database fields. There are also many useful technical properties which can be automatically extracted which should be stored as separate database fields, so that they too can be stored as separate database fields. So IMO there are two needs: 1-set up extra DB fields, some of which are automatically populated 2-provide much-improved search interface to search over those fields.
In this bug comment 10 I detailed some examples of fields I would like to be able to search by. http://bugzilla.wikimedia.org/show_bug.cgi?id=3712 Some automatic fields: file type, file dimensions, file size, (last) uploader, date (last) uploaded. These are all things that MediaWiki already knows about, but there's no way for users to access those things properly.
An example of a very simple improved search interface is Duesentrieb's Media Search: http://tools.wikimedia.de/%7Edaniel/WikiSense/MediaSearch.php?wikifam=common...
Mayflower Advanced Search is a great example of what might be possible: http://tools.wikimedia.de/~tangotango/mayflower/advanced.php
These tools exist outside Wikimedia. They need to exist as native MediaWiki functionality. Either that or we need a method to redirect all our searches to an external site.
regards Brianna
Bryan Tong Minh wrote:
On 7/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
- Might it ever be possible we could sort categories by date added to category?
Yes. The categorylinks table contains a key cl_timestamp, which gives the timestamp a page is added to a category. In the past, when I was working on [[Commons:ExtendedWatchlist]], I was about to implement this, but then unfortunately the watchlist code got disabled in the API, and I haven't had the time yet to look at it again.
I found it some days ago. However, seems that moving a page reset the timestamp. So it's the time a page with that name was added to the category, which doesn't have to be the time the page was categorised.
Bryan Tong Minh wrote:
This issue has come up multiple times, but without much result. What specific features does Commons need to have? A list of this might be interesting, because their are very likely users who are willing to implement those kind of things, either as an extension, javascript hack or external service.
Just thinking out loud here, none of this is feasible at this point ;-)
The concept of "articles" is, of course, entirely appropriate on Wikipedia: there is one giant <textarea> into which all of the article's content goes. Image pages (or, generically, "media" pages) on Commons, however, also consist of one giant <textarea>, yet the data they hold can be divided into a small number of discrete categories, which include:
- the title of the work (in a variety of different languages) - the creator of the work - the identity of the copyright holder of the work - the date, time, and location of the creation of the work - other media-specific metadata. For images, this is the exposure information; for sound, this is information about the recording setup. - the license under which the work is released - information about post-processing (e.g. Photoshop, Audacity) - categories to which the work belongs (i.e. [[Category:...]]) - Commons maintenance tags (e.g. {{SupersededSVG}}, deletion templates, disputes of any kind)
With this in mind, then, it seems to me that it would make a lot of sense for Commons media pages to consist of these fields, instead of one giant box with all of this information. Speaking from a semi-OCD standpoint ;-), the actual wikitexts of Commons pages are all over the place as far as form. Whereas Wikipedia has a well-developed Manual of Style that dictates how articles should be structured, Commons pages can contain a hodge-podge of {{Information|...}}, redundant headings, categories, and the like.
I suppose my proposal—though as I said, this is really just brainstorming—is to replace the giant <textarea> with some semblance of structured data entry. I'll admit, I'm not particularly enamored with the idea of a thousand input fields on each page, but compelling users to put the license information in *this* box, and the author in *that* box, and the categories *over there* is the only surefire way to standardize the look of media pages on Commons. (A significant bonus here is that having the data structured makes it infinitely easier to search—such structure could put the Commons with the likes of Flickr as far as the Semantic Web goes.) As many people have noted on this thread and elsewhere, MediaWiki is primarily an encyclopedia engine, and needs significant changes to be really useful for media.
As long as I'm dreaming out loud... a couple of years back there was a poll to determine whether images should be added to articles, categories, or both. I don't remember exactly, but I think the outcome was that we would use a combination of articles and categories for the time being, but that new software should be written to enable a "hybrid" approach. Well... we're still waiting :-) Don't get me wrong, I recognize that most (all?) of the MediaWiki programmers are just hacking in their spare time, and aren't being paid, but Commons really needs such a system put in place.
Personally, I think that articles should not be used for this purpose at all, due to the fact that two pages (the image and the article) need to be changed to add an image, whereas adding [[Category:Foobar]] will automatically place an image in a category. OTOH, articles allow images to be sorted into subcategories that would be too pedantic for the normal category system (for example, "Foo at night", "Foo in the winter").
Anyway, my point here is that we need a better way to sort and categorize media. The mythical "hybrid" system would dynamically add images to categories, and still support implicit subcategories like "Foo at night". (BTW, I have no idea how the specifics of such a system would work :-P)
Wow, that was a long post. I hope someone thinks at least some of this is a good idea for Commons, and maybe then we can start to look for a way to implement these changes.
Cheers,
On 7/6/07, Benjamin Esham bdesham@gmail.com wrote:
I suppose my proposal—though as I said, this is really just brainstorming—is to replace the giant <textarea> with some semblance of structured data entry. I'll admit, I'm not particularly enamored with the idea of a thousand input fields on each page, but compelling users to put the license information in *this* box, and the author in *that* box, and the categories *over there* is the only surefire way to standardize the look of media pages on Commons. (A significant bonus here is that having the data structured makes it infinitely easier to search—such structure could put the Commons with the likes of Flickr as far as the Semantic Web goes.) As many people have noted on this thread and elsewhere, MediaWiki is primarily an encyclopedia engine, and needs significant changes to be really useful for media.
On one of the CCC meetings in Berlin (2005?) I hacked a little thing that would, on clicking "edit", split the page text (here:image description) in two: 1. Text (here:{{Information}}) 2. Metadata (categories, language links, non-position-dependent templates) and show them as two separate textareas (a large and a small one). Upon saving, it would append the second to the first one. That allowed for the separate editing of metadata while not interfering with any other part of the software.
It was a quick'n'dirty hack, and it was probably removed from MediaWiki in the meantime. However, something along these lines (showing only one or the other textarea) might be feasible, if properly planned and watched by many eyeballs.
As long as I'm dreaming out loud... a couple of years back there was a poll to determine whether images should be added to articles, categories, or both. I don't remember exactly, but I think the outcome was that we would use a combination of articles and categories for the time being, but that new software should be written to enable a "hybrid" approach. Well... we're still waiting :-) Don't get me wrong, I recognize that most (all?) of the MediaWiki programmers are just hacking in their spare time, and aren't being paid, but Commons really needs such a system put in place.
Maybe that could be achieved through combining categroies, "image box" annotations, gallery inclusions, subcategories, and category intersections, to some abstract concept of annotation: * An annotation can concern only a part of the image (image box) * An annotation can concern the whole image
Both types of annotation use categories to store the information. Example: [1] is in both category "Bee" (through image box) and in gallery "Valeriana officinalis". The latter is in Category:Valerianaceae, which is a sub-sub-sub...category of Category:Plantae. So, all the information to find "Flower [plantae] and bee" is there. It would "only" (biiiig olny) need an algorithmical approach to combine them so [1] would show up in the results.
As for metadata (IPTC etc.) see my recent mail about storing template variables in their own searchable table. This could be combined into the annotation concept as well.
Cheers, Magnus
[1] http://commons.wikimedia.org/w/index.php?title=Image:Valeriana_officinalis_2...
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and in the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
Bryan
On 7/6/07, Magnus Manske magnusmanske@googlemail.com wrote:
On 7/6/07, Benjamin Esham bdesham@gmail.com wrote:
I suppose my proposal—though as I said, this is really just brainstorming—is to replace the giant <textarea> with some semblance of structured data entry. I'll admit, I'm not particularly enamored with the idea of a thousand input fields on each page, but compelling users to put the license information in *this* box, and the author in *that* box, and the categories *over there* is the only surefire way to standardize the look of media pages on Commons. (A significant bonus here is that having the data structured makes it infinitely easier to search—such structure could put the Commons with the likes of Flickr as far as the Semantic Web goes.) As many people have noted on this thread and elsewhere, MediaWiki is primarily an encyclopedia engine, and needs significant changes to be really useful for media.
On one of the CCC meetings in Berlin (2005?) I hacked a little thing that would, on clicking "edit", split the page text (here:image description) in two:
- Text (here:{{Information}})
- Metadata (categories, language links, non-position-dependent templates)
and show them as two separate textareas (a large and a small one). Upon saving, it would append the second to the first one. That allowed for the separate editing of metadata while not interfering with any other part of the software.
It was a quick'n'dirty hack, and it was probably removed from MediaWiki in the meantime. However, something along these lines (showing only one or the other textarea) might be feasible, if properly planned and watched by many eyeballs.
As long as I'm dreaming out loud... a couple of years back there was a poll to determine whether images should be added to articles, categories, or both. I don't remember exactly, but I think the outcome was that we would use a combination of articles and categories for the time being, but that new software should be written to enable a "hybrid" approach. Well... we're still waiting :-) Don't get me wrong, I recognize that most (all?) of the MediaWiki programmers are just hacking in their spare time, and aren't being paid, but Commons really needs such a system put in place.
Maybe that could be achieved through combining categroies, "image box" annotations, gallery inclusions, subcategories, and category intersections, to some abstract concept of annotation:
- An annotation can concern only a part of the image (image box)
- An annotation can concern the whole image
Both types of annotation use categories to store the information. Example: [1] is in both category "Bee" (through image box) and in gallery "Valeriana officinalis". The latter is in Category:Valerianaceae, which is a sub-sub-sub...category of Category:Plantae. So, all the information to find "Flower [plantae] and bee" is there. It would "only" (biiiig olny) need an algorithmical approach to combine them so [1] would show up in the results.
As for metadata (IPTC etc.) see my recent mail about storing template variables in their own searchable table. This could be combined into the annotation concept as well.
Cheers, Magnus
[1] http://commons.wikimedia.org/w/index.php?title=Image:Valeriana_officinalis_2... _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Hmm...
{{information|Author=The [[Artist]]}}
could (per template) become
[table stuff] <div id='information_author'>The <a href="Artist'>Artist</a><div> <div id='information_source_author' style='display:none'>The [[Artist]]</div> [clickable element] [/table stuff]
where [clickable element] would, upon click, * change the 'information_author' div into a textarea, containing 'information_source_author', and OK/cancel buttons * on OK, get the page source, replace "author=The [[Artist]]" with "author=[new wiki text]", store it via EditPage.js * update page display
This could apply to other parts of the article text, not just template parameters. {{editinline|stuff}}, anyone?
Cheers, Magnus
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and in the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and in the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
Bryan
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
On 7/6/07, Ayelie ayelie.at.large@gmail.com wrote:
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
-- Ayelie ~Editor at Large _______________________________________________
http://commons.wikimedia.org/wiki/Image:Casa_Col%C3%B3n_Huelva_01.JPG?withJS...
Ok, no saving yet, and this looks somewhat ugly. I'll try something like a real edit form.
Bryan
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On 7/6/07, Ayelie ayelie.at.large@gmail.com wrote:
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
Hmmm, doesn't do anything for me, not even logged-out (so my own JS won't interfere)...
Using Firefox 2.0.0.4.
Magnus
Yes, it appears to be working for some users, and not for others... I'll be looking into it, but I'll be off for the weekend.
Bryan
On 7/6/07, Magnus Manske magnusmanske@googlemail.com wrote:
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On 7/6/07, Ayelie ayelie.at.large@gmail.com wrote:
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
Hmmm, doesn't do anything for me, not even logged-out (so my own JS won't interfere)...
Using Firefox 2.0.0.4.
Magnus
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
No worries, it just started working, without me doing anything. Obviously a caching issue. Damn squids ;-)
Magnus
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
Yes, it appears to be working for some users, and not for others... I'll be looking into it, but I'll be off for the weekend.
Bryan
On 7/6/07, Magnus Manske magnusmanske@googlemail.com wrote:
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On 7/6/07, Ayelie ayelie.at.large@gmail.com wrote:
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
Hmmm, doesn't do anything for me, not even logged-out (so my own JS won't interfere)...
Using Firefox 2.0.0.4.
Magnus
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Bryan Tong Minh wrote:
http://commons.wikimedia.org/wiki/Image:Casa_Col%C3%B3n_Huelva_01.JPG?withJS...
Ok, no saving yet, and this looks somewhat ugly. I'll try something like a real edit form.
Bryan
Really hard to click on the category name without clicking on the hyperlink. And people won't know it can be edited. Imho it needs some edit button to press.
On 7/6/07, Platonides Platonides@gmail.com wrote:
Bryan Tong Minh wrote:
http://commons.wikimedia.org/wiki/Image:Casa_Col%C3%B3n_Huelva_01.JPG?withJS...
Ok, no saving yet, and this looks somewhat ugly. I'll try something like a real edit form.
Bryan
Really hard to click on the category name without clicking on the hyperlink. And people won't know it can be edited. Imho it needs some edit button to press.
Inspired by the idea, I'm working on an "add a new category" thing. Once its working, it could be merged with EditInline.
Magnus
Ayelie ayelie.at.large@gmail.com wrote
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and in the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
What about auto completion of category names?
Flo
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
Ayelie ayelie.at.large@gmail.com wrote
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and in the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
What about easier category adding? You click the bar at the bottom of the page where the categories are and a little box pops up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
What about auto completion of category names?
http://commons.wikimedia.org/wiki/MediaWiki:HotCat.js :-)
Magnus
"Magnus Manske" magnusmanske@googlemail.com wrote:
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
Ayelie ayelie.at.large@gmail.com wrote
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and
in
the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
What about easier category adding? You click the bar at the bottom of
the
page where the categories are and a little box pops up, you type "Foo"
and
save, and it adds [[Category:Foo]] to the page...
What about auto completion of category names?
You rock! What about an icon showing if a category actually exists when done typing?
Gruß,
Flo
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
"Magnus Manske" magnusmanske@googlemail.com wrote:
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
Ayelie ayelie.at.large@gmail.com wrote
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
How about on-the-fly editting of information in the information template? Users could just click on a field they want to edit, and
in
the end hit "save", without having to deal much with difficult wikicode... Plus the page doens't have to be reloaded if [[MediaWiki:EditPage.js]] is used. (And had been made cross-browser-compatible)
What about easier category adding? You click the bar at the bottom of
the
page where the categories are and a little box pops up, you type "Foo"
and
save, and it adds [[Category:Foo]] to the page...
What about auto completion of category names?
You rock! What about an icon showing if a category actually exists when done typing?
Nice idea. I'll work it in this evening.
Note that the script already retrieves multiple hits; I was just too lazy to implement a pop-up scrollbox...
Magnus
"Magnus Manske" magnusmanske@googlemail.com wrote
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
"Magnus Manske" magnusmanske@googlemail.com wrote:
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
Ayelie ayelie.at.large@gmail.com wrote
On 7/6/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote: What about easier category adding? You click the bar at the > > > > > > > > bottom of the page where the categories are and a little box pops > > > > > up, you type "Foo" and save, and it adds [[Category:Foo]] to the page...
What about auto completion of category names?
You rock! What about an icon showing if a category actually exists when
done typing?
Nice idea. I'll work it in this evening.
Note that the script already retrieves multiple hits; I was just too lazy to implement a pop-up scrollbox...
How do I switch between hits until you become motivated again? ;)
Regards,
Flo
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
How do I switch between hits until you become motivated again? ;)
You don't :-(
If you want to hack at it, look at the "titles" variable in hotcat_show_suggestions() ...
The intranet here at work is down, so I had some time to kill and added the icon thingy you suggested :-)
Cheers, Magnus
"Magnus Manske" magnusmanske@googlemail.com wrote:
On 7/9/07, Florian Straub Flominator@gmx.net wrote:
How do I switch between hits until you become motivated again? ;)
You don't :-(
If you want to hack at it, look at the "titles" variable in hotcat_show_suggestions() ...
Our intranet is way too fast for having time for this :)) BTW: Will it work properly on ISDN?
The intranet here at work is down, so I had some time to kill and added the icon thingy you suggested :-)
As I said previously: You rock!
Regards,
Flo