Wikipedia:Village pump (technical): Difference between revisions

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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

« Archives, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 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, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222

Templated reasons in MediaWiki:Ipbreason-dropdown

Many of the user talk templates were standardized several years ago, including block messages; Wikipedia:Template messages/User talk namespace#Blocks. It appears MediaWiki:Ipbreason-dropdown was missed in the update. I'd like to correct them to match the correct template names, and add an informative note beside each one. For example,

{{spamusernameblock}}

would be changed to

{{uw-spamublock}} <-- Promotional username - Bad faith -->

. Any objections? I'll do a full mockup of all changes in a sandbox if requested. --Geniac (talk) 03:18, 26 January 2015 (UTC)

{{spamusernameblock}} doesn't sound like a warning, and its name as is doesn't need an XML explanation, it's clear. But actually I don't care, if you think your solution is better, make it so. JFTR, <!--  –Be..anyone (talk) 16:52, 26 January 2015 (UTC)

I'm not sure what you mean. spamusernameblock doesn't sounds like a warning because it isn't a warning; it's a block notice. I'm proposing updating block reasons, not any warnings. I've posted to the sandbox subpage MediaWiki:Ipbreason-dropdown/sandbox and I'll wait at least a day or two for discussion. And yeah I forgot the ! in my example here. --Geniac (talk) 01:46, 27 January 2015 (UTC)

Don't see the problem as long as you don't break Special:Block (which uses that page as the input to its dropdown menu). Black Kite (talk) 22:37, 27 January 2015 (UTC)

Yes, Special:Block uses that page. That's my point; the options in that dropdown menu need updated and some of them need annotated. Another improvement I've made in the sandbox is to group some related block reasons together in a logical order. --Geniac (talk) 01:14, 28 January 2015 (UTC)

uw = "user warning" is arguably misleading for a block, but no big deal. –Be..anyone (talk) 03:35, 29 January 2015 (UTC)

The uw- prefix simply indicates that a user talk template was a part of the standardisation effort of 2007, not that a template is necessarily a warning. That's neither here nor there; those are the current correct template names. --Geniac (talk) 03:45, 30 January 2015 (UTC)

Unenforced non-blank edit summaries

Hello! While editing lead section of the Data scrubbing article, I've accidentally clicked on the "Save page" button instead of "Show preview" and my edit was saved with no edit summary. The trouble is that I have "Prompt me when entering a blank edit summary" ticked in my preferences and blank edit summaries shouldn't be allowed; that enforcement seems to be working as expected when editing non-lead sections, but fails to protect lead section edits. While editing that lead section, I've used the "edit" link provided by having "Add an [edit] link for the lead section of a page" ticked in my preferences.

Perhaps this bug has something to do with the automated insertion of /* top */ into edit summaries when lead sections are edited, what was introduced about a year ago or so. However, IMHO it should be fixed, if you agree. — Dsimic (talk | contribs) 13:20, 26 January 2015 (UTC)

• Dsimic, I'm not sure if this is what happened in your case here, but if you click save, and notice some text out of place or something and go back to fix it or whatnot I've found it easy to forget I clicked save once. When you click save again, it goes right through because you've already clicked once and technically gotten your blank summary warning. It's actually never prevented saving, it just takes you back to the edit window and doesn't let you know why. It can be very confusing to new users. I'll try to put in a phab ticket today if I can remember. :) — {{U|Technical 13}} (e • t • c) 14:20, 26 January 2015 (UTC)

@Technical 13: Yeah, I didn't mean that edits with no summaries are completely impossible, instead I had those "first click" warnings in mind. Sorry for not describing it more precisely. However, just to make sure, I've tried to reproduce this bug, and a test edit on a lead section, with no edit summary provided, was saved immediately after clicking on "Save page" with no warnings or anything. So, that's what happened in the first place. :) — Dsimic (talk | contribs) 14:44, 26 January 2015 (UTC)

Sooo... is this a bug or a feature? :) — Dsimic (talk | contribs) 11:35, 27 January 2015 (UTC)

Nobody finds it important? Technical 13, maybe? — Dsimic (talk | contribs) 12:50, 28 January 2015 (UTC)

It seems like a minor issue and I doubt it can be fixed without an unreasonable effort by the developers to adapt a MediaWiki feature to take a gadget into consideration. "Prompt me when entering a blank edit summary" at Special:Preferences#mw-prefsection-editing is part of the MediaWiki software which powers thousands of wikis. "Add an [edit] link for the lead section of a page" and everything else at Special:Preferences#mw-prefsection-gadgets is made at the English Wikipedia, in this case MediaWiki:Gadget-edittop.js where /* top */ in the edit summary was added in [1] after discussion at Wikipedia:Village pump (technical)/Archive 123#Editing the lede as opposed to editing the whole article. If you really want to avoid the issue then you could disable the gadget and make a version in your common JavaScript without /* top */. You could probably just copy code from MediaWiki:Gadget-edittop.js and remove a few things near the end without having to know JavaScript. PrimeHunter (talk) 13:20, 28 January 2015 (UTC)

• I really don't have time right now, but what I would do is modify the gadget to check if the `warn on blank summary` option is activated if ( mw.user.options.get( 'forceeditsummary' ) === 1 ) { ... and then hijack the Save page button to see if ( $( '#wpSummary' ).val() === '/* top */' ) { ... and if it does throw confirm( 'Blank edit summary detected,\npress [OK] to save anyways\nor[Cancel] to go back' ) and then if they click OK $( '#editform' ).submit(); or if they click cancel do $( '#wpSummary' ).focus();. Anyways, I don't currently have access to gadget pages and I'm too busy to work up and test it in a sandbox at this time. Ping me back in a couple three weeks or so if you can't find someone else to do it and I'd be happy to. :) — {{U|Technical 13}} (e • t • c) 14:52, 28 January 2015 (UTC)

@PrimeHunter and Technical 13:

Went ahead and had a look at includes/EditPage.php from MediaWiki 1.24.1: basically, MediaWiki sends an MD5 hash of the default edit summary as a value of the form variable wpAutoSummary on edit pages, and compares it when the form is submitted later to see whether a summary was entered (better said, whether it was modified). Gadget-edittop.js jumps into the middle of that and pretty much "breaks" the relationship between the default edit summary and its stored MD5 hash. In more detail, Gadget-edittop.js presets the summary using GET variable summary, what is additionally handled in includes/EditPage.php as a fix for bug #17416: if submitted using &summary=, edit summary is checked only to be non-empty (the default summary is forcibly assumed to be empty) – that's why /* top */ is accepted.

Thus, Gadget-edittop.js should instead set the summary by modifying wpSummary form varible upon the initial loading of edit pages, and should also initially set the wpAutoSummary to the value of md5('/* top */'). That should correct this issue, by establishing the same relationship as if the setting of a default edit summary was performed by MediaWiki. Would something like that be doable in Gadget-edittop.js? — Dsimic (talk | contribs) 15:01, 28 January 2015 (UTC)

• Okay, so then Phab:T19416 apparently isn't fixed or was rebroken is what you are saying? MrBlueSky, since you're the one that marked this as resolved, maybe you or Happy-melon (bug author?) can help clarify there. — {{U|Technical 13}} (e • t • c) 19:03, 28 January 2015 (UTC)

Well, that's what the code in MediaWiki 1.24.1 does (see lines 2428–2433 in includes/EditPage.php). If that behavior is changed, then it seems that Gadget-edittop.js should be working as expected with no modifications. — Dsimic (talk | contribs) 20:04, 28 January 2015 (UTC)

Phab:T19416 asks to not require a different edit summary when &summary= is set. MrBlueSky (talk) 21:24, 28 January 2015 (UTC)

Hm, the whole Phab:T19416 is like "well, I like my waffles with xyz syrup" with no real explanation and no analysis on what else could be affected by such changes. Maybe I'm missing something, but in a request like this it would be important to state where pre-specified summaries shouldn't be validated to be different when a page is submitted; as-is, IMHO it doesn't look like it's about a bug or specific misbehavior. — Dsimic (talk | contribs) 21:39, 28 January 2015 (UTC)

Well, I guess this is one of those WP:DEADHORSEs. :) — Dsimic (talk | contribs) 06:00, 31 January 2015 (UTC)

Find red links

