Wikipedia:Village pump (technical): Difference between revisions

• Table of contents
• First discussion
• End of page
• New post

security implications should be reported differently (see how to report security bugs

).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache . 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 have problems making your fancy signature work, check Help:How to fix your signature. 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. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Why in the world is there no option to sort results by date or any other parameter? Results like this are absurdly primitive and make it extremely time-consuming (a complete, senseless waste of time) to search pages and archives for something.

Why are search results unsortable in 20176? Is this something that can be addressed with a simple phab request or is our search engine so horrible that it would be have to be completely redone? Jytdog (talk) 20:58, 26 January 2017 (UTC) (fix date, per below. duh on me. Jytdog (talk) 03:50, 28 January 2017 (UTC))[reply]

The top right of search pages link to Help:Searching on "Help". It mentions prefer-recent and the see also section includes mw:Help:CirrusSearch, the MediaWiki documentation for the search feature. See mw:Help:CirrusSearch#Prefer-recent. PrimeHunter (talk) 21:14, 26 January 2017 (UTC)[reply]

thanks for your reply. but wow. I have to use obscure things like adding prefer-recent to simply get results in date order? Oy. In any case I added that to the search query and I got basically the same results: see here. So... not only baroque, but mostly useless. People use search engines every day. It should not take obscure coding to sort various ways (like, why can I not search only section headers, by clicking a box or doing something simple?) This is something that anybody who wants to bring diffs in a discussion struggles with every day. Why is our search function so awful? Jytdog (talk) 22:58, 26 January 2017 (UTC)[reply]

FWIW, I totally agree. It is the most primitive search tool and next to useless for anything other than a very simple query. Leaky Caldron 23:09, 26 January 2017 (UTC)[reply]

You can search with prefer-recent:1,1 to only search by date per mw:Help:CirrusSearch#Prefer-recent. I agree it's complicated and few users will find it. PrimeHunter (talk) 23:15, 26 January 2017 (UTC)[reply]

Yes, I see that. But why not make is user friendly? If a date range is required, who is going to know the syntax? It is not the sort of feature these days that requires near-programming skills. Leaky Caldron 23:24, 26 January 2017 (UTC)[reply]

Search is mainly used by readers in mainspace. Last modified is rarely relevant there so sorting by it may be low priority. PrimeHunter (talk) 23:28, 26 January 2017 (UTC)[reply]

Yep. helping editors and facilitating community interaction is a low priority - this is clear. Jytdog (talk) 00:50, 27 January 2017 (UTC)[reply]

Sorry you're frustrated Jytdog, but that's not very kind. :( Admittedly, search on Wikimedia projects has room for improvement. Discovery folks are probably some of the most aware of that. :) Heck, I could imagine more advanced search features have probably been discussed since 2001!

To the matter at hand, there is active work on improving the UI for search results, faster updates to the index, cross-project search, and - you guessed it - improving advanced search features. Just a few weeks ago there was a good session at the Wikimedia Developer Summit that covered two active initiatives (session notes here). The first is the Advanced search workshop hosted by WMDE as part of their WMDE Technical wishes. I hear tell they even have a prototype coming soon! The second is Discovery's own work on cross-wiki search results improvements - a component of which has been a discussion around UI changes to make apparent more of these 'hidden' features present. The team is hoping to have some A/B tests in place this quarter .

That's not to say that we're going to see overnight changes here. Making changes to something that touches every Wikimedia project is dicey business (see [1] [2] for humor on this topic). Folks use search in many different ways, and adding bunches of checkboxes or drastic changes to the behavior of search is not something to be taken lightly. Improvements are improvements and I hope you and other members of the community welcome them (and let us know if we get off track!).

Besides that more targeted work, myself and Cpiral among others are active at Help_talk:CirrusSearch. Together (well really Cpiral gets all the credit) we recently reworked much of the documentation, made it available for translation, and made sure the "? Help" link from almost all Special:Search results page link to the documentation (Humorously enough the English Wikipedia search results don't link to the updated documentation. Anyone want to help with that?).

If you want to know more, I'm happy to help. You can see our statistics on the quality of search at http://discovery.wmflabs.org/metrics/. If you have suggestions for the cross-wiki search results improvements, feel free to drop a note on the talk page there. Constructive, actionable feedback is much appreciated! General suggestions for improvement are welcome wherever you can put finger to key, just ping me to get my attention.

I hope this finds you well. I'm sorry if you're still frustrated, but please do know I'm doing my best. CKoerner (WMF) (talk) 04:29, 27 January 2017 (UTC)[reply]

Thanks for your note, I am sorry you find it unkind. I find that the communication between the editing and dev communities has sucked rocks as long as I have been here. But really - I have zero time to go read documentation and use bizarre functions that don't even work like prefer-recent. And I find it just weird that you are even suggesting that I devote time to that. I want tools that work. Happy to test stuff and happy to tell anybody what i want. Jytdog (talk) 06:23, 27 January 2017 (UTC)[reply]

Me bookmarks this, so that I can point the few people who will complain about the 'undesired changes' to the searchpage, when the work of the German techteam changes the Search UI somewhere in the next year. :) —TheDJ (talk • contribs) 07:18, 27 January 2017 (UTC)[reply]

Whoops, sorry Jytdog, my intent wasn't to tell you, "Go read the manual", it was to say, "Hey there are folks interested in helping with search-related questions, we hang out over here. Come ask us questions." I got a little off topic talking about the improvements to the documentation we made. Sorry for the confusion. To make sure your feedback doesn't get lost in the archive I created a Phab task to have the team take your suggestion into consideration. Take care. CKoerner (WMF) (talk) 15:22, 27 January 2017 (UTC)[reply]

@CKoerner (WMF): The target of the Help link on search pages is determined by MediaWiki:Search-helppage. The default for Wikimedia wikis is mw:Special:MyLanguage/Help:CirrusSearch. The English Wikipedia (me specifically) has set it to the local page Help:Searching. It includes some Wikipedia-specific information but may be lacking in other areas. I mentioned the setting at MediaWiki talk:Search-summary#Protected edit request on 2 November 2015. Before that we used MediaWiki:Search-summary (displayed at top left [3]) to link to Help:Searching since 2011. PrimeHunter (talk) 11:25, 27 January 2017 (UTC)[reply]

PrimeHunter, that's helpful background and context. Thank you for pointing it out. I'll try to find some time to look over Help:Searching and if I see any suggested improvements I'll drop a note on the talk page. CKoerner (WMF) (talk) 20:05, 27 January 2017 (UTC)[reply]

Few know Search, and the docs don't seem to explain it well enough. It's very good. I learned about it by posting at Help talk:Searching and phabricator. I don't understand why Help talk:Searching has always been so quiet (by Wikipedia standards). ... Hey, a post there just announced WP:Request a query. I wonder if that will somehow help Search get the attention it needs. — Cpiral§Cpiral 23:52, 26 January 2017 (UTC)[reply]

https://phabricator.wikimedia.org/T23139 — Preceding unsigned comment added by 197.218.90.119 (talk) 12:31, 27 January 2017 (UTC)[reply]

Jytdog "Why in the world is there no option to sort results by date or any other parameter?" Because Google doesn't do it. Yes, I'm being serious here. See this. --NeilN ^{talk to me} 15:04, 27 January 2017 (UTC)[reply]

@NeilN: Hello again. As with last time, your characterisation of the situation is inaccurate, and your anger misplaced. I said the reason why Google does not have it is the same reason we don't, namely degradation of experience. This is not the same as simply doing what Google does like you imply. To repeat, the reason this feature is not a priority is because it will degrade the search experience for the vast majority of users. I acknowledge that it is a useful feature for some users, such as yourself and Jytdog, but often I have to make hard decisions about how to prioritise the few resources we create the maximum impact, which in this case sadly means not prioritising your request. It's currently the hope of the Search Team that we can work on advanced query features, potentially such as this one, in Q4 (i.e. April - June 2017); we've been laying a lot of groundwork over the past few months, and it may finally be a time when we can really improve things. I am hopeful that we can partner on this and work together, and put any previous hostility behind us. --Dan Garry, Wikimedia Foundation (talk) 16:26, 27 January 2017 (UTC)[reply]

Sorting by date (or by page title) is useful when searching in discussion page archives; if that is not practical, filtering by date would also be helpful. I often find myself searching for a discussion that happened sometime in the last year on a given talk page, and getting apparently randomized results from the last 15 years of discussion is not helpful in those cases. I hope that WMF staff will return here when they are working on a spec for improving search. There are many constructive, helpful editors who watch this page. – Jonesey95 (talk) 16:44, 27 January 2017 (UTC)[reply]

@Jonesey95: Thanks so much! We'll be sure to reach out to you and others for your input when we start planning the work. --Dan Garry, Wikimedia Foundation (talk) 17:00, 27 January 2017 (UTC)[reply]

@Deskana (WMF): No, I think my characterization of the situation is pretty accurate. You repeat it will "result in degraded performance for the vast majority of users" over and over again but have never justified or explained your assertion. --NeilN ^{talk to me} 16:48, 27 January 2017 (UTC)[reply]

@NeilN: You said the same thing last time in spite of my giving an example, but very well, I shall try again. Three years ago, in phab:T40403#477014, I gave an example; "Due to the way search works, for most queries this would generate a list of articles with nothing in common. For example, searching for Barack Obama and sorting alphabetically would generate nonsensical results such as Aaron McGruder, an American cartoonist, followed shortly thereafter by Abbottabad, a city in northeastern Pakistan". For the use case Jytdog mentioned, searching for his username in discussion namespaces, this makes perfect sense. For searching the article namespace as a casual reader, it does not make sense, which is the danger with exposing such functionality plainly. This does not mean that there are not legitimate use cases, but it does mean caution is necessary. Sadly, as with last time, I won't respond further due to your hostility. --Dan Garry, Wikimedia Foundation (talk) 17:00, 27 January 2017 (UTC)[reply]

