This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
I always tick "Keep me logged in for up to 30 days" and in the past that has worked. For the last few days I have had to re-login every day. I wonder if it is related to accessing WP from different computers. But I have long regularly used two computers and only had to log in on each every 30 days. Nurg (talk) 09:37, 10 February 2016 (UTC)
Login on Commons is also not working, as of 5 minutes ago. It told me I was centrally logged in and then that I had to login. I was logged in here on WP. When I attempted to login on Commons, I got sent to the main page 3 times. I finally gave up and left. White Arabian Filly (Neigh) 20:52, 10 February 2016 (UTC)
@White Arabian Filly: It is suspected that you were using the mobile version of the website when you encountered this ? The developers just discovered that in the last couple of hours, logging in on mobile commons can be a problem. They are verifying and fixing it as we speak. The desktop version should be usable while this situation is being worked on. —TheDJ (talk • contribs) 21:39, 10 February 2016 (UTC)
The configuration issue keeping mobile web logins on commons and meta from working should be fixed as of 2016-02-11T01:58Z. See T49647 which was reopened as a regression. --BDavis (WMF) (talk) 03:14, 11 February 2016 (UTC)
All users have been forcibly logged out several times over the past two weeks. This was required, because a very complex dance is going on with the system that keeps track of the logins. Since there had been indications that something had gone wrong in that dance, it was decided it was safer to have everyone log back in, rather than that there was the possibility that people would have access to accounts that did not belong to them. The full details are in T124440 as already mentioned by Redrose64 —TheDJ (talk • contribs) 21:39, 10 February 2016 (UTC)
The forced session expirations for T124440 have been completed now. MediaWiki 1.27.0-wmf.13 was deployed to "group1" wikis (everything except Wikipedias) at 2016-02-10T20:03Z, undeployed at 2016-02-10T23:38Z, and finally redeployed at 2016-02-11T01:58Z. Each of these transitions may have caused some users to lose their CentralAuth sessions again. If further instability is seen (e.g. suddenly logged out when not expected or error messages related to cookies or sessions when logging in), please report here on the Village Pump, on irc, and/or as a Phabricator bug. We have done a lot of testing with the new SessionManager component, but there may still be edge cases that we haven't been able to fully exercise yet. Having details about which wiki(s) you were using when the error occurred, and if possible the cookies and headers that your browser or bot received will be very helpful. --BDavis (WMF) (talk) 03:14, 11 February 2016 (UTC)
I don't know. But, it might be that there is some loss of synchronisation - something thinks that you're logged in, something else doesn't. Or something thinks that you're logged in with cookie/token A, something else thinks that you're logged in with cookie/token B. You can force these to sort themselves out by going to the project that you last logged in through, and deliberately logging out, then logging in again. A deliberate logout will force invalidation of all cookies and tokens that have your name on, so you start with a clean sheet; and a login will create a fresh set with matching values. --Redrose64 (talk) 13:59, 11 February 2016 (UTC)
Another possibility at the moment is that WMF's Ops team is upgrading the servers that host the redis instances that hold the session data. When they depool a server to upgrade it and again when they repool it after upgrading, that could cause session loss as it changes how the data is sharded among the different servers. Anomie⚔14:52, 11 February 2016 (UTC)
The work by WMF technical operations on upgrading the Redis servers is tracked in T123711 and was just announced on the wikitech-ambassadors mailing list. Unfortunately the sessions that are actively stored on a particular server are lost when it is removed from the available pool. I've been watching backend monitoring metrics for edit session loss and it does have spikes of failures each time a server is taken out of the rotation for maintenance work. These elevated rates subside pretty quickly as session storage for affected users is remapped to new backend servers. --BDavis (WMF) (talk) 19:10, 11 February 2016 (UTC)
Just to be clear, those "AuthenticationManager" changes haven't come into force yet, right? We're still suspecting this is session-based? Thanks, West.andrew.g (talk) 16:00, 12 February 2016 (UTC)
Correct, AuthManager hasn't started yet, and isn't likely to for several weeks. Although the issues with Huggle and STiki this week aren't due to session changes either, they're actually due to a mostly-unrelated change to make the login and account creation tokens more logical (i.e. you can now fetch them the same way you fetch every other token) and secure that happened to break some bad assumptions that people's code was making (i.e. that action=login would never return warnings or that login tokens didn't need to be percent encoded). Anomie⚔17:59, 12 February 2016 (UTC)
With the Chrome browser under Windows 10 while previewing edit of a section that contains {{sfn}} citations an error message appears like:
1. ^ Bourrée 2004. Harv error: link from #CITEREFBourr.C3.A9e2004 doesn't point to any citation.
The citation is in fact present, but in a section at the end of the article, not the section being edited. For example, Maxime Blocq-Mascart#Inter-war period.
The error message does not appear with Microsoft Edge or with Firefox.
Also, in all three browsers if the last line is preceded by a single line break it shows as a new paragraph in edit preview mode, but flows into the previous paragraph in normal viewing mode. Aymatth2 (talk) 19:35, 9 February 2016 (UTC)
The latter thing is a known issue and will be fixed next week when the followup improvements to reference previewing will roll out. The first thing, I have no clue... When you are comparing the browsers, are you logged in into your account on all three of them as well ? —TheDJ (talk • contribs) 19:53, 9 February 2016 (UTC)
I was not. When I log in, the red error message appears in all three browsers. I do not recall see the list of citations before, with or without error messages. It seems as if a {{reflist}} is being added at the end of the section for preview purposes. I tried defining a citation with <ref name=testref>blah blah</ref>, then referring to it in another section, and got the message:
^ Cite warning: <ref> tag with name testref cannot be previewed because it is defined outside the current section or not defined at all.
I guess this is a new "preview citations" feature. I do not like it. I always put citation details at the back of an article, so will always get error messages. Aymatth2 (talk) 20:31, 9 February 2016 (UTC)
For many people this is desirable behaviour. If you don't like it, you can disable it. You can add #wikiPreview.references{display:none;} to your common.css. Alternatively, I've written a script that makes the references invisible by default but allows you to show them if you wish: add importScript('User:Relentlessly/hiderefs.js'); to your common.js. Relentlessly (talk) 21:15, 9 February 2016 (UTC)
Yeah Cenarium is working on improving on avoiding the warning messages. Still, It makes slighly more sense that it is suddenly consistent if you log in to all accounts, but I don't have errors with that particular section preview, and I'm logged in as well so something more complex is at play. /me has to ponder on it a bit. —TheDJ (talk • contribs) 21:40, 9 February 2016 (UTC)
The css #wikiPreview.references{display:none;} has the effect that even when editing the whole article the {{notelist}} and {{reflist}} are suppressed in the preview. In full-article edit mode it would be useful to preview the appearance of the whole article before saving.
The hiderefs.js script is good when editing one section, gives slightly odd results when editing the whole article, with two "Show/hide refs" buttons, one for the {{notelist}} and one for the {{reflist}}, with the top and bottom of one button displaced a bit, so they look quite odd - but it does work. Is there a place I can upload a screenshot of this?
Ideally, what I would like is the option (preference) to suppress the generated {{reflist}} when previewing a section, but not when previewing the whole article. That is, for Show preview to show the section or whole article as they will look when saved. Aymatth2 (talk) 02:22, 10 February 2016 (UTC)
@Relentlessly: Here is a screenshot of the effect of the hiderefs.js script when previewing edit of the whole article, for a "Notes" section that holds {{notes}}{{reflist|30em}}. The buttons work, so there is no real problem, but look a bit odd. Chrome Windows 10.
Now I am unsure what works best. I typically start an article and add most of the content in "full article edit" mode: I want to see what the whole article will look like, and will often merge or split sections and shuffle content around from one section to another. At this stage I obviously want any cite link problems to be highlighted, so
User:Ucucha/HarvErrors.js is essential
css #wikiPreview.references{display:none;} is not really an option
hiderefs.js is awkward since I would have to click two buttons every time I want to preview, which in my case is "often".
I may go back to an article a day or two later to look at it with fresh eyes and copyedit, one section at a time. At this stage I do not have any use for the list of citations, particularly when non-errors are highlighted.
The false error messages are a bit distracting.
I often make minor edits to other articles, such as adding links to an article I just started. If this includes adding a citation I will do it in "full article edit" mode, so I can see that all the citations for the article looks consistent, and perhaps tidy up the others a bit while I am at it. If I am editing just one section it would be a very minor edit where I would not have any use for the list of citations.
What are the chances of getting an "opt-out" preference, so the citation list does not appear in single-section edit preview? Aymatth2 (talk) 14:28, 10 February 2016 (UTC)
To get the "false error messages" fixed or suppressed would probably need the attention of Ucucha (talk·contribs), who wrote the script - it's not part of MediaWiki, nor is it a recognised gadget - it's a user script which everybody (Ucucha included) uses at their own risk. --Redrose64 (talk) 00:14, 11 February 2016 (UTC)
@Redrose64: User:Ucucha/HarvErrors.js may be a red herring, although it highlighted the problem. A very similar result would appear with named references defined in different sections, or perhaps tucked away at the back inside {{reflist|refs=<ref name=abc>{{citation ...}}</ref><ref name=xyz...> }}, thus:
What looked at first like a bug seems to be a question of whether an editor can default to suppressing the list of citations that is now added to the preview of a section edit. A solution that would work well for me and perhaps for other experienced editors would be to have hiderefs.js act only in "section edit" mode, not "full page" edit mode, and to have it remember the editor's preference or last choice on whether the list of citations should be shown or hidden. A user who had chosen "hide" would see the Show/hide refs button but not the list of citations. They could click on the button to see the citations if they wanted – the best of both worlds. In "full page" edit mode they would always see the citations as they would appear after the page was saved, so the button would not be needed. Is that practical? Aymatth2 (talk) 02:44, 11 February 2016 (UTC)
This'll be possible next week today since there's going to be a class specifically for references in section preview ("mw-ext-cite-cite_section_preview_references", cf phab:T125981). Cenarium (talk) 10:50, 11 February 2016 (UTC)
@Cenarium: That is good news. I do not think I am unusual in preferring to usually hide the preview of references. I mostly work on short articles, maybe 10k long. My habit is to make significant edits, including addition of citations, in full-article mode. I frequently preview to check the appearance of the whole article, including references. I use section edits only for small changes like adding a link or fixing a typo, where I am not interested in previewing the references. When the references are visible, more scrolling is needed to compare the preview text to the edit text. But this is just personal habit, and I am sure that for others the preview of references will be very useful. I will find it useful when editing sections in very large articles, where editing and previewing the article as a whole is less practical. Some editors work almost entirely on large articles.
How do I request addition of a Show references / Hide references button to show or hide references in section preview? It could perhaps appear on the Preview of References heading line and default to the user's last choice... Aymatth2 (talk) 14:12, 11 February 2016 (UTC)
I don't know about making it a switchable preference, but I can show you how to turn it off long term. To suppress the display of reference lists in preview mode, there's a simple CSS rule:
/* hide reflist in preview mode */div#wikiPreviewol.references{display:none;}
To display the reflist, but suppress the red Harv errors (also the recently-introduced black Harv warnings, which you might not have noticed), don't use the above - instead, a more complicated selector is needed for the rule:
/* hide Harv errors and warnings in preview mode */div#wikiPreviewspan.reference-textstrong.error,div#wikiPreviewspan.reference-textstrong.warning{display:none;}
@Redrose64: Thanks, but those css changes work on preview of full article edits as well as just section edits, and hide footnotes as well as citations. I would rather put up with seeing a sort-of-preview of the references, single column, bold red warnings and all, when editing a section than lose the ability to see a preview when editing the whole article. Perhaps I am being too picky. I feel I am taking up too much time over this. Again, thanks, Aymatth2 (talk) 18:59, 11 February 2016 (UTC)
The new code has been deployed so you can just add
to hide the ref section completely in section preview. Or
/* hide Harv errors and warnings in preview mode */.mw-ext-cite-cite_section_preview_referencesspan.reference-text.error,.mw-ext-cite-cite_section_preview_referencesspan.reference-text.warning{display:none;}
to only hide errors/warnings. (Errors/warnings are likely to become spans in the future, and mw-ext-cite... div.) Relentlessly will probably update the script too. Cenarium (talk) 20:11, 11 February 2016 (UTC)
This shouldn't be a default since inexperienced users benefit most from previewing the references in section preview and might not think of clicking on the show button. This could be a gadget though. Cenarium (talk) 17:32, 12 February 2016 (UTC)
One way to do it would be to put a toggle link on the reference preview header, like:
Preview of references [ hide ]
reference1
reference2...
Then if the editor clicked on "hide" it would change to
Preview of references [ show ]
[references hidden]
The initial default would be to show the references. Once they click hide on a section preview the references would be hidden on subsequent previews until they click show, after which the references would be shown on subsequent previews. Probably that violates all sorts of guidelines though. Aymatth2 (talk) 20:40, 12 February 2016 (UTC)
Moving article didn't work at first
I moved Ásta Helgadóttir to Ásta Guðrún Helgadóttir, as she is best known under her full name. When I first tried moving the article, it wasn't yet interwiki-linked to the Icelandic and German articles through Wikidata. I entered the new article name (Ásta Guðrún Helgadóttir), gave a reason, and checked the "Watch source page and target page" box. When I clicked the "Move page" button, there seemed to be some kind of browser response, a short loading time, but nothing happened and the page didn't get moved. I tried this, I think, three times without success. Well, I tried it again after I linked the pages in Wikidata, and also didn't check "Watch source page and target page" this time. For whatever reason, now it worked. No idea whether this may have something to do with Wikidata (Icelandic and German article were already named Ásta Guðrún Helgadóttir), or with the watchlist, or whatever, but well, maybe it's an interesting report for some people dealing with technical matters ;-) Gestumblindi (talk) 20:55, 12 February 2016 (UTC)
"Shew" is usually pronounced the same as "show". In Milton it's pronounced to rhyme with "hoo" or "moo". I have no idea how Ed Sullivan pronounced it. DuncanHill (talk) 09:08, 13 February 2016 (UTC)
They were advised at WT:RD to post to WP:HD, which is one of the two preferred places for how-to questions. This page is for suspected technical problems/issues with Wikipedia software. But it's been bounced around enough, so I'm leaving it here. ―Mandruss☎13:48, 10 February 2016 (UTC)
@BOTFIGHTER:: You can login using the Android app, yes. Tap on the menu icon in the top left corner, next to the search box (). You'll get a fly-out from the left that has the option to login. Keegan (talk) 23:17, 11 February 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Starting yesterday the Teahouse and Help desk have received questions like this. When the user tries to create an article they receive a message that the edit was trapped by the autobiography filer, offering a workaround. When they try the workaround, it repeats the original message. While trapping autobiographies is a good thing, the workaround seems to be broken, leading only to frustration. Maybe a solution would be to direct the author to save the article as a draft and then submit it through AFC. —teb728tc00:07, 12 February 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I know, it's archived, but still. If the problem was to delete (recreate) the page, then it's AN matter, not VPT. Yes, it's a known bug, that page content model doesn't get updated, when performing such moves. --Edgars2007 (talk/contribs) 19:21, 13 February 2016 (UTC)
It works just fine for me. But we only support HTTPS, so my guess is that your version of lynx doesn't support https, or the algorithms of HTTPS that we require. —TheDJ (talk • contribs) 23:53, 10 February 2016 (UTC)
SSL (https) is a configure-script (build-time) option.
The version message (lynx -version) shows whether lynx is built with OpenSSL (or even GNUTLS).
The SSL configure option (--with-ssl) for Lynx provides the ability to make use of SSL over HTTP for secure access to web sites (HTTPS) and over NNTP for secure access to news servers (SNEWS).
My version of Lynx supports https (with OpenSSL, no TLS). Anyway, when I type "https://en.wkipedia.org/" in the address bar,
I get the message "making https connection to en.wikipedia.org" and nothing more, till the connection times out.
Another machine, at the side of the first, using Firefox 2.0 and the same gateway can access without any problem almost 100% of the time.
Note: I am the guy who did post the first message of this thread, even if my IP address is not the same. — Preceding unsigned comment added by 201.42.210.251 (talk) 23:00, 13 February 2016 (UTC)
Overlined text does not display properly in table of contents
The Prosigns for Morse code article includes several sections with overlined text like this. This overlining is significant to the content of the article and cannot be substituted by any alternate highlighting forms such as underlining or italics, angle brackets, etc. The overlining displays correctly in the article itself, but does not display in the automatically generated table of contents. Is there a fix or workaround for this? Thanks.
50.174.97.118 (talk) 10:48, 14 February 2016 (UTC)
The short answer is no. Try to use different section names instead. The longer answer is those symbols are using 'visual' markup icw text. Think of it like this. Text == "content" but visual markup == "non-important decoration". For various reasons, we only allow text in headers (you don't want images in your headers either right). There is actually some way to do this with text. It's the combining overline diacritic: H̅H̅. Unfortunately the way it displays is very dependent on the fonts used by the computer trying to display this sequence, and most computers are still terrible at it. People with work on math articles often run into similar problems btw. You are running into the limitations of what computers can currently do. (they can do it quite well in a 'sandboxed' and specialized environment, but not so well in a generic environment like the web). —TheDJ (talk • contribs) 12:31, 14 February 2016 (UTC)
So I encountered this bug when trying to respond to a message on my talk page. In this image, you can see that the bottom section isn't being acknowledged as a section. At first I thought it was improper formatting, but the wikimarkup is properly formatted as a level 2 header. Yet, this section is not recognized as one. I tried to access it manually by setting the section id in the edit address, only to get a section not found error.—cyberpowerBe my Valentine:Online14:27, 10 February 2016 (UTC)
Not a bug. A pair of opening braces introduces a template transclusion, and the MediaWiki parser expects there to be a matching pair of closing braces later on. Not being closed is an error by Bgwhite (talk·contribs), not the MediaWiki parser. --Redrose64 (talk) 21:49, 10 February 2016 (UTC)
I disagree. The parser ignored the template and left the text alone. It should not be considered a template if it can't find respective closing braces. It's clearly an inconsistency. Either it makes it a template, it ignores it COMPLETELY, not halfway.—cyberpowerBe my Valentine:Limited Access18:14, 11 February 2016 (UTC)
To call the MediaWiki parser a true parser probably does it more justice than it should... I believe Parsoid seeks to correct that mistaken impression. --Izno (talk) 19:12, 11 February 2016 (UTC)
Yup. Looks like a sure fire bug to me. The PHP isn't outputting the correct HTML, so that's a definite bug. Yeah, the whole <span class="mw-editsection"> is omitted. If those two braces aren't being parsed properly, there's the potential for all kinds of nasty hackery. fredgandt13:38, 14 February 2016 (UTC)
Hello folks, so building on top of the earlier quicksurvey experiment. This is headsup that the team is running anther survey tomorrow. By the afternoon, the sampling rate will be (0.002%) meaning that 1 out of every 500 will get to see the survey. It is planned to run for 2 weeks, however, we may stop after 1 week if we have enough responses by then. More info around the user research is found here. Feel free to ask question there. Thank you--Melamrawy (WMF) (talk) 21:39, 10 February 2016 (UTC)
Why do you run this on such short notice, Melamrawy (WMF)? WMF ran the same survey on enwiki in November 2015 (via Google Forms!). Now you want to rerun it, again via Google Forms(!) with even moar data collection on users ("We have added additional instrumentation that will allow us to join survey responses to the web-request logs, which opens up many new avenues of analysis...") "Given the added instrumentation there is a new privacy policy" ("We may disclose any collected information when required by law, when we have your permission, when needed to protect our rights, privacy, safety, users, or the general public, and when necessary to enforce our Terms of Use or any other Wikimedia policy.") - that is very open to interpretations... And additionally Wikipedia readers have to agree to the google Terms Of Service...! And, regarding "we will run Survey 1-2, and 3 in 2 more languages." - which Wikipedias / languages will that be? --Atlasowa (talk) 23:04, 10 February 2016 (UTC)
@Atlasowa: Regarding running surveys 1 and 2 in two more languages: We ran the surveys in eswiki and fawiki at the end of January. We will be able to share the results of the handcoding from that survey on the Research page in the week of February 15. The goal of those surveys was to assess whether the categories and labels identified from running surveys 1 and 2 in enwiki persist as we go to other languages.
Regarding the timing of the survey: I'm more than happy to be a bit more flexible and make sure you have enough time to learn more about it before we start the survey. I will ask the team to start the testing in the morning PST with a very low sampling rate of 5 out of 100K requests or something along that line. This way we will at least have another 18 hours to discuss. If we have questions we cannot address in that time, I'll request a delay for the survey for us to have some more days to talk. I'm hoping that this addresses the comment below by @The Quixotic Potato:. --LZia (WMF) (talk) 03:40, 11 February 2016 (UTC)
This isn't a change in the privacy policy. The privacy statement for the survey fulfills our obligations under the main privacy policy. In the Surveys & Feedback section, there is flexibility in how we run surveys, so for each survey we provide more information about what we will collect, share, and keep, as well as the purpose of the survey. Just to clarify, the survey's privacy statement just applies to users who opt to fill out the survey, not everyone reading Wikipedia. Stephen LaPorte (WMF) (talk) 02:22, 11 February 2016 (UTC)
Atlasowa, The Quixotic Potato: on top of what Stephen and Leila said, I'd be very happy to discuss any additional questions or concerns you may have about this study and its participation, which is entirely opt-in. Please ping me so I can respond promptly.--Dario (WMF) (talk) 06:04, 11 February 2016 (UTC)
The WMF offered to wait, to hear our input. Thank you. This is a very good idea. We are not in a hurry.
In the future, please assume that there is always someone out there who disagrees with or complains about whatever you do (because there is, this community is big), and post a message (for example at the village pump) asking people for input. If you cannot get a consensus then it is probably a bad idea. If you have a good idea then it is incredibly easy to get consensus, and it doesn't take a lot of time. If everyone agrees that it is an excellent idea they will still be grateful that you've asked them for their input, because it means that you value their input. If some people still dislike it then you can point out that you have asked for input from the community and that you have consensus to do whatever you are doing.
I think that this would be an excellent strategy from now on. Do you agree?
The WMF seems to be addicted to surveys. This needs to stop. Every week you guys run another survey, and they are usually pointless. Communication with the userbase is a good thing, but asking people to fill out survey after survey after survey is extremely annoying. If you value the time of others then please please stop doing this. I have noticed that the results of the survey are usually ignored, because the quality on average is very low. Most people who are smart and use Wikipedia a lot can more or less predict what the answers would be anyway. Informally asking for input at (for example) the Village Pump will reduce the need for Yet Another Survey (I believe most of them can be avoided this way).
Look at the community; it is running a billion "surveys" at the same time, but it uses the discussion format instead of creating HTML forms. The Village Pump, WP:Requests for comment and AfD, that is the kind of stuff the community uses to quickly get consensus about something (or not). The WMF's insistence on using surveys with HTML forms isn't helpful, it would be better to adapt to the community and to allow it to use the discussion format.
Surveys should ALWAYS be opt-in. No exceptions. Don't tell me that this introduces bias, everything introduces bias. Every choice you make while creating the survey influences the results in some way. The simple act of observing a particle changes it. Opt-in means that you do not see a surveyquestion unless you explicitly opt-in to receive surveys. You seem to be using your own (wrong) definition. Opting in for beta features is something completely different.
The WMF doesn't seem to understand how difficult it is to create a good survey (and how difficult it is to create a good way to deal with the response). Asking the right questions in the right way and interpreting the results correctly is an art and a science. Doing this kind of research is incredibly complicated, and the WMF makes the same basic mistakes over and over again. I am not an expert on this topic but you guys can probably find a community member who is, or hire someone. Scientists have been working on this for quite a while; why doesn't the WMF use their knowledge to its advantage? Like I said, every choice you make while creating the survey influences the results in some way.
Surveys should NEVER be placed in articles. Can I test this somewhere without installing the QuickSurveys extension in my own MediaWiki installation? The WMF doesn't seem to understand that they are not allowed to touch the part of the interface that contains the article. I hate banners with the burning passion of a thousand suns, but even that would be a better idea because it they are outside of the article content and they are opt-in. The community owns Wikipedia, because the community created it, and the WMF should serve and protect the community.
The WMF seems to be a bunch of individuals working without any organized leadership... like Wikipedia. In the WMF's case that is a bad thing. Why don't you guys stop doing surveys for 3 months? During this period you collect all the requests for surveys, and then you create 1 combined survey that is multi-purpose. This way you can have 4 big surveys per year, this is MORE than enough. Maybe it is a good idea to start with a period of 6 survey-less months, during this time it is possible to create the infrastructure required and hire someone who knows how to do this kinda stuff.
There seems to be no one in the WMF who dares to stand up and say "this is a bad idea". Please hire me or someone like me, I am extremely good at detecting bad ideas and I don't mind being perceived as rude or blunt. Even I think I am kind of an asshole. I do not know if they are afraid to lose their job or if this is part of the (sub)culture or something but you guys really need to hire some Negative Nancies and Debbie Downers like me who are good at identifying bad ideas and are not afraid to point them out. I am not sure what has caused this problem but I know that this is a very big problem. Pointing out mistakes made by others is my job in real life.
The WMF doesn't seem to understand that discussions are better than surveys and better than voting. This example perfectly illustrates that it would be better if you guys would've started a discussion about this a couple of weeks ago.
The WMF announces things that will happen the next day, and then they are unprepared to deal with all the criticism in this short period of time. The community sees something change unexpectedly and starts complaining en masse. This could all be prevented by making the announcement at least a week or so in advance (preferably more). Or better yet, instead of announcing something, ask around if it is a good idea.
I strongly recommend making a list of people who are willing and able to provide feedback, and asking those people for input. Again, this should be an opt-in list. You can use the message delivery service or pings or something like that to get their attention.
The WMF needs to create a centralized portal where the community and the WMF can ask eachother questions. User:Mdennis (WMF) explained to me that there is a lack of resources in this area. I think that this is incredibly important. It would be nice to have a FAQ, and a place where WMF members can describe the projects they are working on and invite the community to give feedback. Currently, the community isn't able to see what the WMF people are working on. More transparancy = more trust. Another problem is that the community is unable to give feedback on projects that are unfinished. I think a lot of time and money is wasted because the WMF does not ask the community for help when it should (in the earliest stage possible). Certain members of the community are ready, willing and able to point out the mistakes made by the WMF and some can even fix/improve the code written by the WMF. But its not all negative, the community can also help by posting feature requests, translations, help writing documentation, post suggestions to improve something, bugreports etc. There must be someone in the WMF's hierarchy who is able to allocate more resources to the team to speed up the process of creating this hub. Should I ask Jimbo to prioritize this?
Support call for RFC and comments by Atlasowa and Quixotic Potato. I mean, am I really supposed to believe that Wikipedia can't write up a couple of forms with check boxes on its own???? Is this about collecting information for Wikipedia - or for collecting information for Google!? Or its masters at the NSA, who can rely on the company's "unique relationship" with Firefox (and ownership of its own browser) to have reliable long-term identification of users, perhaps. Let's be clear here: the mistake is that MediaWiki should not have extensions that rely on closed-source code or third-party servers, period. Didn't Wikipedia do a huge purge of the toolserver just a year ago over code licensing issues? How'd you miss this? I would be curious to find out whether Google gets to run its script before the users randomly selected for enhanced screening measures even get a chance to say no, and whether the running of this script "due to a bug" on mobile users was able to provide Google with reliable tracking of each article they viewed until they declined the survey. (The survey privacy policy specifically allows the sharing of raw data with "service providers", and the page being viewed is explicitly part of the survey information) Wnt (talk) 08:13, 11 February 2016 (UTC)
Instead of using a survey format I would recommend using discussions, a far more flexible format. But I can imagine that in certain scenarios a survey format is more convenient, so that means the WMF should create an extension that handles the HTML forms. @Wnt: is correct, the technical side of that isn't very difficult, and there is no need for a 3rd party to handle that stuff.
The current QuickSurveys extension should be changed: we need to have something that is truly opt-in, e.g. by showing a sitenotice that says "please participate in this survey". When you click the link it should show a popup like WikiLove or go to a different page. The Quixotic Potato (talk) 09:07, 11 February 2016 (UTC)
@Wnt: No, Wikipedia did not "do a huge purge of the toolserver just a year ago". Toolserver was shut down at the start of July 2014 by Wikimedia Deutschland, who had provided it. The shutdown had nothing to do with code licensing, it was simply a lack of funding. You can't purge something that was no longer operational, and it was not within the remit of Wikipedia to control Toolserver, even if it had still been functional. --Redrose64 (talk) 14:10, 11 February 2016 (UTC)
I think that this definitely is NOT the right village pump for this discussion. I also have some opinions about the discussion being opened, but i have no energy to wikilaywer over stupid stuff like this —TheDJ (talk • contribs) 13:17, 11 February 2016 (UTC)
@TheDJ: it would be helpful if you'd enlighten us where we *should* have this conversation? It sounds like several of us think an RfC is in order, and it would be best to put it in the proper spot from the beginning. Wnt (talk) 13:41, 11 February 2016 (UTC)
Hello again everyone, I would like to clarify a few points around QuickSurveys: This is a service that helps us understand our readers based on data which we can't collect otherwise. The idea of showing messages to users while they are browsing Wikipedia, helps us reach to the right audience directly (our readers), and gives them an optional chance to help us better identify their needs. The survey itself is entirely optional and people can skip it in one click. The screenshots you shared, are for an old mockup of the idea of the survey, the actual survey has a button that checks if the person wants to participate in the survey, and there are yes or no buttons. By choosing not to take it, the message will disappear. Those surveys run for two weeks or less, and are showed to a tiny percentage of users. This survey we announced should show to 0.2% of readers, meanings that every one person out of 500 people will see the survey. Actually, thanks to our traffic, we can collect a reasonable sample in a very short time. QuickSurveys idea has first been announced in the reading team updates since August 2015 and October 2015. Those updates themselves are announced on Wikitech-l. There was an early announcement on this village pump in November 2015, when the first survey was launched and the project has a clear documentation on meta with clear dates, results, and next steps. The phabricator workboard for the project is public which helps keep up to date with all project details, and suggest specific solutions or requests around certain implementation details. We currently do not have a system that enables us to collect data for multiple questions, so we are using an external service, while notifying our users that we are doing so. Even with the current implementation, they way how the system is set up, doesn't allow the third party to identify users identities. So while we need to collect data in order to help us better assess our decisions for the readers products, we trust, that we are not currently exposing our readers to a possible breaching of their privacy, while they are doing us an optional favor of helping us understand what our users want. I hope this has helped clarify more info around those QuickSurveys, and if not and you have more specific questions or suggestions, please share them. Thank you--Melamrawy (WMF) (talk) 23:54, 14 February 2016 (UTC)
I just was helping out at MFD, and found 2 pages where the discussion link was red. While I know that it sometimes takes some time for these links to be updated, these discussion pages were created on January 31. Is the system that slow in updating this? עוד מישהוOd Mishehu06:08, 15 February 2016 (UTC)
Where two blocks that are not text (an infobox and a table in this case), compete for space, white space will be present, it is unavoidable. Also never make too many assumptions about positioning to begin with. Positioning is dynamic and will behave different on mobile vs desktop and narrow and wide monitors. —TheDJ (talk • contribs) 09:45, 15 February 2016 (UTC)
You can disable Ad Block Plus by clicking on its logo. You can disable it for a specific page, an entire website, or disable it everywhere. After you've disabled Ad Block Plus, press F5 to refresh the page, and check if the problem is fixed. If not, re-enable Ad Block Plus. The Quixotic Potato (talk) 13:25, 15 February 2016 (UTC)
Watchlist: pages added to categories
I've been away for a week, and an older bug seems to have reappeared for me. Some two weeks ago, all changes to the contents of a category you watched were shown in your watchlist, until the WMF emergency rollbacked that change after many complaints here. Now, this "feature" seems to have returned. However, in my preferences, under "watchlist", " Hide categorization of pages" has been checked. All I want to see is a change to the actual category page (the code of the category), not any additions or removals of pages to that category. Am I the only one with this problem? And any ideas on how to solve this, without removing these categories from my watchlist (I really want to watch these for vandalism or other problems, like people adding pages directly to a category page instead of by adding the "category" syntax to the page). Fram (talk) 08:18, 15 February 2016 (UTC)
I have meanwhile found the checkbox (hide [...] page categorization) on the actual watchlist page, however I still wonder what the preference is supposed to do, as it didn't work for me. The preference should automatically chech that checkbox, no? Fram (talk) 08:44, 15 February 2016 (UTC)
Let me see if I think you're reporting the same experience that I think I'm experiencing: Changes in categorization of articles are being logged as changes to categories. This is causing changes on the category pages to get lost in the sea of changes, right? --Izno (talk) 12:31, 15 February 2016 (UTC)
Yes! You can suppress this by going to the top of your watchlist and checking the "page categorization" box (second to the right, before Wikidata); but there is also a checkbox in your preferences (tab watchlist), which is the better way of handling these but which (for me) doesn't work. Fram (talk) 13:28, 15 February 2016 (UTC)
I can't speak to the issue you raise, and I agree you should be able to fine tune this setting, but I am enthusiastically in favor of the change that enables ability to monitor changes in category membership. older ≠ wiser13:41, 15 February 2016 (UTC)
Fram: So you want (and I'm pretty sure I would like also) some way for only category changes and not their membership changes to be obvious? For me, this edit showed up on my watchlist with "page categorization" checked on Special:Watchlist (while none of the membership changes show up). Is it possible that in the categories you're watching none have had an edit made to them in the past watchlist time period?
The watchlist check does what it should do, but it wasn't checked for me despite having the preference already set correctly in the past (and still set correctly now). I hadn't at first seen the watchlist check, so was wondering why the preference didn't do anything (for me): I still wonder the same thing, but with the watchlist check it is a lot less urgent of course. And I agree that ity is nice that we can see which articles get added to categories, but for me it isn't useful as I also have some categories with too many articles on them, so my watchlist gets flooded if I enable it. Enabling it on a per-cat basis would be great, but that's something for the advanced watchlists we may get one day. Fram (talk) 14:29, 15 February 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
You can now edit pages on the mobile site version without JavaScript. [3]
A few editors might have been logged in as someone else because of a bug. For security reasons everyone was logged out on 9 February. If you have seen this bug, you can report it. [5][6]
Changes this week
There is a beta feature that adds links to the subject on other Wikimedia projects. The plan was to have it leave beta testing and be enabled for everyone in January. It will happen on 16 February instead. Wikis that don't want this can decide to have it disabled. [7][8]
Cross-wiki notifications will be available as a beta feature on Wikidata, MediaWiki, Commons, and all Hebrew and French wikis on 19 February. [9]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 February. It will be on non-Wikipedia wikis and some Wikipedias from 17 February. It will be on all wikis from 18 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 16 February at 20:00 (UTC). See how to join.
Future changes
The search function on Wikimedia wikis will get a completion suggester that tries to find the right pages as the user is typing. It will also recognize some typos. This will probably happen in March. It is currently in beta. [10]
I have just made a change from class="collapsible" to class="mw-collapsible" on Template:Multiple issues at the request of Tacsipacsi. The result is a more stylish fading in/out of the collapsed content, and according to him/her the article load time is reduced. I'm just checking here that this is a good idea, before deploying this change more widely. Thanks — Martin (MSGJ · talk) 08:57, 16 February 2016 (UTC)
@Tacsipacsi and MSGJ: mw-collapsible does not support autocollapse functionality; that is that tables/divs using the mw-collapsible will not be displayed automatically if there is only one invocation of the class on the page of interest. This is the reason none of our templates use it presently; the change necessary in core was not considered a blocker for deployment by Krinkle at phab:T32352 when mw-collapsible was deployed. Tacsipacsi appears to be subscribed to the task there since December, so I'm not sure why he thought it was a good change to make. --Izno (talk) 12:35, 16 February 2016 (UTC)
Yes, I know that it has no autocollapse functionality (I wish it would have), but I think it isn’t a problem in templates which actually doesn’t use autocollapse. (Autocollapse is useful when there are half a dozen of navboxes at the end of the article, but I think it doesn’t make sense in such templates.) I recently changed the navbox template on huwikibooks to use the mw class if state is explicitly given, and also changed common.js to load the “old” method only if needed. I don’t know about any problems it caused. I know, that’s much smaller wiki than this, but I think it only means that the English Wikipedia’s change will be longer, not that it won’t change. --Tacsipacsi (talk) 13:56, 16 February 2016 (UTC)
Sure, but is this template such a case? It looks to me like the template in this case could use autocollapse. --Izno (talk) 19:51, 16 February 2016 (UTC)
I think autocollapse is not needed for this template in the sense of technique which collapses the templates if there are more than one from it on the page. Actually there mustn’t be more than one {{multiple issues}} template on one page. It might need some automatic collapsing based on the length of its content, but that’s not what the autocollapse CSS class is for (I think it could be done with Lua, but I’m not sure how can we do it exactly). --Tacsipacsi (talk) 21:46, 16 February 2016 (UTC)
How to create a one-time notice for all new user pages?
One of the all-day-every-day issues with speedy deletion is people who think that their user page is like a social media profile page and they can and should post their resume, life story, details about their company, etc. I'm wondering if it is technically feasible to create a a notice that would pop up the first time someone edits their own userpage, to inform them what it is and what it is not, in order to hopefully cut down on this problem. Note that all I am looking for at this time is if it can be done, and if so, how. Or alternately, if there already is something like this and as someone who registered their account nine years ago I'm just not aware of it. Beeblebrox (talk) 21:21, 16 February 2016 (UTC)
That seems like it may be where such a notice could be made, the how is pretty murky, and the talk page has no edits since 2014. Beeblebrox (talk) 22:06, 16 February 2016 (UTC)
Somehow my watchlist setting on my iPad got changed to the mobile version, which was widely spaced and with images for each article. I'd think that's the last thing you'd want on a mobile. Doug Wellertalk13:24, 17 February 2016 (UTC)
You can at least make it better than this, by writing a loader gadget to dynamically load this module only under certain conditions. —TheDJ (talk • contribs) 10:18, 17 February 2016 (UTC)
Source of the "Sign your posts on talk pages ..." text below editing window?
Where does the code live that generates the "Sign your posts on talk pages: <code>~~~~</code> Cite your sources: <ref></ref>" text below the editing window? I want to see about copyediting "posts on talk pages" to "talk posts" (we also sign talk posts on noticeboards, etc.), to make a little room for adding "Wrap code: <code><nowiki></nowiki></code>", which would save probably hundreds of thousands of keystrokes per year among editors (a lot of our template documentation is crappy and hard to read because people get tired of typing that out and just give up). "Cite your sources" should probably also be changed to "Cite a source", since a pair of <ref>...</ref> tags is only for a source, not for plural sources, and "your" is condescending infantilism in this context. Some of the code in the "Insert:" options available in the drop down menu also need to be tweaked for readability, etc. (e.g. the one for [] needs to be kerned so it doesn't look like a single-character rectangle, etc.)
I'd like to adjust this stuff both on our local system and contribute the tweaks to the stock MediaWiki version, but I have idea where anything is since all the repository changes made a year or so ago; some pointers would be helpful. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:17, 14 February 2016 (UTC)
In the first case, it's due to the root <svg> lacking the namespace definition xmlns="http://www.w3.org/2000/svg". I don't know what's wrong with the second file; oddly, it works fine if I download it and open the local copy in Chrome, but not if I view the online original in the same browser. In IE both work; in Firefox and Edge the online SVGs cannot be displayed directly (they only give a prompt to download the file). SiBr4 (talk) 14:50, 17 February 2016 (UTC)
Browser: Google Chrome/OS: Windows 7 Pro
Hello, I am having a persistent problem of changes in pages that I have on my watchlist are sometimes not coming through to my watchlist changes. For example if you see: Mysterious My last comment came through to my watchlist, but the previous one by ColinFine did not. I had to go to the help desk section to know it was there. Jed Stuart (talk) 01:55, 17 February 2016 (UTC)
I think there is a thread going around about items not showing if you have both "hide bots" AND "Group changes by page in recent changes and watchlist" enabled - try removing one or both of these and see if your expected watchlist item returns. — xaosfluxTalk02:14, 17 February 2016 (UTC)
Ah! That's what it will be. I haven't got around to understanding Advanced settings and was assuming that I should be getting all changes, which will now happen when I turn that on. The default position with that on would have been better for someone like me.Thanks.Jed Stuart (talk) 00:11, 18 February 2016 (UTC)
Keeping count
Is there any bot or device that counts the number of times edits by IP's are reverted? Or is there any place where editors can manually increment such a count? I mean does anyone care about making a statistic about this thing, or does the almighty 'Wikipedia is the encyclopedia that anyone including vandals can edit' override our need to keep such a statistic? It's mid-February, the summer break is over and the kids have been back at school for a couple of weeks, and I'm getting tired of reverting vandalism caused by bored kids with cellphones. Akld guy (talk) 00:11, 18 February 2016 (UTC)
I created a redirect Mowl, Timothy to point to Timothy Mowl, to aid in making links from references to his books. When I look at Special:WhatLinksHere/Timothy_Mowl it does not shew, neither does it shew on Dispenser. I did all this last night, and thought at the time maybe it was just a delay in different bits of Wikipedia catching up with each other, but it is now over 10 hours later. What is occurring please? DuncanHill (talk) 10:12, 18 February 2016 (UTC)
I did a couple of null edits last night, but they did nothing, having done one just now it seems to work! Well, it's fixed but it is odd that it happened. DuncanHill (talk) 11:13, 18 February 2016 (UTC)
Is this page still correct? In the lede it says: Among other problems, this browser [Internet Explorer] doesn't properly support PNG images with alpha channel transparency. --Leyo15:39, 17 February 2016 (UTC)
You are probably right, but I think this fact needs to be mentioned explicitly. Otherwise, people think that this issue persists. --Leyo15:47, 17 February 2016 (UTC)
@Leyo: I stuck a "historical" tag on the top of that page. May I ask how you came across that page? Any pages that link to it probably need to be updated or marked historical themselves. — This, that and the other (talk)09:58, 18 February 2016 (UTC)
Hacking {{Noping}} to show red links for users without a userpage
I have been able to get the Noping module to recognize when a userpage does not exist (see {{Noping/test}}). I would like to use this feature extensively for my bot on Commons.
However, I cannot figure out how to directly edit the external links. The <div> looks like this, which doesn't output red links:
Question: Is it possible to get the Lua template to output red links for users with all CSS skins, and not to appear as redlinks for users who have this option turned off in their preferences? I think it's acceptable to edit Mediawiki:Common.css, but IMO a sitewide Javascript approach is too expensive for an infrequent use case like. Magog the Ogre (t • c) 03:21, 16 February 2016 (UTC)
The class a.external has "color:black !important". You might have success by stripping out the class="external text" from the "ret" variable, using substrings. Mamyles (talk) 04:30, 16 February 2016 (UTC)
Hi everyone. I'm planning to run an editing workshop at my university (the Ateneo de Manila University) later this month and I was hoping to get some help.
I've been trying to run WP:TWA to make it more fun for editors to learn how to edit Wikipedia, but for some reason as they edit Wikipedia, they receive errors saying that too many people are doing the exact same action at the same time. I actually have no idea how this happened, but I suppose it's because the computer labs at my university all share the same IP address (or two). I was hoping to get some advice on how to go around that problem so that the 20-30 students who I'll be teaching later this month will be able to play the game, and ultimately edit Wikipedia, with no problem. --Sky Harbor(talk)04:05, 18 February 2016 (UTC)
@AKlapper (WMF): I'm not sure exactly since it happened a while back, but based on the link on Meta I suppose it had something to do with edit rate limits as a result of the IP cap. --Sky Harbor(talk)13:46, 18 February 2016 (UTC)
Shouldn't be linking the date, anyway, per MOS:NUM. If only reason to link a year in a case like this is to go to a specific article about that topic in that year, e.g. [[United States Supreme Court Decisions, 1989|1989]], and we'd only do that (as in this template) in cases of tables or other highly compressed information, where it's clear in context that we're linking to a resource organized by year, not to a year article (which is what the assumption would be if the link appeared in article prose, though one can reasonably do something like "... the Supreme Court [[United States Supreme Court Decisions, 1989|decisions in 1989]] and [[United States Supreme Court Decisions, 1990|in 1990]] were ..."). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:23, 14 February 2016 (UTC)
@SMcCandlish: I understand that we shouldn't be linking the date, which I why I started this thread. Can you change how {{#ifexist}} works so these pages aren't linked to the year articles? GoingBatty (talk) 22:56, 14 February 2016 (UTC)
I think the way to fix it would be for the current {{#ifexist:}}s to be checking whether the |date= parameters are dates, rather than if those articles exist. That would remove the links. My query is whether that's possible currently in the template, or if we have a Lua module lying around somewhere that can do it. Maybe the CS1 date validation module can? --Izno (talk) 01:54, 15 February 2016 (UTC)
The cs1|2 date validation code is rather overkill for this case which requires a single date format (MDY). Perhaps, instead of the {{#ifexist}} test, you could write a sub-template that accomplishes much the same thing. Or, why bother? Are bad dates in these templates a problem that needs solving?
{{#ifexist:}} cannot be used to test the validity of parameters. Its function is to check whether the named page exists or not; in so doing that page is added to the "what links here" table. Thus, "{{#ifexist:10 feet|it exists|it does not exist}}" → "it exists" and see Special:WhatLinksHere/10 feet where you will find Wikipedia:Village pump (technical)/Archive 144 listed; compare "{{#ifexist:20 feet|it exists|it does not exist}}" → "it does not exist" observe that you will still find Wikipedia:Village pump (technical)/Archive 144 listed at Special:WhatLinksHere/20 feet. --Redrose64 (talk) 10:02, 15 February 2016 (UTC)
@GoingBatty: you could probably use a combination of the parser functions time and iferror to determine whether a date is valid or not. — Martin (MSGJ · talk) 09:01, 16 February 2016 (UTC)
You would think that but, but {{#time}} will modify its output to give the appearance of a correct date when its input is clearly wrong. Here is an example of an invalid date and format (February does not have 30 days and the format is missing the comma):
{{#time:F j, Y|Feb 30 2015}}
March 2, 2015
If one could turn off the date mathematics in that function ...
Why not replace {{#ifexist:{{{year}}}||[[Category]]}} with {{#ifeq:{{#expr:(1789<={{{year}}}) and ({{{year}}}<={{CURRENTYEAR}})}}|1|[[Category]]}}, which should catch both non-numerical answers as well as out-of-range years? --Ahecht (TALK PAGE) 17:31, 18 February 2016 (UTC)
Are you are replying to my post? My post was a reply to Editor MSGJ's comment re: the {{#time}} parser function. If these tests are important, then it is also necessary to test the 'date' portions (month followed by day) which {{#time}}, because of the date mathematics functionality doesn't do such a good job at. I'm not seeing any obvious reason why your proposed code could not work for the 'year' portions of the date checking. If these date checks are important, perhaps the correct solution is to simply adapt a portion of Module:Citation/CS1/Date validation to do the work. Are these checks important?
Coemgenus, the creator of the Census template, is unable to resolve issues with this template, as shown by the lack of responses on the Template talk page, and I'm trying to fix it myself. One of the issues was that the Title parm was by default wikilinked to a WP article about the census. This wikilink isn't useful, as the template should link to the actual URL of the source. I removed the WL from the Title parm, and added a parm for URL, but I don't have the expertise required to wikilink the title and URL, as is done in the Cite template. For example, see this census citation containing a URL in Danny Thomas. Can someone point me to an example or documentation that I can use to fix this issue? Thanks — btphelps(talk to me) (what I've done)05:54, 19 February 2016 (UTC)
Thanks for the quick assist! I noticed the punctuation issue as well, but I'm unclear about how to refine it further. I think additional uses of the #if parserfunction might do it, so that when a parm is not present, the punctuation is not displayed, though it's complicated by the various parms that might or might not be present. — btphelps(talk to me) (what I've done)07:19, 19 February 2016 (UTC)
How do I force the table of contents to the top of a page (i.e., no lede)?
See alternatives, and also reasons you might not want to do so, at WP:TOC (i.e. "However, if there is any text at all between the TOC and the first heading, this will cause problems with accessibility."). Quiddity (WMF) (talk) 00:57, 18 February 2016 (UTC)
In Names of Germany there is an image of Gaius Cornelius Tacitus at the beginning of the section Names from Germania (where it belongs; at least in the source), but a string of images on the right from the preceding section is pushing this down. I can't see why. Worse, if you adjust the browser width so that the image is just at the top of the Names from Alemanni section, instead of the title Names from Alemanni flowing around it, it is superimposed on the image. How would I go about sorting this out? Is there an explanation somewhere of the basic strategy to use for images floated left and right - presumably in Wikispeak (I sort of know how to deal with it in html). Thanks Imaginatorium (talk) 15:55, 17 February 2016 (UTC)
Floated images are always displayed in the same order that they occur in the page source; two consecutive images might have their upper edges level with one another if one is left-aligned and the other is right-aligned (or vice versa). So if you have a sequence of right-aligned images, then any left-aligned image that occurs anywhere within or after that sequence cannot be displayed any higher up the page than the top of the last right-aligned image which precedes it. --Redrose64 (talk) 21:12, 17 February 2016 (UTC)
Thanks for the responses. My impression of doing this sort of thing in HTML is that a floated left/right image works wonderfully; two floated images cause problems. Do I understand from this that basically it is better to avoid large numbers (>2) of images as in this case? But I'm also not clear if @Cmglee:'s suggestion of a "gallery" would allow a "vertical" gallery down the right, or whether this means I should simply move all the maps to the bottom somewhere? Imaginatorium (talk) 12:15, 19 February 2016 (UTC)
I was thinking of a horizontal gallery (with wraparound) similar to the mock-up below. I'm unfamiliar with the subject so can't recommend a section in which to place them. They are currently in the Names of Germany#Names from Diutisc section but that doesn't seem relevant to the maps. Perhaps creating a new section at the bottom would be better. Cheers, cmɢʟee⎆τaʟκ13:59, 19 February 2016 (UTC)
I usually fill out citation templates by clicking on the "cite" button in the panel above the editing window and then following the instructions (choosing web, news, or book, I believe I have never chosen other options). At least in the news, the form apparently uses a deprecated parameter "coauthor", and if I fill it in, the template looks partially broken. I guess this is because the form was not updated after it was decided that the template is deprecated. One can check History of Ukraine, Ref. 59 which I minutes ago added using the panel interface. Could somebody please do something about this? Thanks.--Ymblanter (talk) 11:25, 19 February 2016 (UTC)
Yes, the form is using a deprecated parameter of the cite templates. I fixed the problem. For the future, I suggest that you review the help page which was prominently linked. --Izno (talk) 12:35, 19 February 2016 (UTC)
Thank you. Actually, my question was not about fixing the template on the specific page (which I know how to do, I just left it as an illustration of a problem), but about fixing the citation interface in the panel so that it would not produce deprecated parameters any more.--Ymblanter (talk) 12:38, 19 February 2016 (UTC)
This is a screenshot on February 15, 2016 of Wikipedia:Village pump (technical). It is uploaded at the request of editors who need to see the appearance of a music template, in order to diagnose a problem.
@The Quixotic Potato: Imgur should not be necessary; some of us find it objectionable because of the payload (such as advertising) found on every page, which slows the computer right down whilst irrelevancies are loaded. Is there anything wrong with the directions at WP:WPSHOT? --Redrose64 (talk) 20:08, 15 February 2016 (UTC)
FYI, I am now in my car on the road for a few days, separated from my computer. Will follow up on this when I get home. In the meantime, I hope this report will be useful.Anythingyouwant (talk) 21:27, 15 February 2016 (UTC)
@Redrose64:, so don't click? You're generally very helpful and I look for your responses when skimming technical discussions, but your harsh tone here seems misdirected. I use a nifty tool called AdBlock that helps dispel "irrelevancies". I can understand why some users, especially newer contributors, would use Imgur when it's as simple as drag-and-drop without fumbling over the sometimes-awkward wiki image uploader. In summary: I hope you're having a better day today. :) Killiondude (talk) 23:29, 16 February 2016 (UTC)
@Killiondude: We don't know if the comment has a harsh tone, that is one of the limitatons of on-wiki communication. It is possible to interpret Redrose's comment as having a harsh tone but it is also possible to interpret it without one. I highly recommend using stuff like Ad Block Plus, HTTPS Everywhere, Privacy Badger and even NoScript. If a single website is able to bring your computer to its knees then there must be something wrong. It's easy to write some JavaScript that will crash a browser but the rest of the operating system should continue working. Imgur.com contains ads, but no malware afaik. Imgur.com is easier to use than this form. It would be cool to have something similar to imgur.com, but ad-free and with online cropping. Another advantage of Imgur.com is that they don't care as much about copyrights. The Quixotic Potato (talk) 00:36, 17 February 2016 (UTC)
I'm back home now. I have followed the directions at WP:BYPASS, but still have the same problem (i.e. big black rectangle in the "Listen" template). What should I do now? Do you get the same problem?Anythingyouwant (talk) 04:05, 17 February 2016 (UTC)
Right, I did some further digging. The reason why BYPASS doesn't work here, is because this is not coming from the server, it's actually using something inside your browser called LocalStorage. Now something about the setup of the servers has changed in the past month, that made what is in that storage invalid. It's a bit of a cornercase. Luckily, this should be fixed after monday (for the smaller wiki's) and/or wednesday (for the larger wikis), since a new patch will then roll out also will happen to fix this particular instance of the problem. —TheDJ (talk • contribs) 13:42, 19 February 2016 (UTC)
I have some scripts installed (User:Vanjagenije/common.js) that are essential for my SPI Clerking. Yesterday afternoon all scripts stopped working and they are still not working. I am using Google Chrome, but I also tried using Opera, but it's the same. Page is loading and loading, but the scripts are not loaded. What's the problem? Vanjagenije(talk)10:17, 20 February 2016 (UTC)
At intermittent intervals since about 18:00, 19 February 2016 (UTC), perhaps earlier, I've had HTTP 503 errors like "Error Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes." I suspect that you've encountered an outage like that when loading the script. --Redrose64 (talk) 11:09, 20 February 2016 (UTC)
It is indeed a unified account; it simply appears that the user hasn't visited Wikibooks yet. The user should log out and then perhaps try logging in from Wikibooks, to see if that creates their account there. — This, that and the other (talk)08:33, 21 February 2016 (UTC)
Yes, many templates (most notably {{navbox}}) are intentionally hidden on mobile. It's not a bug. OK, I agree, that in this case it looks somehow weird, that the section is empty on mobile version. --Edgars2007 (talk/contribs) 21:25, 19 February 2016 (UTC)
I understand that the common navboxes at the end of an article are different. They are (arguably) not part of the content of the article itself, but helpful navigational aids for people who might be interested in related topics. However, a list of the largest cities of a location in the middle of the article is a very different thing. It may have been convenient to use navboxes to construct them, back before mobile existed, but now that mobile exists, we have many articles (611 transclusions) with a section about largest cities which is empty. I came across this by fielding a question from a reader at OTRS who wanted to know why there was no list of cities in the section clearly labeled as a list of largest cities. If I tell them it is not a bug, I don’t expect that to fly.
My suggestion is not that we rethink the rendering of the navbox template on mobile, but given the ubiquity of this template in lists of large cities, that we look into a conversion of these templates into something that will render. --S Philbrick(Talk)21:47, 19 February 2016 (UTC)
I agree: "a list of the largest cities of a location in the middle of the article is a very different thing." Translated: Someone used the wrong template for the wrong purpose. See also: Wikipedia:Navigation_templates. You shouldn't expect it to work. —TheDJ (talk • contribs) 12:45, 20 February 2016 (UTC)
@MusikAnimal: It's not most templates, it's a comparatively small number. The templates that get hidden are those that belong to certain classes, including sistersitebox tmbox ambox navbox vertical-navbox metadata - most of these are only found in box-type templates. If a template encloses its content in one of these classes, that content won't display on mobile. --Redrose64 (talk) 00:50, 20 February 2016 (UTC)
If you think that this table is important for mobile readers, you should probably start with making it fit on their small screens. Max Semenik (talk) 20:40, 20 February 2016 (UTC)
The most useful solution for a mobile phone would be if the template displayed a link, so that the user can navigate to the list, if interested. That would be a similar experience to expanding a list, with the main difference that it doesn't display the surrounding text, which isn't necessary here. (The other difference is that it will count as a new page request, which has its advantages, too.) I think that it should also be easier to implement than other solutions. — Sebastian22:53, 21 February 2016 (UTC)
New England Cop Go to your personal user Preferences, then Gadgets, under the Browsing section. Scroll down to the two "suppress" options and check one or both, whichever you feel applies to you. Click "Save" at the bottom of the page. — Maile (talk) 23:26, 21 February 2016 (UTC)
Reporting: Gadget only works with Vector skin, javascript error
Greetings, The gadget Mobile sidebar preview (Preferences / Gadgets / Mobile sidebar preview - Show page in mobile view while browsing the desktop site) has an error for all skins except Vector.
* Awaiting – February 17 is approaching. Wondering if the javascript error and be found, tested & made live before then? Or should this tip be rescheduled forward? Per the Phab.T126553, TypeError: $content.position(...) is undefined
this gadget appears under "Testing and Development". i just can't imagine someone interested in "testing and development" using any skin other than the standard one - you don't do either testing or development using monobook. indeed, it should not result in JS error, and the solution is trivial: add to the definition of this gadget (MediaWiki:Gadgets-definition) "skin=vector", so it won't be invoked for other skins. peace - קיפודנחש (aka kipod) (talk) 20:24, 15 February 2016 (UTC)
@JoeHebda: Found the message at WT:US. It appears to be a blindingly simple fix: just remove that line. The top variable hasn't been used since this edit back in 2014, so unless the content.position() function call is doing something by side effect that I'm not aware of, we can just ditch that assignment completely. (Of course, the var keyword needs to be kept, though, for the other assignments in that statement.) jcgoble3 (talk) 20:28, 15 February 2016 (UTC)
@קיפודנחש: I believe the "testing and development" section is not meant for users performing testing and development, but rather it means that those gadgets themselves are still being developed and tested and might not be fully finished or fully functional yet, which in turn means that they might break from time to time. Such is the nature of using beta software. jcgoble3 (talk) 20:34, 15 February 2016 (UTC)
@Jcgoble3 and קיפודנחש: – Thanks for the info. as I know very little about scripts. In order to get the Tip-of-the-day posted for February 17, I will update this tip to state As of February 15, 2016 the mobile sidebar preview gadget is available only with the Vector skin. Regards, JoeHebda(talk) 20:55, 15 February 2016 (UTC)
i get it: "testing/development" is about the state of the script, rather than what it's used for. even so,, i think my point still stands: this gadget is meant for people who wish to make sure the page they are editing looks good in the mobile view. it is hard to imagine that someone using an outdated, obsolete skin cares about "how the page looks for mobile users" - they should care at least as much about "how this page looks to (practically all) desktop users" (i.e., how does it look using vector). so i still think my "stopgap" suggestion, to limit this gadget to vector users via "gadgets-definitions", makes sense. on the happy side, i looked at the script, and the issue seems pretty obvious. i left a message on the author's talk page in meta (author is User:Brion VIBBER, and his meta talk page is, naturally, m:User talk:Brion VIBBER). peace - קיפודנחש (aka kipod) (talk) 21:53, 15 February 2016 (UTC)
@Jcgoble3 and קיפודנחש: – Looking forward, to prevent future confusion: Can the Gadgets page be updated to mention (Vector skin only) for the Mobile sidebar preview option? It looks like that page is non-editable so I don't know where/how to have the change made. JoeHebda(talk) 00:43, 16 February 2016 (UTC)
@JoeHebda:This is the page you'd want changed, but like I said, the code throwing the error isn't even in use anymore, and it's likely (but not guaranteed) that removing that piece of code would fix it in other skins, so I would strongly recommend pursuing that change first before giving up and labeling it Vector-only. @קיפודנחש:, I think, is barking up the wrong tree here (albeit with good intentions); the other skins are not "outdated [and] obsolete", but rather, some people simply hate Vector and prefer a different look, and those skins are actively maintained AFAIK. Users can simultaneously prefer a different look on desktop and still be concerned about mobile appearance; there's nothing wrong with that. So it can easily be of use to non-Vector users, and support for those skins shouldn't be dropped that quickly (much less implementing a technical restriction completely preventing it from being used at all on those skins, as was suggested earlier in this thread). jcgoble3 (talk) 01:01, 16 February 2016 (UTC)
@Jcgoble3 and קיפודנחש: – Thanks Jcgoble3 for the insights. For the Tip-of-the-day, I posted the Feb. 17 tip about Mobile view sidebar from the desktop. For now, it has the (Vector only) in the lead sentence. Since I know very little of scripts, I am unsure of how long it will take to: 1) find someone to update the non-Vector skins to include this feature; 2) testing 3) go-live. Being somewhat new to Wikipedia (April, 2014) my first thoughts are that completing this may take many weeks and/or months to complete. I'm just happy that the Vector gadget works correctly, even though I do not like Vector skin & prefer Modern instead. Current report of User preferences, Skin shows majority of users chose MonoBook - 2,182,546 vs. Vector - 162,136. Regards, JoeHebda(talk) 01:27, 16 February 2016 (UTC)
some comments:
it's not about fixing other skins to support the script - it's about fixing the script to work with all skins. the script is maintained by User:Brion VIBBER, on his meta accound (meta:User:Brion VIBBER/mobile-sidebar.js). it should take Brion less than 10 minutes to fix it (one minute for the fix, the rest for testing with all skins). there's a topic about it in Brion's talk page on meta.
as to enwiki: IMO, the correct thing to do, is not to edit the gadget's description, linked above by User:Jcgoble3, but rather to edit MediaWiki:Gadgets-definition, and add "skin=vector". this will hide the gadget from the gadgets' page in "preferences", and avoid loading it even if selected, when the skin is not vector. look at the page history to figure out whom you can ask to edit it.
vector vs. monobook users: the stats page does not show the default value used by the vast majority of registered users, and 100% non-registered readers. (according to Special:Statistics, there are some 27 mil. registered users on enwiki. anyone not using one of the existing non-vector skins, is using "vector". so there are about 25 mil. registered vector users, and about 800 mil non-registered users...
@קיפודנחש: Again, putting "skin=vector" into MediaWiki:Gadgets-definition is the nuclear option here and IMO is completely ridiculous when the script can likely be fixed on the other skins by removing a single line. That's not a reason to completely and totally prevent the gadget from loading at all for anyone at all on the other skins. The correct solution is to fix it so it can be used on those other skins, which looks to be very simple to do. And I do not care one whit about what numbers you come up with; MediaWiki supports the other skins, and therefore we should also support them wherever feasible. And here it is likely plenty feasible to do so. I strongly oppose that course of action unless and until it is determined that it is completely impossible to get the script working on any other skin. We are far from making such a determination here. Don't throw the baby out with the bathwater. jcgoble3 (talk) 02:51, 16 February 2016 (UTC)
@Jcgoble3: i do not feel that strongly about it, but i think there are some slight difference in point of view here: (1) i do not see editing MediaWiki:Gadgets-definition as a "nuclear option". it is not something holy (i've done it on hewiki dozens of times - nothing to it, really), and it seems cleaner - instead of changing the gadget prompt to say "does not work with modern", we just don't show this choice to modern skin users. i don't see why you consider it "nuclear".
(2) i don't see a huge issue in doing it this way now, and reverting once the script is fixed.
(3) as to the fix in the script - i suspect it's tiny bit more than just removing one line, but it should not be that much more (basically, replace all calls to $('#content') with mw.util.$content ).
(4) if User:Brion VIBBER will not respond to the prompts in his meta user page, it's always possible to copy this script locally to enwiki and fixing it here. this is not the desired solution, but it *is* possible.
@קיפודנחש: 1) and 2) For something as simple as this, it's unnecessary and would actually make debugging a little harder (in that the script would need to be manually installed at Special:MyPage/common.js to be tested on the other skins). And the "testing and development" header implies that stuff there is not guaranteed to work correctly and may be broken, so there's no urgent need to disable it when leaving it there can simplify testing. 3) I'm not all that familiar with the mw library, so perhaps so. Still, it's not a big script, so should be an easy fix. 4) Indeed possible, and I think it might be better to copy the script to the local MediaWiki: namespace so that the many admins here can maintain it, rather than relying on one person on Meta to keep it up-to-date. I'll leave that decision to others, though (obviously). jcgoble3 (talk) 20:11, 16 February 2016 (UTC)
How hard would it be to implement a plus/minus number at the top of the diff pages? In the history pages there is always a +/- number beside each edit summary which gives an approximate clue of the number of characters changed in the edit. This can however be misleading since it is a net-difference (remove 1000 chars, add 1001 different characters, display a +1 change). What I would like to see is:
a number above the left column of the diff showing the # of chars removed,
(highlighted by the CSS entry for td.diff-deletedline .diffchange{background:...)
a number above the right column of diff showing the # of chars added,
(highlighted by the CSS entry for td.diff-addedline .diffchange{background:....)
and a number above the middle of the two columns showing the net change (the same number as on the edit history entry).
Preferably both side numbers would be highlighted just like the actual change text below them are. I suspect this number already exists as a counter in the code just because the text is highlighted. IMHO this would be a trivial code change to display these numbers but a very helpful one when going through a long series of diffs. Just my opinion (and wishlist). Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 00:59, 21 February 2016 (UTC)
That's a bit disingenuous. Tha "improved diff screen" proposal was voted on by the community after being proposed by The Quixotic Potato and another user. No-one told anyone to do anything. And in fairness, diff is a difficult thing to get right. wikEdDiff is certainly not infallible. It will most likely take the Community Tech team some time to work on improvements, especially since the request is so broad. — This, that and the other (talk)07:48, 21 February 2016 (UTC)
Disingenuous? I didn't want to explain the full circumstances, which would be quite boring, but I wanted to make clear that this wasn't an idea they made up on their own. And yes, after I wrote my proposal another user posted a proposal that was similar to mine, so someone merged them. Of course they do not listen to me, because I am just a random potato who fixes typos on Wikipedia and I do not work for the WMF but I am pretty sure I did tell them to do that. Multiple times. They finally started to take this request seriously when it received unanimous support in that survey, but that wasn't the first time that I posted that request... You seem to be unaware of the history behind that request, so you shouldn't claim that that comment is disingenuous. It is true that wikEdDiff isn't perfect, almost nothing is, but in most cases it is a hell of a lot better than the default diff compare screen. The amount of chars added/removed is also displayed on the history page and the list of recent changes.The Quixotic Potato (talk) 08:05, 21 February 2016 (UTC)
@Koala Tea Of Mercy: To return to the original q. No, the numbers are not present in the default (i.e. non-wikEdDiff) diff, so there is nothing that we can do to reveal them. The differing colours are because the MediaWiki software has compared two lines, detected some inconsistencies, and has wrapped those inconsistencies on the left in <del>...</del> elements, and those on the right in <ins>...</ins> elements. These elements also have classes so that the colours may be applied through CSS. To add the numbers (bytes removed, bytes added, +/- change) sounds nice, but we can't do it - to have it implemented you would need to file a feature request at phab:. --Redrose64 (talk) 10:19, 21 February 2016 (UTC)
Redrose64, I would be fine with filing a feature request at Phab, if that is all it takes to start the ball rolling then you have answered my question. I thought maybe I would have to put up some sort of RFC or whatnot here first. Thanks for the information.
When I said that "I suspect this number already exists as a counter in the code" I was referring to the MediaWiki code. Whenever you compare strings there is a length counter involved. This is fundamental to all string processing routines in any programming language I know of. That length counter has to be used to help setup what text will be highlighted (essentially this kind of process always requires 2 variables: a start-pos and string-length to isolate the string to be highlighted). All that would be needed is to insert a single instruction near the end of the highlighting subroutine, "borrowing" the length counter for a microsecond and adding it to either the master-ADDs-length-counter or the master-DELs-length-counter [these are just pseudo-code var names for illustration] for eventual display the final diff page layout. I am by no means a master programmer but I would wager this is so trivial that if someone would point me to the diff highlighting section of the Wikimedia code I could write up a concrete proposal including the appropriate code. Someone familiar with the more complex diff page layout would then need to write a few lines to actually put the numbers on the page [I know better than to try and tinker with something that complex myself]. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:13, 21 February 2016 (UTC)
There are many phabricator tickets and not enough developers; if you can show that you have a consensus that your idea is a good idea then it is more likely to get attention from the developers. The Quixotic Potato (talk) 17:49, 21 February 2016 (UTC)
I got rid of the metadata class from the RFA closure templates (it had been there since they were created in 2005, and there are no CSS rules applied to it on desktop). Of course, this won't affect any existing RFAs, as the template is substituted into every old RFA subpage. — This, that and the other (talk)10:39, 22 February 2016 (UTC)
It's based on the map supplied by the map you're using in the |locmapin= parameter — it automatically transcludes a category entitled "Historic district contributing properties in {{{locmapin}}}". The first and third articles display the map in question, and the second omits it because coordinates aren't specified in the template. For a quick example of how this is supposed to work, see the article on the William B. Dunlap Mansion and its categories. I don't remember how to do it, but it can be fixed; there are lots of articles about NR-listed places in Portland, but the Kenton Hotel is the only article currently in Category:Historic district contributing properties in USA Portland, so presumably the rest of them have the coding to fix this problem. Nyttend (talk) 00:16, 22 February 2016 (UTC)
Historic district articles are autocategorized into a state-level category, Category:Historic districts in STATE, which are all listed in Category:Historic districts in the United States by state. This categorization uses the locmapin parameter; if locmapin is left blank or not included, the article will be placed into Category:Historic districts in the United States. Since this is a top-level category, it is desirable to move articles down to lower, more localized categories. Most times this can be fixed by simply adding a state name to the locmapin parameter, but this will cause the locator map to be displayed. If, for whatever reason, the location map should not be displayed, there is a workaround:
nocat – Setting any value to this parameter will cancel all autocategorization and allow you to manually categorize the article.
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
There was no new MediaWiki version last week. Changes that were planned to happen last week will happen this week instead. This is because of a bug that made saving pages take longer time. [14][15]
Changes this week
After February 23, you can use Wikidata for inter-language links on Wikiversity. [16]
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 23 February at 20:00 (UTC). See how to join.
FYI, one of the Zotero maintainers is hosting a workshop next week on how to write Zotero translators (the website parsers that are used in Citoid's citation generation backend). I highly recommend joining in. It's scheduled for next Monday, the 29th, at 20:00 UTC (more details) czar06:56, 22 February 2016 (UTC)
This is awesome. I hope there will be a high attendance, since this is really important for our references. Unfortunately I myself will be on vacation during that time, so I hope the recording will be of sufficient quality to fully enjoy it afterwards. —TheDJ (talk • contribs) 18:35, 22 February 2016 (UTC)
I created my account with my real name, but soon realized that it is not a good idea. I recently changed my username but all my old contributions still have my old name as the Author and not my new name. Can anyone help me with it? — Preceding unsigned comment added by WavesOfTahoe (talk • contribs) 21:46, 16 February 2016
Redrose, they've already been to WP:CHU. WoT, your old username doesn't show on those edits anymore, with the exception of your signature on the WP:CHU page. For transparency, I don't think we usually delete those. However, you have a very short editing history, so if you're concerned about any links to your previous name, it's probably easier to just abandon this account and start a new one, with yet another username. As long as you don't continue any disputes you had under the old name (if any - I haven't checked), that's a perfectly legitimate thing to do. --Floquenbeam (talk) 22:19, 16 February 2016 (UTC)
Hi there! If you go to this page, you'll see a bunch of redlinked templates at the top which shouldn't be there. I tried to fix it on my own but, clearly didn't do it right. If someone wouldn't mind fixing it or, better yet, explaining to me how to do it on my own so I know should I encounter this again, I would very grateful! Thanks in advance!Cebr1979 (talk) 00:36, 23 February 2016 (UTC)
I don't see it when I'm logged out. Sorry to confuse you: "where is this coming from" was meant as a question about the page where this change was made, i.e. when someone hit "Save" to deploy this note, what page were they editing? MediaWiki:Gadget-geonotice-list.js is the only MW:space page that's been edited in four days, according to Special:Recentchanges. Nyttend (talk) 00:33, 22 February 2016 (UTC)
Indeed, it was out intention (in Wikimedia Community Ireland) for just those in Ireland to be targeted with this survey. MZMcBride was kind enough to help our group set up the banner and he campaign, so this issue should be resolved by tomorrow (GMT) Smirkybec (talk) 15:11, 22 February 2016 (UTC)
Whoops, sorry about that. For some reason I thought you all intended to target users in the U.S. and Ireland in both Gaelic and English on both ga.wikipedia.org and en.wikipedia.org. It seems that understanding was close, but not quite right. James A. already fixed the issue over on Meta-Wiki, according to m:Special:CentralNoticeLogs. (Thank you, James!) --MZMcBride (talk) 00:57, 23 February 2016 (UTC)
Interminable flashing
Gobi Desert has suddenly begun flashing interminably, at a frequency of a couple dozen hertz. At points, almost the whole page is visible, while at others, it's almost totally blank. See the screenshots I've uploaded as File:Gobi Desert screenshots.pdf for three examples of what's happening. It happens regardless of where I am on the page: top, bottom, or in between. It's only when I view the page while logged in, either the live version or the version I see when previewing (the history page is fine); logging out fixes the problem, as does viewing it in Firefox instead of my normal browser, the latest Internet Explorer. Perhaps it's a skin thing, since I use Monobook. Neither cache-clearing nor making a dummy edit had any effects. Any idea what could be causing this? Nyttend (talk) 01:04, 23 February 2016 (UTC)
It sounds like a graphics card driver problem. You can disable hardware acceleration in your browser settings to avoid these (rather common, imo) issues. To do so in firefox, go to firefox menu > options > advanced > general and uncheck use hardware acceleration in that panel. Mamyles (talk) 04:41, 23 February 2016 (UTC)
I opened Wikipedia and somehow I was logged in to this account
Okay, this is really weird, but I'm actually User:FallingGravity. Somehow I logged into this account when I opened my laptop, even though I never typed in the username and I don't have any clue what the password is (I checked and it's not the same as my actual password). Apparently this account used to be active on the Chinese Wikipedia. Anybody have any clue how this happened? Should I be worried about my account? Actually I think I'll just go ahead and change my user password just in case. 023yangbo (talk) 06:34, 23 February 2016 (UTC)
Greetings, I'm about one-half way through updating columns in article List of popes which has 20 tables, one for each century. For each table, I'm doing a copy-and-paste of this wikicode:
! style="width:5%;"|{{small|Numerical order}}
! style="width:10%;"|{{small|Pontificate}}
! style="width:5%;"|{{small|Portrait}}
! style="width:15%;"|{{small|Name: English<br/>· Regnal<br/>Motto:<br/>Latin (English)}}
! style="width:10%;"|{{small|Personal name}}
! style="width:10%;"|{{small|Place of birth}}
! style="width:5%;"| {{small|Age at start/<br/>end of papacy}}
! style="width:45%;"|{{small|Notes}}
Is there any way that I can do something like an "include" or "copy" or "subpage" to create the column heading wikicode only once? Then each table could pull in the same columns wikicode. Back in my mainframe programming days, this was easy to do. Right now I'm lost & asking for help. Going forward it would make table maintenance a lot easier too. Thanks. JoeHebda(talk) 14:25, 22 February 2016 (UTC)
Greetings User talk:Trappist the monk – Interesting example & might work for this list also. Please excuse me if I'm asking a dumb question (do not know much about templates): can only the begin & end templates be made like a wrapper for existing data? Or are all 3 required? JoeHebda(talk) 19:49, 22 February 2016 (UTC)
The item template is not required but is I think easier to maintain in the long run. The shipwreck lists {{shipwreck list item}} simply encapsulated the table row markup and data making it easier to edit later if necessary. That same could apply to List of popes especially since there is special markup applied to each row (vertical-align:top) and to three of the columns cells in a row (style="font-size:85%"). Should it ever be desirable to add or take away a column, change the markup, or other 'global' changes, those changes would likely be easier done once to a template than to touch every row.
It isn't necessary, though for editor readability it might be desirable, to have each column's data in a row have a named parameter.
Hi User talk:Trappist the monk – Sounds like a lot of work with eight columns of data and 266 rows spread across the 21 tables. Wondering if there are any kind of template/table conversion tools out there? Or maybe a bot that can change a wikitable into a template?
For now, it might be easier for me to continue plowing through the remaining (1st to 12th centuries) and look to do the template update as a next step. Any advice would be great. Cheers! JoeHebda(talk) 21:56, 22 February 2016 (UTC)
Hi User talk:Trappist the monk – Thanks so much for doing this. Never in a million years could I have ever figured this out on my own. Very good & easy to understand example! Will try it out with 21st century (two most recent popes). Learning something new every day. :-) Cheers! JoeHebda(talk) 22:54, 22 February 2016 (UTC)
Trappist the monk – When I reviewed the List of popes I saw the error because I missed adding the title= to the Pope list begin template. Now I'm puzzled about why the edit links for each century no longer work? The "1st millennium" edit link works, but not for the century wikitables. For "2nd millennium", I have not yet fixed the title error & all of the century edit links work. Any idea of how to fix? Regards, JoeHebda(talk) 18:43, 23 February 2016 (UTC)
Greetings Trappist the monk – All is good: Wikitable titles = done; Edit links = done; all pope list begin = done; all pope list end = done. 21st century has pope list item template in place. So now as time allows, I can do the item templates. Thanks again for your expert help! Cheers! JoeHebda(talk) 00:51, 24 February 2016 (UTC)
Now, when I edit a section and click "Show preview", the preview includes the references cited in that section. This is a big improvement. I would like to thank whoever implemented it. If this is not the right place for my thanks, could someone please let me know where is? Maproom (talk) 14:51, 23 February 2016 (UTC)
I concur that is is nifty new feature. I look forward to the day when it can fully deal with sections that are referenced in WP:LDR (list defined references} format—those using named references, e.g.- <ref name="Annual report" />. Cheers! {{u|Checkingfax}} {Talk}23:21, 23 February 2016 (UTC)
I concur with the thanks and with the hope that someday LDRs will also preview, although I can't imagine how that would work, since they are defined outside the section. Easy enough to open another window and view the References section, though. Perhaps an elegant solution would be to have the References preview when editing the section where they're listed, in the order in which they're listed?
Cenarium has been working on that as well (tracked in T124840), but it indeed comes with some added complexity, so probably best not to make promises on that just right now. —TheDJ (talk • contribs) 00:23, 24 February 2016 (UTC)
Also thanks from this little corner of Wikipedia, as I no longer have to insert a test {{reflist}} to preview, and then (sometimes forget to) remove it before I save the section. MaxiKudes! Follow Jimbo!Paine02:27, 24 February 2016 (UTC)
The closest I know is Page/History/Revision history statistics. That's not as narrow as you indicate you want. However, the results tell you the first edit and last edit of a given editor. 1. — Maile (talk) 17:42, 19 February 2016 (UTC)
As a general rule, what should be done with very old unsigned threads on article talk pages? These will never be archived and they effectively reduce |minthreadsleft=, potentially to zero. Example: Talk:9-1-1. ―Mandruss☎17:53, 22 February 2016 (UTC)
I usually add my own signature and a comment saying the above thread is very old. Then it gets archived away by a bot or whatnot. OTOH, you can also manually archive it if it's that old. Either way works. --Izno (talk) 17:56, 22 February 2016 (UTC)
Yeah, it can be a pain, but that's the other way to do it. You might be able to fake an old signature; I don't know the specifics of how the archive bots work, so I'm not sure that that will work. --Izno (talk) 18:02, 22 February 2016 (UTC)
Right. That's a lot of work for a thread that's years old, especially for one that has no replies, making it fairly useless. ―Mandruss☎18:07, 22 February 2016 (UTC)
Mandruss. While it would be perfect to have it in context of its date, the reality is that it isn't now, so just archive it to the last archive. It will be searchable anyway, and if it is that old, its value is probably not high. Personally, I would stick a manufactured date on it at an approximate point of time, and let the bot sort it out. The world is less than perfect. <shrug> — billinghurstsDrewth00:50, 23 February 2016 (UTC)
I enjoy a bit of talk page cleanup every now and then (my last spree before this one was at Talk:Microsoft Windows), and unsigned messages are one of my pet peeves on Wikipedia. Therefore I've archived the unsigned threads manually into their proper positions and signed them using the {{unsigned}} template. WikiBlame makes this task an awful lot easier. BTW, ClueBot III is better at dealing with threads with no signatures when it's working, as it uses the page history to determine when an edit was made. Graham8712:01, 23 February 2016 (UTC)
@Mandruss: I have User:Anomie/unsignedhelper.js installed on my vector.js file. When I come across an unsigned section, I edit that section and then click the {{unsigned}} link under the edit window. The script thinks for a while and then inserts an {{unsigned}} template. Before I click Save edit, I open the history in another window just to make sure that the script picked the correct edit. Hope this helps! GoingBatty (talk) 04:14, 24 February 2016 (UTC)
When I check my watchlist in mobile view [17], I get all changes to all categories on my watchlist, even though in my preferences I have checked "Hide categorization of pages" (this works on the standard watchlist in desktop mode). I see no way to change this for mobile explicitly, so it looks as if that preference doesn't work for mobile view, making my watchlist useless in that mode (I get changes from the last 13 minutes there on my watchlist, nothing further back!). The grouping (see only the last change to a page) doesn't work there either. Basically, I'm very glad that I do my editing from desktop and not from mobile, but I had no idea it was so bad. Am I the only one with this situation, or is this standard snafu? Fram (talk) 15:44, 22 February 2016 (UTC)
Thanks. Well, I guess it should just follow the preferences people have given, I can't see anything in "preferences - watchlist" indicating that these are only valid for the desktop and not for the mobile environment. But it certainly is an improvement. If the mobile watchlist would follow the preferences, it would also mean that it wouldn't show every change made to followed pages, but only the most recent one, which is also one of the vey useful standard options (certainly on mobile, where you can't see that many changes anyway). In general, the mobile experience for everything but reading pages is clearly vastly inferior, even for things (like these remarks above) which are not inherent to mobile and its smaller screen. But that's a general remark, not aimed at you, you are helpful so thanks! Fram (talk) 07:21, 24 February 2016 (UTC)
Magic word for section title?
Is there a magic word or template for the title of the section on a page? That is, something like {{FULLPAGENAME}} but for section titles. --Stefan2 (talk) 17:48, 18 February 2016 (UTC)
What I need is to insert the title of the current section in the output of a template. None of those methods would allow me to do this. --Stefan2 (talk) 18:21, 18 February 2016 (UTC)
Wiktionary wants this as well. I expect it will happen at some point in the next couple of years as section handling is overhauled, but as I often say, don't hold your breath. — This, that and the other (talk)06:15, 19 February 2016 (UTC)
Is there a tool for finding contributions to Wikipedia from an IPv6 range? For IPv4, I use X!'s Tools, but it doesn't seem to work for IPv6. At least, I got nothing when I input an IPv6 range, even though I knew of three contributions from that range. Unless I used the wrong format? I expressed the range the way I got it from NativeForeigner's rangefinder, which was this: 2600:1:c22b:eeae:8000::/65. Pinging MusikAnimal. Bishonen | talk14:29, 21 February 2016 (UTC).
Thanks, but not really, as Native Foreigner's tool will already calculate IPv6 ranges. I've got the range; what I need is a tool that will find the contributions from it. (I notice that the template you link to says, a ways down, that "no tools are available to show the contributions for an IPv6 range", so I guess I'm not optimistic.:-( Pinging NativeForeigner and Johnuniq.) Bishonen | talk15:15, 21 February 2016 (UTC).
I thought the contribsrange gadget supported IPv6, but I'm currently unable to get it to work. A heavy-duty off-wiki tool like xTools that supports IPv6 is much needed. Whatever your findings do try to keep WP:ADMINTOOLS updated. Best — MusikAnimaltalk15:40, 21 February 2016 (UTC)
Sorry, not that I know of. If you try {{blockcalc}} you will see that it provides contribs links for a single IPv4 or IPv6, and for IPv4 ranges, but I could not find any contribution links for a range of IPv6 addresses. I pondered what would be involved in writing a tool, but I'm unlikely to get around to it. Such a tool would need to examine every edit on the recent changes feed and build an efficient database of IPv6 ranges active in the last month. It would be do-able but tricky code would be needed. Johnuniq (talk) 23:32, 21 February 2016 (UTC)
But you're so clever, John! It would be really useful, in fact right now I have a situation, and a call to make, where it's very frustrating not to have it. Bishonen | talk01:49, 22 February 2016 (UTC).
Huh! You think I'm susceptible to flattery!? The problem is that such a tool would need to be at wmflabs which is a big unknown to me, and whereas I am comfortable at a command line, I have no idea of how or whether tools can access recent changes. If someone volunteers to hold my hand for those details, I could eventually code the rest of it. One unknown would be how many entries a database would have to hold, and how much storage/time would be used. Johnuniq (talk) 01:58, 22 February 2016 (UTC)
I have a reasonable idea how the existing ipv4 tool works but I just don't have anywhere near the time to implement it and probably won't until June-September, if this year at all. NativeForeignerTalk08:23, 22 February 2016 (UTC)
My time too is also very limited. Not only that but IPv6 is a bit iffy as different formats can mean the same IP. I do know that quentinv57's global contributions tool has full IPv6 support, after I added it, but it doesn't do ranges. So you could feed it individual IPv6's to get global contributions.—cyberpowerChat:Online14:36, 22 February 2016 (UTC)
In a template, is it possible to create and set a parameter that was not passed in through the template call? For example, in a template I am modifying/updating, there are six or seven occurrences of this: {{{show_name|}}} ({{if||{{{season_qualifier|}}}|{{{season_qualifier}}} |}}{{{season_type|season}}} {{#expr:{{{season_number|}}}+1}}). Instead of having to use all of this code over and over again, is it possible to create and set a new parameter to equal the above? i.e. {{{full_show_name}}} = [All the code above], and simply use {{{full_show_name}}}?
Or. Can I create a sub-template that I can pass all parameters to in a simple way (e.g. global parameters), and just use that to concatenate all of the above, and use it as a call to the sub-template? Alex|The|Whovian?04:37, 22 February 2016 (UTC)
@Edgars2007: Thanks for the reply. I saw on some other wiki that they have a {{#set}} parser function, but Wikipedia doesn't have that. Do you know of a way that I can pass all parameters to in a simple way (e.g. global parameters) to the sub-template instead of passing them one-by-one? Alex|The|Whovian?07:00, 22 February 2016 (UTC)
So, I need to create a whole module which will be a few lines long at most for this? That's a waste of space and time. And how does one pass all parameters into a Lua function without passing them through {{#invoke}}? Alex|The|Whovian?06:06, 23 February 2016 (UTC)
These are questions which I am unable to answer, I find the whole Lua thing a total mystery. Templates which I formerly had no problem reading, explaining, amending and maintaining, suddenly become a black hole upon conversion to Lua. I unwatch them and let somebody else pick up the fallout. --Redrose64 (talk) 20:02, 23 February 2016 (UTC)
The complicated answer: use frame:getParent().args. The simple answer: ask me, and I'll write the module for you. ;) Or if you want to do this in template code, the traditional way is to use a subtemplate and then pass all the parameters through for each use. — Mr. Stradivarius♪ talk ♪11:36, 24 February 2016 (UTC)
Creating/parameterising a template to categorise broken section anchors
Hello. I was hoping that it would be possible to create a template (or add a parameter to an existing one) that will categorise broken section anchors (i.e. here and here). If so, would it be possible for the template to be added to those redirects automatically (e.g. via a bot) or will one have to do such a task manually. Thank-you.--Neve–selbert22:29, 22 February 2016 (UTC)
You'd be wanting to modify one of the {{rcat}} templates, probably adding a flag to {{R to section}} and {{R to anchor}} which are slightly different but both affected by this. Pinging Paine Ellsworth, he does a lot of work with them. As for a bot adding them that's probably easy enough, but I'm not a coder. Ivanvector🍁 (talk) 22:33, 22 February 2016 (UTC)
Category:Pages containing links with bad anchors has a backlog of more than 4,000 entries. You probably want to populate a category similar to that one? That category contains talk pages and was used by WildBot when it was active, but I don't know how the bot's creator, Josh Parris (hasn't edited for almost a year, now), populated it. WildBot would sense the broken anchors and leave a message box near the top of the article's talk page, then categorize the talk page to the above-linked category. Don't know what happened to Josh Parris, but I hope somebody will come along and continue that important work. Good faith!Paine00:22, 23 February 2016 (UTC)
I don't know how Josh Parris and WildBot actually found the broken anchors unless they worked from a list similar to the ones to which you linked above, then categorized the talk pages to the category to which I linked. The data finder that populates those lists could also populate a category, but if there are lists, then I have to wonder why a category would also be needed? If you think there should also be a category, then you probably want to check with the editors who work on the data finders at WT:Database reports. Since I know of no template that can be placed on redirects that are known to target broken section links or anchors, your only other alternative would be to use Category:Redirects to sections and Category:Redirects to embedded anchors (which might be what a bot may use to generate a broken anchors list) to find broken anchors. Both of those categories are pretty heavily laden, so a bot would be needed that's programmed to find the broken redirects in those categories. Wish I could be of more help – perhaps someone else here can get you closer to where you want to go? Follow Jimbo!Paine17:58, 24 February 2016 (UTC)
I noticed yesterday that the large table at Wikipedia:Sockpuppet investigations can't be sorted by any of the timestamp fields (table is transcluded from here) but all of the other fields work. On investigation and help from other users, it seems it works in Chrome but not in Firefox or Safari, nobody bothered to check IE and I don't care to. Is this a bug? I can't think of any other pages which use a detailed timestamp field in order to check if this is just an issue with this table or with the browser, but I can confirm that sorting by year works elsewhere. Ivanvector🍁 (talk) 20:00, 24 February 2016 (UTC)
During the last 1-2 days I see this recurring message:Error - Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. with the Wikimedia logo to the left (sporadically like 3-4 times per day). What's strange about this: there is zero lag, and re-loading the same Wikipedia page a millisecond later works perfectly fine again. It could be a problem on my side or in my region, but does anyone else experience this sporadic message lately? (FF 44.0.2, Windows XP) GermanJoe (talk) 10:46, 24 February 2016 (UTC)
Pageview stats at http://stats.grok.se are down again. Stats have not compiled since October 11. Thus, the following is a summary the datefiles that are currently not compiled.
Complete datafiles in need of compiling
January 31, 2008
February 28, 2008
March 1, 2008
June 1–2, 2008
July 1, 2008
July 13–31, 2008
October 20, 2008
November 15, 2009
June 26, 2010
September 2, 2011
October 20, 2011
April 30, 2012
February 5, 2015
October 12, 2015
January 21–February 1, 2016
Partially complete (between 1 and 23 hourly files have data) datafiles which should be considered for compiling
March 3–4, 2008
October 21, 2008
October 14, 2009
October 16, 2009
November 22, 2009
January 23–24, 2010
February 8, 2010
June 28, 2010
July 5, 2010
July 7, 2010
July 10, 2010
July 23, 2013
January 6, 2014
August 28, 2014
dates without datafiles that can not currently be compiled
Yes, sadly stats.grok.se should no longer be seen as an active project. We released a new pageview API and there are several efforts to write a tool that will replace stats.grok.se, by querying the API. The project we're all watching right now is one by Jan Ainali's students. Here's the task in Phabricator (the wmf task tracker): https://phabricator.wikimedia.org/T120497. Once a stable tool is up, we (the analytics team) will be helping to maintain that. We can be reached most easily on Phabricator with the tag "Analytics". Milimetric (talk) 22:39, 10 February 2016 (UTC)
Well, how do we use what you have linked? Can you give us instructions, please? Once upon a time we had as an alternative the wonderful Wikiviewstats. Although it's still listed at Labs, it has not been enabled for a long time. — Maile (talk) 13:46, 3 February 2016 (UTC)
@Maile66: For example, here [18] is a printout of User:Maile66 page views between January 2, 2016 and February 2, 2016. Just enter the article name into the URL along with the dates you want to view. Like I noted, it is clunky to use! Woodlot (talk) 21:42, 3 February 2016 (UTC)
@Makeandtoss: Oh, right, that tool. I don't recommend using it, though I know a lot of people do. There's some work being done to build the information into the ?action=info page, but that's not done yet, which isn't very helpful, I know. Sorry. Jdforrester (WMF) (talk) 02:52, 1 February 2016 (UTC)
Looking at the "about" page on that tool's site, it says "They should be directed at User:Henrik on Wikipedia." regarding questions or comments. The page also carries the disclaimer "This is very much a beta service and may disappear or change at any time." That mention should notify him of this thread, but I think it's fair to say that he's under no obligation to fix it quickly (looks like an unofficial personal experiment to me, with even less warranty than the rest of Wikipedia). Murph9000 (talk) 03:02, 1 February 2016 (UTC)
User Henrik hasn't opened Wikipedia in years... Well dammit, it coincides with my DYK. Why not make this tool official? Its used by alottt of people. --Makeandtoss (talk) 03:06, 1 February 2016 (UTC)
The new API is official. And as James stated, a very simple version of it will soon be added to the "Page information" list. There are also several groups looking into making a new 'stats.grok.se'-like official tool using this new official API. stats.grok.se will likely disappear however at some point. —TheDJ (talk • contribs) 09:58, 1 February 2016 (UTC)
Well, I think there is a real problem with the stats... Completely out of order and we don't know why. Rather bad, unfortunately, for Wikipedia.86.73.64.12 (talk) 10:21, 2 February 2016 (UTC)
Let me add my two cents to the page view statistics being inoperative. This is one of the tools that we, major contributors but non-technical wikipedians. like and use. It would be a shame if we didn't have access to page view data. Please get it functioning again. I have no idea what an API is. I just want something that works. Smallchief (talk02:20, 3 February 2016 (UTC)
I know this is frustrating, this is precisely why we built the API. I know people don't care what an API is, but I'll expand a little. So, the reason stats.grok.se is hard to maintain and probably the main reason Henrik stopped doing it is that we have a ton of data that he has to crunch to get these stats. So, the API gives everyone access to that pre-crunched data. So instead of a huge server parsing through billions of lines of text, now you can use a browser on a mobile phone to get the stats you need. The problem right now is that nobody has built a nice website like stats.grok.se to take advantage of this new client. But it's a very simple project and I personally promise all of you that if it's not built by the end of this quarter I will build it myself. I'm "milimetric" on irc, I hang out in #wikimedia-analytics. I work on the Analytics team which works on Phabricator, and this is the work we do: https://phabricator.wikimedia.org/tag/analytics/. If you'd like to see an example website that uses the API, you can take a look at this demo that someone else cooked up quickly: https://tools.wmflabs.org/pageviews. They say they'll be maintaining that but I wouldn't treat it as a permanent link. We'll announce the one tool that survives this early stage and gets maintained going forward. Please let me know where that announcement should go so it reaches everyone who's interested. Milimetric (talk) 22:51, 10 February 2016 (UTC)
Article traffic statistics
I don't seem to be able to read article traffic statistics for any date past 2016-01-20. Is there a problem or should I wait a few more days to see the article traffic statistics for 2016-01-28 for Birdsill Holly (day of DYK)?--Doug Coldwell (talk) 12:05, 29 January 2016 (UTC)
Hi Doug Coldwell. I don't know where I saw it but I saw mention that the traffic stats database has not been updated for a while and that last week is one of the weeks that is taking a hit. Cheers! {{u|Checkingfax}} {Talk}12:30, 29 January 2016 (UTC)
Just out of curiosity, what counts as a page-view for these stats’ purposes? Specifically, when Navigation Popups or any similar tools grab a preview, does that count as a hit, or are there means of access that aren’t monitored for counting purposes? Also, is there a time limit within which repeated loading of a page is counted as a single viewing, or is every request for the URL registered as a distinct hit? Finally, is access to a past revision or diff counted?—Odysseus147902:52, 24 February 2016 (UTC)
Page view stats - somebody please fix this!
This is the third thread on this page about the fact that "page view stats" (one of the installed links on the "view history" page) has not worked for more than two weeks. The WMF attitude seems to be summed up by User:Jdforrester (WMF): "Oh, right, that tool. I don't recommend using it." He goes on to say we should be using some other tool that none of us have ever heard of, much less have a convenient link to. The attitude of the rest of is well summed up by User:Smallchief: "This is one of the tools that we, major contributors but non-technical wikipedians. like and use. It would be a shame if we didn't have access to page view data. Please get it functioning again. I have no idea what an API is. I just want something that works."
Look, folks. This is a tool that many of us use every day. Don't blow it off. Don't blow US off. Either fix the existing system, or replace that link with one that works. We are your volunteers, the creators of content without whom Wikipedia would not exist. All we ask is a system that works. To just ignore a major glitch like this for two weeks is not acceptable. --MelanieN (talk) 21:56, 4 February 2016 (UTC)
@Cyberpower678 and MusikAnimal: What would it take for Labs to re-enable Wikistats on XTools and become a routine part of the Revision Stats? It's such a wonderful tool, that I don't understand why it was more-or-less deactivated on Labs. — Maile (talk) 22:06, 4 February 2016 (UTC)
It's my understanding there will soon be a new and far more accurate WMF-provided pageviews API. Currently the pageview stats show only desktop hits, not mobile, which probably accounts for most traffic. There's a demo here, which appears to be working. Xtools wikistats is unlikely to return to service — MusikAnimaltalk22:23, 4 February 2016 (UTC)
I failed to read everything above... I guess the new API and demo is no secret. Why are we complaining about stats.grok.se, then? I would not trust it over the WMF API — MusikAnimaltalk22:28, 4 February 2016 (UTC)
Because the earlier complaints and requests were getting blown off and ignored. That's why. User:MusikAnimal, the reason we are "complaining about stats.grok.se" is because it is the default. It is the button that Wikipedia gives us called "page view stats". If they want us to use something else, replace that link with the one we are supposed to use. --MelanieN (talk) 22:36, 4 February 2016 (UTC)
@MelanieN: Hey there. I'm a bit confused when you say "Either fix the existing system, or replace that link with one that works.". There are no official links from Wikipedia to stats.grok.se; any and all such links that you may find have been added by well-meaning volunteers like yourself. The "existing system" is fixed, covers both desktop and mobile views, and is very solid (about as reliable as the site itself; maybe four–five-nines). Jdforrester (WMF) (talk) 22:35, 4 February 2016 (UTC)
At last check we were not certain what was causing the problem. That tool was written by a dewiki user on his own, and then left the project, without educating the remaining users on how to maintain it. Also I am no longer a major contributor to xTools. As such I am not going to be of much help.—cyberpowerChat:Online 5:42 pm, Today (UTC−5)
@Jdforrester (WMF): How the average user accesses page views is article Page/History/Page View Statistics. That all the average editor knows how to access and read the stats. What we want changed, is for somebody to link the new tool to Page View Statistics. Any tool. We don't care. Just link one that works all the time, please. — Maile (talk) 22:47, 4 February 2016 (UTC)
(ec)What Maile said. This is what my "view history" page looks like: [22] See those links at the top? The one at the far right is called "page view statistics". From what you say, I guess it links to stats.grok.se. That's the link that is used by the 99.99% of us users that are not technical and do not follow the techie pages to keep up on all the latest innovations. If you have a better system, one which "is fixed, covers both desktop and mobile views, and is very solid", great! Then make it the link for us to use. Don't expect us, one by one, to have to find out about it and figure out how to use it. --MelanieN (talk) 22:49, 4 February 2016 (UTC)
Yes, that is set by MediaWiki:Histlegend, which we can change. There's just nothing to change it to you... yet. My guess is someone needs to write a tool using the new API. I could do it, but I use Ruby, and if I leave the project there won't be many other Ruby devs to takeover. Let's defer to someone who writes Python or PHP — MusikAnimaltalk22:51, 4 February 2016 (UTC)
P.S. And thanks, MusikAnimal and cyberpower, for all you do to try to maintain these things. I know it isn't easy. If I am yelling at anyone here, it isn't at you two; you do heroic work. I guess I am yelling about the lack of any help, or even concern, we are getting from the WMF about this. --MelanieN (talk) 22:57, 4 February 2016 (UTC)
The link above is to a forum post announcing the API. How would a not-technically-proficient user such as myself create a URL to produce page view stats for a given page using that API? For example, Module:PageLinks can currently be called to produce a link to stats.grok.se for a given page, and that module is in turn called by several templates on enwiki (e.g. {{rfd2}}). Is there something equivalent for the new API? Or are we just at this point waiting for someone to create one? Ivanvector🍁 (talk) 22:59, 4 February 2016 (UTC)
Yes, I think we need someone to create it for us using the new API. I will see to it that this gets done, since I know all the techy people to ask. If no one does it I'll give it my best shot :) — MusikAnimaltalk23:00, 4 February 2016 (UTC)
Oh, Lawdy Miss Clawdy, somebody who understands exactly what we are saying (MelanieN, you and I are seeing it the same). It's not by user, but the link for Page View Statistics that appears on each page history. Yes, yes, yes. Please someone make the necessary techno version of abracadabra-alakazam, so even first-time editors can just click on it and get the stats. — Maile (talk) 23:02, 4 February 2016 (UTC)
I can make something very simple, but can't promise something as full featured as the demo they've created. If only they supported deeplinking! Seems like it'd be better to take their source and work off of that — MusikAnimaltalk23:08, 4 February 2016 (UTC)
@Maile66 and MelanieN: Yes, I'm aware that some of the volunteers on this wiki have hacked in a line of links to unsupported tools as "External tools". I personally think it's pretty disrespectful to link to things we know often don't work in such a prominent way, which leads to the entirely-reasonable belief by many that they are "official" even though they aren't, but every time I point this out I get shouted down because people like them too much. :-( As I mentioned above, the Community Tech team are working to provide this information on-wiki in ?action=info; see m:Community Tech/Pageview stats tool for some details from them. On reflection, adding hacky things that don't quite work but do so well enough to reduce the demand for a real replacement might be considered a poor approach in future; really, WMF should have built a page view tool years ago. I can appreciate that you are frustrated that this hasn't yet been built, but please don't feel that you're not getting any help just because some volunteers haven't fixed things; they do awesome work, and it's no reflection on them that WMF hasn't yet managed to finish this work despite embarking on it five years ago. Jdforrester (WMF) (talk) 23:13, 4 February 2016 (UTC)
@Jdforrester (WMF) and MelanieN: Hacked in? I don't know about that. Henrik, who ran stats.grok has been around for a decade, and his stats tool has been the linked tool since I've been around, which is 9 years. That long ago, he was probably approved to do it. — Maile (talk) 23:17, 4 February 2016 (UTC)
@Jdforrester (WMF): I think it's pretty disrespectful of you to characterize the community's creation of tools to fill in functionality gaps left by what the Foundation fails to develop as "hacked in" and "unsupported", as much as that may be the case, in particular in your Foundation-associated capacity. A volunteer developed this to provide a vital tool, and it worked perfectly well enough for many years such that its vital function became an integral part of this wiki. I think we all know full well that if the volunteer who developed it is not around now then there's not anything any of us can do to fix it, and the Foundation's own replacement is not ready to go, so we're stuck without a stats tool for the indefinite future, until a different volunteer develops a replacement tool. But your characterization of the tool and the links to it as some sort of illicit plot is frankly insulting. Ivanvector🍁 (talk) 03:01, 5 February 2016 (UTC)
As a side note, hack doesn't mean bad. On the other hand, unsupported by the WMF does mean things like "run entirely by a private individual on his own website, which he is free to ignore or even turn off without even telling anyone in advance".
I think that reasonable people can honor what this volunteer provided for years, while still wondering whether it is wise for this community to continue to depend upon the good will, finances, and continued existence of a single individual's private website for what you call a "vital tool". I'm glad that we're moving away from that. Perhaps we should do the same with the link to WikiBlame, which is in the same histlegend text, and also goes to someone's personal website. WhatamIdoing (talk) 07:59, 13 February 2016 (UTC)
We seem to be going around in circles. Let's simplify this dialog. First, go to any one of 5 million Wikipedia articles in English. Second, click "View History" at the top right of the page. Third, when the history page shows up click: "Page view statistics." Fourth, a graph will appear that shows the number of number of views per day that page has had for last 30 days -- or for any period which you wish to see.
That is the tool that quit working about January 20, 2016. We, or at least some of us, would like to see it restored -- or replaced with another tool that will tell us the number of views of that page on a given day or other period of time.
What is the answer? Will this long-functioning, easily-accessible, and comprehensible tool be restored? What is the problem with keeping it functional until such time as a better system, if needed, can be developed? Smallchief (talk00:42, 5 February 2016 (UTC)
The exact tool that has been used for so long? Unlikely, at best. And we honestly have no idea how it's still functioning, since the user who runs it is inactive. No-one else is publicly maintaining it, so we don't know who to bug. You can try User talk:Henrik, but it looks like at least one user has already attempted contact with him.
The official API provided by Wikimedia linked above provides the same raw data (you can get the raw data by looking at the documentation page, which includes some GUIs to play with). A tool providing "graphs" as with Henrik's tool is in development. --Izno (talk) 02:20, 5 February 2016 (UTC)
Well.. In fact, no news... Stats completely out of order. Without any explanation. Do you know a Wikipedia administrator ? No ! There is no Wikipedia administrator ! So, I think it's rather disturbing. Maybe, next day, Wikipedia out of order. Without any explanation...86.73.64.12 (talk) 07:39, 5 February 2016 (UTC)
I have forked the demo at toollabs:musikanimal/pageviews with support for deep linking. This means we can replace the "page view statistics" link on revision history pages (specified by MediaWiki:Histlegend). The data is accurate, but there are some interface bugs which I should have fixed very soon. This will hold us over until the official WMF tool is deployed, which I believe isn't too far off — MusikAnimaltalk08:14, 5 February 2016 (UTC)
Up and running. If you add pages, change date range, etc, the URL will be updated with the new params so that you will have a unique URL to what you are seeing. However hitting the browser "Back" button won't do what you think it does, but I don't think anyone cares about that. Basically just let me know if you have any issues. Best — MusikAnimaltalk16:01, 5 February 2016 (UTC)
That seems to be a most helpful response from somebody who is doing something about fixing the problem. Thank you.
As an explanation for my interest, if you look at my user page, you will see that I follow page views for the pages I have created. I'm curious about what subjects attract the most attention -- and what attracts the least, plus the trends if any. For my personal interests, I much value having consumer-friendly access to page view statistics. Plus, there is statistical gold in wikipedia page view stats that may be useful to social scientists for the next X thousand years -- so I hope Wikipedia gets this problem fixed. Smallchief (talk16:21, 5 February 2016 (UTC)
THANK YOU, THANK YOU, User:MusikAnimal, for honchoing this and for "tweaking" the result. The code is also credited to a user named marcelrf, but I can't find them to thank, so please give them all of our gratitude as well. I wonder what it says, that WMF can't get this done in five years, and it takes you volunteers one day? :( Oh, and the reason for my current interest: It turns out that my latest DYK was my most-viewed ever and is one for the record books. This kind of feedback is very rewarding to us volunteers. --MelanieN (talk) 21:24, 5 February 2016 (UTC)
@MelanieN and Maile66: Absolutely, thank you to MusikAnimal for taking this on, and to Mforns (WMF) ("marcelrf") for the original code. BTW, you should not compare numbers from this tool (which are as accurate as the Analytics Engineering team know how to make them) to the numbers taken from stats.grok.se (which are less accurate for a variety of reasons, and most notably miss many mobile page views); they're not really measuring the same thing, sadly. Jdforrester (WMF) (talk) 20:56, 8 February 2016 (UTC)
No, they're not, and for most purposes they will be very different - orders of magnitude in some cases. But in the specific case of WP:DYK views - that is, page views on the day the DYK runs - the difference doesn't seem to be as great as first expected. Some testing suggests that the DYK-day views differ by only 5–10% between the old and the new systems. I'm told that DYK does not show up on the mobile view of Wikipedia, and this could explain why the difference in DYK page views is not huge. This is of interest to editors who put their new articles up for DYK; we get our jollies if lots of people look at our article because of the DYK, and records are kept of the most "successful" DYKs. We'll see if the DYK folks decide to modify their criteria; they'll probably decide when they see the February results. --MelanieN (talk) 22:38, 8 February 2016 (UTC)
{{Graph:PageViews}} would show this for the current page. You can insert this template into any talk page (it automatically shows last 30 days), and on any wiki (if you copy it there, no dependencies). You could also specify number of days, page name, and another wiki as 3 parameters, e.g. {{Graph:PageViews|90|Main Page}}.
Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.
,
Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.
@Yurik: This is awesome! Though I'm not sure about the name. The Graph: prefix is misleading as it implies it is in the "Graph" namespace, which does not exist. How about Graph-PageViews (replace with dash)? — MusikAnimaltalk23:55, 19 February 2016 (UTC)
@MusikAnimal: thanks, naming is hard. I would like for all graph templates to have a well known/identifiable suffix. At this point there has been a number of templates like template:Graph:Chart that follow this convention. But you are right, the colon there is misleading. Dash is another option. I'm open for suggestions, and could even rename them, not that hard. --Yurik (talk) 14:07, 20 February 2016 (UTC)
Oddity when pages added to watchlist on editing
I have the "Watch this page" box ticked when I edit a page. Today I have noticed that when I edit a page not already on my watchlist, the "watch" tag at the top of the page does not change to "unwatch" after I save the edit. When I go to "my watchlist" the page has been added, and if I navigate back to the page, then the tag says "unwatch". Is this a bug? DuncanHill (talk) 11:55, 25 February 2016 (UTC)
See the EXIF data at File:Hiramkennedycenterfront.jpg — because the camera name includes < and > characters, the normal {{R from EXIF}} link is broken. Is there any way to fix this onwiki (presumably at Commons, but I suppose also here), or is this something we need to send to Phabricator? Nyttend (talk) 14:10, 25 February 2016 (UTC)
https://commons.wikimedia.org/wiki/File:Hiramkennedycenterfront.jpg?uselang=qqx says (exif-model-value: <KENOX S730 / Samsung S730>, ), so the text is made by commons:MediaWiki:Exif-model-value. The MediaWiki default is just $1 which doesn't attempt to make a link so it's not a Phabricator issue. Commons has changed the default to {{Exif-model-value|$1}}. This uses commons:Template:Exif-model-value so that would be the place to potentially make some string processing to deal with characters that are not allowed in page names, for example removing them. If it's a rare issue (don't know) then I'm not sure it's worth using resources on string functions every time a file page is displayed. Our own Template:Exif-model-value is used by locally uploaded images. It doesn't handle disallowed characters either. PrimeHunter (talk) 17:29, 25 February 2016 (UTC)
Among experienced editors, the visual editor's table editing is one of the most popular features. If you select the top of a column or the end of a row, you can quickly insert and remove columns and rows.
Now, you can also rearrange columns and rows. Click "Move before" or "Move after" to swap the column or row with its neighbor.
You can read and help translate the user guide, which has more information about how to use the visual editor.
Since the last newsletter, the VisualEditor Team has fixed many bugs. Their workboard is available in Phabricator. Their current priorities are improving support for Japanese, Korean, Arabic, Indic, and Han scripts, and improving the single edit tab interface.
Recent changes
You can switch from the wikitext editor to the visual editor after you start editing. This function is available to nearly all editors at most wikis except the Wiktionaries and Wikisources.
Many local feedback pages for the visual editor have been redirected to mw:VisualEditor/Feedback.
You can now re-arrange columns and rows in tables, as well as copying a row, column or any other selection of cells and pasting it in a new location.
The formula editor has two options: you can choose "Quick edit" to see and change only the LaTeX code, or "Edit" to use the full tool. The full tool offers immediate preview and an extensive list of symbols.
Future changes
The single edit tab project will combine the "Edit" and "Edit source" tabs into a single "Edit" tab. This is similar to the system already used on the mobile website. (T102398) Initially, the "Edit" tab will open whichever editing environment you used last time. Your last editing choice will be stored as an account preference for logged-in editors, and as a cookie for logged-out users. Logged-in editors will have these options in the Editing tab of Special:Preferences:
Remember my last editor,
Always give me the visual editor if possible,
Always give me the source editor, and
Show me both editor tabs. (This is the state for people using the visual editor now.)
The visual editor uses the same search engine as Special:Search to find links and files. This search will get better at detecting typos and spelling mistakes soon. These improvements to search will appear in the visual editor as well.
Please try out the newest version of the single edit tab on test2.wikipedia.org. You may need to restore the default preferences (at the bottom of test2wiki:Special:Preferences) to see the initial prompt for options. Were you able to find a preference setting that will work for your own editing? Did you see the large preferences dialog box when you started editing an article there?
Can you read and type in Korean, Arabic, Japanese, Indic, or Han scripts? Language engineer David Chan needs help from people who often type in these languages. Please see the instructions at mw:VisualEditor/IME Testing#What to test if you can help. Report your results on wiki (Korean – Japanese – all languages).
If you aren't reading this in your favorite language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thanks!
@.js: I think it's pretty safe to assume that Henrik won't be back any time soon, so I would just remove those sections. There's no real need to archive them, as you can just look at Wikipedia:Wikipedia Signpost/Archives. There's nothing in the settings for lowercase sigmabot III that might let you archive specific threads immediately, but the bot is still working, so if you don't want to remove the sections you can just do nothing they will all be archived eventually. Alternatively, if you really want to archive all of the Signpost threads right now, you can always do it manually with copy and paste. — Mr. Stradivarius♪ talk ♪12:43, 24 February 2016 (UTC)
@Redrose64: I only referred to User talk:Misza13 stating "Please do not post here regarding archiving bots." and User talk:Σ stating "I cannot help with issues about archiving your own talk page."
@Mr. Stradivarius: thank you for helping! My thoughts were to clear the page of the Signposts and then stop the bot from further archiving it, so that more people looking for stats.grok.se infos see them more easily. Would that be according to the en:wp user talk page guidelines and what do you think about that idea? --.jsWP: [democracyneeded]08:15, 25 February 2016 (UTC)
Yes I would also usually never touch another's talkpage like that, thanks for your support. I already tried to contact Henrik via nail and other people at sv:wp, no response. Still I think I rather wait two or three more days if anyone opposes here or there and then do as above. --.jsWP: [democracyneeded]20:10, 25 February 2016 (UTC)
How do I override a template that automatically italicizes the article title?
{{DISPLAYTITLE}} appears to be intentionally overridden. Specially I'm trying to force Fireside chats to not be italicised, as "fireside chats" wasn't the official name of the broadcasts.--Prisencolin (talk) 23:17, 25 February 2016 (UTC)
Place {{DISPLAYTITLE:Fireside chats|noerror}} after the infobox?
How do I type 1/2 so it looks like a fraction instead of "1 or 2"? I'm sure it used to be available in the "symbols" underneath the edit field, but it appears to have disappeared. DuncanHill (talk) 11:40, 25 February 2016 (UTC)
I do, but the chance of me remembering all the ALT codes for fractions I'm likely to need is significantly lower than the chance (not itself high) that I'll remember about the frac template! DuncanHill (talk) 14:19, 25 February 2016 (UTC)
I made up {{half}} which gives 1/2, but in the past it gave "½" but which does not comply with MOS. I coould not remember that frac template either (or sfrac). Graeme Bartlett (talk) 13:00, 25 February 2016 (UTC)
Yes, my problem is it is too hard to remember so many templates. It is easier if they have a very obvious name. We also have to consider whether the output is useful, ie will search engines find it and summarise correctly, will copy and paste work, will screen readers be able to pronounce the output. Anyway the MOS should have considered that. Graeme Bartlett (talk) 03:16, 26 February 2016 (UTC)
Policy short-cut template issues?
I'm not familiar at all with templates except in basic usage so perhaps I'm missing something. However, something looks a little weird with {{policy shortcut}}. I was here and clicked on WP:LOWERCASE, and it took me to here, not sure why it has a redirect=no in there. Is this expected behaviour? What is also weird, and this may be desired behaviour, but I went to the page for the policy shortcut template, and when I clicked 'Talk', it took me to the talk page for the Shortcut template. Anyway, I thought I'd ask here. I don't think it's a browser issue, but I'm running Firefox 44.0 on Ubuntu 64-bit, from distro packages with no unusual add-ons. Thanks in advance! Chrisw80 (talk) 00:36, 26 February 2016 (UTC)
What is going on with the Wikipedia email function? I have not made any change in my email address or anything else, and although I used it successfully in mid January, it now is suddenly not delivering mail, incoming or outgoing. Is this being handled somewhere? Tvoz/talk20:38, 23 February 2016 (UTC)
Tvoz, I've sent you a test message just now. I received the "Email me a copy of my message" one, so at least that much is working. Please let us know if you get it. Whatamidoing (WMF) (talk) 04:21, 24 February 2016 (UTC)
OK - yes I got it. Thanks. But I just sent you one back via the email system (not as a reply to yours) and I did not get the "email me a copy" one, although it is checked off. Did my message get to you? Tvoz/talk05:09, 24 February 2016 (UTC)
Now I got a notification that my email address was no longer confirmed - although it was confirmed when I checked a few hours ago - so I reconfirmed it. Will see if it all works now. Anyone know what's going on? Tvoz/talk06:13, 24 February 2016 (UTC)
Further info: I have re-confirmed my email, but when I do it I get a notification here that reads:"Your registered email address xxxxxx@xxxxx.xxx has been unsubscribed due to multiple message delivery failures. You can verify your email address again." So I am back to square one - I tried testing it by sending email to myself and this was the result. Hope someone can figure this out.Tvoz/talk06:28, 24 February 2016 (UTC)
And now the "email this user" has disappeared from my user page, since the system unsubscribed me - the problem is getting worse. Tvoz/talk06:44, 24 February 2016 (UTC)
I received an Echo notification that you sent an e-mail message to User:WhatamIdoing, but no e-mail message. I don't suppose that you have a Yahoo! e-mail address? (I do, on my real account; staff e-mail is processed through Gmail.) There were some problems with that a while ago. Also, you might look at phab:T123068 and see how much of that sounds familiar. Whatamidoing (WMF) (talk) 06:59, 24 February 2016 (UTC)
Yes, this is tied to a yahoo account - but it has been working perfectly since 2007, including a month ago when I used the email link incoming and outgoing with no problem. I'll take a look at that page and get back to you. Thanks Tvoz/talk04:48, 25 February 2016 (UTC)
OK - I changed it to a different non-yahoo account and it seems to be working when I send to myself, but if someone could send me a test I'd appreciate it. Thanks for all the help - that seemed to be the problem. Tvoz/talk08:04, 25 February 2016 (UTC)
The main subject is how to extract accurate, automated bibliographic citations from websites. This talk is mostly about Zotero, which is a free and open-source citation management tool. Zotero is used on the Wikipedias through the automagic citoid service. Citoid is currently an option in the visual editor and will (eventually) be used for automated citations in the wikitext editor at some Wikipedias. Zotero is also used by many academics and researchers, and most of the information presented will be useful to people outside of Wikipedia as well.
Searching for articles is getting a much needed boost in intelligence. When searching for an article on any Wikimedia project, a list of possible matches appear as you type. This incremental search 'completion suggester' helps narrow down possible results for your search query. Currently the completion suggester is very literal - mistype a word and you won't see any suggestions. The Discovery team has an update that will make the search better at detecting typos and spelling mistakes. The list of suggestions is also tends to be more accurate and relevant to the original search query. You can see the improvement for yourself at a beta feature. The plan is to begin rolling out this update in the coming month.
This improvement will impact all Wikimedia sites (with the exception of Wikidata). With the initial rollout, there will be a few limitations. For technical reasons, the completion suggester will only affect articles in the mainspace, not other pages like policy or user pages. Those searches will continue to use the existing incremental search. We're hoping to expand the scope of the completion suggester to include other pages in the future, but this will not be a part of the initial release.
Why are we making this change? The success of our A/B tests on the completion suggester show a reduction in users who find zero results when searching. We also have a fairly large number of Wikimedians (nearly 19,000 editors since December 2015) using the beta feature, and we've received positive feedback on the feature so far. The completion suggester has the potential of lessening the need for redirects based on spelling mistakes as well.
The goal is to bring these updates to the default search across all Wikimedia projects in the coming month. This change will affect the completion suggester in the main search box on desktop, mobile apps, adding links in VisualEditor, and the search box on the Wikimedia Portal.
Here are two animations showing the completion suggester before and after (using a misspelling of "Abendessen", with a missing "s").
Since December 2015, nearly 19,000 editors have already opted into the completion suggester beta feature. We encourage you to try it out and share your feedback on the Completion Suggester discussion page.
There was an issue in that timeframe where categories were not being populated correctly. An insource:/\{\{db-/ search will probably find them, which also appears to identify some pages which need updating in the search engine (likely for the same reason). --Izno (talk) 14:05, 26 February 2016 (UTC)
Not browser specific, IE and Firefox show the same word - maintenance - in the upper left of all articles and talk pages alike. Special Pages don't seem to have it. It's been showing for several days 24/7, and the phenomenon has occurred previously, quite some time ago. I can't remember if I asked about it then. But why is that word there as a constant without going away? — Maile (talk) 00:32, 25 February 2016 (UTC)
There is apparently an ongoing issue happening repeatedly to users trying to add new sections to different talk pages, and the software adding the section to Undefined instead. As a precautionary measure I've protected the page so that only admins can edit it until this issue is resolved. — Coffee // have a cup // beans // 08:47, 27 February 2016 (UTC)
Has anybody filed a phab: ticket? If not, there's nothing we can do from this side, since it's the MediaWiki software itself, over which we have no control. --Redrose64 (talk) 12:05, 27 February 2016 (UTC)
In this discussion@BillKenny14: aka Smooth Sailing states that they did not get any notifications, despite three pings by me in the discussion and 23 messages on their talk page. How can we figure out what is wrong? We have a relatively new editor, who is trying to add some decent content, but is understandably unhappy because it appears contributions are being deleted without notice.--S Philbrick(Talk)02:49, 27 February 2016 (UTC)
@Sphilbrick: Notifications can be a bit finicky. You need to make sure that (1) the edit includes a link to the userpage, e.g. using {{ping}} (2) the edit must be signed with ~~~~ (3) the edit needs to look like an addition to the page, not an edit to existing content. (1) to (3) must be in a single edit. (3) would probably be why this edit[23] wouldn't have generated a ping. Further details at mw:Manual:Echo#Technical_details - Evad37[talk]05:59, 27 February 2016 (UTC)
I knew about items one and two. Those bit me in the past, as I sometimes miss typed the username and the pain and found that if I simply corrected it, the ping would not go through. However, I think I’ve corrected my behavior for those two items. Three is new to me; I didn’t know about that. The editor followed up in an email to me that the failure isn’t 100%. Sometimes the red doesn’t show up but if the editor clicks on the symbol, there is a notification. However, the edits to the talk page don’t seem to be going through is a notification. I will ask the editor @BillKenny14: to pay attention going forward and to follow up here if clear examples can be identified which are failures. Thanks for your comments. --S Philbrick(Talk)13:58, 27 February 2016 (UTC)
I know there are (at least) two ways to link to an old version of an article (or page):
[https://en.wikipedia.org/w/index.php?title=Assassination_of_John_F._Kennedy&direction=prev&oldid=706174807 This is a URL link]
and
[[Special:Permalink/706174807|This is a permalink]]
I've been experimenting in my sandbox, and I've found that the URL method always works, but the Permalink method frequently malfunctions, bringing up the wrong previous version or the current version. I've tried it many many times using two different browsers (albeit using the same tablet) and always with the same result. I'm wondering if this is a known Wikipedia bug, or if it's more likely a problem at my end. Richard27182 (talk) 11:47, 23 February 2016 (UTC)
Hi MER-C and PrimeHunter. Thanks to both of you for replying. I think I understand it now. Having that "direction=prev" in the URL link means use the version previous to the one whose number is specified. That's why, even though the URL and the Permalink specified the same version number, they did not return the same version; the one the URL link brings up is the one before the one specified by number. Using the URL without "direction=prev" will bring up the actual version specified. (I hope I got that right.) Richard27182 (talk) 14:09, 23 February 2016 (UTC)
When I use the regex + or \s+ to remove trailing whitespace from articles, sometimes it removes spaces from a few other places, resulting in weird things like {{Usemdydates|date=March2015}}. I'm not sure what's the cause of this problem. nyuszika7h (talk) 19:30, 26 February 2016 (UTC)
@Nyuszika7H: It sounds like you need to "anchor" your regex to the end of the string with $, e.g. with \s*$. What regex tool are you using to do this? The exact details will vary depending on the regex flavour that the tool uses. — Mr. Stradivarius♪ talk ♪04:22, 28 February 2016 (UTC)
@Mr. Stradivarius: Sorry, I meant \s+$, that's what I'm using. I'm using the search and replace tool on the enhanced editing toolbar. It doesn't remove all spaces in the middle of lines, just the first few at the beginning of the text. And I want to remove just one trailing space at the end too. nyuszika7h (talk) 09:38, 28 February 2016 (UTC)
Tracking articlespace pages moved from non-articlespace
Hi! Is there a way to get some kind of overview of pages that have been moved from, say, userspace to articlespace? I came across this user, who tends to create pages in userspace and then moves them later on to articlespace, essentially creating a new page. Those pages are usually desperately in need of curation, but they do not appear in Special:NewPages and so could remain undetected for a long time. While this particular user appears to act in good faith, others could exploit this unguarded backdoor for adding things like adverts and POV-pushing. - HyperGaruda (talk) 09:36, 28 February 2016 (UTC)
Correction, almost perfect; moves by old editors are not included. I think Graham87's suggestion is usable, in combination with filters set for redirects from userspace, considering that these redirects are usually the result of page moves. - HyperGaruda (talk) 12:21, 28 February 2016 (UTC)
Odd... That particular filter combination is not recognised, i.e. the "set filter" button stays grayed out. I guess the de-userfying option is as good as it gets at the moment. - HyperGaruda (talk) 12:31, 28 February 2016 (UTC)
Meet up banner lag?
Sorry, wasn't sure where to post this. My watchlist is still showing a reminder banner at the top for the Liverpool meetup, for 27 February i.e yesterday (even in USA!) Is there some kind of time zone problem here? I thought these banners automatically deleted after they had expired. Martinevans123 (talk) 10:57, 28 February 2016 (UTC)
It's still there because the expiry date of the notice is 13 March 2016, which is the date of London 103. I've now taken out the Liverpool information (plus some expired notices) - for Sunday meetups I normally do this on the Monday; for Saturday meetups I do it on the Sunday (today). For midweek meetups I often forget... --Redrose64 (talk) 13:31, 28 February 2016 (UTC)
Thanks. Some kind of automatic function might be useful for this? It's not a big problem, as one just obviously just "hide" it if it has gone. I guess some folks might even like to be reminded they've missed a meet-up! Martinevans123 (talk) 13:34, 28 February 2016 (UTC)
It is automatic, in that the expiry date (in this case end: '13 March 2016 17:00 UTC') will cease showing the notice if it's left unattended after the last meetup mentioned has passed.
I am having issues with Template:Infobox civil conflict. In Example Alpha, if I try to add a bullet point to the last entry "C3" in the "causes" field, then the bullet points with subpoints in the "result" field will not indent as desired. In Example Beta, if I remove the bullet point to the last entry "C3" in the "causes" field, then the bullet points with subpoints in the "result" field will format correctly by indenting. I am using web browser Firefox version 44.0.2. I don't know what to do to fix this.
@Mitchumch: The problem is that the template is trimming the newlines from the end of the list, and the last list item ends up containing code added by Module:Infobox. If I feed example alpha into Special:ExpandTemplates, I get this:
The problematic parts of that are **3</td></tr><tr><th scope="row">Result</th><td> and **3</td></tr></table>. All of that HTML-like markup needs to be on a new line. My first thought is that you could fix it by adding some dummy character after the list like this:
@Mr. Stradivarius: was on the right track with the "dummy character" approach though wiki mark-up/parser/parsoid/parsley prefers a "null character" more often than not (an empty div usually "works")
The dummy character can be something as simple as   or   - the entity representing a normal space. The advantage of this is that it remains in the markup without being sanitised, tidied, or modified in any other way - until a very late stage, by which point all necessity for its presence has been eliminated; it's then cleanly removed. Even if it does somehow make it through to the rendered page, the browser treats it as regular whitespace. --Redrose64 (talk) 13:21, 28 February 2016 (UTC)
Are A, B, C an ordered series? If so, and the same is true for X, Y, Z and 1, 2, 3 then bulleted lists are not semantically appropriate. Ordered lists are preferable, although using Wikimarkup the only available style is numbered:
First cause
First sub-cause
Second sub-cause
Third sub-cause
Second cause
but you can get letters for the outer lists by mixing Wikimarkup with HTML -
@Jax 0677: I believe the bots work the list at Special:DoubleRedirects, and thus are dependent on the frequency of updating of that. Right now, it says:
"The following information is cached, and was last updated 07:53, 26 February 2016."
I want to write a regex that can puts references after (or before) punctuation ((?:(?:<ref[^<>]*\/>)|(?:<ref[^<>/]*>[\s\S]*?<\/ref>)) *(?:(?:<ref[^<>/]*>[\s\S]*?<\/ref>)*(?:<ref[^<>]*\/>)*)*)([:;,]) ․ This regex works when article contains only wrong punctuations
@ԱշոտՏՆՂ: Your problem is greedy matching somewhere, so you'd presumably need to add a question mark after an asterisk somewhere, or otherwise restrict matching two tags at once. I wrote and use this search-and-replace pair, and it seems to work well without any greediness issues: ([^\.,:;])<\s*ref(\s*[^>]*)>([^<]*)<\s*\/\s*ref\s*>([\.,:;]) and $1$4<ref$2>$3</ref> . {{Nihiltres |talk |edits}}21:19, 28 February 2016 (UTC)
@ԱշոտՏՆՂ: Yes, this should work with many refs and named refs. I use this with the WikiEditor search-and-replace feature and the "replace all" option. I can't promise it's perfect, but it seems to work pretty well and I'd love feedback if you notice it missing something or making a mistake. {{Nihiltres |talk |edits}}03:51, 29 February 2016 (UTC)
Thanks, Nihiltres! I meant refs like this: <ref>dfghe</ref><ref>wrhehrts</ref><ref name="fdd" /><ref>ergbverdasb</ref>. Maybe this will work: ((?:(?:<ref[^<>]*\/>)|(?:<ref[^<>/]*>[^>]*<\/ref>)) *(?:(?:<ref[^<>/]*>[^>]*?<\/ref>)*(?:<ref[^<>]*\/>)*)*)([:;,.]) but if reference contains ">" it will give wrong result․ Do somebody knows how to negate string in regex? (in this case we need to negate "</ref>" instead of ">")--ԱշոտՏՆՂ (talk) 10:17, 29 February 2016 (UTC)
@ԱշոտՏՆՂ: Right; mine won't recognize calls to named references (e.g. <ref name="foo" />). Heh, hasn't been a problem to date, because usually the editors who put punctuation after refs rarely use named refs. I guess supplement it with ([^\.,:;])<\s*ref\s*([^>]*)\s*\/>([\.,:;]) and $1$3<ref $2 /> , and alternate "replace alls" of each until both match nothing consecutively. {{Nihiltres |talk |edits}}15:15, 29 February 2016 (UTC)
When visiting Why Me? (Daniel Johnston Album) (which is linked to from Daniel Johnston discography#Live albums), the page one ends up at is Why Me? (album), as was intended by the redirect. But the URL — which, mercifully, nowadays is modified to point to the final destination page title instead of the redirect title — is ending up as //en.wikipedia.org/w/index.php?title=Why_Me%3F_%28album%29&_%28Daniel_Johnston_Album%29=, clearly not was intended (the red indicating stuff that shouldn't be there). I assume this a known bug, but I couldn't find anything about it. - dcljr (talk) 07:12, 29 February 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
The Capiunto extension is installed on test wiki. Capiunto provides flexible infobox functionality for Scribunto and generates HTML for infobox features such as headers and rows. It is designed for clean and modern infoboxes that are driven by data from Wikidata, easily usable across different language versions, and easily extensible.
The visual editor now follows the TemplateData format setting announced in November. When you edit or add a use of a template, the wikitext will be laid out in one of the two ways. [26][27]
The order of parameters and format defined in a template's TemplateData will be now respected. [28][29]
Changes this week
On wikis where the visual editor is available in single edit tab mode, red links may open the visual editor instead of the wikitext editor, depending on user preferences. [30]
Anonymous editor warning is now displayed as a warningbox for consistency in both the visual editor and the wikitext editor. [31]
Parsoid has been updated to fit some HTML 5 specifications. [32]
Meetings
Resigning executive director Lila Tretikov is taking questions at Knowledge Engine FAQ regarding the much talked about project. [33]
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 1 March at 20:00 (UTC). See how to join.
Maybe something is wrong with {{yesno}} because note that
{{#ifeq:{{{df|yes}}}|no|{{MONTHNAME|{{{2}}}}} {{#expr:{{{3}}}}},|{{#expr:{{{3}}}}}. {{MONTHNAME|{{{2}}}}} }} {{{1}}}. год.
is working very awesome... Only "subst:" or "lc:" should be able to get found as responisble as switch is working properly for sure, or some definitions inside "no", or I am missing something obvious...
Are definitions for various names in Lua [I need it for CS1 modules, specifically] such as 'sheet', 'Лист', 'liSt' in ['Sheet'] = {'sheet', 'лист', 'list'}, for ['Sheet'] case sensitive or not?
1. Template:Yesno#Usage says: "By default, the template returns "yes" in the first and last case but returns blank in the other cases." You apparently assume it returns no in the other cases. It returns blank by default because it becomes easy to make a test {{#if:{{yesno|...}}|code for yes|code for no}}. If you want it to return "no" then see Template:Yesno#Customizing the output. PrimeHunter (talk) 11:42, 29 February 2016 (UTC)
Thank you. For me it was really intuitive it will return no if it is no because template name is "yesno" and it returns yes for yes, but I hadn’t previously read the documentation. I’ve made modifier template {{yes/no}} that will return yes for any yes and no for any no, and in other cases works as same as {{yesno}}. Maybe it is possible to simplify it using {{yesno}} with extra options, don’t know.
Wasn’t it better to make at the very beginning template {{yesno}} returns no for any no and simply use either {{#ifeq:{{yesno|...}}|yes|code for yes|code for no}} or {{#ifeq:{{yesno|...}}|no|code for no|code for yes}} because we cannot really say "it is easier to make a test" {{#if:{{yesno|...}}|code for yes|code for no}} than one of the previous two I’ve mentioned: difference is negligible (eq and |yes or |no are only extra text, and I don’t believe "ifeq:" takes more time than "if:" to be parsed)?--Obsuser (talk) 14:23, 29 February 2016 (UTC)
{{yesno}} already has an option to specify the output for no. I wrote: If you want it to return "no" then see Template:Yesno#Customizing the output. {{yesno|X|no=no}} returns "no" if X is one of the values meaning no. Non-blank for true and blank for false is a very common and practical convention in template code. It is easier to write {{#if:{{yesno|...}}|code for yes|code for no}}, and you don't have to worry about whether a positive return from {{yesno}} says "Yes", "yes", "True", "true", "1", or whatever. There may be many template coders who are more familiar with #if than #ifeq, and the #if code is also easier to read when you know the practice. It may be confusing to have {{yesno}} and {{yes/no}} with different behaviour. PrimeHunter (talk) 19:56, 29 February 2016 (UTC)
It's far too late to change the default behaviour of {{yesno}}, there are a lot of templates out there that rely on {{yesno|no}} returning an empty string. But if you want it to return an explicit "no", it's easy - just use {{yesno| (test value) |no=no}} for example: {{yesno|no|no=no}} → no and it does the same for the empty input string: {{yesno|no=no}} → no --Redrose64 (talk) 19:58, 29 February 2016 (UTC)
I mixed up something and could not get it work using {{yesno|no|no=no}}, but now I understand. {{Yes/no}} is a redirect. Is it OK? If not, it can be nominated for speedy and deleted.
It depends on what you do with them. {'sheet', 'лист', 'list'} creates an array containing three (in themselves case-sensitive) strings; the functions that process that data may or may not operate case-sensitively. SiBr4 (talk) 23:10, 29 February 2016 (UTC)
Where can I define translated names for CS1 parameters; i.e. is it necessary to define both »URL« and »url« such as ['NotImportant'] = {'url', 'URL'},, for example, so one can use both |url= and |URL= as a parameter name in—let’s say—{{cite web}}?
Are "порука-id" and "порука-ID" both needed here if I want both of them to be in function as the CS1 template parameters?
PS I didn’t wanted to get no for empty parameter; is there a way to use {{yesno}} to have exactly this (yes for every yes, no for every no, empty for empty or any other values): Yes-no on .sr? --Obsuser (talk) 00:30, 1 March 2016 (UTC)
Oh, parameter names in templates. These are always case-sensitive, and a template needs to be specially coded to allow variants of case, which complicates them and slows them down, so we don't normally do it except in special cases. Templates like {{cite web}} do allow |URL= as an alias for |url=, but it's not case-insensitive because |Url= isn't recognised (and nor are five other variants of case). If you want to get more case variants recognised by the CS1 templates, you'll need to get your proposal past Trappist the monk (talk·contribs) who
I wish you hadn't chosen to use the cockeyed date format in the new page view graph page. Most of Wikipedia uses d-m-yyyy, or the international format yyyy-mm-dd. But the new graphs use m-d-yyyy, which is used and understood in only a minority of he English-speaking world. I hope this can still be fixed. DOwenWilliams (talk) 15:59, 29 February 2016 (UTC)
Redrose64 On the articles, stats.grok has been replaced by the Tools Pageview Analysis and shows the views as a bar graph. Henrik used the European date format on stats.grok. The Tools pageview uses American-style dates. — Maile (talk) 18:50, 29 February 2016 (UTC)
The hyphens are not the point here. That's just the way the editor above wrote it. What he is referring to is that the Pageviews display mdy, where stats.grok used dmy.— Maile (talk) 20:11, 29 February 2016 (UTC)
Pageviews Analysis checks your computer/browser settings (with navigator.language) and displays the date format that is considered the standard for that language/country. Users of IE 10 and below get the default YYYY-MM-DD. You can force it to always use YYYY-MM-DD by turning off date localization in the "Settings". — MusikAnimaltalk22:56, 29 February 2016 (UTC)
A semi-related helpful hint: if you use the yyyymmdd format when naming files that are otherwise the same name, they will list in order of date. For example, suppose you are a secretary responsible for keeping the minutes of weekly meetings. If you name the minutes for December/January like this: 2015-12-26 Minutes, 2016-01-02 Minutes, 2016-01-09 Minutes, they will list in order of date in your folder. It works for monthly meetings too. Neither of the other two date systems does that. Akld guy (talk) 14:21, 1 March 2016 (UTC)
Sure. That's a consequence of writing the dates in declining order of significance, years, then months, then days. The notation can be continued with hours, minutes and seconds. I suppose someone, somewhere, may write tines as minutes, then seconds, then hours, which would be as illogical as the mdy notation for dates. DOwenWilliams (talk) 16:23, 1 March 2016 (UTC)
Page link notifications
Whenever I recieve notifications of one page that links to one I am watching, when I try to click on the link I am watching I am redirected to the other page. What is the point in highlighting both pages when the notification only allows you to click on one of them? Simplysouth ......time, deparment skies for just 9 years12:33, 28 February 2016 (UTC)
@Simply south: All the notifications are in the process of being standardized, so that they're more consistent and less confusing. Previously, each notification had a "primary" link (clicking anywhere in the rectangle), and could optionally include additional text-links, too - these could duplicate the primary link, as well as link to secondary and tertiary (and more) items. This led to some confusion/ambiguity about which was the most important detail, and why a click that was a few pixels away led to a different page than intended; hence there is now just a single primary link, and secondary/etc links are added separately below. For page-linked notifications specifically, they used to read: $3 was {{GENDER:$2|linked}} from $4. (or for bundled notifications $3 was {{GENDER:$2|linked}} from $4 and $5 other {{PLURAL:$6|page|pages}}.). Because this notification is about a page that the recipient ("you") created, it is assumed that the recipient is familiar with that page, and will be more interested in the page that linked to it; hence the primary link is to that page, and there's a secondary link (below) that targets Special:WhatLinksHere/$2. The page names are both emphasized to make them easier to pick out of the surrounding text.
The Ashoka talk page currently has two archives titled 1. One of these appears to have been created manually while the other appears to have been created by ClueBot III. What's the best way to fix this? Other bots have an option to leave at least the last X threads on the talk page unarchived. Does Cluebot have an option for this? Thanks.--Cpt.a.haddock (talk) (please ping when replying) 13:58, 1 March 2016 (UTC)
Thanks, @Izno:! Can something also be done about the two archives titled "1" (in the search archives box)? Cluebot (or the search template) seems to be detecting both of them even though it appears that you've merged them into the one archive.--Cpt.a.haddock (talk) (please ping when replying) 17:36, 1 March 2016 (UTC)
I would suggest a deletion of the Archive1 page, possibly using WP:CSD#G6 with a custom rationale. I didn't feel comfortable doing so myself because I was unsure if you wanted the extra page around or if ClueBot would fix the inclusion on the template page (apparently not--it's probably embedded in the template logic). There's no substantial history to speak of since all of the archived content is located on the Archive 1 page and so the CSD should go right through. --Izno (talk) 17:55, 1 March 2016 (UTC)
Template:Infobox title parameter is not centered in mobile view
(reposting from Template Talk:Infobox): {{{title}}} is left-aligned, instead of centered, in mobile view: [34]. This looks like a CSS problem to me, but whatever it is, I figure someone here would be able to diagnose it and determine the best place to fix it. – Jonesey95 (talk) 04:32, 2 March 2016 (UTC)
Note for people looking at this: Many infoboxes don't use title which is outside the box but only use above which is inside the box. above is centered in mobile. See Venus (mobile view) for an example with title. PrimeHunter (talk) 13:14, 2 March 2016 (UTC)
The second Inspire Campaign has launched to encourage and support new ideas focusing on content review and curation in Wikimedia projects. Wikimedia volunteers collaboratively manage vast repositories of knowledge in our projects. What ideas do you have to manage that knowledge to make it more meaningful and accessible? We invite all Wikimedians to participate and submit ideas, so please get involved today! The campaign runs until March 28th.
All proposals are welcome - research projects, technical solutions, community organizing and outreach initiatives, or something completely new! Funding is available from the Wikimedia Foundation for projects that need financial support. Constructive, positive feedback on ideas is appreciated, and collaboration is encouraged - your skills and experience may help bring someone else’s project to life. Join us at the Inspire Campaign and help your project better represent the world’s knowledge! I JethroBT (WMF)19:55, 2 March 2016 (UTC)
"This talk page is protected, you don't have permission to add to it"
I keep getting this message when I try to add to talk pages using the mobile add discussion tab. It doesn't happen when I simply edit the same page. I'm logged in and can edit semiprotected pages, so this must be a technical issue. White Arabian FillyNeigh02:19, 2 March 2016 (UTC)
I would agree. @White Arabian Filly: Does your device show the URL when editing? If so, does that contain title=Undefined or title=undefined anywhere? If so, what is happening is that the URL you are using is trying to edit Undefined which is fully-protected. --Redrose64 (talk) 10:02, 2 March 2016 (UTC)
It does show a url if I scroll up and hide the "Editing page name" tab, but not the undefined or any other kind of parameter. This has never happened before last night and it happened on two different pages. Neither of them are protected at any level. I bet it is connected to the issue above. White Arabian FillyNeigh00:11, 3 March 2016 (UTC)
view stats
page view statistics is one of the most sought after features. it used to be external tools, and every time they break you'd hear people asking for it.
our good friends in mediawiki recently added inbuilt/API access to view statistics, that allows us to do some interesting things. User:Yurik created Template:PageViews graph that displays the page view stats. there are some interesting things that can be done using this template:
add it directly to the bottom of MediaWiki:Pageinfo-footer (instead of, or in addition to, the link that enwiki has today. you can see it in "page information" on hewiki.
i create a tiny wrapper script to display the template (using the api call "parse" with the template name) in a "popup" dialog box. see User:קיפודנחש/viewstats.js. this 20-liner add a "View statistics" item to p-caction, that pops a dialog showing the page view statistics. it's practically instantaneous.
Just please be careful with adding a graph on every page - we wouldn't want the servers to melt :). It might make sense to have a popup of some sort that would get the graph image. --Yurik (talk) 03:39, 2 March 2016 (UTC)
i do not know that it's possible to get stats for number of times people use action=info (aka "page information"), but i doubt it's that many. IMO, adding this graph to "Page information" makes sense. as to popup: please test User:קיפודנחש/viewstats.js (basically, hit F12 and in JS console type mw.loader.load('User:קיפודנחש/viewstats.js') ), and then click "View statistics" from the "More" menu on top to view how it looks. peace - קיפודנחש (aka kipod) (talk) 15:40, 2 March 2016 (UTC)
For any article, you can already view the graph by clicking 'View history', then clicking 'Page view statistics'. Why not simply move the latter link to the article itself? Akld guy (talk) 21:02, 2 March 2016 (UTC)
actually , the view statistics link is available from "Page information", which, IMO, is more logical place for it ("View history" is not really very logical place for view statistics, and the link is there for historical reasons). i did not fully understand what did you mean by "move the link to the article itself" where exactly in the article? somewhere in the left-hand-side menu? in the top menu? the footer?
the new template provides essentially the same information as the linked site (with less bells and whistles) directly, without sending the reader to another site. IMO, this is better. i do not propose removing the link from history - too many mice and people will complain loudly that someone moved their cheese. i only suggested to add the image directly to Page Information - with the new template this can be done very easily: someone with the appropriate permissions would edit MediaWiki:Pageinfo-footer, and append to the bottom
I'm obviously biased, having helped authored it, but an interactive pageviews tool is surely more useful than a static image. The template also lacks much seeked information, such as averages, ability to select a date range, and pinpoint exact days where there is a spike in order to find out why. Still not opposed to adding the template to the info page, however! It's certainly nice to see it at a glance. Note this would be temporary as we have an official extension from WMF underway. — MusikAnimaltalk21:40, 2 March 2016 (UTC)
@קיפודנחש: I suggest putting it as a new clickable option on the top line >> Article Talk.....Read Edit View history.... << somewhere on that line. Akld guy (talk) 23:48, 2 March 2016 (UTC)
@Akld guy: IMO "view statistics" is way too esoteric piece of information to warrant a place in the top menu. it can be argued that it's important enough to be in the left menu, under "Tools". i created a script that adds a "view stats" menu item to the "More" menu on top (User:קיפודנחש/viewstats.js) - see WP:JS for instructions for installing it. if you want to experiment, you can copy it to your own user space and replace the string "p-cactions", with, say, "p-tb", to add the "View statistics" menu item to the Tools menu instead (or, you can actually use "p-views" to add it to the top menu). @MusikAnimal: i don't think i suggested to discard the link to the external site - i mentioned that the graph lacks all the bells and whistles the external site has. however, both the template and the popup script are order of magnitude simpler than the external tool, and they provide the main piece of information most people want. we don't have to choose - nothing prevents us from having both. peace - קיפודנחש (aka kipod) (talk) 01:25, 3 March 2016 (UTC)
(←) No worries. And yes, adding a new tab within the top menu is very, very unlikely to happen. That area is pretty much reserved for native stuff and critical navigation. Adding anything else would require substantially broad consensus. For action=info I !vote we wait out the official tool – it's not too far off the horizon. For the popup script a gadget would be quite nice, although I doubt it would be default-enabled. WP:GP would be the place to propose — MusikAnimaltalk01:52, 3 March 2016 (UTC)
Regarding AIV notation templates
Hello everybody. I was recently perusing the WP:AIV[35] board, when I came across something peculiar. In the templates for AIV, it says that non-administrators are allowed to 'use these when applicable to comment on reports. Try to keep commentary brief and remember that, while we appreciate your opinion, it is not final, and administrators are not guaranteed to follow the same course of action as you would.' I posted a few templates, after which I was contacted by an Administrator, who told me that editors are not allowed to use AIV templates that are relating to declining AIVs, which makes sense. Could we update the AIV notation templates, or more specifically the "New to AIV? Read me" section so that it states that that block templates are to be used by Administrators only Thanks. Boomer VialHolla22:59, 21 February 2016 (UTC)
That's where it is, under the instructions "New to AIV? Read me! " Those instructions were inserted by administrator Master of Puppets and was deliberately meant for non-admins with this this edit. Maybe Master of Puppets can clarify this. — Maile (talk) 00:05, 22 February 2016 (UTC)
Master of Puppets previously made it easy for everyone by preventing vandalism entirely :-) Perhaps we could insert something telling non-admins to employ an additional to-be-added parameter in the template that will insert {{nacc}} somewhere in the message? Nyttend (talk) 01:32, 22 February 2016 (UTC)
@Nyttend: Hey, just because the text is small doesn't mean I can't see it! Haha.
@Boomer Vial: Those instructions were added a lifetime ago, when general consensus amongst AIV users - both reviewing admins and reporters - was that non-admin editors could comment on or action reports that were blatantly against AIV policy (example - if an IP editor with one vandal edit five days ago and no warnings is reported, that would be something you'd most definitely decline). It's a very similar line of thought to WP:NAC. I'm not sure if that's changed, as I'm not nearly as active these days as I was back then, but I still hold the same opinion about editors helping out at AIV. m.o.p05:16, 25 February 2016 (UTC)
@Master of Puppets: That's interesting, considering I added a few "incorrectly warned" templates, and was subsequently told that is was "frowned upon" for non-admins to do so. I checked out the reported editor's talk page, and contributions history to find that they were insufficiently warned. So should I just avoid doing this altogether? Boomer VialHolla07:07, 25 February 2016 (UTC)
@Boomer Vial: Frowned upon by who? As I said above, unless there's community consensus on this issue that has changed since 2009 (which I doubt, as I can't find anything in any of the AIV guidelines), I don't see how that sentiment is anything more than a personal opinion.
I don't see anything wrong with an editor helping clerk the page, provided they're dealing with clear-cut reports only. After all, non-admin and admin editors have absolutely nothing separating them except for a technical role; Wikipedia is not a hierarchy, and, as long as they're not being disruptive (whether intentionally or accidentally), I can't think of a situation in which I'd 'frown upon' one's effort to further contribute to the project. m.o.p08:18, 25 February 2016 (UTC)
@Master of Puppets: This[36] is the message that was left on my talk page after I did so, advising me to not to please do not do so. Is there any possible way to find this discussion over the using of AIV templates? I don't see any mention of AIV under WP:NACD. I've also found the discussion[37] that took place over non-admin closure, and I'm currently looking it over. In the mean time while I'm doing so, should I start looking for a fresh Trout? 08:28, 25 February 2016 (UTC)
@Boomer Vial: There are a few more that I can see after a cursory search (1, 2). Those discussions are relatively more recent. There may be more, and they may not all agree on every single point, but I don't see anything talking about how such behaviour is strongly discouraged.
(←) I personally don't approve of non-admins declining reports. There's a lot more to the picture than just "insufficiently warned" or conceivably something clear-cut. AIV is urgent admin attention, where checking deleted contributions, applying page protection or deletion may be other options to a decline – things only admins can do. If non-admins are to respond beyond a simple comment, I'm not going to revert them, but I do ask you make some indication that you are not an admin. I'm not a big-headed rogue sysop shunning the "lower class editors" (which of course they are not), I just don't think AIV is that worthy of clerking compared to other venues — MusikAnimaltalk20:04, 25 February 2016 (UTC)
@MusikAnimal: The thing about this though, was that I added the templates to specific AIV cases in the middle of the day, AIV was extremely backlogged, and there was no admins in sight (nor did one show up for a while longer). Other editors were also aware of the ongoing lack of sysops in the middle of the day[38] as well. I figured it would make sense to weed through the AIVs, and clearly label the reports that were inappropriate due to insufficient/inproper warnings. If there was an administrator that was currently attending to AIV at that particular moment, I wouldn't have added the templates. Boomer VialHolla20:15, 25 February 2016 (UTC)
It's a bit silly to decline something that you would not even be able to accept in the first place. While comments from non-admins can sometimes be helpful, WP:AIV is essentially an admin area where reports should, and frankly, are expected to be reviewed by admins, not admin hopefuls. We have occasionally seen enthusiastic, new(ish) editors who like to help out by performing "non-admin closures", but every so often those closures have been far from ideal. This happens frequently at WP:UAA and WP:PERM as well. Each closure should be checked by a real admin anyway, so it just tends to be a waste of time for everyone. Widr (talk) 20:19, 25 February 2016 (UTC)
@Widr: Again, I did so because there were no administrators available, and AIV was terribly backlogged. I understand your concerns about non-admin closures being incorrect, but this is hardly the case for every non-admin AIV closure. Boomer VialHolla20:23, 25 February 2016 (UTC)
If you check the revision history I think you'll see the admins are around. If reports are left open for some time it's probably because we're indirectly deferring the report to other admins. This is sort of an unspoken practice, from my experience. You'll see the same at WP:RFPP. And I agree with Widr in that as much as I'd like to appreciate the help, I still feel inclined to double-check reports declined by non-admins, given their technical restrictions and possible inexperience in dealing with this area. It's nothing personal and any insightful commentary on a particular report are most certainly encouraged — MusikAnimaltalk20:25, 25 February 2016 (UTC)
There was not when I posted the AIV templates. I was also not the only editor to notice this. It wasn't a cases of AIV reports being deferred, or ignored. It was a case of absence of administrators. The point being that there are periods of the day when AIV gets no attention, and gets backlogged. This would be the only instance I would use AIV templates, though now I'm not sure seeing as it doesn't seem worth my time to add my good-faith contributions. Boomer VialHolla20:27, 25 February 2016 (UTC)
@Widr: I assume you are using the term 'real admin' to connote experience with Wikipedia and anti-vandalism efforts? Because, if that's the case, I'll happily list dozens of editors who do not have the mop and are just as competent, if not more so, at spotting and dealing with vandalism as we are. Writing off someone's good-faith efforts as 'a waste of time for everyone' isn't exactly in the spirit of the project. m.o.p20:30, 25 February 2016 (UTC)
@Master of Puppets: No, by real admins I was referring to the administrators, those who physically can use the block button if needed. No one is writing off Boomer Vial's efforts here, quite the opposite. Widr (talk) 20:45, 25 February 2016 (UTC)
Proposal break
How about a proposal: we expand the contested section. Flesh it out a bit. We could go the strict, defined route and set a minimum number of edits/account age which are required for an editor to clerk (though neither of those metrics indicate any inherent knowledge about vandalism and fighting it). Or we could expand on it and add some recommended reading or examples of good/bad reports and how to deal with them. I'd prefer the latter option. Thoughts? m.o.p20:30, 25 February 2016 (UTC)
I'd prefer the latter as well. Setting a guideline on how AIVs should be clerked based on the reported editors contributions/warnings. I also add that AIV clerking should be autoconfirmed group+. Boomer VialHolla20:34, 25 February 2016 (UTC)
Elaborating on how to respond to reports is a great idea. This should go in the administrator instructions, which is noticeably lacking compared to other venues. My !vote is still a firm oppose to the concept of clerking at AIV. I think there's much more meaningful things to do with your time. If a report isn't actionable that's OK, no one is suffering from it lingering on the noticeboard. It's the actionable ones that matter — MusikAnimaltalk20:40, 25 February 2016 (UTC)
I'm honestly about to take a walk. It's getting really frustrating having to explain repeatedly that there are gaps of attention in WP:AIV, only to be told I'm wrong. Absence of administrator attention to AIV is why I am suggesting a guideline to non-admin AIV clerking, as well as the ability of non-admin AIV closures. I've seen it multiple times myself, one of those times being in the middle of the day. I'm not sure how else I can say it. Boomer VialHolla20:44, 25 February 2016 (UTC)
I understand you, and thank you for your eagerness to help. I'm not convinced admins are inactive when you say they are, or the absence of declining reports is adverse to productivity at this noticeboard. This just isn't a very "clerkable" area for reasons I've stated above. For instance at WP:SPI we need folks to do thorough behaviorial checks, along with busy work of archiving reports, etc. At AIV we need the suite of administrative tools to make a definitive call on the reports. Not always the case, but I certainly use them — MusikAnimaltalk20:51, 25 February 2016 (UTC)
Please see this[40]. This is clearly AIV jammed with reports from 11:39pm (02/18/16) to 12:54 pm (2/19/26). There was one Administrator paying attention to AIV User:Smalljim, but AIV was still clogged, regardless. I still stand by my point that when an administrator goes into an backlogged AIV, they'll see the declined cases first, which will hopefully help them make a quicker decision regarding the reports. I'll be back later. Boomer VialHolla20:58, 25 February 2016 (UTC)
Adding explanation of ping requirements. A ping is only generated if a single edit (1) links to user or user_talk pageY, (2) is signedN, (3) diffs as + text. Adding to an old signature fails (2) and (3)... it's an unsigned edit which diffs as a - + modification to existing text. To avoid spam, ping fails if more than 50 pings would be generated. I think it fails if the edit is not restricted to a single section. Alsee (talk) 13:34, 3 March 2016 (UTC)
It was 30 September 2005.[41] Log systems have changed. I think some of the old user creation dates have been transferred from elsewhere, but apparently not to the data used by ListUsers in this case. PrimeHunter (talk) 01:31, 4 March 2016 (UTC)
The actual mechanism is over my head, but I know I've run into this in the past. When some template that is transcluded on all the pages gets CSD'd, and the noinclude tag isn't used, and then the CSD tag is removed, sometimes the cache takes a while to catch up. I *think* it would have resolved itself in a while, but to be safe I added a space to the articles, forcing the cache to purge, and the CSD categorization went away. It's kind of like turning your computer off and on; you don't really know why it works, but it usually works. -Floquenbeam (talk) 23:37, 3 March 2016 (UTC)
Adding a space like [42] is a dummy edit. A null edit is to save without making any changes. A null edit isn't logged but it should be enough to update link tables and thereby category pages. A purge only updates the purged page and not link tables. PrimeHunter (talk) 01:36, 4 March 2016 (UTC)
Yeah, sorry, I knew that (dummy vs null), just being lazily imprecise. But I tried an actual null edit, thinking it should work, and it didn't. Also tried preview-only for a dummy edit, which I thought was supposed to work, and it didn't work either. I'm sure you're right about me using the wrong terminology for "purge" as well, but I don't understand what you said. Rather than give a clueless explanation, I should have just said "I made dummy edits because for reasons I don't understand that has worked for me in the past". --Floquenbeam (talk) 03:24, 4 March 2016 (UTC)
Wikipedia is probably going to "break" for 10 or 15 minutes later this month
This is a heads-up note for everyone who gets asked tech questions:
The Ops team is planning a major change to the servers, (very) tentatively scheduled for Tuesday, 22 March 2016. One probable result is that when this happens, all wikis will be in read-only mode for a short time, likely less than 15 minutes for all editors. You will be able to read pages, but not edit them. "All wikis" means all of the WMF wikis, not just the Wikipedias, and it may affect some related sites, such as mw:Wikimedia Labs (including the Tool Labs). There will also be no non-emergency updates to MediaWiki software around that time.
Many details are still being sorted out, but I am asking you to please share the word with your friends and fellow contributors now. This will be mentioned in m:Tech/News (subscribe now! ;-) and through all the other usual channels for Ops, but 99% of editors at the English Wikipedia don't read this page, and even fewer contributors at other projects will see this note. If you are active in other projects or speak other languages, then please share the news with your fellow contributors at other projects, so that whenever it happens, most people will know that everything should be back online in 10 or 15 minutes.
May I suggest that starting about 2 hours prior to the scheduled "downtime", a BIG UGLY alert box of some kind be programmed to pop-up every time someone (1) enters the edit screen, (2) clicks preview in edit, (3) saves an edited page. This leadtime alert will help prevent folks from working in an edit screen for a long time only to be surprised when they go to save their hard work. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 21:41, 1 March 2016 (UTC)
I can't promise something upon editing (although I'm asking about it), but we could certainly set up a CentralAuth notice for the two hours beforehand. That would reach all editors and readers, not just all editors, but it could be done at nearly all the wikis. (And by "we could do that", I mean "I could beg James A to do it for me". ;-) Whatamidoing (WMF) (talk) 07:04, 4 March 2016 (UTC)
When an image on the English Wikipedia bad image list but not on the Meta-Wiki bad image list is added onto the Meta-Wiki user page of a certain user, and the user does not have a user page on the English Wikipedia, the GlobalUserPage extension means that the user page on Meta-Wiki is displayed, together with the image. This (archive link, contains an image on the local bad image list) is my result. Should this be stopped, and if so, how? sst✈07:04, 4 March 2016 (UTC)
As far as enwiki goes: Stop them after the fact by making an edit to the page, like a redirect to their talk page. Leave the user a note that their page violates community standards. If they persist they can be blocked and their page locked. Perhaps we can adjust the copied from meta section to include a report link to meta:Meta:Requests_for_help_from_a_sysop_or_bureaucrat if there are issues? — xaosfluxTalk12:02, 4 March 2016 (UTC)
Fixed in [43]. Templates which produce viev/discuss/edit links have a parameter which must be the template name. With the current template language it is not possible to extract the name automatically when the template is used. PrimeHunter (talk) 15:10, 4 March 2016 (UTC)
Coordinates for Bull Run Fossil Plant appear in the "infobox power station," but do not show up on the actual displayed page. I looked at the template, and it seems to be used correctly. What is wrong? Comfr (talk) 16:47, 4 March 2016 (UTC)
In Preferences/Editing, I have checked "Show edit toolbar" and "Enable enhanced editing toolbar", but not "Enable wizards". Compared to the diagram in Help:Edit toolbar, the "Signature" and "Insert citation" buttons have gone missing from my toolbar. (Vector skin). Is this a system problem, or have I done something to lose them? How can I get "Insert citation" back? JohnCD (talk) 17:27, 4 March 2016 (UTC)
I've tried IE and IOS9/Safari: both those give the "Insert citation" button but not the "Signature" one. Curiouser and curiouser. JohnCD (talk) 18:13, 4 March 2016 (UTC)
...and now "Insert citation" is back on Firefox. That's what I really wanted, so I'm happy now, but I'd like to know what to do if it goes away again. JohnCD (talk) 18:16, 4 March 2016 (UTC)
I stumbled upon the Poi (performance art) article and noticed all the edit section links are each in the same font as the section heading itself, with no space or square brackets. Article History shows that this happened only in the most recent edit (25 October 2015) by ClueBot NG, before which, throughout the past ten years, there were no edit section links at all. Section headings appear (to me) to be formatted correctly. Maybe it's just my computer, or only today? I have no interest in the article, but thought I should report it. Milkunderwood (talk) 20:03, 25 February 2016 (UTC)
I am finding an anomaly on article Tuskegee Veterans Administration Medical Center. Each section has an oversized "Edit" where "[edit source|edit]" or "[edit]" should be. I've viewed the page using Firefox version 44.0.2 and IE version 11.0.9600.18204. Whenever I view other pages besides this one on wikipedia, they appear normally. Mitchumch (talk) 13:03, 29 February 2016 (UTC)
I see this two or three times a day, and a WP:PURGE always fixes it. Saw it a couple of days ago at User:Graham87/Page history observations of all places, and you can bet your sweet bippy that Graham87 (talk·contribs) - who is the only person to have edited that page since May 2013 - doesn't use a touchscreen device, which kinda nixes the idea that the mobile interface is to blame. --Redrose64 (talk) 23:32, 3 March 2016 (UTC)
Why the strange look of the section edit buttons on the Comic opera article?
in mobile view, normally there is no TOC, and the h2 headers serve as "outline" headers that allow fold/unfold, so basically, when all are folded (or collapsed), the article itself can be perceived as its own TOC.
however, some articles *do* show TOC in mobile view. i could not find what controls this. see, e.g., Thermographic camera: it shows uncollapsed (and uncollapsible) table of content in mobile view. some articles show a variation on this theme: e.g., Mercury cadmium telluride in mobile view shows a collapsed TOC box above the first section. i could not find anything in the article text to attribute this behavior to. is this a feature? bug? if the former, how do we control this? peace - קיפודנחש (aka kipod) (talk) 18:49, 4 March 2016 (UTC)
some more information: for Mercury cadmium telluride, the extra TOC appears on my mobile (android, using chrome) and on desktop using "Mobile view", but *not* when i use the "Mobile sidebar preview" experimental gadget. the plot thickens. peace - קיפודנחש (aka kipod) (talk) 18:54, 4 March 2016 (UTC)
this seems extremely doubtful. maybe the fact that TOC on Thermographic camera was uncollapsible is related, but the new addition of TOC to mobile view is absolutely intentional - the new TOC even sports a class named "toc-mobile"... i think the answer is that TOC was recently added to mobile view, and the pages i received which did not have TOC in mobile view were simply stale. right now, it seems that any page containing TOC in desktop, has it on mobile too. peace - קיפודנחש (aka kipod) (talk) 21:41, 4 March 2016 (UTC)
stranger and stranger. i see the "content" box on desktop, using "mobile view", pretty much on every article with TOC i tried so far (4 or 6 of them), but only very few on my mobile. there are other differences between "mobile view" (on desktop browser) and the actual mobile view: for instance, on my android thingy is see at the bottom a "Categories" box, and on the same article, desktop "mobile view" does not show it. i give up. peace - קיפודנחש (aka kipod) (talk) 21:52, 4 March 2016 (UTC)
Is there any way to watch the related changes for the subcategories of a given category
In the watchlish I want to watch the related changes that happens in the subcategories of a given category (recursively) — Preceding unsigned comment added by Uni3993 (talk • contribs) 00:34, 5 March 2016 (UTC)
Updating problem: Sigurd Snake-in-the-Eye Talk page - edits do not appear in "read", only in "edit" mode
Because it was missing this in it's description. Would be nice if someone could make a bot to make sure to check the template data for templates that are being used in this style. —TheDJ (talk • contribs) 20:18, 28 February 2016 (UTC)
Not cites, please. Refs are often added in the middle of a paragraph, and multi-line cite templates make diff comparisons somewhat difficult as the second half of the paragraph is no longer on the same line as the first. Generally speaking: if the template is used inline, it should be written inline; if it makes a block, it can be written multiline. --Redrose64 (talk) 00:47, 29 February 2016 (UTC)
@Redrose64: I disagree. Inline reference templates make the wikitext essentially (even more) unreadable, and I've been writing them (manually) in block format for years without objection. In future please {{ping}} people if you're replying to them, rather than just commenting and then reverting. :-( James F.(talk)15:41, 2 March 2016 (UTC)
@Jdforrester: You may prefer cite templates to be written multiline; that doesn't mean that it's everybody's preferred format. Indeed, there have been several previous proposals to make multiline the only preferred format for cite templates; these always met with objections and never went through. VE edits excepted, I encounter far more that are written inline than are written multiline. In future please obtain consensus for controversial changes before making them. I didn't use {{ping}} at 00:47, 29 February 2016 because you asked the question, and it's courtesy to watch pages where you are expecting a reply. --Redrose64 (talk) 21:36, 2 March 2016 (UTC)
@Redrose64: Sure, I'm not at all concerned that you reverted me; you had good reason. Can you provide links to discussions about these templates being laid out well being rejected in a discussion?
BTW, I'd disagree with you on the idea that it's OK to fail to use ping just because someone will probably see it when they check in a few days' time; courtesies change, and by now not ensuring that your conversants are pinged (either with a mention or because you're using a modern discussion system). The concept of a "courtesy to watch pages" was true back in 2011 when there wasn't a better alternative for talk pages and there weren't pings available. :-) James F.(talk)00:28, 3 March 2016 (UTC)
Are you talking about the code in Template:Refimprove itself? I was talking about its transclusions, and transclusions of other templates based on Template:Ambox. (That's what I understood by Jdforrester saying "amboxes".) For example, at the A article, the invocation is {{refimprove|date=December 2014}}, which is all on one line. — Mr. Stradivarius♪ talk ♪02:12, 1 March 2016 (UTC)
For clarity of language, let's say that {{refimprove}} is constructed in block form and invoked inline, since its parent template {{ambox}} is invoked in block form. Amboxes, i.e. the class of templates constructed using {{ambox}}, are almost always invoked inline. {{Nihiltres |talk |edits}}18:55, 5 March 2016 (UTC)
I came across a lot of these in the last day or so: e.g. this edit to an instance of Template:Infobox football biography. It's common practice for the set of four parameters that apply to one football club to be written across the page, rather than on four separate lines, and the bug (if that's the right word) is mixing them up apparently at random. cheers, Struway2 (talk) 12:28, 1 March 2016 (UTC)
Unresolved issue is archived - How to "UN-Archive"?
Possibly; archiving bots do not take any notice of whether a thread has been replied to or not. Threads on this page are archived if they've not been posted to for five days. So if nobody responds here before the next bot run that occurs after 10:30, 5 March 2016 (UTC), it will be archived. --Redrose64 (talk) 10:30, 29 February 2016 (UTC)
FWIW, i copied User:Brion VIBBER's script locally, and verified it works with "monobook" and "modern" after minor changes. i had to modify about 5 lines to use mw.util.$content instead of $('#content'), and add a line to incease z-index specifically for monobook: for some reason the left edge of the mobile image was overshadowed by the right edge of the content in monobook (i'm sure there's more . you can try User:קיפודנחש/mobile-sidebarcopy.js to verify it indeed works with other skins (you'll probably want to disable the gadget, or you may get 2 of them...). peace - קיפודנחש (aka kipod) (talk) 20:55, 3 March 2016 (UTC)
קיפודנחש – Thanks for helping. I know about testing computer programs in other languages but nothing about js scripts. If you or anther editor could explain the steps to test, I would be willing to try testing. So far, I did un-check existing Gadgets option to disable Mobile sidebar preview option. Regards, — JoeHebda • (talk)21:36, 3 March 2016 (UTC)
to test the modified script, add to your personal script file the following line (if you copy from edit screen, *do not* include the "code" tags):
(if the file does not exist yet, create it, add the line, and save. more detailed instructions and explanations about personal scripts can be found in WP:JS). peace - קיפודנחש (aka kipod) (talk) 22:15, 3 March 2016 (UTC)
קיפודנחש – Followed the test instructions & same results = Mobile sidebar preview works only with Vector skin & not the other skins. I did the Purge and logout for each; not seeing the little toolbar icon to activate preview. I know it is running the test version because I have the Gadgets one unchecked with Vector & icon shows & works correctly. — JoeHebda • (talk)22:37, 3 March 2016 (UTC)
you are correct. it turned out to be more elaborate than i thought - the code Brian wrote displayed the phone nicely, but placing the icon for turning it on/off on the menu turned out to be a bitch... anywhoo, i at least made it so that you can use it now, though it's not really pretty when you use a skin other than vector. peace - קיפודנחש (aka kipod) (talk) 00:10, 4 March 2016 (UTC)
@JoeHebda: update: could not get the mobile on/off icon to look acceptable on monobook, modern and cologne blue, so on these skins, the on/off switch is text only (top row for mo*, left-menu under "Edit" for cologne). peace - קיפודנחש (aka kipod) (talk) 16:34, 4 March 2016 (UTC)
@קיפודנחש: – So far, it looks good and okay to me. For Cologn Blue, I am confused because I can not find any "Edit" anywhere on the page; not on top or left sidebar. I do see a "Mobile view" but that is just for switching the entire page between Mobile/Desktop views. Wondering where to look? — JoeHebda • (talk)16:48, 4 March 2016 (UTC)
@JoeHebda: i practically never use cologne, and not aware of all its idiosyncrasies. for me, using this skin, when i am on a page i am allowed to edit, i see in the left-hand menu column "Edit". i verified that this is so even as anon (you can test any skin by appending to the address line "?useskin=<skinname>". this works for anons too. names are [ vector monobook modern cologneblue ]). i also verified that the script causes "Mobile" to appear there even for anons. there might be something in your prefs that causes it not to show, or maybe it *does* show and for some reason you missed it. HTH, peace - קיפודנחש (aka kipod) (talk) 17:58, 4 March 2016 (UTC)
קיפודנחש – Yes, I did find it now. I had to set my custom CSS font-size to 155 percent for Cologne Blue skin to help overcome a line-height issue making that skin very hard to read. And the Mobile preview sidebar works okay there as well. Just a FYI, I found a report of User skin preferences at Wikipedia:Database reports/User preferences#Skin. Thanks so much for getting Mobile to work correctly with these skins! IMO not seeing the little toolbar icon is a lesser (non-structural) issue.
Now in order to go live with this script, what needs to be done? Once it is out there I will check On in Gadgets. Then, could the Mobile sidebar preview line of Gadgets be moved out of the Testing and development section? Perhaps move into Appearance section? Cheers! — JoeHebda • (talk)19:13, 4 March 2016 (UTC)
@JoeHebda: i saw this more as an experiment, to gauge the amount of change needed to make mobile-sidebar work with other skins. ideally, User:Brion VIBBER would patch the script on meta to work with all skins (TBH, Brion needs me to tell him how to do that exactly as much as i need my grandson to teach me to suck eggs). if, for any reason, Brion doesn't do it, enwiki can decide that limiting this gadget to vector is acceptable. the very last resort would be to change the gadget on enwiki to consume Brion's css file from meta, and the modified js file from my userspace (or some copy of it). this last option is both undesirable and unlikely. if none of those options is executed, people who do not use vector can consume my modified script privately, the same way i listed above and you tried. peace - קיפודנחש (aka kipod) (talk) 20:31, 4 March 2016 (UTC)
@קיפודנחש: – Thanks for the answer. It sounds complicated, but I think I understand. For now, I will leave the test js in place and wait until resolved. Cheers! — JoeHebda • (talk)13:51, 5 March 2016 (UTC)
Very early edit history missing
I'm looking at the Amedeo Avogadro article and I notice that the edit history starts with an edit on 19:46, 26 February 2002 which is pure vandalism and the second edit is a quick "revert", suggesting the original edit history prior to 19:46, 26 February 2002 is missing. I don't see any page moves or other log entries that might explain the missing history. Is it just lost? What forensics can be done to figure out what happened in such cases? Jason Quinn (talk) 22:34, 2 March 2016 (UTC)
I remember this coming up before, but couldn't find the thread. IIRC, a lot of early histories are missing, and those that do survive may be wrong. DuncanHill (talk) 22:41, 2 March 2016 (UTC)
I couldn't find the entry at the Nostalgia Wikipedia so the Amedeo Avogadro article must have been created after 20 December 2001. The missing history probably exists in the 2002 database dump. Graham87 does indeed have a very informative write-up of his efforts. Thank you all. Jason Quinn (talk) 23:53, 2 March 2016 (UTC)
The import caused some anomalies (due to out-of-order revisionIDs), take for example the Anarchism article (history: Dec 2009; Jan 2005; Oldest):
prev 01:44, 19 December 2009 174.124.221.56 (talk) (93,022 bytes) (+1)
prev 02:05, 18 December 2009 Graham87 (talk | contribs) m (93,021 bytes) (0)
prev 19:34, 17 December 2009 Midnightblueowl (talk | contribs) m (93,021 bytes) (-3)
...
prev 02:59, 17 January 2005 TimMony (talk | contribs) m (84,641 bytes) (+75,206) (→See also)
prev 04:40, 15 January 2005 Conversion script (talk | contribs) m (9,435 bytes) (-83,586) (link fix)
prev 15:00, 25 February 2002 Conversion script (talk) m (9,546 bytes) (+119) (Automated conversion)
prev 15:25, 2 December 2001 216.39.146.xxx (talk) m (9,427 bytes) (-83,594) (*Added Kropotkin;
prev 15:08, 2 December 2001 216.39.146.xxx (talk) m (9,175 bytes) (+171) (*Add two substantial
Click the 19 December 2009 "prev" link, then click ← Previous edit; instead of 17 december 2009, you get 15 January 2005
Click ← Previous edit again, you get 15:25, 2 December 2001
Click ← Previous edit one more time: 19:34, 17 December 2009
Didn't know who did the import. Well, that does explain Graham87's edit summary on 18 Dec 2009. Why the Conversion script revision was given the date 15 Jan 2005 however, that still doesn't make sense.. Prevalence 02:28, 3 March 2016 (UTC)
@Prevalence: That's because I messed up and imported this edit from the Nostalgia Wikipedia (it had its own conversion script).
@Jason Quinn: Re the Amedeo Avogadro case, that's really, really weird! The earliest surviving edit to that page was made well after Wikipedia upgraded to the Phase II software, and also after and a mistake on 25 February 2002 when the timestamps of thousands of edits were botched. Usually in cases like this, at least one edit survives before 25 February 2002. Niether the March 2002 database dump nor the old deletion logs have further clues about where any missing edits could have gone. However, the contributions of 151.24.146.117 are interesting; after adding the first substantial content to the page, they wikilinked it in four articles, adding all but two of the links to that page that occur in the March 2002 database dump (the others were at "1776" and "Talk:Avogadro's number". Therefore they may have added the first page content, but I don't see how they could have done it in ten minutes. Hmmm. I'll add it to my page history observations anyway. Graham8710:58, 3 March 2016 (UTC)
If the text is original and appeared so suddenly, one possible explanation is that is was a copy-paste from elsewhere and therefore a likely copyright violation. I spent a few minutes searching for evidence of that but failed to find anything incriminating. Thanks, Graham for your work on page history stuff. Jason Quinn (talk) 20:03, 5 March 2016 (UTC)
Uncheck from watchlist
Hi,
do we have any script to uncheck watched pages directly from Special:Watchlist?--17:26, 5 March 2016 (UTC) — Preceding unsigned comment added by Juandev (talk • contribs)
For some reasons overflow-x:scroll has become popular. Over 500+ pages popular. We should standardize with a template or better: kill it.
Why Kill? Well its hard using scroll bars you can't see. That is a usability and accessibility issue (large-pixel, low vision users). Don't believe me? Try it on Marvel Cinematic Universe cast, resize the window to 1280x720 (that's Bruce Banner to Natasha Romanoff) try seeing which films Banner appears in only using the left mouse button. Because believe it or not there are two-button non-multi-touchpads used out there. We should not exclude them because we have RGB illuminated 10-button mice with touch sensitive tilt-scroll wheels while we edit on a glorious 4K ultrawide monitor. — Dispenser06:06, 22 February 2016 (UTC)
That's overflow:hidden; I've made the original post clearer that this is concerning scroll bars. I've been eliminating those over protests of some users. — Dispenser15:56, 22 February 2016 (UTC)
The overflow-x: property is described in CSS basic box model, section 11.1. This doc is a W3C Working Draft, as such is a work in progress - and not (yet) a formal part of CSS, so browser vendors are under no obligation to provide support for it. It's dated 9 August 2007 and I don't know if there is any further progress expected. --Redrose64 (talk) 19:58, 22 February 2016 (UTC)
Does overflow:scroll have accessibility problems? Should we eliminate it and/or standardize it? How to deal with users who say they don't have said problems. What previous discussions have we had? And What happened to your overflowbugx class, TheDJ? — Dispenser14:29, 26 February 2016 (UTC)
That class was for an ie6 (and 7?) Internet Explorer bug. I have some thoughts on overflow, but i'm too tired right now to share them. —TheDJ (talk • contribs) 19:31, 26 February 2016 (UTC)
I see you added it already, thanks. But I have excuses! The page is unusually wide, and the width of my browser window was such that Step 2 cleanly ended on the right. Also considering the squished columns, I think the page would be more readable if the three steps were listed vertically. But that's something to take up elsewhere. Manul ~ talk04:39, 6 March 2016 (UTC)
"Category:Candidates for speedy deletion#Pages in category" still includes Laurent Weil
Hello all, Category:Candidates for speedy deletion#Pages in category still includes Laurent Weil.
I've checked all the possible redirects and templates on that article to see if any of them have speedy deletion tags on 'em. If there are, I can't find them.
I've purged - myself, my browser cache, and also by adding &action=purge to both the category and the article - and the tag is till there.
What's going on? Is this some sort of known issue?
Pete AU aka --Shirt58 (talk) 10:22, 6 March 2016 (UTC)
It was gone when I looked. A purge of an article only affects the purged article page and not category pages. Make a null edit ot the article to also update category pages. PrimeHunter (talk) 10:36, 6 March 2016 (UTC)
Copy/ paste on a certain article makes Chrome browser crash repeatedly
All of a sudden I'm repeatedly having issues with Chrome browser crashing when I am editing an article, during a copy/ paste operation. When I do the paste, I get the "Aw snap! Something went wrong" Chrome browser screen. I go back and try the same thing again and keep getting it. Doing a "Paste as plain text" doesn't fix it. At that point I have to stop editing, close the whole browser and start over again to be able to edit.
I'm wondering if it's something specific to the article as I noticed just now I was able to paste the "problem" text (a blank Template:cite news copied from the template wiki page) into this text box with no problems, although I deleted it so as not to be cluttering up this post. The article that's giving me problems with editing is Death of Starr Faithfull . So far this is the only article on which the problem has occurred, and it's happened multiple times within the past week, but not sure if that's just because I'm spending a lot of editing time on that particular article right now, so a problem is most likely to pop up there.
I'm using Win 7 Home Premium with svc pack 1 and Chrome version 48.0.2564.116 m . If anyone can tell me how to stop this from happening it would be great as it's really causing headaches with me trying to add the appropriate citations to the article. TheBlinkster (talk) 21:51, 5 March 2016 (UTC)
No, I'm more comfortable with Wikimarkup code. I also don't use any mobile devices to edit, I do it on a laptop like the old skool person I am :) I switched over to Firefox to edit on the article today and am not having the problem with that browser. TheBlinkster (talk) 01:34, 6 March 2016 (UTC)
OK, just narrowing things down. I can't reproduce the issue (Safari 9.0.1 & Chrome 48.0.2564.116; OS X 10.11.1), so there's one data point. {{Nihiltres |talk |edits}}01:42, 6 March 2016 (UTC)
I reproduced it on first attempt at Death of Starr Faithfull with Chrome (same version as above) on OS X. That was around 23:00 UTC (and Chrome had probably been running for some hours before that), but now after restarting the browser I'm not able to reproduce the issue. --Pipetricker (talk) 10:04, 6 March 2016 (UTC)
Happened to me too on the Finnish Wikipedia yesterday when I tried to edit my user page. I usually use Firefox but wanted to try Chrome, and it always crashed when I tried to paste some text on my user page. Then I updated my Chrome and the problem got solved. I don't remember the old Chrome version, but now I have 49.0.2623.75 m. --Stryn (talk) 12:13, 6 March 2016 (UTC)
Hmm... I notice now that when restarting my Chrome it got updated from 48.0.2564.116 (where I reproduced the issue) to 49.0.2623.75 (where I haven't been able to reproduce it). Maybe the issue got fixed between these versions. --Pipetricker (talk) 17:38, 6 March 2016 (UTC)
Can't always access "Cite" in the wikitext edit window
I use the wikitext edit box (not Visual Editor) to edit Wikipedia. As shown at File:How to edit a page Edit box.png, when editing using that edit box, there are supposed to be "menus" for Advanced, Special characters, Help, and Cite at the top of the edit box. However, I don't get the Cite menu every time. Usually it's there -- but sometimes it doesn't appear, and all I get in those situations is Advanced, Special characters, and Help.
Is anyone else familiar with this problem, and, if so, what can be done to ensure that I can always access the Cite menu from the edit box? --Metropolitan90(talk)16:34, 6 March 2016 (UTC)
I have a different sporadic quirk lately. I can access the Template drop down list, and see the cite templates to select. That step usually works with no problem. But about once a day or so, when I select a cite template from the drop down, nothing happens. Try again, two, three times, nothing happens. So, I click "Show preview", which seems to clear the problem and I can then select and use a cite template. This happens when I'm in Firefox 44.0.2. There is no consistency on it that I can see. — Maile (talk) 17:44, 6 March 2016 (UTC)
OK. Yesterday I saw these level-3 section titles showing in really big-bold font. Gone now, so let's close the topic. -DePiep (talk) 01:03, 7 March 2016 (UTC)
But I did: "I would've preferred squared brackets for the sorting key, that would look even better, but Wikipedia doesn't allow it." CN1 (talk) 02:18, 7 March 2016 (UTC)
IW does not work from search box
I found out that iw does not work from search box. E.g. if you type on cs.wp to search box en:dog and click on enter, you are redirected to English Wikipedia's article Dog. Or if you type in es:Perro you are redirected to Spanish Wikipedia's article Perro. So if I type on en.wpcs:pes, I should be redirected to Czech Wikipedia's Pes, but it wont work. There is just error message stating "There were no results matching the query." What am I doing wrong?--Juandev (talk) 08:57, 7 March 2016 (UTC)
It also works for me currently in Firefox but has occasionally failed in the past. When it fails it is apparently because the "Go" feature of the searh box to go directly to an exact match is failing. Do you go to Dog or get search results if you type Dog and click enter? What is you browser and skin? PrimeHunter (talk) 09:25, 7 March 2016 (UTC)
I just did three saves with no problems. I though that it might be related to the "Show preview on first edit" preference, but apparently not. RudolfRed (talk) 20:45, 6 March 2016 (UTC)
I get it maybe once a month, usually (but not always) it throws the "Sorry! We could not process your edit due to a loss of session data" error at the same time. --Redrose64 (talk) 00:16, 7 March 2016 (UTC)
Yes, of course. At that point they hadn't edited! Stupid me, I'll remember to check what links here next time. And to block him. I added him so I'd know if he'd done something to attract a user to his talk page. Doug Wellertalk15:23, 7 March 2016 (UTC)
Discussion about WP:CITEVAR and use of it to restrict how things may be coded
Please see Wikipedia talk:Citing sources#Instruction creep in WP:CITEVAR. The relevance to VPTECH is that some wording in the guideline has been interpreted by some as permitting reversion of wikicode changes that have no effect on visual output. Others are convinced that the "citation style" referred to in that guideline means the style (the visual appearance and arrangement) of citations, not the formatting of the underlying code. Give that WP:CITESTYLE and its WP:CITEVAR component are closely related to MOS:ENGVAR, MOS:DATEVAR, and various other *VAR provisions for "status quo enforcement", and efforts are made to keep these provisions synchronized to some extent, this discussion could have much broader implications that citation-related bickering. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:06, 7 March 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Files on Wikimedia Commons can now be 2 GB big. The old limit was 1 GB. [45]
Welcome notifications now have a different symbol. English Wikipedia already had this one. [46]
The Wikimedia memory cache servers in the Eqiad cluster have now been upgraded to Debian 8 (Jessie). Some users might have had to log in again because of this. [47]
It is now easier to categorize images uploaded to Wikimedia Commons in the Commons Android app. [48]
Bare attributes in tags now parse according to the HTML5 specifications. <pages from= to= section=1> will parse as <pages from="to=" section="1"> instead of <pages from="" to="" section="1"> as it used to. Please use <pages from="" to="" section=1> or <pages section=1> instead. This is mostly likely to affect pages on Wikisource projects. [49]
Problems
Phabricator has been a bit unstable lately. This should be fixed now. [50]
The PageView API shows wrong data between 23 February and 29 February for pages with special characters in their title. [51]
The parsing change mentioned above caused a large number of pages to break, especially on Wikisource. [52]
You may see falsely formatted edit links on both mobile and desktop devices. Mobile devices can also show incorrect formatted table of contents. This should be fixed soon. [53]
Templates using TemplateData that were edited with the visual editor might have some problems in wikitext mode. This can be fixed by editing and saving the page by using the visual editor without making any changes. [54]
Changes this week
Cross-wiki notifications will be enabled as a beta feature on all wikis on 10 March. You will be able to get notifications when something happens on another Wikimedia wiki. [55]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 March. It will be on non-Wikipedia wikis and some Wikipedias from 9 March. It will be on all wikis from 10 March (calendar).
Wikivoyages will get the Kartographer extension. Kartographer will allow <mapframe> and <maplink> tags in an article to insert an interactive map and overlay it with different markers. You can add ideas and suggestions to the Maps talk page. If you find any bugs, you can report them in Phabricator. [56]
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 8 March at 20:00 (UTC). See how to join.
Future changes
The buttons in interfaces will be simplified. Instead of white, red, green and blue buttons, in future there will only be white, red and blue ones. [57]
The Wikimedia technical operations team plans to do some server work on 22 March. This could cause some problems, for example make it possible to read but not edit the Wikimedia wikis for a short period of time. The date for this might change. [58]
My userpage has always functioned correctly, but now my {{divhide}} template no longer transcludes, but shows as a plainlink instead. Also, some of my barnstars no longer work either.—cyberpowerChat:Limited Access16:36, 7 March 2016 (UTC)
@Jo-Jo Eumerus: Looks like Anomie (talk·contribs) created the template with some incorrect code, which I have removed. Code that applies to the template and not to the pages it is transcluded on belongs inside <noinclude>...</noinclude> not in <includeonly>...</includeonly>; and in any case, {{pp-template}} is redundant since the {{documentation}} handles any prot icon padlocks that may be applicable. --Redrose64 (talk) 00:33, 8 March 2016 (UTC)
Search error in Template:Search deletion discussions
The error message ends with for example "(663 > 300)" for me. A length limit of 300 was set in September at phab:T107947. {{Search deletion discussions}} must be changed to greatly reduce the length. There is another problem. It uses {{Search prefixes}} which makes searches with a syntax that doesn't currently work when you select multiple prefixes. For example, {{Search prefixes|Wikipedia:Articles for deletion|Wikipedia:Categories for discussion}} produces:
short search title
click show to see which wikipedia areas are searched
A search on X becomes X prefix:Wikipedia:Articles for deletion|Wikipedia:Categories for discussion. It's apparently meant to search two prefixes separated by a pipe but that doesn't happen. It gives no results and maybe interprets it as a single long prefix. PrimeHunter (talk) 09:55, 7 March 2016 (UTC)
In trying to delete File:Iiac.png and File:SLAF Palaly Crest.jpg as orphaned files in batch deletion via Twinkle, I run into similar error messages: Error deleting file: The file "mwstore://local-multiwrite/local-deleted/a/j/b/ajbyzg02hhch9vwtsilxeaqnhdxfpz8.png" is in an inconsistent state within the internal storage backends. I ran into this problem when trying to delete other files, but I was able to get them deleted on the second try. I simply can not get the two aforementioned files deleted. Attempting to delete the files individually has not resolved the problem. Any ideas as to why this issue is occurring? — ξxplicit02:50, 8 March 2016 (UTC)
Implementation of editormeter, that depends on time.
Wikipedia has counter of edits, but can it depend on time? For example, with {{NUMBEROF:|Edits|en|01.01.2016 10:00:01|01.01.2016 12:00:01|N}} we will obtain the number of changes, that were made from January 1, 2016 from 10 hours 00 minutes and 01 seconds to 1 January 2016 to 12 hours 00 minutes and 01 seconds. Is it any technical realization of such or similar counter? Thanks! Ігор Пєтков (talk) 19:34, 8 March 2016 (UTC)
I'm not aware of any template that gives edit counts on a specific date or time. There is, however, a well-maintained page with the exact time of 10 million edit increments and a Wikiproject dedicated to edit counters. It is likely possible to make a module loop around to find a diff number at a specified time to get what you're describing, but you'd need to be careful not to exceed the expensive operation limit. Mamyles (talk) 20:28, 8 March 2016 (UTC)
It's not currently possible to do this in Lua - the Lua API doesn't include any access to page histories or user contributions. It would have to be done via some other means (probably a tool or bot). — Mr. Stradivarius♪ talk ♪23:46, 8 March 2016 (UTC)
“TypeError: mw.util is undefined”
Error messages from Firefox. First I'm told that mw.util is undefined, then I'm told that something else is deprecated and that I should use mw.util instead. As a result, I don't see a number of links which are supposed to be created by my global.js script. Any idea what's wrong? Note that Firefox also produces warnings that a bunch of other things also are deprecated between these two warnings, but I don't see anything which would explain why I'm told to use something which is apparently undefined. --Stefan2 (talk) 21:27, 5 March 2016 (UTC)
Looks like a load order error. If it's running before some stuff from the mediawiki (shortcut mw) object is defined, wrapping it in $().ready(function () { /* code goes here */ }) might help; otherwise I'd be suggesting the mw.loader.using helper. {{Nihiltres |talk |edits}}01:27, 6 March 2016 (UTC)
It seems that the problem disappeared when I added $(mw).ready(function(){ at the beginning of my userscript and }); at the end of my userscript, but I think that it would be better if Mediawiki did this automatically for all userscripts instead of confusing users. I suspect that quite a lot of userscripts depend on the mw object. Thanks for the help! --Stefan2 (talk) 11:51, 6 March 2016 (UTC)
@Stefan2:. Thats still wrong unfortunately (and only works per chance). Please see ResourceLoader documentation, for the right way to write userscripts that depend on resourceloader modules. And you need to declare this dependency on mw.util, because the only modules that are always loaded by default are mw and mw.loader. Because many other components also load mw.util, it can often go unnoticed that you had forgotten to declare this dependency, but global scripts are loaded a bit earlier than most other user scripts, so that might surface the problem a bit quicker than other modules might have. —TheDJ (talk • contribs) 11:15, 9 March 2016 (UTC)
Does {{db-c1}} (empty category) contain a timer like PROD to say when four days are up? Should it be added when a category is first empty, or should one wait four days before adding? How does one tell whether a category has been empty for four days? JohnCD (talk) 12:33, 8 March 2016 (UTC)
(i) is gnerally not an issue - empty categories are rarely edited. As to (ii), these categories do end up at CSD on a fairly regular basis - I believe that Joe's Null Bot is responsible for this. עוד מישהוOd Mishehu11:33, 9 March 2016 (UTC)
Cross-wiki notifications alive on Beta on your wiki March 11th, 00:00UTC
Greetings!
As you may have noticed on the last Tech News issue, Collaboration team is please to announce that Cross-wiki notifications will be available as a Beta feature on all wikis by March 11th, 00:00UTC (it has been rescheduled).
Cross-wiki notifications will help you know about some activity on another wiki. How does it work? Imagine someone thanks you on Commons - the next time you open a page on English Wikipedia, you'll see that notification from Commons! We hope this will help everyone who is active on multiple wikis. You will find more information in the documentation.
Of course, it is a Beta Feature. We have tested many possible cases on test wikis, and then release that feature one month ago on MediaWiki.org, Commons, Wikidata, French and Hebrew wikis. That first release allowed us to solve encountered problems, but if you experience some bugs (and we are sorry about that), please report them on the dedicated page. That page is also open to feedback and suggestions.
To activate the feature, you will have to go on the 11th of March to your preferences, Beta tab, and select the "Enhanced notifications" checkbox. You will then receive Notifications when they happen on any other wiki (and may the unread ones posted a long time ago). You will receive these notifications only on the wiki where you have activated the feature. If you do not activate it, nothing will change on your Notifications panel.
@Edgars2007: Thank you - that looks like what I need. Two Qs: Is "en" in FROM externallinks enel the identifier for the English Wikipedia (and so frel for French. etc)? and how do I get http and https links? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:57, 8 March 2016 (UTC)
@Pigsonthewing: The quarry search from Edgars2007 is sensational, but for completeness it is also possible to write a script which uses the API. That can produce formatted lists for contemplation. See this VPT archive for my example in case it is of interest. Johnuniq (talk) 04:10, 11 March 2016 (UTC)
Hello all. I have been tracking certain abuse filter logs and was stumped by one particular edit filter entry. As per this edit filter entry, User:Amylieumedia made (or rather, tried to make) a certain edit which the edit filter recorded. But as per the user log, such a user does not exist and in fact is not even registered. How is that possible? Any inputs would be welcome. Many thanks. Xender Lourdes (talk) 12:32, 11 March 2016 (UTC)
Recently I am experiencing problems when editing wikicode that edit toolbar rarely loads. Also box with symbols under edit window is not clickable and I cannot initiate page to edit it in Visual Editor.--Juandev (talk) 17:29, 5 March 2016 (UTC)
Images not showing, attempting to click on their root page will result in 404 error
Hi, I posted the same issue six months ago and the problem has not been solved for me. It occurs on all devices, logged in or out, and is not network-dependent or operating system dependent (happens on Ubuntu 15.10 and Windows 7/10). Both Wikimedia Commons and Wikipedia-based images do not load. I believe that I have seen the issue occur on Internet Explorer and Firefox -- but I cannot remember for sure (this issue is a regular occurance, but is very transient and random at the same time). Thanks, Mynameisnotdave (talk/contribs) 17:34, 5 March 2016 (UTC)
This wasn't happening earlier yesterday (like before 4 p.m. central US time), but started last night and is still going on. When I type, say, "saddle" into Google, it brings up the Wikipedia article as one of the top results. When I click on the link to our article on saddle, I get an error message that says, "No app found to open url". This has never happened before and I'm pretty sure it's a bug. If I type in Wikipedia's address, it loads the site and I can then search. I don't want to download the Wikipedia app because I may switch phones soon anyway and don't want my memory taken up by yet more stuff. Is this issue being tracked or fixed? White Arabian FillyNeigh20:41, 12 March 2016 (UTC)
Do you have an Android phone? If so, open Settings, go to Apps, and tap the three dots icon at the top right. Then tap "Reset app preferences". As far as I know, this is an Android issue, not a Wikipedia issue, though my searches indicate it's mostly linked to the Google search app. clpo13(talk)01:01, 13 March 2016 (UTC)
@White Arabian Filly: Thanks for the report. A few other users noticed this problem. This appears to have been an experiment by Google, as nothing changed from the app's end. The problem is now resolved, as Google appears to have discontinued their experiment. --Dan Garry, Wikimedia Foundation (talk) 18:07, 14 March 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The mobile web interface no longer suggests HiDPI thumbnails. This is to take up less bandwidth on slow or expensive connections. [59]
Wikimedia has a new backup data center in Dallas. Because of planned work on this, you will be able to read but not edit the wikis for a short period of time on both 22 March and 24 March. This could be postponed to April 18. You might lose edits if you try to save during this time. Because of a test, there will also be a couple of minutes where you can't edit the wikis on 15 March starting 07:00 UTC. You can read more about the server work. There will be more notifications and updates about this.
Administrators and other users with advanced permissions will need to have an 8-byte long passwords. This change takes place on 15 March. Users with too short passwords will be asked to change password the next time they log in. This was decided in a discussion on Meta and is because they can use tools that can hurt the wikis. [61]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 March. It will be on non-Wikipedia wikis and some Wikipedias from 16 March. It will be on all wikis from 17 March (calendar).
The buttons in interfaces will be simplified. Instead of white, red, green and blue buttons, in future there will only be white, red and blue ones. [62]
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 15 March at 19:00 (UTC). See how to join.
Updates to wiki search auto completion are arriving 16 March
Hello!
Please help translate to other languages.. Thank you!
The completion suggester beta feature became the default at the first group of wikis on Thursday, 10 March. This initial rollout started with some of the smaller wikis to ensure the change happens in an organized way. The remaining wikis will receive the update on Wednesday, 16 March. This update brings three major improvements to search. Improved search result ordering, a tolerance for a small number of spelling errors, and suggests fewer typos.
Since December 2015, 19,000 editors have already opted into the completion suggester beta feature. Contributors are encouraged to try out the feature ahead of the release. Please share any comments on the Completion Suggester discussion page in any language.
To learn more about the work of the Discovery department and other improvements to search, please check out the Wikimedia blog. Read about CirrusSearch, the MediaWiki extension that makes wiki search possible.
Regarding this edit, is this some sort of newish feature that I'm unaware of? It looks like a named ref was automatically moved when it was removed elsewhere, within the same edit (I kind of doubt the person who removed the text was considerate enough to also notice the ref problem and fix it). I noticed a similar edit a few days ago. Can anyone confirm or deny? --Bongwarrior (talk) 02:26, 14 March 2016 (UTC)
Please report any bugs that you found during the read-only time in phab:T129968
This is your twelve-hour reminder: Nobody will be able to edit or save for five minutes around 07:00 UTC on Tuesday (=3:00 a.m. EDT Tuesday). This time was carefully chosen because most of our editors are either asleep or otherwise not editing yet.
These are huge sites, and there are no times when the larger sites are actually quiet. I think we can confidently expect some people to be surprised by this. Also, would you mind making notes here about where editors went to ask questions or report problems (e.g., IRC channels during the event or Village pumps afterwards)? When this happens for the actual switches, which will take much longer, it might be nice if we could have announcements posted at all of those pages. Whatamidoing (WMF) (talk) 18:51, 14 March 2016 (UTC)
I received the following watchlist notice: You will be unable to edit the encylopedia for five minutes at approximately 07:00 on Tuesday 15 March 2016.
Two criticisms: the message implies that only the user who receives the message will be unable to edit. Also there is no indication what time zone the 07:00 refers to. Please change to something like "All editing will be suspended for maintenance for five minutes at approximately 07:00 UTC, 15 March 2016." DO NOT use the day of week (Tuesday) because some time zones do not enter Tuesday until some considerable time after the event. Stating it in UTC with date is the only meaningful way to state it. Akld guy (talk) 23:55, 14 March 2016 (UTC)
I agree with Akld guy's comments. Also, @MSGJ: could the watchlist notice be made more prominent? (Just making the text bold might be enough) I probably wouldn't have noticed it if I hadn't already seen this discussion. DH85868993 (talk) 00:13, 15 March 2016 (UTC)
I've tweaked the watchlist notice. I'll go ahead and make it bold too. But considering it goes into unplanned edit-only mode every so often, we shouldn't panic too much. --Floquenbeam (talk) 00:17, 15 March 2016 (UTC)
I too agree with Akld guy's suggestion - and perhaps link UTC too, to help people who aren't aware of what it means. I haven't seen the watchlist notice yet. DuncanHill (talk) 00:17, 15 March 2016 (UTC)
We took a "both/and" approach here. There were "generic maintenance" sitenotices with "emergency" priority on all the projects and in 417 languages. The language depth is the main advantage to using the generic message, but I'm considering a custom one for the main phase.
BTW, as usual, if you personally saw one of those notices (IP or logged-in), then please tell me. CentralNotice can be a tricky thing, and it's always nice to hear that it worked. Whatamidoing (WMF) (talk) 15:14, 15 March 2016 (UTC)
About four and a half hours to go. I've heard nothing from Ops for several hours, so I assume that it's all still "go". I'm going to post messages to some IRC channels, in the hope that a few people will see them now and also be online later. Whatamidoing (WMF) (talk) 02:37, 15 March 2016 (UTC)
Completion suggester coming soon - how long does it take a new article to appear?
several years back, it took articles and phrases a day or more to appear in search results and search autocomplete. then things have improved dramatically (i think it was related to a new search engine, called cirrus search), and new phrases and new articles began to appear mere minutes, or even seconds after creation (never actually measured it, but i'm pretty sure it was < 10min from article creation to appearance in autocomplete).
i have the "search suggestion" beta feature turned on (ya'll will have it in less than 2 days - read #Completion Suggester inital rollout above), and i noticed that even day old articles do not yet show in search suggestions (e.g., 9600 port). once i turn off "Completion suggester", i get completion for articles off the very top of Special:NewPages.
run this simple test: turn the beta feature on, and then type in the search box "9600 por" (i think you need to get out of "preferences" for the beta feature to actually take effect). nada. turn it off, and try again - it's there.
if, by the time you read this, "9600 port" *does* appears in suggestion with the new suggester turned on, try again with some other article, maybe 12 hour old or so (hopefully you'll find everything works as advertised).
is this a temporary hiccup, or does this mean that turning on suggestion will bring us back to the "good old days" when we had to wait a day or more for an article to appear in suggestions? if the latter, is the very nice functionality of the suggester worth this price of waiting a day? (as a side: what *is* the delay?) pinging @CKoerner (WMF):. peace - קיפודנחש (aka kipod) (talk) 22:39, 14 March 2016 (UTC)
@MaxSem: you may be right, but i doubt it: fact is, new pages *do* appear in "search" and completion shortly after creation. it's only when you turn on "suggester", that completion takes longer. notice that when suggester is off, articles created minutes ago already appear in completion, and when it's "on", even articles created 12 hours ago do not. if it was "job queue", i would expect completion to either work or not work for specific article, regardless of "suggester" settings. peace - קיפודנחש (aka kipod) (talk) 23:03, 15 March 2016 (UTC)
@קיפודנחש: Currently the indices for this are rebuilt every night between 2:30 and 5:30 UTC. This is a temporary limitation due to us being on an older version of the elasticsearch server that powers search. This will be corrected in the next few months as we upgrade to the latest versions of elasticsearch. I've done some analysis and the # of searches that click through to newly created pages is infinitesimally small.
Comments subpages
Please could someone tell me how to query the server to get a list of all edits in the past year to any subpage called /Comments in the article talk namespace? Thank you — Martin (MSGJ · talk) 12:00, 14 March 2016 (UTC)
@MSGJ: There are two basic ways to do it: by running an SQL query on Labs, e.g. with Quarry, or by querying the action API, e.g. with Pywikibot. How you do it exactly will depend on your needs. Do you need to see every edit, or would it be enough to have a list of every /Comments subpage that has changed in the last year? How would you like the results to be formatted? And is this a one-off, or will you need this information regularly? — Mr. Stradivarius♪ talk ♪13:37, 14 March 2016 (UTC)
This is one-off, just to see if anyone is still using these subpages. Just a list would be okay, and I'm not fussed about the formatting, but wikilinked would be nice. Thanks — Martin (MSGJ · talk) 14:59, 14 March 2016 (UTC)
Also, this is Edgars2007's Quarry query. I am guessing that his didn't time out because he joined the page and revision tables with the primary key of the page table rather than the primary key of the revisions table, and there are a lot more revisions than there are pages. — Mr. Stradivarius♪ talk ♪02:52, 16 March 2016 (UTC)
Thanks to both of you. The lists are helpful and confirm to me that no one systematically using these pages for the purpose they were intended. Most of the edits are moves alongside the corresponding article, or maintenance to redirects. There are relatively few which relate to adding comments. — Martin (MSGJ · talk) 09:15, 16 March 2016 (UTC)
In a previous job, we found that when a report was written in such a way that it was going to query most of a large table (let's call it "table_1"), we could speed up the whole process by first sending the whole table to the null device - that is, entering cat table_1 > /dev/null at the shell prompt - which forced the OS to cache the whole of table_1. The query could then run from the cache instead of the HD, with much faster access times, and less chance of a timeout. --Redrose64 (talk) 11:16, 16 March 2016 (UTC)
MathJax fails on Chrome
In my Preferences, in the Appearance tab, I have selected "MathML with SVG or PNG fallback". When browsing on Google Chrome, the MathJax fails, and all math is rendered via the SVG/PNG fallback. This issue is specific to Google Chrome on Wikipedia: when browsing Wikipedia with Firefox, Wikipedia's math renders via MathJax, and other websites with MathJax are fine when viewed with Chrome (for example, all the linked tests at https://www.tuhh.de/MathJax/test/examples.html render perfectly). --LucasBrown (talk) 03:31, 15 March 2016 (UTC)
MathJax rendering has been removed from MediaWiki some time ago. The MathML option only works on Firefox (actually using its own internal MathML engine, not MathJax), and Chrome is supposed to fall back to using PNGs. -- [[User:Edokter]] {{talk}}14:52, 15 March 2016 (UTC)
@Edokter: I believe Lucas is likely referring to the Chrome extension maintained for Mathjax since he deliberately stated which option currently existing he is using. --Izno (talk) 16:32, 15 March 2016 (UTC)
There are probably tens of thousands of minority language wikipedia articles that are not integrated into the wider interwiki linkage of more prominent languages. This is because several non-tech savvy editors find it too technical to figure out how to integrate the languages. I have even had such difficulties myself a while ago. This is a problem especially prominent among IP page creators. Therefore I propose some measures be taken to help novice editors to integrate the languages. My suggestion is to create a bot that automatically converts the old form (i.e. "en.articletitle") into the newer format. Example problem page. Hawaan12 (talk) 14:22, 16 March 2016 (UTC)
There are interwiki links in the wikicode on so:, and those were added yesterday. Aren't there bots which regularly scan articles for interwiki links and migrate those to Wikidata? --Stefan2 (talk) 16:47, 16 March 2016 (UTC)
The is introduced by {{FlagIOC}} and is indeed not working. We're doomed (I'm not in the best frame of mind to even think about fixing it). fredgandt18:27, 13 March 2016 (UTC)
There's definitely nbsps being injected into the tables, traced as far as {{Flagicon/core}} but got tired. I'll hazard that part of the reason it's not having the desired effect in this case, is because it's a text node between inside and at the end of a <span> and folowed by an <a>, in a <table> (which does all kinds of formatting things by default) - nowrapping would be better (as mentioned below). The simplest solution is simply to give the table contents a little more room to breathe. fredgandt19:37, 13 March 2016 (UTC)
This is the code emitted by {{Flaglink/core}} for each of the four countries:
<span class="flagicon">[[File:Flag of the Czech Republic.svg|23x15px|border |alt=|link=]] </span>[[Czechoslovakia men's national ice hockey team|Czechoslovakia]]
<span class="flagicon">[[File:Flag of Hungary.svg|23x15px|border |alt=|link=]] </span>[[Hungary men's national ice hockey team|Hungary]]
<span class="flagicon">[[File:Flag of France.svg|23x15px|border |alt=|link=]] </span>[[France men's national ice hockey team|France]]
<span class="flagicon">[[File:Flag of Belgium (civil).svg|23x15px|border |alt=|link=]] </span>[[Belgium men's national ice hockey team|Belgium]]
One nbsp, between flag and link, is that wrong somehow? It's not been altered since 19:59, 15 March 2015 - 364 days ago. --Redrose64 (talk) 19:50, 13 March 2016 (UTC)
No RedRose - it's fine, but tables do weird things to what is in reality a kludge anyway. The tables can be made wider or some whitespace nowrapping applied. It's just a browser fart; an edge case; HTML fun and games \o/ fredgandt19:54, 13 March 2016 (UTC)
@Koala Tea Of Mercy, Fred Gandt, and Redrose64:
I have an idea: Let's edit {{flaglink/core}} and put all this code into the nowrap: [[File:{{{flag alias-{{{variant}}}|{{{flag alias-{{{altvar}}}|{{{flag alias}}}}}}}}}|{{#if:{{{size|}}}|{{{size}}}|23x15px}}|{{{border-{{{variant}}}|{{{border-{{{altvar}}}|{{{border|border}}}}}}}}} |alt=|link=]] 213.151.215.195 (talk) 20:23, 13 March 2016 (UTC)
If anything, simply wrapping the output of flaglink/core in a span that nowraps the content gets it done. i.e.<span class="super-duper-nowrapping-class"><span class="flagicon">[[File:Flag of the Czech Republic.svg|23x15px|border |alt=|link=]] </span>[[Czechoslovakia men's national ice hockey team|Czechoslovakia]]</span>fredgandt22:38, 13 March 2016 (UTC)
User:Redrose64, the flag and the name of Czechoslovakia are divided into two lines, see this table. My idea is to "glue" a flagicon with following NBSP, because currently it's not possible. In my contribution above, you can see the exact procedure – nowrapping of flagicon+NBSP. And the result would be: flagicon+NBSP+text as a single non-breakable word, and the width of that table would be automatically adjusted. 213.151.215.195 (talk) 23:39, 13 March 2016 (UTC)
No it wouldn't 213.151.215.195 - see my contribution above - the entire output needs to be wrapped in nowrap, not just the first part up to the nbsp.
Redrose - I fixed the table - see above - it was line-broken. Remove the table white-space styling in your browser's inspector to see. fredgandt23:58, 13 March 2016 (UTC)
Or see the other example 213.151.215.195 just linked to. fredgandt
Screenshot: Screenshot of Wikipedia table exhibiting a display error (not a bug) under discussion. I had to update Firefox to be sure. Was broken in v38.? and in whatever version of IE I have and in Chrome (my default). Perhaps using XP (yikes!) has an effect? Whatever the case, here's the unnecessarily complicated proof that two people aren't tripping or lying. As 213.151.215.195 and I suggest, the solution is nowrapping the output, so the nbsp gets glued to the rest of the output (one way or another) so the nbsp actually does what it's supposed to do (although with my method, the nbsp isn't even needed). fredgandt01:07, 14 March 2016 (UTC)
And if you don't want to do that, just remove the width= attributes from the table. They're rarely necessary, and make all sorts of assumptions about the user's display, not least of which is that everybody is using the same font family, font width, etc. If you don't know the font characteristics, you don't know how wide a given piece of text will be, so you don't know what size of table cell will contain it. --Redrose64 (talk) 14:50, 14 March 2016 (UTC)
@Edgars2007, Fred Gandt, and Redrose64:
Definitely it's a bug. NBSP is not working after any picture. See this example: (picture+NBSP+text) HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
NBSP is under the picture. What are we going to do about it? 213.151.215.195 (talk) 12:37, 16 March 2016 (UTC)
does not work like that. It only glues text together, not any other HTML element (and anchor containing the image in this case). As said above, a nowrap span is the best solution (and then it doesn't even need an inside). -- [[User:Edokter]] {{talk}}13:11, 16 March 2016 (UTC)
No, that still makes the fatal assumption that what you are constructing will fit into the available width, which you cannot do when there is a forced width going on, which is what the attributes like width="120" are doing. The solution is to ensure that the table columns are not too narrow for anything that might be shoehorned in, and the best way of doing this is by not setting the widths explicitly. That will avoid any need for nbsp, nowrap or odd techniques with CSS. --Redrose64 (talk) 14:52, 16 March 2016 (UTC)
It appears that the nbsp is not supposed to act as glue at all, but rather is just to ensure the space for accessibility (i.e. alt-text text-text). What Redrose says is completely right, and what I and several others have said about nowrapping is also completely right. The tables should be free to breathe by removing the restrictions, and IMO the output should be nowrapped so a consistent inline output is observed everywhere - and anywhere the nowrapping doesn't fit, it's because the HTML is restrictive - as in the specific tables in this example. The addition of a <wbr> would solve the occasional "eep!"fredgandt18:40, 16 March 2016 (UTC)
Open call for Individual Engagement Grants
Hey folks! The Individual Engagement Grants (IEG) program is accepting proposals from March 14th to April 12th to fund new tools, research, outreach efforts, and other experiments that enhance the work of Wikimedia volunteers.
Whether you need a small or large amount of funds (up to $30,000 USD), IEGs can support you and your team’s project development time in addition to project expenses such as materials, travel, and rental space.
What to do about tens of thousands of unnecessary parser functions on user talk pages?
The template {{Welcome to Wikipedia}} was poorly coded for a substantial length of time (now fixed), which resulted in large quantities of unsubstituted parser functions being added to many user talk pages.
This search suggests possibly thousands of pages being affected, and those that are, will have around eleven nests of 1 * parser function acting on the result of 1 * module invocation.
If only half the total user talk pages from that search have 10 of these nests each, that's around 100,000 unnecessary wastes of server resources! This guesstimate is ballpark.
Prior to the poor coding, the template was not leaving unresolved parser functions behind, the wording of the substed result has been altered over time, and unfortunately my suggestion to add a tracking link years ago went down like a lead balloon - so it isn't trivial to find the broken ones (manually).
So, with that said, I ask:
Should these stray and unnecessary parser functions out in the wild, be fixed?
To do it manually would be insensible; is there a currently approved bot that can be tasked to do the work?
Would it be acceptable to set about fixing these things by use of the API in a semi-automated fashion?
I'm no technical expert, but my understanding is that simply "fixing" these by removing the parser functions with a new edit doesn't save any server resources whatsoever, since the "bad" edit is kept in memory anyway. Now, if having those parser functions (whatever they are) is doing something bad (as opposed to just taking up space), that could be an argument for getting rid of them, but that doesn't seem to be the argument you're making. In any event, I could well be entirely wrong, so let's see what someone more technically knowledgeable than I has to say about it. BMK (talk) 02:55, 11 March 2016 (UTC)
We shouldn't generally be worried about using server resources, and I don't think the module calls and parser functions would increase the time for the page to be parsed by very much anyway. The main advantage is that by expanding the parser functions etc. you are guaranteed to have the same text on the page each time. As it is, changing Module:IPAddress would change the text that was displayed on those talk pages. There is also the fact that it makes the page's wikitext easier to understand, which is likely to be more helpful for newcomers. — Mr. Stradivarius♪ talk ♪05:41, 11 March 2016 (UTC)
It would be significantly more disruptive to edit all those pages to expand those parser functions than whatever downside they currently have. Even if you use a bot account to suppress new messages notifications, you'd still be adding watchlist entries and whatnot. Legoktm (talk) 06:03, 11 March 2016 (UTC)
<!--
NewPP limit report
Parsed by mw1255
Cached time: 20160311084804
Cache expiry: 3600
Dynamic content: true
CPU time usage: 0.499 seconds
Real time usage: 0.748 seconds
Preprocessor visited node count: 8919/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 61821/2097152 bytes
Template argument size: 18596/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 9/500
Lua time usage: 0.054/10.000 seconds
Lua memory usage: 1.75 MB/50 MB
Number of Wikibase entities loaded: 0-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 344.405 1 - -total
22.24% 76.588 11 - Template:Category_handler
16.33% 56.250 1 - Template:Flatlist
15.32% 52.777 9 - Template:Lang
15.29% 52.670 17 - Template:Xt
13.81% 47.559 1 - Template:Citation_needed
10.76% 37.046 45 - Wikipedia:Signpost/Template:Cover-item
9.29% 31.997 1 - Template:Fix
7.98% 27.500 1 - Template:Lafc
6.36% 21.894 50 - Template:Ping
-->
<!-- Saved in parser cache with key enwiki:pcache:idhash:47307636-0!*!0!!en!3!* and timestamp 20160311084803 and revision id 708865513
-->
After
<!--
NewPP limit report
Parsed by mw1239
Cached time: 20160311085217
Cache expiry: 3600
Dynamic content: true
CPU time usage: 0.475 seconds
Real time usage: 0.725 seconds
Preprocessor visited node count: 8831/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 61371/2097152 bytes
Template argument size: 18596/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 9/500
Lua time usage: 0.036/10.000 seconds
Lua memory usage: 1.57 MB/50 MB
Number of Wikibase entities loaded: 0-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 297.007 1 - -total
20.72% 61.548 11 - Template:Category_handler
15.72% 46.687 17 - Template:Xt
15.15% 44.988 1 - Template:Flatlist
14.20% 42.177 1 - Template:Citation_needed
14.17% 42.085 9 - Template:Lang
12.96% 38.479 45 - Wikipedia:Signpost/Template:Cover-item
9.06% 26.906 1 - Template:Fix
8.76% 26.011 1 - Template:Lafc
7.93% 23.553 50 - Template:Ping
-->
<!-- Saved in parser cache with key enwiki:pcache:idhash:47307636-0!*!0!!en!3!* and timestamp 20160311085217 and revision id 709504667
-->
Multiplied by an guesstimated minimum of 5000 pages = significant IMO.
Aside from the performance concerns, Mr. Stradivarius makes a fair point that the intended result of these clusters of code isn't reliable. fredgandt09:11, 11 March 2016 (UTC)
Exactly what is being saved here? Hundredths of a second? Considering that user talk pages aren't heavily trafficked to worry about saving a few hundredths of a second, it simply isn't worth the trouble. —Farix (t | c) 12:31, 13 March 2016 (UTC)
I agree with Farix: it's not worth the trouble. Since the traffic is so small, and the number of pages affected also small relative to the overall size of the Wikipedia page set, I think this is not a significant enough issue to be worth going back and fixing retroactively. We have far bigger problems that need fixing more urgently than this. Having said which, if you want to go write a bot to fix this, I won't object to your doing so -- but please note that it's unlikely to save any significant amount of resources relative to overall use. -- The Anome (talk) 12:50, 13 March 2016 (UTC)
Although the ms savings per page seem relatively tiny, if we say 5000 pages * edited twice per month * 24ms of CPU time = 4 minutes of CPU time per month for nothing.
Even if only in principle, I think the saving is worth the effort. If I build a bot to resolve wild parser functions (don't hold your breath), should I make it specifically for this set or include an option to train it for other cases? fredgandt14:05, 13 March 2016 (UTC)
"Saving" 4 minutes a month of CPU time is woefully insignificant compared to the number of hours you will take to create, test, and execute a bot to "fix" these parser calls wasting far more CPU time than you are "saving". And I serous doubt that 4 minutes is anything but a gross over estimation of the amount of time it takes to render these pages. If you are worried about 4 minutes per month, then I must point you to Wikipedia:Don't worry about performance. —Farix (t | c) 14:34, 13 March 2016 (UTC)
I've already been pointed at wp:PERF and read it, and point you to the last three significant sections. The hours I spend doing anything is entirely my concern; what's relevant here is whether to clean a little unnecessary muck from the gears or not? A simple question which doesn't need to be so aggressively challenged. You've stated you opposition, and it's been read. fredgandt14:57, 13 March 2016 (UTC)
@Fred Gandt: The performance aspect is more complicated than it first seems. Wikipedia pages are parsed on WMF clusters, and the various computers involved are connected by (very fast) network connections, so any network delay will affect the result. There may be other overhead involved as well - I'm not sure of the details. The upshot of this is that the same page will typically take a slightly different time to parse each time you try it. When I tried previewing the current version of User talk:Peppy Paneer three times, I got CPU time usages of 0.801s, 0.532s, and 0.539s, and real time usages of 1.066s, 0.772s, and 1.417s. To find useful numbers, you would have to parse the page a lot of times (say 100) and take an average. Also, these numbers only matter when someone edits the page - when someone is just viewing the page, they get served a cached version.
Furthermore, the important number is the time taken to save one page, not the time it would take to save all of those pages. A typical user would not notice if a page takes a few milliseconds longer to save than usual (the perceptual limit is about 0.1s), but if it takes a few seconds longer, then it will feel noticeably sluggish. On the other hand, if all of the pages need to be parsed (for example, because someone edited Module:IPAddress), then this will happen in the background, and users aren't likely to notice either a few extra milliseconds or a few extra seconds per page. — Mr. Stradivarius♪ talk ♪05:16, 16 March 2016 (UTC)
@Mr. Stradivarius: I understand the caching and tiny irregular numbers, and that's why I didn't overblow my guesstimation sum. Even a low number of changes to a high number of pages wasting a measly few milliseconds all add up to lots of wasted time. Anyway, and don't take this as being stroppy, I'm clearly pretty much on my own here, so consensus being what it is, I accept the answer to my question as being "don't worry about it". I will however continue to worry about it, but not mention it again. I will suffer in silence fredgandt18:50, 16 March 2016 (UTC)
And I'm totally admiring your focus, Fred. Something's intuitively & evidentially wrong and you wish to fix it. That absolutely works for me. There's an interesting academic consideration, which is, by when will the cost of fixing be paid back by the benefit. And there are other opportunity-cost arguments that could be raised, for instance in whether your talents might be employed on higher-value fixes. But in the scheme of things, they're both angel-on-heads-of-pins noise. Per WP:PERF, wikipedia clearly has sufficient performance resources to afford the fix being made. You're motivated to do the work. In some long term, it may well be a beneficial change measured in simple resource utilisation terms - whether or not it is in any way noticable for practical purposes. That all seems very positive, and I'm not seeing a downside. You ask "If I build a bot to resolve wild parser functions (don't hold your breath), should I make it specifically for this set or include an option to train it for other cases?" then clearly the latter is to be preferred. I want a wikipedia where people obsess over the smallest of details & make themselves experts in obscure corners. So carry on. Get it fixed. (And yes: the final three sections of WP:PERF clearly support action being taken.) --Tagishsimon(talk)23:51, 16 March 2016 (UTC)
however, there is insufficient evidence that such a change will make any difference: taking the 2 datapoints in earlier in this thread, one can see that the 2nd one shaved 8 ms off the lua execution (which is the kernel of the change), and at the same time it also shaved 15 ms off "Template:Category_handler", and 11 ms off "Template:Flatlist" - both of which have nothing to do with the change, as far as i understand.
IOW, it is more likely that the diff between the 2 runs is a result of natural variance, than that it's a result of the proposed change.
out of curiosity, i ran "action=purge" on the same page (which User:Fred_Gandt have "manually fixed"), and looked at the times. i got the following numbers: 538, 709, 731, 451 and 613 ms in 5 consecutive tries. it is clear that the variance between purges far exceeds the claimed gain, which means that the "gain" may be 3 times what Fred claims it is, but it may also be 0, or even negative. peace -קיפודנחש (aka kipod) (talk) 00:22, 17 March 2016 (UTC)
Okay then - However, since AnomieBOT (@Anomie:) is already out there substing templates, I doubt the value of reinventing this particular wheel. If it's agreed that (for whatever reason) these should be fixed, tasking a preexisting and proven bot with the job seems prudent. And, thank you Tagishsimon; I enjoyed reading that :-)
I'm afraid I have no inarguable technical response for kipod or their concerns. I admit to being biased in favour of fixing no matter what the numbers say, simply because there's no way more computation per page can be faster than less,[Citation needed] and moreover, if this were my site, there'd be no question and they'd all be fixed already. The actual numbers will vary - perhaps even wildly. However, again, thousands of instances smooth the graph so to speak. fredgandt01:35, 17 March 2016 (UTC)
Discussions
Is there a template or magic word that provides the total number of discussions that exists on a talk page? (For example, running it with this page as this instance would return 26). Alex|The|Whovian?03:16, 17 March 2016 (UTC)
27 <h2> sections including this one. I don't know of anything that counts sections accept the ToC, or any way except JavaScript to do it. I'm just beginning to adjust to Lua, so don't know its capabilities or limits yet. The immediate difficulty is the arbitrary nature of the definition of "discussion" since in this page, threads have split, and merely counting the h2s doesn't give a complete picture. fredgandt03:39, 17 March 2016 (UTC)
It wouldn't be hard to make a Lua module that counts lines on a page that start and end with "==", but it would be considerably more difficult to make one that would do things like respect nowiki tags and HTML comments, and find section headings added by templates, etc. Also, a Lua version would not work properly on preview, as it would always use the latest saved version of a page rather than the version being previewed. While you could probably throw something together that might work most of the time, it might be better to do this with a gadget or a bot, depending on what it is needed for. — Mr. Stradivarius♪ talk ♪04:47, 17 March 2016 (UTC)
Wow. That's amazingly helpful and kind. Thank you Mr. Stradivarius :-) I had a feeling I was going to like you (don't be creeped). That's a powerful possibility too. I haven't played yet, and am currently past bedtime so will wait 'till tomorrow, but recall seeing somewhere about getting or parsing different forms of content (which now makes more sense). If we can get the content of multiple pages, the mind practically boggles! And back to earth, this section counter should be a relative doddle - perhaps a fun learning project \o/
I was thinking about this whilst walking my dog, and think it would be trivial to include as an extension that might then be adopted into the MW core to allow {{NUMBEROFSECTIONS[:2]}}.
JavaScript can be simply: document.getElementById( "mw-content-text" ).getElementsByTagName( "h2" ).length - !!document.getElementById( "toctitle" ); (most of the time). fredgandt07:31, 17 March 2016 (UTC)
I simply wanted to get an automatic counter on how many discussions I had archived from my talk page. If it's possible, great; if not, then so be it. Alex|The|Whovian?07:51, 17 March 2016 (UTC)
If you don't already know this: You can run JavaScript in your browser's (most browsers) console which can be opened via its menu or by a keypress shortcut. In the case of Google's Chrome browser, access by Ctrl+Shift+J and then paste the code I just posted and hit ↵ Enter. The number of level 2 sections on the current page will be returned in the console. Extra code would be needed to fetch the numbers for other pages.
If you already knew that, maybe someone else passing by didn't, so no harm.
If you wanted a way to show other people by printing the number under the archive box on your talk page where it currently says 319 automatically after each archive operation - we're talking about an expensive magic word being needed that will fetch the stats for other pages, unless Lua can do that too. A specific alternative in this case might be for the archiving bot to edit the counter while it's there. Lowercase sigmabot IIIfor example expresses the number of discussions it archives in the summary, so it should be trivial to have it add that info to a target on the page it's already editing. fredgandt08:41, 17 March 2016 (UTC)
Rather than count the sections, or the <h2>...</h2> elements, how about some JavaScript to process the rendered page, and look inside the <div>...</div> element which has the attribute id="toc"? The highest section number can be extracted from the contents of this. Each enclosed <li>...</li> element has two classes, a toclevel-n class and a tocsection-n class. Ignore the latter, it is a simple progressive number and increases by 1 for each section or subsection. Look for the last <li>...</li> element which is of class toclevel-1 - at the moment, the last one on this page is
From that, extract the <span>...</span> element of class tocnumber, and the content of that element is the highest section number - 28. --Redrose64 (talk) 11:21, 17 March 2016 (UTC)
Hi! Would some kind soul take a look at Hipparchicus to see why the link to the translation on Perseus from the infobox doesn't correctly display the page title? It's probably some obvious mistake on my part, but I can't find what I've done wrong. Many thanks, Justlettersandnumbers (talk) 19:16, 17 March 2016 (UTC)
I was trying to use the the Interaction Check ([63]) and it seems that it's not working properly. It doesn't seem to be picking up edits from a while back. For example, Carolmooredc and I interacted quite a bit, but since her ban she's been inactive... the interaction checker shows no interaction though ([64]). I am unsure if this is just on my end or something is not working properly. Please advise (and please ping me in reply). EvergreenFir(talk) Please {{re}} 06:26, 17 March 2016 (UTC)
This was reported in the past month or two, but I'm not sure exactly where. It's probably not just you, unless you were that reporter. --Izno (talk) 11:32, 17 March 2016 (UTC)
Regulars here may recall that Ops is planning to temporarily put all the wikis into read-only mode when they're launching the new data center in Texas during the week of 21 March. Here are a few more details:
What to expect
The read-only disruption will happen TWICE, once on Tuesday, 22 March (at the start of the tricky bits) and once on Thursday, 24 March (at the end of the tricky bits).
There will probably be a five-minute test of read-only mode next week. Details are being discussed.
The time of day has not been determined yet. Ops normally does things during low traffic periods, so my guess is approximately 07:00 UTC (midnight in California).
The read-only mode for the actual event will probably last 15 to 30 minutes each time (longer than initially hoped for, but this estimate sounds more realistic). If you try to edit or save during this time, then you'll get an error message about the wiki being in read-only mode (not the 'blue screen of death').
If you get that error message when trying to save the page, just hang on; you should be able to save your edit once everything's back to normal. (But please make a copy first, just in case it fails.)
Bots and scripts may need to be restarted afterwards. Some pages may need to be purged (or just wait a bit for the jobs to catch up), e.g., if you see a redlink but the page was recently created.
Communications issues
If you are a regular on the IRC channels, please be prepared for lots of people reporting the "unexpected outage". It might be a good idea to change the headers during these events to let people know what's going on. I hope to get an explanation for this project posted soon, so a link to that might help.
I'm working on CentralNotices and MassMessages to all the wikis.
I'd like to see watchlist notices up at the bigger projects, starting approximately now. What do you all think of that idea?
We can certainly watchlist notice this - is there a good link to a page describing the activity, etc (besides this?). — xaosfluxTalk17:00, 10 March 2016 (UTC)
Xaosflux, there's no useful page at the moment, but I hope that one will be available soon. There's a Phab project, and various pages on mw.org that discuss technical aspects of it, but there's nothing in plain English or intended for humans. What do you think about a watchlist notice that says something like this:
Wikimedia Technical Operations is planning a major infrastructure migration on Tuesday, 22 March and Thursday, 24 March. This process is expected to take 15 to 30 minutes each time. During these times, you will be able to read, but not edit any page. We apologize for the disruption.
Vaguely related question: I had understood that the servers were in Florida, does this mean they will all then be in Texas? And, if so, does that have any legal ramifications for us as editors, or is state law not relevant and only Federal law is controlling? BMK (talk) 02:59, 11 March 2016 (UTC)
IMHO, now you could post some small notice, that it will happen (in case, there are some planned editathlons etc.). Some watchlist notices, big notification in pumps and other things could be done some few days before the thing. Because if the only sent message will be now (11 days before it will happen) most people will forget it. --Edgars2007 (talk/contribs) 09:33, 11 March 2016 (UTC)
BMK, I'd have to ask, but I believe that the main servers are in Virginia. There are also some in Amsterdam and California. I'm not sure that there are any servers in Florida.
You are correct. I had a chance to ask about the setup, and I have learned the following: The main data center is in Virginia. The new one in Texas (this whole thing about temporarily not being able to edit has to do with work on the new one) is going to be a full copy of the main data center. The other two are cacheing servers. The one in Florida was dismantled a while ago. The basic idea with this process is to make everything (or everything they can, since the new data center doesn't have quite everything yet) run from the Texas data center for two days, and then to go back to Virginia. They have multiple reasons for doing this, but it's also good for disaster recovery – sort of like making sure that you can actually restore from a backup if you needed to, rather than waiting until your computer dies and then discovering that your backup drive failed, too. A tornado in Virginia could wreak a lot of havoc on Wikipedia, and we'd all like the servers to get back up and have Wikipedia be editable ASAP after that.
RESTBase et al. (Parsoid, the Mobile Content Service, CXServer, Mathoid, Citoid, Apertium and Zotero) will probably make this switch on Thursday, 17 March, around approximately 10:00 UTC. Ops believes that we should expect an uptick in the number of error messages (such as 404 and 504 pages) when that happens. Whatamidoing (WMF) (talk) 19:12, 14 March 2016 (UTC)
Nope, this one happened on the original schedule. It's ElasticSearch that's been postponed (and should be even less noticeable than this one). Whatamidoing (WMF) (talk) 02:18, 18 March 2016 (UTC)
). You'll get a fly-out from the left that has the option to login. Keegan (talk) 23:17, 11 February 2016 (UTC)
Resolved
Done - recreated to fix the content model. — xaosflux Talk 18:44, 13 February 2016 (UTC)
Administrator note adding directly to archive because someone may come searching for this one day Special:ChangeContentModel is now available for admins to fix these directly. — xaosflux Talk 18:30, 16 March 2016 (UTC)
--LZia (WMF) (talk) 03:40, 11 February 2016 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 February. It will be on non-Wikipedia wikis and some Wikipedias from 17 February. It will be on all wikis from 18 February (calendar).
The Holy Roman Empire, 1789
German Confederation, 1815-1866
Germany (Deutsches Reich), 1871-1918
Germany (Deutsches Reich), 1919-1937
Nazi Germany, 1944
-de.svg)
You can join the next meeting with the Architecture committee. The topic this week is Assign RFCs to ArchCom shepherds. The meeting will be on 24 February at 22:00 (UTC). See how to join.
czar 06:56, 22 February 2016 (UTC)
Only "subst:" or "lc:" should be able to get found as responisble as switch is working properly for sure, or some definitions inside "no", or I am missing something obvious...
, (2) is signed
, (3) diffs as + text. Adding to an old signature fails (2) and (3)... it's an unsigned edit which diffs as a - + modification to existing text. To avoid spam, ping fails if more than 50 pings would be generated. I think it fails if the edit is not restricted to a single section. Alsee (talk) 13:34, 3 March 2016 (UTC)
There is currently an edit request at Template talk:Protected page text. Thank you. -- SLV100 (talk) 03:21, 14 March 2016 (UTC)
(I'm not in the best frame of mind to even think about fixing it). fredgandt 18:27, 13 March 2016 (UTC)
.png&action=edit&redlink=1){kind=link}
/Archive_144#c-Jo-Jo_Eumerus-2016-03-07T18:17:00.000Z-Incorrect_protection_level_category_on_File:AnonEditWarning.svg){kind=link}
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH