Last modified: 2011-04-14 15:14:36 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 14247 - Provide Autosumm-blank and Autosumm-replace message with CSS class
Provide Autosumm-blank and Autosumm-replace message with CSS class
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/MediaWik...
:
Depends on:
Blocks: 22771
  Show dependency treegraph
 
Reported: 2008-05-24 10:20 UTC by Melancholie
Modified: 2011-04-14 15:14 UTC (History)
4 users (show)

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


Attachments

Description Melancholie 2008-05-24 10:20:11 UTC
Provide an id or a class for the message part (non-$1 part) of [[MediaWiki:Autosumm-blank]] and [[MediaWiki:Autosumm-replace]]!

* In [[MediaWiki:Autosumm-blank]] the text "Blanked the page" should be *red* then
* In [[MediaWiki:Autosumm-replace]] the text "Replaced content with" could be *orange* then

You can pick out vandalism from Special:RC much better then.
Comment 1 Melancholie 2008-05-24 15:36:50 UTC
<del>id</del> (*class* of course; as multiple ;-)
Comment 2 Leon Weber 2008-05-24 16:14:21 UTC
Although this request sounds reasonable, I'm not sure where to add the <span> tags. Article::getAutosummary() obviously is the wrong place, as this would write the tags to the database and they'd be html escaped later. It'd need to be implemented in the history listing, though that would only work by matching the summary text and checking if it's an autosumm, in any of the languages. Super ugly!
Comment 3 Danny B. 2008-05-24 16:36:19 UTC
It's not that ugly as it looks on the first sight. I took a look in sources and I think the solution is following:

1) mark auto summaries with certain borders
2) when rendering the related page content (RC, history, ...) use regexp to find these auto summaries and wrap them in corresponding span with class

This will have advantage for future, since we'll have universal mechanism for passing & marking auto summaries and their further rendering.

The only issue is durability: If the auto summary should be still rendered same even when its content got changed (eg. "Blanked the page" will be changed to "blanking the page" - so should all "Blanked the page" in history be still marked with such class or not?). If yes, we need to keep and pass the track of the auto summary type, if not, we can only pass the fact it's auto summary and it will decide it's type comparing to such current messages.

Trying to work on patch for this. I may prepare both versions.
Comment 4 Roan Kattouw 2008-05-24 16:43:55 UTC
(In reply to comment #3)
> 2) when rendering the related page content (RC, history, ...) use regexp to
> find these auto summaries and wrap them in corresponding span with class

That's ugly as hell. Why don't we add a rev_autosummary bool to the revision table? Hell, why don't we store the message key and arguments in that table so that autosummaries can be localized and past autosummaries will automatically change when the message changes?
Comment 5 Danny B. 2008-05-24 16:54:17 UTC
Why is it ugly? It is based on the same principle as formatting summaries for sections. It counts with localization of course. Besides it doesn't need schema change even to preserve marking of those auto summaries which have changed their content during the time, but your way does. Also, does your approach differ between different types of auto summaries?
Comment 6 Roan Kattouw 2008-05-24 16:57:30 UTC
(In reply to comment #5)
> Why is it ugly? It is based on the same principle as formatting summaries for
> sections.
Are you gonna introduce new syntax to the mini-parser then (like /* ... */ for sections)?

> It counts with localization of course. Besides it doesn't need schema
> change even to preserve marking of those auto summaries which have changed
> their content during the time, but your way does. Also, does your approach
> differ between different types of auto summaries?
> 
Yes, because it stores the message key and its arguments. Alternatively, we could have an autosummary_type field which stores 0 for "not an autosummary" and 1,2,... for different types of autosummaries.
Comment 7 Danny B. 2008-05-24 17:11:30 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Why is it ugly? It is based on the same principle as formatting summaries for
> > sections.
> Are you gonna introduce new syntax to the mini-parser then (like /* ... */ for
> sections)?

I was thinking about eg.

 /#1# auto summary goes here #/

(not saying necessarily this form, just showing the principle) where the "1" can be different number according to the auto summary type.

Regexp for this is very easy and then you can then make a switch according to the number to provide corresponding class.

If it's not the best approach, then it would be nice to know why, thanks.

----

Shouldn't we change the summary of this bug to more general such as "Provide mechanism to format autosummaries" or open new one?
Comment 8 Roan Kattouw 2008-05-24 17:14:08 UTC
(In reply to comment #7)
> I was thinking about eg.
> 
>  /#1# auto summary goes here #/
> 
> (not saying necessarily this form, just showing the principle) where the "1"
> can be different number according to the auto summary type.
> 
> Regexp for this is very easy and then you can then make a switch according to
> the number to provide corresponding class.
That's probably better. I thought you wanted to regex for the exact message.
Comment 9 Danny B. 2008-05-24 17:40:15 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > I was thinking about eg.
> > 
> >  /#1# auto summary goes here #/
> > 
> > (not saying necessarily this form, just showing the principle) where the "1"
> > can be different number according to the auto summary type.
> > 
> > Regexp for this is very easy and then you can then make a switch according to
> > the number to provide corresponding class.
> That's probably better. I thought you wanted to regex for the exact message.

The durability concern was the result of this dilemma: if to check the regexp in general form (say /# (.+) #/ - does not preserve since this would actually switch according wfMsg) or "typed" form (say /#([0-9]+)# (.+) #/ - does preserve, since it switches according the number which is always there). In the meantime I realized the preserving way would be better.

I also found out it actually *should* (if I read the code correctly) be possible to pass HTML summary directly - then there would the general regexp come back on stage since the class would already be present in the summary (say /# <span class="autosummary-replace>Replaced page with:</span> lorem ipsum dolor sit amet #/). But this has disadvantage of consuming a lot of characters in 200 chars summary field.

It seems to me that the numbered way is from these three ways the best unless somebody comes with something better than that.

However I think there maybe should be additional mechanism to differ if it's being rendered for recent changes, history or other page. My POV is that colorful (auto summaries in classes) history isn't necessary, but recent changes of course. But I don't know ATM, how to do that anyway... ;-) So possible phase 2 is for someone else... ;-)
Comment 10 Happy-melon 2010-03-14 21:00:52 UTC
This should be done (and can be done fairly easily) with JavaScript; it is of no use to anyone except power users, who are sure to have JS enabled.  Far too much complexity and hackishness for such a niche feature.  I'd say WONTFIX.

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


Navigation
Links