@Deskana (WMF): I don't think I'm hostile, just aware of the game you seem to be playing. I've dealt with similar situations in my professional life and, if I'm honest, used the technique too. You can always custom craft examples to show why change wouldn't be good. Note the emphasis in all of these requests is sort results by date, not alphabetically - this is your red herring. And no one is suggesting that the default behavior of search be changed so, again, "degraded performance for the vast majority of users" still has no justification. --NeilN ^{talk to me} 17:19, 27 January 2017 (UTC)[reply]

@NeilN: wow, on that prior discussion and the discussions linked-to there. Just wow. Yep, discussions between people who work in dev and editors who need to work in community and dig around in histories and archives in order to do so, is completely bolloxed. Our search engine sucks rocks for that purpose and devs are just completely, utterly deaf to that. I can't see any place where reasonable efforts have been made to even to try to fix that problem. I may be unaware of them, but I have not seen them. (of course trying to find them will be a pain the butt and i am uninterested in using the crappy search engine to even try to find them.) Jytdog (talk) 22:16, 27 January 2017 (UTC)[reply]

@Jytdog: Yep. I've interacted with WMF devs before and I have always understood when they say something like "our user surveys indicate this feature request does not have high priority with other users" but don't feed me a line like it will degrade performance for the vast majority of users and then refuse to back up that assertion with any kind of proper justification. Just say you don't want to do it and accept the (deserved) brickbats thrown at you instead of coming up with a bogus explanation. I mean, adding two dropdowns (sort by, sort order - default to Relevance, Descending) to this screen is going to "degrade performance for the vast majority of users"? Really? --NeilN ^{talk to me} 22:42, 27 January 2017 (UTC)[reply]

@Jytdog: No need to search. Discovery Quarterly Check-in Q2-Q3 2016-2017 Edit: Forgot a link to our weekly updates. Hope that helps. CKoerner (WMF) (talk) 23:28, 27 January 2017 (UTC)[reply]

I took the bait and reviewed the pdf document. There is nothing there about past discussions between the dev community and the editing community about making internal search work better on page histories and archives. This is the second instance (the first being discussions about the Discovery engine) where you have responded to stuff i have written by sending me to go read things that had nothing to do with what I was asking about. You wasted my time and volunteer time is the most important asset WMF has (not that mine is particularly valuable compared to others). And you have acted for the 2nd time now as a PR guy instead of a liaison. Stop wasting my time. Jytdog (talk) 23:46, 27 January 2017 (UTC)[reply]

I'm not sure why you're emphasizing the wrong year. It's 2017.

I agree that site search is rudimentary and would benefit from additional features. If you can convince Erik B. of the merits, that would be your best path forward. Trying to deal with other members of the "Discovery" team is just useless, as you all are apparently re-discovering here. It also isn't really fair to flatly say that developers are missing the point or causing problems here, given that Dan G. and Chris K. aren't developers. Some developers, such as Chad H., certainly aren't helping matters, though.

It's in discussions like this, where people like Dan G. talk about the "hard decisions" he's forced to make, that I'm re-reminded why nobody should donate money to the Wikimedia Foundation. It's gotten far too big and bloated. --MZMcBride (talk) 03:31, 28 January 2017 (UTC)[reply]

You just made me laugh. Thanks for that! Yes it is 2017.  :) I am emphasizing the year as the search engine appears to be so primitive, and we are so, so hamstrung by it. So much time wasted pouring over these search results that appear to be presented in random order. I see no sense, at all, in the order of search results in my OP. There are 944 archive pages for ANI. Really, this is not fixable with existing technology in 2017? Really?? This makes me grit my teeth any time I go looking in archives, or even just blow it off, as I mentioned above with regard to finding past iterations of this exact discussion - am not going to wade through however many of the 154 archives (!) of this page mention "search engine", randomly presented to me.

Somebody above said that google can't sort by date, but it can very precisely limit the date (on bing and duckduckgo too). But as noted above, google is a bad example as it searches the whole darn web. I use Pubmed a ton and there are zillions of filters that can be used on that, which are simple to use. Why can we have not a decent search of archives?

and thanks for the pointer to the apparent wizard, Erik B ! Will head down the yellow brick road to find them. Jytdog (talk) 03:50, 28 January 2017 (UTC)[reply]

The Google comparison also falls apart when you dig into it. It can certainly sort by date - see this. Of course the news search has more structured data to work from... kind of like a certain website. --NeilN ^{talk to me} 05:51, 28 January 2017 (UTC)[reply]

I've re-opened phabricator:T40403 for further consideration.

When Nik E. left the Wikimedia Foundation, Erik B. took over the CirrusSearch maintenance and support. Nik actually went to go work at Elastic, the company that makes Elasticsearch, which is what powers Special:Search currently. CirrusSearch is the MediaWiki implementation of Elasticsearch. --MZMcBride (talk) 08:00, 28 January 2017 (UTC)[reply]

Well that didn't end well :( —TheDJ (talk • contribs) 20:18, 30 January 2017 (UTC)[reply]

Thanks for the call-out/criticism without the ping :) But....huh? I haven't had anything to do with search in quite some time. I'm not sure what I'm supposed to be helping that I'm not. ^

^{[omg plz]} 20:37, 30 January 2017 (UTC)[reply

]

It doesn't seem like you needed a ping to find this discussion. ;-)

I was specifically referring to phabricator:T40403#477138. You went further than saying "I'm/we're not going to work on this", extending it to "nobody should work on this, patches won't be accepted". This comment is from March 2014, back when you were more involved with search. (If you weren't involved with search in March 2014, then that comment is even more unusual and upsetting.) Comments like this can stall work and progress literally for years, which I find pretty unhelpful, yes. --MZMcBride (talk) 01:27, 31 January 2017 (UTC)[reply]

In reading back over it, I realized that comment was actually misplaced entirely, as Andre was suggesting that people could make local hacks or extensions for their own wiki to accomplish this--not suggesting they be committed to Cirrus or core. So it was useless to state that. Fair enough that this may be discouraging, but it was nearly 3 years ago when I was actually involved. I can remove/retract it if that'll help. I don't care strongly about this anymore... ^

^{[omg plz]} 02:16, 31 January 2017 (UTC)[reply

]

Raw sorting using dates will certainly provide worse results unless they are filtered, [4][5]. There are also studies providing evidence that end-users prefer sorting based on ranking, Disambiguating, categories, [6]. Examples of current garbage results yielded by data ranges or filtering, in which the dates have 0 relevance are easy to find even in a Billion dollar search engine: [7]. They would be far worse in a Wiki, due to vandalism, bogus dates from imports, or even a routine bot edit that invalidates dates.

For readers, however, sorting and filtering articles using wikidata related dates would be much more meaningful than using either creation date or last-edited date. — Preceding unsigned comment added by 197.218.80.247 (talk) 21:14, 30 January 2017 (UTC)[reply]

Listen, the following are facts:

• Editors need to find things in archives as part of their work in community
• The search engine is useless in that effort, as the results are presently random. Whatever the engine understands as "relevance" is irrelevant when searching for an exact phrase. The results are random. Instead of using the search engine for this, I browse - I go though the archives manually, one by one starting at the most recent or around the date when I remember something being discussed, and use my browser's "find" function to search for the string. That is how useless the search engine is for this.
• Nobody from the dev world has even acknowledged that the search engine absolutely sucks for this. That makes the responses here and at phab all the more bitter to receive.
• They are hard to hear anyway, as they have been knee-jerk rejection at worst, and uncreative elaboration of "present priorities and limitations of technology blah blah blah" or dismissed as something that only "power users" need which is a) bullshit and b) clueless about how the WP community works..
• I have no idea how the back end works, but here are two ideas pulled out of my ass (yes, I know nothing about the back end)
  • could talk archives and Wikipedia space be indexed separately, searched separately, and available via federated search for general searching only if selected, so that whatever "resources" this would take up are not incurred in general search by readers? (they are not relevant for people who want to read articles anyway)
  • is it really so resource-intensive to have the results from the present engine sorted by Archive number (almost all archives are numbered; part of the very URL that is presented in the results includes the string "Archive_#") (For example, could sorting by archive number in the URL not be done as a separate step after the engine generates results and before they are presented?)

I am sure those will easily be shot down. Which is what I expect to happen, along with more dismissive, uncreative, bullshit comments that ignore the problem for the editing community. And the problem will remain unsolved Jytdog (talk) 18:26, 2 February 2017 (UTC)[reply]

Hey Jytdog. I'm still listening as are others. Real quick, saying “I am sure those will easily be shot down.” immediately makes replying with any information difficult. Any response you perceive as contrary to your proposed facts have the chance to be construed as ‘being shot down’. But hey, it’s my job and i’m still going to give it my best - not because I have any hope to convince you that WMF staff are not evil incompetent poo-poo heads, but because others might appreciate alternative facts. No, wait, that came out wrong. Others might appreciate clarifications on the claims you have put forth. :)

Please, AGF in my response.

Editors need to find things in archives as part of their work in community

Totally agree. No one is arguing this. As we all know the same thing replies to Readers, which unfortunately are harder to reach and hear from than editors. When making any decisions, folks at the WMF have to balance the needs of people who have a voice, such as yourself, with those that aren’t around to tell us what’s working or not. It is not something to be taken lightly.

That, I think, is the crux of the “degrade the search experience” concern. It’s not that super handy search tools for editors are unwelcome, but it’s a challenge to build something that works for editors and everyone else we (editors and WMF) support with our work.

