Article snapshot taken from[REDACTED] with creative commons attribution-sharealike license.
Give it a read and then ask your questions in the chat.
We can research this topic together.
<noinclude>{{Short description|Page for discussing Misplaced Pages technical issues}}<!--
<noinclude>
--><!--
{{village pump page header|alpha=yes|start=88|1=Technical|2=The '''technical''' section of the village pump is used to discuss technical issues ''about'' '''Misplaced Pages'''. Bugs and feature requests should be made at ] (]). Bugs with ] should be reported to {{email|security|wikimedia.org}}.
-->{{User:MiszaBot/config
<!--All of the text for this top section is found at template:Villagepumppages-->
Please do not move these categories to the end of the page. If they are there, they will be removed by the process of archiving the page.
-->
]
]
]
]
<!--
-->
-->
{{Village pump page header|1=Technical|2=The '''technical''' section of the ] is used to discuss technical issues ''about'' '''Misplaced Pages'''. Bug reports and feature requests should be made in ] (see ]). Bugs with ] should be reported differently (see ]).
{{cent}}
<!-- All of the text for this top section is found at template:Villagepumppages -->
If you want to report a ] error, please follow ]. Questions about ] in general should be posted at the ]. Discussions are automatically archived after remaining inactive for five days.
Please add new questions to the end of the page. The easiest way to add a question is to click the "New post" link, near the top of the page.
{{clear}}
<!--
Please do not move these categories to the bottom of the page. If they are there, they will be removed by the process of archiving the page.
-->]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]</noinclude><!--
Please add new questions to the bottom. The easiest way to add a question is to click the "add" link, just above the table of contents.
-->
-->
== What happened to Geohack? ==
{{resolved}}
Today, upon clicking the <nowiki>{{coords}}</nowiki> , I got a 404. Maybe this is a temporary problem, but given the use of the coords feature it's fairly impactful. ''']]''' 16:04, 17 January 2025 (UTC)
*It's down, and it isn't maintained by volunteers that are active on-wiki. The last RFC to move away from it didn't pass (c.f. ] and ] ). — ] <sup>]</sup> 18:13, 17 January 2025 (UTC)
*:One of the maintainers, Magnus Manske, is still active on wikidatawiki, I've pinged them to this report there. — ] <sup>]</sup> 18:19, 17 January 2025 (UTC)
:Click the globe icon instead of the coordinates for a map in Katographer for now. — ] <sup>]</sup> 18:15, 17 January 2025 (UTC)
== Preference for opening search result list or search suggestion in new tab ==
:Now working as intended. --] 🌹 (]) 17:15, 18 January 2025 (UTC)
::I'm intermittently getting unreachable errors. Not 100% sure it's resolved. ''']]''' 03:01, 22 January 2025 (UTC)
== Heading in history view ==
I propose a gadget (in preferences) for opening search results and suggestions in new tabs. I suggest basing it on the JavaScript found here:
*]
The following edits and show a different heading (corresponding to the section being edited) in the edit summary than edits (which was made using the convenient discussions tool) and (which was made using the reply tool). When navigating from the history view, clicking on the heading in the edit summary for the first two edits results in a popup saying {{tq|This topic could not be found. It might have been deleted, moved or renamed.}} I made my edit using the default wikitext editor. Does anyone know why it would produce an incorrect heading in the edit summary? ] (]) 19:34, 17 January 2025 (UTC)
It works great on both Misplaced Pages and the Commons. For implementation and more info read the talk page here:
*]
:@] there are problems in jumping to the correct section when the section heading contains links, either <nowiki>]</nowiki> or <nowiki>{{ }}</nowiki>. ] (]) 19:39, 17 January 2025 (UTC)
I also proposed this here:
::Sure; just wondering why the behaviour is inconsistent with the reply tool and the default wikitext editor (I would have thought the same code would be used to generate the heading for both use cases, but I guess not). ] (]) 19:48, 17 January 2025 (UTC)
*] - but that page does not seem very active. --] (]) 10:10, 12 April 2012 (UTC)
:::{{ping|Isaacl}} Your post was confusing because your third link was the same as the second and you didn't clarify what was supposed to be different. The wikitext of the actual heading says <code><nowiki>Dark mode and {{tl|Yes}}</nowiki></code> which renders as "Dark mode and {{tl|Yes}}" without <code>tl</code> being displayed. Your second link uses the wikitext with <code>tl</code> in the edit summary and fails to link to the section. Your third link should have been where the edit summary uses the rendering without <code>tl</code> and links correctly to the section ]. Different discussion features apparently use different ways to generate the automatic section edit summary and one of them works better in this case. ] from 2014 is about the issue. ] (which doesn't apply to project space) says "For technical reasons, section headings should: ... Not contain template transclusions." ] (]) 20:46, 17 January 2025 (UTC)
::::My apologies for the copy and paste mistake for the links. Yes, obviously the edit summaries and underlying link text are being generated in different ways. I was wondering if it is a visual editor vs default wikitext editor difference, or something else? And if it was fixed for visual editor, was there an issue in following the same approach for the wikitext editor (maybe the fix was just partial, or not sufficiently resilient?). But I'm not asking for anyone to do any deep research on it. If someone knows off the top of their head, it would be nice to know. Thanks for the Phabricator link; it helped provide some context. (I know about the style recommendation for section headings; thanks for the reference.) ] (]) 23:31, 17 January 2025 (UTC)
:Basically, this happens because the wikitext editor generates the edit summary directly from the wikitext of the heading, while the visual editor generates it from the parsed HTML of the page. The HTML contains the <code>id</code> attribute needed to make the correct link, but generating the correct link from the wikitext would require parsing it to HTML first, and most of the tools don't bother to do that.
:The same applies to other wikitext-based editing tools and other HTML-based editing tools. There are more tasks in Phabricator about this, ] is a good summary and has even more links.
:The only wikitext-based tool I know that does this better is DiscussionTools's new topic tool's wikitext mode, where we solved it as a side-effect of ] – we needed to parse the HTML for some other reasons, and once that was implemented, adding a bit of code to read the <code>id</code> attribute out of it was easy. In principle the same approach could be used in other editors, but it is tricky to get the data from point A to point B, especially without affecting performance, and no one has put in the effort to do it yet. ] <small>]</small> 23:23, 18 January 2025 (UTC)
::Thanks for the explanation! ] (]) 23:33, 18 January 2025 (UTC)
== Why is this image acting so odd? ==
::I started this ] thread: "'''Bug 35974 - Preference to open search results and suggestions in new tab'''".
], floated in this section, doesn't give a thumbnail. In this it turned into a page-wide hyperlink to the image page. When I click on the link, I see "Unauthorized
This server could not verify that you are authorized to access the document you requested." What's going on there? ] (]) 16:54, 18 January 2025 (UTC)
:This looks like a recurrence of ]. --] 🌹 (]) 17:16, 18 January 2025 (UTC)
::Thanks for explaining and for reporting the bug, ] (]) 03:31, 19 January 2025 (UTC)
:::It wasn't me, it was {{user|Dylsss}}. --] 🌹 (]) 10:36, 19 January 2025 (UTC)
=== Page mover SVG broken? ===
::But that may take a long time. Is there any reason this can't be implemented as a gadget now on English Misplaced Pages? Many people want it. --] (]) 16:23, 14 April 2012 (UTC)
Is it just me or is ] somewhat broken? I'm getting "Sorry, the file cannot be displayed There seems to be a technical issue. You can retry if it persists. Error: could not load image from <nowiki>https://upload.wikimedia.org/wikipedia/commons/thumb/4/4b/Wikipedia_page_mover.svg/1024px-Wikipedia_page_mover.svg.png</nowiki>" when clicking the image on ]. I have tried on Firefox, Chrome, Edge, iOS Safari with or without safemode, all yield the same results. However, clicking the original file doesn't generate the same error. '''<span style="color:#f535aa">—</span> ] <span style="color:#f535aa">(] • ])</span>''' 13:36, 19 January 2025 (UTC)
:::After adding the JavaScript mentioned above, clicking the search icon when the form is empty takes one to ] in a new tab.
:::So this proposed gadget solves many problems. Also, there are many suggested search enhancements discussed here:
:::]. Some of them depend on getting to ]. --] (]) 15:40, 6 May 2012 (UTC)
== Gadget proposal ==
=== Search link in sidebar would fix the problem too ===
We currently have a gadget that makes disambiguation links orange, which makes correcting said links much easier. Would it be feasible to create something similar for redlinks to articles that have previously been deleted? For instance, let's say I'm writing an article on an academic named Joe Bloggs, who published a significant work cowritten by Joe Public. I believe Joe Public is notable, but he does not currently have a Misplaced Pages article, so I create a redlink. However, I failed to check the page's deletion log (!!), which shows that an article on Joe Public did once exist, but it was deleted after its subject was found to lack sufficient independent coverage. Now imagine if I had a gadget that made that redlink purple (or pink, or maroon, or black; I'm not picky), so I would know at a glance to not bother to create a link for a person who has already been determined to not meet notability criteria. It would also make it easier to spot and correct such links while looking through other articles. Much like with the existing gadget I mentioned, this is, of course, still a process that can be done manually, but a gadget would make it much more efficient. ] 19:22, 18 January 2025 (UTC)
Putting an "advanced search" (]) link in the sidebar would fix the problem too. People could right-click it to open it in a new tab. Most readers do not know much about how to find stuff on Misplaced Pages. They try the search form, but soon see that it covers up the page they are looking at. Many people stop using the search form after that, and use ] instead for site searches.
:{{ping|An anonymous username, not my real name}} MediaWiki adds the class mw-disambig to links to disambiguation pages like ]. This means the gadget only has to say links with that class should be orange. The entire code of the gadget is one line in ] and it's client-side with no impact on the servers. MediaWiki does not add a class to red links with a deletion log like ]. A gadget would have to make an API call to the servers for each red link on a page to check for deletion logs. I don't think that's worth the server load even if somebody would make the non-trivial code. ] (]) 20:33, 18 January 2025 (UTC)
::That's fair. Thank you for taking the time to explain. ] 20:57, 18 January 2025 (UTC)
::The script, as noted, only has to hit the servers for redlinks. More broadly ], that's the server admins' job. If it became a problem they would alert us. There is also a lot of caching in user agents as well as the WMF servers, and this is only doing reads so it hits the caches. --] (]) 01:34, 19 January 2025 (UTC)
:You probably want to raise this as a feature request for ] instead. – ] (]) 10:39, 19 January 2025 (UTC)
:: I don't know that I'd implement such a request. Most of what linkclassifier does is based on categories (a little is based on page props). To do this, it'd have to query the logs for each page, which is a whole different thing. ]] 15:04, 19 January 2025 (UTC)
:Just curious, what gadget makes dab links ''orange?'' I have the one that makes redirects green, dab page links have a ''yellow background'', etc... - ] <sub>]</sub> 23:52, 19 January 2025 (UTC)
::{{ping|The Bushranger}} It's "Display links to disambiguation pages in orange" at ]. The feature you describe is not a gadget but a user script you load in ]. ] (]) 00:06, 20 January 2025 (UTC)
:Just because a page has previously been deleted, you can't assume that the article you were going to create would fail our notability criteria. Notability is far from the only deletion criteria, and especially if you are creating articles on people, you can't always assume that the person you were going to write about is the same person as the adolescent pro skateboarder whose article was deleted fifteen years ago. They may just have the same name. That said, some sort of colour coding or pop up that alerted you to there being a previous article of that name and the reason and recency of deletion might be helpful. New page patrol has a recently deleted colour which usually indicates that someone is repeatedly trying to create a particular article. '']]<span style="color:#CC5500">Chequers</span>'' 06:59, 20 January 2025 (UTC)
== Do certain configuration templates need to be in the first <var>n</var> bytes of a page? ==
But Google Toolbar does not allow one to pick and choose namespaces to search. ] does do this. Also, Google no longer makes Google Toolbar for Firefox. So, putting an "advanced search" link in the sidebar would solve many problems. --] (]) 05:35, 23 April 2012 (UTC)
I have a vague recollection that certain templates need to be in the first <var>n</var> bytes of a page? I'm thinking of templates like these:
=== Or search link in a drop-down menu at the top ===
* {{tl|CS1 config}}
* {{tl|use dmy dates}}
* {{tl|Use British English}}
* {{tlu|User:MiszaBot/config}}
* {{tl|Italic title}}
* {{magic word|DISPLAYTITLE}}
I can't find anything about this in searches of documentation here or at ] It looks to me like ] searches the entire page contents. Do other bots or scripts care? ] (]) 19:23, 18 January 2025 (UTC)
:Moving configs somewhere else which CS1 relies on is likely to have a non-zero increase on the Lua execution time associated with a page. (These metadata are incidentally good candidates to move to something like ] since they definitely don't need to participate in transclusion and are otherwise pretty simple settings.)
In preferences there is a gadget (in the appearances section of the gadget tab) called "Add page and user options to drop-down menus on the toolbar." The search link could go there in the drop-down menu. That may be the simplest way to get searches done in a new tab. Also, it does not take up any valuable real estate in the sidebar or at the top. Any thoughts? --] (]) 14:48, 29 April 2012 (UTC)
:Title templates are there because they modify the title though you could theoretically move them.
:Archiving template is there because it would otherwise get lost by archiving of threads + addition of new threads. ] (]) 20:31, 18 January 2025 (UTC)
:AFAIK the only one that is position-critical is {{tlux|User:MiszaBot/config}}, which must be before the first section heading (of any level), i.e. in the lead section. This is to guard against it being accidentally moved to an archive, which might happen if it were placed inside a section (or subsection) which became archived. It's possible that {{tlx|CS1 config}} might need to be before the first ]/] template, but not if the relevant JavaScript function(s) has been written carefully. {{pb}} The others are definitely position-independent, but do have conventional positions, summarised at ]. --] 🌹 (]) 22:09, 18 January 2025 (UTC)
::] reads article wikitext looking for {{tlx|CS1 config}}, {{tlx|use dmy dates}}, and {{tlx|use mdy dates}} (and any of their redirects). Of course, the earlier these appear in the wiki text, the less work the module needs to do. But, if none of them appear in the wikitext, the module still must scan all of the wikitext to be sure that none of them exist so placement really doesn't matter. Scanning for the {{tld|use xxx dates}} could be made faster by eliminating some of the several redirects but that suggestion has already been dismissed ].
::—] (]) 22:39, 18 January 2025 (UTC)
== Mouse-over popups and redirects ==
=== Can now be imported into any-language Misplaced Pages ===
I've enabled ] that pops up a micro-summary of an article whenever I mouse over a link to it. Unfortunately, it's not working properly with redirects. For example, if visit ], I'm given the following text: ''I dedicate this book to my parents, ], and ]''. If I mouse over the first link, I get a picture of Amis and this text:<blockquote>Martin Amis ⋅ actions ⋅ popups
Here below is what people can add to ] - for me that ends up here: ]. The JS links are for English Misplaced Pages (en). Change the links as necessary for other-language Wikipedias.
Sir Martin Louis Amis (25 August 1949 – 19 May 2023) was an English novelist, essayist, memoirist, screenwriter and critic. He is best known for his novels Money (1984) and London Fields (1989). He received the James Tait Black Memorial Prize for his memoir Experience and was twice listed for the Booker Prize (shortlisted in 1991 for Time's Arrow and longlisted in 2003 for Yellow Dog).</blockquote>However, if I mouse over the second link, I get this text:<blockquote>JK Rowling ⋅ actions ⋅ popups<br />Redirects to<br />J. K. Rowling ⋅ actions</blockquote>'''Is there a way to change this''', so that the popup shows the target of the redirect (as if the link went to the target), rather than the redirect itself? I can't imagine a reason why we should care whether it's an article or a redirect. The documentation suggests that identifying pages as redirects helps people fix them, but ''You probably don't want to "fix" such links every time you come across them'', and ] actively prohibits changing those redirects without some alternate reason, e.g. it's fine to replace "JK Rowling" with "J. K. Rowling" if we want the full stops and space to appear in the article, but not good to edit the article just to change <nowiki>] to ]</nowiki>. If there are any legitimate uses for distinguishing redirects from articles with this tool, that's different, but as far as I can see, it merely gets in the way of using this tool. ] (]) 22:12, 19 January 2025 (UTC)
/* Open search results list and search suggestions in new browser tab */
:{{ping|Nyttend}} The first time I hover over a redirect like ] after loading or reloading a page, I see text from the target below the text you quoted. If I come back to hover over the same link, I only see what you quoted. ] (]) 23:58, 19 January 2025 (UTC)
Hi, Good day. I am having trouble loading Huggle as no list of articles/edits is shown on it. Below are the system logs.
=== Popular Firefox search addon opens results list in new tab ===
Mon Jan 20 13:09:53 2025 Failure of feed provider XMLRCS on enwiki, trying to find some alternative provider<br>
Featured, popular Firefox search addon: . From its description:
Mon Jan 20 13:09:53 2025 ERROR: XmlRcs failed: redis is empty for 10 seconds
Kindly advise me on what I can do or point me to the right editor/talk page for help. (I didn't go to the Huggle talk page for this issue, as the talk page is not very active and, at times, no one replies to messages. Thank you. ] <span style="border-radius:8em;padding:2px 5px;background:#0151D2;font-size:75%">]</span> 02:24, 20 January 2025 (UTC)
Once the search engine menu is visible:<br>
- ''Left click to search in a new background tab.''<br>
- Middle click to search in a new tab and switch to that tab immediately.<br>
- Ctrl+click to search in a new tab and switch to that tab immediately.
:@]: You can temporarily change the feed provider. Just open the System menu, click on <code>Change Provider</code>, and set it to <code>Wiki</code>. – ] <small>(])</small> 09:57, 20 January 2025 (UTC)
If you have Firefox set to switch to new tabs immediately, the above key combinations will have the inverse effect.
:{{u|DreamRimmer}} Thank you so much. It worked! Be safe and best.] <span style="border-radius:8em;padding:2px 5px;background:#0151D2;font-size:75%">]</span> 10:07, 20 January 2025 (UTC)
=== Issue - Loading ] ===
Shift + click opens search results in a new window. ''(End of description quote)''.
Hi, Good day. I am having trouble loading Huggle as no list of articles/edits is shown. Below are the system logs.
Mon Jan 20 13:09:53 2025 Failure of feed provider XMLRCS on enwiki, trying to find some alternative provider<br>
This is one of the most popular Firefox search addons. I believe part of the reason it is so popular is that it opens the results list page in a new tab. That is the default setting. '''So search never interferes with what you are doing or what page you are reading.''' On the other hand the results from Misplaced Pages's search form at the top right of every article page cover up the article that one is reading. It is very annoying to many people. --] (]) 22:22, 15 May 2012 (UTC)
Mon Jan 20 13:09:53 2025 ERROR: XmlRcs failed: redis is empty for 10 seconds
Kindly advise me on what I can do or point me to the right editor/talk page for help. (I didn't go to the Huggle talk page for this issue, as the talk page is not very active and, at times, no one replies to messages. Thank you. ] <span style="border-radius:8em;padding:2px 5px;background:#0151D2;font-size:75%">]</span> 02:17, 20 January 2025 (UTC)
=== Ctrl-click does not work to open search result list in a new tab ===
:Have you tried setting it to another provider like IRC or Wiki? ] 02:31, 20 January 2025 (UTC)
At least in Firefox for Misplaced Pages this is true. Neither does shift-click, nor ctrl-shift-click, nor alt-click. --] (]) 23:57, 20 May 2012 (UTC)
:: {{U|Frost}} Thank you for your reply. No, I have never have this issue and this is the first time after using Huggle for many years. How do I set to IRC or Wiki as provider? (note: I am not technical). Thank you.] <span style="border-radius:8em;padding:2px 5px;background:#0151D2;font-size:75%">]</span> 02:41, 20 January 2025 (UTC)
:::From the toolbar at the top, click System > Change provider. ] 02:49, 20 January 2025 (UTC)
::::{{U|Frost}} I changed to Wiki, and it worked! Thank you very much for helping me. Thank you! Be safe and best.] <span style="border-radius:8em;padding:2px 5px;background:#0151D2;font-size:75%">]</span> 03:01, 20 January 2025 (UTC)
:::::{{replyto|Cassiopeia}} This is not a matter for ]; and as you also created a near-identical thread here at WP:VPT, I have combined the two. --] 🌹 (]) 18:32, 20 January 2025 (UTC)
== Watchlist-boldletterarticle titles! ==
== Requst for file name change ==
On January 17 I uploaded the image '''LMC SMC Bab al Mandab.png''', which shows the present (2025) position of the Large and Small Magellanic Clouds over the southern horizon. I have now created an accompanying image, LMC SMC Bab al Mandab_900.png, which shows the same thing as seen in the year 900. If possible, please rename the first image '''LMC SMC Bab al Mandab_2025.png'''.
:''See also ]
If this is not the proper page for such a request, please advise. ] (]) 09:14, 20 January 2025 (UTC)
{{Tracked|33123}}
Suddenly, the article titles in watchlist are in bold letters. I dislike the use of bold letters, since the article titles are not important, but the changes have been made are important in watchlist. --<small style="border: 2px dotted;padding:1px 4px 1px 3px;white-space:nowrap">''']''' ''']'''</small> 16:51, 10 May 2012 (UTC)
:Just hit the button that says mark all viewed. The bold is to show which you have visited and which you haven't. I don't really like it either so I just hit the button every once in a while. ] (]) 16:55, 10 May 2012 (UTC)
::I absolutely ''hate'' having to do that!--] ] 16:55, 10 May 2012 (UTC)
:::Fully Agree - makes the Watchlist page much more difficult to read, not easier. Don't know whose idea it was, but it wasn't bust, so you haven't fixed it. Please revert to the old layout or at least provide a switch in My Preferences to turn it off. ] (]) 16:58, 10 May 2012 (UTC)
::::I expect there is a way to turn it off in preferences but its locked at the moment. If you look under gadgets there's probably a new feature box to turn it off. ] (]) 17:00, 10 May 2012 (UTC)
:::::But an article I'v just been editing doesn't show up bold. And articles that I watch and have never edited show up as bold. I don't think it's working right. It's awful. ] (]) 17:02, 10 May 2012 (UTC)
::::::Like the Village pump isn't bolded on my watchlist, and I just edited it. ] (]) 17:07, 10 May 2012 (UTC)
:::::::I'm pretty sure the bolded pages are ones you haven't viewed since they were last updated, while the non-bolded ones are ones you have viewed since they were last updated. I think that is the way it is intended to work, but I too would like an option to turn the bolding off. ] (]) 17:11, 10 May 2012 (UTC)
:So ... ugly, non-useful, and distracting is the default which can only be gotten around by a manual action each time the page gets viewed? Not good. Should be a setting added to User Preferences.
:While we're on the subject of ugly, non-useful, and distracting changes ... adding green-blocked text on the history tab should also be a User Preference setting. Hopefully a .css setting can be changed to at least change that back to the standard background color. --- ] <small>(] • ])</small> - 17:03, 10 May 2012 (UTC)
::You can try this CSS code in your common.css page.
<syntaxhighlight lang="css">
strong.mw-watched { font-weight: normal !important; }
</syntaxhighlight>
::Hopefully this won't be needed long. – ]4] 17:05, 10 May 2012 (UTC)
:::Thanks for that - it's good enough for now. ] (]) 19:10, 10 May 2012 (UTC)
::No - no off-switch in My Preferences - Gadgets ] (]) 17:07, 10 May 2012 (UTC)
::::Where is this off-switch? I can't seem to find it. – ]4] 17:15, 10 May 2012 (UTC)
:::::He said there is none, apparently. But if this change is permanent, a gadget or preference to shut it off will probably be added soon. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 17:18, 10 May 2012 (UTC)</font>
:Chances are it won't last. They try this every once in a while and it always gets turned off after a while (due to bugs I think). If they do finally keep it around this time, you'll get used to it. It's like everyone complaining about facebook changes, then a week later they can't remember how it used to be. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 17:13, 10 May 2012 (UTC)</font>
::Your right I agree. IMO they would be better off adding ] as a standrd than this though. ] (]) 17:22, 10 May 2012 (UTC)
:Take this damned eyesore away! Why are such New! Brighter! Whiter! "improvement" crap always inflicted on us without notice - then we are forced to jump through hoops to turn the bloody irritants off! They should be opt-in choices, not opt-out. ] (]) 17:23, 10 May 2012 (UTC)
*Ugh, I participated in the discussion where it was decided this should be enabled (]) and was assured that if activated there would be a gadget/preference where I could switch it off. Why can't whoever's implementing this make being able to switch it off the first priority instead of the last? ] (]) 17:23, 10 May 2012 (UTC)
*Just adding my voice to those who say this is harder to read. Would appreciate some way of being able to switch it off. ] <small><sup>]</sup></small> 17:26, 10 May 2012 (UTC)
*Utterly hideous. Please make it go away. ] (]) 17:29, 10 May 2012 (UTC)
*Agree. This is very annoying. I don't need a bold face telling me that I need to click on every diff from Helpful Pixie Bot or AnomieBot or MiszaBot. –] (] ⋅ ]) 17:32, 10 May 2012 (UTC)
*It looks the worst when you have a whole day of unviewed changes and the page is full of bold text. Good idea, bad appearance. ] (]) 17:35, 10 May 2012 (UTC)
*Far too distracting, not fit for purpose. Please remove and rethink. (] ]) 17:37, 10 May 2012 (UTC)
* Just another voice of disapproval, I genuinely despise this change, having been glad when I joined[REDACTED] that it wasn't used here (I've seen it used on other wikis using similar software before). A way to remove it would be ''hugely'' appreciated. ] ] 17:38, 10 May 2012 (UTC)
*(copying from my comment at ]) I really, really would like a way to turn this off. For users like me, who do a lot of their pageviews and diff views through popups, this "unread" bolding misses the point entirely, and results in nearly my entire watchlist being perpetually bold. I understand it could be a useful feature for others, and I can live with it being enabled, even by default, for that reason but pleeeeease give me a way to turn it off in my prefs. ] (]) 17:39, 10 May 2012 (UTC)
*Bold the change times, instead of the article titles. --] <sup><font face="Calibri">'']''</font></sup> 17:39, 10 May 2012 (UTC)
:Bold should be the exception not the norm. ] (]) 17:40, 10 May 2012 (UTC)
*This feature would be a useful tool if one could opt-IN rather than being forced to opt-OUT. ] (]) 17:43, 10 May 2012 (UTC)
* Yes, and it would be helpful if some sort of banner informed us of the impending change, just logged out did a Ccleaner to check that it wasn't some malware fugging around, and then figured that if it wasn't at the Help Desk, it'd be here. Yuk! Make it go away. <b>] <sup>]</sup></b> 17:54, 10 May 2012 (UTC)
*I dislike this. I'm all for making it easier to remember which pages have changes I haven't viewed yet, but for a watchlist with 900+ items on it this is a bit excessive...there's no way I'm going to visit all of those pages regularly even if they get changed. It's great for projects I only visit once and a while like Wiktionary or Wikinews, but on English Misplaced Pages this feature gives me more hassle than I get benefit. An option to turn off this feature would be nice, but not urgent. ] <sup>(]•]•]•])</sup> 18:05, 10 May 2012 (UTC)
*Yet AGAIN something that's a SUBJECTIVE change where they don't give a CHOICE. Make it an option and make the OLD way default (and remove that hideous gray button too). ] (]) 18:14, 10 May 2012 (UTC)
*Another vote for the dislike camp. This sort of change would be so much better if it were opt in. This makes the page harder to read. - ] (]) 18:14, 10 May 2012 (UTC)
*Ugh! Please turn it off. ] (]) 18:25, 10 May 2012 (UTC)
*Well, hey, just so it doesnt seem like ''everyone'' hates it. I think it's a good idea though I'll admit I don't read all the pages on my watchlist anymore. But if I did then it's good to be able to know where I've been. <b>]]]</b> 18:27, 10 May 2012 (UTC)
*With Ks0stm on this one - on Commons it's nice, here it's unmanageable. --''']]]''' 18:33, 10 May 2012 (UTC)
*Adding to my earlier comment - I have almost 2000 watchlist items. I, at most, look at only one in ten of the items on my watchlist on any given day. I can actually tell the difference between visited and unvisited links - a colour change has been a standard feature of browsers since Microsoft's head office was in dad's garage! No change should ever be permitted to "go live" without a working disable switch but in any case they should always be opt-in, not opt-out. Why were we not all given a '''prominent''' notification of this in the form of a banner? Do the software geeks even live on the same planet us we lowly "unworthy of being consulted about such highly important and sophisticated technology" users? Finally; where should we send the hate-mail? ] (]) 18:35, 10 May 2012 (UTC)
*'''Make it stop, please :( ~~ ] (]) 18:38, 10 May 2012 (UTC)'''
*I agree, please turn it off by default or at least allow us to switch it off. Regards ''']]''' 18:52, 10 May 2012 (UTC)
*Sadly, a poor solution to what was not really a problem. Implementing the feature might have had consensus, but I don't think there was consensus for it to be on by default, and there was certainly no consensus to not allow editors to disable it at all. At the very least, let us turn this off; I would suggest that, unless consensus is established otherwise, the default is to be switched off. ] <sup>(] • ])</sup> 19:05, 10 May 2012 (UTC)
*'''Kill it with fire''', but please first disable the feature so I don't have to see the change where it was killed be bold. I dislike when others tell me (and especially ''change'') what part of a display deserves my attention and don't let me control that (I also see where this concern was explicitly raised in the discussion leading to it!). My use of watchlist is not centered around "what changes have I not examined yet?", which is what this bolding emphasizes. And by keeping already-viewed not-bold, those pages become essentially invisible, lost in the wall of non-bold text that includes all the details of the changes (who/when and links). If the goal is to help us find pages whose changes we haven't seen yet, how about a checkbox to filter the list on exactly that criterion? I use popups to see the of the change and to browse the of recent changes so it's quite likely that I will ''never'' click on the link for the page itself, so "changes I've seen" are not registered and the page stays bold. That's functionally broken, not just "bold is annoying". ] (]) 19:07, 10 May 2012 (UTC)
*Really annoying. I use ] to view diffs on my watchlist and rarely view the full link. Please disable, make Opt-in, or provide a gadget to make this go away. --] ] 19:08, 10 May 2012 (UTC)
*Get rid of it! I don't like it as I think it's completly unnessecary and distracting and why were we not informed before this was thrust upon us? ] (]) 19:33, 10 May 2012 (UTC)
*The thing is, I don't ''want'' to check each page that has changed. About half of the pages that pop up in my watchlist are vandalism reverts, some others are on discussions that don't bother me. I usually open all the changes that interest me in a separate tab before I'm reading them, so this change doesn't help me in any way. If it is kept it should be made optional. It could also help to mark viewed pages in ''italic'' letters, which are far less distracting. ] (]) 19:35, 10 May 2012 (UTC)
*''']!''' Seriously... This is something that the Engagement group would have nailed to the wall in early user acceptance ad completely un-acceptable. Please let me know when ]. ] (]) 19:38, 10 May 2012 (UTC)
*There has beena big discussion on bolding of epsiode titles for episode list template and it was removed as it was agreed it conveys MOS and also makes it harder to read witha screen reader, altohugh i personally like bolding this is to far even for me with dsylexica i dnt need it highlight in bold to knwo there a change since i generally know what time i was last on so i look at all changes i feel are relevent to look at and review them from the pop up for history, either make it not default or give the abilty to turn it off, very bad idea that has made it nearly unreadable to disable users like myself--] (] - ]) 20:08, 10 May 2012 (UTC)
*Just a thanks to those who explained how to override this change. I've got no desire to argue about pros-cons of this in general, but I was definately looking for a way to turmn it off.--] (]) 20:45, 10 May 2012 (UTC)
*Turn it off by default. It's useless for anyone who uses Popups. And as far as community opinion goes, you're getting it here, now. —]] 20:48, 10 May 2012 (UTC)
*:{{done|Bold letters changed to stars}}—] <sup>]</sup><sub style="margin-left:-3.7ex"><font color=olive face=arnprior>Online</font></sub> 20:58, 10 May 2012 (UTC)
*Brilliant. As soon as a kludge arises to deal with some of the changes, said changes are replaced with something else instead; rather than spending time coding green stars instead of bold links, just devise an opt-out function and the problem's solved. ] ] 20:56, 10 May 2012 (UTC)
*The stars are annoying for similar reasons. They're less cluttersome to the watchlist, but as I said before, I don't need the interface telling me "LOOK AT THIS BOT EDIT or MINOR EDIT, DON'T YOU WANT TO SEE IT, WHY DIDN'T YOU LOOK AT IT YET." –] (] ⋅ ]) 21:06, 10 May 2012 (UTC)
*Please turn this off! The green stars are only marginally less annoying and perhaps equally as annoying as the bolded text. Each time I log in today I see something different. We have masses and masses of discussions about the smallest things here, but three major changes in a day? What happened to Misplaced Pages where consensus rules? ] (]) 21:12, 10 May 2012 (UTC)
*] Off-think, off-think, off-think. Bolding and stars, it's like throwing glitter over the watch-list to make it pretty. Ugh. --] (]) 22:22, 10 May 2012 (UTC)
*I would get rid of this entirely, but if this is to stay, or for the interim, can we change {{highlight|updated since my last visit|lime}} in page histories to green stars as well?--] (]) 22:26, 10 May 2012 (UTC)
*#Why is this not optional for those who want it, and not off by default for those who don't even know what it is?
*#Why is there no legend or something explaining what it means? It's very disorienting, and it wasn't easy to find out what it was about.
*#Why is it so difficult (non-obvious) to shut off? <span style="padding:0 .75ex;font-variant:small-caps;background-color:#fdd;">]<small><sup style="margin-left:1.5ex;">]</sup><sub style="margin-left:-5ex;">]</sub></small></span> 23:17, 10 May 2012 (UTC)
:::Because we have always had a problem where the developers make sweeping changes without any real community input—the change from the Monobook Skin to the Vector Skin being a sterling highlight (the alleged community input and testing there was an absolute sham).--] (]) 23:21, 10 May 2012 (UTC)
*'''Seeing text on your watchlist in boldface must be an eyesore, especially if your watched pages are heavily edited and you weren't aware of the change earlier, isn't it? I knew we should always ], but not like this. ] <sup>]]]]</sup> 02:16, 11 May 2012 (UTC)'''
*The green highlighting on history pages is bloody awful. Get rid of it! ] 04:23, 11 May 2012 (UTC)
*Even though pretty much everything has been mentioned, I wanted to add that it's hard to read (on this (admittedly small) monitor I'm currently using, anyway). Also, it will be crap to deal with after my two-month wikibreak I'll be taking in about two weeks. - ] (]) <small>(])</small> 04:35, 11 May 2012 (UTC)
* '''Kill with fire This is awful. It makes the watch list more difficult to read. A particular mistake is that it makes assumptions about how people use the watchlist and what they do when they visit a page. It sounds like something that would make a nice gadget - maybe some people would like it or find it useful, but it is a great assumption that many or everyone would.''' --] (]) 12:44, 11 May 2012 (UTC)
:@]: You uploaded ] to Wikimedia Commons so you will need to request a rename there. You can read ] for guidance on how to rename a file. To rename this file, you can simply add the <code><nowiki>{{Rename|File:LMC SMC Bab al Mandab_2025.png|1|reason=your reason here}}</nowiki></code> template to the file description on the file page. Please don't forget to add your reason in the reason parameter. – ] <small>(])</small> 09:45, 20 January 2025 (UTC)
===Positive feedback here!===
::Thanks a lot for a quick and helpful advise! ] (]) 10:11, 20 January 2025 (UTC)
:::The file has been renamed by Ziv on Wikimedia Commons. <small><sub><span style="color:SteelBlue;">Regards, </span></sub></small>] ] 10:35, 20 January 2025 (UTC)
== ] table. ==
The change took me by suprise as well, but the community wanted this change. Instead of a mass-call for ''dis''abling it again, post some opinions on ''how'' you want changed pages to look on your watchlist. Perhaps a green star in front of the page name? <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 18:58, 10 May 2012 (UTC)
::: Sorry just butting in here but what community? the overwhelming reaction is WTF, OMG, this is spawnbreath etc., i.e. people seem fairly upset and hostile to this ''community'' decision. <b>] <sup>]</sup></b> 19:32, 10 May 2012 (UTC)
::::], the English Misplaced Pages community. --] (]) <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added 20:27, 10 May 2012 (UTC).</span><!--Template:Undated-->
:I don't want changed pages to look like anything. The fact that they appear on the watchlist is signal enough that a change has occurred. No? I use ] to view diffs and rarely click through to the entire page. This change is annoying. --] ] 19:03, 10 May 2012 (UTC)
When the links in the table showing the stubs, A class B class etc. are clicked on, it just goes to a blank-ish page. I suspect that there is something to do with the slash it the name, but I hope someone knows a solution. <span style="font-family:monospace;background:#368;padding:.2rem;color:white">'']''('']'')</span> 18:50, 20 January 2025 (UTC)
:Honestly, I would rather there was no additional change. I can tell when a page I'm interested in has been changed simply by checking who the last contributor was; or simply by seeing that the "diff" link has already been viewed based on its colour. I understand that this change can be useful for some editors but by surprising everyone with it without notice it's basically forced a lot of us to put up with a nuisance while a fix is found for those who dislike it; an opt-''in'', rather than opt-''out'' change would have been much more welcome from all parties as those who benefit would be able to use it and those who don't wouldn't have to take extra measures to avoid it. ] ] 19:03, 10 May 2012 (UTC)
:I'm not sure anything go be done on our end. ] might be worth a shot.<span id="Qwerfjkl:1737399951187:WikipediaFTTCLNVillage_pump_(technical)" class="FTTCmt"> — ]] 19:05, 20 January 2025 (UTC)</span>
*I highly disagree. There are people who want it and people who don't, and I personally think it is only effective on small wikis, not the largest one in the world (this one). I ''know'' what's new and what's old, I don't need a second annoying reminder! That proposal actually needed an RfC.--] ] 19:06, 10 May 2012 (UTC)
== Tech News: 2025-04 ==
:Are you for real! Have you even '''read''' any of the above posts?
:Here's my positive feedback:
:"but the community wanted this change"{{cn}}
:"post some opinions on ''how'' you want changed pages to look on your watchlist" The short answer is that everyone who complained above want their watchlists to look the way they used to look just a few hours ago! We don't need no steenkin' bolding or green stars or other shit! ] (]) 19:09, 10 May 2012 (UTC)
:{{ec}}{{ec}}'''The watchlist was fine as it was; any change is just a massive eyesore. I keep a lot of pages watchlisted just to keep an eye on them if anything out of the ordinary happens, and I don't need some ugly function to let me know when some bot adds an interwiki or some random person fixes a typo. The pages that I'm involved actively in I already know when someone does something. ~~ ] (]) 19:10, 10 May 2012 (UTC)'''
::'''How I want to change it''': Okay, 1) Add an option '''Show/Sort unread''' the way we have options like ''Hide minor edits | Hide bots | Hide anonymous users | Hide logged-in users | Show my edits | Hide patrolled edits'' in watchlist. or 2) Add a "U" to show unread the way bot edits are shown by "b" and minor edits by "m" --<small style="border: 2px dotted;padding:1px 4px 1px 3px;white-space:nowrap">''']''' ''']'''</small> 19:23, 10 May 2012 (UTC)
::remove bolding. The fact that a page is on my watchlist is enough. It's already a burden to deal with my watchlist, even without the bolding. Motivates me to cut my watchlist down. ] (]) 19:22, 10 May 2012 (UTC)
Latest ''']''' from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. ] are available.
'''Updates for editors'''
: '''Agree''' with all the above ''repliers'' after skimming the replies, I know where I've been (different shaded links), I know where I want to go (where I want, thanks) and I hate "you're absolutely gonna love this" changes without being informed in advance. <b>] <sup>]</sup></b> 19:28, 10 May 2012 (UTC)
* Administrators can mass-delete multiple pages created by a user or IP address using ]. It previously only allowed deletion of pages created in the last 30 days. It can now delete pages from the last 90 days, provided it is targeting a specific user or IP address.
* On ] the ] feature, when the rollback feature is used to revert an unpatrolled page revision, that revision will now be marked as "manually patrolled" instead of "autopatrolled", which is more accurate. Some editors that use ] on Recent Changes may need to update their filter settings.
* ] View all {{formatnum:31}} community-submitted {{PLURAL:31|task|tasks}} that were ]. For example, the Visual Editor's "Insert link" feature did not always suggest existing pages properly when an editor started typing, which has now been ].
'''Updates for technical contributors'''
* '''Yay!''' As one of the people who favored this in the recent discussions (I know, I know: someone's about to screech ]), I am totally thrilled that it appeared on my watchlist today. Perhaps I won't actually have to ] after all. Did someone post a way to set the highlighting color for the "updated since my last visit" text yet? If not, please do! ] (]) 20:06, 10 May 2012 (UTC)
* The Structured Discussion extension (also known as Flow) is being progressively removed from the wikis. This extension is unmaintained and causes issues. It will be replaced by ], which is used on any regular talk page. ] ({{int:project-localized-name-cawikiquote/en}}{{int:comma-separator/en}}{{int:project-localized-name-fiwikimedia/en}}{{int:comma-separator/en}}{{int:project-localized-name-gomwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-kabwiki/en}}{{int:comma-separator/en}}{{int:project-localized-name-ptwikibooks/en}}{{int:comma-separator/en}}{{int:project-localized-name-sewikimedia/en}}) will soon be contacted. If you have questions about this process, please ping ] at your wiki.
::So where <s>the fuck</s> are the "recent discussions" and the community wide notification that such dicussions were happening? These type of discussions should not be allowed to take place in some deliberately obscure hidden corner of the site. Our overlords love inflicting fugly banners on us when they want money but they can't be botherred to place similar banners notifying '''everybody''' of such far-reaching proposals. I'm sorry but such underhanded bad faith actions by the technical cabal are totally unacceptable. ] (]) 20:17, 10 May 2012 (UTC)
* The latest quarterly ] is now available. This edition includes: updates about services from the Data Platform Engineering teams, information about Codex from the Design System team, and more.
:::It's called ], and if you don't pay attention to it, you're going to miss some things. It was also listed in the Centralized Discussion list. That is not "deliberately obscure", that's as publicized as it gets around here, short of watchlist notices and horrid sitewide banners. --] (]) 20:34, 10 May 2012 (UTC)
:::Agree with statement directly above. Kill it. Good intentions but turned out to be a bad idea. ] (]) 23:24, 10 May 2012 (UTC)
::::"Horrid sitewide banners" is exactly what we do want for proposals with such drastic consequences that affect all users. ] (]) 20:50, 10 May 2012 (UTC)
:::::Drastic consequences? Really? Changing the formatting of one element in a list is "drastic consequences" in your books? ] (]) 23:37, 10 May 2012 (UTC)
''''']''' prepared by ] and posted by ] • ] • ] • ] • ] • ].''
* All I can say is, good change, but it took me coming here to figure out what the bold meant. Please don't disable it, but if you could make a "disable" button in preferences I'm sure ^some people^ would appreciate it.-<b>]<sup>(])</sup></b> 20:11, 10 May 2012 (UTC)
</div><section end="technews-2025-W04"/>
<bdi lang="en" dir="ltr">]</bdi> 01:34, 21 January 2025 (UTC)
*'''Don't change a bloody thing''' - This change '''was supported by the community 6 months ago''', and it has simply taken that long to actually implement it. Provide an opt-out option for those who don't like it, but keep recent changes on as default. Within a few days, people will forget. Ugly? How? Not useful? Are you kidding me?! Consensus was for this, those who didn't participate probably don't participate in VP discussions until after a change takes place that they dislike. - ''']''' <sup>]</sup> <sub>]</sub> 20:24, 10 May 2012 (UTC)
<!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/search/?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=28129769 -->
*:Likely because the first time many of us knew about such a discussion was six months after it was over. We can get incessant watchlist notices about the Muhammad RFC but none about a change which affects ''every'' editor? If these discussions were as widely advertised as narrow RFCs are there'd be a much higher turnout, and complaints like these would be tempered by the fact that there'd have been six months to devise a shut-off fix. ] ] 20:28, 10 May 2012 (UTC)
*::Or if people added the four village pump pages and ] to their watchlist, and actually kept abreast of what's going on, it wouldn't need to be. Why don't we just get rid of all these boards, the RfC process, and centralized discussion, and just place a list of upcoming changes into a banner that appears at the top of every page. I'm certain that this would not receive any complaints, and that nobody would minimize the banner until after reading it daily. - ''']''' <sup>]</sup> <sub>]</sub> 13:54, 13 May 2012 (UTC)
:What does it take to get somebody/anybody to just post a link to the alleged consensus discussion! ] (]) 20:33, 10 May 2012 (UTC)
::It was posted above: ]. ] (]) 20:37, 10 May 2012 (UTC)
== Data not shown in the infobox ==
*To answer the question at the top of the thread - I think that by default having a page show up on a watchlist indicates that it's been changed. Not sure why we need to have the bolding, but I will say this: for someone who doesn't have great eyesight, the bolded pages (ones I rarely check) are making the unbolded ones (ones I frequently check) nearly invisible. So it's very difficult to see much, except a sea of bolded purple. Having Helpful Pixie bot on a rampage at the moment isn't much help b/c my entire watchlist has been hit in the past few days which is unusual. Anyway, not a fan of this at all, but can't think of how watched changes should look - other than having them show on the watchlist? ] (]) 20:44, 10 May 2012 (UTC)
*:This doesn't show that it's been changed since you last ''edited'' the page. It shows that it's been changed since you last ''read'' the page. If it's not in bold, then there is no need for you to check the page at all, because it has not been changed since the last time you checked it. ] (]) 23:39, 10 May 2012 (UTC)
*Give it a day or so, and you'll adjust. This is exactly how my e-mail clients (yes, plural), newsreaders, etc. work. Items that have changed since you last visited them are in bold. I support this, but oppose the fidgeting with the CSS to add/change the display. Leave it be, and at worst, add a button next to the "Mark all pages visited" button to shut it off for people. <span style="background:#006B54; padding:2px;" >'''] ]'''</span> 21:03, 11 May 2012 (UTC)
In ], the infobox for some reason doesn't contain ] that is shown in the read mode. I thought it's in the wikidata, but says the "end time" for that coa is 1925 and that since 2012 ] is used, yet the infobox displays the outdated coa. What's going on? ]<sup>]</sup> 09:37, 21 January 2025 (UTC)
*Is this where I voice my '''support''' for these changes? We already have bold titles in ] for articles on your watchlist. Seems like there's precedence for bold titles in watch lists. Maybe it's unclear why they're bold but it's not ugly and certainly not hideous. Please do not take away the functionality for aesthetic reasons. If you pull your head out of your everyday experience, you'll see that the watchlist is already plenty ugly. I am often away from Misplaced Pages for days and before this feature I've had to manually track what I had and had not reviewed. I would prefer that bolding was used in both the watchlist and in article histories to indicate unreviewed changes. Failing that, please put some sort of unreviewed indicator near the links on the left hand side of the entries. I want the indicators to be near the links I click in response to seeing them --] (]) 13:35, 13 May 2012 (UTC)
:I fixed it by the old file, not sure if that is the normal way to fix this, but it works. ] (]) 12:23, 21 January 2025 (UTC)
== Contributions by CIDR range plus date range ==
===How to forcefully revert this change===
I'm tracking a LTA account who frequently IP hops within the same session eg. they might switch IP 6 or 7 times within 30 minutes. However they appear to be limited to certain A or B classes which in theory makes tracking possible. But in practice anything bigger than a C is hard. For example class C ] is doable but class B ] is not, and certainly not class A 5.* .. (I have "JavaScript-enhanced contributions lookup 0.2 enabled", your results may look different from mine.)
Is there a script or simalar kludge method to "sabotage" this change? I want it gone, dead, destroyed, terminated, extinguished, whacked, sleeping with the fishes asap! Oh and btw does anyone know where to send the hate mail? ] (]) 19:19, 10 May 2012 (UTC)
:There's a change listed above that can remove the bolding by adding a line to your custom CSS page; but it still leaves the "mark all pages visited" button sitting there. ] ] 19:20, 10 May 2012 (UTC)
Question: is there a tool to filter Class A or Class B based on ''time frame'' eg. show all edits within this Class A between 10:40 and 12:40 on Jan 20 on Enwiki. -- ]] 15:03, 21 January 2025 (UTC)
::Found it, thanks, but you're going to have to talk slowly in words of no more than two syllables: Where is my "custom CSS page" and how do I add the script to it? (I need "paint by numbers" instructions) ] (]) 19:26, 10 May 2012 (UTC)
:I've long thought that the CIDR gadget is pretty much deprecated since the functionality was built in to the contributions page (there are probably still a couple of niche uses, but not many). The contributions page allows you to filter by range and date... For this /16 range the link looks like (there are no contributions on the 20th and it won't filter by exact time). Won't that suffice? -- ] <sup>]</sup> 15:14, 21 January 2025 (UTC)
::Excellent, thanks! Now wondering why is not working: or return valid JSON but empty. -- ]] 16:42, 21 January 2025 (UTC)
:::I haven't checked the API doc but it's probably a "direction" issue. is the same as your's except that it reverses the two dates. ] (]) 22:20, 21 January 2025 (UTC)
::::Thanks John. Start is end. End is start. The docs mention this but somewhat confusingly. The default is {{para|ucdir|older}}, which requires ucstart to be higher than ucend. The original will work with {{para|ucdir|newer}} enabled: .. probably {{para|ucdir|newer}} should be the default because counting backwards is.. backwards. -- ]] 01:22, 22 January 2025 (UTC)
== Some table classes yet to be adapted for Dark Mode ==
:::Click "my preferences", and then click the "appearance" tab. There should be a line which reads "Shared CSS/JavaScript for all skins: Custom CSS | Custom JavaScript". The "Custom CSS" part should be a red link; click it to be brought to an edit screen for your personal CSS settings. It'll be blank as I'm assuming you've never created one. Paste the above code into it and save it; that'll create the page and apply that code regardless of which skin you're using. Check your watchlist afterwards to be sure it's worked. ] ] 19:31, 10 May 2012 (UTC)
::: Your custom css page is ]. --] (]) 19:34, 10 May 2012 (UTC)
::::Probably worth pointing out that the above link works for everyone. It should look something like ] when you're done. ] (]) 19:37, 10 May 2012 (UTC)
:::::It works! Yay! Now all that remains is the little matter of sending some hate mail... <evil smirk> ] (]) 19:38, 10 May 2012 (UTC)
::::::Seriously, do the software coders cabal have a talk page where we can directly communicate our unhappiness about this? ] (]) 19:47, 10 May 2012 (UTC)
:::::::Oh, that's going to be a big help. The devs respond to a consensus-backed community request, and since there weren't enough people who were aware of the community discussion, they get lots of non-consensus-backed complaints and undo-requests on something that the community could deal with themselves if necessary. Sheesh. Make a simple proposal to undo the change on VPR, and if the community supports it, an admin can add the CSS to common.css. --] (]) 20:15, 10 May 2012 (UTC)
::::::Thanks worked, if there was anything positive in the change I couldn't see it because blinded by a hundred bold lines. --] (]) 19:51, 10 May 2012 (UTC)
{{od}} forceful change didn't work for me. Can't figure out why. ] (]) 20:50, 10 May 2012 (UTC)
::The line at the top of your CSS (// remove bolding of watchlist) is breaking it. CSS comments don't work like that. --] (]) 21:27, 10 May 2012 (UTC)
:::Thanks! ] (]) 21:36, 10 May 2012 (UTC)
::::Nasty, brutish and short, thanks to that code. Please accept that this is the best idea since New Coke.--] (]) 22:44, 10 May 2012 (UTC)
:::::I wouldn't compare bolding watchlist items to New Coke... The forced switch to the Vector skin, on the other hand... - ''']''' <sup>]</sup> <sub>]</sub> 13:57, 13 May 2012 (UTC)
An example can be found at ], where each cell features a white background with invisible transliteration:
===Related changes===
At the same time that the watchlist change went into effect, there was also a change to the history tab on articles. To see it, from your watchlist, click the "Hist" link for any article you haven't yet viewed. Next to every new edit is text with a bright-green background that states "updated since my last visit". Does anyone know the css change that can, at the very least, kill the background coloring? --- ] <small>(] • ])</small> - 19:40, 10 May 2012 (UTC)
{| class="wikitable"
:I see it in ordinary text, no green, so the above script must have killed it too. ] (]) 19:45, 10 May 2012 (UTC)
|+ Some Javanese letters and their Balinese equivalents
::I still see it, and I'm using the above script. I'm using the Monobook skin though, so maybe that change was kept out of Vector? I'll need to test. --- ] <small>(] • ])</small> - 19:48, 10 May 2012 (UTC)
|- class="letters-violet letters-lo"
:::Confirmed ... this lovely "enhancement" was reserved as a special treat just for us hold-outs that are still using the MonoBook skin ... the Vector skin was mercifully spared this eye-sore.
|{{letter|l=jv|s=Java|ch=ꦲ|top=ha}}
:::For those of us on MonoBook yet, anyone know how to kill this one? --- ] <small>(] • ])</small> - 19:52, 10 May 2012 (UTC)
|{{letter|l=jv|s=Java|ch=ꦤ|top=na}}
|{{letter|l=jv|s=Java|ch=ꦕ|top=ca}}
::::It's from http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/main.css?view=markup which says:
|{{letter|l=jv|s=Java|ch=ꦫ|top=ra}}
span.updatedmarker {
|{{letter|l=jv|s=Java|ch=ꦏ|top=ka}}
color: black;
|{{letter|l=jv|s=Java|ch=ꦄ|top=a}}
background-color: #0f0;
|{{letter|l=jv|s=Java|ch=ꦄ|top=ā}}
}
|{{letter|l=jv|s=Java|ch=ꦆ|top=i}}
::::] (]) 20:02, 10 May 2012 (UTC)
|{{letter|l=jv|s=Java|ch=ꦇ|top=ī}}
::::I don't know much CSS but this in ] changes the background from green to white for me:
:::::And that seems to fix it for me (I tried using white at first, but the normal background appears to be off-white, so was still noticeable). --- ] <small>(] • ])</small> - 20:16, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬓ}}
::::::If you want to get rid of it entirely, you can use <tt>span.updatedmarker{display:none;}</tt>. --] (]) 20:21, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬅ}}
:::::::I had just found that css formatting via a Google search - I should've just waited for the post here. :-) --- ] <small>(] • ])</small> - 20:26, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬆ}}
|{{letter|l=ban|s=Bali|ch=ᬇ}}
:::::::::Thanks for this code - to which page should it be added? ] (]) 20:29, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬈ}}
::::::::::Add it to ] as said above. ] (]) 20:31, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬉ}}
:::::::::::That's only for users of the monobook skin. For everyone else, use ]. --] (]) 20:51, 10 May 2012 (UTC)
|{{letter|l=ban|s=Bali|ch=ᬊ}}
:::::::I realize this is probably the wrong place to ask for css tips ... but, instead of hiding entirely, is there a way to replace the text "updated since my last visit" with something more compact, like a single bold asterisk or other symbol/character? I can see a potential use for this one ... but the initial implementation was just too distracting to be effective. --- ] <small>(] • ])</small> - 20:44, 10 May 2012 (UTC)
::::::::How about this: <tt>.updatedmarker{overflow:hidden;display:inline-block;height:1em;width:10px;}span.updatedmarker::before{content:'*';font-weight:bold;font-size:20px;width:10px;display:inline-block;}</tt> It's a bit hack-y, but it'll work, I think. --] (]) 21:04, 10 May 2012 (UTC)
{{outdent}}It made its way to default now too...except in green text instead of a green background. I don't need help figuring out what has changed since I last viewed a page. Please tell me there are options to shut off these page cluttering stars and annoying notes. --]]] 21:06, 10 May 2012 (UTC)
:It's no longer green, which I actually find more annoying because I now keep thinking it was an intentional part of the edit summary left by the person making the edit. Is there a css fix to getting rid of the 'updated since my last visit' annoyance? --]]] 14:54, 11 May 2012 (UTC)
===Seeing stars===
:Both the "bold hears the go-away bird" and "green box-b-gone" scripts are brilliant, and thank you very much. :) But...is there a script for banishing those horrid green stars from the watchlist? - ] <sub><font color="maroon">]</font></sub> 21:11, 10 May 2012 (UTC)
::The stars were added by Edokter twenty minutes ago: {{diff|488663421|491871039}}. CSS to get rid of the stars: <tt>strong.mw-watched a{background:none;padding-left:0;}</tt>. Anyone want to make that into a gadget? --] (]) 21:13, 10 May 2012 (UTC)
:::On the subject, is it possible to hide that "mark all pages visited" button too? If I can just hide the changes and resume the functionality of the previous version I'll be happy to go on my merry way, but only hiding half of the changes isn't really doing it for me. ] ] 21:15, 10 May 2012 (UTC)
::::<tt>#mw-watchlist-resetbutton{display:none}</tt> should do it. --] (]) 21:19, 10 May 2012 (UTC)
:::Thank you so much for the css workaround. It was incredibly annoying to find a workaround for the bold ugliness suddenly worthless due to a starry ugliness. --]]] 21:17, 10 May 2012 (UTC)
:::::Thanks, Yair! That's me satisfied for now, anyway. Back to content creation again. ] ] 21:25, 10 May 2012 (UTC)
And now the bold is back. Make up your fucking minds so I know which bullshit workaround I need to use. The one that stops the bold watchlist screws with how watchlisted articles appears in the recent changes list. --]]] 22:20, 10 May 2012 (UTC)
===Green star invasion===
Now the watchlist has been invaded by fugly green stars! We need a starblaster script. ] (]) 21:08, 10 May 2012 (UTC)
:Looking for smaller stars... It's a concept. Stop stifling innovation! <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 21:10, 10 May 2012 (UTC)
:::Misplaced Pages is not a sandbox. If they really had to do this for that purpose, they should've done this on a test wiki and recruited people from this wiki.--] ] 21:30, 10 May 2012 (UTC)
::No, do not like green star. Distracting! --<small style="border: 2px dotted;padding:1px 4px 1px 3px;white-space:nowrap">''']''' ''']'''</small> 21:12, 10 May 2012 (UTC)
:::The stars are kinda cute. But all I see is people asking for an off-button. I guess the devs just thought, "Hey, everyone likes stars right? Just bombard them with stars until they shut up." STARS. (on an off note, I will support the stars if I can make them different colours. Rainbow stars). ] <small><span style="color:#191970">]</span></small> 21:14, 10 May 2012 (UTC)
They suddenly appeared on my watchlist and my first thought was: WTF (or should I say WMF)? Where has this been announced? -- ] (]−]) 21:13, 10 May 2012 (UTC)
::I agree. I was able to get rid of the watchlist bolding with the CSS code, but now there are green stars by the article title names and still the "updated since my last visit" text by revisions on the history page. I'm hoping there will soon be a way to kill these additions as well. After working on Misplaced Pages for more than two and a half years, I've gotten used to a certain setup, and I wish to continue editing the way I am used to. I'd really prefer a gadget over more code I am not generally familiar with. —] (]) 21:15, 10 May 2012 (UTC)
::You don't have my permission to inflict your "innovation" on my watchlist. ] (]) 21:16, 10 May 2012 (UTC)
::: UAT - the secret to great implementation. One day, I'll teach the developers what it means lol. The bolding of unread changes was a bit eyewatering, but fitted with custom and practice elsewhere - email clients generally do it, forums generally do it. But hey guys, green stars DO NOT WANT.--] (]) 21:19, 10 May 2012 (UTC)
;Funky stuff-Watchlist stars-posting on a user talk page
*I now have cute little stars on my watchlist. Kind of like them.
*When I try to post on a user page - and it's only one user - I get that full-screen Wikimedia error message about the servers being busy. I can post on any other talk page I've tried as a test. But not this one. ] (]) 21:10, 10 May 2012 (UTC)
;Green star
I like the changes. Well, I don't entirely understand them. I instantly liked the use of bold letters to indicate unread changes, as soon as it happened, because I'm accustomed to it from Commons. Suddenly I'm getting a green star instead of bold; my guess is it does the same thing. My preference would be for slower changes, but anyway I won't go along with my fellow old fogies who instantly hate anything they don't instantly understand. I'm confident it will take only a little study to turn these novelties into tools to increase my pleasure and efficiency. ] (]) 21:13, 10 May 2012 (UTC)
:The green star seems reasonable to me, far better than the emboldening, but it needs to be smaller. ] ] 21:15, 10 May 2012 (UTC)
::Yes, smaller, and maybe a slightly less obtrusive color. --''']]]''' 21:18, 10 May 2012 (UTC)
:::The green stars are a much better idea than the bolding, I'll admit. But there does need to be a "canonical" on/off switch for us old farts who like our MonoBook and our watchlist The Way They Were, ]. ;) - ] <sub><font color="maroon">]</font></sub> 21:20, 10 May 2012 (UTC)
:The green starts are better than the bold. But that's not the point - just gives us an option to turn them off. Better - let us choose between bold, stars, off, and whatever else people come up with. That way everyone's happy. ] <sup>(] • ])</sup> 21:21, 10 May 2012 (UTC)
:::Smaller star found. There's not going to be an option. If every change needs an option to turn it off, there's going to be a gazillion options, which will totally overwhelm new users. <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 21:22, 10 May 2012 (UTC)
::::Then make an advanced tab for those that want it. Who are you to say that "There's not going to be an option?" --]]] 21:24, 10 May 2012 (UTC)
:::: {{ec}} There are already a gazillion options and I'm still overwhelmed by them after 6 years. A gazillion and one doesn't bother me. In fact I'm comforted to know that when I want to find an option, it's probably there, since there are so many. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 21:25, 10 May 2012 (UTC)</font>
*Green makes me think "These are the ones you've already checked". Star makes me think "These are of particular interest". They should be black bullet points instead. Or just give us a bunch of options. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 21:21, 10 May 2012 (UTC)</font>
::It's all reasonable, as an option or if implemented with the option to not have it forced on you. I'm comfortable changing my css pages...even if I haven't done it much and screwed up with my first attempt today...but many people aren't. Have a damn checkbox in preferences ready if you (not you, Malleus) decide to change what options I have. --]]] 21:23, 10 May 2012 (UTC)
How to banish the Green Star Invasion: Step 1 navigate to your CSS stylesheet for the theme you're using. Step 2, Add <nowiki>strong.mw-watched a { background: none; padding-left:0px;}</nowiki> to the list of CSS rules. Step 3, send ] some hummus, for I am hungry. ] (]) 21:25, 10 May 2012 (UTC)
:*I want to somehow change the colour. Is that possible? ] <small><span style="color:#191970">]</span></small> 21:27, 10 May 2012 (UTC)
::*I assume that it would be something like adding this to your CSS: --''']]]''' 21:31, 10 May 2012 (UTC)
:::Adding <tt>strong.mw-watched a {background: url(//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Asterisk.png/13px-Asterisk.png) no-repeat left;}</tt> to your CSS will change it to use the image ]. Just replace Asterisk.png with any other file name to use a different image. You can find tons of star images on Commons. --] (]) 21:38, 10 May 2012 (UTC)
::::Thanks! I'm very grateful. ] <small><span style="color:#191970">]</span></small> 21:40, 10 May 2012 (UTC)
:I want the choice to not have stars! These changes may be useful for some people - those with only a handful of watched pages who habitually look at every change as it comes up on their watchlists. But for many of us that watch thoudsands of pages and only examine a few of every day's listings it is a major eyesore. ] (]) 21:25, 10 May 2012 (UTC)
*To get rid of stars please.]·] 21:35, 10 May 2012 (UTC)
*I am a little amused that we react to a change described as undiscussed and obtrusive by... rushing into a different change which is similarly intrusive, four hours after the first complaint. That said, I don't really mind either version (and the mark-as-viewed functionality is potentially useful), but... if we're keeping the green stars, could we ''align'' them? At the moment they're on the right of the "m" and "b" watchlist notes for minor and bot edits, so what would be a clear vertical line showing viewed or not becomes a ragged line that's much harder to skim down. ] (]) 21:36, 10 May 2012 (UTC)
Other way around. It's precisely us obsessive-compulsive noodges with 5,534 watched pages who can benefit by this feature to tell us which of the two hundred on the screen we have already examined. It's a big help for me in Commons (where it's done by bold; no big difference to me) and I have long hoped en would catch up. ] (]) 21:40, 10 May 2012 (UTC)
:Jim - if you used ] to look at your diffs, you'd be able to whizz through them much quicker, and you'd see why any form of flagging changes like this is so annoying, because the flag doesn't go away when you've looked at the change. —]] 22:01, 10 May 2012 (UTC)
*(ec) Please get rid of the green stars. I have 900 pages on my watchlist. Too many green stars, and what are they supposed to do anyway? ] (]) 21:42, 10 May 2012 (UTC)
*:The stars indicate that you haven't viewed the page since the last edit to it was made. --] (]) 21:44, 10 May 2012 (UTC)
*::But this page has a green star after it on my watchlist and this is my third or fourth edit to it in the last hour. ] (]) 21:50, 10 May 2012 (UTC)
*As I'm getting used to seeing it, I kind of like being able to see at a glance which pages on my watchlist have changed since I last visited them, and which haven't changed. But I also am sympathetic to the negative opinions about how intrusive the display is. How about making the stars blue, like the rest of the font characters? --] (]) 22:10, 10 May 2012 (UTC)
*:But you can see that anyway by the bytes added or subtracted. I'm going to take this page off my watchlist to get rid of some of the stars. ] (]) 22:20, 10 May 2012 (UTC)
*::No, you can't. {{red|(-24)}} does not tell me "you've already looked at that change". The bold/green stars/whatever tells me which pages I've '''read''' in their current state. ] (]) 23:48, 10 May 2012 (UTC)
*:::Actually the fact that the hyperlink has changed from blue to purple is an indication that I've already looked at it. This has been a standard feature of practically all web browsers since the original ] first appeared. 00:01, 11 May 2012 (UTC) <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) </span></small><!-- Template:Unsigned -->
*::::Yes, that tells me whether I've looked at the page (in my case) sometime during the last 30 days. That's not helpful if I want to know whether a busy page, like this one, has changed since the last time I looked at it, which was probably only a couple of hours ago. ] (]) 02:19, 14 May 2012 (UTC)
If only I could touch the green star and ''see what it means''. -] (]) 22:31, 10 May 2012 (UTC)
===A sorting option please===
I change my opinion. Green stars are much better! Also I suggest to add an option '''Show/Sort unread''' the way we have options like ''Hide minor edits | Hide bots | Hide anonymous users | Hide logged-in users | Show my edits | Hide patrolled edits'' in watchlist.--<small style="border: 2px dotted;padding:1px 4px 1px 3px;white-space:nowrap">''']''' ''']'''</small> 21:29, 10 May 2012 (UTC)
:Yes, the third change in an hour is better. But I'd get shot if I started testing in a live environment, which is plainly what someone is doing here. --] (]) 21:34, 10 May 2012 (UTC)
===RFC===
{{rfc|tech|rfcid=9CFDE38}}
To actually get the ''whole'' community's opinions, I'm starting an RFC on this:
Please describe your view of this new change. Indicate whether you:
#Absolutely hate this change and want it abolished.
#Want the change to be revised (explain exactly how)
#Want an opt-out other than a gadget
#Want it to be opt-in
#Do not care about the change
#Support the change
When closing this RFC, please consider the discussion above.--] ] 21:40, 10 May 2012 (UTC)
*'''Opt-in''': Unless it's something that is required to be in place technical wise, it's always better to give users an option to opt-in. Announce/incentiveize/convince all you like, but it's the '''User''' interface you're putzing with here. ] (]) 21:47, 10 May 2012 (UTC)
*'''Opt-in''': as per Hasteur. ] (]) 21:53, 10 May 2012 (UTC)
*'''Opt-in''': In fact I think it should policy that ''all'' user interface changes should be strictly on an opt-in basis only. ] (]) 21:52, 10 May 2012 (UTC)
*'''Opt-in''': Want to opt in! Want a newsletter like signpost which will inform about the new features like this and allow us to opt in --<small style="border: 2px dotted;padding:1px 4px 1px 3px;white-space:nowrap">''']''' ''']'''</small> 22:05, 10 May 2012 (UTC)
*'''Opt-in''': ] (]) 22:11, 10 May 2012 (UTC)
*'''Opt-in''' personally I find it very annoying and virtually useless, it's obvious lots of people feel the same way, and the previous discussion didn't get enough participation for such a change. '''''<font color="#FF0000">]</font>''''' 22:14, 10 May 2012 (UTC)
*'''Opt-in'''. A real good way to avoid getting the kinds of complaints showing up here, just common sense. Ironically, people will tend to like something more when they have chosen to opt into it. This should always be the process. But I kind of like the feature, just wish that it were less visually intrusive. I suggested above that the stars be made blue instead of green. --] (]) 22:15, 10 May 2012 (UTC)
*'''Opt-in''' (What the fuck is going on? I lost my edit because of the edit conflict, and now I see hidious green on the history page. Is someone high? Because obviously someone is trying to sabatoge WP to make things more difficuly and ugly all around) ] (]) 22:18, 10 May 2012 (UTC)
*'''Opt-in''': As per Roger. Maybe it should even be policy that user interface changes should be gradually deployed, starting with opt-in, and switching to opt-out or default as per community consensus based on live experience. ] (]) 22:21, 10 May 2012 (UTC)
*'''Change''' The functional specification for the current changes appears to be "display all unread items in the watchlist differently". This may be useful for some users, but is no help at all for someone who uses popups to decide whether each changed item needs to be inspected in greater detail or knows that it is not necessary to open every single one of the helpful pixie's ISBN updates. I suggest the following function: "Remember the latest time the watchlist was refreshed and display the first subsequent entry (only) differently next time". This would make it rather easier than at present to see which items have not previously been displayed. It would also be only a single per-user datum to manage. --] (]) 22:26, 10 May 2012 (UTC)
*'''Leave as is''', but give instructions for opting out in ]. I don't particularly like it here, due to the nature of my watchlist, so I've opted out. On the other hand, it's been on Commons for some time, where I find it more useful (as the stuff I watch tends to only change occasionally). Giving people something new to try, then allowing them to opt out if it doesn't suit them, is better than hiding a new option where people won't be aware of it. <small style="white-space:nowrap;border:1px solid #000000;padding:1px;"> An ] on the ] </small> 22:46, 10 May 2012 (UTC)
*'''Opt-in'''. Second choice involves deletion and salting.--] (]) 22:53, 10 May 2012 (UTC)
*'''Opt-in. I like Wehwalt's second choice too. ~~ ] (]) 22:58, 10 May 2012 (UTC)'''
*{{comment}}: all "opt-in" comments above don't make any sense as there's no way for this feature to be opt-in. Also, this is a very standard feature of MediaWiki, so it would be nice for it to be available in standard ways and not with obscure, user-unfriendly and unusable hacks. ] 23:04, 10 May 2012 (UTC)
**Opt in, in this case, is referring to the fact that this feature should be disabled and presented as an one time offer to the user as part of the configuration or as part of options a user may change at any time (on or off). ] (]) 23:45, 10 May 2012 (UTC)
**:Exactly: that is, something not possible. --] 23:58, 10 May 2012 (UTC)
**::Rubbish! Of course it is possible - the code just has to be rewritten to impliment it that way. ] (]) 00:09, 11 May 2012 (UTC)
*'''Support''' I have been looking for something like this after years of manually inserting bookmarks into my watchlist. Although there could still be discussion on improving the look and an opt-out for those that don't want it. Opt-in is bad - new users typically don't start off by scrabbling through the settings finding useful things to turn on. ''']]''' 00:14, 11 May 2012 (UTC)
*'''Opt-in''' please. This truly is migraine inducing - a page splashed with bolded bright purple is difficult to bear. If it stays like this I'll probably delete my entire watchlist and work without one. ] (]) 00:21, 11 May 2012 (UTC)
*'''Opt-out''' – ] – This is the default, and it has been the default . Encyclopedia Dramatica, Commons, dewiki, Meta, and others have this setting set to "true". It makes it much easier to tell the difference between pages one has visited and pages that've changed since one has last visited it. I find it useful outside of enwiki, and I hope to make use of it on enwiki. that Wikipedians resent technical changes, even when those changes are progressive. An opt-out option should be available to those don't wish to open their minds to change. --] (]) 00:46, 11 May 2012 (UTC)
*'''Opt-in''' and can we please stop having these dumped on us without any warning. We put banners on the at the top of our screens for all manner of things including requests for moeny. We should certainly be able to use them to advise us of changes like this. ] | ] 01:01, 11 May 2012 (UTC)
*Revert to and NEVER renable bolding. '''Having your watchlist in bold in VERY distracting and does NOT make a good style for the encyclopedia. ] / ] / ] 01:21, 11 May 2012 (UTC)'''
*'''Opt-in''' This is simply an eyesore to use, since my watchlist has a lot of heavily-edited Misplaced Pages pages (noticeboards, reference desks etc.) What makes it worse is that I was completely unaware of this change until just now, even if there were discussions last December! At lease a message on my watchlist saying "Effective (date), (feature) will be enabled." For now at least, change the code so that it will be opt in! ] <sup>]]]]</sup> 01:31, 11 May 2012 (UTC)
*'''Abort (option 1)''' I really don't see the point of the ''massive'' use of bolding in the watchlist. I know the devs will scream because apparently the community asked for this feature, and now we're all up in arms. Well, actually, reading the previous discussion that had maybe a dozen participants, that was a rather fanciful wish-list feature with little thought of just ''how'' it would be in real life. There ought to have been a further discussion as to its scoping and roll-out. I intensely dislike the 'new' watchlist. I find the bolding is rather obtrusive. Most people who use the watchlist will tell you that ften, it's not the article itself which is the most important link appearing. Frequently, it's the editor, or the diff itself. The highlighting of the titles gives totally the wrong emphasis. I would qualify my vote by saying that I could be persuaded to support it as an opt-in feature (option 4), and definitely '''not''' as an opt-out. <s>There is no question to my mind that users who are not logged in ought to be exposed to this at all.</s> More useful features could be 'highlight IP edits' or 'show/hide edits by ]' --<small>] ]</small> 01:43, 11 May 2012 (UTC)
*:Well put. My lost comment touched on that too -- checking the watchlist isn't about what articles were changed, it's about what the changes were. I can't be the only one who checks my watchlist by clicking all the DIFFs. Highlight those (though perhaps less 'bold'ly) and we might be getting somewhere. ] (]) 04:14, 11 May 2012 (UTC)
* '''Support''': I like it, though I use pop-ups to review the watch-list and seldom actually visit the diffs themselves. The "mark all pages visited" button makes the bold go away and then I can tell where I left off. But the stars were much cuter than the bold. And I have a very small watch-list, less than 500 items, so what works for me likely will not work for everyone. -- ] (]) 03:44, 11 May 2012 (UTC)
* '''Opt-in''' Seriously, stop forcing these things on us when they are only useful for a very small number of people. Make it opt-in so those people can use it and everyone else can ignore it like they want to. <font color="silver">]</font><font color="blue">]</font><sup>]</sup> 03:46, 11 May 2012 (UTC)
* '''Opt-in''' I ''LOVE'' that this feature has been added so I don't have to use ANOTHER script for this functionality (the script isn't all that user-friendly, either). However, because some people use their watchlist differently, make this an opt-in feature (not opt-out, opt-in ). --]] 03:56, 11 May 2012 (UTC)
* '''Opt-in''' although I am strongly inclined to choose option #1 with the way this was deployed. – ]4] 04:14, 11 May 2012 (UTC)
*If it's done in an unobtrusive way (see below) then I don't care. But at the moment, this is just another nasty surprise. '''Revise''' per Eloquence or '''kill'''. ] 04:18, 11 May 2012 (UTC)
* '''Opt-in''' because some editors like it. Second choice: Option 1. Introduces visual clutter that makes use of the watchlist harder. Some changes to a watched article (such as bots adding interwikis and hyphenating ISBNs) do not require a visit to the page and therefore the bolding remains. It also remains when people use pop-ups instead of loading the page. Therefore reduces functionality. Also the green "changed since last visit" in page histories does not go away unless one actually visits the page; viewing the history page should suffice to have it removed, since viewing teh history page itself constitutes a visit to the page for checking purposes. ] (]) 04:26, 11 May 2012 (UTC)
* '''Opt-in''' or abort entirely. ] (]) 04:41, 11 May 2012 (UTC)
*'''Opt In''' Whoever created this mess should be hauled up and forced to justify themselves. Some people don't understand programming language or code, so all these "fixes" are confusing and potentially dangerous. I don't want bolding, stars, green lines or anything else. I want things reverted back to normal. Without programming language, without code, without fiddling about under the bonnet. Change it all back, and do it immediately. ] (]) 04:42, 11 May 2012 (UTC)
*'''Opt-out or opt-in'''. It should be plain to see there there needs to be an option, though I don't particularly care which is the default. I think there should also be display options for when it's on, like the subtle dotted underline suggested by Elonka, instead of the bold. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 04:58, 11 May 2012 (UTC)</font>
*'''Support''' Commons has bolded text in the watchlist and can't see why it is a big deal, far better then the green stars. It allows me to look at the articles that are in my watchlist and look at the changes without having to guess if I've viewed it. ] (]) 05:06, 11 May 2012 (UTC)
*'''Support''' I have long wondered why en couldn't do something Commons has done for years. Yes, if the developers want to write and test some code making it optional, no problem but newbies ought to see it this way, so it should be opt-out for those of my fellow old farts who can't tolerate a change that won't be useful until they study it a little. ] (]) 05:33, 11 May 2012 (UTC)
**The nature of Commons and of Misplaced Pages pages are fundamentally different. Commons' simplicity, and the relatively lower number of users, is much better suited to this type of monitoring than the often complex WP articles, maintained by a much larger army of editors. To leave the feature in place unchanged, or to insist that it be an opt-in because "English Misplaced Pages ought to be the same as Commons" would be a failure to recognise these fundamental differences and thus the way editors work. --<small>] ]</small> 08:59, 11 May 2012 (UTC)
*'''Opt-in. Such dramatic changes should almost always be implemented on an opt-in basis whenever technically possible. That means that those who want the change can get it, and those who don't want it won't be offended by its suddenly being thrust upon them. In other words, everyone is happy. Instead, the default method seems usually to involve inflicting it on everyone across the board. Regarding this latest infliction (i.e., the bolding—I missed the stars and have no idea if I'd have liked them), it's typographically inept. By that, I mean that bold type of that size, set with that tight a leading, is ugly and hard to read; one's eyes tire quickly of it.''' (The preceding lines I am deliberately putting in boldface to illustrate what I just said—I hope not in violation of ] but certainly in violation of easy readability and good typographic practice.) ] (]) 05:35, 11 May 2012 (UTC)
*'''Opt-in'''. These mass changes where people are scrambling to find out how to turn them off is kind of annoying when it keeps happening. A bolded watchlist may be okay for very short watchlists but for longer ones there's just a mass of bold that's hard to read. Less is more. ] <small><sup>]</sup></small> 06:10, 11 May 2012 (UTC)
*'''Opt-in'''. Some '''people''' like '''it''' so '''let''' them '''have''' it. '''Some''' people '''hate''' it '''so''' let '''them''' be '''without''' it. '''Bolding''' stuff '''is''' far '''too''' distracting '''for''' me. '''I''' hope '''my''' message '''is''' not '''too''' distracting '''for''' you '''to''' read. ] (]) 06:18, 11 May 2012 (UTC)
*'''Opt-in''', per ]. Any changes to the software must be gradual and reversible (]). ''']</font><sup><font color="#AF7817">]</font></sup>''' 06:33, 11 May 2012 (UTC)
*'''Leave as is (but with a user preference to disable it)'''. Get used to it, people. Things change. It's not as if the watchlist mas been removed on the grounds of server load. We should welcome, not spurn, extra functionality. — <span style="border:dashed #666;border-width:1px 0 0 1px">]</span>, and <span style="border:dashed #666;border-width:0 1px 1px 0">]</span> 07:30, 11 May 2012 (UTC)
*'''Hate the change and want it reverted''' I've made my case in other forums already. This is one of the worst decisions I've experienced here. It's a mess, a colossal, hideous and unjustified mess. Please revert it. No opting in, no using coding or progamming, no fiddling about - just revert it ] <sub>]</sub><sup>]</sup> 07:43, 11 May 2012 (UTC)
*'''Opt-in'''. All interface changes should be opt-in. At the very least, an off switch in User Preferences must be a prerequisite before future changes are implemented. - ] (]) 08:12, 11 May 2012 (UTC)
*'''Opt-in'''. I understand that this change might be useful to some editors, who should have the option to use it. But, like many others above, I view my watchlist using pop-ups, and this feature does not recognise this. Consequently, it is useless, misleading and obtrusive for me. I can click on the Mark All as Read button; but I would rather that disappeared from my watchlist too, leaving more space for actually useful information. <span style="font-family: Papyrus">] (])</span> 08:20, 11 May 2012 (UTC)
*'''Opt-in''', or at the very least give us a way to '''opt-out''' without having to alter our .css files. — ] 08:28, 11 May 2012 (UTC)
*'''Abolish''' as first choice, '''Strictly opt-in''' as second choice. Use the "principle of least astonishment", here - don't change the way a functioning system works without an extremely good reason! --] (]) 08:56, 11 May 2012 (UTC)
*'''Opt-in'''. No point in stopping people using it, if anyone really wants to. However, '''all''' such changes should be switchable in User Preferences, with the default as off. Many WP users are not Techies, and expecting them to add text to CSS pages is totally unacceptable. Even for those happy to add code, the problem is knowing the code exists, and being able to find it - many such options are hidden away on obscure pages, or in archives.] (]) 10:20, 11 May 2012 (UTC)
* '''Opt-in''' but '''No Bold''' is better. '''Can't believe anyone in their right mind would think that it is a good idea to use bold to support this (in itself) sensible functionality. What is this; 1995? Making it bold makes the page much busier and therefore much harder to read (as well as more hideous). Anyone with even a basic understanding of website usability (and that should include those working on Misplaced Pages) knows that this is an absolute no-no.''' --] (]) 10:30, 11 May 2012 (UTC)
* '''Opt-in''' - came home from work a few hours ago, checked my watchlist and it now looks like an email client in-box instead of what I was otherwise expecting. No green stars, tho. (Firefox 12.0, WinXP) --] (]) 10:44, 11 May 2012 (UTC)
*'''Opt-in''' There's no reason to get rid of access to it entirely entirely for those who actually want it but this should never have been presented as a fait accompli. I find it actually painful to view my watchlist.--] (]) 11:13, 11 May 2012 (UTC)
*'''Opt-out'''. I do like the feature for a simple reason: Previously, I needed to check every page twice: first to see the last bunch of edits, and second time to mark the last watched edit visible in my browser (and moving from office to home may be a problem). Now I only need to do it once. Opt-in is not sufficient, since most people would not bother. For me, changing the .js files is a serious technical challenge. At the very least, it should be available as a option in preferences. BTW I would also prefer to have edits appeared since my last visit marked green, in my case they only show up as plain text.--] (]) 11:54, 11 May 2012 (UTC)
*'''Opt-out''': I supported this feature before and still do, but opt-out doesn't hurt as every one doesn't seem to find it constructive to ''their'' own editing. --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 12:17, 11 May 2012 (UTC)
*'''Opt-out''': I don't mind the concept, but I personally don't like it, so I would really like a way to turn it off through gadgets rather than random CSS hacks. '''Yoenit''' (]) 12:52, 11 May 2012 (UTC)
*'''Opt-in''' May be useful to some, awful for others. --] (]) 13:05, 11 May 2012 (UTC)
*'''Opt-out'''. Any editor sophisticated enough to be using a watchlist can figure out how to opt out, so long as there's an option to do so. ] (] - ] - ]) 13:35, 11 May 2012 (UTC)
*'''Op-in''' Seems to me my watch-list shows changes by default anyway, the last ''x'' number of changes; why do i need bold or stars or anything else to see it; let it stay, if others like it, but has to be opt-in, not opt out. Just because this is default elsewhere doesn't necessarily make it a good thing. Now looking at my watch-list or a history page is painful to mine eyes. Cheers, ''']'''<sup>]</sup> 13:40, 11 May 2012 (UTC)
*'''Opt-in''' (or opt-out). I don't find it useful, more of an eyesore than anything else. There should at least be an option to disable it. ] <small><span style="color:#191970">]</span></small> 14:46, 11 May 2012 (UTC)
*'''Opt-in''' doesn't seem all too helpful to me, and my first instinct when seeing the bolding is to assume it's a page or change I already viewed. <span style="background:#66EE88">''']'''</span> 15:03, 11 May 2012 (UTC)
*'''Opt-out'''. This has been in place for years on other wikis like Commons, where I spent more of my time, and I've found it extremely useful over that period of time, nor have I ever seen anyone complain about it in any forum. I believe new users who are not so accustomed to the old watchlist styling will also find it useful. A feature that is off by default is a feature that is almost never discovered and therefore of minimal utility. However, I think an option to turn it off would be reasonable deference to those with a strong personal preference. I would also reluctantly accept a compromise in which it is '''opt-in''' for existing users, and '''opt-out''' for new users. ] 15:06, 11 May 2012 (UTC)
*'''Opt-out'''. I appreciate that some people will use it however there really needs to be either a gadget or an opt out. I find it very distracting and for me it makes the watchlist difficult to follow. The bolding should be turned off why this is happening. ] ] 16:04, 11 May 2012 (UTC)
*'''Absolutely hate this change and want it abolished'''. I'm not stupid, I have something called a "memory" which enables me to understand which links I've clicked and which I haven't. <span style="text-shadow:grey 0.2em 0.2em 0.1em; class=texhtml">] ]</span> 16:06, 11 May 2012 (UTC)
*'''Opt-in''' or "Absolutely hate this change and want it abolished": The choice says it all, but for the 'not a vote' crowd: the continuous bold gives me a headache. ] (]) 16:50, 11 May 2012 (UTC)
*'''Dump it''' or '''Make it Optional''' - Right now, my watchlist contains many times more its normal load, due to various factors like bots, or assessment projects, whatever.''' It's all in bold, and it's hurts my eyes. My watchlist lately is one big page of bold type. '''] (]) 17:07, 11 May 2012 (UTC)
*'''Revise/Opt-in''' The big issue for me, as nearly everyone seems to be observing, is that everything I decide isn't worth looking into stays bolded, so that the bold (besides its obstrusiveness, which is also something of an issue) doesn't give a good indication of what to look at. If it is to be retained, it needs to have a "clear" function so that the user can tell the bold to go away on items that he judges don't need to be looked into. ] (]) 17:14, 11 May 2012 (UTC)
::And, sure, you can manually click on "Mark all pages as visited" to clear the bolding. A nanno second later, something else can pop up on the watch list. Especially when bots are running out there. Nobody wants to spend all day clicking the option to clear the bolding.] (]) 17:25, 11 May 2012 (UTC)
:::I've looked at the watchlist, and at preferences, and I still haven't been able to find how to 'mark all as viewed'. Even if I were to use it, busy pages like ANI, BLPN, RSN, RM and this one continue to light up like Christmas trees. It really needs to have an on–off switch. --<small>] ]</small> 00:29, 12 May 2012 (UTC)
::::There's a big "mark all pages visited" button on top of the watchlist which is very hard to miss, unless some admin or other user script has removed it for you. --] 06:06, 12 May 2012 (UTC)
*''''Revise/Opt-in''' pretty much per Mangoe. It essentially keeps the items you're the ''least interested'' in looking at bolded. <B>—]</B> <sup>]</sup><sub style="margin-left:-3.5ex;">]</sub> 17:51, 11 May 2012 (UTC)
*'''Opt-in''' per Tryptofish et al. Absurd, annoying and (to me) useless. ] ]] 18:14, 11 May 2012 (UTC)
*'''Opt-in''' - stress-inducing and useless to me, and above all, '''Tell us what is going on''' if ever you change the appearance of everyone's watchlist: there was no explanation of this, just a sudden headache of bold text shouting at me. ]] 18:34, 11 May 2012 (UTC)
*'''Opt-in''' or '''opt-out''', either way is fine with me, but please make it a choice, not an absolute!! An opt-in or opt-out would be much easier for us techno-phobes who do not want to have to copy complicated .js stuff into our preferences!! --] (]) 19:57, 11 May 2012 (UTC)
*'''Opt-in''' (off by default) is my first choice. If that is not easily doable, just undo the change. Distant 3rd would be to go back to the star instead of bolding. --] (]) 00:44, 12 May 2012 (UTC)
*'''Opt-in'''. For experienced users, who typically have large watchlists and many high-traffic pages on them, there are too many cases where the natural reaction to a watchlist change is something other than visiting the page, making the whole idea of highlighting based on visited status not really useful. There should also less visually distracting ways of implementing the highlighting, if you wanted it. ] ] 06:42, 12 May 2012 (UTC)
*'''Opt-in''' Damn nuisance. I know what I'm doing in my watchlist. This refers to the bolding - I can't remember seeing any stars anywhere, green or whatever. Don't want any, either. ] (]) 14:18, 12 May 2012 (UTC)
*'''Support as opt-out feature'''. The first couple of times bold showed up on my watchlist for brief intervals, I couldn't figure out what it meant and the changes were distracting (maybe the feature wasn't working properly). However, in its full implementation I found it very helpful. New users who get this by default are unlikely to complain because they will find it helpful, but opt-out should be available. (PS - There are plenty of other recent interface changes that I find annoying, but this one was helpful.) --] (]) 15:30, 12 May 2012 (UTC)
*'''Opt in'''. Could be useful for some, but I find the forced implementation based on a ] of something that affects every single registered user annoying. ] (]) 05:24, 13 May 2012 (UTC)
*'''Opt out'''. This will by far be most useful to new users and leaving it as an opt in absolutely defeats that purpose. As has been noted the default in email readers is for bold to be unread messages and many new users will be expecting that. There is no reason to disable or leave it as an opt in other than to take "revenge"(?) on the awful devs and to make sure that "your" way is the "right" one. Tradition is a terrible excuse to keep things stationary. ] (]) 06:42, 13 May 2012 (UTC)
*'''Opt in''' This feature may be welcome by some, but I suspect more find it a nuisance than a benefit. Personally I have no use for this, since I check the diffs with navigation popups, not by clicking through to the articles. ''']]]''' 17:44, 14 May 2012 (UTC)
*'''Change''' per Mirokado. Instead of seeing lots of green stars (the best version so far), have the script find either the last refresh of the watchlist page, or the earliest green-star change, and on ''that'' change line only, add a second (divider) line consisting of a horizontal rule with central text like "last visit 00:00, 00 Mmm 0000 (UTC)". Picking out a ''single'' HR rather than navigating the starfield is much clearer. '''Note''': this applies in spades to the change listing "updated since my last visit" in green prior to every "(undo)" link, which is '''absolutely horrid'''. Looking for the earliest green line when it's not at the beginning or end of the line and looks almost black on a laptop is much much worse than an unobtrusive horizontal rule. (And when I look at the page via choosing a diff link in history rather than visiting the page directly, this "service" guesses wrong anyway, but that wouldn't be such a frustration with an easy-to-find HR). '''Sidenote''': the vast sentiment for "opt-in" does ''not'' mean "opt-in" is the winner, it means the winner is "the UI guys tried too many changes too fast and scared us". If more discussion of technical capability occurs and more users are drawn in, a second straw poll would probably give a different result. The solution is that future major UI changes should get a dismissible announcement note where users can comment "hate it" during the trial period until people stop hating it. I hated italicized titles for a long time until I realized my concerns were illusory. ] 20:15, 15 May 2012 (UTC)
*'''Opt out''' Apparently some people think it has functionality, but many others including me find it both useless and annoying. I was finally able to figure out the instructions for deleting the stars and the green tag manually (I re-posted the method below in the "Now getting green 'updated since last visit' message in page history" section), but it shouldn't be that hard. Please provide a click-here button for those who want to turn off both new features: the bolding and the "updated since my last visit" tag. (At first I thought that was something which was being added by the editor making the edit, and I almost contacted them to ask "why are you using that as your edit summary?") --] (]) 22:10, 15 May 2012 (UTC)
* '''Opt-in'''. If other folk want it, then fine; but I don't, and cannot fathom why it should be imposed by default. Those who are least adept at dealing with UI tweaks and preferences are most likely to be uncomfortable with the change (this is why I'd say opt-in rather than opt-out). Personally, I'd treat an incredibly busy live environment as ''live'', and restrict my tinkering to a test environment, but what do I know? ] (]) 09:14, 16 May 2012 (UTC)
*'''Support''' this is a very useful feature for editors like myself who don't always visit Misplaced Pages every day. I don't understand what is so intrusive about titles conditionally being displayed in boldface. There is precedent for bold titles as an indicator in ]. I request that bold be used as an indicator both in watchlists and in article version histories. --] (]) 19:39, 16 May 2012 (UTC)
*'''Opt out''' or '''support''' (per Kvng) - this is '''great funkcionallity''' I know from other WM projects it relieves the user from lot of re-reading. Those who comment about having too much of pages in watchlist for this - I believe it just the other way, because I do have simply too much of pages in the watchlist I want to know instantly which of them I did visit already. I want this option back ASAP. please! '']'' ''']''' 20:26, 17 May 2012 (UTC)
====A note about "opt-in"====
Let's be clear; this feature only adds a marker to indicate that a page has been changed. I cannot imagine how that could ''not'' be good functionality. As for the styling, that has yet to be decided, but there is absolutely no reason to have it disabled in any way, just becuase of a conservative mindset. If everything new is made opt-in, the preferences section is going to be too overwhelming to new users. That is something we absolutely do not want. The feature is there based on earlier consensus. It was also decided the styling was to be discussed at a later date. Right now, all the nay-sayers want it disabled or made opt-in ''purely'' based on what it ''looks'' like, while not a single comment has been made on the ''functionality'', so those comments are likely to be discarded pre-emtively.
So, let's be really constructive and decide how we want changes to be visualized, because there is one thing I can guarantee you: configuration options that have been enabled by default on this (or other) project(s) can and will ''never'' be opt-in. <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 08:04, 13 May 2012 (UTC)
::'''Re "Right now, all the nay-sayers want it disabled or made opt-in ''purely'' based on what it ''looks'' like, while not a single comment has been made on the ''functionality'', so those comments are likely to be discarded pre-emtively.": Aesthetics and functionality are inseparable in this case. When how something ''looks'' compromises its ''functionality'', then there is a problem. I have the bold watchlist on Commons, and I don't take any issue with it; I only have a few things watchlisted, so the bold is pretty unobtrusive. Here, however, I have dozens and dozens of pages watchlisted. Logging in after a day and seeing a wall of <font color=0000CC>blue</font> and <font color=660088>purple</font> bold is just not helpful at all. The design impairs the usefulness. ~~ ] (]) 21:06, 14 May 2012 (UTC)'''
:Well, it would appear this one is opt-in as of now. As for which change specifically we're discussing, that's semantic. People clearly don't want the visual style that's been implemented here forced on them. That should be opt-in (and is right now) since the discussion on styling didn't take place beforehand, as it probably should have, especially if the need for that discussion was foreseen prior to implementation.
:Seeing as the people have spoken, it would appear that the default visualization should be no visualization. I don't think those voting for opt-in care if some extra code they can't see is implemented, so that should stay. Visualization should be implemented as a preference/gadget, or set of them for different style options. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:14, 13 May 2012 (UTC)</font>
::The fact that its opt-in is because some admins apparently feel intimidated by the current backlash. Had it been left in place, I'm sure most commenters would be accustomed by the change real quick (as some already have). The fact fact that the option was turned on took us all by suprise, so there was no time to discuss beforehand (it even looked like it wasn't going to be implemented at all). Now that it has been enabled, it is here to stay. Elen of the Roads has put up a ] to poll the various options, and I'm interested to see where this is going. But again... opt-in is not an option, because configured MediaWiki behaviour should never be hidden by default. <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 19:33, 13 May 2012 (UTC)
:::We appear to have made it an option. Intimidating admins with backlash? Opt-in is not an option? Are you hearing yourself? First of all, if intimidating admins with backlash is what it takes to make the interface reflect community consensus, then so be it. That doesn't bother anyone (except the admins? and again who cares). Secondly, you're no one to say that anything is not an option, especially in the face of all this feedback. Third, Elen of the Roads had a very clear rationale for instituting the override, which she's expounded on repeatedly, and there was no intimidation involved (I don't think Elen is capable of being intimidated and you should apologize to her for suggesting as much).
:::Anyone who's looking at your responses here and following the situation can tell that you're feeling spited by the massive lack of support for something you were involved in. It must suck and I'm sorry. But don't start dictating what can and can not happen, nor brushing off the response as typical this or that. You can supply your input like everyone else, and implement the community's decision in the end; aside from that, please sit down. You're not in charge here. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 19:43, 13 May 2012 (UTC)</font>
::::No, we appear to be outraged over a configuration change, which triggered a change (by me) which was reverted, then disabled allthogther. People don't like the bolding? Fine. But when those same people ''demand'' it be disabled or made opt-in, they are purely expressing their personal opinions, without realizing the consequences for ''other'' people. As an admin, I realized I cannot allow that. I have to see beyond those opinions and their ramifications; making a core functionality hidden by default for all users, including new ones? I'm sorry... that's simply not an option.
::::Yes, I originally proposed the option be turned on, which was met with approval. But again, the community is not in charge of disabling/hiding functionality once enabled. I simply don't understand the outrage for something that ''can'' be really unobstusive. There is simply no point in making it opt-in. It only adds another layer of complexity that we can surely do without. <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 20:16, 13 May 2012 (UTC)
:::::The community ''is'' in charge of interface changes, and you being an admin does ''not'' allow you to override a demonstrated consensus in favor of your own views of what's best. Call it outrage or whatever else you like, but ''your'' characterization of ''why'' the change is being rejected is of no consequence. It was claimed that a demonstrated consensus brought this change in the first place, not ''you'' (as it should be); and now a much larger consensus is now being demonstrated against it. So now it's off by default (as it should be). What to do now is being discussed, but barring another consensus to switch it back on by default in some form or another, it doesn't happen. It is not your place to declare that it should be on by default because you know better than everyone else. Adminship doesn't grant you that privilege. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 00:21, 14 May 2012 (UTC)</font>
::::::''The community ''is'' in charge of interface changes''
::::::Where's the policy that says that? I can't find one. More to the point, where's the agreement from the WMF that they agree with this statement? I can't find one, and I can find multiple counterexamples, e.g., the ], which is definitely an "interface change" and which was definitely continued despite people yelling about how much they hate it. ] (]) 02:29, 14 May 2012 (UTC)
:::::::WMF retains the right to override the community on nearly any issue, including interface changes (though they say in general they don't do that). I don't see any evidence that this decision comes from them. On the contrary, this was shown to have been enacted via a community discussion -- and an even broader community discussion now shows a different outcome. So it goes. Should the foundation decide to override it, we'll deal with that then. Edokter doesn't speak for them just because he's an admin, any more than I do. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 02:40, 14 May 2012 (UTC)</font>
::::::Is this one opt-in as of now? Where do I opt in? ] (]) 12:32, 14 May 2012 (UTC)
Is it really that important that traditional users not have to check off one box to have their traditional style in place? 4 days of some users screaming in the Village pump is enough to constitute "clear consensus"?
Has anyone tried to scream at Google for making this behavior the Gmail default? At Microsoft for doing it in Hotmail? This hadn't been the default here for fear of performance issues but over at ptwiki and at others projects it has been used for ages. In fact users complained a lot over the brief time it was disabled in order to get better performance metrics about the new watchlist emails. But hey, the world will end if you have to check a box off to get old behavior back. ] (]) 17:04, 14 May 2012 (UTC)
:There's a huge difference between emails, which are singular specific entities, and marking bold if you have simply not VISITED a page. As someone pointed out above, bolding the title of the article gives weight to the wrong thing. If I check my watchlist, and then go visit an article after the last change to read something, it's pretty dumb to have it not bolded because of that, don't you think? ] (]) 18:08, 14 May 2012 (UTC)
I don't think so. Articles are indeed distinct entities, as are changes, and the question of whether I've already seen them is as important as in E-mail. And yes, if I check my mail, and visit somewhere else and return, the one I've read is marked as been read. Easy to remember when it's only one or two to which I might return. Yes, marking things as been read is more important here in en than in either E-mail or Commons, because en is busier than either (for me, anyway) and this is where my old and feeble brain needs all the help it can get. Anyway, I've now got it thanks to the helpful note of ] and it will help me in sorting out all the irritating little changes made by Helpful Pixie. However, the smarter editors than me ought to be the ones who have to dare to customize to omit this information. ] (]) 22:03, 14 May 2012 (UTC)
:Significant comments about the '''opt-in''' vote appear in my vote above. ] 20:15, 15 May 2012 (UTC)
=== Now getting green "updated since last visit" message in page history ===
Presumably this is linked to the changes made on watchlists but now there are green messages appearing on page histories indicating that the page has been changed since my last visit. Any way to opt out of this one as well? ] (]) 21:50, 10 May 2012 (UTC)
<code>strong.mw-watched a {
background: none;
padding-left: 0;
}</code>
cf ]. ] <sup>]</sup> 21:52, 10 May 2012 (UTC)
:History, not watchlist stars. --]]] 21:53, 10 May 2012 (UTC)
:{{ec}}This is related to the above.--] ] 21:54, 10 May 2012 (UTC)
:<code>span.updatedmarker{display:none;}</tt> --] (]) 21:54, 10 May 2012 (UTC)
I use Vector skin and I have the green message on the history page. I can't follow the above discussions. What am I supposed to do to get rid of it? Please be explicit, i.e., go to here, put this code here, etc. Thanks.--] (]) 23:02, 10 May 2012 (UTC)
:And what's absolutely and truly STUPID about this is that it showed new edits to this page in green when I pushed history after clicking the diff four minutes earlier (and then checked the rest of my watchlist). So a whole bunch of edits that are new are not shown in green while only a couple are. ] (]) 01:22, 11 May 2012 (UTC)
::And even MORE dumb is that hitting the back button shows only the updates since I posted, not the intervening edits between me clicking on the batch of diffs from the history and reading and then making the above posts, which I of course never actually saw. So how is this supposed to be helpful again? ] (]) 01:53, 11 May 2012 (UTC)
*{{highlight|'''This is so ridiculously inane please turn it off. ~~ ] (]) 02:06, 11 May 2012 (UTC)'''|lime}}
*Lose the commons-like bold stuff and green highlighting - and see if you can get rid of it at commons also. It's very annoying. ←] <sup>'']''</sup> ]→ 05:22, 11 May 2012 (UTC)
*It certainly is jarring. Seems to me it could be toned down considerably. After all, if we can have diff colors so subtle you practically need to wear special glasses to see them, there's no reason we couldn't have a gentle, low-saturation green here. And perhaps smaller type. ] (]) 05:44, 11 May 2012 (UTC)
:The green notification might be useful if it was done properly. Currently it displays itself for every revision that I supposedly haven't seen. And on some pages that can mean many copies of the same green box. It is completely taking over the page and makes it look awful IMO.
:Perhaps better if the box was be be placed only once at the eldest revision that I haven't seen. And the text can then be changed to something like "Changes above this notification bar are new. Changes below this notification you have already seen". ] (]) 07:30, 11 May 2012 (UTC)
*Actually this is great, mine wasn't green so I changed to a green highlight by editing common.css. :D --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 14:36, 11 May 2012 (UTC)
*I have the same opinion as ]: it's useful to have a line drawn across the revisions, not so useful to label every revision more recent than the last visit, given that there's already a lot of clutter on each line.
*I have the same question: I don't find the green "updated since my last visit" note helpful, and I do find it annoying. Is there some way to opt out of it? <s>I see that this subject has been here for the better part of a week, with questions but no replies; are the tech gods even listening?</s> Update: For some reason someone just reverted my comment, without explanation. If there are instructions somewhere in this thread for opting out (maybe the line of code posted by Yair Rand?), they are not evident or helpful without more detail about what to do with that code or where to put it. --] (]) 15:22, 15 May 2012 (UTC)
::P.S. Looks like Bbb23 has the same problem. --] (]) 15:24, 15 May 2012 (UTC)
OK, I found some instructions many paragraphs above this one and I think they worked. Here they are, for those who like me came directly to this section, copied from above with the code pasted in: <blockquote>Click "my preferences", and then click the "appearance" tab. There should be a line which reads "Shared CSS/JavaScript for all skins: Custom CSS | Custom JavaScript". The "Custom CSS" part should be a red link; click it to be brought to an edit screen for your personal CSS settings. It'll be blank as I'm assuming you've never created one. Paste in the code '''<nowiki>span.updatedmarker{display:none;}</nowiki>''' and save it; that'll create the page and apply that code regardless of which skin you're using. Check your watchlist afterwards to be sure it's worked.</blockquote> --] (]) 15:56, 15 May 2012 (UTC)
:Far too complicated. ] (]) 17:22, 15 May 2012 (UTC)
::I agree a straightforward opt-out feature would be better, but this is better than nothing. --] (]) 17:24, 15 May 2012 (UTC)
::::Only very very slightly. ] (]) 10:50, 16 May 2012 (UTC)
:::Significant comments about why this is '''absolutely horrid''' and a horizontal rule would be much better appear in my straw-poll vote above. ] 20:19, 15 May 2012 (UTC)
=== "Changes related to" pages all gone wrong ===
It should be that ''Changes to pages on your watchlist are shown in '''bold''''', but they are not. Items not on my watchlist don't get a green star; items on my watchlist do get a green star - but I just marked all pages as visited, so I guess they shouldn't have. Not good. ] (]) 21:57, 10 May 2012 (UTC)
:In that case, the message can be changed. <span style="font-family:'Trebuchet MS'"> — ] (]) — </span> 22:04, 10 May 2012 (UTC)
The stars don't work for me. Instead looking a word, I'm looking at a column of green stars. <span style="border-bottom:1px dotted #000;">]</span> would be so much better since it would focus the users' attention on the word instead of an area to the left of the word. --] (]) 22:07, 10 May 2012 (UTC)
The stars don't work for me. Instead looking a word, I'm looking at a column of green stars. <span style="font-style:italic;">]</span> would be so much better since it would focus the users' attention on the word instead of an area to the left of the word. --] (]) 22:07, 10 May 2012 (UTC)
:Italics are harder to read than either plain (Roman) text or bold-faced text. I don't think we want to increase the visual challenge involved in reading the most important words on the page, especially given the number of users we have who have significant visual impairments. ] (]) 23:50, 10 May 2012 (UTC)
===Use a check mark instead of stars===
A tick-mark (✓, ✔, ☑, etc.) for verified pages would make more sense to me. Not only is it less obtrusive, but the mark itself is mnemonic and clearer in meaning. The drawback is the need to insert a character in the text. Regards, ] (]) 18:25, 14 May 2012 (UTC)
===Change temporarily reverted in search for better consensus===
:''See also ]
I have this change because it was clearly not discussed widely enough. The number of people commenting after the change to Common.css is more than double the number that originally commented on the proposal. The stars are particularly too bold a change for a function that is used by basically every active editor. <font style="font-family:Palatino, Georgia, serif;">] • ]</font> 22:17, 10 May 2012 (UTC)
:Oh. So is it currently at bolding? Because the stars really were better than the bold. ] <small><span style="color:#191970">]</span></small> 22:19, 10 May 2012 (UTC)
::<s>I have , though it was the green stars that I first noticed.</s> In any case, I fully support people proposing radical change to the watchlist. But only in the spirit of ]. Update: I am an idiot and didn't see that the bolding is not in Common.css at all. <font style="font-family:Palatino, Georgia, serif;">] • ]</font> 22:26, 10 May 2012 (UTC)
*Whomever started this process needs a kick in their britches. There are many ways to solicit attention to proposals of forced change in visual design. One way to implement them is to not fuck with the live copy. <s>The annoying bold text is still present, and is still degrading my user experience.</s> ] (]) 22:19, 10 May 2012 (UTC) 22:34, 10 May 2012 (UTC)
*The bolding is back and it's really hard on the eyes - also it induces an instant migraine. Each time I've logged off and logged back in today the watchlist has been different. It's extremely annoying. ] (]) 22:31, 10 May 2012 (UTC)
*Agree with ], '''all''' these changes need to be reverted and the proposal(s) needs to go back to the start. I hope the "powers that be" have learnt out of this "epic fail" that we do want projectwide wall-to-wall notification of proposals that have such a drastic effect on all editors' experience of working on the project. ] (]) 22:30, 10 May 2012 (UTC)
*:The "powers that be" had nothing to do with these changes. --] (]) 22:37, 10 May 2012 (UTC)
*::Whoever managed this process and implimented these changes are "the powers that be" for the purposes of this discussion, or have the WMF servers achieved self awareness and now write their own code? ] (]) 22:51, 10 May 2012 (UTC)
*::: As you can see from ] the developers were just fulfilling a community request backed by a consensus. People would be pretty mad if they just refused the change too, so I don't think anyone can lay some blame on their laps here. <font style="font-family:Palatino, Georgia, serif;">] • ]</font> 23:10, 10 May 2012 (UTC)
::::: The problem was, those who had taken part in the original discussion had said "yes, let's have something, preferably an opt in gadget." There wasn't actually a discussion about how it was going to work, or when it would be done, so when Erwin starts trying to see how it might work, people were surprised, didn't like the first couple of tests, and had in many cases been expecting something else entirely. It was ever thus, but having a space to test out how it might work before changing the interface for everyone might have been really useful, and saved a lot of flak. ] (]) 23:26, 10 May 2012 (UTC)
*Put an option in userprefs and then leave it alone. My watchlist style changed at least 4 times today between 3 different styles, which is more annoying than either bold or stars. ] (]) 23:00, 10 May 2012 (UTC)
*There's a misunderstanding I think, the change , only the stars (!) have been removed. There's ] for the status quo, default feature (normal bolding and green text), drastic changes like these (no bolding and different style in histories, besides weird stars) need a vast consensus after a discussion of at least some days at usual, not such hasty decisions and rapid changes, as pointed out also by Kilopi above. ] 23:12, 10 May 2012 (UTC)
***'''Where is there consensus on this page for "normal bolding"? The status quo is no bold. ~~ ] (]) 00:08, 11 May 2012 (UTC)'''
** Since it appears the CSS hack to remove the bolding on watchlists is breaking bolding elsewhere, I think it may be wise for me to set Commmon.css back to what it was before either Erwin or I edited it. If people want to fight out the configuration change referenced in the bug, then let them have at it. <font style="font-family:Palatino, Georgia, serif;">] • ]</font> 23:40, 10 May 2012 (UTC)
*:A "consensus" of only 20 support !votes to impose a radical user interface change (that has no easy "off switch") on all ninety-odd thousand active editors<ref></ref> is not a true consensus. Such proposals should require thousands of support !votes before anyone sane could call it a true consensus. Twenty users is a cabal, not a consensus. (IM<s>H</s>O the threshold should be in the region of ten thousand !votes.) ] (]) 23:42, 10 May 2012 (UTC)
*:::I agree it should probably be discussed more. I cannot do anything about it personally though. <font style="font-family:Palatino, Georgia, serif;">] • ]</font> 23:44, 10 May 2012 (UTC)
*::::Surprises seem to bring out the worst in active Wikipedians, but I think, based on the experience of many other websites with visible, function-enhancing changes, that the thing to do would be to leave it in place for a month or two, and only then ask people what they thought. Think about the "Tell Facebook to revert its changes" pages that spring up every time that website changes anything. Tens of thousand of users sign up on these protests, and a month later, most of them can't even remember what the old version looked like. ] (]) 23:56, 10 May 2012 (UTC)
*::::::'''No, I'm sorry, that's just plain dumb. Sites like Facebook and Youtube do that because they exploit the fact that they have a "captive audience". Misplaced Pages is very much a user-oriented site, and not giving an option violates that fundamental spirit of the project. ~~ ] (]) 00:06, 11 May 2012 (UTC)'''
*:::::::Facebook also has a beta testing program where they make sure changes are reasonably acceptable to their audience before implementing them, rather than testing new stuff live. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 00:12, 11 May 2012 (UTC)</font>
*::::::::'''But here you actually have the option of sticking with old settings. I am using MonoBook with green/yellow diff styling. Meanwhile, I am dreading the day when Mark Zuckerberg is going to finally shove that Timeline monstrosity down my throat for good. ~~ ] (]) 00:18, 11 May 2012 (UTC)'''
*:::::::::Why so much bold? :( — ] 07:18, 11 May 2012 (UTC)
*::::::::::'''What, you don't like the bold? It doesn't make things easier to notice? {{highlight|What if I throw in some green, does that make it better? ~~ ] (]) 13:52, 11 May 2012 (UTC)|lime}}'''
*'''Can we please get rid of the fucking bold again, already.''' I don't wake up and shit all over your user-interface and then play hissy-fit games about consensus. ] (]) 00:34, 11 May 2012 (UTC)
**'''^What he said. ~~ ] (]) 00:50, 11 May 2012 (UTC)'''
***^What they said. ] (]) 00:55, 11 May 2012 (UTC)
****Couldn't have put it more eloquently. ] | ] 01:03, 11 May 2012 (UTC)
*I agree that we should revert all these changes until a consensus can be reached for their implementation. We need a wiki-wide surveying for single articles like ] and ]/] yet technical changes that ''actually affect us'' are sandboxed around Facebook-style? I don't appreciate it, and most others here would agree. — ''']''' <small>(] • ])</small> 01:09, 11 May 2012 (UTC)
*'''''GET RID OF THE BOLD!'''''. '''Constantly having every-fucking-THING on your watchist in bold if you just started the day's editing is EXTREMELY distracting and does NOT make a good work environment. Hopefully this bolded paragraph will be able to aptly demonstrate what I mean! ] / ] / ] 01:16, 11 May 2012 (UTC)'''
*'''Revert immediately'''. Clearly a case of inadequate discussion and hasty implementation. I don't want to look at that eyesore of my watchlist for a second longer. As the <u>net number of complainants now far exceeds the number who participated in the original decision</u>, can someone please revert now and discuss now that we have the undivided attention of "the community"? --<small>] ]</small> 02:11, 11 May 2012 (UTC)
*'''''GET RID OF THE BOLD!''''' Please!. It makes the page really hard to read and gives me a headache. All that bolding takes its power away as a highlighter while, at the same time, confusing the reader. Bold has to have a reason; there is no logical reason for this use. The titles were perfectly clear. ] (]) 02:10, 11 May 2012 (UTC)
*'''Bin the Bold''' I echo the sentiments of the honourable and right honourable members of the project above. ] <sub>]</sub><sup>]</sup> 05:21, 11 May 2012 (UTC)
*'''Don't reset &days=''' – I don't mind this feature, except that pressing the button "Mark all pages visited" a) does more than that – it also brings up pages which have changed since the list was previously generated and already unbold them, which is confusing; b) forgets what value I had used for the &day= parameter. In short, pressing the button will issue the default ] action, which makes long watchlists much harder on the browser. As it is, the button has more downsides than upsides; I guess I have to learn not to use it. -- ] (]) 09:39, 11 May 2012 (UTC)
*:You're right, I've filed your feature request under ]. ] 14:04, 11 May 2012 (UTC)
*The users who are now contesting the consensus for implementing this change clearly didn't participate in the consensus where it was almost unanimously determined to implement this change (and yes, those who didn't participate gave it a silent consensus too). It is right that a notice should have been added or something to inform atleast of what was going on (I was already using a script for the bolding so I got confused too), but I don't think that this was blatantly applied without a consensus. The changes are good, instead of removing them, an opt-in or opt-out feature should be added so that it doesn't hurt those who don't want it. --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 14:44, 11 May 2012 (UTC)
**] does not imply agreement or disagreement. As pointed out by others above, this is an issue that affects thousands upon thousands of users, and for such discussion to have real mandate, the participation rate needed to be a lot higher than the approximately dozen votes that caused this feature to be implemented. --<small>] ]</small> 00:33, 12 May 2012 (UTC)
**:That page doesn't say what you attribute to it: «This page in a nutshell: Consensus is assumed when there's no evidence of disagreement». You need another essay to prove that lack of consensus is proved when there's evidence of disagreement. Thanks, ] 07:28, 12 May 2012 (UTC)
*Is there any way we can get this feature back (opt-in) while the arguments continue? --] (]) 15:20, 12 May 2012 (UTC)
** See ] below. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 15:24, 12 May 2012 (UTC)</font>
===This actually fixed a bug===
:''See also ]
Not only the feature "Show changes since last visit" was enabled by community request, as said above (], by the way), but as far as I can see it was also needed to fix some bugs reported a few sections above, see link. Without this default feature, MediaWiki behaves inconsistently; with it, nothing is broken. --] 23:24, 10 May 2012 (UTC)
:I think I can sum up the opinion above by responding with: ]! ] (]) 00:03, 11 May 2012 (UTC)
:'''As far as I'm concerned—and I think many others will agree with me—that thread does not in any way constitute a "community consensus", so stop pretending like it is. An RfC is the most transparent way of going about determining consensus here, and that is what is being done above. ~~ ] (]) 00:15, 11 May 2012 (UTC)'''
:"Enabled by community request". '''bullshit''' ] (]) 00:40, 11 May 2012
*This is not a "fix." This is simply making the bug 24/7.--] ] 01:12, 11 May 2012 (UTC)
*:Wasn't the reported bug about an inconsistent behaviour and confusing info? I don't see any of that. ] 14:07, 11 May 2012 (UTC)
:Agree with Fifelfoo completely. It's really absolutely terrible and needs to become an opt-in option in preferences. Also, can someone please stop Helpful Pixie bot while this his happening to cut down on the watchlist burden. ] (]) 01:23, 11 May 2012 (UTC)
*We had basically the same reaction from Nemo on " Performer's username is shown twice in page move entries on the history": it's not a bug, it's a feature! A poor feature, wanted in principle but very badly implemented. Additionally, the button "Mark all pages visited" sadly does more than that alone; I usually have clicked on "hide my edits" and on "show all bots" to reverse the defaults, but using the "mark" button undoes that preference and sets everything back to its default setting. This is unwanted behaviour. ] (]) 11:51, 11 May 2012 (UTC)
*:If you consistently change the defaults, it's advised to do so ]. As said above, I've filed this feature request under ]. ] 14:07, 11 May 2012 (UTC)
*The manner in which this was implemented made many people irate; and now, no matter how many bugs were fixed, or how effective they were, the implementation debacle totally overshadows the bug fixes. --<small>] ]</small> 00:38, 12 May 2012 (UTC)
*:No. The number of users who like and need the feature the number of complaining users. Moreover, the implementation debacle of hasty and confusing changes to the watchlist style by some admins totally overshadows the (supposed) benefits in terms of (unproven) consensus compliance. ] 06:54, 12 May 2012 (UTC)
====Community and consensus-focused development====
If you want to spend some time raising awareness about problems with watchlist, why don't you spend a minute e.g. voting on ? It's very annoying that attention is drawn on unimportant things the large community doesn't care about/agree on while the problems reported by the community sit unnoticed, isn't it? For instance, ]. (Perhaps now no developer will fix such bugs, being afraid to be shot at by users who consider buggy software to be better than functioning software as long as it respects habits and tradition?) ] 07:00, 12 May 2012 (UTC)
:But just remember that the number of votes for a bug ]... ] 01:41, 13 May 2012 (UTC)
=== HOWTO: Subtle marker / no marker ===
If you'd prefer a subtle marker to the bold text, insert the following into ].
.mw-watched {
border-bottom: 1px dotted #999;
font-weight: normal !important;
}
This will cause the markers to appear as dotted gray underlines instead of bold text, like so:
]
If you'd prefer no marker, use:
.mw-watched {
font-weight: normal !important;
}
In both cases note that this will also affect display of watched pages on ].
HTH,--]] 02:07, 11 May 2012 (UTC)
:VERY much like. Thank you. This should be a gadget, at least. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 02:08, 11 May 2012 (UTC)</font>
:Brilliant idea, I'm in favor (though perhaps as an opt-in to avoid more community rage). — ''']''' <small>(] • ])</small> 02:14, 11 May 2012 (UTC)
:see that tiny "mb" to the left of the diff in your image example? That's another ''pre-existing'' example of a low-intrusiveness inclusion of one bit of information. ] (]) 02:16, 11 May 2012 (UTC)
::A bit of info which you wouldn't be able to customise. ;-) But if you want yet another letter instead of the bold everyone is accustomed to, you can file the request on ]. ] 14:09, 11 May 2012 (UTC)
*Thanks, this is an excellent alternative. I can now use it along with ] without confusion. --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 15:04, 11 May 2012 (UTC)
* Thanks for the workarounds. <b>] <sup>]</sup></b> 19:29, 11 May 2012 (UTC)
* That works nice. I don't mind a subtle marker, but the bold was a bit much for me. Offering some options on a gadget that updated your css (you want jazzy, subtle, little green stars, blue fish...?) would be a really nice feature. ] (]) 22:56, 11 May 2012 (UTC)
{{tl|sudo}}
Can the underlined version be made the default please? ] just needs a quick edit. --] (]) 00:33, 12 May 2012 (UTC)
:It seems a very bad idea: as pointed out elsewhere, , other options are very user-unfriendly and would increase confusion. A more of focused discussion on if and how to change the style should happen with less haste when this discussion (and the users' habits) settles down. ] 06:04, 12 May 2012 (UTC)
:: "Standard" really doesn't mean anything. It's the MediaWiki default and can remain that way, but nothing precludes a local community from overriding the default behavior.
:: I agree that a more focused discussion should take place. That doesn't mean that leaving the bolding on in the meantime is a good idea. For smaller watchlists, it's not so bad. But for active users with a lot of watchlist entries, the bold is simply overwhelming. --] (]) 15:27, 12 May 2012 (UTC)
:::I've never found it overwhelming even with tens of thousands of items in the watchlist, and I don't see how the number of items in the watchlist matters, it's more about the percentage of visible text which is bolded.
:::Why isn't holding the default in the meantime a good idea? As written elsewhere, users were already getting used to it, while now only very few users will ever notice this feature and propose something else if needed. ] 18:39, 12 May 2012 (UTC)
:::: When you have a larger watchlist, the percentage of bolded items is higher. Usually on a directly proportional basis. That's the overwhelming part. It's very similar to an e-mail inbox that you simply can't ever get ahead of. Not on a project as active as this one, at least. Meta-Wiki is manageable.
:::: The underlining is vastly less awful. It gives a cue without punching the user in the face. I think it would make sense to use the bold for users with smaller watchlists and something less awful for users with larger watchlists. This could be accomplished through a user preference, implicit controls (less than 1,000 items, bold, etc.), or some other means.
:::: That said, this is actively causing a problem for established users, so it should be a fairly high priority to make the site less awful for them. When you have the chief tech guy at Wikimedia posting hacks to make the site less awful, you really question the default, at least as a default for everyone using the site. But obviously Erik's focus ''is'' the entire site while my focus is largely people like myself (users with large watchlists). --] (]) 18:50, 12 May 2012 (UTC)
:::::The size of watchlist should be proportional to your interest/ability to follow it; if it isn't, and "unread" items just increase and increase, there's something wrong in yor selection, very similarly to how an inbox as described by you would be plainly broken, and not by its style.
:::::I don't know what Erik's intervention means, I agree that established users should be heled and I think the update markers are very useful for those with a big watchlist (unless they have the memory of ]). Speaking of the style, I agree of course that it could be changed, although it's difficult to imagine something better than bolding; see for instance the recent comment on ]. ] 18:36, 13 May 2012 (UTC)
*Thanks for that script. It's brought the watchlist back to how it was early yesterday. This should be added to gadgets to allow a choice between a bolded or unbolded watchlist. ] (]) 01:46, 12 May 2012 (UTC)
=== Move this discussion? ===
] has made several attempts to move this discussion to ]. I've reverted them pending discussion. I feel the new location is obscure and this move unwarranted. Would like to get other opinions. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 09:10, 11 May 2012 (UTC)</font>
*Looks like a graveyard over there. I knew to come straight to VP, and I think many others did too. It seems natural enough to host the issue here, unless there's a better alternative. Suitable notifications should be posted at other potential landing points for queries and comments, such as ]. --<small>] ]</small> 09:14, 11 May 2012 (UTC)
**"graveyard" - what? I centralised the discussion there from VPR and VPT, leaving the original thread titles and a note about the move, and put the RFC on ]. This discussion is nearly 100k (about half of VPT), and now that there's an RFC, it's probably going to continue for days and weeks. How the hell is that appropriate for VPT? ] <sup>]</sup> 11:41, 11 May 2012 (UTC)
***The problem is that CENT and RFCs don't work as ideally as they should. People who notice interface changes generally come to VPT to see what the deal is. I don't see how it being long means it needs to be moved. ''Maybe'' the RFC section alone could be moved to an ] subpage, or maybe VPR, only because they might be more appropriate venues? I don't agree with shuffling the entirety of discussion off to an obscure newly-created page though. The general discussions seem fine where they are either way. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 11:49, 11 May 2012 (UTC)</font>
****It's irrelevant whether the discussion is moved to a VPT subpage, the talk page of a new help page documenting the issue under discussion, a user subpage, or the arse end of Mars - as long as links to the new destination are placed in appropriate places. The only difference with leaving the content on VPT, rather than a link, is that all other VPT discussions are crowded out. ] <sup>]</sup> 12:01, 11 May 2012 (UTC)
*****Crowded out? I don't see how. Links at CENT etc. are great but aren't as noticeable; I think it's far more helpful to hold a discussion in the place where it's most likely to be looked for. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 12:05, 11 May 2012 (UTC)</font>
******"Crowded out" is too obvious to explain. Now how is it better to have the discussion at VPT instead of at a VPT subpage pointed to from VPT? That's the question you need to answer, made very specific. ] <sup>]</sup> 12:12, 11 May 2012 (UTC)
*******How is it better? I answered that above. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 12:34, 11 May 2012 (UTC)</font>
{{od}}
and the answer was? ] <sup>]</sup> 13:34, 11 May 2012 (UTC)
:Well, aside from the fact that there's no reason to move the discussion to begin with (this is the correct venue for it and its length doesn't hamper other discussions -- I've seen much worse and people seemed to get along fine), VPT is where people go when they see interface changes, especially unwelcome ones. Moving things off this page just makes the discussion more difficult to find. A header and line kept around doesn't suffice, and while it's true we can link from CENT and we have the RFC listing, those aren't terribly prominent; many if not the majority of people don't know to check those. It makes sense to keep it displayed prominently here; also for the reason that developers etc. need to be reminded of what people's current concerns are, and it's harder for them to ignore a big discussion at VPT than a subpage or some new WP: space page made just for it that ''no one'' is watching yet. Prominence here should match the amount of attention an issue has garnered, and this one's got a lot of attention. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 14:02, 11 May 2012 (UTC)</font>
*Where is the RfC? Do you mean the vote happening at ] or is there another page somewhere? ] 14:16, 11 May 2012 (UTC)
**Yeah he means the vote above. An RFC tag was placed at the top of that section, so that makes it listed automatically at ]. Those listings don't get as much attention as one might hope though. The discussion's presence on this page is actually much more of a draw than the RFC listing (as you've actually demonstrated :) ). '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 14:19, 11 May 2012 (UTC)</font>
::It's ironic that the cause of this whole discussion is exactly the fact that things are "hidden" in obscure walled gardens inhabited only by uber-geeks. If an anouncement about the original proposal of six months ago was properly distributed to all user in the first place this "long" topic would not exist. Now you want to sweep this under the rug too! If WP was a commercial organisation the people responsible for this epic fail would have been unemployed today. As for the "crowding out" argument - utter bollocks! This page is not made of paper - it can stretch to accomodate practically any amount of text. ] (]) 14:18, 11 May 2012 (UTC)
::: Now now, let's not be mean to Edokter. The problem is that while there was approval of the theory - "let's have something that allows you to highlight changes you haven't looked at in your watchlist" - nobody really sat down and hammered out the details "how bold? Different colour? Is subtler better? Do we need a css tweakeria? Can we make it a gadget? No? What can we do instead? Would little icons work? Which icons? What colour?" and all the dozens of possible combos. And no-one did the stakeholder communication plan. I know this stuff seems like fantastical bureaucracy when you just want to get in there and tweak code (and the code tweakers are seldom the right folks to do the project plan - everyone has their own set of skills and should be respected for that), but this is what happens if you don't have something. ] (]) 15:22, 11 May 2012 (UTC)
:::I can't help but feel that some of this is being done the wrong way round. Is there a problem with the basic skin (of whatever hue)? Not that I can see but there is obviously a demand by a number of users for enhancements to, in this case, the way the watchlist is presented. That is fine and a valid demand but the way forward isn't to make a universal change which is bound to be unsatisfactory to all. With the ability to create user specific custom.css, shouldn't there be an advertising of services available which allow users make changes that suit their needs? On this page since yesterday there have been several options for displaying the watchlist, a shopping list like that, that people can choose from to place on top of the vanilla stylesheet is surely better than enforced changes that few are happy with? ] (]) 16:00, 11 May 2012 (UTC)
::::Yes. I think there are lessons to be learnt here. Highly-visible changes to functionality need greater sign-off by the community. I don't think needs to be a big-burden process. For example, if a change gets consensus then, before rolling it out, there could be a process to (a) advertise the change on watch lists, (b) link to a page describing the change (with reasoning, descriptions, screen shots, how to opt-out/opt-in/disable the change and, if possible, a staging area), (c) if there is no big fuss after two weeks then deploy the change.
::::I'm not saying what I described should be ''the process'' but some process of this kind may prevent the sudden "WTF!" reaction that this change brought. --] (]) 15:51, 11 May 2012 (UTC)
:::::Design by consensus doesn't work. You need someone with vision who understands how the site works at every level and is willing to implement small changes in a way that doesn't upset people. The problem here is that the person or people doing this are going about it in the wrong way. ] (]) 23:25, 11 May 2012 (UTC)
::::::Not talking about design by consensus. I talking about sign-off and process (i.e. going about it in the right way). --] (]) 01:23, 13 May 2012 (UTC)
===How does this work, anyways?===
I just cleared my cookies. It still knows what pages I visited (and didn't). Where is this (apparent) tracking-information stored and for how long? ] <sup>]</sup> 21:17, 11 May 2012 (UTC)
:I think it's stored in the server somewhere. Privacy questions related this have been brought up on meta ]. ] (]) 21:23, 11 May 2012 (UTC)
:: It is stored in the server. The watchlist table in the database has a field on each watchlist entry for when an email was last sent (or would have been sent, if you had that preference turned on) about changes to the watched page. Whenever an edit is made to a page, this field in all the watchlist entries pointing to the page is set if it doesn't already have a value. Then when you view the page (or view a diff against the current version of the page), it clears out that field for your watchlist entry. The watchlist-bolding feature uses this same field to determine which entries to mark. ]] 22:02, 11 May 2012 (UTC)
:::I'm just wondering by what order of magnitude this change has increased server load? --<small>] ]</small> 00:44, 12 May 2012 (UTC)
::::I'm not a developer, but this has been enabled in careful steps to measure the server load (which was the only reason it wasn't enabled on some Wikimedia wikis, unlike all the other wikis), and the worries seem to have been proven unsubstantiated. I think (database master for en.wiki), and there's no noticeable impact to any component, except a peak for a few minutes after the feature was enabled, to set it up in the database. ] 06:15, 12 May 2012 (UTC)
===Day 2 of this shit===
Perhaps the implementers of this change fail to understand consensus at a basic level, I am not waiting a month for them to revert a bold change that has been overwhelmingly rejected, simply because there is technical apparatus standing in the way of AnyUser reverting this shit.
#The discussion implementing this solicited in the range of 20 users' input . The discussion did not describe the effects on the user interface
#The snow grade level above indicating this should be opt-in only is a big clue, as is the depth of outrage at sudden and poorly implemented UI changes
#Why has the implementer of this not reverted their actions? ] (]) 23:47, 11 May 2012 (UTC)
::because they don't have to. There is consensus ''editing'', but not consensus developing; they can do whatever they want. ] <sup>]</sup> 00:18, 12 May 2012 (UTC)
:::Yes, I recall that being the status on development. But surely that means they can develop what they want, but we can still ignore it? We did manage to get ] disabled, eventually ;-) --<small>] ]</small> 00:50, 12 May 2012 (UTC)
:::If you read the they relied on a construction of consensus on wikipedia. ] (]) 02:24, 12 May 2012 (UTC)
*The problem is, Steve Walling has tried to revert Edokter, and it hasn't worked as expected. I can have a go at resetting it, but I can't figure out why Steve's reverts didn't work how he expected. Let me see if I can give it a go to turn it off entirely - with apologies for testing in a live system. ] (]) 01:13, 12 May 2012 (UTC)
::Something has worked as all the bolding is gone. Whether it stays this way or not I want to say thanks to you EotR and/or anyone else who gave my eyes a rest - even if it is only temporary. Thanks again. ] | ] 01:51, 12 May 2012 (UTC)
::It was me. Not sure if this is a permanent fix, but I've given a number of options at the bottom of the page for folks who want the markers back. ] (]) 02:12, 12 May 2012 (UTC)
:::Thank you for this action Elen. The concealment of process, and change structure, from the community was disturbing. While the option appears to be fruitful, if needing a lot of UI development, the process so far has not been optimal. It is good to see the Revert section of BRD applied properly to the process at last. Hopefully the discussion will improve the options related to the watchlist greatly. Again thank you. ] (]) 02:24, 12 May 2012 (UTC)
*Thank you for restoring the vanilla watchlist. Now let's talk about the changes item by item. --<small>] ]</small> 02:32, 12 May 2012 (UTC)
**Just to say I was happy when I refreshed my watchlist this morning and the dreadful bolding went away :) Thank you for your work on this. ] (]) 10:24, 12 May 2012 (UTC)
:: At least now people have a choice as to how to display their watchlist. Turning on the option wasn't the problem, it was that it by default altered the appearance, which people hadn't anticipated. In the future, I expect someone who is a better script kiddie than I will create a gadget that allows you to choose if you want neon stripes or blue fish. ] (]) 02:36, 12 May 2012 (UTC)
:::I probably wouldn't mind some blue fish on my GUI... ;-) --<small>] ]</small> 02:50, 12 May 2012 (UTC)
:::Thanks from me too, Elen. I'm much less likely to miss things this way. Now if we can get the colour of links we have visited to be a little more visibly different from that of links we have not visited, I'll be a happy camper. I'm one of those who looks at the colour of the diff link. ] (]) 04:18, 12 May 2012 (UTC)
:Great, now how can we get rid of the pointless "Mark all as read" button? No bolding means no need for that. ] (]) 04:37, 12 May 2012 (UTC)
::I made a script for the time being if you want. Add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to ]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 04:54, 12 May 2012 (UTC)</font>
*This is absurd, there's no consensus to disable this feature for everyone. The discussion about this has been opened for a short while and has not reached any conclusion: as was repeated by many, it's a very bad idea to change this back and forth before any stable conclsion, it confuses users a lot. Besides, even if you considered the ] above to be a valid consensus (and it isn't), this change does not make is an "opt-in" feature, which as pointed out by the proposers themselves would require some coding; the complete disabling of the feature was supported by a very tiny minority. <br />More importantly, as Risker said, it's not hard to see that '''', because many said so in this page although users ''liking'' something usually don't come here to comment, unlike people wanting to complain. ] 06:25, 12 May 2012 (UTC)
**It's not absurd. The burden of consensus lies in making the change to begin with. There doesn't actually need to be consensus to roll it back when there was no demonstrated consensus to implement it in the first place. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:26, 12 May 2012 (UTC)</font>
**:There ''was'' consensus to enable the feature, and there's no consensus to disable it (in fact no complete disabling has been asked to the devs). There's no consensus for any particular style other than the default one, which should be restored until a proper consensus has been found on an alternative. --] 13:07, 12 May 2012 (UTC)
***:A good many people would seem to disagree with you that there was adequate consensus, and that said consensus was for the change the way it's actually been implemented. The discussion wasn't very widely advertised nor did it get broad participation. Many of the support !votes it did get were on the condition that a preference be added for it too. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 13:13, 12 May 2012 (UTC)</font>
****My bolding seems to be gone, thankfully, but I would like to point out I never heard of this so-called community discussion. This was a hijacking by a minority. In the future, everyone should hear about this sort of discussion...] (]) 17:56, 12 May 2012 (UTC)
=== Watchlist styles ===
OK, at great expense and enormous loss of life, I have made the bolding effect invisible in the common css as a temporary measure.
*If you want no bolding but small green stars against the unwatched items add this to ] (just click, add and save)
<code>/* Styling for update markers on watchlist and history pages */
*If you want a dotted line under the unread ones, add this
.mw-watched {
border-bottom: 1px dotted #999;
font-weight: normal !important;
}
*If you want the unread in italic , add
.mw-watched {
font-style: italic !important;
}
If you want anything else, put in a request.] (]) 02:08, 12 May 2012 (UTC)
:Je veux ton amour et je veux ta revanche.<small> But seriously, thanks.</small> ] (]) 02:13, 12 May 2012 (UTC)
:Elen, you're a beautiful person. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 02:17, 12 May 2012 (UTC)</font>
:::I've grown fond of the bolding. When I add the code snipit into my common.css, the bolding doesn't return. ] (]) 02:26, 12 May 2012 (UTC)
::::I can't get bolding to work either. Looks like any bold attempt is being overridden, I guess by common.css? Other styles do work. I'm not complaining though. Considering the response I think it's better reverted anyway. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 02:44, 12 May 2012 (UTC)</font>
::::: Most odd. I can get it in italics (see code above) but not bold. I'll see if I can get something that looks similar to the bold. ] (]) 03:00, 12 May 2012 (UTC)
::::::Everything works fine for me although I placed my own style in before this thread was opened. Goto ] and copy the code from there. It bolds and stars at the same time making it actually look good in my opinion. After every technical change made to .js or .css config files, you need to purge your cache.—] <sup>]</sup><sub style="margin-left:-3.7ex"><font color=red face=arnprior>Offline</font></sub> 03:17, 12 May 2012 (UTC)
Now we're cooking on gas. Figured out what the problem was, thanks Cyberpower
*To get the bold back, use
span.updatedmarker {
background-color: transparent; color: #006400;
}
strong.mw-watched a {
font-weight: bold;
}
*And for a really jazzy experience, try
strong.mw-watched a {text-shadow:1px 1px #000080;}
(won't work in Internet Exploder) ] (]) 03:36, 12 May 2012 (UTC)
:Glad I could help.—] <sup>]</sup><sub style="margin-left:-3.7ex"><font color=red face=arnprior>Offline</font></sub> 03:46, 12 May 2012 (UTC)
:Exalt! Most useful. Many, many thanks. ] <sub>]</sub><sup>]</sup> 04:02, 12 May 2012 (UTC)
:If you want to hide the "Mark all as read" button too, add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to ]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 05:05, 12 May 2012 (UTC)</font>
:::Of course, you could also just use plain CSS to remove the button: <code>form#mw-watchlist-resetbutton { display: none }</code>. ] (]) 11:16, 12 May 2012 (UTC)
::Thank you Elen and Cyberpower. I hated the bold at first, but now find it extremely useful. Nice to have it back. Equazcion, I could never get your new category script to work, but found your LiveDiffLink.js script to be very convenient and now I get to add your "Mark all" script. ] (]) 05:20, 12 May 2012 (UTC)
:::«'''I hated the bold at first, but now find it extremely useful'''» (bold added ;) ). Yeah, such a common and obvious thing. Too bad that the bold has been disabled for everyone and now the vast majority of users who would like it will never discover it, only because a tiny minority complained about it being unable to wait for a day to get used to it (as all MediaWiki users already are). ] 06:37, 12 May 2012 (UTC)
::::Yes, as someone experienced in change management I have to say that the reactions here should have been expected, and not over-reacted to themselves. Very shallow behaviour on both sides. Sad. It was a good change. ] (]) 07:02, 12 May 2012 (UTC)
:::::Many of us are experienced there too, as can be especially said for Elen of the Roads. As much as a negative reaction could've been expected, not every negative reaction is merely par for the course and should be brushed off as such. This one was more warranted due to the flawed development cycle it resulted from. Firstly, the change wasn't discussed (or was barely) -- and even though that usually isn't something users of a site are brought in on, it is something that '''has to''' happen here; the developers are not supposed to have the power to decide on changes merely due to their technical ability to implement them. The change was also not tested on a pool of this project's audience in beta fashion, and was instead tested live, where it was also rapidly tweaked several times, again with no testing. This rollback isn't a judgment of the feature or a mere reaction to outcry, but I would say in part it's a demonstration of the fact that Misplaced Pages is not Facebook. We're a community that discusses and decides on interface changes ourselves, rather than having them thrust upon us. When a more proper discussion and test occurs, or it is simply provided as an extra opt-in feature (or at the very ''least'' an opt-out, as even ''that'' wasn't provided), a less contentious rollout of this feature (or one like it) can then occur. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:10, 12 May 2012 (UTC)</font>
* Now, is there any way to get in the history pages unread from the last visit back on a green background, like it it done on Commons by default?--] (]) 07:22, 12 May 2012 (UTC)
** I think Elen's CSS code above is supposed to remove those too, but I updated my script to remove them as well: add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to ] if you want to try it out. It also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:20, 12 May 2012 (UTC)</font>
**: Actually, I do not want to remove them (an Ellen's code does not remove them), I want to make them stronger (like it was yeaterday for a couple of hours - black text on green background). I am on the side which likes the new appearance.--] (]) 08:24, 12 May 2012 (UTC)
Thanks for all the code guys, really appreciated. Could someone please tell me how to remove "updated since my last visit" from when I'm looking at the history of a page (I'm on vector)? ] (]) 07:38, 12 May 2012 (UTC)
:(I meant to reply to this comment originally instead of the one above) You can add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to ]. This also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:20, 12 May 2012 (UTC)</font>
::Yes, I am using that to get of the button (thanks). But what I'm asking about is when I look at the history of a page I am seeing "updated since my last visit" in green next to edits that have occurred since I last looked at the page; how can I get rid of that? ] (]) 08:53, 12 May 2012 (UTC)
:::Yes, I updated my script since I first advertised it here -- it should now be removing those green notices on history pages too. Try hitting Ctrl-F5 to make sure the update is in effect. Let me know on my talk page if it's still not working. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:57, 12 May 2012 (UTC)</font>
::::Yep, just had to purge my cache, thanks. ] (]) 09:27, 12 May 2012 (UTC)
:Note that I also just updated the script so that if the bolding is ever re-enabled by default, the script will automatically disable it without any CSS needed. See ]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 11:39, 12 May 2012 (UTC)</font>
This will give a light grey background to unread items:
<syntaxhighlight lang="css">
.mw-watched {
background-color:#e0e0e0;
font-weight: normal !important;
}</syntaxhighlight>
—] (]) 19:16, 12 May 2012 (UTC)
::Cool. We need to update ] with all these options (perhaps not the text shadow one!!) with screenshots, so that people realise they have all these choices. ] (]) 19:24, 12 May 2012 (UTC)
:::Actually, that's only one part of the issue. Fact is that many users are not technically comfortable in using all these scripts (and since they're on individual user pages, it is impossible to ensure that they are all updated properly - which is a major problem). As well, even if people are comfortable in using them, they may have technical reasons why they are suboptimal. I've wound up disabling almost every script I ever put into my .css because it did not function properly due to some interaction with (a) other scripts or (b) something in a mandatory hardware or software setting. Gadgets work okay, most of the time. So they should either be gadgets (which are usually maintained and kept compatible with upgrades), or standard. <p>In the case of this particular change, I believe that the main reason there are so many complaints is that so many of the editors on this project are using skins other than Vector - in fact, I think I saw a stat somewhere that said over 70% of users who were editing pre-Vector continue to use Monobook or some other skin. This change looks fantastic in Vector, but is less pleasant on Monobook (the bolding goes beyond making the entries stand out, and can make it difficult to pick out the unbolded entries). Probably what needed to be done here was tweaking of the non-Vector skins - I note there isn't much discussion of what skin/OS/browser was being used that might relate to this issue. ] (]) 15:41, 13 May 2012 (UTC)
::::Good point about different skins. Each skin can of course have its own sitewide default. I did suggest over in The Other Place This Discussion Is Also Happening (For No Obvious Reason) that we make a gadget to apply the styling, so everyone can do what they want, and then collect stats on user choices to inform the default. If we did that we should be able to collect data split by skin, so different skins can have different defaults. On the other hand, if we do Elen's survey, that's a ''lot'' of screenshots (different options for different skins)... ] <sup>]</sup> 16:45, 13 May 2012 (UTC)
:::: Good point. Should add that to the survey. I use modern, and it looked bloody awful - exactly the same as Truthkeeper's description of a migraine attack. So an alternative would be to check in each skin and alter the css to get a toned down effect. I do think there is a style out there that is sufficiently unobtrusive for most people not to be bothered if it is on or off - we just have to find it. ] (]) 18:38, 13 May 2012 (UTC)
:Hey, I have no clue how I ended up here or how I managed to understand any of this, but the green star bolding works now! Thanks cyberpower! <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) 04:38, 19 May 2012 (UTC)</span></small><!-- Template:Unsigned -->
=== So how about those of us who actually want this? ===
I personally loved the bolded titles for recent changes, and in my opinion, given how minor of a change it was, it should not have prompted such vexatious responses. Can this be made into an option in the watchlist tab of user preferences? - ''']''' <sup>]</sup> <sub>]</sub> 05:11, 12 May 2012 (UTC)
* I second that! ] (]) 05:13, 12 May 2012 (UTC)
* Me too! ] <small>(])</small> 07:23, 12 May 2012 (UTC)
* Like the new diff display, this took me about a day to adjust to, and now it's gone. I would like it back! <span style="background:#006B54; padding:2px;" >'''] ]'''</span> 07:32, 12 May 2012 (UTC)
::The ability to highlight the changes is still there. See above, or the page below, for plenty of ways to customise it to suit your eyes and watchlist. If you need a hand, give me a ping. I'm hoping we can get some kind of gadget out of this that just allows people to pick from options, which is what the original discussion actually wanted. --] (]) 12:54, 12 May 2012 (UTC)
:::I don't want to ping anybody. I liked the change. I can never find options and gadgets on this far too complicated site anyway. Don't make this a site for nerds. Make it friendly to newbies. ] (]) 08:25, 13 May 2012 (UTC)
:::: The style used seems to have caused a lot of people to have accessibility difficulties. Part of that seems to be that the entries on the watchlist are on a tight linespacing, and part that the colours are very bright. I'm betting there's a style out there that most people would find non-intrusive enough to accept as the default, but it'll be less bright. It's unfortunate that there isn't a simple way to switch it on/off, as this would end all these arguments, but there isn't. It's either on for the whole wiki or off for the whole wiki. --] (]) 14:58, 13 May 2012 (UTC)
:::::How about ] as a default (for the watchlist part only). Others can remove or adjust. The lime underline is minimally visible in the line spacing and doesn't seem to have any reducing effects on that (even the grey one seems fine to me). I think new users will never know about it if we make it an opt in feature. --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 15:27, 13 May 2012 (UTC)
::::::: I'm collecting options. Certainly add that to ] ] (]) 17:44, 13 May 2012 (UTC)
*Me too! Those who actually liked the change will be more likely to by shy and reluctant to go around like you to see what had happened, why it came to their watchlist and why it disappeared again. I want it back, I want it back (without reading through tons and tons of mostly negative comments). It was saving me lot of time (the thing I have the least of) '']'' ''']''' 20:38, 17 May 2012 (UTC)
=== Misplaced Pages:Customizing watchlists ===
A new page to try and collect the ever-shifting sands of this styling thing in one place: ]. Contains instructions to disable, enable, and use alternative styles. ] <sup>]</sup> 10:26, 12 May 2012 (UTC)
=== Next steps ===
Appreciate input as to next steps with communicating this, moving to a more permanent outcome etc. --] (]) 13:57, 12 May 2012 (UTC)
::Communication suggestion now posted at ]. Comments, brickbats etc here or at ]. We have to put out something to let users know that the facility is available should they wish to use it. At the same time, some of the folks who took part in the very first discussion are still of the opinion that it should just be switched on as most users either like it or would get used to it, so we need to find out if that is the case as well. --] (]) 12:13, 13 May 2012 (UTC)
:::Final version with images now done. I'll leave it 24hrs for comments (I notice people have started to fill it in), then move it out of userspace and ask for a watchlist notice, unless anyone objects. --] (]) 00:30, 14 May 2012 (UTC)
=== Real life has intruded ===
:::: I'm having r/l time issues. Could someone ship this out into rfc space and list it to see if we can have a watchlist notice. So we don't lose any more time. ] (]) 21:04, 15 May 2012 (UTC)
===Fake Edit Summaries===
A request was made above for a way to disable the fake edit summaries that came with this change. I for one would really like a way to do so, as its extremely annoying when you have an edit occur with no summary, and then look to see what the justification for the edit was, only to find the stupid message informing you the change occured since you last looked, which as your looking is REALLY OBVIOUS. So is there a way to get rid of them? ]] 18:35, 13 May 2012 (UTC)
:You mean the green "changed since your last.." message. I do believe there is a way to make it invisible as a js hack. --] (]) 20:16, 13 May 2012 (UTC)
::That is what I'm referring to, do you know if anyone has one working? ]] 01:42, 14 May 2012 (UTC)
::Add this to ] (applies to all skins) or ] (your current skin):
span.updatedmarker{display:none;}
::] (]) 01:43, 14 May 2012 (UTC)
===Overriding to plain text===
{{unanswered}}
I think the turning off of bold text has something to do with overriding the js scripts which no longer bold the specific links. Is there a way around that? Shouldn't this be fixed? --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 01:32, 14 May 2012 (UTC)
:I think you need to explain the question better. Bold text where. What links. If you mean watchlist links, the whole (lengthy) explaination is either above or in the archive. --] (]) 21:05, 15 May 2012 (UTC)
::I'm using ] which notifies of changes on the watchlist while being on other pages as well as bolds the lines that appear after last reload of watchlist. After the the watchlist changes were enabled (which bold the unvisited pages rather than just the newly loaded ones) and the was set to normal text as default... I chose to use a subtle underscore version of it so that the new changes after reload can still be bold and do not confuse. The issue is that the new lines are still getting a bold font as per the script minus the page titles in the watchlist which if unvisited do not get bold even though the js script is set to bold the full line. --<span style="text-shadow:#396 0.2em 0.2em 0.5em; class=texhtml">] (])</span> 21:44, 15 May 2012 (UTC)
===Restore watchlist bolding after the new change to Common.css on May 17===
Is this the right place, or has a whole page somewhere been devoted to this topic? Anyway I woke to find that my bolding had gone away. This was a valuable tool. It didn't come back even when I inserted the necessary material into ]. Help; I am much more easily confused going through my excessively long recent changes list without the system telling me which of the hundreds of changes I've already seen. ] (]) 09:50, 17 May 2012 (UTC)
:Fixed it for you (you may need to ]). See ] below for details on why the old change stopped working. ]] 16:14, 17 May 2012 (UTC)
::Anomie's latest change to Common.css was . Anomie had previously explained what to do at ]. I made to my vector.css and it restored the bolding as promised. ] (]) 16:28, 17 May 2012 (UTC)
:::Thank you kindly. Returned tired and sunburnt from pedalling a daylong, 30 mile, umm 50 km photo trip, and felt much better to turn on the home computer and see a friendly face of watchlist. Hope a simple opt-out button in Preferences can soon do such things. And for that matter, in the list of diffs, a similar scheme would be better than words saying a page has been "updated since last visit". ] (]) 23:51, 17 May 2012 (UTC)
===What's going on? It just doesn't work===
{{Tracked|36956}}Whether we like the bolding in the watchlist or not, what we currently have just doesn't seem to work. My watchlist states "Pages which have been changed since you last visited them are shown in bold", and yet nothing is bold. There is also a "Mark all pages visited" button, which seems to have absolutely no effect (and in any case, it's unlikely that there'd be any pages on my watchlist which I haven't ever visited). These "features" should either be fixed or removed. ] (]) 07:41, 18 May 2012 (UTC)
:The bolding itself was de-activated temporarily due to backlash while a more permanent solution is being considered. See ] for instructions on removing the other remnants of this feature for yourself, or re-enabling the bolding, whichever you prefer. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:15, 18 May 2012 (UTC)</font>
::Being able to customise stuff is all well and good if that's what you want, and if you know what to do. But the default uncustomised state should at least make sense, without non-functional buttons and irrelevant messages. I shouldn't have to "remove the remnants". The button and message should only appear if they work, whether this be by default or following customisation. ] (]) 09:43, 18 May 2012 (UTC)
:::We are in complete agreement. The developers responsible for these changes were either unable or unwilling (it's unclear) to undo them. This temporary override was initiated by Misplaced Pages's administrators, who have more limited access, as a last resort. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 09:58, 18 May 2012 (UTC)</font>
::::I've filed a bug for this. I don't think this was tracked otherwise, so there is no chance to get it fixed. — <span style="color:#d30000; text-decoration:inherit">☠</span>]<span style="color:#d30000; text-decoration:inherit">☢</span>(])<span style="color:#d30000; text-decoration:inherit">☣</span> 15:29, 18 May 2012 (UTC)
:::::I use ] and it works fine with me. With the bolding in the watchlist, no message and no button. ] <small>(])</small> 06:17, 19 May 2012 (UTC)
::::::Good for you Oda, but you're missing my point. Most users won't want or know how to use css code. It should just be correct, without the need to resort to this kind of workaround. ] (]) 08:18, 19 May 2012 (UTC)
== Problems in categorization of BLPPRODs "by days left", any template magic ==
The ] template attempts to sort the articles it finds into ], which sounds tasty.
But it's never worked correctly or that usefully at that. I kinda get why, but I'm too much of a template newbie to necessarily explain it well--roughly speaking the "number of days left" is only recomputed when the article is actually modified. Cache purge doesn't do it. So there are "expired" articles marked with 8 days left. While there's no hurry, it's a problem for people looking through the BLPPROD pile looking for things to put effort into, an accurate days left count would be a significant benefit to that triage process.
The relevant code is at ] via ] for interested parties.
So, clever people, workarounds? Ideas? --]] 06:46, 15 May 2012 (UTC)
: Meh, maybe the real issue is ] --]] 07:16, 15 May 2012 (UTC)
:: It certainly seems unwise to rely on articles automatically being re-categorised each day.
:: Maintenance templates are usually sub-categorised according to the month of transclusion, which results in a steady but slow increase in sub-categories.
:: Some possible workarounds:
::# You could similarly sub-categorise according to the date of nomination, but that would create numerous sub-categories (a new one every day).
::# Instead of using the initial digit (in the category sortorder) to indicate the number of days outstanding, perhaps you could extend this to an initial letter to indicate the day of the month that the article was nominated (eg 1 to 9 for the 1st to the 9th, then A to V for the 10th to the 31st).
::# As a compromise between the above options, you could create 31 sub-categories, and have rolling sub-categories for the day of the month of nomination (but not sub-categorise the month or year).
:: — ] (]) 08:26, 15 May 2012 (UTC)
:::Or a bot could go through the articles daily and make a ] if they are not categorized correctly. Null edits update category pages. Purges don't. ] (]) 13:24, 15 May 2012 (UTC)
: Thanks for the brainstorming, folks. The thing that concerns me about the bot is the effect on article history. A moderate fraction of articles do survive the BLPPOD processW, it'd be a shame to leave ten null edits clogging the histories there. Perhaps every other day would be a better compromise.
: Subcategory by, say, nomination date or expiration date has some real advantages, and the cleanup of empty categories strikes me as easy bot-based maintenance.
: Anyway, the brainstorming is much appreciated, folks. Thanks! --]] 20:57, 15 May 2012 (UTC)
::A ] is not shown in the page history or elsewhere. ] (]) 22:06, 15 May 2012 (UTC)
::: I did not know that, that pretty much does seem potentially practical. --]] 08:51, 17 May 2012 (UTC)
:::: I tihnk I'm going to follow up and attempt a BRFA on the idea. Thanks! --]] 19:18, 19 May 2012 (UTC)
== Major problems with new Misplaced Pages mobile site - Please revert back ==
Someone posted this in another section and didn't re-post this here, so I am doing it for them. I am also having major problems on the new mobile site on my Android phone that mirror these and make it nearly unusable. It worked fine before!!
----
The new Misplaced Pages mobile website is really bad. It has many problems when viewed on Android mobiles:
If you scrolll down while the page is loading, it scrolls back up to the beginning after page loads, unexpectedly. Why does it forcefully scroll the page when the user didn't request it?
The arrow button (in each section for "Show more content") is hard to press, because it's too small. The previous version had a proper "Show" button which was bigger.
Sometimes the full content doesn't appear when you press the arrow button. It might show only the first half of a paragraph, for example.
When you use the arrow button a few times, it's virtually impossible to escape out of the page with the Back button. You have to press it so many times, and it's difficult to tell what's going on.
Using an arrow button is not good for usability anyway, because you can't tell what it's supposed to do.
The link "Jump back a section" usually does nothing.
Please could someone revert it back to the old mobile version ASAP, which didn't have any of these problems.
----
Adding to this: when you press the arrow or text to expand a section, it takes forever to open. You aren't sure if anything is happening, so often you will press it again, only to have it quickly open and then re-close because the re-close operation registers nearly immediately.
Really, it's terrible. Even my girlfriend, who is not technical, was using it the other day and mentioned it was different and wasn't working correctly. <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) 14:19, 15 May 2012 (UTC)</span></small><!-- Template:Unsigned -->
* Sorry about the problems with the recent deployment of the mobile site. A lot of unexpected problems crept in. The fixes to most of the problems should be deployed today. --] (]) 17:52, 15 May 2012 (UTC)
::*Yeah I also seem to be having some problems, even though I use an iPod Touch. I'm also probably the only person who browses Mobile Misplaced Pages on a computer though. Anyway, aside from the fact that sometimes the whole page doesn't load (just a few sections), another problem I have is if I try to open a new tab, when I go back to the old tab, it goes back to the top of the section! Very, very, very annoying. ] <sup>]]]]</sup> 01:28, 16 May 2012 (UTC)
::: We haven't seen any more of these issues creep up after last weeks pushes. Let us know if you see any more. ] (]) 22:07, 21 May 2012 (UTC)
== REVISIONID ==
Sorry if this is in the wrong place. I recently made a request at ] to provide a link to the diff when a cleanup tag was applied. It was suggested the <nowiki>{{REVISIONID}}</nowiki> magic word would accomplish this, but it doesn't seem to work. Maybe someone here knows a bit more about how to do this or can point me in the right direction. There might even be another way to accomplish the same thing. ] ] 01:04, 16 May 2012 (UTC)
:I hope you realise that it only works after the page is saved, and updates after the page is edited each time, so you might want to substitute it. <b><span style="border:2px solid;font-variant:small-caps">]]</span></b> 02:02, 16 May 2012 (UTC)
::No I didn't. That won't really work as cleanup templates aren't substituted. Is there another way to link to the diff that added the template? ] ] 00:03, 17 May 2012 (UTC)
:::Can't one do something like <nowiki>{{tag|1=}}</nowiki>? Something more refined, obviously. But I still think it's doable. ] (]) 18:56, 17 May 2012 (UTC)
::::Yes this could have been done, unfortunately I am not allowed to do it. ''] ]'', <small>01:22, 24 May 2012 (UTC).</small><br />
:I was trying to do something similar yesterday: creating a template like for use like ? But didn't work, because the magic word returned an empty string (although I think in a previous MW version it used to return the id of the revision just saved). ] 14:56, 24 May 2012 (UTC)
== Template parsing ==
Has anyone created a function that can parse wikitext and return a template with its parameters? Alternatively, does an API query exist for that?
<pre>
{
"Template:X3":
{
"bla{h":"Hello!"
}
}
Something like this, taken from https://en.wikipedia.org/search/?title=Misplaced Pages:Sandbox&diff=prev&oldid=492475629
</pre>
→<span style="font-family:Euclid Fraktur">]]].</span> 04:16, 17 May 2012 (UTC)
:You should be able to do that with Regex pretty easily I imagine. Could you give us a little more detailed description of what you are trying to do. It could just be me and my tired 1AM brain but its kinda unclear from the description what your trying to do. ] (]) 04:27, 17 May 2012 (UTC)
::What I'm trying to do is capture a template from wikitext, that looks something like <tt><nowiki>{{Foo|bar={{baz|b{oo=far}}}}</nowiki></tt> Regex cannot be used for this purpose, because there are nested templates and uneven braces. So that leads to my question, is there already a method of extracting the template? →<span style="font-family:Euclid Fraktur">]]].</span> 05:19, 17 May 2012 (UTC)
Using regex is horrible, '''don't do it'''. It's like drugs; seems like a great idea at the time, but in the long run you end up with more problems than its worth. Even simple things like a link in the template (e.g. <nowiki>{{foo|]}}</nowiki>), can break the regex unless it is very well written. Assuming you're using PHP, here is my hack of a solution to parsing templates:
{{collapse top|Collapsed long code snippet, click "show" to the right}}
<syntaxhighlight lang="php">
<?php
class template implements Iterator {
private $name;
private $params;
private $pos;
public function __construct ($name, $params) {
$this->name = $name;
if (empty($params)) {
$this->params = array();
} else {
foreach ($params as $key => $value) {
$this->params = array($key,$value);
}
}
$this->pos = 0;
}
public function getByKey ($key) {
if (!isset($this->params))
return false;
return $this->params;
}
public function __toString () {
return $this->name;
}
public function current () {
return $this->params;
}
public function key () {
return $this->params;
}
public function valid () {
if (isset($this->params))
return true;
return false;
}
public function rewind () {
$this->pos = 0;
}
public function next () {
$this->pos++;
}
}
// Look, don't even bother and read this, just accept that it parses
// $text, and returns an array of templates.
// Yes, it is horrible in every possible way; but it works.
$templates = parsetemplates($wikicode); // Returns an array of template objects
foreach ($templates as $template) {
echo "$template\n"; // The name of the template
foreach ($template as $argument => $value) {
echo "\t\"$argument\" => \"$value\"\n";
}
}
</syntaxhighlight>
I wrote parsetemplates() one night, very late when I was frustated by this exact problem. It's a horrible function, but, it works for all the wikicode i've encountered so far. That said, try not to find anything that breaks it ;) --] 07:15, 17 May 2012 (UTC)
:That's a fun piece of code. Haven't tested it at all, but it looks like it doesn't handle template parameters (<tt><nowiki>{{{param_name|default}}}</nowiki></tt>, etc), although I guess that's not a common sight on article pages. More generally I think it won't like multiple sets of braces put together; things like <tt><nowiki>{{template|foo={{bar}}}}</nowiki></tt> or especially <tt><nowiki>{{{{WorkOutWhichTemplateToCall}}|foo=bar}}</nowiki></tt> will make it go in or out too many levels. Also image captions can contain links: <tt><nowiki>] which confuses things]]</nowiki></tt>. But a valiant effort nonetheless! <tt>:D</tt> ]‑] 14:03, 17 May 2012 (UTC)
:::It deliberately doesn't deal with template parameters, it's just way too ugly (and lets face it, if you're trying to parse actual templates, you're going to need something beefier than this, that can handle all the parser functions etc). <s>Image captions with links it can deal with</s>, and <nowiki>{{template|foo={{bar}}}}</nowiki> is also fine (I actually wrote it specifically for that purpose, so that I could parse templates that have templates as arguments). However, you are right <nowiki>{{{{WorkOutWhichTemplateToCall}}|foo=bar}}</nowiki> doesn't work. Damn. --] 16:30, 17 May 2012 (UTC)
::::Actually, strike that about the images with captions. This version can't deal with them (although your example does work, this code <nowiki>] which confuses things|right]]</nowiki> doesn't). I have a different version that does actually deal with that problem, however it breaks with other things, and is not ready for primetime yet. --] 16:50, 17 May 2012 (UTC)
: I have similar code (but in ]) at ]. My version uses a callback architecture, so giving it <code><nowiki>{{foo|{{bar}}}}</nowiki></code> will call the callback for <code>bar</code> and then for <code>foo</code>, and the callback can return new wikitext to directly replace the template if desired. It also tries to handle {{tag|nowiki|o}}, {{tag|ref|o}}, and so on in a reasonable manner. ]] 01:52, 18 May 2012 (UTC)
Thank you for your ingenious solutions to this problem. →<span style="font-family:Euclid Fraktur">]]].</span> 03:37, 19 May 2012 (UTC)
There is a solution for this in PerlFAQ, number 6, I think. ''] ]'', <small>14:29, 24 May 2012 (UTC).</small><br />
== Cache of ] ==
Seems ] keeps defaulting back to a version of the page over 7 days old. Problem comes when viewing as an anon from an external website (see , for example). I have purged the article numerous times over the last week. Any ideas? ] (]) 19:05, 17 May 2012 (UTC)
:What exactly is different on your end (as an anon)? I checked it and don't see anything. In general, however, anonymous users use cached versions of pages but it normally isn't more than just a few edits behind the live version. ] (]) 19:14, 17 May 2012 (UTC)
:: when not signed in and when directed from external site. ] (]) 21:14, 17 May 2012 (UTC)
:::The bottom of pages say "This page was last modified on ...". That part is missing in your screenshot but it does look like an old version. If ] doesn't help then it may be your ISP. See ]. Try adding a '?' to the url as in ] (]) 22:15, 17 May 2012 (UTC)
::::The page says "This page was last modified on 1 May 2012 at 10:22." The article is now 18 days out of date! If you can see the updated page as an anon, then you must be right that it is my ISP (which is ] in the UK). Any ideas on how to rectify for good, rather than adapting the url? ] (]) 13:40, 18 May 2012 (UTC)
:::::It seems to be only one day outdated for me, as logged in I see 18 May, yet logged out I see 17 May. <b><span style="border:2px solid;font-variant:small-caps">]]</span></b> 03:03, 19 May 2012 (UTC)
::::::Thanks Hazard-SJ. I do not know what is going on with BT's cache. "BT is the largest ISP in the UK with currently 4,600,000 broadband users." This does not seem very good for a number of potential Misplaced Pages readers. ] (]) 10:01, 19 May 2012 (UTC)
== Hamletbot considered desirable ==
Reading ], I noticed
that it described Moose Bay as a ] instead of a ]. After
,
I decided to see get an idea of how many ''other'' hamlets have this problem, in case it was
a small enough number that I could reasonably fix them all.
Well, according to "What links here", there are approximately 4,500 pages that link to '']''.
At least 300 of these appear to be pages for places, half of them in the province of
Saskatchewan and half in various other states, provinces, and countries. I therefore suggest
that practically all of these are talking about hamlets and not ''Hamlet''.
But 300+ pages is too many to conveniently fix by hand. So I had another idea: links intending to
point to the play will almost certainly spell it '''<code><nowiki>]</nowiki></code>''', whereas those
intending to talk about a hamlet will almost certainly spell it '''<code><nowiki>]</nowiki></code>'''.
Therefore if someone would please write a bot to scan through all links to '']'', find the ones
spelled <code><nowiki>]</nowiki></code>, and just change those into
<code><nowiki>]</nowiki></code>, it might introduce a few errors but I'm sure
it would be a big improvement on the current situation.
Whether this bot should be a once-only thing or whether it should run regularly in case someone
generates a bunch more pages about hamlets in some state, province, or country is a decision I'll
happily leave to others. Likewise the question of what degree of human checking is appropriate,
and of whether there are any other words/names that need similar treatment.
But I do say that it should be written and should be run once on "Hamlet", anyway.
--] (]) 08:09, 19 May 2012 (UTC)
:I've started to go through the pages manually - most of them are fairly easy to spot so I haven't had to look at each and every article. But it's a bigger job than I'd anticipated, and it won't get finished immediately. A bot would certainly help, but it could end up introducing new errors, e.g. linking to ] when the correct link would be ]. ] (]) 12:49, 19 May 2012 (UTC)
:: I found that there are 122 articles in the ] that contain links to ]. I think it's pretty safe to assume without hand-checking that all of these should link to ] so I'm correcting them. <s>I suspect there may be one or two other cases like this.</s> That category appears to be unique; any remaining errors will have to be detected some other way. --] (] Russ) 13:21, 19 May 2012 (UTC)
Should the links be fixed, though, or perhaps the pages renamed? Why is a play more important than the thing the guy the play is named after is named after, when that is a general term? -— ] ] 18:25, 19 May 2012 (UTC)
: So you'd rather break 4,500 links than fix 200 of them? OK, that was a rhetorical question. Anyway, the question isn't what's "more important"; the question is whether one of these is the ] for the ambiguous term "hamlet." --] (] Russ) 20:18, 19 May 2012 (UTC)
::I've now gone through the entire list of articles that link to Hamlet and fixed about 250 or so. I think that between us R'n'B and I have probably fixed the bulk of this problem, although undoubtedly some will still remain incorrect. There are also quite a few like "X was an actor who played ]" where the link is to the page for the play - arguably it should link to the character, ]. However, I guess that this isn't a real problem because at least they link to something relevant. ] (]) 16:02, 20 May 2012 (UTC)
::I guess we have different views of long-term significance. -— ] ] 17:02, 20 May 2012 (UTC)
::: Maybe, but in the end we should both be guided by consensus. If you think the current naming is wrong, feel free to ] of the articles about the play and about the community. (I presume we both agree that the fish is not in contention.) However, if there is a consensus favoring such moves, someone will need to take the responsibility of fixing all affected links either before or contemporaneously with the moves. --] (] Russ) 17:08, 20 May 2012 (UTC)
::::Hamlet the character is only notable because of the play. Arguably, the type of place is more important than the play, but I would disagree - at best they are of equal importance. However, we need to take into account the collateral damage of changing the scope of the ] article, and this would be huge if it changed from anything but the play. It's just not worth it. ] (]) 17:21, 20 May 2012 (UTC)
== "This Is A Tool Icon" on the with Beacon Hill article ==
{{Tracked|36968}}
at the ] Article (http://en.wikipedia.org/Beacon_Hill), there's a cross halfway down on the right hand side with an X, labled "This Is A Tool Icon", that floats with page scrolling.
Looking at the edit box, I could not see what was causing it
tested on Firefox 12 and Internet Explorer 10
] (]) 15:19, 19 May 2012 (UTC)
: See also ]. From the comments there, I'd guess it has something to do with development of the "]" (the "mwe-pt-toolbar" and other tags mentioned there come from the ] extension). ]] 16:29, 19 May 2012 (UTC)
::I've turned off the extension for now. ] (]) 18:47, 19 May 2012 (UTC)
== Monobook ==
Morning. My monobook scripts used to give me a nice citation button, where once you inserted a URL it would auto-populate the reference. This seems to have vanished. Anyone up to kindly perusing my script here and working out what's wrong with it? 'Caure I'm a dunderhead. ] <sub>]</sub> 09:02, 20 May 2012 (UTC)
<div class="NavHead" style="font-weight:{{{fw1|bold}}}; background-color: {{{bg1|Turquoise}}}; text-align: {{{ta1|center}}};">This is what I have. ] <sub>]</sub> 08:34, 18 May 2012 (UTC) </div>
:RefToolbar is now enabled by default. Remove <code>importScript('User:Mr.Z-man/refToolbar.js');</code> and reload per the instructions at the top of your JS page. ---'''''— ]<span style="color:darkblue"> '''''</span><sup>]</sup> 14:16, 20 May 2012 (UTC)
:::Ah, that's back again - but still not auto-populating? ] <sub>]</sub> 20:38, 20 May 2012 (UTC)
== Date sort screwing up ==
{{tracked|36991}}
The table below is copied from ]:
{|class="wikitable sortable"
|-
!Date sort mode
|-
|07 Apr 2001
|-
|16 Apr 2007
|-
|16 Mar 2007
|-
|05 Apr 2007
|-
|04 May 2007
|-
|18 Mar 2007
|-
|27 Mar 2007
|-
|20 Aug 2006
|-
|22 Jul 2006
|}
|}
Notice that Apr 2007 gets sandwiched between two Mar 2007 entries upon sorting. Now, I'm honestly not sure if this table is supposed to be an example of a non-working setup or what, because frankly, the help section on date sorting is so completely fucked that it hurts my brain to imagine the individual that considered it helpful. I plan to nuke it once this is clarified to me. How exactly does one make a table sortable by date? '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 13:44, 20 May 2012 (UTC)</font>
:Thanks for posting this here, Equazcion. I posted a Q over at the Help Desk because I couldn't really figure out the explanations either. Hopefully someone'll know! :) <span style="13px Sylfaen;background-color:#000000;padding:0 3px 0 3px;">]</span> 15:12, 20 May 2012 (UTC)
::Try something like <code><span style="display:none;"><nowiki>{{#time:Y-m-d|{{{date1}}} }}</nowiki></span><nowiki>{{{date1}}}</nowiki></code> etc. in a template although I note that there are two ambiguous dates listed. Is it d-m-Y ({{#time:d-m-Y}}) or m-d-Y ({{#time:m-d-Y}})? – ]4] 15:31, 20 May 2012 (UTC)
:::This is copied from the help page, so I'm not sure what the original intent was. If this table is meant to work, it could conceivably take the format of the entries with named months as indication that they're all d-m-y. My main question though is, are the hidden labels always necessary? Is there a way to do this by grouping d-m with wikilinks? The help page seems to indicate something like that, and might even be saying ''that'' isn't necessary, but I can't tell because it seems to have been written by someone with some sort of neurological disorder. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 15:38, 20 May 2012 (UTC)</font>
::::P.S. The template is {{Tl|Dts}}. – ]4] 15:40, 20 May 2012 (UTC)
:::::I think the moral here is - be consistent with your date formats and it'll be alright on the night. ] (]) 15:42, 20 May 2012 (UTC)
::::::The only all-number date allowed by ] is yyyy-mm-dd. (Also tweaked the above for full year as there is also an 07 April entry and poor me got confused.) --] (]) 15:45, 20 May 2012 (UTC)
::::::Consistency doesn't seem to work on its own, I've tried. The template Allen4names posted is the only thing that seems to have worked so far, so thank you very much for that, Allen. I'd still like to know what's up with this though. I want to clean up that help section so it looks less like a schizophrenic clown's pubic hair (I'm running out of ways to insult this thing, sorry). '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 15:50, 20 May 2012 (UTC)</font>
{{od|5}}The interpretation is described in the help page section "Sort modes", with some errors and vagueness. The main ideas seem to be that it only works with formats like "25-12-1987", "25-12-87", "25 Dec 87", or "25 DEC 1987". All it does is create a character string by moving various characters around. Plus, if the year is only two digits, it interprets everything below 50 as in the 2000's and everything above 50 as in the 1900's. So the examples I gave would be transformed to "19871225", "19871225", "1987De25", and "1987DE25". Then the resulting character strings would be sorted.
Does this imply that all classes labeled <code>letters-*</code> haven't been updated for Dark Mode yet?
So all the dates in the table must be consistent within the table. Further, of the 4 formats allowed by MOS, three don't work. Of the 6 formats allowed by this function, 4 are forbidden by MOS. This is so horrible, I'm not sure whether it would be better to plaster the help page warning not to do this, and only use the information for correcting any article that contains this abomination, or to file a bug to have this crap completely ripped out of Misplaced Pages source code, and let any tables that contain it fail. ] (]) 15:58, 20 May 2012 (UTC)
:I edited the table above to be consistent as , which according to your interpretation of the help page, should work. It doesn't seem to though. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:03, 20 May 2012 (UTC)</font>
::It seems to work if every month is given as three letters. The letters can be first-letter capitalized ("Sep") or all-caps ("SEP"). It does not work if the months are spelled out (September). ] (]) 16:34, 20 May 2012 (UTC)
:::Sorry I should've said . The table above is currently formatted as you suggest, but the sorting still screws up. Give it a try. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:37, 20 May 2012 (UTC)</font>
::::OK, so it seems to be translating the month abbreviations to a number, but sorting first on the year, then on the day-of-month, and last on the month, so it is indeed broken. And, in my view, not worth fixing. ] (]) 16:41, 20 May 2012 (UTC)
*Whoa, what? When is '''any''' bug not worth fixing? Even the most minor bugs need to be corrected. The whole point of creating and maintaining any kind of system is make it as error-free as possible, and ignoring or dismissing errors certainly runs contrary to that goal. <span style="13px Sylfaen;background-color:#000000;padding:0 3px 0 3px;">]</span> 16:49, 20 May 2012 (UTC)
**From Jc3s5h's other comments above, it seems he means that the whole feature should be tossed out since it's in such bad shape -- not quite that it should be ignored. I'd love to demolish that help section myself to make it clear that this feature isn't worth any attempt to use except with the {{tl|dts}} template. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:53, 20 May 2012 (UTC)</font>
Additionally, I can't find where to modify the CSS code. Thank you for your attention. ]（]） 09:25, 22 January 2025 (UTC)
::Yes, my view is that the feature should be removed; let the table editor either put in date strings that are directly sortable (YYYY-MM-DD) or use the dts template. Any effect in existing tables would be a benefit, since its better to have an obvious error that a subtle one. ] (]) 17:32, 20 May 2012 (UTC)
:::Ah, I get it. :) <span style="13px Sylfaen;background-color:#000000;padding:0 3px 0 3px;">]</span> 17:37, 20 May 2012 (UTC)
:Would be better to get rid of these colors altogether per ]. ] (]) 09:30, 22 January 2025 (UTC)
Yes, table sorting is borked. When 1.18wmf1 was deployed last fall, it included a new tablesorter module that should have made the sorting templates obsolete. Unfortunately, it is dependent on HTML5 and when that was enabled, it broke so many things that HTML5 was disabled after a few hours. {{Bug|31527}} ---'''''— ]<span style="color:darkblue"> '''''</span><sup>]</sup> 17:43, 20 May 2012 (UTC)
::I see the transliterations (e.g. ha and na) above the first row of characters in both light mode and dark mode. – ] (]) 15:25, 22 January 2025 (UTC)
:I just took a wrecking ball to ]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 18:16, 20 May 2012 (UTC)</font>
:::Here's how I see it: ] ]（]） 22:14, 22 January 2025 (UTC)
: {{ec}} We ''are'' using the new tablesorter module, we just can't take advantage of the explicit column tagging feature until HTML5 is enabled. This bug is unrelated: the date sorting of the tablesorter module could easily determine that "1 Apr 2012" is DMY order and "Apr 1 2012" is MDY order, but for some reason it doesn't. It just converts them to "1 4 2012" and "4 1 2012", respectively, and then assumes MDY or DMY order based on the global wiki configuration. ]] 18:19, 20 May 2012 (UTC)
::::Strange. I suggest trying a different browser, and trying dark mode while logged out. – ] (]) 00:01, 23 January 2025 (UTC)
::My SWAG is that the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis. ---'''''— ]<span style="color:darkblue"> '''''</span><sup>]</sup> 18:42, 20 May 2012 (UTC)
:::I should think that would've been obvious. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 18:50, 20 May 2012 (UTC)</font>
::::I'm pretty sure the axis referred to by Gadget850 is normal to a toilet bowl rim. ] (]) 19:11, 20 May 2012 (UTC)
:::::I almost fell over laughing when I read "''the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis.''" A while back I spent a few days trying to figure out just a few problems with table formatting for sorting. It nearly drove me nuts. I did manage to add some accurate (at the time) info to ]. I did not even attempt to figure out full date sorting though. I did manage to figure out a few permutations of year-only sorting. Also, I figured out some of the numerical sorting problems. --] (]) 10:31, 22 May 2012 (UTC)
== Any insight in to new accessibility issue affecting screen readers and Vector 2022 and Chrome? ==
== A question for CSS specialists ==
See {{section link|Misplaced Pages talk:WikiProject Accessibility|Search Field More Difficult to Activate with a Screen-reader in Chrome}}. Any replies should probably go there. ] (]) 14:36, 22 January 2025 (UTC)
How can I remove the three humongous sections on a edit page, namely 'Please Note', 'Pages transcluded onto the current version of this page' and 'This page is a member of 2 hidden categories'. Is there a CSS tag to remove these? <br />
Thanks in advance! ''']</font><sup><font color="#AF7817">]</font></sup>''' 17:35, 20 May 2012 (UTC)
: You could try the following, assuming we're talking about the Vector skin:
<code><pre>
div#editpage-copywarn2 { display: none; }
div.templatesUsed { display: none; }
div.hiddencats { display: none; }</pre></code>
:--] (] Russ) 17:50, 20 May 2012 (UTC)
::"This page is a member of 2 hidden categories" is probably dealt with the preference in the Appearance tab at ] labeled "Show hidden categories". --] (]) 00:10, 21 May 2012 (UTC)
:::Nope, that preference refers to viewing the article normally, not in the edit window. ''']'''<font color="green">]</font> 02:03, 21 May 2012 (UTC)
:Thanks everyone. I've tried these to put in monobook.css but I don't get the desired results. I'm using the vector skin. Please take a look at ]. ''']</font><sup><font color="#AF7817">]</font></sup>''' 03:56, 21 May 2012 (UTC)
{{done}} After putting the same in vector.css, all these sections are now gone in a puff of smoke. :) Thanks for the help. ''']</font><sup><font color="#AF7817">]</font></sup>''' 04:00, 21 May 2012 (UTC)
== Perlcalltogetsearchresults ==
== Getting List of All Class B Articles ==
Hi,
Is there a Perl call that can pick up the results of a Wiki search? If I perform are there a few lines of Perl that get the results so I can then look through them? Thanks. ] (]) 20:31, 20 May 2012 (UTC)
: See ], particularly ]. ]] 22:37, 20 May 2012 (UTC)
I would like to get a list of urls to all class B articles. I know programming. But from what I could figure out up to now, it seems quite tedious to go to Category:B-Class_articles and do all subcategories in a recursive manner and change targets from talk pages to the actual articles. Is there any easier way to do it?
::I will take a look. Thank you. ] (]) 04:44, 21 May 2012 (UTC)
== File redlink should not lead to godawful upload form ==
Why do file redlinks lead to the upload wizard? It is such a pain to try fix deleted image issues now, because you have to cut the filename out of the target page URL, or open up the page to cut it out of the code, then search for it and click from the link from there, or paste it into a fresh URL. It should show the page logs with an option to go to ] ''or'' the upload wizard (which is designed for the uninitiated). Why are we encouraging editors to re-upload images that were deleted, instead of showing them why they were deleted? That seems disruptive. ▫ ''']''' 20:58, 20 May 2012 (UTC)
:As an admin it's also annoying because I might want to track patterns of those deleted images (''all I want'' is the deletion log-entry and associated links). When one follows a redlink to an article (or other text-content) page that has been deleted, there's a pink "A page with this title has previously been deleted." box with log entries, etc. Seems like this same UI feature would be just what we need on the first upload-page one gets when following a redlink to an image. ] (]) 21:10, 20 May 2012 (UTC)
::Yes, that makes sense. I think they changed it because it was pointless to encourage edits to "create" file pages, instead of uploading files. Why not create a hybrid? Show the page logs at the top (like a normal redlink), and the upload links at the bottom (instead of an edit field)? Clicking the '''edit''' tab should still allow you to create a file page, so everyone would win. ▫ ''']''' 21:17, 20 May 2012 (UTC)
:::Is there any chance of a script/preference workaround for this? Could the navigation popup catch this as a special case and display something about the wpDestFile instead of telling us about the upload wizard? -- ] (]) 16:17, 21 May 2012 (UTC)
::::: In principle, the ] page itself could be made to recognize the wpDestFile= parameter and include a message with the deletion log etc if necessary. However, for this to be possible, it would be necessary to make the script globally available through one of the global script files. But the better option is certainly to have the redlinks point somewhere else from the start, see for options below. ] ] 06:31, 22 May 2012 (UTC)
::::Until ] decided to rename the page three months ago, there was always a link to the deletion log at Misplaced Pages:Upload. I've never seen the benefits of moving the page, but this is a clear downside to having it moved. ] (]) 01:30, 22 May 2012 (UTC)
:::::I pinged FutPerf. ] (]) 02:19, 22 May 2012 (UTC)
{{outdent}} I was going to ask the same question when I returned from the trip I'm on. Although I agree this may be helpful for new users, and have no problem with it being the default, it would be nice if there was a user option to instead have it show the name "deleted page" page, essentially for the same reasons as DMacks although I think it could also be beneficial to other users who are unlikely to upload an image but for whom the deletion log may be useful (people investigating sockpuppets, copyright etc). ] (]) 02:26, 22 May 2012 (UTC)
:This was discussed a few months ago. I quite agree the image redlinks should not lead to the upload wizard. I want to make clear though that the change I made when introducing the wizard is not what causes this behaviour. If we reverted that change today, image redlinks would instead lead to the page that is currently at ] (because image redlinks go to ], and that's what was at that page before I redirected it to ].) This page would not show the deletion log either, because (unlike ]) it can't react to the filename parameter in the Url any more than the FUW can. If it seems my change coincided with another change in linking behaviour, this must be because it happened to coincide with a change in the Mediawiki software, where there were some tweaks made to image redlinks around the introduction of v.1.20 (iirc). I'll need some time to dig up the links to the old discussion and related pages on bugzilla about the Mediawiki changes. If I remember correctly, there is a Mediawiki variable whose behaviour was changed, and which we might want to set differently in order to point the redlinks elsewhere. But I'm not quite sure what the best target would be. ] ] 05:11, 22 May 2012 (UTC)
For illustration, here's several options of how file redlinks could currently be handled:
*Image redlink with colon (<code><nowiki>]</nowiki></code>): ] (links to https://en.wikipedia.org/search/?title=File:Just_an_example.jpg&action=edit&redlink=1 , i.e. the edit page of the non-existing file page)
*Image redlink without colon: ] (links to https://en.wikipedia.org/Wikipedia:Upload?wpDestFile=Just_an_example.jpg)
*Fake link demonstrating what would happen if we reverted ] to what it was before February: <span class="plainlinks"></span>
*Fake link demonstrating what would happen if redlinks went to ] per original Mediawiki default behaviour: <span class="plainlinks"></span>
*Fake link demonstrating what would happen if redlinks went to the non-existing file page, without "action=edit": <span class="plainlinks"></span>
Out of curiosity, which of these corresponds to what people remember was the normal behaviour for (non-coloned) redlinks prior to February? Because I really don't know. ] ] 06:22, 22 May 2012 (UTC)
:So, if moving the page back to the previous title wouldn't help, what would? All I know is that it stopped appearing exactly at the same time as when you moved and rearranged the page substantially. ] (]) 12:13, 22 May 2012 (UTC)
:: What would help would be to get the MediaWiki variable that governs the behaviour of these redlinks changed to point to one of the url types listed above. I forget what it was called, but there is such a variable. It's something that has to be requested on Bugzilla and done by the devs, but other than that it's fairly easy. We just need to decide which of the above we want. ] ] 13:52, 22 May 2012 (UTC)
== Images overlapping with table ==
Can someone have a look at ] and see how to amend it so as the table refs don't overlap with the photos? I'm using Safari on ipad. The first photo opposite the table (Barclay) displays fine, but then on all the others (except Needham) the photos overlap with the Ref column. Thanks. ] (]) 21:23, 20 May 2012 (UTC)
:I added a <nowiki>{{clear}}</nowiki> that solved the issue on Safari, and was going to come here to comment that since a) I didn't see the problem with other PC browsers I tried, b) the overlap only appeared with PC Safari with a fairly narrow window sizing, and c) it leaves a hideous amount of whitespace on '''all''' browsers at '''all''' window sizings, I was going to say it might not be worth it, but now see that my "fix" was immediately as "unacceptable solution", so not sure what to suggest. (Well, I have a theory about breaking the table up alphabetically and having one image/clear per sub-table, but that kinda defeats the purpose of having a sortable wikitable, and again, given the limited number of users affected, probably wouldn't fly, either.) ] (]) 01:23, 21 May 2012 (UTC)
::Thanks for responding and trying something. I can see how the whitespace was a problem, and yes splitting it up would not work as you would not be able to sort. I'd like to think there is a technical solution, as I've seen pictures on the right on similar articles. ] (]) 07:39, 21 May 2012 (UTC)
:::Pictures on the right of tables is oftentimes a problem. A gallery section would solve the problem. See ]:
:::<nowiki><gallery> </gallery></nowiki>
:::You can eek out a little more space for photos on the right by putting the sorting icons above the header text. See the last part of this section: ] --] (]) 10:42, 22 May 2012 (UTC)
== Watching topic ==
''This discussion is brought over from ]''
''Before I start, let me say I have no idea '''how''' to do this, I just think it is a good idea. But will be willing to help anyone who wants to implement it.''</br></br>At the moment, we have the option of watching pages. If I want to watch just one topic or discussion on that page, I have to watch the whole page. So when I look at what has changed in my watchlist, even things I am not interested in pop up. I think it would be a good idea to have an option whereby a user can watch a page, but also watch a topic, heading, or sub-heading of a page or article. <span style="border: 1px solid #C90016;background:white">]]</span> 20:54, 16 May 2012 (UTC)
:<s>It's a good idea. There is the script ] lets you watch a category for changes</s> (I misunderstood)'''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 21:14, 16 May 2012 (UTC)</font>
::I don't think that's what Kinkreet is after. It sounds more like s/he would like to be able to watch (for example) a single discussion at ] without having to watch the entire page. ] (]) 21:19, 16 May 2012 (UTC)
:::Oops I wasn't paying attention. Yeah this has been brought up before. Actually they were thinking of making all the ANI discussions into transcluded pages, so people could watch them individually and avoid edit conflicts, as is done on some other process pages. It never came to fruition though. The ability to watch a particular header would definitely be awesome. I think it would require some significant new coding and database changes in MediaWiki though. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">]<small>]</small>''' 21:29, 16 May 2012 (UTC)</font>
::::] caught my idea right on, thanks. I want it (and I think others want it as well) for following a single discussion, as well as following a section of a large article. For example for ], if someone is a historian and only want to keep an eye out for the history of quantum mechanics, I think it would be more efficient for them if they are able to watch just that section, ''for example''. <span style="border: 1px solid#C90016;background:white">]]</span> 10:41, 17 May 2012 (UTC)
:::::Yes, a good idea, and may require effort to implement if it requires schema changes as Equazcion said. But as they say leave it to the bot. If the user has patience, a bot could produce such a report without Mediawiki modifications and produce a report once a day. And that would not overload the Mediawiki servers if and when distributed bots fly... but let me not get off topic, for this is unlikely this year. ] (]) 21:57, 18 May 2012 (UTC)
::::::I think we have establish this might be not a simple implementation, but ''if'' there is someone who we can talk to about this, who would it be? <span style="border: 1px solid#C90016;background:white">]]</span> 12:31, 19 May 2012 (UTC)
:::::::It would have to be brought up at , that's how we communicate with the developers who make the major changes. It can be tough to get them to do stuff that constitutes major new features, unless a broad consensus is demonstrated first by the community (even then it can be difficult). A !vote at ] would probably be needed first. I can't predict how that might go. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px#999;">] <small>]</small>''' 12:47, 19 May 2012 (UTC)</font>
::::::::Thanks for the advice, I will move this discussion over there. <span style="border: 1px solid#C90016;background:white">]]</span> 08:26, 21 May 2012 (UTC)
{{collapse top|1=Copied from ]}}
I find that Misplaced Pages's watchlist is nearly useless on pages such as ]. I want to see if anyone has posted to the one particular dispute I am working on, not every dispute on the list. Same with the Village Pump -- I want to see if there are any posts responding to the question I asked without seeing everything posted in response to the other questions. --] (]) 02:37, 20 May 2012 (UTC)
:Gets suggested often, there's one now at ]. PS I do agree this would be great. ANI alone is worth it. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 02:40, 20 May 2012 (UTC)</font>
::Yes, that's an issue for me too. Please? ] (]) 02:42, 20 May 2012 (UTC)
:: This does get suggested often, to the point where it is listed at ]. The problem is that it would require a major change to the software, and no one with the necessary skills has stepped forward to plan out and implement the necessary changes at the code level. ]] 02:55, 20 May 2012 (UTC)
:::Has there been any effort to hire such a person on a short-term project basis? In software development, it often turns out that what was considered to be hard turns out to be easy once the right person looks at the problem.
:::I am wondering about that "it would require a major change to the software" bit. Right now the software feeds my watchlist the page that was changed, how many bytes, who changed it, when, and the edit summary. You could add the section title. Then the watchlist, when watching a section, could simply ignore anything with the wrong section title. Yes, this would fail if someone changes the section title, but that could be addressed by always sending me the pre-edit section title, so on my watchlist I would see the edit making the section title change. --] (]) 04:19, 20 May 2012 (UTC)
::::Having to determine the section title that was edited would add significant complexity over the current process that occurs when a page change occurs, since currently it just registers that some change occurred without determining anything. There would need to be a kind of diff routine added each time. What if multiple sections were changed etc? We could have it use the section header noted in edit summaries, but that's not reliable since people can change that manually or delete it entirely, and it doesn't even show up if you hit the edit tab instead of a section link.
::::Any "simple" solution involving only using the current system of wiki headers would likely require updating a new set of data that catalogs section changes as they occur. This is all just based on my evaluation though; someone could come up with an amazingly simple outside-the-box solution, who knows.
::::Then there's the more complex route, where we change the way discussion pages work fundamentally. Personally I think that's the way to go. The ] ] is/was an attempt, though I don't know how well it'll accomplish the goal, if it ever does get implemented. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 04:41, 20 May 2012 (UTC)</font>
{{collapse bottom}}
It's a good feature request, and one that's been on the table for at least five years (and probably a lot longer). Basically, it's not technically feasible to literally watch the sections on a page; but as has already been mentioned, each section could be a transclusion of some other page, and you could watch that. These sorts of considerations fed into the design of a new extension, LiquidThreads; unfortunately, that project has a rather checkered history, so it's not deployed yet (and may not be for some time). Hence why you still can't watch individual sections of a page, unless you manually transclude them out, unfortunately. - ] <sup>] ]'']</sup> 09:58, 21 May 2012 (UTC)
== Interwiki BOTs ==
Can someone take a look at ] as for the last 4 days a number of interwiki BOTs have been adding then removing the interwiki links. Looks like something is causing a problem on one of the wiki's entry. ] (]) 12:04, 21 May 2012 (UTC)
:I've stopped the bots for now (I hope), but I don't think they were misbehaving. Looks like a malicious user is creating stubs on this ] guy on multiple Wikipeida wikis only for them to be deleted shortly afterwards, presumably on speedy notability grounds. This causes the interwiki bots to chase each other around adding and then removing the corresponding articles (). Looks like it the work of a blocked user, ]. — ] <sup>]</sup> 13:59, 21 May 2012 (UTC)
::Thanks for taking a look, thought there had to be a simple explanation. ] (]) 17:23, 21 May 2012 (UTC)
== New pages bug? ==
When I clicked the link to review the new page ] I got a page saying "The page Long Ding＆action=markpatrolled＆rcid=504963624＆token=9993d1607d61778bcd5415f0 does not exist". What is going on?
]] 15:10, 21 May 2012 (UTC)
:Where are you clicking this from? Special:NewPages or somewhere else? This wiki or another wiki? (The problem seems to be with the use of a non-standard & character.) - ] <sup>] ]'']</sup> 15:31, 21 May 2012 (UTC)
::When coming to an unpatrolled page from ], a link appears at the bottom that says <small></small>. See ] ]] 19:46, 21 May 2012 (UTC)
:::Happened on ] as well ]] 20:21, 21 May 2012 (UTC)
::::Has anyone else had this happen? ]] 13:38, 22 May 2012 (UTC)
:::::] was apparently just deployed, along with MediaWiki 1.20wmf3 (below), so maybe it has something to do with one of those. I just tried patrolling a page and didn't get an error; I don't know if you're getting it every time or just intermittently? '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 13:47, 22 May 2012 (UTC)</font>
::::::It's only happened several times, and not on all pages. ]] 17:50, 22 May 2012 (UTC)
Hi everyone! Yet another deployment in our bi-weekly deployment cycle will soon be underway (in 30 min, at 18:00 UTC). See ] for release notes. Let us know if you encounter problems caused by this deployment. Thanks! -- ] (]) 17:27, 21 May 2012 (UTC)
:Done now -- ] (]) 18:22, 21 May 2012 (UTC)
=== Bug with RevDel ===
{{Tracked|36973}}
When you go to look at a blocked user's contributions (for example, ]) you no longer see the (<span style="color:blue">del/undel</span>) link to hide the block event. Instead, you see a checkbox, which I presume has to do with the update of log event hiding. However, the button to hide the selected events does not appear. Thanks! ] (]) 18:58, 21 May 2012 (UTC)
:The same issue occurs with deleted pages (). ] (]) 19:01, 21 May 2012 (UTC)
::I just noticed this while deleting ]. As far as I can see, the boxes up top have no effect; when I selected all of them (while leaving all of the boxes at the bottom of the screen unchecked) and undeleted, it restored everything (just as if I'd not selected any boxes at all), and the same thing happened when I selected just one box up top and none below. ] (]) 01:19, 22 May 2012 (UTC)
== Yet MORE idiocy thrust on us? ==
I imagine this is part of the "MediaWiki 1.20wmf3 deployment" but seriously, whose bright idea was it to change the title page when looking at DIFFs to 'Difference between revisions of "(X)"'? I mean, are people TRYING to drive out editors in droves by making stupid and ugly interface changes that just make things worse? ] (]) 22:07, 21 May 2012 (UTC)
:Meh, I quite like it (why so much hate?). Also it changes the title tag (displayed in your tabs) to make it more obvious which tabs are diffs and which aren't. It's quite clearly a more informative title that what preceded it, anyhow. Ugly, maybe, but certainly more functional (i.e. hardly "stupid", IMHO). It was bug #], by the way. - ] <sup>] ]'']</sup> 22:41, 21 May 2012 (UTC)
:I think the important thing here is that we continue to oppose every single change that ever happens to the interface with a response that is out-of-proportion with the change itself. Indeed, it is important to keep in mind that the developers are purposely trying to make Mediawiki worse so that people will no longer want to contribute to Misplaced Pages, and we also need to keep in mind that there is no such thing as a good change. Change is always for the worst, and for that reason we must oppose it, and we must also use inflamatory language and act far more personally incensed than we have the right to be. Or maybe we shouldn't do that. --]''''']''''' 23:06, 21 May 2012 (UTC)
::This change was also , and an . Specifically, Amir is changing it so that the title of the article will precede the explanatory text. That should roll out with 1.20wmf4, which is due in two weeks. -- ] (]) 00:09, 22 May 2012 (UTC)
:: Per Jayron32: We must also oppose editors editing articles in a manner that changes something that previously existed, because the prior state will then only exist in the article history. We must not allow editors to edit articles such that the prior intent of an earlier editor is overridden. Previous editors know better than current editors, so established revisions of articles must always be retained. ''Nothing'' must ever be lost if someone put it in an article before someone else got there. Assume that previous editors were right and that anyone who makes a change, has made a mistake. See also: Happy-melon and Jorm (below); such technical people should be restricted to code they can develop by carving ''wood'' with chisels so that everyone can have a chance of understanding it. Change is bad; usually blockably so. ] (]) 09:19, 23 May 2012 (UTC)
:What Jayron said. The horrific technological inertia that is developing within the community is only going to lead to two possible outcomes (or some even-less-sustainable combination of the two). Either the developers abandon any hope of satisfying the community and stop bothering to even try to engage with it, or they stop trying to develop beneficial features at all. Either approach has only downsides and (ironically) even ''less'' chance of the issues the community ''genuinely'' feels strongly about being addressed. Is making ''such'' a strong statement about the change of the title of a non-reader-facing page ''really'' proportionate? ]‑] 00:17, 22 May 2012 (UTC)
::^This.--] (]) 00:22, 22 May 2012 (UTC)
::Well it was quite a shock, and as it's something I have to look at many times a day it's jarring. Right now I have seven tabs that say "Difference betw..." on them. No idea which is which, so how can I know which are likely to be quick checks and while I want to save until the end to spend more time of them? If the article name will be moved to the front, I guess that solves that issue, at least. But what's the point of it anyway? It's completely redundant driven by the fact that the grey and green is above the article, which means that it's very easy to glance and see it's a diff in the first place. ] (]) 01:34, 22 May 2012 (UTC)
:When editing or moving pages, the page title changes to "Editting (x)" or "Move (x)", similar to the way DIFFs are currently titled. Were there any complaints about it? If you are viewing several editors contributions at once, it has been difficult to distinguish them by tabs alone because they are titled "User contributions of (User name)". Do you wish them to be changed as well? Or new ones (DIFFs) only? --] 02:41, 22 May 2012 (UTC)
: You know, we can easily change this by editing the appropriate MediaWiki-namespace page. I've taken the liberty of changing ], ], and ] to match the change linked above by RobLa-WMF (please delete those pages when 1.20wmf4 is live). Also, I agree with Happy-melon above. ]] 02:54, 22 May 2012 (UTC)
::Thanks, I just noticed that change. It's much better to have the article title first as that is what is important, and it's the only thing visible when have many tabs. ] (]) 03:08, 22 May 2012 (UTC)
:::The point previously made about mistaking "Revision history" for part of the title (in this new version, where the quotes are removed and the page action put after the title, separated by a colon) - is a good point. Which is one of the reasons I very much dislike this re-ordered construction, entirely. To make tabbed browsing easier, We normally use a reversed breadcrumb in the page title (Action < Page name < Site name). Up until now that was the case for all actions and special pages. But this is now broken for Diff and History. For example, right now I see tabs "Editing User:Kr..", "My Watchlist - W..", "Misplaced Pages:Villag..", "Misplaced Pages:Villag.." and "Misplaced Pages:Villag..". I can't tell which of these last three is view, Diff or History. Now one could make a similar point when saying you have tabs "Difference ..", "Difference .." and "Difference ..". So I doubt there is really much of a gain for either. But whatever the case, consistency throughout the interface is most important. And right now these "Diff" and "History" are inconsistent with all other titles, because those titles (Edit, Move, Delete, View source, What links here, ...) all put the action first and quote the page title (which has so far always prevented most confusion about which part the page name is). ] (]) 03:18, 25 May 2012 (UTC)
::::How many different types of views are there? I have no clue what type of work it takes to change stuff like this, but do we need 'Difference between revisions' instead of just 'Diff' or even just 'D'? 'Hist' or 'H' instead of 'Revision history'? I'd think we could come up with some system that would allow several tabs to be up at once showing what type of view '''and''' for which page at the same time. Do we need such long descriptions? --]]] 04:23, 25 May 2012 (UTC)
::::: Remember that we want the titles to be transparent to new users as well. "D" and "H" certainly don't fit that bill. ]] 11:36, 25 May 2012 (UTC)
::::::Beyond all that, it really breaks my brain sometimes. I keep thinking "Difference between revisions" is part of the title. But once again, I ask what the POINT of it is in the first place? It's 100% clear that it's a diff by virtue of the extra stuff at the to] (]) 13:19, 25 May 2012 (UTC)
::::::: I have the same brain breakage with the diff pages. OTOH, I've long used a small script to remove the "Revision history of" bit on history pages for the same reason the devs changed the default message now: lots of tabs all saying "Revision his..." are useless. There is a way to change both messages: get consensus and we can edit the appropriate MediaWiki-namespace pages to say whatever we want. Or use a script to rewrite the page title and {{tag|h1|o}} tags on history and diff pages, if you can't get consensus to change it for everyone. ]] 16:31, 25 May 2012 (UTC)
:I wanted to respond to Happy-Melon's remarks. I don't really see anything wrong with this particular change FYI. However, as someone who participates at VP Proposals and basically always has, I'd just like to point out that the developers would probably find themselves getting better responses if they worked on changes the community has been requesting. Realizing full-well that they're mostly volunteers and can spend their time the way they like, I think a better job could be done in encouraging development of what the community wants, rather than their own whims regarding what is best ''for'' the community. They've become a little too comfortable with the latter over the years for my taste, and it would appear I'm not alone in feeling that. Most rights-wielding users have been more-or-less trained to be sensitive to the fact that their privileges are only there to serve the community's decisions. I feel this much less from developers. Perhaps it's a disconnect that started with the use of bugzilla, a forum outside of Misplaced Pages, where development business is discussed outside the purview of the average user (even most non-average users). The argument could be made that that's a good thing, and certainly that bugzilla's features are more conducive to development talk. I just don't know if keeping things status-quo is worth risking the kind of breakdown Happy-Melon describes, which does seem plausible. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 04:35, 22 May 2012 (UTC)</font>
::Huh? This ''was'' a community requested change, not a developer "whim" about what's best for the community. In fact pretty much all of the development projects that are going on right now are community requested (visual editor, new templating system, PageTriage, etc.), mostly from the English Misplaced Pages community. In fact, we do so much development specifically for the English Misplaced Pages community that the other languages and projects are often upset at being neglected. I agree that Bugzilla isn't ideal, but it's much more efficient than hanging out on the Village Pump all day ;) ] (]) 05:42, 22 May 2012 (UTC)
:::I was speaking more in general terms, but if you could point me to the discussion on this change, that might help. Surprised you'd bring up triage though, considering ]. I wasn't prescribing any particular solution, least of which handing development discussions entirely over to VP. But if you want idea seeds: Some sort of automated cross-posting of promising bugs to a page that doesn't require a separate login from Misplaced Pages; or some sort of "transclusion" of them here, as it were (have a page here read their database). More communication, more visibility, more accountability. Creation-of and adherence-to a policy on Misplaced Pages for proposing, discussing, and implementing interface changes that affect Misplaced Pages's defaults. That's just off the top of my head. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 06:00, 22 May 2012 (UTC)</font>
::::Except from en.wikipedia isn't the only MediaWiki wiki, so having MediaWiki development discussions here isn't really the best option. Having an external forum from any particular implementation of MediaWiki is actually quite important, in my opinion. And there is no reason why the MediaWiki developers should have to follow some policy the community on Misplaced Pages make up for them. - ]<sup>]</sup> (]) 07:34, 22 May 2012 (UTC)
:::::As far as I'm concerned, the developers can feel free to make whatever MediaWiki changes they want, with the notable caveat that anything default is disabled on Misplaced Pages until the community agrees to it via a process. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 07:36, 22 May 2012 (UTC)</font>
:::::Addendum: I'm not claiming to have all the answers. Nevertheless, Happy-Melon brought up a valid point. Whether or not you agree that people's reactions are justified in these situations, we can't change the way people react just by telling them they should be reacting differently. Why not attempt to address this issue in a way that has a chance of improving it? I'm open to suggestions, but considering there is an incongruence between MediaWiki's development as standalone software vs. its effects on a website purported to be run by a very large community whose interests may differ, I think discussing a policy governing the way MediaWiki changes affects Misplaced Pages could be a good start. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 07:50, 22 May 2012 (UTC)</font>
::::::"''And there is no reason why the MediaWiki developers should have to follow some policy the community on Misplaced Pages make''" is exactly the sort of attitude which is giving rise to the frequent and voluminous complaints about changes to the MW software, interface etc. The general feeling is that ''someone'' suggests a change, a small coterie of editors agree with the principle without adequately thrashing out the practical, implementation and other issues, and it appears the developers then go ahead on exactly the same basis, and as if "the community" has given ''carte blanche''. Then they recoil in horror when "the community" rejects the change loudly the moment such change 'goes live'. I'm not suggesting the everything needs to have the same degree of community approval, nor that I am unhappy about the subject of this particular discussion. Crux is that editors feel the developers are acting without accountability. The best recent example is the bolding applied to the Watchlist. Of course, it makes little sense to discuss these solely on en.wp as development changes affect other wikis. but the current process (cycle of request–development–trial–roll-out) is not working properly right now, because there is currently no such procedure. --<small>] ]</small> 08:11, 22 May 2012 (UTC)
{{od|::::::}}
''"the developers can feel free to make whatever MediaWiki changes they want, with the notable caveat that anything default is disabled on Misplaced Pages until the community agrees to it via a process"''
We should make that official policy. (No, I am not kidding, those green stars that popped up on my watchlist recently and of which I (fortunately) got rid is a strong argument in favor of that). -- ] (]−]) 07:56, 22 May 2012 (UTC)
#The green stars were not a change in MediaWiki, but on English Misplaced Pages itself.
#Anyone can bookmark a bugzilla query which generates a list of recently fixed (or opened) bugs (check e.g. or these ). Then, it is easy to check periodically and mention here on VP any request which seems ''controversial for the English wikipedia'' (e.g.: in case it was a request of one of the ''many other WMF wikis'', which may happen to have different needs from enwiki), in order to have more discussion prior to "fixing" the bug.
#I think it is even possible for someone which the appropriate knowledge to write a bot to check bugzilla periodically and list the recent bugs in a Misplaced Pages page, so that people can watch it without leaving the wiki (there is also a MW extension for this: ]). ] 12:55, 22 May 2012 (UTC)
:#The preceding change that resulted in the backlash that preceded the rash move to green stars was the result of a developer move to change a MediaWiki config option for Misplaced Pages. It makes little difference either way. That that change could occur the way it did, and the backlash, were the result of a lack of governance of interface changes.
:#You're saying users here can keep an eye on bugzilla if they want. That incurs the same problem. The ones who would take that upon themselves aren't the ones whose reactions we're looking to deal with here.
:#''This'' one sounds like a good start. But ''only'' a start. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 13:10, 22 May 2012 (UTC)</font>
:::I think this really boils down to giving users a choice whether they want certain changes to apply or not, at least initially. In most cases it would be relatively easily to allow the user to check a box or uncheck a box for a given function to apply. If the user wants it great and if not thats ok too. Changes are notoriously hard to implement in WP for Anything but generally better accepted if its opt in or out based on the user. Lets remember that Users are different and I mean this in no derogetory way but some can see better than others, some see colors different, some have trouble reading certain fonts and some of us like things a certain way and once we are used to it get rather irritated when it changes. Same applies here. ] (]) 14:00, 22 May 2012 (UTC)
::::Surely the standard option should be the basic, with users able to '''add''' whatever embellishments they choose, whereas currently I, and many other users, have to use code to turn things off. This gives longer refresh times and annoying jumps - e.g when the "Mark all pages visited" button initially appears, and then disappears. This is particularly pronounced and frustrating with a poor connection. Presumably this "provide then hide" also adds to the server load, slowing the system down for everyone. The developers seem to have forgotten the ]. ] (]) 14:26, 22 May 2012 (UTC)
::::: The "KISS principle" apparently does not mean what you think it means, if you think adding a user preference and much conditional code is somehow simpler than just enabling the feature and allowing people to override it with styling. Also note that this "provide then hide" probably adds less to the server load than would "don't provide then issue extra requests to load it extra" would. ]] 15:34, 22 May 2012 (UTC)
:::: @Kumioko: Had people not jumped the gun and disabled the bolding for everyone, we'd certainly have a gadget by now that disabled it with a single checkbox click, and then people who wanted different styling could start from either state in their personal CSS. But as it is, we've got the incomplete hiding in the site-wide CSS and massive arguments over whether it should be shown again and how exactly it should look that we'd now need 7 or 8 checkboxes to turn on each of the different style options to satisfy people. ]] 15:34, 22 May 2012 (UTC)
:: @Equazcion: Recall that the enabling of this feature was ]. What "governance" do you imagine that would avoid the "Oh noes! I can't abide change!" comments from people who didn't bother with the original discussion? ]] 15:34, 22 May 2012 (UTC)
::: It would appear "overwhelmingly" is a subjective term. The response following the change was noticeably more "overwhelming" than ], which got 20 support votes -- some of which included the condition that a preference setting for toggling the feature accompany its implementation, which was ignored. I've outlined above some ideas for "governance". '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 15:47, 22 May 2012 (UTC)</font>
So back to the topic at hand, while the header has been switched, it's AlSO been switched on the revision history page...so is there any way to make it go back to old behavior with CSS? ] (]) 13:31, 22 May 2012 (UTC)
:Where on history pages do you see this? '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 14:14, 22 May 2012 (UTC)</font>
: If you're talking about that the history page titles changing from "Revision history of "$1"" to "$1: Revision history", that change was coming anyway in 1.20wmf4. It can of course be changed back (or to something else), but is there a reason besides "Oh noes! I can't abide change!"? ]] 15:34, 22 May 2012 (UTC)
It is ironic:
# First English Misplaced Pages users request the feature to be enabled (me included);
# Then in order to get that the feature on enwiki, it has to be disabled other wikis where it was already in use for years, causing .
# After that, the feature gets enabled and enwiki just "disable" it locally again...
] 18:28, 22 May 2012 (UTC)
=== break 1 ===
Yeah, it's been almost 4 weeks and called it quits on en.wp. Disappointing that the first time I dare to open VPT again, I find the exact same problem. This confirms my conviction that I should no longer spend time on this community as a developer/editor. Stuff like this is supposed to be fun and interesting. When it starts becoming so much of a frustration, I'd better steer clear of it. —] (] • ]) 18:43, 22 May 2012 (UTC)
:The whole idea that every user and wiki should be able to opt out of every single change to MediaWiki is why doing any sort of development takes ages. Not only do we have to make sure that our software works in 200+ languages (including right-to-left), but we also have to make sure that it works in all the ancient MediaWiki skins, that it supports all 3 versions of the editing interface (old, older, and oldest), that if the user disables any dependencies or JavaScript it degrades gracefully, and we even have community members demanding that all features work in text-only browsers. Frankly, it's a miracle that any changes to MediaWiki ever actually get deployed. And for the record, we try really hard to get community feedback before changes are deployed (with some notable failures). Most of the development teams do weekly IRC office hours, and spend a huge amount of time responding to bugzilla threads, listserv threads, and on-wiki threads discussing ideas for features. And we devote special attention to English Misplaced Pages in particular: frequently advertising projects on the Signpost and Village pumps. And that's just what we do publicly. We spend inordinate amounts of time discussing community feedback and potential community reaction to features in development meetings, often skyping or IRCing with community members for real-time feedback on ideas. And for all our efforts, we still get chewed out for every single change without fail. I'm not saying the community isn't entitled to griping about the process, but you should realize it's a 2-way street, and both sides should work towards better collaboration. Demanding that all changes be opt-in or that all MediaWiki-related discussions happen on en.wiki isn't realistic or helpful. And calling our work "idiocy" isn't going to make developers take community input more seriously. ] (]) 19:27, 22 May 2012 (UTC)
::I feel your pain and my heart bleeds for you. I'm only being partially sarcastic. Nevertheless, if you think ''telling'' people about this here is going to solve the problem, you're being very optimistic. This thread did become the recent developments complaint discussion, though my comment that more or less began it was to address something more fundamental. The issue you and DJ outline is the problem. Evidently, if you're trying really hard to get community feedback, the current system apparently limits your ability to do that, to the point that your changes still don't reflect the community's wishes -- or they hate them because they still didn't know they were coming, but either way it makes no difference. We have a problem, whether or not your intentions and efforts are noble. Maybe we should look for ways to address it. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 19:40, 22 May 2012 (UTC)</font>
:::I'm all for that. Right now, there are so many different venues for discussion it's rather unmanagable. I also think one of the big problems is that we have a very hard time getting people to beta test things for us. We usually have working prototypes of new features up on test.wiki or one of the prototype wikis weeks before they are deployed to en.wiki, but it seems no matter where we advertise it, we generally only get significant community feedback after the features are deployed. When I was first hired, I pushed for getting more of our work covered in the Signpost, which I think has had some positive impact, but not a lot. We've also started using "community liasons" for projects, which I also think has had some success. Of course part of the problem is none of these solutions scale well to 800+ projects. I'm interested in more ideas though. ] (]) 20:04, 22 May 2012 (UTC)
::::I suggested a Vector Beta skin somewhere above (if it hasn't been archived yet) where changes could be tested by the community simply by switching skins. Advertising of changes could be done via watchlist notices. Feedback could be handled via a newly-created forum here. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 20:09, 22 May 2012 (UTC)</font>
{{od|::::}}
Obviously, the current situation isn't satisfying for either side, developers and editors alike. Many users including me have expressed a lack of communication between the two sides, and obviously we need to think about how to improve this. We cannot expect developers to monitor all our village pump discussions, and many of us don't even know where to look and comment on the progress of the MediaWiki development. Sure, there are the occasional Signpost notifications, but they often read like "beware, we are gonna deploy this new feature soon, whether you like it or not". I still don't understand why the new diff scheme got deployed after all the opposition it received when we were still at MW 1.18, and then when it eventually was made available as an opt-in in MW 1.19 that option was taken away with the latest version. What I expect is something like a 3-step process:
# Developers notifying the community on a central page which new features are going to be implemented, with the possibility for the community to comment on these changes. The notification page could be at mediawiki.org, but some means (e.g., a bot) would be needed to forward notifications to a page on the English Misplaced Pages (unless we get global watch list functionality). Discussions can take place at the mediawiki.org page. Notifications replicated at the en.wiki page include feature requests (and bug reports) submitted via Bugzilla, using ] as suggested above.
# Prior to the mass deployment of a new MW release, it is installed locally at mediawiki.org (or maybe some ] space?), and the community gets notified, having the ability to provide feedback for fine-tuning the new version as well as to catch some late bugs.
# Mass deployment of the new MW release.
Does that approach sound sensible? Is it implementable? ] (]) 20:12, 22 May 2012 (UTC)
(PS: I see that some of the ideas have already been thrown up in the discussions immediately above. ] (]) 20:17, 22 May 2012 (UTC))
Re testing: I pointed out a blocking bug in the new math extension prior to the deployment of MW 1.20wmf1, yet it was ignored and I still don't get any feedback by MW developers. So testing alone isn't sufficient when developers don't care. ] (]) 20:19, 22 May 2012 (UTC)
'''Comment''' Why can't we just have one page here on en.wiki where significant changes to MediaWiki or Misplaced Pages are announced beforehand? Why can't changes be rolled out on some test Wiki first and only later being deployed on en.wiki? If we already have one of those two or both then I must have missed that. -- ] (]−]) 20:29, 22 May 2012 (UTC)
:MediaWiki deployments to the WMF cluster go through about four generations of testing before they are deployed to enwiki, usually consisting of , , then deployment to , then one or two tranches of other WMF wikis (for 1.20wmf3, all 121 wikibooks wikis), before finally hitting enwiki. I don't think it's a generalisation to say that ''most'' enwiki editors missed that entire process, simply because they do not generally have cause to look outside enwiki (and of course there's no reason why they should).
:In terms of your first comment, remember that context and ask why enwiki is more deserving of notifications than any of those 124 other sites. Of course it ''is'', and as Ryan says above, substantially more effort ''is'' put in to engaging with enwiki than other communities. The WMF sysadmins, and MediaWiki developers, are certainly happy to work to make that engagement more efficient and effective; but enwiki is far from the sole community deserving of their time, and the extent to which many enwiki users think it should be, is stretching many developers' patience. ]‑] 20:54, 22 May 2012 (UTC)
::I think a single notification page that could be watched would already be a huge step forward. ''Some'' way to provide feedback would be needed as well. ] (]) 21:04, 22 May 2012 (UTC)
:::I think so too, because although such notifications are already made, they are made to VPT and it's clear that that is not being effective at spreading the word to those that want to know. But it is important that whereever such notifications are made, that venue is clearly laid out and well-publicised, which is where the discussion Equazcion exhorts above is needed. A comprehensive discussion amongst the enwiki community about how it wants to best organise its interaction with the MediaWiki community, would certainly have the full support of said MediaWiki community. ]‑] 21:09, 22 May 2012 (UTC)
:::''"I think a single notification page that could be watched would already be a huge step forward."''
:::{{like}} -- ] (]−]) 10:25, 23 May 2012 (UTC)
=== break 2 ===
I wasn't going to participate any further in this discussion, in the same vein as DJ; but Equazcion's comments above have reassured me that some sort of coherent discussion is possible. I think a very large number of people here don't have a clear awareness of how much less 'important' the English Misplaced Pages is in the community of MediaWiki wikis than they think it is. We can from only the ''public'' internet nearly 40,000 separate MediaWiki instances, comprising a quarter of a billion pages and 63 million users; that's not including an unknown number of corporate internal wikis each with potentially entire workforces as users. Enwiki claims less than 6% of the total MediaWiki article count and somewhere in the region of 2% of its userbase (the proportion of active users on enwiki, at 0.8%, is vastly lower than the MW average, which is something like 12%). Is enwiki the single largest wiki in the community? Yes, obviously, and that's unlikely to ever change. Is enwiki larger even than the next two put together? No; enwikt and frwikt have more articles between them. The top four ''non-WMF'' wikis have both more articles, and more active users, than enwiki.
Everyone in this community badly needs to wake up to the fact that enwiki isn't the centre of the MediaWiki universe, and hasn't been for for years. And not only is it not the centre of the universe, it's not even close; I think many people believe that enwiki is the 'large minority', when in fact it is only a small slice of the WMF wikis, and an even smaller slice of the entire community. In actual fact, enwiki probably gets substantially ''more'' attention than it strictly deserves; out of precedent; the fact that the majority of developers are English speaking; and yes, the fact that enwiki is the most vocal and voluminous proponent of MediaWiki developments.
Broadly, it's a mistake to think that enwiki inherently 'deserves' ''any'' significant control over developments to the MediaWiki software. Don't think, Ohconfucius, of developers either taking ''or needing'' "carte blanche" or consensus from the enwiki community, to implement ''any'' change. Rather, enwiki exercises influence over MediaWiki by its ''direct'' relationships with developers, who can be enticed to develop features that are beneficial to enwiki and at worst ] to the rest of the MediaWiki community. The enwiki community does itself no favours by alienating those developers, still less by suggesting that enwiki should be able to claim ''even more'' of their time by virtue of some sort of divine right.
Now of course, this is a very unsatisfactory lowest-common-denominator of interaction. As Ryan says above, the MediaWiki developers interact substantially more with the enwiki community than they do any other wiki community, and are always happy to increase that interaction further. The WMF sysadmin staff (and it's important to also be cogent of the distinction between the WMF and MediaWiki) interact far more with the enwiki community than they do any other WMF wiki. Equazcion is absolutely right to say that there is a discussion to be had about how that interaction process can be streamlined and made more effective, and enwiki will certainly have the support of the MediaWiki community in doing so. But it's important not to lose track of the big picture when framing that discussion, which is that the discussion is about how enwiki can best organise ''itself'' to punch ''above its weight'' in the MediaWiki community when liaising with the developers. ]‑] 20:41, 22 May 2012 (UTC)
:And how often are the small wiki communities requesting new features for MW? Where do all the ideas for new features come from? From the developers? From editors on the English Misplaced Pages? If the fraction of the latter is significant I think it is just fair to at least have a way to ''comment'' on the MW progress. Thank you. ] (]) 20:47, 22 May 2012 (UTC)
::Certainly not nearly as vocally, or regularly, as enwiki; and of course the majority of features are positive developments for ''all'' wikis. But it was disappointing to see the 1.18 release criticised for being light on frontend changes, when it was merely that the majority of said frontend changes (improved text-directionality and gender support, for instance) were merely targeted at languages other than English.
::It is absolutely appropriate for enwiki editors to be involved in the MediaWiki development process, to propose changes and even to ''oppose'' them. What needs to change is the ''attitude'' in the community when participating in that interaction, which needs to have more of an embassadorial feel and less of the Divine Right of Kings. ]‑] 21:04, 22 May 2012 (UTC)
:::I tend to agree with your last sentence. Let's hope that better ways for intercommunication and a better attitude go hand-in-hand. ] (]) 21:10, 22 May 2012 (UTC)
::The first part of your comment is clearly a resource problem (it's impossible to deliver everything everyone wants within a short timeframe with the people we have), not a problem of ideas or input and where they come from. The second part... well you got to comment on the process right ? It's just that your comments weren't picked up in a timely and expedient manner, giving you the feeling that you were not heard.... So that is where any focus of the discussion should be (visibility of the process).
::How do developers convince people they are listening and that they are giving priority to issues, without continuously being in debate. And is achieving this goal more important than the actual process of developing the software (Are we gonna allow the pace of the development pace to drop in order to give this visibility) ? The only thing that I can come up with is coupling a much more advanced and usable system than bugzilla (such as the commercial Jira for instance) and significantly integrating it with wiki communities. If the developers can then force themselves to do any actual time accounting and planning in this tooling and that makes the development prices more visible to the community. Such a change would go a long way to making the process more visible. But that is gonna require a huge investment in customizing and switching tooling for the development process and probably still won't work very well for the volunteer developers. —] (] • ]) 21:15, 22 May 2012 (UTC)
:::Better visibility doesn't necessarily imply a slowed down software development pace. I'm not requesting that all activities are accounted for in detail. A tighter integration of the bug tracking system with Misplaced Pages certainly will help, but even interim solutions such as the extension mentioned above and a rough but up-to-date progress plan pushed to en.wiki will possibly already improve things quite a bit. ] (]) 21:27, 22 May 2012 (UTC)
::::So basically the "this month in tech" blog post, but then integrated into every WMF wiki and with more detail and planning, with a 'direct feedback' option for a wiki reader (that does not overload the developers) and without overwhelming the reader. Would likely also require separating the volunteer effort from the WMF effort (which is hardly plannable) and making that a WMF decision on when to include certain sets of volunteer work (roadmap that inclusion process separately for WMF). I don't see a way to do that without significantly diverting resources to that plan for at least the next 2 year to enable this, because otherwise we will be having the same conversation again in 3 more months. —] (] • ]) 21:39, 22 May 2012 (UTC)
:::::I cannot see any intent for efforts in this post. What would be so painful to assemble a list of features the developers are planning to implement for their next (major) MW release, with a possibility to comment on these ideas??? I'm at loss. Other than that, it would already be a step forward if editor-requested bugzilla feature requests would be disseminated to the community via above-mentioned extension. ] (]) 22:25, 22 May 2012 (UTC)
::::::Since all major projects take time to develop, it's usually quite easy to track their progress. For example WMF sponsored projects on such a scale are all referenced extensively in the (aforementioned in other people's comments) monthly engineering reports on the WMF blog (if you're not happy with commenting there, there is also a MediaWiki talkpage you can use). If there are non-WMF-sponsored large projects on the go (these are rarer), generally you're reliant on en.planet.wikimedia.org or on posts to the wikitech-l mailing list (though this isn't the case with Wikidata, for example, which gets included in the WMF's monthly reports. For more imminent upcoming deployments, see ] (no way to comment there, admittedly); for more distant upcoming deployments, see ] (which has a talkpage). For small (in coding time) tweaks, you can consult commit logs, or the easiest way is to wait for ] to be created, like wmf3 has already been - this usually happens well before deployment to enwiki. There's a talkpage attached wherre you can comment. Finally, if that all sounds like a bit too much, I try to summarise upcoming projects of all sizes in the ''Signpost''{{'s}}s weekly Technology Report, and people are quick to comment on articles there with their thoughts, which have a surprisingly high developer response rate. I'm also open to suggestions on how to improve the report. - ] <sup>] ]'']</sup> 22:51, 22 May 2012 (UTC) <small>Apologies if you personally knew some of the above Nageh -- I just wanted to be complete(ish) so people reading this could get a feel for the difference avenues available. - ] <sup>] ]'']</sup> 22:56, 22 May 2012 (UTC)</small>
::::::There's nothing painful about assembling release notes; indeed the developers do it all the time (see ], for instance). The question is how to bring that information to enwiki, and the 45,999 other wiki communities, without the very process of notification taking up huge chunks of developers' time. And even whether it's reasonable of enwiki to expect that information ''to'' be brought to them, as opposed to 'merely' placed on a neighbouring wiki which shares user accounts and logins with enwiki. ]‑] 22:57, 22 May 2012 (UTC)
::I think these are some very useful ideas. Clearly we need a higher-profile and more stream-lined venue of communication between the community and developers. In the meantime, if you want to get detailed information on what's coming down the pipe, probably the best place to look is http://www.mediawiki.org/MediaWiki_1.20 and related subpages. Specifically you can see what new changes are in the latest release (for example, http://www.mediawiki.org/MediaWiki_1.20/wmf3#What.27s_new), and when they are going to be deployed to en.wiki (for example, http://www.mediawiki.org/MediaWiki_1.20/Roadmap). These pages are updated every two weeks. Maybe there's some way this could be set up as a feed that gets picked up by other wikis. ] (]) 23:15, 22 May 2012 (UTC)
:::Global watchlists would be invaluable for this. ]‑] 23:55, 22 May 2012 (UTC)
::::Take a look at ] --] (]) 01:01, 23 May 2012 (UTC)
{{od|::::}}
Regarding en.wiki not being the center of the universe: I get that. Other than the communication and visibility issue, there's currently a bit of ambiguity regarding how development of the software should affect the sites that use it. For example, if en.wiki were a standalone site with no relationship to MediaWiki, we would be looking at updates to the wiki software we use and determining how, and even '''if''', to apply those updates; furthermore, if they are to be applied, how we might customize them to fit our site. The ties we maintain with the software development is partly responsible for the problems we're seeing.
We currently look to the developers and request MediaWiki changes when we want something changed, and to my understanding, that's currently our only option (aside from our copy of MediaWiki's config switches, which by the way are also set by MediaWiki developers). Our administrators can't customize our PHP files, and when such changes are requested of developers, I think both parties assume that the change must be judged as either good for MediaWiki or bad for it, when that might not necessarily be the right question to ask. We here '''are''' only concerned with en.wikipedia. Although I respect that you can't afford to be, maybe that means the separation between MediaWiki and en.wikipedia needs to be made less subtle. MediaWiki was originally developed as "our" software, but now it's not, and continuing to maintain this quasi-bond could be hurting.
As an IT/web guy I know that care needs to be taken when customizing a local installation of web software, otherwise applying future update releases can become a problem, but there is a right way to do it. I don't know if there are currently people in position who could handle something like that, but it might be worth asking. I'm envisioning the posting here of plain-english release notes for an update, describing how users will be affected; noting which changes are optional to the installation; allowing a period for comments on what to do with them; and if non-optional features are proven unpopular enough, discussing whether or not a deeper customization is warranted. Also adding an area where new features and changes specific to en.wiki could be discussed. Features that might work well for MediaWiki as a whole could still make their way to bugzilla. This is all just brainstorming though. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 05:13, 23 May 2012 (UTC)</font>
:As long as we're on the subject, you may want to take a look at ] ] (]) 22:49, 24 May 2012 (UTC)
== Template talk:NDB ==
The website of the Neue Deutsche Biographie changed and that ruined the template is it possible to change it from
to
? Thanks <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) 08:50, 22 May 2012 (UTC)</span></small><!-- Template:Unsigned -->
:German Misplaced Pages already updated theirs, so I copied their code over here. Let me know if there are any problems, I'm still checking through some transclusions. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 09:01, 22 May 2012 (UTC)</font>
:Some links don't appear to be working this way. I don't know enough about this to fix it (or to tell if the invocations are wrong). Could someone else have a look? {{tl|NDB}}, German version is here: http://de.wikipedia.org/Vorlage:NDB. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 09:14, 22 May 2012 (UTC)</font>
:I reverted and tried just changing the URL prefix but that doesn't seem to be working either. See ], ]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 09:31, 22 May 2012 (UTC)</font>
::I also tried it in the sandbox but I could not get it to work, this is why I turned here.--] (]) 12:21, 22 May 2012 (UTC)
=== Fix a url in a template ===
Is here nobody capable to fix the url in the Template talk:NDB? If not who is the person for that job? Thanks.--] (]) 08:21, 23 May 2012 (UTC)
:I've looked at ] and I see no problem. What is wrong with it? --] (]) 09:25, 24 May 2012 (UTC)
::I don't know why Stone mentions the unused talk page. The post refers to an issue with ], mentioned above in ]. ] (]) 11:26, 24 May 2012 (UTC)
:::The problem is not necessarily with ] (the German template being ]) - it might lie in the subtemplates. There are two which are used to build portions of the URL, these are ] and ] - the German equivalents are ] and ]. Even if we ignore the fact that the string <code>0001/bsb000</code> is in the main template at en.wp but a subtemplate at de.wp, we see that the numbers generated by the subtemplates are very different. --] (]) 14:07, 24 May 2012 (UTC)
::::Possible red herring, but I notice that the German template ] uses subtemplates ] and ], whereas the English template ] uses subtemplates ] and ] even though ] and ] exist. ] (]) 16:36, 24 May 2012 (UTC)
:::::I think I got it now. I copied the German code again, but only copied the code within the link this time. For some reason this seems to have worked -- and on checking the resulting diff, Redrose and DH's observation seems to have been the issue. Post back if there are still problems. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 17:02, 24 May 2012 (UTC)</font>
== Massive vertical break in ''Signpost'' News and notes display mode ==
I wonder whether anyone with the right technical expertise could respond to . Vagaries in display, especially concerning images vs. text, are a problem with the current WM software, and advice as to the options for minimising visual distortions would be most welcome. I see no distortion on my system, but that's not the point here. Thanks. ] ] 14:26, 22 May 2012 (UTC)
:Thanks Tony. I'm running IE 7.0 (though I wish I wasn't) if that's any help. --] (]) 14:48, 22 May 2012 (UTC)
::Big gaps before files or section breaks are something I've often noticed when using IE7 recently - I don't remember it from a couple of years back, so it may be due to a recent change, but it's certainly not just you! No idea for a solution, sadly... ] (]) 22:21, 22 May 2012 (UTC)
== Database lag ==
Lag has been increasing steadily for the past hour or two. It's currently at 736 seconds. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 15:50, 22 May 2012 (UTC)</font>
:Someone had been pegging our API servers with requests, causing a replication lag on db12 (contributions). The offender has been blocked now, replag seems to be dropping. ] (]) 15:59, 22 May 2012 (UTC)
::I see it is indeed dropping now. Thanks for the quick info :) '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:03, 22 May 2012 (UTC)</font>
::: Ummm, didn't stay dropping for long, continuing to poke up: , 12806s. --]] 05:28, 23 May 2012 (UTC)
*Now 309 seconds and rising... - ] <sub><font color="maroon">]</font></sub> 21:37, 23 May 2012 (UTC)
*The problem seems to be continuing, and not getting any better, at least for me. It's really difficult to pull up my watchlist or any edit histories. --] (]) 21:45, 23 May 2012 (UTC)
**and now it seems clear... - ] <sub><font color="maroon">]</font></sub> 21:48, 23 May 2012 (UTC)
***My theory is that we fixed it, by making our comments here.{{Citation needed|date=May 2012}} Works like magic, every time! --] (]) 22:36, 23 May 2012 (UTC)
:According to #wikimedia-tech, it was apparently the same server today that was causing the problem yesterday. It's an older machine that just isn't up to serving en.wp, so it has been removed from duty until it is replaced in a few weeks. —] (]) 22:47, 23 May 2012 (UTC)
::Thanks. It's much better now. --] (]) 23:08, 23 May 2012 (UTC)
:::Yep, it's hell getting old...even for computers, I suppose ;) —] (]) 13:07, 24 May 2012 (UTC)
== ]: rework or delete? ==
The template has simply stopped working. May be it's because ] has changed. But, whatever the reason is, the template either needs serious rebuilding or a total deletion. Otherwise it makes so sense. <span style="text-shadow:grey 0.3em 0.3em 0.1em; class=texhtml"><font face="Kristen ITC" color="deeppink">]</font></span><sup>(] • ])</sup> 17:56, 22 May 2012 (UTC)
== Talk pages messed up for IE 7 ==
I don't know what other users are seeing right, but IE 7 renders Talk pages as a mostly blank page, with only the section headers (and a few other things like sidebars) visible. The positioning of the top div element of the page seems to be off as well, overlapping text underneath. I suspect a CSS fault somewhere. Hopefully it's only my browser, but perhaps other users might be complaining. (Until this is fixed, I won't be able to read any responses here.) — ] (]) 18:05, 22 May 2012 (UTC)
:Why haven't you tried another browser then, instead of leaving us to guess what your problem is? --] (]) 20:50, 22 May 2012 (UTC)
::I'm at work, where we are limited to only IE 7. — ] (]) 15:58, 23 May 2012 (UTC)
: I gave IE7 a quick spin; can't reproduce. Any specific pages you're seeing this on? Does it happen when you're logged out? Any errors reported by the browser? Any other odd behavior on other sites? Any suspicious-looking ] nearby?--]] 21:30, 22 May 2012 (UTC)
:: The problems seem to be gone now, so I'll guess that it was my browser and/or configuration. None of the article pages was affected, and only about half of the Talk pages seemed to be affected. The primary effects were: 1) the first box below the title line appeared to overlay text underneath; 2) the entire page contents did not load, stoppping somewhere at 50%–80% of the page; 3) only the section titles, tables, and images were visible, while none of the normal text was; 4) in the editing pages, most things were visible but some things like the symbol selection div were not. Like I said, the problem appears to be gone now (another day, another reboot), I suspect a local caching problem here on my company's side, but perhaps my experience can be useful to others in the future(?). — ] (]) 15:58, 23 May 2012 (UTC)
== Wikilinking to a subsection? ==
My apologies if this has been answered elsewhere and I'm simply unable to locate; I'm curious if and/or how one can create a wikilink to a sub-section ===3=== or lower? The syntax for doing so would be very appreciated. Thank you. ] (]) 19:14, 22 May 2012 (UTC)
:As long as the subsection name's is unique, you can append the section name after a "#" symbol in the name. For example, this section, I can wikilink as <nowiki>]</nowiki> Alternatively, or if the title's not unique, you can use the template {{tl|anchor}} right after the section header, which you can assign any name, and then link to that anchor name instead. So for example if you put <nowiki>{{anchor|this spot}}</nowiki> in the section you want to link to, you can then link to it via <nowiki>]</nowiki>. --] (]) 19:23, 22 May 2012 (UTC)
:And just adding that this is irregardless of how deep the header is; it is based on the textual content not the level of outline. --] (]) 19:24, 22 May 2012 (UTC)
::Thank you, the 'anchor' was exactly what I was looking for. :) ] (]) 19:35, 22 May 2012 (UTC)
::I think these days you have to encode punctuation, that test link of yours doesn't seem to work in my browser. - ] <sup>] ]'']</sup> 21:03, 22 May 2012 (UTC)
== Reviewing link bug ==
Hey, all. I just noticed a page review link or some annoying "This page has been reviewed" text at the bottom of a lot of pages. What gives? <sub>Is this part of the New Page Feed trial?</sub> --]] 00:10, 23 May 2012 (UTC)
== Turning Sharebox into a gadget ==
We still get once in a while, so I think turning ] into a ] may be a good idea. Personally I ] Facebook, but that is just my POV. Please voice your opinion ]. ] (]) 01:47, 23 May 2012 (UTC)
== Headers ==
Up until yesterday, there was a drop-down menu to insert Headers (L1, L2, L3...). It wasn't there when I woke up this morning, I rubbed my eyes and thought I may still be dreaming. I've now had a strong black coffee and the drop-down menu is still missing. Can anyone tell me what's going on? --<small>] ]</small> 02:36, 23 May 2012 (UTC)
:If you have ] with a right pointing triangle at "Advanced" then click Advanced to see Heading and other options. ] (]) 03:44, 23 May 2012 (UTC)
::THanks, that's what I was looking for. --<small>] ]</small> 04:46, 23 May 2012 (UTC)
== Make it possible to show different content to different users ==
It would be nice to be able to show different content to different user groups (and possibly even individual users). Howzabout implementing that in wiki-syntax? The first proposed use would be to get rid of AIV backlog warning on the admin noticeboards for non admins... If this is better in bugzilla pleas say <span style="background-color:#C0C0C0">] ]]</span> 16:43, 23 May 2012 (UTC)
: I don't know if it's easy to detect if the current user is an admin, but conditionals exist in MediaWiki, we make a fair use of , for example. --]] 18:25, 23 May 2012 (UTC)
:Do you mean the <code>class="sysop-show"</code> from ] and ]? ] 19:17, 23 May 2012 (UTC)
== Fixing redirected pages ==
Is there a tool that can be used to sort out redirects? I need something that will work through the links in a page, and make the piped link point to a new address where the article has been moved to? So for example, at ], Longguan is piped to ]; but as the article has now been moved to ], it's preferable for the pipe be so modified. <nowiki>]</nowiki> will become <nowiki>]</nowiki>. Cheers, --<small>] ]</small> 18:13, 23 May 2012 (UTC)
:You should probably consider whether the changes you want to make are in accord with ], first. ]‑] 19:43, 23 May 2012 (UTC)
::Yes, they are. I asked Ohconfucius to make these changes because many of the articles listed at that page will likely be deleted and re-created (see the ANI thread on User:Jaguar). Better to fix the links now and have the future re-creations at the WP:NC-ZH-compliant titles rather than leaving them as they are and forcing users like me to move them again. ''GotR'' <sup>]</sup> 21:29, 23 May 2012 (UTC)
== Template:Split media ==
Is there a template like {{tl|Split media - processed}} or {{tl|Split media}} for non-free images? I've uploaded new versions of non-free files, and I'd like to request the deletion of the older versions. ▫ ''']''' 21:50, 23 May 2012 (UTC)
:Not sure exactly what you mean, but I think you might be looking for {{tl|Orphaned non-free revisions}}. →<span style="font-family:Euclid Fraktur">]]].</span> 00:33, 24 May 2012 (UTC)
::That's exactly it. I wouldn't have expected it would serve that function based on the name. Thank you. ▫ ''']''' 01:39, 24 May 2012 (UTC)
== Watchlist gremlins ==
I sought help for this issue at the ], but to no avail. Recently, I've been experiencing intermittent disappearances of entries when I display my watchlist. In other words, I have an article on my watchlist, but when I display the watchlist, the most recent edit to it doesn't show up, even though it happened in the time frame my watchlist displays. Then, usually, some time later, it starts showing up again for no apparent reason. It's baffling. Also, it's disturbing because I have a lot of pages on my watchlist, and it's hard to notice the ''absence'' of an entry, so, for all I know, this is happening more often than I'm aware of.--] (]) 22:34, 23 May 2012 (UTC)
:At the top of my watchlist, I have "Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits". What do you have there? - ] <sup>] ]'']</sup> 23:10, 23 May 2012 (UTC)
::Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits --] (]) 23:19, 23 May 2012 (UTC)
:::Your question raised a question for me. I have Show bots above. That means it hides any edits by bots. Does that also mean that if the ''last edit'' was by a bot, it won't show the edit just before the bot edit, i.e., it shows nothing?--] (]) 23:25, 23 May 2012 (UTC)
::::Exactly. That's why I posted this to your original question at ]: "Make sure you are not hiding some entries at ]". It appears you ignored that and instead came here claiming you didn't get help at the help desk. ] (]) 00:03, 24 May 2012 (UTC)
:::::My apologies. I didn't "ignore" it, though, I failed to look before I came here and mistakenly thought the last edit to the topic was the one before yours. Still, my fault for not checking. That explains it perfectly because I recently changed that setting. I don't suppose there's a way to hide bot edits but still see the latest non-bot edit? And to expand on my apology at the risk of sounding fawning, I almost always get the help I need at the help desk. It is hands down my favorite place on Misplaced Pages.--] (]) 00:09, 24 May 2012 (UTC)
::::::Sorry if I sounded harsh. I don't think you can hide some types of edits and still see the latest edit not of those types. ] is about it. Hiding works better if you choose "Expand watchlist to show all changes, not just the most recent" at ]. See ]. ] (]) 00:31, 24 May 2012 (UTC)
:::::::Yes you can. There is a kickass script that does this - and more - courtesy of ]. ] for details. ''] ]'', <small>15:55, 24 May 2012 (UTC).</small><br />
== Pipe separator problems ==
{{resolved|] has been created as clone of ]}}
Please see ] and ]. There is a problem for some editors (not all, though) viewing templates with pipe separators such that they appear with missing spacing – "<span class="mw-usertoollinks">]| ]</span>" rather than "<span class="mw-usertoollinks">] | ]</span>". Could someone please have a look? Thanks. ''']''' <sup>'''] / ]</sup>''' 22:48, 23 May 2012 (UTC)
: Do you have your language preference set to en-gb (or something else) instead of en? I note that ] has been fixed to not screw up when used in parser functions, while ] does not have any such fix. ]] 04:03, 24 May 2012 (UTC)
::Yes, I have <code>en-gb</code>. ''']''' <sup>'''] / ]</sup>''' 09:52, 24 May 2012 (UTC)
:::] says (I wrote it): ''It is not recommended to select "en-GB - British English" or "en-CA - Canadian English" at the language option in preferences. Many interface messages have been customized at the English Misplaced Pages but only for the default selection "en - English". The language option only affects interface messages and not article text.'' ] (]) 11:17, 24 May 2012 (UTC)
::::Actually, this applies to all language options— ] shows the top language setting is <code>es</code>. I have a bit more on this at ]. I made a proposal some time back about the possibility of redirecting messages where the default version has been modified, but there was no participation. ---'''''— ]<span style="color:darkblue"> '''''</span><sup>]</sup> 11:29, 24 May 2012 (UTC)
:::::The problem applies to all languages but if a user chooses a foreign language then the advantage of knowing the language better is often larger than the disadvantage of losing customized messages. Therefore I only disrecommended English variants. See ] ] (]) 12:01, 24 May 2012 (UTC)
This should now be fixed - ] has been created as a clone of ]. --] (]) 15:03, 24 May 2012 (UTC)
:Fixed in en-gb and en-ca but not any foreign language. It seems impractical to create hundreds of identical language pages at ]. It would be nice if MediaWiki gave an option for ] to say "Use this for any language without a customized message". ] (]) 19:14, 24 May 2012 (UTC)
== Black background on Misplaced Pages? ==
Is it possible to view Misplaced Pages with a black (or dark) background? ] <font color="#3CB371">¤</font> <small></font>]]</small> 23:03, 23 May 2012 (UTC)
:Yes, although the green-on-black gadget hasn't yet been updated to work with Vector properly, so you either have to switch to Monobook or put up with the logo in the wrong place. - ] <sup>] ]'']</sup> 23:09, 23 May 2012 (UTC)
:: How do I view it like that? I am a relative novice in this area. ] <font color="#3CB371">¤</font> <small></font>]]</small> 23:24, 23 May 2012 (UTC)
::: Ah, I figured it out, thanks. It's pretty garish! ] <font color="#3CB371">¤</font> <small></font>]]</small> 23:30, 23 May 2012 (UTC)
:::: Very much so. I mean, you can also try and "build your own", but it's a bit more complicated, especially if it takes you a while to work out what actually looks best. - ] <sup>] ]'']</sup> 13:14, 24 May 2012 (UTC)
I am now using the green-on-black format. I find that some users' signatures are not visible. Here are some examples:-
I presume that this is because the users have specified black as the text colour. Can this be adjusted for my viewing? ] <font color="#3CB371">¤</font> <small></font>]]</small> 09:20, 26 May 2012 (UTC)
:You should inform each of these users that their signature fails ] and ], because by explicitly setting a text colour without also setting a background colour, they have made incorrect assumptions about the background colour. If you examine my own signature, you'll see that those portions which explicitly set a text colour also set a background colour - the markup is {{tag|span|params=style="color:#a80000; background:#ffeeee; text-decoration:inherit"|content=Red}}, which shows as having a contrast of 7:1, and shows 7.02:1 - either way, it's WCAG 2 AAA Compliant. --] (]) 12:41, 26 May 2012 (UTC)
== TOC ==
Suddenly ToC is collapsed by default on articles - at least for me. What's happening? ''] ]'', <small>01:25, 24 May 2012 (UTC).</small><br />
:It should remember the last state. If you expand one then are the following still collapsed? It works for me. ] (]) 02:14, 24 May 2012 (UTC)
::Thanks, yes it does - maybe collapsed is the default? Is this another "bugfix"? Pages are crafted to work with their ToC... ''] ]'', <small>14:36, 24 May 2012 (UTC).</small><br />
:::I'm not sure what you say yes to. If you still have problems then try ]. For as long as I know, it has worked so if you collapse one TOC then all following TOC's are collapsed in that browser until you expand one, and then they are all expanded until you collapse one. That is sensible to me and it also works for unregistered users who cannot set preferences. Maybe you accidentally hit a hide link in a TOC. ] (]) 17:44, 24 May 2012 (UTC)
== files in[REDACTED] and commons with same name ==
I was trying to add an image from the commons to ], only to discover that there was an identically named image in wikipedia, which is obviously the image that was displayed. (They were different pictures). I managed to resolve the issue by requesting a file rename for the image in the commons which was approved, although this broke the file's usages in other wikipedias which I had to go fix manually. I feel like there must be a better way. Is there a way to link directly to the commons, ignoring files in the local wikipedia? --] (]) 06:28, 24 May 2012 (UTC)
:No, there isn't: the same syntax is used whether the image is on the local[REDACTED] or on commons - the MediaWiki parser looks locally first, and then on commons.
:Generally, where there is a filename clash, it's best to rename the local image, not the one on commons, because there is likely to be much less work involved. --] (]) 09:21, 24 May 2012 (UTC)
::Thanks for the info. I'll take your advice next time. --] (]) 10:01, 24 May 2012 (UTC)
== Image and Cache Issue ==
Hi,
Thanks a lot
I was directed here from Misplaced Pages's Cache page; I have recently uploaded a new version of . This new version is currently active on . However, there appears to be a caching issue. The image is not being presented correctly on Wikis such as . I have tried purging and, to a certain extent, that has worked. However, if I want to add this image to an article and I press the 'preview' button, the image is shown to be out-of-date and warped. Is there a way to fix this? Is it only a matter of time until the image will be shown properly? Thanks for the help. ] (]) 20:58, 24 May 2012 (UTC)
Yours ] (]) 15:34, 22 January 2025 (UTC)
== What WMF developers are going to be working on for the next year ==
:Query the database. This is most easily done with ] if you don't already have a toolforge account, or asking at ] if you don't speak SQL. (But don't bother with the latter; it'd probably be me that ends up answering you there anyway, and it's not worth moving this unless it gets long.){{pb}}Do you really mean to get a list of pages in the ] tree? There's about 85 categories named "B-Class ..." that aren't in it, and conversely some that are but likely don't categorize b-class articles such as ]. See ] for a full list of each. —] 16:27, 22 January 2025 (UTC)
::Hi,
::thanks for your response. I think I got a toolforge account. So I will try to quarry the database. The reason why I want to work with such a list is my mediawiki2latex program. I want to run it on all class B articles to try if a PDF is created in every case and fix the cases where it does not happen.
::Yours ] (]) 16:51, 22 January 2025 (UTC)
:::This should feasible in ] from ]. ] (]) 20:24, 22 January 2025 (UTC)
::::Hi,
::::when I click "Launch PetScan", I get
::::"Error
::::This web service cannot be reached. Please contact a maintainer of this project"
::::so it seems to be broken ] (]) 09:37, 23 January 2025 (UTC)
::Hi ],
::thanks a lot for you query 90084 example. I am not really used to SQL, but this was a nice opportunity for me to practice SQL. I came up with a modified version of your query, that seems to do what I need ]. I exported it to csv and built a set of the lines, which resulted in 151299 elements, which is the right order of magnitude.
::For my purpose it is good enough, I just need a set of Misplaced Pages articles with not too short content, that I can use as test data for my mediawiki2latex program.
::Thanks a lot for your help. ] (]) 13:35, 23 January 2025 (UTC)
== Retrieving multiple property values in one call of Module:wd ==
In the interests of keeping the community more in the loop, here is a draft of the WMF engineering goals for the next fiscal year:
Feedback regarding any of these projects is welcome on the talk pages of the specific projects on mediawiki.org. ] (]) 22:45, 24 May 2012 (UTC)
I am trying to retrieve multiple property values from wikidata (using Module:wd) in one call but it is ignoring the other properties I give so I only ever get one property value. I must not be giving things in the correct order but none of the Module examples help me. For example, given a mountain name, I want to retrieve the elevation, prominence, mountain range, coordinates and the first ascent significant event. I can get all the values if I code one call per property but how do I code it so I can get all the properties in one call?
:: Thank you! I see a some amazingly cool stuff there. --]] 20:49, 25 May 2012 (UTC)
So given this:
P2044 = elevation
P2660 = prominence
P4552 = mountain range
P625 = coordinates
P793 = significant event; Q1194369 = first ascent; P585 = point in time
:I am fairly certain this cannot be done in that module. ] (]) 21:32, 22 January 2025 (UTC)
== Proxy error ==
::The documentation for the "property" command says "Returns the requested property – or list of properties". Yet, I see no example or syntax of how to specify this list of properties. ] (]) 22:35, 22 January 2025 (UTC)
== Incomprehensible error message ==
I am getting these messages frequently:
Hi, near the bottom of ] is the giant red error message "Lua error in Module:Navbox at line 604: attempt to concatenate field 'argHash' (a nil value)." Does this mean anything to anybody? And, more importantly, can anyone make it go away? Thank you, ] (]) 19:40, 22 January 2025 (UTC)
:The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /wikipedia/en/search/.
:Reason: Error reading from remote server
:Apache/2.2.14 (Ubuntu) Server at secure.wikimedia.org Port 443
:"Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value)." Is it ]? ] ] 20:08, 22 January 2025 (UTC)
I am assuming this is because some server is overloaded. I use the secure login—does that affect which servers are used? Can I do anything other than keep re-sending edited pages? Would I be better off using the non-secure login? --] (]) 01:46, 25 May 2012 (UTC)
:: Whatever has gone wrong is not just related to that - see ] for example, and looks like its broken every navbox at the bottom of articles. It may be related to ].
: Are you using https://en.wikipedia.org/ or https://secure.wikimedia.org/wikipedia/en/? If the latter, try changing to the former. ]] 02:29, 25 May 2012 (UTC)
::I will try the former, as I am using the latter. But I would appreciate getting a tech answer to my initial questions. Tks --] (]) 07:50, 25 May 2012 (UTC)
:::secure.wikimedia.org is deprecated. See ]. ] (]) 12:56, 25 May 2012 (UTC)
:I've reverted a recent change to ] that caused the problem. —] (]) 20:14, 22 January 2025 (UTC)
== Category sortkey problem ==
::Thanks {{u|Bkell}}! ] ] 21:12, 22 January 2025 (UTC)
== Wayback Machine not archiving new links? ==
This problem is stumping me, and I have to leave for the airport in 50 minutes so I don't have much time to work on it. Why does ] sort under the wrong place in ]? It should be under "Operas" but it's the first entry in the list. ''']'''<font color="green">]</font> 02:13, 25 May 2012 (UTC)
: Well, it was sorting as the first entry in the list because ] had an extra space when it was constructing the category link. But fixing that makes it be under "1" instead of "o" in the category, so something in ] still isn't quite right. Perhaps it should be redone along the lines of one of the templates for the other categories. ]] 02:27, 25 May 2012 (UTC)
::Fixed in after reading the documentation of {{tl|Year by category}}. ] (]) 11:00, 25 May 2012 (UTC)
::: Nifty! ]] 11:34, 25 May 2012 (UTC)
::::Indeed! Thanks, guys. ''']'''<font color="green">]</font> 01:19, 26 May 2012 (UTC)
:A prime example of why content categories should not be in templates. ''] ]'', <small>12:18, 26 May 2012 (UTC).</small><br />
Obviously this is beyond the scope of Misplaced Pages, but it seems to be impossible to find snapshots of new links that can be archived at the moment. It simply produces an error message such as "Fail with status: 498" or "We're sorry — something's gone wrong. Our team has been notified." This is a nuisance as archiving links via the Wayback Machine is important. Are other people having this problem? '''''] <sup>]</sup>''''' 20:03, 22 January 2025 (UTC)
== Access to Article Feedback Tool Data ==
== Parent categories ==
Hi,
I am interested to know whether it is possible to get access to Article Rating Data. I have found data on the earlier version, which covers the period of 2011march-september, but I would like to use the latest data. In case that is not public yet, is there any chance it also will be accessible in the future; and if so when approximately? Thank you in advance! <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) 19:20, 25 May 2012 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
:Historical data dumps collected via ] as well as weekly data dumps from the current AFT version are available for ], but only for English Misplaced Pages. All dumps are available as compressed CSV files and are released under a . Real-time anonymized AFT data is also via the ]. Version 5 of the Article Feedback Tool is now under development by the Wikimedia Foundation. This will be a huge improvement compared to older versions of the AFT because ] will actually be useful. ] (]) 12:58, 26 May 2012 (UTC) p.s. If you have any questions about the AFT its probably best to ask people like ] or ].
An editor has ] to the way we display categories in the Category: namespace. The existing system, which looks approximately like this:{{box|]: ], ], etc.|border color=lightgray}}does not seem intuitive. @] figured out ] to something that makes the meaning more obvious:{{box|]: ], ], etc.|border color=lightgray}}''and'' to have this only appear in the Category: namespace (i.e., will not change/screw up any articles).
== replacing references temporarily ==
Could we please get this change implemented here? It would only require copying the contents of ] to ].
Using Perl, I've slurped an article.
::
I need to match the first sentence of the article, but intervening references with a period in them create an ambiguity so the script does not find the period at end of the sentence (it finds the period in the embedded reference instead).
::
::
] (]) 20:18, 22 January 2025 (UTC)
So, I'd like to be able to save references off and put them back again into the first sentence after I've extracted and processed it.
:This sort of sounds like it would be an overall general improvement - that is not something special for only the English Misplaced Pages, and for only users with their interface language in en. If so, this should be requested upstream. — ] <sup>]</sup> 01:56, 23 January 2025 (UTC)
How can this be done? ] 21:41, 25 May 2012 (UTC)
::I think it'd be better to do this locally, where it's been requested. If it seems to be a net improvement, we could always suggest it for widespread use (which would require re-translation of the string for all 300+ languages – not something that can happen quickly). ] (]) 03:44, 23 January 2025 (UTC)
== Nonsense redlink ==
:Assuming you have the entire article in a scalar, I'd use a regex something like this (you'll need to add in other weird reference type coding, but you get the idea): <code><nowiki>if ($article =~ m$^(.+?)(<ref>.+</ref>)?(.*?)?\.$){$first_sentence = "$1" . "$3"}</nowiki></code>. In case you don't know, the ? following + makes it non-greedy, which is probably important for what you're trying to do. ] (]) 23:06, 25 May 2012 (UTC)
::That won't work if there's more than one <ref> element in the document and the first sentence ends between them. Something like this should work: <code><nowiki>m$^(<ref>.*?</ref>|.)*?\.$</nowiki></code> (the sentence ends up in <code>$&</code>). You need to replace the <code><ref></code> part with something that will actually match all <code>ref</code> open tags (perhaps just <code><ref</code> would work) and you will have to deal with empty tags as well. And I'm sure there are other bugs. I wish MediaWiki syntax wasn't such a mess. -- ] (]) 23:44, 25 May 2012 (UTC)
:::Did you test that? I don't think it will catch the refs at all, because it should treat the entire OR as a single token... I'll test it in a minute. ] (]) 00:22, 26 May 2012 (UTC)
::::Ok that works. I learned something new (could you tell me where I went wrong? I'm surprised the () group allows alternate versions like that). As an aside, you're gonna have practical problems with this script with things like infoboxes, and other templates, the IPA template, for example, has lots of periods in it that will cause you problems. You might do something like ensure a space after the period, which would cut down on some of these. ] (]) 00:27, 26 May 2012 (UTC)
:::::In your code, the initial <code>.+?</code> means that <code><ref></code> will match the first occurrence in the file, but the following <code>.+</code> means that <code></ref></code> will match the last occurrence, which may be too late. If that <code>.+</code> is replaced with <code>.+?</code>, it will match the first occurrence of <code></ref></code>, but in that case it will fail if there's a second <ref>...</ref> in the first sentence which has a period in it.
:::::<code>|</code> is an infix operator that has lower precedence than concatenation (which is the only other infix operator, I think), and you can override that with any kind of parentheses. In older regular expression syntaxes parentheses were only used for grouping (as in mathematical expressions), but Perl uses them for capturing groups and has the ugly (?:...) syntax for pure grouping parentheses. I should have used (?:...), but I wanted the expression to be slightly more readable.
:::::Since Perl tries the leftmost alternative first, it will match <code><ref>.*?</ref></code> (a single reference) if it can. Otherwise it will advance by one character (matching <code>.</code>) and try again. Actually, this is buggy: if there's no period in the whole article outside of <ref>...</ref> pairs, it will backtrack and find a period inside a ref, which is probably not what you want. To fix that you would need to control backtracking somehow. I think that <code><nowiki>m$^(<ref>.*?</ref>(*PRUNE)|.)*?\.$</nowiki></code> will work, but I've never actually used <code>(*PRUNE)</code> before. This expression still has a lot of problems, and Misplaced Pages being what it is I bet there are a lot of pages that will trigger those problems. -- ] (]) 06:09, 26 May 2012 (UTC)
:::::::Using ?: has two main advantages, reducing processing time and readability. The first (as I understand it - later versions of perl may be smarter) only applies if it is used for all groups, and is negligible in most cases, the second is somewhat subjective. I tend to use it where branching selections would give different numbers, this is relatively rare and I have not looked for better solutions. ''] ]'', <small>12:53, 26 May 2012 (UTC).</small><br />
:::The big extra thing these regexes need to match is something like <ref*/> for named refs - and indeed the valid but meaningless <ref />.''] ]'', <small>13:02, 26 May 2012 (UTC).</small><br />
:Further to the extra comments you made on my talk page about replacing the refs temporarily with XXXXX:
:This process is called "strip marking" and is used by a number of processes including the MediaWiki software, AWB and the perl code for Helpful Pixie Bot and Pixie. There are several issues to account for:
:# Assumptions. Depending on what you can assume you can make the process more or less simple. The following items can be ignored if simplifying assumptions can be made.
:# No mis-matches. Sufficiently bad mis-matches means you have to throw the idea away (at least partly), and find another strategy. Sufficiently bad means:
:#: p(mis-match)* damage > threshold
:# Nesting - code should deal with arbitrary levels of nesting if needed
:# Removal - if the stuff surrounding thing you are stripping is removed, should it stay?
:# Matching the strip marker. This has tripped me up using AWB (and indeed the coder's response to the bug I logged is how I know AWB uses strip markers).
:# Conversely no aliases for strip markers. "Strip marker" would be a bad strip marker (in general), as would anything you might find on a WP page. I might suggest for generality using a bunch of Unicode characters form obscure planes (or even illegal Unicode characters if perl will let you get away with them - these should provide extra belt-and-braces if you check for legality before you write the page). But for this case even your "XXXXX" might well suffice.
:# Replacement - if you can be sure the whole thing is simple you can push the items onto a stack (array) and pop them back afterwards. This is effectively an ] argument - and the way Pixie does it (though recursively in some cases - which is rather elegant in its way). If, however, you might re-arrange paragraphs you need to use something smarter - a hash for example. Strip-mark with a unique strip mark for each item (remembering how this affects the above point) and replace by iterating through the hash or strip markers - removing the items from the has h as you go. If the hash deos not end up empty, flag an exception.
:''] ]'', <small>12:53, 26 May 2012 (UTC).</small><br />
Twice in the past three days, AnomieBOT has created the entirely unpopulated maintenance category {{cl|Articles lacking reliable references from 2025-01-19 from January 2025}}, which has in turn generated a nonsense redlink for {{cl|Monthly clean-up category (Articles lacking reliable references from 2025-01-19) counter}} — but since YYYY-MM-DD is not part of our naming format for either "Articles lacking reliable references" or "monthly clean-up category" maintenance categories, neither of these are categories that should ever exist at those names at all. But when I deleted the referencing category as both nonsense and empty earlier today in order to blow up the monthly clean-up redlink, the bot came along and recreated it again a few hours later even though it's still both nonsense and empty.
::Try ]. ---'''''— ]<span style="color:darkblue"> '''''</span><sup>]</sup> 13:25, 26 May 2012 (UTC)
Could somebody look into this and figure out how to make it stop? I haven't deleted the category again this time, though I have wrapped the template in {{tl|suppress categories}} since the redlinked parent still needed to go away regardless. Thanks. ] (]) 01:29, 23 January 2025 (UTC)
== Issue with College Baseball Template - But Only Once ==
:The somewhere to ask about this begins here: ]. — ] <sup>]</sup> 01:53, 23 January 2025 (UTC)
In the ] article, the <nowiki>{{cbsb link}}</nowiki> template is used frequently. It works for the most part, but for some reason displays "Missouri Tigers baseball" in the first round of the "Bracket" section. It works fine in the standings. Manually changing and unchanging the display field failed to resolve the problem. ] (]) 21:55, 25 May 2012 (UTC)
: AnomieBOT created that because ] existed. ]. ] ] 02:43, 23 January 2025 (UTC)
:: More specifically, because ] existed and was in ]. As the latter says, {{tq|A bot, currently ] and formerly ], will monitor the categories in this category and create the necessary monthly subcategories.}} ]] 12:54, 23 January 2025 (UTC)
:{{replyto|Bearcat|Xaosflux}} It's not the fault of AnomieBOT. The problem stems from {{diff|2024–25 European windstorm season|1270527703|1270470545|these two edits}} by {{user|En rouge}}, who added more than fifty instances of {{tlx|Irrelevant citation}}, each of which used {{para|date|2025-01-19}} and not {{para|date|January 2025}} as advised by the template doc. They also manually created {{cl|Articles lacking reliable references from 2025-01-19}}, which has since been deleted. --] 🌹 (]) 10:08, 23 January 2025 (UTC)
::Some input validation could help there. — ] <sup>]</sup> 10:22, 23 January 2025 (UTC)
== asterisks ==
:Fixed by removing a wrong capitalization. ] (]) 23:10, 25 May 2012 (UTC)
*List item
== Rollback now displays "(warn using TW)" when complete ==
**Second level list item
***Third level list item if there's a line separating this from the previous list item
After completing a rollback, the diff page used to say:
^^ Why is this the default behavior for multiple asterisks? Does anybody ever actually ''want'' every asterisk to render as an additional dot? Why isn't *** by default just a twice indented bulletpoint, even if not immediately preceded by a once indented bulletpoint? This silliness is why many people wind up starting lines with e.g. :*:::: or :::::*, which if I recall correctly isn't ideal for accessibility. At minimum, given the ubiquity of unordered lists in wiki discussion pages, shouldn't indents be the default behavior (with perhaps some template for anyone with a weird multi-bullet use case)? — <samp>] <sup style="font-size:80%;">]</sup></samp> \\ 03:46, 23 January 2025 (UTC)
:Reverted edits by Username (talk | contribs | block) to last revision by Bongwarrior (talk | contribs | block).
:Because any ‘lists’ with newlines between them are not actually one united list. See ]. Sadly MediaWiki does not make this ''obvious enough'', if anything, but both are bad for accessibility. Editors should be advised not to insert blank lines between list items, or at least to insert them as blank lines with indentation (<code>*** <blank></code>), as that would generate a hidden empty list item that would unite the markup. ] 04:59, 23 January 2025 (UTC)
{{outdent|:}} It becomes immediately obvious when using hashes to make an ordered list:
#List item
##Second level list item
###Third level list item if there's a line separating this from the previous list item
But today it says:
Notice the lack of an item numbered 2. This is such a long-established feature of the MediaWiki software that it's unlikely to be changed. But you can use CSS to highlight the problematic markup. Here's a quick-and-dirty rule that draws a thick dashed red line in the gap of the first example above: <syntaxhighlight lang=css>ul+ul { border-top: 2px dashed red; }</syntaxhighlight> --] 🌹 (]) 23:43, 23 January 2025 (UTC)
:I actually have a user style called ] (in Russian Misplaced Pages) that highlights a bunch of accessibility/markup-related issues like this, including one mentioned here. I mostly advertised it on Discord, though.<br><small>(Recently I’ve been thinking of turning it into a user script that can then provide more refined suggestions, since CSS can have too many false positives if you try to write, for example, a rule specifically for a list containing only another list.)</small><br>— ] 00:33, 24 January 2025 (UTC)
== PetScan down or broken ==
:Reverted edits by Username (talk (warn using TW) | contribs | block) to last revision by Bongwarrior (talk | contribs | block).
Hi, For , when launched, it shows
What is the "(warn using TW)" addition all about? I haven't noticed any extra functionality, and it looks kind of ugly and unnecessary to me. I'm not sure if it was a Twinkle change, a MediaWiki namespace change, or something related to the MediaWiki 1.20wmf3 deployment, but I felt that, for the good of the project, it was important to make my displeasure known. --] (]) 04:01, 26 May 2012 (UTC)
''Error: This web service cannot be reached. Please contact a maintainer of this project.''. Needed to run an hour ago and still fails. Will check again later today. Regards, ] (]) 14:32, 23 January 2025 (UTC)
:It was a Twinklechange. Prior to this,thelink to thetalkpagewas ''']'''. →<span style="font-family:EuclidFraktur">]]].</span> 05:58, 26May2012 (UTC)
:It's been down for a couple of days. It doesn't appear to have any current documentation as to active maintainers. — ] <sup>]</sup> 15:28, 23 January 2025 (UTC)
::It only accepts bug reports on github, where there is now. Github isn't really good for operational bugs, just software ones... This is another project with a lack of active onwiki volunteers unfortunately. — ] <sup>]</sup> 15:31, 23 January 2025 (UTC)
:::Only maintainer linked is ], who is still active on wikidata. Similar to the geohack outage (]) above -- needs an operator to possibly work with the cloud team. — ] <sup>]</sup> 15:35, 23 January 2025 (UTC)
::::@] - Thank you for digging into this issue. PetScan really is a great tool for category filtering of articles. I regularly use to find Unreferenced + Orphan articles combination. For now, "Plan B" is to search thru just the old Unref. articles. Yes, it would be great to find an expert to: 1. Identify what is broken; 2. Fix it. There are some Bots that occasionally fail off & need to be restarted. Cheers, ] (]) 17:41, 23 January 2025 (UTC)
::::: shows that Magnus Manske is the only maintainer. Since this is a very important tool, I think the Wikimedia Cloud team can help restart the web service if Magnus is not available. – ] <small>(])</small> 18:04, 23 January 2025 (UTC)
: Why Misplaced Pages has no own tools like PetScan? ] (]) 21:13, 23 January 2025 (UTC)
== source editor parameter? ==
== ] does more than a sandbox should ==
Hi, perhaps having brain clouds... is there a parameter that can be passed to open a page for immediate editing in the source editor? ] suggests action=submit will do it, but it does not. Thanks, — ] <sup>]</sup> 23:12, 23 January 2025 (UTC)
I made edit when playing with the <tt>action=edit</tt>. Does anyone know how one reports this sort of issue? →<span style="font-family:Euclid Fraktur">]]].</span> 06:14, 26 May 2012 (UTC)
:What's wrong with <code>action=edit</code> ? --] 🌹 (]) 23:49, 23 January 2025 (UTC)
:I'm not clear what the issue is. But the answer is probably Bugzilla. ''] ]'', <small>12:27, 26 May 2012 (UTC).</small><br />
::For example https://en.wikipedia.org/Art_Building_and_Annex?action=edit that link does not open the page for immediate editing, nor does https://en.wikipedia.org/Art_Building_and_Annex?action=submit ; they both open the page with an interstitial popup asking which editor you would like to use. I'm looking for a solution to bypass that beside having already stored a cookie for it. — ] <sup>]</sup> 23:54, 23 January 2025 (UTC)
== Page top edit counter down ==
== Is there any technical reasons to keep Category:Hidden Categories a hidden category? ==
Forgot what you call this. But every page on top has a little updated notice on how many views, etc. have been on that page. This is not browser specific, in my case. I have three browsers, and it's the same on all of them. Now I see a little left-hand dot moving back and trying to load the page stats. But it just keeps going back and forth with no results. ] (]) 23:31, 23 January 2025 (UTC)
I don't think ] should be hidden... and now it contains itself... ] (]) 07:23, 26 May 2012 (UTC)
:Sounds like a user script, or a gadget. It's certainly not a standard feature. --] 🌹 (]) 23:47, 23 January 2025 (UTC)
:No there is no reason for this. ''] ]'', <small>12:09, 26 May 2012 (UTC).</small><br />
::Sounds like the XTools gadget which I have – and now notice isn't working. ] (]) 23:51, 23 January 2025 (UTC)
::{{Fixed}} ''] ]'', <small>12:17, 26 May 2012 (UTC).</small><br />
:::XTools gadget isn't maintained here, for help with it see ]. — ] <sup>]</sup> 23:56, 23 January 2025 (UTC)
::::Whatever it's called, it is working perfectly now. To the left of it, is a little colored "Assessment" button. I just discovered that if I click on it, it takes me directly to XTools. ] (]) 00:12, 24 January 2025 (UTC)
== Constantly getting semi-logged out ==
== Featurerequest for ] ==
By "semi" I mean I only have to click "log in" to get back in, not fill in my password or anything. But still annoying to have Vector2022 constantly flash onto my screen. This has been happening last three days or so, sometimes as often as every ten minutes. ] (]) 23:52, 23 January 2025 (UTC)
I have a featurerequest for an expert programmer; ] sometimes mistakes the text in the commentbox as the name of the author which results in of . "Meld je aan of registreer je om een reactie te plaatsen!" is Dutch and means "Login or register to comment".. It may be possible to get it to fetch the author's name correctly but if not the easiest hack would be to simply disallow a couple of strings. Unfortunately ] does not communicate anymore. ] (]) 13:29, 26 May 2012 (UTC)
Latest revision as of 00:33, 24 January 2025
Page for discussing Misplaced Pages technical issues
If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
The following edits and show a different heading (corresponding to the section being edited) in the edit summary than edits (which was made using the convenient discussions tool) and (which was made using the reply tool). When navigating from the history view, clicking on the heading in the edit summary for the first two edits results in a popup saying This topic could not be found. It might have been deleted, moved or renamed. I made my edit using the default wikitext editor. Does anyone know why it would produce an incorrect heading in the edit summary? isaacl (talk) 19:34, 17 January 2025 (UTC)
Sure; just wondering why the behaviour is inconsistent with the reply tool and the default wikitext editor (I would have thought the same code would be used to generate the heading for both use cases, but I guess not). isaacl (talk) 19:48, 17 January 2025 (UTC)
@Isaacl: Your post was confusing because your third link was the same as the second and you didn't clarify what was supposed to be different. The wikitext of the actual heading says Dark mode and {{tl|Yes}} which renders as "Dark mode and {{Yes}}" without tl being displayed. Your second link uses the wikitext with tl in the edit summary and fails to link to the section. Your third link should have been where the edit summary uses the rendering without tl and links correctly to the section #Dark mode and {{Yes}}. Different discussion features apparently use different ways to generate the automatic section edit summary and one of them works better in this case. phab:T69068 from 2014 is about the issue. Misplaced Pages:Manual of Style#Section headings (which doesn't apply to project space) says "For technical reasons, section headings should: ... Not contain template transclusions." PrimeHunter (talk) 20:46, 17 January 2025 (UTC)
My apologies for the copy and paste mistake for the links. Yes, obviously the edit summaries and underlying link text are being generated in different ways. I was wondering if it is a visual editor vs default wikitext editor difference, or something else? And if it was fixed for visual editor, was there an issue in following the same approach for the wikitext editor (maybe the fix was just partial, or not sufficiently resilient?). But I'm not asking for anyone to do any deep research on it. If someone knows off the top of their head, it would be nice to know. Thanks for the Phabricator link; it helped provide some context. (I know about the style recommendation for section headings; thanks for the reference.) isaacl (talk) 23:31, 17 January 2025 (UTC)
Basically, this happens because the wikitext editor generates the edit summary directly from the wikitext of the heading, while the visual editor generates it from the parsed HTML of the page. The HTML contains the id attribute needed to make the correct link, but generating the correct link from the wikitext would require parsing it to HTML first, and most of the tools don't bother to do that.
The same applies to other wikitext-based editing tools and other HTML-based editing tools. There are more tasks in Phabricator about this, T234982 is a good summary and has even more links.
The only wikitext-based tool I know that does this better is DiscussionTools's new topic tool's wikitext mode, where we solved it as a side-effect of T338390 – we needed to parse the HTML for some other reasons, and once that was implemented, adding a bit of code to read the id attribute out of it was easy. In principle the same approach could be used in other editors, but it is tricky to get the data from point A to point B, especially without affecting performance, and no one has put in the effort to do it yet. Matma Rextalk23:23, 18 January 2025 (UTC)
Is it just me or is File:Misplaced Pages page mover.svg somewhat broken? I'm getting "Sorry, the file cannot be displayed There seems to be a technical issue. You can retry if it persists. Error: could not load image from https://upload.wikimedia.org/wikipedia/commons/thumb/4/4b/Wikipedia_page_mover.svg/1024px-Wikipedia_page_mover.svg.png" when clicking the image on Misplaced Pages:Page mover. I have tried on Firefox, Chrome, Edge, iOS Safari with or without safemode, all yield the same results. However, clicking the original file doesn't generate the same error. — Paper9oll (🔔 • 📝)13:36, 19 January 2025 (UTC)
We currently have a gadget that makes disambiguation links orange, which makes correcting said links much easier. Would it be feasible to create something similar for redlinks to articles that have previously been deleted? For instance, let's say I'm writing an article on an academic named Joe Bloggs, who published a significant work cowritten by Joe Public. I believe Joe Public is notable, but he does not currently have a Misplaced Pages article, so I create a redlink. However, I failed to check the page's deletion log (!!), which shows that an article on Joe Public did once exist, but it was deleted after its subject was found to lack sufficient independent coverage. Now imagine if I had a gadget that made that redlink purple (or pink, or maroon, or black; I'm not picky), so I would know at a glance to not bother to create a link for a person who has already been determined to not meet notability criteria. It would also make it easier to spot and correct such links while looking through other articles. Much like with the existing gadget I mentioned, this is, of course, still a process that can be done manually, but a gadget would make it much more efficient. Anonymous19:22, 18 January 2025 (UTC)
@An anonymous username, not my real name: MediaWiki adds the class mw-disambig to links to disambiguation pages like St. Mary's Church. This means the gadget only has to say links with that class should be orange. The entire code of the gadget is one line in MediaWiki:Gadget-DisambiguationLinks.css and it's client-side with no impact on the servers. MediaWiki does not add a class to red links with a deletion log like Corruption in Wales. A gadget would have to make an API call to the servers for each red link on a page to check for deletion logs. I don't think that's worth the server load even if somebody would make the non-trivial code. PrimeHunter (talk) 20:33, 18 January 2025 (UTC)
The script, as noted, only has to hit the servers for redlinks. More broadly Don't worry about performance, that's the server admins' job. If it became a problem they would alert us. There is also a lot of caching in user agents as well as the WMF servers, and this is only doing reads so it hits the caches. --Slowking Man (talk) 01:34, 19 January 2025 (UTC)
I don't know that I'd implement such a request. Most of what linkclassifier does is based on categories (a little is based on page props). To do this, it'd have to query the logs for each page, which is a whole different thing. Anomie⚔15:04, 19 January 2025 (UTC)
Just because a page has previously been deleted, you can't assume that the article you were going to create would fail our notability criteria. Notability is far from the only deletion criteria, and especially if you are creating articles on people, you can't always assume that the person you were going to write about is the same person as the adolescent pro skateboarder whose article was deleted fifteen years ago. They may just have the same name. That said, some sort of colour coding or pop up that alerted you to there being a previous article of that name and the reason and recency of deletion might be helpful. New page patrol has a recently deleted colour which usually indicates that someone is repeatedly trying to create a particular article. ϢereSpielChequers06:59, 20 January 2025 (UTC)
Do certain configuration templates need to be in the first n bytes of a page?
I have a vague recollection that certain templates need to be in the first n bytes of a page? I'm thinking of templates like these:
Moving configs somewhere else which CS1 relies on is likely to have a non-zero increase on the Lua execution time associated with a page. (These metadata are incidentally good candidates to move to something like mediawikiwiki:MCR since they definitely don't need to participate in transclusion and are otherwise pretty simple settings.)
Title templates are there because they modify the title though you could theoretically move them.
Archiving template is there because it would otherwise get lost by archiving of threads + addition of new threads. Izno (talk) 20:31, 18 January 2025 (UTC)
AFAIK the only one that is position-critical is {{User:MiszaBot/config}}, which must be before the first section heading (of any level), i.e. in the lead section. This is to guard against it being accidentally moved to an archive, which might happen if it were placed inside a section (or subsection) which became archived. It's possible that {{CS1 config}} might need to be before the first WP:CS1/WP:CS2 template, but not if the relevant JavaScript function(s) has been written carefully. The others are definitely position-independent, but do have conventional positions, summarised at WP:LEADORDER. --Redrose64 🌹 (talk) 22:09, 18 January 2025 (UTC)
Module:Citation/CS1/Configuration reads article wikitext looking for {{CS1 config}}, {{use dmy dates}}, and {{use mdy dates}} (and any of their redirects). Of course, the earlier these appear in the wiki text, the less work the module needs to do. But, if none of them appear in the wikitext, the module still must scan all of the wikitext to be sure that none of them exist so placement really doesn't matter. Scanning for the {{use xxx dates}} could be made faster by eliminating some of the several redirects but that suggestion has already been dismissed dismissed (permalink).
I've enabled the gadget that pops up a micro-summary of an article whenever I mouse over a link to it. Unfortunately, it's not working properly with redirects. For example, if visit Serial comma#Mainly British style guides opposing typical use, I'm given the following text: I dedicate this book to my parents, Martin Amis, and JK Rowling. If I mouse over the first link, I get a picture of Amis and this text:
Sir Martin Louis Amis (25 August 1949 – 19 May 2023) was an English novelist, essayist, memoirist, screenwriter and critic. He is best known for his novels Money (1984) and London Fields (1989). He received the James Tait Black Memorial Prize for his memoir Experience and was twice listed for the Booker Prize (shortlisted in 1991 for Time's Arrow and longlisted in 2003 for Yellow Dog).
However, if I mouse over the second link, I get this text:
JK Rowling ⋅ actions ⋅ popups Redirects to J. K. Rowling ⋅ actions
Is there a way to change this, so that the popup shows the target of the redirect (as if the link went to the target), rather than the redirect itself? I can't imagine a reason why we should care whether it's an article or a redirect. The documentation suggests that identifying pages as redirects helps people fix them, but You probably don't want to "fix" such links every time you come across them, and WP:NOTBROKEN actively prohibits changing those redirects without some alternate reason, e.g. it's fine to replace "JK Rowling" with "J. K. Rowling" if we want the full stops and space to appear in the article, but not good to edit the article just to change ] to ]. If there are any legitimate uses for distinguishing redirects from articles with this tool, that's different, but as far as I can see, it merely gets in the way of using this tool. Nyttend (talk) 22:12, 19 January 2025 (UTC)
@Nyttend: The first time I hover over a redirect like JK Rowling after loading or reloading a page, I see text from the target below the text you quoted. If I come back to hover over the same link, I only see what you quoted. PrimeHunter (talk) 23:58, 19 January 2025 (UTC)
Hi, Good day. I am having trouble loading Huggle as no list of articles/edits is shown on it. Below are the system logs.
Mon Jan 20 13:09:53 2025 Failure of feed provider XMLRCS on enwiki, trying to find some alternative provider
Mon Jan 20 13:09:53 2025 ERROR: XmlRcs failed: redis is empty for 10 seconds
Kindly advise me on what I can do or point me to the right editor/talk page for help. (I didn't go to the Huggle talk page for this issue, as the talk page is not very active and, at times, no one replies to messages. Thank you. Cassiopeiatalk02:24, 20 January 2025 (UTC)
Hi, Good day. I am having trouble loading Huggle as no list of articles/edits is shown. Below are the system logs.
Mon Jan 20 13:09:53 2025 Failure of feed provider XMLRCS on enwiki, trying to find some alternative provider
Mon Jan 20 13:09:53 2025 ERROR: XmlRcs failed: redis is empty for 10 seconds
Kindly advise me on what I can do or point me to the right editor/talk page for help. (I didn't go to the Huggle talk page for this issue, as the talk page is not very active and, at times, no one replies to messages. Thank you. Cassiopeiatalk02:17, 20 January 2025 (UTC)
Frost Thank you for your reply. No, I have never have this issue and this is the first time after using Huggle for many years. How do I set to IRC or Wiki as provider? (note: I am not technical). Thank you. Cassiopeiatalk02:41, 20 January 2025 (UTC)
On January 17 I uploaded the image LMC SMC Bab al Mandab.png, which shows the present (2025) position of the Large and Small Magellanic Clouds over the southern horizon. I have now created an accompanying image, LMC SMC Bab al Mandab_900.png, which shows the same thing as seen in the year 900. If possible, please rename the first image LMC SMC Bab al Mandab_2025.png.
If this is not the proper page for such a request, please advise. AstroOgier (talk) 09:14, 20 January 2025 (UTC)
@AstroOgier: You uploaded this file to Wikimedia Commons so you will need to request a rename there. You can read Commons:File renaming for guidance on how to rename a file. To rename this file, you can simply add the {{Rename|File:LMC SMC Bab al Mandab_2025.png|1|reason=your reason here}} template to the file description on the file page. Please don't forget to add your reason in the reason parameter. – DreamRimmer (talk) 09:45, 20 January 2025 (UTC)
When the links in the table showing the stubs, A class B class etc. are clicked on, it just goes to a blank-ish page. I suspect that there is something to do with the slash it the name, but I hope someone knows a solution. APenguinThatIsSilly("talk") 18:50, 20 January 2025 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
Administrators can mass-delete multiple pages created by a user or IP address using Extension:Nuke. It previously only allowed deletion of pages created in the last 30 days. It can now delete pages from the last 90 days, provided it is targeting a specific user or IP address.
On wikis that use the Patrolled edits feature, when the rollback feature is used to revert an unpatrolled page revision, that revision will now be marked as "manually patrolled" instead of "autopatrolled", which is more accurate. Some editors that use filters on Recent Changes may need to update their filter settings.
View all 31 community-submitted tasks that were resolved last week. For example, the Visual Editor's "Insert link" feature did not always suggest existing pages properly when an editor started typing, which has now been fixed.
Updates for technical contributors
The Structured Discussion extension (also known as Flow) is being progressively removed from the wikis. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. The last group of wikis (Catalan Wikiquote, Wikimedia Finland, Goan Konkani Misplaced Pages, Kabyle Misplaced Pages, Portuguese Wikibooks, Wikimedia Sweden) will soon be contacted. If you have questions about this process, please ping Trizek (WMF) at your wiki.
The latest quarterly Technical Community Newsletter is now available. This edition includes: updates about services from the Data Platform Engineering teams, information about Codex from the Design System team, and more.
I'm tracking a LTA account who frequently IP hops within the same session eg. they might switch IP 6 or 7 times within 30 minutes. However they appear to be limited to certain A or B classes which in theory makes tracking possible. But in practice anything bigger than a C is hard. For example class C Special:Contributions/5.90.7.* is doable but class B Special:Contributions/5.90.* is not, and certainly not class A 5.* .. (I have "JavaScript-enhanced contributions lookup 0.2 enabled", your results may look different from mine.)
Question: is there a tool to filter Class A or Class B based on time frame eg. show all edits within this Class A between 10:40 and 12:40 on Jan 20 on Enwiki. -- GreenC15:03, 21 January 2025 (UTC)
I've long thought that the CIDR gadget is pretty much deprecated since the functionality was built in to the contributions page (there are probably still a couple of niche uses, but not many). The contributions page allows you to filter by range and date... For this /16 range the link looks like (there are no contributions on the 20th and it won't filter by exact time). Won't that suffice? -- zzuuzz15:14, 21 January 2025 (UTC)
Thanks John. Start is end. End is start. The docs mention this but somewhat confusingly. The default is |ucdir=older, which requires ucstart to be higher than ucend. The original will work with |ucdir=newer enabled: .. probably |ucdir=newer should be the default because counting backwards is.. backwards. -- GreenC01:22, 22 January 2025 (UTC)
Some table classes yet to be adapted for Dark Mode
An example can be found at Javanese script, where each cell features a white background with invisible transliteration:
Some Javanese letters and their Balinese equivalents
haꦲ
naꦤ
caꦕ
raꦫ
kaꦏ
aꦄ
āꦄ
iꦆ
īꦇ
uꦈ
ūꦈꦴ
ᬳ
ᬦ
ᬘ
ᬭ
ᬓ
ᬅ
ᬆ
ᬇ
ᬈ
ᬉ
ᬊ
Does this imply that all classes labeled letters-* haven't been updated for Dark Mode yet?
I would like to get a list of urls to all class B articles. I know programming. But from what I could figure out up to now, it seems quite tedious to go to Category:B-Class_articles and do all subcategories in a recursive manner and change targets from talk pages to the actual articles. Is there any easier way to do it?
thanks for your response. I think I got a toolforge account. So I will try to quarry the database. The reason why I want to work with such a list is my mediawiki2latex program. I want to run it on all class B articles to try if a PDF is created in every case and fix the cases where it does not happen.
thanks a lot for you query 90084 example. I am not really used to SQL, but this was a nice opportunity for me to practice SQL. I came up with a modified version of your query, that seems to do what I need quarry:query/90125. I exported it to csv and built a set of the lines, which resulted in 151299 elements, which is the right order of magnitude.
For my purpose it is good enough, I just need a set of Misplaced Pages articles with not too short content, that I can use as test data for my mediawiki2latex program.
Retrieving multiple property values in one call of Module:wd
I am trying to retrieve multiple property values from wikidata (using Module:wd) in one call but it is ignoring the other properties I give so I only ever get one property value. I must not be giving things in the correct order but none of the Module examples help me. For example, given a mountain name, I want to retrieve the elevation, prominence, mountain range, coordinates and the first ascent significant event. I can get all the values if I code one call per property but how do I code it so I can get all the properties in one call?
So given this:
P2044 = elevation
P2660 = prominence
P4552 = mountain range
P625 = coordinates
P793 = significant event; Q1194369 = first ascent; P585 = point in time
how do I get all the property values in one call?
{{#invoke:wd|property|P2044|P2660|P4552|P625|property|qualifier|P793|Q1194369|P585|page=Mount Robson}} RedWolf (talk) 19:10, 22 January 2025 (UTC)
The documentation for the "property" command says "Returns the requested property – or list of properties". Yet, I see no example or syntax of how to specify this list of properties. RedWolf (talk) 22:35, 22 January 2025 (UTC)
Incomprehensible error message
Hi, near the bottom of Anglo-German Fellowship is the giant red error message "Lua error in Module:Navbox at line 604: attempt to concatenate field 'argHash' (a nil value)." Does this mean anything to anybody? And, more importantly, can anyone make it go away? Thank you, DuncanHill (talk) 19:40, 22 January 2025 (UTC)
"Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value)." Is it WP:THURSDAY? Hawkeye7(discuss)20:08, 22 January 2025 (UTC)
Obviously this is beyond the scope of Misplaced Pages, but it seems to be impossible to find snapshots of new links that can be archived at the moment. It simply produces an error message such as "Fail with status: 498" or "We're sorry — something's gone wrong. Our team has been notified." This is a nuisance as archiving links via the Wayback Machine is important. Are other people having this problem? ♦IanMacM♦20:03, 22 January 2025 (UTC)
Parent categories
An editor has requested a change to the way we display categories in the Category: namespace. The existing system, which looks approximately like this:
This sort of sounds like it would be an overall general improvement - that is not something special for only the English Misplaced Pages, and for only users with their interface language in en. If so, this should be requested upstream. — xaosflux01:56, 23 January 2025 (UTC)
I think it'd be better to do this locally, where it's been requested. If it seems to be a net improvement, we could always suggest it for widespread use (which would require re-translation of the string for all 300+ languages – not something that can happen quickly). WhatamIdoing (talk) 03:44, 23 January 2025 (UTC)
Nonsense redlink
Twice in the past three days, AnomieBOT has created the entirely unpopulated maintenance category Category:Articles lacking reliable references from 2025-01-19 from January 2025, which has in turn generated a nonsense redlink for Category:Monthly clean-up category (Articles lacking reliable references from 2025-01-19) counter — but since YYYY-MM-DD is not part of our naming format for either "Articles lacking reliable references" or "monthly clean-up category" maintenance categories, neither of these are categories that should ever exist at those names at all. But when I deleted the referencing category as both nonsense and empty earlier today in order to blow up the monthly clean-up redlink, the bot came along and recreated it again a few hours later even though it's still both nonsense and empty.
Could somebody look into this and figure out how to make it stop? I haven't deleted the category again this time, though I have wrapped the template in {{suppress categories}} since the redlinked parent still needed to go away regardless. Thanks. Bearcat (talk) 01:29, 23 January 2025 (UTC)
Third level list item if there's a line separating this from the previous list item
^^ Why is this the default behavior for multiple asterisks? Does anybody ever actually want every asterisk to render as an additional dot? Why isn't *** by default just a twice indented bulletpoint, even if not immediately preceded by a once indented bulletpoint? This silliness is why many people wind up starting lines with e.g. :*:::: or :::::*, which if I recall correctly isn't ideal for accessibility. At minimum, given the ubiquity of unordered lists in wiki discussion pages, shouldn't indents be the default behavior (with perhaps some template for anyone with a weird multi-bullet use case)? — Rhododendrites \\ 03:46, 23 January 2025 (UTC)
Because any ‘lists’ with newlines between them are not actually one united list. See MOS:LISTBREAK. Sadly MediaWiki does not make this obvious enough, if anything, but both are bad for accessibility. Editors should be advised not to insert blank lines between list items, or at least to insert them as blank lines with indentation (*** <blank>), as that would generate a hidden empty list item that would unite the markup. stjn04:59, 23 January 2025 (UTC)
It becomes immediately obvious when using hashes to make an ordered list:
List item
Second level list item
Third level list item if there's a line separating this from the previous list item
Notice the lack of an item numbered 2. This is such a long-established feature of the MediaWiki software that it's unlikely to be changed. But you can use CSS to highlight the problematic markup. Here's a quick-and-dirty rule that draws a thick dashed red line in the gap of the first example above:
I actually have a user style called user:stjn/linter.css (in Russian Misplaced Pages) that highlights a bunch of accessibility/markup-related issues like this, including one mentioned here. I mostly advertised it on Discord, though. (Recently I’ve been thinking of turning it into a user script that can then provide more refined suggestions, since CSS can have too many false positives if you try to write, for example, a rule specifically for a list containing only another list.) — stjn00:33, 24 January 2025 (UTC)
PetScan down or broken
Hi, For PetScan, when launched, it shows
Error: This web service cannot be reached. Please contact a maintainer of this project.. Needed to run an hour ago and still fails. Will check again later today. Regards, JoeNMLC (talk) 14:32, 23 January 2025 (UTC)
It's been down for a couple of days. It doesn't appear to have any current documentation as to active maintainers. — xaosflux15:28, 23 January 2025 (UTC)
It only accepts bug reports on github, where there is bug 187 open now. Github isn't really good for operational bugs, just software ones... This is another project with a lack of active onwiki volunteers unfortunately. — xaosflux15:31, 23 January 2025 (UTC)
@Xaosflux - Thank you for digging into this issue. PetScan really is a great tool for category filtering of articles. I regularly use to find Unreferenced + Orphan articles combination. For now, "Plan B" is to search thru just the old Unref. articles. Yes, it would be great to find an expert to: 1. Identify what is broken; 2. Fix it. There are some Bots that occasionally fail off & need to be restarted. Cheers, JoeNMLC (talk) 17:41, 23 January 2025 (UTC)
LDAP shows that Magnus Manske is the only maintainer. Since this is a very important tool, I think the Wikimedia Cloud team can help restart the web service if Magnus is not available. – DreamRimmer (talk) 18:04, 23 January 2025 (UTC)
Forgot what you call this. But every page on top has a little updated notice on how many views, etc. have been on that page. This is not browser specific, in my case. I have three browsers, and it's the same on all of them. Now I see a little left-hand dot moving back and trying to load the page stats. But it just keeps going back and forth with no results. — Maile (talk) 23:31, 23 January 2025 (UTC)
Whatever it's called, it is working perfectly now. To the left of it, is a little colored "Assessment" button. I just discovered that if I click on it, it takes me directly to XTools. — Maile (talk) 00:12, 24 January 2025 (UTC)
Constantly getting semi-logged out
By "semi" I mean I only have to click "log in" to get back in, not fill in my password or anything. But still annoying to have Vector2022 constantly flash onto my screen. This has been happening last three days or so, sometimes as often as every ten minutes. Cremastra (talk) 23:52, 23 January 2025 (UTC)
view · edit Frequently asked questions (see also: Misplaced Pages:FAQ/Technical)
Click "" next to each point to see more details.
Resolved
Moved from Misplaced Pages talk:Village pump (technical) § Issue - Loading WP:Huggle
View all 31 community-submitted tasks that were resolved last week. For example, the Visual Editor's "Insert link" feature did not always suggest existing pages properly when an editor started typing, which has now been fixed.
