Cannabis Indica

thcscience_admin
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.
« Older discussions, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145
Centralized discussion
Proposals: policy other Discussions Ideas
Note: inactive discussions, closed or not, should be archived.


Unresolved issue is archived - How to "UN-Archive"?[edit]

Greetings, A problem awaiting resolution is now archived here and tracked at phabricator:T126553.

If it's not possible to pull back from archive, does it need to be re-posted again?

Regards,  JoeHebda (talk)  19:04, 27 February 2016 (UTC)

@JoeHebda: Just post the new question, with a link back to the archived thread. --Redrose64 (talk) 21:39, 27 February 2016 (UTC)
If I re-post again here, will it be archived again before the issue is solved? Just wondering... JoeHebda (talk)  02:19, 29 February 2016 (UTC)
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)
Redrose64 – Thanks for the update. Yesterday I did repost the new VPT archive link to Wikipedia talk:User scripts#Fix needed: Gadget only works with Vector skin, script error which was orginally posted on Feb. 15th. Wondering if there might be a better place to post where the issue can be fixed? Without waiting for months for a resolution? If I knew anything about scripts (which I do not) I would attempt to fix myself. Regards,  JoeHebda (talk)  13:39, 29 February 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 1) ω Awaiting a solution – also see: MediaWiki:Gadget-mobile-sidebar and Wikipedia:Gadget.  JoeHebda (talk)  13:45, 29 February 2016 (UTC)

@JoeHebda: You can use {{DNAU}} to prevent archiving. nyuszika7h (talk) 21:26, 29 February 2016 (UTC)

2) ω Awaiting a solution — JoeHebda • (talk) 12:08, 2 March 2016 (UTC)

3) ω Awaiting a solution — JoeHebda • (talk) 18:12, 3 March 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):
importScript('User:קיפודנחש/mobile-sidebarcopy.js');
(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)

Strip marker problems with nowiki tags[edit]

Whence came the oddness in infobox television episode?[edit]

Example 1
Above
Header
Example 2
Above
Header

Compare the infobox formatting in The Foretelling and The Archbishop - the title in the blue header in the infobox is larger and horizontally-centred in the latter (which is correct), but smaller and left aligned in the former (which is wrong, I think). I've recently made an (unrelated) edit to The Foretelling, so presumably it's showing the change there because the caches were flushed by my edit. Test editing The Archbishop shows the same defect in it, were it to be saved. The infobox by itself, in my sandbox, has the defect. So I think there's something gone wrong with the infobox template(s). That infobox is {{Infobox television episode}}, which depends on {{Infobox}}. I don't see a relevant change in the history of either. It's a pretty subtle change, so I can well understand how it can have been overlooked for some time. Can anyone see what might be causing this? -- Finlay McWalter··–·Talk 14:30, 11 March 2016 (UTC)

