I've seen some chatter in the archives about the failure to render infoboxes, but it seems to me that the problem is much more widespread than that. I have looked around and every WP article with tables that I have checked have had the tables excluded in the .pdf print/export version. That is to say, after looking around, I have yet to find ANY tables that are rendered in the .pdf generated by print/export. Yes, there are many articles without tables, nevertheless, many articles include critical information in the articles and the lack of tabular information renders (pun intended) the .pdf nearly worthless. This is a widespread problem that IMHO should be prioritized relatively high. Examples are easy to find:

• So Far So Good (Bryan Adams album): §§  Track listing, Chart positions, and Certifications
• List of countries and dependencies by population: § Countries and dependencies by population
• Periodic table: §§  Overview​ and Groups
• Properties of metals, metalloids and nonmetals: § Comparison of properties
• Oregon: §§  Geography, Major cities, and Politics
• List of U.S. state abbreviations: § Table
• Harrison Ford: § Awards
• Macaulay Culkin: §§  Film​ and Television

Go to your own favorite corner of WP and if you find tables, you will find this bug. YBG ( talk) 05:08, 28 February 2015 (UTC)

Known issue. See T87499 which was merged into T73808. -- George Orwell III ( talk) 06:05, 28 February 2015 (UTC)

Great! Much appreciated. YBG ( talk) 06:16, 28 February 2015 (UTC)

Help:Download as PDF --   Gadget850  ^talk 14:49, 28 February 2015 (UTC)

In Jacques Brel, my eye gets the impression that the infobox header (the colored bar with text 'Jacques Brel') is asymmetrical: lefthand whitespace looks like 3px, righthand ws 2px. I'm using Firefox 35 (not 36 yet) now. Possibly related: #Tables_just_changed_.28using_monobook.29. Is it just my eye, or is this real? - DePiep ( talk) 20:49, 27 February 2015 (UTC)

Not sure, was the dress white/gold for you today or black/blue ? — TheDJ ( talk • contribs) 21:33, 27 February 2015 (UTC)

Team white and gold! -- MZMcBride ( talk) 22:15, 28 February 2015 (UTC)

In Jacques Brel, my eye gets the impression that the infobox header (the colored bar with text 'Jacques Brel') is asymmetrical: lefthand whitespace looks like 3px, righthand ws 2px. I'm using Firefox 35 (not 36 yet) now. Possibly related: #Tables_just_changed_.28using_monobook.29. Is it just my eye, or is this real? - DePiep ( talk) 22:13, 27 February 2015 (UTC)

I'd like to revive this thread.

Summary: When an admin moves a page to a salted target, there is no warning that the page is salted. (I tested it myself and saw no warning.) I'm not sure if the target remains salted.

Case in point: [1], [2]

A warning box would have made User:Necrothesp aware of an old AfD. He then would likely have made others aware of that at the new AfD.

Can this be fixed? Bug report? Thoughts? Anna Frodesiak ( talk) 01:09, 27 February 2015 (UTC)

To your q "I'm not sure if the target remains salted", no - because salt can only be applied to the title of a non-existent page; once a page is moved to that title, it's no longer the title of a non-existent page. -- Redrose64 ( talk) 11:08, 27 February 2015 (UTC)

Hi, Redrose64. I see. And if it is deleted again? Is the redlink then salted again for non-admins? Anna Frodesiak ( talk) 21:51, 27 February 2015 (UTC)

No, it's not; and I've just confirmed it at User:Cryptic/test1 ( | talk | history | links | watch | logs). — Cryptic 22:02, 27 February 2015 (UTC)

Thank you, Cryptic. So, how do we get this fixed. This is the second post about this, and it seems to be getting just as ignored as the first one. Anna Frodesiak ( talk) 22:06, 27 February 2015 (UTC)

Posted at phab:T91129

Anna Frodesiak ( talk) 22:34, 27 February 2015 (UTC)

I asked for a username change from EmeraldRS to Emerald-wiki. It says the change has been carried out but I can't log in with my old or new username. I get a message with the new username saying my account is being renamed or merged. Is there some step that got missed? Help! 80.176.153.231 ( talk) 17:35, 27 February 2015 (UTC)

The rename was an hour ago [3] and your account has nearly 1000 edits in total. Try again later. PrimeHunter ( talk) 17:52, 27 February 2015 (UTC)

I have waited, it is now about 15 hours since the rename, but still I can't login. Are you sure it is just a matter of waiting and not that something else needs fixing? 80.176.153.231 ( talk) 08:49, 28 February 2015 (UTC)

I think it should have worked by now. What exactly happens if you try to log in as Emerald-wiki? If you get a message then quote it precisely. Can you log in at meta: or wikisource:? PrimeHunter ( talk) 13:01, 28 February 2015 (UTC)

When I try to log-in the message says "Login error/ Your account is currently being renamed or merged./ View the status", clicking 'View the status' shows the Global rename progress with everything 'Done' except de.wikipedia.org which is 'Queued' and has been for approaching 24 hours. I get exactly the same thing at Meta, Wikisource and Commons. I have never used de.wikipedia.org and, not speaking German, probably never will. I hope you can help. 80.176.153.231 ( talk) 14:23, 28 February 2015 (UTC)

Apparently the global renaming process is still waiting for de.wikipedia to be completed. That's one of the downsides of global accounts: if one local instance is delayed or interrupted I suppose you can't use your account at all. It looks like you'll have to wait for the German queue to finish. De728631 ( talk) 14:36, 28 February 2015 (UTC)

Okay, thanks, I'll wait. I changed my username once before, that time it happened so fast it surprised me - within 5 mins of submitting my request it had happened, I hadn't even got as far as logging out. This time it is really, really slow! 80.176.153.231 ( talk) 14:40, 28 February 2015 (UTC)

• @ Keegan: is such a long delay expected? – xeno ^talk 14:57, 28 February 2015 (UTC)
• Note that there is already a user on deWP called Emerald-wiki, which was created on 10 January 2015 but hasn't made any edits. Is that his newly renamed global account, or is it an unrelated account holding up the rename? A few random other wikis I've checked don't have a user by that name, though esWP does. SiBr₄ ( talk) 15:15, 28 February 2015 (UTC)

It seems the hold-up has been identified. Can I take over the other Emerald-wiki on DE or choose another username - bearing in mind that I can't login anymore? 80.176.153.231 ( talk) 15:22, 28 February 2015 (UTC) I should say that the Emerald-wiki on DE in January is nothing to do with me. I was EmeraldRS or my previous username, which unwisely was my real name 80.176.153.231 ( talk) 15:26, 28 February 2015 (UTC)

I don't know the reason for the de hold-up but I definitely think the de account is yours, created when you were EmeraldRS and part of the rename. Special:CentralAuth/Emerald-wiki shows it belongs to the global account, and was created at a time where you were also created at other wikis. If you are logged in at another wiki and visit any page at a Wikimedia wiki which is part of the global login system then your account is automatically created there. de:Special:Logs/Emerald-wiki confirms it was an automatic creation. https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php?username=Emerald-wiki also says there are no unattached acccounts. PrimeHunter ( talk) 15:41, 28 February 2015 (UTC)

I'll just keep waiting then!!! I wish I did know German to ask a question on one of their help talks! 80.176.153.231 ( talk) 15:48, 28 February 2015 (UTC)

Hi there (thanks for the ping, xeno). We'll get that fixed for you. Sorry for the hold up, that's not normal. Keegan (WMF) ( talk) 03:36, 1 March 2015 (UTC)

 Done - Legoktm unlocked the account and hopefully fixed the issue. You should be able to log in to your account. If you have any future problems getting locked out, please feel free to contact me directly. You can find my contact information on my userpage. Again, sorry for the trouble. Keegan (WMF) ( talk) 03:58, 1 March 2015 (UTC)

Thanks everyone. Got up this morning and the first thing I tried was logging in to Wiki - straight in, no problem - great!! Richard Emerald ( talk) 10:41, 1 March 2015 (UTC)

Is there any reason why this is only counting my noms, and not my vote at AfD? -- Fauzan ^{✆ talk} _{✉ mail} 16:04, 28 February 2015 (UTC)