The search engine is useless in that effort, as the results are presently random. Whatever the engine understands as "relevance" is irrelevant when searching for an exact phrase. The results are random. Instead of using the search engine for this, I browse - I go though the archives manually, one by one starting at the most recent or around the date when I remember something being discussed, and use my browser's "find" function to search for the string. That is how useless the search engine is for this.

Random makes me think of 'by chance'. Like as if when you search we spin a giant wheel in the background and out pops whatever pages we can find. :) You might think that would be better than what currently happens, but I can assure you there is far more logic and reason behind search.

Elastic, the company that created Elasticsearch, has some very technical (over my head) documentation on how scoring works. That's just the 'out of the box stuff'. We've been tuning it for movement needs beyond that for quite some time now. I have another thought on this further down. Maybe search isn't the thing you need?

But, since all we have is search right now: Have you tried putting a query in quotes? It will return results for that exact phrase. If that's not working then do let us know. [8]

Nobody from the dev world has even acknowledged that the search engine absolutely sucks for this. That makes the responses here and at phab all the more bitter to receive.

There are about 16 people working in Discovery. We all know search can be made better and each of us show up to work every day to make it so. You may have missed it after you unsubscribed from the task, but we are considering the feature request and the intent is to keep the task open until a time where we're ready to work on it. Another editor also mentioned creating a user script and I would love to see that as a possible solution myself.

They are hard to hear anyway, as they have been knee-jerk rejection at worst, and uncreative elaboration of "present priorities and limitations of technology blah blah blah" or dismissed as something that only "power users" need which is a) bullshit and b) clueless about how the WP community works..

Oh, man. This is really not helpful. That 'knee-jerk' reaction comes from members of the department being at the foundation for years and editors and admins for years before that. You can't really use that argument I'm afraid. Saying "blah blah blah" is equally dismissive as your claim and does not further the dialog. :(

I have no idea how the back end works, but here are two ideas pulled out of my ass (yes, I know nothing about the back end)...

Which is fine, we're not all backend developers (who, while magical, are not mythical). Feedback like this is what people like me strive for. Good ideas to make better tools for editors are appreciated. The rest of the stuff, ehh, it makes my day crappy and you come across as a jerk. Not a good situation for anyone.

could talk archives and Wikipedia space be indexed separately, searched separately, and available via federated search for general searching only if selected, so that whatever "resources" this would take up are not incurred in general search by readers? (they are not relevant for people who want to read articles anyway)

Bingo, this is the exact question we're asking with the proposal (and similar). How do we surface project Wikipedia content in a way that doesn't confuse, frustrate, or worse alienate folks who are satisfied with general search? That's what we're trying to get to with discussions around reworking the UI of Special:Search and thinking about incorporating advanced search - of which your suggestion is one in consideration!

is it really so resource-intensive to have the results from the present engine sorted by Archive number (almost all archives are numbered; part of the very URL that is presented in the results includes the string "Archive_#") (For example, could sorting by archive number in the URL not be done as a separate step after the engine generates results and before they are presented?)

"Almost all", but "not all" means very different things! As smart as search engines are, they are only as good as what you put in. That's why searching is 'fuzzy'. Imagine how frustrated you would be to make a search thinking everything in the archive is structured only to discover the early days were more lax and you see no results?. Oh, wait, you already are. :(

This also points out one of the challenges in using search to find info in archives. As TheDJ pointed out in the phab task, "Talk archives are edited all the time (and thus their recent indicator that we currently have isn't useful to determine their age)."

While not at attempt to shoot this idea down, perhaps this is something like a Special:Archive could accomplish better. You know that currently search isn't great for it. Maybe we're at the point of looking at the hammer and wondering if a screwdriver wouldn't be better. :) Something separate from search that provides an index of specified Archive pages? You give it a "Talk:" page title and it spits back every section heading for each Archive number?

Ok, so while I may not have convinced you of anything, at least know I tried to be as modest and creative in addressing the concerns you bring forth. I think the problem will remain unsolved if we can't have a civil and agreeable conversation on this topic. However, if you can meet us half way (as you did with your latter suggestions here and in Phabricator) I think you'll be pleasantly surprised at what we can accomplish together.

For folks not keen on participating in Phabricator, the ticket I created in response to Jytdog’s feedback earlier in this thread was merged with an existing task from 2015 and reopened by a community member. The search team is reviewing the task and will consider it when we look to approach advanced search in the future. Feedback there is welcome or wherever you can ping me. CKoerner (WMF) (talk) 20:34, 2 February 2017 (UTC)[reply]

Thanks for your note.

If you search for a string in quotes, many pages will have the string, so "match" is simple. There is no apparent order in which they are presented. Quibbling over "random" is off topic.

It is not true in my experience that talk archives "are edited all the time". Archives have big tags on them saying "DO NOT EDIT" and in my experience are edited rarely. The assertion at phab was just that - an assertion.

Having the search engine present results when searching archives that are useful most of the time (for archives that are numbered, which most of them are in my experience) would be way better than search results that are always useless for searching archives. Everybody understands that things are limited in the real world. That includes me.

With regard to WMF priorities, I have nothing to say about that. Your priorities are set by your bosses and everybody knows the history there. To the extent this can be addressed with the resources you have been given, that would be great. Jytdog (talk) 21:02, 2 February 2017 (UTC)[reply]

I must admit, the prefer-recent search parameter does not work clearly and consistently well to actually sort by date. I don't even know, at this point, that it works as intended. In any case, the end-user of CirrusSearch is currently in a rough terrain: exposed to complexity of its page ranking, while not having recourse to discussions on the talk page, which take place on phabricator. Plus I admint that I am not, alone, as a volunteer and non-expert, able to document search to the level that happier, more experienced users of CirrusSearch can simply reply, in cases like this, "RTFM".

Search can be improved without taxing developers and the Discovery Team too much if more volunteers work on it, discuss it, document it. Yet the places to do so are not frequented in proportion to the value and importance of Search. This conversation might have happened on Help talk: Searching, right? — Cpiral§Cpiral 23:22, 5 February 2017 (UTC)[reply]

I put this here as i don't need help with the current search function. The current search function is worthless for searching archives. There is no "help" for that. Jytdog (talk) 23:35, 6 February 2017 (UTC)[reply]

Just as a quick note about prefer-recent, since I wrote it. It was never designed as a full filter by date. It was primarily built to replicate old behavior for Wikinews (hardcoded in lsearchd) that helps their recent articles be preferred (while still searching primarily on text). So yes, while it helps *prefer* a date based order it doesn't actually *enforce* it if other factors provide a better match. It was simply exposed to all wikis because it's easy enough to do so. For the usecase here (actually ordering by date) it's not a real workaround. Sorting by *anything* is a simple technical solution...the data is all there. I will note, it would be pretty easy (and not clutter a UI at all) to just expose an order-by: parameter just as easily we do for prefer-recent, has-template, or any of a dozen other parameters we already support. This also avoids the "we don't want to confuse the UI for readers/non-power-users who don't need them." ^

^{[omg plz]} 02:48, 10 February 2017 (UTC)[reply

]

Talk is cheap, show us the code!!! Seriously though, sorting will keep failing unless the search engine indexes every single history page. That's something that would likely use massive amounts of space and processing power, and would never be acceptable because history pages contain a lot of illegal, obscene and spammy content. Another issue is that anyone with enough brain cells to write a bot can easily fire one to go through all archives and do a small edit. That would immediately make those "sorted" results as pointless as they are currently. The simple fact that is that the notion of archives doesn't exist in mediawiki. Moving those "pages" into subpages, and calling them something else doesn't change what they are, nor does it remove their limitations. Manure by any other name smells just as bad. — Preceding unsigned comment added by 197.218.81.60 (talk) 23:46, 10 February 2017‎ (UTC)[reply]

• Note about the hullaballoo over WP "banning" the daily mail. Where did that "banning" take place? Oh, at RSN. What is "RSN'? It is the noticeboard where the community discusses whether sources are reliable. Guess what? Many sources, like the Daily Mail, have been brought up zillions of times there. How many archives does RSN have? 219. Why do you think people keep using the same awful refs over and over and we need to keep having the same discussion over and over, which is what probably led to the RfC that led to the "ban"? Gee maybe because in the world of search engines, the one you force us to work with to find past discussions and the consensus we already reached, is about the same quality as the Daily Mail in the world of reliable sources. Jytdog (talk) 19:57, 9 February 2017 (UTC)[reply]

• This section is so long that I didn't read all of it, so I hope that this is not redundant. Two points about searching by date:

• For those searching through talk pages that are automatically archived, it's possible to narrow down a search. For example, at the Wikipedia:Help desk, if I type "Anne Delong" "Archives/2013" into the archives search box, I get only results archived in 2013. "Anne Delong" "Archives/2013/July" gives me results from July 2013.
• Adding "prefer-recent:1,0.0007" to a search will give well sorted results by date, but it's hard t remember and annoying to type. There's a handy template that allows a user pre-specify areas to search by presetting the "prefix" parameter. You can also include a reminder note and just copy-paste the "prefer-recent:1,0.0007". Here's one that looks in a couple of talk namespaces, but it can be set to be more specific, for example, just my own user pages.

Find pages in Wikipedia talk: and User talk: Type a keyword and click on the button. Optionally, add "prefer-recent:1,0.0007" to see results in date order. [[Wikipedia talk:]] [[User talk:]]

According to Template:Search templates, the search box is created by something called Extension:InputBox. Perhaps someone familiar with this process could expand the template above by adding one more item: preset search parameters= which would insert a text string (such as is done in Template:Search link) after the user's search words but before the prefix. In this way, users could make their own custom searches, and those wanting date-ordered results could preset "prefer-recent:1,0.0007" (or any other text) in the template and save it on their user page or wherever handy.—Anne Delong (talk) 13:18, 11 February 2017 (UTC)[reply]

I used the search tool and it gave me results just fine: Talk:Muhammad/images/Archive 6#Painted by muslims linked to the website which is the subject of my research. It then led me to Wikipedia:WikiProject Spam/LinkReports/petitionsite.com and Wikipedia:Wikipedia Signpost/2008-02-11/Muhammad image. How do I locate the blacklist entry for this site and find out who blacklisted it, when and why? 176.25.77.192 (talk) 11:09, 15 February 2017 (UTC)[reply]

Found something: m:Talk:Spam blacklist/Archives/2010-12#thepetitionsite.com/1/ban-wikipedia. Looks like there was prior discussion on en:wp. How would I find that? 176.25.77.192 (talk) 11:19, 15 February 2017 (UTC)[reply]

Seem to have tracked it down: MediaWiki talk:Spam-blacklist/archives/June 2010#thepetitionsite.com. 176.25.77.192 (talk) 11:38, 15 February 2017 (UTC)[reply]

Beginning from a few days ago, I have been having trouble logging into all Wikipedia sites (specifically the English versions of Wikipedia, the Wikimedia Commons, and the Wiktionary) on my iPhone and iPad using the Safari browser (not sure which version – how do I check?). I get the error message:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

I cannot bypass this message, and neither reloading the page nor going to some other page helps. I do not know if Safari's built-in function for autofilling user-ids and passwords is causing the problem, but even if I manually enter the user-id and password the problem occurs. I tried reporting this issue to the Phabricator, but since it seems to be specific to Safari (the problem doesn't seem to occur with the Mozilla Firefox browser) I was told that it was not a problem on the Wikipedia side. Any idea how to solve this problem? —

