Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with 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.

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

Internal search engine results

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))

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

@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)

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)

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)

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

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)

@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)

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)

@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)

@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)

@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)

@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)

@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)

@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)

@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)

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)

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)

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)

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)

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)

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

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. ^demon^{[omg plz]} 20:37, 30 January 2017 (UTC)

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)

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... ^demon^{[omg plz]} 02:16, 31 January 2017 (UTC)

It is funny that those who help build an encyclopedia won't do the basic research to back their claims when it really counts, though having made a similar request (based on indexing time html5 tag and sorting using that) in a non-WMF it is easy to empathize.

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)

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)

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)

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)

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)

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)

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." ^demon^{[omg plz]} 02:48, 10 February 2017 (UTC)

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)

• 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)

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

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)

Extraneous spaces in edit requests

Hey all, weird question. I notice that the grand majority of the time, when a user submits an edit request to a talk page, like here or here, an extraneous space often appears before the user's signature. Any idea why this could be? Terribly anal of me, I know, I'm just curious cuz the resulting signature-in-a-box irritates the crap out of me. Thanks, Cyphoidbomb (talk) 17:56, 7 February 2017 (UTC)

In short, they're not following the instruction to "Write your request ABOVE this line". Template:Submit an edit request/preload ends with the line

}}}} ~~<noinclude />~~

Those two pairs of braces terminate a {{subst:trim}} and a {{subst:^}} and if nothing is entered, they substitute to nothing - and the next character is a space, which ends up at the start of a line, with the signature following it. --Redrose64 🌹 (talk) 18:12, 7 February 2017 (UTC)

Thanks for the explanation, Redrose64. Appreciated. Cyphoidbomb (talk) 17:53, 8 February 2017 (UTC)

If we hide the space from the MediaWiki parser, by altering that line to

}}}}&#32;~~<noinclude />~~

it'll still work, and the signature will have a normal (not monospaced) appearance when no text is entered. --Redrose64 🌹 (talk) 00:13, 9 February 2017 (UTC)

Ranking articles in a certain category by number of incoming wikilinks?

Hi! Does anyone know if there is a tool that lets you rank Wikipedia articles that are in a certain category according to how many other Wikipedia articles link to them? I'm looking for a method that is easier than going into the "What links here" page for each individual article in a category and manually filling the data into a spreadsheet. --Dodi 8238 (talk) 09:16, 8 February 2017 (UTC)

A query can probably sort this; it might also be an interesting change to WP:Petscan. --Izno (talk) 12:59, 8 February 2017 (UTC)

Thanks for the reply! I figured out how to get the result I was looking for in Petscan:

1. Enter a category in the "Categories" section
2. Select "Sort: by incoming links (ns0)" and "Sort order: descending" in the "Output" section
3. Press "Do it!"

--Dodi 8238 (talk) 19:25, 8 February 2017 (UTC)

Template:CSS image crop

I have a question about using Template:CSS image crop. It is a very useful template for displaying large maps, and I have used it on several articles. At Port Anderson, Mississippi, I used it in the infobox (where it must be center-justified to display properly). At Mound Landing, Mississippi and at Christie Street, I added it to the article. My question is: is there an easy way to set up this template? Finding the exact "oTop" and "oLeft" coordinates is entirely by trial and error. To do this, I load the template into my sandbox, start with a very small "bSize", and then slowly increase the bSize as I manipulate the oTop and OLeft to find the exact spot on the image I am looking for. This can take a very long time when manipulating a large map. Is there a tool or a trick for easily finding the coordinates? Does this meet the definition of a First World problem? Thanks! Magnolia677 (talk) 12:50, 8 February 2017 (UTC)

Note that you are forcing every visitor of Mound Landing, Mississippi, to download a 2440px by 9363px image of almost 5MB, and I don't think that is reasonable. If you have an old phone, that will basically cause it to freeze up and require a reboot of the device. —TheDJ (talk • contribs) 13:30, 8 February 2017 (UTC)