My contributions in Wikipedia:Articles for Deletion/* -- Fauzan ^{✆ talk} _{✉ mail} 16:13, 28 February 2015 (UTC)

Which (diff) vote are you referring to? Nakon 04:02, 1 March 2015 (UTC)

Nakon, I mean the voting matrix shows only my nominations, and not the 50 other votes at AfD. The tool is not recognizing my votes at AfD, which it should. -- Fauzan ^{✆ talk} _{✉ mail} 08:23, 1 March 2015 (UTC)

I recently created a template for a link to the National Center for Missing and Exploited Children, which would be used on missing persons pages, but I can't get the URL to work. I created it after I saw Template:Find a Grave. Here is my template page: Template:NCMEC. Here is a page that it is used on: Michaela Garecht and here is a URL to a poster: [4]. I'm hoping someone could help with this issue, as the formatting works perfectly with my template for unidentified persons on the website (see Template:NCMEC UID. Thanks, -- GouramiWatcher ^(?) 17:04, 28 February 2015 (UTC)

I don't know the website. Is there a reason the template says NCMU instead of NCMC the second time? Your example works if it's changed to NCMC. PrimeHunter ( talk) 17:26, 28 February 2015 (UTC)

"NCMU" is used with the unidentified people. The missing children's URLs have the "NCMC." -- GouramiWatcher ^(?) 20:12, 28 February 2015 (UTC)

But why does Template:NCMEC only choose a url with NCMC if there is an author, date or accessdate parameter, and another url with NCMU if there isn't? None of those parameters sound like they have something to do with unidentified people versus missing children. It seems a very odd system, and I think it's an extremely poor idea to make an external link template which changes the url if an accessdate is added. That means a user may test the link, find it works, add an accessdate, and that action may break the link without the user rechecking it. Additionally, the NCMC case is coded wrong and needs fixing but I would like to first understand the idea behind the whole NCMC/NCMU choice. PrimeHunter ( talk) 21:51, 28 February 2015 (UTC)

Changed NCMU to NCMC as per PrimeHunter and it seems to pull the poster just fine then, but the concerns above remain & are on point.

Oh I think I get the premise now, the first incarnation is for use as a citation for inline refs and the second is for standalone usage (still doesn't quite add up however). -- George Orwell III ( talk) 22:03, 28 February 2015 (UTC)

Maybe that's the intention. All current uses of both templates are in external links sections and none of them use any of the parameters which invoke the first incarnation. The OP said "the formatting works perfectly" about Template:NCMEC UID, but that template also changed the url (although only by adding '=') if any of author, date or accessdate were added. In all cases I tested, this broke the link. I guess it was simply never tested and '=' should just be removed from the url in both templates, in addition to your change of NCMU, and an addition of a missing pipe. I made these changes [5] [6] and both templates now give working links in both incarnations:

• Dana Point Jane Doe at the National Center for Missing and Exploited Children
• "Dana Point Jane Doe". NCMEC. Retrieved March 1, 2015.
• Michael Hughes at the National Center for Missing & Exploited Children
• "Michael Hughes". NCMEC. Retrieved March 1, 2015.

PrimeHunter ( talk) 00:52, 1 March 2015 (UTC)

Thanks for your assistance! Sorry if I confused anyone! -- GouramiWatcher ^(?) 03:30, 1 March 2015 (UTC)

As someone who works with wikitables all the time I am very unhappy with the padding change. Most of the time I am working on wikipedia I work on results tables (Most of the time motorsport results tables). Those result tables need to be tight so you can put 20-sometimes 56 or more races in one table. Example: Dave Marcis. Now that the padding has changed (doubled) these result tables are way bigger than they should be. This makes them harder too reed and untidy. I really don't understand why the padding has doubled. This affect every single table on wikipedia. I am really disappointed and upset that this affects all the hard work I have put in to create all these results tables. What's going to happen next? I mean the padding being doubled is'nt a minor change. Particularly when this affects almost all the tables on wikipedia. Is their a possibility that this change is going to be reverted? Jahn1234567890 ( talk) 15:59, 1 March 2015 (UTC)

Have you commented at https://phabricator.wikimedia.org/rMW33cfd0bc4a5f009b86c40b0312b4c7f7b006cbc7? -- Ahecht ( TALK
PAGE) 18:08, 1 March 2015 (UTC)

We can append &uselang=qqx to an url to get the interface messages name, but what can we do when one wants to get the interface message names also when submitting requests ? I don't see qqx in the language selector in preferences.  Cenarium ( talk) 19:50, 1 March 2015 (UTC)

What do you mean by "when submitting requests" - is this editing a page? If so, the URL will already include a question mark at some point earlier than (but not necessarily immediately before) the action=edit; there can be only one of these, so leave that alone, and append &uselang=qqx to the right-hand end of the URL. -- Redrose64 ( talk) 19:56, 1 March 2015 (UTC)

The question is about cases where a displayed message doesn't just depend on the current url but also on what you just did, for example move a page. Adding uselang=qqx does not always reproduce the right situation and message. If you want to find the used MediaWiki messages in such situations then there are tips at Wikipedia:Village pump (technical)/Archive 131#What interface page is used for the results after a successful undeletion? PrimeHunter ( talk) 20:52, 1 March 2015 (UTC)

Thanks. Yes, it was when I was moving a page. There are some useful tips, though it may make things easier if the non-overriden default messages (for the site language only, like AllMessages) were indexed when searching mediawiki namespace.   Cenarium ( talk) 21:55, 1 March 2015 (UTC)

C: Indeed. This is phabricator:T22858. If you have a clone of mediawiki/core.git, "git grep" is probably fastest. -- MZMcBride ( talk) 22:00, 1 March 2015 (UTC)

Why do we have the secure link icon only for red links: Red link example and logged in secure. --   Gadget850  ^talk 21:47, 1 March 2015 (UTC)

I'm not sure what you mean. Internal red links have never had a secure link icon, as far as I know. I don't see an icon next to red link example using Vector or Monobook over HTTPS. Maybe you can provide additional details about your setup or a screenshot? -- MZMcBride ( talk) 21:57, 1 March 2015 (UTC)

Must be me, not seeing it logged out. --   Gadget850  ^talk 22:13, 1 March 2015 (UTC)

Something in my JS. Possibly User:Anomie/linkclassifier. --   Gadget850  ^talk 22:20, 1 March 2015 (UTC)

I'm not seeing a secure link icon, but I am seeing the small WP:SKYBLUELOCK for that particular link thanks to User:Anomie/linkclassifier. Something random like slkndkfoewgfoiwenbgflksgewe that isn't create-protected isn't showing any icon here. Anomie ⚔ 23:27, 1 March 2015 (UTC)

Hi, this message is to let you know that, on domains like en.m.wikipedia.org, unregistered users cannot edit. At the Wikimedia Forum, where global configuration changes are normally discussed, a few dozens users propose to restore normal editing permissions on all mobile sites. Please read and comment!

Thanks and sorry for writing in English, Nemo 22:32, 1 March 2015 (UTC)

I was checking something in the Lyndon B. Johnson article, and saw that the link on his father, Samuel Ealy Johnson Jr., was red. Yet, when I hovered over the link, PopUps showed me that there is in fact an article on Samuel. But the link was red, and I still got the "(page does not exist)" title-text. The Samuel article has existed for years, so it's not one of those situations where it was recently created and the backlink colors haven't changed yet. I purged the page, and that seems to have fixed the problem, at least for me. Here's a screengrab. Is this a known issue? I skimmed Phabricator but didn't see anything similar. —  PinkAmpers & ^{(Je vous invite à me parler)} 02:27, 2 March 2015 (UTC)

The page history of Samuel Ealy Johnson Jr. shows it was moved to that title one minute after Lyndon B. Johnson was last edited, so it was just a normal red link cached at that time. PrimeHunter ( talk) 02:50, 2 March 2015 (UTC)

@ PrimeHunter: Ah, that explains it. I should've noticed. Thanks. —  PinkAmpers & ^{(Je vous invite à me parler)} 06:21, 2 March 2015 (UTC)

Hello all,

As you may know there is a Wikipedia Signpost Mobile App for Android. It's currently borked, but the source code is on GitHub. We're doing a lot of organizational work at the moment and the mobile app is one of the things we'd like to look into: we're looking into technical improvements behind-the-scenes and we'd like to take the opportunity to more tightly integrate mobile access into things.

The Android project is likely to be fixed soonish; would anyone be interested in working on porting the Signpost mobile app to iOS, or know someone that they think might interested in such a project? Res Mar 05:40, 2 March 2015 (UTC)

Why can't I delete Cremation or burial?? When I choose delete it just reloads the page. I can delete other pages but not this one. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 07:28, 26 February 2015 (UTC)

Not quite sure. I just did and it worked fine. Something with your browser or personal Javascript maybe? Seraphimblade ^{Talk to me} 08:11, 26 February 2015 (UTC)

That's strange I deleted another page with no problem. I'll just put it down to sunspots as they get blamed for almost everything in the Arctic. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 08:19, 26 February 2015 (UTC)

I'm guessing it's a problem with '?' which usually indicates a query string in url's. MediaWiki encodes '?' in pagenames as %3F to avoid confusion but maybe your browser is still confused. Which browser? Does the same happen for Quo vadis? PrimeHunter ( talk) 19:30, 26 February 2015 (UTC)

I was using Chrome Version 40.0.2214.115 on Ubuntu 14.04 but I just tried in Firefox 36.0 on the Quo vadis page and got the same result. This time I checked the url and noticed it was /info/en/?search=Quo_vadis%3F?action=delete. I'll have to try later on Windows. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:01, 26 February 2015 (UTC)

@ CambridgeBayWeather: That really is odd, since I'm using Ubuntu 14.10 with Chromium 40.0.2214.111. Are you using Twinkle or any other scripts, or just the regular Mediawiki delete button? Seraphimblade ^{Talk to me} 01:22, 27 February 2015 (UTC)

It's indeed an issue with '?' but probably not in your browser. Your link /info/en/?search=Quo_vadis%3F?action=delete doesn't work for me either. How do you reach that link and what is your skin? I'm in Vector and click the "More" tab and then "Delete". That gives me https://en.wikipedia.org/?title=Quo_vadis%3F&action=delete which works. Your url structure works on page names not containing '?', for example /info/en/?search=Quo?action=delete. It may be a MediaWiki bug that a query part cannot be added to a url of form /info/en/?search=...%3F. It also fails for /info/en/?search=Quo_vadis%3F?action=history as non-admins can test. The "View history" tab gives me https://en.wikipedia.org/?title=Quo_vadis%3F&action=history which does work, but I think /info/en/?search=Quo_vadis%3F?action=history should also have worked, like /info/en/?search=Quo?action=history works. MediaWiki apparently chokes on the %3F? combination where %3F is an encoded '?' ending the pagename, and '?' is the start of a query part. Or maybe there is some general url rule I'm unaware of which disallows '%3F?' in url's. PrimeHunter ( talk) 01:49, 27 February 2015 (UTC)

The %3F? combination works on this wiki with an old MediaWiki version: http://mersennewiki.org/index.php/Why_participate_in_GIMPS%3F?action=history. http://mersennewiki.org/index.php/Special:Version says MediaWiki: 1.5.8. PrimeHunter ( talk) 02:24, 27 February 2015 (UTC)

The problem is not restricted to '?' at the end of the pagename. /info/en/?search=%3F_Nycticebus_linglom?action=history should have produced the page history of ? Nycticebus linglom. PrimeHunter ( talk) 02:56, 27 February 2015 (UTC)

User:PrimeHunter. To get the non working link I just followed the original Quo vadis? link you provided. I then clicked on the delete and it reloaded the page with the /info/en/?search=Quo_vadis%3F?action=delete non working link. I'm using Vector as well. I notice you said that you clicked on the "More" tab and then "Delete". On the "More" I see the only option is "Purge". The option to delete is on the "Page" tab and says "Delete page". Also the https://en.wikipedia.org/?title=Quo_vadis%3F&action=delete works for me as well. I looked through my deletion log and found this, I did see at least one more with the ? at the end, and this with the ? in the middle. So at one time I was able to delete pages with the ? at the end. The other links on your 01:49 post all work the same for me as they did for you. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:19, 27 February 2015 (UTC)

The "Page" tab is not part of MediaWiki. It is made by "Add Page and User dropdown menus to the toolbar" at Special:Preferences#mw-prefsection-gadgets. The gadget is disabled by default. I have tried to enable it and get the same non-working url as you on the Page tab. The gadget uses MediaWiki:Gadget-dropdown-menus.js which uses MediaWiki:Gadget-dropdown-menus-vector.js for Vector users, but the bug is in MediaWiki and should be fixed there. Question marks in pagenames are rare and I'm not sure it's worth coding the gadget to work around the bug by using url's with /?title= instead of /wiki/. PrimeHunter ( talk) 03:33, 27 February 2015 (UTC)

OK that was it. I removed the gadget and was able to delete https://en.wikipedia.org/?title=User:CambridgeBayWeather/Test3%3F&action=delete. I found that with the gadget enabled it is possible to move the page and not leave a redirect. That deleted the ? page and then of course I was able to delete the page without the ?, https://en.wikipedia.org/?title=User:CambridgeBayWeather/Test%3F&action=edit&redlink=1. Given that there are several things I like about the gadget and the very few times that the ? comes up I'll leave it enabled and use the move workaround. Thanks for all your help. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:48, 27 February 2015 (UTC)

Moves are made with a special page and not a query string, so the bug does not interfere. Protect and Purge on the Page tab are affected. It probably also affects several other scripts and tools. I'm not proficient with Phabricator. Can somebody see if it's there, and add it if not? PrimeHunter ( talk) 04:18, 27 February 2015 (UTC)

I'm not seeing a problem with the Protect from the page tab. It worked fine yesterday. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 04:58, 27 February 2015 (UTC)

On a pagename with a question mark? The bug is only known to affect that. PrimeHunter ( talk) 05:11, 27 February 2015 (UTC)

I can fix this for MediaWiki:Gadget-dropdown-menus-vector.js, but I do not maintain the non-vector version if that is what you are using. Because of the same bug all internal links involving a page name with a ? will not work, so it's worth fixing for the interim I think. — MusikAnimal ^talk 06:23, 27 February 2015 (UTC)

Should be fixed now. Thanks for the report! — MusikAnimal ^talk 07:05, 27 February 2015 (UTC)

This should be fixed in core though... -- [[ User:Edokter]] {{ talk}} 12:38, 27 February 2015 (UTC)

Thanks User:MusikAnimal that works now. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 16:18, 27 February 2015 (UTC)

• @ MusikAnimal: I use vector, and I'm having the same problem with ampersands and quotation marks. See this discussion.-- Bbb23 ( talk) 09:20, 3 March 2015 (UTC)

The CirrusSearch, which normally updates within 10-15 seconds, appears to have stuck
I corrected misspellings of "received" at 12.37 and 12.38 but both sill appear in the search for recieved nearly 6 hours later - Arjayay ( talk) 18:18, 1 March 2015 (UTC)

I thought that it updated once a day, around 04:00 UTC, which is some eight hours off. -- Redrose64 ( talk) 19:59, 1 March 2015 (UTC)

The old Lucene-search updated once a day. The current CirrusSearch should normally update much faster. See mw:Help:CirrusSearch#Updates. I also get the old revision of your diff currently (you posted the same diff twice). PrimeHunter ( talk) 21:01, 1 March 2015 (UTC)

This is even worse than when LuceneSearch index was not updated; at least when it got restarted, even if it took a week, it would completely reindex everything. The CirrusSearch update failure has not been seen before to this extent, I think, and something extraordinary will have to be done to make things right. I don't think they expected that something like this could actually happen, and I will be surprised if they have a way to quickly fix it. Chris the speller  ^yack 21:23, 1 March 2015 (UTC)

We have a script for handling outages. Its one of the first things I built. NEverett (WMF) ( talk) 18:21, 2 March 2015 (UTC)

Filed as phabricator:T91216. -- MZMcBride ( talk) 21:31, 1 March 2015 (UTC)

I just filed phabricator:T91217, then saw your post. It looks like you beat me by a nose. I'll update mine as being a duplicate of yours. Chris the speller  ^yack 21:43, 1 March 2015 (UTC)

Now updates to the index are taking place again as articles are edited, but the ones we already complained about are still not updated in the index, as my earlier post predicted. Chris the speller  ^yack 02:05, 2 March 2015 (UTC)

Some old edits have appeared in the updated search, and some haven't. The real one mentioned above at 12.37 hasn't, but the one I should have posted at 12.38 has, although neither article has been altered since. If there is a definite time period that has not updated, is it possible to give all articles edited in that time-frame a null edit to nudge the search along? - Arjayay ( talk) 16:36, 2 March 2015 (UTC)

Grabbed the task and will work on it now. Thanks for filing it! We have a script to handle it and I'll kick it off as soon as I find the timestamps to feed it. NEverett (WMF) ( talk) 18:21, 2 March 2015 (UTC)

I believe I've reindexed all the effected pages. I'm off to kick off this process on the other ~880 wikis! NEverett (WMF) ( talk) 02:07, 3 March 2015 (UTC)

Well, I was surprised; they actually did have a way to quickly fix it. I sampled updates from yesterday to see what was reindexed, and they seem to have caught them all. This turned out better than I expected, and I have more faith in the CirrusSearch group than I did before. Thanks for resolving this. Chris the speller  ^yack 02:56, 3 March 2015 (UTC)

I came upon the article Vytautas Mažiulis and noticed that italics in the biography section are not displaying properly. The organization name "Milanese Linguistics Society" is not entirely italicized, however the country and phrase that follows it is italicized for some reason. The code looks correct. Is there something that I'm missing here? How can these italics be fixed? Mamyles ( talk) 16:15, 2 March 2015 (UTC)

It's because there was an artificial linebreak after "Milanese". I've fixed it (although those organization names probably shouldn't be italicized anyway per MOS:ITAL). Regards, Orange Suede Sofa ( talk) 16:21, 2 March 2015 (UTC)

Looks better, thanks. That also clears up why my browser wasn't displaying a space after "Milanese" in the edit window.

I was just bothered by this issue while reading and do not care if the italics are there or not. Feel free to remove if you think they are inappropriate. Mamyles ( talk) 16:33, 2 March 2015 (UTC)

This is basically a repost of MediaWiki talk:Common.css#Fixing bulleted list inside an unbulleted list to get some more attention.

When using {{ bulleted list}} inside {{ unbulleted list}}, it doesn't work because {{ unbulleted list}} adds a class to the outer list without a means to revert that inheritance in inner lists. To make stuff less complicated, I propose to make the styles of unbulleted list apply strictly to the direct children of the outer list, so as to prevent the inner lists from inheriting the styles.

Example:

{{unbulleted list
| This
| {{bulleted list|E|F}}
}}

Timothy G. ^{from CA} ( talk) 03:50, 3 March 2015 (UTC)

Commented there. -- [[ User:Edokter]] {{ talk}} 09:46, 3 March 2015 (UTC)

There is something wrong with Template:Orphan, looking at the edit summary this edit: [7] hid the cleanup tag and as a result the tag has disappeared from 99 of our articles. Is there a fix fir this? - Knowledgekid87 ( talk) 04:53, 3 March 2015 (UTC)

@ Knowledgekid87: Please see Template:Orphan#Visibility, which explains that the template is only visible for the current & previous month (e.g. not visible on A Gentleman's Kiss), but is always visible within {{ multiple issues}} (e.g. visible on AUKcon). The articles are still categorized and still on your report. The template instructions also contains a fix that might interest you. Good luck! GoingBatty ( talk) 05:49, 3 March 2015 (UTC)

What am I messing up here? Martijn Hoekstra ( talk) 10:19, 3 March 2015 (UTC)

Substing does not work inside <ref> or other parser tags. -- [[ User:Edokter]] {{ talk}} 10:25, 3 March 2015 (UTC)

Thanks! Live and learn. Martijn Hoekstra ( talk) 10:28, 3 March 2015 (UTC)

I have added a new property to an existing item – P527 (name = 'has part', value = barangay) to (Q316370) Santa Fe, Cebu, then added qualifer P1114 (name = 'quantity', value = 10).

When I try to retrieve, using {{#invoke:Wikidata|getRawQualifierValue|P527|P1114|FETCH_WIKIDATA}} it throws an error:
Lua error in Module:Wikidata at line 168: invalid value (table) at index 1 in table for 'concat'.

Is it me or ...?

NB I have successfully used getting qualifier values before, e.g. {{ Population census prose}}

-- Unbuttered parsnip ( talk) mytime= Sun 16:35, wikitime= 08:35, 1 March 2015 (UTC)

I don't know Lua and know very little Wikidata so I could be wrong but it looks to me like getRawQualifierValue in Module:Wikidata cannot handle qualifiers with data type Quantity such as wikidata:Property:P1114. {{ Population census prose}} uses getRawQualifierValue for wikidata:Property:P459 which has data type Item. PrimeHunter ( talk) 15:58, 1 March 2015 (UTC)

Well it allowed me to add the qualifier to the property, so it's a surprise it doesn't work (not really, this is wikidata we're talking). I'll take my problem over to the wikidata village pump (T) , if there is one. Unbuttered parsnip ( talk) mytime= Mon 07:38, wikitime= 23:38, 1 March 2015 (UTC)

I suspect the problem is in Module:Wikidata and have posted to Module talk:Wikidata. PrimeHunter ( talk) 23:42, 1 March 2015 (UTC)

I think that my naming the Wikipedia Lua module "Wikidata" may be causing confusion. Whatever happens on Wikidata won't guarantee that the Lua module (which is intended to import data from Wikidata to Wikipedia in a flexible way) will always work. The problem occurs because the module was written before numeric data types existed on Wikidata. Line 168 takes a table of all of the values for that qualifier and concatenates them together with a comma+space separator assuming that the value is a string. As I understand it, you can't concatenate numbers like that, using the table.concat() method, unfortunately. I think I can solve the problem by ensuring that the wikitext gets a string representation of the number but I'll need to do some testing before I can be sure. -- RexxS ( talk) 00:03, 2 March 2015 (UTC)

Thanks for looking into it. Oddly, the revision time for my above edit [8] says 23:46, four minutes after the 23:42 signature which was made with a normal four ~~~~. I sometimes see a 1-minute difference which makes sense if it takes about a second to process the edit and it was saved near a minute change with signature time and revision time recorded at different stages. I have never seen more than 1 minute. The save went through quickly. My browser history indicates it was 23:46 with an accurate clock. PrimeHunter ( talk) 00:08, 2 March 2015 (UTC)

Well, it's not the problem I thought it was. It seems table.concat() does implicitly cast the numbers into strings, so the concatenation method works as it should. From the error message you give, I now suspect that the first item in the table is actually a table, not a single value. I'll go check that and see if I can fix it. -- RexxS ( talk) 00:24, 2 March 2015 (UTC)

Update: yes the first item is a table, so can't be concatenated with ", " as the call tries to do. -- RexxS ( talk) 14:40, 2 March 2015 (UTC)

The more I've looked at this, the more I become convinced that you can't write a generic call to fetch just the value of a given qualifier associated with a given property because of the possibility of multiple values. For example, if you look at Richard Burton ( d:Q151973), he has 3 spouses (P26) listed, two of whom have qualifiers for start time (P580) and end time (P582). What should a call asking for Richard Burton's spouse's start time return? Should it return nil for Elizabeth Taylor? or 3 July 1983 for Sally Burton? or 1949 for Sybil Christopher? Of course we could have it return 1949 and 3 July 1983, but what value would they be without knowing which spouse they referred to? It would be possible to write a call that fetched e.g. the value of first given qualifier from the first given property, but that becomes vulnerable to someone adding another value for the property. How would you want to deal with the situation if Santa Fe ( d:Q316370) had 30 sitios and someone added "has part=sitio" with a qualifier of "quantity=30"? Should getRawQualifierValue|P527|P1114 return 10 or 30? Sorry to be negative about the problem, but I can't see a general solution. -- RexxS ( talk) 14:40, 2 March 2015 (UTC)

I don't understand any of this. Other properties, for instance 'population', are quite happy to have more than one different qualifier ('date' and 'method'), no problem. Other properties, e.g. 'inception' are happy to have (and return) more than one value. I cannot believe that it is not possible to return a qualifier attached to an instantiation of a property, here 'quantity' attached to 'has part'=barangay. Time to bin it all and start again in SQL, or anything proprietary and proven.-- Unbuttered parsnip ( talk) mytime= Mon 23:30, wikitime= 15:30, 2 March 2015 (UTC)

Maybe a discussion is needed about what to do with multiple values (an error message and tracking category if the caller didn't specify which value was wanted?), but can it be coded to at least give the value when there is only one? PrimeHunter ( talk) 16:03, 2 March 2015 (UTC)

There is no way of specifying which qualifier you want if more than one - you just get them all. But qualifier should be attached to property value, not to property name as implied here. Unbuttered parsnip ( talk) mytime= Tue 00:24, wikitime= 16:24, 2 March 2015 (UTC)

Yes, code can be written to return a given qualifier's value if there is only one qualifier present among all the statements connected with a given property. But how would you want it to behave in Wikipedia if somebody added another qualifier in Wikidata? Should it disappear because it's no longer a unique value? or are you willing to risk the value of the second qualifier now appearing in the Wikipedia article instead of the value of the previously unique qualifier?

Qualifiers are definitely attached to a particular name-value pair. So in the case of Richard Burton, the property named "spouse" with the value "Sybil Christopher" has attached to it a qualifier called "start date" with the value '1949'. But again how does that help you if you want a call that returns just the qualifier value? because you don't know the value "Sybil Christopher" when you make the call. On the other hand, if you want a call that returns a list of the all values of a given property along with a list of the values of a given qualifier when present, then that's possible as it could look like this for Richard Burton / property='spouse' / qualifier='start date' :

• Elizabeth Taylor; Sally Burton, 3 July 1983; Sybil Christopher, 1949; (note that the two dates for Elizabeth Taylor's two marriages to Burton could be added at any time)

But that's different from the problem outlined by Unbuttered Parsnip. -- RexxS ( talk) 22:56, 2 March 2015 (UTC)

It already returns more than one value for a qualifier, as in 'inception' or 'demonym'. I don't see the point in providing a massive database which can't be interrogated. If it is possible to add a value to a qualifier of a property, then it has to be possible to read it back too. As regards particular case, I can't make any sense of the notion that a qualifier could have more than one 'quantity' value. In the general case, I think one would want the latest. So for population ordinarily you'd want the latest (current) census, not one from 10 years ago. Exceptionally you might want all of them. Because data-sort is not a parser function, it would be incumbent on WD to return a sorted list. -- Unbuttered parsnip ( talk) mytime= Tue 10:52, wikitime= 02:52, 3 March 2015 (UTC)

(1) The database can be interrogated. (2) It is possible to read the data back, but if there are multiple values meeting the search criteria, you have to specify what you want read back. (3) There is no reason whatsoever why a property can't have multiple instances of the same qualifier. I already gave you the example of Richard Burton marrying his second wife twice, so the start date of the marriage would appear as a qualifier twice with two different values: 1964 and 1975. If you call for the start date of Richard Burton's marriage to Elizabeth Taylor, which qualifier value would you want returned? (3) The "latest" doesn't make sense in general for all qualifier values which could be numbers or text as well as dates. (4) Yes, sometimes you want just one qualifier value from amongst several - and there's no means of specifying which one - and sometimes you want all of them, but writing a generic module that copes with any Wikidata item won't do what you want. (5) At present there is no call to the mw.wikibase API that returns sorted tables, but sorting can be done in the Lua module, so parser functions are irrelevant. -- RexxS ( talk) 03:59, 4 March 2015 (UTC)

Reads like a snow job to me. I don't know how the database can be interrogated, because the only module we've been given doesn't seem to work. In particular, it doesn't allow specification of which occurrence of the property, nor of which occurrence of any qualifier. Your reply implies that the qualifiers for different instantiations of a property are jumbled together, and it's pot-luck which gets returned. Sad if true. I didn't specify every qualifier, I was restricting myself to 'quantity'. If a property has a qualifier of 'quantity' then I'd be very surprised if there could be more than one associated value. That's tantamount to saying that the value of the qualifier contains every known number. I can't imagine anyone would update a raw value by adding another instantiation of the qualifier rather than just changing the value, since there is no way of differentiation. As I said, other properties, e.g. 'inception', allow multiple copies of qualifier (a date) and return them without breaking.
Regarding Burton–Taylor, it seems incorrect to have only one wedding tuple with more than one date set, when they married twice – correct form would be one tuple for each marriage with not more than one date set each. -- Unbuttered parsnip ( talk) mytime= Wed 12:49, wikitime= 04:49, 4 March 2015 (UTC)

If you want me to write more modules for specific purposes, then please feel free to ask, but please understand that these modules are created by volunteers like you and me and there's no entitlement for anyone to be "given" anything. When I wrote the Wikidata module, it only fetched property values because qualifiers were still in development. Since then, others have added calls to fetch qualifiers which - as I've pointed out - can't cover every case, although I'm pleased they work in some circumstances. To fetch a property, it is sufficient to scan though all of the values associated with that property and return them as some form of list (or a single value or nil). If you try to fetch the value(s) of a given qualifier associated with a property, then when you create a list consisting of just the qualifier values you won't know which property value they belong to, should there be multiple values for the property. Re Burton–Taylor, there's nothing "incorrect" about organising the spouse data as a single property value with multiple qualifiers - in fact that's exactly what you need if you want to populate an infobox with the names of Burton's wives. Wikidata allows editors some freedom to organise the data entered in the way that they choose, and the challenge for anyone seeking to import that data into Wikipedia is to cater for all possible cases. -- RexxS ( talk) 13:30, 4 March 2015 (UTC)

I've been experiencing trouble with a bot I'm running in Javascript that signs in as a user and does a lot of stuff that takes ~3-4 hours to finish before finally editing some pages with the results. At the end I'm getting a badtoken error for the edits (which I hadn't gotten until recently, actually.. did something change?), so my only guess is that it takes so long the bot is being automatically logged out before it has time to finish. I am going to try one more time with the "keep me logged in" button selected, but just for information's sake, does anyone know the time limit for a session? Is there any way for a user to modify that setting for him/herself? Has that default value changed recently, i.e. in the last few weeks? Thanks!-- Dudemanfellabra ( talk) 01:19, 3 March 2015 (UTC)

Ok I ran the code again and got the same error, even with the "keep me logged in" button selected, so now I'm stumped. Just to check to make sure I wasn't being logged out after the run, I visited another page after the error and sure enough was still logged in, so that doesn't seem to be the problem.

The code is set up so that it can be run by two accounts--the bot one ( User:NationalRegisterBot) and this one, my personal one (for situations like this, mostly). While signed into my personal account, I just tried to run a smaller section of the code that only takes about 10 minutes to run instead of 3-4 hours but which relies on the same routine (literally the exact same JavaScript function) to edit pages, and it worked, successfully editing the page it was supposed to. This led me to believe that maybe there was just something wrong with fetching a token for the bot account, so I tried running the same function that worked on my personal account while signed in with my bot account, expecting it to fail, but much to my surprise, it worked!

Again, the piece of code that worked and the original 3-4 hour piece of code both rely on the same routine to edit pages at the end... the only difference between the two as far as practice goes is the time it takes for the two functions to run. It seems that since the 3-4 hour code takes so long to run, something freaks out with the edit token, causing it to be invalid. To figure out if that was the case--maybe the edit token had expired or something--I made the code fetch the edit token at the beginning of the run and then again at the end of the run so I could compare the two and got the same output for both (42163ed75d03ff490b30c96e9d59716a54f5440f+\, if that's relevant). Because they were the same, it doesn't appear to me that the token expires over the course of execution, so I'm really stumped. How can a function work in one instance and not in another?

All of this started about 2-3 weeks ago, so I suspect something has changed in the API or somewhere else, but I haven't been able to find any information about that. Does anyone know why I might be encountering the error I'm describing?-- Dudemanfellabra ( talk) 08:59, 3 March 2015 (UTC)

The test fetching the edit token at the beginning and end of the run should certainly have not given you the same token each time; even fetching two tokens one second apart should give you two different tokens (but both valid) since the end of October. Since you got the same token hours apart, whatever you're using to fetch the tokens is apparently caching them rather than fetching a new one the second time.

Ideally, your bot should be able to attempt the edit, and if it gets a badtoken error it should automatically fetch a fresh token and retry the edit.

As for the time it takes, the configuration is currently using the default of 1 hour for $wgObjectCacheSessionExpiry. I don't see any recent changes to the timeout, but I do see there was this recent change to session handling that probably made page views no longer reset the session timer. Anomie ⚔ 13:05, 3 March 2015 (UTC)

If I were you, i'd rewrite the bot to make use of mediawiki.api.edit module and friends, which do automatic token (re)fetching, uses promises etc and detects api errors. Examples of its usage can be found here. And make sure to add proper logging in the fails of the request, so that you KNOW what is failing instead of having to guess. — TheDJ ( talk • contribs) 13:54, 3 March 2015 (UTC)

I see you are using mw.user.tokens and not checking for bad-token failures. That is probably why it is failing. These tokens are valid 'pre generated' tokens, but your script is supposed to be able to fetch a fresh token if your request fails with bad-token for whatever reason. mw.Api knows about these constraints and applies or recovers from them as required. — TheDJ ( talk • contribs) 14:06, 3 March 2015 (UTC)

Thanks everyone for the responses. Modifying the code to use mw.Api makes everything work. I was not aware that mw.user.tokens generates a token at pageload, not at the time of execution. In fact, I misunderstood the idea of a token all together. Either way, I have everything working now, so mission accomplished! Thanks again!-- Dudemanfellabra ( talk) 09:25, 4 March 2015 (UTC)

@ Dudemanfellabra: you will want to wrap any usage of mw.Api with mw.loader.using( 'mediawiki.api.edit' ).done( function() { usage here } ), to guarantee that the edit module is loaded on demand if nothing else on the page has loaded the module yet. Developing user scripts with resource loader modules— TheDJ ( talk • contribs) 10:26, 4 March 2015 (UTC)

At times, I have been unable get a page from Wikipedia, and it appears that the servers are either down or temporarily overloaded. When this happens, I do not know if the problem is with my computer, the network, or Wikipedia. I usually diagnose the problem by trying other web sites, but the really does not tell me if anything was wrong with Wikipedia.

My email provider gives me a link to pingdom, where I can easily tell if the email servers were down. Does Wikipedia keep track of down-times, response times, or server loads? Where should I look?

If I had a graph of Wikipedia response-times, I could plan on using Wikipedia when it was lightly loaded.

Thanks.

Comfr ( talk) 04:32, 3 March 2015 (UTC)

Lots of data is available at http://gdash.wikimedia.org/ - there is no one graph of some "response-times" though... -- Malyacko ( talk) 08:32, 3 March 2015 (UTC)

There is some information on status.wikimedia.org, eg. the response times for HTTPS wikipedia. -- Sitic ( talk) 22:13, 3 March 2015 (UTC)

Hello.

I was trying to make the medal templates to link to an optional target by adding link={{{link}}} in {{ gold1}}, so the link can be passed on to the {{ sort}} template. It works fine, but when you don't provide a link to {{ gold1}}, it links to the gold medal icon itself, instead of not linking to anything at all. What is it that I do wrong?

For an example, check the Brittany Bowe article, section "Results overview", where I've linked the gold medal icon in the last row, left-most column, to an article, and it works, but the other gold medal icons in the same row link to the icon itself. I don't want that, and why does this occurs when the link parameter supplied is empty?

HandsomeFella ( talk) 14:42, 3 March 2015 (UTC)

This is result, that you wanted? See my . -- Edgars2007 ( talk/ contribs) 15:26, 3 March 2015 (UTC)

Yes, it is. But the parameter is empty by default, so why does one have to add that code to avoid linking to the medal icon? HandsomeFella ( talk) 15:50, 3 March 2015 (UTC)

I see now that I had missed that pipe character. Thanks. HandsomeFella ( talk) 17:21, 3 March 2015 (UTC)

...starting late last week on several different Mac running various fairly-new and fairly-old firefox versions. I've tried disabling the gadget (hovering on a wikilink gives me a yellow box with just the target name) then re-enabling it gadget (reverts back to nothing appearing while hovering on a wikilink) and cache purge/refresh. Same on commons as well as enwp. On a Mac where firefox has not accessed WP in a long time if at all, popups do work. So it seems like "something at some level" has changed to be incompatible with "something else", but I don't know how to diagnose further what/where. DMacks ( talk) 04:08, 1 March 2015 (UTC)

It works for me with Firefox in Windows Vista. Does it work if you log out and click https://en.wikipedia.org/?title=Example&withJS=MediaWiki:Gadget-popups.js&withCSS=MediaWiki:Gadget-navpop.css? That also works for me. PrimeHunter ( talk) 04:25, 1 March 2015 (UTC)

Popups works for me on OSX 10.9.5, Firefox 35. Keegan ( talk) 05:42, 1 March 2015 (UTC)

Updated to FF 35.0.1edit: and 36.0 to be sure, and popups are still fine. Keegan ( talk) 05:44, 1 March 2015 (UTC)

Removed AdBlock (it hadn't been a problem before, but may as well rule it out), also tried manually importing it in my common.js, still nothing. DMacks ( talk) 10:22, 1 March 2015 (UTC)

It's working for me, although I had a weird problem with a popup appearing (after accidentally hovering over an article title) and then refusing to go away a few days ago. What OS are you running? Whatamidoing (WMF) ( talk) 19:58, 4 March 2015 (UTC)

When did we get Smurf buttons for < inputbox>? See Wikipedia:Editnotice#Creating editnotices. --   Gadget850  ^talk 21:43, 1 March 2015 (UTC)

Hi. This is the "mw-ui-button" CSS class. It was added to InputBox here: < https://phabricator.wikimedia.org/rEINB7ce80c51a5f0c6ee8e78758afb924bc18b00d525>. You'll see some additional mw-ui-related changes at < https://phabricator.wikimedia.org/diffusion/EINB/>. -- MZMcBride ( talk) 22:06, 1 March 2015 (UTC)

@ MZMcBride: But, what are the CSS specifics of class="mw-ui-button"? The reason I ask is that that class does not yet exist over at Wikia. Therefore, I need to add the class details locally to MediaWiki:Common.css. Unfortunately, I could not discern the simple CSS setup from those phabricator pages. Thanks! — Spike Toronto 18:57, 3 March 2015 (UTC)

Hi SpikeToronto. Newer versions of MediaWiki use Less for Cascading Style Sheets. The relevant code for ".mw-ui-button" is here: < https://github.com/wikimedia/mediawiki/blob/0c8327466bebd44a9c0f60cd010307446b9ead63/resources/src/mediawiki.ui/components/buttons.less> (found via this search). -- MZMcBride ( talk) 05:22, 4 March 2015 (UTC)

@ MZMcBride: Thanks!! — Spike Toronto 20:29, 4 March 2015 (UTC)

We have a vast number of templates for ending tables, whose content is |}.

I propose that we redirect them to {{ End}}, which has the same content, and replace instances with {{End|Foo}}, where "Foo" is the name of the template which starts the table, as in this edit.

Eventually, a bot could do substitution for us. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 3 March 2015 (UTC)

• support --   Gadget850  ^talk 20:06, 3 March 2015 (UTC)
• (ec) Redirecting is fine, but replacing the templates with {end|...} isn't very usefull; it does somewhat confuse the otherwise obvious pairing of templates. -- [[ User:Edokter]] {{ talk}} 20:08, 3 March 2015 (UTC)
  • Actually it makes it clearer in some instances. In Andy's example, the pair is {{ public art table}}/{{ public art footer}}. And many templates simply use {{ end}}. --   Gadget850  ^talk 20:14, 3 March 2015 (UTC)
    • The end template in that case would be would be {{End|Pubic art table}} - easily matched to the start of the table. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 3 March 2015 (UTC)
      • "Pubic art table" is a funny typo. So the very example of the proposed system is already wrong, losing the ability to find the end by searching the source for "public art", and making it impossible for {{ End}} to detect the parameter if we want that later. PrimeHunter ( talk) 13:24, 4 March 2015 (UTC)
• Oppose. The templates are from pairs like {{ Public art header}} and {{ Public art footer}}. The current system gives us the ability to easily change implementation of the pair, for example if something is added to the bottom or it's no longer a table. Your suggestion {{End|Public art table}} could in theory change implementation by testing the parameter value in {{ End}} and do something different for Public art table, but it requires that users always remember the parameter and always give it the exact same value. The parameter is ignored by {{ End}} so users will see no difference if they omit or misstype it. And {{ End}} is fully protected for good reasons but it means most editors would need help to change implementation of low-use cases like the currently unprotected {{ Public art footer}}. We would also lose the ability to use Special:WhatLinksHere/Template:Public art footer, for example to compare it with Special:WhatLinksHere/Template:Public art header. Pairs like {{Public art header}} and {{Public art footer}} are also easier to spot in wikitext, especially when they start the line. I see no significant advantages of the proposed system. It would make it easier to fix if wikitext suddenly stopped accepting |} as code for table end but that seems highly unlikely. PrimeHunter ( talk) 20:26, 3 March 2015 (UTC)
  • You appear to be considering improbable hypothetical scenarios, such as "[if] it's no longer a table" and "testing the parameter value in {{ End}}". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 3 March 2015 (UTC)
    • Eh yeah of course those are hypothetical. Wasn't he just saying that that was the whole point ? To keep that option open ? Such changes have happened in the past. Switches between divs and table structures have been quite common, and I don't think we have seen the last of them yet. I advise against substitution. Redirects could be possible, but might lead to people using the target instead. Indirect transclusion seem appropriate, but will wast more resources. — TheDJ ( talk • contribs) 00:27, 4 March 2015 (UTC)
    • The proposal looks like a solution looking for a problem. If there is no problem to solve then there is no reason to destroy the current flexibility and create potential problems. Who knows whether {{ Col-end}} will always have a table end? If we replace uses by {{ end}} then maybe it will, because we have made it very hard to change it. It currently says <p></p>|} (newlines omitted in code display here), so I guess the current version would actually be excluded from the proposal. Lots of end templates are not an isolated table end or may not be so in the future. {{ Multicol-end}} is </div>|}</div>. {{ Football squad end}} is |}|}. {{ Extended football squad end}} had been |} since 2010 but added code to give or request a source last week. And consider {{ S-end}} where the documentation says (I don't know whether it actually works like that currently): "The various succession box templates are considered navigational content and thus are excluded from print in the PDFs and printed books. However, {{ end}} can be used to end any table, thus that template cannot be excluded from print. However, {{ s-end}} can be excluded without any negative repercussions. Similar templates that are unambiguously the end of tables which should be excluded in print should redirect here, rather than to {{ end}}." If we redirect the templates then it's certain and not just a hypothetical that some users will use the targets instead. PrimeHunter ( talk) 01:02, 4 March 2015 (UTC)
      • If "{{ Col-end}}... currently says <p></p>|}", then it is clearly outside the scope of this proposal; and thus a red herring (and, logically, a straw man). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:11, 4 March 2015 (UTC)
        • It's an example of how tables can end in many ways depending on the chosen formatting. This one started out as |}|} but later became |}, so it would be within this proposal which would make it unable to restore the old formatting. PrimeHunter ( talk) 13:24, 4 March 2015 (UTC)
    • I didn't say they are "hypothetical", I said they are "improbable hypothetical scenarios". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:11, 4 March 2015 (UTC)
• I agree with redirecting end templates to {{ end}}, but we shouldn't replace the instances for the reasons that PrimeHunter spells out. If someone does ever need to change one of the end templates, then that would be the difference between a one-edit task and a task requiring bot work. — Mr. Stradivarius ^{♪ talk ♪} 00:52, 4 March 2015 (UTC)
• Oppose per PrimeHunter. This is too rigidly tied to the current implementation of these templates and would make it much more difficult to change them individually to a different implementation if we someday wished to do so. And what is broken about the current system that this would fix? — David Eppstein ( talk) 00:03, 5 March 2015 (UTC)

The problem that I reported here to no avail just happened again. This seems obviously broken and in need of a fix. Could some kind person log it as a bug? 109.151.63.210 ( talk) 21:50, 4 March 2015 (UTC)

Please see mw:How to report a bug (exact steps, browser and OS info etc. are welcome). -- AKlapper (WMF) ( talk) 08:11, 5 March 2015 (UTC)

When I go to the contributions of an editor, and click his logs I get 'all public logs'. When I go to the contributions as an admin, I am however often not interested in all their public logs, but in all logs, or even in all non-public logs. However, currently I have to go through every single non-public log to see whether the editor was logged in one of them and for what reason. Could the system be changed to standard show 'all logs that I am allowed to see with my userrights' (which for ordinary users defaults to 'all public logs' as well), and have two options 'all public logs' (to get an overview of all regular information like account creation, moving stuff around and such), and 'all non-public logs' (which shows why a user ran into problems, or why a user is problematic) as second and third in that dropdown menu. -- Dirk Beetstra ^{T C} 03:38, 5 March 2015 (UTC)

In the article Circular prime, the References section displays as follows for me (bolding is mine):

1. The Universal Book of Mathematics, Darling, David J., retrieved $1 $2 Check date values in: |accessdate= (help)
2. Prime Numbers - The Most Mysterious Figures in Math, Wells, D., retrieved $1 $2 Check date values in: |accessdate= (help)
3. Circular Primes, Patrick De Geest, retrieved 25 July 2010
4. The mathematics of Oz: mental gymnastics from beyond the edge, Pickover, Clifford A., retrieved $1 $2 Check date values in: |accessdate= (help)

It looks like something got messed up with the way the access dates are validated, since $1 $2 is being shown instead of the specified access date. Could someone familiar with that bit of the code take a look? Thanks, 28bytes ( talk) 15:08, 5 March 2015 (UTC)

The Universal Book of Mathematics, Darling, David J., retrieved 25 July 2010 (see page 70) {{ citation}}: Check date values in: |accessdate= ( help) is using |accessdate=25 July 2010 (see page 70) which is a bad date. But this should not be exposing the variables. Reported at Module talk:Citation/CS1/Archive 11#Date checking. --   Gadget850  ^talk 15:13, 5 March 2015 (UTC)

16:42, 2 March 2015 (UTC)

Documented direct section links at Help:Section#Direct section links. --   Gadget850  ^talk 15:41, 6 March 2015 (UTC)

As of today, categories appear to be trying to avoid splitting articles sorted under the same letter. For any large category this results in a single column of 200 entries, which looks ridiculous. Is this a site-wide change or a problem on my end? — Xezbeth ( talk) 08:23, 5 March 2015 (UTC)

I'm seeing three columns, even if there's no heading to split at. (Maybe browser-related?) If there's a split after the first article in the cat, but no others in the first 200 (for example at https://en.wikipedia.org/?title=Category:Living_people&from=9th%20W), I see a column of 1 and two columns of about 100 each, which is still fairly ridiculous, though. — Cryptic 08:34, 5 March 2015 (UTC)

I only get the single column with Chrome, IE doesn't have that problem. Even so, having different sized columns everywhere looks silly compared to the uniform categories we've had until now. — Xezbeth ( talk) 08:47, 5 March 2015 (UTC)

Categories switched from tables to CSS columns. There are some minor errors in its implementation though, so I added my comments in phab:T55130. -- [[ User:Edokter]] {{ talk}} 09:26, 5 March 2015 (UTC)

I'm seeing two columns in Chrome: the first column contains only 5 or 6 entries and all the rest are crammed into the second column, there is just whitespace where the third column should be. Roger (Dodger67) ( talk) 18:09, 6 March 2015 (UTC)

The templates {{ oldpuffull}} and {{ oldffdfull}} are only shown on en.wikipedia.org but not on en.m.wikipedia.org. This causes confusion to the users of the mobile website. What is causing this and how can this be fixed? -- Stefan2 ( talk) 19:51, 6 March 2015 (UTC)

What's causing this is the presence of the tmbox class. Mobile site has the CSS declaration display: none !important; applied to a number of classes, including tmbox. It's exactly the same issue as the navbox and metadata classes that occasionally come up on this page. -- Redrose64 ( talk) 20:04, 6 March 2015 (UTC)

Yeah I have been bashing the mobile team a bit on this topic. So far all this hiding hasn't been too bad (hardly any Wikipedians were using the mobile site anyways), but they really need to start investing some time on how to reduce those hidden content blocks and present the same information, in better ways. Like, a navbox is totally pointless on my phone, but there are ways you can use the contents of navboxes, to serve a similar need on mobile.. (carousel of related articles for instance). Similarly, I might not want to see a full section ambox on my smaller phone, but i might want to see a right floating small warning button or something that allows me to show the information. I don't know, just throwing ideas up there. — TheDJ ( talk • contribs) 21:22, 6 March 2015 (UTC)

Re File:Gerald Farinas saimin at Shiro's Saimin Haven in Hawaii.JPG, I made a few tries with copying this over to Commons with the Move to Commons Assistant. It does not come up with the full file image name: Step One. I've copied other images to Commons with assistant and had no problems. I'm thinking this file name is too long for the assistant to recognize/handle. Continuing the process with the shortened name brings up a message that no such file exists. If I am correct, would someone with file mover permission please move it to a more apt name? — Maile ( talk) 20:42, 6 March 2015 (UTC)

The Wiki' PDF generator is still funky. In the past several days, every time I attempt to generate and download a pdf file of an article I get a 'Wiki' Foundation' error. Will someone look into that or forward this message to someone who knows how to do something about it? Thnx. -- Gwillhickers ( talk) 23:00, 4 March 2015 (UTC)

@ Gwillhickers: Does this happen for you only with large books, or also with single-article PDFs? We're aware of issues with large books due to HHVM and investigating, see phab:T89918.-- Erik Moeller (WMF) ( talk) 05:39, 5 March 2015 (UTC)

@ Erik Moeller (WMF): I was getting a Wiki' Foundation error even when I attempt to download one article. Just now however I was able to download a PDF on Abraham Lincoln, but got an Wiki' error when I attempted to do so with the Ulysses S. Grant article. Just to complicate matters. -- Gwillhickers ( talk) 21:46, 5 March 2015 (UTC)

@ Gwillhickers: OK, thanks for the update. This is likely the same issue -- timeout due to very large file. We'll aim to get this resolved ASAP, sorry for the inconvenience.-- Erik Moeller (WMF) ( talk) 06:30, 7 March 2015 (UTC)

Unrelated to my other thing here. "No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker." above Not that I care but why? – DangerousJXD ( talk) 10:39, 7 March 2015 (UTC)

See WP:FDB#Fully automatic spell-checking bots. -- Redrose64 ( talk) 11:16, 7 March 2015 (UTC)

@ DangerousJXD: You can also use tools such as AutoWikiBrowser, WPCleaner, and wikEd to find and fix spelling errors. See Wikipedia:AutoWikiBrowser/Typos for the list of typo rules and other information. GoingBatty ( talk) 13:33, 7 March 2015 (UTC)

At User talk:RightBKC I'm trying to leave a copyvio warning, but get the message "User talk page modification: Could not resolve redirects for: User_talk:RightBKC". I also can't find any history for the page, although it's possible there isn't any. Thanks. Dougweller ( talk) 12:21, 7 March 2015 (UTC)

That's very strange. I understand why Twinkle can't resolve it (the page redirects to itself) but I don't understand why the logs show the page as having been deleted but no edits to it (you can't delete something that was never created, right?) Since you're an oversighter I'm assuming there aren't any edits that were oversighted, correct? If there were, that might explain the missing history; if not there may be something screwy going on with the global rename function. 28bytes ( talk) 12:47, 7 March 2015 (UTC)

Thanks. I can't see anything, so maybe there isn't any history. At least two editors reverted copyvio by this user but don't see to have warned him. Dougweller ( talk) 13:25, 7 March 2015 (UTC)

Database error, I've been pointed to [20]. Dougweller ( talk) — Preceding undated comment added 14:58, 7 March 2015 (UTC)

Is the "page information" page (e.g. [21]) editable by local admins (perhaps via a Mediawiki: page)? I notice there is an outdated link to the toolserver in the footer. 28bytes ( talk) 13:02, 7 March 2015 (UTC)

Do you mean this list? -- Redrose64 ( talk) 13:15, 7 March 2015 (UTC)

Yes, that's exactly what I was looking for. Thanks! 28bytes ( talk) 13:47, 7 March 2015 (UTC)

Which is funny, because apparently I've actually edited that page before. Must be getting old... 28bytes ( talk) 13:48, 7 March 2015 (UTC)

?uselang=qqx or &uselang=qqx shows the name of used MediaWiki messages: https://en.wikipedia.org/?title=Wikipedia:Village_pump_%28technical%29&action=info&uselang=qqx. PrimeHunter ( talk) 14:12, 7 March 2015 (UTC)

Very handy, thanks! 28bytes ( talk) 23:53, 8 March 2015 (UTC)

Since a while ago (I don't know exactly when) tables header cells (=cells which are coded with ! instead of|) don't have a background color anymore on the mobile version of the site. Why is that? Furthermore, even in the desktop version their background color has become much lighter and is actually hardly noticeable at all, especially if a background color is coded for the whole table. There is hardly any contrast at all. Why? Many other wikipedias have much darker ( and in my opinion better) background color for their header cells (e.g. German, Dutch, ...). If it's important I generally use desktop Safari 8.0.3. T v x1 02:15, 8 March 2015 (UTC)

The desktop CSS for the wikitable class is defined in mediawiki.legacy/shared.css. There was a recent change to padding, but not color. Would you give an example?

I don't know where the mobile CSS repository is located. (anyone?) But I can see that the table background is set to transparent. As to why, my SWAG is that someone thought it was a good idea. --   Gadget850  ^talk 12:37, 8 March 2015 (UTC)

Mobile Frontend extension. All styling files. -- [[ User:Edokter]] {{ talk}} 14:12, 8 March 2015 (UTC)

There has been no change in table color here, but I note that the Dutch Wikipedia has set a darker color for header cells. -- [[ User:Edokter]] {{ talk}} 14:12, 8 March 2015 (UTC)

Ok. If the color wasn't changed in the desktop I might have been wrong. I thought the contrast had reduced but I might be mistaken. I do think our header color is rather light however. T v x1 22:43, 8 March 2015 (UTC)

When I look at the Writer article using Firefox 36.0.1, the references are displayed on top of the numerous {{ Wikisource}} templates. When I look at the same article using Internet Explorer 11, the references start after the {{ Wikisource}} templates. What is the correct way this article should be displayed? Thanks! GoingBatty ( talk) 15:57, 8 March 2015 (UTC)

Moving File:Tomas Transtromer and Modhir Ahmed.jpg up a bit will fix this. So will removal of irrelevant Wikisource templates.--   Gadget850  ^talk 17:09, 8 March 2015 (UTC)

@ Gadget850: It appears that the picture of the Nobel Prize winning poet is supposed to be in the Awards category. Presuming that the image and Wikisource templates are important enough to be there (which they might not be), what would be the next step? GoingBatty ( talk) 21:34, 8 March 2015 (UTC)

The image is taller than the section, which causes the problem. Clear it with {{ -}} (which will add a lot of whitespace), reduce the height or movie it. --   Gadget850  ^talk 22:08, 8 March 2015 (UTC)

The box-style {{ Wikisource}} templates can be changed to {{ Wikisource-inline}} if the boxes interfere with content further down the page - Evad37 [ talk 23:26, 8 March 2015 (UTC)

The templates are in the wrong section, for a start - Wikipedia:Manual of Style/Layout#Links to sister projects says to put them in the last section, which for Writer is "External links" - but they're in "References". The {{ commons}} and {{ commons category}} templates advise "do not place this template in a section containing columns"; but {{ Wikisource}} does not. Perhaps it should. -- Redrose64 ( talk) 00:27, 9 March 2015 (UTC)

@ Evad37 and Redrose64: I combined your advice and replaced the {{ Wikisource}} templates with a {{ Wikisource-inline}} template in the External links section. Others can decide if these templates are really worthwhile or not. Thanks everyone! GoingBatty ( talk) 01:35, 9 March 2015 (UTC)

I thought there was an inline version, but it wasn't linked from {{ Wikisource}}. --   Gadget850  ^talk 01:39, 9 March 2015 (UTC)

There is an interest in tracking progress toward gender equality by dynamically updating statistical measure of self-identified "gender pronoun usage preference" on user pages to confirm trend of progress to achieve gender parity. This is likely admin only access to technical user data. Does anyone know how easy/how difficult it would be to gather and then print out these statistics? LawrencePrincipe ( talk) 21:16, 13 February 2015 (UTC)

@ LawrencePrincipe: Actually, you can access it using the "gender" magic word like so: {{gender:username|he|she|unset}}

So if you enter {{gender:Philosopher|he|she|unset}}, you get he, indicating hat I have my preferences set to "he". I do the same thing to you and see that yours is "unset". –  Philosopher  ^{Let us reason together.} 00:14, 14 February 2015 (UTC)

@ Philosopher: On a one-by-one basis that works, though the stats are needed system wide on a weekly and/or monthly basis. That is, out of the total number of new users per month, what ratio self-identified as female and what ratio self-identified as male system-wide. Can it be done system-wide for being dynamically updated? LawrencePrincipe ( talk) 00:35, 14 February 2015 (UTC)

Listed at Wikipedia:Database reports/User preferences but out of date. --   Gadget850  ^talk 00:53, 14 February 2015 (UTC)

@ Gadget850: Those stats are quite fine, but quite dated: "User preferences statistics; data as of 23:12, 19 June 2014 (UTC)." Is there a way to update them, or get a month-by-month graph? LawrencePrincipe ( talk) 02:01, 14 February 2015 (UTC)

Looks like this was run on the old Toolserver. I don't know of a replacement. --   Gadget850  ^talk 02:23, 14 February 2015 (UTC)

Note that this data is very unlikely to be useful or meaningful. The preference is designed to be used for gendering language correctly (not an issue in English) and not for demographic tracking; most users will never set it. Andrew Gray ( talk) 15:28, 14 February 2015 (UTC)

@ Andrew Gray: The gender stats from the UN study from 2010 are the only ones currently is use and are dated. Although not optimal, looking at the "user preference choice of gender" offers a useful approximation. It is not optimal, but useful for gaining some insight into the current status of the gender stats. Are you familiar with the new Toolserver applications and data base access? LawrencePrincipe ( talk) 16:02, 14 February 2015 (UTC)

FWIW, this is the WMF Analytics discussion from last year on whether it was likely to be useful data. Andrew Gray ( talk) 19:51, 14 February 2015 (UTC)

Hi Andrew Gray; That conversation between Ryan Kaldari, Aaron, and Steven Walling at WMF Analytics was interesting on gender preference data being used in a sub-optimal way of getting gender stats updated from the old 2010 UN data. If anyone has their user id name, then I could ping them to try to find someone who knows the new Toolserver. The link just provided above here by Gadget850 was strongly on target with women editors estimated at 19%, which is actually quite close to the 2010 UN numbers. If anyone knows the new Toolserver well enough, or has the user id for any of the above (Ryan, Aaron, and Steve Walling) then I could ping them. LawrencePrincipe ( talk) 20:46, 14 February 2015 (UTC)

I'm not sure what you mean by "knows the new toolserver", but if you have an idea of what the old SQL query was you can try it at quarry - no need for a toolserver/labs account. I would strongly stress that the 19% is probably as much random chance as meaningful data, though. Andrew Gray ( talk) 20:56, 14 February 2015 (UTC)

Does someone know how to update this link: Wikipedia:Database reports/User preferences. LawrencePrincipe ( talk) 21:22, 16 February 2015 (UTC)

@ LawrencePrincipe: The code that generates this report is at Wikipedia:Database reports/User preferences/Configuration. Looks like it comes from the Toolserver era, so it's going to need adjustments, but you should be able to run the SQL queries at least without modifications on Quarry (mentioned above). Perhaps you can get MZMcBride (its author) to make it work. Matma Rex talk 12:46, 17 February 2015 (UTC)

@ Matma Rex: MZMcB wrote that for the old toolserver, and what is needed to maintain stats now is if it can be updated/converted to the new toolserver to update the stats. Any way that this can be done? LawrencePrincipe ( talk) 01:53, 18 February 2015 (UTC)

(un-indent) phabricator:T60196 is what's blocking us here. -- MZMcBride ( talk) 20:03, 19 February 2015 (UTC)

@ MZMcBride:@ Rich Farmbrough: That issue seems to have been addressed by @Rich who appears to be able to find a way to get the gender stats on a monthly basis (see section immediately below). The last update to comments on the phabricator link you just provide was from 14Dec which has not been updated since then. Any chance of getting the month-by-month gender preference stats for the last three or four monthly intervals? LawrencePrincipe ( talk) 00:09, 20 February 2015 (UTC)

Section break for Wikimedia research stats

There was a user survey done by the WMF, the results of which have not been released yet. There is a paper which describes identifying users gender by name as a supplementary process (I forget which paper). There is also some work on gendered linguistic differences on Wikipedia, and the conclusion I took from that was that it is not valid to extrapolate gender tells from general Internet discourse to Wikipedia discourse without supporting evidence. I also analysed some small samples of text on a standard "gender tester" with poor results. However there is no reason that a full text analysis of all talk page contributions could not be done, and it might well lead to a model with good gender predictive power, since there is a valid training set consisting of the gender identified users. All the best: Rich  Farmbrough, 11:46, 18 February 2015 (UTC).

@ Rich Farmbrough: That paper you mention would be interesting to locate if you have any leads. The issue of using the new toolserver to count up the number of new accounts which self-identify as female seems to be difficult to accommodate, even though the old toolserver apps did this with ease. The research apps you describe above sound pretty advanced, though the simple counting of new accounts which self-identify as female would offer a first step if someone could figure out the new toolserver. LawrencePrincipe ( talk) 15:18, 18 February 2015 (UTC)

The last 5000 new accounts (that have edited) were 9 male, 1 female, 4990 unset. All the best: Rich  Farmbrough, 16:13, 18 February 2015 (UTC).

Thanks, Rich, that is important to keep in mind (also, specifying user gender is only possible since october 2011):

• Quarry Masc vs Femin ptwiki_p
• Quarry Masc vs Femin in dewiki
• Quarry swedishWP gender
• Quarry swedishWP admin gender

"However there is no reason that a full text analysis of all talk page contributions could not be done, and it might well lead to a model with good gender predictive power, since there is a valid training set consisting of the gender identified users." - Except that this would be freaking creepy! -- Atlasowa ( talk) 16:37, 18 February 2015 (UTC)

• Quarry Male and female users accounts on enwiki

Declared: male = 502573, female=98369 , female = 16.40% of those with declared gender.

• Quarry Male and female admins on enwiki

Admins: female=56, male= 600.

All the best: Rich  Farmbrough, 17:04, 18 February 2015 (UTC).

@ Rich Farmbrough:@ Atlasowa: Those are remarkable gender stats, but what does 500,000 male editors refer to? The Economist newsweekly has stated here [ ^[1]] that there is a total of 50,000 editors in 2007, which went down to 30,000 editors in 2014. What does your 502,573 number mean, and is it related to the 2011 date cited by @Atlasowa? Maybe there is a simple explanation. LawrencePrincipe ( talk) 17:50, 18 February 2015 (UTC)

The vast majority of the 20,555,036 Wikipedia accounts have never edited (or have no edits visible in their contributions). There are several obvious reasons for these accounts, and some not so obvious:

1. Someone sees some vandalism and creates an account, but it is fixed by the time they get there.
2. Someone creates an account but finds editing too hard, changes their mind, gets distracted (ooh look a butterfly!)
3. Accounts created to protect a name (e.g, User:Placeholder, and WP:DOPPELGÄNGER accounts) or to reserve a name
4. Accounts who try to vandalise and give up because the edit filters won't let them
5. Accounts that created an article which was later speedy deleted
6. Accounts where the password was forgotten, or set wrongly
7. Sleeper socks

and probably a few more.

And the other figures are based on "active editors" which has various definitions, usually in terms of X edits per month or year.

All the best: Rich  Farmbrough, 18:49, 18 February 2015 (UTC).

LawrencePrincipe, the Economist refers not really to "total editors" but to "active editors" (Active Editors = Registered (and signed in) users who made 5 or more edits in a month), see english WP summary stats, 2007: ~50,000 active editors and 2014: ~30,000 active editors. Same trend on other big WP, german WP summary stats 2007: ~9,000 active editors and 2014: ~6,000 active editors. Total (ever) Registered users on enWP: 24,107,661, that makes 500,000 male editors a very small part. Same for admins: Out of 1,363 enWP Administrators, 56 are female and 600 male. -- Atlasowa ( talk) 19:28, 18 February 2015 (UTC)

@ Rich Farmbrough: The comments all appear to be in agreement. The stats would be interesting to see for results for the last 10,000 editors and the last 15,000 editors. Are they all consistent at about 10% gender pronoun usage? @ Atlasowa: The Economist article also states that non-English Wikipedia is stable at about 42,000 active editors, up or down 2000 for seasonal variation. The 'active' editor number appears to be a significant one for all the reasons that Rich has stated above. Can the stats and tools you provided be used as reliable data to be published from Wikimedia? LawrencePrincipe ( talk) 21:41, 18 February 2015 (UTC)

The Quarry tools are there, and I might be able to make something better. (Well I am able, but I need to brush up my SQL.)

The 5k figure I can potentially get you the 10k and 15k figure. To replicate those figures, it is important to state the time by which the accounts needed to have edited to qualify. Probably simpler just to list the 15k accounts.

I do agree with Steve Walling, though, that the declared numbers are a poor proxy. For example GamerGate may have made females lees willing to self-identify (or it may not.. but it's a potential confounding factor.)

All the best: Rich  Farmbrough, 23:36, 18 February 2015 (UTC).

@ Rich Farmbrough: All those stats would be useful since at present there is no new data on gender stats since the 2010 UN study. If you say "it is important to state the time" for the 5k, 10k, 15k then it may be just as easy to double the time interval to indicate how many women registered (approx. 10k level), and the triple the time interval to approx. the 15k level, if that seems reasonable. The actual number for each time interval would tell the story. Regarding your other question about women "GamerGate" concerns, my understanding is that if women were given confidence that self-identifying gender would help them to better achieve gender parity, then they would have every incentive to do so. Historically, a chance to achieve goals is often a high incentive to participate. LawrencePrincipe ( talk) 00:31, 19 February 2015 (UTC)

Absolutely, it's the case that Editathons based on improving coverage (achieving gender parity) on women's history, women's literature etc. are very successful in attracting participants (of both genders) I believe for this reason. However the motivation to edit is generally not related to gender parity, and those who are really passionate about this tend to think (perhaps rightly) that their time is best spent encouraging other women and girls to edit.

As far as the numbers go 5,000 editors is about 2 or 3 days worth. But I can take samples at monthly intervals, or some such. All the best: Rich  Farmbrough, 00:52, 19 February 2015 (UTC).

If the monthly stats are a convenient time interval then by all means it would be useful to see it, for a few monthly intervals if possible. It is not clear to me why this data is being called unreliable by different editors. This is the same data source for counting the number of new editors and number of edits per week, per month, etc, with no-one thinking these data counts as being unreliable? Why call them unreliable for counting personal pronoun preference selection on user pages? LawrencePrincipe ( talk) 20:37, 28 February 2015 (UTC)

It's unreliable because it's not complete. Making your gender public is optional: those I have met in real life know my gender, but I can (and do) hide it from those who only know me electronically: {{ he or she|Redrose64}} → he or she. I expect that there are many editors who have not set their gender simply because they don't know that it is possible for them to do so - and some may have set it without realising that it's not compulsory. By contrast, the number of edits that I make is permanently recorded, and moreover is something that I cannot hide. -- Redrose64 ( talk) 20:23, 1 March 2015 (UTC)

I have produced a little graph at Wikipedia_talk:WikiProject_Countering_systemic_bias/Gender_gap_task_force#F.2FM_ratio_of_gender_identifying_editors_on_en:WP which shows the gender ratio of new gender identifying editors month by month. All the best: Rich  Farmbrough, 01:16, 4 March 2015 (UTC).

redrose and Richf; those graphs are very good with comments on talk there. It is a priority to ask redrose how hard it would be to make a gender prefered sign in tab as a system wide change. If jwhales is serious for more gender equality then these stats are essential to track progress. The larger the base of stats then the more reliable the data. LawrencePrincipe ( talk) 20:16, 4 March 2015 (UTC)

@ LawrencePrincipe: I don't see why it should be a priority to ask me - I am not a MediaWiki developer. Try phab: (but don't hold your breath, judging by a recent experience of mine, they will probably close it as "invalid" because one of them passed it to the wrong department). -- Redrose64 ( talk) 20:56, 4 March 2015 (UTC)

Giving a gendered create account tab at the top of the page sounded like it might be welcoming. LawrencePrincipe ( talk) 20:17, 5 March 2015 (UTC)

I guess Lawrence can have any priority he likes! And indeed you gave him one answer he needs, which is Phabricator.

For reference the figures I used are at https://meta.wikimedia.org/wiki/User:Rich_Farmbrough/Gender_balance.

I have thought about the Gender Prefs and ISTM that adding it to account creation would not be too onerous, especially if a "prefer not to say" or "hide" option, or both were provided.

All the best: Rich  Farmbrough, 23:22, 7 March 2015 (UTC).

Yes, agree completely. Right next to the "Login" tab we could leave the current "Create account" tab as is, and then place a color coded one next to it for an optional gendered "Create account for women" (pink scarlet color tab I assume). Phabricator (see comment of @ Redrose64: above) apparently wants an RfC for this first somewhere though I have never set one up for them. If someone can do it, then the tool of @ Rich Farmbrough: just described above would have a much richer supply of data to show gender equality trends and trending on Wikipedia. Such a "Create account for women" tab would also be able to give a simple news flash of current Edit-a-thons for women editors as one possible use among others. Cheers. LawrencePrincipe ( talk) 19:54, 8 March 2015 (UTC)

A special "Create account for women" pink tab is about as useful as this pink minibus. No. Just no. -- Redrose64 ( talk) 23:30, 8 March 2015 (UTC)

Data collection for user pronoun preference stats

There is much skepticism on the gender gap issue at Wikipedia and some argue that gender distribution in the IT industry in general, currently at about 28 percent, cannot be breeched. Is there a preferred position that you have taken on this issue (see Redrose above), that is, gender equality is possible or gender equality is not possible at Wikipedia. Rich's tools above depend on getting added supplies of gender data, if Wikipedia wishes to track these stats in a serious way, then what would you suggest. LawrencePrincipe ( talk) 01:13, 9 March 2015 (UTC)

About the "sign-in tab" idea, which I take to be an extra box on the account sign up page to specify gender: The GettingStarted team (now disbanded) did some work on things like that. Their overall finding is that every extra question you add to the sign-up process means that measurably fewer people sign up. "Pick a username, password, (optional) email address, and (optional) gender" will result in fewer accounts being created than the current "Pick a username, password, and (optional) email address". WhatamIdoing ( talk) 18:17, 9 March 2015 (UTC)

Hi @ WhatamIdoing: That seems very reasonable to leave the sign-up sheet as it is. The big question is the account sign-up tab on the system wide screen right before you get to the sign-up sheet. This new gender tab does not even have to be a long term thing, and 90 days would be sufficient time to collect much needed data for Rich's new gender stats tools discussed above. Since the tab on the system wide screen would be color coded and right next to the regular "Create account" tab, then there would be no need to re-ask the gender question after it is selected as "Create account for women". That makes it one less question on the sign-up form, and the data can still be gathered for the trial period of data collection of these statistics. Cheers. LawrencePrincipe ( talk) 19:00, 9 March 2015 (UTC)

I use monobook, and the default cell height and padding seem to have changed. The font size of the text appears to be the same, but the cells are definitely bigger. Where could a change have been made that would affect this for me? - Niceguyedc ^{Go Huskies!} 01:59, 26 February 2015 (UTC)

It's the same for me on Vector. Also, the bullets on bulleted lists are smaller (like a middot) and appearing to be at the bottom of the line instead of the usual larger size centered vertically on the line. Imzadi 1979  → 02:25, 26 February 2015 (UTC)

OS and browser please? -- [[ User:Edokter]] {{ talk}} 10:21, 26 February 2015 (UTC)

The bullets are now SVG instead of PNG. There is one known issue where Webkit on iOS does not size the bullets correctly. Webkit bug report. -- [[ User:Edokter]] {{ talk}} 10:28, 26 February 2015 (UTC)

I'm using Safari version 8.0.3 on MacOS X Yosemite (10.10.2). Firefox (v. 14.0.1) does not have the bullet size issue, however the bullets are still slightly off center vertically, putting them slightly too low, but not as low as in Safari where the are at the bottom of the line. In Chrome (v. 40.0.2214.115), the appearance is the same as Firefox: right size but slightly too low on the line. Just for kicks, I also looked in Opera (v. 12.12 ), and it's the same as Chrome and Firefox. The bullets look the same in Safari on an iPad running iOS 8.1.3 as they do on Safari running on the desktop. Imzadi 1979  → 15:46, 26 February 2015 (UTC)

@ Edokter: I'm using Windows 7 and Firefox 36. I don't actually notice anything different with the bullets, just the extra size of rows in tables. - Niceguyedc ^{Go Huskies!} 14:06, 26 February 2015 (UTC)

@ Imzadi1979 and Niceguyedc: The table cells for .wikitable have had their padding increased... doubled even. I found only this commit, but cannot find a accompanying task that discusses this change. (The bullets only affects Vector.) -- [[ User:Edokter]] {{ talk}} 14:43, 26 February 2015 (UTC)

Yep, the previous padding was pretty tight. You can see examples at testwiki:Wikitable padding. This change shouldn't have broken anything. Please provide links here or file Phabricator tasks if you see issues. -- MZMcBride ( talk) 15:50, 26 February 2015 (UTC)

While we are on this, where is the repository for shared.css? The catalog still links to SVN, and I can't find main on git. --   Gadget850  ^talk 16:02, 26 February 2015 (UTC)

[22] this? It's on mediawiki core repo. Glaisher ( talk) 16:09, 26 February 2015 (UTC)

Thanks! Since I keep referring to it, created {{ shared.css}}. --   Gadget850  ^talk 16:20, 26 February 2015 (UTC)

Is this a permanent change? I'm working with tables all the time on wikipedia and am quite upset by this change. Bigger tables don't even fot on a page anymore. Personally I think the tables harder to read and it looks untidy. Isn't there any way too make the table cells the size you want? Jahn1234567890 ( talk) 00:45, 27 February 2015 (UTC)

@ Edokter and MZMcBride: I also agree that the change should be reverted - Jahn1234567890's note on its untidy look is well take. It is also harder to follow visually, especially when zoomed in - as I have to because of vision difficulties - as the distance between the text and the lines is increased. Finally, vertical vs. horizontal whitespace is now unbalanced, as dmeonstrated in the small table at List of Governors of Iowa#Living former governors. –  Philosopher  ^{Let us reason together.} 01:48, 27 February 2015 (UTC)

Noted this through the notably wider infobox element, which contains a 6-column table. (see Uranium). Considerably widened. 1. Not a bad thing per se, except that relative image size now changed (i.e. it did not change absolutely), and there might be a guideline saying something about ideal infobox width ("33% body pagewidth max"?). The infobox now has fewer unforced line-wraps, but its whitespace is growing and growing. I hope this is within grand page-design philosophy. 2. Then I went to check a table that needs all 100% page width: {{ Periodic table}} in Periodic table. No effect so OK, because it has cellpadding= set (without this, the wider padding is breaking bad, undesired & useless). This leads to these points: a) are there similar tables (using & needing 100% width) that are gravely affected this way, because they are without cellpadding set?, and b) if I remember correct, cellpadding= is deprecated. Though this depends on it. 3. Btw, is the padding in the infobox enlarged too (mostly visible with section headers)? Conclude: nothing broken so far for me, some questions left. - DePiep ( talk) 08:14, 27 February 2015 (UTC)

{{ Periodic table}} should not be affected because it's not using .wikitable, not because of the obsolete attributes being used. I did replace those attributes with proper CSS. -- [[ User:Edokter]] {{ talk}} 09:34, 27 February 2015 (UTC)

I get this. (Had to squeeze out some ws). - DePiep ( talk) 10:45, 27 February 2015 (UTC)

What is this central point where deprecated code (like this) is listed? I only meet such statements off and on. - DePiep ( talk) 20:28, 27 February 2015 (UTC)

Wikipedia:HTML5. SiBr₄ ( talk) 21:09, 27 February 2015 (UTC)

My biggest problem with the table change is that this affects every single table on wikipedia. I don't understand why it was changed in the first place. The previous table size was just fine. And if you found that padding too small you could adjust the width by yourself. Now you have no option at all. Jahn1234567890 ( talk) 14:08, 27 February 2015 (UTC)

Yes. Why not make it 8px? - DePiep ( talk) 20:28, 27 February 2015 (UTC)

Hi Jahn1234567890. You can trivially reduce wikitable padding in your personal user CSS. In general, I think the increased padding looks better. The cited example above ( List of Governors of Iowa#Living former governors) looks good to me. -- MZMcBride ( talk) 20:47, 27 February 2015 (UTC)

Is there a central place where this whitespace philisophy is discussed? 'I think .. looks better' is not enough to me. - DePiep ( talk) 20:52, 27 February 2015 (UTC)

I dunno about a central place. testwiki:Wikitable padding is where I did my testing. I don't think anything broke and there seems to be general consensus that the increased padding (0.3em 0.4em instead of 0.2em) is an improvement. There are quite a few studies that suggest that adding whitespace improves readability. Maybe that would be a better argument? -- MZMcBride ( talk) 20:58, 27 February 2015 (UTC)

I'm lost. "I dunno", "don't think anything broke", "there seems to be general consensus" (where, where, WHERE I repeat). If this is the way classes are set, why are we talking anyway? Who cares. (and let me note that you still did not address my specific points). Make it 8px, I say. - DePiep ( talk) 21:04, 27 February 2015 (UTC)

@ MZMcBride: For results tables like this Dave Marcis the change makes tables like this look really untidy. Personally I'm unhappy with this change because with results tables in general this change makes those tables unnecessary big. But how would reduce wikitable padding in my personal user CSS? I haven't worked with this before. Jahn1234567890 ( talk) 21:28, 27 February 2015 (UTC)

Before I forget. Why was the table padding changed? It was just fine the way it was. I mean this change effects every wikitable on wikipedia. I think doubling the padding is a way to big change Jahn1234567890 ( talk) 22:02, 27 February 2015 (UTC)

(un-indent) Hi. gerrit:188311 contains most of the relevant discussion. DePiep: If you want to propose 8px, a Gerrit changeset or Phabricator task is probably what you want. :-) Also, the English Wikipedia's technical village pump is just one of many venues to discuss technical changes. Jahn1234567890: You'll probably want to add the following code (or similar) to User:Jahn1234567890/common.css:

table.wikitable > tr > th,
table.wikitable > tr > td,
table.wikitable > * > tr > th,
table.wikitable > * > tr > td {
    padding: 0;
}

Hope that helps. -- MZMcBride ( talk) 22:28, 28 February 2015 (UTC)

The concern is not just with Jahn1234567890, there are tables on wikipedia which are now unnecessarily huge for everyone. If there is a consensus to make this sitewide change (other than just MZMcBride and "a friend of his"), could a new class such as wikitablecompact be created that uses the old 0.2em padding? While affected tables could be rewritten to not use the wikitable class altogether (manually setting the style for each individual cell), it would be an major pain and create unnecessarily confusing code. -- Ahecht ( TALK
PAGE) 18:25, 1 March 2015 (UTC)

Hi Ahecht. Describing the increased padding as huge seems a bit extreme. I considered having wikitable variants, such as wikitable-compact, but the use-cases seemed to be pretty limited. If you'd like such variants available locally, we can modify MediaWiki:Common.css. This approach would require proposing alternatives and gaining local consensus to support the additional class(es) here. -- MZMcBride ( talk) 21:24, 1 March 2015 (UTC)

@ MZMcBride: The Padding increase is'nt huge to you perhaps, but for a person like me who works with tables all the time it is more than a huge change. All the results tables I made during my stay on wikipedia are now way to huge and untidy when they should be compact. I mean all the work I have done. Thats feels like a slap in the face to me. I honestly have no idea why the padding whould be changed like that. A lot of people are far from happy with this change. And to be honest I haven't seen a lot people who are happy with this change. There are way to many tables that are affected by this (and not for the best most of the time). There has got to be some way to work this out, because I think it is far from unreasonable to keep this change when there is so much objection against this change. Jahn1234567890 ( talk) 21:54, 1 March 2015 (UTC)

Any design or user interface change is going to elicit some negative feedback. A few people have complained and there are various options available, including per-user and per-site customizations, as explained above. -- MZMcBride ( talk) 22:38, 1 March 2015 (UTC)

• MZMcBride, you keep saying that this change was discussed, and referring to the gerrit page. Well, only developers read gerrit pages. This wasn't discussed with the people or projects that it affects. There's really no difference between a change that affects hundreds of thousands of pages made by WMF staff and changes that affect hundreds of thousands of pages made by volunteer developers: both should be discussed with the affected projects and communities before implementation. Basically, what I see here is one volunteer developer coming up with what he thinks is a cool idea, and having the connections to get it committed and distributed across WMF projects, without having discussed the proposal with anyone outside of the developer stream. That's pretty much the type of action that, when taken by WMF staff, you yourself have decried. I'd have expected better from you. Risker ( talk) 22:57, 1 March 2015 (UTC)
  • Hi Risker. Theoretically any change to MediaWiki core affects millions of pages... I don't see your point.

    The increased padding looks better on the whole. If you have proposals for discussing changes like this across 800-plus Wikimedia wikis (in addition to the thousands of non-Wikimedia MediaWiki wikis), please share. If you have specific technical problems to be addressed, please share.

    As it is, you seem to be arguing that a slight padding increase required extensive community consultation, which seems to be pretty insane. Do you really believe that's how development works or should work? -- MZMcBride ( talk) 23:04, 1 March 2015 (UTC)

    • No, MZM, what I expect is an analysis of the impact of the change and a method of informing groups that will be affected by the change of how it will affect them, and what they can do to mitigate the change. This is especially important when it comes to subjective changes that have not been requested anywhere by anyone and are, essentially, the wish and desire of a single developer. Risker ( talk) 23:14, 1 March 2015 (UTC)
      • Well, I am spending volunteer time responding to questions and concerns being raised here. :-) In this case, the change was so small/slight as to not warrant much in the way of notification or contingency plans. There was no expected breakage and the impact to users was considered negligible. -- MZMcBride ( talk) 23:26, 1 March 2015 (UTC)
      • Hello @ MZMcBride: Thank you for your reply. I Figured out how to work on my own CSS page. But somehowe I can't get the skin like it was before the padding change. Could ypu help me out? Jahn1234567890 ( talk) 23:22, 1 March 2015 (UTC)
        • Special:Permalink/649445826 looks fine. You should probably revert to that. -- MZMcBride ( talk) 23:28, 1 March 2015 (UTC)
    • I'm sorry, but I disagree witht he change as well. 0.2em to 0.4em is doubling, not "slight", and it shows. Any change with such a visual impact should have been discussed, at least in Phabricator. The perceived improvement is subjective and there was no premise that prompted this change. -- [[ User:Edokter]] {{ talk}} 23:26, 1 March 2015 (UTC)
      • No need to apologize, disagreement is fine. And the nature of Cascading Style Sheets allows individual sites or individual users to customize their experience by overriding the default padding or creating derivate CSS classes. There was a premise that prompted this change and it's explained in the commit message of gerrit:188311. -- MZMcBride ( talk) 23:32, 1 March 2015 (UTC)
        • So, shall we set it back to 0.2em on this wiki in Mediawiki:Common.css then? -- WOSlinker ( talk) 09:19, 2 March 2015 (UTC)
          • I am very inclined to do so. I will also raise a task and seek to revert it. -- [[ User:Edokter]] {{ talk}} 10:09, 2 March 2015 (UTC)
        • The premise of "it looks better" is not much of an argument, and considering the flack it has invoked, it was poorly researched for impact. You cannot send user to their personal CSS to 'undo' a change of this nature. What's even more troubling, that if you want to undo it in a table or template, it requires inline CSS for every table cell. -- [[ User:Edokter]] {{ talk}} 10:09, 2 March 2015 (UTC)

(un-indent) Err, "flack" is a pretty generous term. Maybe a half-dozen people have commented, which is probably about equal to the number of people who reviewed the Gerrit change. It might've been best to not make this edit yourself. Do you know if any other wikis have noticed or cared about this change to the wikitable padding? If the objections are specific to the English Wikipedia, a local override is perhaps for the best. Or perhaps 0.2em 0.4em. :-) -- MZMcBride ( talk) 05:17, 4 March 2015 (UTC)

If these comments had appreared on Phabricator, it would have been -2'd (rejected). If such a 'minor' change generates comments, it is generally a bad idea. All the above comments have merit, but I haven't seen you address a single one of them, ie. you can't explain why "it looks better". It is a subjective, unmeasurable criterium, which in itself is never a good reason for a change unless absolutely uncontested. That is not the case here. Please don't dismiss all comments as irrelevant; it makes you look as simply ignoring them. -- [[ User:Edokter]] {{ talk}} 09:00, 4 March 2015 (UTC)

In MZ's defense, he did give a non-subjective reason: that sort of small increase (an absolute change of one-fifth of the width of a single character) to white space improves readability (for average readers, on average content).

I think that a more productive conversation to have would be this: What changes do we need to wikitext table settings, to be able to accommodate both readability for average tables (more white space) and common sense for other tables (e.g., less white space for cells that only contain a single number), without having to set CSS tags in every single cell? WhatamIdoing ( talk) 19:47, 4 March 2015 (UTC)

Edokter: I think this conversation has jumped the shark. Your comments are horribly wrong, but they're not really worth addressing. You've now imposed your preferred padding on the English Wikipedia; I think we can leave MediaWiki alone. -- MZMcBride ( talk) 21:36, 6 March 2015 (UTC)

Horribly wrong? You imposed a drastic change bypassing any discussion, which is not well received. What did you expect? -- [[ User:Edokter]] {{ talk}} 00:01, 7 March 2015 (UTC)

There was discussion in Gerrit, you just don't approve of the venue. While you're trying to personalize this discussion by blaming me specifically, I only proposed this change. I didn't merge this change nor did I deploy this change. And I'll repeat that this change seems to have been well-received on the 800-plus other Wikimedia wikis. A few people on one wiki disagree with the change, as far as I can tell.

I've tried to avoid directly calling you out, but in this entire discussion, I've had the strong feeling that you're mostly upset that you (personally) weren't consulted about this change. And that seems a bit petty to me. Your local override seems to suggest the same mentality. Could you really not find any other local administrator to agree with you? You really felt it necessary to revert this padding change yourself when you'd already been involved in the discussion and clearly have a conflict? Your behavior here has every taste of "I wasn't consulted!" and "I disagree with changes where I wasn't consulted!" even when the change is beneficial. -- MZMcBride ( talk) 15:40, 7 March 2015 (UTC)

I'm not blaming you personally... I'm trying to expose the absense of process with this change. You however seem to take this personally. I am addressing you because you stepped up defending the change, and systematically dismiss all complaints and arguments as non-existing. And it is irrelevant that I was not consusted... no one was consulted! I simply responded to complaints (which I happen to agree with). I don't know what you define as "well received"; please post examples of that. In the mean time, I will just open a tast to discuss the actual chhange. -- [[ User:Edokter]] {{ talk}} 17:52, 7 March 2015 (UTC)

When you look at the bullet points in for instance this AFD Wikipedia:Articles for deletion/New Downs - Are they extremely tiny ?,
As you can see from the picture they're absolutely tiny for me so I'm not sure if something here's changed or it's something to do with my laptop/chrome settings?,
Thanks, – Davey2010 ^Talk 03:33, 27 February 2015 (UTC)

They appear at the normal size for me. — Mr. Stradivarius ^{♪ talk ♪} 03:35, 27 February 2015 (UTC)

There is some discussion of this at the top of #Tables just changed (using monobook). –  Philosopher  ^{Let us reason together.} 03:40, 27 February 2015 (UTC)

Thanks Mr. Stradivarius,

Philosopher - It actually appears to be a Chrome issue I think ?, I tried IE and they're normal but when I try Chrome logged out it still seems tiny, The font settings are all normal, I'll wipe everything and see if that does the trick, – Davey2010 ^Talk 03:46, 27 February 2015 (UTC)

Forgot to say I'm using Vector, Anyway nope all still the same, Well it looks like I partially have the Monobook issue...Just in Vector , Ah well thanks anyway ) – Davey2010 ^Talk 04:44, 27 February 2015 (UTC)

It's a Webkit issue; Chrome fixed this last year (in Blink), so that should not be a problem (unless you have a really old Chrome version). -- [[ User:Edokter]] {{ talk}} 09:43, 27 February 2015 (UTC)

Hi Edokter - Nope I'm using the latest version as far as I know (34.0.1847.116), Thanks, – Davey2010 ^Talk 17:35, 27 February 2015 (UTC)

Davey2010, that is old! The latest version is 40. -- [[ User:Edokter]] {{ talk}} 17:47, 27 February 2015 (UTC)

Yes, as I noted at #New CSS in Firefox above, Chrome 40.0.2214.115m is current version. -- Redrose64 ( talk) 17:51, 27 February 2015 (UTC)

Edokter Eh seriously?, I've been updating chrome the moment the 3 bars go green so how on earth could I have gone from using updated versions to old ?.....Unless without me knowing Chrome hasen't been updating at all for quite some time?, I really don't no!, Anyway thanks for solving the mystery ) – Davey2010 ^Talk 18:13, 27 February 2015 (UTC)

By the looks of it my browser hasen't updated itself since April 2014 ..... Great!, Anyway thanks all for your help :) – Davey2010 ^Talk 18:24, 27 February 2015 (UTC)

I've got the same problem with Safari 8.0.3 (latest version) on OS X 10.10.2 (see screenshot on the right). The bullet points have about the same size and position as full stops. SelfishSeahorse ( talk) 13:40, 1 March 2015 (UTC)

Same problem on Chrome for Android 40.0.2214.109 running Android 5.0 on my Galaxy S5(SM-G900V). Really annoying becuase they look like messed up periods. EoRdE6^{( Come Talk to Me!)} 19:25, 6 March 2015 (UTC)

{{ ping}} is very close to {{ pong}}—since I and O are very close on the QWERTY keyboard it's a common typo that I'll readily admit to making.

Proposal: a vanity template to take advantage of this fact in a humorous manner.

For example, @ Resident Mario:, or @ Mr. Stradivarius: (versus @ Resident Mario: or @ Mr. Stradivarius:) Res Mar 21:01, 6 March 2015 (UTC)

Apologies to Stradivarius in advance for using him as a guinea pig! Res Mar 21:02, 6 March 2015 (UTC)

Pong (disambiguation) says: "Pong, in computer networking jargon, a response to a ping". It may be confusing if you use pong as a synonym for ping instead of a response, but I suppose you could make documentation which suggests use when you alert a user who pinged you. See also Ping-pong scheme. <pedant alert>I could have used it to "pong" you but you didn't release the image as public domain so attribution is required and your template doesn't link to the file page.</pedant alert> PrimeHunter ( talk) 21:32, 6 March 2015 (UTC)

@ PrimeHunter: Ah, sorry, File:Pong ball in flight.svg is the one, I've pubbed it now. It wouldn't be too hard to reverse the image (and host it from the other side of the template if need be). Res Mar 23:42, 6 March 2015 (UTC)

I removed my template from this discussion to free up my sandbox, sorry, heh. Res Mar 04:46, 10 March 2015 (UTC)

(See WP:Village pump (technical)/Archive 126#Link to a section in a Wikipedia article)

When section titles are not-unique, the TOC still works fine, the 2nd section has _2 appended to its #anchor link; the 3rd, _3, and so on.

But the system fails in two other situations I know about.

When you edit a section, WP pre-fills the edit summary with /* ≶section title> */, which is turned into a → linking to the section. This works fine provided the section names are unique. But WP isn't smart enough, so the summary of an edit in the 2nd or following identically-named section will include a misleading → link to the first section by the same name.

