Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VP/T)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to or filed under the "Security" product in Bugzilla.

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

« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127
Centralized discussion
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.


Closed AFDs not displaying on mobile version[edit]

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 (talkcontribs) 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}} (etc) 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). by Xaosflux. I'll complete his request for 25 trials in each prefix tomorrow. (bed time for me here). — {{U|Technical 13}} (etc) 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)
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}} (etc) 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)

Missing piece of wiki table syntax/markup?[edit]

Prompted by this.

In tables, wiki syntax/markup offers...

| ... || ... || ... || (etc) an alternative to...

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

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

| ... || ... || ... -|
| ... || ... || ... -|
| ... || ... || ... -|
| (etc) 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 (talkcontribs) 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 Farmbrough13: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 Farmbrough17: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) [ -| ]*

* 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 Farmbrough23:33, 5 July 2014 (UTC).

Any further thoughts / advice re Wikipedia:Village pump (technical)#Missing piece of wiki table syntax/markup?...? (Maybe I should enquire at
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,[1] 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? 00:34, 11 July 2014 (UTC)

Toolserver shut down[edit]

No more reflinks[edit]

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

FYI: The reference converter seems to be shut down

I just saw the following error when visiting both and

"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 (talkcontribs) 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 () {
  "p-tb",     // toolbox portlet
  "" + 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,, 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}} (etc) 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}} (etc) 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: --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 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 (tc) 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[edit]

"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 (talkcontribs) 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 (talkcontribs) 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 [5] 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, 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'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 Farmbrough22: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 Farmbrough01:45, 7 July 2014 (UTC).

Other tools[edit]

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?[edit]

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)

Also Scottywong's tools[edit]

  • 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> or" "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', '//' + 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?[edit]

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[edit]

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?[edit]

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. - NeutralhomerTalk • 00:35, 2 July 2014 (UTC)

Seriously, no alternative to Checklinks exists? - NeutralhomerTalk • 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)


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 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[edit]

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[edit]

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[edit]

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)
    • +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}} (etc) 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 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?[edit]

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 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
(tJosve05a (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 and 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. 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 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[edit]

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[edit]

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 [{{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)

==Watchlist (external link)==

Editing tools (external links)[edit]

There are various "tools (apps)" intended to simplify, make more efficient, or provide additional functionality to Wikipedia. The most common are listed below, for a listing of tools and editing aids see Wikipedia tools and Tool Labs.

  • Reflinks - edits bare references by adding title, dates, authors, publisher and more to bare references.
  • Checklinks - allows you to tag, search and repair external links.
  • Dab solver - allows you to easily resolve ambiguous links.
  • Citation tool for Google Books - converts a bare Google Books URL into a filled-out {{cite book}} template ready to be pasted into an article.

New "insource" search not working (for me)[edit]

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[edit]

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 (talkcontribs) 08:52, 12 July 2014 (UTC)
@George Orwell III, 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"?>
    <page ns="10" title="Template:Cite web" purged="" linkupdate="" />
    <n from="Template:Cite_web" to="Template:Cite web" />
.... 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)

New search history tool[edit]

@Hedonil: The new search history tool at 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)

WHOIS for IPs[edit]

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 [6][7] show some other MediaWiki namespace pages with "". PrimeHunter (talk) 13:12, 3 July 2014 (UTC)
(edit conflict) @Nyttend: "14:08 < Betacommand> or more generic" 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)
Yes check.svg 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)

MW extension "Manage template documentation" now affecting every template[edit]

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 bug 63389 (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 TemplateData 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). 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[edit]

So apparently there was further discussion, and today's story is: You can't transclude TemplateData. That problem is now bug 67677 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[edit]

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), 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[edit]

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. 12:28, 11 July 2014 (UTC)
@Mr. Stradivarius, 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)

Image full-screen popup[edit]

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)

help with a javascript application?[edit]

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)

No more "wg..." globals in JavaScript[edit]


I would like to ask any user which have personal scripts to check if they continue to work on (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. Smile.png 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}} (etc) 00:00, 8 July 2014 (UTC)
I've been using 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). 00:07, 8 July 2014 (UTC) 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. 02:37, 8 July 2014 (UTC) 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}} (etc) 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}} (etc) 17:30, 8 July 2014 (UTC)
@Jonesey95, Drilnoth: This change should fix the usage of global variables as well as one deprecated method (addPortletLink). 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, Superm401: This change should fix it (and there are a few other changes Krinkle did to the script which were lost in this update). 01:32, 9 July 2014 (UTC) 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. 23:50, 11 July 2014 (UTC)

Allow Current year and similar switches in redirects[edit]

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.

