# Wikipedia:Village pump (technical)/Archive 144

## "Keep me logged in for up to 30 days" not working

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)

I've been having to log in again every couple of weeks on the same computer. DuncanHill (talk) 09:39, 10 February 2016 (UTC)
This is because of phab:T124440. I myself have been forced out three times. --Redrose64 (talk) 09:55, 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)
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 (talkcontribs) 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 (talkcontribs) 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)
Ok, that's fine. Thanks everyone. Keep up the good work. Nurg (talk) 07:10, 11 February 2016 (UTC)
• I've been getting a lot of "cannot complete edit because of loss of session data" today. Is this related? DuncanHill (talk) 13:12, 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)

This also seems to be affecting STiki. Flyer22 Reborn (talk) 08:29, 12 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)

## Watchlist not showing all edits

For it shows a reversion of vandalism today[1] but not the vandal's edits.[2] Doug Weller talk 15:17, 12 February 2016 (UTC)

It works for me. Maybe you are hiding anonymous users or only showing the most recent edit. See Help:Watchlist#Options and Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 16:38, 12 February 2016 (UTC)
Thanks, but I checked all those before coming here. I'll see if it happens again. Doug Weller talk 19:25, 12 February 2016 (UTC)

## Harv error shows in Chrome in edit preview

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 (talkcontribs) 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:
1. ^ 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 (talkcontribs) 21:40, 9 February 2016 (UTC)
@Aymatth2: The red error message is because you did this in May 2014. More information at User:Ucucha/HarvErrors. --Redrose64 (talk) 23:32, 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)
@Aymatth2: re Is there a place I can upload a screenshot of this? – you can upload screenshots to Wikipedia or Commons, see WP:WPSHOT for info - Evad37 [talk] 05:05, 10 February 2016 (UTC)
• 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)

• 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#wikiPreview ol.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#wikiPreview span.reference-text strong.error,
div#wikiPreview span.reference-text strong.warning {
display: none;
}

Whichever one you choose to go with, put it in Special:MyPage/common.css. These rules are only effective in preview mode: they will not affect the display of references when viewing pages normally. --Redrose64 (talk) 16:58, 11 February 2016 (UTC)
• 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
.mw-ext-cite-cite_section_preview_references{display: none;}

to hide the ref section completely in section preview. Or
/* hide Harv errors and warnings in preview mode */
.mw-ext-cite-cite_section_preview_references span.reference-text .error,
.mw-ext-cite-cite_section_preview_references span.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)

### Harv error (break)

@Cenarium: I tried the first option, adding

.mw-ext-cite-cite_section_preview_references{display: none;}


to User:Aymatth2/common.css, and the result was strange:

I got this even after closing Chrome and restarting. I blanked common.css, tried again, and as expected got:

Chrome under Windows 10. No idea what is wrong. The last-line-new-para bug is fixed. Aymatth2 (talk) 21:18, 11 February 2016 (UTC)

Looks like the rendered html on WMF wikis is not the one I had expected from local testing. You can add

Hence the line

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

The page Curation tool tracks these pages. Graham87 11:42, 28 February 2016 (UTC)
You can also filter for the tag "de-userfying" on Special:RecentChanges. – nyuszika7h (talk) 12:02, 28 February 2016 (UTC)
Ah perfect! Just what I needed. Thanks a lot! - HyperGaruda (talk) 12:04, 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)

I assume that it's deleted manually, which would mean that this isn't a technical issue. עוד מישהו Od Mishehu 12:44, 28 February 2016 (UTC)
Yes it would. But I still don't know. Any suggestion for a better place? Thanks. Martinevans123 (talk) 13:00, 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 also replied at m:Talk:Meetup/Liverpool/18#Banner. --Redrose64 (talk) 13:41, 28 February 2016 (UTC)

## Template malfunction?

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.

Example Alpha
Caused by
• A
• 1
• 2
• 3
• B
• 1
• 2
• 3
• C
• 1
• 2
• 3
Resulted in
• X
• 1
• 2
• 3
• Y
• 1
• 2
• 3
• Z
• 1
• 2
• 3
Example Beta
Caused by
• A
• 1
• 2
• 3
• B
• 1
• 2
• 3
• C
• 1
• 2
3
Resulted in
• X
• 1
• 2
• 3
• Y
• 1
• 2
• 3
• Z
• 1
• 2
• 3

Mitchumch (talk) 00:36, 28 February 2016 (UTC)

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:
Extended content
<table class="infobox vevent" style="width:22em;width: 300px"><tr><th colspan="2" class="summary" style="text-align:center;font-size:125%;font-weight:bold;font-size: 125%; background-color: #CEE0F2; vertical-align: middle">Example Alpha</th></tr><tr><th scope="row">Causes</th><td>
*A
**1
**2
**3
*B
**1
**2
**3
*C
**1
**2
**3</td></tr><tr><th scope="row">Result</th><td>
*X
**1
**2
**3
*Y
**1
**2
**3
*Z
**1
**2
**3</td></tr></table>

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:
*C
**1
**2
**3
&nbsp;

But perhaps someone else can think of a more elegant way of doing it. — Mr. Stradivarius ♪ talk ♪ 03:44, 28 February 2016 (UTC)
Come to think of it, doing this with HTML list markup would work. Probably the easiest way would be by using {{bulleted list}}:
{{bulleted list
|A {{bulleted list|1|2|3}}
|B {{bulleted list|1|2|3}}
|C {{bulleted list|1|2|3}}
}}

In an ideal world I would fix the template itself, but I think that may be difficult to do without affecting the way it displays on other pages. — Mr. Stradivarius ♪ talk ♪ 04:07, 28 February 2016 (UTC)
That insight works for me. Thank you. Mitchumch (talk) 05:11, 28 February 2016 (UTC)
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")
*C
**1
**2
**3
<div></div>