Also, after completing a section edit, WP automatically scrolls to the beginning of the section being edited. This, too, fails when section names are not unique. If you edit the 2nd section, you'll get scrolled back to the beginning of the first section.

For example, the article Properties of metals, metalloids and nonmetals, the first and third section have parallel sub-section names

• §§  Shared properties, Metals, Metalloids, and Nonmetals
• §§  Anomalous properties, Metals 2, Metalloids 2, and Nonmetals 2

When I made this dummy edit to 2nd Metals section, WP pre-filled the edit summary with /* Metals */, which got changed to →, pointing to the first Metals section, and when I saved the edit, my browser scrolled to the 1st (not 2nd) Metals section.

Has this made it into the buglist? YBG ( talk) 07:03, 9 March 2015 (UTC)

Yep, back in 2004. These issues are T4831 and T2111, respectively. Matma Rex talk 08:37, 9 March 2015 (UTC)

See https://tools.wmflabs.org/xtools-ec/?user=Anthonyhcole&project=en.wikipedia.org

It is linked at the bottom of every user "contributions page". -- Anthonyhcole ( talk · contribs · email) 13:29, 9 March 2015 (UTC)

• Anthonyhcole, Xtools seems to be running, but apparently there is some db lag or some other db issue (that's why it's reporting as all 0s, no data coming back from the db). Not much xtools can do about labs issues, sorry. — {{U| Technical 13}} ( e • t • c) 14:34, 9 March 2015 (UTC)

