Template talk:Status

icon appears at bottom of page?
Hi, I just realized that the status icon is not visible when logged in, and it appears at the bottom of a page instead of at the top right when not logged in (see for example Spanish by Choice). I think I liked the previous layout better. --Martin Kraus (discuss • contribs)

from CSS and JS to
Hello! Check this - mw:Help:Page status indicators Iniquity (discuss • contribs) 15:18, 6 December 2015 (UTC)
 * To make this more formal, I propose using the  MediaWiki built-in feature instead of the   hack. The page indicators play more nicely with different skins, work without JavaScript and even prevent issues like triple-click on page title selecting the padlock as well. Can someone replace   with   (and its corresponding   with  )? Thanks in advance! (If there’s an established way of using sandboxes and testcases here in Wikibooks, I’m happy to use it, but I couldn’t find any.) —Tacsipacsi (discuss • contribs) 23:30, 15 August 2020 (UTC)


 * Becoming more dependent on stability of Foundation-supported "built-in features" sounds dangerous to me; la WMF è mobile. --Pi zero (discuss • contribs) 02:25, 16 August 2020 (UTC)
 * You don’t have to depend on WMF software, you’re free to find another service provider with another wiki software, the content is under a free license. But as long as you’re here, you use a massive amount of WMF software anyway. WMF’s engineers are not evil; they do their best to make the software work for as many people as possible. Yes, Wikibook’s own hacks are more stable than WMF software—stably broken. Your hack doesn’t work without JavaScript. It doesn’t work on Modern skin (example: the indicator becomes attached to the first section header instead of the page title). It makes triple-click title selection impossible. And there’s no guarantee that future changes to the interface (like the ongoing Desktop Improvements project) won’t break it even more severely, while built-in status indicators will certainly be thoroughly tested before rolling out anything; and if something breaks regardless, fixing it will be a top priority by any means, including temporarily rolling back the whole change. They won’t do anything like this just because some project’s already-broken hack breaks even more. Tacsipacsi (discuss • contribs) 14:44, 16 August 2020 (UTC)
 * It's nothing to do with "evil", and also actually not particularly about the devs as it's more of a policy sort of thing. And qualitatively different sorts of features do have varying levels of risk associated with them. --Pi zero (discuss • contribs) 15:52, 16 August 2020 (UTC)
 * And this is not one of the riskiest features—things like FlaggedRevs can break at much more points, yet you do use it. Actually, using local hacks that expect a certain DOM structure is way riskier than using a built-in parser tag, as DOM changes (which might happen from time to time) potentially break it, and WMF devs are not likely to fix these breakages. By the way, what policy states that WMF may break existing, well-defined interfaces like parser tags without prior notice? —Tacsipacsi (discuss • contribs) 16:16, 16 August 2020 (UTC)
 * ✅ I've added the indicator tag, but please feel free to call it from a new template indicator to facilitate its maintenance if needed. JackPotte (discuss • contribs) 06:41, 21 August 2020 (UTC)
 * If we must use the indicator tag at all &mdash;it's an inherently unwise thing to create dependency on imho&mdash; isolating it in a template sounds to me like a very good idea, yes. --Pi zero (discuss • contribs) 12:12, 21 August 2020 (UTC)