Lack of geographical coordinates in the exported pdf webpages

Hello everybody. I just joined Wikipedia as a user, so please forgive me in case I am not reporting this the right way or in the right place. I am currently saving some Wikipedia webpages as pdf files (using the tool "Download as PDF" in the "Print/export" section) to store for future reviews. The pages I am saving are related to geographical locations, therefore the coordinates usually reported in the top-right corner of the page are really useful. However, I noticed that in the pdf version of the Wikipedia page, the coordinates are omitted. Am I the only one who thinks this would be a nice feature to implement (and most probably not that difficult to implement for the programmers)? Would it be possible, in the future, to modify the exporting tool to include them? — Preceding unsigned comment added by Tommasosacco (talk • contribs) 15:45, 8 February 2017 (UTC)

From Wikipedia:Village_pump_(technical)/Archive_152#Problem_with_WP:EMAIL

Can we get an accurate estimate of how many users were affected and not the heretofore incorrect "all the spam systems out there from blocking us"? It's pretty irritating to now have every email display as from "Wikipedia". --NeilN ^{talk to me} 23:25, 8 February 2017 (UTC)

Revision History Statistics

Anyone know how to get the revision history statistics? You used to be able to click on "Revision history statistics" on the Revision history screen but this has been replaced with a "Wikihistory" page of very limited use. Anyone know how to access the old version? Hawkeye7 (talk) 03:28, 9 February 2017 (UTC)

Yes, ditto from me. A while back we used to get the pie chart filled in with % edits by user for the current version of an article (which is more relevant than the list of number of edits made by each user going back ten or more years). I found this very useful when coming to an article for the first time and being able to check who were the major contributors so far, with a view to perhaps notifying them if I planned to completely rewrite the article. JG66 (talk) 03:41, 9 February 2017 (UTC)

The links at top of page histories are made by MediaWiki:Histlegend. https://tools.wmflabs.org/xtools-articleinfo was recently removed because the tool was down.[9] It may be back up currently but the xtools have been unstable for years. The bottom of "Page information" under "Tools" in the left pane displays MediaWiki:Pageinfo-footer which has linked to xtools-articleinfo in the past but has only used other tools since 2015. PrimeHunter (talk) 04:03, 9 February 2017 (UTC)

I had a similar reason to JG66. Thanks for that - it worked for me. Hawkeye7 (talk) 19:46, 9 February 2017 (UTC)

Fuzzy image

Resolved

Hello. Pigsonthewing suggested I post here. As I mentioned initially in this thread, I've uploaded a new cover image at Chemistry Education Research and Practice. My source image is high quality, however the displayed image on the page is fuzzy, particularly around the words. How do I fix this? I've tried purging the page. Msuxg (talk) 11:32, 9 February 2017 (UTC)

@Msuxg: This is because the original has a lot of 'noise' pixels around the letters and such. This will confuse the scaling and sharpening algorithms slightly, resulting in soft edges in the small thumbnails (especially with JPG). Either cleaning up the original manually, or finding an original without compression or scanning artefacts is your best bet to improving this. —TheDJ (talk • contribs) 11:45, 9 February 2017 (UTC)