15:19, 9 March 2015 (UTC)

The website hasn't updated since the 5th. Previously, pageviews for a day would be available the following day. But there hasn't been updates in five days.

Also, should it be time to create a parallel tool on Wikimedia Labs, if only as a backup? Narutolovehinata5 ^{t c csd new} 23:11, 9 March 2015 (UTC)

There is already another tool at https://tools.wmflabs.org/#toollist-wikiviewstats but it has been completely down for a long time, at least each time I checked. I don't know whether there is work or plans for it. PrimeHunter ( talk) 01:11, 10 March 2015 (UTC)

Hi, could somebody give me the coding in my preferences to suppress Template:Infobox person in an article and to replace a photo if in the infobox with a formatted photo in place set at 250px with the caption given in the infobox?♦ Dr. Blofeld 14:27, 2 March 2015 (UTC)

@ Dr. Blofeld: I know how to suppress the display of the whole of {{ infobox person}} - it's

table.infobox.biography { display: none; }

in Special:MyPage/common.css - but I don't know how to do put the image back in replacement. I suspect that Javascript is necessary. -- Redrose64 ( talk) 13:37, 7 March 2015 (UTC)

Hi Dr. Blofeld. Can you please provide some specific examples of articles using {{ Infobox person}} and the specific images that you're trying to suppress? Can you please also provide some examples of articles using this infobox (or a different infobox) and examples of images you're trying to not suppress?

