Policy | Technical | Proposals | Idea lab | Miscellaneous |
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk. |
|||||||||||||||||||||
|
|||||||||||||||||||||
« Older discussions, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141 | |||||||||||||||||||||
Centralized discussion | |||
---|---|---|---|
Proposals: policy | other | Discussions | Ideas |
Note: inactive discussions, closed or not, should be archived.
|
|||
Contents
- 1 Category membership issues
- 2 JavaScript gadget problems
- 3 Do we normally delete old MediaWiki interface pages that are no longer in use?
- 4 distance around .OGG files?
- 5 How to see what links to a particular section of an article?
- 6 Whole content of Wikipedia as PDF files
- 7 VisualEditor News #5—2015
- 8 List of Wikipedians by article count
- 9 Import limits
- 10 Visual editor putting in HTML markup?
- 11 Copy and paste table using VE
- 12 Prompt for edit summary when only using default section summary
- 13 Watchlist subpages
- 14 Javascript puts logo with banner back
- 15 Cleaning up gadgets
- 16 Main Page oldid pages lack revision info – they look like live pages
- 17 Adding Template:Main Page banner to the Mobile site front page
- 18 Help in fixing a "cite error"
- 19 Move log
- 20 Safari not displaying images in articles
- 21 Recent contributions from a group of editors
- 22 Superprotect is gone
- 23 A list
- 24 Has Wiki Code change Prevented saving as "Web Page Complete?"
- 25 User profile
- 26 Underlined links
- 27 Pages with DOIs inactive since 2014 category
- 28 Bullet randomly appearing
- 29 TOC
- 30 New maps service for Wikipedia
- 31 Search in Google
- 32 Redirect templates in mobile
- 33 Mickopedia
- 34 I keep wishing there were a way to "upvote" edits.
- 35 Lowercase title
- 36 Article patrolled twice
- 37 Stop hiding the instructions when a user creates a page
- 38 Helping page creators get title capitalization correct
- 39 Contents of big Categories
- 40 Tech News: 2015-46
- 41 Community Wishlist Survey
Category membership issues
Categories not placing items in the File namespace correctly.
Category:Candidates for speedy deletion as hoaxes
This category has been stuck a 2 for days, even though there are no pages tagged as a hox. What's wrong?--Bbb23 (talk) 04:45, 18 October 2015 (UTC)
- @Bbb23: That is odd. On the main category page (Category:Speedy deletion) it lists the current pages under hoaxes as 1P, 2F. The 1 page is accounted for. I am assuming the 2F stands for 2 files so it must be something in the File namespace that is triggering it. I just don't know why it is not displaying those files in the category listings. The same thing is happening with Category:Candidates for speedy deletion for unspecified reason. It is showing 1F on the main category page but no listings. --Stabila711 (talk) 05:38, 18 October 2015 (UTC)
- This seems like a much larger issue and is probably worth a bug report. I would file one myself but I don't know how to do that. The File namespace is not being allocated to categories correctly. This can be seen multiple times on the speedy deletion page. Even a category marked for deletion as empty (Category:Wooldridge Monuments images) says it contains 10 files and even warns that it doesn't appear empty even though it is. I am going to copy and paste this thread over to VPT and request a bug report be filed. --Stabila711 (talk) 06:02, 18 October 2015 (UTC)
This thread was copied from the Help Desk. Would someone with more technical knowledge take a look at this and post a bug report if necessary? Thank you. --Stabila711 (talk) 06:02, 18 October 2015 (UTC)
-
- Thanks, Stabila711.--Bbb23 (talk) 11:26, 18 October 2015 (UTC)
- Some cashing issue. WP:NULLEDIT also didn't help. Wasn't there some API call to force update? --Edgars2007 (talk/contribs) 06:53, 18 October 2015 (UTC)
- User:Edgars2007: You might be thinking of
titles=name of page with namespace&action=purge&forecelinkupdate
. This doesn't help when used on the category, though. --Stefan2 (talk) 23:12, 19 October 2015 (UTC)- Maybe :) Thanks. --Edgars2007 (talk/contribs) 05:41, 20 October 2015 (UTC)
- User:Edgars2007: You might be thinking of
- It appears the file count is not updated when a file is deleted, at least in the discussed cases. Category:Candidates for speedy deletion as hoaxes was empty but still said 2 files at Page information and in the parent category a second before I added a file as a test.[1] The count correctly changed to 1 right away. I removed the category again (without deleting the file) and the count correctly changed to 0. Google's cache shows Category:Wooldridge Monuments images did contain 10 files previously, for example File:Wooldridge Monuments 2.JPG. This and all the others are currently at Commons. Page information still claims 10. I haven't made tests to change this. PrimeHunter (talk) 11:44, 18 October 2015 (UTC)
Thanks PrimeHunter. The addition and subtraction of a file in the Wooldridge Monuments category fixed that one as well. So this definitely seems like a caching issue in the File namespace. Now that we know exactly how to fix the problem, does that deserve a bug report or is that something that is just going to have to be lived with and fixed when it comes up? --Stabila711 (talk) 20:14, 18 October 2015 (UTC)
- My suspicion is that this is another effect of phab:T115586 preventing links tables from being updated correctly. Anomie⚔ 13:10, 19 October 2015 (UTC)
- I have also noticed this when looking at c:Special:WantedCategories. That special page is now full of dated deletion categories which are now empty, but the special page thinks that they still contain lots of files. --Stefan2 (talk) 23:12, 19 October 2015 (UTC)
Article categories not always saving completely
I started noticing this a few days ago, but every now and then when I make a category addition or change to an article, the category doesn't get updated with showing the article in its list. This is even considering lag. I've had to re-save articles to get them showing in categories. Is anyone else seeing this? Stevie is the man! Talk • Work 17:11, 25 October 2015 (UTC)
- Please give an example (always give an example when possible no matter what you report), so we can see how the category was added. You appear to use HotCat a lot. Maybe the relevant link table isn't always updated when categories are added via the API. If this is the case then any manual edit, including a null edit but not a purge, should update the link table. PrimeHunter (talk) 17:43, 25 October 2015 (UTC)
- Pardon me for not providing an example, as I was initially just interested if others were seeing the issue, not making an official report. Jeffersontown, Kentucky was the last one, adding Category:1797 establishments in Kentucky. I already did the null edit to fix it, though. Stevie is the man! Talk • Work 18:02, 25 October 2015 (UTC)
- Thanks, that was with HotCat.[2] I haven't been active with categories lately and rarely use HotCat. PrimeHunter (talk) 19:24, 25 October 2015 (UTC)
- Yeap, it's Hotcat. Strangely enough, from out of the blue, somebody just asked me about this problem on my talk page, and I fixed it the same way. I'll report this to Hotcat if it's not reported already. Stevie is the man! Talk • Work 21:05, 25 October 2015 (UTC)
- Thanks, that was with HotCat.[2] I haven't been active with categories lately and rarely use HotCat. PrimeHunter (talk) 19:24, 25 October 2015 (UTC)
- Pardon me for not providing an example, as I was initially just interested if others were seeing the issue, not making an official report. Jeffersontown, Kentucky was the last one, adding Category:1797 establishments in Kentucky. I already did the null edit to fix it, though. Stevie is the man! Talk • Work 18:02, 25 October 2015 (UTC)
- I note that MediaWiki was recently changed to put the updating of links and categories after an edit onto the job queue, rather than performing them immediately. If the job queue is being slow, that could be a cause of this as well (e.g. see T116001, particularly this comment). Anomie⚔ 13:00, 26 October 2015 (UTC)
- I have noticed this lag recently, just in the past couple of weeks, as I regularly clean out Category:Pages with citations using unsupported parameters and similar tracking categories. About one out of every twenty articles will remain in the category after I make a change that should remove it from the category. When I visit the article, the tracking category is not listed at the bottom, but until I do a null edit, the article stays on the category page. This is something new that has never happened to me in tens of thousands of similar edits over the past couple of years. The bug report linked immediately above has a technical but pretty clear explanation by Bawolff. – Jonesey95 (talk) 00:03, 29 October 2015 (UTC)
- This is a pain in the a**. I just reverted this edit, which had put Category:Canadian table tennis players inside itself, and no matter what I do, it's still showing as a subcategory. --Redrose64 (talk) 09:15, 2 November 2015 (UTC)
- I have noticed this lag recently, just in the past couple of weeks, as I regularly clean out Category:Pages with citations using unsupported parameters and similar tracking categories. About one out of every twenty articles will remain in the category after I make a change that should remove it from the category. When I visit the article, the tracking category is not listed at the bottom, but until I do a null edit, the article stays on the category page. This is something new that has never happened to me in tens of thousands of similar edits over the past couple of years. The bug report linked immediately above has a technical but pretty clear explanation by Bawolff. – Jonesey95 (talk) 00:03, 29 October 2015 (UTC)
Misreporting category size
It seems that Mediawiki has started misreporting category size in the past week or so. Mediawiki states that Category:All Wikipedia files with the same name on Wikimedia Commons is at 608, while it quite obviously is at 324. Is this a known issue? Magog the Ogre (t • c) 00:21, 26 October 2015 (UTC)
- See #Categories not placing items in the File namespace correctly. above. PrimeHunter (talk) 01:08, 26 October 2015 (UTC)
Category:Open SPI cases
Wikipedia:Sockpuppet investigations/Turnbull35 is in the category "Open SPI cases". The SPI is in fact archived and not in open status. According to Amalthea, according to this discussion, when this occurs (a relatively new phemenon), one should do a null edit to the category page. I did that, but nothing changed. The next step recommended by Amalthea was to notify someone here. Thanks for looking at this.--Bbb23 (talk) 15:29, 3 November 2015 (UTC)
- @Bbb23: This sounds like another instance of #Category membership issues above. — Mr. Stradivarius ♪ talk ♪ 15:48, 3 November 2015 (UTC)
- @Mr. Stradivarius: I'd completely forgotten I'd filed that report here, mainly because at least with respect to CSD, although I don't patrol CSD as often as I use the WP:SPI table, I never saw the problem again. Assuming the issue here is connected to the other, is there a resolution, an outstanding bug? I'm not good at following these things having to do with the Wikimedia software.--Bbb23 (talk) 15:53, 3 November 2015 (UTC)
- User:Bbb23: You should make the null edit to the SPI case, not to the category page. I did that, and now it has been removed from the category. --Stefan2 (talk) 18:02, 3 November 2015 (UTC)
-
- @Stefan2: My recollection is I used to do that and sometimes it worked and sometimes it didn't, which is principally why I took it to Amalthea. (My recollection also is that when it did work, it sometimes came back not too longer after, don't remember the exact time frame.) Did I misunderstand Amalthea's instructions?--Bbb23 (talk) 18:07, 3 November 2015 (UTC)
-
- @Bbb23: Yes, you need to purge the SPI page, not the category page. It's always worked that way, as far as I can remember. (So it seems that this isn't actually an instance of the category members bug that others have brought up - sorry, I should have read your original post more closely.) — Mr. Stradivarius ♪ talk ♪ 23:25, 3 November 2015 (UTC)
- I do think there's /some/ new problem: The recategorization is caused by an edit of the page, not through a parser function or transcluded template. A null edit or maintainance task shouldn't be necessary then. Amalthea 08:59, 4 November 2015 (UTC)
- @Bbb23: Yes, you need to purge the SPI page, not the category page. It's always worked that way, as far as I can remember. (So it seems that this isn't actually an instance of the category members bug that others have brought up - sorry, I should have read your original post more closely.) — Mr. Stradivarius ♪ talk ♪ 23:25, 3 November 2015 (UTC)
- Getting annoyed with this, so I filed phab:T117679. --Redrose64 (talk) 11:41, 4 November 2015 (UTC)
Delay in displaying and filling new categories
Why do some newly created categories (eg by year) still show up as red-links, and also a new category is still empty after I have added an article to it. Eg Bocaue Pagoda Tragedy which I altered from Category:1993 in the Philippines to Category:1993 disasters in the Philippines and created the latter as it was a (non-natural!) disaster. But despite the Pagoda article now having the new category and it showing as blue-linked, clicking on the link at the bottom of the article gets the new category but it is empty! I could understand if there was a short delay until slave servers are updated with new or updated articles and categories, but this was done yesterday! NB: I found a somilar problem after creating Category:1503 in Russia, but it seemed to require a space at the end of the standard country by year template before the final brackets. Hugo999 (talk) 03:41, 5 November 2015 (UTC)
- If a page has a red link to another page that exists then a purge of the first page will fix it. See #Category membership issues for discussion of missing entries on category pages. PrimeHunter (talk) 03:58, 5 November 2015 (UTC)
JavaScript gadget problems
The problem I am about to describe may have something to do with Wikipedia:Village pump (technical)/Archive 141#Twinkle broken? or Wikipedia:Village pump (technical)/Archive 141#Pages without JS or CSS via Google, but editors there state the issues there have been resolved. Yet for me, the revert vandal, rollback, and revert good faith edits buttons that should be above each current edit 100% of the time now only appear intermittently. The RefToolbar and CharInsert also have this problem, even though all three gadgets are turned on in my preferences. Vycl1994 (talk) 06:09, 20 October 2015 (UTC)
- If it's intermittent, that suggests that the problem isn't at your end but something elsewhere is being slow - either the bits server itself or your connection to it. --Redrose64 (talk) 08:54, 20 October 2015 (UTC)
Do we normally delete old MediaWiki interface pages that are no longer in use?
See the CSD request at MediaWiki talk:Antispoof-name-conflict. No idea what we normally do in cases like this, thought it better to come here and ask first rather than just delete it. Jenks24 (talk) 03:35, 24 October 2015 (UTC)
- Looks like we conflicted, sorry :S I think it's fine to delete under G6 given nothing uses it anymore. Legoktm (talk) 03:38, 24 October 2015 (UTC)
- No worries. I just wasn't sure if we marked them historical or something, but I'm sure you'd know better than me. I'll delete the talk page. Jenks24 (talk) 03:44, 24 October 2015 (UTC)
- I'd have liked to have seen this kept as historical. All the best: Rich Farmbrough, 21:37, 8 November 2015 (UTC).
- I'd have liked to have seen this kept as historical. All the best: Rich Farmbrough, 21:37, 8 November 2015 (UTC).
- No worries. I just wasn't sure if we marked them historical or something, but I'm sure you'd know better than me. I'll delete the talk page. Jenks24 (talk) 03:44, 24 October 2015 (UTC)
distance around .OGG files?
A minor issue, that has irritated me for some time: see the anthem in the infobox in Germany. On my display (vector skin, Firefox 41.0.2) the grey bar icon to play the .OGG-file overlaps the preceding text "(English: "Song of Germany")" - most of it is visible, but the lower pixels of "g" and "y" are hidden by the .OGG bar. I tried adding "border" to the file tag, as that is supposed to add a tiny white border around File links, but that didn't have a visual effect. What's the best way to re-arrange those 2 elements a bit to get some distance between them? Note: I found Wikipedia:Village_pump_(technical)/Archive_64#Rendering_of_ogg_player which may be related, but the bug request was declined for a technical reason. GermanJoe (talk) 14:23, 25 October 2015 (UTC)
- It's not just you. I have Modern skin, same version of Firefox 41.0.2. I also have IE 11. Same thing on both browsers. I also toyed around with the Zoom, because sometimes that can clear oddities. Zoom has no effect on this. No answers, but it's not just Firefox. — Maile (talk) 14:34, 25 October 2015 (UTC)
Anthem: Song of Germany |
-
- With JavaScript disabled I see another dark grey media player box which doesn't overlap. When JavaScript is enabled and I reload the page, I briefly see the dark grey media player box and it doesn't overlap. Then the box disappears and the content below it moves up to fill the hole. Then a light grey media player box appears instead and the content below it moves down, but the box overlaps the text above it a little. With no infobox but just
'''Anthem:''' Song of Germany<br />[[File:German national anthem performed by the US Navy Band.ogg]]
I see something similar: - Anthem: Song of Germany
- However, this case starts out with more space between the text and the dark grey box, so when the light grey box appears instead and moves up, it doesn't move enough to overlap the text. PrimeHunter (talk) 15:07, 25 October 2015 (UTC)
- It's the same behaviour for me: First a darker bar during loading, which has some distance and looks OK. And then another light-grey version of the bar is displayed with the mentioned overlap problem. Java has its own set of display elements of course, but I am really not that experienced with the technical details. GermanJoe (talk) 15:24, 25 October 2015 (UTC)
- Java and JavaScript have absolutely nothing to do with each other. --71.119.131.184 (talk) 16:41, 25 October 2015 (UTC)
- It's the same behaviour for me: First a darker bar during loading, which has some distance and looks OK. And then another light-grey version of the bar is displayed with the mentioned overlap problem. Java has its own set of display elements of course, but I am really not that experienced with the technical details. GermanJoe (talk) 15:24, 25 October 2015 (UTC)
- With JavaScript disabled I see another dark grey media player box which doesn't overlap. When JavaScript is enabled and I reload the page, I briefly see the dark grey media player box and it doesn't overlap. Then the box disappears and the content below it moves up to fill the hole. Then a light grey media player box appears instead and the content below it moves down, but the box overlaps the text above it a little. With no infobox but just
- I added a line break
<br />
to move the player down a line. I then found that the United States article already uses exactly that same fix. I randomly checked Mexico and Brazil, both had the same problem and I applied the same fix. It looks like this is a widespread issue. Do we need to open this as a bug on Phabricator? It's really strange that the light-grey music player renders a few pixels too high when it's inside an infobox. In fact, I think it should probably be a pixel or two lower even when it's not in an infobox. I don't like the way it still touches the bottom of g and y. Alsee (talk) 08:18, 28 October 2015 (UTC)- Yes, please file a bug in phabricator -- a few of us are working on improvements to the media playback interface, and this would be nice to fix up properly. Sounds like a CSS styling issue, probably combining funky styles from the infobox with funky styles from the player... --brion (talk) 20:10, 6 November 2015 (UTC)
How to see what links to a particular section of an article?
I was perusing MOS:HEAD, and stumbled across the following:
"Before changing a section heading, consider whether you might be breaking existing links to that section."
It occurred to me that I know how to determine what pages link to a particular page (via the "What links here" link at the left of every page), but I have no clue how to determine what existing links there may be to a particular section. How do I see what links to a section, so that I may follow the advice given, and not break things if I fix a heading? Thanks! 1980fast (talk) 02:01, 26 October 2015 (UTC)
- There is no easy way in MediaWiki to find links to a specific section of a page, so the only way to be certain is to check all the links in "What links here" individually. Personally, I wouldn't bother doing that all of that, as it would be a lot of tedious work for not much probable benefit. Instead, I would check any articles in "What links here" that you think are likely to contain links to that section, and I would also click "Hide transclusions" and "Hide links" so that only redirects to the page show up, and then check all of those redirects to see if they point to that section. User:WildBot (owned by Dispenser) used to check for these, but it hasn't edited in a couple of years. Does anyone know if there are any bots or tools out there at the moment that check for broken section links? — Mr. Stradivarius ♪ talk ♪ 05:57, 26 October 2015 (UTC)
- Wildbot is actually Josh Parris's. What I recommend is making redirects for sections you want to link to. This way they'll be easy to fix (made rdcheck years ago). I also have some code that'll replacement section links with their equivalent redirect if they're close enough (The Glossary#G issue). — Dispenser 15:13, 27 October 2015 (UTC)
- It may miss some links and give some false positives but you can make a blank search to get the main search form and then enter the expected link text in quotation marks like "Wikipedia:Manual of Style#Section headings". Click "Everything" to search all namespaces like [3]. PrimeHunter (talk) 11:54, 26 October 2015 (UTC)
- Haven't tested myself, but there is such tool. --Edgars2007 (talk/contribs) 11:59, 26 October 2015 (UTC)
- this is not 100% foolproof, but in most cases, using the "insource:" (don't forget the colon) magic serachword should do it. include the article name and the section name in quotes: i.e., serch for
insource:"Article name#Section name"
. e.g., to find all the links to WP:CENSOR, use [4]. i chose this example simply because it was the first section-link i found... as i said, this is not perfect. specifically, if there are any redirects to the article (*not* to specific sections), it's possible that someone linked to the section using [[redirect name#section name]], and this search will not find it. there are probably other links you will miss. peace - קיפודנחש (aka kipod) (talk) 17:32, 5 November 2015 (UTC)
- this is not 100% foolproof, but in most cases, using the "insource:" (don't forget the colon) magic serachword should do it. include the article name and the section name in quotes: i.e., serch for
- Haven't tested myself, but there is such tool. --Edgars2007 (talk/contribs) 11:59, 26 October 2015 (UTC)
Whole content of Wikipedia as PDF files
Hi.
Instead of using web crawlers to fetch pdf versions of all the articles in Wikipedia, is there any other option available? Possible reasonable fee would also be ok in this case.
And if using web crawlers is the only option, what would be the guidelines for using that option to e.g. avoid unnecessary load on Wikipedia servers?
Kind Regards,
Jukka Pesonen — Preceding unsigned comment added by Jukkapesonen (talk • contribs) 10:59, 27 October 2015 (UTC)
- @Cscott: One that you might be able to answer? I guess the question is, Jukka, why do you want to do this? — This, that and the other (talk) 11:25, 27 October 2015 (UTC)
Wikipedia content would be used for developing and testing full text search technologies with pdf preview capability locally in our company. Respecting the great service provided by Wikipedia community, we would like to get the content with no interference to the service. Assuming naturally that this kind of utilization of the content would be ok in the first place?
If we can make this happen, I believe it would not be too hard to convince our management to consider a small donation to Wikipedia.
Kind Regards,
Jukka Pesonen — Preceding unsigned comment added by Jukkapesonen (talk • contribs) 08:56, 28 October 2015 (UTC)
- Jukkapesonen, Wikipedia&more is available for free download at dumps.wikimedia.org.... the most recent HTML version of English Wikipedia is at dumps.wikimedia.org/other/static_html_dumps/current/en/. We even have a page of Torrent links for English and a few other languages. We have a page on how to get and use the Wikipedia:Database_download. You should probably also check our page on Wikipedia:Copyrights, especially the section on Reusers' rights and obligations. It's all free to download, but there are conditions on reuse. If you redistribute any of it, basically you need to credit the original authors, you need to label it as licensed under Creative Commons Attribution-Share-Alike License 3.0 or later, if you make modifications you have to indicate it's been modified, and you must license your changes under the same terms. Alsee (talk) 13:19, 28 October 2015 (UTC)
-
- I think the html dump would be the easiest to use as there are many tools available for coverting html to pdf. Roger (Dodger67) (talk) 06:48, 29 October 2015 (UTC)
Which tool is Wikipedia using for pdf rendering and is it free to use by others too? If it is not available, what would be the second best option?
Kind Regards,
Jukka Pesonen — Preceding unsigned comment added by 87.100.243.238 (talk) 18:58, 29 October 2015 (UTC)
- Jukka, the last I heard, there are bugs in the rendering of WP's xml to pdf, which the html rendering does not suffer from. --Ancheta Wis (talk | contribs) 22:03, 7 November 2015 (UTC)
- We use mw:Offline content generator to generate PDFs from Parsoid-format DOM stored in RESTBase. You can install it on your own servers and run it against wmf content to reduce the load on our servers. Our request rate to the PDF endpoints ranges between 1 to 4 requests per second. If you keep your third-party use to a small fraction of that, we shouldn't be too affected by the additional load. C. Scott Ananian (talk) 21:28, 9 November 2015 (UTC)
VisualEditor News #5—2015
Read this in another language • Subscription list for this multilingual newsletter
Since the last newsletter, the VisualEditor Team has fixed many bugs, added new features, and made some small design changes. They post weekly status reports on mediawiki.org. Their workboard is available in Phabricator. Their current priorities are improving support for languages like Japanese and Arabic, making it easier to edit on mobile devices, and providing rich-media tools for formulæ, charts, galleries and uploading.
Recent improvements
Educational features: The first time you use the visual editor, it now draws your attention to the Link and Cite tools. When you click on the tools, it explains why you should use them. (T108620) Alongside this, the welcome message for new users has been simplified to make editing more welcoming. (T112354) More in-software educational features are planned.
Links: It is now easier to understand when you are adding text to a link and when you are typing plain text next to it. (T74108, T91285) The editor now fully supports ISBN, PMID or RFC numbers. (T109498, T110347, T63558) These "magic links" use a custom link editing tool.
Uploads: Registered editors can now upload images and other media to Commons while editing. Click the new tab in the "Insert Media" tool. You will be guided through the process without having to leave your edit. At the end, the image will be inserted. This tool is limited to one file at a time, owned by the user, and licensed under Commons's standard license. For more complex situations, the tool links to more advanced upload tools. You can also drag the image into the editor. This will be available in the wikitext editor later.
Mobile: Previously, the visual editor was available on the mobile Wikipedia site only on tablets. Now, editors can use the visual editor on any size of device. (T85630) Edit conflicts were previously broken on the mobile website. Edit conflicts can now be resolved in both wikitext and visual editors. (T111894) Sometimes templates and similar items could not be deleted on the mobile website. Selecting them caused the on-screen keyboard to hide with some browsers. Now there is a new "Delete" button, so that these things can be removed if the keyboard hides. (T62110) You can also edit table cells in mobile now.
Rich editing tools: You can now add and edit sheet music in the visual editor. (T112925) There are separate tabs for advanced options, such as MIDI and Ogg audio files. (T114227 and T113354) When editing formulæ and other blocks, errors are shown as you edit. It is also possible to edit some types of graphs; adding new ones, and support for new types, will be coming.
On the English Wikipedia, the visual editor is now automatically available to anyone who creates an account. The preference switch was moved to the normal location, under Special:Preferences.
Future changes
You will soon be able to switch from the wikitext to the visual editor after you start editing. (T49779) Previously, you could only switch from the visual editor to the wikitext editor. Bi-directional switching will make possible a single edit tab. (T102398) This project will combine the "Edit" and "Edit source" tabs into a single "Edit" tab, similar to the system already used on the mobile website. The "Edit" tab will open whichever editing environment you used last time.
Let's work together
- Share your ideas and ask questions at mw:VisualEditor/Feedback. This feedback page uses Flow for discussions.
- Can you read and type in Korean or Japanese? Language engineer David Chan needs people who know which tools people use to type in some languages. If you speak Japanese or Korean, you can help him test support for these languages. Please see the instructions at mw:VisualEditor/IME Testing#What to test if you can help, and report it on Phabricator (Korean - Japanese) or on Wikipedia (Korean - Japanese).
- Local admins can set up the Citoid automatic reference feature for your wiki. If you need help, then please post a request in the Citoid project on Phabricator. Include links to the TemplateData for the most important citation templates on your wiki.
- The weekly task triage meetings are open to volunteers. Learn how to join the meetings and how to nominate bugs at mw:VisualEditor/Weekly triage meetings. You do not need to attend the meeting to nominate a bug for consideration, though. Instead, go to Phabricator and "associate" the main VisualEditor project with the bug.
If you can't read this in your favorite language, then please help us with translations! Subscribe to the Translators mailing list or directly, so that we can notify you when the next issue is ready. Thank you!
— Whatamidoing (WMF) 04:16, 30 October 2015 (UTC)
List of Wikipedians by article count
Hello, WP:List of Wikipedians by article count has stopped updating since past few weeks. Although the bot is getting activated everyday, it is not updating anything. Can someone please give this a look? I also placed a request here about the same issue. Many thanks. Arun Kumar SINGH (Talk) 07:50, 30 October 2015 (UTC)
- Thanks for raising this, Arun. I did some checks yesterday, after creating about 15 or so new articles, and the totals have not changed. The page is updated around 1am each morning. Lugnuts Dick Laurent is dead 13:01, 30 October 2015 (UTC)
- Yes, please also note this recent discussion at WP:AN about this topic that AKS referenced, especially the comments by ErrantX, as ErrantX's comment seem to be directly relevant to the technical side of this issue. --IJBall (contribs • talk) 18:27, 30 October 2015 (UTC)
-
- I hope this gets resolved soon. Cheers, Arun Kumar SINGH (Talk) 05:12, 31 October 2015 (UTC)
-
- Bump. Lugnuts Dick Laurent is dead 14:23, 2 November 2015 (UTC)
-
- Checked today and the report is still not working. Is anyone looking into it? Cheers, Arun Kumar SINGH (Talk) 04:08, 5 November 2015 (UTC)
-
- Probably not. Pinging MZMcBride as he's the operator of BernsteinBot which is in charge of updating the article. --IJBall (contribs • talk) 05:44, 6 November 2015 (UTC)
-
Hi. Right, so I'm the only person who maintains this report. This means that the report is pretty much entirely independent of the Wikimedia Foundation. It also means that if you don't ping me about the report not updating, no amount of bumps or noticeboard threads will help. :-)
I will take a look in the next day or two to see what's going on. The script has occasionally been throwing uncaught exceptions, but I'm still not totally sure why. I imagine this is related, though. Thank you for the concrete examples of incorrect stats. Those should help in diagnosing the issue and verifying a complete fix. --MZMcBride (talk) 14:02, 6 November 2015 (UTC)
Import limits
See WP:AN#Edward Sims Van Zile, or once that gets archived, see the section edited in this diff. The article had been copied from simple: without proper attribution, and someone suggested importing the other page to resolve the problem, but we had to pick a different route because it's not possible to import from simple:. Currently, the only normal Wikipedias whence we can import pages are German, Spanish, French, Italian, and Polish, plus the Nostalgia English Wikipedia, Meta, and a couple of technical WMF projects. (1) What technical barriers prevent us from importing from other projects, i.e. what would have to be changed to enable us to import from elsewhere? (2) Why was it decided to have such a small list of possible source projects? Nyttend (talk) 14:10, 30 October 2015 (UTC)
- I think it was mostly limited for concerns about the quality of the content being imported (sourcing, copyright violations etc). If you can find consensus to expand the list, you can file a phabricator ticket to define additional wgImportSources. —TheDJ (talk • contribs) 15:09, 30 October 2015 (UTC)
- Note that importers can import files from anywhere by using XML files. You could maybe get help from an importer. --Stefan2 (talk) 15:20, 30 October 2015 (UTC)
- @Nyttend and TheDJ: I'm working on some code to allow any wiki to import from any other (see phab:T17583). Fingers crossed, it should be done in the next month or two. — This, that and the other (talk) 09:02, 6 November 2015 (UTC)
Visual editor putting in HTML markup?
Take a look at this edit.[5]. This was the first edit by a new user, using Visual Editor, and added many bogus <div> and <span> tags. No idea what that editor did, but all those HTML tags probably were not inserted by hand. Possible Visual Editor bug, or there's some way a new editor can get it very confused. John Nagle (talk) 20:32, 30 October 2015 (UTC)
- This happens if you do "Select All" and from the Style menu, select "language" and just pick a language. —TheDJ (talk • contribs) 23:17, 30 October 2015 (UTC)
- Maybe they were trying to translate it? — Mr. Stradivarius ♪ talk ♪ 00:37, 31 October 2015 (UTC)
- To Sinhala? --Redrose64 (talk) 09:25, 31 October 2015 (UTC)
- Mr. Stradivarius, that sounds like a very plausible guess. I've requested that the actual purpose (which is to label text that isn't in the wiki's usual content language) be clarified in phab:T117460. Whatamidoing (WMF) (talk) 19:12, 2 November 2015 (UTC)
- To Sinhala? --Redrose64 (talk) 09:25, 31 October 2015 (UTC)
- Maybe they were trying to translate it? — Mr. Stradivarius ♪ talk ♪ 00:37, 31 October 2015 (UTC)
@Whatamidoing (WMF), Nagle, and Mr. Stradivarius: Already filed bug report on this... T116887, but was marked as closed as not a VE error, but user error. Already filed and closed as user error were empty span tags and div tags. T110995 for unnecessary font tags is still open. Content Transcrapulator (CX) does the same thing. One has to file separate bug reports for VE and CX as they use different versions of parsoid. T110173 is the ticket for unnecessary span tags in CX. I continue to see these errors every day by different editors. Alot of errors are picked up by CheckWiki or I notice while fixing other CheckWiki errors. A group of us file bug reports that are mostly closed as user error or just closed for no reason. The rest we get emails when they put it further back on the queue. Bgwhite (talk) 01:16, 4 November 2015 (UTC)
- I believe this diff does actually represent a user error. That's why the subject of phab:T117460 is finding a way to tell users that they are (probably) about to make a mistake.
- I haven't followed anything with CX; the only thing I hear about it is that it's not using VisualEditor. I should try it out again and see whether it's compatible with NoScript these days. Whatamidoing (WMF) (talk) 01:57, 4 November 2015 (UTC)
- This looks like a "developer in denial" situation. Clearly, VE is inserting tags in article space it has no business inserting. It's violating WP:HTML: "Most HTML can be included by using equivalent wiki markup or templates; these are preferred within articles, as they are simpler for most editors, and less intrusive in the editing window.". HTML is supposed to be used only in templates, not where editors have to explicitly deal with it. Also, <div> and <span> aren't on the allowed list of HTML tags in WP:HTML. John Nagle (talk) 05:17, 4 November 2015 (UTC)
-
WP:HTML#div and WP:HTML#span both work for me.
Most HTML can be included by using equivalent wiki markup or templates; these are preferred within articles VE has no way to know whether there is an acceptable substitute for a particular piece of HTML it is dealing with.
HTML is supposed to be used only in templates I have dealt with it in some small amount in a handful of articles. --Izno (talk) 12:37, 4 November 2015 (UTC)
- John, I realize that it's frustrating to see a big mess like that. I've cleaned up my share of such problems, as you would expect of anyone who's spent so much time at Wikipedia. But the real problem isn't the HTML.
- Izno's analysis is correct, but try this as a thought exercise: Let's pretend that WP:HTML were a policy rather than an essay, and that it was magically possible for software to comply with the directly conflicting requirements of every wiki,[1] and that it was possible for the software to know which standard HTML elements map to which local templates (and which HTML elements don't have local templates), so that if a community preferred templates, then those templates would automagically be substituted. Let's also say that this system is working perfectly, and that this wiki had chosen to always use {{lang|si}} instead of the equivalent HTML tags.
- Let's say that in this template-based system, the same user went to the same page and did exactly the same thing, and that you checked the diff. Then you would have seen every element on the page wrapped in the {{lang|si}} template, rather than every element on the page wrapped in the HTML tag. It would still be a mess, and it would still need to be fixed.
- That's because the real problem is that the user didn't understand the tool. The real problem isn't the exact method used to document the fact that the user was confused; the real problem is that the software was unclear to the user. Therefore, the most relevant and practical solution is: Make the tool be less confusing. Making the tool's purpose more obvious might result in what we actually want, which is neither HTML tags that incorrectly label the whole page as Sinhalese nor local templates that incorrectly label the whole page as Sinhalese, but instead a page that does not have all the English text marked as being in Sinhalese through any method at all. Whatamidoing (WMF) (talk) 21:16, 4 November 2015 (UTC)
-
- This looks like a "developer in denial" situation. Clearly, VE is inserting tags in article space it has no business inserting. It's violating WP:HTML: "Most HTML can be included by using equivalent wiki markup or templates; these are preferred within articles, as they are simpler for most editors, and less intrusive in the editing window.". HTML is supposed to be used only in templates, not where editors have to explicitly deal with it. Also, <div> and <span> aren't on the allowed list of HTML tags in WP:HTML. John Nagle (talk) 05:17, 4 November 2015 (UTC)
- ^ For example, WP:HTML was forked some years ago from m:Help:HTML in wikitext, which takes the opposite approach. It opens with a lengthy list of explicitly permitted HTML.
-
-
-
-
- @Nagle and Whatamidoing (WMF): I used to see 1-2
<h2>
tags a month, now with VE I see upwards 10 a day (9 for today). When I fix them later, I'll expect to see the<h2>
tags surrounded by<p>
and<li>
tags, with<br>
tags inside the<h2>
tags every few days. Why are those tags surrounded or inside, who knows. Yes, a bug report has been filed and has been ignored. Sorry Izno, but VE does know there is an acceptable substitute for a section heading. - Whatamidoing's answer goes along with what they say at developer's conferences... 1) wikicode is going away and only HTML/VE. 2) WMF does not have to abide by community MOS.
- WP:HTML is an essay, but WP:ACCESSIBILITY says use wikicode when possible and WP:MOS says use HTML sparingly. But, Whatamidoing uses a Meta help page which says what HTML codes are possible, not what should be used. Meta help page trumps community MOS. Both VE and CX are littering pages with HTML, dates wikilinked, templates (including cite templates) left in foreign languages and other messes. This goes against what Wikicode was originally created for, to make editing a Wiki page relatively simple. Whatamidoing is only here for the users of VE. The peons who cleanup VE's messes don't matter to the WMF, and thus doesn't matter to Whatamidoing either. Bgwhite (talk) 06:36, 5 November 2015 (UTC)
- Technically, VisualEditor doesn't know the wikitext for ==Section headings==. It "thinks" in HTML. VisualEditor sends <h2> headers to Parsoid, whose sole purpose is to turn HTML into wikitext (and vice versa). If that's not happening, then it's either a bug and it needs to be fixed, or it's the return of phab:T93754's problem with a RESTbase race condition—and it still needs to be fixed. I don't see any bug reports or recent comments from you on Phab about the h2 header problem, but I'll make sure it gets on the list. Please feel free to drop by WP:VEF or my talk page whenever you want more information about a problem, or even to have someone
complain loudlyremind the team about one that you think they're ignoring. Whatamidoing (WMF) (talk) 07:41, 5 November 2015 (UTC)- Whatamidoing (WMF) T113173 is the ticket filed for
<h2>
problem. It was closed as a duplicate of T116460. I'm already a subscriber on the ticket. Today's list of articles with header problems are Ahoy (greeting), Cross merchandising, Gentamicin, Gill Kalan, Knowledge-based decision making, Tigecycline, Transcendent (television series), William Spiggot, Groth Law Firm. Tigecycline and Chloroquine also contain<li>
tags in an already defined wikicode list, thus it breaks accessibility guidelines by creating a list made up of multiple lists. Bgwhite (talk) 09:48, 5 November 2015 (UTC)- Thanks for the link. I've got a little list of bugs for a meeting tomorrow. Whatamidoing (WMF) (talk) 20:38, 5 November 2015 (UTC)
- Whatamidoing (WMF) T113173 is the ticket filed for
- Technically, VisualEditor doesn't know the wikitext for ==Section headings==. It "thinks" in HTML. VisualEditor sends <h2> headers to Parsoid, whose sole purpose is to turn HTML into wikitext (and vice versa). If that's not happening, then it's either a bug and it needs to be fixed, or it's the return of phab:T93754's problem with a RESTbase race condition—and it still needs to be fixed. I don't see any bug reports or recent comments from you on Phab about the h2 header problem, but I'll make sure it gets on the list. Please feel free to drop by WP:VEF or my talk page whenever you want more information about a problem, or even to have someone
- @Nagle and Whatamidoing (WMF): I used to see 1-2
-
-
-
Copy and paste table using VE
A few days ago I was able to add a table by copying from an Excel file and pasting in an edit box (Visual Editor)
Yesterday and today I have been unable to.
I don't believe this functionality is identified in the manual. That manual states you can drag a CSV file, but I was able to copy from the screen and paste into the edit box.
I made sure to reboot my computer in case I had something hung up. Any thoughts on what might've changed?--S Philbrick(Talk) 17:14, 31 October 2015 (UTC)
- Hi S. It still works for me, using Google Docs in Safari 9 on Mac OS 10.10. (I don't have Microsoft Excel.) How similar is the content that you're trying to paste this time? Any odd formatting, charts, images, etc.? What's your browser or OS? Whatamidoing (WMF) (talk) 21:24, 4 November 2015 (UTC)
@Whatamidoing (WMF):My operating system is Windows 7; my browser is Chrome; no changes to either of those recently (other than the obvious occasional automatic updates)
I tried three examples in a sandbox which should provide some useful information.
My normal procedure is to drop in a header, a source with reference and a legend template first using edit source, then follow up with the visual editor edit, drop in the table, then follow up with an edit source to add in the class="wikitable"
I tried that (except for the last step) three different ways:
- I tried it in Mozilla copying from Excel, and that drops the data in but not in a well-formed way.
- Next I tried the same thing in chrome. In this case there is nothing below the legend because when I copy and paste it's like I didn't do anything.
- The third time, I used chrome but copied from Google docs. This time it worked as it should. I show the table in the first part of that section as it appears after simply dropping it in. I added it again and then added the class="wikitable" table code to make it look right.
I hope this will provide insight into what the problem is. The bad news is it seems to have something to do with Excel, which is a bit of a pain because you don't have it. For what it's worth when I said I copied from Google Docs, I first grabbed the data from Excel dropped in it to Google Docs and then copied it from Google Docs so it's very much the same data but it used to work when I did it from Excel.
On the one hand your advice might be to use Google Docs. If I have to, I have to, but I get the data from an external source (an NCAA database), drop it into Excel and do a fair amount of processing. I have separate routines for ordinary four year players, players with five years and one redshirt year, players with five years and one partial year, players with four years but different schools etc. I might be able to do all that Google Docs but I sure would be a lot happier if I could continue to use Excel.--S Philbrick(Talk) 22:21, 4 November 2015 (UTC)
Prompt for edit summary when only using default section summary
I have selected the preference for the wiki software to warn me if I try to save an edit with a blank edit summary, and I think it has helped me. Until today (or at least quite recently) It treated a summery that contained the defualt section summary on a section edit (/* Section name */) as if it were blank, and still prompted me for a fuller edit summary. Today it doesn't, but it does still propmpt if the summary is blank. I prefer the previous behavior. Is this an intentional change? I use FireFox on MS Windows 7 (64 bit). DES (talk) 00:20, 3 November 2015 (UTC)
- It prompted me when I tried it just now. Do you happen to have some user script or gadget that changes the summary somehow? Anomie⚔ 13:37, 3 November 2015 (UTC)
- subtle point: as far as i know, the logic is not necessarily "default section name". the logic compares the "pre-filled" summary with the content of "summary" field, prompts you if they are equal. the difference may seem meaningless, but under some conditions it isn't: for instance, if you choose the gadget to add "edit" link to the lead section, you'll see /* top */ as the summary when editing the lead section. however, this summary was added by the gadget, and is not "pre-filled", as far as mw software is concerned, so you won't get prompted if you leave it as is (you *will get prompted if you delete it - "nothing" is the pre-filled value from mw POV). there are probably other such cases. this works the other way too, i believe: e.g., when you hit "undo", there's elaborate pre-filled summary, which is not "section name". mw will still prompt you to fill one if you leave it unchanged. peace - קיפודנחש (aka kipod) (talk) 15:16, 4 November 2015 (UTC)
- This seems to be the opposite of phab:T19416. We should add a way to override the change that it made. Jackmcbarn (talk) 02:29, 9 November 2015 (UTC)
- For gadgets it's simple enough: if the hidden
wpAutoSummary
form field matches the md5 hash of the summary, it will prompt for a summary. If not, it won't. So have your gadget update the field appropriately and you're good. That probably doesn't help much for the "edit lead section" gadget, though, or other things using the summary URL parameter instead of JS on the edit form. Anomie⚔ 16:47, 9 November 2015 (UTC)
- For gadgets it's simple enough: if the hidden
- This seems to be the opposite of phab:T19416. We should add a way to override the change that it made. Jackmcbarn (talk) 02:29, 9 November 2015 (UTC)
- subtle point: as far as i know, the logic is not necessarily "default section name". the logic compares the "pre-filled" summary with the content of "summary" field, prompts you if they are equal. the difference may seem meaningless, but under some conditions it isn't: for instance, if you choose the gadget to add "edit" link to the lead section, you'll see /* top */ as the summary when editing the lead section. however, this summary was added by the gadget, and is not "pre-filled", as far as mw software is concerned, so you won't get prompted if you leave it as is (you *will get prompted if you delete it - "nothing" is the pre-filled value from mw POV). there are probably other such cases. this works the other way too, i believe: e.g., when you hit "undo", there's elaborate pre-filled summary, which is not "section name". mw will still prompt you to fill one if you leave it unchanged. peace - קיפודנחש (aka kipod) (talk) 15:16, 4 November 2015 (UTC)
Watchlist subpages
Is there a way to watchlist "all subpages of a given page" (for namespaces that support subpages) rather than having to explicitly and separately watchlist each subpage? DMacks (talk) 06:07, 3 November 2015 (UTC)
- Not that I'm aware of. This would be a good idea for a gadget, though. The question is, what would be the best interface for it? A dropdown menu next to the star icon, perhaps? — Mr. Stradivarius ♪ talk ♪ 13:17, 3 November 2015 (UTC)
- Actually, just putting it in the "More" dropdown menu (in the Vector skin) might be best. — Mr. Stradivarius ♪ talk ♪ 13:20, 3 November 2015 (UTC)
- This works well for, say, five subpages, but consider how many subpages there are of Wikipedia:Articles for deletion, or somesuch. Any tool would need to have a limit on how many pages could be watched in one go. Relentlessly (talk) 13:36, 3 November 2015 (UTC)
- "All subpages of a given page" ought to include subpages that haven't been created yet. That's obviously much more difficult and would need changes to the core software. -- John of Reading (talk) 07:41, 4 November 2015 (UTC)
Javascript puts logo with banner back
MediaWiki:Common.css was edited today to remove the rules that used to replace the Wikipedia globe logo in the corner of every page with a celebratory logo with a red banner. Thus, the logo with the banner should no longer appear. However, I'm still seeing the logo with the red banner, if I enable Javascript in my browser. The rules are no longer in common.css, but some javascript on the page adds CSS rules to the DOM that put the celebratory logo there. This shouldn't happen.
Why does this happen, and how do we fix this? I don't have enough webdev-fu to debug this. Flushing the browser caches didn't help. ?action=purge didn't help. It was suggested that changes to common.css may take up to five minutes to take effect, but it's been over 50 minutes since the edit. It is possible that what you see depends on your user preferences or skin. If you could help, I'd appreciate it.
I have cross-posted this problem from the #wikimedia-tech channel on the Freenode IRC network. – b_jonas 18:49, 3 November 2015 (UTC)
- It's gone for me.. are you logged in, out, what browser, did you try restarting it ? —TheDJ (talk • contribs) 18:52, 3 November 2015 (UTC)
- The stylesheet cache rolls over every 5 minutes and was updated swiftly. The module update got skipped due to a rare race condition between the hundreds of web servers. It seems the old revision of the page was effectively re-cached under the new revision ID. I've done another update to mitigate the issue for now. –Krinkle 19:23, 3 November 2015 (UTC)
- Krinkle has explained that the "module" he's referred to is the "site" Resourceloader module, which indeed loads a copy of the styles from javascript for arcane and historical reasons.
- The banner logo is gone now, thank you. I hope it's fixed for everyone else as well, if not, please mention it here. – b_jonas 10:20, 4 November 2015 (UTC)
Cleaning up gadgets
I propose we delist any gadget older than 2-3 years with fewer than 5 users... They can still be loaded by users from userscripts, but they won't clutter up the Gadget list. —TheDJ (talk • contribs) 22:20, 3 November 2015 (UTC)
- The only way to clean up that list is to purge the database of user preference flags still pointing to old, deleted gadgets.
-- [[User:Edokter]] {{talk}}
23:26, 3 November 2015 (UTC)- I was just going to ask why we had a gadget called "-contribsrange" in addition to the usual "contribsrange", along with several other similar cases. This looks like it needs to be made a Phabricator task. — Mr. Stradivarius ♪ talk ♪ 23:32, 3 November 2015 (UTC)
- Looking at phab:T117120, I see that this has already been fixed. I'm not sure whether the patch made it out in time for Thursday's update, though. — Mr. Stradivarius ♪ talk ♪ 23:40, 3 November 2015 (UTC)
- It didn't. Legoktm (talk) 23:46, 3 November 2015 (UTC)
- Is this patch going to remove the de-listed items from the database of user preference flags? Or only hide them in the list? WhatamIdoing (talk) 02:07, 4 November 2015 (UTC)
- It just hides them in the list. — Mr. Stradivarius ♪ talk ♪ 02:27, 4 November 2015 (UTC)
- Is this patch going to remove the de-listed items from the database of user preference flags? Or only hide them in the list? WhatamIdoing (talk) 02:07, 4 November 2015 (UTC)
- It didn't. Legoktm (talk) 23:46, 3 November 2015 (UTC)
- Yuck polution.. :D Well let's see what the list looks like after the next train.. —TheDJ (talk • contribs) 08:18, 4 November 2015 (UTC)
- Looking at phab:T117120, I see that this has already been fixed. I'm not sure whether the patch made it out in time for Thursday's update, though. — Mr. Stradivarius ♪ talk ♪ 23:40, 3 November 2015 (UTC)
- I was just going to ask why we had a gadget called "-contribsrange" in addition to the usual "contribsrange", along with several other similar cases. This looks like it needs to be made a Phabricator task. — Mr. Stradivarius ♪ talk ♪ 23:32, 3 November 2015 (UTC)
- Counts should be accurate now. Legoktm (talk) 08:19, 9 November 2015 (UTC)
Main Page oldid pages lack revision info – they look like live pages
The old version (oldid) pages of the Main Page are lacking the revision info and links usually found at the top of such pages, making them look like current pages. Example: 13 January 2003 Main Page version. Is this normal?
This is also the case with the oldid pages of for example the sv: and simple: front pages, but not with for example da: and no:. --Pipetricker 15:10, 4 November 2015 (UTC)
- We change some things for the display of the main page. The info is hidden in the Vector and Monobook skins by
display: none !important;
for#contentSub
in MediaWiki:Vector.css and MediaWiki:Monobook.css. Compare to https://en.wikipedia.org/w/index.php?oldid=585725&useskin=modern. I don't know whether it was different previously but the live version of Main Page in Vector currently has an empty<div id="contentSub"></div>
so I don't know why we hide it. PrimeHunter (talk) 15:59, 4 November 2015 (UTC) - The Vector code was added by TheDJ 5 July 2009.[6] It may have been based on Monobook code from 9 August 2008 with edit summary "Fix padding weirdness on top of Main Page".[7] MonoBook also currently has an empty
<div id="contentSub"></div>
on Main Page. PrimeHunter (talk) 16:11, 4 November 2015 (UTC) - Archived versions at [8] and [9] also have an empty
contentSub
on those dates. PrimeHunter (talk) 16:18, 4 November 2015 (UTC)
Adding Template:Main Page banner to the Mobile site front page
You are invited to join the discussion at Talk:Main Page#Adding Template:Main Page banner to the Mobile site front page. Thanks. Mz7 (talk) 21:07, 4 November 2015 (UTC)
Help in fixing a "cite error"
I found a big red cite error message for reference #1 here American Water Spaniel#References. My skills in fixing these is limited and I couldn't track down the problem so any help from those of you who know what to do will be appreciated. MarnetteD|Talk 23:56, 4 November 2015 (UTC)
- The error message correctly said: '"spiotta30" defined multiple times with different content'. One of the definitions was for page 38 so I changed it to "spiotta38". PrimeHunter (talk) 00:33, 5 November 2015 (UTC)
- Many thanks PrimeHunter. MarnetteD|Talk 00:58, 5 November 2015 (UTC)
Move log
The "revert" link does not appear next to entries in the move log that are moves over redirects. GeoffreyT2000 (talk) 02:03, 5 November 2015 (UTC)
- Please include examples in reports so others don't have to search for them. Move over redirect, Move not over redirect. I don't know why a move over redirect has no revert link. PrimeHunter (talk) 03:31, 5 November 2015 (UTC)
- After some epic archaeology in the MediaWiki codebase, it looks like this is simply due to an oversight by Aaron Schulz in 2008 (the important commit that removed "revert" links from move log entries was r33234). So you could file a Phabricator task if you would like it changed. All the same, one has to remember that the revert link doesn't perform any undeletions of the redirect that was there before. — This, that and the other (talk) 08:38, 5 November 2015 (UTC)
Safari not displaying images in articles
As of this morning, I noticed for the first time that Safari is not displaying images in the articles. I know Safari has WikiMedia issues, but I've had this new Mac for weeks, doing quite a bit of work on Wikipedia, and I don't recall seeing this issue before. Anyone else notice a recent problem? Works fine when I download Firefox, of course. Shawn in Montreal (talk) 14:44, 5 November 2015 (UTC)
- Works fine for me on for example Sean Combs, Normandy landings. I have Safari as my backup and normally use Chrome. I am running Mavericks -- Diannaa 🍁 (talk) 20:13, 5 November 2015 (UTC)
- Okay thanks. I'm on Yosemite. Shawn in Montreal (talk) 20:15, 5 November 2015 (UTC)
- It's been fine for me on El Capitan. Imzadi 1979 → 20:26, 6 November 2015 (UTC)
- Okay thanks. I'm on Yosemite. Shawn in Montreal (talk) 20:15, 5 November 2015 (UTC)
Recent contributions from a group of editors
Is there a good tool to track recent contributions from a group of usernames listed on, say, a meetup page, without going through wikimetrics or an education program extension?--Pharos (talk) 14:52, 5 November 2015 (UTC)
Superprotect is gone
Superprotect was introduced by the Wikimedia Foundation to resolve a product development disagreement. We have not used it for resolving a dispute since. Consequently, today we are removing Superprotect from Wikimedia servers.
Without Superprotect, a symbolic point of tension is resolved. However, we still have the underlying problem of disagreement and consequent delays at the product deployment phase. We need to become better software partners, work together towards better products, and ship better features faster. The collaboration between the WMF and the communities depends on mutual trust and constructive criticism. We need to improve Wikimedia mechanisms to build consensus, include more voices, and resolve disputes.
There is a first draft of an updated Product Development Process that will guide the work of the WMF Engineering and Product teams. It stresses the need for community feedback throughout the process, but particularly in the early phases of development. More feedback earlier on will allow us to incorporate community-driven improvements and address potential controversy while plans and software are most flexible.
We welcome the feedback of technical and non-technical contributors. Check the Q&A for details.
Quim Gil, Engineering Community Manager @ Wikimedia Foundation -- 17:33, 5 November 2015 (UTC)
A list
Hi! I am hungarian, I speak english only a little bit. I woluld like a list of en:Category:County seats of the United States with all articles name. AWB is not supported for me... Thank you! --B.Zsolt (talk) 21:32, 5 November 2015 (UTC)
- You can ask some AWB user here. Or you can try catscan for yourself. --Edgars2007 (talk/contribs) 22:39, 5 November 2015 (UTC)
Has Wiki Code change Prevented saving as "Web Page Complete?"
I periodically save some Wikipedia pages to my hard drive, to have a record of how before and after edits appeared, which helps me a lot to understand template coding, as well as other forms of structure in Wikipedia.
For the last few months, however, when I click to save as "web page complete," the result does not include most of the photo images that are in the article too. Instead, where the photos are located in the article, there is complex code, but no actual photo.
This has been going on only for two or three months now. Since I don't have the same problem when I save pages from other websites, I am assuming it is the result of some kind of Wikipedia code revision. I use the latest version of Firefox for my browser and have Windows 10 OS or Windows 7, on the computers I am using to access Wikipedia. I get the same "save as" result with both of those OSs.
Wondering if this will be a permanent situation in Wikipedia, or if some pending revision of your software will enable me to save Wiki pages as I did before -- as a web page complete?EditorASC (talk) 00:11, 6 November 2015 (UTC)
- "complex code"... can you try describing that again... :) —TheDJ (talk • contribs) 07:51, 6 November 2015 (UTC)
- It works for me, except the logo is missing. Firefox 42.0 on Windows Vista 32-bit. Try saving Couch in a folder. Which images are missing? Do you get a subfolder called something like "Couch - Wikipedia, the free encyclopedia-files"? If so, are the images in that folder? I for example get "300px-2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartme.jpg", a copy of https://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg/300px-2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg. Can you view source (Ctrl+U) of the saved page and copy-paste the code where an image is missing? For example something like:
<div class="thumb tright"> <div class="thumbinner" style="width:302px;"><a href="https://en.wikipedia.org/wiki/File:2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg" class="image"><img alt="" src="Couch%20-%20Wikipedia,%20the%20free%20encyclopedia-files/300px-2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartme.jpg" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/c/c2/2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg/450px-2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/c/c2/2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg/600px-2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg 2x" data-file-width="3888" data-file-height="2592" height="200" width="300"></a> <div class="thumbcaption"> <div class="magnify"><a href="https://en.wikipedia.org/wiki/File:2009-05-16_Main_office_lobby_at_Hampton_Forest_Apartments.jpg" class="internal" title="Enlarge"></a></div> A three-cushion couch in an office lobby</div> </div> </div>
- PrimeHunter (talk) 13:40, 6 November 2015 (UTC)
User profile
Special:UserProfile, which is displayed when you click on the username in a mobile diff, displays just plain text with blue (unvisited) or purple (visited) links instead of putting "Edited the page" and "Thanked by" in two boxes and making the links black. GeoffreyT2000 (talk) 02:26, 6 November 2015 (UTC)
- Please include in example in reports. Here is one: https://en.m.wikipedia.org/wiki/Special:UserProfile/GeoffreyT2000. It sounds similar to Wikipedia:Village pump (technical)/Archive 136#Some sort of presentation bug in April where Jdlrobson posted when it was fixed. Today I don't see boxes at any tested wikis, except a "Talk to" box. PrimeHunter (talk) 13:15, 6 November 2015 (UTC)
Underlined links
So how come I have the "underline links" option set to "always" in my Preferences, yet the links in the article ToCs are no longer underlined? (The rest of the links are underlined as they should be). Can this be fixed, please, or do I need to add yet another hack to my css sheet? I'm using Monobook skin, if this matters. Thanks.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 6, 2015; 15:48 (UTC)
- Me too - Vector skin. Also affects Commons. Optimist on the run (talk) 16:43, 6 November 2015 (UTC)
- It's caused by Mediawiki's CSS treating the TOC as a table. It seems to be discussed in phab:T92481, but I'm not sure if that's the correct ticket or not. Relentlessly (talk) 17:11, 6 November 2015 (UTC)
- When I select "Underline links: Skin or browser default" at Special:Preferences#mw-prefsection-rendering, I see underlined TOC links in Cologne Blue and no other skins. With "Underline links: Always" I also see it in Modern, so the setting is able to affect the TOC in some circumstances. PrimeHunter (talk) 17:45, 6 November 2015 (UTC)
Pages with DOIs inactive since 2014 category
Could somebody please tell me what is causing the deleted category Category:Pages with DOIs inactive since 2014 to appear on Real ear measurement. Thanks, JMHamo (talk) 00:02, 7 November 2015 (UTC)
- Caused by ref 3 which has
|doi_brokendate=
set. Keith D (talk) 00:47, 7 November 2015 (UTC)- More specifically, that
{{cite journal}}
has|doi_brokendate=2014-03-28
--Redrose64 (talk) 00:56, 7 November 2015 (UTC) - @Keith D and Redrose64: Thank you. I've removed
|doi_brokendate=2014-03-28
from the citation and it no longer appears. JMHamo (talk) 01:21, 7 November 2015 (UTC)- Deleting an error message does not resolve the error. I have recreated the tracking category with some explanatory text. It looks like that article was in a draft state until the last few days, so the category was not applied until the article moved to mainspace. I reported the broken DOI to crossref.org, which may be able to re-establish a link to it. – Jonesey95 (talk) 16:58, 7 November 2015 (UTC)
- More specifically, that
Bullet randomly appearing
Hi, yesterday I created American Morgan Horse Association. I used the infobox organization at the top of the article and filled in the most-needed parameters (I plan to fill in more later). The association is headquartered in Shelburne, Vermont and every time I look at the article, a bullet pops up in the infobox in front of the words "Shelburne, Vermont". I've checked it several times and can't find any error, and the bullet disappears after a couple of seconds. This is very weird and I've never had it happen before. White Arabian mare (Neigh) 00:39, 7 November 2015 (UTC)
- The location parameter produces different code because {{Infobox organization}} has this:
| label19 = Location | class19 = label | data19 = {{Unbulleted list | 1 = {{comma separated entries | 1 = {{#if:{{{location_city|}}} |<span class="locality">{{{location_city}}}</span>}} | 2 = {{#if:{{{location_country|}}} |<span class="country-name">{{{location_country}}}</span>}} }} | 2 = {{{location|}}} | 3 = {{comma separated entries | 1 = {{#if:{{{location_city2|}}} |<span class="locality">{{{location_city2}}}</span>}} | 2 = {{#if:{{{location_country2|}}} |<span class="country-name">{{{location_country2}}}</span>}} }} | 4 = {{{location2|}}} }}
- I don't see a bullet in Firefox 42.0 on Windows Vista but other browsers may react differently. The infobox produces this wikitext for the cell:
<td class="label"> <div class="plainlist"><ul><li>Shelburne, Vermont</li></ul></div></td>
- The rendered page gets identical html apart from line breaks. MediaWiki:Common.css contains:
/* Unbulleted lists */ .plainlist ol, .plainlist ul { line-height: inherit; list-style: none none; margin: 0; }
- "none" prevents
<ul>...</ul>
from producing a bullet but your browser may render the original page long enough to see the bullet before the css is applied. - Here is
<div class="plainlist"><ul><li>Shelburne, Vermont</li></ul></div>
: -
- Shelburne, Vermont
- Here is
<div><ul><li>Shelburne, Vermont</li></ul></div>
: -
- Shelburne, Vermont
- I never see a bullet in the first but permanently (as expected) see a bullet in the second where I removed the plainlist class. PrimeHunter (talk) 01:22, 7 November 2015 (UTC)
Ok, thank you. White Arabian mare (Neigh) 02:58, 7 November 2015 (UTC)
TOC
The TOC in Wikipedia:Village pump (proposals) has a longer gap between consecutive sections than most other pages. GeoffreyT2000 (talk) 01:43, 7 November 2015 (UTC)
- This is likely related to the thread "Underlined links" above. Just scroll up to see where the situation stands at this time. You might also want to cut and paste this to that thread to keep everything together. MarnetteD|Talk 01:52, 7 November 2015 (UTC)
- It's because
__TOC__
is placed in a table there. The table has other content but would render the same as now with only this:
{| |- | __TOC__ |}
- PrimeHunter (talk) 02:13, 7 November 2015 (UTC)
- The same effect is seen at User talk:Bgwhite, which doesn't have an explicit
__TOC__
but does have an unclosed table (and two unclosed<div>
which are not the culprits). I've been stalking that talk page for over three years, and the TOC was normally-spaced until recently. I'm sure that it's a recent styling change in MediaWiki. --Redrose64 (talk) 22:21, 7 November 2015 (UTC)- That sounds right. The 3 October version at https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29 has normal TOC gaps while 7 November has large gaps. Our own 3 October revision [10] with current rendering has large gaps. PrimeHunter (talk) 23:31, 7 November 2015 (UTC)
- The problem (as in the other thread) is the addition of
to Mediawiki's styling of the table of contents. It's clearly a not-totally-thought-through change. Relentlessly (talk) 23:41, 7 November 2015 (UTC)display:table-cell
- Is there a hack I can add to my css/js scripts to fix this? Optimist on the run (talk) 07:44, 8 November 2015 (UTC)
- The same effect is seen at User talk:Bgwhite, which doesn't have an explicit
- It also affects any page that uses
{{TOC hidden}}
, since that is a__TOC__
wrapped in a collapsible table. --Redrose64 (talk) 00:14, 9 November 2015 (UTC)- Unless I'm much mistaken, Redrose64, it affects any page with a table of contents, not merely those wrapped in a table. Relentlessly (talk) 16:26, 9 November 2015 (UTC)
- No - it doesn't affect (for example): Wikipedia:Village pump (technical); User talk:Redrose64; Wikipedia:WikiProject Women writers or indeed User talk:Relentlessly. These all have normal spacing, not the broader spacing seen at Wikipedia:Village pump (proposals); User talk:Bgwhite; or Wikipedia:WikiProject Women. --Redrose64 (talk) 20:32, 9 November 2015 (UTC)
- Oh, I see. So all TOCs have more spacing than previously, but those ones have even more. It's caused by the
property on the table, for what it's worth: elements withborder-spacing
will get that border spacing. The use of thatdisplay:table cell
property feels like an ill-thought through kludge to me. Relentlessly (talk) 22:11, 9 November 2015 (UTC)display
- Oh, I see. So all TOCs have more spacing than previously, but those ones have even more. It's caused by the
- No - it doesn't affect (for example): Wikipedia:Village pump (technical); User talk:Redrose64; Wikipedia:WikiProject Women writers or indeed User talk:Relentlessly. These all have normal spacing, not the broader spacing seen at Wikipedia:Village pump (proposals); User talk:Bgwhite; or Wikipedia:WikiProject Women. --Redrose64 (talk) 20:32, 9 November 2015 (UTC)
- Unless I'm much mistaken, Redrose64, it affects any page with a table of contents, not merely those wrapped in a table. Relentlessly (talk) 16:26, 9 November 2015 (UTC)
New maps service for Wikipedia
Dear community, I would like to get your feedback on the future of Wikipedia Maps. As you might have heard, our maps server is now operational, and is used on Wikivoyage and the Android app. We do not yet have enough maps servers to enable it for all Wikipedia articles, in part because we need community to expressly say this is a high priority, in part because community needs to establish what must happen for maps to be adapted, and lastly because we should have a <map> wiki markup to support direct maps usage. Be forewarned that most of our time was spent developing the tiling server, whereas the map itself (style) can use more work - we even have this proposal from a volunteer to help us with it (please support). So, to move ahead, we need:
- Blockers: Decide what changes must happen for maps to be used anywhere in Wikipedia.
- Hopefully this list is short, otherwise it will be tough to allocate substantial resource without a clear community buy-in.
- Labs: Decide on the migration of the map popups at the top of the articles to the new underlying tiles.
- Articles: Decide which capabilities should the <map> tag support.
- Prioritization: Plan which of these features should we work on next. What use cases will be the most valuable from the start?
Please send your general maps feedback, comments, and questions here. Thanks! --Yurik (WMF) (talk) 08:15, 7 November 2015 (UTC)
- Come one people, show your enthusiasm about maps !!!! —TheDJ (talk • contribs) 23:08, 9 November 2015 (UTC)
Search in Google
Hi. Please tell me how to remove it?. -- Дагиров Умар (talk) 21:22, 7 November 2015 (UTC)
- For others searching for this: the article is at ce:Соьлжа-ГӀала, you can see the problem in this Google search, and the "Коьрта агӀо" part seems to mean "Main page" in Chechen. @Дагиров Умар: I don't see anything strange happening at the ce:Соьлжа-ГӀала page, so I can only assume that this is a mistake on Google's part. We don't control how Google displays their search results, so I'm afraid that you will have to ask them about it. Best — Mr. Stradivarius ♪ talk ♪ 10:08, 8 November 2015 (UTC)
- Google's title choice can be hard to predict or affect. Many sites have a poor title in
<title>...</title>
so it often makes sense to use something else, but it's done completely automatically with varying results. See https://support.google.com/webmasters/answer/35624?hl=en and https://yoast.com/google-page-title/. I have no idea how to get Google to remove the unwanted text. PrimeHunter (talk) 13:49, 8 November 2015 (UTC)- I see that you recently created MediaWiki:Pagetitle. Maybe wait for some time. But anyway it is strange - I see, that previously you have used the translatewiki version, which is the same for Wikipedia. --Edgars2007 (talk/contribs) 14:13, 8 November 2015 (UTC)
- Watch This section does not have this problem. (Wikipedia small). for Lezgi Wikipedia also has unwanted text. Thank you --Дагиров Умар (talk) 15:59, 8 November 2015 (UTC)
Redirect templates in mobile
In the mobile Wikipedia, "DISPLAY CATEGORY OVERVIEW →" and the redirect templates below it are not shown when clicking on "Page issues" in a redirect page such as Angular units. GeoffreyT2000 (talk) 22:07, 7 November 2015 (UTC)
- Your post is apparently about the difference between the desktop https://en.wikipedia.org/w/index.php?title=Angular_units&redirect=no and the mobile https://en.m.wikipedia.org/w/index.php?title=Angular_units&redirect=no. The redirect page contains
{{redr|from move|from plural}}
which is displayed on the desktop redirect page but not the mobile. {{redr}} uses {{mbox}} which in mainspace adds the classesmetadata
andambox
, both of which are not displayed in mobile as far as I can tell from https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/resources/skins.minerva.content.styles/hacks.less. I find it more odd that the mobile redirect page displays (at least for me in Firefox on Windows Vista) a cut off version of File:Angle measure.svg, the first image on the redirect target Angular unit. PrimeHunter (talk) 23:15, 7 November 2015 (UTC)
Mickopedia
When viewing a page such as Mickopedia on Mickopedia (see e.g. [11]) in Internet Explorer, it says that it is HTTP 403 Forbidden because it requires you to log in. GeoffreyT2000 (talk) 23:58, 7 November 2015 (UTC)
- Wikipedia has nothing whatever to do with Mickopedia, and it is very unlikely that anybody here can answer any technical questions about it. --ColinFine (talk) 00:14, 8 November 2015 (UTC)
- I'm also unable to access any tested pages at the site except http://mickopedia.stroma.org. There are lots of Wikipedia:Mirrors and forks with no association to the Wikimedia Foundation which runs Wikipedia. The sites may break, close or restrict access at any time with nothing we can do about it. PrimeHunter (talk) 01:07, 8 November 2015 (UTC)
I keep wishing there were a way to "upvote" edits.
A way to add a very quick "thank you" note in the edit log, rather than having to add a note to a talk page somewhere. The big application is when someone corrects a mistake, or otherwise improves an edit I made, and I want to show that I've seen and approve of the correction. Basically, it would
- Provide warm fuzzies to editors in smaller doses than barnstars. New editors, in particular, might find it very reassuring and motivating.
- Demonstrate consensus agreement with an edit, as opposed to having to infer it from the absence of additional edits.
- Show that someone is paying attention to this page.
If I and another editor are going back and forth over something and they create a version that we agree on, I'm happy when I find a lingering small typo just so I can add an edit log entry giving thanks for the previous edit. Everyone can then see our "edit battle", capped with a final edit by one of us which the other approves of.
Even bots could use the feedback for algorithm training. "Yes, that really was vandalism, good catch."
Another application would be in watchlists and contributions pages, an "edits since the last one you upvoted".
(Yes, I know this would be a huge change to MediaWiki.) 71.41.210.146 (talk) 04:17, 8 November 2015 (UTC)
- Registered users have an easy way to thank each other for specific edits without making a new edit. See Wikipedia:Notifications/Thanks. An IP address can be shared by many users and one user can have many IP addresses so the system is limited to registered users. PrimeHunter (talk) 04:28, 8 November 2015 (UTC)
-
- Nifty! I never knew about that. I was imagining a more public version, where third parties could see the thanks. Basically A makes an edit *and B concurs*. (You'd presumably only list two or three explicitly before collapsing to a number.)
- I confess I have no idea why IP address confusion constitutes a reason to limit use of the Thanks system any more than it limits use of user talk pages. 71.41.210.146 (talk) 05:49, 8 November 2015 (UTC)
- It's part of a larger feature Wikipedia:Notifications which is limited to registered users although some of the parts could also be done for IP's with some confusion. One reason for not doing it may be that thanks are less important than user talk discussions so there is less willingness to accept confusion over IP addresses. Also, the current Notifications system can deliberately only be seen by the user. If an unregistered user changes IP address then they would completely lose access to Notifications to the old IP address, while they can still view its user talk page if they know the IP address or can find it in a page history. PrimeHunter (talk) 06:08, 8 November 2015 (UTC)
Lowercase title
Template:R from Java package name displays a lowercase "r", even though it has {{lowercase title}} within includeonly tags. See Template talk:Lowercase title#.3Cincludeonly.3E.7B.7Blowercase_title.7D.7D.3C.2Fincludeonly.3E_doesn.27t_work. GeoffreyT2000 (talk) 15:46, 8 November 2015 (UTC)
- As I asked there, why is it a problem? --Redrose64 (talk) 16:02, 8 November 2015 (UTC)
- It happens because it transcludes itself. It could be avoided by testing wether
{{PAGENAME}}
isR from Java package name
but I fail to see a problem needing a fix. PrimeHunter (talk) 17:08, 8 November 2015 (UTC) - There was more potential for confusion at Wikipedia:Template messages/Redirect pages which displayed "template" in the title so I have used {{main other}} to only apply lowercase in mainspace.[12] PrimeHunter (talk) 17:34, 8 November 2015 (UTC)
Article patrolled twice
Hi, I created the article Roan Allen a while back. It was originally patrolled by Wgolf. A few minutes ago, I got a notice that it was patrolled by Eeekster. I have no idea how this happened. I had always thought, one new article, one patrol. How did it show up on new pages feed or wherever? Are all my articles going to have to be patrolled again (which seems like a waste of time)? Or was it the random page patrol? White Arabian mare (Neigh) 23:55, 8 November 2015 (UTC)
- I'm not exactly sure what you mean by "patrolled", because User Wgolf does not show up in the edit history. Did he click that notice that says "mark this as patrolled"? It looks to me like User Eeekster tagged it for bare URLS. New articles appear on all kind of of links. On the left-hand side of the article click on "What links here", and you'll see what I mean. People look at new articles for all kinds of reasons, and they edit an article, tag it in this case, wherever they feel the need arises. Hope this helps. — Maile (talk) 00:07, 9 November 2015 (UTC)
-
- He clicked the "mark this page as patrolled" tab, I guess. I got a notification that said "User:Wgolf patrolled Roan Allen". Anyway, somebody else removed the tag and filled in the bare URLs with Refill. White Arabian mare (Neigh) 00:22, 9 November 2015 (UTC)
- @White Arabian mare: There's only one entry in the patrol log. @Maile66: to find that, go to the page history, at the top click View logs for this page, in that select "Patrol log" in the first dropdown and click Go. --Redrose64 (talk) 09:09, 9 November 2015 (UTC)
- He clicked the "mark this page as patrolled" tab, I guess. I got a notification that said "User:Wgolf patrolled Roan Allen". Anyway, somebody else removed the tag and filled in the bare URLs with Refill. White Arabian mare (Neigh) 00:22, 9 November 2015 (UTC)
Looks like it was some kind of computer or system error then. I know I got two patrolled notices. Thanks, White Arabian mare (Neigh) 15:46, 9 November 2015 (UTC)
Stop hiding the instructions when a user creates a page
How many users ever see the advice and instructions given at the top of the page when they go to create a page? In the browser, as soon as the page displays, it scrolls up so that the content entry area is at the top. Should this behavior be eliminated? —Largo Plazo (talk) 01:49, 9 November 2015 (UTC)
- It doesn't scroll for me. What is your browser, how do you create articles, and what is the url at the time? When I create articles by clicking a red link like Title of article, the top says "Creating Title of article" in big bold, and the url is https://en.wikipedia.org/w/index.php?title=Example_page&action=edit&redlink=1 with no anchor and no scrolling in my Firefox. PrimeHunter (talk) 02:03, 9 November 2015 (UTC)
-
- Suppose I search for "Blah de Blah". The search results tell me "You may create the page "Blah de Blah", but consider checking the search results below to see whether the topic is already covered." When I click the red link, I'm at https://en.wikipedia.org/w/index.php?title=Blah_de_Blah&action=edit&redlink=1. The editing toolbar is at the top of the viewport. I get the same result in both Chrome and Firefox on Windows 7, and I got the same result when I clicked your Example_page link. I'm using the Vector skin. —Largo Plazo (talk) 02:10, 9 November 2015 (UTC)
- Have you enabled wikEd at Special:Preferences#mw-prefsection-gadgets and is wikEd active with a yellow pencil icon in the top right corner? PrimeHunter (talk) 02:21, 9 November 2015 (UTC)
- Yes and yes, except that the pencil's black and white, not yellow. —Largo Plazo (talk) 02:33, 9 November 2015 (UTC)
- OK. wikEd scrolls for me as you describe but only when it's active with a yellow pencil. Try to also disable it at Gadgets. Do you scroll if you log out and click Draft:Blah de Blah? Unregistered users cannot create mainspace pages so Blah de Blah cannot be tested. How about when you are logged in and click . I guess you haven't changed account settings there. PrimeHunter (talk) 03:54, 9 November 2015 (UTC)
- Yes and yes, except that the pencil's black and white, not yellow. —Largo Plazo (talk) 02:33, 9 November 2015 (UTC)
- Have you enabled wikEd at Special:Preferences#mw-prefsection-gadgets and is wikEd active with a yellow pencil icon in the top right corner? PrimeHunter (talk) 02:21, 9 November 2015 (UTC)
- Suppose I search for "Blah de Blah". The search results tell me "You may create the page "Blah de Blah", but consider checking the search results below to see whether the topic is already covered." When I click the red link, I'm at https://en.wikipedia.org/w/index.php?title=Blah_de_Blah&action=edit&redlink=1. The editing toolbar is at the top of the viewport. I get the same result in both Chrome and Firefox on Windows 7, and I got the same result when I clicked your Example_page link. I'm using the Vector skin. —Largo Plazo (talk) 02:10, 9 November 2015 (UTC)
Helping page creators get title capitalization correct
I have never ceased to be amazed at the number of biographical articles created about people with names like "First middle last", even though, in the lead sentence, they magically become "First Middle Last". :-) I suppose that's because editors start by searching for the names, entering them in lower case as I suppose people do when searching, to see whether an article already exists. When told that an article doesn't exist and offered the chance to create one, they go ahead without noticing that the article that they're about to create is cased incorrectly. I wonder if we can warn them prominently at the time when they're about to create the article. Maybe the page creation view can include a field that displays the name as currently entered, and gives them a chance to change it right there in place? Regarding either of those options, however, note the section I began immediately above this one, where I note that page creators don't see the instructions anyway, and asking if that can be fixed. —Largo Plazo (talk) 01:57, 9 November 2015 (UTC)
- I'm unsure about the techno stuff, but I'll give you the way I create new pages; by writing their correct titles on my userpage and then clicking the redlinks! 😉 I think that what you are saying about the search fields does happen all the time though, or else some people may get in a hurry or get excited. It depends on the user. White Arabian mare (Neigh) 02:03, 9 November 2015 (UTC)
- In any case it is trivial for a new page patroller or other experienced editor to move the page to the correct title, so I don't see this as a major issue. DES (talk) 03:02, 9 November 2015 (UTC)
- It is a problem for users who create an article very soon after registering, as even though they can create pages, they can't move them until they are autoconfirmed. In my opinion, the best fix for this would be a new MediaWiki extension that automatically checks articles as they are being created to root out problems like a lack of references, promotional wording, and yes, problems with the title. This would take some time to develop, even if the the resources were allocated for it, which they aren't at the moment as far as I'm aware. But as a stopgap solution we could add title detection to MediaWiki:Newarticletext and output a big warning message for titles of more than one word where all the words apart from the first start with lowercase letters. (The problem being that with this approach it is very hard to work out which titles are names of people and which aren't.) — Mr. Stradivarius ♪ talk ♪ 07:37, 9 November 2015 (UTC)
- Is this really such a big problem ? I mean we just move the article at some point and done.. As opposed to potentially scaring away people with yet more big warning messages.. —TheDJ (talk • contribs) 07:41, 9 November 2015 (UTC)
- Well, yes and no. The biggest problem that I've noticed is that instead of waiting for someone else to come along and move the article, new users will often start a new article with the same content at the correct title, resulting in a cut and paste move. On the other hand, there are bigger problems on WP, and having a big bold warning might well be overkill. — Mr. Stradivarius ♪ talk ♪ 10:03, 9 November 2015 (UTC)
- Is this really such a big problem ? I mean we just move the article at some point and done.. As opposed to potentially scaring away people with yet more big warning messages.. —TheDJ (talk • contribs) 07:41, 9 November 2015 (UTC)
- It is a problem for users who create an article very soon after registering, as even though they can create pages, they can't move them until they are autoconfirmed. In my opinion, the best fix for this would be a new MediaWiki extension that automatically checks articles as they are being created to root out problems like a lack of references, promotional wording, and yes, problems with the title. This would take some time to develop, even if the the resources were allocated for it, which they aren't at the moment as far as I'm aware. But as a stopgap solution we could add title detection to MediaWiki:Newarticletext and output a big warning message for titles of more than one word where all the words apart from the first start with lowercase letters. (The problem being that with this approach it is very hard to work out which titles are names of people and which aren't.) — Mr. Stradivarius ♪ talk ♪ 07:37, 9 November 2015 (UTC)
- Trivial but also just a nuisance for something that could possibly be avoided. As for scaring new users off with warnings, it might be interesting to learn how many people have been disturbed to realize that the title of their new article is written incorrectly and worried that it would be irreversible. Then we could ask which is the better way to jar users. —Largo Plazo (talk) 10:46, 9 November 2015 (UTC)
- In any case it is trivial for a new page patroller or other experienced editor to move the page to the correct title, so I don't see this as a major issue. DES (talk) 03:02, 9 November 2015 (UTC)
As helpdesk and OTRS agents can attest, there are quite a few messages from new editors who've managed to figure out some of the basics of editing and assume, incorrectly but understandably, that they should be able to edit the title as well. Many spend some time trying to figure it out and then reach out to the help desk or an email to OTRS in frustration. It would be nice if there were a better solution. However, the suggestion to "one them prominently" raises a red flag. We have lots of prominent warnings and I'm not excited about creating yet another one.
I have another thought although I can identify a problem with it; maybe somebody can resolve. If we change the suggestion to:
Click "First Middle Last" or "First middle last" to create an article with that name
they will almost always choose the first one.
The obvious problem is that if we offer them "Guinea Pig" and "Guinea pig", they are likely to choose the first, which would be wrong. If we knew a simple rule for identifying names of humans, we might be able to come up with a workable role for suggesting alternatives.--S Philbrick(Talk) 14:46, 9 November 2015 (UTC)
- We can't restrict the set of choices because then they wouldn't have any way to create Guy de Maupassant, Honey in the Rock, De Polignac's conjecture, etc. —Largo Plazo (talk) 14:58, 9 November 2015 (UTC)
- The suggestion was only where all the searched words apart from the first start with lowercase letters. PrimeHunter (talk) 16:06, 9 November 2015 (UTC)
Contents of big Categories
The webpage https://en.wikipedia.org/wiki/Category:Human_name_disambiguation_pages?from=E shows Aa, Ab, Ac, Ad, Ae etc in its Contents. Should not it show Ea, Eb, Ec, Ed, Ee etc?SoSivr (talk) 13:03, 9 November 2015 (UTC)
- The large TOC is not a MediaWiki feature but made with {{Large category TOC}}. That limits what is possible but I have made a test version at User:PrimeHunter/sandbox5 with anchors. I added it to Category:Human name disambiguation pages below the normal version. In my Firefox, the anchor link scrolls the long TOC line so the right end is placed at the anchor. I therefore placed each anchor letter at the end of the sublist for that letter. It seems unavoidable that browsers will scroll vertically to place the whole sublist at top of the page. A large TOC could be placed higher on the category page if we want more of the leading category text to be visible after this scrolling. If we want the short TOC line to remain visible then it must be moved or copied below the scrolling TOC line. If we copied it then we could keep the original functionality (going to top of the page with no scrolling in either direction) in one version and the new in the other. This test version certainly has some disadvantages but I don't know how to do better with the available features. PrimeHunter (talk) 15:48, 9 November 2015 (UTC)
- Note the alternative {{Large category TOC 2}} which avoids horizontal scrolling by allowing line wrapping. The long TOC line is kept shorter for this reason, with five subentries for each letter instead of 26. Five may be OK on Category:English footballers with 17000 pages. 26 would probably be better for Category:WikiProject California articles with 52000 pages. PrimeHunter (talk) 16:00, 9 November 2015 (UTC)
- There is a good reason for not changing the behaviour of templates like
{{LargeCategoryTOC}}
- regardless of how far through the category you have got, you always have a quick link to an earlier stage, so it would be wrong to suppress the Aa-Dz links if you were currently viewing E. --Redrose64 (talk) 20:24, 9 November 2015 (UTC)
- There is a good reason for not changing the behaviour of templates like
Tech News: 2015-46
17:19, 9 November 2015 (UTC)
Community Wishlist Survey
Hi everyone!
The Community Tech team at the Wikimedia Foundation is focused on building improved curation and moderation tools for experienced Wikimedia contributors. We're now starting a Community Wishlist Survey to find the most useful projects that we can work on.
For phase 1 of the survey, we're inviting all active contributors to submit brief proposals, explaining the project that you'd like us to work on, and why it's important. Phase 1 will last for 2 weeks. In phase 2, we'll ask you to vote on the proposals. Afterwards, we'll analyze the top 10 proposals and create a prioritized wishlist.
While most of this process will be conducted in English, we're inviting people from any Wikimedia wiki to submit proposals. We'll also invite volunteer translators to help translate proposals into English.
Your proposal should include: the problem that you want to solve, who would benefit, and a proposed solution, if you have one. You can submit your proposal on the Community Wishlist Survey page, using the entry field and the big blue button. We will be accepting proposals for 2 weeks, ending on November 23.
We're looking forward to hearing your ideas!
MediaWiki message delivery (talk) 21:30, 9 November 2015 (UTC)