Jpegs are always fuzzy. It's an unavoidable effect of the lossy compression inherent to the JPEG format. An image which is not a photograph (like File:CoverIssueCERP.jpg) shouldn't really use a format that was designed specifically for photos (see JPEG#Typical usage, second paragraph) - instead, something like the PNG format would be significantly better. --Redrose64 🌹 (talk) 12:09, 9 February 2017 (UTC)

The large original has only slight quality issues, and the problems are all scaling artefacts. It will help if you resize the image to something near the display size required on the article page and upload it again at that size. Fair-use images should be low-res anyway. William Avery (talk) 12:22, 9 February 2017 (UTC)

I've done that. Looks better. William Avery (talk) 12:35, 9 February 2017 (UTC)

@Msuxg: Apart from the scaling issues, your 2489 × 3249 version was far too large for a fair use image, and you kept |Low_resolution = Yes at File:CoverIssueCERP.jpg#Summary. See WP:Image resolution. PrimeHunter (talk) 13:17, 9 February 2017 (UTC)

Many thanks to everyone for their help and suggestions, that looks much better now. Msuxg (talk) 13:20, 9 February 2017 (UTC)

Adding status to |statusChanger2.js

Hello all, I was wondering if you could offer some help with how to add a status, "phone", to the above. My current js is here, and the source code for original is here. I have attempted to add the status "phone" by way of making the same additions as Kraftlos did to add sleep, but this has not worked. -- Iazyges Consermonor Opus meum 14:16, 9 February 2017 (UTC)

You didn't say what the problem is. I guess it is that User:Iazyges says "Status: Unknown" when User:Iazyges/Status says "sleepphone". What others see has nothing to do with your JavaScript files which run in your own browser and only affects what you see and can do. User:Iazyges uses {{Statustop}} which doesn't recognize "phone" so that value in User:Iazyges/Status isn't going to work unless you modify or don't use {{Statustop}}. The documentation shows it can redefine what is displayed for "sleep" so you could use "sleep" to display "Phone" with {{Statustop|link=User:Iazyges/Statuses|sleep=Phone}}. This would mean you can no longer display "Sleeping", but offline and away would still be available. Your script is only a fancy way to change the value in User:Iazyges/Status instead of manually editing it. If you keep using the current {{Statustop}} then there is no reason for a script to place "phone" in User:Iazyges/Status. PrimeHunter (talk) 17:59, 9 February 2017 (UTC)

noindex,nofollow

Why somepages have html tag robots with value of noindex,nofollow? Mjbmr (talk) 19:35, 9 February 2017 (UTC)

So that search engines do not index them. Do you have a question about a specific page? --Unready (talk) 19:51, 9 February 2017 (UTC)

See Wikipedia:Controlling search engine indexing for noindex. External links automatically get nofollow, mainly to make link spamming less attractive (I have seen SEO people complain it's to greedily suck up page rank without giving any back). See meta:nofollow. PrimeHunter (talk) 20:27, 9 February 2017 (UTC)

Specifically, this presumably relates to a page like Cody Strong. New pages are not allowed to be indexed until they have been reviewed as part of Wikipedia:New pages patrol. There are currently 14,950 unreviewed pages.. 2596 pages were reviewed this week, so it might take a couple of months before someone comes across it so it can be indexed. -- zzuuzz ^(talk) 20:38, 9 February 2017 (UTC)

Note there is also a timer on these - if the patrolling goes ignored long enough they will start becoming indexed anyway. — xaosflux ^Talk 21:00, 9 February 2017 (UTC)

Yes, 30 days. I'll add some more info to the page. Cenarium (talk) 21:31, 9 February 2017 (UTC)

So why there is no public log for them and why on the info page says "Indexing by robots: Allowed". Mjbmr (talk) 02:27, 10 February 2017 (UTC)

You need to click show patrol log to view the patrol log in logs. The info page saying that indexing is allowed is incorrect, it's a bug, I've made a task for this: phab:T157747. Cenarium (talk) 03:05, 10 February 2017 (UTC)

What about pages that are not patrolled and are created less than a month such as OmarGoshTV. Mjbmr (talk) 06:02, 10 February 2017 (UTC)

I think OmarGoshTV doesn't have noindex because it was moved to that title by an administrator.[10] Administrators are Wikipedia:Autopatrolled. A deleted version was patrolled.[11] PrimeHunter (talk) 11:00, 10 February 2017 (UTC)

It doesn't say any present revision of it was patrolled. Mjbmr (talk) 14:50, 10 February 2017 (UTC)

Indeed there are a couple of bugs affecting moving and patrolling, such as not leaving a log entry when moved, mostly because we can't patrol moves in MW core (phab:T98617). Cenarium (talk) 16:36, 10 February 2017 (UTC)

Wrong colors in upcoming featured image

I'm running Fedora 23 Linux with Firefox 50.1.0. When I open a certain upcoming Featured Picture of the Day, namely Template:POTD/2017-02-16, the thumbnail displays with the wrong color palette—the beige background becomes magenta, the black becomes cyan, and most of the rest is either cyan or magenta also. Same if I click through to the image's own page File:Fromental Halévy, L'Éclair score cover - Restoration.jpg and view the full image or any of the other available sizes. (If I download the image file and open it with xv or okular, it looks normal.) Looking at the file history on the image's page, I see that all the earlier versions appear correctly and there is a comment "+ color profile" on the newest one. Presumably this "color profile" is what's making it not work for me, but this is beyond my knowledge of how JPGs work.

I remember reporting a similar problem with an image once before (I would have been using a different IP address at the time), but I don't remember how it was resolved. Considering that we're talking about a Featured Picture of the Day and that Firefox is not exactly a nonstandard tool, I think there's a case for fixing the problem even if the image is technically correct. --76.71.6.254 (talk) 22:09, 9 February 2017 (UTC)

Added note: I was going to plant a courtesy pointer to this posting on who last edited the image file, but if I've found the the right one, it's semi-protected both on Wikipedia and on Commons, so I can't. --76.71.6.254 (talk) 22:17, 9 February 2017 (UTC)

Does the previous version exhibit the same problem for you? FWIW, beige in the JPG looks beige to me.... --Unready (talk) 23:10, 9 February 2017 (UTC)

No, as I said, all the earlier versions in the image history look normal to me. --76.71.6.254 (talk) 07:49, 10 February 2017 (UTC)

Added information: I've now updated to Fedora 25 with Firefox 51.0.1, and it still looks bad for me. --76.71.6.254 (talk) 23:29, 10 February 2017 (UTC)

Broken gif

Original size

Scaled thumbnail

Scaled thumbnail at 199px

Am wondering if a tech person can help fix an animated gif that doesn't animate until clicking on the image (at the resulting image info page, it anmates fine). There are similar gifs by the same creator that animate fine in articles and don't require going to the image info page for it to animate. The gif creator (Commons user) hasn't edited since 2014, so probably no help there. Please advise if there is more appropriate board for this. Ok, --IHTS (talk) 01:20, 10 February 2017 (UTC)

You failed to link the gif or article but from your contributions I assume you refer to commons:File:Queen (chess) movements.gif. It's affected by mw:Manual:$wgMaxAnimatedGifArea so it only animates if it's used at the original size. I have displayed it here. I don't have a tool to make a smaller version which can be scaled but Wikipedia:Graphics Lab/Illustration workshop or commons:Commons:Graphic Lab/Illustration workshop would probably be the place to ask. PrimeHunter (talk) 01:57, 10 February 2017 (UTC)

The value for commons:File:Queen (chess) movements.gif should be 512 × 512 × 224 = 58,720,256. That's well above the default 1.25e7 at mw:Manual:$wgMaxAnimatedGifArea, but https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php says $wgMaxAnimatedGifArea = 10e7; // 100MP. That should actually be enough here so I guess it only fails because a thumbnail was cached before the limit was raised to the current value. I tried a 199px version (unusual number unlikely to be cached) and it works! The middle version has unspecified size which for me means 220px set at Special:Preferences#mw-prefsection-rendering, and failure to animate. I thought our limit was 50 MP before looking it up. commons:Category:Animated GIF files affected by MediaWiki restrictions has a 50 MP subcategory so I guess the current limit is relatively recent. 50 MP wasn't enough here. PrimeHunter (talk) 02:25, 10 February 2017 (UTC)

Thank you for all the investigative digging & testing, PrimeHunter! Sincere, --IHTS (talk) 12:10, 10 February 2017 (UTC)

I have purged the image at Commons, and it seems that the 220 thumbnail now animates as well. —TheDJ (talk • contribs) 11:57, 10 February 2017 (UTC)

Yes! Could you please do the same thing (purge) for one more? (The other chess piece gifs work fine, only the queen & knight had size limitation problems.) Thank you!

Scaled thumbnail

--IHTS (talk) 12:10, 10 February 2017 (UTC) p.s. (ping) TheDJ --IHTS (talk) 21:11, 10 February 2017 (UTC)

@Ihardlythinkso: You can do this yourself. The WP:PURGE technique is the same at Commons as it is here (see c:Help:Purge), although some of the gadgets are described differently; and like the purge feature here, it's available to all users. --Redrose64 🌹 (talk) 00:39, 11 February 2017 (UTC)

Redrose64, thx, but not working for some reason. (Both Commons & WP, went to Preferences, Gadgets, checked box to turn on Purge option, confirmed my skin is default Vector, ... no Purge gadget appears. Logged out & on again, still nothing.) --IHTS (talk) 01:08, 11 February 2017 (UTC)

The alt method worked, thx for your help! --IHTS (talk) 05:52, 11 February 2017 (UTC)

Try adding ?action=purge at the end of the url. Cenarium (talk) 03:49, 11 February 2017 (UTC)

Worked, thank u! --IHTS (talk) 05:52, 11 February 2017 (UTC)

In Vector, the purge gadget shows as an option in the "More" tab; in MonoBook skin it's a separate tab containing only an asterisk. In both skins, you need to wait for the JavaScript to finish running before it displays reliably. --Redrose64 🌹 (talk) 09:47, 11 February 2017 (UTC)

Is there documentation on the code editor?

Where can I find info about it? The Transhumanist 04:14, 10 February 2017 (UTC)

Found it (mw:Extension:CodeEditor). The Transhumanist 06:07, 10 February 2017 (UTC)

Cyberbot I continually cleaning sandboxes

Since December 16, 2016, Cyberbot I has been continually cleaning template sandboxes without other activity taking place. That has been reported here and here to the bot operator, who thinks it's the fault of the mediawiki software but isn't sure which projects to address at Phabricator. Dhtwiki (talk) 22:29, 10 February 2017 (UTC)

Also User_talk:Cyberpower678#Cyberbot_I_.22no_difference.22_edits - Evad37 [talk] 00:30, 11 February 2017 (UTC)

If there is no content change, it's a null edit, and is not normally recorded in the page history, the user's contributions, etc. The fact that it is being recorded implies that the MediaWiki software is not treating it as a null edit. My guess is that the page contains some strange character which is not being overwritten, so it doesn't show in the diff. There was a case a few years back where redirects had been created with a double newline at the end, and a null edit removed the second newline - but the diff showed no change. --Redrose64 🌹 (talk) 00:20, 11 February 2017 (UTC)

Looking at the bot's source code, it just uses {{subst:Template sandbox reset}} to reset the template sandboxes, so that template would likely be where the problem is. - Evad37 [talk] 00:30, 11 February 2017 (UTC)

I've just replaced the box characters with asterisks[12], maybe that will solve the problem - Evad37 [talk] 00:34, 11 February 2017 (UTC)

It does appear to be a bug, but removing the trailing linefeed in Template:Template sandbox reset resolved it. — xaosflux ^Talk 00:54, 11 February 2017 (UTC)

What's wrong with WT:WikiProject Equine headers

For some reason, on mobile view I see the top header, then the one about the breeds infobox, and...nothing. The additional threads below don't show up separately but as a part of that one. What's wrong? White Arabian Filly ^Neigh 22:54, 10 February 2017 (UTC)

 Fixed. There was an unclosed "div" tag that appears to have been messing up the mobile view. Pinging White Arabian Filly. – Jonesey95 (talk) 00:10, 11 February 2017 (UTC)

Is there some sort of bot malfunction?

Hi. It seems that the table entitled "Genetics articles by quality and importance" on Wikipedia:WikiProject_Genetics hasn't been updated in several days. That is the only one I'm watching, so I don't know if this problem is unique to genetics or is system wide. Could you please check and/or advise me what to do? I've contemplated changing an assessment on some other project page to see if that updates, and if you suggest that I do, I will. Specifically, there are 230 unassessed articles listed at the genetics site, but it appears to me that the assessment ratings actually do appear on the talk page, but aren't showing on the table. Thanks, DennisPietras (talk) 02:48, 11 February 2017 (UTC)

@DennisPietras: I think you are referring to User:WP 1.0 bot/Tables/Project/Genetics, normally updated by User:WP 1.0 bot. That bot's operators are @Theopolisme: and @Wolfgang42: - who have been gone for a while. Last time the project talk at Wikipedia talk:Version 1.0 Editorial Team/Index had a bot issue, @Bamyers99: responded. — xaosflux ^Talk 03:33, 11 February 2017 (UTC)

@Xaosflux: Yes, that is the table in question. Thank you for contacting the right people! DennisPietras (talk) 04:11, 11 February 2017 (UTC)

@Xaosflux and DennisPietras: I am not a maintainer for the WP 1.0 project. The only thing that I did was requested via IRC that a Tool Labs admin restart the webservice. There is a way to request a manual stats update via Update project data. It may be time for someone to invoke the Tool Labs Abandoned tool policy. --Bamyers99 (talk) 18:54, 11 February 2017 (UTC)

Thanks for the update - the risk of relying on a bot operator too much! — xaosflux ^Talk 19:06, 11 February 2017 (UTC)

Thanks all! DennisPietras (talk) 20:33, 11 February 2017 (UTC)

Resolved

dead-end Page

Hello, I want to update this https://sa.wikipedia.org/w/index.php?title=विशेषः:निराग्रपृष्टानि&limit=500&offset=0 page. In English this called https://en.wikipedia.org/wiki/Special:DeadendPages. Please update if some one can. NehalDaveND (talk) 10:54, 11 February 2017 (UTC)

@NehalDaveND: you have to request at phabricator, you can use this ticket as an example phab:T10663. — xaosflux ^Talk 14:32, 11 February 2017 (UTC)

@Xaosflux: Thank you. NehalDaveND (talk) 14:39, 11 February 2017 (UTC)

Some special pages like dead end pages update periodically (e.g. every week, month), due to the heavy amount of processing and time to do this (see https://www.mediawiki.org/wiki/Manual:$wgMiserMode). So it will eventually update at some point, see:

https://phabricator.wikimedia.org/T45668 https://phabricator.wikimedia.org/T17434

The only actionable report here would be correcting the message in the page that erroneously states that the report will not update (and maybe include the next update date) when in reality some special pages in miser mode update at a given interval. — Preceding unsigned comment added by 197.218.83.4 (talk) 15:32, 11 February 2017 (UTC) For small wikis one can use a tool like dev:CacheCheck. — Preceding unsigned comment added by 197.218.83.4 (talk) 15:48, 11 February 2017 (UTC)

Can't log into Wikipedia sites using Safari browser on Apple devices

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 (talk) 11:49, 11 February 2017 (UTC)

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

I did try that, but it doesn't seem to have worked. — SMUconlaw (talk) 18:21, 13 February 2017 (UTC)

Inline images on mobile

At Yngvi#The Ingwaz rune there are runes presented inline with the text using images. Presumably this is because many (most?) people don't have fonts for Unicode runes. On mobile, they appear as block elements, even with frameless, which is supposed to force inline style. Bizarrely, it appears correctly in the edit preview! Hairy Dude (talk) 14:50, 11 February 2017 (UTC)

Prose size script bug?

When running User:Dr_pda/prosesize.js on bouncing ball, it stops functioning after the sentence "If Reynolds number is very low (Re < 1), the force on the ball is described by Stokes' law[7]".

Is the script bugged, or does the article contain some weird css/html thing that makes the script choke? This is the only page I know that the script can't handle. Headbomb {talk / contribs / physics / books} 15:27, 11 February 2017 (UTC)

I don't know what this means, but if you comment out the "Drag" and "Magnus effect" sections, the script works. Feel free to experiment in User:Jonesey95/sandbox3. – Jonesey95 (talk) 17:11, 11 February 2017 (UTC)

I found the reason. This is caused by inline <math></math> tags. Very annoying to say the least. Could anyone fix that script? Or make a new one? Headbomb {talk / contribs / physics / books} 17:25, 11 February 2017 (UTC)

Interactive map

Tracked in Phabricator
Task T138057

Hi. Could someone help me understand why this lovely map works on Meta but not on the English Wikipedia? Thanks in advance! Rehman 17:14, 11 February 2017 (UTC)

@Rehman: looks like its not done being implemented, see phab:T138057. — xaosflux ^Talk 18:51, 11 February 2017 (UTC)

The map is made with <mapframe>...</mapframe> from mw:Extension:Kartographer. meta:Special:Version and our Special:Version both list Kartographer under Installed extensions, but only meta lists <mapframe> under Parser extension tags. It means <mapframe>...</mapframe> is ignored as a tag here and just displayed as text with the inside rendered as wikitext:

<mapframe> problems:

• Attribute "width" is missing
• Attribute "height" is missing

. https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php sets wgKartographerEnableMapFrame to false for Wikipedias except seven languages. I don't know why. phab:T151591 and phab:T154021 show two languages getting it enabled on request with a link to a local consensus. PrimeHunter (talk) 19:49, 11 February 2017 (UTC)

Thanks for the replies User:Xaosflux and User:PrimeHunter. That is a really great feature; I'm sure everyone will agree. Maybe it's time we raise a consensus to enable it here too? Rehman 23:07, 11 February 2017 (UTC)

Per phab:T153158, it looks like English Wikipedia and other large wikipedias will be among the last to get it. Also, until phab:T151665 gets resolved, maps may not work properly with Pending changes-protected pages. - Evad37 [talk] 23:53, 11 February 2017 (UTC)

Note that <maplink>...</maplink> is available, and there's even a template {{maplink}} to make it easier to use. - Evad37 [talk] 23:56, 11 February 2017 (UTC)

Special:MyContribs

This page doesn't work (it should link to Special:MyContributions, as Special:Contribs does to Special:Contributions) 95.49.34.243 (talk) 18:22, 11 February 2017 (UTC)

The Special: namespace is beyond what can be technicaly done on-wiki. Please see Wikipedia:Bug reports and feature requests. עוד מישהו Od Mishehu 18:29, 11 February 2017 (UTC)

If by "it should work" you mean it was working and broke, can you say the last time it did work? If you mean "I would like this changed", follow Od Mishehu's link - Special: pages redirects are called "aliases" when placing a phabricator ticket. — xaosflux ^Talk 18:31, 11 February 2017 (UTC)

I don't think Special:MyContribs has ever worked or been promised to work. mw:Release notes/1.18#New features in 1.18 only says "Special:Contribs now redirects to Special:Contributions." A wiki cannot redirect special pages so it would have to be done in MediaWiki. It's rare to link to Special:MyContributions and it's already the first suggestion in the search box when I type "special:my", so a redirect doesn't seem significant. PrimeHunter (talk) 18:41, 11 February 2017 (UTC)

Checklinks problem?

User:Alligators1974 recently used Checklinks to insert multiple 'dead link' tags into John Key. The edit inserted the tags before the closing </ref> instead of after it. The result is that the tags do not show on a reading of the article. Because Checklinks may be used by multiple editors on multiple articles, this has the potential to become a widespread problem. @Alligators1974:, please stop using Checklinks until this problem is clarified. I would report this to the developer of Checklinks myself but am pressed for time right now. Akld guy (talk) 18:58, 11 February 2017 (UTC)

That's where {{Dead link}} is supposed to be. Template:Dead link#Usage says: "If the article uses clickable footnotes, then this tag should be placed just before the </ref> that contains the dead link. The notice will then correctly appear in the reference section (instead of in the body of the text, which is not recommended)." PrimeHunter (talk) 19:38, 11 February 2017 (UTC)

You're right. After many years I learned something new. Akld guy (talk) 20:46, 11 February 2017 (UTC)

Disabling book popup?

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)

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)

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

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)

