Last modified: 2014-01-28 05:52:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2931, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 931 - automatic edit summary for categorizing pages
automatic edit summary for categorizing pages
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 167
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-23 10:53 UTC by User:JesseW
Modified: 2014-01-28 05:52 UTC (History)
4 users (show)

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


Attachments

Description User:JesseW 2004-11-23 10:53:25 UTC
It would be great to have a flag like the minor changes flag, except for
categorization work.  Categorizing takes so many minor changes, it would be very
helpful if there was a way to filter them out.
Comment 1 Brion Vibber 2004-11-23 12:42:16 UTC
I think this would be an unnecessary complication; "minor" and the edit summary already 
cover explaining that it's a trivial categorization edit and hence people uninterested can 
skip over it easily enough.
Comment 2 User:JesseW 2004-11-23 13:15:57 UTC
It's the ability to ''automtically'' hide them that I would like.  People use
various different ways of explaining that something is categorizing work ("cat",
"category", etc.), and sometimes they use the minor changes flag, but sometimes
they don't.  If there was a seperate flag, it would be clearer, and unless you
worked on categorizing it wouldn't affect you at all.
Comment 3 Rowan Collins [IMSoP] 2004-11-23 20:29:02 UTC
I think the problem is we could end up with a whole proliferation of "flags" of
this sort, and a) RecentChanges and page history displays would be cluttered up
with them and b) people would simply not bother using them. Indeed, if there are
already people failing to use the "minor edit" flag for minor categorization
edits, what makes you think they'll remember to tick one called "categorization
edit"? Or are you proposing (as others have) that this be an automatic test, in
which case what exactly would that test be?

Now I think about it, there can be such a thing as a major edit that only adds
or changes a category - it could be controversial, or it could even be
vandalism. So I'm not sure "categorization" would be a good category of edits to
seperate out.
Comment 4 Catherine Munro 2004-11-27 19:34:12 UTC
How about automatic edit summary, the same way section headers are automatically 
entered now:

Could the software detect if the ONLY thing a person enters is a [[Category:]] or a 
{{template}} tag, and enter that tag text into the edit summary?  Not only would it 
make it quicker for those doing categorization work, it would make a consistent 
format that is as easy to recognize on Recent Changes as a flag, and perhaps more 
easy to filter either by us or by external bookmarklets and such.
Comment 5 User:JesseW 2004-11-28 18:02:34 UTC
Ok, let me try to be more specific.  People currently start category-related
edit summaries with the word "cat".  I would like a way to hide those items, or
show only them, as a way of dividing my watchlist.  I can, and I will, write a
javascript bookmarklet to do this, but it would be more useful and easier for
other people to use if it was added to Mediawiki.  That would not require any
more flags for people to pay attention to than they already do, and it would not
make controversial items any more likely to be missed; it would just add
technical support for an existing practice.

Regarding the idea of automatic insertion of the word "cat" if only category
items are entered, that's a good idea, also.  It could also be implemented by a
bookmarklet, but people would have to click it everytime the saved a page(AFAIK,
now) as there is no way to automatically call a bookmarklet(if anyone knows how,
_*please*_ let me know). 
Comment 6 Shane King 2004-12-08 06:34:57 UTC
Automatic edit summaries seems like a good idea, but it involves running a diff
between the previous and current version, extracting what's changed, trying to
work out what that is, and then changing the edit summary. It seems a lot of
work for a small benefit, especially since you'd be leaving the edit summary
blank and then just hoping your change met the criteria that caused it to
automatically fill in the sumary for you.

As I see it, the real problem is that categories are meta-data that shouldn't be
in the article text to start with ... 
Comment 7 Wikipedia:en:User:Paddu 2004-12-25 08:23:09 UTC
It could be possible to implement this (if enough people find it useful & have
enough time...) by having an edit-link for categories just like the section-edit
links.

In the ideal world, all category tags would be lumped up somewhere at the end
and it might be easy to be able to edit just them. But in real life, there might
be articles with category tags in all places.
Comment 8 Wikipedia:en:User:Paddu 2004-12-25 08:28:16 UTC
Hey it just occured to me. If one is just going to add a category/template tag
(and isn't bothered about existing tags), one would just append whatever tags
one wants to the page. An ideal use of "action=edit&section=new".

Hence, I'd suggest an "append a tag" link to non-talk pages similar to the
"post-a-comment" link to talk-pages, with the edit summary prefilled with "/*
tag */" or something.

The editor could still choose whether to mark the edit as minor, of course.
Comment 9 Antoine "hashar" Musso (WMF) 2005-07-06 14:53:21 UTC
That will be trivially fixed the day we get interwikis and categories
links out of article. We can have two edit mode:
_ one for the article text
_ one for the metadatas
Comment 10 Andre Klapper 2012-12-21 13:19:42 UTC
[Removing RESOLVED LATER as discussed in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . Reopening and setting priority to "Lowest". For future reference, please use either RESOLVED WONTFIX (for issues that will not be fixed), or simply set lowest priority. Thanks a lot!]

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


Navigation
Links