Oddly, the issue is caused by the addition of {{abbr}}. See the current sandboxed version utilising the HTML entity &period; in place a a natural period character - Template:Infobox television episode/sandbox. This appears to be the fix. I would appreciate confirmation from other editors before pushing the change live. fredgandt 14:57, 11 March 2016 (UTC)
Request placed at the template talk page - awaiting feedback. Albeit a seemingly trivial change, look what a dot in the wrong place can do! fredgandt 15:03, 11 March 2016 (UTC)
At least in my sandbox, your proposal doesn't seem to manifest as a fix ☹ Finlay McWalter··–·Talk 15:07, 11 March 2016 (UTC)
Yeah, that's not good Face-blush.svg. However, although not a fix, it is the problem. At least that's one part of the equation. I'll continue looking into it. fredgandt 15:15, 11 March 2016 (UTC)
Whoever fixes this might also fix the centering of the title parameter in mobile view. – Jonesey95 (talk) 15:28, 11 March 2016 (UTC)
Apparently whatever happened during my initial evaluation was an anomaly which I cannot duplicate; some kind of caching ghost or something. I thought it unusual that the use of a period in a simple template should be any problem, but that's what I saw. I will have another look at it in a while, but need to bathe my dog and rest my eyes (too many curly braces!). It's more than likely something more obvious that a stray period - like a style declaration -_-  fredgandt 15:38, 11 March 2016 (UTC)
We had a similar problem with {{Infobox television}} today. (See the discussion). The problem there seemed to be related to links to a subpage. The ability to customise the colour used in Infobox television was removed a long time ago but {{Infobox television/colour}} exists to allow 14 of the 37,122 articles using the infobox to still have differently coloured infoboxes. (I don't know why!) In order to solve the problem I simply commented out the links.[1] I don't know why it worked, as there have been no recent changes to the template and this has been working for years. --AussieLegend (✉) 15:44, 11 March 2016 (UTC)
I've now made the same change at {{Infobox television episode}} and the problem seems to be fixed. Please hold all applause for the person who can explain why this fixed the problem, because I have no idea. --AussieLegend (✉)
I believe there was some change to how nowiki tags are parsed since this seems to have fixed it. Frietjes (talk) 16:25, 11 March 2016 (UTC)
another one and here. Frietjes (talk) 16:28, 11 March 2016 (UTC)
I added two examples to show that it's <nowiki> tags that are causing the problem. Frietjes (talk) 16:32, 11 March 2016 (UTC)
this may be a _major_ problem considering how many of these color templates are using <nowiki> tags, e.g., all the meta/color templates ... Frietjes (talk) 16:35, 11 March 2016 (UTC)
Yep, someone has changed how the nowiki (and perhaps other) stripmarkers are rendered. This is a percent encoded version of a nowiki stripmarker:
%7F%27%22%60UNIQ--nowiki-0000000E-QINU%60%22%27%7F – the %27%22%60 and %60%22%27 are new
The previous version was just
%7FUNIQ--nowiki-...-QINU%7F
If they changed this, no doubt they changed how nowiki stripmarkers are handled. Was there a reason for this change?
—Trappist the monk (talk) 17:03, 11 March 2016 (UTC)
@Trappist the monk: The weird "nowiki" text occurs when you put a "ref" tag after the pipe in a piped link: [[Main Page|<ref>https://en.wikipedia.org/wiki/Main_Page</ref>]] displays as '"`UNIQ--nowiki-00000007-QINU`"'1'"`UNIQ--nowiki-00000008-QINU`"'. 63.251.215.25 (talk) 17:24, 11 March 2016 (UTC)
This case (along with the <math> in the link text below) both occur with the old strip-marker format on fresh installs of MediaWiki. It looks like this is an open issue (T27417) from 2010. CSteipp (WMF) (talk) 23:05, 18 March 2016 (UTC)
3425 templates with "color" or "colour" in the title and "nowiki" in the source. So this isn't going to be fixed manually. Right? fredgandt 17:38, 11 March 2016 (UTC)
Fred_Gandt can you provide an example where one of the meta/color templates are now broken? all the places that I have checked thus far, e.g., Aberdeenshire#Governance and politics, are still working. also, Template:Infobox election and Template:Composition bar aren't broken, as far as I can tell (probably because they don't use {{infobox}} or {{navbox}}). but, there may be some uses which are broken? Frietjes (talk) 18:22, 11 March 2016 (UTC)
@Frietjes: - Short answer = "no", which is my point. I'm not trudging through thousands of templates by hand to find which might be broken by this. A root or automated fix solution is needed; assuming the nowiki handling isn't broken, but rather is changed - I'd like to think this problem is an edge case which needs a special solution.
It seems that with vast numbers of these meta/colo[u]r templates, it would be prudent to scrap them all and utilise MediaWiki:Common.css to apply classes. The argument of course will be that only admin can edit it, but that shouldn't be a problem (all things considered). fredgandt 07:50, 12 March 2016 (UTC)

mw.html?[edit]

Example 1
Example 2
Example 3

the first two infobox examples used to render the same. the odd thing is that example 3 works, which makes me think that it's a combination of nowiki tags and the HTML builder (mw.html) that's barfing? checking further, I get some interesting results from the following

Input Output
{{str left|{{Green Party (United States)/meta/color}}|5}}
{{str left|#0BDA51|5}}
  1. 0BDA
{{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}} '"`U
{{#invoke:string|sub|#0BDA51|1|5}}
  1. 0BDA
{{#invoke:string|len|{{Green Party (United States)/meta/color}}}} 34
{{#invoke:string|len|#0BDA51}} 7

Frietjes (talk) 22:31, 11 March 2016 (UTC)

This is the Example 1 infobox output according to Special:ExpandTemplates:

<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid ?'"`UNIQ--nowiki-00000000-QINU`"'?;">Example 1</th></tr></table>

and it's accompnying raw html output window:

<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid&#160;?&#39;&quot;`UNIQ--nowiki-00000000-QINU`&quot;&#39;?;">Example 1</th></tr></table>

This is the output when the infobox is wrapped in {{code}}

<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid #0BDA51;">Example 1</th></tr></table>

This is the output as it is in my browser's source:

<table class="infobox" style="width:22em">
<tr>
<th colspan="2" style="/* invalid control char */">Example 1</th>
</tr>
</table>

—Trappist the monk (talk) 23:32, 11 March 2016 (UTC)

It looks like the strip markers are being changed to /* invalid control char */ by HTML Tidy. That would explain why they appear in the HTML for the Special:ExpandTemplates preview but not in the HTML for this page. The change in nowiki tag behaviour doesn't seem to be caused by Lua. Strip markers have always been visible - and editable - from Lua, and Frietjes' example of {{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}} would have worked the same way before. The nowiki tags are converted to strip markers before they are passed to Lua, and MediaWiki converts them into whatever they are supposed to be after they are returned back from Lua. If you edit them while they are in Lua then they won't be recognised properly by MediaWiki after they are returned, which is what is happening in Frietjes' example here - the remaining characters left after the operation on the strip marker are just being treated as normal wikitext. The change in the nowiki tag behaviour seems to have something to do with how the strip markers are processed after they have been returned from #invoke, or from other templates or parser functions. — Mr. Stradivarius ♪ talk ♪ 02:18, 12 March 2016 (UTC)
Mr. Stradivarius, it seems to be #invoke (and padleft?) and not templates in general. as far as I can tell, {{Infobox election}} isn't having any problems, but I had to change {{Infobox political party}} to use the div hack. Frietjes (talk) 14:10, 12 March 2016 (UTC)

Hi Folks. My fault about changing the format of the UNIQ markers. I can confirm it was an intentional change, but I did not anticipate it would cause these problems (Sorry!). I am hopeful we will have this issue resolved by the end of Monday. User:Mr. Stradivarius's explanation above about why things are different in Special:Expandtemplates is a good guess, but not entirely right. The reason that Special:Expandtemplates is returning different results, is due to subtle differences between it and normal pages. Special:Expandtemplates parses stuff by first expanding all templates, and then in a second step, parsing the expanded templates to html (Normal pages do it all in one step). This is mostly the same as normal pages, except that it converts {{#tag:syntaxhightlight|...}} into <syntaxhighlight> instead of interpreting directly. Additionally Ascii delete (aka &#7F;) is removed at the beginning of each step, and UNIQ tags might not remain valid between each step. Last of all, I believe tidy is now applied to the output of Special:Expandtemplates, and the invalid control character thing comes from MW not tidy. BWolff (WMF) (talk) 04:33, 14 March 2016 (UTC)

What does I can confirm it was an intentional change, but I did not anticipate it would cause these problems (Sorry!). I am hopeful we will have this issue resolved by the end of Monday really mean? Why was it necessary to change the format of the stripmarkers? Does the ...resolved by the end of Monday mean that there will be additional changes? If so, what are they? Have you made a note in the code to warn future editors of these problems so that similar situations can be avoided?
—Trappist the monk (talk) 11:45, 14 March 2016 (UTC)
That he is a developer who says sorry for introducing an unexpected side-effect, and that he takes ownership of solving it, so that other ppl don't have to worry. —TheDJ (talk • contribs) 11:56, 14 March 2016 (UTC)
Yeah, I got that and I appreciate it. Perhaps my quote is too long. What is not clear, to me anyway, is: I am hopeful we will have this issue resolved by the end of Monday. All of the subsequent questions that I asked are about that. I asked because, apparently, the intentional change (whatever that is) is still incomplete, may or may not be complete today, and so may yet further break existing templates and modules or rebreak those that have been 'fixed' to accommodate the intentional change.
—Trappist the monk (talk) 13:13, 14 March 2016 (UTC)
It means 1 of 2 things will happen: Either A: the change in strip markers will be temporarily reverted until we are sure we are not accidentally beaking anything. (This should not break any of the template fixes, as they were all back compatible, afaik). Or B: we will try to fix the issues identified. My proposed fix for these issues would be to make it so that syntaxhighlight always removes strip markers before highlighting (esentially making the extension treat nowiki the same as normal text). And making mw.html not mess with strip markers it puts in attributes. Ive been assuming that while the most pressing examples have been worked around , it is still causing problems and wikipedia would want this issue resolved quickly. If everything has basically been fixed and nobody's worried about this anymore, please let me know. BWolff (WMF) (talk) 14:20, 14 March 2016 (UTC)
The change of stripmarker form from (these shown percent encoded to include the delete characters):
%7FUNIQ--<name>-...-QINU%7F
to
%7F%27%22%60UNIQ--<name>-...-QINU%60%22%27%7F
where <name> is gallery, math, nowiki, pre, ref and ... is the unique identifier, was felt beyond the templates identified here. Module:Convert uses a pattern to discover <ref>...</ref> tags used within {{convert}} templates. Module:Citation/CS1 uses a similar pattern to prevent the inclusion of stripmarkers in the metadata that are part of each cs1|2 template rendering. Similarly, that module also relies on stripmarker detection to create simplified but meaningful representations of equations wrapped in <math>...</math> tags when they are made part of the metadata – typically journal article titles.
What was the purpose and benefit of making the stripmarkers more unique by the additions of '"` and `"'? You mentioned 'we'; is there a centralized discussion related to the stripmarker form change that I can read?
—Trappist the monk (talk) 15:44, 14 March 2016 (UTC)
"We" is the Wikimedia Security Team, so I also share responsibility for this, and add my apology. We're working on fixing an issue related to the strip markers, and we'll make the issue public once the fix is released. It's unfortunately a difficult balance to socialize that we need need to make a significant change when we don't want to make the details of the vulnerability public before we have the fix in place. I've just deployed the fix for Scribunto, so hopefully this particular situation has improved. CSteipp (WMF) (talk) 17:01, 14 March 2016 (UTC)
Ah, understood. Do report back when the 'issue' is fixed, please.
—Trappist the monk (talk) 13:34, 15 March 2016 (UTC)

Infobox on Dutch language looks broken[edit]

Hi! The Dutch language article's infobox is kind of not correct looking, because the name of the language (Dutch / Nederlands) is in fairly small print and left-justified, making it hard to read. Click this link to see a screenshot (PNG, 275kb) of the issue. The <th> and <td> tags have style="/* invalid control char */" which looks wrong. The issue happens in Firefox Developer Edition 47.0a2, and also appears to happen in Google Chrome "Version 48.0.2564.116 (64-bit)". Could this be fixed? Thanks :) Goldenshimmer (talk) 20:54, 12 March 2016 (UTC)

@Goldenshimmer: This edit has fixed Dutch language but it's knackered the template's own doc page. I've not undone my edit: given the choice of broken article or broken template doc, I'd go with the latter. --Redrose64 (talk) 21:14, 12 March 2016 (UTC)
Thanks @Redrose64! Yeah, I would agree that broken article is much more important 😛. I feel something of a fool now, since I skimmed this discussion yesterday, but didn't make the connection when I saw the issue today, even though I looked for a report… i think i might have assumed that it had to do with Template:Infobox language specifically…. Anywho, thanks again :) Goldenshimmer (talk) 21:33, 12 March 2016 (UTC)
I made a further change, which does not affect Dutch language but has fixed the documentation. The sum of my two edits is this: every instance of <nowiki>#rrggbb</nowiki> has become /**/#rrggbb
The /**/ is a valid CSS comment, and it's passed through untouched by the MediaWiki parser, and its presence hides the hashes so that they're not converted to ordered-list item markers, but remain valid RGB hex triplet markers. --Redrose64 (talk) 21:38, 12 March 2016 (UTC)
Seems that the bgcolor= attribute of table cells doesn't like that technique. Never mind; it's obsolete in HTML5 anyway, so an edit like this is also necessary. --Redrose64 (talk) 21:50, 12 March 2016 (UTC)

Redirects from plurals[edit]

Template:R from plural and the pages transcluding it such as numbers say '"`UNIQ--nowiki-00000000-QINU`"' instead of [[link]]s. GeoffreyT2000 (talk) 00:12, 13 March 2016 (UTC)

I wonder if this is the same issue causing the infobox fuckery above. The Template:R from plural page for me seems to contain the same delete character (0x7f) that shows up in the discussion of the broken infoboxes. I'm seeing: <snip /> Huh, the deletes are turning into 0x3f for some weird reason in the saved page, so let's try this: <snip /> Dafuq? I get why the entity I left the semicolon off of isn't working, but the first one? Let's try this again…

This redirect link is used for convenience; it is often preferable to add the plural directly after the link (for example, &#x7f;'"`UNIQ--nowiki-00000000-QINU`"'&#x7f;). However, do not replace these redirected links with a simpler link unless the page is updated for another reason (see WP:NOTBROKEN).

/me googled it. Turns out html entities are decimal by default and need to be prefixed with an x to use hex… D'oh. :-S Goldenshimmer (talk) 00:58, 13 March 2016 (UTC) Update: Refactored comments and cut out some stuff to make it less ugly to read. Goldenshimmer (talk) 01:01, 13 March 2016 (UTC)
I can't get those entities to work for some weird reason (I'm probably missing something obvious…) so yeah, just use your imagination that the "&#x7f;"s are actually, ya know, like, 0x7f. Goldenshimmer (talk) 01:08, 13 March 2016 (UTC)
(Edited comments again, cause I seem to have a semicolon deficiency today…. Goldenshimmer (talk) 01:10, 13 March 2016 (UTC))

Examples of the problem that lead to the above (the third example works with no problem):

  • {{code|<nowiki>[[link]]s</nowiki>}} → [[link]]s
  • {{#tag:syntaxhighlight|<nowiki>hello</nowiki>|lang="text"}} → 
    hello
  • {{#tag:syntaxhighlight|<nowiki>hello</nowiki>}} → 
    hello

A workaround would be to remove the nowiki and replace "[" with &#91;, but a fix for the underlying problem is needed. Johnuniq (talk) 01:22, 13 March 2016 (UTC)

@GeoffreyT2000, Goldenshimmer, and Johnuniq: No need to encode the square brackets; if you check the documentation for {{code}}, it says "the template uses the <syntaxhighlight> tag with the attribute enclose="none". This works like the combination of the <code> and <nowiki> tags", therefore, there is no need to provide your own <nowiki></nowiki> tags, so I removed them. --Redrose64 (talk) 10:26, 13 March 2016 (UTC)
OK, I did this search for "UNIQ--nowiki" and got four hits. Two were <nowiki>...</nowiki> inside {{code}}; two were <ref>...</ref> inside wikilinks. All fixed. --Redrose64 (talk) 10:57, 13 March 2016 (UTC)
Thanks, that has fixed Template:R from plural. However, my point was to show the wikitext in the template that used to work and which now results in a broken strip marker. Perhaps the nowiki should never have been in {{code}}, but should placing it there cause a strip marker to become visible? Johnuniq (talk) 10:59, 13 March 2016 (UTC)
@Redrose64: I wasn't trying to encode the square brackets. Rather, I was trying to encode the delete character U+007F. Goldenshimmer (talk) 17:48, 13 March 2016 (UTC)
Indeed; but see comment by Johnuniq above, beginning "A workaround would be ...". --Redrose64 (talk) 18:09, 13 March 2016 (UTC)
Oh, got it. Thought the ping meant the comment was responding to mine too, :P, thanks :) Goldenshimmer (talk) 21:24, 13 March 2016 (UTC)
It was a reply to everybody who had posted before me; you and Johnuniq both seemed to be going to a lot of trouble (with various encodings; re-editings of the posts here, comments like "I can't get those entities to work") to find what was really a very simple solution - simply omit the <nowiki></nowiki> tags. I mentioned GeoffreyT2000 as well by way of saying "fixed". --Redrose64 (talk) 21:35, 13 March 2016 (UTC)
To Redrose64: It's a lot of trouble to remove nowiki tags from everywhere, for example, I caught your edit to {{R from plural}}, but what about its category, which still shows the superfluous code as of 18:50, 14 March 2016 (UTC)? There are times when the nowiki tags may be needed, e.g., when using the {{Code}} template to render tlx|, which comes out as '"`UNIQ--nowiki-00000034-QINU`"'. Omit the nowiki tags and the pipe disappears, as in tlx. Perhaps a better idea would be to leave the code alone and wait for the devs instead of telling people to omit nowiki tags, which may lead to more problems?  Follow Jimbo! Paine  18:50, 14 March 2016 (UTC)
Fixing the cat page is easy. When do you need to put tlx| inside {{code}}? Do you have examples of pages where this is done? --Redrose64 (talk) 20:03, 14 March 2016 (UTC)
Being an easy fix misses my point. The loss of the pipe in my example above is a subtle loss that may go unnoticed, and there are plenty other possible instances where the removal of nowiki tags might cause subtle yet important differences. An example of the tlx| inside {{code}} is actually how I found this problem that led me to this discussion. It's on my user talk page in a discussion with Martin at the end when I disabled some template loops. Point is, there should be no encouraging people to remove code (nowiki tags) until the devs have worked their magic.  Follow Jimbo! Paine  23:32, 14 March 2016 (UTC)
Can we be sure that the devs will return things to the previous state? We can't. But if they eventually do, how long will this problem (which might be temporary) last? Do we sit around waiting and/or complaining, or do we assume that it may take months, and actually get off our arses and do something about it ourselves?
This bug/feature/effect is highlighting misused markup. Too often I see people using complicated techniques for situations that don't merit them - for instance, you don't need a <nowiki>...</nowiki> inside {{code}} when <code>...</code> does the whole job, like this. --Redrose64 (talk) 00:18, 15 March 2016 (UTC)
Thank you – I changed that last one back so it's easy for me to tell when the problem is fixed. This shouldn't be too difficult for the devs to fix quickly. I just think we're asking for more problems if we encourage the removal of nowiki tags, since subtle diffs could be missed. Some editors are more careful than others. It'll soon be a moot point, I trust.  Paine  09:18, 15 March 2016 (UTC)

One possible alternative, is if the lang is unspecified for {{code}}, to use <code>{{#tag:nowiki|{{{1}}}}}</code> instead of using #tag:syntaxhighlight. This would handle embedded nowiki's better than syntaxhighlight currently does. Bawolff (talk) 22:05, 15 March 2016 (UTC)

Yes, I sandboxed that and it works well on my talk page; however, since {{Code}} is but one part of this problem, shouldn't we be looking for a fix that allows #tag:syntaxhighlight to work as well as it did a few days ago? so other issues reported above will also be fixed?  Paine  18:42, 17 March 2016 (UTC)
There are closely-related problems with {{bcode}} --Redrose64 (talk) 19:47, 17 March 2016 (UTC)

Math inside wikilinks broken?[edit]

For markup like e^{i\pi}=-1 (markup: [[Mathematics|<math>e^{i\pi}=-1</math>]]; should look like: eiπ = −1) where a wikilink encloses a mathematical formula, I'm seeing renderings like ?'"`UNIQ--postMath-00000001-QINU`"'?. This is with Chrome under OS X with the MathML/SVG-fallback option enabled. Is it happening more widely? —David Eppstein (talk) 20:46, 17 March 2016 (UTC)

The link works, it just isn't blue? 90.199.52.141 (talk) 20:49, 17 March 2016 (UTC)
Under PNG it looks fine, but when I switch to MathML in the Preferences, the first and third wiki links have the UNIQ...QINU problem. This is also with OSX, Chrome Version 49.0.2623.87 (64-bit). So, verified, but I don't know the solution. --Mark viking (talk) 21:28, 17 March 2016 (UTC)
I assume you know that this used to work? There have been a few discussions about broken strip markers recently. At #mw.html? above, BWolff (WMF) said "I am hopeful we will have this issue resolved by the end of Monday" although that was not in relation to math. BWolff might like to comment on this as well. The problem exists when "MathML with SVG or PNG fallback" is selected in Preferences for Firefox. Johnuniq (talk) 22:29, 17 March 2016 (UTC)
Yes, stripmarker treatment has changed, I think in connection with phabricator:T103269. This has also caused problems with <math> in citation template parameters (such as article titles and quotations) but that's under control (fixed in the latest sandbox version of the citation templates, to be included in the next monthly update). —David Eppstein (talk) 23:16, 17 March 2016 (UTC)
David Eppstein, I looked into how the strip marker change could have caused this, and it looks like this is a new case of an old, open issue-- T27417. If this only started recently, it might have been a change to the MathML processing. But I'm able to duplicate this issue on a fresh install of mediawiki, using the old strip-marker format, so the issue predates Bawolff's patch. CSteipp (WMF) (talk) 23:16, 18 March 2016 (UTC)
Maybe a change to math processing exposed the math stripmarkers to the same problem that was already occurring with other kinds of stripmarkers? Anyway, thanks. Having a known bug to refer to for this saves the trouble of starting a new one. —David Eppstein (talk) 23:37, 18 March 2016 (UTC)

There is another bug for this specific problem, T130508.--Salix alba (talk): 16:36, 21 March 2016 (UTC)

May we get a firm timeline when this will be fixed?[edit]

I see this problem on template documentation pages almost everywhere I turn!  Embrace neutralisms! Paine  14:47, 21 March 2016 (UTC)

As it is related to a security issue, I very much doubt so. The fact that it is still there is proof enough that it is a rather troublesome problem to solve without reintroducing the security problem and thus logically a date cannot be given, because that would imply that the problem is predictable in complexity. —TheDJ (talk • contribs) 23:57, 22 March 2016 (UTC)
I do apologize for the delay in getting this fixed. I've just deployed the fix for syntaxhighlighter, so {{code}} and {{bcode}} should be fixed now. I believe that was the major issues with the template documentation pages. If you're still seeing issues, can you point me to some examples? CSteipp (WMF) (talk) 22:24, 24 March 2016 (UTC)
After looking into things again, it looks like the lua patch was dropped from the current deployment branch. That has been redeployed. So as of about 25 Mar 03:45 UTC, the issue with lua modules and the {{code}} templates should both be fixed, and things should be back to being parsed as they were prior to the strip marker change. Apologies, again, for the delay in getting this fixed. The next mediawiki release should be published soon as well, so we can make the issue behind this public. CSteipp (WMF) (talk) 04:02, 25 March 2016 (UTC)
To BWolff (WMF) and CSteipp (WMF): Thank you beyond words for fixing this multiple-page damage! I knew it wouldn't take you long! Happy E-day (belatedly) and Best of Everything to You and Yours!  Embrace neutralisms! Paine  13:59, 28 March 2016 (UTC)

Small improvement to standard Search Box[edit]

The current search box algorithm by Wikipedia for article searches implements a simple search with autofill option for linking to articles. Other major companies and institutions, like Amazon and others, who use similar search boxes offer the same feature, though they have significantly improved their versions to include a spelling correction facility to help users find their products and what they are looking for. It is fairly easy to implement an improved Wikipedia search box with simple spelling correction and perhaps it should be done. If someone misspells Dostoeievsky then they do not need to be told that their page does not exist or that a new page can be created. A simple spelling fix suggestion in the search box might be more useful and more user friendly. The current Wikipedia subtext of "Did you mean... option is the poor man version of what companies like Amazon and others have usefully implemented for their users. Fountains-of-Paris (talk) 16:23, 22 March 2016 (UTC)

This is being worked on by the Discovery team. I'm not sure which exact task it is, but [2] is the project board on Phabricator. --Izno (talk) 16:59, 22 March 2016 (UTC)
Hi Fountains-of-Paris. What timing! The Discovery department just updated the 'smarts' behind the search-as-you-type "completion suggester" last week. The update brings better handling of spelling mistakes as you mentioned. You can read more about the update on the Wikimedia Blog. CKoerner (WMF) (talk) 17:50, 22 March 2016 (UTC)
That's a nice link and it works for the correction of their test case of "David Bowtie" corrected to "David Bowie". I then tried it for my example of Dostoyevsky by typing the letter next to it by accident "Fostoyevsky" and it went back to "no page exists" mode. Do the coders of the new version know about this glitch that corrections only seem to catch the last letters of mistyped search box entries? Fountains-of-Paris (talk) 19:35, 22 March 2016 (UTC)

I quote:

ebernhardson> thedj: we don't do fuzziness on the first letter, it was too expensive
ebernhardson> thedj: it would basically require iterating every possible article
ebernhardson> the short answer is a suggest takes 10-12ms of server time by handling the first character, and 2-3 ms by forcing the first character to not be fuzzy. This makes a very large change in the number of servers required to serve this feature

Hope that answers your question. —TheDJ (talk • contribs) 17:06, 23 March 2016 (UTC)

@TheDJ and CKoerner (WMF): That clarifies a lot if you are saying that the algorithm currently being used is fixed at a 1-character or 2-character look-back for error correction in the simple search box. If I am reading this correctly, then could one of you tell me if it is an n-character look-back algorithm which is now being used starting at the end of the typed search box item which is limited to a 2-3 ms response time maximum? Or is it some other search-correction strategy? Fountains-of-Paris (talk) 15:03, 25 March 2016 (UTC)
I believe that it's fixed at one character. Whatamidoing (WMF) (talk) 18:51, 30 March 2016 (UTC)

Breaking change: wikibits[edit]

Beginning with MediaWiki 1.27 (April 2016) wikibits Javascript module will no longer load by default. In MediaWiki 1.28 (November 2016) it will be removed entirely. It is advised that code using wikibits be refactored to use modern replacements. See this email for more details.

— JJMC89 (T·C) 13:16, 26 March 2016 (UTC)

Is there a list of often-used gadgets and user scripts that will break once this change is rolled out? MER-C 14:14, 26 March 2016 (UTC)
Well the loss of importScript will affect virtually everyone who calls any scripts on their own js pages. Nthep (talk) 14:50, 26 March 2016 (UTC)
There is no replacement for importScript. 19:58, 26 March 2016 (UTC) — Preceding unsigned comment added by Ruslik0 (talk • contribs)
importScript should be replaced by mw.loader.load. I think it was a long-term plan to do this replace. --Edgars2007 (talk/contribs) 21:15, 26 March 2016 (UTC)
I've successfully upgraded User:John of Reading/common.js by hand. I wonder if a bot could do this? There could be about 27,000 affected pages. -- John of Reading (talk) 21:17, 26 March 2016 (UTC)
Since only administrators and interface editors can edit other users' js and css pages, the bot will have to be either an administrator or an interface editor. Preferably, the bot should be a global bot and an interface editor because the change also applies to the other wikis. GeoffreyT2000 (talk) 21:53, 26 March 2016 (UTC)
I wouldn't be keen on a bot doing this. I've changed the use of importScript on my own .js pages and it didn't take much working out. What is needed is a much wider advertising of the change and how to fix things to users whose pages will be affected - that is a task for a bot. Nthep (talk) 23:07, 26 March 2016 (UTC)
Agreed, it's more an issue of knowing this needs to happen. Anyone capable of editing their .js pages to add a script can just as easily change the statements to the new function call, but if they don't know that they need to, then that's a problem. Also, all the documentation pages for scripts will need to be updated so new users don't add outdated code. Since this affects anyone using scripts, maybe a watchlist notification linking here or to an information page with steps for migrating? clpo13(talk) 23:11, 26 March 2016 (UTC)
I agree this needs wider notice and have posted at WP:AN. Here's a bunch of gadgets that need to be updated. MER-C 13:01, 27 March 2016 (UTC)
Unfortunately removal of importScript will break hundreds of scripts across hundreds Wikimedia projects and mw.loader is imperfect replacement of the importscript. Ruslik_Zero 20:19, 27 March 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I agree; while mw.loader is generally good, importScript's desirable simplicity in referencing on-wiki JS files is missing in mw.loader.load. Here's a quick hack for those too lazy to properly update that restores it:

window.importScript = function (importPage) {
    var wg = mw.config.get(["wgServer", "wgScript"]),
        importUrl = wg.wgServer + wg.wgScript + "?title=" + mw.util.wikiUrlencode(importPage) +
        "&action=raw&ctype=text/javascript";
    return mw.loader.load(importUrl);
};

Note that scripts may still have errors from implied globals, because of the way mw.loader.load() wraps its output. These can be fixed by making the global explicit by specifying it as a property of the window object, as in the snippet above. {{Nihiltres |talk |edits}} 23:55, 27 March 2016 (UTC)

So I just need to add this snippet to the top of my .js and importScript will continue to work? Is there a reason importScript is going away, it seems rather useful and more elegant? –xenotalk 18:55, 28 March 2016 (UTC)
something is wrong here, IMO: for other stuff that were obsoleted, we received console.log messages (at least when running with "debug=true" address-line parameter), reporting this obsolescence. anyone using wiked or wikeddiff gadgets can see tons of such report in JS console, complaining about direct access to wgXxxxx global variables.
however, importScript() is *not* marked as obsolete even now, and there's no report in js console telling users to replace it. announcing something like this on WP:VPT in enwiki is grossly inadequate. i can see no justification for such a breaking change.
the fact that there is no adequate substitute for importScript anywhere in mw libraries is even more puzzling (for instance, if i remember correctly, addPortletLink() was obsoleted long time ago, with a message instructing to use "mw.util.addPortletLink", and during the time since it was declared obsolete, practically all call-sites were converted. other such functions were handled similarly (appendCSS => mw.util.addCSS, etc.) nothing like that happened with importScript and importStylesheet(). the least i'd expect is for "someone" to create mw.util.import(Script|Stylesheet), add "obsolete" marker to wikibits functions, and give the communities some time to convert. peace - קיפודנחש (aka kipod) (talk) 15:35, 28 March 2016 (UTC)
Read the email. It hasn't happened yet. Load by default goes first with Mediawiki 1.27 next month with the wikibits removed in a further release in November so that's the 6 month period for people to convert etc. Nthep (talk) 15:41, 28 March 2016 (UTC)
@Nthep:: removing "load by default" _is_ a breaking change: stuff that works today will stop working, and will require code change to work again. whether this code change is manually loading wikibits or rolling your own "importScript()" is irrelevant.
TWISI, for wmf to be considered "good citizens", 3 things need to happen before removing the "load by default":
  1. mark *all* wikibits functions as "deprecated" or "obsolete", so calling them will leave a mark in JS log. this is how these things were done until now, and we came to expect it. please don't surprise us.
  2. offer good substitute for each function removed. most functions have them, but not all: as several people noted in this section, there is no reasonable substitute for some of the calls, specifically import(Script|Stylesheet)
  3. allow the communities reasonable time to go over the obsolete calls and update the call-sites.
removing "load by default" _is_ a breaking change, so claiming you give people 6 months to adjust is just not true. not marking the calls that are going to disappear as "obsolete", is being less helpful than you can be. not providing good substitute is just wrong - why should every single project have to place the code User:Nihiltres in their mediawiki:common.js, when it clearly blongs in mw.util ?
peace - קיפודנחש (aka kipod) (talk) 18:28, 28 March 2016 (UTC)
Yes, I agree that we should have a solution in mw.util or mw.loader. It would be better if we had a simple mw.loader.wikiLoad() or something, with the same basic functionality (probably worthwhile to add importCSS functionality as well, with type defaults based on page suffix). The mw.loader.load() functionality is built around server-side registration of modules, while user code has to use the ugly URL-based fallback. In the long term, with plans to create Gadget namespaces and such, it's not so bad, but until we have that, a clean way to load wiki-based JS/CSS pages is quite desirable. {{Nihiltres |talk |edits}} 19:19, 28 March 2016 (UTC)
@Nihiltres Beware that mw.util.wikiUrlencode (from mediawiki.util) requires a dependency as otherwise it may be undefined in race conditions. A shortcut for local wikis in Common.js could look as follows instead: 
window.importScript = function (pageName) {
    mw.loader.using('mediawiki.util').then(function () {
        var conf = mw.config.get(['wgServer', 'wgScript']),
            url = conf.wgServer + conf.wgScript + '?title=' + mw.util.wikiUrlencode(pageName) +
                '&action=raw&ctype=text/javascript';
        mw.loader.load(url);
    });
};
Modules like mediawiki.util won't load multiple times (it's a ensure command, it'll run immediately if loaded already). Also note, the site module (Common.js/css) is still guaranteed to load before user module. Defining this in MediaWiki:Common.js is supported and will work! –Krinkle 00:34, 29 March 2016 (UTC)
Good catch. I'm pretty sloppy about remembering to wrap things with mw.loader.using(). {{Nihiltres |talk |edits}} 03:52, 29 March 2016 (UTC)
Maybe I'm missing something, but I think having to put in the full URI into mw.loader.load is a bit outrageous. That's super annoying and turns our personal JS into a wall of text instead of a concise and legible line by line list of scripts. Call me crazy but I think enwiki should just add our own importScript as Nihiltres has created above, at least until mw.loader.wikiLoad or the like is available — MusikAnimal talk 05:51, 31 March 2016 (UTC)

WP:Checklinks is still going bonkers[edit]

13 days ago I reported that WP:Checklinks is going bonkers by duplicating added accessdates. Today it is doing it again. (cc to @Frietjes and Dispenser:. I would like to be able to rely on Checklinks to do a tidy job. Cheers! {{u|Checkingfax}} {Talk} 12:07, 28 March 2016 (UTC)
Reping Frietjes {{u|Checkingfax}} {Talk} 12:09, 28 March 2016 (UTC)

CSS Image Crop[edit]

There is a problem with a file name unexpectedly appearing below an image generated by a css template, with a screenshot provided, at the discussion here (scroll down to "Image review". Help would be appreciated.--Wehwalt (talk) 16:02, 28 March 2016 (UTC)

@Wehwalt: The screenshot shows a copy of the image name instead of the usual "jump to the full image" icon, so this is something to do with the "magnify" CSS class. I noticed that Module:Location map generates <div class="magnify">[[:File:Foo.jpg| ]]</div>, whereas {{CSS image crop}} omits the pipe and the space, generating <div class="magnify">[[:File:Foo.jpg]]</div>. But that's as far as I can go, and I don't know whether that is significant or why Nikkimaria is seeing an unexpected result. -- John of Reading (talk) 16:58, 28 March 2016 (UTC)

Tech News: 2016-13[edit]

19:43, 28 March 2016 (UTC)

There's something wrong with XTools[edit]

Article info gives me an error which says "The ini file could not be read". The other XTools are at the moment having spotty reliability at best: at times they work, but in other times they take too long to load. Narutolovehinata5 tccsdnew 00:50, 29 March 2016 (UTC)

@Narutolovehinata5: Should be working now (it is for me). It was related to a permissions issue that the labs reboots brought to light. ~ Matthewrbowker Drop me a note 01:56, 29 March 2016 (UTC)
Yes, props to Matthewrbowker! He spent quite some time earlier today diagnosing this issue. Still need to figure out what's up with the edit counter, but I believe we have some solid theories — MusikAnimal talk 02:23, 29 March 2016 (UTC)
It appears the edit counter is now functional. ~ Matthewrbowker Drop me a note 05:21, 29 March 2016 (UTC)

Unhidden category[edit]

Template:EPA content adds unhidden Category:Wikipedia articles incorporating text from the United States Environmental Protection Agency to the articles (currently only one article there). Could someone look if this cat could be hidden? Brandmeistertalk 08:49, 29 March 2016 (UTC)

Done. The category has only a single member. Not sure, then, why we have the cat. --Tagishsimon (talk) 09:00, 29 March 2016 (UTC)
@Brandmeister: Redlinked categories are never hidden. This is because the code to hide them must be placed on the category page; and if it's there, the cat page must then exist, therefore it's no longer a redlinked category. --Redrose64 (talk) 15:05, 29 March 2016 (UTC)

Recycled url[edit]

The Gender Equality Architecture Reform (GEAR) Campaign lobbied from 2007 for a new UN gender equality entity, with a website at http://www.gearcampaign.org. It achieved its goals in 2010 and dissolved, letting the domain name lapse. Now the domain name is being used by a blog about electric battery technology. The effect is that links in the Gender Equality Architecture Reform article point to the home page of the electric battery blog. I changed the citations to look like:

Is there a better way? This cannot be a new problem. I do not see anything about it at Wikipedia:Link rot. Aymatth2 (talk) 12:48, 29 March 2016 (UTC)

You should provide a |archiveurl=. --Izno (talk) 13:16, 29 March 2016 (UTC)
That would work if the pages had been archived, but on a search for the page the Wayback Machine says
Page cannot be crawled or displayed due to robots.txt.
See www.gearcampaign.org robots.txt page. Learn more about robots.txt.
So even if the pages were archived, the present version of the site is hiding the archived versions. Aymatth2 (talk) 13:36, 29 March 2016 (UTC)
Seems like a "bug" with IA. --Izno (talk) 13:47, 29 March 2016 (UTC)
This is just IA being responsible and adhering to the robots.txt file of the website. We also have a https://en.wikipedia.org/robots.txt. PrimeHunter (talk) 13:52, 29 March 2016 (UTC)
@PrimeHunter: The point I'm making is that that is the current owner's robots.txt. We do not know if the previous owner's robots.txt also required noindex. --Izno (talk) 13:58, 29 March 2016 (UTC)
  • The "new" owner may be just a new name for the previous owner, like Alphabet and Google, and archive.org may choose to respect the current robots.txt setting whatever it was in the past. Anyway, assuming that for whatever reason we cannot find an archived version, how do we show we are citing a page by that name we found at that url on that date, which has since been replaced by something completely different? Aymatth2 (talk) 16:24, 29 March 2016 (UTC)
@Aymatth2: Don't change the citations that way. It's a form of link rot, so use {{dead link}} instead. See Wikipedia:Link rot#Robots.txt. --Worldbruce (talk) 04:10, 30 March 2016 (UTC)
  • I thought of that, but the link is all too live. An undead link, perhaps. I want a way to show that what was there is no longer there, but something else is. Otherwise someone will come along, check the link, find it is not dead at all, and remove the {{dead link}}. Aymatth2 (talk) 12:32, 30 March 2016 (UTC)
This should probably be taken up at Help talk:CS1. I can imagine adding a parameter that would suppress the url, and add appropriate categorization and messaging.
—Trappist the monk (talk) 12:54, 30 March 2016 (UTC)

Broken links table[edit]

I just moved Glen Parva railway station to Wigston Glen Parva railway station, following which Special:WhatLinksHere/Wigston Glen Parva railway station was empty for several minutes; most worryingly, the redirect wasn't listed there. Is this phab:T117332? Perhaps Matma Rex (talk · contribs) knows. --Redrose64 (talk) 13:14, 29 March 2016 (UTC)

@Redrose64: I'm afraid I don't know. But it looks like Special:WhatLinksHere is correct now. A delay of a few minutes is normal. Matma Rex talk 19:31, 29 March 2016 (UTC)
It used to be that it was updated so quickly that you wouldn't notice - to all intents and purposes it was instantaneous. If there is now a measurable delay, then fixing resultant double redirects - as we have been advised to do for years - might get completely missed. --Redrose64 (talk) 19:48, 29 March 2016 (UTC)

IPv6 range contributions[edit]

Is there any tool available which will show all the edits from an IPv6 range? I have the gadget that allows viewing contributions from an IPv4 CIDR range turned on, but it doesn't appear to work with IPv6 ranges. -- Ed (Edgar181) 15:36, 29 March 2016 (UTC)

I'm pretty sure that the same gadget allows IPv6 prefix search ( unless it is something that I pull in with my common.js ). However requires using an asterisk (*) after a colon instead of using an IPv4 style #.#.#.#/# subnet. It should show many of the contributions with that prefix. I think it is limited to 50 or so though. PaleAqua (talk) 02:50, 30 March 2016 (UTC)
@PaleAqua: Thanks for the suggestion. You're right. I had tried Special:Contributions/2601:8c:4004:af05:* which returned nothing, but with the letters capitalized Special:Contributions/2601:8C:4004:AF05:* it works. -- Ed (Edgar181) 13:52, 30 March 2016 (UTC)

Lots of white space in article[edit]

The Sephardi Jews article has lots of white space before the colums with pedigrees in the Sephardic pedigrees section, because of the "Jewish exodus from Arab and Muslim countries" template in the section above that pushes down the table. I tried something to make the table float, but it didn't work. Can somebody look into it, please? Debresser (talk) 22:27, 29 March 2016 (UTC)

This was done[8] and the editor received a public "thank you". Debresser (talk) 00:24, 30 March 2016 (UTC)

Special:Redirect not found[edit]

The page Special:Redirect has a 404 (Four-Oh-Four) error. GeoffreyT2000 (talk) 23:58, 29 March 2016 (UTC)

The page works for me in Firefox but according to http://404checker.com/404-checker it returns a 404 Not Found status code. It shouldn't do that. I tested many other pages at Special:SpecialPages and they all returned a 200 OK code. PrimeHunter (talk) 00:25, 30 March 2016 (UTC)
404checker shouldn't be giving you 200's for anything, it should be giving you TLS redirects??? — xaosflux Talk 01:43, 30 March 2016 (UTC)
Do you mean if https:// is omitted so the default http:// of 404checker is used? I include https:// like https://en.wikipedia.org/wiki/Special:Redirect (gives 404 Not Found) or https://en.wikipedia.org/wiki/Special:Log (gives 200 OK). PrimeHunter (talk) 10:01, 30 March 2016 (UTC)

Exception encountered, of type "Exception"[edit]

I was contacted by a user who receives the message above (no stack trace) when attempting to log in to any WMF project. Does anyone have any suggestions for them? Cheers, Bovlb (talk) 16:33, 30 March 2016 (UTC)

@Bovlb: See phab:T119736. Might want to add their username to that task so ops can fix the account. ~ Matthewrbowker Drop me a note 16:36, 30 March 2016 (UTC)
Thanks, I have done so. The user and I are awaiting a response from ops. Cheers, Bovlb (talk) 19:18, 30 March 2016 (UTC)
Resolved

new citation template displays documentation box and description box after displaying reference[edit]

I'm in the process of making Template:Cite archival metadata, which I basically stole from Template:Cite open archival metadata. When I use it on my sandbox, it displays a description of the page and a blank documentation box after the reference citation. I don't really know what I'm doing when it comes to writing templates, so I feel like I probably made an obvious error. I deleted a part of the template that would have explained the page description box (on my sandbox it says "this is the sandbox page..."); but after purging both the template and my sandbox it persisted.

Could you help me understand what's going on? Much thanks for any assistance you may offer. Rachel Helps (BYU) (talk) 18:35, 30 March 2016 (UTC)

I have added <noinclude>...</noinclude> around {{Documentation}}.[9] PrimeHunter (talk) 20:30, 30 March 2016 (UTC)
Thank you for helping with this simple thing! I will never again underestimate the importance of noinclude. Rachel Helps (BYU) (talk) 16:04, 31 March 2016 (UTC)

DISPLAYTITLE is NS:2[edit]

In this edit I added a custom title to my userpage via DISPLAYTITLE, but seems that it doesn't work - I see no changes in page title. Do anyone know why? --XXN, 14:33, 31 March 2016 (UTC)

Please look at Template:DISPLAYTITLE/doc#Examples - specifically the last one: there are technical limits on how different the display title can be from the technical title. I'd say that the punctuation you added makes it too different. עוד מישהו Od Mishehu 14:58, 31 March 2016 (UTC)

Creating a bot to identify out-of-date information in Wikipedia entries[edit]

There are a mass of entries in English and Chinese Wikipedia that include out-of-date facts or references. And there are some existed software tools or algorithms relative to natural language pattern matching to solve this problem. We would like to measure the usefulness of these tools and algorithms and create a new bot to identify those information based on the result of measurement. During the work of measuring existed tools and testing the new bot, we will try to collect abundant Wikipedia entries and create some new cases. And the modular software can be used by Wikireview and other contributors of Wikipedia.

URL of detailed proposal is here: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Searching_for_out-of-date_information_in_wikipedias

Please give us your advice in the discussion board of the proposal: https://meta.wikimedia.org/wiki/Grants_talk:IdeaLab/Searching_for_out-of-date_information_in_wikipedias

Li Linxuan (talk) 16:22, 31 March 2016 (UTC)

Single edit tab[edit]

I've just posted information about an upcoming change for editors who have the visual editor enabled. The information is at Wikipedia:Village pump (miscellaneous)#Single edit tab. If you currently have two edit tabs (Edit/Edit source), then this will give you the options of having only one Edit button, if you prefer that. Please read that information, and share it with other editors. Whatamidoing (WMF) (talk) 17:30, 31 March 2016 (UTC)

Bot assistance[edit]

Do we have a bot, possibly launchable by users on selected pages, that can fix duplicate key ref errors or such work requires human input? I'm asking because I stumble upon multiple such pages and fixing them manually is tedious (actually the related category currently lists 24,319 such pages, including good article Greco-Persian Wars). Brandmeistertalk 21:52, 31 March 2016 (UTC)

New page created by IP?[edit]

Somehow, an IP-editor has managed to create Talk:El Gabacho. Pretty sure that shouldn't be possible. (Note: CSD-tagged as combined WP:G8/WP:G3, so if it appears as a redlink at some point, that'd be why) AddWittyNameHere (talk) 04:16, 1 April 2016 (UTC)

IPs have pretty much always been able to create talk pages, even if the corresponding article doesn't exist. I think a lot of junk gets missed there, but there's a lot of useful stuff going on like anons creating the talk page to add project tags and whatnot. --Bongwarrior (talk) 04:33, 1 April 2016 (UTC)
Could the talkpage creation be controlled via pending changes? With something clever to add a category such as "Talk pages created by IP editors" so they can be easily spotted? Lugnuts Dick Laurent is dead 13:20, 1 April 2016 (UTC)

Metadata[edit]

If this the most effective way to emit metadata on licences for images? I did question whether spans were better than divs but was told they are not. — Martin (MSGJ · talk) 09:30, 1 April 2016 (UTC)

I'm not sure I believe that argument that the parser will wrap <span>...</span> tags in <p>...</p> tags. That may be true for raw <span>...</span> tags in article text but may not be true for template output. Before the <cite>...</cite> tag's css was fixed, the cs1|2 templates were wrapped in <span>...</span> tags and that didn't cause extraneous <p>...</p> tag insertion.
—Trappist the monk (talk) 13:38, 1 April 2016 (UTC)

Watchlist legend[edit]

Hello, regarding design of watchlist explanations. Could someone more knowledgeable in code remove "Pages that have been changed since you last visited them are shown with a green marker" from under "You have 999 pages on your watchlist" and add the explanation of the green and blue bullet to Template:Watchlist legend? It has been suggested by a few other people as well. Thanks! Renata (talk) 03:51, 2 April 2016 (UTC)

It cannot be done in a good way here at the English Wikipedia. Template:Watchlist legend is only designed to imitate the actual watchlist legend for display in Help:Watchlist#How to read a watchlist. https://en.wikipedia.org/wiki/Special:Watchlist?uselang=qqx shows the real watchlist legend is built from a bunch of MediaWiki messages which each have a specific placement and are designed for a specific message. There is no message suited for adding an explanation of last visited markers in the legend. MediaWiki:wlheader-showupdated is intended for it and MediaWiki displays it in another place above the "Mark all pages as visited" button. PrimeHunter (talk) 10:12, 2 April 2016 (UTC)

NOINDEX[edit]

Is there a problem with NOINDEX? I was under the impression that userspace are noindexed and that pages in Category:Noindexed pages aren't actually indexed. As I noted at Wikipedia:Miscellany for deletion/User:Streetseekers/Blackwater Primero, there's an five year old userspace draft for a rapper that is literally the only relevant item if you search for his name. Now, the fact that people still want to keep that is another problem but the point still stands, if that is kept, how in the world can I actually get it not indexed since we don't have a dozen British rapper/DJ articles posted afterwards? -- Ricky81682 (talk) 04:49, 2 April 2016 (UTC)

Ok, I was informed that the problem is probably that the mainspace version at Blackwater Primero used to be a cross-space redirect to the userspace one and because mainspace is indexed, google hasn't catch up yet. Interesting bug. -- Ricky81682 (talk) 05:29, 2 April 2016 (UTC)
User space is not NOINDEXed by default, it is only NOINDEXed if you add appropriate code, such as by adding the {{Userspace draft}} template, or by adding a |noindex=yes parameter to a {{user sandbox}} template. --Redrose64 (talk) 08:43, 2 April 2016 (UTC)
Um, actually it is - or should be - now by default.Jo-Jo Eumerus (talk, contributions) 08:47, 2 April 2016 (UTC)
Yes, since Wikipedia:Village pump (proposals)/Archive 126#Userpage drafts shown in search engines. –xenotalk 09:43, 2 April 2016 (UTC)
It's opposite. The green triangle in Google's search gives a "Cached" link which shows Google cached the page 12 Mar 2016 19:19:06 GMT where User:Streetseekers/Blackwater Primero was a redirect to mainspace after a move [10] to Blackwater Primero. The redirecting version was overwritten and deleted when the page was moved back 28 March so the user page should be removed from Google next time they visit it. Redirects from userspace to mainspace are not noindexed. PrimeHunter (talk) 10:00, 2 April 2016 (UTC)

RfC: Linking to talk page sections from multiple issues templates[edit]

An discussion after an edit request at the template protected {{Multiple issues}} about whether and how to include single or multiple links to related talk page sections in the condensed interpretations of the child issue templates has reached an apparent impasse.

Your input is thus hereby requested there. fredgandt 10:04, 2 April 2016 (UTC)

Old gadget stylesheet stuck in ResourceLoader[edit]

Krinkle, Can saomeone purge MediaWiki:Gadget-NewMainPage.css from whatever place possible? An old revision is stuck inside <style>...</style> tags and there is nothing I can do to clear the problem. I tried purging a thousand times, null-edits, deleting/disabling the gadget; nothing works! I'm quite desperate now... -- [[User:Edokter]] {{talk}} 10:26, 2 April 2016 (UTC)

It seems the only results I can get is the bad styling, or no styling at all... I am now getting quite aggitated. -- [[User:Edokter]] {{talk}} 10:35, 2 April 2016 (UTC)

Edit request button leads to wrong target[edit]

I was trying to submit an edit request for Module:Message box, but the "Submit an edit request" button leads me to Wikipedia:Main Page/Errors. Perhaps it's because of the casacde-protection due to being transcluded on the main page. nyuszika7h (talk) 11:40, 2 April 2016 (UTC)

Removing Wikidata bots from watchlist?[edit]

I like having Wikidata on my watchlist, and I like having Wikipedia bots on my watchlist, but the Wikidata bots just seem to clutter everything up. Is there a way to just remove the Wikidata bots while leaving the Wikipedia bots and the rest of Wikidata on my watchlist? Cheers, -- Irn (talk) 12:48, 2 April 2016 (UTC)

Adding/changing information for pagecounts-ez dump[edit]

I'm having difficulty figuring out the encoding for page titles in the dumps at https://dumps.wikimedia.org/other/pagecounts-ez/merged/. For example, with pagecounts-2015-01-views-ge-5-totals.bz2, I can see

  • en.z %D9ˆ%D9Š%DA%A9%D9Š%D9%BE%DB%90%DA‰%D9Š%D8%A7:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License 8
  • en.z (-)-2£]-(1,2,4-Oxadiazol-5-methyl)-3£]-phenyltropane 8
  • en.z 07_Zgå‚oå›_Siä™ 10
  • en.z 1._Fc_Kã¶ln 10
  • en.z 1._Fc_Slovã¡cko 8

UTF-8 conversion dies on this. I wonder if the encoding could be added to the documentation at https://dumps.wikimedia.org/other/pagecounts-ez/?

Also the url link at the bottom of that document is wrong (although the text form is correct)

HYanWong (talk) 20:19, 2 April 2016 (UTC)

source: https://web.archive.org/web/20160402144920/https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)

Leave a Reply