Template:Webarchive

I'm alerted on my talk page to a possible error in Template:Webarchive. The page about it starts "Error in webarchive template: Check |url= value. Empty." There seems to be nothing much to the template other than the invoking of Module:Webarchive (most recently edited by User:Green Cardamom). I have no experience of editing this kind of thing, and so bring up the matter here. -- Hoary (talk) 09:52, 12 February 2017 (UTC)

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)

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

Script dependencies

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 script?   The Transhumanist 12:16, 12 February 2017 (UTC)

@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)

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)

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)

@Mr. Stradivarius: It had little to do with memory, but your suggestion provided the essential clue. Since I had 2 versions of the script running simultaneously, the second one worked because of data stored locally by the first one. Without that storage there, the second script failed, which became apparent when I customized the localstorage key per your suggestion. Which led me to a bug. I fixed the bug, and the now the second 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)

@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)

Location maps

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

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

@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)

color displayed by {{u|example}}

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)

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)

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

Resolved

<br/> or <br>?

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

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

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

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)

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)

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)

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)

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)

Localised magic links

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)

@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)

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)

Visual mobile edit: Link brackets replaced with object replacement characters

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|Goldenshimmer}}|✝️|ze/zer|😹|T/C|☮️|John15:12|🍂 10:59, 13 February 2017 (UTC) (forgot to sign)

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)