@

Smuconlaw: try to clear your cookies (Wikimedia-related) in Safari. Stryn (talk) 18:09, 13 February 2017 (UTC)[reply

]

I did try that, but it doesn't seem to have worked. —

talk) 18:21, 13 February 2017 (UTC)[reply

]

Earlier, I went on Special:Book while I was looking around the special page list. I didn't click anything, just opened the page and then left it. However, now, whenever I hover over a wikilink to anything in the article space, I get a little popup with an option to "add the linked wiki page to your book". How do I disable this? — Train2104 (talk • contribs) 05:05, 12 February 2017 (UTC)[reply]

I just reproduced your problem. At the top of any article, I found a "Book creater" banner, with the option of disabling "Book creater". After confirming that I wanted to disable it, and bypassing my browser's cache, it's gone. עוד מישהו Od Mishehu 08:39, 12 February 2017 (UTC)[reply]

The question is should it be so easy to activate "Book Creator" accidentally?Nigel Ish (talk) 11:38, 12 February 2017 (UTC)[reply]

Found the disable link, thanks. It's in the sidebar, not obvious at all. Though that's where the link to the special page is, so one could make that argument. — Train2104 (talk • contribs) 14:54, 12 February 2017 (UTC)[reply]

I'm alerted on my talk page to a possible error in

It's not an error. A template often displays poorly on the template page itself because it doesn't get mandatory parameters, in this case |url=. Some templates are coded to avoid the issue by using <includeonly>...</includeonly> around the template code, or supply example parameters inside <noinclude>...</noinclude>. But this has disadvantages for users who expect the template page to display what a call without parameters would display. I think it's OK that Template:Webarchive does that. PrimeHunter (talk) 11:20, 12 February 2017 (UTC)[reply]

I understand. Thank you, PrimeHunter. -- Hoary (talk) 12:45, 12 February 2017 (UTC)[reply]

Let's say a script works for one person, but not another. Or it's working on two machines, but after one is cold booted, it doesn't work on that one.

How would one find the dependencies required by the

@The Transhumanist: I am guessing that your problems are not caused by a lack of dependencies, but rather by the way you are using the localStorage object. According to the docs, you should be using localStorage.setItem('foo', 'bar'), not localStorage.foo = 'bar'. If you use the API in a non-standard way I wouldn't be surprised if there were differences between the way the various browsers handle it. — Mr. Stradivarius ^{♪ talk ♪} 13:18, 12 February 2017 (UTC)[reply]

Actually, after some more reading, it seems that the localStorage.foo = 'bar' syntax is fine (although the setItem syntax is preferred). That link does give some other suggestions as to things that could be wrong, though - localStorage might not be implemented on old browsers, it might be disabled by users, or it might be full. — Mr. Stradivarius ^{♪ talk ♪} 15:01, 12 February 2017 (UTC)[reply]

Also, I would use a unique prefix for your localStorage keys, maybe olutils_ (so the current key would be olutils_redlinks), to reduce the chance of clashes between your data and other localStorage data saved by MediaWiki or by other gadgets. — Mr. Stradivarius ^{♪ talk ♪} 13:24, 12 February 2017 (UTC)[reply]

@

script works on its own. Though there are still some bugs (the menu item has to be clicked again after getting a preview, twice, for it to work, but it does work). Thank you! The Transhumanist 00:59, 13 February 2017 (UTC)[reply

]

@The Transhumanist: Also, all calls to LocalStorage should always be wrapped in a try catch. Localstorage can easily fail due to being full, or due to being in a privacy mode or some other restriction that the browser is placing. —TheDJ (talk • contribs) 07:32, 13 February 2017 (UTC)[reply]

Thanks, I'll look that up. The Transhumanist 20:01, 13 February 2017 (UTC)[reply]

Does anyone can help me to create a simple location map? Xaris333 (talk) 15:29, 12 February 2017 (UTC)[reply]

I want only a part of File:Cyprus adm location map.svg. Xaris333 (talk) 16:04, 12 February 2017 (UTC)[reply]

@Xaris333: Unless you know Lua, head to Wikipedia talk:Lua. I once made a request there. – Finnusertop (talk ⋅ contribs) 03:41, 13 February 2017 (UTC)[reply]

@Xaris333: Were the replies at Wikipedia:Village pump (technical)/Archive 152#Location map not helpful? --Redrose64 🌹 (talk) 23:18, 13 February 2017 (UTC)[reply]

Coordinates

I have create File:PaphosDistrict.svg with the help of File:Cyprus adm location map.svg. The coordinates I have add are wrong. Anyideas how can I find the correct coordinates? Xaris333 (talk) 21:05, 13 February 2017 (UTC)[reply]

Hi again. I'm an admitedly stubborn and eccentric newbie. When I use the template {{u|example}} "example" appears in a bluish color. There exists some code somewhere that specifies that color. I've tried to look at documentation pages for that template, but can't find the code. I'd like to personalize my "pings" (recall my eccentricity) by specifying a different color. I don't care if there is a paragraph-long code that needs to be used in place of {{u|}}. I would simply save that code in a text document, and when I want to use my personalized "ping", simply copy and paste that into the wiki page (recall that I'm stubborn). Can anybody please give me the wiki code for that {{u|}} template? Thanks, DennisPietras (talk) 17:06, 12 February 2017 (UTC)[reply]

The code {{u}} or {{u|...parameters here....}} calls the template at

Template:U, in this case a redirect to Template:User link. Click "Edit" or "View source" to see its code. It doesn't add any coloring. It just makes a wikilink to a user page. Some users haven't made a user page for their account. Internal wikilinks are automatically blue if the page exists and red if it doesn't exist. If your browser has visited the link then the color may change a little to indicate this. See more at Help:Link color. It's possible to directly specify the color of links but it must be done inside the link brackets after a pipe. It causes confusion for readers who know the meaning of the normal link colors so please don't do it in pings or most other situations. PrimeHunter (talk) 18:21, 12 February 2017 (UTC)[reply

]

Thank you DennisPietras (talk) 20:44, 12 February 2017 (UTC)[reply]

Resolved

Is there any difference between <br/> and <br>? -- Magioladitis (talk) 18:50, 12 February 2017 (UTC)[reply]

See

Wikipedia:Line-break handling#.3Cbr.3E. PrimeHunter (talk) 19:01, 12 February 2017 (UTC)[reply

]

Also, <br/> and <br /> are preferred for anyone who uses this syntax highlighter. kennethaw88 • talk 20:09, 12 February 2017 (UTC)[reply]

See this guide from W3Schools — both are valid in HTML, but <br> is considered invalid for XHTML purposes. Nyttend (talk) 02:28, 13 February 2017 (UTC)[reply]

I believe that consensus is that <br> should not be converted to <br/> unless there are substantive changes being made at the same time. I have no evidence to support this belief, however. – Jonesey95 (talk) 02:41, 13 February 2017 (UTC)[reply]

You're probably thinking of the fact that bots are

prohibited from making this kind of change, basically because they clog up a large number of edit histories with no visible effect. Since humans can't edit as fast, someone making such changes presumably wouldn't encounter opposition; the likely response would be something like "why do that; you're wasting your time". Nyttend (talk) 02:53, 13 February 2017 (UTC)[reply

]

Or edit wars between two people who obstinately disagree on / or <br/> vs. <br />. I've seen that (elsewhere). --Unready (talk) 05:20, 13 February 2017 (UTC)[reply]

Nyttend, in most cases you would be right, but in this case, I was actually thinking that the OP needed to see the words I wrote above, given the situation in which he has placed himself recently. – Jonesey95 (talk) 06:00, 13 February 2017 (UTC)[reply]

@Magioladitis: I am certain that I answered this question for you, some months ago. IIRC it was on a user talk page, not necessarily your own.

