Wikipedia

Wikipedia:Village pump (technical)/Archive 128

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 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

New search history tool

@Hedonil: The new search history tool at https://tools.wmflabs.org/xtools/blame/?style=new is very useful, but what does starting date and ending date mean? For example, is the starting date the date you want to move forward from or back from? The tool can be used without filling in those boxes, but it would be good to know what they mean. --P123ct1 (talk) 18:16, 2 July 2014 (UTC)

We're about to put the finishing touches on X!'s tools suite with all its submodules (modern, userfriendly GUI, new features, more speed). One of the primordial purposes of begin and end was to show some results even if exceeding the old TS-threshold (50,000 revisions).
These restrictions don't apply any longer - it's now unlimited. Thus, in reply to your question/suggestion, I removed both fields from the form. --Hedonil (talk) 09:24, 3 July 2014 (UTC)

help with a javascript application?

Hi, could someone please point me in the right direction for some documentation or other help about how to integrate an application into wikipedia? I'd like to make it available to other editors at WP:PLANTS, for performing moderately complex text reformatting. It exists as html with a separate javascript file (and as an earlier java applet). It has a text input area where the person would paste a largish chunk of text, a "convert" button to click, and a text output area from which they would copy the resulting wikipedia encoding. As a simple experiment, I've made User:Sminthopsis84/TPLConvert.js, just trying to display some text with a date; have imported that into User:Sminthopsis84/common.js, and thought that I could execute the javascript function from another page, as in User:Sminthopsis84/TPLConvert. That gives nothing. I've been reading Help:Wikipedia:_The_Missing_Manual/Customizing_Wikipedia/Easier_Editing_with_JavaScript, but can't find an answer. Any help would be much appreciated. Sminthopsis84 (talk) 14:52, 6 July 2014 (UTC)

Take a look at Wikipedia:User scripts/Guide first. Ask if you still have questions after that. --V111P (talk) 07:15, 7 July 2014 (UTC)
Thanks. If that's all the documentation there is, then I guess that what I've been trying to do is too ambitious. Perhaps I'll be able to find a place to store and run the program outside wikipedia, and create javascript to add a tool button here that transfers to it. Much to learn. Sminthopsis84 (talk) 17:06, 7 July 2014 (UTC)
Don't worry, Sminthopsis84, I wrote a template script for you. You just do your reformatting of the text the user selected in the textarea before he/she pressed your script's toolbar button, then you replace the selection with the reformatted text. (Read the comments in the source code for explanations).
I was thinking of writing a more comprehensive tutorial on writing user scripts before, but sadly there seems to be very little interest in both using and writing such scripts, despite them being potentially very useful, so there is no point of me doing that at this time.
--V111P (talk) 21:41, 7 July 2014 (UTC)
Gosh, that works, thanks V111P! I hope you don't mind if I go to your talk page to quiz you further, as I experiment to see if the application can be grafted into that style of script. It has a help window without which hardly anyone would be able to figure out how to use it, and also has a button for an output option. The matter of documentation is an interesting one, because I'm not without programming experience, but have found it very hard to learn vital things here; I end up going around in circles. For example, it has just been pointed out to me that I didn't discover the Tools lab, which offers the sort of application-hosting that I was thinking of with the sole key-word, "script" without also "tool". However, I'm still going around in circles and haven't yet found places where such hints could be added to the documentation. So, next I need to read about the Tools lab, and see if it can be blended with a tool button here. Sminthopsis84 (talk) 16:42, 8 July 2014 (UTC)
Many things are documented on the MediaWiki website - for example mw:ResourceLoader/Default modules lists available JavaScript libraries, while mw:API:Main page is an introduction to the API which provides direct, high-level access to the data contained in MediaWiki databases. I don't know a lot about the Tools lab, but I think you need it if you need to store data in a database or need to access Wikipedia's database directly on the server. With JavaScript you can do anything on the page, you can see the scripts on my user page for examples. Let me know if you need help with doing anything similar. --V111P (talk) 00:13, 9 July 2014 (UTC)

Parsoid Based Linter

Hi Everyone,

I am a GSOC student working with Parsoid Team to build a Parsoid based linter (Linttrap). Lintrap will detect broken wikitext found on the wiki pages and will also collect stats about certain wikitext usage patterns.

Currently, for this demo, Lintrap can detect 4 types of broken wikitext, But, other kinds of issues could be detected in the coming weeks and months : 

* Fostered Wikitext : Eg1
* Missing End Tag : Eg2
* Missing Start Tag : Eg3
* Stripped Tags : Eg4

Linttrap also collect information about transclusion usages where multiple templates are used to construct a DOM structure Example. Here's our stats page.

Once a page is parsed, Lintrap uses parsoid based logger facility to log them to a web service. We call it Lintbridge. Currently Lintbridge is hosted on Wikimedia Labs and use mongodb to store all the issues. Lintbridge offers a REST api which can be used by bots and other applications to fix the broken wikitext. Linttrap uses this REST api to store issues into Lintbridge.

We have also built a HTML app on top of Lintbridge HTML Page. This is a basic app for now which is used to demonstrate linttrap abilities. But, It is quite useful as it is today. Feel free to browse over the issues. 

 * You can use the links in the table to filter the issues. 
 * Click on issue type to filter issue by issue type. 
 * You can filter issue by page too. 
 * You can use Fix All to fix all issue for that page. 
 * You can even use filters on the top bar to filter by Wiki and Type.
 * Each issue contain a info about wiki, page, revision on the left and the wikitext snippet on the right.

Just for the demo of this working prototype, we have collected issues by parsing 1000 picked from http://parsoid-tests.wikimedia.org/topfails. If you want to try the JSON API you can use the following routes.

GET /_api/issues : Show all issues (http://lintbridge.wmflabs.org/_api/issues)
GET /_api/issues/type/issue-type : Filter by issue-type (http://lintbridge.wmflabs.org/_api/issues/type/fostered)
GET /_api/enwiki/issues : Filter by enwiki (http://lintbridge.wmflabs.org/_api/enwiki/issues)

POST /_api/add : Add a issue to the Lintbridge

If you think you can you use this info to fix wikitext, please let us know.

Inviting feedback, suggestion and feature requests.

Hardik95 (talk) 18:30, 8 July 2014 (UTC)

You might like to get in touch with Wikipedia:WikiProject Check Wikipedia which main wikiproject dealing with errors in wiki syntax. They have an extensive list of syntax errors they check.--Salix alba (talk): 02:36, 9 July 2014 (UTC)

WHOIS for IPs

The WHOIS links visible at the bottom of Special:Contributions for an IP address is a service running on the Toolserver. Is there a comparable service on WMFlabs? Nyttend (talk) 12:24, 3 July 2014 (UTC)

{{Anontools/ipv4}} and {{Anontools/ipv6}} also have a toolserver link on "Tor check". Searches [1][2] show some other MediaWiki namespace pages with "toolserver.org". PrimeHunter (talk) 13:12, 3 July 2014 (UTC)
(edit conflict) @Nyttend: "14:08 < Betacommand> http://tools.wmflabs.org/betacommand-dev/cgi-bin/SIL?ip=101.60.209.117 or more generic http://tools.wmflabs.org/betacommand-dev/SIL.html" Meatsocked by 930913 {{ping}} 13:15, 3 July 2014 (UTC)
That tool does provide some useful information but how is that a complete WHOIS tool? AFAIK, there is no replacement on Labs for a whois tool yet. However, there are many tools to query WHOIS on the interweb (which we can probably use temporarily until a reasonable whois tool is on labs). --Glaisher (talk) 16:49, 3 July 2014 (UTC)
  DoneI have removed the broken links from Template:Anontools/ipv4 and Template:Anontools/ipv6, suggested changes for new tools can be discussed on Template talk:Anontools, please centralize the discussion there. — xaosflux Talk 16:53, 4 July 2014 (UTC)
I have made a suggestion there. SpinningSpark 14:39, 9 July 2014 (UTC)

Uploading logos but need SVG - help

I want to upload logos, but they must be in SVG format. Where can I find a free SVG converter online? I have searched for so many websites but all sucked except Vectormagic. However, they only give you two free trials and the words under the logo gets weird looks. Thanks, Nahnah4 | Any thoughts? Pen 'em down here! | No Editcountitis! 09:52, 9 July 2014 (UTC)

I create all my SVG files using a plain text editor. If you're on Unix, there is vi; for Windows users, there is WordPad but make sure that you save as UTF-8 plain text. Having created the file, I check it by viewing in my browser - for something like eight years now, Chrome, Firefox Opera and Safari have all provided the capability to view a SVG image (recent versions of IE do as well, but not IE 8 or earlier). Some people use Inkscape to create and view SVG files, but that leaves a lot of unnecessary junk in the file that can increase file size by as much as 50% (view a SVG file in a plain text editor, and if you see sodipodi: all over the place, somebody's edited it in Inkscape). --Redrose64 (talk) 11:12, 9 July 2014 (UTC)
There's no simple way to convert raster files to SVG. There are programs that do this, but in most cases it results in sloppy and inaccurate SVGs (click on either of the first two revisions of this file for an example). What I usually do is opening the raster file in Inkscape, drawing the image using paths, rectangles, circles etc., saving as Optimized SVG and then removing the remaining junk in Notepad. SiBr4 (talk) 12:31, 9 July 2014 (UTC)
Why must they be in SVG format? —Designate (talk) 19:58, 9 July 2014 (UTC)

Previous edits incorrectly deleted

Over the years I've repeatedly seen cases of an edit unintentionally deleting one or more previous recent edits. I think this has been brought up here several times in the past (here's one thread from 2009 [3]) but I don't remember seeing any clear explanation of why this is happening. Some could be down to editing an old version of the page as the 2009 thread suggests, but here are some recent ones that happened to me which I am pretty sure are not that: [4][5][6]. The last one in particular I am absolutely certain was not an old version edit. That is because on that one an edit conflict was flagged and the I made the edit through the edit conflict interface. The edit from ColinFine that got deleted was definitely not showing in the window and I definitely did not delete it. That one, however, might possibly be a diffferent problem as usually there is not edit conflict flag at all, the edit just takes, but on examining the diff later someone else's edit has been deleted.

Does anyone know if this has ever gone to Bugzilla? I can't find anything, but all the search strings I tried using came up with too many false hits to be able to sort through them all. SpinningSpark 12:52, 9 July 2014 (UTC)

For the "why", the answer is probably "because it's a bug". https://bugzilla.wikimedia.org/show_bug.cgi?id=11922 ? --AKlapper (WMF) (talk) 12:51, 10 July 2014 (UTC)

GeoGroupTemplate not working (again)

See the "GeoGroupTemplate not working" section at Wikipedia:Village pump (technical)/Archive 127. I'm getting precisely the same results today as I was getting a week ago, although the URL got updated so that it's not seemingly relying on the toolserver now. Can someone explain what's happening? Para spoke of the tool hitting some sort of limit; maybe it's hit it? I don't know at all what that should look like, or what effect it would have. Nyttend backup (talk) 13:41, 9 July 2014 (UTC)

Other Tool Labs users are recommending a tool that restarts the lighttpd server if it's gone. I've put that in place then, none the smarter about why Tool Labs webservices need to be restarted so often. The recent start date of most tools in the "time" column of the status page is fairly descriptive of this... --Para (talk) 17:28, 9 July 2014 (UTC)

Template:Albumchart glitch

On Turn It Up (Josh Thompson album), does anyone know why the second use of {{albumchart}} is causing "Template:Album chart\chartnote" to randomly show up in a big red link? I don't see anything wrong in the coding. Ten Pound Hammer • (What did I screw up now?) 20:51, 9 July 2014 (UTC)

There were some errors with slashes in the code of {{Album chart}}, which 2Flows fixed here. SiBr4 (talk) 21:19, 9 July 2014 (UTC)
@TenPoundHammer: As SiBr4 said above, the problem should now be fixed. However, if you still see the red link on certain pages, try to clear the page's server cache by adding ?action=purge to the end of the URL. If a page has not been edited since the template was fixed, the old version may still be showing for some time. 2Flows (talk) 22:07, 9 July 2014 (UTC)

Changes to how entity references are compared in #ifeq and #switch

Hi folks.

Just a heads up, as of tommorow entity references (&amp;, &gt;, &#32; etc) are going to be considered equal to the characters they represent when comparing string with #ifeq or #switch. For example 

 {{#ifeq:&amp;|&|equal|not-equal}}

Previously would return not-equal, will soon return equal. In particular this means that on pages with special characters in the title (such as *, ', ", =, ;), the comparision has changed. Thus on a page named *foo: 

 {{#ifeq:*foo|{{PAGENAME}}|on page|not on page}}

previously returned not on page, but will soon return on page. Using {{#ifeq:{{PAGENAME:*foo}}|{{PAGENAME}}|on page|not on page}} will continue to work both before and after the change.

For more information see http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-June/000796.html . Changes are already visible on testwiki:. Thanks. Bawolff (talk) 20:59, 9 July 2014 (UTC)

Move tab not appearing

I had been reading a lot of Help Desk archives questions that involved moving an article and so when I clicked on one article mentioned in a question, I naturally found myself looking where the "move" tab should be. I have been autoconfirmed for many years and have moved many articles, and a "Move" tab still appears in the skin I use on most articles. Unless it was very slow to come up, I never saw any kind of lock on Samoa and yet I saw no Move tab. I'm sure I'm asking in the wrong place.— Vchimpanzee • talk • contributions • 21:05, 9 July 2014 (UTC)

It's not appearing in this page either, but it does appear for me on many pages in various namespaces, including for example Jane Egan. Could this be a case of the move tab being hidden for pages with lots of edits? BethNaught (talk) 21:10, 9 July 2014 (UTC)
Samoa is indefinitely move-protected. The "move" button is there for me on Jane Egan. SiBr4 (talk) 21:13, 9 July 2014 (UTC)
Does it have a lock which I'm somehow not seeing?— Vchimpanzee • talk • contributions • 21:14, 9 July 2014 (UTC)
  Facepalm I should have thought of move protection. And the padlock icon is just a template - its usage is discretionary. I agree it would be nice to see it though. BethNaught (talk) 21:17, 9 July 2014 (UTC)
Samoa contains the {{pp-move-indef}} template, though unlike most other protection templates, pp-move-indef does not add a padlock topicon (only a category). SiBr4 (talk) 21:24, 9 July 2014 (UTC)
I'm seeing the move tab both here and on Samoa. It must be that users only see the tab if they have the permissions necessary to actually move the page. I'm not sure if this is a new addition to the MediaWiki software or not. — Mr. Stradivarius ♪ talk ♪ 23:26, 9 July 2014 (UTC)
It has always been that way, and one of the reasons why non-able users have no idea how to get a page moved. On Commons, for this purpose, they add their own "Move" tab, that pushes non-autoconfirmed users into their "Rename a file process" using JS. —TheDJ (talk • contribs) 10:04, 10 July 2014 (UTC)

So based on the above, how about, on move-protected pages, include the move option in the menu, but have it grayed out (like Windows and Mac do) with the message "this page is protected against moves" popping up when you mouseover? Then people would at least know why they can't do it. Ego White Tray (talk) 01:41, 10 July 2014 (UTC)

I believe that the visibility and wording of all the tabs is based on a combination of user rights and page settings. For example, people without the admin bit don't see the "delete" and "protect" tabs; admins don't see a "protect" tab on protected pages (there's a "change protection" tab instead). The absence of a "move" tab for non-admins when the page is move-prot is consistent with that --Redrose64 (talk) 16:30, 10 July 2014 (UTC)

Missing entry in the protection log

John Reaves (talk · contribs · logs) just applied pending changes protection on The Avengers (2012 film). Five minutes later I semi-protected it because when I checked the protection log there was nothing to indicate that he had already done so. See here where the last entry before mine was from 2013. CBWeather, Talk, Seal meat for supper? 22:59, 9 July 2014 (UTC)

They're recorded in different logs, but both logs are shown on the "Change protection level for "The Avengers (2012 film)"" page. Your semi and un-semi are listed under "Protection log", but further down (in fact at the very bottom) the PC change made by John Reaves is under the heading "Pending changes log". --Redrose64 (talk) 23:11, 9 July 2014 (UTC)
OK, thanks. So once again I've managed to make myself look stupid. Good job I'm used to it or I would have to delete this entire page. Of course deleting a page with a large number of edits is one of my other tricks to make me look stupid. CBWeather, Talk, Seal meat for supper? 23:33, 9 July 2014 (UTC)

Table glitch

When ever I start to edit Stig Severinsen#AIDA Freediving World Records then click 'Show preview,' the preview doesn't show the text in the form of a table. The first time I clicked 'Edit' at the top of that section, I made this edit to the edit box then clicked 'Show preview' and it showed text that was not in table format and I guessed that it was because of a Wikipedia source code glitch and not because of the change I made to the edit box before clicking it so I clicked 'Save page' then to see if that was the case, I clicked 'Edit' at the top of that section after I saw that the article itself still had table format in that section then without making any change to the edit box, clicked 'Show preview' and the preview still didn't show table format then I left the page without clicking 'Save page.' Table format does show in the preview if I click 'Edit' at the top of the whole article. Blackbombchu (talk) 01:13, 10 July 2014 (UTC)

The table start was before the section header instead of under it. See my edit HERE. -- George Orwell III (talk) 02:02, 10 July 2014 (UTC)

Wait, since when...

...did clicking on links in diffs actually count as a link? And can I turn it off? Thanks, Ansh666 06:20, 10 July 2014 (UTC)

@Ansh666: I'm not quite sure what you mean here. Could you give an example of where this behaviour is occurring? — Mr. Stradivarius on tour ♪ talk ♪ 06:33, 10 July 2014 (UTC)
Take this diff, for example. Hovering over my signature ([[User:Ansh666|Ansh]]''[[User talk:Ansh666|666]]'' 06:22, 10 July 2014 (UTC)) in the diff text enables clicking on the text, linking to my user pages (and nav popups trigger too). As I like to click on things while reading them, well, this is rather annoying. Ansh666 06:42, 10 July 2014 (UTC)
Hmm, it's not happening for me, either when logged in or logged out. Try logging out and seeing if you still see the same behaviour - that will at least narrow the problem down to something within your account. — Mr. Stradivarius ♪ talk ♪ 07:31, 10 July 2014 (UTC)
I'm sure there's a pref/CSS/JS that can turn this off, even though I don't know what it is, but I just have to ask why the hell you click on things while reading? I can understand highlighting, but clicking on random pieces of text while reading seems like you would run into unknown links a staggering amount of the time. VanIsaacWScont 07:33, 10 July 2014 (UTC)
Well, I did mean highlighting, which I generally do by double clicking on text...which today led me to unexpectedly click on a link. I'll dig around in my prefs again, if it's CSS or Javascript then oh well... Ansh666 08:01, 10 July 2014 (UTC)
CSS and Javascript are easy to change on wikipedia. You've got a User:Ansh666/common.css and User:Ansh666/common.js files, as well as skin specific CSS and JS (look under preferences:appearance/skins), and you'd just need to add the right code to yours to suppress the functionality. VanIsaacWScont 09:42, 10 July 2014 (UTC)`
Well, yeah, I know how to use them, just I don't want to go find the right code. Thanks, though. Ansh666 09:50, 10 July 2014 (UTC)
That is a hidden feature of WikEd / WikEdDiff. —TheDJ (talk • contribs) 09:53, 10 July 2014 (UTC)
I do have that enabled. I thought it was only the stuff that appears when you click the little triangle thing, though... Thanks, Ansh666 10:32, 10 July 2014 (UTC)
The "little triangle thing", is presumably the Delta button Δ. I've also seen it referred to as the "little toggle arrow". --Redrose64 (talk) 12:54, 10 July 2014 (UTC)

New user group

I noticed today that there is a new usergroup 'users' as well as the historical 'Users' (see the bottom of Special:ListGroupRights) which is automatically assigned to accounts. I'm guessing this was a typo by a dev, does this need to go to bugzilla? Callanecc (talk • contribs • logs) 09:43, 10 July 2014 (UTC)

This may be related to Wikipedia:Village pump (technical)/Archive 127#Empty group of users. -- John of Reading (talk) 09:55, 10 July 2014 (UTC)
It is related and has been fixed in gerrit:143604. I believe were just waiting for it to be caught up in another wmf branch release. I'll poke about though. John F. Lewis (talk) 10:01, 10 July 2014 (UTC)

Missing piece of wiki table syntax/markup?

Prompted by this.

In tables, wiki syntax/markup offers... 

| ... || ... || ... || (etc)

...as an alternative to... 

| ...
| ...
| ...
| (etc)

...but, so far as I'm aware, it doesn't offer something like... 

| ... || ... || ... -|
| ... || ... || ... -|
| ... || ... || ... -|
| (etc)

...as an alternative to... 

| ... || ... || ...
|-
| ... || ... || ...
|-
| ... || ... || ...
|-
| (etc)

What can work (at least, at present) is... 

| ... || ... || ... </tr>
| ... || ... || ... </tr>
| ... || ... || ... </tr>
| (etc)

...i.e. using the HTML "end table row" tag </tr>. I understand, however, that this is improper as it mixes wiki and HTML markup. So, may there be a wiki-style alternative, please? Sardanaphalus (talk) 17:13, 23 June 2014 (UTC)

The markup |- doesn't mean "end row", it means "begin row", that is, it's equivalent to <tr> not </tr> --Redrose64 (talk) 18:25, 23 June 2014 (UTC)
  • Yes. How about a piece of wiki markup that can be added to the end of a row to mark the end of that row? Sardanaphalus (talk) 00:07, 24 June 2014 (UTC)
It's not necessary to mark the end of a row if the start of the next row is indicated, or the end of the table has been reached. This is because, for any given table row, the <tr> tag (for which the wiki markup is |- at the start of a new line) is mandatory, but the </tr> tag (for which there is no wiki markup) is optional (it's always been optional in HTML, but not in XHTML, which has no optional tags). --Redrose64 (talk) 08:40, 24 June 2014 (UTC)
  • I'm considering this from user-to-syntax, so to speak, rather than vice versa. Because it can be useful visually, I – user – ("I, User"!) would like to be able to mark the end of a row (and so, if one follows, the beginning of the next row on the next line) on the same line as the code for that row, just as the syntax already allows for each cell in a row. So how about a piece of markup – syntax – that facilitates this (whether "-|" or something else)...? Sardanaphalus (talk) 21:11, 24 June 2014 (UTC)
It's not a good idea to introduced hacks like detailed in that post and the above posting. It adds very specific behavior that can very easily break because it depends on a slew of side effects of the parser. Long term we are getting rid of many of these side effects, so you are just creating tables that are very likely to break at some point in the future. Use either HTML syntax or wikicode, but don't mess with combinations of the two or using templates to generate something that can also (although a bit more verbose perhaps) be done without a template. It's just a bad idea. We all know that wikicode is ugly, it's ugly in a thousand different ways, but it's what we've got and what we have to live with. —TheDJ (talk • contribs) 19:10, 23 June 2014 (UTC)
  • This use of </tr> has been around long before my becoming aware of it – in fact, it's near-certain I came across it here. Mixing markup may be a bad idea, but, in the long-term, isn't the idea that something is "what we've got and what we have to live with" a worse one...? Sardanaphalus (talk) 00:07, 24 June 2014 (UTC)
Using </tr> without the next tag being either <tr> or </table> relies on browser quirks: assuming that we're not dealing with XHTML (see my post of 08:40, 24 June 2014 (UTC) above), most browsers, on encountering the sequence <table><th>, for which the wiki markup is 
{|
!
or <table><td>, for which the wiki markup is 
{|
|
will assume that there should be a <tr> (i.e. a |-) in between. Similarly, if they encounter the sequence </tr><th> or </tr><td>, they will also assume that there should be a <tr> in between. Since the <tr> tag at the start of a table row is documented as being mandatory, not all browsers will assume that it should be present if it has been omitted, and so you mustn't rely on such behaviour. --Redrose64 (talk) 08:40, 24 June 2014 (UTC)
  • That's what's motivating my request/proposal, especially as there's already provision for more than one cell per line of code. Sardanaphalus (talk) 21:11, 24 June 2014 (UTC)
  • I'll note that in the above instances, the parser will add the 'missing' <tr> automatically. So this is valid wiki markup resulting in valid HTML. -- [[User:Edokter]] {{talk}} 11:11, 27 June 2014 (UTC)
yes, relying on the HTML Tidy module as a hack is a very bad idea, especially since the core HTML Tidy it hasn't been updated since 1998. Frietjes (talk) 21:57, 23 June 2014 (UTC)
Since 2008 actually. -- [[User:Edokter]] {{talk}} 23:00, 23 June 2014 (UTC)
correct, thank you, the 1998 was a typo (still very old). Frietjes (talk) 23:56, 24 June 2014 (UTC)
So HTML Tidy is very very stable. Sounds like something one can rely on. All the best: Rich Farmbrough, 13:01, 4 July 2014 (UTC).
@Rich Farmbrough: I think stagnant would be a better way to describe it than stable, since stable also implies that it works well, which it doesn't. Look at all of the bugs that depend on the "Tidy sucks" bug. It really can't be relied on. Jackmcbarn (talk) 16:31, 5 July 2014 (UTC)
Fair enough. Regardless its functionality will need to be replaced or maintained, and the OP's request for a neater way to end table rows is well founded. Cries of "Well wiki-markup is horrible, so suffer!" do not evoke sympathy from me, just as I am not sympathetic to the "system" when major Mediawiki bugs go unresolved for years on end. All the best: Rich Farmbrough, 17:02, 5 July 2014 (UTC).
@Rich Farmbrough: The thing is, the OPs request is not just asking for row end markers, but the ability to omit row start markers. It has been the philosophy of HTML, right from the very start, that when an element has optional tags, it is almost always the end tag that is optional. The few elements that have optional start tags (HTML HEAD BODY COLGROUP TBODY) allow omission of those tags under very special circumstances; and for all five, the end tag is also optional - there are no elements with optional start tag and mandatory end tag. The start tag of the TR element - <tr> - is mandatory; its end tag - </tr> - is optional. There is no need to mark the end of the row, because a row end is implied - either by the start of the next row, or by the end of the table. Wiki markup was devised on the same lines: the row start marker is |- and that is mandatory; the table end marker |} is also mandatory. Since omission of either of those is not an option, there is no point in providing a </tr> equivalent. --Redrose64 (talk) 18:39, 5 July 2014 (UTC)
  • I don't feel I am asking to omit row-start markers. Instead, I think I'm asking for an alternative kind of row-start marker – say " -| " – that would make structures such as the following equivalent:
{|
| ... || ... || ... || (etc)
|-
| ... || ... || ... || (etc)
|-
| ... || ... || ... || (etc)
(etc)
|}

{|
| ... || ... || ... || (etc) -|
| ... || ... || ... || (etc) -|
| ... || ... || ... || (etc) [ -| ]*
(etc)
|}

* May/may not be necessary.
Sardanaphalus (talk) 23:56, 10 July 2014 (UTC)
Not at all. We parse the table syntax, therefore which XHTML tags we generate is up to us. Starting an implicit row at the obvious point would improve the robustness of table rendering. As you will no doubt be aware many many tables currently end with a surplus |-. All the best: Rich Farmbrough, 23:33, 5 July 2014 (UTC).

Any further thoughts / advice re Wikipedia:Village pump (technical)/Archive 128#Missing piece of wiki table syntax/markup?...? (Maybe I should enquire at mediawiki.org...?)
I imagine you might have quite a backlog – you seem to dispense advice and information everywhere! Very valuable. Hope you don't find it too exhausting.
Regards, Sardanaphalus (talk) 09:46, 27 June 2014 (UTC)

(end of moved text) Please don't split discussions across multiple pages, it makes them harder to follow.
  • Posted on your talkpage as the discussion here seemed to've petered out. Sorry if that was a mistake. Sardanaphalus (talk) 08:07, 30 June 2014 (UTC)
It's not possible to configure the English Wikipedia to accept MediaWiki-style markup additional to what MediaWiki provides itself. That would need a feature request at bugzilla:. But aside from that, it is bad HTML to use end-of-row markers without corresponding start-of-row markers; it is also bad practice to expect a browser to make assumptions about where missing markup should have been placed, unless the documentation (which for tables may be found at: HTML 3.0; HTML 3.2; HTML 4.01; HTML 5.0; HTML 5.1) explicitly shows it to be optional markup. For a table row, the <tr> tag has always been mandatory; the </tr> tag has always been optional, except in XHTML 1.0 where it is mandatory (because there are no optional tags in XHTML). --Redrose64 (talk) 10:04, 27 June 2014 (UTC)
  • I can understand that it's bad HTML to use these markers without those markers and to rely on browsers and/or things like HTML Tidy to perfect syntax, but my request/proposal is for some wiki syntax to mark the end of a row (and possible beginning of a subsequent row) on the same line as the wiki syntax used to define that row. Sardanaphalus (talk) 08:07, 30 June 2014 (UTC)
HTML Tidy is disabled by default in MediaWiki,[7] thus pages using this hack will break when ported to a wiki with the defaults. Tidy is required to mix wiki table and html table markup. --  Gadget850 talk 11:01, 27 June 2014 (UTC)
I have had my head in Sanitizer.php recently. It looks like it is Sanitizer that closes these tags, not HTML Tidy.  Gadget850 talk 00:04, 11 July 2014 (UTC)

Maybe Gwicke (which is working in the mw:Parsoid) may provide some comments on this topic? Helder.wiki 00:34, 11 July 2014 (UTC)

Image full-screen popup

Instead of getting the image page, i get a metroized full-screen popup. You seem to detect my browser (IE11) wrongly and serve me the mobile version. My user agent is: 

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

� (talk) 08:53, 6 July 2014 (UTC)

This is the WMF's wonderful new Media Viewer that they foisted, without notice or asking permission, on absolutely everybody who conceivably could have their editing productivity obliterated by some stupid new gadget designed to turn Wikipedia into a clone of every other social media platform. Go to Special:Preferences#mw-prefsection-rendering under Files you will see the check box to disable this monstrosity. And if you really like the Media Viewer as much as everyone else seems to, you can show your support at Wikipedia:Media Viewer/June 2014 RfC. VanIsaacWScont 09:25, 6 July 2014 (UTC)
Vanisaac: "Without notice" is a lie and frustration not a valid reason for wrong statements. Don't blame others for you not reading. See here, here, here, here and here. --Malyacko (talk) 11:29, 6 July 2014 (UTC)
And flashing four paragraphs of 4 point text for a half second at the end of a TV commercial technically constitutes disclosure. But in no universe except the purgatory of legalese is it remotely sufficient, and likewise no one but the WMF would think that a couple threads at a single noticeboard constitutes anything remotely approaching sufficient warning about a drastic change to fundamental site navigation. Oh, and please show an inkling of class and remove your WP:NPA. VanIsaacWScont 12:46, 6 July 2014 (UTC)
You can disable this nonsense by going to your preferences for appearance. In the Files section, uncheck the Media Viewer. In related news, I think that any such gadgets should always be opt-in instead of opt-out. De728631 (talk) 12:59, 6 July 2014 (UTC)
Brilliant. Glad you can turn that shit off. Nice one. Lugnuts Dick Laurent is dead 19:29, 6 July 2014 (UTC)
My opinion of this 'improvement' changed totally when I discovered how easy it was to turn it off. A button to the bottom left of any infected screen. It is absolutely brilliant.-- Clem Rutter (talk) 23:02, 6 July 2014 (UTC)

Allow Current year and similar switches in redirects

Tracked in Phabricator
Task T63791

Is it possible to allow {{CURRENTYEAR}} and similar parser functions to be included in redirect targets?

For example:
#REDIRECT [[Deaths in {{#time:Y}}]]
produces "1. REDIRECT Deaths in 2014", with the one exactly as you see it, create a link, but it does not redirect.

Also:
#REDIRECT [[Wikipedia:Redirects for discussion/Log/{{CURRENTYEAR}} {{CURRENTMONTHNAME}} {{CURRENTDAY}}]]
does not redirect to todays RfD page but simply prints the text.

Has a bug report been opened on this already? Ego White Tray (talk) 05:05, 8 July 2014 (UTC)

  • Ego White Tray, I believe T63791 is what you're looking for... — {{U|Technical 13}} (e • t • c) 02:17, 9 July 2014 (UTC)
    • Which has been marked as duplicate of 1575. 1575, on the other hand, is marked closed won't fix. Considering this ticket has been opened ten times without any reason provided, it's time to overturn wontfix on this. Ego White Tray (talk) 04:12, 9 July 2014 (UTC)
Then reopen 1575. Jackmcbarn (talk) 04:22, 9 July 2014 (UTC)
  • I've reopened 61761 which is the exact opposite of 1575. 1575 says that "Redirection should not occur", 61791 says that "redirection should most certainly occur". Seems like as clear cut a difference as there can be. Brion has also been on the notify list for 61791 for five months now and since he is the one that wontfixed 1575 it is up to him to decide if he wontfix 61791 either. — {{U|Technical 13}} (e • t • c) 10:37, 9 July 2014 (UTC)
No, it isn't. It's not very well worded that 1575 is asking for that behaviour to change, but the usage scenario 1575 is trying to do is exactly what you are talking about. They are duplicates. VanIsaacWScont 10:55, 9 July 2014 (UTC)
I frankly don't care what's a duplicate of what. This has been reopened 10 times, and the only reason ever given for not fixing is essentially "it doesn't work that way". I say unresolve 61791 and explicitly say it won't be closed as a duplicate until someone provides a good reason not to fix it. Ego White Tray (talk) 14:36, 9 July 2014 (UTC)
Bugzilla has its own etiquette, and repeatedly re-opening WONTFIXed bugs is something that can get you banned there. Usually, WONTFIX means that even if a volunteer writes a patch up, that the devs responsible for that extension will absolutely refuse to implement it. It's a bit of an "over my dead body" statement, although things do change sometimes (for example, if it's WONTFIXed because of server resources, and the server gets bigger and faster, then it's reasonable to reconsider). If they don't absolutely oppose it, but aren't willing to work on it themselves, then it usually gets marked with a low priority and left open for any volunteer dev who is interested.
Probably the best thing to do is to send e-mail either to Brion (as the person who WONTFIXed the other) or to one of the WP:Mailing lists to explain what you want and to ask what other people's concerns are. Wikitech-l is probably the best choice for this. Whatamidoing (WMF) (talk) 20:14, 10 July 2014 (UTC)

New hover display

Very recently, most links and pics started showing a mouseover hoverbox in Firefox, when they did not before. I have no problem with this, the problem I have is with the huge, unwieldy, yellow box around the text. I'm reasonably sure this is something defined in Wikipedia, as it doesn't happen with most other sites, and I haven't updated or changed Firefox recently. Does anyone know of a way to reduce the box display size to something...smaller??

 
A screenshot of wikipedia alt-text display on Firefox

 The Steve  00:50, 9 July 2014 (UTC)

Update - I managed to fix it using the Popup Alt Attribute Extension for Firefox, which displays Alt text in a (thankfully) tiny box.  The Steve  01:06, 9 July 2014 (UTC)
Using Firefox 30 here, I don't get that huge, unwieldy, yellow box but a small grey one on the same link that you posted as a screenshot, so I think that this depends on either browser or operating system settings... --AKlapper (WMF) (talk) 07:51, 9 July 2014 (UTC)
I think it was a glitch, but a weird one, because it only happened on a couple of websites. Most websites had a normal-sized popup box. Also, the whole mouseover thing on links is brand new (to me) on wikipedia.  The Steve  03:59, 10 July 2014 (UTC)
I wonder if you're seeing mw:Hovercards. Whatamidoing (WMF) (talk) 20:41, 10 July 2014 (UTC)

Coordinates passed to Google Maps app not resolving

On my iPad, when I click on a location's coordinates such as in the infobox on Musée des Beaux-Arts de Tours, and then the Google Maps link in GeoHack's "View this location..." part, it takes me to the right location in the browser-based version of Google Maps. So far, so good. However, in the browser version of Google Maps, when I then click on the link to the Google Maps app, it can't seem to handle the prefix "loc: ". I'm sure it used to work. Is this a problem with Google Maps, or with GeoHack, or something else?--A bit iffy (talk) 11:42, 9 July 2014 (UTC)

Ehm, it simply links to http. I'm not sure what would cause it to point to a loc: link for you. Did you perhaps install some browser extension or something ? —TheDJ (talk • contribs) 10:14, 10 July 2014 (UTC)
No, I haven't installed any extensions.--A bit iffy (talk) 14:00, 10 July 2014 (UTC)
  Resolved
It's now working OK — the "loc: " prefix is no longer being passed to the app, only the coordinates. Consider this closed.--A bit iffy (talk) 17:41, 11 July 2014 (UTC)

Is there a way to add items to the CharInsert gadget?

Does anyone know if it's possible to add items to existing groups in the CharInsert toolbar, or even add new groups? I would assume that there might be hooks allowing users to add something to their common.js or common.css. Any pointers or examples would be appreciated.- MrX 18:49, 10 July 2014 (UTC)

your link is to the wrong place. the tool you mean is MediaWiki:Gadget-charinsert-core.js. if you read the code, it supports "charinsertCustom", which, presumably, is something you can place in your common.js. i am positive it worked in the past, but not sure if it still works. also, i did not find documentation. there are some explanations in the archives of this page. peace - קיפודנחש (aka kipod) (talk) 19:37, 10 July 2014 (UTC)
Thank for your help קיפודנחש. I will give that a try.- MrX 20:01, 10 July 2014 (UTC)
Your suggestion worked. Thank again. Do you (or anyone) know how to insert a new line in the symbol list such that it would be inserted into the editor box? \n line feeds the symbols on the toolbar, and &#13 doesn't seem to work.- MrX 21:16, 10 July 2014 (UTC)
I don't think that will work, but you could try \\n. -- [[User:Edokter]] {{talk}} 09:36, 11 July 2014 (UTC)
That worked perfectly! Many thanks Edokter.- MrX 11:42, 11 July 2014 (UTC)

Authority control template not showing in mobile

Please can someone assist with the styling issue described here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:02, 10 July 2014 (UTC)

References in Heisenbug

There is something weird going on with the references on the Heisenbug page. I think they're supposed to display in multiple columns, but I'm using Firefox and they display in just one single narrow column with a huge swath of blank space on the right. 78.0.236.159 (talk) 00:53, 11 July 2014 (UTC)

I'm using Firefox 30 on Windows 7, and I see two columns. What are you using? I'm not used to seeing {{quote box}} within the references section - that may be causing the issue. GoingBatty (talk) 02:40, 11 July 2014 (UTC)
Positive. Those quotes are better served as article text. -- [[User:Edokter]] {{talk}} 09:41, 11 July 2014 (UTC)
From a quick glance: get the two {{Quote box}} out of ref 17; lose the two {{-}} which are also in ref. 17; make the refs consistent - either use Citation Style 1 templates for all, or templates for none; fix the {{DEFAULTSORT:}}. --Redrose64 (talk) 10:05, 11 July 2014 (UTC)

Database lag?

A few minutes ago my watchlist said that changes newer than 45 seconds may not appear due to database lag. Is this normal or is it something to be concerned about? Retartist (talk) 01:44, 11 July 2014 (UTC)

EDIT: it has disappeared Retartist (talk) 01:46, 11 July 2014 (UTC)
It means that the slave sql servers are behind in replicating and that we are getting old data. It happens when the databases are over stressed by writes and reads. It will catch up on its own. Chillum 01:47, 11 July 2014 (UTC)

Thanks Retartist (talk) 01:55, 11 July 2014 (UTC)

I don't usually worry about this until it's up to around a thousand seconds or so (~15 minutes' delay). WhatamIdoing (talk) 18:29, 11 July 2014 (UTC)

Dashboard glitch

Me again, It seems that The dashboard is broken for me. See:webpagescreenshot. Using Chrome Version 35.0.1916.153 m, Win 8.1 on surface pro 2. Retartist (talk) 02:01, 11 July 2014 (UTC)

What is "the dashboard" and where to find it? What does "broken" mean? --AKlapper (WMF) (talk) 08:56, 11 July 2014 (UTC)
See Wikipedia:Dashboard. It is a bot-generated list of active topics. -- [[User:Edokter]] {{talk}} 09:55, 11 July 2014 (UTC)
Should be fixed now. "!!!" was mistaken for wikitable markup. -- [[User:Edokter]] {{talk}} 09:52, 11 July 2014 (UTC)
@Edokter: The problem with amending bot-updated pages is that on the bot's next run, it will put the page back to what it thinks is correct. You need to find the root cause, and fix that. The bot then updates the dashboard to suit. --Redrose64 (talk) 13:58, 11 July 2014 (UTC)

Create protection

This is purely a technical question and has nothing to do with the merits of my action or subsequent actions by another administrator.

I deleted Jet Naked Airlines. I salted it after deleting it. Although I can find a record in my log of my action, it appears that it is no longer salted. Did the temporary restore by an administrator automatically unsalt it? Although I can't seem to find the page protect log for the article, if I click on protect page, it shows at the bottom that I salted it and it doesn't show that it was unprotected. At this point I'm not sure whether it is or isn't still protected. I looked at this list, but I don't see any way to search the list for a particular title (I don't even understand how the list is organized or how often it's updated). Thanks for any help.--Bbb23 (talk) 11:40, 11 July 2014 (UTC)

A delete/undelete (or vice versa) resets all prot settings to unprot. I've seen this happen twice with histmerges, one (if not both) performed by Graham87 --Redrose64 (talk) 11:54, 11 July 2014 (UTC)
Yes, as Redrose says, it's currently unprotected. I find it an irritating bug. Check out the log history of Test page which is regularly recreated by admins and then has to be re-salted. Jenks24 (talk) 12:10, 11 July 2014 (UTC)
I see the history of deletes and undeletes, but how do I see the protection history? If this just happens under the covers, so to speak, then that's annoying.--Bbb23 (talk) 12:21, 11 July 2014 (UTC)
Thru Special:Log/protect. There's also a T27023 about adding protection log to moveddeleted-notice. --Glaisher (talk) 12:26, 11 July 2014 (UTC)
The first link shows what I already knew, that I protected it. I'm afraid I can't follow the bug report. Much of it is written in an English I don't speak. What does it say? :-) --Bbb23 (talk) 12:33, 11 July 2014 (UTC)
The bug report isn't so important - that's just discussing how the two different logs should be shown to users. The basic point is that deletion and protection are covered in separate logs, and that deletion trumps protection. Just looking at the protection log alone won't tell you the current protection status of a page, as if it was deleted or undeleted in between the time the log was made and the time you look at it, the page will be unprotected. — Mr. Stradivarius ♪ talk ♪ 12:52, 11 July 2014 (UTC)

No more "wg..." globals in JavaScript

See also: meta:User:Krinkle/Le Tour de Wikí/2011 Resource Walker

Hi!

I would like to ask any user which have personal scripts to check if they continue to work on https://test2.wikipedia.org (now that gerrit:139569 is merged). If not, please report any issues you find (or fix them!), so that these scripts continue to work smoothly even after we fix bugzilla:33837 (at some point in the [near] future). If you can also test gadgets in that wiki, even better.   Helder.wiki 23:38, 7 July 2014 (UTC)

  • Helder thank you for the notice. Apparently this is something that the developers have been changing behind our backs since 1.17. I don't care why it is being done, what I'm wondering is what the rational is to wait until the last minute to tell us about it knowing damn well there is no way our handful of editors that can read scripts that rely on this will be able to get them all fixed before they are broken by a core change. I've noted this on the Bugzilla ticket as well. Can you point us to, or create, a replacement table for what we should be using instead of these variables? For example, "wgPageName" is now "mwPageName" or whatever it is? Thanks. — {{U|Technical 13}} (e • t • c) 00:00, 8 July 2014 (UTC)
I've been using wikibooks:pt:User:Helder.wiki/Tools/jsUpdater.js since MW 1.17 to do this and a few other updates.
In the case of the wg*** globals, the regex looks like this:
  • /([^'"<>$0-9A-Za-z_\/])(skin|stylepath|wgUrlProtocols|wgArticlePath|...)\b/g
  • $1mw.config.get('$2')
(it may need some update to include variables included recently). Helder.wiki 00:07, 8 July 2014 (UTC)
@Helder.wiki: Are you stating that scripts such as the Reflinks script will need to be tweaked? I have several scripts like that. Could you please use the Reflinks script as an example to show us what the new script should look like? Thanks! GoingBatty (talk) 01:32, 8 July 2014 (UTC)
@GoingBatty: Something like this and this should work. Helder.wiki 02:37, 8 July 2014 (UTC)
@Helder.wiki: That works great - thanks! GoingBatty (talk) 01:48, 9 July 2014 (UTC)

We need documentation of this change, in human-readable prose, please. Right now, I can't tell whether my .js scripts need to be changed based on the esoteric discussion here and on the bugzilla page.

As a concrete example, does Wikipedia:AutoEd/core.js need to be changed? It appears to use "wg" variables, but I can't tell from the bugzilla discussion whether they qualify. If they do, AutoEd code will need to be changed. Many people use this tool, I believe. – Jonesey95 (talk) 05:25, 8 July 2014 (UTC)

From reading the discussion at the bug, the most important fact is this: This is not an emergency. They're not removing these right now (or even next week). Whatamidoing (WMF) (talk) 06:14, 8 July 2014 (UTC)
  • Okay, like I said, I also brought my concerns up on the Bugzilla ticket and Krinkle clarified it for me. The variable names aren't changing or going away, we just need to access them through mw.config.get(). He also assured me that there is no rush on this like I had initially thought based on my interpretation of this post. I will be digging through all of the documentation, then gadgets, then userscripts I can find and requesting edit changes as is appropriate for each one I come across. So, if you can not figure out for yourself if there is a change that needs to be addressed, rest assured that I will be through before these variables are no longer available to make a suggestion for how you can fix it. I will post the request on the talk page for the script, pinging the author(s) of the script and leaving a TB where appropriate on their talk page. If there is no response in about seven to ten days I will prefix the request with a {{Edit protected}} template and get an administrator to make the necessary changes. Thank you. — {{U|Technical 13}} (e • t • c) 11:52, 8 July 2014 (UTC)
Thanks for your help with this. There are scripts that I depend on, and I really appreciate you sorting through other people's scripts. Could you take a quick look at User:PleaseStand/userinfo.js, and tell me if I'm correct that it's already fixed? Thanks, Whatamidoing (WMF) (talk) 17:15, 8 July 2014 (UTC)
  • Whatamidoing, all of the wgVariables seem to be properly called via mw.config.get('wgVariables') and that script should be fine. — {{U|Technical 13}} (e • t • c) 17:30, 8 July 2014 (UTC)
@Jonesey95 and Drilnoth: This change should fix the usage of global variables as well as one deprecated method (addPortletLink). Helder.wiki 14:36, 8 July 2014 (UTC)
What? Who? Oh, right, I helped out with that script in the distant past. :P Thanks for keeping it working. Now lemme just return to my wiki-slumber. Hopefully someday I'll be able to make a more full return. –Drilnoth (T/C) 00:50, 9 July 2014 (UTC)

MediaWiki:Gadget-ProveIt.js uses global variables. -- WOSlinker (talk) 22:34, 8 July 2014 (UTC)

@WOSlinker and Superm401: This change should fix it (and there are a few other changes Krinkle did to the script which were lost in this update). Helder.wiki 01:32, 9 July 2014 (UTC)
@Helder.wiki: First, to be clear, there are no plans for the near future to turn off legacy globals on English Wikipedia (it will probably happen, but not in the near future). See bugzilla:33837#c10 (Krinkle said, "They're also cheap to maintain compatibility for. I wouldn't prioritise pushing for the removal of these in the current MediaWiki release cycle."). I have not heard anything conflicting with that elsewhere.
Now, putting my ProveIt hat back on, given the concern (and that the fix is straightforward), I'll prioritize this fix. I'm also am going to reapply Krinkle's change in git.
To submit fixes to ProveIt, please use pull requests. I keep the versioning in git (hosted in GitHub), since MediaWiki revision history is not ideal for software (in fact, pull requests are one good example of the better workflow it allows vs. just copying text around between sandbox pages). In this case, I'll take care of the wg/legacy change (possibly as part of another change) (so no need to do a pull request for that). However, for future changes, it's pretty easy to submit a pull request. After signing in to GitHub (accounts are free), you can make simple changes by simply editing and saving this page. It will do the git work required behind the scenes for you, then I'll be able to review the change. (There are other ways to do git changes, but that is fine for simple things). Superm401 - Talk 02:34, 9 July 2014 (UTC)

I submitted a few edit requests for scripts in the MediaWiki namespace. Helder.wiki 23:50, 11 July 2014 (UTC)

Requiring/checking Sort criteria on "List of" articles in "Lists of" category.

(Help Desk Suggestion to ask here) As far as I can tell, in any case where there is a "Lists of" category like Category:Lists of people by city in the United States that all articles in that category should have sort criteria for the entry in that category. So that List_of_people_from_Hillsboro,_Oregon would have [[Category:Lists of people by city in the United States|Hillsboro, Oregon]] rather than [[Category:Lists of people by city in the United States]]. (Rarely would this be done with a default sort) Would there be a tool that would help with making sure that this is true? For example, would this be appropriate for Wikipedia:WikiProject Check Wikipedia?Naraht (talk) 21:55, 11 July 2014 (UTC)

Adding a sort key like that is possible using a regex find/replace in AWB. You could post a request at WP:AWB/Tasks. Figuring out which articles don't have a sort key is easy, since all such articles are sorted under "List" on the category page. SiBr4 (talk) 23:05, 11 July 2014 (UTC)

Template transclusion question

Does anyone know why AJ Leitch-Smith is reporting a template transclusion error on Template:Yeovil Town F.C. squad using this tool here? Thanks, JMHamo (talk) 22:31, 11 July 2014 (UTC)

  • If I had to guess, I might think it is because that tool is on toolserver which doesn't have current data. Try getting the tool ported to toollabs and see if that helps. — {{U|Technical 13}} (e • t • c) 22:40, 11 July 2014 (UTC)
  • The strange thing is it works fine with every other template entry, just took a disliking to this one particular entry... JMHamo (talk) 22:45, 11 July 2014 (UTC)

New "insource" search not working (for me)

I am unable to use the new "insource" search feature described at this mediawiki page to search using regular expressions. This feature was supposed to be enabled in CirrusSearch, the new beta search feature, on June 26.

I have enabled the new search in my Beta Preferences. I try to search for the example on the page linked above — insource:/foo/ — but I get only a red error message: "An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later."

It has not been a temporary problem, at least for me. I have gotten this same error message when trying to search for any regular expression using the syntax above. I have tried this search a few times a day for the past four days. I have gotten this error message every time.

Is it working for anyone? What is the trick to making it work? – Jonesey95 (talk) 04:32, 2 July 2014 (UTC)

@NEverett (WMF): ? — This, that and the other (talk) 05:52, 2 July 2014 (UTC)
See mailarchive:wikitech-ambassadors/2014-June/000768.html & bugzilla:43652#c13. --Glaisher (talk) 05:53, 2 July 2014 (UTC)
Thanks for the links. I had seen the first one via the helpful Tech News update that has been posted to this page. The mailing list note says that "the article source will take some time to roll into the index after the deployment." I wonder if "some time" means a few days or a few months. Recategorizing articles when templates are changed is taking about 90 days currently.
The bugzilla report said that Wikipedias were about 10% indexed at some point on June 27, but there is no subsequent update to let us know the pace of the reindexing. And of course, being the hegemonic sort that I am, I care only about the English-language WP, so I really want to know the reindexing timeline for en.WP, not the average of all WPs.
The bugzilla report also says that Special:Search/insource:/a/ is working, but I get the same red error message when I try it. – Jonesey95 (talk) 14:48, 2 July 2014 (UTC)
Sorry about that! Yeah, enwiki isn't fully indexed with source yet - it'll be a few more days before its done. I just tried it and it worked for me but I get that this doesn't mean it works for everyone all the time. I've opened bugzilla:67418 issues like this. So far it has three points: error message when a query times out, raise the timeout for regexes, and making sure that the regex is executed last. When we first implemented this we spent so long making sure syntax errors were somewhat readable that we neglected those other points. Syntax errors are pretty ok though: Special:Search/insource:/a/.NEverett (WMF) (talk) 15:33, 2 July 2014 (UTC)
Let me revise that "few days" because I can be more accurate. enwiki is 39% done reindexing right now. Rough math puts that completing around July 11th. Unlike the old search index a full reindex is slow and competes with other stuff running on the job queue. Its one of my least favorite parts of the whole thing. It creates a much higher fidelity search index but at a pretty steep cost. On the other hand if MediaWiki gets faster then so does this so at least we're in an "a rising tide lifts all boats" kind of situation.NEverett (WMF) (talk) 15:48, 2 July 2014 (UTC)
NEverett (WMF), do you have an update on this reindexing? It is now July 12, and I am still getting the same error. Thanks. – Jonesey95 (talk) 02:39, 12 July 2014 (UTC)

Recategorizing articles when templates are changed is taking about 90 days currently

Another point: "Recategorizing articles when templates are changed is taking about 90 days currently." Wow! You mean, like, if a template that contains a category changes then pages that have the category take months to get reindexed by Cirrus? That's horrible. I knew it was slow and I've always wanted to add monitoring to it but its never floated to the top of the list. I've bumped it up bugzilla:67419. NEverett (WMF) (talk) 15:42, 2 July 2014 (UTC)

NEverett (WMF), I have moved this to its own subsection. I will give a concrete example so that we are both talking about the same thing. The Citation/CS1 Lua module, which is the foundation for heavily-used citation templates like {{cite web}} and {{cite journal}}, was updated on 30 March. The changes included the creation of a new citation error category, Category:CS1 errors: authorlink‎. Between 30 March and 28 June, a few hundred articles trickled into that category as articles were processed (by a back-end null edit or something; the job queue?). I fixed them every day or two as they popped up in the category. The most recent one to appear was corrected on 28 June, shortly after it appeared in the category. As you can see in the date of the previous edit before my edit, some sort of reindexing or job queue put the article in the category, not an erroneous edit by an editor.
There were other new categories and error types created in this revision. They behaved in the same way, with a large chunk of articles popping into the category in the first week or so, then a continual trickle for months.
As recently as six months ago, these changes propagated in less than 60 days, which is still ridiculously long, but now it's 50% longer. Anything you can do to make that propagation faster will be appreciated. Thanks! – Jonesey95 (talk) 16:56, 2 July 2014 (UTC)
Something happened to the job queue about a year ago. Until then, a template change would pretty much always be fully processed within twelve hours, and was often finished in less than two. Since then, it takes days - even weeks - and sometimes appears that some job queue tasks never get fully completed. There are several link tables which should be updated together; sometimes one of these is updated but not the others. Consider the category mentioned above: it might be that viewing an article shows the category at the bottom, but upon going to the cat page, the article is not listed (let's call this case "A"). It might be the other way around: you view a cat page, click on an article, and find that the cat is not shown at the bottom of the article (case "B"). A WP:NULLEDIT to the category does nothing useful; a NULLEDIT to the article fixes things up - for that one specific article. For case "B" you can go through the whole cat, article by article, and NULLEDIT; but for case "A", although a NULLEDIT will also fix that one article, I know of no way of locating the other articles that need the same treatment. Another situation concerns "what links here". The template might have links to other pages - this is common practice with navboxes - and if an article link is added to or removed from the navbox, a "what links here" for that article may give a false picture for a very long time. Something similar happens when templates transclude other templates - the deeper a template is in the transclusion tree, the less likely it is that a "what links here" for the template will show the transclusions accurately. --Redrose64 (talk) 18:54, 2 July 2014 (UTC)
Fwiw... sometimes you can force a complete refresh of a particular category as described above - especially when a template is doing the categorization - through an API call...
... where &titles= is the key template, page or cat primarily handling some element or status that has become "other than reflecting the current state" (e.g. out-of-date). Sometimes more than one target needs to be hit in order for a cascade-effect refresh to occur. Hope that helps. -- George Orwell III (talk) 02:07, 5 July 2014 (UTC)
This link does not appear to do anything for me. In Firefox, I get a Mediawiki message that says "You are looking at the HTML representation of the XML format. HTML is good for debugging, but is unsuitable for application use. Specify the format parameter to change the output format. To see the non HTML representation of the XML format, set format=xml. See the complete documentation, or API help for more information." In Safari, I get a very long API documentation page, starting with "error code="mustbeposted" info="The purge module requires a POST request" xml:space="preserve"".
For what it's worth, a new article popped into the CS1 authorlink category today, 101 days after the last CS1 module update. I fixed it with this edit. – Jonesey95 (talk) 06:04, 10 July 2014 (UTC)
It was not intended as a browser link. A link like above is interpreted by your browser as a GET request. This URL requires POST. —TheDJ (talk • contribs) 08:52, 12 July 2014 (UTC)
@George Orwell III and TheDJ: If it was not intended as a browser link, why was it given as a clickable browser link above? What other method is suitable for using a URL like that? Or, for those not so technical, how *should* a browser URL be formatted in order to produce the same effect as this "forcerecursivelinkupdate" function? --Redrose64 (talk) 19:35, 12 July 2014 (UTC)
Not sure what the issue is - I can click the previously given URL and produce an output showing the completed request
<?xml version="1.0"?>
<api>
  <purge>
    <page ns="10" title="Template:Cite web" purged="" linkupdate="" />
  </purge>
  <normalized>
    <n from="Template:Cite_web" to="Template:Cite web" />
  </normalized>
</api>
.... the purged="" linkupdate="" reflecting both the purge & the forced recursivelinkupdate took place. Please note - as with most if not all API commands you must use SSL (i.e. https:// ), otherwise you'll get the GET/POST clap-trap (I just assumed everybody logged in nowadays uses the secure server - my bad).

The thing about narrowing down the actual target in short equates to URLs using encoding or titles using lowercase like...

.... both of which are alternatives of the same string.

The final note I've just discovered - this command works best when the target has no protection. If a target title is protected, a null edit is needed to get the re-cache ball rolling regardless of the API command being applied or not (perfect example, Template:! was just made redundant because {{!}} is now a formal magic word. I can refresh it with the API a hundred times but because it is protected, 'what links here' remains frozen until its unprotected or null-edited). -- George Orwell III (talk) 21:59, 12 July 2014 (UTC)

MW extension "Manage template documentation" now affecting every template

As of very recently, when you edit any template at the top there's a link provided to "Manage template documentation". This appears to have been made as a MedaWiki extension for the visual editor's "TemplateData" (see Wikipedia:VisualEditor/Updates/21 May 2014), and someone has enabled that MW extension here without any announcement I can find. I was wondering if this was error; whether it was supposed to be just enabled for VE – certainly it's not clear what this is useful for, in general, sitewide, and not segregated to only appear for VE. It also is confusing in that I immediately thought, before exploring what it was (and I bet others would assume so too), that it was related to template documentation which it's not. This was noted at T65389 (where the creator of the extension basically said "nothing to be done about that").--Fuhghettaboutit (talk) 02:50, 6 July 2014 (UTC)

This looks like a useful tool that should be enabled here, but a couple of changes need to be made:
  1. Now it works on template pages themselves, rather than just documentation pages. This means that editors are quite likely to add it to templates by mistake, and transclude TemplateData in the template results. This needs to be fixed ASAP to prevent accidental damage by less experienced editors.
  2. The button needs to be changed to read "Manage TemplateData" instead of "Manage template documentation" to make it clearer what is being edited.
Maybe there are some MediaWiki messages that we can edit to make this work? If anyone knows where they are located, please leave a note here. :) — Mr. Stradivarius ♪ talk ♪ 12:26, 6 July 2014 (UTC)
As for not being useful for editors that don't use VE - that's not the target audience here. This tool is for template coders, rather than template users, and template coders should be in the habit of adding TemplateData to their documentation so that users who choose to use VE can use their templates easily. Anything that makes it easier to add TemplateData has to be a plus - myself, I have been using fr:Utilisateur:Ltrlg/scripts/TemplateDataEditor.js which does pretty much the same thing. — Mr. Stradivarius ♪ talk ♪ 12:33, 6 July 2014 (UTC)
I've just found the message responsible for the button text - MediaWiki:Templatedata-editbutton - and changed it to "Manage TemplateData". If anyone has other suggestions for what it should say, I'm all ears. — Mr. Stradivarius ♪ talk ♪ 12:42, 6 July 2014 (UTC)
I changed MediaWiki:Templatedata-modal-title from "Template documentation editor" to "TemplateData editor" as well. (That's the title of the window that pops up after you click the "Manage TemplateData" button.) However, it doesn't seem to be changing the actual title of the window. — Mr. Stradivarius ♪ talk ♪ 13:00, 6 July 2014 (UTC)
The change to the button text looks like a significant improvement. Even as someone who has written code to use TemplateData information, I found the "Manage template documentation" to be confusing and almost just ignored the new button. The change to the window title will be good also. ::::I also strongly agree that it should only be placing this information on the /doc page, not the template page, or at least be set up to use the /doc page by default. While there are some templates which have their documentation on the template page itself, the tools should, by default, put the TemplateData on the /doc page. It is fine that the button is enabled on the template page, but any TemplateData should be stored in the /doc unless the user specifically selects to do other otherwise (checkbox?).
Aside: Why do people title things like this with grandiose ideas about the functionality provided. It is clear and obvious that it is not actually managing the template documentation, just a subset of the information contained in the documentation. The TemplateData, while desireable, is currently just a bit of data that makes it easier to use functionality, VE, which is in use by a very small subset of the Wikipedia population. While it is very desireable for template coders to be able to explicitly specify this information, from the descriptions of the VE template functionality which I have seen, the TemplateData appears to be primarily used to make up for the lack of VE having any capability to automatically determine the parameters used by a template. Sorry, that is a bit of frustration at multiple issues talking there. Having the TemplateData is good and desirable. While still lacking in functionality, it allows template coders to explicitly specify at least some of what is necessary from the parameters to a template/module. — Makyen (talk) 13:21, 6 July 2014 (UTC)
I've never clicked that Template data editor button. Why not? Because it has no help text next to it to tell me what it does, nor a link to an explanatory page; and when I hover over it, Firefox 30 doesn't tell me where I'll be sent if I click it. Normal links, when hovered, show the link destination in the bottom left corner of the screen (bottom right if the link would be obscured by that action). I'm not some kid who clicks buttons "to see what they do". I clear up enough crap every day. I don't want to have to start fixing broken templates too. --Redrose64 (talk) 13:54, 6 July 2014 (UTC)
The tool was enabled here by request from someone who wanted to use it. Given the brittle JSON code in TemplateData, I think it is far better than trying to do it by hand.
If it's set up to add TemplateData to a /doc page, and the /doc page doesn't exist and/or isn't transcluded onto the template page, then will that screw up the existing in-template documentation? What happens if you have documnetation split between the template page and the subpage? Whatamidoing (WMF) (talk) 23:49, 6 July 2014 (UTC)
Good points. Maybe rather than hiding the button on template pages, we could get the tool to wrap the <tempatedata>...</tempatedata> tags in <noinclude>...</noinclude> tags, and ensure that there is no extra whitespace between the end of the template and the start of the TemplateData. A little ugly, but at least we would have our TemplateData without altering the template output. One possible pitfall for this approach: some templates have an opening <noinclude> tag before the documentation, but no corresponding </noinclude> tag at the end. — Mr. Stradivarius ♪ talk ♪ 11:51, 7 July 2014 (UTC)

Can someone remove that annoying Manage TemplateData button? It's an eyesore and really not helpful. Have it as an opt-in preference for someone who may require it. Jared Preston (talk) 22:40, 8 July 2014 (UTC)

If you really want to hide it you can add

 button.tdg-editscreen-main-button {
   display: none;
 }

to you Special:MyPage/skin.css.--Salix alba (talk): 02:27, 9 July 2014 (UTC)
@Salix alba: Thanks, it worked! Jared Preston (talk) 09:27, 9 July 2014 (UTC)


On a related point, I asked about transcluding TemplateData, and it appears that TemplateData can be stored in whatever page you want and transcluded, but it only accepts one TemplateData block per template. (Like parameters in infoboxes, if you have multiples, the only one (the last?) gets used.) So if you put some in the doc subpage and some in the template page, you'll only see half of it.

I don't know if it would work if the TemplateData were wrapped in noinclude tags. (Probably yes?) That will be my next question. Whatamidoing (WMF) (talk) 19:42, 7 July 2014 (UTC)

As to the issue of having the script put the TemplateData in the /doc or the template page when clicked from the template page: It is a script, it can have a reasonable amount of logic. It should have the small amount of logic to figure out if the TemplateData should go on the Template page or the /doc page under almost all circumstances. Determining if there is documentation data already existing on the template page should be relatively easy. If it does not exist there then it should put it in the /doc page, using the normal starting text with a section at/near the bottom titled "TemplateData", and appropriately append the {{documentation}} template to the template inside <noinclude>...</noinclude>, if it does not already exist. Oh, and if it can't figure it out: ask the user that is making the edit. Of course, the user making the edit should be permitted (e.g. a checkbox) to override the location selected by the script. These should be a normal part of implementing this type of feature. There is a normal/preferred method of doing things, but it is the script's responsibility to determine the method that is already in use, if there is one, and not change the method that is in use without explicit instructions to do so by the user after it has informed the user that this is a change from the current method of documentation.
As to transcluding: yes, there can be only one TemplateData block. That does not mean that you can not use multiple templates to build the TemplateData block of JSON. For example, it is fairly simple to have a template that contains the pre-parameter JSON, a template that contains parameters A-J, then another that contains parameters K-S, yet another that contains parameters T-Z, and a final one that contains the post-parameter JSON. Doing such is reasonable and expected in situations where there are a group of templates with similar, but not identical, parameters. An example of this would be the CS1 citation templates which already use modular (template-ized)documentation. — Makyen (talk) 00:25, 8 July 2014 (UTC)
See also bugzilla:54140 (Store TemplateData in its own namespace ("Template data:") with a JSON content type and associated to the Template: namespace). Helder.wiki 00:46, 8 July 2014 (UTC)
It's a script, and it can have a reasonable amount of logic, but it also needs to work on 800+ WMF wikis, not just this one. So if we're going to recommend creating /doc subpages where they don't exist, the first question is whether that's something that's used everywhere, or just (mostly) here? Do all the wikis use /doc as the name, or do some of them use other names? Do any of them reject the subpage approach entirely? Also, creating the page is not the same thing as transcluding it, of course, so I'll need to find out whether TemplateData will work if it's on the subpage but not transcluded, and assuming that it won't work in that case (which seems likely to me, but I might be wrong), we need to have a recommendation on how to transclude the subpage (e.g., directly or via the {{documentation}} template). Template:Documentation has a huge number of interwiki links, so it seems plausible that it will be okay everywhere, but that's something we need to be sure of before setting any defaults. It's no good adding {{documentation}} to the template if that doesn't exist.
And that takes me back to my original question: if I have a template that already contains some documentation, and I then add a /doc subpage but don't move the old documentation to the new subpage, is that going to cause any problems (other than aesthetics)? I don't think it will, but it'd be nice if someone could confirm this. Whatamidoing (WMF) (talk) 05:45, 8 July 2014 (UTC)
Re "/doc": I have seen a couple of wikis that use "dok", and others that use something else. For example, Module:Convert/doc = ilo:Modulo:Pagbaliwen/dok = vi:Mô đun:Convert/tài liệu. For example, Template:Convert/doc = ilo:Plantilia:Pagbaliwen/dok (but for some reason the Vietnamese Wikipedia uses vi:Bản mẫu:Convert/doc with "doc"). Johnuniq (talk) 09:51, 8 July 2014 (UTC)


<noinclude> issues

So apparently there was further discussion, and today's story is: You can't transclude TemplateData. That problem is now T69677. Mr. Stradivarius, you can wrap the TemplateData in noinclude tags: the response I received was, quote, "that’s what you’re meant to do".

The complete list of bugs (open and closed) mentions a couple of ideas discussed here, but not explicitly the idea of creating subpages. Given the variety of subpage names used at a few wikis, do you all think that would be a good idea? (I don't think that we have found any with no subpages, correct?) Whatamidoing (WMF) (talk) 17:36, 8 July 2014 (UTC)

@Whatamidoing (WMF): Yep, I know that you're supposed to put TemplateData inside noinclude tags. The problem is that if you use the "Manage template documentation" script while editing a template that doesn't have TemplateData already defined, then it puts the TemplateData right at the end of the page, after two line breaks, without any noinclude tags. This means that both the extra whitespace and the TemplateData will be included in the template output, unless the editor knows enough about templates and TemplateData to avoid it. If the script can add the noinclude tags itself, and make sure no whitespace is added to the template output, this should prevent TemplateData from accidentally appearing in articles. — Mr. Stradivarius ♪ talk ♪ 05:31, 9 July 2014 (UTC)
If, as it appears below, TemplateData is moving to its own namespace, then this might be irrelevant soon, as it could all go there. Does that sound appropriate to you? Whatamidoing (WMF) (talk) 20:02, 10 July 2014 (UTC)
That would solve the problem, yes. I'm guessing the timescale for a TemplateData namespace is in the months, rather than the days, though, so it probably won't be in time to stop misplaced TemplateData from appearing on pages it shouldn't. It's hard to say what the scale of the problem may turn out to be, but in my opinion it would be better to fix it in the script now to reduce the likelihood of inexperienced template coders making mistakes. — Mr. Stradivarius ♪ talk ♪ 07:30, 11 July 2014 (UTC)

Reusing templatedata blocks

Tracked in Phabricator
Task T69677

The complete list of bugs (open and closed) mentions a couple of ideas discussed here, but not explicitly the idea of creating subpages. Given the variety of subpage names used at a few wikis, do you all think that would be a good idea? (I don't think that we have found any with no subpages, correct?) Whatamidoing (WMF) (talk) 17:36, 8 July 2014 (UTC)

You can use templates to translude portions of the TemplateData JSON object. You do have to use something like {{#tag:templatedata|Your templates here}}. I have set up an example at {{Ref supports}}. The resulting TemplateData can be seen here. The example transcludes separate portions of the template data JSON from 5 subpages onto the Ref supports/doc page which is then transcluded, using {{documentation}}, onto the template page. — Makyen (talk) 21:47, 8 July 2014 (UTC)
@Makyen: Though impressive, please don't encourage people to use incredibly-delicate hacks like this. It's likely that this kind of unintended use will get broken horribly from other changes, and would cause a lot of pain and irritation when that happens. It also makes it impossible to build tools that let you properly edit the TemplateData when you do this, too. Jdforrester (WMF) (talk) 21:58, 8 July 2014 (UTC)
I have no expectation that you will build a tool that will be usable to help edit TemplateData JSON that is intended to be consolidated from multiple pages. At least from my point of view, the intended use is to be able to build the JSON from multiple subpages each containing a subset of parameters. The specific use that I am considering is the CS1 citation templates where multiple templates share a large number of common parameters, but not all templates permit every parameter, or use them in exactly the same way. The documentation is built in this manner (transcluding subsections). It is reasonable that the TemplateData also be constructed this way. Other people have mentioned other groups of templates where it would be useful.
If you think that I was recommending to split the TemplateData into multiple pages for use by a single template then we miscommunicated. The example I worked up was merely that, an example; a proof of concept that it is possible.
As far as I can tell, I am using the {{#tag:}} parser function exactly as it is intended. It explicitly is intended to be used to allow "execution of wiki code and parser functions within tags before the tag is processed." That is exactly what is needed in this case because without it the TemplateData extension executes on the wiki-text of the transclusion syntax prior to the transclusions occurring. I do not see it as unstable or delicate. It has been a feature since 1.12 and has significant use in other areas (nested references).
This works. It works now. It appears to be a better option for use where multiple templates share parameters than copy-and-pasting portions of TemplateData JSON by hand, or alternately not having any TemplateData on those templates. It is not intended to be generally used on single templates. In such case, it would just be extra work for no reason and significant detriment. However, it is usable on groups of templates which share parameters where it is desireable to maintain consistency in the TemplateData across those templates. — Makyen (talk) 22:41, 8 July 2014 (UTC)
@Makyen: Works now and breaks next month. What a great example to set for users who are going to follow your advice. :-) #tag: is an exceptional hack that probably shouldn't ever have been enabled given the number of huge issues it's caused, and the massive reduction in engagement on getting improvements made to the software (because people can just scratch their own itch with a hack). Jdforrester (WMF) (talk) 00:11, 9 July 2014 (UTC)
Given that template data seems to be a very incredibly-delicate hack, that's quite an ironic request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 8 July 2014 (UTC)
@Pigsonthewing: Umm. Could you clarify what you mean? There are no hacks in TemplateData at all, this is standard industrial-scale MediaWiki engineering. Jdforrester (WMF) (talk) 00:11, 9 July 2014 (UTC)
TemplateData may not be a hack, but JSON is brittle, even if it's "standard industrial-scale" engineering. Anything that breaks if you get one too many or one too few commas on the whole page is difficult to use. WhatamIdoing (talk) 23:31, 10 July 2014 (UTC)
Same goes if the JSON is part of a Javascript data structure. It varies between browsers: this comma caused Internet Explorer to cough, but Firefox said "no problem". --Redrose64 (talk) 18:51, 13 July 2014 (UTC)
@Redrose64: This isn't very relevant to this discussion, but for the sake of nitpicking :) : The syntax for JSON and JavaScript objects is not actually the same. The most noticeable differences are a) JavaScript allows trailing commas in array and (in newer browsers) object literals, JSON doesn't, b) JSON requires quoting the keys, JavaScript doesn't, and c) JSON only accepts double quotes, JavaScript accepts single quotes too. For example, this is a valid JavaScript object but invalid JSON: { a: 'foo', }. Matma Rex talk 19:07, 13 July 2014 (UTC)
@Jdforrester (WMF) and Makyen: How about assembling the <templatedata>...</templatedata> tags and the JSON code using a Lua module, and then preprocessing it with frame:preprocess? That's what we're doing at Module:WikiProjectBanner to save WikiProject editors from having to write their own TemplateData. (Or at least, that's what we will do when we finally get round to finishing the module.) — Mr. Stradivarius ♪ talk ♪ 05:00, 9 July 2014 (UTC)
@Mr. Stradivarius: Yes, that also definitely won't work long-term. TemplateData will move to its own namespace which won't accept wikitext like #tag, template, or Lua invocations. Maybe instead we could talk about what you want to achieve so we can work on improving TemplateData for your needs? One of the things to bear in mind is that TemplateData is intended to replace most, or possibly all, of the /doc pages. Jdforrester (WMF) (talk) 22:23, 9 July 2014 (UTC)
I'm a bit dubious about this "replace most of the /doc pages" thing. On some of my favorite templates, the doc pages explain policy rather than anything technical about how to use the template, and I doubt that TemplateData would (or should) be an appropriate way to support that information. WhatamIdoing (talk) 20:04, 10 July 2014 (UTC)
@Mr. Stradivarius: I considered using Lua. If the {{#tag:}} parser function did not function, I probably would have gone there. Given that the {{#tag:}} works, I just don't see a need for the added complexity, increased development time, and reduction in maintainability (due to fewer Lua developers than those that can understand a simple {{#tag:}}). The only advantage I see is that it reduces the unexplained concerns expressed by Jdforrester (WMF), which, while they may be valid, are unexplained and appear to be based, at least in part, on a personal bias against the existence of the {{#tag:}} parser function. If what I was envisioning for use required any significant processing or logic, then Lua would be the way to go. As it is, I don't see any benefit to using Lua in a case where what is effectively being done is just transcluding pages. If it was something that would save a significant amount of back-end processing, then maybe it would be worth it. But, based on the fact that a null-edit of the template page is required to update the TemplateData (when the TemplateData is contained on the /doc page), it is clear that the TemplateData is certainly not generated from scratch each time it is requested from the API. Thus, even if the usage of the TemplateData is high (e.g. VE suddenly becomes the default editor) generating the expanded wiki-text from which the TemplateData is generated would still be a very rare occurrence. — Makyen (talk) 09:50, 9 July 2014 (UTC)
@Jdforrester (WMF): Actually, I believe it is a good example to set for others. It allows us to move forward, should we choose, on creating TemplateData for groups of heavily used templates rather than throwing up our hands and either waiting for some unknown future date when a newly created bug report might get fixed or creating the TempalteData using the very unmaintainable method of copy-and-pasting, with modifications, the entirety of the JSON from one template to another. Doing either of those options would be a bad example.
It is not clear that it will break in the future. You have not explained why you believe using the {{#tag:}} may break in the future. Even if it does break in the future, fixing it is the very simple replacement of {{#tag:templatedata|Your templates here}} with <templatedata>Your templates here</templatedata> which can easily be accomplished with a simple regex replacement using AWB. It would be easy to change even if the run had to check the entirety of the template namespace (database scan, then actual changes made on the very few that will actually use this method). This assumes that the bug/issue that prevents using templates inside <templatedata>...</templatedata> actually gets fixed. Even if that issue was not fixed and no other way was determined to allow the transclusion of templates effectively within <templatedata>...</templatedata> tags then it would be a simple matter of using that AWB run to {{#subst:}} the templates – a change that could be reverted once transclusions did work. On the other hand, there is no way for us to know in the future if the deployed version of TemplateData actually fixes this issue due to your refusal to use version numbers for the TemplateData code which results in no method to distinguish between the versions of mw:Extension:TemplateData released with the MediaWiki software.
It is clear that you have a personal bias against the {{#tag:}} parser function. That is fine. The situation would certainly be better resolved by having templates work normally within <templatedata>...</templatedata> tags. However, that is currently not the case. It is not clear when, or even if, it will be the case. If you would explain why you think using {{#tag:}} might break in the near future, then perhaps we could better evaluate if using it should be abandoned. — Makyen (talk) 09:50, 9 July 2014 (UTC)
@Makyen: While there are probably no immediate issue with using {{#tag:templatedata, I also think that was a misguided feature as it lets you do too many things that are not supposed to happen, making it possible to "break" the parser in various interesting ways (I can share some examples, but preferably not here because of WP:BEANS; one well-known issue is nesting <ref> tags, which was never supposed to be possible).
How about a different solution: let's allow multiple <templatedata></templatedata> tags on the page, and the final template data for the page would be the "sum" of the ones given on the page (with the description objects merged recursively). For example <templatedata>{a: 123, c: 5, foo: {b: [1, 2, 3]} }</templatedata> together with <templatedata>{b: 345, c: 42, foo: {c: 'asd'} }</templatedata> would be equivalent to <templatedata>{a: 123, b: 345, c: 42, foo: {b: [1, 2, 3], c: 'asd'} }</templatedata>. This would let you reuse descriptions of parameters from other templates (by simply {{transcluding}} their documentation pages) without being too "freeform" to be editable using specialized tools (it should be rather easy to do it so that only the content of tags directly placed on this page would be editable, while the rest would be just shown "greyed out" or something). Thoughts? Matma Rex talk 10:18, 9 July 2014 (UTC)
It sounds like that might be a reasonable long-term method of accomplishing what is desired as opposed to permitting transclusions within <templatedata>...</templatedata> tags. It would be necessary to consider what to do about a variety of issues, for example: Is the display on the page merged when the <templatedata>...</templatedata> blocks are immediately consecutive, or just the API JSON; how to handle duplicate parameter names defined in multiple blocks (merge various attributes with last definition which includes a particular attribute superseding any prior?, last entry completely supersedes?; a way to indicate that a parameter is not used even if defined in one or more blocks; etc.
At a minimum, multiple <templatedata>...</templatedata> blocks should be handled in some other way than silently using just the last <templatedata>...</templatedata> block because that is contrary to user expectations. What a user would currently be expecting from multiple <templatedata>...</templatedata> blocks, I am not sure. The presence of multiple <templatedata>...</templatedata> blocks should probably either be used or generate an error.
I am certainly not wedded to using {{#tag:}} and I don't prefer it as a long-term solution. Its primary advantage is that it is currently a functional method if including TemplateData definition JSON from other pages and is easy to change to <templatedata>...</templatedata> if and when <templatedata>...</templatedata> has the capability to include transclutions within the block. — Makyen (talk) 14:40, 9 July 2014 (UTC)
@Makyen: Please don't attack the messenger with comments like "personal bias" when I am informing you of reality. :-) I, as product manager for all editing tools (including TemplateData), am trying to explain to you that your hack will definitely not survive the future transition to its own namespace.
Finding things you want to do that TemplateData doesn't is totally understandable. Expressing the wish for TemplateData to be extended is great. However, failing to mention that you have this issue but instead finding an impressive but doomed hack just adds more cruft to the wikis, and robs others of the insights you have about possible routes to improve TemplateData.
If you go ahead and implement this, in a few months' time the community will have to fix up after you. Maybe instead we could work together on improving TemplateData for your needs? Jdforrester (WMF) (talk) 22:23, 9 July 2014 (UTC)
The use of #tag is fairly common where we need to include variable data within a parser or extension tag; for example, in {{reflist}}. We could create templates, let's call them {{TemplateDataStart}} and {{TemplateDataEnd}}. My concern would be if the Manage TemplateData would recognize the TemplateData block. Need to do some testing there. --  Gadget850 talk 12:29, 10 July 2014 (UTC)
Regarding the statement that "TemplateData is intended to replace most, or possibly all, of the /doc pages", and agreeing with WhatamIdoing that many of the "doc pages explain policy rather than anything technical about how to use the template, and I doubt that TemplateData would (or should) be an appropriate way to support that information", in the event there is any idea that we will use the /doc subpage's text in the templatedata, please note that copyright must be preserved. That means than we would either have to port the history somehow, or provide clear attribution, in conformity with our licenses. I have written or contributed to many doc subpages that have detailed content, and I own the copyright to whatever I wrote, as does anyone else who had a hand in a template's /doc subpage's text.--Fuhghettaboutit (talk) 22:54, 12 July 2014 (UTC)

Integration of TemplateData with Lua

This is a continuation of the discussion above about generating TemplateData using Lua. Some Lua modules don't have their parameter names hard-coded into the module itself, but instead load them from a config file so that they can be easily configured to work on other wikis. A good example of this is Module:Citation/CS1/Configuration. For these modules, it makes sense to automate the generation of TemplateData from the config file; this saves users from having to type in config twice, and keeps the config page and the TemplateData synchronised.

Kephir and I are planning to take this a step further with Module:WikiProjectBanner. Rather than just having one config page for the module, each WikiProject will have its own config submodule containing various data necessary for the module. Initially, our plan was to get parameter information from the config submodule and use this to generate the TemplateData, the documentation page, and data for third-party tools such as Kephir's rater. However, if we aren't going to be able to generate TemplateData from Lua in the future, we will need to rethink.

How about this approach - instead of generating the TemplateData with Lua, we use the TemplateData as the config file. We load the TemplateData from Lua, check that the data structure is valid for whatever it is we want to do, and then make the parameter names specified in the TemplateData available to the user. This would keep our data synchronised, and it also wouldn't be liable to break when TemplateData moves to its own namespace.

While we haven't talked about using TemplateData for configuration yet, we did talk about it as a possible data format to use with third-party tools. That was back in June 2013, so a lot has undoubtedly changed since then, but at the time, Kephir said that TemplateData would need to be able to handle grouping and type annotations — whether a parameter denotes a request, B-class checklist item, task force membership, more detailed information on allowed values than just "string", whether a parameter should be paired with another (like task force membership and importance, request notes). I'm not sure how much of this is possible in the current version of TemplateData, but we would need similar information to make TemplateData usable as a module config file. — Mr. Stradivarius ♪ talk ♪ 07:16, 11 July 2014 (UTC)

To note: in the current implementation of Module:WikiProjectBanner, I designed a config page in an independent format and made the module generate TemplateData in a Lua table from that, then have a lightweight JSON serialisation module convert it to JSON, and feed it to the <templatedata> tag. I just tested it and it seems to work as expected at this stage. There is a caveat, though: you have to null-edit the template itself for the TemplateData to be updated. By which I mean null-edit — purging or even purging with forcelinkupdate do not work. — Keφr 07:56, 11 July 2014 (UTC)
About purge not working, see bugzilla:50372. Helder.wiki 12:28, 11 July 2014 (UTC)
@Mr. Stradivarius and Kephir: That sounds like it could be an option, and very impressive, but possibly unmanageable in the long term as a towering edifice/thicket of impressive, terrifying code that no-one dare touch lest they break everything? Just something to consider. Jdforrester (WMF) (talk) 18:41, 11 July 2014 (UTC)

Content going under references

In response to a Teahouse question, I looked at an edit and tried to repeat it, but of course the table ended up under references anyway. I don't see any ref tags out of place, so something very strange must be going on.— Vchimpanzee • talk • contributions • 16:52, 12 July 2014 (UTC)

User:Glaisher tried something that merely kept the content from going under "References", but it's still in the wrong section.— Vchimpanzee • talk • contributions • 16:58, 12 July 2014 (UTC)
Special:Diff/616672504 Missing |} did that. --Glaisher (talk) 17:02, 12 July 2014 (UTC)
Thank you. I saw missing bracketsbraces but didn't think about that.— Vchimpanzee • talk • contributions • 17:08, 12 July 2014 (UTC)

Argument delimiters in a Mediawiki function

See User:Dank/trop1.js for a snippet. The Mediawiki function mw.util.$content.highlightText technically takes a single string as an argument, but within that string, it uses spaces to delimit the arguments that are passed to some other function (presumably) and highlights any of those arguments on any page (for the user only, it doesn't actually make changes to a page). It works great ... except that a space is a bad choice for an argument delimiter, since that makes it impossible to search for and highlight a two-word phrase. This has been reported to bugzilla (here), and assigned a "low" priority, but for all I know, there might be a simple fix here, if the delimiter I'm talking about here could be changed to something else (tab would work, or an array of strings). - Dank (push to talk) 12:39, 13 July 2014 (UTC)

User:Seppi333/EditCounterOptIn.js

It sounds like a product that haz been done in hit counters on web pages over and over again, with facebook statistics being curtailed, because they can name people, and geographical hits being the most interesting graphic. Why would I want to opt into an edit counter? Please reply on my talk page. 75.152.119.10 (talk) 17:48, 13 July 2014 (UTC)

Toolserver shut down

No more reflinks

It's gone as of today. Is there something else we can use? Anna Frodesiak (talk) 02:36, 1 July 2014 (UTC)

FYI: The toolserver.org reference converter seems to be shut down

I just saw the following error when visiting both http://toolserver.org/~dispenser/cgi-bin/webreflinks.py and http://toolserver.org/~dispenser/view/Reflinks:

"Good bye Toolserver

As of July 1, the community run Toolserver was shut down. My tools weren't aligned with the Wikimedia Foundation's priorities, so they didn't make the transition to Labs."

In my opinion, this is a valuable tool that should be retained, not disbanded. --Jax 0677 (talk) 02:55, 1 July 2014 (UTC)

Completely agree that this is a great tool and should be preserved! MaxPayne888 (talk) 07:06, 1 July 2014 (UTC)
I don't see why people are acting all surprised about this. Here at VPT, we've known for about two years that all was not right with Toolserver. For the last year or so, we've been told - quite often - that it would be shut down; and some months ago we were told that it would be no later than 30 June. So, today is 1 July, and I don't expect any Toolserver links to work, ever again. --Redrose64 (talk) 07:32, 1 July 2014 (UTC)
To answer the question about Dispenser's tools on the Toolserver, this user has stated on several occasions that they will not migrate their tools from the Toolserver to the new Wikimedia Labs infrastructure. I believe it has something to do with not being allocated the very large amount (24 TB) of disk space that was requested (see an old discussion), but Dispenser didn't really explain himself very clearly. — This, that and the other (talk) 07:49, 1 July 2014 (UTC)
I have to say I honestly can't imagine why you'd need anything remotely near 24TB to store 20 million links - that's more than a megabyte per link. And as was pointed out somewhere else, with the WMF servers using multiple redundancy and industrial-grade disks, that's not a trivial amount of resource - it's not like buying a bunch of cheap disks for your home PC. If the WMF raises it as a significant issue (which it is), the way forward is surely to engage in discussion on how to reduce the space requirements and how to fit it in with WMF's available resources? — Alan / Boing! said Zebedee (talk) 08:40, 1 July 2014 (UTC)
  • I don't much care about the rationale. It's in the left hand menu and it needs to work. It's referred to in countless places. The alleged wisdom f crowds strikes again. So how about someone who understands the politics gets it put back? And no, I wasn't aware it was going because, hey, I don;t come here often. Fiddle Faddle 08:27, 1 July 2014 (UTC)
@Timtrent: It's not in the left hand menu for all users; it's only there for you because it's been installed in User:Timtrent/vector.js - specifically, it's all the lines from 
// Add [[WP:Reflinks]] launcher in the toolbox on left
to the end of the file. --Redrose64 (talk) 08:44, 1 July 2014 (UTC)
Alarmed to hear this brilliant tool is no more. It was far the best way to create footnotes and rescue old ones. It did not work with Internet Explorer, but it worked perfectly with Firefox. How crazy to get rid of it. --P123ct1 (talk) 10:00, 1 July 2014 (UTC)
That does not console me. It is referred to in countless places, in templates, in help pages, in talk pages. The link to it is everywhere. And it needs to work again. Fiddle Faddle 08:47, 1 July 2014 (UTC)
I'm pretty sure the only way it will ever start working again is if Dispenser chooses to migrate it to Labs, or releases the source code to allow someone else to migrate it (as far as I can tell, the source code is not publicly available). Either way, it would be an immense undertaking that would take a substantial amount of time. — This, that and the other (talk) 08:52, 1 July 2014 (UTC)
And so we descend into the morass of linkrot. Oh joy. We migrate Wikipedia more and more towards Idiocracy. Shall we just turn the lights off now? Reflinks goes. Citation bot stops combining duplicate references, and the whole edifice takes a backward step.
Or shall we do something about it? Gosh it might involve money. Well, WMF has money. Let's spend some. Fiddle Faddle 08:58, 1 July 2014 (UTC)
  Like. Fylbecatulous talk 12:52, 1 July 2014 (UTC)
Yes, why don't we do something about it ? The community needs editors and the editors need good project governance and skilled technical volunteers. There is more than one way to contribute and you are welcome to step into any of those roles at any time. If you write a well defined grant request the Foundation even might throw some money your way. —TheDJ (talk • contribs) 09:10, 1 July 2014 (UTC)
I;d like to thank you for your encouragement. When I get some from you I will. Fiddle Faddle 10:19, 1 July 2014 (UTC)
@Timtrent: To return to your point "I wasn't aware it was going because, hey, I don;t come here often" - VPT was not the only place. I've checked the Signpost archives, and have found:
There are plenty more. --Redrose64 (talk) 09:38, 1 July 2014 (UTC)
Yes, justify it all you like. I never saw it. I gave up reading the signpost ages ago. Still, now it has gone I hope the furore over its departure will do something. This reminds me of the Vogon constructor crew who demolished the earth and the earth never had time to object because it never saw the notice. Fiddle Faddle 10:22, 1 July 2014 (UTC)
What Reflinks used to do, even with its limitations, saved a lot of time. To echo Anna Frodesiak: do we have any similar tool? Sam Sailor Sing 09:17, 1 July 2014 (UTC)
  • Reflinks was an invaluable tool, and I would like to add my support to the calls to revive or replicate it. --LukeSurl t c 09:23, 1 July 2014 (UTC)
As above - whatever the reasons or rationale, this tool is invaluable and all efforts to revive it should be explored. Manually trying to deal with all the bare URLs around would take eons, and I seriously doubt anyone would be prepared to reduce their numbers. For anyone uncertain of the size of the problem see [Category:Articles needing link rot cleanup from June 2014], for just one month's worth of the backlog to be addressed.
Derek R Bullamore (talk) 09:49, 1 July 2014 (UTC)
I'll add my two cents worth of pleaing - please bring back Reflinks in some shape or form, a crucial tool. Mick gold (talk) 11:13, 1 July 2014 (UTC)

Checklinks has also gone. - X201 (talk) 10:38, 1 July 2014 (UTC)

Well, this is unfortunate. I knew there was some question and trouble surrounding this from past usage of the tool, but didn't know it was going to go away today... Is there no alternative or similar tool at all? -- ferret (talk) 11:44, 1 July 2014 (UTC)
  • Okay, so this finally happened (it's been announced many times it would, but it kept getting postponed). The first thing people who come here are going to want to do is to remove the chunk of code from their common or skin specific .js page that looks something like (if you are unsure exactly what to remove, I'd be happy to look and help you):
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {
 addPortletLink(
  "p-tb",     // toolbox portlet
  "http://toolserver.org/~dispenser/cgi-bin/webreflinks.py/" + wgPageName
   + "?client=script&citeweb=on&overwrite=&limit=20&lang=" + wgContentLanguage,
  "Reflinks"  // link label
)});
The next step is figuring out which of the multiple options for what we can do to come up with a solution to this loss in no particular order as I see it:
  1. Create a consensus to give in to Dispenser's demands for 24TB of hard drive space and request the WMF to consider it.
  2. Create another tool similar to reflinks and let it take over.
  3. Create a userscript or gadget to pull a list of link URLs in <ref>...</ref> tags on the page and scrape each URL trying to obtain as much information as possible about the page. It will loose a lot of the "other" features of reflinks, but will essentially offer replacement "preformed" citations in the simplest form.
  4. Create a partnership with another site (there's a vast array of "reference generator" sites like http://www.citationmachine.net/, http://www.easybib.com/, http://www.bibme.org/) to create a tool that will return better cited pages.
  5. Revise and update Citation bot (operated by Smith609) to be able to take over this task.
  • I'm sure there are other options I've not thought of, but I wanted to get the ball rolling discussing a solution to the problem instead of re-establishing there is a problem. I personally support the upgrade to Citation bot to allow it to automatically fix citations and also be able to do so via a UI. There is also a discussion on mw:Tool Labs/Collection of issues after Toolserver shutdown where you can report other tools that are now gone that you will miss and work on building the list of tools to recreate or get migrated over. — {{U|Technical 13}} (e • t • c) 12:53, 1 July 2014 (UTC)
  • I think an obvious possibility that you have perhaps overlooked it to get Dispenser to release the source code into the public domain and explain the need for that 24TB (times redundancy requirements). That way, perhaps some work can be done on improving data-storage efficiency (and at more than 1 megabyte per link, there surely has to be something better). And if Dispenser doesn't want to do the work, perhaps someone else could take over? (As an aside, I think a general good move forward would be for the WMF to only allow tools to be run on their servers if the source is released into the public domain) — Alan / Boing! said Zebedee (talk) 13:22, 1 July 2014 (UTC)
  • This might be one for legal, but can the WMF after notification of the tool owners and a grace period open all the source code on their servers to the others interested in maintaining the tools? Basically a notification that they have X amount of time to get their tools/bots code off the server or it will be considered abandoned and based on the fact that all stuff one WMF servers is suppose to be CC-BY-SA anyways... I'm expecting a no, but it would be interesting to see exactly what legal has to say. If someone knows someone from legal that can ping them to this discussion for an answer, that would be awesome. Thanks. — {{U|Technical 13}} (e • t • c) 13:33, 1 July 2014 (UTC)
    • Actually, one of the differences between Tool Labs and the toolserver (and, a cause of friction originally), is that tools being Open Source is in fact a requirement of hosting in Labs – specifically to deal with that situation. We obviously can't do that retroactively, however. — MPelletier (WMF) (talk) 14:12, 1 July 2014 (UTC)
      • Ah, thanks for the info. I strongly support the requirement for all future tool code to be Open Source - it's entirely within the ethos of Wikimedia as a whole, and we really can't rely on tools that are privately owned and subject to the whims of their owners. — Alan / Boing! said Zebedee (talk) 14:44, 1 July 2014 (UTC)
  • If there is no hope to retrieve this, getting a replacement built will be important. Maybe it could be an Individual Engagement Grants project? —Anne Delong (talk) 13:57, 1 July 2014 (UTC)

(Copied from the AN thread): I don't know which employee who reputedly said [that 24TB was unreasonable], but that seems to be a gross simplification. I do remember discussing the topic with Dispenser about this, and I remember telling him that 24 TB is a significant chunk of the space available to Labs (our disk space is somewhat constrained and expensive to increase because it lives on a highly redundant array of commercial-grade disks and not on consumer devices), but also that he should discuss this with the Foundation to see if they could allocate the resources to support his tool.

I've also offered to help him analyze other methods of storage for his data (24TB does seem very inefficient for storing some 20 million external links – since it represents over a megabyte of data per link) but he has not offered further details of his architecture or engaged in discussion on how it could be adapted to Tool Labs.

Tool Labs remains open for anyone who has the desire to port/adapt/rewrite the tool. — MPelletier (WMF) (talk) 03:54, 1 July 2014 (UTC)

Re: "Is there no alternative or similar tool at all?" (by ferret) see a little list of ref tools:
And in future: https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog --Atlasowa (talk) 14:14, 1 July 2014 (UTC)
Updated, Makeref seems to work now --Atlasowa (talk) 08:17, 2 July 2014 (UTC)
@Timtrent: I'm also very disappointed that Dispenser's tools are now gone. I hope that they will be recreated in some other form. In response to your comment that "It's referred to in countless places", I started removing those references yesterday, including {{Cleanup-bare URLs}}, {{Incoming links}}, {{Dabnav}} and various documentation pages. Links still need to be removed from many other places, including many WikiProject pages (e.g. Wikipedia:WikiProject Mars#Tools). GoingBatty (talk) 17:27, 1 July 2014 (UTC)
@Redrose64: Although the Toolserver's demise has been a long time coming and mentioned in many places, I bet there are a lot of users who have been happily using Dispenser's tools without understanding that they were hosted on the Toolserver. GoingBatty (talk) 17:32, 1 July 2014 (UTC)
I was one of those users. I've always found Reflinks useful because I edit with a screen magnifier and it saves me having to search out names and dates from articles, which can present problems. I think we need to get something else up and running to replace it as soon as we can. I'll fix the sources I've added today manually, but can't imagine wanting to do that on a long term basis. It may also mean I'm less likely to take on big projects such as FAC and GA. This is Paul (talk) 20:18, 1 July 2014 (UTC)
Reply - While http://tools.wmflabs.org/templator/?language=en may be the best replacement, it is still much more time consuming than WP:REFLINKS. While I do not have the skill set to create such a tool, I think that it would be extremely helpful to have something equivalent put in its place. If we do not replace this tool, we will have numerous problems with link rot. --Jax 0677 (talk) 19:29, 1 July 2014 (UTC)
Nah, doesn't even come close in terms of efficiency. Pulls in quite a lot of junk metadata, but still can you ever imagine trying to populate more than maybe two citations with Templator? I can, and the thought doesn't appeal in the slightest. -- Ohc ¡digame! 08:04, 2 July 2014 (UTC)

@This, that and the other: The code is available and could easily be ported, but cannot be used on Labs as it is not under a free license. πr2 (t • c) 20:26, 1 July 2014 (UTC)

  • I assumed every single tool was migrated over .... obviously not, I (and probably everyone else) used Reflinks everyday so I'm disappointed to see it's now dead... –Davey2010 • (talk) 21:36, 1 July 2014 (UTC)
Note: I am taking care of the links at the Wikiprojects as seen here :-) -- Moxy (talk) 00:48, 2 July 2014 (UTC)
  • How long would it take someone to write new tools to replace Dispenser's tools? And, I don't want to be stuck with the "visual" (= wysiwyg) wiki editor only. In wikis such as the Harry Potter wiki that have a choice between a visual editor and an old-type "source editor", I always choose the "source editor". Anthony Appleyard (talk) 08:43, 8 July 2014 (UTC)

A lesson

"this user has stated on several occasions that they will not migrate their tools from the Toolserver to the new Wikimedia Labs infrastructure" Why on Earth were we hosting tools which were (apparently) not open source, with the code available for anyone to fork? I hope that lesson has been learned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:54, 1 July 2014 (UTC)

Because it worked for years and WMF has other priorities. However, yes, tools on WMFLabs must be open source. --NeilN talk to me 17:11, 1 July 2014 (UTC)
That's good to know. I'm not clear, though, what "WMF priorities" have to do with what was on the toolserver. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 1 July 2014 (UTC)
Toolserver wasn't WMF, it was Wikimedia Deutschland. --Redrose64 (talk) 18:42, 1 July 2014 (UTC)
Andy Mabbett, it's an irritation I have with the WMF. I feel they should be proactive, look for tools that are heavily used in projects but have maintenance risks, and spend some of the ample funds they have to formally take them over or provide support to mitigate the risks. For example, Reftoolbar, one of the best tools for editors, was broken for significant periods of time over the past few years. Now I can't complain because it's maintained by volunteers. But instead of strengthening the stability and maintenance of these types of tools, WMF gives us other stuff... --NeilN talk to me 19:13, 1 July 2014 (UTC)
WMF stopped being proactive (except in a public-relations role) a long time ago. — Alan / Boing! said Zebedee (talk) 19:20, 1 July 2014 (UTC)
I've never seen it more proactive. I seriously wonder if people understand how much of what the WMF is currently responsible for was initially thought up and prototyped by highly committed volunteers. It's mostly just the scale that has changed. It always has been the volunteers that were the proactive ones. That's how and why the whole of toolserver got built in the first place and it's why WMF thought it was time to facilitate it in a more permanent manner. It might not be finished yet, but long term this is probably a much healthier setup. Also when asking why, remember that the toolserver much predates the technical staff of WMF actually. Toolserver started in 2005. In oktober 2006, WMF only employed 2 technical staff employees. I would however qualify them more as 2 paid fulltime volunteers assisted with a ragged bunch of unpaid volunteers. It probably took until late 2009 before WMF tech staff was able to look into the future beyond just 'keeping the thing online'. By that time toolserver was already hosting hundreds of services. It's why an API was added, why ResourceLoader arrived, why work was done on replication and database dumps. In some way that made the problem bigger, because more tools were being built by more volunteers :) —TheDJ (talk • contribs) 21:18, 1 July 2014 (UTC)
So WMF reacted reactively to what individuals were doing, and saw that it was good and helped - but that's not proactive — Alan / Boing! said Zebedee (talk) 21:33, 1 July 2014 (UTC)
You mean it's not proactive on the front end parts that you care about. It was quite proactive at backend parts. But that doesn't translate into instant results, it's with the foresight of the next ten years, not for today. —TheDJ (talk • contribs) 22:21, 1 July 2014 (UTC)
Sadly, there is very little that we (the WMF) can do about tools whose maintainers refuse to open source. We obviously can't simply steal their code, or forbid project volunteers from using them until they break. The only thing we can do (and have done) is to provide an infrastructure for running tools of that kind with a set of rules designed to make sure things like that cannot happen in the future.

I suppose you could say that the lesson was already anticipated and learned; but there's nothing we could do that would fix things retroactively. — MPelletier (WMF) (talk) 23:53, 1 July 2014 (UTC)

Thanks for the comment. Obviously, it sucks to abruptly lose a tool that many people used productively... but it's pretty much inevitable that something was going to break with the shutdown of the Toolserver, especially given the lack of agreement with the author of Reflinks in terms of licensing and computing resources. —Moxfyre (ǝɹʎℲxoɯ | contrib) 01:57, 2 July 2014 (UTC)
MPelletier (WMF), I'm not sure the lesson was fully learned. Suppose some other volunteer tech guru resurrects Reflinks. Is WMF prepared to allocate money and resources to ensure the code will be properly taken care of if the volunteer stops volunteering instead of hoping another volunteer steps up? --NeilN talk to me 02:10, 2 July 2014 (UTC)
I don't believe that's an entirely reasonable expectation any more than it would make sense to expect that the WMF could hire editors to take the place of leaving ones. We are, in the end, a volunteer-driven project; what we can do is make sure that everything is in place to make sure that any volunteer that is willing to take over a community tool is able to.

That said, any tool that has become a critical component of the volunteers workflow may be a reasonable candidate for integration into production (as an extension, perhaps, or part of core) and it might be a good idea to propose its rewrite/integration as an Engineering project. — MPelletier (WMF) (talk) 02:39, 2 July 2014 (UTC)

WMF is a volunteer-driven organization? News to me. So all these people are volunteers? We both know WMF is largely staffed with paid positions, designed to support a volunteer organization which focuses mainly on content. It is entirely reasonable to expect any good proactive IT department to identify important IT functionality which is weakly supported by them and take steps to improve the situation. Again, being proactive is not waiting for users to come to you with proposals hoping to pick up spare change left over from VE and Flow. Being proactive is actually assigning WMF resources to go out into the projects, seeing what's being used, and making sure the important stuff is properly covered as part of their every day jobs. --NeilN talk to me 03:45, 2 July 2014 (UTC)
Of course it is. None of it would be here if it weren't for the volunteers who originally built the Wikimedia movement. And if they all left, the WMF would be absolutely nothing. Legoktm (talk) 04:48, 2 July 2014 (UTC)
I don't think you're understanding or addressing the distinction I'm making. --NeilN talk to me 04:54, 2 July 2014 (UTC)
In the years in which editing and development were both voluntary, an editor would see an issue, and a developer would address it in a 1:1 tester/developer ratio. When the code was stable, the tester would announce it, and the developer would wait for more requests. Very efficient. Why couldn't this kind of model be used today? That would lessen the amount of overhead. --Ancheta Wis   (talk | contribs) 05:11, 2 July 2014 (UTC)
Development IS still voluntary plus a few people get paid by WMF so they can do long-term development and are definitely around. Maybe you missed the word "completely" in your sentence? Anyway, when were those days you dscribe? How did that one tester among those tens of thousands of users find that one developer among those thousands of developers? How many issues are you aware of that never got reported plus which criteria allow to judge which model worked better (if there actually are different models)? Are there examples that your described model works and scales in any other really huge free collaboration project on the internet? I'm curious and somehow doubtful. --Malyacko (talk) 09:01, 2 July 2014 (UTC)
It was over 10-11 years ago. Wikipedia was small enough that Recent changes was usable, meaning that the community of editors could lurk and pounce on the changes. For example, when the homunculus page was started with one sentence, 7 editors jumped in over the hour & a half after it was started. At that time, Wikipedia had a large number of developers who also edited, so a peer would request and another peer would implement, or administer. The peers separated out by interest/inclination afterward. As another example, User:Eloquence proposed that the main page have a small number of categories to link to, so we just jumped in and re-implemented the main page. We seemed to all know html, for example, and the wiki text just seemed intuitive, not needing explanation. The help pages got implemented in the same way. One peer, then another, in a huge cascade, as in for example {{catmore}}, now obsolete. Hacking got us what we wanted, for example when user:mav discovered the proper magic word to increment the date counter, which was the basis behind Selected Anniversaries. There were no portals, at the time, so we abused the category pages to serve as portals. You get the idea. Very few constraints. --Ancheta Wis   (talk | contribs) 14:21, 2 July 2014 (UTC)
I am torn between thanking Dispenser for creating this tool, which was immensely useful, and berating him for not making it open source/free software and "taking his toys with him". Did anyone ask him (or did he say himself) why his tools are not open source? User:Dispenser/Toolserver migration hardly explains much, and I do get the general feeling of "either my way or the highway" attitude :( PS. That said, perhaps there's just some sort of misunderstnading/burn-out. I'd hope that current troubles don't overshadow Dispenser's immense contributions, and we can work this out - i.e. if he is too burned out to continue himself, at least convince him to license his tools under GFDL or such. Looking at his page at [11] I am not seeing any copyright notice; does anyone know if he ever addressed that in some shape or form? (Also, how stupid it was of us not have a generic note that any and all content hosted on the Toolserver would be open source...?).
I said it before, however, just like User:Pigsonthewing, that hosting non-open source content on toolserver was an error. It created a set of bad practices that we are now paying for. If it's not open code, we should reject it from the start. PS. If anyone replies to me directly, please echo me. Thanks, --Piotr Konieczny aka Prokonsul Piotrus| reply here 13:37, 2 July 2014 (UTC)
Piotr Konieczny aka Prokonsul Piotrus, you bring up a good point. Dispenser's tools are open source but not freely licensed. The new Tools Labs policies only state that tools have to be open source and open data, nothing about licenses. So what's to prevent a similar situation from happening again? MPelletier (WMF), can you comment? --NeilN talk to me 14:08, 2 July 2014 (UTC)
@NeilN: What does "open source but not freely licensed" mean? Are you saying that he shares the source code (does not imply open source) but doesn't license it under a free/open source license? —Moxfyre (ǝɹʎℲxoɯ | contrib) 18:19, 2 July 2014 (UTC)
@Moxfyre: Correct. The source is publicly available but is not freely distributable or modifiable. Kind of like Microsoft_Reciprocal_License#Restricted_licenses. --NeilN talk to me 19:13, 2 July 2014 (UTC)
@NeilN and Moxfyre: Actually, according to open source, it's a bit confusing, but making code available to others for viewing is not making it open source. This requires "a universal access via free license to a product's design or blueprint, and b) universal redistribution of that design or blueprint, including subsequent improvements to it by anyone", hence a free license has to be used. So the current Labs requirement of open code seems fine, as it does include a requirement for a free license built in the definition, as far as I can tell. --Piotr Konieczny aka Prokonsul Piotrus| reply here 10:13, 3 July 2014 (UTC)
Piotr Konieczny aka Prokonsul Piotrus, if it came down to it, no court is going to take legal definitions from an always editable Wikipedia article. There is no downside for the WMF to list the free license requirement explicitly in the policy. --NeilN talk to me 12:41, 3 July 2014 (UTC)
@NeilN: You are right. Please let me know if there's a place we can demand that such a requirement is explicity stated. There should no repetition of this fiasco. --Piotr Konieczny aka Prokonsul Piotrus| reply here 13:05, 3 July 2014 (UTC)
There is no need for such a demand; for one, the requirement of the terms of use already explicitly state "Do not use or install any software unless the software is licensed under an Open Source license." with a link to opensource.org's definition. In addition, I've already begin discussion with WMF Legal about providing for a default license for software that has not been explicitly licensed. — MPelletier (WMF) (talk) 13:17, 3 July 2014 (UTC)
Thanks for the response, MPelletier (WMF). --NeilN talk to me 15:13, 3 July 2014 (UTC)
The mistake is to break all these tools at once because WMF wanted to "own" the tool service. Having the German Chapter run the toolserver was valuable distribution of our eggs into more than one basket. All the best: Rich Farmbrough, 22:17, 2 July 2014 (UTC).
Rich, to be fair there was no "at once"; the tools that broke were either long abandoned or their maintainers have actively refused numerous offers of help from both the WMF labs team and WMDE to help move their tools over the past 18 months. — MPelletier (WMF) (talk) 16:44, 3 July 2014 (UTC)
My concern, which I have expressed weakly and in random places, is that a distributed set of tools, hosted all over the world, run by different people, using different systems is more robust than everything sitting in one (or two) server rooms in the same country, maintained by the same people, looked after by one single legal entity. In the old scenario if WMF went down, anyone with the right set of dumps and some servers could resurrect the project. Bot owners and tool owners would simply re-target and everything would carry on. Indeed I would like to see the chapters getting involved in distributed hosting for this very reason. The same approach could have been taken, to offer to duplicate or replicate the toolserver in the US, rather than insisting on a complete new infrastructure and destroying a working system. All the best: Rich Farmbrough, 01:45, 7 July 2014 (UTC).

Other tools

I see above that checklinks was mentioned, but while this discussion is occurring, I'd also like to point out Dispenser's other tools like Dabsolver and Dabfix, which I've found useful for disambiguating links or expanding dab pages. They may not be as broadly useful, but they were handy and I'd hate to see them not replaced. —Ost (talk) 17:36, 1 July 2014 (UTC)

Dabsolver was by far the best disambiguation tool by a country mile. Will be less likely to dab without it.Blethering Scot 20:37, 1 July 2014 (UTC)
Yes, we always knew that if we made a mistake Dabsolver would be along soon to let us know about it. How many people will remember to check every link they add? This is Paul (talk) 20:42, 1 July 2014 (UTC)
That's what DPL bot does, and it has nothing to do with Dabsolver. Graham87 04:14, 2 July 2014 (UTC)
DPL bot provides links to Dabsolver in the message it leaves Users so they can fix the problem. See e.g. User talk:Yellow Evan#Disambiguation link notification for July 2. Tassedethe (talk) 23:40, 2 July 2014 (UTC)
This is Paul, you can try my Smart Linking tool for checking the links you are adding at the time you are adding them. --V111P (talk) 08:11, 3 July 2014 (UTC)
V111P, thanks, I'll check that out. I see DPLbot is still detecting disambiguation links, so hopefully it'll be possible to with your gadget. This is Paul (talk) 21:50, 5 July 2014 (UTC)

Is there a replacement for Dispenser's transcludedchanges tool?

I just tried to check the transcludedchanges WikiProject watchlist tool, only to find that since the toolserver had been shut down and the tool hadn't been migrated to labs, it doesn't exist anymore! Is there any replacement for this currently on labs or planned for labs, or will we have to make do without this incredibly useful tool for the forseeable future? StringTheory11 (t • c) 19:37, 1 July 2014 (UTC)

Yeah, I had the same experience. The WikiProject watchlist was one of my startup tabs. VanIsaacWScont 21:44, 1 July 2014 (UTC)
Ditto. This was the most valuable tool available to help manage WikiProjects. To suddenly find it gone with no warning and no replacement is very disconcerting. Meclee (talk) 23:41, 2 July 2014 (UTC)
It is possible and simple enough to create a list of all pages bearing a project tag and use the "related changes" special page to follow edits to them. Someone will have to frequently update the list though. User:WatchlistBot used to perform this sort of update but hasn't been running since 2007. --Paul_012 (talk) 02:55, 3 July 2014 (UTC)
For whom is this simple? I haven't a clue how to do what is described. If someone else understands these instructions and is able to implement, please drop a note on my talkpage. Meclee (talk) 15:02, 3 July 2014 (UTC)
The sad thing is, this tool is trivial to implement into MediaWiki. Just shows how out of touch the foundation is. — Dispenser 23:23, 14 July 2014 (UTC)

Also Scottywong's tools

  • Scotty tools. I don't know how many tools Scotty aka Snottywong had out there, but he has been semi-retired for a while. One of his tools we depended on at Did You Know was what DYK referred to as the QPQ check. It checked for how many previous DYK nominations a user had on the Main Page by detecting how many notices the DYK bot had placed on their user page. 5 or more means they are required to to a QPQ review when they nominate a DYK hook. Now we have no way of ascertaining that data. — Maile (talk) 22:13, 1 July 2014 (UTC)
@Maile66: "23:23 <Betacommand> Im in the process of writing DyK checker" "23:24 <Betacommand> Im about half way done already" Meatsocked by 930913 {{ping}} 22:36, 1 July 2014 (UTC)
Thanks. — Maile (talk) 22:38, 1 July 2014 (UTC)
@Maile66: "00:01 <Betacommand> http://tools.wmflabs.org/betacommand-dev/cgi-bin/dyk.py?user=Maile66 or http://tools.wmflabs.org/betacommand-dev/cgi-bin/dyk.py" "00:09 <Betacommand> Im open to feedback/more tool requests" Meatsocked by 930913 {{ping}} 23:12, 1 July 2014 (UTC)
I have posted a notice at DYK Talk and asked for comments to be posted here at this thread. This, looks good to me as far as duplicating what Scotty had. — Maile (talk) 23:31, 1 July 2014 (UTC)

"And here is the code for your /Common.js

if(wgNamespaceNumber==3 || wgNamespaceNumber==2) mw.util.addPortletLink('p-cactions', '//tools.wmflabs.org/betacommand-dev/cgi-bin/dyk.py?user=' + encodeURIComponent(mw.config.get('wgTitle')), 'DYK Notices');

Or if you prefer for your greasemonkey users"

930913 {{ping}} 23:35, 1 July 2014 (UTC)

OK, I copied and pasted the above to my Common.js. What does it to for me? Will it be in my Toolbox sidebar? What DYK really needs is for this to be added to Template:DYK tools, which then appears on each nomination template. — Maile (talk) 23:43, 1 July 2014 (UTC)
I pasted this onto the DYK tools template. We'll see how this works. — Maile (talk) 00:03, 2 July 2014 (UTC)

Can we raise the loss of these tools with someone at WMF?

I ask because I think the loss of all these tools will affect my ability to edit, and perhaps that of others. I'm classed as visually impaired and use a screen magnifier to work on articles, and things like Reflinks, Dabsolver, etc, save a lot of time and effort. As I've mentioned above I can't imagine wanting to take on anything big because it'll be a nightmare trying to get it into shape. We do need something to replace the tasks these things did. This is Paul (talk) 21:19, 1 July 2014 (UTC)

I'm certain that the WMF are aware: but it is not their fault that replacement tools are not on Labs. They did not create any of the tools on Toolserver, the onus is primarily on the tool creators to make sure that there is an equivalent on Labs. Missing tools fall into two main groups: those that were set up on Toolserver by users who (for one reason or another) are no longer with us; and those that were set up on Toolserver by users who are still around, but have either forgotten or refused to port the tools over. Either way, the WMF are not responsible for creating replacements; and if the source code is not available (as is the case with Dispenser's tools), there's not much that anybody else can do other than start from scratch. --Redrose64 (talk) 23:24, 1 July 2014 (UTC)
I have to point out here that this very scenario is the reason why the Labs terms of service were constructed from the start with the requirement that any software used or installed there (with very limited exceptions) be open source and readily salvageable in case of departure or inactivity by the maintainers.

It's obviously extremely disruptive when a community tool being relied upon by the project's volunteers for day-to-day works breaks down and can't be fixed; and Labs was designed to make that situation easier to recover from. — MPelletier (WMF) (talk) 23:46, 1 July 2014 (UTC)

It seems pretty clear now that the issue lies solely with Dispenser. He needs to come forth with the real reason for not porting it to the new server. Without his code, the place will have some hiccups but nothing will come crashing down. Nobody has been bothered rewriting it before because there was no need, but I am sure someone will come along and write a free-licensed version if Dispenser refuses to give over the code. But writing new code will take time. -- Ohc ¡digame! 02:15, 2 July 2014 (UTC)
A new reflinks will take a lot of time. Once again, why not put some money on the table? A cash offer for a new reflinks or the old code ought to get this sorted out right away. Why not? Anna Frodesiak (talk) 05:18, 2 July 2014 (UTC)
Only Dispenser knows the real reason why he's holding out. You may have an answer, but I wouldn't care to speculate. -- Ohc ¡digame! 08:07, 2 July 2014 (UTC)
Reply - Should we start an WP:RFC to have The Wikimedia Foundation reimplement WP:Reflinks or an equivalent application through their code or otherwise? --Jax 0677 (talk) 19:38, 2 July 2014 (UTC)
Can we raise the loss of these tools with someone at WMF?
You're already talking to WMF staff. Half a dozen devs routinely read this page. Marc–André (whom most of you will recognize better under the name Coren) and I are currently posting from "(WMF)" labeled accounts, but a lot of the devs on staff post from their personal accounts. Whatamidoing (WMF) (talk) 22:42, 2 July 2014 (UTC)
Noted above, but worth repeating: There is a discussion of lost tools at mw:Tool Labs/Collection of issues after Toolserver shutdown. -- John Broughton (♫♫) 18:58, 6 July 2014 (UTC)

Getting reflinks again

I asked Dispenser at his IRC channel if he could donate the code for reflinks to WMF. I'm not sure how that all works and if the code could be used again. Anyway, couldn't WMF even pony up some cash for the cause? Reflinks saves editors thousands of hours. It's an essential service, no? Anna Frodesiak (talk) 23:54, 1 July 2014 (UTC)

WMF seems to have $22,171,889 in a great big pile. I suggest we offer 5,000 bucks for the product, and that's peanuts. That would leave WMF with $22,166,889 which is still plenty. Anna Frodesiak (talk) 00:11, 2 July 2014 (UTC)

How would a "Throw some code over the wall" action help? I don't think it's really about money - code needs to be understood in order to maintain it, but nobody except for the author has an understanding of the codebase (and its complexity or quality). --Malyacko (talk) 09:07, 2 July 2014 (UTC)
Oh. Okay. Sorry. I just don't know anything about code. I thought it would just be like buying a software product. Anna Frodesiak (talk) 09:14, 2 July 2014 (UTC)
But, as Anna Frodesiak says, it saves (saved) editors thousands of hours?? Martinevans123 (talk) 09:23, 2 July 2014 (UTC)
@Anna Frodesiak: Usually, software bought off the shelf will have been written such that it will work on a variety of different systems, but not all - something written for Windows is unlikely to work on a Mac (and vice versa). Normally there is information on the packaging which shows which systems it works with - but for each of those, the software writers will have needed access to each of the different platforms that they claim compatibility with. If they only have access to one machine, which is running Microsoft Windows XP (Service Pack 3), they cant put "For Microsoft Windows" on the packaging, because it's unlikely to work with Windows 3.1, perhaps not even with Windows XP (Service Pack 2). By analogy, software written specifically for Toolserver won't necessarily work on Labs without careful testing and adjustment. We may be able to get a copy off Toolserver, and it may be possible to install that copy on Labs; if we can install, we can then test; but without the source code, we can't adjust. --Redrose64 (talk) 12:50, 2 July 2014 (UTC)
However, a savvy developer will be able to take the code and read it, and untangle the original requirements and design decisions from it. They can make an educated judgment call on whether to port the code or rewrite it, but without an original reference implementation of how it is supposed to work exactly, any new tool will be swamped by "it doesn't work with 'x'" reports the minute it's launched. So the code is useful even if it's not ultimately used. Ritchie333 (talk) (cont) 13:19, 2 July 2014 (UTC)
Underlining the need discussed here for Reflinks. I just came across an article with 579 references, almost all of them bare URLs. Based on the title of the list article, I think it must be one in a series of 26 articles. — Maile (talk) 17:52, 2 July 2014 (UTC)
A sad day for WP. And I can't believe the laconic WMF statement "everybody knew the toolserver was going to shut down". Yeah, i had heard about that, but never in my worst nightmares imagined that this would mean closing down tools like reflinks (and anybody here having trouble recently with Citationbot, too, especially articles with more than just a few references?) Isn't that what WMF is for, providing support for the editing community? Wasn't it obvious to anybody involved in the technical side of these things that massively used tools like this need to be replaced? As Anna Frodesiak says, they're sitting on a pile of $$$, why aren't they using it to prevent this kind of situations? Instead they are spending time, money, and effort on unwanted "improvements" (like the much-missed orange message bar) and sit idly by and watch the blue sky while hugely useful tools disappear. Make our life easier, not harder, people! --Randykitty (talk) 18:57, 2 July 2014 (UTC)
@Maile66: I just added some code to my cleanup app, that effectively automates some of legoktm's old code. Is this what reflinks is supposed to do? (I never used it.) 930913 {{ping}} 00:51, 3 July 2014 (UTC)
@A930913: That's a good start. Reflinks would also add the publisher, and sometimes the author and date and language. GoingBatty (talk) 01:00, 3 July 2014 (UTC)
@A930913: I'm not technically savvy enough to answer that. All I know, is that when I click Reflinks in my sidebar Toolbox, it cleans up all the bare URLs in whatever document I have on the screen. — Maile (talk) 01:13, 3 July 2014 (UTC)
@A930913: I'd say it was a close substitute, and would welcome it if it were made freely available.

I'll just preface my criticism here by saying I don't understand the issues User:Dispenser had with migrating to code to the new platform, and everyone here seems to be just guessin. But I feel WMF isn't to blame for this fiasco. We should definitely not be held ransom by a developer, however good the person is at coding and however useful the product is. Any goodwill User:Dispenser created for making and allowing the use of Reflinks and his other code is slowly evaporating because people are feeling being left in the lurch. As for having to pay $X,000 for it, that would create all sorts of issues with authors of other code that was or wasn't given over as GFDL. -- Ohc ¡digame! 01:40, 3 July 2014 (UTC)

@Ohconfucius: It's available for anyone who doesn't mind reporting the odd bug. (Also need some help documenting in general ;) ) Follow the instructions to install on WP:Vada, load it, and install "A930913's Cleaner" from the app store, then run it. Populate the queue, then click an entry or the next button to generate the diff. Change as required, then click the save button. (A plugin some may also want is the WikEdDiff one, also available from the app store.) 930913 {{ping}} 02:09, 3 July 2014 (UTC)
@A930913: A930913's Cleaner is a good start, but still needs more work in alpha testing before it can be usable by the general public. I tried it on one article and left feedback at Wikipedia:Vada/Talk. Thanks! GoingBatty (talk) 02:56, 3 July 2014 (UTC)

Checklinks Alternative?

Is there an alternative to Checklinks somewhere out there? I ask because I used Checklinks often to make sure my GA and FA articles are up-to-date link-wise. - Neutralhomer • Talk • 00:35, 2 July 2014 (UTC)

Seriously, no alternative to Checklinks exists? - Neutralhomer • Talk • 16:32, 2 July 2014 (UTC)
I need Checklinks (or something similar) for future GAN's and FAC's! SNUGGUMS (talk · contribs) 00:37, 3 July 2014 (UTC)

Break

24 TB isn't needed. Legoktm (talk) 00:58, 2 July 2014 (UTC)

I took it down due to Dispenser's request. It was a very simple proof of concept, that running webreflinks.py DOES NOT require 24 TB of space. It took about 2 hours to set up on a fresh webserver, or about 30 minutes on Tool Labs. Legoktm (talk) 01:28, 2 July 2014 (UTC)
User:Legoktm: can you tell us more about this request? What did Dispenser say? Why did he want you to take down what you describe was an already-working replacement? --Piotr Konieczny aka Prokonsul Piotrus| reply here 13:59, 2 July 2014 (UTC)
Hi Piotrus. Sure, you can see our conversation here. Legoktm (talk) 20:53, 2 July 2014 (UTC)

Please let's collect missing tools in a single place

Hello! Thanks for the feedback about what's missing! May I ask you to keep the collection of what is missing / malfunctioning in one place only? It's so much easier for everbody to go through one page only. As mentioned above, we created one single page where you add the tool you miss most, missing redirects from Toolserver to Tool Labs and problems you can't name exactly (we'll sort out what you mean). You add also add yourself as someone interested in migrating or maintaining someone else's tools, so the upper part can work a bit like a voting for those who want to help to see which tools are missed by how many people. Would you mind to bring the missing tools you mentioned over? Thanks! Silke WMDE (talk) 07:15, 2 July 2014 (UTC)

See list here: User_talk:Dispenser#A_table_showing_the_old_Toolserver_tool_and_its_replacement by User:Anna Frodesiak - is this what you wanted? --Piotr Konieczny aka Prokonsul Piotrus| reply here 13:52, 2 July 2014 (UTC)
Isn't that the same list as is shown at #Duplication detector below? --Redrose64 (talk) 16:40, 2 July 2014 (UTC)

Suggestion: positive reinforcement, or stuff the pride and ask (beg) nicely

Here's a thought. We can rant about some developers not using open source, taking their toys, etc., and it will make them even more alienated. Or we can consider that nothing is white or black, those guys (that guy...) did a lot for the community in their own way, and if we ask really nice, they may port the tools/relicence them under GFDL and let others work on them. So how about dropping at Dispenser's talk page, and leaving him a wikilove "thank you for your past great contribs, can you port/relicence your tools"? type of a message? I'd be surprised if getting a few dozen NICE requests telling him we appreciate his works wouldn't make him reconsider. I, for one, have been burned out of Wikipedia before, and few kind words, even in the occasional ocean of malice, did a lot to make me stay. Let's show Dispensers that we are not "leechers" who just demand and rant, and keep a lid on our valid but not so constructive complains of "he could've done it better" (yes, he could - and so could have all of us). --Piotr Konieczny aka Prokonsul Piotrus| reply here 13:57, 2 July 2014 (UTC)

RfC to have The Wikimedia Foundation implement an application equivalent to Reflinks

I am starting this thread to determine whether an RfC should be started to see if The Wikimedia Foundation can/should implement an application equivalent to WP:Reflinks, through payment, outsourcing or otherwise. I am not as familiar with the history of Reflinks as some people are, so I wanted to enlist feedback. Thoughts? --Jax 0677 (talk) 19:41, 2 July 2014 (UTC)

User:Dispenser/Checklinks was also very valuable. BollyJeff | talk 20:00, 2 July 2014 (UTC)
  • Lets wait for the fallout to settle and see who steps up to replace the tools that where lost in the toolserver shutdown. Odds are most of these will be replaced if we give them time to do so. Werieth (talk) 20:02, 2 July 2014 (UTC)
    • User:Technical 13/+3 Yes, exactly what Werieth says. I will say, I expect worse case scenario to be that when I start taking my C# class in about 7 weeks (Fall semester), my class project will be to create this tool (I've outlined some details of what I have in mind on my talk page in various sections). Worrying about it does no-one any good and crying about it on-wiki builds tension and there is no need for that. A little patience will go a long way for everyone here. — {{U|Technical 13}} (e • t • c) 20:47, 2 July 2014 (UTC)
Please, no RfCs on this page. Start one on WP:VPR if you like, or at WT:REFLINKS, but bear in mind that although WMF provided Labs well over a year ago (was it 18 months? don't rightly remember), they don't provide the tools hosted there. As stated in several posts above, all the tools that were on Toolserver, and all those now on Labs, were written by us. Unless one of us is willing to step forward and write a Reflinks-replacement, no amount of RfCing will persuade WMF to provide it. --Redrose64 (talk) 20:34, 2 July 2014 (UTC)
Jax, is your goal to have a tool that lets you put in a bare URL (or ISBN, or whatever), and get a formatted citation out the other end? If so, then it's already being done, with a goal of the first phase (use in VisualEditor) being finished in a couple of months. There are also several other existing tools that people have been using for several years, most of which are listed above.
The most helpful thing you can do is to try out what already exists, and, if you find that they aren't adequate, to figure out what Reflinks did that you can't do now. Depending on exactly what you want to do, you might find that your needs are already met, or that a small extension of an existing tool would meet them. Whatamidoing (WMF) (talk) 22:52, 2 July 2014 (UTC)
Reply - I appreciate your feedback, but mw:Citoid seems to require many steps and the installation of a great deal of software on my hard drive space. The http://tools.wmflabs.org/templator/?language=en site seems to be the best option at this time.
I wonder if Jimmy Wales knows about this issue. --Jax 0677 (talk) 23:51, 2 July 2014 (UTC)
@Jax 0677: I found Jimmy responded to a toolserver question on User talk:Jimbo Wales/Archive 166#Checklinks question, and I added a link to this thread. GoingBatty (talk) 00:05, 3 July 2014 (UTC)
@Jax 0677: How does the Templator help you? Seem to me that it doesn't do anything more than the built-in Cite tool in the toolbar (Wikipedia:RefToolbar). Better just use that, or try the tools listed on Help:Citation tools, including mine ;). --V111P (talk) 07:54, 3 July 2014 (UTC)
Jax 0677, it only requires local installation right now because it's "pre-alpha"—the very beginning stages of writing the software. In a few months, it should be available for anyone at the click of a button. Whatamidoing (WMF) (talk) 15:50, 3 July 2014 (UTC)

An RfC would be good. Has anyone asked Dispenser if he is willing to sell the copyright? Since he doesn't want to release the code, it means he either wants to make profit on it, or hurt the community. Hopefully it's the former, not the latter. Since WMF has a policy of paying for some code, I have no problem in buying code that has proven very useful in the past; it should certainly be a priority. --Piotr Konieczny aka Prokonsul Piotrus| reply here 10:16, 3 July 2014 (UTC)

Working again?

This edit has just appeared on my watchlist. I don't use Reflinks (I prefer to make my own mistakes), so was that a genuine Reflinks edit, or a faked-up edit summary? If genuine, has it been ported to Labs? --Redrose64 (talk) 12:22, 3 July 2014 (UTC)

It just worked for me and appears to be on Tools, with my old favorite redirecting me there. —Ost (talk) 13:14, 3 July 2014 (UTC)
Yes, it is now back up: see http://tools.wmflabs.org/dispenser/cgi-bin/viewer.py/Reflinks. I'm not sure exactly who is responsible, but some thanks seems to be in order. :) — Mr. Stradivarius ♪ talk ♪ 13:47, 3 July 2014 (UTC)
Yay!!!!! Anna Frodesiak (talk) 13:49, 3 July 2014 (UTC)
  Like A lot! Fiddle Faddle 14:24, 3 July 2014 (UTC)

I am torn, mostly because of this:
<@Dispenser> The tools are running on my home machine
<@Dispenser> It running in a VM on my own personal machine over a Wi-Fi connection
(t) Josve05a (c) 14:38, 3 July 2014 (UTC)

I see. We shouldn't get people's hopes up yet, then - this is probably only a temporary fix. But kudos to Dispenser for getting the tool running again at all. — Mr. Stradivarius ♪ talk ♪ 14:43, 3 July 2014 (UTC)
I'm pleased that Reflinks is now working. Checklinks and Dab solver don't appear to be working yet. I hope all of Dispenser's tools will soon move to labs, and that Dispenser will then be motivated to work on fixing the unresolved bugs reports from the last few years (which I'm presuming Dispenser wasn't motivated to do if his tools were going to disappear). Thanks! GoingBatty (talk) 16:36, 3 July 2014 (UTC)
I restored the Reflinks link in {{cleanup-bare URLs}} and its documentation, as well as a few other places I had removed it. I will do the same for Dispenser's other tools when they come back on line. Keep up the good work, Dispenser! GoingBatty (talk) 17:02, 3 July 2014 (UTC)
So does that mean he got a home computer with a VM environment that would allow him his 24TB of space he requested ? I doubt it very much, to be honest. Just my .02 Kosh Vorlon    17:01, 3 July 2014 (UTC)
«<Dispenser> Only got 6 TB on my home computer and 81 % full :-(» --Glaisher (talk) 17:07, 3 July 2014 (UTC)
  • Wow I'm extremely surprised to see it migrated to Labs :) - Thanks Dispenser :) –Davey2010 • (talk) 20:35, 3 July 2014 (UTC)

And it's down again, giving an "Unable to establish gateway with remote VM" message. GoingBatty (talk) 21:29, 3 July 2014 (UTC)

And back up again. Anna Frodesiak (talk) 21:45, 3 July 2014 (UTC)
Reply - I now get the following error when I run Jessie James on Reflinks:
"This page can’t be displayed
•Make sure the web address http://dispenser is correct.
•Look for the page with your search engine.
•Refresh the page in a few minutes." --Jax 0677 (talk) 11:35, 6 July 2014 (UTC)
@Jax 0677: It's working for me. Could you please let us know how you are trying to run Reflinks, so we can try to reproduce your issue? Also, what operating system are you using? (Someone else here had issues with Windows XP but not with Vista.) Thanks! GoingBatty (talk) 13:37, 6 July 2014 (UTC)
Reply - @GoingBatty:, Using Internet Explorer 11.0.9, I visited WP:Reflinks, then tried both links http://tools.wmflabs.org/dispenser/cgi-bin/webreflinks.py and http://tools.wmflabs.org/dispenser/cgi-bin/viewer.py/Reflinks?action=view. I typed in Jessie James, and I got the error shown. --Jax 0677 (talk) 19:14, 6 July 2014 (UTC)
Comment - I also tried it on Firefox 30.0, and I am having the same problems. --Jax 0677 (talk) 19:35, 6 July 2014 (UTC)
@Jax 0677: Same for me. https://tools.wmflabs.org/dispenser/cgi-bin/webreflinks.py/Jessie_James?client=script&citeweb=on&overwrite=simple&limit=10&lang=en doesn't work either. Hopefully User:Dispenser can get it working again soon! GoingBatty (talk) 21:34, 6 July 2014 (UTC)
@Jax 0677: I did get https://tools.wmflabs.org/dispenser/cgi-bin/webreflinks.py/Jessie_James?client=script&citeweb=on&overwrite=simple&limit=10&lang=en to work - see this edit. GoingBatty (talk) 23:08, 6 July 2014 (UTC)
Reply - @GoingBatty:, I got it working again on a different computer. --Jax 0677 (talk) 00:08, 9 July 2014 (UTC)

Just wanted to say how pleased I am Reflinks is up and running again, and thanks for doing that. It's much appreciated. :) This is Paul (talk) 17:30, 10 July 2014 (UTC)

Alternatives to Reflinks

Is there an alternative tool we can use from Wikipedia's labs? It has to live online as I often work from computers that are locked down for security reasons. TeriEmbrey (talk) 14:14, 3 July 2014 (UTC)

Help making a template

Ok so looks like we have or are going to have these great tools back. As noted above I have been removing the links to Toolsever from Wikiprojects pages...this includes links to Reflinks, dabsolver, etc..and watchlists. I am intersted in addind these bac to the project pages but with a template. However this time we should not just link dispenser tools but link the Wiki tool page and labs main page. Can I get help in creating this template. My main problem is a code that would detect the watchlist page by the project name space. This aspect is the only real help I need in making the template. The reason I am asking for a template is so we dont have the same problem in the future - that is 2000 projects all needing updating one by one over a nice template that can be amended at any time from one location. -- Moxy (talk) 21:59, 3 July 2014 (UTC)

@Moxy: Good idea - try [https://tools.wmflabs.org/dispenser/cgi-bin/transcluded_changes.py/Template:{{BASEPAGENAME}}|Wikiproject Watchlist - {{BASEPAGENAME}}] once it's back online. GoingBatty (talk) 22:09, 3 July 2014 (UTC)
That was fast WOW..going to work on it at Template:WPTools. Think best we list the top 5 or 6 tools that take you to a page with action and the watchlist with a "Main" links to the lab and wiki tool page. What are the most used tools our there? -- Moxy (talk) 22:14, 3 July 2014 (UTC)
IMHO: Reflinks, Checklinks, and Dab solver are good simple tools in that they do not require installation or approval to use - these seem to be commonly listed on WikiProject pages. LanguageTool is a work in process. The tools maintained by User:Ohconfucius are great, but require that the user modify their js page. AWB and WPCleaner are wonderful, but require installation on your PC. GoingBatty (talk) 22:25, 3 July 2014 (UTC)

Error: No text given for quotation (or equals sign used in the actual argument to an unnamed parameter)

Defaultsort

Maybe there could be created tool for work with DEFAULTSORT (and other magic words, too)? It could determine which articles in specified category (or category and its subcats) contains or not contains the DEFAULTSORT. It could also determine if article's title and DEFAULTSORT has the same value, so it could be deleted from article (ok, this isn't so important). It could save some time checking categories for people. It would be nice if it would be working in other Wikipedias, not only English (I would it use in another Wikipedia, but I think it is interesting for you, my English speaking colleagues). --Edgars2007 (talk/contribs) 15:08, 11 July 2014 (UTC)

@Edgars2007: You could do these as two separate tasks using AutoWikiBrowser:
  1. Create a list from a people category (or category and its subcats), and skip articles that contain DEFAULTSORT. It will then load each article that doesn't have a DEFAULTSORT and add one when necessary.
  2. Create a list of articles, and set up a rule to find {{DEFAULTSORT:%%pagename%%}}\n and replace it with nothing. Set the rule to run before general fixes, and then AWB will try to add the appropriate DEFAULTSORT if necessary. Note that this will find some false positives that you'll need to skip.
Good luck! GoingBatty (talk) 11:19, 12 July 2014 (UTC)
Ok, thanks! But if somebody is willing to create a tool for this, I wouldn't mind :) --Edgars2007 (talk/contribs) 12:09, 14 July 2014 (UTC)
@Edgars2007: Please note that AWB is a tool that can be used on other language Wikipedias. See the AutoWikiBrowser page on that wiki to learn how to register to use the software. GoingBatty (talk) 17:01, 14 July 2014 (UTC)

Request

Portal:Nautical is, at the present time, appearing in several articlespace categories which it shouldn't be. I recognize that the categories are being transcluded onto the page by the "Article of the Day", Joseph Yale Resnick, but they're not supposed to be there and I can't figure out how to get them off. Can anybody assist in fixing this? Thanks. Bearcat (talk) 02:15, 13 July 2014 (UTC)

  •   Done. For future reference, before you transclude the article of the day, you need to enclose the categories on that page in <noinclude>...</noinclude> tags. VanIsaacWScont 02:39, 13 July 2014 (UTC)
  • The problem is that the selected article pages redirect to the articles and these will need fixing for every "article of the day"; some (such as Portal:Nautical/July/25/Selected article) also contain non-free images, which should only be used in articles. Peter James (talk) 10:37, 13 July 2014 (UTC)
Perhaps this could be solved through creative use of {{suppress categories}}? — Mr. Stradivarius ♪ talk ♪ 15:36, 13 July 2014 (UTC)
Portals don't normally display the whole of their selected article, just a two or three paragraph "taster" from the article's lead section. -- John of Reading (talk) 17:11, 14 July 2014 (UTC)

Wikipedia:* namespace: documentation, permissions, comments… what a mess

I feel that the Wikipedia:* namespace is holding too much, which

  • makes it more difficult for me to look up my past contributions in my contributions history, and
  • makes page names harder to maintain or remember (with the '/' in the name).

I would like to suggest that new namespaces are added. To make things easier to discuss, I've added subsections below. --Gryllida (talk) 11:16, 13 July 2014 (UTC)

I think that VPT may be the wrong venue for such a proposal and discussion. – Jonesey95 (talk) 15:23, 13 July 2014 (UTC)
Moved to User:Gryllida/WikipediaNamespace. --Gryllida (talk) 11:25, 14 July 2014 (UTC)

Language tool updates not showing up in list

Tracked in Phabricator
Task T69991

I tried out the WMF labs Language Tool and was surprised not to see the changes on my watchlist. By default, the changes are marked 'minor'. Might this be the reason these assisted changes did not show up? --Ancheta Wis   (talk | contribs) 12:56, 13 July 2014 (UTC)

Visibility of edits in watchlists is very sensitive to the settings at Preferences → Watchlist. To see all, you should enable "Expand watchlist to show all changes, not just the most recent" and disable the five from "Hide minor edits from the watchlist" through "Hide edits by logged in users from the watchlist" inclusive. Then, you also need to ensure that you actually watched the pages in question: I have "Add pages and files I edit to my watchlist" selected too, as an aide memoire. --Redrose64 (talk) 13:36, 13 July 2014 (UTC)
Thank you. I incorporated your suggestions in my preferences. Then I will try LanguageTool again on another article. --Ancheta Wis   (talk | contribs) 14:11, 13 July 2014 (UTC)
Well, at least it's consistent. The processes do show up under my contributions, so I should use that instead of the watchlist as a sanity check. Maybe there is a time lag, or maybe a process which is hosted on the LanguageTool server just isn't set up to spoof the ownership of a personal watchlist. That is probably a good thing. Yeah, I support the privacy of my watchlist token! --Ancheta Wis   (talk | contribs) 14:46, 13 July 2014 (UTC)

I found the bug: when I run LanguageTool, it removes the article from the contributor's watchlist. I had to visit the articles I touched to fix this. --Ancheta Wis   (talk | contribs) 03:43, 14 July 2014 (UTC)

@Ancheta Wis: If you use it on a page that you're not watching, and you have "Add pages and files I edit to my watchlist" enabled, and the tool doesn't cause the page to be watched, that's a minor bug. But if you use it on a page that you're already watching, and the tool causes the page to become unwatched, then (regardless of the setting of "Add pages and files I edit to my watchlist") that's a major bug and should be reported. --Redrose64 (talk) 06:43, 14 July 2014 (UTC)
@Redrose64: Yes, the tool causes the page to become unwatched. I unchecked "Add pages and files I edit to my watchlist". I selected an article on my watchlist, and ran languagetool wikicheck (merely clicking 'submit changes to wikipedia', without selecting any copyedits, generates an edit page to submit. Clicking save with no changes will clear the blue star). The article is now unwatched. It is no longer on my watchlist either. The article has to trigger rules to list suggested copyedits. Examples formerly on my list were Putamen, Therapeutic food, and Grammatical Framework.
So there are several configurations that I checked, including pages that I'm already watching, with the repeatable result that running LanguageTool on the examples removed them from my watchlist.
One way to run the tool is: go to an article|view history | revision history statistics| languagetool wikicheck| 'submit changes to wikipedia', without selecting any copyedits| this generates an edit page to submit | save with no changes |this will clear the blue star. --Ancheta Wis   (talk | contribs) 12:10, 14 July 2014 (UTC)
That's clearly a bug; it should be reported. I don't see a link concerned with bug reporting, but upper right there's a link Imprint, which seems to go to the website for the product itself. There should be a help/support page in there. --Redrose64 (talk) 15:03, 14 July 2014 (UTC)
I put it in as bugzilla:67991 --Ancheta Wis   (talk | contribs) 15:33, 14 July 2014 (UTC)
Thanks for reporting. I just informed Dnaber who is the maintainer of the LanguageTool. I assume he'll leave a reply soon.
Btw. if you use XTools Gadget - it queries LanguageTool (and others) and merely uses its results, performs an on-the-fly-check (Syntax, Grammar, Wikidata) in ~ 1 sec and provides an access to all the results. If you edit it from there, the bug does not apply. But no matter how you use it (either embedded or as stand alone app) it's a great tool. I'll care about the bz ticket while Dnaber fixes the bug. --Hedonil (talk) 19:01, 14 July 2014 (UTC)

Tech News: 2014-29

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

Recent software changes

  • The latest version of MediaWiki (1.24wmf13) was added to test wikis and MediaWiki.org on July 10. It will be added to non-Wikipedia wikis on July 15, and to all Wikipedias on July 17 (calendar).
  • It is now possible to globally rename global (SUL) users. Please go to the username changes page on Meta if you want to rename your account on all wikis. [12] [13]
  • You can now read a summary of the Wikimedia technical report for June 2014.
  • You can now read the latest issue of the Wikidata newsletter and translate it into your language.

VisualEditor news

  • The tool to add templates and citations will now work for templates that include HTML comments or templates in their titles. [14] [15]
  • The button to make images full size should now work correctly. [16] [17] [18]
  • References will now be shown in the default font size again. [19]

Future software changes

  • CirrusSearch will be enabled as the primary search method on the Dutch (nl) and Japanese (ja) Wikipedias on July 14, and on the Polish (pl) and Russian (ru) Wikipedias on July 16. [20]
  • The Special:Version page will soon show the exact version of MediaWiki and all extensions installed on your wiki (example). [21] [22]
  • It will soon no longer be possible to order printed books of wiki articles via PediaPress. You will still be able to create PDF files. [23]
  • Pages that use {{DISPLAYTITLE:''title''}} more than once will soon show a warning. You can use {{DISPLAYTITLE:''title''|noerror}} to hide it. [24] [25]
  • Pages that have the list of references added automatically will soon be added to a tracking category. Administrators will be able to configure the name of the category on their wikis. [26] [27]
  • Administrators will soon be able to easily merge histories of two pages using Special:MergeHistory. [28] [29]
  • Administrators will soon see links to delete files on Special:ListFiles. [30]

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

07:49, 14 July 2014 (UTC)

Broken-link footnote

I have tried to repair a broken-link footnote in Islamic State of Iraq and the Levant, but have been blocked when trying to save the edit with the new link. I could not find the web address on the Wayback machine, CiteWeb or any of the other archive services mentioned in the Wiki help on this, but found it via Google under the archive service "archive.today". Is this archive linked to "archive.is", about which I understand there are or have been problems? If not, why am I being blocked? --P123ct1 (talk) 12:38, 14 July 2014 (UTC)

archive.today is an alias of archive.is.—Kww(talk) 13:30, 14 July 2014 (UTC)

Template question

I am trying to fix a template, but so far, not succeeding. I have a specific question about a specific instance of the template, but the existing approach seems like a kludge, so I'd like to propose a better solution, which would require help from someone with real template expertise.

Specific issue The infobox of 2014–15 UMass Minutewomen basketball team has the title "2014–15 UMass Minutewomen women's basketball"/. The desire is to have the title "2014–15 UMass Minutewomen basketball". I thought I fixed it with an edit to Template:Infobox NCAA team season/name/sandbox. Oh duh, that's the sandbox. So maybe I simply need to copy the result into the main template. I'll try that, but I'll ask about the general issue below.

General issue The specific template to make this change is buried inside other templates, so whenever a change is needed, it takes some time to recall exactly how everything fits together. The goal, in case it isn't obvious, is to include the word "men's" as a default, include the word "women's" when sex=women, but use neither if the team name indicate the sex of the team, such as in this case. However, the approach is to use a nested set of searches for the unique set of words that identify when the descriptor should be omitted. This is already complicated, and is likely to get worse.

I think it would be better to do the following:

  • If sex = men, or blank use "men's"
  • If Sex =women, use "women's"
  • If sex=none omit word.

Wouldn't that be far easier? Plus, if some team changes their name, it means we would not have to rewrite the template, but simply change the parameter.

One complication is that the word choice is not simply driven by the sex parameter, but also the sport parameter. I'm not quite sure what happens if they conflict.

Is there someone familiar with template usage who would be willing to help me make this change, if it makes sense?--S Philbrick(Talk) 13:29, 14 July 2014 (UTC)

  • Sphilbrick, I've looked over this mess of spaghetti code in the past, and I'm thinking it would be best to go over to WP:LUA/R and request a single module be made that does what you want without the rat's nest of various templates. What you really need is a simple regex filter and the best way to do that is with Lua. — {{U|Technical 13}} (e • t • c) 15:02, 14 July 2014 (UTC)
Thanks. I'll see if I can work on some specs.--S Philbrick(Talk) 15:23, 14 July 2014 (UTC)

Talk page references

Recently a reflist showed up on Talk:Syrian Civil War and Talk:August 2013 Rabaa Massacre and there is no code or diff for that. I have no objection to having a reflist on a talk page, but the way it stands might confuse the editors, so I think something should be done to separate it from the discussion. Fitzcarmalan (talk) 16:14, 14 July 2014 (UTC)

Fixed. FunkMonk (talk) 16:26, 14 July 2014 (UTC)
See #Missing reference markup will no longer show an error & T68860. --Glaisher (talk) 16:28, 14 July 2014 (UTC)

ProveIt

Is there a way to disable the "(edited with ProveIt)" tag next to my edit summaries? I went to the teahouse but apparently no one there was able to help. The only way to stop this, as far as I know, is by previewing my edits first, then remove it. But most of the time I forget to do so. Fitzcarmalan (talk) 16:21, 14 July 2014 (UTC)

@Fitzcarmalan: Follow the instructions at [31] 'Edit Summary Message' section. --Glaisher (talk) 16:38, 14 July 2014 (UTC)

References appearing in the wrong place

Someone added 3 references to User talk:Ebyabe#Wesley then I added a new section and the references moved to my section when I created it. Blackbombchu (talk) 23:49, 14 July 2014 (UTC)

See #Missing reference markup will no longer show an error . --  Gadget850 talk 00:49, 15 July 2014 (UTC)
Fixed?. Helder.wiki 00:51, 15 July 2014 (UTC)

Requests for Arbitration

(copied from Commons) Statements regarding the fate of Media Viewer and the role assumed by various individuals on the WFM project team have been and continue to be presented to the Arbitration Committee. -- Gwillhickers (talk) 02:25, 13 July 2014 (UTC)

Note, that is the English Wikipedia's ArbCom. -Pete F (talk) 04:06, 14 July 2014 (UTC)
N.b.: This section was copied to this page by Gwillhickers at 16:19, 14 July 2014 (UTC). Graham87 08:01, 15 July 2014 (UTC)

Closed AFDs not displaying on mobile version

AFDs that have been closed using class="boilerplate metadata vfd" in the div are not displaying on the mobile version. Example Wikipedia:Articles_for_deletion/Tube_Bar_prank_calls. The class used in {{Afd top}} is "boilerplate afd vfd xfd-closed" and these display ok. Anybody got any idea what it is about the former class that causes it not to display? SpinningSpark 02:13, 24 June 2014 (UTC)

probably it's the metadata class. That's stuff that should be hidden in the content namespace, but perhaps mobile has an overly 'active' implementation of it. There are 2 solutions, remove that class, or fix mobile :) —TheDJ (talk • contribs) 05:30, 24 June 2014 (UTC)
It's the metadata class, and a related matter has come up before, see Wikipedia:Village pump (technical)/Archive 116#CfDs in mobile view - there is much related detail at Wikipedia:Village pump (technical)/Archive 116#'Listen' template not rendering in mobile view. There were one or two related threads, see for example Wikipedia:Village pump (technical)/Archive 119#Wikipedia mobile page have a bug for sister project links. --Redrose64 (talk) 09:25, 24 June 2014 (UTC)
So is this something that should be raised on bugzilla? I could ask for a bot to change all the templates in the archive, but this does not seem like the right approach. We can never be sure we have found all the entities generating that class. SpinningSpark 15:43, 24 June 2014 (UTC)
Bugzilla is only for things that we can't fix ourselves. We have two possible approaches here: either remove the metadata class from {{afd top}} or modify the relevant rule in whichever CSS file is setting a rule like 
.metadata { display: none; }
I think that altering none to block whilst being the "obvious" thing to do would unhide things that should remain hidden. If we choose the first approach - which has, in fact, already been done - we need to do something about those AfDs closed prior to that modification, perhaps send in a bot to remove the metadata class. --Redrose64 (talk) 16:06, 24 June 2014 (UTC)
Yeah, I thought that would be the answer on Bugzilla, just checking. Are you sure that my example was created with {{afd top}}? It does not have the template name in hidden text as more recent ones do. If we are sure that there is nothing currently creating this class, then yes, a bot would be the solution. SpinningSpark 17:00, 24 June 2014 (UTC)
  • If you can get me a list of pages, I can run through once with AWB and remove the "metadata" classes. — {{U|Technical 13}} (e • t • c) 20:01, 24 June 2014 (UTC)
  • @Technical 13: The pages that need checking should all be in the following searches:
Update: My request for T13bot has been   Approved for trial (175 edits or 10 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. by Xaosflux. I'll complete his request for 25 trials in each prefix tomorrow. (bed time for me here). — {{U|Technical 13}} (e • t • c) 01:34, 25 June 2014 (UTC)
Initial trial run has completed, if anyone has any comments, please bring them to Wikipedia:Bots/Requests for approval/T13bot. Thank you, — xaosflux Talk 00:20, 26 June 2014 (UTC)
Update
Spinningspark — TheDJ — Redrose64 — Xaosflux: I completed an initial pass this morning to remove this class from pages and decided to build a new list and see if there were any "new" instances still being created and apparently there are. The templates used on "Wikipedia:Categories for discussion", "Wikipedia:Possibly unfree files", "Wikipedia:Files for deletion", and "Wikipedia:Templates for discussion" are still adding this unwanted class. If someone wants to ping me when that is fixed, then I'll happily run the bot for one more pass to clean up the stragglers and it should be done. — {{U|Technical 13}} (e • t • c) 20:25, 11 July 2014 (UTC)
All the other {Xfd top} templates still contain the metadata class. They will need to be removed as well. -- [[User:Edokter]] {{talk}} 10:08, 12 July 2014 (UTC)
Templates are clear now, only TfD still has metadata. Is it possible some automated tool injects its own template code instead of using the template source? -- [[User:Edokter]] {{talk}} 10:24, 12 July 2014 (UTC)
@Technical 13 and Anomie: T13bot and AnomieBOT are edit warring over the metadata class on TfD pages: see here, for example. — Mr. Stradivarius ♪ talk ♪ 23:35, 15 July 2014 (UTC)

Wikipedia:List of Wikipedians by number of edits not updating

Wikipedia:List of Wikipedians by number of edits is supposed to update weekly, but it is now 17 days old. When will this be fixed for the editcountitis sufferers? -- Djembayz (talk) 11:51, 12 July 2014 (UTC)

@Djembayz: - It appears the question has been asked at User talk:MZMcBride#BernsteinBot, with no response yet. GoingBatty (talk) 12:21, 12 July 2014 (UTC)
Like some other reports, it hasn't run since end of June. I guess that MZMcBride (talk · contribs) hasn't finished moving all the reports from Toolserver to Labs. --Redrose64 (talk) 20:43, 12 July 2014 (UTC)
Finished? I'm not sure I've even started. :-( --MZMcBride (talk) 03:32, 16 July 2014 (UTC)

How to disable image "lightbox" effect, permanently?

See subject. If this is discussed elsewhere, please point me to it. Thanks. ―cobaltcigs 22:52, 13 July 2014 (UTC)

@Cobaltcigs: Open it, scroll down, then click "Disable Media Viewer" at the very bottom. Matma Rex talk 23:08, 13 July 2014 (UTC)
Oh, thanks. I didn't see that before as I didn't realize scrolling on this pseudo-screen was even possible. Got it. ―cobaltcigs 23:21, 13 July 2014 (UTC)

Is there some option (global preferences or some javascript code) to disable the Media Viewer on all wikis? --Edgars2007 (talk/contribs) 12:07, 14 July 2014 (UTC)

@Edgars2007: You can add 
mw.config.set("wgMediaViewerOnClick", false);
to m:User:Edgars2007/global.js and it would be disabled on all wikis where your global.js is loaded by local common.js or skin.js. --Glaisher (talk) 12:19, 14 July 2014 (UTC)
@Glaisher: So I need to have User:Edgars2007/common.js on every wiki? Hm, it is almost the same as I would check the preferences section on every wiki (for this time) as I don't have very much wikis, where I have my local js page, but I use several wikis. Ok, what could be the smallest piece of code that I have to include in my local js code pages (I can't left them blank, right?)? BTW, maybe I could enable Monobook and the old toolbar in this way (by adding some piece of code in js page @meta)? --Edgars2007 (talk/contribs) 12:52, 14 July 2014 (UTC)
Edgars2007: you can wait for the installation of GlobalCssJs extension on all WMF wikis (Legoktm might know what is the status on that). Or, if you want to create the JS pages, you can use this on each wiki:
mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Edgars2007/global.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400');
and create the global.js page with the code suggested by Glaisher above (which I didn't test). Helder.wiki 14:14, 14 July 2014 (UTC)
Re: GlobalCssJs, we're waiting on some code review in core right now. Legoktm (talk) 18:44, 14 July 2014 (UTC)
@Edgars2007: you can blank out a .js page, that's OK. If you would prefer it to contain something that does nothing, blank it out and add a comment line, like this: 
/* Do nothing */
You can request speedy deletion (on English Wikipedia at least) by tagging it {{db-userreq}} or {{db-author}} --Redrose64 (talk) 19:31, 14 July 2014 (UTC)

Another alternative: 

// ==UserScript==
// @name        Disable MediaViewer
// @namespace   http://myveryowntools
// @description Disables Wikimedia MediaViewer
// @match	    *://*.wikipedia.org/*
// @match	    *://*.wikimedia.org/*
// @match	    *://*.wikidata.org/*
// @run-at 		document-end
// @version     1.0
// @grant       none
// ==/UserScript==
var code = 'mw.config.set("wgMediaViewerOnClick", false);';

var script = document.createElement('script');
script.textContent = code;
(document.head||document.documentElement).appendChild(script);
script.parentNode.removeChild(script);
  • save this snippet to file <something>.user.js (.user.js is important)
  • Chrome/Chromium: Settings -> Tools -> Extensions. just drag & drop the file.
  • Mozilla: (You need Greasemonkey) open blank page in browser -> drag & drop the file
  • Advantages:
  1. all projects included
  2. quickly toggle the things on/off without editing your common.js
  3. removed and newly installed in seconds
  4. works even if logged out

Beat me, if it doesn't work ;) --Hedonil (talk) 20:05, 14 July 2014 (UTC)

Thanks for the information, I was wondering how to turn that off[32]. Chillum 20:10, 14 July 2014 (UTC)
From what I hear, global prefs settings won't be worked on until WP:SUL is finalized, which will probably be in the first part of 2015 (subject to change without warning). WhatamIdoing (talk) 02:31, 16 July 2014 (UTC)

searching for articles with titles containing dashes

When searching for articles where the title contains a dash (e.g. 2013–14 Wolverhampton Wanderers F.C. season) but you type the article name in manually using a minus sign rather than a dash (e.g. 2013-14 Wolverhampton Wanderers F.C. season) the article doesn't appear anywhere near the top of the search list despite the fact that there is only one letter different in the search string. This ([33]) is the search with the dash and this ([34]) is the search with the minus sign. One solution is to create a redirect but surely the search tool could be a little more intelligent when most users don't notice the difference between the minus and the dash and keyboards don't include the dash. — Preceding unsigned comment added by Spudgfsh (talk • contribs) 20:43, 15 July 2014 (UTC)

Well I thought that making the redirect with hyphen to n-dash was almost compulsory. Since you are using this as a search failure I won't fix it though! SHould have a word to the article creator though. Graeme Bartlett (talk) 21:27, 15 July 2014 (UTC)

Sigh. People will eventually recognize the wisdom of WP:Short horizontal line. Think there's any chance of making it official policy?—Kww(talk) 14:14, 16 July 2014 (UTC)

This is fixed with the new search that is currently available as a Beta option. That will launch within the next month as default for everyone, so this problem shouldn't exist very long anymore. —TheDJ (talk • contribs) 15:11, 16 July 2014 (UTC)

Automated notification of discretionary sanctions

never mind. Beeblebrox (talk) 23:53, 16 July 2014 (UTC)

I just had what might be a brilliant idea. Before trying to get consensus for it I would like to discuss the technical feasibility of it.

Often, users are offended at being informed that they are editing in an area that is subject to discretionary sanctions placed by an arbcom decision. A large part of the reason for this is seems to be that a specific user, usually another person editing in the same area, is the one that alerts them to the fact that they are in a sanctioned area. Really, an alert of DS is more like a warning sign on a highway. It is there to alert you to the presence of a hazard, not to criticize you specifically. People don't usually get angry and feel judged by road signs.

So, I suppose you can see where I am going with this: how complicated would it be to design and implement some sort of system that would automatically alert a user that they are editing in area that is subject to discretionary sanctions? Given some of the bot wizardry I've seen here I suspect this would be fairly simple, but not being technically minded I am aware of my own ignorance of exactly how this stuff works.

Features desired would include:

  • Automatic user talk page notification to any user who edits an article subject to discretionary sanctions
  • Link to the specific case that authorized the sanctions (using Template:Ds/alert)
  • No more than one notification per case every 12 months (DS alerts are considered expired after 12 months from date of issue)

There is already an edit filter that automatically logs each use of the proscribed template, presumably whatever bot or script did this could consult with it somehow. Reminder: All that is being looked for right now is preliminary information on how difficult this would be to implement, not a discussion of whether or not it is actually a good idea. (that'll come next at some other forum) Thanks in advance, Beeblebrox (talk) 20:52, 16 July 2014 (UTC)

I've just been informed that over a year of discussion and testing has already taken place on this topic, and the idea was rejected. I therefore withdraw this as probably unworkable. Beeblebrox (talk) 23:53, 16 July 2014 (UTC)

Asking anonymous editors to sign up

This is a quick announcement that we've enabled a test of a new feature which asks anonymous editors to sign up for an account. This A/B test will last for one week from today.

If you're interested, a specification of the new interface to view, including screenshots. There's also a specification for the previous interface we tested, and you can check out our data analysis. If you want to test this out for yourself, I'd recommend viewing our beta testing wiki in an incognito browser (you may have try a couple times, since it's fully randomized).

If you remember the previous thread about this, I should note that we fixed a bug which caused the popup to appear every time someone attempted to edit anonymously. It now only shows once per user.

If you're curious about why we're testing these changes, I'd recommend reading our blog post. Please ping me if you have any more questions, Steven Walling (WMF) • talk 00:17, 10 July 2014 (UTC)

Have we ever tried a campaign along the lines of "You know... you're more anonymous when your IP address is hidden behind a pseudonym... just sayin'."? - Floydian τ ¢ 01:11, 10 July 2014 (UTC)
Not yet, but we have definitely considered it. Right now, we're trying to keep the amount of text in the call to action small. A sentence or two is really not quite enough to explain the dichotomy correctly. However, in a larger version like this one we tested last time could easily include this kind of information. For now, a large part of what we're hinging on is the assumption that there are a large number of people who would be willing to sign up if we say it's recommended and doesn't require personal information . So far, it seems to be working. Steven Walling (WMF) • talk 01:41, 10 July 2014 (UTC)
As a (non registered) contributor that just encountered this popup dialog on clicking edit, I have to say I'm not a fan. I'm having a read through of the various meta and mw pages about it now. Cheers, 91.125.182.5 (talk) 03:05, 10 July 2014 (UTC)
Hi there. So, since you had the experience to know where the Village Pump was/what it's for and post with the correct wiki markup for talk pages and sign your post, I'm going to assume you're the kind of person who is pretty experienced as an editor. If that's the case, yes, it's true that this interface isn't really designed for you. We do want to make sure that we're not impeding or annoying folks like yourself, who are aware of the tradeoffs and choose to be anonymous. That's why we're only showing the invitation to sign up once now. We're going to keep testing this, and measuring if we have any negative impact on the volume of contributions from unregistered editors like yourself. Steven Walling (WMF) • talk 04:02, 10 July 2014 (UTC)
And to add to that, as an experienced but anonymous editor, what do you feel is the hurdle to having an account to organize your contributions and carve an identity within the editor community? - Floydian τ ¢ 20:09, 12 July 2014 (UTC)

Update: we've turned off the test now, so you should stop getting any signup invitations when anonymous, except for the odd caching issue. For the curious, results of the test will be posted here. Steven Walling (WMF) • talk 23:50, 17 July 2014 (UTC)

Why is the edit summary maximum length so low?!

See the section title. I think the max length should be about twice as long as it currently is. Every time I couldn't fit everything I wanted to say in an edit summary, it would have fit if the max limit was twice as high as it is now. Where is this limit actually specified anyway? Dustin (talk) 17:13, 12 July 2014 (UTC)

Because bad technical decisions made ten years ago are hard to change when you have terabytes of data. See T6715. The current limit is 255 bytes, which means at most 255 characters (fewer is you use non-ASCII ones). Matma Rex talk 17:43, 12 July 2014 (UTC)
Okay, thanks for responding. I know that space is extremely high in terms of availability so isn't a significant issue, and that is the reason for which I brought up my inquiry here. Hopefully, they will be able to up the limit at some point. Dustin (talk) 17:47, 12 July 2014 (UTC)
Still more than twitter :-P. — Dispenser 17:51, 12 July 2014 (UTC)
Well, that's a big reason for which I don't use twitter.   Dustin (talk) 17:52, 12 July 2014 (UTC)
FYI the current length is about twice what it was when I started editing in '05. Dustin V. S. please note that, if you want to explain an edit in more detail, you can always post a message about said edit on the talk page of the article. The message can include a link to the specific edit. You may already be aware of this but I thought I would mention it just in case. Cheers. MarnetteD|Talk 18:12, 12 July 2014 (UTC)
That is what I currently do, but like I said, the length should be doubled in my opinion because at that higher limit, I don't believe that I would ever run out of space anymore. Dustin (talk) 18:17, 12 July 2014 (UTC)
You're looking at this from a pretty Anglophone perspective :) The limit counts bytes, which means that due to the behavior of the UTF-8 encoding (which is used internally for all text by MediaWiki) the actual character limit is up to four times lower in other languages: while Latin letters a-z count for one byte each, most of their variants with diacritic accents count for two bytes (which is a major problem for, say, Vietnamese), characters in Russian or Greek alphabets count for two bytes each too (and Russians words are longer than English equivalent in general), and I'm not sure what is the exact behavior for Japanese or Chinese, but it definitely limits the length a lot (it's harder to compare directly to English, as the languages are very different). I don't think any length extension would be satisfying for everyone until the length is practically unbounded (like the length of articles, which are currently limited to a bit over two million bytes each). Matma Rex talk 18:34, 12 July 2014 (UTC)
See Help:Edit summary#The 250 character limit. Somewhere I have information on when it was changed from 200 characters to 250, and then to 255 bytes. Both increases were possible because 255 bytes had already been designated for storage of the edit summary, but the text input window was set to a lower max length, so unless you used tricks like MediaWiki:Gadget-LongEditSummaries.js (which allowed 250 characters to be input instead of 200), there was always 50 bytes or more of unused space for each edit. All that was necessary was to adjust that max input length, but this means that there is no longer any unused space that we can expand into. --Redrose64 (talk) 20:52, 12 July 2014 (UTC)
Where in the code was the maximum set to 255 bytes in the first place? Dustin (talk) 21:02, 12 July 2014 (UTC)
The database field for edit summaries is 255 bytes long: [35] (MySQL's tinyblob field used here is 255 bytes long, as stated here: [36] in a very roundabout way). The value of '255' is repeated in a few other places, for example here [37]. Matma Rex talk 21:10, 12 July 2014 (UTC)
I believe that the question is "Why was the database field made so small?" The answer to "Why can't my edit summary be larger than the database field?" is pretty obvious. WhatamIdoing (talk) 21:33, 12 July 2014 (UTC)

I very much agree we need more characters, often important information is left out of summaries because it does not fit

That being said I understand what is involved in changing the database schema of a table that has millions of entries and is replicated over many servers. It would require extensive downtime.

Though, there is nothing preventing a new table from being made to that the software will begin to use. An revision ID can be hard coded so the software knows to use the old table for any rev before that and the new one for all after.

An alternative to using a special rev as a border would be to put a special character in the old table(something that is not allowed in edit summaries) that tells the software to look in the new table to the longer summary. This would mean that regular sized edit summaries would be treated normal, and only long edit summaries would require a second lookup and take longer.

With a bit a creativity there is no reason we can't manage larger edit summaries. Chillum 21:43, 12 July 2014 (UTC)

@WhatamIdoing: I think "Why was the database field made so small?" best summarizes part of my inquiry. Dustin (talk) 21:55, 12 July 2014 (UTC)

I'm ok with current field length, it's really up to you to summarise in a couple words so that it's not hard to follow an article history. Longer edit summaries would make it harder to follow (with my screen size even now many edit summaries do not fit one line in the history tab). --Gryllida (talk) 11:35, 13 July 2014 (UTC)

  • Brevity is the soul of wit, and the essence of lingerie. We already have way too many editors that attempt to communicate context via edit summaries, it is a pet peeve that annoys me to no end. The field is only supposed to be for a quick, brief communication to the project regarding the nature of your edit; if you're consistently bumping up against the 255 limit, then you're doing it wrong. Tarc (talk) 12:26, 13 July 2014 (UTC)
    • The primary case where it is an issue for me is reverting an edit, since much of the limit is taken up by the wiki text pointing to the edit being reverted. isaacl (talk) 00:00, 15 July 2014 (UTC)
      • You can delete that text if you like, though. It isn't mandatory, it's just there for the people who would otherwise leave an edit summary blank. Tarc (talk) 00:01, 15 July 2014 (UTC)
        • Generally to make it clear what was reverted, I prefer to keep this text in place. isaacl (talk) 01:41, 15 July 2014 (UTC)

"Why was the database field made so small?" well... because someone thought it would be enough. Much alike 640K for ram, or 4.2 billion of Interernet addresses. —TheDJ (talk • contribs) 14:28, 13 July 2014 (UTC)

That, and the next size up would have been 65535 bytes, an awful lot for a summary. Most Wikipedia pages have less than 64K of content. --Redrose64 (talk) 14:36, 13 July 2014 (UTC)

I think everyone misunderstood that bug: performing a schema change even on tables as large as revision is a PITA but doable, and was done before, so it's not the reason why the change was repeatedly turned down by DBAs. The problem is that WMF uses a custom covering index on every column of revision table which means that the total size of a row is restricted by MariaDB/MySQL's index limit. As a result, increasing rev_comment substaintially would require a drop of that index which will result in IO skyrocketing on MariaDB servers, affecting site performance. Max Semenik (talk) 23:14, 14 July 2014 (UTC)

  • Apart from the interesting technical explanations, the fundamental point is that substantially increasing the available space for edit summaries would lead to bloat and hard-to-read histories. Some editors paste their comment into the edit summary which would be unhelpful if it weren't truncated to something reasonable. Other editors are inclined to put advanced reasoning into an edit summary, but anything longer than 255 bytes needs to be on the talk page—there should not be anything to encourage "discussion by edit summary". Johnuniq (talk) 01:55, 15 July 2014 (UTC)
Dustin, please see Wikipedia:Shortcut.—Wavelength (talk) 02:09, 15 July 2014 (UTC)
Sometimes though, the short limit messes up auto-generated edit summaries, including edit summaries by bots which might have required something more like 300 bytes of space. Dustin (talk) 02:12, 15 July 2014 (UTC)
Here is an example of a cut-off edit summary. Dustin (talk) 02:16, 15 July 2014 (UTC)
Many operators of automated editors welcome feedback.—Wavelength (talk) 02:22, 15 July 2014 (UTC)
Dustin, I have started three shortcut pages specifically for use in long automated edit summaries: (RPVB), (TVB), (FP?).
—Wavelength (talk) 03:24, 17 July 2014 (UTC)
And I nominated them all for speedy deletion. This type of thing does not belong in article space. See the note on your talk page. Oiyarbepsy (talk) 03:27, 17 July 2014 (UTC)
At least in the case of summaries with links, the limit should be based on the number of displayed characters instead of the number of characters of code used to produce the links (e.g. "[[Special:Contribs/LongUsername|edits]]" should count as 5 characters, since this is what will appear in the history/watchlists/recent changes). Helder.wiki 02:38, 15 July 2014 (UTC)
Agreed. Dustin (talk) 03:49, 15 July 2014 (UTC)
@Helder.wiki and Dustin V. S.: The limit could be based on the number of displayed characters, but then we would have the problem that if somebody entered close to 255 displayable characters, some of which was linked, then the edit summary as stored would be shorter, since it would still be cut off after 255 bytes of Wiki markup. This is because the link still needs to be stored, and as noted above, there are no more than 255 bytes to store the whole of the edit summary, markup included. If you really want 255 displayed characters, you need to exclude all markup from your edit summary.
When space is a premium, use abbreviations; if you need to link, use WP:SHORTCUTs. --Redrose64 (talk) 09:53, 15 July 2014 (UTC)
What I mean is that in order to avoid "bloat[ed] and hard-to-read histories" the limit should not be in the size of the wiki markup, but in the size of the text which will be visible to other users after parsing that markup. There needs to be a limit on the amount of wiki markup, but that needs to be bigger than the limit of visible text. Helder.wiki 12:54, 15 July 2014 (UTC)
It is not practical to increase the amount of space available to wiki markup. Therefore, if the space available to wiki markup cannot be increased above 255 bytes, the space available for display needs to be decreased from 255 single-byte characters. I don't think that would gain favour. If the edit summary that you want to use won't fit in the available space, even after using WP:SHORTCUTs and WP:ESL, put it on the talk page instead, with an edit summary like rewrote 6 paragraphs - see [[Talk:Foo#Rewritten paragraphs, 15 July 2014]] --Redrose64 (talk) 13:09, 15 July 2014 (UTC)

Solutions

Some solutions for shortening long summaries:

  1. When entering edit summaries, provide a "explain on talk" button - a user can enter as much text as they like, which appears on the talk page with an auto-generated heading, and an auto-generated edit summary saying see Talk#heading.
  2. Shorten ipv6 addresses in accordance with the standard ways of doing so. The wiki software should automatically shorten these IPs in accordance with the IPv6 standard which would make these usernames much shorter.
  3. Require abbreviated usernames - if a user picks a name with more than xx characters the software would require them to create an abbreviated version that could be used in edit summaries.

Not sure if all of these are good ideas or not, just brainstorming. Oiyarbepsy (talk) 05:51, 17 July 2014 (UTC)

Not sure whether this should be kept here or moved to the Idea Lab... My comments on each.
  1. Could this be created as a tool that someone could add? Also, if it is added to the standard code, I'd suggest it as something that could be set to on/off in preferences (default off)
  2. I think that would have to be done in the software that actually allows things like reverts, they fill in the summaries.
  3. Not sure on this, maybe they get the equivalent of a short URL to them (starting with something wierd like two LtoR markers) Naraht (talk) 14:46, 17 July 2014 (UTC)
Different wikis have different limits on the username length, and the usernames are (going to be) global. Helder.wiki 15:40, 17 July 2014 (UTC)

Pages slow and not loading properly

Recently (last two or three days), Wikipedia seems slow to load, and sometimes fails to load pages properly or at all. All other websites seem OK. Any known issues? 86.179.2.182 (talk) 17:39, 14 July 2014 (UTC)

I have something that started last night or this morning that might possibly be related to that. Under Windows 7 and Firefox 30.0 using MonoBook, certain Wikipied pages --such as AN, AN/I and this one -- never completely loads. The loading icon keeps circling and circling and "Read en.wikipedia.org" is displayed in the corner. I can read and edit the page, but some information appears to be missing - such as the info in the RFC/U box on AN/I. If I go to other pages, such as articles, after that, the icon keeps spinning, however if I exit Wikipedia and go directly to the article, they'll load completely.

Could this be a template that got munged in some way and is not loading? BMK (talk) 22:01, 14 July 2014 (UTC)

Tech savvy users are very welcome to use the Developer Tools of their web browser to check if there are specific resources loading slowly over their network. Also, do you face the same problem a) with a different browser and b) on a different network, in case you can test? --AKlapper (WMF) (talk) 23:05, 14 July 2014 (UTC)
@Beyond My Ken: this might be similar to Wikipedia:Village pump (technical)/Archive 127#Servers not serving, and not timing out either. --Redrose64 (talk) 23:15, 14 July 2014 (UTC)
@Redrose64 - Yes, that sounds like it might well be a related problem.
@AKlapper (WMF) - As far as I can tell, it doesn't occur with Chrome, Safari, Opera or IE. On Firefox, it only occurs when I'm logged in -- if I log out, the pages finish loading. (It didn't matter with the other browsers whether I was logged in or not.) I suppose that points to some problem between Firefox and my set-up (which hasn't changed at all for months)? BMK (talk) 01:32, 15 July 2014 (UTC)
Do you have any Firefox extensions installed? Does FF use any special proxy settings that other browsers don't have? Max Semenik (talk) 00:55, 16 July 2014 (UTC)
I don't believe I have any extensions, and I don't know about its proxy settings. Regardless, the phenomenon has stopped, without my making any changes. BMK (talk) 08:51, 17 July 2014 (UTC)

(OP) Wikipedia seems back to normal for me too now. Nothing I've done... 86.160.82.115 (talk) 20:32, 17 July 2014 (UTC)

Problem with tabs on main page

For some days now, a number of tabs at the top of the first page of each Wiki article have been appearing flapped forward, obscuring the text, and they cannot be shifted. Can this be fixed, please? --P123ct1 (talk) 09:33, 15 July 2014 (UTC)

Screenshot very welcome (as I wonder what the "first page of a Wiki article" is exactly). Also, which browser and which version do you use, and if you know, how wide is your screen in pixels? --AKlapper (WMF) (talk) 00:14, 16 July 2014 (UTC)
Also, which skin are you using? Vector? Monobook? (If you're not sure, it is probably Vector - you can check your preferences under "appearance"). Risker (talk) 00:21, 16 July 2014 (UTC)
@AKlapper (WMF): I did a screenshot, saved it, and when returning to the screen, the tabs had all gone back into the right place. Also, I've just noticed that the tab problem only occurs when I have the screen on "reduced size" (which I usually do), but disappears on "full screen". I use Vector and IE11, but have no idea about the screen width in pixels, though I suspect this is the problem. I can cure it now if it happens (by going into full screen mode on opening and then going to "reduced size") but it is odd that the problem has only been happening in the last week. I can't upload a copy of the screenshot (don't know how to) but the line of tabs from L to R at the top, on opening the article in "reduced" mode, were: Article (normal position. i.e. upright) - Talk (normal) - Read, Edit, History and Star, all dropped forward and down and obscuring the text beneath. --P123ct1 (talk) 14:15, 17 July 2014 (UTC)

Possible JS error in the DRN filing script

Could anyone check whether this bug report is anything that needs fixing? I'm not sure if this is a bug in MediaWiki:Gadget-DRN-wizard.js, a brief glitch in the API, or a false alarm. At any rate, the DRN script seems to be working for me on IE. (The report claims it isn't working in Firefox.) — Mr. Stradivarius ♪ talk ♪ 04:49, 17 July 2014 (UTC)

  • I'll look at it if you (or someone) can find steps to reproduce the error. Though "unknown error by API" looks like a potential caching or connection problem (see...well...I don't know the line number, but search for "API" in the code and you'll see it), which is what the script reports if it doesn't have a successful request and doesn't get an error code. Likely not a problem in the JS. Protonk (talk) 15:20, 17 July 2014 (UTC)

Substing a redirect

Is there a way to subst a redirect page? For example, if I try to subst State Route 10-Y (Virginia) into a page, what actually happens is that the redirect target - U.S. Route 19 in Virginia - gets substed. --NE2 02:31, 18 July 2014 (UTC)

What, exactly, would you like substing it to do? I seriously don't understand. Oiyarbepsy (talk) 03:24, 18 July 2014 (UTC)
I wouldn't think so. Consider wikitext like {{U|Example}}. If that is added to a page, it actually invokes {{User link}} because Template:U is a redirect to Template:User link. Likewise, {{subst:U|Example}} would do the same. I imagine you would need to edit the redirect page, then copy the wanted wikitext, then paste it wherever needed. Johnuniq (talk) 04:04, 18 July 2014 (UTC)
You could write a Lua module that gets the wikitext of the redirect page and then outputs that when the module is substituted. But before writing such a module I'd want to know what it was going to be used for; I can't think of a use for it that isn't satisfied by just editing the redirect page itself. — Mr. Stradivarius ♪ talk ♪ 04:24, 18 July 2014 (UTC)

The reason is for an AWB run to make redirects (in accordance with WP:USSH). For example, I can hack the regexes to create {{subst::State Route 10-Y (Virginia)}} on Virginia State Route 10-Y, but, as described, that doesn't work. The alternative is to simply create the redirect to State Route 10-Y (Virginia) and let one of the double redirect bots run through and fix them. --NE2 04:52, 18 July 2014 (UTC)

@NE2: That sounds like something that can be done through the API, but I'm not how well that kind of thing is supported in AWB. I seem to remember there's a feature that can hook through to outside scripts? At any rate, I've written a module for you, but it's in my pseudo-userspace because it probably shouldn't be used on any production pages. See Module:User:Mr. Stradivarius/pageSubster for the details. — Mr. Stradivarius ♪ talk ♪ 07:04, 18 July 2014 (UTC)
Thanks. You didn't have to do that :) --NE2 07:12, 18 July 2014 (UTC)
@NE2: No problem. If you decide to use it, test it using AWB on a non-existent page and let me know if you see the error message before you make the edit. If you don't see the error message, it's probably better that the module outputs nothing at all rather than throwing an error. — Mr. Stradivarius ♪ talk ♪ 07:16, 18 July 2014 (UTC)
Here's what the error message looks like. Don't worry - I've done the necessary checks to ensure that what I'm substing exists and is a redirect. --NE2 07:18, 18 July 2014 (UTC)
Fair enough. I've taken the error messages out anyway, though, in case anyone else uses it without making the proper checks. — Mr. Stradivarius ♪ talk ♪ 07:31, 18 July 2014 (UTC)

Asking anonymous editors to sign up

This is a quick announcement that we've enabled a test of a new feature which asks anonymous editors to sign up for an account. This A/B test will last for one week from today.

If you're interested, a specification of the new interface to view, including screenshots. There's also a specification for the previous interface we tested, and you can check out our data analysis. If you want to test this out for yourself, I'd recommend viewing our beta testing wiki in an incognito browser (you may have try a couple times, since it's fully randomized).

If you remember the previous thread about this, I should note that we fixed a bug which caused the popup to appear every time someone attempted to edit anonymously. It now only shows once per user.

If you're curious about why we're testing these changes, I'd recommend reading our blog post. Please ping me if you have any more questions, Steven Walling (WMF) • talk 00:17, 10 July 2014 (UTC)

Have we ever tried a campaign along the lines of "You know... you're more anonymous when your IP address is hidden behind a pseudonym... just sayin'."? - Floydian τ ¢ 01:11, 10 July 2014 (UTC)
Not yet, but we have definitely considered it. Right now, we're trying to keep the amount of text in the call to action small. A sentence or two is really not quite enough to explain the dichotomy correctly. However, in a larger version like this one we tested last time could easily include this kind of information. For now, a large part of what we're hinging on is the assumption that there are a large number of people who would be willing to sign up if we say it's recommended and doesn't require personal information . So far, it seems to be working. Steven Walling (WMF) • talk 01:41, 10 July 2014 (UTC)
As a (non registered) contributor that just encountered this popup dialog on clicking edit, I have to say I'm not a fan. I'm having a read through of the various meta and mw pages about it now. Cheers, 91.125.182.5 (talk) 03:05, 10 July 2014 (UTC)
Hi there. So, since you had the experience to know where the Village Pump was/what it's for and post with the correct wiki markup for talk pages and sign your post, I'm going to assume you're the kind of person who is pretty experienced as an editor. If that's the case, yes, it's true that this interface isn't really designed for you. We do want to make sure that we're not impeding or annoying folks like yourself, who are aware of the tradeoffs and choose to be anonymous. That's why we're only showing the invitation to sign up once now. We're going to keep testing this, and measuring if we have any negative impact on the volume of contributions from unregistered editors like yourself. Steven Walling (WMF) • talk 04:02, 10 July 2014 (UTC)
And to add to that, as an experienced but anonymous editor, what do you feel is the hurdle to having an account to organize your contributions and carve an identity within the editor community? - Floydian τ ¢ 20:09, 12 July 2014 (UTC)

Update: we've turned off the test now, so you should stop getting any signup invitations when anonymous, except for the odd caching issue. For the curious, results of the test will be posted here. Steven Walling (WMF) • talk 23:50, 17 July 2014 (UTC)

Why is the edit summary maximum length so low?!

See the section title. I think the max length should be about twice as long as it currently is. Every time I couldn't fit everything I wanted to say in an edit summary, it would have fit if the max limit was twice as high as it is now. Where is this limit actually specified anyway? Dustin (talk) 17:13, 12 July 2014 (UTC)

Because bad technical decisions made ten years ago are hard to change when you have terabytes of data. See T6715. The current limit is 255 bytes, which means at most 255 characters (fewer is you use non-ASCII ones). Matma Rex talk 17:43, 12 July 2014 (UTC)
Okay, thanks for responding. I know that space is extremely high in terms of availability so isn't a significant issue, and that is the reason for which I brought up my inquiry here. Hopefully, they will be able to up the limit at some point. Dustin (talk) 17:47, 12 July 2014 (UTC)
Still more than twitter :-P. — Dispenser 17:51, 12 July 2014 (UTC)
Well, that's a big reason for which I don't use twitter.   Dustin (talk) 17:52, 12 July 2014 (UTC)
FYI the current length is about twice what it was when I started editing in '05. Dustin V. S. please note that, if you want to explain an edit in more detail, you can always post a message about said edit on the talk page of the article. The message can include a link to the specific edit. You may already be aware of this but I thought I would mention it just in case. Cheers. MarnetteD|Talk 18:12, 12 July 2014 (UTC)
That is what I currently do, but like I said, the length should be doubled in my opinion because at that higher limit, I don't believe that I would ever run out of space anymore. Dustin (talk) 18:17, 12 July 2014 (UTC)
You're looking at this from a pretty Anglophone perspective :) The limit counts bytes, which means that due to the behavior of the UTF-8 encoding (which is used internally for all text by MediaWiki) the actual character limit is up to four times lower in other languages: while Latin letters a-z count for one byte each, most of their variants with diacritic accents count for two bytes (which is a major problem for, say, Vietnamese), characters in Russian or Greek alphabets count for two bytes each too (and Russians words are longer than English equivalent in general), and I'm not sure what is the exact behavior for Japanese or Chinese, but it definitely limits the length a lot (it's harder to compare directly to English, as the languages are very different). I don't think any length extension would be satisfying for everyone until the length is practically unbounded (like the length of articles, which are currently limited to a bit over two million bytes each). Matma Rex talk 18:34, 12 July 2014 (UTC)
See Help:Edit summary#The 250 character limit. Somewhere I have information on when it was changed from 200 characters to 250, and then to 255 bytes. Both increases were possible because 255 bytes had already been designated for storage of the edit summary, but the text input window was set to a lower max length, so unless you used tricks like MediaWiki:Gadget-LongEditSummaries.js (which allowed 250 characters to be input instead of 200), there was always 50 bytes or more of unused space for each edit. All that was necessary was to adjust that max input length, but this means that there is no longer any unused space that we can expand into. --Redrose64 (talk) 20:52, 12 July 2014 (UTC)
Where in the code was the maximum set to 255 bytes in the first place? Dustin (talk) 21:02, 12 July 2014 (UTC)
The database field for edit summaries is 255 bytes long: [38] (MySQL's tinyblob field used here is 255 bytes long, as stated here: [39] in a very roundabout way). The value of '255' is repeated in a few other places, for example here [40]. Matma Rex talk 21:10, 12 July 2014 (UTC)
I believe that the question is "Why was the database field made so small?" The answer to "Why can't my edit summary be larger than the database field?" is pretty obvious. WhatamIdoing (talk) 21:33, 12 July 2014 (UTC)

I very much agree we need more characters, often important information is left out of summaries because it does not fit

That being said I understand what is involved in changing the database schema of a table that has millions of entries and is replicated over many servers. It would require extensive downtime.

Though, there is nothing preventing a new table from being made to that the software will begin to use. An revision ID can be hard coded so the software knows to use the old table for any rev before that and the new one for all after.

An alternative to using a special rev as a border would be to put a special character in the old table(something that is not allowed in edit summaries) that tells the software to look in the new table to the longer summary. This would mean that regular sized edit summaries would be treated normal, and only long edit summaries would require a second lookup and take longer.

With a bit a creativity there is no reason we can't manage larger edit summaries. Chillum 21:43, 12 July 2014 (UTC)

@WhatamIdoing: I think "Why was the database field made so small?" best summarizes part of my inquiry. Dustin (talk) 21:55, 12 July 2014 (UTC)

I'm ok with current field length, it's really up to you to summarise in a couple words so that it's not hard to follow an article history. Longer edit summaries would make it harder to follow (with my screen size even now many edit summaries do not fit one line in the history tab). --Gryllida (talk) 11:35, 13 July 2014 (UTC)

  • Brevity is the soul of wit, and the essence of lingerie. We already have way too many editors that attempt to communicate context via edit summaries, it is a pet peeve that annoys me to no end. The field is only supposed to be for a quick, brief communication to the project regarding the nature of your edit; if you're consistently bumping up against the 255 limit, then you're doing it wrong. Tarc (talk) 12:26, 13 July 2014 (UTC)
    • The primary case where it is an issue for me is reverting an edit, since much of the limit is taken up by the wiki text pointing to the edit being reverted. isaacl (talk) 00:00, 15 July 2014 (UTC)
      • You can delete that text if you like, though. It isn't mandatory, it's just there for the people who would otherwise leave an edit summary blank. Tarc (talk) 00:01, 15 July 2014 (UTC)
        • Generally to make it clear what was reverted, I prefer to keep this text in place. isaacl (talk) 01:41, 15 July 2014 (UTC)

"Why was the database field made so small?" well... because someone thought it would be enough. Much alike 640K for ram, or 4.2 billion of Interernet addresses. —TheDJ (talk • contribs) 14:28, 13 July 2014 (UTC)

That, and the next size up would have been 65535 bytes, an awful lot for a summary. Most Wikipedia pages have less than 64K of content. --Redrose64 (talk) 14:36, 13 July 2014 (UTC)

I think everyone misunderstood that bug: performing a schema change even on tables as large as revision is a PITA but doable, and was done before, so it's not the reason why the change was repeatedly turned down by DBAs. The problem is that WMF uses a custom covering index on every column of revision table which means that the total size of a row is restricted by MariaDB/MySQL's index limit. As a result, increasing rev_comment substaintially would require a drop of that index which will result in IO skyrocketing on MariaDB servers, affecting site performance. Max Semenik (talk) 23:14, 14 July 2014 (UTC)

  • Apart from the interesting technical explanations, the fundamental point is that substantially increasing the available space for edit summaries would lead to bloat and hard-to-read histories. Some editors paste their comment into the edit summary which would be unhelpful if it weren't truncated to something reasonable. Other editors are inclined to put advanced reasoning into an edit summary, but anything longer than 255 bytes needs to be on the talk page—there should not be anything to encourage "discussion by edit summary". Johnuniq (talk) 01:55, 15 July 2014 (UTC)
Dustin, please see Wikipedia:Shortcut.—Wavelength (talk) 02:09, 15 July 2014 (UTC)
Sometimes though, the short limit messes up auto-generated edit summaries, including edit summaries by bots which might have required something more like 300 bytes of space. Dustin (talk) 02:12, 15 July 2014 (UTC)
Here is an example of a cut-off edit summary. Dustin (talk) 02:16, 15 July 2014 (UTC)
Many operators of automated editors welcome feedback.—Wavelength (talk) 02:22, 15 July 2014 (UTC)
Dustin, I have started three shortcut pages specifically for use in long automated edit summaries: (RPVB), (TVB), (FP?).
—Wavelength (talk) 03:24, 17 July 2014 (UTC)
And I nominated them all for speedy deletion. This type of thing does not belong in article space. See the note on your talk page. Oiyarbepsy (talk) 03:27, 17 July 2014 (UTC)
At least in the case of summaries with links, the limit should be based on the number of displayed characters instead of the number of characters of code used to produce the links (e.g. "[[Special:Contribs/LongUsername|edits]]" should count as 5 characters, since this is what will appear in the history/watchlists/recent changes). Helder.wiki 02:38, 15 July 2014 (UTC)
Agreed. Dustin (talk) 03:49, 15 July 2014 (UTC)
@Helder.wiki and Dustin V. S.: The limit could be based on the number of displayed characters, but then we would have the problem that if somebody entered close to 255 displayable characters, some of which was linked, then the edit summary as stored would be shorter, since it would still be cut off after 255 bytes of Wiki markup. This is because the link still needs to be stored, and as noted above, there are no more than 255 bytes to store the whole of the edit summary, markup included. If you really want 255 displayed characters, you need to exclude all markup from your edit summary.
When space is a premium, use abbreviations; if you need to link, use WP:SHORTCUTs. --Redrose64 (talk) 09:53, 15 July 2014 (UTC)
What I mean is that in order to avoid "bloat[ed] and hard-to-read histories" the limit should not be in the size of the wiki markup, but in the size of the text which will be visible to other users after parsing that markup. There needs to be a limit on the amount of wiki markup, but that needs to be bigger than the limit of visible text. Helder.wiki 12:54, 15 July 2014 (UTC)
It is not practical to increase the amount of space available to wiki markup. Therefore, if the space available to wiki markup cannot be increased above 255 bytes, the space available for display needs to be decreased from 255 single-byte characters. I don't think that would gain favour. If the edit summary that you want to use won't fit in the available space, even after using WP:SHORTCUTs and WP:ESL, put it on the talk page instead, with an edit summary like rewrote 6 paragraphs - see [[Talk:Foo#Rewritten paragraphs, 15 July 2014]] --Redrose64 (talk) 13:09, 15 July 2014 (UTC)

Solutions

Some solutions for shortening long summaries:

  1. When entering edit summaries, provide a "explain on talk" button - a user can enter as much text as they like, which appears on the talk page with an auto-generated heading, and an auto-generated edit summary saying see Talk#heading.
  2. Shorten ipv6 addresses in accordance with the standard ways of doing so. The wiki software should automatically shorten these IPs in accordance with the IPv6 standard which would make these usernames much shorter.
  3. Require abbreviated usernames - if a user picks a name with more than xx characters the software would require them to create an abbreviated version that could be used in edit summaries.

Not sure if all of these are good ideas or not, just brainstorming. Oiyarbepsy (talk) 05:51, 17 July 2014 (UTC)

Not sure whether this should be kept here or moved to the Idea Lab... My comments on each.
  1. Could this be created as a tool that someone could add? Also, if it is added to the standard code, I'd suggest it as something that could be set to on/off in preferences (default off)
  2. I think that would have to be done in the software that actually allows things like reverts, they fill in the summaries.
  3. Not sure on this, maybe they get the equivalent of a short URL to them (starting with something wierd like two LtoR markers) Naraht (talk) 14:46, 17 July 2014 (UTC)
Different wikis have different limits on the username length, and the usernames are (going to be) global. Helder.wiki 15:40, 17 July 2014 (UTC)

Pages slow and not loading properly

Recently (last two or three days), Wikipedia seems slow to load, and sometimes fails to load pages properly or at all. All other websites seem OK. Any known issues? 86.179.2.182 (talk) 17:39, 14 July 2014 (UTC)

I have something that started last night or this morning that might possibly be related to that. Under Windows 7 and Firefox 30.0 using MonoBook, certain Wikipied pages --such as AN, AN/I and this one -- never completely loads. The loading icon keeps circling and circling and "Read en.wikipedia.org" is displayed in the corner. I can read and edit the page, but some information appears to be missing - such as the info in the RFC/U box on AN/I. If I go to other pages, such as articles, after that, the icon keeps spinning, however if I exit Wikipedia and go directly to the article, they'll load completely.

Could this be a template that got munged in some way and is not loading? BMK (talk) 22:01, 14 July 2014 (UTC)

Tech savvy users are very welcome to use the Developer Tools of their web browser to check if there are specific resources loading slowly over their network. Also, do you face the same problem a) with a different browser and b) on a different network, in case you can test? --AKlapper (WMF) (talk) 23:05, 14 July 2014 (UTC)
@Beyond My Ken: this might be similar to Wikipedia:Village pump (technical)/Archive 127#Servers not serving, and not timing out either. --Redrose64 (talk) 23:15, 14 July 2014 (UTC)
@Redrose64 - Yes, that sounds like it might well be a related problem.
@AKlapper (WMF) - As far as I can tell, it doesn't occur with Chrome, Safari, Opera or IE. On Firefox, it only occurs when I'm logged in -- if I log out, the pages finish loading. (It didn't matter with the other browsers whether I was logged in or not.) I suppose that points to some problem between Firefox and my set-up (which hasn't changed at all for months)? BMK (talk) 01:32, 15 July 2014 (UTC)
Do you have any Firefox extensions installed? Does FF use any special proxy settings that other browsers don't have? Max Semenik (talk) 00:55, 16 July 2014 (UTC)
I don't believe I have any extensions, and I don't know about its proxy settings. Regardless, the phenomenon has stopped, without my making any changes. BMK (talk) 08:51, 17 July 2014 (UTC)

(OP) Wikipedia seems back to normal for me too now. Nothing I've done... 86.160.82.115 (talk) 20:32, 17 July 2014 (UTC)

Problem with tabs on main page

For some days now, a number of tabs at the top of the first page of each Wiki article have been appearing flapped forward, obscuring the text, and they cannot be shifted. Can this be fixed, please? --P123ct1 (talk) 09:33, 15 July 2014 (UTC)

Screenshot very welcome (as I wonder what the "first page of a Wiki article" is exactly). Also, which browser and which version do you use, and if you know, how wide is your screen in pixels? --AKlapper (WMF) (talk) 00:14, 16 July 2014 (UTC)
Also, which skin are you using? Vector? Monobook? (If you're not sure, it is probably Vector - you can check your preferences under "appearance"). Risker (talk) 00:21, 16 July 2014 (UTC)
@AKlapper (WMF): I did a screenshot, saved it, and when returning to the screen, the tabs had all gone back into the right place. Also, I've just noticed that the tab problem only occurs when I have the screen on "reduced size" (which I usually do), but disappears on "full screen". I use Vector and IE11, but have no idea about the screen width in pixels, though I suspect this is the problem. I can cure it now if it happens (by going into full screen mode on opening and then going to "reduced size") but it is odd that the problem has only been happening in the last week. I can't upload a copy of the screenshot (don't know how to) but the line of tabs from L to R at the top, on opening the article in "reduced" mode, were: Article (normal position. i.e. upright) - Talk (normal) - Read, Edit, History and Star, all dropped forward and down and obscuring the text beneath. --P123ct1 (talk) 14:15, 17 July 2014 (UTC)

Possible JS error in the DRN filing script

Could anyone check whether this bug report is anything that needs fixing? I'm not sure if this is a bug in MediaWiki:Gadget-DRN-wizard.js, a brief glitch in the API, or a false alarm. At any rate, the DRN script seems to be working for me on IE. (The report claims it isn't working in Firefox.) — Mr. Stradivarius ♪ talk ♪ 04:49, 17 July 2014 (UTC)

  • I'll look at it if you (or someone) can find steps to reproduce the error. Though "unknown error by API" looks like a potential caching or connection problem (see...well...I don't know the line number, but search for "API" in the code and you'll see it), which is what the script reports if it doesn't have a successful request and doesn't get an error code. Likely not a problem in the JS. Protonk (talk) 15:20, 17 July 2014 (UTC)

Substing a redirect

Is there a way to subst a redirect page? For example, if I try to subst State Route 10-Y (Virginia) into a page, what actually happens is that the redirect target - U.S. Route 19 in Virginia - gets substed. --NE2 02:31, 18 July 2014 (UTC)

What, exactly, would you like substing it to do? I seriously don't understand. Oiyarbepsy (talk) 03:24, 18 July 2014 (UTC)
I wouldn't think so. Consider wikitext like {{U|Example}}. If that is added to a page, it actually invokes {{User link}} because Template:U is a redirect to Template:User link. Likewise, {{subst:U|Example}} would do the same. I imagine you would need to edit the redirect page, then copy the wanted wikitext, then paste it wherever needed. Johnuniq (talk) 04:04, 18 July 2014 (UTC)
You could write a Lua module that gets the wikitext of the redirect page and then outputs that when the module is substituted. But before writing such a module I'd want to know what it was going to be used for; I can't think of a use for it that isn't satisfied by just editing the redirect page itself. — Mr. Stradivarius ♪ talk ♪ 04:24, 18 July 2014 (UTC)

The reason is for an AWB run to make redirects (in accordance with WP:USSH). For example, I can hack the regexes to create {{subst::State Route 10-Y (Virginia)}} on Virginia State Route 10-Y, but, as described, that doesn't work. The alternative is to simply create the redirect to State Route 10-Y (Virginia) and let one of the double redirect bots run through and fix them. --NE2 04:52, 18 July 2014 (UTC)

@NE2: That sounds like something that can be done through the API, but I'm not how well that kind of thing is supported in AWB. I seem to remember there's a feature that can hook through to outside scripts? At any rate, I've written a module for you, but it's in my pseudo-userspace because it probably shouldn't be used on any production pages. See Module:User:Mr. Stradivarius/pageSubster for the details. — Mr. Stradivarius ♪ talk ♪ 07:04, 18 July 2014 (UTC)
Thanks. You didn't have to do that :) --NE2 07:12, 18 July 2014 (UTC)
@NE2: No problem. If you decide to use it, test it using AWB on a non-existent page and let me know if you see the error message before you make the edit. If you don't see the error message, it's probably better that the module outputs nothing at all rather than throwing an error. — Mr. Stradivarius ♪ talk ♪ 07:16, 18 July 2014 (UTC)
Here's what the error message looks like. Don't worry - I've done the necessary checks to ensure that what I'm substing exists and is a redirect. --NE2 07:18, 18 July 2014 (UTC)
Fair enough. I've taken the error messages out anyway, though, in case anyone else uses it without making the proper checks. — Mr. Stradivarius ♪ talk ♪ 07:31, 18 July 2014 (UTC)

Negative category membership counts

Rummaging through enwiki-20140707-category.sql, I discovered sixty entries that contain negative numbers in at least one of the fields counting the number of articles, categories and files in a given category.

List

A few of the categories don't exist or have been deleted, but many of them look perfectly fine. Is this a feature or a bug? Paradoctor (talk) 10:05, 16 July 2014 (UTC)

Inconsistencies in various site statistics happen sometimes, and could be caused by many of the hundreds of big and little bugs that were fixed over the years (basically, if anything goes wrong between the page content being saved and data updates like category counts being done, this can happen). MediaWiki does include a sanity check to never display the negative numbers to users (when you visit such a category page, the count will be immediately recalculated – this basically means that no one has looked at any of these categories for years, which is reasonable if most of them are deleted). Matma Rex talk 19:45, 17 July 2014 (UTC)
I said "some", not "most". Take Category:Video game franchises, which had 70 views/day during the last 30 days, and contains hundreds of pages and subcategories. Yet it had a negative member count, so this is not bitrot preying on unused categories.
You are saying that a bug for this problem exists, right? Paradoctor (talk) 22:59, 17 July 2014 (UTC)
The ones I happened to look at were all deleted, so I said "most" :) (I have now added links to your list above, 21 of the categories exist and 39 are deleted). Anonymous page views usually do not reach the MediaWiki software in Wikimedia environment (instead, they are served by a caching proxy, based on Varnish), so they usually will not cause that number to be updated (I should have mentioned this).
I'm not sure if a bug exists for such miscalculations, you might want to file one. However, I think it's widely considered just a property of the software. It's nigh impossible to ensure perfect database consistency without sacrificing performance in some way, and MediaWiki is heavily optimized towards performance. Matma Rex talk 14:46, 18 July 2014 (UTC)
"added links" [[File:|25px|link=]] Should've thought of that.
I'm well aware of the difficulty of producing quality code in a production environment. It's just that I have difficulty imagining how a simple counting function yields negative numbers, that's really bizarre. Anyway, I'll take this to MediaWiki, maybe this info will help prevent the Rise of the Machines™.   Paradoctor (talk) 21:44, 18 July 2014 (UTC)
Reported as T70240. Paradoctor (talk) 22:13, 18 July 2014 (UTC)
In my experience it happens when you've optimised the counting, so that instead of counting the records in Table A on the fly every time a count is requested (this takes time), you maintain a Table B which holds the counters; and when a count of Table A is requested, you actually read the counter from table B (this is very fast). When a record is added to Table A, you increment the counter in Table B; when a record is deleted from Table A, you decrement the counter in Table B. The problem comes when a record is added to Table A but the update of Table B is not performed; eventually, when all the records are deleted from Table A and the counter in Table B is decremented the same number of times as the deletions, you find that the counter goes negative. We had a maintenance program which was run weekly to recalc the counters in Table B. --Redrose64 (talk) 22:21, 18 July 2014 (UTC)
Yes. Occasionally bad things happen and the counter gets out of sync (I don't think the counter update is even in the same transaction). Historically there was also some bugs where certain types of changes didn't update the counter, but they've been fixed years ago (but could still potentially affect older categories). If the category is small (< 200 members), the count should be updated on page view. Bawolff (talk) 00:12, 19 July 2014 (UTC)
It seems my imagination is wanting.   Thanks for the explainer and happy editing. Paradoctor (talk) 02:16, 19 July 2014 (UTC)

HotCat conflicts?

Are there any known conflicts between HotCat and other gadgets? It hasn't been working for me at all for many months now, but I never bothered to report it because it wasn't (and isn't) a very big deal. This is under Windows 7, Firefox 30 and the MonoBook skin. I looked at my preferences and it's checked off. I unchecked, saved, rechecked and saved again, no difference. It's not that HotCat doesn't function, it's that the HotCat (+)(-) etc. don't even show up. I use HotCat regularly on Commons with the exact same set up, so I thought it might be something else I have installed here that's not installed over there, and that maybe someone had already reported a problem. BMK (talk) 01:55, 18 July 2014 (UTC)

Beyond My Ken: I don't know if this is the cause but I noticed User:Beyond My Ken/monobook.js uses the wrong syntax for comments: it should be /* like this */ (or, // like this, in the end of a line), but not <!-- like this -->. Helder.wiki 03:51, 18 July 2014 (UTC)
Thank you so much! That seems to have fixed it! Much appreciated. BMK (talk) 20:03, 18 July 2014 (UTC)

Save as pdf

Tracked in Phabricator
Task T46552
Tracked in Phabricator
Task T48115

Hi, I'm a newbie and I brought this up over in the Teahouse. They suggested I bring it here. I used "save as PDF" to download an article on the Institute for Health Metrics and Evaluation. When I looked at the resulting PDF and compared to the live article, a number of citations were missing (13 cites on the PDF and 18 on the live article.) FYI the missing citations were not very recent additions. The entire list of citations on the PDF appear to be from a much older version of the article. I see you discussed a problem like this last year, but it doesn't appear to be resolved so I figured I'd bring it to your attention. I was using a firefox browser. It happened on a Mac and a PC. Thanks Savannah38 (talk) 14:38, 18 July 2014 (UTC)

It looks like references using templates (i.e. {{cite x}}) are being dropped. The article text is certainly up to date, and the references seem to be otherwise up to date. I'm initially guessing there's something happening with the templates that's getting flagged as not appropriate for print: the PDFs are designed to be printable, so there are a few unprintworthy things removed or adapted. {{Nihiltres|talk|edits}} 17:50, 18 July 2014 (UTC)
(edit conflict) @Savannah38: Let me guess: the ones that don't come out on the PDF are the ones beginning 'McNiel, Donald (February 16, 2008)'; 'Doughton, Sandi (April 9, 2008)'; 'Paulson, Tom (June 4, 2007)'; '"Harvard still hasn't gotten Ellison's $115M pledged last year". USA Today'; '"WHO: World Malaria Report 2010". World Health Organization'; 'Paulson, Tom (2011)'; 'Pallarito, Karen (June 16, 2011)'; 'Van Dam, Andrew (2011)'. These were all formatted using citation templates; the others were not.
This is a known problem on any article that uses templates inside <ref>...</ref> tags. The last time this was reported was at Wikipedia:Village pump (technical)/Archive 127#PDF printouts have lost some harv citation detail. There's nothing we can do in general terms until bugzilla:46115 is sorted. --Redrose64 (talk) 18:04, 18 July 2014 (UTC)
More specifically, I found bug 44552 for this particular case. {{Nihiltres|talk|edits}} 18:15, 18 July 2014 (UTC)
I believe a new PDF rendering engine will be deployed soon.[41]. --  Gadget850 talk 18:52, 18 July 2014 (UTC)

API: prop=languageshtml removed

Hi,

I ran a script search following the recent announcement by Brad Jorsch:

Found 3 matches:

--Krinkle (talk) 18:35, 18 July 2014 (UTC)

Redlink that links

On the Sacchin dab page the last entry has a redlink. But if you click on you get (via a redirect) to an article. How so? DexDor (talk) 19:06, 18 July 2014 (UTC)

The entry Satsuki Yumizuka was created fairly recently, and the DAB page was still cached from prior to that instant. I purged the server-cache, and now the link is blue. DMacks (talk) 19:18, 18 July 2014 (UTC)
Wikipedia:Village pump (technical)/Archive 122#Link to a nonexistent article strikes again --Redrose64 (talk) 19:56, 18 July 2014 (UTC)

Time for the semi-annual enlarging of thumbnail images

This interesting RfC attracted a great deal of commentary. Although a certain amount of evidence was provided (and thank you in particular to Patrick87 for the screenshots), the vast majority of discussion consisted of opinion statements. It was hard to know how much weight to give to these, and what I really felt I needed was data on the screen sizes that most Wikipedia readers are actually using in 2014. The data that we do have, from Analytics, tells us very little about the average user who uses the default settings.

I am afraid I cannot see a consensus in the discussion below, so I feel the only close available to me is no consensus. This is unsatisfactory and rather unhelpful, and I would have preferred to reach a clear decision here, but I'm afraid one has not emerged.

All the best—S Marshall T/C 20:24, 8 August 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bigger screens, both on desktops & laptop, as well as mobile device have left images on foundation wikis looking rather small these days.

Based on research from the Analytics group "There are 15580 instances logged across 393 wikis in log.PrefUpdate_5563398" to the preference that stores thumbnail default size. On english Wikipedia the current value is 220px for "default" sized thumbnail images, the size logged in and logged out users see if they haven't manually changed their preference. Of the ~15k users who have changes this preference the trend is to set the preference to a larger size, usually 300px as seen by the graph included in the bug for this issue eventually I'd love for us to move to responsively sized images, but perhaps thats a seperate discussion.

As proposed this would change the default value for "Thumbnail size" which would affect logged out users, and users who had never modified the value of "Thumbnail size" in preferences.

Some points of clarification to questions that have come up

  • Thumbnail size affects desktop and mobile, however MobileFrontend constrains images to the device width so a default greater than the device width will still look properly formatted
  • Responsive/dynamically sized images are the eventual goal but that isn't the point of this discussion as there are unsolved technical challenges before this can be tackled
  • This change will not affect the ability of logged in users to choose the thumbnail size they prefer
  • This change will have no effect on users who have manually set their thumbnail size
  • Due to the recent switch to have small screen devices like tablets redirect to the mobile formatted site, more users are seeing the mobile site on devices with larger screens than they historically have, feedback and bugs have been logged by these users complaining that the current default of 220px appears too small on these devices.
  • This change has no effect on Mediaviewer
  • Most logged in users make very few changes to settings in their user preferences, those who have changed thumbnail size have made it larger in almost 90% of cases, it is probably reasonable to assume this desire is present in readers but is not possible for them to do.
  • This change would affect all readers

Concerns

  • Possible typographic layout issues on small screens (<800px wide)
  • Large images could break mobile layout (be larger than the screen)
    Resolved : MobileFrontend limits image width to the device width, so this change will not break mobile layout
  • Performance issue due to more requests for larger images (investigating)
    Resolved : Ops and platform recommend small to large site rollout to offset server load during thumbnail image generation
  • Accessibility: larger images that cramp text can be difficult for readers with dyslexia - DrKiernan (talk) 20:12, 14 July 2014 (UTC)
    Resolved : Larger images lead to shorter line lengths which studies have shown are easier on dyslexic readers - Jared Zimmerman (talk) 06:50, 15 July 2014


I'd like to close this discussion by Wednesday July 16 2014

Jared Zimmerman (talk) 19:35, 9 July 2014 (UTC)

Proposal

Make foundation wikis and mediawiki software thumbnail style images use 300px (rather than current default of 220px used by most sites) size based on user data provided by Analytics Team.

Discussion

  • So, based on your graph, about 9K (~0.02%) editors have increased their thumbnail size to 300px. This hardly seems to be a trend to have larger thumbnails to me as it would then require the other 47,293,512 editors (~99.98%) to have to change their settings to restore the accepted 220px current size. — {{U|Technical 13}} (e • t • c) 19:50, 9 July 2014 (UTC)
    • That's hardly scientific. Most users don't change any settings. That says nothing about their preferences. —Designate (talk) 19:56, 9 July 2014 (UTC)
    • Technical 13, Its a good point, but we don't have a great way of asking readers/logged out users for their opinion. To assume that users are "happy" with the default is a pretty big assumption, I think it would be safer to assume that most users are either unaware there is a preference to change this, they don't have an opinion about thumbnail images sizes. I don't feel comfortable saying that inaction by users is a sign that they are happy with the current state of things. We can however look to purposeful user actions (changing the preference) to show a trend toward preferring larger images. Jared Zimmerman (talk) 20:10, 9 July 2014 (UTC)
      • I would wholeheartly support responsively sized images, but I can't support a change that only benefits less than 3% of users. I think that if users where unhappy about the size of thumbnails, they would either change the preference or they would ask at any one of the over a dozen different forums available for such a change to be made for them. In the interest of full disclosure, I am one of the 9,000 that has my thumbnail size set to 300px, yet I still oppose a change such as this currently because I see it as intrusive. Another thing that I would support in the mean time, is expanding the list to offer larger thumbnail sizes. Currently the list of available thumbnail sizes caps out at 300px, this leaves no room for expansion above that threshold. If there was a 360px and 480px option that was being utilized frequently, then I could perhaps support that 300px is a reasonable "average" size. As it stands, 300px is only reasonable as a max size. — {{U|Technical 13}} (e • t • c) 20:21, 9 July 2014 (UTC)
        • Technical 13, where are you getting the 3% number, this would benefit most readers. Readers don't have the option to increase the image size (short of making an account). As I said before if only a small subset of users have changed this preference from the default, I'd still argue that this is due to user not being aware of the preference even existing. I like your idea of adding new thumbnail sizes, and we can log that as a bug, but Ideally the bug to have responsive images would negate the need for having this setting at all. Jared Zimmerman (talk) 20:52, 9 July 2014 (UTC)
            • And why do you think that "most readers" benefit from reducing the share of the smaller screen devoted to text? Unlike certain publications, Wikipedia is one where most readers actually come toit to read the articles rather than browse the pictures! The Big Bad Wolfowitz (aka Hullaballoo) (talk) 12:01, 12 July 2014 (UTC)
              • Citation needed? Dubious–discuss? Or, more relevantly, how do you know that readers are here for the articles instead of the pictures? (Or, for that matter, for the external links, which some people have told me in person is the best part?)
                It is always pleasant to assume that readers are all interested in reading every word of my brilliant prose. However, I have generally found that the assumption that I and the readers value the same things is invalid. But even if it were a valid assumption, I sometimes go to articles in search of an image myself, so at least some of them are here to browse the images. WhatamIdoing (talk) 16:12, 12 July 2014 (UTC)
          • (edit conflict) Do you have any data to support it would benefit most readers? Based on my Google searches the majority of mobile devices still use a smaller screen size. Even if they are unaware of the preference and the ability to change it, they certainly should be familiar with the most fundamental concept of talk pages where they can complain (because that is the most likely form of a report if they were unaware they had some control). — {{U|Technical 13}} (e • t • c) 21:03, 9 July 2014 (UTC)
            • Technical 13, honestly I think its also a very generous to say that anonymous users (readers in this case) can find, and more specifically, participate in a talk page. Jared Zimmerman (talk) 04:21, 10 July 2014 (UTC)
        • @Technical 13: No one has actually suggested changing it to 300px. The discussion so far is just about enlarging it. What if it was only a moderate increase, like to 250px? Kaldari (talk) 20:48, 9 July 2014 (UTC)
          • (edit conflict) I just did a search on Google, and it appears that the majority of current mobile devices have a screensize of <= 250px, so I would be fairly hesitant to think that is a good idea until we have more data on people that would use a higher size than that by adding at least a 360px tier. If that higher option was offered, and it was brought back to the community a few months later showing data that users are selecting these higher sizes, then I would support it. For now though, the current data and research on screen sizes indicates that 220px is appropriate. — {{U|Technical 13}} (e • t • c) 21:03, 9 July 2014 (UTC)
            • Technical 13, I don't know that that number is correct… this source makes it looks like 320px is on the low end for most mobile devices, I'm not sure where you'd find definitve info about this though. Jared Zimmerman (talk) 22:16, 9 July 2014 (UTC)
          • Kaldari & Technical 13, I was actually suggesting 300px based on actual user data provided by Analytics. Jared Zimmerman (talk) 20:54, 9 July 2014 (UTC)
  • Support. Gradual increase in screen resolution means the thumbnails are actually getting smaller, which is a disservice to people. A little inflation would be an improvement. —Designate (talk) 19:56, 9 July 2014 (UTC)
    • I agree, but jumping right to the max size is too much inflation at this time. — {{U|Technical 13}} (e • t • c) 20:21, 9 July 2014 (UTC)
  • Support anyone who likes smaller thumbnails can always shrink them, can't see any harm in this. GimliDotNet (Speak to me,Stuff I've done) 20:07, 9 July 2014 (UTC)
    • I can in the form of people with smaller screened devices being unable to load pages because the thumbnails are too large. — {{U|Technical 13}} (e • t • c) 20:21, 9 July 2014 (UTC)
      • Technical 13, It might be helpful if you can upload a screenshot of any technical issues you're having. We already have a bug that images on mobile are too small, if you're experience issues it would be great to learn more about that. — Preceding unsigned comment added by Jaredzimmerman (WMF) (talk • contribs) 20:52, 9 July 2014 (UTC)
        • I've tried to download and run various screen grabbing and screenshot applications on my phone and they have all resulted in me having to factory restore my phone, so I'd rather not at this point. I will say that when I'm on my phone, I never intentionally use the mobile site because it just doesn't work most of the time and is way too limited for an editor of technical code (such as javascripts and templates). I use the desktop version of the page, and I've come across pages where the initial size of an image is forced at a higher pixel level than it would be if it was a thumbnail. Not only does it take a substantial amount of extra time to load the page, it covers the entire screen which is disorienting and I'm forced to have to zoom out and have to try and figure out where on the page I am. On the flip side, if the image is too small, it is harder to see and I have to zoom in, but it loads exceptionally fast and I'm not disoriented on page load. I can always click on the image to go to the file page and see it fullscreen. — {{U|Technical 13}} (e • t • c) 21:14, 9 July 2014 (UTC)
          • Technical 13, you shouldn't need 3rd party software, try this if you're on android or this if you're on an iphone to document the issue you're having — Preceding unsigned comment added by Jaredzimmerman (WMF) (talk • contribs) 22:10, 9 July 2014 (UTC)
            • @Technical 13: That's already a problem for people using the desktop site on a mobile device. Most articles these days have intro images set to 280px or 300px anyway. That's an edge case, problem, IMO. If you're using the mobile site (which is the default for all mobile devices and tablets), we limit the image max-width to the width of the device anyway, so it's not a problem. Kaldari (talk) 22:34, 9 July 2014 (UTC)
  • Oppose: 220px is a size that works well at almost all reasonable screen-widths for reading (e.g. works perfect for approx. 1000 px width, is only slightly too small for ~ 1200 px width and is already slightly too large for ~ 800 px width. All widths above ~ 1200 px are nonsense from a typographic point of view anyway (Typography refresh even tried to fix the width at somewhere around 1000 px during the beta stages for this exact reason). Higher resolution displays therefore do not really mean "more space" but either better resolution for "zoomed" content (e.g. TVs) or the possibility to arrange multiple windows on one display.
    If people really happen to think it makes sense to maximize their browser and use the full 1920 px (or higher) width of their display for non-zoomed content (and then claim the images where to small relatively to the page width) this is a problem of those individual users.
    Last but not least think about a Wikipedia page printed in A4 or letter format (which results in something similar to 800 px screen width): Do you really think larger images would be a good idea here? Obvious answer to the rhetorical question: No! --Patrick87 (talk) 20:42, 9 July 2014 (UTC)
  • 220px is a size that works well at almost all reasonable screen-widths for reading – not really, since the rise in popularity of tablets. Related bug: [42]. Keep in mind that tablets represent ~1 billion pageviews per month to all our projects, and growing... Maryana (WMF) (talk) 21:07, 9 July 2014 (UTC)
    • Maryana based on what data do you come up with ~1 billion pageviews per month? I'm guessing the amount of pageviews per month from mobile devices with smaller screens such as cellphones are likely higher. Please just show the data. Thanks. — {{U|Technical 13}} (e • t • c) 21:19, 9 July 2014 (UTC)
  • For one thing the bug you linked is about mobile UI, so not really applicable to the topic here which I assumed was mainly about desktop UI. If another thumbnail size in mobile UI is needed it's pretty much independent of desktop UI I assume? For another thing the thumbnails in the bug report rather show how bad it looks if thumbnails grow too large: They occupy a line on their own but are not large enough to fill it. On everything that is not a "mobile device" in the broadest sense, thumbnails are supposed to be placed inline with text content which a larger thumbnail size will pretty much break. --Patrick87 (talk) 21:46, 9 July 2014 (UTC)
      • Here is the monthly trendline for all mobile pageviews, and here is tablet's share of that. So 5 billion total mobile pageviews times 0.25 (the % of tablet pageviews from all mobile device pageviews) = roughly 1.25 billion. Maryana (WMF) (talk) 21:39, 9 July 2014 (UTC)
  • Support, the easier is it to see the image's contents, the better. Let's not forget that the main purpose of images is not to look great in article flow but to give reders additional information. Considering this, please yes - let's do it. Max Semenik (talk) 20:58, 9 July 2014 (UTC)
  • Support. I'm not sure if 300px is the right number, but it's definitely time for an increase. I would also support adding some larger values to the non-default options. Kaldari (talk) 21:17, 9 July 2014 (UTC)
  • Strong oppose If we consider the default, non-resigtered user, they are going to be ones likely to visit on older devices and thus the 220px size is best suited for them. It is far far too early in technology adoption curve to consider the possibility of larger screen sizes, in addition to how this will affect NFC aspects too. --MASEM (t) 22:20, 9 July 2014 (UTC)
    • Masem Mobile frontend already scales image down to the width of the device, so this is a non-issue. It does not however scale images up to the width of the device, so having images that are greater than the device width will result in properly formatted images on mobile, rather than postage stamp size ones. Jared Zimmerman (talk) 22:35, 9 July 2014 (UTC)
      • I'm more thinking of laptop and desktop systems. I know 220px on a 25" monitor is tiny, but I doubt most unreg'd users are using 25" monitors, but even a heavily reliance on CRTs. (COnsider that when Win XP expired earlier this year, it was estimated the system was still used by 40% of the Windows install base - the average person moves slow on technology improvements) --MASEM (t) 22:45, 9 July 2014 (UTC)
      • Masem, not sure where you're getting your number, but even on a 13" or 15" laptop screen 220px feels very small. Jared Zimmerman (talk) 22:49, 9 July 2014 (UTC)
        • I disagree. It's the very purpose of thumbnails to provide small images that can be enlarged for better viewing. As has been rightly observed above, images are meant to provide additional information in an article. However, they are not meant to dominate entire sections of the article which will quickly become the case with enlarged images on 13" or 15" inch screens. At the same time, I question the necessity of enlarged thumbnails now that Wikimedia has only recently launched the image viewer which, as far as I recall, was meant to aid viewing images without much obstructive meta-data like licence templates and whatnot. Let's not remember that the main focus of Wikipedia is still on text, and I oppose the recent tendency of it becoming Picturepedia. De728631 (talk) 23:05, 9 July 2014 (UTC)
        • Totally concur with De728631! On a 13" laptop screen 220 px is the perfect size to properly balance text content against image content. While the images might seem a little small on 15" screens (note however that many "cheap" 15" are actually the same resolution than a highly resolved 13" screen) there is no point in increasing image size as long as no flexible design is used that (as an example) defines image size in percentage of page width (plus a minimum size). Otherwise we break design for all smaller screens to make it look OK on larger screens instead of the current situation wich give good layout on small screens and acceptable layout on large screens. --Patrick87 (talk) 23:21, 9 July 2014 (UTC)
        • Patrick87 & De728631 I'll have to disagree with you that "the point of Wikipedia is text" the point is to be an educational resource, and we should help people learn about the world around them in ways that work for everyone, whether that is text, images, video, audio, or other means of representing knowledge. I see no reason why images cannot have equal weight or importance to text based content.
        • Patrick87, as you can see from the initial post I am proposing that we eventually move to responsive images, but that will require significantly more work than the simple 2 line fix that will update the default image size. Can you show some pages that feel would be made worse by larger images? it might be useful for other to see what your concern is rather than have to imagine. I hear an image is worth 1,000 words… Jared Zimmerman (talk) 00:08, 10 July 2014 (UTC)
            • That's a singularly smug, wrongheaded comment. A picture may be worth a thousand words in conveying information about appearances, but finding out what a subject looks like is not the primary reason readers come to Wikipedia. Especially when we're talking about images associated with article ledes, increasing the size means reducing the amount of text the reader initially encounters, and that's a very bad idea. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 12:09, 12 July 2014 (UTC)
          • For an encyclopedia, the finest image is worthless if there is no text to describe it, and in fact it is media like images, videos, audio etc. that complement the information provided in the text of an article, and not the other way around. And 220px do not look small on a 15" screen at all. In my sandbox I'm showing the first two paragraphs from the article Amrum with the current default thumb size and with images extendend to 300px. On my screen, the latter version reduces the text column in the Geography section to 50% of the page width excluding the toolbar on the left, while the default size now provides about 66% of text between the first image and the infobox. With a thumb size at 300 px the images on that page become in fact distracting when you want to read the first few paragraphs.
            Also, you wrote above that assuming that most user are "happy" with the current situation was a big assumption. I challenge you to show that the majority is actually unhappy with the current default size so the WMF needs to act. Has the WMF gotten a vast number of complaints about inadequate file sizes from desktop pc and laptop users? The number of mobile page views may be increasing but compared to the remaining 75% of users (20 billion total views - 5 B mobile = 15 B desktop views) they're not representative. So applying any changes the majority of users might not even need for the sake of making Wikimedia more accessible to the mobile community is the wrong approach imho. If there's a bug for tablets you should try to find a workaround that addresses the specific problems there instead of forcing changes on the entire community (yes, I wrote "forcing" because, speaking strictly for myself, I regard any change from the default that afterwards requires me to change my settings as forceful). De728631 (talk) 18:33, 10 July 2014 (UTC)
          • Jared, please compare the images below. They show a screenshot of Miroslav_Klose#Club_career with 800 px screen width as well as an A4 print preview: The versions with 220 px thumbnail size have the images fill about 1/3 of the screen width looking pleasant to the eye and working OK in regard to typographic standards. The versions with 300 px thumbnail size have the images fill 1/2 of the screen width, therefore mostly breaking the flow of text, looking bad and being a nightmare from a typographers standpoint.--Patrick87 (talk) 22:04, 10 July 2014 (UTC)
  •  
    Screenshot:
    page width 800 px
    thumbnail width 220 px
  •  
    Screenshot:
    page width 800 px
    thumbnail width 300 px
  •  
    A4 print preview:
    page width 800 px
    thumbnail width 220 px
  •  
    A4 print preview:
    page width 800 px
    thumbnail width 300 px
  • Patrick87, I'm not seeing quite the disjointed flow of text you are seeing, however I'm testing the new image styling as well, which should be in place within a few weeks. While in your screenshot the text flow is less than ideal, "nightmare" is a bit of a stretch, part of the issue is the skin's non-responsive layout. If you view the mobile (tablet) layout for the same page on desktop you'll see a much smarter layout of the same content when a browser is that narrow. 800px width seems to be an outlier for me, and no doubt when this becomes the default you'll see users shifting a few images around here and there when they feel the layout could be improved. Jared Zimmerman (talk) 23:11, 10 July 2014 (UTC)
  •  
    Screenshot:
    page width 800 px
    thumbnail width 220 px</nowiki>
  •  
    Screenshot:
    page width 800 px
    thumbnail width 300 px</nowiki>


  • @Patrick87: As a side note, a) the problems here are exacerbated by placing the images alternatively on left and right instead of just right (the default), and b) these are portrait-orientation images, and they should probably be using the |upright parameter (which reduces the default width by 25%), see Wikipedia:Picture tutorial#Upright images. I just applied these two fixes to the article, care to look again? Matma Rex talk 17:24, 11 July 2014 (UTC)
  • For obvious reasons, I didn't chose the example, that shows the issue worst. Surely one can tweak size and orientation of some thumbnails on some pages, but the fundamental issue stays the same: A 300 px wide thumbnail fills at least half the page for 800 px wide screens or paper prints of Wikipedia articles. This is too much and layout issues are much more probable than for slightly smaller thumbnails of 220 px width. --Patrick87 (talk) 17:40, 11 July 2014 (UTC)
  • Wait, are you saying you would expect new editors and IP editors to know that they should use an obscure parameter that I barely know about (as it is fairly new) even with my spending hours on mw:Help:Images learning everything I could about how to format and lay them out the way I want them to appear? That seems like a pretty tall order to me. — {{U|Technical 13}} (e • t • c) 17:54, 11 July 2014 (UTC)
  • @Technical 13: |upright is not new, it has existed for years. It doesn't matters much anyway, it is sufficient not to use |left. MediaWiki should be smart enough to "turn |upright on", in a way, but it currently isn't – there was a plan to fix it, but like every new idea it was met with a backlash right here. (I don't have links handy, you can probably find it somewhere, google "square bounding box thumbs mediawiki".) Matma Rex talk 18:07, 11 July 2014 (UTC)
  • Technical 13, no one is suggesting that readers do this (they can if they'd like) but editors are always gnoming and making small changes, i frequently find instances of weird hackish ways that people have put images next to each other and replace it with MulitpleImages template, its already happening and Matma Rex is just saying it will continue to happen in the case you mentioned. Jared Zimmerman (talk) 19:02, 11 July 2014 (UTC)
  • I don't think anyone will disagree that people are using weird hackish ways to put images next to each other or format them a specific way that looks good at their resolution (I'd guess most have no idea that a slight change from their resolution completely breaks their "perfect" formatting). The point is, that there has to be a reason they are using these methods, and my guess is because the "default" method doesn't work right or doesn't look right at the OPs resolution, so they try to "fix" it, which of course breaks it for almost everyone else. I think the point being made here is that failing to consider these issues and changing the default size is going to exponentially worsen said cases and we are going to see more of said cases. So, the question becomes, how do we fix the root cause and how do we make this work for as many readers (whether they edit or not) as we can. The first thing that comes to mind is to actually make use of @media css and set different defaults for different viewing screen sizes and get rid of the option all together. This would be the best stopgap in my mind until the dynamic size blockers are fixed. — {{U|Technical 13}} (e • t • c) 19:11, 11 July 2014 (UTC)
@Matma Rex: it was Wikipedia:Village pump (technical)/Archive 127#Infobox Image. --Redrose64 (talk) 20:17, 11 July 2014 (UTC)
  • Support— pictures are worth a thousand words after all. Imzadi 1979 → 03:32, 10 July 2014 (UTC)
  • Support. The file size increase is negligible and if 220px is really wanted it should be done via CSS - the images will be much crisper as a result. Noteit seems we support responsive images already on my retina device. The srcset attribute seems to be set on images when I inspect on my desktop computer (although sadly the larger resolution images are not loaded :-(. — Preceding unsigned comment added by 76.21.59.101 (talk) 06:17, 10 July 2014 (UTC)
  • Comment I though we already had support on this from the community ? Wasn't it mostly stuck on technical/operational issues on the WMF side ? —TheDJ (talk • contribs) 10:09, 10 July 2014 (UTC)
  • Support if tech opinion doesn't throw up serious issues. I co-led the push to increase the tiny 180px default to 220px, in 2009 (a 49% increase in area). I remember senior tech at the WMF writing on the subsequent Bugzilla request something like: "Yeah, 'bout time". There was strong support from the community. I'd cautiously suggested 220px in the hope it would fly more easily, but numerous people wanted more than that. I'd have been happier with 240px myself. 300px, even now, sounds rather large. If there's going to be resistance, I'd go for 240px or 250px. As a matter of interest, the WMF waited until a new bank of servers was installed before they upgraded en.WP, just so there would be sufficient back-up if it crashed the system. They did Commons within a month, and rolled it out to the other sites in the subsequent months. Keen to hear more from techs. Tony (talk) 12:53, 10 July 2014 (UTC)
  • I've pinged people from platform:performance and operations to have them weigh in if there are any technical concerns. Jared Zimmerman (talk) 17:17, 10 July 2014 (UTC)
  • Support - Content should improve (in this case, increase in size) as technology improves, and anyone can ultimately control size via preferences. 300px seems about right. For similar reasons, I favor a move toward responsive sizes sooner rather than later.- MrX 19:03, 10 July 2014 (UTC)
  • Question on implementation - If 300 px is going to be the default size, does this imply that user prefs will allow for larger sizes? Because if this is the implication, then I have to reiterate a extremely strong oppose on the basis of non-free images. We have a good system that aims for uploading NFC images (where finer details are otherwise not needed) at a size that a 300px max possible thumbnail size works well and maintains the minimization of copyright-taking (eg ablum covers are reduced to 300x300px). If now we can go past 300px for maximum image size, that is going to encourge people to upload larger resolution images so they look right at the newest larger size, and that breaks the purpose of non-free minimization. --MASEM (t) 22:15, 10 July 2014 (UTC)
    • I don't get this objection, though I've heard you repeat it several times this year. If 300 px is actually the limit for Fair Use according to our policy, then write down in the policy that 300 px is the limit for Fair Use images, full stop, no matter what other settings are possible in prefs or what might make sense for particular circumstances, and then go delete anything that has a FUR and is 301 px or larger in either direction. If 300px isn't the limit, then you shouldn't oppose it on the grounds that it might embolden someone to upload an image that fully complies with the written policy, even if that means uploading an image that is 360 or 400 px in one direction or the other. You know that I'm never sympathetic to arguments that amount to failing to get consensus for putting a 300-px limit into the policy, and then trying to enforce your preferred size restriction through other means. If they're real consensus for that 300 px limit, then you ought to be able to get that limit enshrined in the policy and enforced through deletion of larger images.
      Having said that, this proposal says nothing about allowing larger sizes. It would just set the default to one of the two, already-existing, larger sizes. WhatamIdoing (talk) 22:40, 10 July 2014 (UTC)
      • 300px is not a hard limit on non-free - but even through the 180->220px default thumb change, the nominal size that we encouraged editors to upload materials of non-free nature remained mostly unchanges - albums at 300px square, screenshots at 480x360 / 480x270px for screenshots, etc. These sizes balance the viewability of the content of the image with the need to reduce non-free works without too much problem. In other words, these image sizes work for these type of media and hence there's rarely a need to go larger with these types of works. You can go larger on other types of non-free but there has to be a good reason to go larger (for example, to show finer detail on a work of art). But as the bulk of non-free is cover art and screenshots, these former sizes worked given the range of allowable thumbnail sizes. If the increase of the default thumbnail size is accompanied by an increase in the maximum preference setting range (Which didn't happen with 180-->220px) editors would start uploading at larger sizes to meet the larger thumbnail size without considering that smaller sizes for these images have worked for us in the past without problem. But again, this is going on the basis that if we make larger thumbs at 300px, that there would also be a new larger preference size that could be set. If no new larger thumbnail preference size is being set, then there's not as much an issue here with non-free. --MASEM (t) 23:02, 10 July 2014 (UTC)
    • Just to echo what WhatamIdoing has said, this proposal/bug does not seek to increase the maximum thumbnail size. However, the bug i logged at the same time, might possibly increase the effective "largest thumbnail size" while simultaneously removing the preference all together. see T69695 but lets keep that issue separate for now, for simplicities sake. — Preceding unsigned comment added by Jaredzimmerman (WMF) (talk • contribs) 23:20, 10 July 2014 (UTC)
  • Support. 220px looks very small on most modern displays, and on an increasing number of mobile displays. And the work on the mobile site means that mobile users with smaller screens will not be at a disadvantage. The only people who will be at a disadvantage are desktop users who are still stuck with 800x600 displays. And these days, even PCs that make me think "wow, that's an old PC" almost never have less than 1024x768. (That is, PCs that people are actually still using.) According to w3schools, 800x600 and lower count for 0.5% and 0.5% of global pageviews respectively. — Mr. Stradivarius ♪ talk ♪ 09:54, 11 July 2014 (UTC)
  • Support just don't go crazy with it. I usually keep my browser on a monitor turned on its side, so consider that use case as well. Make sure it looks ok with a width of around 1000px for people with portrait turned monitors. Gigs (talk) 16:50, 11 July 2014 (UTC)
  • Support Entirely reasonable and well-timed change. — Scott • talk 19:12, 11 July 2014 (UTC)
  • Oppose per Technical 13. Wikipedia is about text, not images. Chris Troutman (talk) 20:20, 11 July 2014 (UTC)
  • Oppose - It's fine as it is, Don't fix what isn't broken. –Davey2010 • (talk) 22:28, 11 July 2014 (UTC)
  • Maybe. What is the distribution of screen sizes (in pixels) among our readers? MER-C 10:05, 12 July 2014 (UTC)
    @MER-C: I've asked a dev: we don't currently collect that data (even in anonymized aggragate). Hopefully they'll add that in the future. Quiddity (talk) 01:12, 17 July 2014 (UTC)
  • Oppose. Because some viewers are using smaller screens, we should reduce the share of the screen devoted to text? That's pinheaded and shortsighted. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 11:56, 12 July 2014 (UTC)
  • Strong oppose per Hullaballoo Wolfowitz. Breaking news: most of mobile users doesn't use Galaxy V nor iPhone 5 nor any other two square kilometers-wide screen device. --Vituzzu (talk) 20:31, 12 July 2014 (UTC)
  • Vituzzu, as has been mentioned at least 3 times in this discussion, MobileFrontend has code that limits the max width of thumbnail images to the device width, so this will change the postage stamp sized images on mobile to be full width, but will not cause text rendering issues or images larger than the device screen size. You can test it yourself by setting your preference to 300px then visiting the mobile site, while logged in from your phone. Jared Zimmerman (talk) 06:04, 13 July 2014 (UTC)
  • Perhaps I'm missing the obvious, but the proposal is pretty confusingly phrased - what would the enlargement actually be? 250px would seem unproblematic but 300px is perhaps a little more concerning. Andrew Gray (talk) 21:11, 12 July 2014 (UTC)
I thought the same, but "I was actually suggesting 300px based on actual user data provided by Analytics. Jared Zimmerman (talk) 20:54, 9 July 2014 (UTC)" is in the middle somewhere above. I have clarified at the top. Options for 250 or 300 might have led to clearer comments. Johnbod (talk) 00:27, 13 July 2014 (UTC)
  • Support essentially per Mr. Stradivarius.Blethering Scot 21:52, 12 July 2014 (UTC)
  • Strong Support 250px should be fine, maybe 300. I'd also support a larger max option for preferences - 350px at least. If I remember correctly, last time existing registered users who had never set a preference saw no change. If this is still the case the change needs good advertising. Johnbod (talk) 00:17, 13 July 2014 (UTC)
  • Support a change in the default to 300px. We have data showing that only a trace of users are using 800x600px displays anymore. Anyone using a mobile device or tablet gets the mobile site, which has special handling of images that would be unaffected by this change. I also support larger sizes being available in user preferences, as well as the removal of a few of the smaller sizes. Why we ever needed the granularity of 120,150,180,200,220,250,300 is beyond me; this could be changed to, say, 120,180,220,250,300,350,400. — This, that and the other (talk) 04:11, 13 July 2014 (UTC)
  • Support a change, but 300px seems a little too much to me. 250px would be more appropriate IMHO (and some sort of a compromise with opposers, too). Cavarrone 10:03, 13 July 2014 (UTC)
  • Strong Support for 300px as default and I'd also support a larger max option for preferences (400px).--LikeLifer (talk) 11:27, 13 July 2014 (UTC)
  • Don't care, as the entire website and skin will be redesigned soon (including typography refresh, new mobile skin potentially coming to desktop, etc) and the thumbnail size will be irrelevant or just different. --Gryllida (talk) 11:32, 13 July 2014 (UTC)
  • Strong Support per Johnbod. Alberto Fernández Fernández (talk) 16:37, 14 July 2014 (UTC)
  • Oppose; the Manual of Style explicitly allows alternating left-and-right images, and this change would exacerbate and introduce "sandwiching" problems in many articles, as seen on the Miroslav Klose article screenshots posted above. Titoxd(?!? - cool stuff) 17:00, 14 July 2014 (UTC)
  • Support, wholeheartedly. Mobile/small screens aren't an issue. The issue is only desktop browsers and since 2009 the average screen size of these devices (in pixels) has increased dramatically. I know we're focused on providing support for readers with older, cheaper and smaller devices and that's a great goal. But let's not conflate supporting those users with retaining a default setting which works best largely for a small and shrinking proportion of the reader base. Protonk (talk) 19:28, 14 July 2014 (UTC)
  • Oppose: conflicts with wikipedia's supposed policy to provide an educational resource for everyone. Note dyslexia style guides recommend against the sort of layout shown by the example screenshots because they can be much harder for dyslexics to understand.[43][44] There is also a mistaken assumption by young or Western editors that everyone has new devices. The image size shown in the example screenshots in the bugzilla report look fine to me. DrKiernan (talk) 20:11, 14 July 2014 (UTC)
    • The first link only opposes "very large graphics", and if 300px-wide images are "very large", then they've violated their own advice. I conclude from their own use of graphics that 300px images aren't "very large" by their standards. WhatamIdoing (talk) 02:19, 16 July 2014 (UTC)
  • The first link says "Avoid cramping" and "Avoid narrow columns". The example screenshots with the new image widths have cramped text in narrow columns. DrKiernan (talk) 08:01, 16 July 2014 (UTC)
  • Oppose - I like the looks of layouts using the 220px standard. Bear in mind that some horizontally-oriented graphics need to be pumped up to as much as 450px to look proper; 300px is too large for vertical graphics, however. Carrite (talk) 16:15, 15 July 2014 (UTC)
    @Carrite: Vertical/Portrait oriented images are meant to use the "|upright" parameter, which shrinks the thumb to ~75% width (details in WP:PIC#upright). That results in these size-pairs, for each of the standard (and considered) options: 220px/170px, 250px/190px, 300px/230px. See the images in the FA Cuban macaw, for examples. Quiddity (talk) 20:53, 16 July 2014 (UTC)
  • Oppose. From my perspective, the current default size is quite adequate for encyclopedia entries that are primarily textual. (Disclosure: my desktop is a mere 1440 px wide.) Statistics based on people who fiddle with the user preference may not be the most unbiased sample – folks with a particular interest in pictures could be overrepresented.

    A larger format is appropriate is some situations. I could support the idea of offering two default sizes, if that is not a contradiction in terms, one for a "thumbnail" image (already much larger than the nail of most people's thumbs – elephants don't count), and one for an "expanded" or "prominent" image on the order of half the width of a desktop screen. ~ Ningauble (talk) 17:54, 16 July 2014 (UTC)

    @Ningauble: We do already have policy/guidelines for larger Lead images. See details in WP:Image use policy#Size, and in MOS:IMAGES#Size, and in WP:PIC#Thumbnail sizes.
    Also, I've been looking through some recent FAs, and many of them are either not using the |upright parameter where they should, or are specifically overriding the default sizes in various places, eg. Roy Phillipps, SS Arctic disaster, Royal baccarat scandal and Pope Paul III and His Grandsons. Possibly, increasing the default size would help resolve these issues. Quiddity (talk) 00:55, 17 July 2014 (UTC)
    My experience here is that the "upright" parameter is not well known and/or somewhat difficult to understand and tends to get lost over the more direct "width" one. I know it is doing exactly what we want in terms of technical implementation, but it's not very easy to explain to people that are not used to flexable formatting approaches. It's much "simpler" to recognize that "width" can narrow the size that a portrait-style image appears at than adding "upright" that does that automagically. --MASEM (t) 01:36, 17 July 2014 (UTC)
    @Quiddity: Yes, I know all about the various ways of tweaking image sizes. They are a bit fiddly and, as Masem notes, not as well understood as they might be. I was only suggesting, as an aside here, that it might be simpler to have a second default, an alternative to "thumb", for situations where a larger presentation is appropriate. A half page graphic is not a thumbnail image.

    And no, I really do not think making all of the images larger by default is a satisfactory resolution for the need to make some of the images larger. I was specifically referring to situations where one-size-fits-all is not fitting. If this is too far off topic or outside the box in a discussion of what the single default size should be, then please disregard it. ~ Ningauble (talk) 13:20, 17 July 2014 (UTC)

  • Partial Support I'd say about 260px. Adam Cuerden (talk) 17:59, 16 July 2014 (UTC)
  • Support. Definitely. I could've said the same thing even 4 years ago. -- œ™ 03:39, 18 July 2014 (UTC)
  • Support There is a clear interest in displaying images at higher resolution given changes to technology. I approve of this, even as a user of what most would consider an old, small-screened laptop (my hard drive is smaller than the Wikipedia:Database download). I don't find any of the above reasons reasons against convincing. The Klose article clearly had presentational issues in the screenshots above before we started (images should not bump out headings), so it's not a good test case. These are manual of style issues that would already be exacerbated for the 10,000 users manually opting for larger image size. I don't find it convincing that larger images will detriment encyclopaedic presentation. Images are often an undervalued element of articles that readers will mostly want to see at higher resolution, and will be better served from a learning perspective by that change (see Cheetah for example). If images are not bringing extra value to an article, they should be excluded as an editorial decision. The one concern I do have is that this is quite a big jump up in size. I would prefer an upgrade to 250px with A/B testing for 300px, if that is possible. SFB 10:50, 19 July 2014 (UTC)

---

Thank you everyone who added feedback, concerns, responses, and clarification. We appreciate your time and involvement. At this time I'd like to request an uninvolved 3rd party close and summarize the thread. Thank you again. Jared Zimmerman (talk) 06:00, 18 July 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Links

Guys, what is the RGB code for blue and red links? --Edgars2007 (talk/contribs) 08:31, 19 July 2014 (UTC)

They are listed at Help:Link color -- John of Reading (talk) 08:40, 19 July 2014 (UTC)
Silly me. Thanks! :) --Edgars2007 (talk/contribs) 08:44, 19 July 2014 (UTC)
They also vary between skins: links in Vector are darker than those in MonoBook. --Redrose64 (talk) 08:53, 19 July 2014 (UTC)

iPad Beta

The cite tools don't work on safari or chrome on the iPad, the window pops up but the fields are not editable. Anyone else have this issue? GimliDotNet (Speak to me,Stuff I've done) 21:10, 19 July 2014 (UTC)

Made an edit and it didn't show up

[45] versus [46] Where did it go?? -- Kendrick7talk 02:56, 20 July 2014 (UTC)

@Kendrick7: I fixed it but had to remove your signature (which was just four tildes!) because my signature was shown. The problem was that someone had used text like <ref example> which made an unclosed reference. Please add your signature again. Johnuniq (talk) 03:54, 20 July 2014 (UTC)

phpMyAdmin

I've configured phpMyAdmin so anyone can run SQL queries on their own. Enjoy! — Dispenser 00:04, 9 July 2014 (UTC)

Err, no. I've deleted the tool immediately; not only is phpMyAdmin not allowed on Tool Labs, but having it open to all is a very poor idea even if it weren't.

It would be a good idea to have a tool by which users not very familiar with SQL or Labs can request queries to be run, provided it has human supervision, but that was just begging for trouble. — MPelletier (WMF) (talk) 00:28, 9 July 2014 (UTC)

And why not? Its under FLOSS license and up to date. And views it has aren't privileged. Unlike Toolserver, Labs doesn't contain sensitive data. Now why would queries need human supervision, wouldn't the query killer take care of any stray queries? — Dispenser 00:59, 9 July 2014 (UTC)
Watched pages is generally an agreed upon 'not privileged' but also still sensitive to release information. If vandals from 4chan or other boards knew which pages were watched the least, they would be perfect targets.--v/r - TP 01:02, 9 July 2014 (UTC)
That's Toolserver, there's no watchlist table on labs. Plus we were listing unwatched pages for nearly two years without problems. — Dispenser 01:31, 9 July 2014 (UTC)
Because, amongst other things, phpMyAdmin is a security hole with secondary database features. Besides that, (and I'm sure Legal would add "more importantly") database access is contingent upon being a user of Labs and to have agreed to its terms of use. — MPelletier (WMF) (talk) 02:54, 9 July 2014 (UTC)
Its pretty much expected that tools will have security vulnerabilities which is reflected in Labs' architecture. And by using updated off-the-shelf software like phpMyAdmin (whose team takes security seriously) will be better than any custom solution. Finally, could you quote the relevant passage because I don't see it on Labs Terms of use. — Dispenser 03:42, 9 July 2014 (UTC)
I can think of all sorts of reasons why Joe Public shouldn't be let loose on a SQL command line. --Redrose64 (talk) 11:17, 9 July 2014 (UTC)
The user account separation does not allow modifying or deleting other databases. In fact, tables are unreadable unless the read permissions are set. — Dispenser 13:48, 9 July 2014 (UTC)

So I take it that all issues have been addressed and we can reinstate this incredibly useful tool? — Dispenser 15:47, 12 July 2014 (UTC)

  • Implementation of phpMyAdmin at Labs is a great idea! I fully support it.--XXN (talk) 21:23, 15 July 2014 (UTC)
    @MPelletier (WMF): So can we re-instate this? — Dispenser 00:25, 17 July 2014 (UTC)
    • No, you may not. As I've stated previously, access to the databases requires the user to be a registered wikitech user (and thus subject to the TOS); any tool that allows unsupervised queries into the database is not permitted, as it may severely impact database performance. (This should come as no surprise to you since the Toolserver also did not allow this for the same, obvious, reasons).

      I would have though this obvious enough to go without saying, but I've added a point to the Tool Labs rules to reiterate common sense. — MPelletier (WMF) (talk) 15:11, 17 July 2014 (UTC)

      So do these users need a Wikitech wiki account or shell account? Is OAuth ok? — Dispenser 14:58, 20 July 2014 (UTC)
    • I oppose phpMyAdmin, being publicly available. Tool labs users have access to a table, not accessible in the dumps, which can easily be abused.—cyberpower ChatOnline 15:30, 20 July 2014 (UTC)
    • I will however support it iff the security issues are resolved && access to the db is only allowed through the supplied username and password issued in the replica.my.cnf && nothing is logged. I also want to see a WMF staff member be listed as a maintainer, preferably Coren.—cyberpower ChatOnline 15:38, 20 July 2014 (UTC)

Watchlist notification page

Greetings, (I have forgotten), could someone provide me the page link that controls notifications above watchlist (example: A new discussion is taking place on ABC. [dismiss]). Thanks Tito☸Dutta 05:13, 20 July 2014 (UTC)

@Titodutta:, I am pretty sure you do not mean the Wikipedia:Requests_for_comment#Before_starting_the_Request_for_comment_process because that is for pages that are prone to adversarial action. As far as I can tell, you can get notified about any wide-ranging discussions about watchlisted pages only if you created that page. In that case, in the top right corner of that page | Preferences | check Page link, or check Page review (you can hover your cursor over the question mark to get help) | Save .
It occurs to me that an editor could simply post a section to any watchlisted talk page about discussion or request for comment. You would see that by virtue of your watchlist.
PS: wp:flow may make it possible to get notified about pages which you did not create yourself (but not yet). Pinging @Quiddity: about this application for the Flow project. --Ancheta Wis   (talk | contribs) 06:58, 20 July 2014 (UTC)
@Titodutta: MediaWiki:Watchlist-details. — Mr. Stradivarius on tour ♪ talk ♪ 08:56, 20 July 2014 (UTC)
I think you're misunderstanding Titodutta. The query is about "notifications above watchlist". This would be about the banner adverts occasionally appearing there, and which can be [dismiss]ed with a click. AFAIK, there is no way to opt out of them, and I don't recall opting in. Actually, I don't have the slightest idea who or what is reponsible for these. Paradoctor (talk) 10:56, 20 July 2014 (UTC)
Wikipedia:Watchlist notices has some CSS fragments that make them invisible. -- John of Reading (talk) 11:07, 20 July 2014 (UTC)
There are two sets of these. Watchlist notices are displayed to all users; geonotices, which are displayed just above that (and in a different font, for reasons I've never worked out) are shown to all users in a specific region. These tend to be for local events rather than for on-wiki discussions, as it wouldn't make much sense to limit on-wiki stuff by geography. At some point they should probably be combined :-) Andrew Gray (talk) 19:12, 20 July 2014 (UTC)
I can never remember the exact page name that works as the linkhub, but the shortcut is easy: WP:NOTICES. :) Quiddity (talk) 18:34, 21 July 2014 (UTC)

Tech News: 2014-30

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

Recent software changes

  • The latest version of MediaWiki (1.24wmf14) was added to test wikis and MediaWiki.org on July 17. It will be added to non-Wikipedia wikis on July 22, and to all Wikipedias on July 24 (calendar).
  • CirrusSearch was removed as the primary search method from Wikimedia Commons and the Spanish (es) Wikipedia due to a high server load. The plan to enable it on the Dutch (nl), Japanese (ja), Polish (pl) and Russian (ru) Wikipedias was also postponed to a later date. [47] [48] [49]
  • The tool that stores information about languages (CLDR) was updated to its latest version. You can still help translate language names into your own language so they can be used in the sidebar and other places. [50]
  • Translation memory for newly translatable pages should now offer more suggestions. [51] [52]
  • A tool to convert MediaWiki pages to LaTeX is now available on Tool Labs. [53]

VisualEditor news

  • Tablet users visiting the mobile version of Wikimedia wikis will be able to use a special version of VisualEditor starting on July 31. You can test the new tool by choosing the beta version of the mobile view in the Settings menu. Feedback is welcome. [54]
  • All windows in VisualEditor have now a new design. Main action buttons will always be located in the top bar and will use simple words rather than icons. [55]
  • You can now easily open links inside the link editor, for example to see their target. [56]
  • Several bugs related to the positioning of the cursor around some items (like images and references) were fixed last week. [57] [58] [59] [60] [61] [62]

Future software changes

Problems

  • Mailing lists were broken for about 16 hours between July 14 and July 15 due to a server problem. [66]

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

07:42, 21 July 2014 (UTC)

Links in headings

I'm increasingly seeing links (and sometimes even templates) in section headings. AIUI, this shouldn't be done. How can we encourage editors not to do so? Should we raise a bug for mediawiki to remove such markup from headings? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:13, 21 July 2014 (UTC)

MOS:HEAD already advises not to include links in headers. Is it such a big problem that links need to be removed automatically by MW? SiBr4 (talk) 15:15, 21 July 2014 (UTC)

requesting help for 'help video clip'

Hi, I came across one video clip for ULS help for Telugu language wikipedia as shown below. The clip is usefull but it does not show how to access help page. We will apreciate if some one helps us with simmiller clip for Marathi language.

Thanks & Regards Mahitgar (talk) 15:16, 21 July 2014 (UTC)

Click on the 'cc to change the subtitle language and learn how to type in Telugu on Telugu Wikimedia projects from this video

More templates not appearing on mobile

Further to recent discussion, about {{Authority control}}, it also appears that {{Commons category}} does not appear on our mobile view or app; and no doubt its sibling templates and others are similarly affected.

This will affect editors little, since most are likely to be working on in desktop-view, but a significant number of our readers are on mobile devices. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:45, 17 July 2014 (UTC)

{{Commons category}} ultimately uses Module:Side box, which adds the invisible-for-mobile metadata class. About 380 other templates also use the module. SiBr4 (talk) 14:20, 17 July 2014 (UTC)
All those elements are also not present in print. This is by choice. They are not part of the 'content proper', but are 'internal' in nature. Now with the more advanced mobile website might slowly start losing the requirement to hide some of those elements by default, I think it was mostly hidden originally because of the maintenance templates, and even those are being represented now, so perhaps someone should file a bug against Mobile to revert the decision to hide .metadata in the mobile view. —TheDJ (talk • contribs) 14:56, 17 July 2014 (UTC)
Alternatively, we can of course say that {{Sister}}, should just not call the metadata version of {{Sidebox}}, but that is a community decision. —TheDJ (talk • contribs) 15:01, 17 July 2014 (UTC)
It's Template talk:Listen/Archive 3#Does not render in mobile view. once again. Just add |metadata=no to the {{side box}} that is inside Template:Sister. --Redrose64 (talk) 16:44, 17 July 2014 (UTC)
@Redrose64: Done; please let me know if anything breaks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:37, 22 July 2014 (UTC)

Collapsed sections not showing

It also appears that anything inside {{Collapse top}}/{{Collapse bottom}} is hidden on mobile. See:

example

Foo

This really isn't on. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:33, 22 July 2014 (UTC)

{{Archive top}} has the navbox class. Same issue as with Template:Authority control. SiBr4 (talk) 09:25, 22 July 2014 (UTC)

LaTeX, Cyrillic, UTF8, oh my!

I'm in the process of converting lots of Bibtex entries into wikipedia-friendly UTF-8. Consider the following bibtex entry taken from Mathematical Reviews: 

 @preamble{
    "\def\cdprime{$''$} "
 } 
 @article {MR0178390,
     AUTHOR = {Erd{\H{o}}{\v{s}}, Paul},
      TITLE = {On some geometric problems},
    JOURNAL = {Fiz.-Mat. Spis. B\u ulgar. Akad. Nauk.},
   FJOURNAL = {B\cdprime lgarska Akademiya na Naukite. Fizicheski Institut.
               Matematicheski Institut. Fiziko-Matematichesko Spisanie},
     VOLUME = {5 (38)},
       YEAR = {1962},
      PAGES = {205--212},
       ISSN = {0015-3265},
    MRCLASS = {50.00},
   MRNUMBER = {0178390 (31 \#2648)},
 }

Per [67], I'm guessing \cdprime is supposed to be ъ or something similar, and MR def'ed it to a null character on the assumption that most people wouldn't have the cyrillic style file included. But honestly, my LaTeX isn't good enough to be sure that's what's going on. I'm not able to get this to compile on my home machine.

  1. Is ъ the intended symbol?
  2. Should the start of the full journal name look like "Bъlgarska"?

Thanks, Lesser Cartographies (talk) 04:36, 21 July 2014 (UTC)

(update) Worldcat uses "Bŭlgarska akademii︠a︡" and "Bulgarska Akademii︠a︡ ". Way out of my depth here.... Lesser Cartographies (talk) 04:57, 21 July 2014 (UTC)

No, it doesn't make sense to mix latin and cyrillic letters in one word, so Bъlgarska shouldn't be an option. You can use ŭ if you want. The sound is like the schwa sound of the letter u in the word Bulgaria. It can also be transliterated as a, with or without diacritics, but for English speakers even plain u works. It depends on which of the many transliteration standards you want to follow. Some standards use " (double quote) to transliterate ъ from all languages that use the Cyrillic alphabet, that's because ъ is silent in Russian, so you can't use a or u there. I suspect that line 2 of your bibtex code defines cdprime as double quote. --V111P (talk) 04:17, 22 July 2014 (UTC)
@V111P:, I just figured out how to compile this and the results aren't particularly sensible: B′′lgarska. I'm going to chalk this up to a strange error at MR and follow your advice and use Bŭgarska. Thanks for the help, I really appreciate it. Lesser Cartographies (talk) 06:00, 22 July 2014 (UTC)

SUL question

So, according to this, once an account is unified that name is reserved on all Wikimedia wiki's. So I have a few questions:

  1. Does this preclude a bureaucrat on a local wiki from renaming a local user to a name that isn't (locally) taken yet (but is globally unified)? Or one that is taken but has zero edits?
  2. Does this break the "unification"?
  3. Is there a log/view that shows if/when an account was unified?

Back when this feature was enabled I could have swore I successfully unified my account. Then, sometime in 2010 or so, another user wanting to use my username on pt-wiki got a bureaucrat to rename them to my name. Now my account is not unified and refuses to unify as I don't have the password for that account. Is this a bug, or a feature, or am I misremembering that I unified my account? =)

Thanks! —Locke Cole • t • c 01:42, 22 July 2014 (UTC)

@Locke Cole:, the answers to your questions are:
  1. No. Local bureaucrats have the ability to arbitrarily detach local accounts from global ones using Special:RenameUser.
  2. Yes. As you can see from the bottom of Special:CentralAuth/Locke Cole, your account is no longer fully unified.
  3. Not to my knowledge. Special:CentralAuth/Locke Cole is probably the closest you can get, but it's hardly comprehensive and there are errors for older accounts.
However, don't fret too much. When we finally do the SUL finalisation and forcibly rename users to resolve every single clash, the user on ptwiki will be renamed out of the way for you and your account will be permanently fully unified; I decided a while ago that if someone had already taken a global account then they'd get to keep it, irrespective of any other factors. --Dan Garry, Wikimedia Foundation (talk) 03:15, 22 July 2014 (UTC)
Sounds good, thanks for your help Dan! =) —Locke Cole • t • c 04:13, 22 July 2014 (UTC)

Can I get consensus for Special:Email to point to Special:EmailUser

It seems intuitive to me: Special:Email should redirect to Special:EmailUser. I was having a chat in IRC, on #wikipedia-en-help, and I asked a user to email me, and gave the wrong link. Redirects are cheap and this should save (some) time and confusion. I mean, who would you be emailing other than users? I was going to go to bugzilla but decided to get consensus first. Comments? Thanks, Lixxx235Got a complaint? 04:48, 16 July 2014 (UTC)

I would support such a change. Special:Contribs points to Special:Contributions, so why shouldn't Special:Email point to Special:EmailUser? Dustin (talk) 05:03, 16 July 2014 (UTC)
Technically, as a software change, this doesn't need consensus. Anyway, I submitted gerrit:146798 that will add it. Jackmcbarn (talk) 16:11, 16 July 2014 (UTC)
I gave the patch a +1. I'm wary of adding in aliases for every possible thing, but this one seems pretty sensible and common to me. --Dan Garry, Wikimedia Foundation (talk) 03:26, 22 July 2014 (UTC)
Agree. — xaosflux Talk 04:07, 22 July 2014 (UTC)
We should probably do the same for Special:E-mail and Special:E-mailUser. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 17 July 2014 (UTC)
Might be going a bit too far, along the lines of DGarry's comment, not as useful. — xaosflux Talk 04:07, 22 July 2014 (UTC)
My change has been accepted. It will be live here effective July 31st. Jackmcbarn (talk) 18:13, 22 July 2014 (UTC)

Use old version of a template

Tracked in Phabricator
Task T70399

At Template:IPvandal/testcases, I want to include a set of tests that showed the results given by a specific old version (581205260) of the template. I read and tried Help:Permanent link, but it doesn't work for templates (it just becomes a link to the specified template; it doesn't transclude it). How can I transclude this old version of {{IPvandal}}? —[AlanM1(talk)]— 14:21, 20 July 2014 (UTC)

Create {{Template:IPvandal/old}} with the version you desire and transclude it. --  Gadget850 talk 16:57, 20 July 2014 (UTC)
@AlanM1: I copied the request to bugzilla:68399, because I wanted this same feature in few occasions before. Helder.wiki 20:52, 22 July 2014 (UTC)

Suggestion for a new tool

With certain articles, we get a lot of editors working at once on the article, with multiple edit conflicts etc. Recently, Malaysia Airlines Flight 17 has been affected by this.

Would it be technically possible to introduce a "timer" preventing the article from being edited for a short period of time (i.e. not more than 5 minutes) after the last edit? Of course, if such a feature was technically possible, there would need to be due discussion as to its desirability, but there's no point in discussing the latter if the former isn't possible, is there? Mjroots (talk) 20:51, 20 July 2014 (UTC)

@Mjroots: Would reasonable use of {{in use}} (with a parameter as needed) be appropriate? GoingBatty (talk) 21:15, 20 July 2014 (UTC)
@GoingBatty: - No, because that is only a courtesy request, as is {{underconstruction}}. There is nothing to stop an editor from editing an article where these templates are displayed. Mjroots (talk) 21:21, 20 July 2014 (UTC)
@Mjroots: Note that {{under construction}} is an invitation for others to help with editing, whereas {{in use}} is a courtesy request not to edit for a short period of time. GoingBatty (talk) 21:35, 20 July 2014 (UTC)
I believe he's looking for something that's enforced in software, not something that depends on the courtesy, or even the attention of, dozens or hundreds of other editors. WhatamIdoing (talk) 22:29, 20 July 2014 (UTC)
On the actual question: It is technically feasible, but it'll never be agreed to. WhatamIdoing (talk) 22:30, 20 July 2014 (UTC)
I think this is a bad idea. At best, it would mean every act of vandalism would remain for 5 minutes at a minimum. At worst, it would discourage positive contributions and allow users to effectively lock down a page (by timing their next edit to the end of each time period). SFB 16:43, 21 July 2014 (UTC)
I'd already thought of that. One way around this would be to enable admins (or maybe admins and confirmed editors) to be able to edit during the temporary lockdown time. Mjroots (talk) 14:55, 22 July 2014 (UTC)

I noticed that sometimes I have been getting edit conflicts on that same article's talk pages... caused by editors editing different sections (I am relatively sure of this, although I am not certain). Has anyone else experienced this issue? Dustin (talk) 22:34, 20 July 2014 (UTC)

Yes, I ran into that issue on that article's talkpage myself a few times, I believe. Similar matters tend to happen if I take a while writing an edit on huge pages like ANI. AddWittyNameHere (talk) 06:34, 21 July 2014 (UTC)
Flow is intended to replace current Wikipedia talk page system. --  Gadget850 talk 15:38, 21 July 2014 (UTC)

Ref tags cluttering an article talk page

Have a look at the end of Talk:Malaysia Airlines Flight 17; there are many sections of discussions where editors are proposing or challenging text from the article, and have included said text from the main page, refs tags and all. Is there a way to address this via technical means, e.g. suppress the output of a reflist on a page? Tarc (talk) 14:36, 21 July 2014 (UTC)

Not anymore. See #Missing reference markup will no longer show an error. Until that enhancement was deployed, we had namespace control over the previous error message and did not show it on user and talk pages because of the copy/paste references. This keeps coming up, so I will file a bug report on this. --  Gadget850 talk 14:40, 21 July 2014 (UTC)
T70324 - Cite: Add namespace detection for automatically generated reference list. Now marked as WONTFIX. --  Gadget850 talk 01:22, 22 July 2014 (UTC)
Well, thanks for trying. The WMF is too busy wasting millions on features no one wants (flow, visual editor) and rejecting small things that may actually be of value to the community. Tarc (talk) 12:13, 22 July 2014 (UTC)
The practical solution is pretty easy, and has the advantage of making it possible to evaluate the sources in that section. WhatamIdoing (talk) 18:16, 22 July 2014 (UTC)

Viewing SVGs in IE

I'm running IE11, and I've always used this or previous versions since I began editing in 2006. I've always known that I can't get a full-resolution SVG by clicking on the image when viewing its description page: I have to click one of the links after "This image rendered as PNG in other sizes", or rightclick to get Properties and go to the address given in the "Address (URL)" line, because I've never had software capable of viewing or editing SVGs (aside from Notepad), and as a result it's always asked me if I want to download the SVG, or download software to view it, or something like that.

In the last couple of weeks, I've discovered that this is no longer the case: going to an SVG's description page and clicking on the image will take me to a larger-resolution version of the image, as if I'd clicked on a PNG or JPG. For example, clicking on the image itself at File:NRHP Counties Net Quality.svg takes me to https://upload.wikimedia.org/wikipedia/commons/1/12/NRHP_Counties_Net_Quality.svg without problem. Is this something new with our software, or something new with IE? I've not changed anything with my browser, aside from routine updates from Microsoft which, I suppose, could have included the capability to view online SVGs. Nyttend (talk) 01:05, 22 July 2014 (UTC)

Internet Explorer has included the ability to natively view SVGs since version 9. Nothing really new. — This, that and the other (talk) 01:32, 22 July 2014 (UTC)
@Nyttend: It's been the case for some years that on a file description page (including that for a SVG), clicking the image is the same as clicking the Original file link; this is how I obtained the original SVG files so that I could make my first derivative work way back in 2010. What your browser does upon clicking the image (or the link) is down to itself. When I try it in IE8 (having Windows XP, I can't use IE9 or later), it pops up a box headed "0% of ...NRHP_Counties_Net_Quality.svg from upload.wikimedia.org" and in front of that, another headed "File Download" containing "Do you want to open or save this file?" and some buttons. --Redrose64 (talk) 10:13, 22 July 2014 (UTC)
I was running IE8 until the end of last year, when I bought the current computer. Maybe it's just taken me eight months to notice the additional capability that this newer browser has? Nyttend (talk) 12:21, 22 July 2014 (UTC)

is there a way to change the highlighted reference colour?

on pages with many references i find it difficult to find the reference i clicked because the highlight colour is too much like the page colour. is there a way i can make it more obvious? — Preceding unsigned comment added by Xxami (talk • contribs) 10:31, 22 July 2014 (UTC)

You can put the following rule in your common.css and change the color to your liking:
ol.references li:target, sup.reference:target, span.citation:target {
    background-color: #DEF;
}
-- [[User:Edokter]] {{talk}} 10:49, 22 July 2014 (UTC)

My preference for the desktop version of Wikipedia on the iPad doesn't stick! Any solutions, including JavaScript?

I am using Wikipedia in Chrome on the iPad. When I visit the site, I am redirected to the mobile version. I always tap on the desktop link at the bottom of the page and I get the desktop version. Wikipedia used to remember my preference and give me the desktop version on subsequent visits, but now it always redirects me to the mobile version. I don't want the mobile version - I want the desktop version! Any solutions - I don't mind using JavaScript?

Tracey Lowndes (talk) 17:35, 22 July 2014 (UTC)

@Tracey Lowndes: Please see #two annoying problems above. --Redrose64 (talk) 17:49, 22 July 2014 (UTC)

w:(lang) links

Tracked in Phabricator
Task T70085

Did something change in recent months relating to the way MediaWiki handles [[w:(lang):Example]] links? Previously, [[w:de:Australien]] should have worked in exactly the same manner as [[:de:Australien]] to produce a link to this page, however it doesn't seem to work anymore, for any non-English language code. For some reason, the en language code still works: w:en:Test and en:Test both do the same thing. --benlisquareT•C•E 17:45, 15 July 2014 (UTC)

It has changed [68], there have been some fixes aiming to make the handling of "local interwiki links" like [[en:Dog]] or w:Dog more consistent. It seems that the fixes indeed introduced a little regression, [[w:de:Australien]] is now handled like [[de:Australien]] instead of [[:de:Australien]]. This, that and the other should know what to do with this. Matma Rex talk 19:00, 15 July 2014 (UTC)
Hmm, this is interesting. The new behavior is arguably more correct, and I suppose I designed the changes so it would work this way. But on reflection, it doesn't seem quite right; in particular, from a cross-wiki code reuse/transclusion perspective, it is definitely not right. I'll have a think about this and perhaps write a patch for MW core. Benlisquare, thanks for bringing this up! — This, that and the other (talk) 02:52, 16 July 2014 (UTC)
Now that I've looked a bit more deeper into the issue, does this apply to enwiki only? w: links seem to still work just as before on the Chinese Wikipedia and other language Wikipedias. --benlisquareT•C•E 06:23, 16 July 2014 (UTC)
I've found (see User talk:RexxS#Oh no, not her again) that all you need to do to fix these is either insert a colon right at the start ([[:w:de:Australien]] → w:de:Australien), or omit the initial w ([[:de:Australien]] → de:Australien). So long as it begins with a colon, it's treated as a clickable link, not a H:ILL. --Redrose64 (talk) 20:36, 16 July 2014 (UTC))
That's true, but the intention is to restore the old behavior, so there is no need to go around willy-nilly adding leading colons everywhere! — This, that and the other (talk) 02:48, 17 July 2014 (UTC)
Yes, there is the chance that templates and pages throughout Wikipedia have such links which have yet to be modified by someone following the change to link behaviour, meaning that there may be non-functional links lying around. --benlisquareT•C•E 04:58, 17 July 2014 (UTC)
Given Wikidata has removed the old way of doing interwiki links that needed a colon, should the non-colon functionality be made identical to colon, or is there anything where it's still relevant? Adam Cuerden (talk) 20:46, 16 July 2014 (UTC)
@Adam Cuerden: ILL are still needed for #section links, and for topics with 2 pages at wiki-A but only 1 page at wiki-B. See H:ILL#Local links (2nd bullet point) and d:Help:FAQ#Editing (#14 and #15) for details on each. Quiddity (talk) 21:16, 16 July 2014 (UTC)
Also for pages in User: space. --Redrose64 (talk) 21:54, 16 July 2014 (UTC)

This is now tracked as T70085, with a fix pending review. Matma Rex talk 23:05, 16 July 2014 (UTC)

Running template within Lua and a few other questions

I'm working on a Lua replacement for {{UND}}

My original goal was to allow an optional parameter to indicate that it should be signed. I'm still mulling how to do that, but wanted to recreate the existing functionality first.

My draft attempt is Module:Sandbox/Sphilbrick/UNDiftest

My main issues:

  1. Several of the output strings include a template. I don't quite see how to run a template inside a string. For example, one of the output strings has {{Font color|white|green|Submit your draft when you are ready for it to be reviewed!}}. That one should be easy, but I also have to accept an admin name and convert that to the usual output.
  2. The copyvio option has an optional input. - you can run it with or without an external site name. I think I want to do something like if frame.args[2] but I'm not quite sure.
  3. I believe we don't usually end with a module, but wrap the module in a template. I'm missing how to deal with the fact that the module will have 1-4 arguments
  4. In some cases, the template used safesubst rather than subst. I didn't use either. What should I do?
  5. I'd like to convert upper case input to lower case for the parameters. I know Lua is case-senstive, so if someone passes "D" as an argument, I'd like to autoconvert to "d". I chexkws the refernce manual and didn't see such a function.

I know I still have to write documentation and create testcases. I will work on that, but want to make sure I don't have to fundamentally restructure first.--S Philbrick(Talk) 17:39, 20 July 2014 (UTC)

@Sphilbrick: As I look at that template, I don't see any advantage to converting it to Lua. Jackmcbarn (talk) 18:21, 20 July 2014 (UTC)


What I really want is a better version of the CBB templates, as seen in:
North Carolina Tar Heels women's basketball
The problem:
When adding the 2013–14 entry, it isn't hart to enter the wins and losses overall and by conference. But it is a pain to update the coach records and the overall records, especially when you consider that they are occasionally done wrong, so you should verify the complete sums, not just add the most recent year to the totals.
AFAIK, ordinary templates don't do math well. They can calculate ratios within a row, but I don't know how to sum across records.
My impression is that Lua can do this, so I thought I would learn Lua to work on it.
However, I wanted to tackle something easier as a start.
I had independently been working at both WP:SCV and Wikipedia:Requests for undeletion. In each case, there are canned templates to deliver standardized answers. However, the SCV templates automatically add a signature, and a bullet point, and are designed to be added to the end of the entry, rather than the next row. In contrast, the UND templates do not automatically add a signature, and you need to add your own indention and place on the next row. Not a big difference, but when going back and forth it means I have to stop and think each time which convention has been adopted.
I suggested that the UND templates be modified to auto add signatures, and that was rejected. So I thought it would be a good excuse to learn some Lua skills and either create some templates which could handle either case, r if not, at least create some that would work for me.
If you tell me either how to do math in traditional templates, or that Lua can't handle math, I'll probalby abandon my attemtps to lean Lua, and simply make a custom version of UND templates for my own use.--S Philbrick(Talk) 19:42, 21 July 2014 (UTC)
You can use the {{#expr:}} parser function, covered at m:Help:Calculation. For example, {{#expr:2+2}} → 4 --Redrose64 (talk) 20:54, 21 July 2014 (UTC)
That would actually be mw.ext.ParserFunctions.expr("2+2") inside Lua. Jackmcbarn (talk) 20:59, 21 July 2014 (UTC)
It was in reply to Sphilbrick's q "how to do math in traditional templates". --Redrose64 (talk) 21:53, 21 July 2014 (UTC)
I know how to do something simple like add two numbers in the same string. However, I have wins for each year, and need a total. For example, in Karl_Smesko#Head_coaching_record, the current approach has a separate template for each year, and subtotal templates. As you can see, I calculated the win loss ratio for the Walsh University year, but tpo get the sums of wins and losses for the subtotal and total lines, I need to do it in an external spreadsheet. That works if I always do the updates, but many of these were already created, so adding a new year, which is an upcoming task, is quite a pain.--S Philbrick(Talk) 22:07, 21 July 2014 (UTC)
I think I asked once before and was told I cannot do math across templates, if that makes sense, so I need to build the table as a simple template, to have access to all the values. I'm assuming that is that much rework is needed, it ought to be done in Lua.--S Philbrick(Talk) 22:09, 21 July 2014 (UTC)
For ease of access, Karl Smesko record
Statistics overview
Season Team Overall Conference Standing Postseason
Walsh University Cavaliers (Independent) (1997–1998)
1997-98 Walsh University 29–5 NAIA DII Champion
Walsh University: 29–5 (.853)
IPFW Mastodons (Great Lakes Valley Conference) (1999–2001)
1999-00 IPFW 13–14 9–11 8th
2000-01 IPFW 19–8 12–8 5th
IPFW: 32–22 (.593) 21–19 (.525)
FGCU Eagles (Independent (Division II)) (2001–2007)
2001-02 FGCU
2002-03 FGCU 30–1
2003-04 FGCU 18–8
2004-05 FGCU 21–9
2005-06 FGCU 29–2 NAIA DII
2006-07 FGCU 34–1 NAIA DII
FGCU (Independent): 132–21 (.863)
FGCU Eagles (Atlantic Sun) (2007–2014)
2007-08 FGCU 22–9 12–3 2nd WNIT Second Round
2008-09 FGCU 26–5 17–3 1st WNIT Second Round
2009-10 FGCU 24–7 17–3 2nd WNIT First Round
2010-11 FGCU 28–4 17–3 1st WNIT Second Round
2011-12 FGCU 29–3 18–0 1st NCAA First round
2012-13 FGCU 27–7 18–0 1st WNIT First Round
2013-14 FGCU 26–8 17–1 1st NCAA First round
FGCU (ASun): 182–43 (.809) 116–13 (.899)
FGCU (All): 314–64 (.831) 116–13 (.899)
Total: 375–91 (.805)

      National champion         Postseason invitational champion  
      Conference regular season champion         Conference regular season and conference tournament champion
      Division regular season champion       Division regular season and conference tournament champion
      Conference tournament champion

Tables / HTML

What is the correct sintax for some HTML code?

Variant A Variant B Variant C
background bgcolor=#RRGGBB style="background-color:#C0C0C0;" style="background:#C0C0C0;"
RGB - U/l #RRGGBB #rrggbb
RGB - 3/6 #RGB #RRGGBB

For now it's all, but I think I had something more :) And am I right, that mixing bgcolor and background/background-color in one article could cause some problems with some browser? I read about it in one talk page. And which is the place (Wikipedia, Internet) where I could get the correct sintax?

For the tables, I think the Help:Tables could be expanded (in code size). These are the changes (never mind the reference, it is unrelated). And the tool warned for the deprecated HTML elements. --Edgars2007 (talk/contribs) 15:06, 22 July 2014 (UTC)

Technically, variant B is the only correct one (though the RGB values may be specified using eiter 3 or 6 octets in either upper or lower case). Variant C will work, but is actually a shorthand for background-color, background-image and background-position combined. If you only want to change the color, don't use it to prevent potential CSS inheritance issues (when overriding it on a cell level for instance). -- [[User:Edokter]] {{talk}} 15:59, 22 July 2014 (UTC)
@Edgars2007: See Wikipedia:Village pump (technical)/Archive 127#Background colour on mobile devices regarding bgcolor= and compatibility. If you find that bgcolor= is still mentioned in help pages, please list them here and we'll fix them up. --Redrose64 (talk) 17:48, 22 July 2014 (UTC)
Thanks. @Edokter and Redrose64: What about making changes to Help:Table? --Edgars2007 (talk/contribs) 08:51, 23 July 2014 (UTC)
I have already amended it to not use the bgcolor= attribute (six weeks ago). What's still wrong with it? --Redrose64 (talk) 09:12, 23 July 2014 (UTC)
@Redrose64: I was talking about these changes (most of which were made with Dispenser Reflinks tool), there are some deprecated HTML elements, too. --Edgars2007 (talk/contribs) 13:54, 23 July 2014 (UTC)
I've eliminated all use of the bgcolor= attribute from Help:Table. Is any of the other deprecated markup actually causing problems? --Redrose64 (talk) 15:15, 23 July 2014 (UTC)
I just thought, that help page should represent correct sintax, so that people could use it (at least those, who read that page), but OK, if I'm wrong, then it's my problem :) And yes, I know about the WP:AINT. --Edgars2007 (talk/contribs) 15:26, 23 July 2014 (UTC)
There is a demonstrable problem with the bgcolor= attribute on mobile devices, this is mainly because that attribute was never a formal part of the HTML spec except when used in the <body> tag, so it is good practice to hunt down and fix such markup.
However, a lot of other deprecated markup was valid at some time or other - this includes align= on a <table>, <tr> or <td>; valign= on a <td>; and width= on a <th>. In particular, the border= attribute is still valid on the <table> tag and is not deprecated. Some of the changes made in that edit to User:Edgars2007/tables was completely unnecessary, such as changing underscores to spaces in the left-hand side of piped links, changing the case of hex colour values, and adding spaces in section headings. Trivial changes like those make it difficult to spot the real changes. --Redrose64 (talk) 16:25, 23 July 2014 (UTC)
The latest HTML5 draft is showing align= on <table>, <tr> or <td> under "11.2 Non-conforming features": "Elements in the following list are entirely obsolete, and must not be used by authors". border= on <table> is not showing as obsolete or deprecated, but the W3C validator gives a warning that "The border attribute on the table element is presentational markup". --  Gadget850 talk 17:02, 23 July 2014 (UTC)

RfC: Should the hidden navbar be removed from the base Stub and WikiProject banner templates?

Should the CSS-hidden navbar be removed from the base Stub (1.8 million pages) and WikiProject banner (5.5 million pages) templates? -- Netoholic @ 23:44, 22 July 2014 (UTC)

Survey

  • Remove - This {{navbar}} template call was added to the WikiProject banner back in 2008, but then immediately hidden by CSS (display:none) in {{WPBannerMeta/core}}. The same thing exists in the Stub base template {{Asbox}}. There is a CSS trick which editors can add to their custom CSS files, but this trick hasn't been publicized and is in use by only a handful of already experienced users. Even though it is hidden by CSS, it still adds a few hundred characters to every stubbed or bannered talk page download (and pages with multiple banners add it multiple times). The navbar template transclusion itself is called every time a page is saved (which for talk pages can be alot). Now, normally, we don't worry about performance, but in the template design space we do have to weigh the costs vs benefits, and since these templates are so widely used, I think every small efficiency we can do deserves consideration. The people that know about this hidden trick or would use it, are also experienced enough to get by without it on the rare occasions they need to edit a particular stub or WikiProject template. -- Netoholic @ 23:44, 22 July 2014 (UTC)
  • Procedural close as wrong venue. It has been pointed out before that RfCs are not hosted at VPT; if the template's own talk page is unsuitable (why might that be?), it's a WP:VPR matter. --Redrose64 (talk) 08:07, 23 July 2014 (UTC)
    This applies to templates, not policies, and is fairly technical to understand. And since the identical issue is present on two different templates, no one talk page is appropriate. -- Netoholic @ 09:05, 23 July 2014 (UTC)
    VPR is proposals, not policies. That page is currently carrying several RfCs, some of which are technical (including the very first one on the page). --Redrose64 (talk) 09:40, 23 July 2014 (UTC)

Threaded discussion

Need directions with MediaWiki:Spam-blacklist

There is a very simple way to bypass the MediaWiki:Spam-blacklist and insert any blacklisted link, and this was exploited recently. Where to report this bug for urgent attention? The related talk pages don't seem active, and, though the exploit is simple, I hesitate to post it in open. Any advice? Materialscientist (talk) 05:10, 23 July 2014 (UTC)

security wikimedia.org or bugzilla (check the options, public posting is the default). MER-C 06:51, 23 July 2014 (UTC)
https://bugzilla.wikimedia.org/enter_bug.cgi?product=Security allows creating a bug report with very restricted visibility. I am aware of some reports about Spam Blacklist, so dropping an email to the security mailing list might be less work to start with. :) --AKlapper (WMF) (talk) 09:32, 23 July 2014 (UTC)
There's no real problem here. It's well-known that it's trivial to bypass the spam blacklist. It's also not fixable, since fixing it would require checking the blacklist every parse, which has been tried before and undone because it was so bad for performance. Jackmcbarn (talk) 16:07, 23 July 2014 (UTC)

Problem with template

I'm not sure where to post this, but this seems a good fit. A 2013 (!) edit to Template:Current Kenyan MPs updated the template, but also changed something so that the information will not display. See my post on the talk page for a diff. This needs fixing. --Auric talk 13:45, 23 July 2014 (UTC)

Replied there. --Redrose64 (talk) 13:52, 23 July 2014 (UTC)

two annoying problems

I mostly edit from an iPad. So, a while back they switched in the mobile site by default. As it does not support admin tools I opted to go back to the desktop version. For some reason in the last 48 hours I keep getting sent to the mobile version at the start of each new session, even though I'm still logged in from before. I've searched my preferences and can't find anything in there to deal with this. Is there a way to permanently disable the mobile site?

Also, I though maybe I'd try asking the devs over at the technical forum on meta and it seems SUL is not working over there. I navigated there from here and when I got there I was not logged in and for some reason it is not accepting the password I use here. I may have had a separate password over there in the pre-SUL days but I certainly don't remember what it was now. Beeblebrox (talk) 21:05, 19 July 2014 (UTC)

Beeblebrox, I don't know much about tablets, but it sounds like the two most common problems when this happens are the user going directly to the mobile website via the URL (if you type "http://en.m.wikipedia.org", then you'll get the mobile site no matter what your prefs say and no matter what kind of device you're using), and corrupted cookies. So you might double-check the URL, and you might see if there's a way to clear cookies. If neither of those help, then perhaps someone else will know more than I do. Whatamidoing (WMF) (talk) 23:54, 19 July 2014 (UTC)
I've never navigated directly to the mobile site, so it's not that. I've had the same link in bookmarks for three years and it has always taken me to the desktop version of my watchlist. The way they do watchlisting on mobile is one of the worst things about it, I can't understand why anyone thought it was a good idea. I cleared all my cookies and loged back in and it took me to the mobile site again, so it looks like it's not that either. Beeblebrox (talk) 01:27, 20 July 2014 (UTC)
Hrm. @DGarry (WMF):? Ironholds (talk) 04:11, 20 July 2014 (UTC)
[Re: The second problem, your Meta account is attached to your SUL account, so you theoretically shouldn't have a problem logging into that site. Graham87 12:16, 20 July 2014 (UTC)
Tried again just now. Once I bypassed the mobile version over there, it prompted me to reload the page to apply my user settings, seems to be ok now. When I clicked back over here I got the mobile version again.... Beeblebrox (talk) 17:24, 20 July 2014 (UTC)

@Beeblebrox: For the questions about the mobile web interface, Maryana is your woman. For the SUL stuff, Special:CentralAuth/Beeblebrox says that Beeblebrox on Meta is attached to your global account, so I can't explain the issues you're having crossing wikis. Try totally clearing your browser cache and cookies, and if the problem still persists then, file a bug on Bugzilla with as much information as possible. --Dan Garry, Wikimedia Foundation (talk) 17:00, 21 July 2014 (UTC)

The SUL thing seems to have resolved itself, must have been a temporary issue. I've completely reset my browser, removing all history and cookies, twice. Pretty sure the problem is not on my end. But I have to say I hate the idea that I have to set up an account on another website to get attention to an issue on this website. If someone with a bugzilla account wants to copy this over that would be great:
  • Issue:persistently redirected to mobile site despite repeatedly trying to opt out. If I leave WP, even without logging out, when I return I am sent to the mobile site. I can see the URL for the desktop site actually change to the mobile site about a half second after I click the link. Have removed all cookies and cleared all history, issue is persistent.
  • Time frame: last 3-4 days
  • equipment: ipad2
  • OS:ios7.1.4
Thanks in advance, Beeblebrox (talk) 17:31, 21 July 2014 (UTC)
Tracked in Phabricator
Task T70347
  • Hmm, that's no good... Thanks for the bug report, Beeblebrox; I've added it to Bugzilla. Will get the devs to take a look. Maryana (WMF) (talk) 22:19, 21 July 2014 (UTC)
@Maryana (WMF): Ok, here's a weird thing: I went into my bookmarks menu to look at the actual URL, which did not have the "m" for the mobile site in it. I removed it anyway, went to my watchlist and added a new bookmark with the same URL and now it isn't redirecting me. I have no idea how that makes the least bit of sense but there it is. Beeblebrox (talk) 19:18, 23 July 2014 (UTC)
That could potentially make sense if the mobile redirect thingy is, or has ever been, using a wrong kind of HTTP redirect (permanent HTTP 301 instead of one of the temporary ones). I haven't checked if it does. Matma Rex talk 22:43, 23 July 2014 (UTC)

Padlock symbol

I have just repaired a broken-link footnote and now see a small padlock symbol beside the footnote in the "References" section of the article. None of the other footnotes show this symbol. Does this affect the footnote in any way? How can I ensure the symbol does not appear when I next mend a broken-link footnote? What does the padlock symbol mean anyway? You can see the padlock at footnote #171, "Another wave of bombings hit Iraq", in Islamic State of Iraq and the Levant. --P123ct1 (talk) 09:26, 23 July 2014 (UTC)

@P123ct1: The padlock appeared because you used a https: URL in this edit. The web.archive.org website allows both http: and https: forms, so you could have used http: - but it is better to omit it entirely, to give a protocol-relative URL.
Please note that a URL of an archive site shouldn't be put in the |url= parameter, but in |archiveurl= instead, like this. --Redrose64 (talk) 09:51, 23 July 2014 (UTC)
Thanks for making the adjustment. I had no idea about this. There is nothing in the Wiki help on link-rot about how to deal with archive.org URLs, or have I missed it? I have used the Wayback Machine a lot to mend broken links, but never had this problem before, so can only assume it always came up with an http. --P123ct1 (talk) 11:30, 23 July 2014 (UTC)
Some websites allow only the http: form; some allow only the https: form; some allow either. For those that allow either, it can normally be omitted - such as [//www.example.com Example web page] or {{cite web |url=//www.example.com |title=Example web page }}, and this is known as a protocol-relative URL. This does not work for bare URLs like http://www.example.com
The {{wayback}} template uses the https: form internally, so you always get the little padlock when you use that template. It should be possible to alter it to be protocol-relative, and I see from the template's talk page that a discussion was raised about six months ago on this matter, but which doesn't seem to have been resolved. --Redrose64 (talk) 13:47, 23 July 2014 (UTC)
I wonder why we kept the icon for HTTPS while removing all the others? (PDF is added locally). --  Gadget850 talk 20:32, 23 July 2014 (UTC)

Customizing top-of-page navigation links

Some questions about the navigation links that normally appear right-justified at the top line of the window (Username, Talk, Sandbox, Preferences, etc.):

  • Is "navigation links" the right term to use to refer specifically to the links that appear at the top of every page while viewing Wikipedia, or is there some other preferred term?
  • Is adding addPortletLink() statements to one's own "common.js" file still the recommended way of customizing these links, or has this been deprecated in favor of some other method?
  • Can the default links be removed or redefined? If so, how?
  • I can't seem to find any documentation for addPortletLink(); using Google I was able to locate only this brief discussion. Help?

Thanks, — Jaydiem (talk) 19:48, 23 July 2014 (UTC)

The gadget 'Add a "Sandbox" link to the personal toolbar area.' calls it the "personal toolbar area" but its script calls it the "personal portlet menu"; it uses mw.util.addPortletLink(). --Redrose64 (talk) 20:10, 23 July 2014 (UTC)
There is some documentation here. -- WOSlinker (talk) 20:22, 23 July 2014 (UTC)
I don't know about removing links, but I was able to add one. Look for the portlet code in User:Jonesey95/vector.js. — Preceding unsigned comment added by Jonesey95 (talk • contribs) 20:37, 23 July 2014 (UTC)
There is proper documentation for addPortletLink here. —TheDJ (talk • contribs) 07:12, 24 July 2014 (UTC)

Missing reference markup will no longer show an error

Tracked in Phabricator
Task T69847
Tracked in Phabricator
Task T69700
Resolved
Tracked in Phabricator
Task T69845
Duplicate
Tracked in Phabricator
Task T70324
Declined

As noted above, "If you use references on a page, you will soon always see them at the bottom of the page, even if you forget to add the <references /> tag (or a template)."

This has been deployed and has a few issues:

  • It does not work for reference lists with groups. T69847
  • There is no tracking category. T69700
  • A missing </ref> no longer generates the missing reference list error, it now mangles the following rendered markup. T69845

More discussion at Help talk:Footnotes#Missing reference markup will no longer show an error. --  Gadget850 talk 11:08, 11 July 2014 (UTC)

@Gadget850: T68700 doesn't look related, did you mean something else? — This, that and the other (talk) 11:22, 11 July 2014 (UTC)
Fixed. Thanks! --  Gadget850 talk 11:29, 11 July 2014 (UTC)
T69854 doesn't exist? --Redrose64 (talk) 12:09, 11 July 2014 (UTC)
T69845. --Glaisher (talk) 12:13, 11 July 2014 (UTC)

Can the auto system be upgraded to add a References section header, and keep the references section at the bottom? We are now getting talk pages, with no separation between one post and the ref-list, and another post is then added beneath it e.g. Talk:Soka Gakkai where it appears that the references relate to the post above them, although they don't.

The current arrangement means that, althiough the list appears, someone has to go around and manually add the ==References== section header, which is also one of the most common misspellings (I have corrected "Refrences" at least once in 140 of the last 142 weeks, plus the corrections to "Refferences" "Referrences" and "Referneces") - Arjayay (talk) 13:37, 12 July 2014 (UTC)

Depending on how T69700 is resolved, I would add namespace detection like we do with the other cite errors. On talk pages, we could just not show the list or show it with a header. --  Gadget850 talk 23:21, 12 July 2014 (UTC)
Looking at the patch, I think it is just going to add a maintenance category, which would be blank by default. I will have to see this implemented to see how it actually works. --  Gadget850 talk 23:38, 12 July 2014 (UTC)
@Arjayay: Based on your post, I created Wikipedia talk:AutoWikiBrowser/Feature requests#Update FixHeadings to fix misspelling of References. GoingBatty (talk) 17:41, 13 July 2014 (UTC)
Thanks - but if it automatically added the (correctly spelled) References section, this would not be necessary. - Arjayay (talk) 17:48, 13 July 2014 (UTC)
It won't. And the auto reference list will always be put in the wrong place. If we had kept the previous error checking, then we could have done this. --  Gadget850 talk 13:25, 14 July 2014 (UTC)
The tracking category should be deployed in 1.24wmf14. --  Gadget850 talk 15:59, 16 July 2014 (UTC)
  • T70324 - Cite: Add namespace detection for automatically generated reference list --  Gadget850 talk 15:05, 21 July 2014 (UTC)

Adding this feature caused explosion on pages with missing references section. -- Magioladitis (talk) 18:02, 21 July 2014 (UTC)

Details please. What sort of explosion? Example? --  Gadget850 talk 17:14, 24 July 2014 (UTC)
Gadget850 me and Bgwhite and perhaps more, fix daily Page with references list missing. Last month there were very few pages so we could fix them manually, checking for vandalism etc. The last days we have to fix more than 100 pages per day. At some point I had to use my bot. Bgwhite asked help from other bots that add references lists because as far as I remember some other bots were also checking for references lists removed and had better performance than AWB. -- Magioladitis (talk) 17:27, 24 July 2014 (UTC)

Copyright detecting bot

Dear technical experts: When I first joined Wikipedia I remember that there was a bot that went around checking and tagging pages for copyright violations. I haven't seen any pages so tagged for some time, and of course the ones it tagged have either been deleted or had tags removed. Can someone tell me the name of this bot and if it's still around? It appeared to be very useful. —Anne Delong (talk) 05:07, 21 July 2014 (UTC)

User:CorenSearchBot and WP:SCV? MER-C 05:23, 21 July 2014 (UTC)
Also see WT:MED#Exhausted which points to WP:Turnitin. CorenSearchBot handles new pages only, not changes to existing pages, and the others are hopes that something might be done for additions to existing pages. Johnuniq (talk) 06:25, 21 July 2014 (UTC)
As noted above CSB only searches new pages. If you want to see some, see Wikipedia:SCV. There are dozens of new ones every day, and not a lot of editors clearing them. If anyone has any spare time...--S Philbrick(Talk) 19:47, 21 July 2014 (UTC)
If the bot only tags new mainspace articles, that explains why I haven't encountered it lately. I've been working mainly with pages in the Category:G13 eligible AfC submissions, which are all at least six months old, although, surprisingly, many of them are copyright violations. It would be nice if the bot could also check newly created pages in the Draft: namespace. Thanks for taking time to reply. Sorry, I won't have spare time to help with that backlog until I clear out my own. —Anne Delong (talk) 20:30, 23 July 2014 (UTC)
CorenSearchBot misses many that would be easily found with a Google search. This is in part because CorenSearchBot (and MadmanBot, which I believe is a clone) are not permitted to use Google search per Google's Terms of Service. This is a place where a phone call from the Foundation might solve a big problem. --j⚛e deckertalk 19:12, 24 July 2014 (UTC)
Ah! MadmanBot is the one I remember seeing. Does it check AfC pages? There are other search engines. It would also be nice to have a process that would go through a pre-prepared list of links to articles. —Anne Delong (talk) 19:26, 24 July 2014 (UTC)
Yeah, I've seen it catch some things at AfC, for sure. A lot of those get handled quickly, so if you don't spent a lot of time at the most recent end of the "0 days" category, you may not have seen them But you are absolutely right that too much slips through, when I was playing with G13s before there was a G13bot, I can't begin to tell you how many things marked "advert" were also copyvios, it was insane.
When I was noticing that, I looked into feeding MadmanBot (or one of the other CorenBot-alikes) the G13s, and none of them came out hits. You can point it at individual pages at User:MadmanBot/manual. That's what led me, along with some other evidence and discussion, to my conclusion regarding Google. --j⚛e deckertalk 20:09, 24 July 2014 (UTC)

Watchlist on Android beta

I regularly use my Android mobile phone to look for changes on my (ridiculously large) watchlist: we're a two-person one-computer household. I'm using Beta but not "experimental". I have set my watchlist to "Hide bot edits from the watchlist", in my preferences. This works fine on the desktop, but seems to be ignored on the mobile: every bot edit is still listed.

Three other annoying factors about the mobile watchlist:

  • The only way to see User Talk pages is under "all"
  • There is no "more" option at the bottom of each list, so the system restricts how many changes are shown
  • Multiple changes to one page are all shown individually, rather than aggregated as on the normal watchlist.

Like many people, I have DGG's talkpage watchlisted. He currently gets a massive number of separate messages from HasteurBot every morning. As a result, I cannot see on my mobile watchlist any changes made to User talk pages between the last time I looked and about 2am UK time: the day's bundle of HasteurBot messages shifts anything earlier into invisibility.

Is there any chance of any of the 5 contributing factors being fixed?

  1. Make the "hide bot edits from watchlist" preference work on mobile
  2. Add a "more" option at bottom of watchlist listings on mobile, so I can see the rest of the changes
  3. Create a 5th heading for the mobile watchlist, for "User talk" (or include them in "Other")
  4. Aggregate changes to a page so that they list as one item in the mobile watchlist, capable of expansion, as on the desktop version
  5. Get HasteurBot to aggregate its daily messages per talk page.

I get the feeling that mobile users are considered to be the great unwashed, encouraged to upload photos but not expected to be serious editors. More and more people expect to be able to use their phone for a wide range of activities, and aren't always sitting at a desktop. Please can someone offer some help in this area of mobile watchlists? Thanks in advance! PamD 07:19, 22 July 2014 (UTC)

bugzilla:68365, bugzilla:68367, bugzilla:68368, bugzilla:68369. And it is not 'unwashed', it is strategy. The thing is still being build and the initial focus was to make Wikipedia accessible to readers on Mobile devices. Only THEN the team would start looking at what editor related functions would make sense on mobile and slowly build that out. —TheDJ (talk • contribs) 10:02, 22 July 2014 (UTC)
Thanks. Will await progress with interest. PamD 21:22, 22 July 2014 (UTC)
Also just realised: "Hide my own edits" doesn't work either. Can't face trying to read or edit Bugzilla on mobile. PamD 22:01, 25 July 2014 (UTC)

Can you transclude pages from other projects?

I would like to transclude Tech News weekly summaries on my user page: {{m:Tech/News/Latest}}. Is this possible? Wbm1058 (talk) 14:16, 23 July 2014 (UTC)

Or a solution similar to {{Signpost-subscription}} for Tech News? Wbm1058 (talk) 14:26, 23 July 2014 (UTC)
It's not possible to transclude across wikis. A number of things would be much easier if it were. Re your second suggestion: you could ask for this at m:Talk:Tech/News. --Redrose64 (talk) 15:06, 23 July 2014 (UTC)
@Redrose64: Thanks for the tip to look at that talk page, where I found the section Template for user pages?, which pointed me to {{Latest tech news}}. Just what I was looking for! Look at the syntax of that template code. I'll have to study that to figure out how it magically transcludes the current news. Wbm1058 (talk) 16:14, 23 July 2014 (UTC)
I see that I'm just the third editor to transclude {{Latest tech news}}. A tip of the hat to the Technical Communications Manager, Wikimedia Foundation for creating it. Wbm1058 (talk) 19:45, 23 July 2014 (UTC)
He also set up Wikipedia:Tech news and signed that page up for Global message delivery of the news from meta. #lst: must be a parser function for the last section on the page (i.e., the most recent mass message delivery is added at the bottom). Nice! I don't see #lst: documented at Help:Magic words. @Guillom: Where is that documented? Wbm1058 (talk) 20:16, 23 July 2014 (UTC)
#lst is labeled section transclusion. But it won't work across wikis. It is not documented at Magic Words because it is part of a software extension. --  Gadget850 talk 20:18, 23 July 2014 (UTC)
Thanks, I recall having run into documentation of that feature before but had never seen it in action, and this specific example is helpful. I just noticed the <section begin="technews-2014-W17"/> and <section end="technews-2014-W17"/> tags etc. in Wikipedia:Tech news that make it work. Too bad that per mw:Extension:Labeled Section Transclusion#Transcluding sections by headings we can't just use the regular headings, but I guess the work-around isn't that difficult.
Is there a list of all the extensions that are enabled on English Wikipedia anywhere? Wbm1058 (talk) 01:08, 24 July 2014 (UTC)
See Special:Version for a listing. Fwiw... we use #lst like crazy over on Wikisource and have scripted/templatized several solutions to make using it a bit easier, though still nothing simple abut using "regular" headings there as well. -- George Orwell III (talk) 01:50, 24 July 2014 (UTC)
... and fwiw - I recall cross-domain transclusions through the API are possible with some scripting(?). Somebody tried something like that with s:MediaWiki:InterWikiTransclusion.js but we never really wound up using it so I can't tell you much more about it. -- George Orwell III (talk) 01:58, 24 July 2014 (UTC)
We use {{#lst:}} for the Citation Style 1 error help pages to transclude the help section to the tracking category. I have used it a few other places. --  Gadget850 talk 02:15, 24 July 2014 (UTC)
Wbm1058: I just saw your notification, and I see you've found the answers you were looking for :) I'm glad {{Latest tech news}} is useful. Let me know if you have any follow-up questions about Tech News or LST. guillom 08:17, 26 July 2014 (UTC)

User:Mr.Z-man/closeAFD.js (2)

... does not seem to be working properly (it's been a while since I was going through the AFDs, back in March it was still fine). I found that a similar problem has been discussed back in 2012 already, then fixed. But there may be another reason now. Help kindly requested. --Tone 20:45, 23 July 2014 (UTC)

Is it still not working for you? I just closed Wikipedia:Articles_for_deletion/Dunmore_Candy_Kitchen successfully with it. --j⚛e deckertalk 18:41, 24 July 2014 (UTC)
What exactly is wrong with it? I've closed several in the past month, seemed to be working fine. Ansh666 08:43, 25 July 2014 (UTC)

Automatically generated reference lists- tracking

With the deployment of 1.24wmf13, a page with <ref> tags but no the reference list markup ({{reflist}} or <references>) no longer generates an error. Instead, the reference list automatically shows at the bottom of the page.

The automatically generated reference list (AGRL) has issues: it is always at the very bottom of the page, has no heading and can be displayed oddly depending on the markup before it (T70293).

1.24wmf14 will be deployed later today. It adds a tracking category so we can locate and fix AGRL issues. The category is set through MediaWiki:Cite error refs without references category and I have set it to Category:Pages with an automatically generated reference list. I have added namespace detection so that user and talk pages are not categorized per previous consensus. The AGRL will still show on user and talk pages, it just won't show in the tracking category.

--  Gadget850 talk 17:34, 24 July 2014 (UTC)

This is all super-awesome. Thank you. --j⚛e deckertalk 18:42, 24 July 2014 (UTC)
The patch cause strip markers to be exposed and was reverted. --  Gadget850 talk 21:01, 24 July 2014 (UTC)
Ah well. In time, I'm sure. The idea is still excellent, I think. --j⚛e deckertalk 22:45, 24 July 2014 (UTC)
At the moment, there are a few hundred pages listed in this category, and almost all of them are old AFDs. WhatamIdoing (talk) 18:58, 25 July 2014 (UTC)

Job queue rate

It's pretty easy to get the Help:job queue size in number of items, does anyone have any intuition about the rate jobs are processed from it? I had a request for a null bot job that I don't think should be required, the JQ is about 80K entries right now, but I don't have an intuitive sense of whether that represents a second, a minute, an hour, a day or a week in terms of latency. --j⚛e deckertalk 18:36, 24 July 2014 (UTC)

So, [69] is the graph of hourly job queue rates, but it applies to the entire cluster, not just enwp. Legoktm (talk) 23:37, 24 July 2014 (UTC)
Legoktm, there's five graphs there, with dozens of numbers in the images. Which one of those numbers is the best one for estimating how long typically elapses between a job being submitted and a job being completed? WhatamIdoing (talk) 19:04, 25 July 2014 (UTC)
There is some lack of clarity in what is being graphed there. The green parts of graphs 1 and 2 at least are "jobs per minute", which contradicts the title of the page and Kegoktm's comments, which suggest hours, not minutes. I actually expect that graph 1 and 2 might be in jobs completed per hour, but I find it difficult to read graphs 3 and 4 in a manner consistent with what graphs 1 and 2 would suggest. The big y axis jump in graph 4 only makes sense if 1 and 2 are per minute, though. Hmm.--j⚛e deckertalk 21:36, 25 July 2014 (UTC)

some sort of mediawiki error is happening

copied from ANI Compare these two diffs, both which are doing mass replacements. (Or there is a very unsubtle sock)

This appears to be a known issue, but this appears to have been "resolved" quite some time go https://www.mediawiki.org/wiki/QINU_fix

Any way to escalate this to someone? If this isn't socking (which based on the bug report seems likely) then this is probably happening all over the wiki currently. Gaijin42 (talk) 19:28, 24 July 2014 (UTC)

Yep, it's happening here to the refs: User:NE2/temp --NE2 19:46, 24 July 2014 (UTC)
@Gaijin42 and NE2: Yeah, we spotted this after this morning's deployment and just un-deployed the code in Cite that changed – it should now stop recurring. Sorry for the disruption! Jdforrester (WMF) (talk) 20:15, 24 July 2014 (UTC)
What do we do with all the errors that have already happened? There are about forty instances of "UNIQ..." all over the help desk; how do we figure out what the posts meant? Altamel (talk) 01:26, 25 July 2014 (UTC)
These are exposed strip markers; see Help:strip markers. It is going to be hard to figure out what those markers originally were; you can only pick out the parser tag that caused it to be exposed. --  Gadget850 talk 01:57, 25 July 2014 (UTC)
Talk pages are minor compared to the articles, such as Neeloor. --  Gadget850 talk 02:05, 25 July 2014 (UTC)
I have the "new search" turned on, searched for "QINU" in all namespaces, then searched within the results for "24 July 2014" and "25 July 2014". That identified about 20 pages, which I fixed, though some only needed a purge. Is that the lot? What is the lag in the "new search" results? -- John of Reading (talk) 08:18, 25 July 2014 (UTC)

Missing toolbar

The toolbar under the edit window used for insertion of special characters has disappeared. I have checked Preferences->Gadgets->Editing to make sure that CharInsert box is ticked, which it is. How can I recover the toolbar? Brianboulton (talk) 20:30, 24 July 2014 (UTC)

I still seem to have it. Johnbod (talk) 13:59, 25 July 2014 (UTC)

Can the email throttle be bypassed?

A user is asking at User talk:Taylordw#Question for administrator whether the email throttle limiting the number of emails sent in 24 hours can be bypassed for a particular purpose. He has a reason for wanting to use email rather than a mass message to talk pages. My question here is, is that technically possible? It is not one of the standard user-right groups in WP:User rights. JohnCD (talk) 21:36, 24 July 2014 (UTC)

Technically, yes. Several groups have the noratelimit right, which would remove the throttle. Among them are 'crats, admins, and, notably, accountcreators and bots. I saw that adminhelp you're referring to and thought about it a bit; I thought that it was a thing to ask BAG about (basically, create a mass-email bot account and send it to BAG for approval), but after asking some people about it, they didn't think that would fly. (After doing so, I meant to leave a note to that user, letting them know I was looking into it, but apparently I forgot; that was my fault, and I'm sorry for it.) Simply granting them accountcreator would work, of course, and I suppose it's within the realm of simple admin discretion, but I'm a bit leery of that personally, since it's not what accountcreator is meant for. But yeah, it's technically possible. Writ Keeper ⚇♔ 21:50, 24 July 2014 (UTC)
Thanks. I think this is a case for WP:IAR, but I am not quite comfortable with doing it off my own bat, so I have asked at AN if there any objections. JohnCD (talk) 15:34, 25 July 2014 (UTC)

User analysis tool missing the graphs

Hello! I keep a link to the User Analysis Tool on my userpage, and I was checking it today when I found that neither the pie chart of edits by namespace nor the bar graph of edits by month are showing. Is this happening for anyone else, and if so is there a way to correct it? Howicus (Did I mess up?) 22:15, 24 July 2014 (UTC)

I left a note at User talk:cyberpower678. He supports this. Wbm1058 (talk) 02:56, 25 July 2014 (UTC)

Leaving messages

If a message is left on a general Talk page or Help desk for a particular user in this form, @Username:, is the user automatically alerted that they have a message? --P123ct1 (talk) 08:34, 25 July 2014 (UTC)

@P123ct1: Yes, provided that (a) the link to the user's home page (which might be in the form of a {{replyto}}) gets added in the same post that your signature was added and (b) at Preferences → Notifications they have "Mention" enabled (for either Web or Email); if it's enabled for web only, they also need to have "⧼echo-pref-new-message-indicator⧽" (on the same page) enabled. More at WP:ECHO. --Redrose64 (talk) 09:23, 25 July 2014 (UTC)
Thanks, Redrose. --P123ct1 (talk) 09:47, 25 July 2014 (UTC)

pdf format

I am not at all sure this is the right place for this query. I cannot use all the functions in some pdf files (e.g. in footnotes) on my new laptop, e.g. Search and Go to page number. Do I need to update some software in my laptop, and if so, how, please? For technical questions that are not directly related to Wikipedia, is there a forum on Wikipedia that can deal with them? --P123ct1 (talk) 09:47, 25 July 2014 (UTC)

@P123ct1: Yes, it's WP:RD/C. --Redrose64 (talk) 09:54, 25 July 2014 (UTC)
Thanks again. --P123ct1 (talk) 13:36, 25 July 2014 (UTC)

Searching the Wikipedia archives

I want to find a long post I made, either on the main Help Desk or on a Wikipedia article Talk page, but can only remember the month I made it (April this year) and the content, not where I posted it. I have tried to locate it but without success. Is there some way I can do a global search using key phrases from my post and my username? Even looking at the list of topics for each month in the main Help Desk archives is not going to help, as I cannot remember exactly what topic I was posting under. Can I do a global search of all the posts I have made since the beginning of the year? The User Contributions list will not help either because I can't use key phrases to search it. Does Wikipedia have a brilliant data-mining tool that I don't know about? --P123ct1 (talk) 13:36, 25 July 2014 (UTC)

http://en.wikipedia.org/w/index.php?limit=50&tagfilter=&title=Special%3AContributions&contribs=user&target=P123ct1&namespace=1&tagfilter=&year=2014&month=3

84.106.11.117 (talk) 13:41, 25 July 2014 (UTC)

When I've wanted to do this before I just use Google specifying site:en.wikipedia.org I'd be surprised if you couldn't find it pretty quickly. QuiteUnusual (talk) 13:49, 25 July 2014 (UTC)
This one, and following edits?. You only started editing just before so your "Contributions" set to "Oldest" found it very quickly. Johnbod (talk) 13:56, 25 July 2014 (UTC)

CSS code to change the background color to black and font color to green

Hi all! I don't know anything about CSS. Could someone write a CSS code for me to change the background color of wiki to black and font color to green please? I'll put this code onto my preference section within my account so that I can view wiki in black color with green words. Thank you~ — Preceding unsigned comment added by Saucelord (talk • contribs) 19:32, 25 July 2014

Hey, Saucelord! This actually already exists in your Special:Preferences page. First, go to the "Appearance" tag and switch to the "Monobook" skin (by switching to the Monobook radio button and hitting the Save button at the very bottom). Then go to the Gadgets tab and, at the bottom of the "Appearance" section in that tab, check the box for "Use a black background with green text on the Monobook skin" and hit the Save button at the bottom again. It's not perfect, but it might get the job done. Writ Keeper ⚇♔ 19:52, 25 July 2014 (UTC)

Wow, it works! Thank you, Writ Keeper! That is really what I exactly needs! I am happy~~ — Preceding unsigned comment added by Saucelord (talk • contribs) 01:43, 26 July 2014

Looking for user script

Is there, or can there be a script that would change selected/detected ALL CAPS as in this diff ? I assume maybe AWB has a setting for this but, I'm hoping for a .js script or something or even a lab tool. Thanx, Mlpearc (open channel) 18:54, 23 July 2014 (UTC)

Mlpearc, how often do you need to do that? If not very often, you can convert text to lower case in the JavaScript console of your browser (press F12 to open it) like this: "MAJESTY KING ZWELITHINI".toLowerCase() If you want title case, that will be a little bit more code. You can try User:V111P/js/Templates/Textarea1.js to see if you need a script like that one, it is an example script that replaces all spaces with underscores in the text you selected in the textarea (when editing the wiki source code). You run it by pressing its button in the toolbar. --V111P (talk) 05:29, 27 July 2014 (UTC)
Obviously not very often, I figure why not convert it as found. Thanks for the reply, I'll play around with the F12 function and figure it out. Thanx, Mlpearc (open channel) 18:18, 27 July 2014 (UTC)

If someone comes to my talk page in all caps I just slap a LOWER CASE SPAN AROUND THE SHOUTING(<span style="text-transform:lowercase;">). I wonder if there is a template for that? Chillum 18:26, 27 July 2014 (UTC)

Custom sig formatting issue

Sometime during the last few months; and I hope it's visible to most reading this and is not just on my end; I've noticed that when signing my sig it has started to leave a rather annoying leading inter-line space before the last line of text I write. This has never been an issue before and I don't think this has anything to do with my browser (Firefox), skin (Vector), or preferences as they have not changed in years. What has changed fairly recently, I notice, is the typography the entire site uses, and I think what's behind the issue is the superscripted ™ after my 'ligature' pushing the last line of text down. Okay okay I know how pretentious my sig looks with a bogus 'trademark' symbol that links to my talk page.. but if it's all the same I've been using this crazy sig for many years and have grown accustomed to it so I'd rather not alter it nor change my default skin. So wondering if there's any workaround where I can avoid this unsightly line gap but still retain the superscripted ™? If that is even the issue, and assuming the site-wide typography change is permanent.. -- œ™ 20:42, 25 July 2014 (UTC)

@OlEnglish: It's not the superscript (although superscripts and subscripts used to cause this, but it was fixed a long time ago), it's the huge font size. It also causes a gap below your signature, not just above. Matma Rex talk 21:00, 25 July 2014 (UTC)
The <font> tag is deprecated. You should swithc to CSS. The following should work (it also reduces the font size): <span style="font-size:1.6em;line-height:.8em;">œ</span>, which results in œ. -- [[User:Edokter]] {{talk}} 21:11, 25 July 2014 (UTC)
Great! thanks, that did the trick. Just wondering though, if the <font> tag still works, and causes the overall sig code to be shorter/simpler, then why not still use it? I'm guessing it's because not all browsers support it? -- Ϫ 00:31, 26 July 2014 (UTC)
It is deprecated in HTML5 which we use now. It still works, but it runs the risk of not working one day, when the tag is declared obsolete. -- [[User:Edokter]] {{talk}} 08:40, 26 July 2014 (UTC)
If you noticed above, the css formating works, but it still leaves the gaps above and below, like Matma Rex said it is because you are changing the font size. — xaosflux Talk 12:12, 26 July 2014 (UTC)
The line-height property controls the line height (and thus the "gaps"), and it is used here (<font> doesn't allow that) clearly with the aim of getting rid of them. However, I have no idea how Edokter arrived at the value of 0.8 em for it, perhaps it's just an educated guess :) Matma Rex talk 19:06, 26 July 2014 (UTC)
Just a bit of trail and error. With a font zise of 1.6em, the added height disappeared with .8em (with default fonts etc.). Different fonts may behave differently though. -- [[User:Edokter]] {{talk}} 20:10, 26 July 2014 (UTC)

tl:fbas

I have an idea: Let's create a new template "fbas" which would produce a flagicon & wikilink to a national football association article, instead of this full code:

{{flagicon|GER}} [[German Football Association|Germany]] – code used in many many articles

{{fbas|GER}} – my idea

  Germany – result of both

But how to do it? Maiō T. (talk) 15:08, 26 July 2014 (UTC)

@Maiō T.: What's wrong with {{fb|GER}} →   Germany ? --Redrose64 (talk) 16:25, 26 July 2014 (UTC)
It's a different article. (national team instead of national F.A.) Maiō T. (talk) 16:31, 26 July 2014 (UTC)
Well, why not add a new parameter to {{fb}} - this would avoid creation of a new template. Incidentally, have WT:FOOTY been informed? --Redrose64 (talk) 17:12, 26 July 2014 (UTC)

  Done Copied to WT:FOOTY. Maiō T. (talk) 17:28, 26 July 2014 (UTC)

Global gadget for LinkFA

Hi!

I would like your input on this: MediaWiki talk:Common.js#Global gadget for LinkFA. Helder.wiki 16:14, 26 July 2014 (UTC)

Discretionary Sanctions Template Edit Request

The {{Discretionary sanctions}} template has a few issues. The documentation says user can just add the code and the style into the template, but that does not work. For it to work properly, we must use "topic=" and "style=". For example:

{{Discretionary sanctions|pa|long}}, as suggested by

{{Discretionary sanctions|topic=pa|style=long}}

My template-fu is too weak to figure this out in any timely fashion. Are any template experts able to fix this? Thank you! EvergreenFir (talk) Please {{re}} 16:58, 26 July 2014 (UTC)

Afterthought: The topic=/style= method would have to be preserved as that's what talk pages user now. Also, I tested it on another topic code and still the same issues. EvergreenFir (talk) Please {{re}} 17:00, 26 July 2014 (UTC)
This edit should do it. Basically, when a parameter has aliases (in this case {{{topic|}}} {{{t|}}} and {{{1|}}}), every time one of them is used, the others must be used as well. There were four uses each of {{{topic|}}} and {{{t|}}} but only one {{{1|}}}. --Redrose64 (talk) 17:26, 26 July 2014 (UTC)
@Redrose64: Awesome! Any chance you can get the style= to do the same thing? EvergreenFir (talk) Please {{re}} 17:30, 26 July 2014 (UTC)
It already did. In your first demo above, you used {{Discretionary sanctions|pa|brief}}. Try adjusting that to match the text preceding your words "as suggested by". --Redrose64 (talk) 17:32, 26 July 2014 (UTC)
So I did... the dangers of copy-paste. Thank you again!!! EvergreenFir (talk) Please {{re}} 17:39, 26 July 2014 (UTC)

Yet again a trouble for android users

Tracked in Phabricator
Task T50544
Tracked in Phabricator
Task T67039

Hello there, I'm having a trouble. Why I can't check my contributions through this from android?? And yes I'm a IP user. Yes, I'm a proud IP, I'm - 101.221.128.220 (talk) 18:07, 26 July 2014 (UTC)

Are you using Andoid web or the Android app? Whatamidoing (WMF) (talk) 22:26, 27 July 2014 (UTC)
I can confirm using the Android web version it leads to a page saying "No such page" when visiting Special:MyContributions and not logged into an account. It works fine when logged in. I don't have the app so I didn't test that. Killiondude (talk) 23:59, 27 July 2014 (UTC)
It looks like there are a couple of related bugs open. User:Maryana (WMF) will know whether this is a separate one. Whatamidoing (WMF) (talk) 01:56, 28 July 2014 (UTC)
Thanks. I believe it's bugzilla:65039 but the OP conflated two issues. I made a comment there about it. Killiondude (talk) 02:09, 28 July 2014 (UTC)

auto-reviewing not working?

Have a look at the history of Arijit Singh. The article is configured to automatically accept edits by auto-confirmed users. It was vandalized and then reverted by ClueBot NG, yet the bot's edit is still shown to be "pending review." Anyone know what's going on? --Ixfd64 (talk) 15:56, 27 July 2014 (UTC)

@Ixfd64: Isn't that because the earlier edits by Deepedits still needed to be reviewed? -- John of Reading (talk) 17:54, 27 July 2014 (UTC)
Exactly, Clue Bot reverted to a revision which was still pending review. If it had reverted to an accepted revision, its edit would be marked as accepted as well. The same is true for all reviewers - if you revert to a pending revision, you still need to manually accept it afterwards. 2Flows (talk) 19:27, 27 July 2014 (UTC)

Sourcing a footnote

I wasn't sure where else to post this. I found a source for the second footnote here, but apparently, I can't insert reference formatting inside reference formatting. What would be the best way around this? Airplaneman ✈ 22:15, 27 July 2014 (UTC)

@Airplaneman: The best way would be not to use a footnote: if it's worth referencing, it's worth being placed in article body text. However, an awful, awful way of nesting references, which you should never use, is descibed at WP:REFNEST. Matma Rex talk 22:44, 27 July 2014 (UTC)
Thanks, Matma, I'll look into it! Airplaneman ✈ 22:47, 27 July 2014 (UTC)

Custom edit of Template:Infobox language possible?

OK. I have a situation on the Cree language page where the Infobox for that page has the wrong information. One of the Infobox lines is for ISO-639-3, where it lists cre – inclusive code, then goes on to list 9 dialects. Only problem is that cre covers 6 of those dialects, and the other 3, though part of the Cree language, are not part of the cre ISO 639 macrolanguage code. However, the template won't allow me to list 4 ISO-639-3 codes, with the fourth one being the cre, and then having the remaining 6 displayed. If I want to have such a custom display, how would I go about doing it without recreating the template from scratch? Is there a way I can enter commands to custom edit that template? I had originally asked this question at WP:HD on July 24, and it was recommended that I pose the question here. CJLippert (talk) 23:10, 27 July 2014 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_128&oldid=1211997200"