-- George Orwell III (talk) 06:39, 28 February 2016 (UTC)
Good point. <nowiki /> would also do the trick. — Mr. Stradivarius ♪ talk ♪ 07:49, 28 February 2016 (UTC)
The dummy character can be something as simple as &#32; or &#x20; - 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:
1. First cause
1. First sub-cause
2. Second sub-cause
3. Third sub-cause
2. Second cause
but you can get letters for the outer lists by mixing Wikimarkup with HTML -
1. First cause
1. First sub-cause
2. Second sub-cause
3. Third sub-cause
2. Second cause
1. First result
1. First sub-result
2. Second sub-result
3. Third sub-result
2. Second result
More on the HTML markup for ordered lists is at HTML5 section 4.4.5 The ol element. --Redrose64 (talk) 13:55, 28 February 2016 (UTC)

## Double redirect bots

It is still taking double redirect bots over 3 days to fix double redirects. Does anyone out there know why this is the case? Please ping me when you respond. --Jax 0677 (talk) 14:25, 23 February 2016 (UTC)

• Comment - I think that a "first in first out" methodology should be implemented in order to make this happen. --Jax 0677 (talk) 20:33, 25 February 2016 (UTC)
@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."
Discuss this special page at Wikipedia talk:Special:DoubleRedirects; maybe that's where you can ask and find out why it isn't updated more frequently. I'm curious to know the answer myself. – wbm1058 (talk) 21:27, 28 February 2016 (UTC)

## Regex

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

but when one of them is in correct place regex works wrongly

how to solve this bug?--ԱշոտՏՆՂ (talk) 11:53, 28 February 2016 (UTC)

@ԱշոտՏՆՂ: 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)
Thanks Nihiltres. Will this work with many refs? Or named refs? ԱշոտՏՆՂ (talk) 21:34, 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 also was looking for such regex. --Edgars2007 (talk/contribs) 06:16, 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) ## Weird URL after redirect 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) The question mark is apparently being interpreted as the start of a query string in [25] by User:Matma Rex. It says: "The code also supports forwarding query parameters like 'debug=1'." PrimeHunter (talk) 11:24, 29 February 2016 (UTC) That's funny, I'll investigate. Filed as T128380. Matma Rex talk 15:32, 29 February 2016 (UTC) ## Tech News: 2016-09 20:12, 29 February 2016 (UTC) ## Yesno/subst and case sensitive »['abc'] = {'def', 'eXample', 'ghi'},« or not 1. Why is • {{#ifeq:{{yesno|{{{df|yes}}}}}|yes|{{#expr:{{{3}}}}}. {{MONTHNAME|{{{2}}}}}|{{MONTHNAME|{{{2}}}}} {{#expr:{{{3}}}}},}} {{{1}}}. год. not giving same result as • {{#ifeq:{{yesno|{{{df|yes}}}}}|no|{{MONTHNAME|{{{2}}}}} {{#expr:{{{3}}}}},|{{#expr:{{{3}}}}}. {{MONTHNAME|{{{2}}}}}}} {{{1}}}. год.*? 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... 2. 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? --Obsuser (talk) 07:57, 29 February 2016 (UTC) 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) (edit conflict)@Obsuser: Why did you create it as a subtemplate of {{yes}}? 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. Are those names in Lua case sensitive?--Obsuser (talk) 22:07, 29 February 2016 (UTC) Which names? --Redrose64 (talk) 23:05, 29 February 2016 (UTC) 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}}? One "real-life" example: • ['MessageID'] = {'message-id', 'messageid', 'message-ID', 'messageID', 'порука-ид', 'порукаид', 'порука-ИД', 'порукаИД', 'порука-id', 'порукаid', 'порука-ID', 'порукаID', 'poruka-id', 'porukaid', 'poruka-ID', 'porukaID'},. 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 To your last q: as twice noted above by PrimeHunter, see Template:Yesno#Customizing the output - it's |blank=. --Redrose64 (talk) 07:30, 1 March 2016 (UTC) ## Page view dates 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) What "new page view graph page"? Most of Wikipedia does not use d-m-yyyy, that goes against WP:DATESNO. --Redrose64 (talk) 18:26, 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) European style dates as described in MOS:DATE do not have hyphens. Nor do American style. --Redrose64 (talk) 18:56, 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". 22: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? Simply south ...... time, deparment skies for just 9 years 12:33, 28 February 2016 (UTC) 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.
Hope that helps. Quiddity (WMF) (talk) 19:09, 1 March 2016 (UTC)

## Archive bot issue

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)

There was an error in the archiving template. I have corrected that to start. --Izno (talk) 14:12, 1 March 2016 (UTC)
And now I've fixed the minimum threads issue. --Izno (talk) 14:15, 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)
Thought I was fixing the problem but, still have a page that needs deleting :P 18:08, 1 March 2016 (UTC)
Done. Graham87 10:23, 2 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)

## Inspire Campaign: Making our content more meaningful

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 Filly Neigh 02:19, 2 March 2016 (UTC)

Which pages does this happen to you at? עוד מישהו Od Mishehu 06:11, 2 March 2016 (UTC)
Probably the same issue discussed above at #Mobile talk page bug? — This, that and the other (talk) 08:25, 2 March 2016 (UTC)
I would agree. 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 Filly Neigh 00: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:

1. 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.
2. 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.

i suggest doing #1 now. peace - קיפודנחש (aka kipod) (talk) 00:59, 2 March 2016 (UTC)

phab:T43327 has a few blockers, but ultimately we'll have something natively through mw:Extension:WikimediaPageViewInfo. See a demo here. Adding the graph to action=info in the interim isn't a bad idea, though, if others are in support 01:27, 2 March 2016 (UTC)
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 -