Last modified: 2014-11-04 19:26:06 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 T25796, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23796 - Provide a way to set page meta-data flags ("featured article", "protected", etc.), configure which ones are available for a wiki, and display icons indicating these statuses
Provide a way to set page meta-data flags ("featured article", "protected", e...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: 1.25.0 release
Assigned To: Bartosz Dziewoński
:
: 12548 (view as bug list)
Depends on:
Blocks: 10347 31738 51420 72199
  Show dependency treegraph
 
Reported: 2010-06-04 19:32 UTC by Rob Lanphier (RobLa)
Modified: 2014-11-04 19:26 UTC (History)
30 users (show)

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


Attachments
Partial implementation (4.83 KB, patch)
2010-06-08 16:09 UTC, Chad H.
Details
Partial implementation #2 (4.60 KB, patch)
2010-06-30 00:36 UTC, Chad H.
Details

Description Rob Lanphier (RobLa) 2010-06-04 19:32:33 UTC
Currently, the icons in the top-right of an article (e.g. the "featured article" star, the page protection lock, etc) are placed there via CSS absolute positioning.  This leads to quirky rendering bugs that cause these elements to render in unfortunate places.  Here is one example that works as of this writing:

http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook 

What we'd like is a standard place to put them in the html, along with a standard mechanism for extensions and page templates to be able to add new icons, so we can use more reliable CSS features to position them sensibly.
Comment 1 Rob Lanphier (RobLa) 2010-06-04 20:30:53 UTC
Thread on wikitech-l relating to this issue:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/48369
Comment 2 Jimmy Xu 2010-06-05 04:24:51 UTC
FYI, the (rough) implemention on zhwiki: [[zh:Template:Topicon]] and [[zh:MediaWiki:Common.js]] (search for "topicon).
Comment 3 Chad H. 2010-06-08 16:09:40 UTC
Created attachment 7439 [details]
Partial implementation

I've implemented the Parser/OutputPage/SkinTemplate portions of this code. 

Format is like this:
{{#pageicon:File1.ext|Alt text}}

Or like this:
{{#pageicon:File2.ext|Message-key-for-some-alt-text}}

You can use it multiple times in a page to allow for multiple icons like FA, page protection, etc. Still needs some loving to put it somewhere acceptable in the UI with the right styling though.
Comment 4 Roan Kattouw 2010-06-08 17:13:04 UTC
(In reply to comment #3)
> Created an attachment (id=7439) [details]
> Partial implementation
> 
> I've implemented the Parser/OutputPage/SkinTemplate portions of this code. 
> 
> Format is like this:
> {{#pageicon:File1.ext|Alt text}}
> 
> Or like this:
> {{#pageicon:File2.ext|Message-key-for-some-alt-text}}
> 
> You can use it multiple times in a page to allow for multiple icons like FA,
> page protection, etc. Still needs some loving to put it somewhere acceptable in
> the UI with the right styling though.
Looks good, now we just need a place to put it and slap some CSS on it.
Comment 5 p858snake 2010-06-20 01:15:51 UTC
Could we put it where en.wiki already has them, On the right edge of the title line (example: http://en.wikipedia.org/wiki/Cheese)? Although that might cause issues with templates that place them.
Comment 6 Happy-melon 2010-06-21 14:10:13 UTC
The if-a-system-message-exists-with-that-name-use-that implementation used in Sidebar is horrible; definitely not a good idea to extend its use any further.  If people want to add a translatable message, they should use {{int:...}}.  

I'd rather see this implemented either as full image syntax, or as full wikitext.  Supporting only 16px icons with no click-through doesn't actually solve the original problem, which was how to position the FlaggedRevs widget, as well as being useless for most of the things wikis use the icons for.  On the other hand, I *do* like the backend implementation via ParserOutput.
Comment 7 Chad H. 2010-06-21 14:26:10 UTC
(In reply to comment #6)
> The if-a-system-message-exists-with-that-name-use-that implementation used in
> Sidebar is horrible; definitely not a good idea to extend its use any further. 
> If people want to add a translatable message, they should use {{int:...}}.  
> 

Fair enough.

> I'd rather see this implemented either as full image syntax, or as full
> wikitext.  Supporting only 16px icons with no click-through doesn't actually
> solve the original problem, which was how to position the FlaggedRevs widget,
> as well as being useless for most of the things wikis use the icons for.  

I thought about that. I just didn't get to it. Opening up more of the image syntax (including linking) is a good idea IMO. However, I'm a bit leery of opening up all wikitext. This pfunc is designed for putting little clickable things in the upper right corner of articles, and I'm afraid what opening up the syntax might encourage.

> On
> the other hand, I *do* like the backend implementation via ParserOutput.

At least I did something right :)
Comment 8 Happy-melon 2010-06-21 14:37:11 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > I'd rather see this implemented either as full image syntax, or as full
> > wikitext.  Supporting only 16px icons with no click-through doesn't actually
> > solve the original problem, which was how to position the FlaggedRevs widget,
> > as well as being useless for most of the things wikis use the icons for.  
> 
> I thought about that. I just didn't get to it. Opening up more of the image
> syntax (including linking) is a good idea IMO. However, I'm a bit leery of
> opening up all wikitext. This pfunc is designed for putting little clickable
> things in the upper right corner of articles, and I'm afraid what opening up
> the syntax might encourage.

I agree it needs caution.  I think the main step is storing processed HTML in the ParserOutput array; that way extensions can add whatever they like to it (plus it's a bit wierd that what comes out of the 'parser' is not actually *parsed*  :D).  What we allow people to add directly from wikitext is a separate question.
 
> > On the other hand, I *do* like the backend implementation via ParserOutput.
> 
> At least I did something right :)

:D
Comment 9 Bergi 2010-06-21 19:12:51 UTC
Also HTML should be parsed. Many Icons and even messages use their own div, span, small or whatever whith individual ids oder classes, which are needed for the stylesheets. For an example look at [[:de:template:Shortcut]]. Links, and imagemaps or pictures-in-links, are a must. Otherwise this very useful extensions imho wouldn't be used.

Strong abuse by users could be prevented by using some CSS, like (max-)width and heigth, and the very useful overflow:hidden.
Comment 10 Chad H. 2010-06-28 17:52:56 UTC
I'm looking at this some more, and adding full wikitext isn't hard. But I think in doing that the name "pageicon" becomes less descriptive of a parserfunction name. 

Is there some general term we can come up with for "little clickable things in the upper right corner?"
Comment 11 MZMcBride 2010-06-28 18:03:22 UTC
(In reply to comment #10)
> I'm looking at this some more, and adding full wikitext isn't hard. But I think
> in doing that the name "pageicon" becomes less descriptive of a parserfunction
> name. 
> 
> Is there some general term we can come up with for "little clickable things in
> the upper right corner?"

Think of the RTL children.

"topicon" seems like a fine choice, though I don't really see an issue with "pageicon".
Comment 12 Chad H. 2010-06-30 00:36:40 UTC
Created attachment 7531 [details]
Partial implementation #2

Redid this with support instead for full wikitext. Still needs proper placement in skin files (under firstHeading?) and CSS ninja-ing.
Comment 13 entlinkt 2010-08-14 00:48:55 UTC
Positioning such icons (so that they work in all popular skins, of course, as users naturally expect) has so far been a very common, time-consuming (and rather silly) job of local administrators – see the list of interwiki links in [[Template:Top icon]]. Quite a lot of them, especially on smaller wikis, don't work correctly (or not at all).

The implementations are very different. Most wikis use position:absolute, but the French, German and Chinese Wikipedias use float:right together with a little script that moves the icons just before #firstHeading (see [[fr:MediaWiki:Common.js]], [[de:MediaWiki:Vector.js]] and [[zh:MediaWiki:Common.js]]).

While I would prefer having them just after #firstHeading semantic-wise, putting them before #firstHeading and floating them right (like editsection links) solves all the positioning problems in a simple, easily-maintainable way. See [[de:Wikipedia:Bewertungsbausteine]] using Vector for how it looks.

Ah, and there are also the coordinates that, for whatever reason, like to be positioned near the title in many wikis.
Comment 14 p858snake 2010-09-21 13:08:00 UTC
we need a css ninja, cc'ing trevor (blame reedy).
Comment 15 Trevor Parscal 2010-09-21 17:44:47 UTC
I'm very much in support of placing a div that can contain 1 - 5 (please not more than 3, but let's be realistic) 20x20px icons, and adding a parser hook to append images with links and titles to it.

However, we need to consider the transition from the old way to the new way - because if we place this div in essentially the same place as the old ones, the old ones with either be obscured or overlayed, either way that sucks.

How consistent is the templating to get these icons up there? If we could first hack together a template that all icons at the top use (if no single template exists already, than replacing the template with software would be simple.

Feedback on this idea would be helpful - I'm mostly just thinking out loud here.
Comment 16 Chad H. 2010-09-21 18:47:53 UTC
(In reply to comment #15)
> How consistent is the templating to get these icons up there? 

I think comment #13 has your answer:

(In reply to comment #13)
> The implementations are very different. Most wikis use position:absolute, but
> the French, German and Chinese Wikipedias use float:right together with a
> little script that moves the icons just before #firstHeading (see
> [[fr:MediaWiki:Common.js]], [[de:MediaWiki:Vector.js]] and
> [[zh:MediaWiki:Common.js]]).
>
Comment 17 Bergi 2010-09-21 19:14:12 UTC
It's not just about icons, [[de:Kategorie:Vorlage:mit absoluter Positionierung]] (templates with absolute positioning) gives you a short overview what could be placed in the same corner, concurrently.
@ comment #15: I dont think there would be a problem with overlaying icons, it's just a few templates to edit from the old syntax to <topicon> (or better <toptext>).
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-09-21 19:48:29 UTC
(In reply to comment #15)
> However, we need to consider the transition from the old way to the new way -
> because if we place this div in essentially the same place as the old ones, the
> old ones with either be obscured or overlayed, either way that sucks.

I don't think this is a big deal.  Any given wiki probably only has a few widely-used templates that do this effect, and they can all be changed simultaneously to the new system.  If there are any less widely-used templates that do it, it's okay if they break for a little while until someone notices and fixes them.  It should be incredibly easy to port templates to the new system -- replace the whole mess of CSS/JS/voodoo magic with one parser function call giving the image name.
Comment 19 Trevor Parscal 2010-09-21 20:41:04 UTC
(In reply to comment #17)
> It's not just about icons

I would like to see a system with firm boundaries and clear purpose put in place, so that each skin can predictably place these icons with some reasonable assumptions about their size and quantity. Allowing arbitrary HTML would over-complicate the situation in my opinion. What are the serious use-cases for placing something other than an icon in this location? Is that really the best place for that content, or is that just a place that was chosen arbitrarily? However, if there is a reasonable use-case, then I think we should support it.

(In reply to comment #18)
> I don't think this is a big deal

I'm not suggesting it's impossible or even hard to transition, I'm suggesting a transition strategy. I think you are right that the transition is pretty feesable.

I'm going to stop talking and start hacking something up.
Comment 20 Bawolff (Brian Wolff) 2010-09-21 21:06:43 UTC
>What are the serious use-cases for
>placing something other than an icon in this location?

GPS coordinates maybe. Although enwiki seems to place them slightly lower - ex: http://en.wikipedia.org/wiki/Toronto
Comment 21 p858snake 2010-09-21 23:36:20 UTC
(In reply to comment #15)
> I'm very much in support of placing a div that can contain 1 - 5 (please not
> more than 3, but let's be realistic) 20x20px icons, and adding a parser hook to
> append images with links and titles to it.
We shouldn't really limit the number like that, on articles that may be fine but people do use them else where, for example on en.wiki they are/can used to symbolize user rights (the mop, rollbacker, crat etc) or other things (Eg: [[User:Daniel]] uses ~24 icons to denote things.
Comment 22 Trevor Parscal 2010-09-21 23:38:49 UTC
(In reply to comment #21)
> [[User:Daniel]] uses ~24 icons to denote things.

And this is good why?

I'm nearly done with my first revision of this thing, and I have yet to place limitations on it.

If I do add limitations it would only be for initial view, and by expanding it a cookie would be set and it would display expanded from there on out until you collapsed it. Something like that would server both purposes.
Comment 23 Brandon Harris 2010-09-21 23:47:32 UTC
I think having more than 5 icons would be asking for a super duper amount of trouble, and I don't think that having an expando on it will help solve for bloat.  

We expando everything.  Too much, imo.  No; the only way to restrict bloat is to put a hard limit on the size that can be displayed.
Comment 24 Trevor Parscal 2010-09-21 23:52:54 UTC
How about r73498 - a new extension called ArticleEmblems. It collects the contents of <emblem>...</emblem> tags and adds them to a list rendered at the top of the page.
Comment 25 MZMcBride 2010-09-22 00:13:01 UTC
(In reply to comment #24)
> How about r73498 - a new extension called ArticleEmblems. It collects the
> contents of <emblem>...</emblem> tags and adds them to a list rendered at the
> top of the page.

Magic words and other variables like that generally aren't available to XML-style tags, so <emblem>{{PAGENAME}}</emblem> will probably fail. This can be worked around with {{#tag:emblem|{{PAGENAME}}}} I suppose, but it might be better to implement as {{#emblem:}} from the outset (similar to the {{#pageicon:}} proposal above).

I suppose I should probably go install the new extension and test it out before commenting further. :-)
Comment 26 MZMcBride 2010-09-22 00:51:38 UTC
(In reply to comment #25)
> Magic words and other variables like that generally aren't available to
> XML-style tags, so <emblem>{{PAGENAME}}</emblem> will probably fail. This can
> be worked around with {{#tag:emblem|{{PAGENAME}}}} I suppose, but it might be
> better to implement as {{#emblem:}} from the outset (similar to the
> {{#pageicon:}} proposal above).

Oh, bug 2257 (about XML-style tags and extensions) was fixed awhile ago. Hot damn. :D

I tested this new extension on localhost. It seems to work pretty well, though it's not purging the page cache when a template is changed. I'll leave a detailed comment at r73498.
Comment 27 entlinkt 2010-09-23 05:51:19 UTC
Some figures from dewiki: We currently have 10 templates that generate icons, but they are rarely combined. The vast majority of our 1125000 articles (99.5%) has no icons. 5762 articles have 1 icon, 121 articles have 2 icons, and I'm not aware of any situation where an article could have 3 or more icons.

We also have 11 templates that create text elements; the most used is the coordinates template with nearly 200000 transclusions (18% of all articles). The text can be rather long because Swiss towns have their coordinates in WGS84 and the Swiss national format (therefore the tiny font size of 10px), and they can also occur together with icons (see e.g. [[de:Tägermoos]]). The text templates are deliberately made so that no more than 1 can be used on a page (they would overlap).

I'm a little worried about the order in which the items appear in the wikitext becoming significant. That's fine for icons, but it may be desired to differentiate between icons and text elements. At dewiki, in most cases the coordinates are transcluded from and infobox the top of the article that can't be moved. Similarly, the icons are transcluded from a template at the bottom of the article that can't be moved either.
Comment 28 Trevor Parscal 2010-09-23 17:51:54 UTC
Seems like we could add a feature to article emblems that would allow overriding of the order on a case-by-case basis, the default being in the order they appear.
Comment 29 Derk-Jan Hartman 2010-09-24 13:16:27 UTC
Might be an idea to add a hook, to directly add emblems from the software in some way? Or am I overlooking that functionality?
Comment 30 Chad H. 2010-09-24 13:23:41 UTC
(In reply to comment #29)
> Might be an idea to add a hook, to directly add emblems from the software in
> some way? Or am I overlooking that functionality?

That's why I put it in core, with easily accessible methods from OutputPage, so things already hooking into the output page could add extra icons

(That was the motivation for this originally anyway...we wanted to move the FlaggedRevs box up there)
Comment 31 Nux 2010-09-29 08:01:49 UTC
(In reply to comment #28)
> Seems like we could add a feature to article emblems that would allow
> overriding of the order on a case-by-case basis, the default being in the order
> they appear.

The problem with this is that there are other elements that must be sort-in with javascript, but I guess it would simplify existing scripts anyway.

To see what I mean have a look at:
http://pl.wikipedia.org/w/index.php?title=MediaWiki:HeadingIcons.js

We put in header and sort:
* editsection - 0-section edit link added basically when articles are long
* padlock - added for locked articles
* (anything other goes here)
* coordinates
* shortcut_upper - WP:FP and such

An over exaggerated example is here:
http://pl.wikipedia.org/wiki/User:Beau/brudnopis

Note that in practice only one of icons on the right side of coords can exist in one article.

Anyway I don't think a 0-section link and padlock can be added with a template... Or maybe it could?
Comment 32 Platonides 2010-09-29 20:20:32 UTC
The 0-section edit link shouldn't be added with a parser function, since you would presumably want that on all pages [or some namespaces].

The padlock /could/ be added with this, just as it is done now. Although perhaps some auto-magic could be used to automatically show it on protected articles.

BTW, we should allow to add templates on the protecting action.
Comment 33 Bryan Tong Minh 2010-10-16 14:17:21 UTC
Just had a look at the extension. Any reason why you are creating your own table, instead of using page_props? That one is specifically meant for parser-added properties.
Comment 34 MZMcBride 2010-10-16 20:40:00 UTC
(In reply to comment #33)
> Just had a look at the extension. Any reason why you are creating your own
> table, instead of using page_props? That one is specifically meant for
> parser-added properties.

This is discussed here: r73498#c9500
Comment 35 Trevor Parscal 2010-10-17 05:35:20 UTC
See http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73498#c9500

What you are saying has been suggested. However, "since page_props has a unique key on the page and name columns, I would have to be packing all emblems into a JSON blob or something to make use of it - something I have mixed feelings about."

To elaborate on mixed feelings (for using page_props)

For: Fewer moving parts == Less complexity == good
Against: Packing data into a single page_prop row would make the data nearly un-query-able.
For: The data isn't really very query-able anyways, and packing it would probably be more performant.
Against: Maybe the data should be more queryable, such as requiring the emblem to be a template call or something, not just arbitrary wikitext

So - yeah, please feel free to weigh in, or just change the code, it's open source after all - I would welcome contribution and have no firm position on this matter.
Comment 36 Platonides 2010-10-17 20:48:00 UTC
You are just storing html there. So I think it makes more sense to store it in page_props now. We can always add a new table later if needed.
Comment 37 Daniel Friesen 2011-02-10 05:36:54 UTC
Heh, the was badly named... ^_^ this is actually a dup...
Comment 38 Daniel Friesen 2011-02-10 05:37:26 UTC

*** This bug has been marked as a duplicate of bug 12548 ***
Comment 39 Tim Starling 2011-03-24 06:50:14 UTC
(In reply to comment #38)
> 
> *** This bug has been marked as a duplicate of bug 12548 ***

You should have duped the other bug, since this one has more useful discussion on it.
Comment 40 Tim Starling 2011-03-24 06:50:31 UTC
*** Bug 12548 has been marked as a duplicate of this bug. ***
Comment 41 MZMcBride 2011-03-24 23:38:55 UTC
Tim did a review of the ArticleEmblems extension at <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73498#c15365>. Current status is that the extension needs to be rewritten, but there are no interested developers.
Comment 42 Trevor Parscal 2011-03-24 23:49:51 UTC
Re-written might be an overstatement, but clearly he's made a reasonable case for storing emblem data differently including using the page props system.
Comment 43 Daniel Friesen 2011-03-24 23:54:00 UTC
I wouldn't say no-one's interested. I am, but I've been to busy. I actually have page icons on the roadmap for skin rewriting, since as far as I'm concerned, they're part of skinning. However it's at a post-template-language implementation point. I want to take advantage of the xml/html based template language's ability to usage detect. ie: If you omit the page icons' marker it'll automatically inject it into the page title's content so that it still shows up.
Comment 44 Chad H. 2011-11-07 22:42:24 UTC
Removing need-review from my own patch.
Comment 45 Sumana Harihareswara 2011-11-09 04:00:02 UTC
+design, +reviewed
Comment 46 Matthew Flaschen 2013-07-27 01:16:17 UTC
(In reply to comment #0)
> What we'd like is a standard place to put them in the html, along with a
> standard mechanism for extensions and page templates to be able to add new
> icons, so we can use more reliable CSS features to position them sensibly.

This could also potentially be used for core features, such as protection.  These currently use templates on some wikis, but it would make sense in core.
Comment 47 James Forrester 2014-09-22 16:30:07 UTC
This feels like the main piece here is the meta-data setting for articles, and the display part is secondary. Moving to "Page editing".
Comment 48 Nemo 2014-09-22 16:43:34 UTC
(In reply to James Forrester from comment #47)
> This feels like the main piece here is the meta-data setting for articles,
> and the display part is secondary.

Really? I thought the opposite. Data is already available, currently in the form of templates and local scripts; the problem is how to output it in a non-conflicting way.
Comment 49 James Forrester 2014-09-22 16:50:30 UTC
(In reply to Nemo from comment #48)
> (In reply to James Forrester from comment #47)
> > This feels like the main piece here is the meta-data setting for articles,
> > and the display part is secondary.
> 
> Really? I thought the opposite. Data is already available, currently in the
> form of templates and local scripts; the problem is how to output it in a
> non-conflicting way.

That's not "data", that's random wikitext that's not machine-extractable.
Comment 50 Nemo 2014-09-22 17:56:34 UTC
(In reply to James Forrester from comment #49)
> That's not "data", that's random wikitext that's not machine-extractable.

That's not an opposition.
How data machine readability help with the original objective of this bug, that is:

(Rob Lanphier (RobLa) from comment #0)
> quirky rendering bugs that cause these
> elements to render in unfortunate places.
> 
> [...] What we'd like is a standard place to put them in the html, along with a
> standard mechanism for extensions and page templates to be able to add new
> icons, so we can use more reliable CSS features to position them sensibly.
Comment 51 Bartosz Dziewoński 2014-09-22 18:03:08 UTC
I'm going to work on this some time this week. *sinister rumble*
Comment 52 Gerrit Notification Bot 2014-09-24 15:42:30 UTC
Change 162609 had a related patch set uploaded by Bartosz Dziewoński:
Implement page status indicators

https://gerrit.wikimedia.org/r/162609
Comment 53 Gerrit Notification Bot 2014-09-24 15:42:40 UTC
Change 162610 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/162610
Comment 54 Gerrit Notification Bot 2014-09-29 11:30:41 UTC
Change 163558 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163558
Comment 55 Gerrit Notification Bot 2014-09-29 11:35:05 UTC
Change 163559 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163559
Comment 56 Gerrit Notification Bot 2014-09-29 11:37:55 UTC
Change 163560 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163560
Comment 57 Gerrit Notification Bot 2014-09-29 11:45:20 UTC
Change 163563 had a related patch set uploaded by Bartosz Dziewoński:
Add rudimentary support for page status indicators

https://gerrit.wikimedia.org/r/163563
Comment 58 Bartosz Dziewoński 2014-09-29 11:49:45 UTC
Patches:

* MediaWiki: https://gerrit.wikimedia.org/r/162609
* VisualEditor extension: https://gerrit.wikimedia.org/r/163563
* Vector skin: https://gerrit.wikimedia.org/r/162610
* MonoBook skin: https://gerrit.wikimedia.org/r/163558
* Modern skin: https://gerrit.wikimedia.org/r/163559
* Cologne Blue skin: https://gerrit.wikimedia.org/r/163560
Comment 59 Gerrit Notification Bot 2014-09-29 17:56:33 UTC
Change 163563 merged by jenkins-bot:
Add rudimentary support for page status indicators

https://gerrit.wikimedia.org/r/163563
Comment 60 Gerrit Notification Bot 2014-10-17 22:57:29 UTC
Change 162609 merged by jenkins-bot:
Implement page status indicators

https://gerrit.wikimedia.org/r/162609
Comment 61 Gerrit Notification Bot 2014-10-27 20:23:30 UTC
Change 162610 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/162610
Comment 62 Gerrit Notification Bot 2014-10-27 20:23:38 UTC
Change 163558 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163558
Comment 63 Gerrit Notification Bot 2014-10-27 20:23:47 UTC
Change 163559 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163559
Comment 64 Gerrit Notification Bot 2014-10-27 20:23:55 UTC
Change 163560 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163560
Comment 65 James Forrester 2014-10-27 20:28:00 UTC
Done. Thanks, Bartosz!

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


Navigation
Links