Anyway, the Wikimedia sites (including Wikipedia) serve HTML5, where (according to the W3C docs - don't believe all you read at W3Schools) the space and the slash of the <br /> tag are both optional. But when the tag has attributes, and the last attribute doesn't end with a quote character, for example

<br style="clear:both;" id=gap1 />

the space is mandatory if the slash is present. Even if there are no attributes, some browsers don't like the space to be omitted if the slash is present.

Until a few years ago, the Wikimedia sites served XHTML 1.0, where (regardless of attributes) the space is optional but the slash is mandatory. --Redrose64 🌹 (talk) 23:37, 13 February 2017 (UTC)[reply]

The last major browser to require a space before /> was Netscape 4.0, which was released almost 20 years ago. If anything since then can't handle a space, it's a browser bug. --Unready (talk) 01:39, 14 February 2017 (UTC)[reply]

@Unready: Consider a tag like <br id=gap1/> - is the slash part of the value of the id= attribute, or not? It might be; and so the unquoted attribute value syntax states

If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional "/" (U+002F) character allowed in step 6 of the start tag syntax above, then there must be a space character separating the two.

It therefore requires a space to resolve the ambiguity between <br id=gap1/ > where it is part of the value, and <br id=gap1 /> where it is not. --Redrose64 🌹 (talk) 12:41, 14 February 2017 (UTC)[reply]

From the W3C HTML5 reference:

However, in the XHTML syntax, attribute values must always be quoted using either single or double quotes.

... which would apply to self-closed tags. In HTML syntax (not self-closed), quotes are optional. --Unready (talk) 21:54, 14 February 2017 (UTC)[reply]

Self-closed tags are not forbidden in HTML5 - see section 8.1.2.1 Start tags

Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single "/" (U+002F) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.

So the presence of a slash before the greater-than sign does not make it XHTML, nor does it make quotes necessary; the self-closed form is both HTML and XHTML, and so if the document is declared as HTML in its <!DOCTYPE ... > (Wikipedia pages all begin with <!DOCTYPE html>), there is no need to observe the stricter XHTML rules. --Redrose64 🌹 (talk) 01:11, 15 February 2017 (UTC)[reply]

If I write <br> <br/> <br /> in a wiki page, all three of them get transformed by the MediaWiki software to <br />. So from a wikitext perspective, it doesn't matter which one you write, and there are no accessibility or compatibility considerations to worry about.

WP:Line-break handling says "<br /> is preferred as it will be rendered correctly in all circumstances, including strict XHTML", which is nonsensical in view of the way these tags are actually processed by MediaWiki. — This, that and the other (talk) 00:55, 14 February 2017 (UTC)[reply

]

@This, that and the other: The MediaWiki software doesn't touch it. The transformation is done by HTML Tidy, which we're on the point of dropping; partly because it doesn't understand those parts of HTML5 that weren't carried over from HTML 4.01. --Redrose64 🌹 (talk) 00:58, 14 February 2017 (UTC)[reply]

@Redrose64: That isn't the case. I tested this on my local MediaWiki installation, which definitely does not have Tidy installed, and the transformation occurred regardless. This is done by the slightly misleadingly named function Sanitizer::removeHTMLtags in MediaWiki's PHP code. — This, that and the other (talk) 01:30, 14 February 2017 (UTC)[reply]

Tidy isn't a separate installation. Sanitizer is Tidy, until Sanitizer becomes HTML5Depurate, which is "soon." --Unready (talk) 22:02, 14 February 2017 (UTC)[reply]

If you look into it you'll find Tidy is a distinct PHP extension that is called from MediaWiki code when enabled. (For interest, Tidy doesn't appear to be enabled at translatewiki:, so you might like to experiment in the sandbox there to see how things behave without Tidy.) In any case, suffice it to say that MediaWiki does more tidying that one might have thought. mw:Parsing/Replacing Tidy makes no mention of <br> tags, so we don't have anything to worry about in that regard. — This, that and the other (talk) 10:31, 15 February 2017 (UTC)[reply]

As far as I'm concerned, <br> is valid wikitext, and whether it's valid in any particular output format or version of HTML pretty much irrelevant. We'll make it keep working one way or another. I recommend using it in that form in wikitext, without the slash, because it's shorter. This was my position during the XHTML era, and is vindicated now in the HTML 5 era.

WHATWG (the body that made HTML 5) denigrates the idea of XHTML in a few different places. In the syntax section of the HTML 5 spec, it has a kind of joke definition of XHTML which seems to serve only as an argument against its existence. As Redrose64 says, MediaWiki does not output XHTML, we use <!DOCTYPE html> which means we are outputting HTML 5. In HTML 5, self-closing tags exist only as a very limited backwards compatibility concession. Except for foreign content like embedded SVG, self-closing slashes are only recognised in places where they are unnecessary. For example, <div/> is a parse error and is interpreted as if the slash were absent: <div>. Only in void elements like <br> are they allowed, but void elements by definition do not require, and cannot have, closing tags. The HTML 5 fragment serialization algorithm, which defines conversion of a DOM tree to a string, requires that br elements be represented as "<br>".

During the XHTML era, we never actually output XHTML, we declared our output to be "XHTML transitional" which was really just tag soup with aspirations. But XHTML had mindshare and so it made more sense to be arguing about writing wikitext as if it were XHTML. Those days are over, so I don't think that there are two defensible sides of this argument anymore.

We'll soon be getting rid of Tidy on WMF websites in favour of a pure PHP solution called RemexHtml that I recently wrote. It should eventually become the default for new MediaWiki installations as well. It accepts either form and will initially output "<br />" for compatibility with parser tests. -- Tim Starling (talk) 10:03, 17 February 2017 (UTC)[reply]

Is it possible to create additional magic links? The comments at mw:Requests for comment/Future of magic links make me guess not, but perhaps it's saying that existing ones included in core MediaWiki are unchangeable but not commenting on the idea of adding others. Help:Magic links says that the links are defined by Parser.php, but to my surprise, that page is a 404 error.

Background — I wonder if it would be useful to add one for OCLC numbers (e.g. OCLC 636181190 would produce OCLC 636181190) for the English Wikipedia only, but there's no point in requesting people's opinions in a proposal if it's not possible to implement it here. Nyttend (talk) 02:36, 13 February 2017 (UTC)[reply]

@Nyttend: I fixed that link for you by updating {{MediaWiki file}}. To answer your question, sure it's possible, but it would require changes to the core MediaWiki software, and that probably won't happen. — Mr. Stradivarius ^{♪ talk ♪} 02:59, 13 February 2017 (UTC)[reply]

Thank you for fix and for response. "require changes to the core MediaWiki software", I wasn't suggesting something that would require that much work (I just wanted the change if we could tweak some local settings), so thank you for preventing a pointless discussion. Nyttend (talk) 03:01, 13 February 2017 (UTC)[reply]

It's not really a lot of work (well, minus the localized bit), but it's definitely more than a configuration change. And, as the RFC points out, such feature requests would be denied if they were requested today (for a bunch of reasons outlined there). Lua modules and templates are far more suited to do this (or heck, even some parser functions if such an extension was written) than by the very fragile and inflexible magic link code. ^

^{[omg plz]} 21:01, 13 February 2017 (UTC)[reply

]

But a major issue at the Meta RFC is that local projects can't modify or exempt themselves from the existing magic links, and if this were just a configuration change, it wouldn't have those issues. Nyttend (talk) 00:04, 14 February 2017 (UTC)[reply]

Adding configuration is basically the same problem as adding localisation. If you have a serialisation language, it is really annoying to have arbitrary tokens. That's why developers want to get rid of it. These features are tokens in the parser language, inflexible ones, non-translatable ones, non-configurable ones, now, but especially into the future. There is a reason a template or magic word starts with {{ and that is because it isn't natural language and isn't generally used in natural language. I get that people focus on the usability of such 'magic' links, but this is not the right technical solution. The right usability + technical solution is to have the edit page say "it looks like you are pasting an OCLC number, would you like me to properly format that for you". —TheDJ (talk • contribs) 09:52, 14 February 2017 (UTC)[reply]

People don't want to be reminded of the

Microsoft paperclip. --Redrose64 🌹 (talk) 17:42, 14 February 2017 (UTC)[reply

]

Oh FFS, don't get hung up on the language. Per the 'community' our developers wouldn't even be smart enough to come up with something like clippy, so why even put it in my brain. What i'm proposing requires as much 'intelligence' as the current magic links require, as much as recognizing [[ and opening the insert link dialog. I gave a playful user story, not a design idea. —TheDJ (talk • contribs) 23:55, 14 February 2017 (UTC)[reply]

Is this a technical issue with Visual Editor or mobile editing? Figured I'd post it here to get some eyeballs on it. (The problem is that the brackets around Maharashtra got substituted with object replacement characters, which smells like a bug to me.) https://en.wikipedia.org/w/index.php?title=Worli&diff=763830426&oldid=760079008 —{{u|

I think it's related to mobile editing, probably their browser, or then they accidentally just did something strange. Stryn (talk) 18:06, 13 February 2017 (UTC)[reply]

I've come across something like this before, four or five years ago - turned out that somebody had a browser extension that modified certain characters to a different Unicode codepoint. --Redrose64 🌹 (talk) 23:42, 13 February 2017 (UTC)[reply]

18:06, 13 February 2017 (UTC)

One editor (johnuniq) has taken time to start messing with Cebu and {{Bohol}}. As far as I know, or those messages were abandoned at least 2 years ago when Lua came in. So do the messages have any meaning, and should anything be done? 112.198.102.167 (talk) 00:20, 14 February 2017 (UTC)[reply]