You probably need a small JavaScript script to do this. Having a list of test cases would be very helpful in developing such a script.

Finally, can you please provide a link to the image ("formatted photo") you would like to replace the natural infobox image with? -- MZMcBride ( talk) 15:52, 7 March 2015 (UTC)

Hi, much appreciate the response both. Basically instead of the infobox to have it as it was before with the image, although 250px at standard [39]. Infobox architect feeds into infobox person at the moment but not sure if it would work for infobox architect. Basically on any arts biographical article which has a redundant (in my opinion) infobox like that I'd like to be able to suppress it and have clean photograph in place of it. Angelina Jolie, for instance instead of that infobox with the trivia on family to just display her image at 250px with the caption in the infobox. If something can feed off the image parameter of the infobox and just put the image there, can that be done? Something like if image (in infobox person or architect, display [File:xxx.jpg|thumb|250px|Caption=]]... ♦ Dr. Blofeld 17:31, 7 March 2015 (UTC)

It could probably be done without javascript if some css classes were added to Template:Infobox person, with something along the lines of

table.infobox.biography tr { display: none; } table.infobox.biography tr.main-image, table.infobox.biography tr.main-image-caption { display: table-row; }

. — Cryptic 01:57, 8 March 2015 (UTC)

Something like this seems to sort of work with Brad Pitt and Angelina Jolie:

$('.infobox tr').each(function() { $(this).children(":not([colspan='2'])").parent().css('display', 'none') });

For more complex cases such as Barack Obama, this approach wouldn't work as well. It's also not clear how/when you'd trigger this suppression. -- MZMcBride ( talk) 06:19, 8 March 2015 (UTC)

infobox.person { display: none; } didn't work for me. I think it's time that the foundation and developers like Jorm (WMF) acknowledged that disputes over infoboxes are very common on here and to make wikipedia more flexible by suppressing them in biographies. Perhaps the intention is to centralize them in wiki data. If they do so, then there should be the option from user to user whether to suppress certain ones or not. Looks like I'll just have to ignore them for the time being. Thanks anyway.♦ Dr. Blofeld 11:39, 8 March 2015 (UTC)

Such disputes occur in discussion of a very, very tiny percentage of articles, and do not involve many editors at all. Most editors, and most readers, seem to welcome the inclusion of infoboxes. The Foundation would be foolish to squander time and effort on such an esoteric request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:35, 8 March 2015 (UTC)

I don't know who you're trying to kid Andy but virtually every featured article I've been involved with in the last 2 years has had an infobox either imposed or attempted to be imposed on them. I respect that the people advocating them like to see consistency across articles and make infoboxes uniform, but you don't see it from the other perspective Andy and have a habit of gunning down anybody who doesn't agree with you with arrogant IDONTLIKEIT arguments. There is certainly a significant number of experienced editors here who loathe them in biographies. This is a very real issue, the disputes on talk pages often go on for weeks. KJP1 in fact stated recently that he was appalled with the time wasting and passion gone into the infobox dispute when it could be used to write articles. He's right. It should never get to that. There should be the option there to customise pages for each editor, rather than assuming everybody must have an infobox and likes them. And by that I don't just mean infoboxes, I mean options like a whole page option when reading to suppress the sidebar, a much wider range of tools to give readers the desired look they want. Everybody is different.♦ Dr. Blofeld 10:40, 9 March 2015 (UTC)

I'm not trying to kid anyone so please don't impugn my motives. The set of "virtually every featured article [you've] been involved with in the last 2 years" is far from being the set of all our articles, or even from being representative of it. Likewise, you and the other the editors to which you refer are not representative of all of our editors, let alone representative of all of our readers. My arguments are not (unlike the "loathing" of others) IDONTLIKEIT; I have explained the reasons why infoboxes are beneficial, at length and with supporting evidence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 11 March 2015 (UTC)

Nevertheless, Dr. Blofeld, you could try pasting this:

table.infobox.biography tr {display:none;}
table.infobox.biography tr:first-of-type + tr {display:table-row;}

into your common.css - find it at User:Dr. Blofeld/common.css

I don't guarantee that it must work on every biography - and it won't work on old browsers, but it might make wiki-life just a bit more tolerable for you. I really hope it helps. -- RexxS ( talk) 22:41, 8 March 2015 (UTC)

RexxS Thanks for that! It seems to work! Is there any way of ridding of the box outline around the photos though?♦ Dr. Blofeld 10:53, 9 March 2015 (UTC)

Yes, just add a new line:

table.infobox.biography {border:none;}