Hello. Is there a way to find all red links that are in all the articles of a certain category? Xaris333 (talk) 21:28, 28 January 2015 (UTC)

There is in AWB: make a list of pages in the category, save the list, convert it to a pipe-separated list, and make a new list using "Links on page (only redlinks)" for those pages. If you don't use AWB, I could make the list for you if you gave the category name. SiBr₄ (talk) 21:41, 28 January 2015 (UTC)

User:SiBr4 thank you! I did it! Xaris333 (talk) 22:13, 28 January 2015 (UTC)

Thanks from me, too, as I didn't know I could provide a piped list of pages for that purpose, and I've been using AWB since last summer. Stevie is the man! ^{Talk • Work} 15:10, 31 January 2015 (UTC)

Japanese and Chinese character forms

Issues sometimes arise with browsers displaying the wrong form (Chinese or Japanese) of a particular character (e.g. 直 versus 直). Typically they seem to default to Chinese, which is inappropriate for Japanese content. Japanese (or Chinese) can be forced using the HTML "lang" parameter or various templates that presumably generate this internally, but it is highly tedious to do this throughout a long article that makes extensive use of such characters. Instead, what is needed is a way to set a default (Chinese or Japanese) for a whole article. Is this currently possible, and, if not, could I place a request for it to be considered as an enhancement? 109.157.11.14 (talk) 21:36, 29 January 2015 (UTC)

Can you give an example of each? --  Gadget850 ^talk 21:38, 29 January 2015 (UTC)