This relates to my posts at User talk:Alice Zhang Mengping#Template:PHxxx regarding the "pages with script errors" category (articles). I have not taken any action other than post at the above talk and at Talk:Cebu#Template errors. It was JohnBlackburne who edited Cebu. Viewing the html source for Cebu and searching for "NewPP" currently shows "Lua time usage: 10.046/10.000 seconds". That is the reason the article has numerous error messages ("The time allocated for running scripts has expired") at the bottom. The timing varies presumably depending on the speed and load of the server that renders the page. Sometimes Cebu displays without errors (because the Lua time is just under 10 seconds), but often errors are shown. I have been contemplating asking for opinions here. The problem appears to be that {{PH wikidata}} is called 1193 times. It often accesses the same property multiple times because of the limitations of templates which cannot store a value in a temporary variable, and my guess is that the large number of calls to Module:Wikidata is too much overhead. Does anyone know what overhead is involved in accessing Wikidata as in a property for the current page, and a property for another page specified by qid? Can several hundred such accesses be reliably done in a reasonable time? Johnuniq (talk) 00:37, 14 February 2017 (UTC)[reply]

Yes, I manually substituted the first level of template (the top level template {{PH town table}} is utterly useless as it just invokes one of three templates based on whether it‘s a top, middle or bottom, but this something an editor knows and is not going to change; better to invoke the template directly). Hard to tell how much of a speedup it provided, it did not fix the problem.

The next step would be to look at the sub-templates, {{PH town table/mid}} in particular where most of the time is spent. But the more time I spent down that rabbit whole the more I discovered the templates are unfixable. {{PH town table/mid}} invokes more templates {{PH town table/mid5}} ... {{PH town table/mid9}}, some of which invoke yet more templates. None of the templates are documented anywhere, while the coding style renders them particularly unmaintainable: not only the multiple interdependencies but the use of parser functions rather than Lua. Lua is faster and more maintainable in general, and would be especially beneficial here in dealing with the excessive calls to {{PH wikidata}}.

So the best thing would be to replace these with a Lua implementation. Despite their complexity they are not doing anything that difficult, so a replacement should be much simpler. The performance benefits of doing so should be especially significant in this case. In the meantime perhaps substitute the templates, i.e. replace them with the data, to fix the performance and error problems.--JohnBlackburne^words_deeds 01:12, 14 February 2017 (UTC)[reply]

As I thought - you have know idea what you are talking about. Changing e.g. {{Cebu}}, works maybe once ever 3 months, so work means 10 sec / 3 months. The fact is that the messages are read only by ex-programmers with nothing else to do. Subroutines are to get rid of editors, not the other way round. 112.198.102.167 (talk) 01:33, 14 February 2017 (UTC)[reply]

Presumably you have not yet seen the errors that often occur towards the end of Cebu and occasionally at Bohol. My first message above included the fact that the Lua time usage at the time I posted was 10.046/10.000 seconds. That means 10.046 seconds were used out of the maximum possible of 10.000 seconds (it went slightly over because that was when the server noticed and truncated the process that was rendering the page). Right now, Cebu is working without errors because the Lua time was 9.679/10.000 seconds when it tried again. However, that value is right on the limit which is not sustainable. Johnuniq (talk) 03:09, 14 February 2017 (UTC)[reply]

They are not "read only by ex-programmers", or even only by programmers. The reason it came to my attention is it frequently ends up in the category, Category:Pages with script errors. Normally that happens when a script fails with a programming error, but occasionally as here when the page runs out of time running scripts which is more serious, as when that happens every script on the page executing after time runs out fails, and there can be dozens of red messages on the page visible to everyone.

The arguably more serious problem is that even when there are no errors and red messages the page takes way too long to generate. This impacts anyone editing the page, hitting edit or save and wanting to see their work. It is not a long or complex page, so should not have such performance problems.--JohnBlackburne^words_deeds 03:14, 14 February 2017 (UTC)[reply]

{{

sigfig}}, which could perhaps be simplified to #expr? Pppery 03:40, 14 February 2017 (UTC)[reply

]

I think the bottleneck is the fact that there are 1193 calls to {{PH wikidata}}. See Talk:Cebu#Template errors. Johnuniq (talk) 04:39, 14 February 2017 (UTC)[reply]

@Johnuniq: I've made some changes in the sandbox that reduce the number of calls by four per use. There's probably still too many calls, but that might push it out of the timeout state. Pppery 02:20, 15 February 2017 (UTC)[reply]

I would welcome anything which brings the Lua time down so it is consistently below, say, 8 seconds. I haven't looked at your changes but you could pop them in and see what happens. I was just gloomily contemplating what would be involved in translating {{PH wikidata}} to a module. It is certainly do-able and I think that's where the major gains would occur because it would cut down a lot of the duplicate Wikidata calls. However, I should be doing other things and anything that works would suit me. Johnuniq (talk) 02:41, 15 February 2017 (UTC)[reply]

@Johnuniq: I synced my changes, and the lua time seems to have dropped by one second, putting it in the 8-9 range without any overflows in like 5 previews. Pppery 03:22, 15 February 2017 (UTC)[reply]

(And then was reverted because I forgot a pair of curly brackets ..., added the missing pair, and synced it again) Pppery 03:39, 15 February 2017 (UTC) [reply]

As you say, your edits at {{PH town table/mid}} and {{PH town table/mid5}} have reduced the Lua time at Cebu to 8.4 seconds which is higher than we would like, but at least it works. Thanks. JohnBlackburne and I patrol the error category and will notice if it creeps back up. Johnuniq (talk) 06:41, 15 February 2017 (UTC)[reply]

Scribunto has a function profiler on preview, but you need to add a "forceprofile" parameter when submitting the preview and it's somewhat broken at the moment with HHVM. With a little work I got some useful results out of it:

The "getLabel" method there that's using 5.9 seconds of the 10-second time limit is almost certainly mw:Extension:Wikibase Client/Lua#mw.wikibase.entity:getLabel, i.e. Johnuniq is probably right about excessive calls to wikidata. Anomie⚔ 04:56, 14 February 2017 (UTC)[reply]

Very interesting, thanks. While contemplating debugging tools, it would be useful if there were a way to tell a sandbox that it should act like a particular article as far as Wikidata is concerned. For example, I captured all the PHxxx templates from the wikitext at Cebu and was planning to save it in a sandbox to get the NewPP report, and then repeat after removing some of the calls to see the difference. However, I stopped on realizing that a sandbox would behave very differently from the article due to Wikidata. At Special:ExpandTemplates I can enter "Cebu" for the Context title to make it work properly getting Wikidata properties, but there is no NewPP report for that Special page. Johnuniq (talk) 06:08, 14 February 2017 (UTC)[reply]

You could do that using the API's parse action (see the title and text parameters), or possibly with Special:TemplateSandbox. Or just by using the editor's preview button instead of saving the edit. Anomie⚔ 13:25, 14 February 2017 (UTC)[reply]

You know, when someone edit the page but got reverted.

No, because a revert is merely an edit that cancels out the effect of one or more previous edits. They're not marked in any special way, except that some reversion methods (such as

WP:ROLLBACK) use a boilerplate edit summary. --Redrose64 🌹 (talk) 01:01, 14 February 2017 (UTC)[reply

]

Users with the rollback privilege can mark edits and their rollback as a bot edits, even if it's interactive. That's as close as you're going to get. --Unready (talk) 04:07, 14 February 2017 (UTC)[reply]

"Users with the rollback privilege can mark edits and their rollback as a bot edits, even if it's interactive." UH? Since when (and how? but because of

books} 12:49, 14 February 2017 (UTC)[reply

]

It's not part of the rollback right (or the rollbackers group), it's the markbotedits right that sysops have. The "how" is documented at mw:Manual:Administrators#Rollback. As for "since when", apparently since December 2003, although back then it was just part of the sysop package. It was moved to the rollback right in October 2004, seemingly broken in November 2007 due to a typo, and took its modern use of the markbotedits right in August 2008. Anomie⚔ 13:47, 14 February 2017 (UTC)[reply]

That seems like a terrible idea... The idea, as the manual link above says, is to hide vandalism (which is when someone would/should use rollback) from Recent Changes, although it still doesn't hide it if users choose to show bot edits. Also, oops, it's a separate privilege associated with rollback, not rollback itself. --Unready (talk) 22:15, 14 February 2017 (UTC)[reply]

From

Since they do not concern a single url, the usual Mw:Blacklist, filters or XlinkBot can't be used normally. The only thing playing in my head is making XlinkBot have this additional function which checks any edit with a GB link, uses the available GB citation tools to extract the publisher, compares that to its own blacklist and then acts. Is this feasible or are there any better ideas? Ugog Nizdast (talk) 07:46, 14 February 2017 (UTC)[reply]

Shouldn't be hard for the bot to find it. Google Book webpages contain metadata in the page source, including a line labeled "publisher". Should be feasible for a bot to check new links to Google Books, pull out that metadata, and then if the publisher appears to be on a blacklist, add the diff to some page for review by a human. And of course if it's just amazingly efficient, enable the bot to just revert. Someguy1221 (talk) 08:35, 14 February 2017 (UTC)[reply]

Hi, I have an idea for a javascript (which is for the moment pretty much just an idea) to automatically show user status (online, offline, away, etc.) based on how recent their most recent contribution has been. The biggest hurdle I'm facing right now is arguably the lack of javascript programming skills in me. I do know a bit C++ so the task should be easier.

Anyway, to the components of the idea:

1. A page in the user's namespace, let's say "USTATUS" (created for the purpose) that should have a single word, like "online","offline","away", etc.
2. A piece of code that is placed in the user's custom .js file that runs every time the user visits any page on Wikipedia. (I'm assuming that the javascript runs this way). This code snippet serves to check the above mentioned user's page and replace all content on page USTATUS with the word "online" (or leave it unchanged if the page already has nothing but "online").
3. Another piece of javascript code (placed on a separate page - NOT in user's custom .js) that, when run, checks the user's "Conributions" page and retrieves the time of the latest contribution. If the latest contribution is more than, say, 600 seconds old, this code should replace everything on USTATUS with "away", or if it is greater than 3600 seconds, "offline".
4. A template that is placed on the user's talk page that checks that checks USTATUS each time it is run (or purged) and shows status accordingly. (Example: If USTATUS has "online", the template should show something like "The user is online"). Also, this template should have the above component (3) embedded in it so that each time the template is purged, the javascript is executed. Of course, first the code should be executed, then the template should show the appropriate message reflecting "online","offline" or "away". (This is the part I'm mostly doubtful of. I'm not sure if such embedding is possible)
5. Optionally: Another piece of code in the user's custom javascript file that changes the "Log out" button to include code to change USTATUS to "offline". (NOTE: Not an extra button, but modifying the same one)

Note that I'm already aware of the related user scripts that exist (and maybe some code could be borrowed from them) but none of them automate the process.

Any input, regarding the logic or anything else would be greatly appreciated. Contact me on my talk page if need be. Also, I'm hoping this is the right place to post this. Thank you! RoCo^(talk) 13:59, 14 February 2017 (UTC)[reply]

(1) and (4) (apart from embedding 3) can already be done with a template like {{Statustop}} or similar. (2) and (5) should be possible to code. (3) probably isn't possible the way you imagine it – you can't force other users to run your personal scripts when they view/purge your userspace pages – and if you try to do it yourself, the code from (2) would be triggered and set your status to online. - Evad37 [talk] 14:37, 14 February 2017 (UTC)[reply]

(3) checks the contributions of the user where the template is present. It does not matter what the status is until another user wants to find out. So it can be "online" for a long time, even for days if no one checks the page. The moment another editor clicks the purge button on the template, it should check recent contributions and update as such. I don't see where (2) would come into place as the script doesn't run when the user is not using Wikipedia. Am I missing a point? EDIT:To clarify, (2) is in the custom javascript, whereas (3) is common for all users, and is available on a separate page.RoCo^(talk) 14:47, 14 February 2017 (UTC)[reply]

While technically possible to add common js for all users, in

bot that runs at specific times throughout the day, and updates the status subpages of users (who have signed up for it) by checking the timestamp of their last contribution. - Evad37 [talk] 15:30, 14 February 2017 (UTC)[reply

]

I'm truly amazed by my ability to mess statements up. This is embarrassing, but I didn't mean "common" in that way.. (2) would be in user's personal javascript. Good. (3) would be on another javascript page (For example, in my user space, User:Rollingcontributor:newfile.js or something). When the template is purged, it should run the code on newfile.js, with an argument as the user where the template was originally placed. The newfile.js code should then edit what user page has been passed to it as an argument, and then the template should check it and update. Did I confuse you even more? If yes, sorry, let me know. Also, a bot would consume a lot of resources if it needs to constantly monitor a lot of pages. RoCo^(talk) 15:42, 14 February 2017 (UTC)[reply]

Quite right - the developers requested we stop allowing status bots to operate because they made too many edits. –xeno^talk 15:45, 14 February 2017 (UTC)[reply]

I didn't know there existed a bot for this. I couldn't find much about what the bot actually did. Could you let me know? Thanks! RoCo^(talk) 15:54, 14 February 2017 (UTC)[reply]

This might be worth referring to. RoCo^(talk) 15:59, 14 February 2017 (UTC)[reply]

@Rollingcontributor: See User talk:SoxBot V for other links and the oldest contributions of the bot. –xeno^talk 19:21, 14 February 2017 (UTC)[reply]

Maybe its also me... it is quite late in my timezone. Anyway, perhaps you clarify if this is what you want:

• You haven't been editing for several hours, and in fact are not online, or interacting with Wikipedia at all – no open tabs/windows, and lets say you've also logged out – but you status page is still set to 'online'. Another user comes along, decides to check your status, and so clicks on the purge link in the template. An edit gets made to your status page, changing 'online' to 'offline', and the template now shows you are offline.

Now, if that's right, who makes the edit (as shown in the page history)?... and if you are not online, who is running the javascript for this? - Evad37 [talk] 16:24, 14 February 2017 (UTC)[reply]

Well, that's something I didn't think about! I guess it would be technically possible for the user who presses the purge or whatever on the template to make the edit? Wrong? Also, I didn't quite understand "and if you are not online, who is running the javascript for this". The script that changes to "online" is only needed when the user is actually online. The script that changes to "away" or "offline" is, as told earlier, on a separate page, which is run when someone else comes and presses purge. So what we would be needing is a "purge" button that does more than just purge. Did it clarify? RoCo^(talk) 16:38, 14 February 2017 (UTC)[reply]

As noted by Xeno, this won't happen because the developers forbid it (at least the 'automated part of it). And that is because wikitext is not designed for problems like this. If you want something like this, you should integrate with a more suitable system. I think you will want to integrate with something

slack.com-like (perhaps a mattermost or rocket chat instance on wmflabs) and use THAT to keep track of status. —TheDJ (talk • contribs) 16:49, 14 February 2017 (UTC)[reply

]

BTW. 2 and 5 are exactly what TheDJ/Qui and a few other status changer scripts used to do. But it doesn't work properly enough, without a good solution for 3 and 4. Most people just stopped using it after StatusBot was stopped, because it's just annoying and unreliable without automating parts of the status updates. —TheDJ (talk • contribs) 16:57, 14 February 2017 (UTC)[reply]

The edits would only be made when a user explicitly clicks on the button (and only once the user logs in). This doesn't use a bot, and doesn't make a lot of edits, as edits are made only when they are required. It would still be a good idea to integrate, as you've suggested, but that could take a lot of time, effort and programming. Also, it doesn't hurt to try and make this code work, right? RoCo^(talk) 17:02, 14 February 2017 (UTC)[reply]

Laziness with regard to implementations doesn't scale to top 10 websites. The whole point is, yes fixing this properly is a lot of work. Doing it not-properly has been tried in various ways already and didn't work (proof, you didn't know about the ways that have been tried before). —TheDJ (talk • contribs) 17:21, 14 February 2017 (UTC)[reply]

I know little about the advanced programming and integration into a larger system. I only suggested what was in my immediate power and knowledge to try and help make this work. I do accept that laziness in implementation has no place on Wikipedia, but, as you've seen (and so did I now), the problem is nearly a decade old, and there hasn't been a proper solution yet, even though it was pointed by numerous users. Anyway, it would still be better to escalate this. RoCo^(talk) 17:46, 14 February 2017 (UTC)[reply]

We have hundreds if not thousands of technical 'problems' that are a decade old. And you could say that having only 4,931 featured articles after 16 years is a problem. But it's all relative and the easiest solution to all these problems is 'more skilled contributors to produce more results'. But that's also where the scarcity is. That said, you can easily take an old copy of Qui, fork it, fix it, and reach 50-1000 people. But that's still just a drop in the ocean. In my opinion the effort required for that is better invested differently at this point in time (either writing articles, or writing a proper system). —TheDJ (talk • contribs) 00:04, 15 February 2017 (UTC)[reply]

If you want to see when a user edited last simply by loading his/her user page or talk page, see User:PleaseStand/User info. עוד מישהו Od Mishehu 05:14, 15 February 2017 (UTC)[reply]

Since AFAICT, it's been over 8.5 years since the last status bot was shut down, it's perhaps worth just checking that developers will still reject any bot.

More importantly, both Extension:OnlineStatus [14] and Extension:OnlineStatusBar [15] are both marked as stable. I don't know how true it is, but I see mention of the extensions at Wikipedia:Village pump (technical)/Archive 81#Status changers, Wikipedia:Village_pump (technical)/Archive 94#User online status Wikipedia:Village pump (proposals)/Archive 81#Online Status. Notably in the last discussion the conclusion is to move development of opt-in online status to technical review. I think the key problem is even if the extensions are truly stable and suitable for en.wikipedia, the developers are bound to require very good evidence of that before they consider implementing them. There is mention of this in the discussion, and I think that's the hold up. [16] seems to be the BugZilla which is for OnlineStatusBar but there's been no real activity since 2012 and it never went through proper review.

As I understand it, the OnlineStatusBar has some automation. OnlineStatus doesn't have any. But I think both would also be amenable to a bot and since these extensions use their own database to store the online status (so don't need to store so much stuff and can also be de-prioritised), they will probably get around performance concerns of the developers if implemented properly. (Actually if you look at discussion around time of the bots being shut down, developers suggested an extension.) So it seems the extensions may be a possibility but people will need to help with the reviews and somehow convince the developers to partake. Stronger community desire for the extension is likely to help with the later.

Nil Einne (talk) 07:23, 15 February 2017 (UTC)[reply]

Taking into Consideration the different scripts that have been used previously, I believe it is indeed possible. I will likely visit this idea sometime soon and see if I get access to any more information in the meanwhile. Thank you everyone for your comments and suggestions. RoCo^(talk) 12:18, 15 February 2017 (UTC)[reply]

Is there a tool or API available to get back a list of all articles that cite a particular reference? Thanks Pj quil (talk) 16:45, 14 February 2017 (UTC)[reply]

Pj quil, how about Special:LinkSearch? --NeilN ^{talk to me} 16:48, 14 February 2017 (UTC)[reply]

NeilN That's great! Just what I was looking for. Thanks! Pj quil (talk) 16:58, 14 February 2017 (UTC)[reply]