underneath the other lines in User:Dr. Blofeld/common.css. It won't be perfect, but it's close to what you ask for. If you find you would like a faint border then use table.infobox.biography {border:1px solid #EEE;} instead. -- RexxS ( talk) 20:31, 9 March 2015 (UTC)

@ Dr. Blofeld: Assuming that in your post of 11:39, 8 March 2015 you mean this version - no, it wouldn't have worked for you (or for anybody else), because infobox.person is not a valid selector: there is no such HTML element as <infobox>...</infobox>, and even if there were, "person" is not a class that is used on Wikipedia biography pages. If you look at the CSS blobs above, there is always a dot before the word "infobox" and this dot tells your browser that "infobox" is a class, not an element. Punctuation is critical in CSS, not optional. In my first example, I used the selector table.infobox.biography which means 'a HTML <table>...</table> element which has the class "infobox" and also the class "biography"'. -- Redrose64 ( talk) 23:44, 8 March 2015 (UTC)

Am I the only one seeing two snakes with the message "link to this section" at the head of discussion sections? GoodDay ( talk) 00:46, 5 March 2015 (UTC)

It's a section sign added recently. You can remove it with this in your CSS:

.mw-headline-anchor {display: none;}

PrimeHunter ( talk) 00:59, 5 March 2015 (UTC)

I don't understand. GoodDay ( talk) 01:02, 5 March 2015 (UTC)

@ GoodDay: There's a help page at Help:User style. In short, create the page User:GoodDay/common.css and add the code that PrimeHunter gave you to it. Then the snakes will disappear. — Mr. Stradivarius ^{♪ talk ♪} 01:11, 5 March 2015 (UTC)

I tested it with show preview & was warned the code would compromise my account. GoodDay ( talk) 01:12, 5 March 2015 (UTC)

• Code that you don't know or trust can do that. The warning is that it could compromise your account, if it were malicious code. —  Crisco 1492 ( talk) 01:14, 5 March 2015 (UTC)

I think I'll put up with the double snakes. I'm not fussy about venturing into unknown territory. GoodDay ( talk) 01:16, 5 March 2015 (UTC)

It's a good idea to be careful of things that you add to your personal JS and CSS pages, but in this case the code is safe, so don't let that deter you this time. — Mr. Stradivarius ^{♪ talk ♪} 01:29, 5 March 2015 (UTC)

Perhaps those who implimented the section sign, will eventually chose to remove it. Doing so myself, is too risky for me :) GoodDay ( talk) 01:47, 5 March 2015 (UTC)

The code is perfectly harmless and nearly the same is at WP:CSSHIDE. Your JS and CSS pages always show a standard warning, even when you preview a blank page. Administrators like Mr. Stradivarius and I can actually post code in MediaWiki:Common.js and MediaWiki:Common.css which is automatically run by all people who view an English Wikipedia page, or at least those with JavaScript and CSS in their browsers. Administrators can also edit your personal JS and CSS files, but will almost never do so unless you request it, or possibly if you made a user script shared by others but don't maintain it. PrimeHunter ( talk) 01:59, 5 March 2015 (UTC)

We really must do something about that "Code that you insert on this page" message, it causes too much worry, and it comes up every few months. See 27 February 2009; 13 July 2010; 26 May 2011; 15 October 2011; 27 November 2011; 9 December 2011; 1 November 2012; 2 June 2013; 8 July 2013; 2 January 2014; 3 April 2014; 8 April 2014; 20 June 2014; 13 September 2014; and 19 October 2014. It's held in MediaWiki:Jswarning, and is displayed on user CSS pages via MediaWiki:Usercsspreview. The last discussion on this matter at MediaWiki talk:Jswarning was over three years ago. -- Redrose64 ( talk) 13:45, 5 March 2015 (UTC)

I love the snake description! but § is a section sign (used throughout law to indicate a statutory section). Anyway, anyone know of any discussion anywhere not of how we remove it through personal CSS or opting out, etc., but why it was a good idea to make this change everywhere in the first place, and whether it should be removed as a global change?-- Fuhghettaboutit ( talk) 01:42, 5 March 2015 (UTC)

And out of curiosity, what is the purpose of this? If it's to provide an easy way to copy a link to a section without going up to the TOC, it would be cool if it went straight to clipboard (yes, I'm aware that some browser implementations are paranoid about this). Regards, Orange Suede Sofa ( talk) 02:00, 5 March 2015 (UTC)

A Phabricator: search of "mw-headline-anchor" gave phab:T18691. PrimeHunter ( talk) 02:05, 5 March 2015 (UTC)

@ GoodDay: If it means anything, I just added the above code to my CSS page and it worked a treat, no more snakes! - JuneGloom07 Talk 02:27, 5 March 2015 (UTC)

I won't bother with mine. GoodDay ( talk) 02:29, 5 March 2015 (UTC)

Snakes on a Wiki? Lugnuts ^{Dick Laurent is dead} 07:44, 5 March 2015 (UTC)

For what it's worth, the CSS code to disable the links didn't work with my screen reader JAWS in either common.css or monobook.css; code like that usually does what it's meant to, but maybe the fact that it's in a heading confused the screen reader. I had to use JAWS' Flexible Web feature (telling it to hide elements with the CSS class to disable the section links. Graham 87 09:29, 5 March 2015 (UTC)

JAWS? We're gonna need a bigger wiki. Lugnuts ^{Dick Laurent is dead} 09:51, 5 March 2015 (UTC)

To return to the original q, i.e. what's with the snakes, see the phabricator ticket linked from Wikipedia talk:Manual of Style/Accessibility/Archive 13#Imminent MediaWiki feature that will impact accessibility for screen reader users. This ticket was raised in December 2008, but you may not be able to read anything older than about 16 February 2015, for reasons that whilst known, are still unclear to me. -- Redrose64 ( talk) 12:20, 5 March 2015 (UTC)

The Bugzilla url would have been https://bugzilla.wikimedia.org/show_bug.cgi?id=16691. A Google search on that gave http://wikibugs-l.narkive.com/5RSNaeK4/bug-16691-new-section-headings-should-have-some-clickable-anchor-for-passing-links. PrimeHunter ( talk) 13:30, 5 March 2015 (UTC)

Just for the record, Bugzilla is still available in read-only mode at old-bugzilla.wikimedia.org. For example, https://old-bugzilla.wikimedia.org/show_bug.cgi?id=16691 works. Matma Rex talk 17:29, 5 March 2015 (UTC)

This is a known issue that will hopefully be fixed after next Phabricator update ( T89690). In the meantime https://phabricator.wikimedia.org/T18691?before=1 (note the ?before=1) shows all comments on the task. wctaiwan ( talk) 21:46, 5 March 2015 (UTC)

• Isn't it great that WMF implements things we all hate and or find utterly useless ..... Other than Diffs I never need to use the URL bit here so personally not seeing any point to it but meh that's my 2¢ on it, Anyway thanks PrimeHunter for the code :) – Davey2010 ^Talk 16:33, 6 March 2015 (UTC)

I don't see the point either. This basically saves us the enormous hassle of scrolling up to the table of contents? It doesn't offer nearly enough of a benefit to justify the distraction. -- Bongwarrior ( talk) 18:28, 6 March 2015 (UTC)

Bongwarrior - If you're on the bottom page or an area where the title is in the middle of the page - Clicking the snake thing next to a title makes that title/section go to the top of the screen .... So what's the benefit of that ?.....You may aswell just stick to using the scroll bar ? .... I honestly am not seeing any point to this ? ... – Davey2010 ^Talk 21:36, 6 March 2015 (UTC)

My bad I didnt read everything here - Meh it makes sense but personally I prefer scrolling to TOC, Been used to it for years. – Davey2010 ^Talk 21:45, 6 March 2015 (UTC)

Credit where credit is due: this was implemented by a volunteer developer ( [40]). wctaiwan ( talk) 22:16, 6 March 2015 (UTC)

• Yeah this is incredibly useless feature, yet when people want other things it takes months to get implemented... My question is why no one decided to start even the smallest discussion or notice of the change. Here was me scouring through my gadgets trying to figure our where these bloody snakes were coming from! EoRdE6^{( Come Talk to Me!)} 19:47, 6 March 2015 (UTC)

They did actually mention it at the end of #Tech News: 2015-10 which was posted in a lot of places across Wikimedia sites. You can even sign up to get Tech News delivered to your talk page: meta:Global message delivery/Targets/Tech ambassadors. PrimeHunter ( talk) 22:05, 6 March 2015 (UTC)

This has been a feature request since 2008, so I think it's taken a little longer than "months". Legoktm ( talk) 22:10, 6 March 2015 (UTC)

