Wikimedia Bugzilla is closed!

<del>id</del> (*class* of course; as multiple ;-)

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!

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.

(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?

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?

(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.

(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?

(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.

(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... ;-)

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.