Hi, y'all. I want to [Restore this version] of my

The problem is that there is a DS/A in the Deleted portion, so the Edit Filter blocks the Restore. Any ideas? I am not sure if this diff is any different.

I am also switching over to

]

Update: I ran [Restore this version] via Twinkle again and this time the Edit Filter let the Restore go through.

Okay, so now, can anybody help me make Archy McArchface work? 1CA was only working intermittently. Ping me back. Cheers! {{u|

Talk} 05:08, 15 February 2017 (UTC)[reply

]

For anybody wondering what DS/A was, per the edit filter log, it's

discretionary sanctions alerts. Graham87 08:43, 15 February 2017 (UTC)[reply

]

This filter is set to :warn+tag" - that is, make sure you know what you're doing, and make it easy for other suers to review the eidt as required based on what it looks like. Many of these filters have a medium false positive rate. If you have any future issues with the edit filter, please report them at Wikipedia:Edit filter/False positives, as the warning you got tells you to. עוד מישהו Od Mishehu 11:55, 15 February 2017 (UTC)[reply]

Changing Preferences UI interface

Where would I go to request a wording change to a Preferences page? See Wikipedia_talk:Signatures#Link_required.3F --NeilN ^{talk to me} 16:58, 15 February 2017 (UTC)[reply]

https://en.wikipedia.org/wiki/Special:Preferences?uselang=qqx says "(tog-fancysig)" so the message is MediaWiki:Tog-fancysig for users with the default language "en - English". {{Edit fully-protected}} can be used on the talk page. PrimeHunter (talk) 17:39, 15 February 2017 (UTC)[reply]

Thank you very much PrimeHunter. --NeilN ^{talk to me} 20:06, 15 February 2017 (UTC)[reply]

{{wayback}}

How should we handle the case of

C 17:32, 15 February 2017 (UTC)[reply

]

One posibility: Set up {{

subst:wayback}} will become a normal-looking use of {{webarchive}}. Having done that, put {{wayback}} into Category:Wikipedia templates to be automatically substituted, and tell users not to use it. The few users who don't see this notice, or who forget it, will have the template replaced by a bot. עוד מישהו Od Mishehu 17:51, 15 February 2017 (UTC)[reply

]

Have it transclude {{webarchive}} with the correct parameters and make the Wayback template to be substituted. All transclusions will throw a big red error.—CYBERPOWER (Chat) 20:29, 15 February 2017 (UTC)[reply]

WP:HAITI

There is a gadget used (

WP:HAITI? We would prefer to manually include Project Caribbean on a case-by-case basis where deemed applicable to its entirely, such as geography-based articles etc. Project Caribbean sadly is also largely inactive, which furthers our need for this code to be amended as soon as possible. I was referred here by Meno25, in hopes of resolving this issue. Please ping me in a response. Thank you kindly. Savvyjack23 (talk) 20:53, 15 February 2017 (UTC)[reply

]

@Savvyjack23: User:Kephir/gadgets/rater is not what MediaWiki calls a gadget. It's a user script by User:Kephir who would be the natural person to ask. I looked around and found User:Kephir/gadgets/rater/aliases.js which says:

"WikiProject Haiti": "WikiProject Caribbean",

Removing that line would probably prevent such Haiti edits in the future. {{WikiProject Haiti}} hasn't redirected to {{WikiProject Caribbean}} since 2014.[19] User:Kephir/gadgets/rater/aliases.js might have other obsolete data but I haven't examined it. PrimeHunter (talk) 21:24, 15 February 2017 (UTC)[reply]

@Savvyjack23 and PrimeHunter: I removed that line and tested the script. It should be working correctly now. Thank you. --Meno25 (talk) 09:51, 16 February 2017 (UTC)[reply]

Structured Data Errors

Hello. To whom it may concern, while running some random Wikipedia articles in Google's Structured Data Testing Tool there are errors which show up. Does anybody know if this poses an indexing problem on Google's Knowledge Graph and if so does anybody know how to fix them? --Omer Toledano (talk) 07:54, 16 February 2017 (UTC)[reply]

What are the exact "errors which show up"? --Malyacko (talk) 10:13, 16 February 2017 (UTC)[reply]

Problem with citation generation

Tracked in Phabricator
Task T157152

I have two questions -

1. Can someone advise me on the best place to post this sort of concern?
2. My actual concern is the below issue.

I tried to generate a citation from a PMID with the citation generator in what I think is the Wikipedia:RefToolbar.

Here is what I get With source editor, input is PMID (missing PMC link)

• Yuk, SM; Han, KT; Kim, SJ; Kim, W; Sohn, TY; Jeon, B; Kim, YM; Park, EC (16 September 2015). "Consumption of pharmaceutical drugs in exception region of separation for drug prescribing and dispensing program in South Korea". Substance abuse treatment, prevention, and policy. 10: 36.
  PMID 26376979
  .

With visual editor, input is PMID (problem with PMC link)

• Yuk, Sang Mi; Han, Kyu-Tae; Kim, Sun Jung; Kim, Woorim; Sohn, Tae Yong; Jeon, Byungyool; Kim, Young-Man; Park, Eun-Cheol (2015-09-16). "Consumption of pharmaceutical drugs in exception region of separation for drug prescribing and dispensing program in South Korea". Substance Abuse Treatment, Prevention, and Policy. 10: 36.
  PMID 26376979.{{cite journal}}: CS1 maint: PMC format (link) CS1 maint: unflagged free DOI (link
  )

This citation should have a PMC link, which would mean a correct number in the PMC field. The problem with the second citation is that it inserts the letters "PMC" before the number in the field. Removing those letters generates the correct citation, which is

• Yuk, Sang Mi; Han, Kyu-Tae; Kim, Sun Jung; Kim, Woorim; Sohn, Tae Yong; Jeon, Byungyool; Kim, Young-Man; Park, Eun-Cheol (2015-09-16). "Consumption of pharmaceutical drugs in exception region of separation for drug prescribing and dispensing program in South Korea". Substance Abuse Treatment, Prevention, and Policy. 10: 36.
  PMID 26376979.{{cite journal}}: CS1 maint: unflagged free DOI (link
  )

Here is the request -

• Harmonize the citation generators
• PMC field should include PMC number without appending the letters PMC in the front

Thoughts? To whom should I direct this feedback? Blue Rasberry (talk) 16:17, 16 February 2017 (UTC)[reply]

This bug is being tracked in Phabricator bug report T157152. Until it is resolved, you'll need to remove the "PMC" characters manually. – Jonesey95 (talk) 17:29, 16 February 2017 (UTC)[reply]

Resolved

from an English Wikipedia perspective. Blue Rasberry (talk) 20:34, 16 February 2017 (UTC)[reply]

Thursday blues

The user interface in MonoBook skin has changed. When editing a page, the edit summary window takes up more space then it did before; and when creating a new section, the section heading box is bigger. Both have a blue border when they have focus. Blue border - good; more occupation of real estate - bad. --Redrose64 🌹 (talk) 21:55, 16 February 2017 (UTC)[reply]

Seems to be the case in Vector as well. Eman235/talk 22:23, 16 February 2017 (UTC)[reply]

The following css placed on Special:MyPage/common.css (or skin-specific css page) will reduce the size of the box:

#wpSummary { padding: 0.2em !important; }

(you can play around with the number until it looks right for you) - Evad37 [talk] 00:07, 17 February 2017 (UTC)[reply]

I think the font size has changed too. Does anyone remember what the old one was? Daß Wölf 01:13, 17 February 2017 (UTC)[reply]

The change was linked from Tech News above. Luckily, it was the first line of the many changes listed, T152025. The changes appear to have been made here, but I could very well be wrong. Does that help anyone? – Jonesey95 (talk) 06:04, 17 February 2017 (UTC)[reply]

Watchlist

Is there an ongoing issue with the 'mark all pages as visited' button? Appears when first clicking on watchlist but then vanishes as the page completes loading. (Using Chrome). Thanks. Eagleash (talk) 01:28, 17 February 2017 (UTC)[reply]

Ditto. Mine disappeared completely. —ATS 🖖 talk 01:44, 17 February 2017 (UTC)[reply]

Ditto -- ferret (talk) 02:25, 17 February 2017 (UTC)[reply]

Same here: Mobile Safari on iPad: brief glimpse as page loads, then it's gone. I also noticed more spacious text boxes—the edit summary, for instance—that are very welcome! — Gorthian (talk) 02:28, 17 February 2017 (UTC)[reply]

It may be an issue with gadget loading order. It's hidden by "(This loads the base style for the watchlist. Please do not disable this option.)" at Special:Preferences#mw-prefsection-gadgets. The code is in MediaWiki:Gadget-WatchlistBase.css:

#mw-watchlist-resetbutton {
    display: none;
}

It should then be unhidden if any of the two following gadgets are enabled: "Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes" and "Display pages on your watchlist that have changed since your last visit in bold". They both include:

#mw-watchlist-resetbutton {
    display: block;
}

But something goes wrong and it stays hidden. It can be forced to display by placing the latter code in your CSS. PrimeHunter (talk) 02:32, 17 February 2017 (UTC)[reply]

That worked. My thanks! Now someone needs to fix the edit summary line that seems larger but covers up part of the text. —ATS 🖖 talk 02:38, 17 February 2017 (UTC)[reply]

Worked for me too. With regard to the ES box, the box for adding the heading after clicking 'new section' also appeared larger when starting this 'thread'. Thanks PrimeHunter Eagleash (talk) 02:58, 17 February 2017 (UTC)[reply]

PrimeHunter, i don't exactly understand.

talk) 05:57, 17 February 2017 (UTC)[reply

]