Do you mean an example of a character that looks different in the two languages? I gave an example at the start of my post. If they look the same to you then it must be due to some local issue on your machine (e.g. maybe you don't have a Japanese font installed). If you don't mean this then I'm afraid I don't understand what you are asking. 109.157.11.14 (talk) 22:04, 29 January 2015 (UTC)

For those like me who didn't know the issue, it appears that some Unicode characters are supposed to render differently depending whether they are part of a Chinese or Japanese text. {{lang|zh|直}} and {{lang|ja|直}} contain the same character 直 renders as: 直 and 直 contain the same character 直. The zh and ja version render differently for me. The third unmarked version renders like the Japanese in my Firefox 35.0.1 on Windows Vista. So does all three in the nowiki text. {{lang}} merely adds a "span lang=". I see exactly the same if "span lang=" is made directly. <span lang="zh">直</span> and <span lang="ja">直</span> contain the same character 直 renders as: 直 and 直 contain the same character 直. PrimeHunter (talk) 22:04, 29 January 2015 (UTC)

The first samples appear different to me. Please provide examples where you see the problem: what articles? --  Gadget850 ^talk 22:07, 29 January 2015 (UTC)

Hes not saying anywhere is rendering it wrong, hes saying its tedious to have to set the language for every character, and would like to set it once for the whole page. Could a template at the top of the page set a variable that could then be read as a default value for unicode display later in the page? Gaijin42 (talk) 22:09, 29 January 2015 (UTC)

As I understand it, the display is potentially incorrect in any article that does not explicitly set the language (directly or indirectly via a template) every time Japanese or Chinese characters are used. Whether it is actually incorrect depends on what the browser does by default. Note also that most characters render the same. Only a few are different. 109.157.11.14 (talk) 22:38, 29 January 2015 (UTC)

When I read "whole article" then I infer that certain articles have a problem. What articles and what are some of the wrong characters in that article? --  Gadget850 ^talk 22:45, 29 January 2015 (UTC)

I can't remember now, and it doesn't matter. It is a general usability/maintainablity thing. For example, Japanese grammar has masses of Japanese text with no language set. If there any any uses of these dual-form characters (I haven't checked the whole article!) then they would likely display incorrectly. Rather than going through checking every line and applying "lang=", a better solution is clearly to set the language once at the top of the article. 109.157.11.14 (talk) 22:50, 29 January 2015 (UTC)

The lang= attribute is already set at the top of every article, and it is set to lang="en" because this is the English Wikipedia. On the Japanese Wikipedia, pages have lang="ja" set at the top. This code must match the language of the page as a whole: if any part is not in the default language, that part should be marked up as being in that other language (whether by using <span>...</span> <div>...</div> or some other element isn't important), but if that element has (say) the lang="ja" attribute, it cannot enclose any text that is not in Japanese, unless that text is itself marked up using (say) <span lang="en">...</span> for text in English. --Redrose64 (talk) 23:33, 29 January 2015 (UTC)

It couldn't override the main language being English, of course. What would be convenient is a directive "everywhere you find Chinese/Japanese characters, set the language as Japanese (or Chinese)". 109.157.11.14 (talk) 00:12, 30 January 2015 (UTC)

Theoretically, you could write a parser function that could set a value like this for the whole page (a little like DEFAULTSORT). However, while it could work on a small subset of pages, I can see inherent problems on getting it to work for all pages in all languages. Even with a language pairing like English and Japanese that use different character sets, it would be difficult for a program to reliably tell which content was English and which was Japanese. For example, 三菱東京UFJ銀行 (Mitsubishi Tokyo UFJ Bank) should be tagged as being Japanese, but I could easily see a program mistakenly tagging the "UFJ" in the middle as being in English. And it only gets more complicated when you consider language pairings with the same or similar character sets, or pages that contain text in three or more languages. Tagging Japanese text manually may be a pain, but as far as I can see it is the only reliable way of getting it right. — Mr. Stradivarius ^{♪ talk ♪} 11:44, 30 January 2015 (UTC)

Redrose64 is right: every English Wikipedia page has the language set to English by the MediaWiki software. Where other languages such as Chinese or Japanese are used, we have templates to set the language code. Without specific page examples, I can't see what is going on and I can't help. --  Gadget850 ^talk 23:53, 29 January 2015 (UTC)

I have given you a page example. I believe I have explained the issue clearly enough. I don't know why you can't seem to understand it. 109.157.11.14 (talk) 00:09, 30 January 2015 (UTC)

I see you did point out Japanese grammar. ("I can't remember now, and it doesn't matter." made me skip over the example). All of the Japanese text should be enclosed in {{lang-ja}} for proper language support. As PrimeHunter pointed out, the characters render differently when different language templates are used or not used. We have a series of templates for language support. --  Gadget850 ^talk 00:41, 30 January 2015 (UTC)

In both Chinese and Japanese 直 (U+76F4) is the same character with the same meaning. The difference is that the glyph in Chinese fonts looks different from the glyph in Japanese fonts. This FAQ from unicode.org explains how this works, using the example of this character (U+76F4). So if we had a global tag for the whole page, we would be telling the browser that we want one font or the other for characters in the Asian code range. I think that modern browsers already have heuristics to handle this and usually get it right. For example, Japanese grammar and Chinese grammar both display fine for me, even though neither specifies the lang= for all characters. The problems tend to come up when pages contain mixed languages. One example is this page. If you look at the HTML for that page, it handles the 3 different glyph sets in the same way that we do, by wrapping the characters in "lang=ja" or "lang=zh-Hant" spans. We can always do the same thing on Wikipedia if the characters are not displaying properly. – Margin1522 (talk) 06:24, 30 January 2015 (UTC)

Help needed with recursive template

I wrote a template which takes as its single unnamed parameter either a year or the word 'current'. In the latter case it determines from wikidata what the current year is, then calls itself with that value.

Documentation tells me recursion is fine for one level. However I got a recursion error straight away. Then I tried using safesubst: which seemed to work, but only later did I see that it did a regular substitution. Currently the only valid years for input are 2007 and 2010, but at the next census-like point there will be a later year, which I want 'current' to reach. That won't happen with substituted code. I know I can break this into two templates, one to determine the current year which is invoked from the other. But I'd like to know whether recursion is allowed or not.

click "show" at right to view

1st version gave recursion error {{#switch:{{{1|}}} |2007=<ref name=NSO07>{{cite web |publisher=National Statistics Office |url=http://www.census.gov.ph/data/census2007/h070000.pdf |title=Population and Annual Growth Rates by Province, City and Municipality: Central Visayas: 1995, 2000 and 2007 |archiveurl=http://web.archive.org/web/20110624035646/http://www.census.gov.ph/data/census2007/h070000.pdf |archivedate=2011-06-24}}</ref> |2010=<ref name=NSO10>{{cite web |url=http://www.census.gov.ph/sites/default/files/attachments/hsd/pressrelease/Central%20Visayas.pdf |title=Total Population by Province, City, Municipality and Barangay: as of May 1, 2010 |work=2010 Census of Population and Housing |publisher=National Statistics Office |accessdate=1 April 2013}}</ref> |current={{PH census|{{#invoke:Wikidata|getQualifierDateValue|P1082|P585|FETCH_WIKIDATA|y}}}} }}<noinclude>{{documentation}}</noinclude> then safesubst: (or so I thought) {{#switch:{{{1|}}} |2007=<ref name=NSO07>{{cite web |publisher=National Statistics Office |url=http://www.census.gov.ph/data/census2007/h070000.pdf |title=Population and Annual Growth Rates by Province, City and Municipality: Central Visayas: 1995, 2000 and 2007 |archiveurl=http://web.archive.org/web/20110624035646/http://www.census.gov.ph/data/census2007/h070000.pdf |archivedate=2011-06-24}}</ref> |2010=<ref name=NSO10>{{cite web |url=http://www.census.gov.ph/sites/default/files/attachments/hsd/pressrelease/Central%20Visayas.pdf |title=Total Population by Province, City, Municipality and Barangay: as of May 1, 2010 |work=2010 Census of Population and Housing |publisher=National Statistics Office |accessdate=1 April 2013}}</ref> |current={{safesubst:PH census|{{#invoke:Wikidata|getQualifierDateValue|P1082|P585|FETCH_WIKIDATA|y}}}} }}<noinclude>{{documentation}}</noinclude> which became {{#switch:{{{1|}}} |2007=<ref name=NSO07>{{cite web |publisher=National Statistics Office |url=http://www.census.gov.ph/data/census2007/h070000.pdf |title=Population and Annual Growth Rates by Province, City and Municipality: Central Visayas: 1995, 2000 and 2007 |archiveurl=http://web.archive.org/web/20110624035646/http://www.census.gov.ph/data/census2007/h070000.pdf |archivedate=2011-06-24}}</ref> |2010=<ref name=NSO10>{{cite web |url=http://www.census.gov.ph/sites/default/files/attachments/hsd/pressrelease/Central%20Visayas.pdf |title=Total Population by Province, City, Municipality and Barangay: as of May 1, 2010 |work=2010 Census of Population and Housing |publisher=National Statistics Office |accessdate=1 April 2013}}</ref> |current={{#switch:{{#invoke:Wikidata|getQualifierDateValue|P1082|P585|FETCH_WIKIDATA|y}} |2007=<ref name=NSO07>{{cite web |publisher=National Statistics Office |url=http://www.census.gov.ph/data/census2007/h070000.pdf |title=Population and Annual Growth Rates by Province, City and Municipality: Central Visayas: 1995, 2000 and 2007 |archiveurl=http://web.archive.org/web/20110624035646/http://www.census.gov.ph/data/census2007/h070000.pdf |archivedate=2011-06-24}}</ref> |2010=<ref name=NSO10>{{cite web |url=http://www.census.gov.ph/sites/default/files/attachments/hsd/pressrelease/Central%20Visayas.pdf |title=Total Population by Province, City, Municipality and Barangay: as of May 1, 2010 |work=2010 Census of Population and Housing |publisher=National Statistics Office |accessdate=1 April 2013}}</ref> |current={{PH census|{{#invoke:Wikidata|getQualifierDateValue|P1082|P585|FETCH_WIKIDATA|y}}}} }} }}<noinclude>{{documentation}}</noinclude>

As a supplementary, how does safesubst differ from subst (in words I can understand)? --Roger Camotes (talk) 13:42, 30 January 2015 (UTC)

As far as I know, no recursion is possible in wikicode. So you would have to use a simple ifeq on the main template and move the main code to the subtemplate. I have done this to Template:PH census (feel free to revert) but I'm not sure if the wikidata fetch is working correctly yet — Martin (MSGJ · talk) 16:18, 30 January 2015 (UTC)

A template may call itself once; a second level of recursion will throw "" (or whatever the template name is). --Redrose64 (talk) 16:49, 30 January 2015 (UTC)

That's what I thought, but it gave the error on the first recursion. @MSGJ: – that's what I was after. The subst'ed version wasn't even correct.--Roger Camotes (talk) 18:53, 30 January 2015 (UTC)

• I hope you don't mind, I tucked some of that away in a collapsed section as it was making the page render in a way that was impossible to read. Beeblebrox (talk) 17:17, 30 January 2015 (UTC)

"it determines from wikidata what the current year is, then calls itself with that value." That's a terrible use for recursion, and there's no way to make that work. Either write your code in Lua instead, or use a /core template. Jackmcbarn (talk) 20:36, 30 January 2015 (UTC)

If all that you need is the current year, that's ... er ... {{CURRENTYEAR}} which returns 2025. See H:MW#Other variables by type. --Redrose64 (talk) 20:40, 30 January 2015 (UTC)

"current year" was a confusing description. If "current" is passed then the template pulls the census year from the Wikidata entry for the article. You could just make the test in the switch like this: {{#switch:{{#ifeq:{{{1}}}|current|{{#invoke:Wikidata|getQualifierDateValue|P1082|P585|FETCH_WIKIDATA|y}}|{{{1}}}}}|...}}. A subtemplate also works fine. I agree an attempt at recursion is a bad idea. PrimeHunter (talk) 20:54, 30 January 2015 (UTC)

Rollback

Let me preface this by saying I am only asking for technical information on the feasibility of this idea. I just want to know if we can do it before opening a discussion of whether we should. Thanks.

So, the actual idea: rollback as a user right is deprecated and instead it becomes an optional gadget like Twinkle that autoconfirmed users can turn on or off for themselves in the "gadgets" tab of their preferences.

Is that possible, and if so can it be done locally or do we need the foundation to get involved? Also, any guesses about the time frame to implement it should it be approved? Beeblebrox (talk) 17:23, 30 January 2015 (UTC)

The simplest way would be to just give rollback rights to all autoconfirmed users, hide the actual links with CSS, then have a gadget to override that and display them. Another way would be to use $wgGroupsAddToSelf, which could allow autoconfirmed users to add themselves to the rollback group. Both would require relatively trivial changes to the site configuration, but no changes to the software itself. Mr.Z-man 17:32, 30 January 2015 (UTC)

Just remember we'd still need some way to restrict access to tools like Huggle. Huggle should not be enabled as a gadget. Maybe that can be what the "vandal fighter" right is for =P — MusikAnimal ^talk 17:38, 30 January 2015 (UTC)

I might also add if we do create a separate right for Huggle and others, that would conflict with the cross-wiki support of those tools, as they look for rollback on other wikis but will have to be updated to look for a different right on enwiki. We'd also need to update STiki, Igloo and probably others as well. The biggest problem, I think, is that the sneakiest of the sneakiest vandals could create an account, wait till they become autoconfirmed, enable the rollback gadget, then use an older version of Huggle to cause massive damage. All I'm saying is we'd need to somehow ensure users can't get access to powerful semi-automated tools without explicitly being granted the permission on a case by case basis (except is STiki where you automatically get access after 1000 mainspace edits). — MusikAnimal ^talk 20:28, 30 January 2015 (UTC)

A sneaky vandal could already easily use Huggle without being a rollbacker (in theory, they could as an IP). Jackmcbarn (talk) 20:35, 30 January 2015 (UTC)

@Jackmcbarn: Really?! Are the developers aware of this? If it's easy to do we should probably figure out how to fix it! — MusikAnimal ^talk 23:50, 30 January 2015 (UTC)

@MusikAnimal: Yes, really, and by its nature, it's inherently unfixable. For WP:BEANS reasons, I'm not going to provide details here, but I'll email them to you if you want. Jackmcbarn (talk) 23:55, 30 January 2015 (UTC)

@Jackmcbarn: Understandable. I'm intrigued, do contact me if you do not mind! :) — MusikAnimal ^talk 23:57, 30 January 2015 (UTC)

Since I don't that's WP:BEANS, I'll give some hints here. For those interested, it's possible as 1) It's a wiki 2) All the userright checking is done client-side 3) Huggle can do "software rollback". Zhaofeng Li [talk... contribs...] 00:13, 31 January 2015 (UTC)

• I'd support rolling rollback into reviewer and eliminating the extra hat. The reason I say roll it into the next closest grantable right instead of autoconfirmed is so that the community will still have control over who has it without having to revoke the lowest level of access. I'd suggest doing it as a two step process, first add the rollbacker rights to reviewer explicitly. Then give the developers and the community a (few) months notice that rollbacker is being deprecated and inform them they need to update their code accordingly. Make sure that all notices mention that assistance will be available for those in need of it. Then, when whatever is agreed to be a good amount of time has elapsed, run a script that removes the rollback group from all users listed in it and adds those users to reviewer if they are not already a part of that group. Once that is done it will be safe to eliminate the unused and unneeded group entirely. — {{U|Technical 13}} (e • t • c) 16:21, 31 January 2015 (UTC)
• So far I am only seeing one post here that seems to be responding to the question I actually asked. there is a reason I asked here, I am only looking to see if this is possible, this board is not the place to discuss an actual policy change. If I'm reading Mr Z-man's answer correctly the answer is that it probably is possible. Does anyone else have a take on that? Beeblebrox (talk) 18:37, 31 January 2015 (UTC)
  • Since Twinkle already does it, it is obviously possible. The only question left is what to do with the rollback group itself. — {{U|Technical 13}} (e • t • c) 19:08, 31 January 2015 (UTC)
• Since the answer seems to be that it is possible I've gone ahead and proposed it at Wikipedia:Requests for comment/Rollback 2015. Beeblebrox (talk) 21:43, 1 February 2015 (UTC)

Talk pages on Android devices.

I am really confused about talk pages when using Android devices. I am using the wikipedia app, but can't see the normal PC page layout with the talk page tab, except (strangely) on this particular page since I have started a new section by posing this question. Apologies if Im asking a stupid question. In conclusion then, how do I get e.g. Chrome apo or the wikipedia app on Android to display like a PC. 1812ahill (talk) 18:15, 30 January 2015 (UTC)

• 1812ahill, scroll to the bottom of the page and click the link for "desktop mode". — {{U|Technical 13}} (e • t • c) 18:32, 30 January 2015 (UTC)

@1812ahill: The Wikipedia app is meant to provide a simpler mobile view of articles. You can get a desktop view on Chrome, however. Visit any article through Chrome and then scroll to the very bottom - you should see a "Desktop" link. Clicking it will make Wikipedia start displaying like they would on a PC. You can switch back to mobile view by scrolling to the bottom again and selected "Mobile view". ~SuperHamster Talk Contribs 18:33, 30 January 2015 (UTC)

restore IPA symbols that have been removed from editing window

The editing window has been revamped, and tone letters have been removed from the IPA (under 'special characters'). Perhaps others as well. Could someone restore them? There are also lots of useless entries, such as ʙ̩: If someone really needs a syllabic bilabial trill (and it's likely that in the entire history of WP no-one ever has), then it can be entered with two keystrokes. — kwami (talk) 22:21, 30 January 2015 (UTC)

See Help:CharInsert. --  Gadget850 ^talk 22:28, 30 January 2015 (UTC)

@Kwamikagami: presuming you use monobook, i think the problem is in User:Kwamikagami/monobook.js. some time ago, the script loading logic was somewhat changed, and now, if there is an error in your personal scripts, some of the system's gadgets and scripts will not load. your personal monobook script has a problem (it contains a line that was probably meant for your personal css file rather than your personal js file).

the problematic line is .IPA { font-family: 'Gentium', 'Charis SIL', serif; }. my guess is that simply removing this line, will resurrect the functionality you lost. peace - קיפודנחש (aka kipod) (talk) 23:16, 30 January 2015 (UTC)

Tested: It completely kills CharInsert for me. Documented at Help:CharInsert. The JS page now warns of errors on save. --  Gadget850 ^talk 23:59, 30 January 2015 (UTC)

Thanks! That restored CharInsert under the edit window. The one over the edit window is still missing tone in the IPA, but as long as people have access to both, it shouldn't matter. — kwami (talk) 03:13, 31 January 2015 (UTC)

Per MediaWiki:Gadgets-definition, the CharInsert gadget depends on the 'user' module. If executing the user module fails (because of incorrect syntax), then the dependency will not be fulfilled, and CharInsert will therefore not be loaded. If this behavior is not desired, you shouldn't depend on the 'user' module. Matma Rex talk 12:42, 31 January 2015 (UTC)

@Matma Rex: i do not remember (and can not verify) that syntax error in personal common.js causes mediawilki.user to fail loading. actually, a 2-minutes experiment did not confirm that this behavior exists today. is this something new? peace - קיפודנחש (aka kipod) (talk) 19:22, 2 February 2015 (UTC)

@Kwamikagami: for me, the "IPA" section under "special characters" from the toolbar has 226 different characters. are you sure it had more than that in the past? i do not use IPA characters, so i can't say it never did, but i find it highly unlikely. how many characters do *you* see under IPA in the toolbar? is it possible you missed the little scrollbar on the right? peace - קיפודנחש (aka kipod) (talk) 20:45, 2 February 2015 (UTC)

Because the bottom edit window had disappeared, and a new one appeared at top, I thought it had been moved. But I was wrong: with the fix mentioned above, my browser now displayed both. The one on top has a bunch of pre-composed charater+diacritic entries, the one on bottom has tone. — kwami (talk) 23:42, 2 February 2015 (UTC)

@Kwamikagami: again, i do not know much about IPA, but the one on top has 226 symbols. the charinsert one (the one on bottom) has 163. there's a second one called "IPA English" with thirty-odd symbols, but both of these groups combined contain less symbols than the one in the top toolbar, so i'm not sure what you mean when you talk about "tone"... peace - קיפודנחש (aka kipod) (talk) 18:42, 3 February 2015 (UTC)

The general IPA at bottom is complete. The tone letters are ˥ ˦ ˧ ˨ ˩ ꜛ ꜜ. The English one is a subset for our conventions on WP. The one on top adds a bunch of precomposed combinations. — kwami (talk) 18:47, 3 February 2015 (UTC)

@Kwamikagami: again, i know nothing about IPA, but if i understood what you just said, the one at the top is missing some characters it would have. can you please fill in a bug report? Phabricator: can be used directly with your wikipedia account (i think), so it should be pretty straightforward. just create a new task (click "+" in top toolbar) named something like "Edit toolbar: Special characters (IPA) missing symbols", and list all the missing ones in "description". thx. peace - קיפודנחש (aka kipod) (talk) 19:37, 3 February 2015 (UTC)

The top window is missing the following IPA symbols: ⱱ ᶣ ᵊ ˕˔ ˥ ˦ ˧ ˨ ˩ ꜛ ꜜ ↗ ↘

and the diacritics on the following: k̚ s̺ s̻ θ̼ s̬ n̥ ŋ̊ a̤ a̰ β̞ r̝ e̘ e̙ u̟ i̠ ɪ̈ e̽ ɔ̹ ɔ̜ ə̆ z̴ ə̋ ə́ ə̄ ə̀ ə̏ ə̌ ə̂ ə᷄ ə᷅ ə᷇ ə᷆ ə᷈ ə᷉ t͜ɬ k͈ s͎

— kwami (talk) 22:15, 3 February 2015 (UTC)

Wikipedia's eMail interface

Tracked in Phabricator
Task T66795

Over the past month or two, I have had problems using our eMail interface (on 4 or 5 occasions, most recently on this timestamped day). The messages were either prolonged in delay, or not delivered at all – in every instance, I was not sent a copy of the email either, which my preferences stipulate, should happen. Any ideas? Thank you.--John Cline (talk) 06:59, 31 January 2015 (UTC)

You may be running into the bug described at phab:T66795, if your email provider is Yahoo or one of the others mentioned on that bug page. -- John of Reading (talk) 09:35, 31 January 2015 (UTC)

Thank you, this seems to be describing my problem.--John Cline (talk) 10:33, 31 January 2015 (UTC)

• For those unaware, having an email account with Yahoo!, AOL, Comcast, Hotmail, GMail, or any other email provider that has set their Domain-based Message Authentication, Reporting & Conformance (DMARC) policy to p=reject will prevent using Special:EmailUser. Since the MediaWiki software is set up to spoof sending emails with the from address set to pretend it is sending directly from your mail client that has a domain that does not match the sender domain, it causes it to be rejected by mail hosts instead of sending directly from the local domain with the reply to address set as your address. — {{U|Technical 13}} (e • t • c) 13:06, 31 January 2015 (UTC)

• Slight clarification yahoo.com and aol.com have set DMARC policy to p=reject [2] [3]. Others such as gmail.com and outlook.com (the new hotmail.com) and mail.ru have a setting of p=none [4] [5] [6]. Yahoo explains their policy here. Some other sites don't publish records. --Mrjulesd (talk) 13:43, 31 January 2015 (UTC)

(edit conflict)Thank you Technical 13 and Mrjulesd. I am curious, will this situation also affect one's ability to get a password reset sent to the email address? It may seem obvious to the more technically fluent within our midst; but I must ask: what is a good/best manner of mitigation, or is this somehow in our own best interest; whereas instead, I should adopt a mindset of acceptance?--John Cline (talk) 13:55, 31 January 2015 (UTC)

• John, it shouldn't interfere with the ability to get a password reset because those emails are actually coming from the the domain they say they are coming from. Those emails come from something like [email protected] and have a sender set as [email protected]. The issue is when we try to send email from one user to another and the emails actually come from [email protected] but the sender is set to [email protected]. The way to fix this of course, although apparently not as simple as it seems, is to have the email come from [email protected], have the sender set to [email protected], and have the reply-to set to [email protected]. — {{U|Technical 13}} (e • t • c) 14:15, 31 January 2015 (UTC)

• And to be very clear, this isn't broken on Wikipedia's end, some mail provider have decided to block these messages and the complaint technically should be from their customers to them (customer being a VERY loose word here as these are free providers whose actual customers are advertisers, email users are their product). I agree with T13 above that we could band-aid our system and the primary arguments against it all seem to be along the line of "sending a message to these providers that they shouldn't do this" - however I think the chance the providers will actually care about out message is slim to none. @Technical 13:, I haven't followed this very closely, but if this is enwiki specific any reason an RFC to change this behavior would be rejected by the foundation? — xaosflux ^Talk 14:52, 31 January 2015 (UTC)

• xaosflux, it's not enwp specific. It affects all MediaWiki software customers. That said, I still think that we should hold an RfC on whether or not we should formally complain to the foundation as a community that is a customer. The issue I have with calling it a bandaid to fix something that email providers shouldn't do is that more and more email providers are doing it. Where is the threshold when the foundation accepts this is forward progress and will be the accepted norm? This is a question I can not answer and would love to hear feedback from the foundation on. — {{U|Technical 13}} (e • t • c) 15:05, 31 January 2015 (UTC)

• Technical 13 I won't drop the bandaid calling :) , but do think we should change this configuration. I'm missing the why this has to be a production process change for everyone -- even if it is a software change-should be able to be parameterized per project, no? — xaosflux ^Talk 15:10, 31 January 2015 (UTC)

• I need to dig out the code for that special page and how it is processed to know for sure how much work it would be but it is certainly possible to be able to have it per project. — {{U|Technical 13}} (e • t • c) 16:12, 31 January 2015 (UTC)

• @John Cline: One workaround at the moment is to have a second e-mail address, for example with gmail.com or outlook.com. Their current DMARC policy allows spoofing. But of course that could change in the future. Also, if anyone from a yahoo.com address tried to send you an e-mail through the system you'd suffer the same problem.

@everyone surely the best solution for the mediawiki software to spoof sender e-mail addresses slightly differently? For example if [email protected] sent an e-mail, the mediawiki software could spoof the e-mail address something like example@WIKIPEDIA_yahoo.com? Of course to reply the e-mail address would have to altered, but at least the e-mail would be received. --Mrjulesd (talk) 15:56, 31 January 2015 (UTC)

• Altering is not even needed. All they need to do as add an appropriate reply-to: field and clicking reply will automatically put in the correct address. — {{U|Technical 13}} (e • t • c) 16:12, 31 January 2015 (UTC)

External link icons

Different icons for e.g. https:// (see File:External link icons in Vector.png) have been withdrawn, see bugzilla:56604.

The page Help:External link icons needs updating. Hoping someone here can be bothered. – Fayenatic London 15:01, 31 January 2015 (UTC)

Phabricator adds 2000 to bugzilla numbers so you mean bugzilla:54604 = phab:T56604. PrimeHunter (talk) 15:17, 31 January 2015 (UTC)

Help:External link icons is self-updating. MonoBook and Modern still use a number of icons; the help page shows the currently selected skin and different skins can be selected from the page heading. --  Gadget850 ^talk 18:50, 31 January 2015 (UTC)

We removed them from Vector some time ago. Should we remove them for Monobook and Modern as well? -- [[User:Edokter]] {{talk}} 21:12, 31 January 2015 (UTC)

I think they are of limited value. And not accessible, so of no use to screen readers. The same for the locally added PDF icon. --  Gadget850 ^talk 21:42, 31 January 2015 (UTC)

ftp: vs. http: is relevant for me, and PDF as a clear don't is also important, but IIRC the ftp-icon sucked. –Be..anyone (talk) 23:45, 1 February 2015 (UTC)

The Vector FTP icon was a generic document. --  Gadget850 ^talk 00:27, 2 February 2015 (UTC)

Thank link on Recent Changes pages

It would be convenient if there was a Thank link on Recent Changes pages. I would suggest this as an update to the software, or barring that, if there's a user script that adds it, I would use that. I use RC pages a lot for patrolling changes, and having a Thank link there would reduce steps I take to thank other users. Stevie is the man! ^{Talk • Work} 15:05, 31 January 2015 (UTC)

I think the answer to this is not a technical issue but raher the fact that you should actually view a diff before thanking someone for it. Beeblebrox (talk) 18:39, 31 January 2015 (UTC)

And I can from the Recent Changes page. I can hover over the diff to see it. So, it would be nice if I can "thank" from there without additional navigation. Stevie is the man! ^{Talk • Work} 20:12, 31 January 2015 (UTC)

It would be cool if it was made an option in popups when you hover over a diff. Although I suppose if you added everything to popups that was "cool", it would soon become overwhelmed with options. --Floquenbeam (talk) 20:58, 31 January 2015 (UTC)

I should clarify that I'm not asking for the 'Thank' link to be in the popup, just on each Recent Changes entry like they appear in each History entry. Stevie is the man! ^{Talk • Work} 23:02, 31 January 2015 (UTC)

I think that you should make this suggestion "official" by filing it as a feature request under the Thanks project in Phabricator:. (If you need help, then leave a note on my talk page.) I can't guarantee that it would get acted on any time soon, but filing it would put your idea in the list for future consideration. Whatamidoing (WMF) (talk) 07:17, 3 February 2015 (UTC)

Urbane Israel

Hi

There is a title on the Template:Largest cities of Israel that currently reads: Largest cities or towns of Israel which I would like to read Largest urban areas of Israel or Largest urban localities of Israel as per source material here. Help would be appreciated. thanks. GregKaye 15:40, 31 January 2015 (UTC)

@GregKaye: Edit the page Template:Largest cities of Israel, and inside the {{Largest cities}} template, add the parameter |kind=urban areas --Redrose64 (talk) 16:12, 31 January 2015 (UTC)

Categorization of stub tags doesn't work on creation

For some reason, when I've been creating new stub tags, when I save them the first time they don't show up in the category. This is always fixed by saving it the second time without editing it (null edit). I saw this both with {{Arizona-sport-stub}} (created as upmerged to 2 populated categories) and to {{NYC-sport-stub}}. Any idea why that's happenning? עוד מישהו Od Mishehu 09:57, 1 February 2015 (UTC)

@Od Mishehu: The {{asbox}} template - which is the core of every stub template - was Lua-ised a few days ago, so it's best to point out new problems at Template talk:Asbox, which has 45 watchers including me. Or at Module talk:Asbox, if you want to attract a possibly more knowledgeable (but smaller, just 5 watchers) audience. --Redrose64 (talk) 14:05, 1 February 2015 (UTC)

How to - create both category and category talk page with template

I am a little stuck, probably just a little slow in understanding. I have been creating templates for the creation of categories and I am wondering how I could using the same template also create category talk pages. For instance, consider {{Media companies established in year cat}}; in addition to creating the category, I would like to create the associated talk page and put {{WikiProject Companies|class=category}} as the starting content. I've looked a bit at the Magic Word information in mediawiki, but I'm having a tough time understanding specifically how to do this. Thanks for your input. (please include {{reply|ceyockey}} in responding so I can get direct notice of your input -- thanks) --User:Ceyockey (talk to me) 16:04, 1 February 2015 (UTC)

@Ceyockey: Templates don't create pages (categories or otherwise) - people and bots do. Do you mean that you want to put a link into a template, where if somebody clicks that link, they get taken to the edit screen? --Redrose64 (talk) 16:09, 1 February 2015 (UTC)

@Redrose64: OK - simpler explanation. In creating a page such as Category:Media companies established in 2015, if I apply the template {{Media companies established in year cat}} as the content and save the page, not only will the category page contain the desired content, but also the associated talk page will be created bearing the content {{WikiProject Companies}}. In short, by creating the category page, the category talk page will also be created without having to manually add content to that page (i.e. will not have to click on the red talk tab and manually add the wikiproject template. --User:Ceyockey (talk to me) 16:14, 1 February 2015 (UTC)

P.S. I do understand it might not be possible to do this, that, in fact, one might still need to click on a link to invoke creation of the talk page. If that is the case, might it be possible to auto-populate the newly created page with the desired content so that one need only save the page rather than manually inserting content. Thanks. --User:Ceyockey (talk to me) 16:30, 1 February 2015 (UTC)

You say "not only will the category page contain the desired content, but also the associated talk page will be created bearing the content {{WikiProject Companies}}" - I've looked at the template and it has nothing special that might do this. It's transcluded on two category pages, Category:Media companies established in 1957 and Category:Media companies established in 1958; both have a talk page, which was created by yourself and going by the page history there is no evidence that it was automatic - you must have clicked on the "talk" tab, pasted in {{WikiProject Companies|class=category}} and saved (please note, |class=category is redundant). Can you give an example of a talk page which was clearly created automatically, in the manner that you describe? --Redrose64 (talk) 16:48, 1 February 2015 (UTC)

• (edit conflict) Ceyockey, it doesn't work that way. If this is a common application however, a userscript could be created to allow easy creation of both pages in a minimal number of clicks. Let me know if this is desired, exactly what needs to be posted on which pages, and a list of possible editors or projects that would be interested in this. Thanks. — {{U|Technical 13}} (e • t • c) 16:50, 1 February 2015 (UTC)
• See also Wikipedia:AutoWikiBrowser/Create new pages with 2 processes to semi-automatically create pages with some predefined content. Depends on the number of uses, if it's really efficient to dig deeper into that somewhat complex topic (or do it manually like our forefathers :) ). I haven't used that approach yet. GermanJoe (talk) 16:54, 1 February 2015 (UTC)

Date parsing

Resolved: Magog the Ogre (t • c) 19:15, 1 February 2015 (UTC)

Let's say I feed the following string into a template: 20150131. I would like the template to spit out the previous and next dates, which would be 20150130 and 20150201 respectively. Is this doable with templates on Commons or templates on another project which I could copy to Commons? Magog the Ogre (t • c) 18:03, 1 February 2015 (UTC)

{{#time:Ymd|20150131 - 1 day}} → 20150130 and {{#time:Ymd|20150131 + 1 day}} → 20150201 --Redrose64 (talk) 18:45, 1 February 2015 (UTC)

Tech News: 2015-06

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

Problems

• There was a security issue on Wikimedia Labs. Many Labs tools were down after the issue was fixed. [7]

Software changes this week

• The new version of MediaWiki has been on test wikis and MediaWiki.org since January 14. It will be on non-Wikipedia wikis from February 3. It will be on all Wikipedias from February 4 (calendar).
• The "Save page" button in the VisualEditor toolbar is now blue rather than green. This is the same as on the mobile site. [8]
• You can now edit pages on the draft namespace with VisualEditor on the Russian Wikipedia and Hebrew Wikipedia. You can ask to get VisualEditor for a namespace on your wiki. When your community agrees, ask in Phabricator. [9] [10]

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

16:31, 2 February 2015 (UTC)

Content not showing subsections

Hi, the contents on the following page is not displaying subsections. I have played around with it and not been able to get it work. Can anyone look at Operation Brevity and see what the problem is? RegardsEnigmaMcmxc (talk) 19:40, 2 February 2015 (UTC)

The article includes the template {{TOC limit|2}}, which hides third-level and lower sections from the table of contents. SiBr₄ (talk) 19:48, 2 February 2015 (UTC)

Thank you. Never noticed that there.EnigmaMcmxc (talk) 02:51, 3 February 2015 (UTC)

XTools

Hi, XTools are wonderful. Thanks ! However it may need some improvements.I recently checked some articles I've created and I saw some articles which are live but labelled "deleted" and also some others which I'haven't created. Nedim Ardoğa (talk) 20:21, 2 February 2015 (UTC)

VisualEditor News 2015—#1

Since the last newsletter, the Editing Team has fixed many bugs and worked on VisualEditor's appearance, the coming Citoid reference service, and support for languages with complex input requirements. Status reports are posted on Mediawiki.org. Upcoming plans are posted at the VisualEditor roadmap.

The Wikimedia Foundation has named its top priorities for this quarter (January to March). The first priority is making VisualEditor ready for deployment by default to all new users and logged-out users at the remaining large Wikipedias. You can help identify these requirements. There will be weekly triage meetings which will be open to volunteers beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC). Tell Vice President of Engineering Damon Sicore, Product Manager James Forrester and other team members which bugs and features are most important to you. The decisions made at these meetings will determine what work is necessary for this quarter's goal of making VisualEditor ready for deployment to new users. The presence of volunteers who enjoy contributing MediaWiki code is particularly appreciated. Information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins. 

Due to some breaking changes in MobileFrontend and VisualEditor, VisualEditor was not working correctly on the mobile site for a couple of days in early January. The teams apologize for the problem.

Recent improvements

The new design for VisualEditor aligns with MediaWiki's Front-End Standards as led by the Design team. Several new versions of the OOjs UI library have also been released, and these also affect the appearance of VisualEditor and other MediaWiki software extensions. Most changes were minor, like changing the text size and the amount of white space in some windows. Buttons are consistently color-coded to indicate whether the action:

• starts a new task, like opening the ⧼visualeditor-toolbar-savedialog⧽ dialog:  blue ,
• takes a constructive action, like inserting a citation:  green ,
• might remove or lose your work, like removing a link:  red , or
• is neutral, like opening a link in a new browser window:  gray.

The TemplateData editor has been completely re-written to use a different design (T67815) based on the same OOjs UI system as VisualEditor (T73746). This change fixed a couple of existing bugs (T73077 and T73078) and improved usability.

Search and replace in long documents is now faster. It does not highlight every occurrence if there are more than 100 on-screen at once (T78234).

Editors at the Hebrew and Russian Wikipedias requested the ability to use VisualEditor in the "Article Incubator" or drafts namespace (T86688, T87027). If your community would like VisualEditor enabled on another namespace on your wiki, then you can file a request in Phabricator. Please include a link to a community discussion about the requested change.

Looking ahead

The Editing team will soon add auto-fill features for citations. The Citoid service takes a URL or DOI for a reliable source, and returns a pre-filled, pre-formatted bibliographic citation. After creating it, you will be able to change or add information to the citation, in the same way that you edit any other pre-existing citation in VisualEditor. Support for ISBNs, PMIDs, and other identifiers is planned. Later, editors will be able to contribute to the Citoid service's definitions for each website, to improve precision and reduce the need for manual corrections.

We will need editors to help test the new design of the special character inserter, especially if you speak Welsh, Breton, or another language that uses diacritics or special characters extensively. The new version should be available for testing next week. Please contact User:Whatamidoing (WMF) if you would like to be notified when the new version is available. After the special character tool is completed, VisualEditor will be deployed to all users at Phase 5 Wikipedias. This will affect about 50 mid-size and smaller Wikipedias, including Afrikaans, Azerbaijani, Breton, Kyrgyz, Macedonian, Mongolian, Tatar, and Welsh. The date for this change has not been determined.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Please help complete translations of the user guide for users who speak your language.
• Join the weekly bug triage meetings beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC). Information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins. Contact James F. for more information.
• Talk to the Editing team during the office hours via IRC. The next session is on Thursday, 19 February 2015 at 19:00 UTC.

Subscribe or unsubscribe at Wikipedia:VisualEditor/Newsletter. Translations are available through Meta. Thank you! Whatamidoing (WMF) 20:23, 2 February 2015 (UTC)

Toggle between default view and customized settings?

I sometimes wish to browse Wikipedia as a new user and see things as they would. On my own account, I have lots of settings configured. Is there a quick way to toggle all personalization off and see things as a new user would, in such a way that I could easily turn my settings back on? Blue Rasberry (talk) 21:03, 2 February 2015 (UTC)

You would have to log out or use an alternative account with default settings. A few things are different between logged out users and logged in users with default settings. Wikipedia:Sock puppetry#Legitimate uses includes testing. I have User:PrimeHunter2 and User:PrimeHunter3. PrimeHunter (talk) 21:12, 2 February 2015 (UTC)

Alternatively, install a second browser on your computer. I have five (Chrome, Firefox, IE, Opera, Safari), and sometimes run two or more simultaneously (all five at once maxes out my PC memory), but I only log in using one at a time. The logged-out browsers (usually Chrome and IE) show me what a good majority of new users will see. For cases when I need to test for a user who is logged-in but with basic settings, I log in as Redrose64a (talk · contribs), who with just one edit, isn't even autoconfirmed. --Redrose64 (talk) 21:27, 2 February 2015 (UTC)

Alternatively, open a private/incognito window in your usual browser. Matma Rex talk 22:35, 2 February 2015 (UTC)

I use Matma Rex's approach in Firefox (File > New Private Window), but I don't think that's an option on all web browsers. Whatamidoing (WMF) (talk) 07:40, 3 February 2015 (UTC)

"all web browsers" is really not the target here (think Lynx). Privacy mode is supported by _practically_ all the popular browsers - see privacy mode#Support in popular browsers. i doubt there are many wikipedians who feel the need to check the rendering for anons and do not have access to at least one of those. peace - קיפודנחש (aka kipod) (talk) 19:17, 3 February 2015 (UTC)

Edit summary search bug

Letter case affects search results when it shouldn't. Note the differing results for [11] and [12] even though case-sensitive search is unchecked. Andreas JN466 12:29, 3 February 2015 (UTC)

The tool is made by User:Σ. [13] and [14] give the same results while [15] misses all results from section edits but finds all others. So it appears that if "Don't search within /* sections */" is enabled then the search always becomes case sensitive. PrimeHunter (talk) 13:04, 3 February 2015 (UTC)

Well spotted. Thanks. Andreas JN466 14:34, 3 February 2015 (UTC)

VisualEditor on Wikipedia namespace pages

Can someone enable VE on these pages? It is difficult to edit things like WP:SCREENSHOT and VE would be very appreciated. --Rezonansowy_akaRezy (talk | contribs) 13:01, 3 February 2015 (UTC)

Hello, anyone? --Rezonansowy_akaRezy (talk | contribs) 14:26, 4 February 2015 (UTC)

VisualEditor can be enabled on additional namespaces only via a configuration change. Please file a request on Phabricator (guide: m:Requesting wiki configuration changes), preferably after gathering community support at WP:VPR, as the community of this wiki has proven unreceptive to usability improvements in the past. :) Matma Rex talk 21:09, 4 February 2015 (UTC)

Lua module for date handling

Could someone please make (or point me to it, of one exists already) a Lua module which takes a date in a variety of unambiguous formats, and outputs it in one of a few a standard formats, as selected by a switch parameter?

For example, it should accept dates in formats such as:

• 01 February 2014
• 1 Feb 2015
• 1 Feb. 2015
• 23/4/2014
• 23-04-2014
• 2014-04-23
• 2014-04-01 <- note, not ambiguous, as ISO compliant
• 1FEB2014
• others tbc?

(all case insensitive, and allowing other permutations of "1" and "01", "4" and "04"); and output dates in these formats:

• 1 February 2015
• February 1st, 2015
• 2015-02-01
• [as three parameters, YYYY, MM and DD]

It should reject dates in the format:

• 01-02-2015
• 02-01-2015
• 1 Feb 15

as ambiguous, and should reject invalid dates such as:

• 29 February 2015
• 31 September 2015

I would like this module to be available for use in a number of other templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 3 February 2015 (UTC)

mw:Help:Extension:ParserFunctions##time is pretty advanced and uses an existing well-known PHP function. I'm not sure it's a good idea to make an alternative. PrimeHunter (talk) 14:20, 3 February 2015 (UTC)

{{#time:}} seems to accept almost all of these and output what you want.

• 01 February 2014 → 2014-02-01 = 1 February 2014
• 1 Feb 2015 → 2015-02-01
• 1 Feb. 2015 → 2015-02-01
• 23/4/2014 → (This one fails as "Invalid time", presumably this is parsed as M/D/Y, which makes it invalid. Clearly, the format is ambiguous.)
• 23-04-2014 → 2014-04-23
• 2014-04-23 → 2014-04-23
• 2014-04-01 → 2014-04-01
• 1FEB2014 → 2014-02-01

It will, however, also accept your ambiguous and invalid examples, and try to do its best to parse them.

• 01-02-2015 → 2015-02-01
• 02-01-2015 → 2015-01-02
• 1 Feb 15 → 2015-02-01
• 29 February 2015 → 2015-03-01
• 31 September 2015 → 2015-10-01 (these two are really fun, heh)

I agree that it would be better to stick to it rather than create an alternative. As the one invalid "good" example you've given shows, it's really hard to do this well, and #time does an okay job. Matma Rex talk 15:09, 3 February 2015 (UTC)

The extension parser function #time can silently "correct" instances of dates stated in the Julian calendar. For example, 29 February 1900 (which was observed in Greece and Russia) would be rendered as 1 March 1900. This doesn't seem like the kind of function you would want to hide under the covers for use by editors who are potentially unaware of the subtleties of calendars. I would think a function that screams bloody murder when fed a date it considers invalid would be a better choice. Jc3s5h (talk) 15:38, 3 February 2015 (UTC)

Quite. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 3 February 2015 (UTC)

How would we get the multi-parameter output? (Assuming that 01-02-2015 is 2015-02-01 is very, very dumb.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 3 February 2015 (UTC)

Module:Citation/CS1 should have most of this functionality. --  Gadget850 ^talk 06:13, 4 February 2015 (UTC)

Rollback issues

Hello. I often use Twinkle to rollback some edits but the last couple of months the action cannot get completed. I didn't have this issue in the past, only the last couple of months. I thought it might "go away" and gets solve by itself but the issue still exists. I don't know if I did something that caused this. Any help would be useful. In more details; when I click "OK" after I write the summary for the rollback, the action stops at:
"Grabbing data of earlier revisions: revision ....
Info: Opening user talk page edit form for user ...."
I even waited for minutes in case that it just needed more time to complete the action but nothing happens. Any idea why is this happening and how can I fix it? Thank you TeamGale ^(talk) 16:47, 3 February 2015 (UTC)

What is in the browser console? Ruslik_Zero 19:56, 3 February 2015 (UTC)

I am sorry, I forgot to add it. Firefox 35.0.1 W8 TeamGale ^(talk) 07:36, 4 February 2015 (UTC)

See https://developer.mozilla.org/en-US/docs/Tools/Web_Console how to get debug information. --AKlapper (WMF) (talk) 23:05, 4 February 2015 (UTC)

Transclusions

I'm looking at two templates - {{AMQ}} and {{AM station data}}. {{AMQ}} can be used on its own in an article. However, it's also an element of {{AM station data}}.

When I look at "What links here" for {{AMQ}}, I can see all the articles where the template is being transcluded, but that's regardless of which of the two ways it's being transcluded. It feels like there ought to be a way to identify articles that transclude it directly - that is, the article specifically uses {{AMQ}} - but for the life of me, I can't figure it out.

Is this possible? Mlaffs (talk) 18:23, 3 February 2015 (UTC)

A way to do that is to compare the lists of transclusions of both templates to find out which pages transclude {{AMQ}} but not {{AM station data}} (easy if you have AWB). That will however not include pages that directly transclude both separately.

You can also just search for pages that contain "{{AMQ" in the source code, which WP's new CirrusSearch can do (a regex is needed to search for the brackets). A probably more accurate method, which uses AWB, is the one I used here. SiBr₄ (talk) 22:28, 3 February 2015 (UTC)

I'm on a Mac, so AWB won't be an option. However, I've bookmarked that search link so I can use it in the future (and for similar cases) - I won't pretend to understand how that was built, but that's the beauty of bookmarks. Thanks! Mlaffs (talk) 23:03, 3 February 2015 (UTC)

Broken layout of Lua module page

I don't understand why Module:TemplatePar has a broken layout (compared to e.g. Module:String or Module:ATA). Maybe because it was imported, not created locally? --Leyo 19:34, 3 February 2015 (UTC)

I think the multiline comment at the top has confused something (and check the "Categories: %s" at the bottom!). I would try a simple "--" before each of the introductory comment lines. It's not the import. Johnuniq (talk) 20:55, 3 February 2015 (UTC)

It is the import. This is an known import bug, phabricator:T47750.--Snaevar (talk) 22:58, 3 February 2015 (UTC)

Fixed. Jackmcbarn (talk) 23:24, 3 February 2015 (UTC)

Thank you. --Leyo 10:11, 4 February 2015 (UTC)

Code colouring

Wiki editing needs code colouring. Code colouring is a feature of code editing programs, such as XCode in Mac or Notepad++ in Windows, where the various elements are not displayed as black but different colours. It would be really handy, especially if the citations within ≤ref≥ were greyed as a comment as references were worst offenders in terms of legibility. (Yes, I just wanted to put my anger out there. I do not wish to join a technical steering committee, or vote argumentatively or place a counter proposal rich in WP links to push it forth… I'll go back to my science nest now) --Squidonius (talk) 20:17, 3 February 2015 (UTC)

@Squidonius: Actually, there is a gadget for that. Special:Preferences#mw-prefsection-gadgets in the section "Editing" find Syntax highlighter, make syntax stand out colorfully. Then you can try out wikied (the same gadget page section "Editing" wikEd, a full-featured integrated text editor for Firefox, Safari, and Google Chrome). I haven't tested them myself, but you can at least try. Maybe it will help you :) --Edgars2007 (talk/contribs) 20:43, 3 February 2015 (UTC)

Thanks ever so much! You've just made my procrastination fun again! --Squidonius (talk) 21:06, 3 February 2015 (UTC)

Help requested

Over at my talk page - the CRG Int'l threads. We're having a problem getting Legobot to accept his request at CHU. I think I've got rid of a copied | , but Legobot is reading an ASCII 39 code instead of the ' that it wants. I'm getting out of my depth now. Peridon (talk) 20:43, 3 February 2015 (UTC)

Vandalism showing up in Android app, but not the article itself

On the Wikipedia mobile app (Android), viewing the Tom Brady article brings up this (not my image); see the image caption, right below the page title. It's been like this for a couple days I believe, though the article doesn't contain the vandalism anywhere as far as I can tell - and I can't find any recent edits that inserted the text, either. Anyone know what's going on? Caching problem? Is the vandalism transcluded from elsewhere? ~SuperHamster Talk Contribs 21:31, 3 February 2015 (UTC)

I've just fixed some vandalism at Wikidata. Oh dear... -- John of Reading (talk) 21:53, 3 February 2015 (UTC)

@John of Reading: Ouch, that was long lived. Thank you! ~SuperHamster Talk Contribs 22:16, 3 February 2015 (UTC)

There's discussion about it on Wikidata here and here. It looks as if the Wikidata admins are not yet on top of the problem. -- John of Reading (talk) 07:15, 4 February 2015 (UTC)

Category:Category:Pages with script errors

For some reason, a number of pages are getting populated into Category:Category:Pages with script errors. I'm not sure what is causing (or just caused) the double category problem. -- Ricky81682 (talk) 23:10, 3 February 2015 (UTC)

It looks like it was a transient issue. They're all gone now. Jackmcbarn (talk) 23:22, 3 February 2015 (UTC)

Automatically substituting Template:Unsigned and friends

Would anyone object to automatic substitution of Template:Unsigned and other similar signature templates? There are almost 30,000 transclusions of them, so it would be better to make sure there is a consensus to do it before letting a bot loose on them. Please see the discussion at Template talk:Unsigned and the corresponding edit request here. — Mr. Stradivarius ^{♪ talk ♪} 02:47, 4 February 2015 (UTC)

• Yes, I object. This request not only assumes bad faith on the part of an editor who may have simply forgot or been unable to sign ( the ~ isn't available on all mobile devices and copy and past if you have edittools or charinsert isn't always easy ) it is also a change to the content of a discussion that isn't visibly apparent in the rendering and fails COSMETICBOT. I've commented as such and closed the edit request until there is a consensus which should've been obtained first. — {{U|Technical 13}} (e • t • c) 03:21, 4 February 2015 (UTC)

  How does it assume bad faith? The templates are already there, so I don't see how substituting them makes any kind of statement about the editors who made the posts. ekips39 05:59, 4 February 2015 (UTC)

I thought there was a consensus for this. I put a whole bunch of unsigned templates on a talk page, then tried to get bots to archive, and Clubot refused to archive the transcluded unsigned templates (thus, this is a real problem and not just cosmetic). When I posted about it at the bot's talk page, I was told that the bots behavior is intentional since the unsigned template should always be substituted, and the user then went the the talk page and substituted them all. So, to fix this, I put it in this bot's category, but the bot doesn't do it if there's over 100 transclusions. Unsigned has over 20,000, so it would be way too much work for a human. Oiyarbepsy (talk) 03:20, 4 February 2015 (UTC)

Does anyone know the rationale for (a) us wanting all these occurrences to be substituted, (b) the bot not wanting to perform too many substitutions at once? Is the latter due to fear of temporarily overloading the system, though the end result is still desirable? EdJohnston (talk) 04:25, 4 February 2015 (UTC)

I'm not aware of any special rationale for (a), although with this kind of template the reason for substing is usually to make sure that users are guaranteed to see the message as it was originally sent. (If the message is not substed, and someone changes the template after the message is sent, it could look completely different to what the sender intended.) As for (b), this is to prevent vandals from maliciously substing templates with thousands of transclusions, as reverting all the edits would take a disproportionate amount of time and effort. The edits themselves don't put much strain on the system; they are (I think) done at the rate of 6-10 a minute, a similar rate to other bots. This means that while the system load wouldn't be very high, a run of 30,000 substitutions would take a few days to complete. — Mr. Stradivarius ^{♪ talk ♪} 06:31, 4 February 2015 (UTC)

SmackBot, which was operated by Rich Farmbrough, used to do this work; here's an example. Graham87 08:32, 4 February 2015 (UTC)

As far as (a) goes, I assume this to be the dating; a transcluded template containing the current date will always contain the (now) current time (it doesn't, off course, because of bugs/reasons, but it does after an action=purge), while the substituted template will have the time of substitution. Martijn Hoekstra (talk) 13:16, 4 February 2015 (UTC)

I'd thought (a) in this case was mainly to make pages render faster for the server for templates that would be transcluded probably hundreds of thousands of times without subst:, especially if User:SineBot didn't add them substituted. These templates were almost added to Anomie's auto subst list in 2012; only a lack of interested admins at the time prevented it. ‑‑xensyria^T 15:13, 4 February 2015 (UTC)

It's a pretty minor issue either way. But I would be perfectly willing to restart this task, should circumstances permit. All the best: Rich Farmbrough, 18:34, 4 February 2015 (UTC).

Module Citation Style 1 not accepting the 2015 format for arXiv identifiers

Module:Citation/CS1 is borked. It's been that way for a while now. There doesn't seem to be any updates appearing in the talk pages. Can someone fix this? ReferenceBot (talk · contribs) emits error messages onto user talk pages when it encounters perfectly valid arXiv IDs in citation templates that our citation module does not recognize, which may discourage editors from contributing, since they are valid identifiers, but are not being accepted and they receive warnings for doing perfectly valid edits.

ie. CITE JOURNAL "A possible close supermassive black-hole binary in a quasar with optical periodicity". arXiv:1501.01375. {{cite journal}}: Cite journal requires |journal= (help) this is perfectly valid, and exists at http://arxiv.org/abs/1501.01375

-- 70.51.200.101 (talk) 23:25, 4 February 2015 (UTC)