#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 Bugzilla: 61791 is what you're looking for... — {{U|Technical 13}} (etc) 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}} (etc) 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)

Parsoid Based Linter[edit]

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 If you want to try the JSON API you can use the following routes.

GET /_api/issues : Show all issues (
GET /_api/issues/type/issue-type : Filter by issue-type (
GET /_api/enwiki/issues : Filter by enwiki (

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)


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)

New hover display[edit]

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)

Uploading logos but need SVG - help[edit]

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)

Coordinates passed to Google Maps app not resolving[edit]

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 (talkcontribs) 10:14, 10 July 2014 (UTC)
No, I haven't installed any extensions.--A bit iffy (talk) 14:00, 10 July 2014 (UTC)
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)

Previous edits incorrectly deleted[edit]

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 [8]) 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: [9][10][11]. 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". ? --AKlapper (WMF) (talk) 12:51, 10 July 2014 (UTC)

GeoGroupTemplate not working (again)[edit]

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)

Time for the semi-annual enlarging of thumbnail images[edit]

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[edit]

  • 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


  • Performance issue due to more requests for larger images (investigating)
  • Possible typographic layout issues on small screens (<800px wide)

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

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

The actual proposal[edit]

Per below: "...I was actually suggesting 300px based on actual user data provided by Analytics. Jared Zimmerman (talk) 20:54, 9 July 2014 (UTC)" Clarified by Johnbod (talk) 00:28, 13 July 2014 (UTC)


  • So, based on your graph, about 9K (~0.04%) 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 21,768,381 editors (~99.96%) to have to change their settings to restore the accepted 220px current size. — {{U|Technical 13}} (etc) 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}} (etc) 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}} (etc) 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}} (etc) 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}} (etc) 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}} (etc) 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) (talkcontribs) 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}} (etc) 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) (talkcontribs) 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: [12]. 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}} (etc) 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)
  • 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)

  • @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}} (etc) 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}} (etc) 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 (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 (talkcontribs) 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 Bugzilla: 67695 but lets keep that issue separate for now, for simplicities sake. — Preceding unsigned comment added by Jaredzimmerman (WMF) (talkcontribs) 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)
  • 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)

Template:Albumchart glitch[edit]

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[edit]

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


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 . Changes are already visible on testwiki:. Thanks. Bawolff (talk) 20:59, 9 July 2014 (UTC)

Move tab not appearing[edit]

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)
Facepalm3.svg 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 (talkcontribs) 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[edit]

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)

Asking anonymous editors to sign up[edit]

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, (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)

Table glitch[edit]

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...[edit]

...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 (talkcontribs) 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[edit]

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 (talkcontribslogs) 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)

Is there a way to add items to the CharInsert gadget?[edit]

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[edit]

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[edit]

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. (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?[edit]

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[edit]

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)

Missing reference markup will no longer show an error[edit]

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:

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

@Gadget850: bug 66700 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)
bug 67854 doesn't exist? --Redrose64 (talk) 12:09, 11 July 2014 (UTC)
bug 67845 --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 bug 67700 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)

Create protection[edit]

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 bug 25023 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)


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)

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

(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[edit]

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}} (etc) 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)

Wikipedia:List of Wikipedians by number of edits not updating[edit]

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)

Content going under references[edit]

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)

Why is the edit summary maximum length so low?![edit]

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 bug 4715 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. Face-tongue.svg 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: [13] (MySQL's tinyblob field used here is 255 bytes long, as stated here: [14] in a very roundabout way). The value of '255' is repeated in a few other places, for example here [15]. 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)

"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 (talkcontribs) 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)


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)

  • Yes check.svg 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)

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

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)

RfP: requests for permission[edit]

Currently under Wikipedia:*. Wikipedia:* is documentation, while requests for permissions are more a talking-thing. --Gryllida (talk) 11:16, 13 July 2014 (UTC)

RfC: requests for comments[edit]

Currently under Wikipedia:* I believe? Wikipedia:* is documentation, while requests for comment are more a talking-thing. --Gryllida (talk) 11:16, 13 July 2014 (UTC)

Idea: collaborative insight on ideas[edit]

For ideas, like those at the Wikipedia:Village pump (idea lab). They ideally need to evolve, be discussed, in a separate article. (Meta already have one-idea-per-page thing in meta:Grants:IdeaLab, under Grants:<Who is grant being requested from (IEG, PEG, etc)>/<Idea name>). --Gryllida (talk) 11:16, 13 July 2014 (UTC)

Argument delimiters in a Mediawiki function[edit]

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)

Language tool updates not showing up in list[edit]

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)


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. (talk) 17:48, 13 July 2014 (UTC)

How to disable image "lightbox" effect, permanently?[edit]

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)