• I for one think it is a positive change (so long as it doesn't impact usability). Makes it stupidly easy to copy links to article/page sections. *If* it were to be removed globally, is there some CSS or JS code to add it personally? — Huntster ( t @ c) 23:13, 6 March 2015 (UTC)

  I agree. It was pretty annoying to have to scroll all the way up to the top of the page to get the section link URL (and that's assuming there is a TOC). Protip: you can use this with {{ u2w}} to get nicely formatted wikilinks. — Mr. Stradivarius on tour ^{♪ talk ♪} 05:06, 7 March 2015 (UTC)

That's handy. Since some people don't want to see the snake and aren't comfortable editing their CSS, could we add a checkbox somewhere to Preferences?

I find it irritating and distracting but I could see a use for it - if it gave a wikilink and not a URL. When linking to a section, one mostly is doing so in house - well, this one is... I suppose a choice would be too much to ask for, as would requesting that it appeared when one was on the left side of the heading and not way off to the right. Peridon ( talk) 12:30, 7 March 2015 (UTC)

@ Peridon: It happens when you mouseover a heading element of level 2 or deeper. Most browsers treat a heading element as occupying the full width of the page, even if the text of that heading is significantly shorter. In Wikipedia, level 2 headings are given a pale grey border along their bottom edges (as are level 1 headings, i.e. page titles); this demonstrates that the heading is full-width. -- Redrose64 ( talk) 13:26, 7 March 2015 (UTC)

• Okay, so I was unsure about all this as well, and this discussion itself didn't offer me much explanation when I read it. Basically, per MW:Requests for comment/Clickable section anchors and the comments that don't appear to be on that page but instead are on Phab:T18691, the purpose is to change the URL in your URL bar (if you have one) to a link directly to the section you are at or to make it possible to right click and copy the URL for the section you are at without having to scroll back to the top of a long page to click the link in the TOC to make it happen. It is very useful indeed for those on a PC, with JavaScript enabled, and with a URL. Everyone else, it's basically useless. It's not compatible with touch devices, it won't show up for people without .js or with .js disabled, and while they could probably right click on it and copy the link destination, if you don't have a URL bar displayed (my university has them removed from the interface by default for some reason on the lab computers for example) you won't see the result. I also don't like its "Easter Egg" style implementation (despite the fact we are just weeks away from Easter itself). I'm not sure why this option was chosen, it wasn't even the first option and has the most drawbacks in my opinion. I've commented on the Phab ticket, and personally think option 1 was the best option (I've explained why in the ticket as well). I've also suggested that those that like the currently implementation should be allowed to keep it by turning it into an opt-in gadget. — {{U| Technical 13}} ( e • t • c) 13:53, 7 March 2015 (UTC)
  • I haven't decided yet whether I personally care for the new feature, but it does work fine with JS disabled since it's implemented entirely with CSS. It also works on my Android phone in Firefox (on the desktop site, of course) if I touch on the header to activate it, although it does not in Chrome. Anomie ⚔ 14:42, 7 March 2015 (UTC)
  • FWIW I think it's a good feature, because I sometimes forced a __TOC__ manually only to get the fragment (encoded section link) for a link to a section on pages without a ToC. – Be..anyone ( talk) 09:35, 9 March 2015 (UTC)

• For what it's worth - not much at all, I know, because the WMF are bound and determined to render the interface unusable except for those on particular types of bleeding-edge computer set-ups - I find this thing annoying clutter and still don't understand how I'm supposed to use it. It appears, I attempt to click on it, nothing happens. I can and do get the link for a section header by copying and pasting the section header and adding a #. In addition, what the fourpence-a-pound are the black vertical lines that started briefly appearing to the left of each item in my watchlist when I bring up or refresh that page? They made their eyestraining appearance at the same time. Do the WMF want that badly to give us all tension headaches? Yngvadottir ( talk) 16:15, 9 March 2015 (UTC)
  • For what it's worth, this change was driven by volunteers, not by the WMF. — TheDJ ( talk • contribs) 19:27, 9 March 2015 (UTC)

• I don't personally care much one way or the other (although it's one more inexplicable symbol on a page that could well be distracting to readers and its purpose isn't obvious at all), but I am quite concerned about the accessibility issue. I thought MediaWiki was trying to *reduce* accessibility problems, not add to them. Yet up above we have a user with a screen reader identifying that it is a problem, and comments on phabricator indicate that should be a prerequisite to being applied. It was merged too soon (it also has other issues besides mucking up screen readers) and not tested thoroughly enough. I don't actually blame the volunteer developer(s) for this; it's up to the people who are giving +2 and have the access and authority to upload changes to make sure that the issues already raised have been addressed. Risker ( talk) 16:29, 9 March 2015 (UTC)
  • This will be further addressed in the next few weeks. We just need to align a bit on exactly how. As someone who has made considerable efforts towards the accessibility of Wikipedia, and someone who actually saw this fly by (but did not review), I apologize for not mentally flagging it as a potential accessibility problem. It's difficult catching these issues sometimes, it's not something you think about all the time. We only have 2 devs sort of experienced with this topic, one parttime wikidata dev (aka mostly volunteer when working on this) and one volunteer (me). We can't review everything that everyone else does all the time and even if we get invited for a review, sometimes we simply don't have the time. But we do keep an eye out, and do strive to such issues. — TheDJ ( talk • contribs) 19:27, 9 March 2015 (UTC)
    • Thanks very much, TheDJ, for reviewing this. It sort of strains my brain to think that something as important as accessibility doesn't receive in-house support, or that there isn't any expected or required testing standard related to accessibility prior to code implementation. It's a lot of responsibility to leave resting on the shoulders of a couple of respected volunteers. Risker ( talk) 15:46, 10 March 2015 (UTC)

§ on the left

I keep the edit buttons over to the right hand side of the page (in Monobook) which is where I like them to be. Now, when my cursor goes to an edit button, a grey § appears on the left hand side by the heading. Why, and is there some way of getting rid of it? I find it distracting, irritating and unnecessary. Peridon ( talk) 11:48, 7 March 2015 (UTC)

Just found out that it happens anywhere in the Heading line. Peridon ( talk) 11:49, 7 March 2015 (UTC)

See Help:DSL; discussion at #Link to this section snake. --   Gadget850  ^talk 11:59, 7 March 2015 (UTC)

I call it a paragraph sign not a snake... (It's a standard proofing sign meaning 'paragraph break needed'.) Thanks. Peridon ( talk) 12:24, 7 March 2015 (UTC)

You are thinking of pilcrow (¶) perhaps.

— Trappist the monk ( talk) 12:50, 7 March 2015 (UTC)

When and why did the Section sign get added to mainspace articles?

Hi all,
When I mouse-over some but not all mainspace articles, a clickable § pops up in front of the section name.
When and why did this enhancement happen?
Mostly clueless about techernogical things aka -- Shirt58 ( talk) 11:51, 7 March 2015 (UTC)

See Help:DSL; discussion at #Link to this section snake. --   Gadget850  ^talk 12:00, 7 March 2015 (UTC)

D'oh. Note to self: read page before posting. Thanks, Gadget850. -- Shirt58 ( talk) 08:33, 8 March 2015 (UTC)

Symbol to use

The symbol itself can be changed (or removed altogether) at MediaWiki:Section-symbol. Would ¶ be better ?   Cenarium ( talk) 21:06, 9 March 2015 (UTC)

No. The pilcrow is a paragraph sign; the link shown is to a section, not a paragraph. This also matches the behavior of {{ section link}}. --   Gadget850  ^talk 21:47, 9 March 2015 (UTC)

I'm surprised to be told, on its talk page, that Navigation popups is "abandonware". Are there any coders willing to tackle the feature requests for this immensely useful tool? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:36, 5 March 2015 (UTC)

Hmm, isn't that functionality basically superseded by a proper extension called Popups / Hovercards, if I get it right? -- AKlapper (WMF) ( talk) 10:53, 6 March 2015 (UTC)

@ AKlapper (WMF): As an experiment I turned off popups and turned on Hovercards. Now when I look at my watchlist or at recent changes, I see no popup information when I look at a "diff", "hist" or "contribs" link. When I point at an article link, I see a preview but no way to access the history or the diffs of the last edits. So, no, Hovercards is not a replacement for popups. -- John of Reading ( talk) 11:15, 6 March 2015 (UTC)

The new popups is nice, but it only does short previews of content. It doesn't give you actions, diffs or any of the many other previews that navpopups can give you. But the original popups is from 2003... it's a pain to maintain, does everything itself, and does so much, that it's difficult to reimplement in a modern way. — TheDJ ( talk • contribs) 11:22, 6 March 2015 (UTC)

@ AKlapper (WMF): Navigation popups is a tool I use everyday. It does no good to characterize it in a way that suggests its use will not be accommodated. Where should I go to ensure its continued survival? -- Ancheta Wis   (talk | contribs) 11:28, 6 March 2015 (UTC)

@ Ancheta Wis: I'm not sure why you ask me. But thanks everybody for explaining that its functionality is way broader than I had expected from a quick read! -- AKlapper (WMF) ( talk) 11:31, 6 March 2015 (UTC)

Thanks for attempting to reply. -- Ancheta Wis   (talk | contribs) 11:40, 6 March 2015 (UTC)

"Where should I go to ensure its continued survival?" It's like that old dark barn on the side of the scouting grounds. It still works, but it's slowly rotting away and no one want to replace 1/3 of the planks and paint the whole thing with tar front to back... in the mean time, someone's dad dropped off an ugly but fancy new container. It's too white and new, is way smaller, but at least there's no draft. We could still paint the barn if all the scouts would get off their phones and picked up paintbrushes......But it's simply not happening. — TheDJ ( talk • contribs) 20:47, 6 March 2015 (UTC)

For the record, it has the most users at Wikipedia:Database reports/User preferences#Gadgets. Thank you to the coders who so far prevent it from collapsing. At least there will only be whining users outside and not innocent children inside if it does. PrimeHunter ( talk) 21:57, 6 March 2015 (UTC)

40.897 users with Navpopups activated in enwiki alone. Add to those the users in other wikis (i.e. de:MediaWiki_Diskussion:Gadgets-definition/Archiv_2013#old-diff-style.css: 5913? in 2013). -- Atlasowa ( talk) 14:26, 10 March 2015 (UTC)

@ Pigsonthewing: The idea in the future is to have a hovercards setting for editors, see mw:Topic:S9xysb7xlucu4hyz and the screenshot at mw:File:HovercardsSettings V2.png. Hope this helps! EoRdE6^{( Come Talk to Me!)} 19:57, 6 March 2015 (UTC)

Thank you, but no, it doesn't. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 6 March 2015 (UTC)

Hovercards looks very nice, but I don't see much similarity to Navigation popups. Mr Stephen ( talk) 20:13, 6 March 2015 (UTC)

I think it's safe to say that Hovercards was inspired by Navpopups, but it's apples to oranges in functionality and purpose. Hovercards a reading tool that can help keep you from falling down the rabbit hole when you need to keep reading relevant things, Navpopups is an editor tool that provides functionality for cleaning up the website. Keegan ( talk) 22:11, 6 March 2015 (UTC)

If you read the link, again if you missed it, the plan for THE FUTURE is to have hovercards have more editor features. How far in the future is anyones guess but thats the idea. EoRdE6^{( Come Talk to Me!)} 04:15, 7 March 2015 (UTC)

I think it's good we take the time to establish what's the status quo now; i.e. two different things, to attempt to answer the question at hand. The answer to the question at hand is that Navpopups receives life support every year or two or three to keep it running, so it's not quite abandonware. It's not getting bug fixes nor features. Hovercards is new, with recent development; however, the target future features are not on the table right now so it remains a project with different focus. Keegan ( talk) 07:56, 7 March 2015 (UTC)

RefToolbar

We seem to have the same problem with Wikipedia:RefToolbar (see its talk page). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 11 March 2015 (UTC)

See also phab:T71550. Helder 20:39, 11 March 2015 (UTC)

autocomplete script is widely used gadget in Arabic and Hebrew Wikipedias and can help users to quickly fill links, templates and templates parameters in the editbox. I would like to promote autocomplete script to a gadget here too, so English Wikipedia users can take advantage of this useful gadget. Eran ( talk) 06:32, 8 March 2015 (UTC)

Do you have the non-minify'd source available for review? Nakon 06:37, 8 March 2015 (UTC)

he:MediaWiki:Gadget-autocomplete.js [add ?uselang=en if you don't like the Hebrew interface :) ] Eran ( talk) 06:40, 8 March 2015 (UTC)

I've replaced my main JS page but am not able to utilize the script. Would you be able to provide any technical assistance to get this working? Is this script configured to use LTR on this wiki? Thanks, Nakon 06:49, 8 March 2015 (UTC)

• The gadget is configurated to LTR here.
• importScript function is used to import internal scripts, use instead

  mw.loader.load('//bits.wikimedia.org/he.wikipedia.org/load.php?debug=false&lang=he&modules=ext.gadget.autocomplete');
  

Eran ( talk) 06:56, 8 March 2015 (UTC)

This might be because I'm using the legacy monobook. I'll try it with the new template and I'll let you know how it works out. Nakon 07:08, 8 March 2015 (UTC)

i doubt monobook has anything to do with it. just added &useskin=monobook to address line, and the gadget (or rather script) continues to work flawlessly. however, some gadgets may be incompatible with this one. specifically, if you have wikEd activated, you want to turn it off for this gadget to take effect. you can search for users using this gadget (click "advanced" and select "User" namespace) - there are several dozens users on enwiki already using it via WP:JS. peace - קיפודנחש (aka kipod) ( talk) 15:05, 8 March 2015 (UTC)

• Support - I find it very useful, and so would many others. It would be good to make it more discoverable by including it on the gadgets tab in Preferences. Very few people know about WP:JS. Ijon ( talk) 14:40, 9 March 2015 (UTC)
• Support This is brilliant. Like a live search as you type out template and page names with {{ and [[. This will be tremendously helpful and timesaving! — MusikAnimal ^talk 05:13, 11 March 2015 (UTC)

This is very strange: almost every time I try to open any Wikipedia page related to the Assyrians using Google Chrome, I get an error message from the browser and the page won't load. It happens wether or not I'm signed in, but not on other browsers. I'd guess it has something to do with the Assyrian script on the pages. Anyone else had this problem?  Liam987 (talk) 23:46, 8 March 2015 (UTC)

Works for me, in Chrome (current main release). — xaosflux ^Talk 04:52, 9 March 2015 (UTC)

I believe this may be the same as phab:T88478, Chrome bug report at [41]. The tab doesn't crash every time I don't think. — MusikAnimal ^talk 05:25, 11 March 2015 (UTC)

Clicking an image that is opened in the media viewer, then going back with the browser's back button, then clicking it again, and going back again will lose the place of the scroll position in the original page. -- Agamemnus ( talk) 04:14, 10 March 2015 (UTC)

phab:T65892 is closed but maybe phab:T73796 is related? -- AKlapper (WMF) ( talk) 11:25, 10 March 2015 (UTC)

Not sure. It didn't work at all at first (and I noticed this), but they fixed it in phab:T65892 (and I also noticed this). However, they only partially fixed it, since it comes back when you go back and forth as I described. The second ticket you refer to mentions that all that code is hack upon hack, so maybe that is why this stuff keeps breaking in various places... iunno. Guess I should register maybe and post a reply to the first (closed) bug. Does anyone read replies to closed bugs? -- Agamemnus ( talk) 18:40, 10 March 2015 (UTC)

Whoever is in the Subscribers list of a task receives notifications about that task depending on each subscriber's personal notification settings. However if you have found a new bug, a new task might be more effective including a reference to the older existing task. -- AKlapper (WMF) ( talk) 19:19, 11 March 2015 (UTC)

Hi everybody. This week's triage meeting will happen on Wednesday, 11 March 2015 at 12:00 (noon) PST ( 19:00 UTC). We hope to see you there - in case you can't make it, please remember you can still nominate "blocker" tasks in advance on Phabricator, or you can read the IRC logs and minutes which are usually published shortly after the end of the meeting, so you can catch up on what was discussed. So see the meetings page on mediawiki.org for details (notice the new format, a Google Hangout). Thank you, and talk to you soon, -- Elitre (WMF) ( talk) 21:14, 10 March 2015 (UTC)

Hello. Page view statistics don't working from 5 march 2015 in english, polish and spanish Wikipedia (and probably in much more). -- Swd ( talk) 09:18, 11 March 2015 (UTC)

Confirmed. No Page count stats for any page since that date apparently. LawrencePrincipe ( talk) 13:16, 11 March 2015 (UTC)

A link to see the problem would be welcome. -- AKlapper (WMF) ( talk) 19:19, 11 March 2015 (UTC)

See the last 90 days for Mount Hood which is usually examined 300-500 times per day. Notice that there is no information since 2015-03-06, no matter how the data is viewed. — EncMstr ( talk) 19:24, 11 March 2015 (UTC)

Is it possible to add (trough request at Phabricator) protection level for any existing user right groups? For example, at Latvian Wikipedia we would like to add new protection level, so that pages can be edited by autopatrolled users and sysops. Yes, we have autopatrolled user group enabled. -- Edgars2007 ( talk/ contribs) 15:00, 11 March 2015 (UTC)

Hi Edgars2007, are you talking about FlaggedRevisions? And do you mean polish/german WP style or russian WP style? Have a look at meta:Flagged Revisions (and talk page). -- Atlasowa ( talk) 15:54, 11 March 2015 (UTC)

No, i'm talking simply about page protection. autopatrolled users was just an example. Currently we (Latvian Wikipedia) have protection level 1, so that pages can be edited only by registred users and protection level 2, so that pages can be edited only by admins. I'm not asking this @Phabricator, because here I could get some respones faster. -- Edgars2007 ( talk/ contribs) 16:21, 11 March 2015 (UTC)

Yes, it is possible. File a request at Phabricator with #wikimedia-site-requests project. See m:Requesting wiki configuration changes. -- Glaisher ( talk) 16:24, 11 March 2015 (UTC)

Thanks. That's all I wanted to know. -- Edgars2007 ( talk/ contribs) 16:29, 11 March 2015 (UTC)

At the Teahouse (and here as I just discovered) editing isn't working. There isn't any edit buttons. I use a phone and chrome, no app. It is why I had to put this at the top. The only edit button on this page and teahouse is the top one. Also there are no drop down menus. Because of this I can't reply to anyone here if I need too. I also can't fix a typo in this after posting for example. This issue is (my guess) only on mobile and only on pages that has Wikipedia: in the title. This issue needs to be fixed ASAP. If I have to reply I have to do it on your talk page. Normal pages are fine, this issue doesn't happen on normal pages. If I switch to desktop mode, it's the same thing. Help!!! Ping me or since I can't reply here, reply at my talk page to keep the conversation in one spot, it doesn't matter though. -- DangerousJXD ( talk) 10:36, 7 March 2015 (UTC)

@ DangerousJXD: Going to https://en.m.wikipedia.org/wiki/Wikipedia:Teahouse/Questions (mobile version) in Chrome 41 on my desktop computer and switching to "Desktop" at the bottom, I do see an "[edit]" link next to the section heading (the mobile version indeed does not offer this). Hence I cannot reproduce the problem. -- Malyacko ( talk) 15:04, 7 March 2015 (UTC)

@ DangerousJXD: I've fixed it with this edit to Template:TH question page. It looks like the mobile skin has recently stopped being able to collapse sections and display edit links on pages with unbalanced div tags. Removing unclosed divs in the header removed some of the pretty formatting from the page, but at least now you can edit it from your phone. — Mr. Stradivarius ^{♪ talk ♪} 04:02, 12 March 2015 (UTC)

I have submitted a multiple page move request for this number of pages and one of the objections was related to this worry. Comments would be appreciated. Greg Kaye 22:50, 11 March 2015 (UTC)

250 page moves were carried out in the 6 hours prior to this comment, a rate of moves that is more or less typical. An additional few hundred should cause no noticeable problems. - TB ( talk) 23:44, 11 March 2015 (UTC)

WP:PERF, it won't. Legoktm ( talk) 23:57, 11 March 2015 (UTC)

• 184 is a really small number. Even if it was 1840 page moves, I'd have no concerns about any issues being caused by that. I'd have no worries if someone was deleting 2000 revisions of a page (if it was over 5000 revisions, I might worry a little, but there are safeties for that in place). So, TL;DR answer, 184 page moves is nothing. — {{U| Technical 13}} ( e • t • c) 01:46, 12 March 2015 (UTC)

I posted on WT:AFC#Bug with open ref tags regarding a bug that Newyorkadam and I stumbled upon which I presume is in {{ AFC submission}}. Would any of you technically minded editors have a look at it? Thanks, -- Sam Sailor ^Talk! 11:08, 12 March 2015 (UTC)

It's not a bug in {{ AFC submission}}. It's merely that if there is an unterminated ref the rest of the content of the page is regarded as being part of the ref (but an error message is given to highlight the problem). Hence the {{subst:submit}} was never parsed. I've completed the correction which Newyorkadam started but which you had reversed. -- David Biddulph ( talk) 11:29, 12 March 2015 (UTC)

The real bug is the often reported phab:T4700, here meaning that {{subst:}} does not work in ref tags. PrimeHunter ( talk) 13:16, 12 March 2015 (UTC)

I have recently received notifications that edits I made were reverted, even though they weren't reverted at all. They were simply edits ( [42] [43]) that followed mine. T v x1 18:10, 12 March 2015 (UTC)

In each case the edit reverted at least part of your change. Even the first line of the change is a reversion of your change. - David Biddulph ( talk) 18:20, 12 March 2015 (UTC)

The notification is caused by clicking "undo" or "rollback" (only some have the latter feature), and eventually saving the edit. The users probably clicked "undo", removed the prefilled edit summary, and manually made some changes in the edit box before saving. PrimeHunter ( talk) 22:05, 12 March 2015 (UTC)

Also possible is that they were on the page history, and used "undo" after they either (i) clicked a "cur" link for any revision other than the second from top or (ii) selected two non-consecutive revisions and used Compare selected revisions. When you do either of these, you are undoing more than one revision, which might have been made by more than one different person; and so neither a single edit number nor a single user name are suitable, so the default edit summary is blank. -- Redrose64 ( talk) 22:45, 12 March 2015 (UTC)

Just for documentation, I got this several times about an hour ago. I meant to copy the details and forgot to do it before it finally went to the right page.— Vchimpanzee • talk • contributions • 19:02, 12 March 2015 (UTC)

The whole site was down for that period. There was no root cause posted to the Server Admin Log, but from inspection it likely was related to a DoS or error with the mobile cache servers. In any case, seems to have been resolved quickly. Mamyles ( talk) 19:46, 12 March 2015 (UTC)

Curious. Around that time I noticed what may have been unusually heavy DNS traffic on an entirely separate system. I wonder if there were any global problems. ~ J. Johnson (JJ) ( talk) 20:18, 12 March 2015 (UTC)

Statistics

I'd like to change a hatnote at ISIL from :

to:

When I try this I get the message (in red) saying:

Lua error: invalid expiry date ("22 March "ISIL" and "ISIS" redirect here. For other uses, see ISIL (disambiguation) and ISIS (disambiguation).2015").

Can we get round this or track this down pls?

Thanks Greg Kaye 02:37, 14 March 2015 (UTC)

Your code works for me in preview. The error message sounds like hatnote code is mixed up with the following {{pp-vandalism|expiry=22 March 2015|small=yes}}. Try again. If it still fails then post code producing the actual error message here, or save it in the article so you can post a diff before reverting to a working version. PrimeHunter ( talk) 09:05, 14 March 2015 (UTC)

Thank you PrimeHunter, I'm learning. Greg Kaye 14:12, 14 March 2015 (UTC)

Could someone explain why in the here shown infobox the 2nd session, omitting the "sessionend" parameter shows a single date in the box, while at the 4th session the "sessionend" parameter is required. If omitted it shows a sort of fault message. How can it made to show a single date? Kraxler ( talk) 15:17, 14 March 2015 (UTC)

185th New York State Legislature
← 184th 186th →
New York State Capitol (2009)
Overview
Legislative body	New York State Legislature
Jurisdiction	New York, United States
Term	January 1, 1983 – December 31, 1984
Senate
Members	61
President	Lt. Gov. Alfred DelBello (D)
Temporary President	Warren M. Anderson (R)
Party control	Republican (35–26)
Assembly
Members	150
Speaker	Stanley Fink (D)
Party control	Democratic
Sessions
1st January 5 – June 28, 1983 2nd September 15, 1983 – 3rd January 4 – July 1, 1984 4th December 6, 1984 –

Because the {{ Infobox New York Legislature}} has this:

{{#if:{{{sessionend2|}}}| – {{{sessionend2}}}}}

if |sessionend2= is empty or omitted, then don't render anything for that parameter. None of the other parameters are coded this way making |sessionendx= required parameters.

— Trappist the monk ( talk) 15:30, 14 March 2015 (UTC)

Yeah that was kind of lame so I took the liberty of making it possible for any or all of the 8 sessions be just 1 day long. Of course now the issue becomes the ability to "skip" over session-ends without getting a bang, but I prefer to trust in the contributor's diligence over the merely theoretical "trouble maker". -- George Orwell III ( talk) 15:49, 14 March 2015 (UTC)

Thank you very much for the explanation and the fix. Kraxler ( talk) 16:07, 14 March 2015 (UTC)

Is there a way to wildcard watchlist an entire project space, on or off wiki? This is with reference to the Signpost: we have to maintain an at this point vast collection of pages, many of them archival issues which should not be touched. It'd be helpful if we had a mechanism for doing so. Res Mar 16:15, 14 March 2015 (UTC)

@ Resident Mario: If all of the pages that you are interested in are in a single category, you can use the category expand feature of Special:Export: put the category name in the small "Add pages from category" box and click Add. The larger box will fill with page names. Click anywhere in that box, and then (Windows browsers) press Ctrl+A to select all, then Ctrl+C to copy. Then go to Special:EditWatchlist/raw, open up an empty line, and use Ctrl+V to paste, then click Update watchlist. If all of the pages that you are interested in are spread over several categories, you can do this for each individual category. -- Redrose64 ( talk) 22:18, 14 March 2015 (UTC)

  Redrose64: Tut. I've discovered the numerical limit of the watchlist—it'll only take me as far as March 2011. Res Mar 22:42, 14 March 2015 (UTC)

@ Resident Mario: You might be able to use Special:RecentChangesLinked – it is like a watchlist, but for pages in a specified category, or linked from a specified page, or linked to a specific page - Evad37 [ talk 23:17, 14 March 2015 (UTC)

  Evad37: The point appears to be moot—some change in 2012 appears to have stopped the archival process and so Signpost articles newer than 2011 are uncategorized. Res Mar 23:22, 14 March 2015 (UTC)

I was doing some cleanup and found that the {{ ruby}} template does not pass the W3C HTML validation. I get the error "Element rb not allowed as child of element ruby in this context." I have been poking at this and I just don't see the problem. Examples from the W3C site do not validate. I used the W3C validator and https://validator.nu/ which allows text entry: both give the same results. Here is the sample I used for testing:

<ruby>
<rb>紙芝居</rb>
<rp>(</rp>
<rt>かみしばい</rt>
<rp>)</rp>
</ruby>

I am starting to think the validator is at fault here, but I don't see any issues on their bug list. Thoughts? --   Gadget850  ^talk 02:03, 15 March 2015 (UTC)

• The issue is with rb; not rp. <rb> is not part of the WHATWG living standard. See this bug. Alakzi ( talk) 02:25, 15 March 2015 (UTC)
  • Fixed discussion title. More reading... --   Gadget850  ^talk 02:27, 15 March 2015 (UTC)
    • The version with <rb> doesn't validate, but this does: <ruby>紙芝居<rt>かみしばい</rt></ruby>. Note: I haven't read the documentation, this is after the example of the output at wikt:講#Kanji. Another issue is that in Firefox 36 the rubies at Wiktionary display as small characters after the kanji. They display correctly as small characters above the kanji in Chrome. –  Margin1522 ( talk) 04:08, 15 March 2015 (UTC)
      • Display is a different issue, and is browser related. The HTML Ruby add-on for Firefox displays just fine. --   Gadget850  ^talk 08:38, 15 March 2015 (UTC)
      • so the question is what to use? I'd say we put the rb out as the WHATWG seems not to like it and the W3C says that it can be implied abd in the use case the ruby tpl is right now an implied use wouldnt make a problem.

M y 1 06:49, 15 March 2015 (UTC)

• HTML: The Living Standard: has <rb> listed under obsolete; "Providing the ruby base directly inside the ruby element is sufficient; the rb element is unnecessary. Omit it altogether."
• W3C: Use Cases & Exploratory Approaches for Ruby Markup: "The HTML5 CR approach does not have an rb element." The next section then states "The span element can be used in place of the rb tag."
• See also T69042. --   Gadget850  ^talk 09:01, 15 March 2015 (UTC)
  • Looks like <rb> should be considered obsolete, but the documentation is conflicting. Thoughts? --   Gadget850  ^talk 12:41, 15 March 2015 (UTC)

I'm trying to copy article links from my address line into a doc or pdf file, and consistently have errors only when the article title ends in a closing parenthesis:

• /info/en/?search=The_Last_Supper_(Leonardo_da_Vinci) goes only to /info/en/?search=Last_Supper

• /info/en/?search=Pension_(lodging) goes only to /info/en/?search=Pension

• /info/en/?search=Bucket_shop_(stock_market) goes only to /info/en/?search=Bucket_shop

Is this a known issue, and is there any way to create a working link in my file that goes to the correct article? I did notice somewhere that parentheses seem to be rendered as .28 and .29 (if I'm now remembering the numbers correctly), but substituting these by hand didn't work at all.

Thanks for any help. Milkunderwood ( talk) 03:47, 15 March 2015 (UTC)

Here's the place I had found: /info/en/?search=Weimar_Republic#Years_of_crisis_.281919.E2.80.931923.29, which goes to Years of crisis (1919–1923). Milkunderwood ( talk) 04:06, 15 March 2015 (UTC)

For that matter, it doesn't seem to make a lot of sense that the parentheses at the end of a subsection title would encode properly, but not at the end of an article title.

FWIW I'm using Chrome 41 with Office 2013 on a 7 machine; but my files containing links will be for distribution to people with whatever setup they may have, so what I need is a general all-purpose solution. Milkunderwood ( talk) 06:00, 15 March 2015 (UTC)

I'm feeling kind of stymied - maybe an experiment could help if someone wouldn't mind doing it. Just open any kind of blank document form, go to any article with the title ending in parentheses such as the three I listed here, copy your address line into your document, and see if it works, or truncates the title to remove the parenthetical part. I'd love to know if anyone can get to the correct article. Milkunderwood ( talk) 09:02, 15 March 2015 (UTC)

Using Firefox 36.0.1 if I copy the addresss line and paste into Word 2007 I see /info/en/?search=The_Last_Supper_%28Leonardo_da_Vinci%29 and if ctrl-click that I get to the correct document with parentheses in the address bar. Generally, I don't remember problems with this sort of thing. Thincat ( talk) 09:50, 15 March 2015 (UTC)

And with Chrome 41.0.2272.89 m copy/paste gives me /info/en/?search=The_Last_Supper_(Leonardo_da_Vinci) which I have to convert to a link in Word (from Firefox the text pasted in autolinked). Ctrl-click works OK with the address bar showing brackets. All with Windows 7. Thincat ( talk) 09:58, 15 March 2015 (UTC)

It's a common issue in external software like email programs and apparently Word that some characters need percent-encoding to be interpreted as part of a url. The typical problems are '(', ')', and url's ending with '.'. They encode as %28, %29 and %2E. PrimeHunter ( talk) 10:39, 15 March 2015 (UTC)

Thanks very much for these suggestions. Manually substituting %28 for "(" and %29 for ")" works for me. I was thrown off by the full stops used in the "Years of crisis (1919-1923)" in place of the percent sign. Milkunderwood ( talk) 18:24, 15 March 2015 (UTC)

Full stops are used in anchors (the part after '#' to go to a specific place on a page). PrimeHunter ( talk) 21:29, 15 March 2015 (UTC)

A long discussion at Wikipedia talk:WikiProject Religion#Disambiguations of divinities has always unanimously opposed the disambiguation opposed disambiguation shown at pages such as Mars (mythology) on NPOV grounds in comparison to the religions of the living and the religions of the dead.

This page has no "more" menu so as to offer a move function and the tags (if that is the correct term): {{distinguish2|the planet [[Mars]]}} {{pp-move-indef}} {{Use mdy dates|date=May 2012}}

I understand that the reason for protection is to avoid confusion with Mars (planet) but the proposal it to move to Mars (deity).

I have tried a temporary removal of the tags but this did not work.

Thanks Greg Kaye 07:17, 15 March 2015 (UTC)

The page is move-protected, meaning only administrators can move it (the tags are only used to indicate the protection.) If there is consensus to move, you can ask for it on Wikipedia:Requested moves. -- [[ User:Edokter]] {{ talk}} 08:07, 15 March 2015 (UTC)

Thank you Edokter for the help. There are likely just a handful of such protected articles also such as Gaia so I'll collect a list and make the request. Greg Kaye 13:26, 15 March 2015 (UTC)

Hello all, we at the Signpost are currently underway introducing technical archival architecture at the Signpost, and we're in need of talented people to develop the damn thing =). There are essentially two different things we're trying to do:

• Story-tagging: Mr. Stradivarius has written and is still working on a module that tags stories in the Signpost archives according to a manually-generated list which I've put together on top of an automatic "greatest-hits" one. So for instance, if you hit {{#invoke:Signpost|tag|wikisym}} you will get:

{{#invoke:Signpost|tag|wikisym}}

We want to extend this system to every Signpost article to date, a massive task that'll require combing through more than a decade's worth of published material by volunteers. For the moment, however, I have presented what I hope will serve as the lynchpin of this effort, a proposed research hub of sorts, at User:Resident Mario/sandbox. The next steps are outlined in the To-do. Even populating this list is going to be a challenge and so we need a userscript that'll help us maintain the hub—adding things, deleting them, changing information, etc.

• Historical linking: I've created a proof of concept in one of my other sandboxes but have not acted much further than that so far because at this point. This is a simple idea—an option to give readers links to articles as they appeared at publication time—that I think would be valuable to people going through old stories trying to get a picture of the "way things were". Introducing this into articles will require the work of a bot working together with the templates that the Signpost has used over time to integrate this feature into all of our articles.

Please help us! :) Res Mar 17:12, 15 March 2015 (UTC)

I can have a go at writing the user script that updates the Lua module pages with new tags, etc. - it will be good practice for my JavaScript. — Mr. Stradivarius ^{♪ talk ♪} 23:37, 15 March 2015 (UTC)

I have a couple of issues with fonts on my mobile device (Motorola Moto X, Android 4.4).

First is that, in most browsers (specifically Chrome, Naked Browser, and both Operas), [x] ( voiceless velar fricative, U+0078 LATIN SMALL LETTER X) and [χ] ( voiceless uvular fricative, U+03C7 GREEK SMALL LETTER CHI) have identical glyph shapes. They're distinguishable in Firefox, which uses a different font. For displaying Greek, the glyph without descenders is fine (presumably; I don't know Greek) but is a problem for IPA, since they make some passages misleading or incomprehensible, as the example here shows.

The second is that letters with polytonic Greek diacritics just aren't displayed at all - again, except in Firefox. See for example Perispomenon. Much of that article's content is obliterated by the bad font.

None of this goes away by switching to the desktop site.

Is this fixable? Bear in mind that user CSS isn't an option since the mobile style sheet ignores it - and in any case I'd like this to be fixed for all users, not just me. Also I'm not aware of any way to install extra fonts on Android unless it happens to be a Samsung device. Hairy Dude ( talk) 16:47, 13 March 2015 (UTC)

Please file bugreuports with Google Android — TheDJ ( talk • contribs) 10:41, 14 March 2015 (UTC)

Done for the x / chi issue: Android issue 160613. Hairy Dude ( talk) 03:49, 17 March 2015 (UTC)

Hello, I have an idea how to edit the template:flaglink/core in order to avoid the disorder in the first column, as you can see. So, what's your opinion?

Maiō T. ( talk) 23:00, 13 March 2015 (UTC)

Personally, I like your version (the sandbox) better. Mamyles ( talk) 23:39, 13 March 2015 (UTC)

I like the sandbox version slightly better when countries are lined up in a column, but not when they are alone. Example from UEFA Euro 2016 qualifying Group E#Slovenia v Switzerland with {{ fb}}:

9 October 2014

20:45
(20:45 UTC+2)

Slovenia	1–0	Switzerland
Novaković 79' ( pen.)	Report

Ljudski vrt, Maribor

Attendance: 8,500

Referee: Wolfgang Stark ( Germany)

With {{ fb/sandbox}}:

9 October 2014

20:45
(20:45 UTC+2)

Slovenia	1–0	Switzerland
Novaković 79' ( pen.)	Report

Ljudski vrt, Maribor

Attendance: 8,500

Referee: Wolfgang Stark ( Germany)

I don't support alignment as default when there is often nothing to align and you just get an unnecessary gap. An optional alignment would be OK. PrimeHunter ( talk) 00:12, 14 March 2015 (UTC)

How about when the flags are centered? -- [[ User:Edokter]] {{ talk}} 09:07, 14 March 2015 (UTC)

I agree with PrimeHunter; that is why I decided to create {{ flaglist}} (which Maio's test for the sports templates is based on) as a separate template instead of changing {{ flag}}. In this case, we could create separate "..list" templates for each of the hundreds of sports templates, or make the alignment optional by means of a parameter:

•   Niger ({{ fb/sandbox|Niger|align=yes}})
•   Australia ({{ fb/sandbox|Australia|align=yes}})
•   Niger ({{ fb/sandbox|Niger|align=no}})
•   Australia ({{ fb/sandbox|Australia|align=no}})

SiBr₄ ( talk) 09:58, 14 March 2015 (UTC)

I agree with PrimeHunter, too. I propose to edit the 'flaglink/core' lines and add the optional alignment ...
| flaglink/core{{yesno|{{{align}}}|no=}}
... in following team-sports templates:
bb, bbw, bd, bk, bku, bkw, bkwu, davis, fb, fbu, fbw, fbwu, fed, fhm, fhw, fl, flw, hb, hbj, hbw, hbwj, ih, ih18, ihj, ihw, ihw18, iih, iihw, ru, ruu, ruw, ru7, ru7w, sb, sbw, vb, vbw, wp, wpw
To Edokter: That's absolutely perfect !!! Now just replace Template:Flaglink/core with its sandbox version.
To SiBr4: There are the hundreds of sports templates, but just these 40 are team sports. I can edit them (except tl:fb – it's protected)
Maiō T. ( talk) 15:32, 14 March 2015 (UTC)

Done. It would be a good default in lists though. -- [[ User:Edokter]] {{ talk}} 15:55, 14 March 2015 (UTC)

I've reverted – with that change it always aligns, without any parameter switch. What should be done is moving the sandbox to a different title, and changing the sports templates ({{ fb}} etc.) to include a switch between that and the current {{ flaglink/core}} (see {{ fb/sandbox}}). SiBr₄ ( talk) 16:01, 14 March 2015 (UTC)

I don't know much about CSS. Would it be possible to add something like <div class="alignedicons">...</div> around content with flag icons in a column, and then put something in a central flag template and MediaWiki:Common.css which causes alignment without having to add a parameter to each template and each call of that template? PrimeHunter ( talk) 17:16, 14 March 2015 (UTC)

That would be possible using something like

.alignedicons .flagicon {display:inline-block;width:30px;}

However, using a CSS stylesheet, the block width cannot vary with the icon size, like it does in the {{ flaglist}} template. So a CSS class would only be useful for icon sizes close to the default size. SiBr₄ ( talk) 17:47, 14 March 2015 (UTC)

@ SiBr4: I've added switch to tl:fb/sandbox. Now it works fine. Please simplify the code. (The new template could have a title: Template:flaglink/align).
Maiō T. ( talk) 19:07, 14 March 2015 (UTC)

The previous version of the sandbox already had a switch; in fact it did exactly the same thing the current version does, but without duplicating the entire code.

I created a new template at Template:Flaglink/aligned, with the contents from {{ Flaglink/core/sandbox}}. SiBr₄ ( talk) 19:18, 14 March 2015 (UTC)

@ SiBr4: Please remove this code ...
{{#ifeq:{{{size}}}|20x16px| }}{{#ifeq:{{{alias}}}|Nepal|  }}
... from Template:Flaglink/core. From now it's unnecessary – see those "alignings" through adding of NBSPs.
Maiō T. ( talk) 20:41, 14 March 2015 (UTC)

It may be better to first change lists to use the align parameter before removing the "pseudo-alignment" from /core ({{ flag/core}} also still includes it). I added the parameter to {{ fb}}; I could run AWB to quickly change all flag templates, but would advise getting some more input before doing any mass changes. SiBr₄ ( talk) 13:03, 15 March 2015 (UTC)

SiBr₄ we have a problem. Aligned icons are 1 px wider than the default ones. (Or, better said, spaces are 1 px wider.)
  France (default)
  Monaco (aligned)
  Belgium (default)
  Niger (aligned)
  England (default)
  England (aligned)
Maiō T. ( talk) 16:16, 15 March 2015 (UTC)

When aligned, the width of the icon with spacing is fixed at 30px by default. Without the align option, the maximum width at default size is 25px (a 23px image with a 1px border on both sides), plus a non-breaking space (the width of which probably varies with the font used by the reader). I don't think that is a problem, since aligned and non-aligned icons wouldn't be used together. If it really is, I can change the aligning box with to be a pixel less. SiBr₄ ( talk) 16:33, 15 March 2015 (UTC)

SiBr₄ –
1) I thought, the NBSP is always 4 px wide. This will never work. You could change 30px to 29, but it will do a mess to other users.
I would like to use aligned and non-aligned icons together, with aligning only for Switzerland and other squarish flags - see 2015 Men's World Ice Hockey Championships#Championship.
2) Back to my contribution from 20:41, 14 March 2015. The first half of the code – {{#ifeq:{{{size}}}|20x16px| }} – is absolutely unnecessary, because flagicons with 16px height don't exist. And the second half – {{#ifeq:{{{alias}}}|Nepal|  }} – is about Nepal and those two strange NBSPs.

•    Switzerland
•   Great Britain
•     Nepal
•   Qatar
•   Monaco

Maiō T. ( talk) 18:50, 15 March 2015 (UTC)

1. The spaces in the following tests use different fonts:
   •  Qatar (serif)
   •  Qatar (sans-serif)
   •  Qatar (monospace)
   The width of a space obviously also changes with the font size. So it is certainly not a fixed number of pixels. I'm not sure what you refer to with "this will never work".

   I'd suggest just using |align=yes for every entry, if only for consistency. The alignment option should only not be used if there is no need for any alignment; it makes no sense to force non-aligned icons to be aligned with aligned ones. The minimum aspect ratio for a flag icon to be the full 23px wide is 23/15≈1.533, so actually most national flags would require the align parameter in a list (including all 2:3 flags, i.e. France, Russia etc.). If there is enough agreement to do so, aligning could be made the default, so that only flag icons outside of lists need to be marked.

2. The 20x16px check not doing anything was my fault; I changed the default size in {{ Country data Switzerland}} and {{ Country data Vatican City}} from 20x16px to 23x16px back in August, and updated {{ flag/core}} but not {{ flaglink/core}}. I still think that the extra spaces for (less-than-)square flags shouldn't be removed before the align parameter is at least added to all templates. SiBr₄ ( talk) 20:40, 15 March 2015 (UTC)

@ SiBr4:
1.a) Almost every flag in template:flaglink uses 29px field (including borders and nbsp), so, let's change those 30px to 29px in Module:Flaglist/size, maybe it will work after all.
1.b) Okay, I can use |align=yes for every entry.
1.c) I don't recommend to do "align=yes" as default; flagicons outside of lists are used more often.
1.d) Now it's necessary to update 40 team-sports templates (see the list above – 15:32, 14 March 2015) but don't we need a permission, or something?
Maiō T. ( talk) 22:48, 15 March 2015 (UTC)

The longest flags in your non-aligned list at the start of this section (France, Belgium, Russia and Portugal) are actually 30 rather than 29 pixels for me. The non-aligned width is inherently different for everyone, so I don't think there is much point in adapting the aligned width to it.

There are more team sports flag templates than those forty; I found about fifty more that use {{ Flaglink/core}} and are categorized in Category:Flag template system, for example {{ bandy}}, {{ rl}} and {{ af}}. You could ask/notify WT:SPORTS about the proposed changes. SiBr₄ ( talk) 21:31, 16 March 2015 (UTC)

Currently the edit summary is limited to roughly 250 characters. Per Help:Edit_summary#Edit_summary_properties_and_features, "If you attempt to type or paste more, only the first 250 characters will be displayed – the rest will be discarded. For example attempting to add 10 new characters (at the end or in between) to a summary already containing 245 characters will result in the first 5 new characters being inserted and the second 5 being disregarded". In practice this means ellipsis instead of whole phrase, for example, "restoring neutral v..." instead of "restoring neutral version", while an edit summary before saving displays all characters properly. Since many contributors may not be aware of that or may simply forget this, I think some kind of prevention is warranted (also because in practice you have to calculate the characters via some application each time you write a relatively detailed edit summary).

One of the solutions is simply prevention of further typing by cursor when the character limit is reached, with possible notification reading something like "You have reached your character limit" (similar to that appearing after an edit was saved). Another way is increasing character limit to allow more detailed rationales, although then signalling character limit may also be appropriate. Brandmeister ^talk 13:02, 14 March 2015 (UTC)

I can only type the 255 allowed characters but in some cases like page moves where an automatic edit summary is added in front, it may cut off what I typed. What is your browser and does it allow you to type more than 255? PrimeHunter ( talk) 13:42, 14 March 2015 (UTC)

I use the latest Firefox. Recently I've reached the character limit during a page move and the edit summary was cut down by ellipsis. I recall having a couple of such cases in the past and saw them in other edit summaries. From what I see the automatic edit summaries are also affected by character limitation, also when undoing and reverting page versions, so currently one has to delete them to make room for his/her own edit summary. Automatic page move summaries seem to be particularly vulnerable, since they are longer, in the form of "User:Foo moved page Foo to Foo2") Brandmeister ^talk 14:29, 14 March 2015 (UTC)

Normal edits appear to have exactly what you are requesting, I can't type more than the edit summary limit in the edit summary box. Page moves may be an issue though it seems. Sam Walton ( talk) 14:41, 14 March 2015 (UTC)

Indeed (I'm also allowed to type 255 by default). However, the problem persists in automatic edit summaries followed by user's own edit summaries, like here, and also during reverts. But unlike reverts, you can't remove automatic page move summary to make room for your own. Note that section headings in the summaries (including /* top */ sections) are also counted, unless removed. Brandmeister ^talk 15:03, 14 March 2015 (UTC)

I can type 200 characters in the page move "Reason" box, independent of the length of the page name. The whole typed summary is preserved in the move log like [44] but elsewhere like page histories [45] the total summary including the automatic part can only be 255 characters and the user part may be cut off. Really long pagenames will also cut off the automatic part when it reaches 255, and display nothing from the user. If an ordinary edit displays something automatic in the edit summary box like a section edit or undo then nothing is cut off. The user can just type less than 255 characters after the automatic part, but gets the full 255 if the automatic part is removed. The problem with some log actions also being registered in page histories with an automatic part may be hard to solve in a friendly way. There is probably a good reason for a 255 total limit in page histories, including whatever some feature may add automatically. PrimeHunter ( talk) 17:00, 14 March 2015 (UTC)

Thanks. I remember seeing the links to move log in page histories a couple of years ago, but now the accessibility isn't the same it used to be. Brandmeister ^talk 17:48, 14 March 2015 (UTC)

The top of page histories say "View logs for this page". It must be clicked to find out whether there actually are any logs. The top of user contributions has "logs". PrimeHunter ( talk) 18:23, 14 March 2015 (UTC)

Original problem will still be valid but might appear less often once phab:T6715 (Allow comments to have 767 instead of 255 bytes) is "fully" fixed and deployed. It is being worked on. -- AKlapper (WMF) ( talk) 07:43, 16 March 2015 (UTC)

See Template:Infobox ship characteristics/testcases. Ship infoboxes are made from a table that contains (usually) three and sometimes more individual templates each of which provide the necessary html table markup. As can be seen at the testcases page, an odd thing happens when a template parameter contains a bulleted list; in this case |Ship armament= though the problem is not restricted to this parameter alone.

I had thought that recent changes in the template might have caused this problem but now I think not. The sandbox version at the testcases page predates the recent changes and exhibits the same problem in the same way.

If I wrap bulleted lists in {{ plainlist}} then the infoboxes render correctly.

Looking at the html source we can see that following the bulleted list the table is terminated and a new table started:

While not visually apparent, the problem exists when the template containing a bulleted list is the only template in the infobox.

Are the bulleted lists being correctly handled by code downstream from the template? If so, what changes do I need to make to the template in order to allow bulleted lists in the various ship infobox templates?

— Trappist the monk ( talk) 13:38, 14 March 2015 (UTC)

Please state the perceived problem and your browser, and don't just say "an odd thing happens". PrimeHunter ( talk) 13:45, 14 March 2015 (UTC)

The infobox should, as infoboxes generally do, float right and not be, as I and others have seen, split into the normal right-floated portion and a left-floated portion. Do you not see that condition at Template:Infobox ship characteristics/testcases? Current versions of Chrome and Opera and even a very old version of MSIE all exhibit the same problem in exactly the same way.

— Trappist the monk ( talk) 14:19, 14 March 2015 (UTC)

I never use these ship templates and didn't know what to expect from them but I see what you mean. I get the impression there is a deeper problem which is not about bulleted lists, but their presence in your example causes a visible effect. It looks like there is a problem with mixing html code and wikitext for tables.

I have tried to construct a simple example.

Pure wiki syntax:
{| class="wikitable"
|-
|Row 1
|}

Pure html:
<table class="wikitable">
<tr><td>Row 1</td></tr>
</table>

Mixed syntax:
{| class="wikitable"
<tr><td>Row 1</td></tr>
|}

Mixed syntax for single row tables:
{| class="wikitable"
|-
<td>Row 1</td>
|}

The above produces:

Pure wiki syntax:

Pure html:

Mixed syntax:

Something is inserting extra code in the mixed case which has a second row with no content. If html tidy or something thinks there is illegal table code then automated attempts to fix it may have very varying effects in different contexts. PrimeHunter ( talk) 16:05, 14 March 2015 (UTC)

Entering {{Infobox ship characteristics/testcases}} at Special:ExpandTemplates does not show the problem at Template:Infobox ship characteristics/testcases, but entering my above example at Special:ExpandTemplates does show the same problem as above. I don't know what that means. Maybe ExpandTemplates doesn't run everything that a saved edit runs, and this has "very varying effects in different contexts" as I vaguely put it above. PrimeHunter ( talk) 16:24, 14 March 2015 (UTC)

Really starting to think wiki mark-up is the root of all evil....

Mixed syntax for single row tables :

See this diff; Why it worked in stopping that extra empty table generation? Haven't a clue (never mind that entire family of templates need to go "all html" or go home:( ) -- George Orwell III ( talk) 17:37, 14 March 2015 (UTC)

• It works if you put the template closing and opening braces on the same line; see Special:Diff/651363165. Alakzi ( talk) 17:59, 14 March 2015 (UTC)

Admittedly, that does make more sense now that I realize the finished product was intentionally suppose to be in series and not parallel box renderings.... but the truth is most of the solutions for the current batch of html table based templates need to go all-div, all-css3 sooner rather than later. I wonder if developers are even considering switching the table mark up at some point in the future to use a Div based scheme that still behaves like the current table/row/cells stuff does now but without all the "drama" that comes with it. -- George Orwell III ( talk) 18:39, 14 March 2015 (UTC)

I agree that these ought to be superseded; modular {{ Infobox}}es would work—comparatively—well. Farther down the line, infoboxes should probably be made to use definition lists. Alakzi ( talk) 18:55, 14 March 2015 (UTC)

It now seems the problem in my earlier example and the ship templates have different causes, or at least are caused by different examples of mixing wikitext and html. I made a small example of the apparent ship problem.

Broken (does not display Row 1 and Row 2 in the same table):
<table border="1">
<tr><td>
*Row 1</td></tr>
<tr><td>Row 2</td></tr>
</table>

Asterisk removed from broken version:
<table border="1">
<tr><td>
Row 1</td></tr>
<tr><td>Row 2</td></tr>
</table>

Newline removed from broken version:
<table border="1">
<tr><td>
*Row 1</td></tr><tr><td>Row 2</td></tr>
</table>

Newline added to broken version:
<table border="1">
<tr><td>
*Row 1</td>
</tr>
<tr><td>Row 2</td></tr>
</table>

Asterisk replaced by html list syntax in broken version:
<table border="1">
<tr><td>
<li>Row 1</li></td></tr>
<tr><td>Row 2</td></tr>
</table>

The above produces:

Broken (does not display Row 1 and Row 2 in the same table):

Asterisk removed from broken version:

Newline removed from broken version:

Newline added to broken version:

Asterisk replaced by html list syntax in broken version:

Each of the four changes fixes the problem. So if a table has an asterisk causing a list and uses </tr> on the same source line to end the row then the following <tr> must also be on that line to become part of the same table. Or something like that. It's messy. All five versions make a single table at Special:ExpandTemplates, but the last displays the bullet to the left of the table for me where it's inside the table above. If I save it in a html file on my PC and view it without MediaWiki then the bullet is inside the table. The first four versions don't make bullets in a html file since the asterisk is not html. PrimeHunter ( talk) 19:49, 14 March 2015 (UTC)

Broken "works" when Row 2 is swapped for Row 1 btw

Bet$ anyone? My money is on sub-par(?) handling of nuanced table elements like TBODY by the 'BOT behind the curtain' ("always there"? in the table accounting; nothing more than just some text <tbody> in our case). Some interesting reading there but.... ???

Seriously, you can drive yourself nuts trying make rhyme or reason out of 'why some things "behave" the way they do' around here. -- George Orwell III ( talk) 23:27, 14 March 2015 (UTC)

Though the parser escapes <tbody>, it is inserted in all tables by the "linter". Something in the linter is what's probably causing this mess. Alakzi ( talk) 23:43, 14 March 2015 (UTC)

I was already driving myself nuts trying to figure out which wiki code breaks it, let alone why. PrimeHunter ( talk) 00:05, 15 March 2015 (UTC)

One of you good folks would know better than I as to what's behind this. Still I'd like to shamelessly cast doubt on $paragraphStack without any basis nor support in spite of my shortcomings.

why BR is ever tapped to -- in effect -- deal with 'one too many detected' opening P tags just doesn't sit well with me. Why not nullify it with a closing P tag if in doubt? or just keep blindly inserting </P><P> pairs if there is any other remaining doubt that content immediately follows that (?)detected opening tag? (its kind of late in the game for curtailing the number of 'run on' sentences accidently rendered on WP if I do say so myself :). Weird. And frustrating not being fluent enough to stop throwing it under the bus just on a whim. -- George Orwell III ( talk) 00:35, 15 March 2015 (UTC)

This is a known issue, see T19486. -- [[ User:Edokter]] {{ talk}} 08:25, 15 March 2015 (UTC)

I think that it would be better to just re-write the {{ infobox ship}} (and related templates) from scratch. These old, odd templates have developed quite a few small problems. WhatamIdoing ( talk) 00:35, 17 March 2015 (UTC)

I've run into two infoboxes that have problems I don't know how to fix and I'd be grateful for help from some more template literate editors. The problems are explained at the links.

• Template talk:Infobox GAA tournament#Superscripts for ordinals
• Template talk:Infobox Site of Special Scientific Interest#Italics?

Thank you.  SchreiberBike | ⌨  18:37, 14 March 2015 (UTC)

Both have been fixed by John of Reading. PrimeHunter ( talk) 23:24, 14 March 2015 (UTC)

Thank you @ John of Reading: and done elegantly too. Just another reason to believe that people can work together to make a great thing like Wikipedia.  SchreiberBike | ⌨  03:30, 17 March 2015 (UTC)

The upload form on Commons contains a preview button at the bottom. The local upload form does not contain any preview button. Why is there no preview button on this project, and is there a way to add one? -- Stefan2 ( talk) 00:25, 15 March 2015 (UTC)

See commons:MediaWiki:UploadForm.js/Documentation. PrimeHunter ( talk) 00:50, 15 March 2015 (UTC)

When I made my earliest uploads at Commons, I normally used the "Preview" feature, but soon discovered a bug: any categories that you had added using the "Categories" selector (just below the "Licensing" drop-down) would be lost on using Preview, and had to be re-added before clicking Upload file. I don't know if this bug is still there. -- Redrose64 ( talk) 00:04, 16 March 2015 (UTC)