Tech News: 2017-07

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• EventStreams is a new way to show activity on Wikimedia wikis. For now it works with the recent changes feed. It will do more things later. It will replace RCStream. Tools that use RCStream should move to EventStreams before 7 July. [13]

Problems

• The Firefox add-on Firefogg can cause problems with the Upload Wizard. This will not be fixed, because Firefox will not support Firefogg in the future. The Upload Wizard will no longer work with Firefogg. [14]
• Tool Labs and Wikimedia Labs databases will be under maintenance on 15 February. This will start at 17:00 (UTC) and last for about six hours. Some tools could have problems during or after this. [15]

Changes this week

• The TwoColConflict extension is a new way to solve edit conflicts. It makes it easier to copy and paste the relevant text to the text field. It will come to Meta and German Wikipedia this week. It is already available on MediaWiki.org. It will come to more wikis later. [16]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 February. It will be on non-Wikipedia wikis and some Wikipedias from 15 February. It will be on all wikis from 16 February (calendar).

Meetings

• You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 14 February at 20:00 (UTC). See how to join.

Future changes

• Page Previews will be turned on for logged-out users on the Catalan, Greek, Russian, and Italian Wikipedias in the middle of February. Page Previews shows readers a short part of a linked article when they rest their mouse pointer on the link. This is to help them understand what it is about without leaving the article they are reading. Page Previews used to be called Hovercards. It will come to more wikis later this spring. [17]
• The Developer Wishlist is a list where developers prioritize tools they need. The voting closes at 14 February 23:59 (UTC). This process is only for developers.

Review

• You can read the 2016 product summary from the Wikimedia Foundation Product group to see what they did with things they said they would work on in the annual plan.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

18:06, 13 February 2017 (UTC)