This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Interestingly, SMcCandlish's comment is CSS fix (plainlist applies to list elements, not divs...). However, the the CSS quoted above means "lists that are inside plainlist wrappers," not "lists that are plainlists." So either the pre-edit usage was correct (and the comment is not) or site CSS needs to be changed from .plainlist ol, .plainlist ul to ol.plainlist, ul.plainlist. FWIW, the value of the existing CSS is that you don't have to use explicit <ol>, <ul>, and <li> tags. You can just use normal wikitext (* or #), and still the styling would apply to the generated lists. --Unready (talk) 20:06, 3 February 2017 (UTC)
Hello! I created a new user script for converting article references to list-defined format. It's called References Consolidator. It's code is partially based on ProveIt, but it's interface is much simpler. I have tested it extensively in my home Wikipedia (Estonian Wikipedia), haven't tested it much here yet. Just tried on a couple of pages, and everything worked correctly. It is easily portable to other wikis, since it's configuration is in a separate file and the main file is wiki-agnostic. I'm not a native English speaker, so I'm not sure if the script's name and it's few interface messages sound natural and logical to a native English speaker. I'm open to suggestions.
About the script: tried to keep it very simple, yet flexible. It's functionality is similar to User:PleaseStand/References segregator, but it does not have any intermediate steps where user has to input something. That means you don't get to choose reference names, these are assigned randomly. But there are already other tools for renaming references, like ProveIt. It's flexibility means that References Consolidator works correctly with multiple {{reflist}} templates on a page – this is something that I haven't seen any other script that works with references do, even ProveIt does not do that yet.
@The Quixotic Potato: Thanks! I saw the warning but thought that {{subst:iusc}} is the standard way for user scripts in English Wikipedia. Changed it to:
Parameter default is ignored when separate parameter is defined?
I created a template over at wikispecies (species:template:Au), and it's causing me a headache. I'm using an #ifexist: check on {{FULLPAGENAME:{{{1}}} {{{2}}}}} to generate a link to pages. I'd like that check to fail if parameter 1 is undefined (parameter two alone will usually generate a link to a disambiguation or redirect page), so I (quite sensibly in my opinion) set a nonsense default to parameter 1: {{FULLPAGENAME:{{{1|unlink}}} {{{2}}}}}.
This is where my problems start. This expression correctly generates the string "unlink" but only as long as parameter 2 is undefined. The default for parameter 1 is completely ignored if parameter 2 is set (as can be seen in fourth "base use" example), and I have no idea what could possibly cause this to happen. I've never used FULLPAGENAME before (it's been a LONG time since I meddled around in this sort of templating), but I don't see why that should be an issue... Circéus (talk) 12:30, 4 February 2017 (UTC)
In your test call {{au||Darwin}}, parameter 1 is not undefined. It is set to the empty string so {{{1|unlink}}} evaluates to empty. It only evaluates to unlink if parameter 1 is undefined, for example in {{au}} or {{au|2=Darwin}}. If parameter 1 is undefined then {{{1}}} evaluates to itself, i.e. that exact 7-character string. You can use that. PrimeHunter (talk) 13:21, 4 February 2017 (UTC)
https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php says $wgExpensiveParserFunctionLimit = 500; That means it's 500 for all Wikimedia wikis. I have verified it be previewing #ifexist calls at wikispecies. It produces: "Warning: This page contains too many expensive parser function calls. It should have less than 500 calls, there are now 501 calls." Exactly 500 is allowed so "less than 500" is a little imprecise, at least with the standard mathematical definition. PrimeHunter (talk) 13:33, 4 February 2017 (UTC)
Thank you for pointing what should have been obvious to me <<;;. And for the Parserfunction answer. 500 should be _more_ than enough for what we need on Wikispecies. Circéus (talk) 13:43, 4 February 2017 (UTC)
Section-templates don't show on mobile
Here I found that section-templates. such as {{Expand section}}, don't show on mobile.
I can see the note neither on the mobile version of Wikipedia nor the mobile app. Article hatnotes seemed to always show fine - for them it says "Page issues" (which can be shown/expanded by a click on it) - hence for sections it should say "Section issues". User:Redrose64 said that this would be due to Module:Message box using the metadata class, which is "always hidden in mobile".
Whatever the issue is here - please fix it ASAP! Mobile users should also be able to see section-templates, it probably means that there needs to be an alternative way for doing whatever the metadata class was hidden for - however an exception or alike might work as well. Not sure if I should make a phabricator ticket for it.
As I write the only article in Category:Pages with script errors is Mlle Raucourt. Visiting it to see if there’s any problem I can’t see any, and the category is not listed among the article’s category. None of that is unusual as it takes anything from seconds to days for the category to be updated after article changes. As the article has not changed recently it’s probably a template that was temporarily broken.
But I decide to edit it, to see if I can spot any potential sources of problems, such as unprotected templates. Simply editing and hitting preview lists all the templates (and categories) below.
I tried this on another article a couple of days ago and saw the same thing. Categories appearing which made no sense even when there is no content. No recent changes to the article or templates that I can see that might be causing it. The article is OK, so there is nothing to fix in the content but it seems something is broken in the preview mechanism.--JohnBlackburnewordsdeeds20:42, 5 February 2017 (UTC)
It appears that the list of hidden categories is always taken from the saved page, as compared to the list of templates which is taken from the saved page on the initial load of the edit page and from the preview on preview. Anomie⚔21:26, 5 February 2017 (UTC)
Thanks. I only looked for previous reports on this page (thinking it was a new problem), and did not think of Phabricator. Added myself there, nothing to do here.--JohnBlackburnewordsdeeds22:22, 5 February 2017 (UTC)
Developer Wishlist Survey: Vote for Proposals
Almost two weeks ago, the Technical Collaboration team invited proposals for the first edition of the Developer Wishlist survey!
We collected around 77 proposals that were marked as suitable for the developer wishlist and met the defined scope and criteria. These proposals fall into the following nine categories: Frontend, Backend, Code Contribution (Process, Guidelines), Extensions, Technical Debt, Developer Environment, Documentation, Tools (Phabricator, Gerrit) and Community Engagement.
What happens next?
Proposals that will gather most votes will be included in the final results which will be published on Wednesday, February 15th. These proposals will also be considered in the Wikimedia Foundation’s annual plan FY 2017-18 - SSethi_(WMF) (talk) 04:41, 6 February 2017 (UTC)
Conditional expression for detecting a redirect?
Similar to {{#ifexist for detecting the existence of an article, is there something to detect whether a page is a redirect? I searched in the help pages but found nothing. (This sort of thing will useful at User:Aymatth2/SvG clean-up/Race walkers - to see which pages are still in draft: and which have moveed to mainspace.) 103.6.159.78 (talk) 14:23, 6 February 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
The block log sometimes showed blocks as being much longer than they were. This has now been fixed. [1]
Changes this week
Wikimedia pages will now be better at showing pictures when you share them on social media. The descriptions will be different too. You can see an example of before and after. [2]
There are some changes to the OOjs UI. Some old functions will not work anymore or not work as they used to. This could be a breaking change. [3]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 February. It will be on non-Wikipedia wikis and some Wikipedias from 8 February. It will be on all wikis from 9 February (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 7 February at 20:00 (UTC). See how to join.
Future changes
Tidy will be replaced later this year. Instead, the HTML 5 parsing algorithm will be used to clean up bad HTML in wikitext. This will cause problems on a number of wikis. They need to be fixed first. You can see if your wiki still has something to fix here for one of the HTML problems. This list does not cover all problems. You can read about more problems. [4][5]
How to filter user contributions for newer than a date
Special:Contributions has menus to view only "From year (and earlier)" and "From month (and earlier)". Is there a way to do the opposite, that is, only see edits from some year/month to present? I like to look at recent activity when thinking about blocking an IP-vandal to weigh collateral damage (any recent good edits), and other checks of recent range abuse. DMacks (talk) 16:50, 6 February 2017 (UTC)
You can for example start with earlier than a date and click "newer 50". &limit=n in the url will show n entries for n up to 5000. PrimeHunter (talk) 22:15, 6 February 2017 (UTC)
I'd like to create a function to calculate the moon phase on a given date.
The logic that sprang to mind was:
(a) note the date of known full moon
(b) convert that date to days-since-some-epoch
(c) take the target date and convert that to days-since-some-epoch
(d) the difference modulo 29.530588853 gives me the number of days since the last full moon, from which I can estimate the phase.
I've hunted up and down categories, templates, articles but haven't found anything for days-since-epoch (or seconds-since-epoch). Can you point me in the right direction, please? Scarabocchio (talk) 21:57, 6 February 2017 (UTC)
I propose to add my responsive content style sheet as a gadget to our preferences. It gives additional styling rules to bring much of the responsiveness of the mobile website, to Vector and at the same time also gives some nice improvements to users of wide screens (like 27" iMacs), by moving images and infoboxes into sidebars, enlarging the font size and limiting the width of the content for those specific users.
It is part of my effort to explore bringing back some of the enhancements of mobile back into the core of the software, and I've given a short presentation about it recently. Note that the demonstration includes changes to both the content and the layout of Vector, but the gadget i'm making available here would only effect the content area. (A complete Vector gadget might follow later at some point, but is more complicated).
My hope is that by having this gadget, it will be easier for editors to experience what content looks like on mobile screens. Those who want to try it right now, can add
to their JS files (note that you will get a styling flash because of this, which is one of the reasons I want to make this available as a pure CSS gadget). —TheDJ (talk • contribs) 15:29, 7 February 2017 (UTC)
I broadly support this—layout improvements are worthwhile. That said, as a Gadget it should probably be marked experimental; trying it on TFA Johnson Creek (Willamette River) I saw a {{wide image}} run off the left of the screen as a result of the right-hand gutter (for reference, measured window.innerWidth at about 1400px). We should be clear in Gadgets when they are expected or known to be buggy. More broadly, I'll advocate for T90914, because most of the issues in implementing stuff like this—and this ultimately ought to be default—will run up against wikitext-based hacks ({{wide image}}, {{double image}}, Category:Graphics templates, etc.) for displaying images nicely. We should pre-empt some of those issues by improving the underlying markup. {{Nihiltres |talk |edits}}16:06, 7 February 2017 (UTC)
Have you tried ? I'm guessing most people won't even experience this, unless they have a rather large screen. Also, I don't intend to put all these changes into core at the same time, definitely not potentially controversial ones like sidebars. My preference would be to have sidebar markers be emitted by the parser actually, and then have the skin, or skin settings determine how to present that. But that's all way out there into the future as far as I'm concerned (I have very little time for this). —TheDJ (talk • contribs) 16:51, 7 February 2017 (UTC)
@Nihiltres: I'm specifically doing this in a gadget in this phase, because I want to find things like wide-image, before even attempting to do this in core and having to go into a 1 year back and forth with community. —TheDJ (talk • contribs) 16:51, 7 February 2017 (UTC)
@TheDJ: Yes, I understand and think that's a great approach. My point's only that it should be marked as experimental so that users know what to expect when enabling it. I'll still emphasize T90914, of course: better, more semantic image markup could resolve many of the potential problems before or as they arise. {{Nihiltres |talk |edits}}17:03, 7 February 2017 (UTC)
Yeah i have no problem with that. It's working surprisingly well in 99% of the cases though. If you consider how 'dirty' this hack actually is, I was expecting many more issues with it. —TheDJ (talk • contribs) 17:07, 7 February 2017 (UTC)
@TheDJ: I don't think it's necessary to put that line on a user's JS page, if they instead add this line
@Redrose64: I think that doesn't reliably work. All your user stylesheets get concatenated, and there is nothing making sure that the final stylesheet has these all these import's at the top as far as I remember. As such it is probably safer to test with JS loading. —TheDJ (talk • contribs) 16:51, 7 February 2017 (UTC)
I have a question about using Template:CSS image crop. It is a very useful template for displaying large maps, and I have used it on several articles. At Port Anderson, Mississippi, I used it in the infobox (where it must be center-justified to display properly). At Mound Landing, Mississippi and at Christie Street, I added it to the article. My question is: is there an easy way to set up this template? Finding the exact "oTop" and "oLeft" coordinates is entirely by trial and error. To do this, I load the template into my sandbox, start with a very small "bSize", and then slowly increase the bSize as I manipulate the oTop and OLeft to find the exact spot on the image I am looking for. This can take a very long time when manipulating a large map. Is there a tool or a trick for easily finding the coordinates? Does this meet the definition of a First World problem? Thanks! Magnolia677 (talk) 12:50, 8 February 2017 (UTC)
Note that you are forcing every visitor of Mound Landing, Mississippi, to download a 2440px by 9363px image of almost 5MB, and I don't think that is reasonable. If you have an old phone, that will basically cause it to freeze up and require a reboot of the device. —TheDJ (talk • contribs) 13:30, 8 February 2017 (UTC)
Lack of geographical coordinates in the exported pdf webpages
Hello everybody. I just joined Wikipedia as a user, so please forgive me in case I am not reporting this the right way or in the right place. I am currently saving some Wikipedia webpages as pdf files (using the tool "Download as PDF" in the "Print/export" section) to store for future reviews. The pages I am saving are related to geographical locations, therefore the coordinates usually reported in the top-right corner of the page are really useful. However, I noticed that in the pdf version of the Wikipedia page, the coordinates are omitted.
Am I the only one who thinks this would be a nice feature to implement (and most probably not that difficult to implement for the programmers)? Would it be possible, in the future, to modify the exporting tool to include them? — Preceding unsigned comment added by Tommasosacco (talk • contribs) 15:45, 8 February 2017 (UTC)
Ranking articles in a certain category by number of incoming wikilinks?
Hi! Does anyone know if there is a tool that lets you rank Wikipedia articles that are in a certain category according to how many other Wikipedia articles link to them? I'm looking for a method that is easier than going into the "What links here" page for each individual article in a category and manually filling the data into a spreadsheet. --Dodi 8238 (talk) 09:16, 8 February 2017 (UTC)
Can we get an accurate estimate of how many users were affected and not the heretofore incorrect "all the spam systems out there from blocking us"? It's pretty irritating to now have every email display as from "Wikipedia". --NeilNtalk to me23:25, 8 February 2017 (UTC)
Extraneous spaces in edit requests
Hey all, weird question. I notice that the grand majority of the time, when a user submits an edit request to a talk page, like here or here, an extraneous space often appears before the user's signature. Any idea why this could be? Terribly anal of me, I know, I'm just curious cuz the resulting signature-in-a-box irritates the crap out of me. Thanks, Cyphoidbomb (talk) 17:56, 7 February 2017 (UTC)
Those two pairs of braces terminate a {{subst:trim}} and a {{subst:^}} and if nothing is entered, they substitute to nothing - and the next character is a space, which ends up at the start of a line, with the signature following it. --Redrose64 🌹 (talk) 18:12, 7 February 2017 (UTC)
@Msuxg: This is because the original has a lot of 'noise' pixels around the letters and such. This will confuse the scaling and sharpening algorithms slightly, resulting in soft edges in the small thumbnails (especially with JPG). Either cleaning up the original manually, or finding an original without compression or scanning artefacts is your best bet to improving this. —TheDJ (talk • contribs) 11:45, 9 February 2017 (UTC)
The large original has only slight quality issues, and the problems are all scaling artefacts. It will help if you resize the image to something near the display size required on the article page and upload it again at that size. Fair-use images should be low-res anyway. William Avery (talk) 12:22, 9 February 2017 (UTC)
Hello all, I was wondering if you could offer some help with how to add a status, "phone", to the above. My current js is here, and the source code for original is here. I have attempted to add the status "phone" by way of making the same additions as Kraftlos did to add sleep, but this has not worked. -- IazygesConsermonorOpus meum14:16, 9 February 2017 (UTC)
You didn't say what the problem is. I guess it is that User:Iazyges says "Status: Unknown" when User:Iazyges/Status says "sleepphone". What others see has nothing to do with your JavaScript files which run in your own browser and only affects what you see and can do. User:Iazyges uses {{Statustop}} which doesn't recognize "phone" so that value in User:Iazyges/Status isn't going to work unless you modify or don't use {{Statustop}}. The documentation shows it can redefine what is displayed for "sleep" so you could use "sleep" to display "Phone" with {{Statustop|link=User:Iazyges/Statuses|sleep=Phone}}. This would mean you can no longer display "Sleeping", but offline and away would still be available. Your script is only a fancy way to change the value in User:Iazyges/Status instead of manually editing it. If you keep using the current {{Statustop}} then there is no reason for a script to place "phone" in User:Iazyges/Status. PrimeHunter (talk) 17:59, 9 February 2017 (UTC)
Revision History Statistics
Anyone know how to get the revision history statistics? You used to be able to click on "Revision history statistics" on the Revision history screen but this has been replaced with a "Wikihistory" page of very limited use. Anyone know how to access the old version? Hawkeye7 (talk) 03:28, 9 February 2017 (UTC)
Yes, ditto from me. A while back we used to get the pie chart filled in with % edits by user for the current version of an article (which is more relevant than the list of number of edits made by each user going back ten or more years). I found this very useful when coming to an article for the first time and being able to check who were the major contributors so far, with a view to perhaps notifying them if I planned to completely rewrite the article. JG66 (talk) 03:41, 9 February 2017 (UTC)
Specifically, this presumably relates to a page like Cody Strong. New pages are not allowed to be indexed until they have been reviewed as part of Wikipedia:New pages patrol. There are currently 14,950 unreviewed pages.. 2596 pages were reviewed this week, so it might take a couple of months before someone comes across it so it can be indexed. -- zzuuzz(talk)20:38, 9 February 2017 (UTC)
Note there is also a timer on these - if the patrolling goes ignored long enough they will start becoming indexed anyway. — xaosfluxTalk21:00, 9 February 2017 (UTC)
You need to click show patrol log to view the patrol log in logs. The info page saying that indexing is allowed is incorrect, it's a bug, I've made a task for this: phab:T157747. Cenarium (talk) 03:05, 10 February 2017 (UTC)
Indeed there are a couple of bugs affecting moving and patrolling, such as not leaving a log entry when moved, mostly because we can't patrol moves in MW core (phab:T98617). Cenarium (talk) 16:36, 10 February 2017 (UTC)
Wrong colors in upcoming featured image
I'm running Fedora 23 Linux with Firefox 50.1.0. When I open a certain upcoming Featured Picture of the Day, namely Template:POTD/2017-02-16, the thumbnail displays with the wrong color palette—the beige background becomes magenta, the black becomes cyan, and most of the rest is either cyan or magenta also. Same if I click through to the image's own page File:Fromental Halévy, L'Éclair score cover - Restoration.jpg and view the full image or any of the other available sizes. (If I download the image file and open it with xv or okular, it looks normal.) Looking at the file history on the image's page, I see that all the earlier versions appear correctly and there is a comment "+ color profile" on the newest one. Presumably this "color profile" is what's making it not work for me, but this is beyond my knowledge of how JPGs work.
I remember reporting a similar problem with an image once before (I would have been using a different IP address at the time), but I don't remember how it was resolved. Considering that we're talking about a Featured Picture of the Day and that Firefox is not exactly a nonstandard tool, I think there's a case for fixing the problem even if the image is technically correct. --76.71.6.254 (talk) 22:09, 9 February 2017 (UTC)
Added note: I was going to plant a courtesy pointer to this posting on who last edited the image file, but if I've found the the right one, it's semi-protected both on Wikipedia and on Commons, so I can't. --76.71.6.254 (talk) 22:17, 9 February 2017 (UTC)
For some reason, on mobile view I see the top header, then the one about the breeds infobox, and...nothing. The additional threads below don't show up separately but as a part of that one. What's wrong? White Arabian FillyNeigh22:54, 10 February 2017 (UTC)
Since December 16, 2016, Cyberbot I has been continually cleaning template sandboxes without other activity taking place. That has been reported here and here to the bot operator, who thinks it's the fault of the mediawiki software but isn't sure which projects to address at Phabricator. Dhtwiki (talk) 22:29, 10 February 2017 (UTC)
If there is no content change, it's a null edit, and is not normally recorded in the page history, the user's contributions, etc. The fact that it is being recorded implies that the MediaWiki software is not treating it as a null edit. My guess is that the page contains some strange character which is not being overwritten, so it doesn't show in the diff. There was a case a few years back where redirects had been created with a double newline at the end, and a null edit removed the second newline - but the diff showed no change. --Redrose64 🌹 (talk) 00:20, 11 February 2017 (UTC)
Original sizeScaled thumbnailScaled thumbnail at 199px
Am wondering if a tech person can help fix an animated gif that doesn't animate until clicking on the image (at the resulting image info page, it anmates fine). There are similar gifs by the same creator that animate fine in articles and don't require going to the image info page for it to animate. The gif creator (Commons user) hasn't edited since 2014, so probably no help there. Please advise if there is more appropriate board for this. Ok, --IHTS (talk) 01:20, 10 February 2017 (UTC)
Yes! Could you please do the same thing (purge) for one more? (The other chess piece gifs work fine, only the queen & knight had size limitation problems.) Thank you! Scaled thumbnail --IHTS (talk) 12:10, 10 February 2017 (UTC) p.s. (ping) TheDJ --IHTS (talk) 21:11, 10 February 2017 (UTC)
Redrose64, thx, but not working for some reason. (Both Commons & WP, went to Preferences, Gadgets, checked box to turn on Purge option, confirmed my skin is default Vector, ... no Purge gadget appears. Logged out & on again, still nothing.) --IHTS (talk) 01:08, 11 February 2017 (UTC)
In Vector, the purge gadget shows as an option in the "More" tab; in MonoBook skin it's a separate tab containing only an asterisk. In both skins, you need to wait for the JavaScript to finish running before it displays reliably. --Redrose64 🌹 (talk) 09:47, 11 February 2017 (UTC)
Inline images on mobile
At Yngvi#The Ingwaz rune there are runes presented inline with the text using images. Presumably this is because many (most?) people don't have fonts for Unicode runes. On mobile, they appear as block elements, even with frameless, which is supposed to force inline style. Bizarrely, it appears correctly in the edit preview! Hairy Dude (talk) 14:50, 11 February 2017 (UTC)
Some special pages like dead end pages update periodically (e.g. every week, month), due to the heavy amount of processing and time to do this (see https://www.mediawiki.org/wiki/Manual:$wgMiserMode). So it will eventually update at some point, see:
The only actionable report here would be correcting the message in the page that erroneously states that the report will not update (and maybe include the next update date) when in reality some special pages in miser mode update at a given interval. — Preceding unsigned comment added by 197.218.83.4 (talk) 15:32, 11 February 2017 (UTC)
For small wikis one can use a tool like dev:CacheCheck. — Preceding unsigned comment added by 197.218.83.4 (talk) 15:48, 11 February 2017 (UTC)
Prose size script bug?
When running User:Dr_pda/prosesize.js on bouncing ball, it stops functioning after the sentence "If Reynolds number is very low (Re < 1), the force on the ball is described by Stokes' law[7]".
If by "it should work" you mean it was working and broke, can you say the last time it did work? If you mean "I would like this changed", follow Od Mishehu's link - Special: pages redirects are called "aliases" when placing a phabricator ticket. — xaosfluxTalk18:31, 11 February 2017 (UTC)
Hi. It seems that the table entitled "Genetics articles by quality and importance" on Wikipedia:WikiProject_Genetics hasn't been updated in several days. That is the only one I'm watching, so I don't know if this problem is unique to genetics or is system wide. Could you please check and/or advise me what to do? I've contemplated changing an assessment on some other project page to see if that updates, and if you suggest that I do, I will. Specifically, there are 230 unassessed articles listed at the genetics site, but it appears to me that the assessment ratings actually do appear on the talk page, but aren't showing on the table. Thanks, DennisPietras (talk) 02:48, 11 February 2017 (UTC)
User:Alligators1974 recently used Checklinks to insert multiple 'dead link' tags into John Key. The edit inserted the tags before the closing </ref> instead of after it. The result is that the tags do not show on a reading of the article. Because Checklinks may be used by multiple editors on multiple articles, this has the potential to become a widespread problem. @Alligators1974:, please stop using Checklinks until this problem is clarified. I would report this to the developer of Checklinks myself but am pressed for time right now. Akld guy (talk) 18:58, 11 February 2017 (UTC)
The map is made with <mapframe>...</mapframe> from mw:Extension:Kartographer. meta:Special:Version and our Special:Version both list Kartographer under Installed extensions, but only meta lists <mapframe> under Parser extension tags. It means <mapframe>...</mapframe> is ignored as a tag here and just displayed as text with the inside rendered as wikitext:
I'm alerted on my talk page to a possible error in Template:Webarchive. The page about it starts "Error in webarchive template: Check |url= value. Empty." There seems to be nothing much to the template other than the invoking of Module:Webarchive (most recently edited by User:Green Cardamom). I have no experience of editing this kind of thing, and so bring up the matter here. -- Hoary (talk) 09:52, 12 February 2017 (UTC)
It's not an error. A template often displays poorly on the template page itself because it doesn't get mandatory parameters, in this case |url=. Some templates are coded to avoid the issue by using <includeonly>...</includeonly> around the template code, or supply example parameters inside <noinclude>...</noinclude>. But this has disadvantages for users who expect the template page to display what a call without parameters would display. I think it's OK that Template:Webarchive does that. PrimeHunter (talk) 11:20, 12 February 2017 (UTC)
Earlier, I went on Special:Book while I was looking around the special page list. I didn't click anything, just opened the page and then left it. However, now, whenever I hover over a wikilink to anything in the article space, I get a little popup with an option to "add the linked wiki page to your book". How do I disable this? — Train2104 (talk • contribs) 05:05, 12 February 2017 (UTC)
Found the disable link, thanks. It's in the sidebar, not obvious at all. Though that's where the link to the special page is, so one could make that argument. — Train2104 (talk • contribs) 14:54, 12 February 2017 (UTC)
color displayed by {{u|example}}
Hi again. I'm an admitedly stubborn and eccentric newbie. When I use the template {{u|example}} "example" appears in a bluish color. There exists some code somewhere that specifies that color. I've tried to look at documentation pages for that template, but can't find the code. I'd like to personalize my "pings" (recall my eccentricity) by specifying a different color. I don't care if there is a paragraph-long code that needs to be used in place of {{u|}}. I would simply save that code in a text document, and when I want to use my personalized "ping", simply copy and paste that into the wiki page (recall that I'm stubborn). Can anybody please give me the wiki code for that {{u|}} template? Thanks, DennisPietras (talk) 17:06, 12 February 2017 (UTC)
The code {{u}} or {{u|...parameters here....}} calls the template at Template:U, in this case a redirect to Template:User link. Click "Edit" or "View source" to see its code. It doesn't add any coloring. It just makes a wikilink to a user page. Some users haven't made a user page for their account. Internal wikilinks are automatically blue if the page exists and red if it doesn't exist. If your browser has visited the link then the color may change a little to indicate this. See more at Help:Link color. It's possible to directly specify the color of links but it must be done inside the link brackets after a pipe. It causes confusion for readers who know the meaning of the normal link colors so please don't do it in pings or most other situations. PrimeHunter (talk) 18:21, 12 February 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
EventStreams is a new way to show activity on Wikimedia wikis. For now it works with the recent changes feed. It will do more things later. It will replace RCStream. Tools that use RCStream should move to EventStreams before 7 July. [10]
Problems
The Firefox add-onFirefogg can cause problems with the Upload Wizard. This will not be fixed, because Firefox will not support Firefogg in the future. The Upload Wizard will no longer work with Firefogg. [11]
Tool Labs and Wikimedia Labs databases will be under maintenance on 15 February. This will start at 17:00 (UTC) and last for about six hours. Some tools could have problems during or after this. [12]
Changes this week
The TwoColConflict extension is a new way to solve edit conflicts. It makes it easier to copy and paste the relevant text to the text field. It will come to Meta and German Wikipedia this week. It is already available on MediaWiki.org. It will come to more wikis later. [13]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 February. It will be on non-Wikipedia wikis and some Wikipedias from 15 February. It will be on all wikis from 16 February (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 14 February at 20:00 (UTC). See how to join.
Future changes
Page Previews will be turned on for logged-out users on the Catalan, Greek, Russian, and Italian Wikipedias in the middle of February. Page Previews shows readers a short part of a linked article when they rest their mouse pointer on the link. This is to help them understand what it is about without leaving the article they are reading. Page Previews used to be called Hovercards. It will come to more wikis later this spring. [14]
@The Transhumanist: I am guessing that your problems are not caused by a lack of dependencies, but rather by the way you are using the localStorage object. According to the docs, you should be using localStorage.setItem('foo','bar'), not localStorage.foo='bar'. If you use the API in a non-standard way I wouldn't be surprised if there were differences between the way the various browsers handle it. — Mr. Stradivarius♪ talk ♪13:18, 12 February 2017 (UTC)
Actually, after some more reading, it seems that the localStorage.foo='bar' syntax is fine (although the setItem syntax is preferred). That link does give some other suggestions as to things that could be wrong, though - localStorage might not be implemented on old browsers, it might be disabled by users, or it might be full. — Mr. Stradivarius♪ talk ♪15:01, 12 February 2017 (UTC)
Also, I would use a unique prefix for your localStorage keys, maybe olutils_ (so the current key would be olutils_redlinks), to reduce the chance of clashes between your data and other localStorage data saved by MediaWiki or by other gadgets. — Mr. Stradivarius♪ talk ♪13:24, 12 February 2017 (UTC)
@Mr. Stradivarius: It had little to do with memory, but your suggestion provided the essential clue. Since I had 2 versions of the script running simultaneously, the second one worked because of data stored locally by the first one. Without that storage there, the second script failed, which became apparent when I customized the localstorage key per your suggestion. Which led me to a bug. I fixed the bug, and the now the second script works on its own. Though there are still some bugs (the menu item has to be clicked again after getting a preview, twice, for it to work, but it does work). Thank you! The Transhumanist00:59, 13 February 2017 (UTC)
@The Transhumanist: Also, all calls to LocalStorage should always be wrapped in a try catch. Localstorage can easily fail due to being full, or due to being in a privacy mode or some other restriction that the browser is placing. —TheDJ (talk • contribs) 07:32, 13 February 2017 (UTC)
I think it's related to mobile editing, probably their browser, or then they accidentally just did something strange. Stryn (talk) 18:06, 13 February 2017 (UTC)
I've come across something like this before, four or five years ago - turned out that somebody had a browser extension that modified certain characters to a different Unicode codepoint. --Redrose64 🌹 (talk) 23:42, 13 February 2017 (UTC)
Querying all articles that reference a particular site/url
Is it possible to create additional magic links? The comments at mw:Requests for comment/Future of magic links make me guess not, but perhaps it's saying that existing ones included in core MediaWiki are unchangeable but not commenting on the idea of adding others. Help:Magic links says that the links are defined by Parser.php, but to my surprise, that page is a 404 error.
Background — I wonder if it would be useful to add one for OCLC numbers (e.g. OCLC 636181190 would produce OCLC 636181190) for the English Wikipedia only, but there's no point in requesting people's opinions in a proposal if it's not possible to implement it here. Nyttend (talk) 02:36, 13 February 2017 (UTC)
Thank you for fix and for response. "require changes to the core MediaWiki software", I wasn't suggesting something that would require that much work (I just wanted the change if we could tweak some local settings), so thank you for preventing a pointless discussion. Nyttend (talk) 03:01, 13 February 2017 (UTC)
It's not really a lot of work (well, minus the localized bit), but it's definitely more than a configuration change. And, as the RFC points out, such feature requests would be denied if they were requested today (for a bunch of reasons outlined there). Lua modules and templates are far more suited to do this (or heck, even some parser functions if such an extension was written) than by the very fragile and inflexible magic link code. ^demon[omg plz]21:01, 13 February 2017 (UTC)
But a major issue at the Meta RFC is that local projects can't modify or exempt themselves from the existing magic links, and if this were just a configuration change, it wouldn't have those issues. Nyttend (talk) 00:04, 14 February 2017 (UTC)
Adding configuration is basically the same problem as adding localisation. If you have a serialisation language, it is really annoying to have arbitrary tokens. That's why developers want to get rid of it. These features are tokens in the parser language, inflexible ones, non-translatable ones, non-configurable ones, now, but especially into the future. There is a reason a template or magic word starts with {{ and that is because it isn't natural language and isn't generally used in natural language. I get that people focus on the usability of such 'magic' links, but this is not the right technical solution. The right usability + technical solution is to have the edit page say "it looks like you are pasting an OCLC number, would you like me to properly format that for you". —TheDJ (talk • contribs) 09:52, 14 February 2017 (UTC)
Oh FFS, don't get hung up on the language. Per the 'community' our developers wouldn't even be smart enough to come up with something like clippy, so why even put it in my brain. What i'm proposing requires as much 'intelligence' as the current magic links require, as much as recognizing [[ and opening the insert link dialog. I gave a playful user story, not a design idea. —TheDJ (talk • contribs) 23:55, 14 February 2017 (UTC)
The time allocated for running scripts has expired
One editor (johnuniq) has taken time to start messing with Cebu and {{Bohol}}. As far as I know, or those messages were abandoned at least 2 years ago when Lua came in. So do the messages have any meaning, and should anything be done? 112.198.102.167 (talk) 00:20, 14 February 2017 (UTC)
This relates to my posts at User talk:Alice Zhang Mengping#Template:PHxxx regarding the "pages with script errors" category (articles). I have not taken any action other than post at the above talk and at Talk:Cebu/Archives/2017/February#Template errors. It was JohnBlackburne who edited Cebu. Viewing the html source for Cebu and searching for "NewPP" currently shows "Lua time usage: 10.046/10.000 seconds". That is the reason the article has numerous error messages ("The time allocated for running scripts has expired") at the bottom. The timing varies presumably depending on the speed and load of the server that renders the page. Sometimes Cebu displays without errors (because the Lua time is just under 10 seconds), but often errors are shown. I have been contemplating asking for opinions here. The problem appears to be that {{PH wikidata}} is called 1193 times. It often accesses the same property multiple times because of the limitations of templates which cannot store a value in a temporary variable, and my guess is that the large number of calls to Module:Wikidata is too much overhead. Does anyone know what overhead is involved in accessing Wikidata as in a property for the current page, and a property for another page specified by qid? Can several hundred such accesses be reliably done in a reasonable time? Johnuniq (talk) 00:37, 14 February 2017 (UTC)
Yes, I manually substituted the first level of template (the top level template {{PH town table}} is utterly useless as it just invokes one of three templates based on whether it‘s a top, middle or bottom, but this something an editor knows and is not going to change; better to invoke the template directly). Hard to tell how much of a speedup it provided, it did not fix the problem.
The next step would be to look at the sub-templates, {{PH town table/mid}} in particular where most of the time is spent. But the more time I spent down that rabbit whole the more I discovered the templates are unfixable. {{PH town table/mid}} invokes more templates {{PH town table/mid5}} ... {{PH town table/mid9}}, some of which invoke yet more templates. None of the templates are documented anywhere, while the coding style renders them particularly unmaintainable: not only the multiple interdependencies but the use of parser functions rather than Lua. Lua is faster and more maintainable in general, and would be especially beneficial here in dealing with the excessive calls to {{PH wikidata}}.
So the best thing would be to replace these with a Lua implementation. Despite their complexity they are not doing anything that difficult, so a replacement should be much simpler. The performance benefits of doing so should be especially significant in this case. In the meantime perhaps substitute the templates, i.e. replace them with the data, to fix the performance and error problems.--JohnBlackburnewordsdeeds01:12, 14 February 2017 (UTC)
As I thought - you have know idea what you are talking about. Changing e.g. {{Cebu}}, works maybe once ever 3 months, so work means 10 sec / 3 months. The fact is that the messages are read only by ex-programmers with nothing else to do. Subroutines are to get rid of editors, not the other way round. 112.198.102.167 (talk) 01:33, 14 February 2017 (UTC)
Presumably you have not yet seen the errors that often occur towards the end of Cebu and occasionally at Bohol. My first message above included the fact that the Lua time usage at the time I posted was 10.046/10.000 seconds. That means 10.046 seconds were used out of the maximum possible of 10.000 seconds (it went slightly over because that was when the server noticed and truncated the process that was rendering the page). Right now, Cebu is working without errors because the Lua time was 9.679/10.000 seconds when it tried again. However, that value is right on the limit which is not sustainable. Johnuniq (talk) 03:09, 14 February 2017 (UTC)
They are not "read only by ex-programmers", or even only by programmers. The reason it came to my attention is it frequently ends up in the category, Category:Pages with script errors. Normally that happens when a script fails with a programming error, but occasionally as here when the page runs out of time running scripts which is more serious, as when that happens every script on the page executing after time runs out fails, and there can be dozens of red messages on the page visible to everyone.
The arguably more serious problem is that even when there are no errors and red messages the page takes way too long to generate. This impacts anyone editing the page, hitting edit or save and wanting to see their work. It is not a long or complex page, so should not have such performance problems.--JohnBlackburnewordsdeeds03:14, 14 February 2017 (UTC)
@Johnuniq: I've made some changes in the sandbox that reduce the number of calls by four per use. There's probably still too many calls, but that might push it out of the timeout state. Pppery02:20, 15 February 2017 (UTC)
I would welcome anything which brings the Lua time down so it is consistently below, say, 8 seconds. I haven't looked at your changes but you could pop them in and see what happens. I was just gloomily contemplating what would be involved in translating {{PH wikidata}} to a module. It is certainly do-able and I think that's where the major gains would occur because it would cut down a lot of the duplicate Wikidata calls. However, I should be doing other things and anything that works would suit me. Johnuniq (talk) 02:41, 15 February 2017 (UTC)
@Johnuniq: I synced my changes, and the lua time seems to have dropped by one second, putting it in the 8-9 range without any overflows in like 5 previews. Pppery03:22, 15 February 2017 (UTC)
(And then was reverted because I forgot a pair of curly brackets ..., added the missing pair, and synced it again) Pppery03:39, 15 February 2017 (UTC)
Scribunto has a function profiler on preview, but you need to add a "forceprofile" parameter when submitting the preview and it's somewhat broken at the moment with HHVM. With a little work I got some useful results out of it:
Very interesting, thanks. While contemplating debugging tools, it would be useful if there were a way to tell a sandbox that it should act like a particular article as far as Wikidata is concerned. For example, I captured all the PHxxx templates from the wikitext at Cebu and was planning to save it in a sandbox to get the NewPP report, and then repeat after removing some of the calls to see the difference. However, I stopped on realizing that a sandbox would behave very differently from the article due to Wikidata. At Special:ExpandTemplates I can enter "Cebu" for the Context title to make it work properly getting Wikidata properties, but there is no NewPP report for that Special page. Johnuniq (talk) 06:08, 14 February 2017 (UTC)
Why in the world is there no option to sort results by date or any other parameter? Results like this are absurdly primitive and make it extremely time-consuming (a complete, senseless waste of time) to search pages and archives for something.
Why are search results unsortable in 20176? Is this something that can be addressed with a simple phab request or is our search engine so horrible that it would be have to be completely redone? Jytdog (talk) 20:58, 26 January 2017 (UTC) (fix date, per below. duh on me. Jytdog (talk) 03:50, 28 January 2017 (UTC))
thanks for your reply. but wow. I have to use obscure things like adding prefer-recent to simply get results in date order? Oy. In any case I added that to the search query and I got basically the same results: see here. So... not only baroque, but mostly useless. People use search engines every day. It should not take obscure coding to sort various ways (like, why can I not search only section headers, by clicking a box or doing something simple?) This is something that anybody who wants to bring diffs in a discussion struggles with every day. Why is our search function so awful? Jytdog (talk) 22:58, 26 January 2017 (UTC)
FWIW, I totally agree. It is the most primitive search tool and next to useless for anything other than a very simple query. Leaky Caldron23:09, 26 January 2017 (UTC)
Yes, I see that. But why not make is user friendly? If a date range is required, who is going to know the syntax? It is not the sort of feature these days that requires near-programming skills. Leaky Caldron23:24, 26 January 2017 (UTC)
Sorry you're frustrated Jytdog, but that's not very kind. :( Admittedly, search on Wikimedia projects has room for improvement. Discovery folks are probably some of the most aware of that. :) Heck, I could imagine more advanced search features have probably been discussed since 2001!
To the matter at hand, there is active work on improving the UI for search results, faster updates to the index, cross-project search, and - you guessed it - improving advanced search features. Just a few weeks ago there was a good session at the Wikimedia Developer Summit that covered two active initiatives (session notes here). The first is the Advanced search workshop hosted by WMDE as part of their WMDE Technical wishes. I hear tell they even have a prototype coming soon! The second is Discovery's own work on cross-wiki search results improvements - a component of which has been a discussion around UI changes to make apparent more of these 'hidden' features present. The team is hoping to have some A/B tests in place this quarter .
That's not to say that we're going to see overnight changes here. Making changes to something that touches every Wikimedia project is dicey business (see [15][16] for humor on this topic). Folks use search in many different ways, and adding bunches of checkboxes or drastic changes to the behavior of search is not something to be taken lightly. Improvements are improvements and I hope you and other members of the community welcome them (and let us know if we get off track!).
Besides that more targeted work, myself and Cpiral among others are active at Help_talk:CirrusSearch. Together (well really Cpiral gets all the credit) we recently reworked much of the documentation, made it available for translation, and made sure the "? Help" link from almost all Special:Search results page link to the documentation (Humorously enough the English Wikipedia search results don't link to the updated documentation. Anyone want to help with that?).
If you want to know more, I'm happy to help. You can see our statistics on the quality of search at http://discovery.wmflabs.org/metrics/. If you have suggestions for the cross-wiki search results improvements, feel free to drop a note on the talk page there. Constructive, actionable feedback is much appreciated! General suggestions for improvement are welcome wherever you can put finger to key, just ping me to get my attention.
Thanks for your note, I am sorry you find it unkind. I find that the communication between the editing and dev communities has sucked rocks as long as I have been here. But really - I have zero time to go read documentation and use bizarre functions that don't even work like prefer-recent. And I find it just weird that you are even suggesting that I devote time to that. I want tools that work. Happy to test stuff and happy to tell anybody what i want. Jytdog (talk) 06:23, 27 January 2017 (UTC)
Me bookmarks this, so that I can point the few people who will complain about the 'undesired changes' to the searchpage, when the work of the German techteam changes the Search UI somewhere in the next year. :) —TheDJ (talk • contribs) 07:18, 27 January 2017 (UTC)
Whoops, sorry Jytdog, my intent wasn't to tell you, "Go read the manual", it was to say, "Hey there are folks interested in helping with search-related questions, we hang out over here. Come ask us questions." I got a little off topic talking about the improvements to the documentation we made. Sorry for the confusion. To make sure your feedback doesn't get lost in the archive I created a Phab task to have the team take your suggestion into consideration. Take care. CKoerner (WMF) (talk) 15:22, 27 January 2017 (UTC)
Few know Search, and the docs don't seem to explain it well enough. It's very good. I learned about it by posting at Help talk:Searching and phabricator. I don't understand why Help talk:Searching has always been so quiet (by Wikipedia standards). ... Hey, a post there just announced WP:Request a query. I wonder if that will somehow help Search get the attention it needs. — Cpiral§Cpiral23:52, 26 January 2017 (UTC)
@NeilN: Hello again. As with last time, your characterisation of the situation is inaccurate, and your anger misplaced. I said the reason why Google does not have it is the same reason we don't, namely degradation of experience. This is not the same as simply doing what Google does like you imply. To repeat, the reason this feature is not a priority is because it will degrade the search experience for the vast majority of users. I acknowledge that it is a useful feature for some users, such as yourself and Jytdog, but often I have to make hard decisions about how to prioritise the few resources we create the maximum impact, which in this case sadly means not prioritising your request. It's currently the hope of the Search Team that we can work on advanced query features, potentially such as this one, in Q4 (i.e. April - June 2017); we've been laying a lot of groundwork over the past few months, and it may finally be a time when we can really improve things. I am hopeful that we can partner on this and work together, and put any previous hostility behind us. --Dan Garry, Wikimedia Foundation (talk) 16:26, 27 January 2017 (UTC)
Sorting by date (or by page title) is useful when searching in discussion page archives; if that is not practical, filtering by date would also be helpful. I often find myself searching for a discussion that happened sometime in the last year on a given talk page, and getting apparently randomized results from the last 15 years of discussion is not helpful in those cases. I hope that WMF staff will return here when they are working on a spec for improving search. There are many constructive, helpful editors who watch this page. – Jonesey95 (talk) 16:44, 27 January 2017 (UTC)
@Deskana (WMF): No, I think my characterization of the situation is pretty accurate. You repeat it will "result in degraded performance for the vast majority of users" over and over again but have never justified or explained your assertion. --NeilNtalk to me16:48, 27 January 2017 (UTC)
@NeilN: You said the same thing last time in spite of my giving an example, but very well, I shall try again. Three years ago, in phab:T40403#477014, I gave an example; "Due to the way search works, for most queries this would generate a list of articles with nothing in common. For example, searching for Barack Obama and sorting alphabetically would generate nonsensical results such as Aaron McGruder, an American cartoonist, followed shortly thereafter by Abbottabad, a city in northeastern Pakistan". For the use case Jytdog mentioned, searching for his username in discussion namespaces, this makes perfect sense. For searching the article namespace as a casual reader, it does not make sense, which is the danger with exposing such functionality plainly. This does not mean that there are not legitimate use cases, but it does mean caution is necessary. Sadly, as with last time, I won't respond further due to your hostility. --Dan Garry, Wikimedia Foundation (talk) 17:00, 27 January 2017 (UTC)
@Deskana (WMF): I don't think I'm hostile, just aware of the game you seem to be playing. I've dealt with similar situations in my professional life and, if I'm honest, used the technique too. You can always custom craft examples to show why change wouldn't be good. Note the emphasis in all of these requests is sort results by date, not alphabetically - this is your red herring. And no one is suggesting that the default behavior of search be changed so, again, "degraded performance for the vast majority of users" still has no justification. --NeilNtalk to me17:19, 27 January 2017 (UTC)
@NeilN: wow, on that prior discussion and the discussions linked-to there. Just wow. Yep, discussions between people who work in dev and editors who need to work in community and dig around in histories and archives in order to do so, is completely bolloxed. Our search engine sucks rocks for that purpose and devs are just completely, utterly deaf to that. I can't see any place where reasonable efforts have been made to even to try to fix that problem. I may be unaware of them, but I have not seen them. (of course trying to find them will be a pain the butt and i am uninterested in using the crappy search engine to even try to find them.) Jytdog (talk) 22:16, 27 January 2017 (UTC)
@Jytdog: Yep. I've interacted with WMF devs before and I have always understood when they say something like "our user surveys indicate this feature request does not have high priority with other users" but don't feed me a line like it will degrade performance for the vast majority of users and then refuse to back up that assertion with any kind of proper justification. Just say you don't want to do it and accept the (deserved) brickbats thrown at you instead of coming up with a bogus explanation. I mean, adding two dropdowns (sort by, sort order - default to Relevance, Descending) to this screen is going to "degrade performance for the vast majority of users"? Really? --NeilNtalk to me22:42, 27 January 2017 (UTC)
I took the bait and reviewed the pdf document. There is nothing there about past discussions between the dev community and the editing community about making internal search work better on page histories and archives. This is the second instance (the first being discussions about the Discovery engine) where you have responded to stuff i have written by sending me to go read things that had nothing to do with what I was asking about. You wasted my time and volunteer time is the most important asset WMF has (not that mine is particularly valuable compared to others). And you have acted for the 2nd time now as a PR guy instead of a liaison. Stop wasting my time. Jytdog (talk) 23:46, 27 January 2017 (UTC)
I'm not sure why you're emphasizing the wrong year. It's 2017.
I agree that site search is rudimentary and would benefit from additional features. If you can convince Erik B. of the merits, that would be your best path forward. Trying to deal with other members of the "Discovery" team is just useless, as you all are apparently re-discovering here. It also isn't really fair to flatly say that developers are missing the point or causing problems here, given that Dan G. and Chris K. aren't developers. Some developers, such as Chad H., certainly aren't helping matters, though.
It's in discussions like this, where people like Dan G. talk about the "hard decisions" he's forced to make, that I'm re-reminded why nobody should donate money to the Wikimedia Foundation. It's gotten far too big and bloated. --MZMcBride (talk) 03:31, 28 January 2017 (UTC)
You just made me laugh. Thanks for that! Yes it is 2017. :) I am emphasizing the year as the search engine appears to be so primitive, and we are so, so hamstrung by it. So much time wasted pouring over these search results that appear to be presented in random order. I see no sense, at all, in the order of search results in my OP. There are 944 archive pages for ANI. Really, this is not fixable with existing technology in 2017? Really?? This makes me grit my teeth any time I go looking in archives, or even just blow it off, as I mentioned above with regard to finding past iterations of this exact discussion - am not going to wade through however many of the 154 archives (!) of this page mention "search engine", randomly presented to me.
Somebody above said that google can't sort by date, but it can very precisely limit the date (on bing and duckduckgo too). But as noted above, google is a bad example as it searches the whole darn web. I use Pubmed a ton and there are zillions of filters that can be used on that, which are simple to use. Why can we have not a decent search of archives?
and thanks for the pointer to the apparent wizard, Erik B ! Will head down the yellow brick road to find them. Jytdog (talk) 03:50, 28 January 2017 (UTC)
The Google comparison also falls apart when you dig into it. It can certainly sort by date - see this. Of course the news search has more structured data to work from... kind of like a certain website. --NeilNtalk to me05:51, 28 January 2017 (UTC)
When Nik E. left the Wikimedia Foundation, Erik B. took over the CirrusSearch maintenance and support. Nik actually went to go work at Elastic, the company that makes Elasticsearch, which is what powers Special:Search currently. CirrusSearch is the MediaWiki implementation of Elasticsearch. --MZMcBride (talk) 08:00, 28 January 2017 (UTC)
Thanks for the call-out/criticism without the ping :) But....huh? I haven't had anything to do with search in quite some time. I'm not sure what I'm supposed to be helping that I'm not. ^demon[omg plz]20:37, 30 January 2017 (UTC)
It doesn't seem like you needed a ping to find this discussion. ;-)
I was specifically referring to phabricator:T40403#477138. You went further than saying "I'm/we're not going to work on this", extending it to "nobody should work on this, patches won't be accepted". This comment is from March 2014, back when you were more involved with search. (If you weren't involved with search in March 2014, then that comment is even more unusual and upsetting.) Comments like this can stall work and progress literally for years, which I find pretty unhelpful, yes. --MZMcBride (talk) 01:27, 31 January 2017 (UTC)
In reading back over it, I realized that comment was actually misplaced entirely, as Andre was suggesting that people could make local hacks or extensions for their own wiki to accomplish this--not suggesting they be committed to Cirrus or core. So it was useless to state that. Fair enough that this may be discouraging, but it was nearly 3 years ago when I was actually involved. I can remove/retract it if that'll help. I don't care strongly about this anymore... ^demon[omg plz]02:16, 31 January 2017 (UTC)
It is funny that those who help build an encyclopedia won't do the basic research to back their claims when it really counts, though having made a similar request (based on indexing time html5 tag and sorting using that) in a non-WMF it is easy to empathize.
Raw sorting using dates will certainly provide worse results unless they are filtered, [18][19]. There are also studies providing evidence that end-users prefer sorting based on ranking, Disambiguating, categories, [20]. Examples of current garbage results yielded by data ranges or filtering, in which the dates have 0 relevance are easy to find even in a Billion dollar search engine: [21]. They would be far worse in a Wiki, due to vandalism, bogus dates from imports, or even a routine bot edit that invalidates dates.
For readers, however, sorting and filtering articles using wikidata related dates would be much more meaningful than using either creation date or last-edited date. — Preceding unsigned comment added by 197.218.80.247 (talk) 21:14, 30 January 2017 (UTC)
Listen, the following are facts:
Editors need to find things in archives as part of their work in community
The search engine is useless in that effort, as the results are presently random. Whatever the engine understands as "relevance" is irrelevant when searching for an exact phrase. The results are random. Instead of using the search engine for this, I browse - I go though the archives manually, one by one starting at the most recent or around the date when I remember something being discussed, and use my browser's "find" function to search for the string. That is how useless the search engine is for this.
Nobody from the dev world has even acknowledged that the search engine absolutely sucks for this. That makes the responses here and at phab all the more bitter to receive.
They are hard to hear anyway, as they have been knee-jerk rejection at worst, and uncreative elaboration of "present priorities and limitations of technology blah blah blah" or dismissed as something that only "power users" need which is a) bullshit and b) clueless about how the WP community works..
I have no idea how the back end works, but here are two ideas pulled out of my ass (yes, I know nothing about the back end)
could talk archives and Wikipedia space be indexed separately, searched separately, and available via federated search for general searching only if selected, so that whatever "resources" this would take up are not incurred in general search by readers? (they are not relevant for people who want to read articles anyway)
is it really so resource-intensive to have the results from the present engine sorted by Archive number (almost all archives are numbered; part of the very URL that is presented in the results includes the string "Archive_#") (For example, could sorting by archive number in the URL not be done as a separate step after the engine generates results and before they are presented?)
I am sure those will easily be shot down. Which is what I expect to happen, along with more dismissive, uncreative, bullshit comments that ignore the problem for the editing community. And the problem will remain unsolved Jytdog (talk) 18:26, 2 February 2017 (UTC)
Hey Jytdog. I'm still listening as are others. Real quick, saying “I am sure those will easily be shot down.” immediately makes replying with any information difficult. Any response you perceive as contrary to your proposed facts have the chance to be construed as ‘being shot down’. But hey, it’s my job and i’m still going to give it my best - not because I have any hope to convince you that WMF staff are not evil incompetent poo-poo heads, but because others might appreciate alternative facts. No, wait, that came out wrong. Others might appreciate clarifications on the claims you have put forth. :)
Please, AGF in my response.
Editors need to find things in archives as part of their work in community
Totally agree. No one is arguing this. As we all know the same thing replies to Readers, which unfortunately are harder to reach and hear from than editors. When making any decisions, folks at the WMF have to balance the needs of people who have a voice, such as yourself, with those that aren’t around to tell us what’s working or not. It is not something to be taken lightly.
That, I think, is the crux of the “degrade the search experience” concern. It’s not that super handy search tools for editors are unwelcome, but it’s a challenge to build something that works for editors and everyone else we (editors and WMF) support with our work.
The search engine is useless in that effort, as the results are presently random. Whatever the engine understands as "relevance" is irrelevant when searching for an exact phrase. The results are random. Instead of using the search engine for this, I browse - I go though the archives manually, one by one starting at the most recent or around the date when I remember something being discussed, and use my browser's "find" function to search for the string. That is how useless the search engine is for this.
Random makes me think of 'by chance'. Like as if when you search we spin a giant wheel in the background and out pops whatever pages we can find. :) You might think that would be better than what currently happens, but I can assure you there is far more logic and reason behind search.
Elastic, the company that created Elasticsearch, has some very technical (over my head) documentation on how scoring works. That's just the 'out of the box stuff'. We've been tuning it for movement needs beyond that for quite some time now. I have another thought on this further down. Maybe search isn't the thing you need?
But, since all we have is search right now: Have you tried putting a query in quotes? It will return results for that exact phrase. If that's not working then do let us know. [22]
Nobody from the dev world has even acknowledged that the search engine absolutely sucks for this. That makes the responses here and at phab all the more bitter to receive.
There are about 16 people working in Discovery. We all know search can be made better and each of us show up to work every day to make it so. You may have missed it after you unsubscribed from the task, but we are considering the feature request and the intent is to keep the task open until a time where we're ready to work on it. Another editor also mentioned creating a user script and I would love to see that as a possible solution myself.
They are hard to hear anyway, as they have been knee-jerk rejection at worst, and uncreative elaboration of "present priorities and limitations of technology blah blah blah" or dismissed as something that only "power users" need which is a) bullshit and b) clueless about how the WP community works..
Oh, man. This is really not helpful. That 'knee-jerk' reaction comes from members of the department being at the foundation for years and editors and admins for years before that. You can't really use that argument I'm afraid. Saying "blah blah blah" is equally dismissive as your claim and does not further the dialog. :(
I have no idea how the back end works, but here are two ideas pulled out of my ass (yes, I know nothing about the back end)...
Which is fine, we're not all backend developers (who, while magical, are not mythical). Feedback like this is what people like me strive for. Good ideas to make better tools for editors are appreciated. The rest of the stuff, ehh, it makes my day crappy and you come across as a jerk. Not a good situation for anyone.
could talk archives and Wikipedia space be indexed separately, searched separately, and available via federated search for general searching only if selected, so that whatever "resources" this would take up are not incurred in general search by readers? (they are not relevant for people who want to read articles anyway)
Bingo, this is the exact question we're asking with the proposal (and similar). How do we surface project Wikipedia content in a way that doesn't confuse, frustrate, or worse alienate folks who are satisfied with general search? That's what we're trying to get to with discussions around reworking the UI of Special:Search and thinking about incorporating advanced search - of which your suggestion is one in consideration!
is it really so resource-intensive to have the results from the present engine sorted by Archive number (almost all archives are numbered; part of the very URL that is presented in the results includes the string "Archive_#") (For example, could sorting by archive number in the URL not be done as a separate step after the engine generates results and before they are presented?)
"Almost all", but "not all" means very different things! As smart as search engines are, they are only as good as what you put in. That's why searching is 'fuzzy'. Imagine how frustrated you would be to make a search thinking everything in the archive is structured only to discover the early days were more lax and you see no results?. Oh, wait, you already are. :(
This also points out one of the challenges in using search to find info in archives. As TheDJ pointed out in the phab task, "Talk archives are edited all the time (and thus their recent indicator that we currently have isn't useful to determine their age)."
While not at attempt to shoot this idea down, perhaps this is something like a Special:Archive could accomplish better. You know that currently search isn't great for it. Maybe we're at the point of looking at the hammer and wondering if a screwdriver wouldn't be better. :) Something separate from search that provides an index of specified Archive pages? You give it a "Talk:" page title and it spits back every section heading for each Archive number?
Ok, so while I may not have convinced you of anything, at least know I tried to be as modest and creative in addressing the concerns you bring forth. I think the problem will remain unsolved if we can't have a civil and agreeable conversation on this topic. However, if you can meet us half way (as you did with your latter suggestions here and in Phabricator) I think you'll be pleasantly surprised at what we can accomplish together.
For folks not keen on participating in Phabricator, the ticket I created in response to Jytdog’s feedback earlier in this thread was merged with an existing task from 2015 and reopened by a community member. The search team is reviewing the task and will consider it when we look to approach advanced search in the future. Feedback there is welcome or wherever you can ping me. CKoerner (WMF) (talk) 20:34, 2 February 2017 (UTC)
Thanks for your note.
If you search for a string in quotes, many pages will have the string, so "match" is simple. There is no apparent order in which they are presented. Quibbling over "random" is off topic.
It is not true in my experience that talk archives "are edited all the time". Archives have big tags on them saying "DO NOT EDIT" and in my experience are edited rarely. The assertion at phab was just that - an assertion.
Having the search engine present results when searching archives that are useful most of the time (for archives that are numbered, which most of them are in my experience) would be way better than search results that are always useless for searching archives. Everybody understands that things are limited in the real world. That includes me.
With regard to WMF priorities, I have nothing to say about that. Your priorities are set by your bosses and everybody knows the history there. To the extent this can be addressed with the resources you have been given, that would be great. Jytdog (talk) 21:02, 2 February 2017 (UTC)
I must admit, the prefer-recent search parameter does not work clearly and consistently well to actually sort by date. I don't even know, at this point, that it works as intended. In any case, the end-user of CirrusSearch is currently in a rough terrain: exposed to complexity of its page ranking, while not having recourse to discussions on the talk page, which take place on phabricator. Plus I admint that I am not, alone, as a volunteer and non-expert, able to document search to the level that happier, more experienced users of CirrusSearch can simply reply, in cases like this, "RTFM".
Search can be improved without taxing developers and the Discovery Team too much if more volunteers work on it, discuss it, document it. Yet the places to do so are not frequented in proportion to the value and importance of Search. This conversation might have happened on Help talk: Searching, right? — Cpiral§Cpiral23:22, 5 February 2017 (UTC)
I put this here as i don't need help with the current search function. The current search function is worthless for searching archives. There is no "help" for that. Jytdog (talk) 23:35, 6 February 2017 (UTC)
Just as a quick note about prefer-recent, since I wrote it. It was never designed as a full filter by date. It was primarily built to replicate old behavior for Wikinews (hardcoded in lsearchd) that helps their recent articles be preferred (while still searching primarily on text). So yes, while it helps *prefer* a date based order it doesn't actually *enforce* it if other factors provide a better match. It was simply exposed to all wikis because it's easy enough to do so. For the usecase here (actually ordering by date) it's not a real workaround. Sorting by *anything* is a simple technical solution...the data is all there. I will note, it would be pretty easy (and not clutter a UI at all) to just expose an order-by: parameter just as easily we do for prefer-recent, has-template, or any of a dozen other parameters we already support. This also avoids the "we don't want to confuse the UI for readers/non-power-users who don't need them." ^demon[omg plz]02:48, 10 February 2017 (UTC)
Talk is cheap, show us the code!!! Seriously though, sorting will keep failing unless the search engine indexes every single history page. That's something that would likely use massive amounts of space and processing power, and would never be acceptable because history pages contain a lot of illegal, obscene and spammy content. Another issue is that anyone with enough brain cells to write a bot can easily fire one to go through all archives and do a small edit. That would immediately make those "sorted" results as pointless as they are currently. The simple fact that is that the notion of archives doesn't exist in mediawiki. Moving those "pages" into subpages, and calling them something else doesn't change what they are, nor does it remove their limitations. Manure by any other name smells just as bad. — Preceding unsigned comment added by 197.218.81.60 (talk) 23:46, 10 February 2017 (UTC)
Note about the hullaballoo over WP "banning" the daily mail. Where did that "banning" take place? Oh, at RSN. What is "RSN'? It is the noticeboard where the community discusses whether sources are reliable. Guess what? Many sources, like the Daily Mail, have been brought up zillions of times there. How many archives does RSN have? 219. Why do you think people keep using the same awful refs over and over and we need to keep having the same discussion over and over, which is what probably led to the RfC that led to the "ban"? Gee maybe because in the world of search engines, the one you force us to work with to find past discussions and the consensus we already reached, is about the same quality as the Daily Mail in the world of reliable sources. Jytdog (talk) 19:57, 9 February 2017 (UTC)
This section is so long that I didn't read all of it, so I hope that this is not redundant. Two points about searching by date:
For those searching through talk pages that are automatically archived, it's possible to narrow down a search. For example, at the Wikipedia:Help desk, if I type "Anne Delong" "Archives/2013" into the archives search box, I get only results archived in 2013. "Anne Delong" "Archives/2013/July" gives me results from July 2013.
Adding "prefer-recent:1,0.0007" to a search will give well sorted results by date, but it's hard t remember and annoying to type. There's a handy template that allows a user pre-specify areas to search by presetting the "prefix" parameter. You can also include a reminder note and just copy-paste the "prefer-recent:1,0.0007". Here's one that looks in a couple of talk namespaces, but it can be set to be more specific, for example, just my own user pages.
Find pages in Wikipedia talk: and User talk:
Type a keyword and click on the button. Optionally, add "prefer-recent:1,0.0007" to see results in date order.
[[Wikipedia talk:]] [[User talk:]]
According to Template:Search templates, the search box is created by something called Extension:InputBox. Perhaps someone familiar with this process could expand the template above by adding one more item: preset search parameters= which would insert a text string (such as is done in Template:Search link) after the user's search words but before the prefix. In this way, users could make their own custom searches, and those wanting date-ordered results could preset "prefer-recent:1,0.0007" (or any other text) in the template and save it on their user page or wherever handy.—Anne Delong (talk) 13:18, 11 February 2017 (UTC)
Hi, y'all. I want to [Restore this version] of my Talk page using Twinkle. I was in the middle of archiving with 1CA when a large chunk of my Talk page got deleted when I tweaked the Archive basics parameters, so I want to Restore to that diff and then archive parts of my Talk page.
The problem is that there is a DS/A in the Deleted portion, so the Edit Filter blocks the Restore. Any ideas? I am not sure if this diff is any different.
This filter is set to :warn+tag" - that is, make sure you know what you're doing, and make it easy for other suers to review the eidt as required based on what it looks like. Many of these filters have a medium false positive rate. If you have any future issues with the edit filter, please report them at Wikipedia:Edit filter/False positives, as the warning you got tells you to. עוד מישהוOd Mishehu11:55, 15 February 2017 (UTC)
Javascript for current user status
Hi, I have an idea for a javascript (which is for the moment pretty much just an idea) to automatically show user status (online, offline, away, etc.) based on how recent their most recent contribution has been. The biggest hurdle I'm facing right now is arguably the lack of javascript programming skills in me. I do know a bit C++ so the task should be easier.
Anyway, to the components of the idea:
A page in the user's namespace, let's say "USTATUS" (created for the purpose) that should have a single word, like "online","offline","away", etc.
A piece of codethat is placed in the user's custom .js file that runs every time the user visits any page on Wikipedia. (I'm assuming that the javascript runs this way). This code snippet serves to check the above mentioned user's page and replace all content on page USTATUS with the word "online" (or leave it unchanged if the page already has nothing but "online").
Another piece of javascript code(placed on a separate page - NOT in user's custom .js) that, when run, checks the user's "Conributions" page and retrieves the time of the latest contribution. If the latest contribution is more than, say, 600 seconds old, this code should replace everything on USTATUS with "away", or if it is greater than 3600 seconds, "offline".
A template that is placed on the user's talk page that checks that checks USTATUS each time it is run (or purged) and shows status accordingly. (Example: If USTATUS has "online", the template should show something like "The user is online"). Also, this template should have the above component (3) embedded in it so that each time the template is purged, the javascript is executed. Of course, first the code should be executed, then the template should show the appropriate message reflecting "online","offline" or "away". (This is the part I'm mostly doubtful of. I'm not sure if such embedding is possible)
Optionally: Another piece of code in the user's custom javascript file that changes the "Log out" button to include code to change USTATUS to "offline". (NOTE: Not an extra button, but modifying the same one)
Note that I'm already aware of the related user scripts that exist (and maybe some code could be borrowed from them) but none of them automate the process.
Any input, regarding the logic or anything else would be greatly appreciated. Contact me on my talk page if need be. Also, I'm hoping this is the right place to post this. Thank you! RoCo(talk)13:59, 14 February 2017 (UTC)
(1) and (4) (apart from embedding 3) can already be done with a template like {{Statustop}} or similar. (2) and (5) should be possible to code. (3) probably isn't possible the way you imagine it – you can't force other users to run your personal scripts when they view/purge your userspace pages – and if you try to do it yourself, the code from (2) would be triggered and set your status to online. - Evad37[talk]14:37, 14 February 2017 (UTC)
(3) checks the contributions of the user where the template is present. It does not matter what the status is until another user wants to find out. So it can be "online" for a long time, even for days if no one checks the page. The moment another editor clicks the purge button on the template, it should check recent contributions and update as such. I don't see where (2) would come into place as the script doesn't run when the user is not using Wikipedia. Am I missing a point? EDIT:To clarify, (2) is in the custom javascript, whereas (3) is common for all users, and is available on a separate page.RoCo(talk)14:47, 14 February 2017 (UTC)
While technically possible to add common js for all users, in MediaWiki:Common.js, I don't think you would be likely to get consensus for it – per the top comment there, "Keep code in MediaWiki:Common.js to a minimum as it is unconditionally loaded for all users on every wiki page." Plus users would be probably have to be warned that checking your status could cause them to edit your USTATUS page... basically it would be messy, and could slow the site down for everyone. A better idea might be a bot that runs at specific times throughout the day, and updates the status subpages of users (who have signed up for it) by checking the timestamp of their last contribution. - Evad37[talk]15:30, 14 February 2017 (UTC)
I'm truly amazed by my ability to mess statements up. This is embarrassing, but I didn't mean "common" in that way.. (2) would be in user's personal javascript. Good. (3) would be on another javascript page (For example, in my user space, User:Rollingcontributor:newfile.js or something). When the template is purged, it should run the code on newfile.js, with an argument as the user where the template was originally placed. The newfile.js code should then edit what user page has been passed to it as an argument, and then the template should check it and update. Did I confuse you even more? If yes, sorry, let me know. Also, a bot would consume a lot of resources if it needs to constantly monitor a lot of pages. RoCo(talk)15:42, 14 February 2017 (UTC)
I didn't know there existed a bot for this. I couldn't find much about what the bot actually did. Could you let me know? Thanks! RoCo(talk)15:54, 14 February 2017 (UTC)
Maybe its also me... it is quite late in my timezone. Anyway, perhaps you clarify if this is what you want:
You haven't been editing for several hours, and in fact are not online, or interacting with Wikipedia at all – no open tabs/windows, and lets say you've also logged out – but you status page is still set to 'online'. Another user comes along, decides to check your status, and so clicks on the purge link in the template. An edit gets made to your status page, changing 'online' to 'offline', and the template now shows you are offline.
Now, if that's right, who makes the edit (as shown in the page history)?... and if you are not online, who is running the javascript for this? - Evad37[talk]16:24, 14 February 2017 (UTC)
Well, that's something I didn't think about! I guess it would be technically possible for the user who presses the purge or whatever on the template to make the edit? Wrong? Also, I didn't quite understand "and if you are not online, who is running the javascript for this". The script that changes to "online" is only needed when the user is actually online. The script that changes to "away" or "offline" is, as told earlier, on a separate page, which is run when someone else comes and presses purge. So what we would be needing is a "purge" button that does more than just purge. Did it clarify? RoCo(talk)16:38, 14 February 2017 (UTC)
As noted by Xeno, this won't happen because the developers forbid it (at least the 'automated part of it). And that is because wikitext is not designed for problems like this. If you want something like this, you should integrate with a more suitable system. I think you will want to integrate with something slack.com-like (perhaps a mattermost or rocket chat instance on wmflabs) and use THAT to keep track of status. —TheDJ (talk • contribs) 16:49, 14 February 2017 (UTC)
BTW. 2 and 5 are exactly what TheDJ/Qui and a few other status changer scripts used to do. But it doesn't work properly enough, without a good solution for 3 and 4. Most people just stopped using it after StatusBot was stopped, because it's just annoying and unreliable without automating parts of the status updates. —TheDJ (talk • contribs) 16:57, 14 February 2017 (UTC)
The edits would only be made when a user explicitly clicks on the button (and only once the user logs in). This doesn't use a bot, and doesn't make a lot of edits, as edits are made only when they are required. It would still be a good idea to integrate, as you've suggested, but that could take a lot of time, effort and programming. Also, it doesn't hurt to try and make this code work, right? RoCo(talk)17:02, 14 February 2017 (UTC)
Laziness with regard to implementations doesn't scale to top 10 websites. The whole point is, yes fixing this properly is a lot of work. Doing it not-properly has been tried in various ways already and didn't work (proof, you didn't know about the ways that have been tried before). —TheDJ (talk • contribs) 17:21, 14 February 2017 (UTC)
I know little about the advanced programming and integration into a larger system. I only suggested what was in my immediate power and knowledge to try and help make this work. I do accept that laziness in implementation has no place on Wikipedia, but, as you've seen (and so did I now), the problem is nearly a decade old, and there hasn't been a proper solution yet, even though it was pointed by numerous users. Anyway, it would still be better to escalate this. RoCo(talk)17:46, 14 February 2017 (UTC)
We have hundreds if not thousands of technical 'problems' that are a decade old. And you could say that having only 4,931 featured articles after 16 years is a problem. But it's all relative and the easiest solution to all these problems is 'more skilled contributors to produce more results'. But that's also where the scarcity is. That said, you can easily take an old copy of Qui, fork it, fix it, and reach 50-1000 people. But that's still just a drop in the ocean. In my opinion the effort required for that is better invested differently at this point in time (either writing articles, or writing a proper system). —TheDJ (talk • contribs) 00:04, 15 February 2017 (UTC)
Since AFAICT, it's been over 8.5 years since the last status bot was shut down, it's perhaps worth just checking that developers will still reject any bot.
More importantly, both Extension:OnlineStatus [23] and Extension:OnlineStatusBar [24] are both marked as stable. I don't know how true it is, but I see mention of the extensions at Wikipedia:Village pump (technical)/Archive 81#Status changers, Wikipedia:Village_pump (technical)/Archive 94#User online statusWikipedia:Village pump (proposals)/Archive 81#Online Status. Notably in the last discussion the conclusion is to move development of opt-in online status to technical review. I think the key problem is even if the extensions are truly stable and suitable for en.wikipedia, the developers are bound to require very good evidence of that before they consider implementing them. There is mention of this in the discussion, and I think that's the hold up. [25] seems to be the BugZilla which is for OnlineStatusBar but there's been no real activity since 2012 and it never went through proper review.
As I understand it, the OnlineStatusBar has some automation. OnlineStatus doesn't have any. But I think both would also be amenable to a bot and since these extensions use their own database to store the online status (so don't need to store so much stuff and can also be de-prioritised), they will probably get around performance concerns of the developers if implemented properly. (Actually if you look at discussion around time of the bots being shut down, developers suggested an extension.) So it seems the extensions may be a possibility but people will need to help with the reviews and somehow convince the developers to partake. Stronger community desire for the extension is likely to help with the later.
Taking into Consideration the different scripts that have been used previously, I believe it is indeed possible. I will likely visit this idea sometime soon and see if I get access to any more information in the meanwhile. Thank you everyone for your comments and suggestions. RoCo(talk)12:18, 15 February 2017 (UTC)
How should we handle the case of Template:Wayback which was recently merged to {{webarchive}}. {{wayback}} is an old template that pre-merger had over 100,000 transclusions so it's widely known and used, thus deletion/red linking may cause disruption (ie. confusion about a replacement available). It also contains a few hundred non-transclusion links that would be disruptive to red link (it's not possible to create a redirect since the arguments and docs are completely different). Any other options, or just delete? -- GreenC17:32, 15 February 2017 (UTC)
There is a gadget used (User:Kephir/gadgets/rater) that is inadvertently swapping out Project Haiti with its former parent Project Caribbean as seen here [26] This is a problem that reoccurs now-and-then even after several attempts to amend its code, which was previously reported by Meno25 shown here [27] but has appeared to go unresolved. After many manual assessments by myself and others within the project, to have it systemically change constantly via usage of a gadget by other editors that come in and contribute to articles in good faith, indirectly (and unknowingly) undermine the project and sets us back each time. Is there a way to change this code to make sure it is going to WP:HAITI? We would prefer to manually include Project Caribbean on a case-by-case basis where deemed applicable to its entirely, such as geography-based articles etc. Project Caribbean sadly is also largely inactive, which furthers our need for this code to be amended as soon as possible. I was referred here by Meno25, in hopes of resolving this issue. Please ping me in a response. Thank you kindly. Savvyjack23 (talk) 20:53, 15 February 2017 (UTC)
Hello. To whom it may concern, while running some random Wikipedia articles in Google's Structured Data Testing Tool there are errors which show up. Does anybody know if this poses an indexing problem on Google's Knowledge Graph and if so does anybody know how to fix them? --Omer Toledano (talk) 07:54, 16 February 2017 (UTC)
This citation should have a PMC link, which would mean a correct number in the PMC field. The problem with the second citation is that it inserts the letters "PMC" before the number in the field. Removing those letters generates the correct citation, which is
I believe that consensus is that <br> should not be converted to <br/> unless there are substantive changes being made at the same time. I have no evidence to support this belief, however. – Jonesey95 (talk) 02:41, 13 February 2017 (UTC)
You're probably thinking of the fact that bots are prohibited from making this kind of change, basically because they clog up a large number of edit histories with no visible effect. Since humans can't edit as fast, someone making such changes presumably wouldn't encounter opposition; the likely response would be something like "why do that; you're wasting your time". Nyttend (talk) 02:53, 13 February 2017 (UTC)
Nyttend, in most cases you would be right, but in this case, I was actually thinking that the OP needed to see the words I wrote above, given the situation in which he has placed himself recently. – Jonesey95 (talk) 06:00, 13 February 2017 (UTC)
@Magioladitis: I am certain that I answered this question for you, some months ago. IIRC it was on a user talk page, not necessarily your own.
Anyway, the Wikimedia sites (including Wikipedia) serve HTML5, where (according to the W3C docs - don't believe all you read at W3Schools) the space and the slash of the <br /> tag are both optional. But when the tag has attributes, and the last attribute doesn't end with a quote character, for example
<brstyle="clear:both;"id=gap1/>
the space is mandatory if the slash is present. Even if there are no attributes, some browsers don't like the space to be omitted if the slash is present.
Until a few years ago, the Wikimedia sites served XHTML 1.0, where (regardless of attributes) the space is optional but the slash is mandatory. --Redrose64 🌹 (talk) 23:37, 13 February 2017 (UTC)
The last major browser to require a space before /> was Netscape 4.0, which was released almost 20 years ago. If anything since then can't handle a space, it's a browser bug. --Unready (talk) 01:39, 14 February 2017 (UTC)
@Unready: Consider a tag like <brid=gap1/> - is the slash part of the value of the id= attribute, or not? It might be; and so the unquoted attribute value syntax states
If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional "/" (U+002F) character allowed in step 6 of the start tag syntax above, then there must be a space character separating the two.
It therefore requires a space to resolve the ambiguity between <brid=gap1/> where it is part of the value, and <brid=gap1/> where it is not. --Redrose64 🌹 (talk) 12:41, 14 February 2017 (UTC)
Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single "/" (U+002F) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
So the presence of a slash before the greater-than sign does not make it XHTML, nor does it make quotes necessary; the self-closed form is both HTML and XHTML, and so if the document is declared as HTML in its <!DOCTYPE ... > (Wikipedia pages all begin with <!DOCTYPE html>), there is no need to observe the stricter XHTML rules. --Redrose64 🌹 (talk) 01:11, 15 February 2017 (UTC)
If I write <br> <br/> <br /> in a wiki page, all three of them get transformed by the MediaWiki software to <br />. So from a wikitext perspective, it doesn't matter which one you write, and there are no accessibility or compatibility considerations to worry about. WP:Line-break handling says "<br /> is preferred as it will be rendered correctly in all circumstances, including strict XHTML", which is nonsensical in view of the way these tags are actually processed by MediaWiki. — This, that and the other (talk)00:55, 14 February 2017 (UTC)
@Redrose64: That isn't the case. I tested this on my local MediaWiki installation, which definitely does not have Tidy installed, and the transformation occurred regardless. This is done by the slightly misleadingly named function Sanitizer::removeHTMLtags in MediaWiki's PHP code. — This, that and the other (talk)01:30, 14 February 2017 (UTC)
If you look into it you'll find Tidy is a distinct PHP extension that is called from MediaWiki code when enabled. (For interest, Tidy doesn't appear to be enabled at translatewiki:, so you might like to experiment in the sandbox there to see how things behave without Tidy.) In any case, suffice it to say that MediaWiki does more tidying that one might have thought. mw:Parsing/Replacing Tidy makes no mention of <br> tags, so we don't have anything to worry about in that regard. — This, that and the other (talk)10:31, 15 February 2017 (UTC)
As far as I'm concerned, <br> is valid wikitext, and whether it's valid in any particular output format or version of HTML pretty much irrelevant. We'll make it keep working one way or another. I recommend using it in that form in wikitext, without the slash, because it's shorter. This was my position during the XHTML era, and is vindicated now in the HTML 5 era.
WHATWG (the body that made HTML 5) denigrates the idea of XHTML in a few different places. In the syntax section of the HTML 5 spec, it has a kind of joke definition of XHTML which seems to serve only as an argument against its existence. As Redrose64 says, MediaWiki does not output XHTML, we use <!DOCTYPE html> which means we are outputting HTML 5. In HTML 5, self-closing tags exist only as a very limited backwards compatibility concession. Except for foreign content like embedded SVG, self-closing slashes are only recognised in places where they are unnecessary. For example, <div/> is a parse error and is interpreted as if the slash were absent: <div>. Only in void elements like <br> are they allowed, but void elements by definition do not require, and cannot have, closing tags. The HTML 5 fragment serialization algorithm, which defines conversion of a DOM tree to a string, requires that br elements be represented as "<br>".
During the XHTML era, we never actually output XHTML, we declared our output to be "XHTML transitional" which was really just tag soup with aspirations. But XHTML had mindshare and so it made more sense to be arguing about writing wikitext as if it were XHTML. Those days are over, so I don't think that there are two defensible sides of this argument anymore.
We'll soon be getting rid of Tidy on WMF websites in favour of a pure PHP solution called RemexHtml that I recently wrote. It should eventually become the default for new MediaWiki installations as well. It accepts either form and will initially output "<br />" for compatibility with parser tests. -- Tim Starling (talk) 10:03, 17 February 2017 (UTC)
Could one of your techno-wizards take a look at the automatic-archiving set-up for this talkpage and figure out what is wrong?
I had already posted about this problem on the article's talkpage: on Talk:Grigori Rasputin at: Talk Archive with no responses but here is the issue:
The automatic-archiving is working for the talkpage but the linkage isn't showing up on the article's talk page. And yes, I do know there are two different Archives for the (merged)"Rasputin's penis" talkpage and for the main article talkpage plus that both of the (manually archived) archives are malformed according to the Bots' naming conventions, they are named "Talk:[article name]/Archive#" instead of "Talk:[article name]/Archive[sp]#. The bot is doing its work correctly - there is a Talk:Grigori Rasputin/Archive 6 that it is moving content to - but the article talk page doesn't know that Archive 6 exists. Oh! and there is no Talk: Grigori Rasputin/Archive5 or Talk:Grigori Rasputin/Archive 5. Thanks, Shearonink (talk) 17:49, 17 February 2017 (UTC)
No, because a revert is merely an edit that cancels out the effect of one or more previous edits. They're not marked in any special way, except that some reversion methods (such as WP:ROLLBACK) use a boilerplate edit summary. --Redrose64 🌹 (talk) 01:01, 14 February 2017 (UTC)
Users with the rollback privilege can mark edits and their rollback as a bot edits, even if it's interactive. That's as close as you're going to get. --Unready (talk) 04:07, 14 February 2017 (UTC)
"Users with the rollback privilege can mark edits and their rollback as a bot edits, even if it's interactive." UH? Since when (and how? but because of WP:BEANS, by email please) can you do that? That seems like a terrible idea too. Headbomb {talk / contribs / physics / books}12:49, 14 February 2017 (UTC)
It's not part of the rollback right (or the rollbackers group), it's the markbotedits right that sysops have. The "how" is documented at mw:Manual:Administrators#Rollback. As for "since when", apparently since December 2003, although back then it was just part of the sysop package. It was moved to the rollback right in October 2004, seemingly broken in November 2007 due to a typo, and took its modern use of the markbotedits right in August 2008. Anomie⚔13:47, 14 February 2017 (UTC)
That seems like a terrible idea... The idea, as the manual link above says, is to hide vandalism (which is when someone would/should use rollback) from Recent Changes, although it still doesn't hide it if users choose to show bot edits. Also, oops, it's a separate privilege associated with rollback, not rollback itself. --Unready (talk) 22:15, 14 February 2017 (UTC)
Module or other way to convert spaces to underscores in a string
I'm looking for a way to take a string like "John Doe" and convert it with a module or some other method to "John_Doe" for use in a URL.
Full disclosure of my goal: I stumbled across Template:Cite Banglapedia/testcases, created by Worldbruce, and I'm fiddling with the |url= and |title= parameters of the template. The title is added to the end of the URL; the title parameter should display with spaces in the citation, but it needs to have underscores when it is used in the URL. – Jonesey95 (talk) 17:24, 17 February 2017 (UTC)
BTW, I created the testcases in part to highlight misgivings about certain aspects of the design of the recently created template, including its construction of a full url from a partial url (the title with underscores substituted for spaces). Since Banglapedia went online, they've gone through no less than eight different url schemes. Until the most recent one, they've all be more cryptic, like http://banglapedia.org/HT/C_0308.HTM being the url for their article titled "Comilla District" (although in an earlier or later scheme C_0308 might have been the code for a completely different article beginning with "C". Perhaps their current urls are regular enough and stable enough that Wikipedia can safely construct them from article titles. {{EB1911}} and similar templates construct urls for wikisource articles, but whereas we may have considerable influence over a sister project's urls, we have none over Banglapedia's.
I didn't expect this template to be of interest to anyone outside of the small Bangladesh-related-articles community, but the additional technical minds are very welcome. --Worldbruce (talk) 18:10, 17 February 2017 (UTC)
Hi all, I raised a question on the talk page but am keen to see if this is a more general problem - on pages using {{Talk header}} I cannot see any archives box with links to the archives. For example: Talk:Rodrigues, Talk:Human body, or even Template talk:Talk header.
I cannot see any relevant changes to that template but don't know markup well enough to trace anything back to the transcluded templates. Is this just me and my setup (maybe I broke it with a preference change)? Thanks for looking. BW |→ Spaully~talk~09:17, 18 February 2017 (UTC)
Done Thanks, all sorted - I had changed back to MonoBook but had a custom .css that I had last edited in 2009 including "#talkheader {display:none;}", funnily enough that suppressed the talk header. Please ignore my stupidity! |→ Spaully~talk~12:07, 18 February 2017 (UTC)
Script request for checking sources
Not sure if this is the right place to post this, so please let me know if there's a WP:SCRIPTREQ or something similar. I just did a source review on Æthelflæd, part of which was a tedious manual process that I think could be partially automated. The citations look like this:
Keynes & Lapidge 1983, pp. 11–12.
Stenton 1971, pp. 246–248.
Williams 1991b; Williams 1991c.
...
and the bibliography looks like this:
Abels, Richard (1998). Alfred the Great: War, Kingship and Culture in Anglo-Saxon England. Harlow, UK: Longman. ISBN 0-582-04047-7.
Bailey, Maggie (2001). "Ælfwynn, Second Lady of the Mercians". In Higham, Nick; Hill, David. Edward the Elder 899–924. Abingdon, UK: Routledge. pp. 112–27. ISBN 0-415-21497-1.
Baker, Nigel; Holt, Richard (2004). Urban Growth and the Medieval Church: Gloucester and Worcester. Aldershot, UK: Ashgate. ISBN 0-7546-0266-4.
...
I dropped both lists in Excel, scraped off some unnecessary text, alphabetized both, and was then able to run down both lists at the same time and verify that every citation had a bibliographic line corresponding to it, and every work in the bibliography was used.
I don't think a script could reliably do the verification, because there are plenty of exceptions that will come up, but just the basics of alphabetizing the two lists and presenting them in such a way that an eyeball comparison could be done would be a huge time-saver. Is there a way to write a script to do this? Mike Christie (talk - contribs - library) 22:20, 18 February 2017 (UTC)
For Harvard citations it does, but the need to do this is general to all forms of citation. (Thanks for pointing that out, though; I don't use Harvard citations myself and didn't know about the script.) Sino-Roman relations is an example of an article that doesn't use Harvard citations that needs this capability. Mike Christie (talk - contribs - library) 10:36, 19 February 2017 (UTC)
The tag is useful when dating a statement that is expected to change with the passage of time. Unfortunately, it is only useful at the beginning of a sentence, because it forces an upper case 'a'. If the editor tries to use it in mid-sentence, eg. "Many banknotes still carry his signature, As of February 2017[update], from his term as governor.", the upper case "A" is inappropriate. Is someone able & willing to modify the tag to follow the editor's intention for either 'a' or 'A'? Akld guy (talk) 04:14, 19 February 2017 (UTC)
Thank you. I think, though, that after reading about how to use the tag, I shouldn't have to also read the template article for a detail like that. That fact should be in the WP:As_of article itself. If nobody bothers to insert it, I will. Akld guy (talk) 04:42, 19 February 2017 (UTC)
By "the template article", I assume that you mean its documentation - the part of the template inside the green box that is headed "Template documentation". The template documentation should be the first place to look for information about the template's parameters. --Redrose64 🌹 (talk) 07:59, 19 February 2017 (UTC)
Yes, that's what I meant - the link is provided by Huntster above. In this edit, I've made it more obvious at WP:As_of that the template documentation needs to be referred to for optional parameters. Akld guy (talk) 11:34, 19 February 2017 (UTC)
I don’t think there is. A bot could be instructed to do such a task, but In most cases it makes no sense to do so. I mean, if you are moving the page to Peter Adamson (actor) to disambiguate the name, then some of the links to Peter Adamson might be ones which also need disambiguating, as people have linked to the actor but meaning to link to someone else. That is often the driver of disambiguation, when many incoming links are inappropriate. In which case automatically updating them makes no sense: better to manually check them and fix them on a case by case basis.--JohnBlackburnewordsdeeds13:45, 20 February 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The edit summary box is now a little bit bigger. This is to make it follow the Wikimedia design guide. [29]
Changes this week
Page Previews will be updated on 23 February. This fixes many bugs. Page Previews can be turned on as the Beta Feature called Hovercards. [30]
There has been a problem where the CSS of gadgets has been loading twice. The Gadgets extension has two new options: type and peers. The type option solves this problem. You can use peers to create gadgets with more than one style module. Read more about type and peers. [31]
OAuth will handle blocked users in a more consistent way. [32]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 February. It will be on non-Wikipedia wikis and some Wikipedias from 22 February. It will be on all wikis from 23 February (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 21 February at 20:00 (UTC). See how to join.
The user interface in MonoBook skin has changed. When editing a page, the edit summary window takes up more space then it did before; and when creating a new section, the section heading box is bigger. Both have a blue border when they have focus. Blue border - good; more occupation of real estate - bad. --Redrose64 🌹 (talk) 21:55, 16 February 2017 (UTC)
Can you please make some option to turn off all the animations? They are useless and annoying. And why the summary input is now always narrower than the available width? Even before the summary text was not always fitting in the visible area, but now it is even worse (and this meaningless arbitrary right margin does not seem to serve any purpose). — Mikhail Ryazanov (talk) 00:20, 18 February 2017 (UTC)
When using just Firefox, my edit summary box displays well; but when I have wikEd turned on , its edit summary window is now almost useless, which I assume is related to these changes. Dhtwiki (talk) 00:42, 19 February 2017 (UTC)
For like 10 days now, my edit summary textbox has turned so slim that the input texts have become illegible. I am able to view only the middle portion of the typed text. I haven't made any changes to my preferences. I noticed that somebody raised an issue about wider textbox earlier but mine is exasperatingly slender. I am using Firefox 51.0.1. Any help? Hitro talk18:10, 21 February 2017 (UTC)
Different IP (four tilde) compared to running Windows CMD tool - ipconfig
Background - I have moved (in the real world) and had hence to change my internet supplier. As I was about to change my e-mail address , I accidentally happened to see that my IP - made by the foure tilde signs, if one isn't logged on, differed from what my IPCONFIG tool state my IP is. And I have had 192.168.1.94 for longer than a fortnight now. But the tilde signs states my IP is 81.230.36.59 - at the one and same time !. Further, someone has (externally) mixed with my computer somway. I could't take screenshots - after in a mail recommended an other user to use the PrtSc keyboard button. Many effects, like sound were also delayed about 8-10 seconds. So I re-installed Windows. Could anyone please help me ? Am I under surveillance, by some one with admin-tools. Perhaps from an other Wiki ? Or do we get a new IP each time we use Wikipedia ? - simultaineously with the "normal IP", presented by the IPCONFIG-command ? I'm a programmer of embedded systems, but TCP/IP and networks are really not my cup of tea, if I may express myself in that way ? Any honest comments would be much appreciated. Boeing720 (talk) 00:53, 21 February 2017 (UTC)
Your computer connects via a cable or wireless to your router which also acts as a modem to connect to the ISP (internet service provider). The network card in your computer has the 192.x.x.x IP address, but the connection to Wikipedia actually comes from your router (81.x.x.x) so that is what is shown at Wikipedia or sites which display your IP address like this. See network address translation for a lot of detail. Johnuniq (talk) 01:06, 21 February 2017 (UTC)
Hello and thanks , Johnuniq! A good explanation, and I will study your suggested information further. It was however, already through your reply, relieving to read. Thank you very much again ! Boeing720 (talk) 09:43, 21 February 2017 (UTC)
@Boeing720: Any IP address which begins 192.168 (but not others beginning 192) is within a private network; they show as some other IP address when seen from outside that network.
From Wikipedia:Potentially_unreliable_sources#Wikipedia_mirrors and the next section covering SELFPUB companies, is there any way to automate stopping these additions? All of them seem to propagate via Google Books alone. More specific examples, at WT:INB, books by the Gyan publication keep getting used as references and Gyan is shown to be a mirror our articles without acknowledgement, even with their own authors and dates. Right now, dedicated editors have to keep a tab on their occurrences here via linksearch (routine cleanups), since they keep cropping back up.
Since they do not concern a single url, the usual Mw:Blacklist, filters or XlinkBot can't be used normally. The only thing playing in my head is making XlinkBot have this additional function which checks any edit with a GB link, uses the available GB citation tools to extract the publisher, compares that to its own blacklist and then acts. Is this feasible or are there any better ideas? Ugog Nizdast (talk) 07:46, 14 February 2017 (UTC)
Shouldn't be hard for the bot to find it. Google Book webpages contain metadata in the page source, including a line labeled "publisher". Should be feasible for a bot to check new links to Google Books, pull out that metadata, and then if the publisher appears to be on a blacklist, add the diff to some page for review by a human. And of course if it's just amazingly efficient, enable the bot to just revert. Someguy1221 (talk) 08:35, 14 February 2017 (UTC)
I could add this, given time (which I don't have too much). I would however blacklist those on sight, it otherwise keeps eating editor's time. Today you see one, research and remove, tomorrow it is someone else who has to go through it, and the day after ... XLinkBot may however be a good detection. I need to have a look how to do this. --Dirk BeetstraTC13:37, 18 February 2017 (UTC)
Can I have a couple of specific examples of this (preferably popular ones). I may already have this functionality, but am not sure if it was thoroughly tested). --Dirk BeetstraTC13:45, 18 February 2017 (UTC)
Do you know more on how GB works? all I know is it's extremely unpredictable in terms of content and links. I've recently seen an old link to a history book take me a random book about my horoscope. In addition to that, catching each of the publication's books on sight would seem a big task compared to just blacklisting it by its name. This one-by-one method also wouldn't prevent future additions which will have to be "registered" to be prevented.
I would indeed expect that each book has a unique and identifyable ID that we can match in the blacklist. If one book gets varying IDs then it becomes problematic. \bbooks.google.*?id=alllAwAAQBAJ\b should do that.
I have brought the discussion to the spam blacklist, here, but I will leave that open for discussion until we decide that we really want to blacklist this stuff (I haven't seen any evidence of spamming, and I hence am somewhat reluctant to pull the trigger purely on an 'it is not reliable' reason, I'd prefer to have community input on that). --Dirk BeetstraTC06:11, 20 February 2017 (UTC)
A couple of questions. We need evidence of spamming and discussion for the mw-blacklist, right? I feel we won't get any blatant and repeated instances because this isn't clear-cut spamming. This is more a slow but persistent problem which is usually done by AGF editors (mostly new) who didn't know better. Atleast two additional experienced editors whom I know of and who usually deal with this cleanup haven't been active enough for joining this discussion. For discussions, just typing that in the archives search of WP:RSN and WT:INB show a lot.
Can't get diffs but I can demonstrate its prevalence here, just use "insource:Gyan" for instance. However, maybe because being unfamiliar with this issue, I'm having my own doubts about this specific house, I just did the search and so many FAs and GA articles from the first result page itself have it! Earth, India, Cold War! @Fowler&fowler:, at India, this has been there for long, are you aware of this publication or it being used as a source? Also once again pinging (if available) Sitush and SpacemanSpiff about Gyan being is so many high quality articles?
About blacklisting it, it's a good immediate fix but won't it be a really big list in the end? Just this one publisher I mentioned above seems to have a lot of books, this list is going to swell and how can we be sure we've covered them all? And how permanent are these unique ids? Are we sure they won't change later to some other book? Ugog Nizdast (talk) 08:18, 20 February 2017 (UTC)
Hi, I've never heard of these publishers, and can't really speak to their reliability, or lack thereof. I typically only use established scholarly publishers, such as Oxford, Cambridge, Wiley, Routledge, Blackwell etc. Fowler&fowler«Talk»11:51, 20 February 2017 (UTC)
Tyagi's Martial Races of Undivided India is perhaps the most notorious example from Gyan that I regularly clean up. There will be a couple of examples at User:Sitush/Common#Gyan. The problem is that Gyan were publishing before WP existed and some of there earlier things thus certainly cannot be mirrors, although they may still be violating the copyright of other authors/publishers. - Sitush (talk) 13:29, 20 February 2017 (UTC)
@Ugog Nizdast: We generally only blacklist if there is sign of abuse. However, if, e.g. a source comes back 10 times in different contexts on WP:RS/N then we can, based on these 10 discussions say that there is community consensus that these sources should not be used, and use that consensus in a WP:IAR way to use the spam blacklist for that. I will personally not blacklist on a 'hey, this is unreliable, blacklist it' (I am not that rogue), I will however if there are several discussions showing the same trend. A similar example are the high-profile porn sites - they are not spammed, they are not spam (in Wikipedia terms), and actually in specific cases these links are of use .. but we can show persistent abuse of the links to a level that restriction and using whitelisting is much less damaging to Wikipedia (and to many BLPs specific) than allowing the vandalism/abuse to continue. I opened the thread on the SBL to get some of this data, links to a handful of discussions and/or people agreeing etc., and I will then happily pull the trigger (I am keeping an eye on the discussion).
@Sitush: The blacklist would disallow specific books, allowing the rest of the same publisher. XLinkBot would in principle revert all books of a publisher (if I can have it understand it), but there would be a possibility to whitelist books that should not be reverted.
{{rto}} If there would be abuse by such publishers (which then would qualify as 'them spamming Wikipedia with their books') then I would indeed not hesitate to pull the trigger without waiting for reliability discussions. Note that next blacklistings of such material will be performed faster, we just point back to the precedent. --Dirk BeetstraTC11:40, 22 February 2017 (UTC)
I'd like to include in an article what I could call a "family tree in linear text format" such as the one I included [33] here on the French Wikipédia, at the end of the article. I know that classical trees (with boxes) are available on the English Wikipedia, but is there also a mean to produce such "linear text format" trees? I don't know where to find the answer. Thanks beforehand for any help.
This is an example of the French syntax that is used:
{{Arbre début}}
* '''Samuel Woodforde''', ''théologien, poète et membre fondateur de la ''[[Royal Society]] <small>(1636 - 1701)</small>
** '''Heighes Woodforde''', ''recteur d'Epsom (Surrey)'' <small>(1664 - 1724)</small>
*** {{Arbre/Branche finale}} ''descendance de Heighes Woodforde''
** {{Arbre/Branche finale}} '''Robert Woodforde'''
{{Arbre fin}}
QUESTION: What is the exact default html hex color code for hyperlinks on templates - for example, what is the default color code for the right-hand margin hyperlink text of the Template:Nature timeline ( or {{Nature timeline}} ) - I'm trying to match exact colors if possible - the following blue color code in the template seems close, but not exact => <div style="line-height:9pt"><small>[[Cambrian explosion|{{font|size=90%|color=#0052cc|'''Cambrian explosion'''}}]]</small></div> - in any case - Thanks in advance for your help - and - Enjoy! :) Drbogdan (talk) 15:10, 22 February 2017 (UTC)
mw:Extension:ImageMap can do it but making an image map can be a lot of work. It also makes a clickable link for each defined area. I don't know whether the link can be disabled but if it's a link to a non-existing anchor on the same page then clicking may have no effect in browsers. PrimeHunter (talk) 23:32, 19 February 2017 (UTC)
Hello. I am trying to do an ImageMap . I am using polygon selection. Do you know if there is a software that can select an area (maybe by color or by magic wand) to find the coordinates? Polygon selection is not the best solution. Xaris333 (talk) 14:50, 21 February 2017 (UTC)
Quick way to find out how many GARs opened in a certain time period?
Is this possible?
The only way I have been able to find to count GARs is by opening all the pages in a category and checking the dates on each one individually. Are they arranged chronologically anywhere, even in an approximate manner like noticeboard archives?
The reason I ask is because the GAR instructions were radically altered last March, and I suspect this might have had the effect of making the process more difficult and thus discouraging its use. So I'd like to know how many GARs were opened since March 2016 compared to how many were opened in the previous eleven months.
I'm not aware of any such page, but one can try to cobble something together with search, like this, or this, which search talk subpages and subpages of Wikipedia:Good article reassessment respectively. Both of these sort by the date that page was last edited, which isn't quite right, but better than nothing. Pppery19:12, 22 February 2017 (UTC)
I assume an action is watched if there is at least one enabled setting saying to watch it. I don't see a problem with some overlap. Uploading a new file creates a file page so uploads are a subset of page creations which is itself a subset of edits. It would be possible to make all settings disjoint but then you get silly options like "Add pages I edit except pages I create". Who would choose that without also choosing "Add pages I create"? PrimeHunter (talk) 10:24, 23 February 2017 (UTC)
By that argument, the first option should be "Add pages I create to my watchlist" - this would cover all pages created (including files), and remove the disjointedness. Optimist on the run (talk) 11:04, 23 February 2017 (UTC)
It said that in the past before a setting was added to only watch uploads. Many users wouldn't know whether an upload counts as a page creation. PrimeHunter (talk) 11:49, 23 February 2017 (UTC)
The action of uploading a file is distinct from creating a page. If you upload a new version of an existing file, you are not creating a page, so only the setting in "Add new files I upload to my watchlist" would be used. On the other hand, if you create a file page by clicking the "Create" tab (such as creating a file redirect), you are not uploading a file, so only the setting in "Add pages I create and files I upload to my watchlist" would be used. If you upload a brand new file, then the page would be added to your watchlist if one or both of those settings are checked (as PrimeHunter suggested). I haven't verified any of this, but it seems likely that this is the way it would work. — This, that and the other (talk)12:25, 23 February 2017 (UTC)
Watchlist
Is there an ongoing issue with the 'mark all pages as visited' button? Appears when first clicking on watchlist but then vanishes as the page completes loading. (Using Chrome). Thanks. Eagleash (talk) 01:28, 17 February 2017 (UTC)
Same here: Mobile Safari on iPad: brief glimpse as page loads, then it's gone. I also noticed more spacious text boxes—the edit summary, for instance—that are very welcome! — Gorthian (talk) 02:28, 17 February 2017 (UTC)
It should then be unhidden if any of the two following gadgets are enabled: "Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes" and "Display pages on your watchlist that have changed since your last visit in bold". They both include:
That worked. My thanks! Now someone needs to fix the edit summary line that seems larger but covers up part of the text. —ATS 🖖 talk02:38, 17 February 2017 (UTC)
Worked for me too. With regard to the ES box, the box for adding the heading after clicking 'new section' also appeared larger when starting this 'thread'. Thanks PrimeHunterEagleash (talk) 02:58, 17 February 2017 (UTC)
@Eagleash: I don't think that the increased size of those boxes is anything to do with the 'mark all pages as visited' button problem. See the section above - the box change occurred by 21:55, 16 February 2017, some hours before Krinkle's edit (00:47, 17 February 2017). --Redrose64 🌹 (talk) 21:40, 17 February 2017 (UTC)
The gadget definitions have been corrected by Amire80 since, and this problem should be fixed now (it is for me at least on Vector). The new gadget feature that triggered this, gives lots of opportunities to remove the late changes to the UI changes when the page loads btw. So gadget authors can get to work :) —TheDJ (talk • contribs) 12:03, 17 February 2017 (UTC)
Don’t know if this is related, but for the first time in a while my watchilist is bolding unvisited pages. That’s as well as the green dots that are the advertised way of highlighting such pages. Tried clearing my browser cache in case but it made no difference. It’s happening whether or not I have 'Expand watchlist to show all changes, not just the most recent' enabled.--JohnBlackburnewordsdeeds12:38, 17 February 2017 (UTC)
No, that is off. I did not realise there was such an option, I must have turned it off a long time ago. So confirming: " Display pages on your watchlist that have changed since your last visit in bold" is off, but my watchlist is bolding all items I have not visited.--JohnBlackburnewordsdeeds14:30, 17 February 2017 (UTC)
You are not alone. My check box is unchecked (has always been unchecked); my watchlist has gone bold (before Thursday wasn't bold). Hasn't this just recently been broken and then fixed? And now is broken again? Why? How about fixing it and leaving it fixed? Is that so hard?
Why? You wrote in your reply to Editor JohnBlackburne that his "Display pages on your watchlist that have changed since your last visit in bold ..." button ... is on. You jumped to the conclusion that this problem was his fault. Clearly that is not true.
Is it not true that we have recently had this problem? Did it not recently get fixed? Is it unreasonable to ask why we are broken again? Is it unreasonable to ask that it get fixed and remain fixed?
Tried toggling that setting, in case it did something. Nope, no change switching it on or off. Yes, L.S. inc. was a bit presumptuous assuming it might be my fault, but they are a new user, may have just discovered how it worked themselves, so may have assumed it’s new to other people. L.S. inc., if you enable Navigation Popups on the same prefs panel you can easily see when editors have been around for a while and probably have a lot of experience of WP.--JohnBlackburnewordsdeeds15:42, 17 February 2017 (UTC)
" Is it unreasonable to ask why we are broken again? Is it unreasonable to ask that it get fixed and remain fixed?" not unreasonable, but yeah. gadgets and user scripts break. That's what they do. This one is easily fixable. Unfortunately i'm going on vacation, so I can't get around to this as fast as I would like... —TheDJ (talk • contribs) 16:57, 17 February 2017 (UTC)
This (the bolding of every unvisited page on my watchlist) is a bit annoying. But what a I really don't understand is why a gadget breaking effects me when I don't have that gadget enabled? Jenks24 (talk) 22:43, 17 February 2017 (UTC)
Bolding is the default in MediaWiki itself. If no gadgets are enabled or work then you get bolding. The English Wikipedia has chosen to remove the bolding with a default gadget: "(This loads the base style for the watchlist. Please do not disable this option.)". Another gadget can add it back (if it works): "Display pages on your watchlist that have changed since your last visit in bold". PrimeHunter (talk) 23:15, 17 February 2017 (UTC)
OK, that makes sense. Though I suppose figuring out why it's the MediaWiki default isn't worth going into. And the bolding problem has now been fixed, thanks to whoever did that. Jenks24 (talk) 00:28, 18 February 2017 (UTC)
Why exactly are we telling people not to disable that gadget? Surely watchlist style should be each individual editor's choice about whether they want green dots and/or bold-faced titles. "Please do not disable" makes it sound like we're discouraging people from having whatever style they want. WhatamIdoing (talk) 20:32, 20 February 2017 (UTC)
@WhatamIdoing: It predated 'hidden' gadgets, and it was because we changed the site wide defaults (you could reenable with the 'bold' gadget two gadgets lower). We can do some further cleanup there, but we probably have to do some experimenting on test.wp first. —TheDJ (talk • contribs) 21:39, 23 February 2017 (UTC)
I'm running Windows 10 with the latest version of the IE browser [not Microsoft Edge, of which I'm not fond], and when I try to load this file, I get nothingness; clicking on it returns the same results as merely loading the file page. I'm tempted to delete it under Commons:GCSD#1, but before that I'd like input from someone with a different computer — ideally, an Apple user who's using neither Windows nor IE. Can you load this file? Nyttend (talk) 12:24, 23 February 2017 (UTC)
The PDF loads in Microsoft Edge with screwy fonts, and in Google Chrome with garbled characters in part of the heading, so I suspect the PDF is slightly corrupt (or at least, poorly generated). It displays correctly in Adobe Acrobat. In any case, I don't think it is in scope for Commons (PDF files are rarely in scope), so it ought to be deleted one way or another. — This, that and the other (talk)12:30, 23 February 2017 (UTC)
Using Chrome on a Mac, it "almost" comes thru perfectly. But actually the "almost" is important. The title, everything above the foto except the word "(Guadalajara)" is all scrambled in crazy fonts. Hope this helps. Let me know if you want me to save the foto, but all I know how to do is take a screen shot. Smallbones(smalltalk)01:40, 24 February 2017 (UTC)
Two questions from a newbie template editor: template insertion via Twinkle RfD nom + parsing a string in template
Apologies if this is misplaced, but I could really not find a better place to ask. I recently created {{link current revision}} (it took a bit of trial-and-error but I got what I wanted) and have two related questions (please see the template doc).
I wish to add a way to link to the current revision with a particular section anchor, so as to be able to make calls such as {{subst:link current revision|Wikipedia:Help Desk#Some section of interest}}. Algorithmically, it is fairly simple: if the page argument includes a # (e.g. Foo#Bar) then split the string at that point, apply the regular processing to the first part (Foo), then append "#" + the second part (#Bar). However, I could not find a way to do that in mediawiki language in Help:Template and related pages - does this need Lua modules?
The page Freedom of speech in the United States does not appear as a suggestion when typing in the search box. This happened on both my Android smartphone using Chrome and on my laptop running Windows 10 using Firefox. After completely typing the article name and pressing enter, I am taken to the article and there's nothing under the title saying "Redirected from X". On the Windows laptop, I didn't previously have that page open (Firefox clears all data when it's closed). Also, the article is not new. AHeneen (talk) 13:55, 23 February 2017 (UTC)
AHeneen, what precisely did you type? The search box can be really finicky if you don't do things precisely the way it likes them, so giving the precise text string will help with the diagnosis. Nyttend (talk) 16:15, 23 February 2017 (UTC)
@AHeneen: I looked at the data the search engine had about the page and it was empty. These kinds of errors are very rare but they do crop up sometimes for a variety of different reasons, some of which we know about and some of which we don't. This was possibly caused by a full reindex of enwiki content that we did recently, but it's hard to say for sure. Normally the best advice I can give is "make a null edit and wait 24 hours" which will fix most problems with pages being missing from search. Since making a null edit, the search index now has information about the page (as you can see from ?action=cirrusdump) so the search box should pick up the article in the next 24 hours or so. Hope that helps! :-) --Dan Garry, Wikimedia Foundation (talk) 16:46, 23 February 2017 (UTC)
For some reason, searching "Sweden Democrats" in the search bar doesn't give the party's article as a result until the last letter (i.e., exact title) is typed; even up to "Sweden Dem", only Sweden Democratic Youth and Sweden-Denmark relations are offered as results. Any insights as to why? The party's Swedish name Sverigedemokraterna seems to be similarly affected; none of the other Swedish political parties are similarly affected. Mélencron (talk) 01:30, 23 February 2017 (UTC)
Hello. I want to use a picture. Under the picture I want, if I click one it, to show a list. Is there an example of that in an article to see how it can be done? Xaris333 (talk) 13:02, 25 February 2017 (UTC)
Not really, afaik. You can have an image and you can have a collapsed list, but you expand the list by hitting show, rather than clicking the image. --Tagishsimon (talk) 14:52, 25 February 2017 (UTC)
US gallon -> litre conversion is inconsistent
At MV Joyita, {{convert|2,500|USgal|litre}} resulted in "2,500 US gallons (9,500 L)". Fair enough, and a second conversion with 3,000 US gallons resulted in 11,000 L. The ratio 2500:3000 is 1.2, and therefore the second conversion should have resulted in 11,400 litres. What's wrong here? Akld guy (talk) 14:22, 25 February 2017 (UTC)
@Akld guy: That's probably too precise, rounding to the nearest 1 litre – per MOS:CONVERSIONS "Converted quantity values should use a level of precision similar to that of the source quantity value". I would suggest using |sigfig= e.g. {{convert|3000|USgal|litre|sigfig=3}} → 3,000 US gallons (11,400 L), or use a negative number for rounding e.g. {{convert|3000|USgal|litre|-2}} → 3,000 US gallons (11,400 L) - Evad37[talk]15:00, 25 February 2017 (UTC)
Can't log into Wikipedia sites using Safari browser on Apple devices
Beginning from a few days ago, I have been having trouble logging into all Wikipedia sites (specifically the English versions of Wikipedia, the Wikimedia Commons, and the Wiktionary) on my iPhone and iPad using the Safari browser (not sure which version – how do I check?). I get the error message:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
I cannot bypass this message, and neither reloading the page nor going to some other page helps. I do not know if Safari's built-in function for autofilling user-ids and passwords is causing the problem, but even if I manually enter the user-id and password the problem occurs. I tried reporting this issue to the Phabricator, but since it seems to be specific to Safari (the problem doesn't seem to occur with the Mozilla Firefox browser) I was told that it was not a problem on the Wikipedia side. Any idea how to solve this problem? — SMUconlaw (talk) 11:49, 11 February 2017 (UTC)
So no one else is experiencing this problem, and nothing can be done about it? I'm still unable to log in on my mobile devices, which is very annoying. — SMUconlaw (talk) 17:34, 17 February 2017 (UTC)
@Smuconlaw: Tried just now and it works fine for me. For reference, I'm on an iPhone 6S with iOS 10.2.1 (latest version). Find your version number by opening the Settings app -> General -> About -> Version. If you're on an older version of iOS, update by going to Settings app -> General ->Software Update. -FASTILY07:29, 22 February 2017 (UTC)
I'm using iOS 10.2.1 too. This is really strange. Do you use Safari's saved passwords feature? I wonder if that is causing the problem. — SMUconlaw (talk) 10:11, 22 February 2017 (UTC)
Yes, I do, and it does not cause me any problems. It sounds like you have a broken/corrupt cookie. Try deleting cookies/temporary files by opening the Settings app -> Safari -> Clear History and Website Data. Next, close all your open tabs in Safari. Then, kill all running apps on your device and reboot it. Do this for each device. That should fix the problem. -FASTILY03:33, 23 February 2017 (UTC)
Hi, i'm from Bengali wikipedia. I need help. Sometime i use WP:AWB there. I need help with regular expression. I have a words like [[ঢাকা|ঢাকার]] and i want to replace it with [[ঢাকা]]র. How can i do it using regular expression? --Aftabuzzaman (talk) 21:44, 25 February 2017 (UTC)
Is your red character a variable item? s"\[\[ঢাকা|ঢাকা\([^\]*]\]\]"\[\[ঢাকা\]\]\1" will do the replacement in sed. (that's not AWB though) The number of "\" may differ depending on the shell. Graeme Bartlett (talk) 22:24, 25 February 2017 (UTC)
If I've missed something glaring, let me know. Otherwise, please direct me to where I can report this as a bug. Many thanks. YBG (talk) 01:48, 26 February 2017 (UTC)
Many things are possible, but what's the use case, and is that a valid use case ? The infobox is meant as a single element on a page or section, to describe the facts of that topic. It is highly recognisable element that creates expectations both for readers, but also for software reusing our content. If you need to use two next to each other, than you are breaking those expectations. —TheDJ (talk • contribs) 12:34, 27 February 2017 (UTC)
I meant Infoboxes like Battle, Bilarerial relations, Couple, that could have 2 and more equal sides. We have additional infoboxes in infoboxes ex. Template:Infobox album, details in Template:Infobox#Subboxes. subInfobox in table is for Subbox- Kareyac (talk) 12:59, 27 February 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
On 22 February the wikipedia.org portal did not work for an hour. This was because of a problem with a JavaScript file. [36]
Changes this week
You will be able to use <chem> to write chemical formulas in the visual editor. Previously this only worked in the wikitext editor. [37]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 February. It will be on non-Wikipedia wikis and some Wikipedias from 1 March. It will be on all wikis from 2 March (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 28 February at 20:00 (UTC). See how to join.
Future changes
You can soon upload 3D files to Commons. The file formats are AMF and STL. The plan is for this to work later this week but it could be later. [38]
The name "Wikipedia" will be more obvious at the top of the page when you read Wikipedia in the mobile view. This is because many readers don't realize they are on Wikipedia. [39][40]
@Fireattack: Please describe what you are seeing, and what you are expecting to see a bit more thoroughly. "visually broken" doesn't really help people, as they can't see what you are seeing on your screen. —TheDJ (talk • contribs) 21:15, 27 February 2017 (UTC)
@TheDJ: Sorry I thought it's pretty obvious if you open the link. There are a whole batch of magnifying glasses, instead of just one. And they're blocking/overlapping on what you type in.
This is based on numerous RFC's such as RFC3986 which say URI's (which are universal objects) only use percent encoding. URL's from Wikipedia can be used by bots and other downstream processes (Wikidata) without requiring built-in HTML decoding engines, or a built-in Wikitext decoding engines, or whatever-decoding engine. Bots and other downstream process can rest assured there is no mixture of multiple encoding types within a URI which result in ambiguous encoding that's impossible to decode. This is why url encoding was created - a single universal encoding type for URIs.
I'm a bot writer and constantly running into URLs that I can't decode easily or at all. For example {{BillboardURLbyName}} instructs editors to use it within CS1|2 templates .. I can't decode that nor can anyone else who isn't the Enwiki rendering engine. It even gets mixed together with a normal URI like this.
This is surprising. Is that documented somewhere? It creates all sorts of issues with bots and other processes. For example, migrating URLs to Wikidata. Link rot bots maintaining dead links. -- GreenC13:47, 28 February 2017 (UTC)
Log sheet missing on AfD
Afternoon all,
The log sheet for the 19th February appears to be missing on the main WP:AFD page. I have found it manually, but cannot see as to why it has been ommitted? Thanks NördicNightfury13:50, 28 February 2017 (UTC)
Has there been any attempt to create a modified version of the Abuse Filter extension that would apply to single pages only? I'm not talking about a local edit filter that's applied to one page only — I'm interested in a hypothetical piece of Mediawiki software that would work the same way but be able to work with one page only. Of course it doesn't exist; I just wonder about past history before making a formal request for a new feature. Rationale: our Wikipedia:Artist biography article template page repeatedly has its contents replaced with actual biographies, which isn't good, but creating an edit filter that checks every single edit made to Wikipedia would be a poor use of resources. It would be nice if we had the ability to create a filter specifically for this page that would reject an edit if it met certain criteria, without worrying about the filter checking edits to other pages. Nyttend (talk) 12:24, 28 February 2017 (UTC)
Such a technology would prove useful in a variety of pages. It could eliminate most cases of page protection resulting from meme-based vandalism or BLP violations. Ian.thomson (talk) 12:28, 28 February 2017 (UTC)
Do I understand that the reject reason was not "this is a silly idea" but rather "this wouldn't save performance", i.e. no point in doing it? Nyttend (talk) 19:15, 28 February 2017 (UTC)
Help fixing broken template display
(Background). I am hoping someone can help with the broken display of {{Birdsong}}. The template links to audio file listings at a well known ornithology website, but also allows up to four Commons audio files to be linked. It displays fine for me when not linking to Commons files. However, it displays like this for me, when a Commons audio file is invoked – I am viewing on a mac using the latest Firefox. The screenshot of its broken output is from the example use in the template's documentation for a Commons file. The display problem does not seem to affect everyone.
I imported the template from fr:Modèle:Chants d'oiseaux, where the documentation makes use of the same audio file from the Commons as its corresponding example of a Commons file use, and where it displays fine for me despite being the same use – indicating there must be some difference between the French original's code, or how it's working, and my imported version. Can someone take a look for a fix? Thanks.--Fuhghettaboutit (talk) 19:55, 28 February 2017 (UTC)
@Jonesey95: Ahh, It's something to do with my logged-in settings. Yes, it looks okay when logged out but has the same broken display at work from a different computer, though also a mac and also using Firefox. However, when I look at it in Safari it displays fine while logged in. So I am guessing either it's some setting peculiar to me, or maybe it's a combination of mac, Firefox and the monobook skin. If the former, then this is resolved. If the latter, well it's not a big deal, but it would be nice to have someone on a mac, running Firefox check using Monobook.--Fuhghettaboutit (talk) 22:38, 28 February 2017 (UTC)
Duh. Mark this resolved. Of course I should check using a different skin. Same broken display in Vector, so it looks like it's just me. Something in my common CSS or js maybe.--Fuhghettaboutit (talk) 22:45, 28 February 2017 (UTC)
How do you subst a parameter only?
Right now, when substing {{Bot Top}}/{{Bot Bottom}} in closed BRFAs, it substs a template depending on what the first parameter of {{Bot Top}} is. That is, substing {{subst:Bot Top|1=Approved}}, later invokes a {{subst:Bot{{{1}}}}} (e.g. {{subst:BotApproved}}), which creates a hard-coded instance of {{BotApproved}}.
@Headbomb: I'm not sure why you think your edit didn't work. With the current version of the template (with {{Bot{{{1}}}}}), {{subst:Bot Top|Approved}} produces <snip> The result of the discussion was {{BotApproved}}<!-- from Template:Bot Top-->. So after the substitution, {{BotApproved}} is being transcluded on the page. — Mr. Stradivarius♪ talk ♪00:32, 1 March 2017 (UTC)
Publishing Javascript
Hello. I've written a custom Javascript that filters the watchlist based on various criteria. A few questions:
How can I publish this code as a global preference on Commons?
; "Episode Whatever"
# "First song"
#* '''Music:''' John Doe
#* '''Lyrics:''' Jane Public
#; Performer (character)
#: Actress A (Pony A)
#; Backing vocals
#: Actress B (Unicorn B)
#: Actress C (Pegasus A)
#; Context: Pony A has a problem so Unicorn B and Pegasus A cheer her.
# "Second song"
#* '''Music:''' John Doe
#* '''Lyrics:''' Jane Public
#; Performer (character)
#: Actress A (Pony A)
#; Context: Pony A wonders if her problem was solved well.
Resulting:
"Episode Whatever"
"First song"
Music: John Doe
Lyrics: Jane Public
Performer (character)
Actress A (Pony A)
Backing vocals
Actress B (Unicorn B)
Actress C (Pegasus A)
Context
Pony A has a problem so Unicorn B and Pegasus A cheer her.
"Second song"
Music: John Doe
Lyrics: Jane Public
Performer (character)
Actress A (Pony A)
Context
Pony A wonders if her problem was solved well.
I'm thinking of using some trick so the list would be (roughly) look like:
"Episode title"
1. "Song title"
Music: composer
Lyrics: writer
Vocals
List
of
credited
performers
Context
All the context
Of course, I'd use adaptive column template so it would look like not broken into columns on smartphones.
No, there isn't a way to do that without having odd breaks. Either way, the information that we're presenting at the article presently, and which you are trying to change the representation thereof, is correctly tabular information, and should probably continue to use the tabular method. --Izno (talk) 20:10, 26 February 2017 (UTC)
In the linkbar that appears at the bottom of an IP's contribs page (the one that has WHOIS, Geolocate, etc.) can a link be added to the new Range Contribs tool? (Example) Either for any IP or only when a range is searched, I don't think it matters. I would do it myself but I have no idea how. Ivanvector (Talk/Edits) 12:56, 1 March 2017 (UTC)
Good advice, but I do have the gadget enabled and prefer the functionality of the external tool. The native tool cannot filter by date, for example, and doesn't seem to work for ranges which are not /16, /24, /27 or /32, nor for IPv6 at all. Wildcards are nice but not quite what I'm looking for, unless you can think of a wildcard that would catch 134.154.0.0 - 134.154.63.255 but exclude 134.154.64.0 - 134.154.255.255. Ivanvector (Talk/Edits) 13:32, 1 March 2017 (UTC)
The problem with this is knowing which range to lookup. It's possible to always link to a /32, or a /16, /18, or /24, but knowing which to use is always going to be a problem. It would almost be better to link to the tool without any parameters. -- zzuuzz(talk)13:45, 1 March 2017 (UTC)
Feel free to link to XTools in system message, sure, but know that soon, hopefully by the summer, we'll have a core solution :) More at phab:T145912. Whether we use XTools or the core tool, Zzuuzz is right that we don't know what range to link to given a single IP. The new tool will support IPv6, so for that maybe we could link to the common residential /64 range, not sure if we could apply a similar sensible default for IPv4 though. There will also be a range calculator bundled in with the new tool — MusikAnimaltalk17:01, 1 March 2017 (UTC)
We are all looking forward to the core tool. In the meantime, the only solution I can think of is to write a custom script or gadget which checks the querystring for an IP range, and appends an XTools link somewhere on the page (I am not volunteering). -- zzuuzz(talk)19:55, 1 March 2017 (UTC)
Template:MonthlyArchive is causing a few hundred talk page archive pages to hit the expensive parser function limit. Are there any Lua programmers here who might be willing to take a look at it? See the template's talk page and documentation for details. Thanks. – Jonesey95 (talk) 21:43, 1 March 2017 (UTC)
The most recent edit brought the underlying problems in the code to light: each new year on the calendar increases the parser calls. There are workarounds, but a more permanent fix would be helpful. Please continue discussion on the Template Talk page. – Jonesey95 (talk) 22:59, 1 March 2017 (UTC)
Feedback requested on XTools rewrite
Hello! Community Tech is teaming up with Matthewrbowker to address the 2016 top 10 wish of rewriting the popular XTools suite. The first tool Community Tech will be working on is Articleinfo (accessible via the "Revision history statistics" link on history pages). At it's simplest, our goal is to rewrite it to be stable and fully functional. Before we get started, we want your feedback on what you'd like to see in the new version, and what you don't like about the current version. Please review our plans provide any feedback at meta:Community Tech/Rewrite Xtools/Articleinfo. Thanks! — MusikAnimaltalk00:10, 2 March 2017 (UTC)
Cannot delete a page in my user space
Hi,
I am trying to delete User:Amire80/monobook.js, and I cannot. The deletion form just reappears and the page is not deleted.
What I'm asking here is not so much to delete the page, but to understand why does it actually happen, because it's really odd. --Amir E. Aharoni (talk) 06:56, 2 March 2017 (UTC)
I tried to experiment with different skins, and I simply cannot change them. When I change from Vector to Monobook in the Preferences, I see Monobook selected after I save the preferences, but the actual skin is still Vector. And if I refresh the preferences, it goes back to Vector.
This is broken on Firefox, but works on Chrome. This may or may not be related to the "Cannot delete a page in my user space" issue, which I reported in a section above. --Amir E. Aharoni (talk) 07:01, 2 March 2017 (UTC)
As it is browser-specific, sounds like this is more likely on your end. In Firefox try this: Help, Restart with addons disabled. This will help rule out any extensions you have installed locally. — xaosfluxTalk11:34, 2 March 2017 (UTC)
IP blocked last week, couldn't use the UTRS
Last week, when I tried to edit a page, I was notified that my IP address was blocked because of activities of another user. I tried to use the UTRS, indicating that I was requesting exemption from an IP block. When I submitted the form, the response was that my IP wasn't blocked. I went back and forth between trying to edit a page and trying to submit the UTRS form. In page editing mode I was consistently advised that I was blocked. The UTRS form consistently told me that I wasn't.
Ultimately I figured out that I could just put an unblock request on my own user talk page, which worked quickly. The block notice instructions actually say that, but it was obfuscated by the huge, expanded template right in the middle of the instruction as to what to add to my user talk page, such that I had to read really carefully to see that it was telling me what to do on my user talk page.
This isn't quite right. It's the autoblock unblock template that shows that address, which did not show up in CU and has nothing to do with the actual block. Why does the template show an irrelevant address? Doug Wellertalk20:56, 2 March 2017 (UTC)
I don't seem to be able to figure out how to view the infobox in articles in the Wikipedia mobile app. Is there in fact a way to do this? Air.light (talk) 03:31, 23 February 2017 (UTC)
You mean an infobox that is usually in top, or the navbox (usually near the bottom) that does not show in mobile view? Could you give an example article name? -DePiep (talk) 09:00, 23 February 2017 (UTC)
Hi all, I'm trying to help the Kurdish community to improve their language Wikipedias (there are 2 of them) and one of the problems is a lot of vandalism. I am in touch with a lot of bilingual English/Kurdish speakers and they are looking for someone to give them advice about how they can implement edit filters to prevent some of the vandalism they are experiencing. Can anyone point me in the direction of someone who can help? Jwslubbock (talk) 16:46, 24 February 2017 (UTC)
Help re: references to NRHP documents readable in Microsoft Edge but not Chrome or Netscape
What the heck should be done, for readers, for thousands of references to National Register of Historic Places documents that are readable when you use Microsoft Edge browser, but which just show a blank in Netscape and which show gibberish in Chrome? I want to give them the link but warn them they should try a different browser if they can't read it. Can a program determine which of the documents will need such a warning?
This applies to most or all of the NRHP documents for "multiple property submissions" or "multiple resource areas" which are mostly listed at wp:MPS and which are cited in many thousands of articles, either in full references or more minimally by link from the NRHP infobox. All of these have NRHP reference numbers starting with "64". Most of the NRHP documents for individual properties or for historic districts are not subject to this problem. I am forgetting where, but perhaps some individual U.S. state's NRHP documents are all like this too.
Are there any other examples out there of classes of documents whose readability is browser-dependent? What is done for readers, if anything, in these cases? If the readers are using Microsoft Edge, they should have no issue. But if they are using Chrome, they should be given some warning.
It seems to me that the links should be kept but marked by a template giving warning to Chrome users, or if necessary to all readers, which could be easily altered if/when the browsers change. If Edge can read the documents, perhaps sometime Chrome can read them too. But this has remained as a steady problem for quite a long time (years i think) now, so it seems like we should do something for Wikipedia readers.--doncram22:13, 2 March 2017 (UTC)
They display fine using Reader if you download them, but the OP is correct, if you click on the links directly they appear perfectly well in Edge but not in Firefox or Chrome, so there's obviously something wrong with them. Black Kite (talk)23:46, 2 March 2017 (UTC)
Glen Mitchell House does not link to https://npgallery.nps.gov/pdfhost/docs/NRHP/Text/64500490.pdf. I can download it with Firefox and open it with Adobe Reader 9.5.5. I can read it online in Opera 12.18 but not Firefox 51.0.1. I'm not a PDF expert and don't know whether it has poor compliance, uses rare PDF features or what. I would just make sure citations are marked as PDF files like |format=PDF in common citation templates, in addition to the automatically generated PDF icon. We don't know which past and future browser versions can read them or whether the publisher will change them so let's not start listing browsers where some editor's current version works. PrimeHunter (talk) 00:04, 3 March 2017 (UTC)
Odd that the article did not have the reference, I swear that i put it in today (and also that i revised related article on architect Bruce Goff earlier today), but maybe I did not hit "Save". Or why else would my edits disappear? Anyhow, another editor just added a version of the intended reference. --doncram01:03, 3 March 2017 (UTC)
According to https://www.pdf-online.com/osa/validate.aspx, those two PDF files have invalid syntax. Some browsers are presumably better than others at working around syntax problems in PDFs. The best resolution is probably to correspond with the organization hosting the PDFs to see if they would be willing to run them through some sort of script to clean them up. I believe that Acrobat has a "PDF syntax" check in its preflight commands; that check could probably be turned into a script of some sort. It is not Wikipedia's job to fix bad PDFs, but we might want to create a page with a name like to Help:Viewing PDF files that tells people how to deal with PDFs that do not display properly (i.e. right-click and choose Save Link As, and similar advice). – Jonesey95 (talk) 00:44, 3 March 2017 (UTC)
This is a pretty big class of documents. Really they are linked from many hundreds/thousands of articles. I am pretty sure that the PDF files WERE readable in all browsers, this really was not a problem until a year or two ago. Then the browsers eventually changed, perhaps roughly with Windows 10 i dunno? I wonder were the files technically always in violation of some PDF standard that the browsers did not find to be a problem, then the browsers got more strict? Or did the PDF standard change? I could request to the National Park Service for all the files to be changed somehow (i don't understand how yet). It is possible that they would take action; they have been responsive to other requests about access to their documents. So I am taking from this discussion that there are not other examples of Wikipedia trying to handle browser-dependency in links given. --doncram01:03, 3 March 2017 (UTC)
Thank you to you several respondents. This is helpful and enables me to correspond with the National Register now, with me now much better informed. I will try to follow up here about how it goes. Thanks! --doncram04:06, 3 March 2017 (UTC)
Vanishing orphan template
This edit removed most of one of those multiple issues templates, leaving just the "This article is an orphan" template. In that diff, I can't see the orphan template on its own. When I restored the multiple issues template, there it was. I checked on the desktop versions of IE, Chrome, and Firefox and it's not there in any of them. Is anything wrong with the orphan template if it appears on its own? CityOfSilver20:26, 3 March 2017 (UTC)
@Nihiltres: I did not know that so thank you. The rationale there makes no sense. This measure is an effort at getting the orphan backlog under control. But whether or not these articles are on it or not can't possibly make a real difference when that backlog is permanently unstable. So why not maintain visibility to nudge people? CityOfSilver20:51, 3 March 2017 (UTC)
"hovering" behaves differently in sandboxes vs mainspace
Hi folks! I'm a newbie, so this question is probably ancient. Sorry if so. When you hover over a superscripted reference number in an article in mainspace (I hope I'm using the correct terminology), a window pops up showing you the content of the reference so that you don't need to follow down to the references section. When you hover over the same sort of number in a sandbox (for example any of the references here, the window doesn't pop up. I'm using Firefox, but I doubt that matters. Why? Is there some way to fix that difference? Thanks, DennisPietras (talk) 03:11, 4 March 2017 (UTC)
Wikipedia article titles are all capitalized, whether they start with proper nouns or not.
Given a list of random article titles, how can you automatically separate the list into two: one list with articles starting with terms that are always capitalized, and the other list with articles starting with common terms that are generally not capitalized?
This sounds like a Microsoft interview question. I don't think there is a way to do it based on the article's title alone, but you could use categories as a way to do an initial division of articles into two or more groups. Anything in Category:Living people, for example, is very likely to be a proper noun. – Jonesey95 (talk) 03:59, 1 March 2017 (UTC)
@Jonesey95: (Maybe I should go screen applicants for them. I wonder, does MS ask applicants for the solutions to unsolved problems?)
That would take a lot of gathering of selection criteria, as the various relevant categories branch out into thousands of subcats. I've already found a way to filter out 2/3 of the titles. (Those with the last word capitalized virtually always have a capitalized first word). I'm left with filtering what's left over. The Transhumanist05:04, 1 March 2017 (UTC)
There is no way to solve this problem completely simply by looking at any number of lists or categories on Wikipedia. There is an obvious programmatic method of answering the question. That would be to download the entire database of Wikipedia articles, and scan the text of each for its own title in the article body. Specifically, you would be looking to see if instances of the article title that are not at the beginning of a sentence are capitalized. This would then filter out into "always capitalized", "only capitalized in title", "insufficient data" and "inconsistent". Someguy1221 (talk) 04:09, 1 March 2017 (UTC)
@Someguy1221: Unfortunately, %%title%% doesn't work in AWB's database scanner's regex searches, which would make it easy via content searching. So I'm looking further afield for a solution. Please let me know if you have any more ideas. Thank you! The Transhumanist05:04, 1 March 2017 (UTC)
A probably-saner way would be to get the set of Wikidata items which have a Wikipedia page in the mainspace and then see whether those items have labels which start with lowercase or uppercase. --Izno (talk) 04:20, 1 March 2017 (UTC)
A Wiktionary scan for {{wikipedia}} might produce a good comparison list. The entries on there are only capitalized for proper nouns. Thanks! I think this could work. The Transhumanist05:36, 1 March 2017 (UTC)
@The Transhumanist: Right, Wiktionary would also work, but may not have the number of proper nouns which Wikidata has (which has the same rules give-or-take w.r.t. labels and page names). --Izno (talk) 13:23, 1 March 2017 (UTC)
@Izno: Wikidata seems convoluted. I typed "dog", then "cat", then "horse", and in none of those searches did the data item come up in the results. I expected it to jump straight to the page, like Wikipedia does. Or at least see that data item at the top of the search results. What the hell? Which makes me wonder how one would generate a list from Wikidata of item titles corresponding to Wikipedia articles. I have AWB. The Transhumanist16:50, 1 March 2017 (UTC)
@The Transhumanist: That's odd. There may be an issue with the search service or your Javascript may not have loaded correctly. If you can reproduce the problem, that's one for d:WD:Contact the development team.
Regarding a list, I think the users at d:WD:Request a query can trivially help you with the entire query (while I can visualize the query, I'm not good at actually building them). --Izno (talk) 17:15, 1 March 2017 (UTC)
I find it hard to believe that we could generate a list of categories such that an article should be categorized if and only if it's in at least one of them. For example, Thomson's gazelle would not be in any such category, yet it should always be capitalized because it starts with a person's name. By the way, any article which contains {{lowercase}} should definitely not be capitalized, even though many of them are in capitalization categories. For example, we have an article about a song at eBay (song) - and that song (as well as the web site it's named after) should be called eBay, not EBay. עוד מישהוOd Mishehu09:12, 1 March 2017 (UTC)
We can't determine whether an article title begins with a proper name or not just by examining the title. We can't even do it satisfactorily by a human reading the text (such matters have been generating much heat in recent weeks at e.g. WT:UKRAIL). So there is no way that an automated process can do it. --Redrose64 🌹 (talk) 10:33, 1 March 2017 (UTC)
The Wikidata query for this is something like this. Not that it's working without any filtering (by 'to looka t what kind of items'), bet ... P.S. Thanks to everyone about ideas. I had a similar problem for other language, now I have some more ideas. --Edgars2007 (talk/contribs) 08:41, 6 March 2017 (UTC)
Should search let you know if the search term is available in a different language?
I suspect this has been discussed but I'm not recalling such a discussion, so I'm hoping someone can point me either to a discussion with this has been proposed and rejected or if it can work but I'm just not doing it correctly.
All illustrate with an example.
There is no article in the English Wikipedia about Konstantin Meyl, but there is one in the German Wikipedia. While it may be useful to create a translation at some time, in the interim it may be helpful for the search bar to suggest that there is such an article in a different language. People who have multiple language skills may think to search first in the English Wikipedia but may be perfectly comfortable reading it, in this case, in German.
In addition, given that we now have the ability to do translations, shouldn't this be something that is provided in the search? Currently the search suggests there is nothing for the reader.--S Philbrick(Talk)15:03, 6 March 2017 (UTC)
@Sphilbrick: I can't find it right now, but this is something that's in development and/or already functioning to some degree. I found T3837 which seems to be related, but I'm pretty sure I've seen a working version of searching and receiving a suggestion from another language Wiki. Sam Walton (talk) 15:10, 6 March 2017 (UTC)
Yes there is some work going on regarding this topic. See the large epic story phab:T145918. You can test out some of that work by using the cirrusUserTesting=recall_sidebar_results flag in the search url. See for instance English Wikipedia, polish wikipedia, Farsi, Catalan. It's far from finished however, can be quite resource intensive and especially the cross language search isn't part of it yet I believe. It's being worked on however, which cannot be said about the 10 years prior :) —TheDJ (talk • contribs) 15:25, 6 March 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
You can now search on English, French, Hebrew and Greek wikis and find words even if you forget the diacritics. It also works if you use diacritics in your search but the wiki doesn't. [45]
When you use the mobile view and click on a link to an article in another language you will see that article in the mobile view. Previously it changed to the desktop view. [46]
Problems
Some watchlist gadgets didn't work for a period of time last week. This has now been fixed. [47]
Admins who click on "mass delete" on a user's Special:Contributions will be taken directly to a list pages created by that user. It has worked like this before, but not lately. [48]
Changes this week
The way you switch between wikitext and the visual editors in the desktop view has changed. It is now a drop-down menu. This is the same as in the mobile view. [49]
The "flag the edit in the abuse log" checkbox will be removed from the abuse filter interface. This is because the edits are always flagged in the abuse log. [50]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 March. It will be on non-Wikipedia wikis and some Wikipedias from 8 March. It will be on all wikis from 9 March (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 7 March at 20:00 (UTC). See how to join.
Clarification
The 2017/09 issue of Tech News mentioned 3D file formats you can soon upload to Commons. The AMF format will be available later.
I had edited WP:AFD/T a few days ago to use the following parser function to transclude the current day's page: {{Wikipedia:Articles for deletion/Log/{{#time: Y F n}}|}}. The documentation says that absent an input value, the time parser function uses {{CURRENTTIMESTAMP}}. However, the page transcluded was the page as of March 3 (the edit date) and did not update, even if the page was purged. What am I missing here? — Train2104 (t • c) 22:15, 6 March 2017 (UTC)
Hi - as I type in the edit summary box I can only see the top half of the text. This came about recently tho I aint made any changes in Preferences section for ages. I've looked everywhere for a fix but no dice. How do I increase font size in the edit box, or the box size itself? Thanks. MarkDask04:22, 7 March 2017 (UTC)
I recently became aware of the Horizon project, apparently something wikitech-related. It has been, for the lack of a better description, eating pages on the English Wikipedia (try editing that redirect to see what I mean). Is there some sort of workaround? Do we really need a "Horizon:" shortcut for that project? Huon (talk) 00:54, 3 March 2017 (UTC)
horizon was added to meta:Interwiki map 22 April 2016 [51] after meta:Talk:Interwiki map/Archives/2016#Horizon. Nearly all Wikimedia projects have an interwiki prefix, and many users expect it to be so and look for the prefix. Existing page names starting with it and a colon become inaccessible with normal methods, and new pages cannot be created. I wouldn't worry about it when no article disappears in a black hole (which has happened for other prefixes). PrimeHunter (talk) 01:21, 3 March 2017 (UTC)
Thanks for the ping. Sadly this is not new. I've had a discussion in the past when the interwiki prefix "vd:" was added as an alias for Wikidia. It caused that an entire wiki namespace aliases to break. I resolved it by removing the interwiki link and asking a developer to update the database, not without much discussion from the supporters of that interwiki though. The easiest solution would be for a developer to run namespaceDupes.php, first in dry-run mode, to see how many links are bad. Trying to edit those pages will result in an error so it needs to be done by the back door. Other option would be to request the removal or modification of the Interwiki prefix at m:Talk:Interwiki map, but given that this is a Wikimedia service, I doubt that the request would be granted. I'd suggest to use the first option (namespaceDupes.php or cleanupTitles.php). I'll ask at Phabricator for the list of broken titles and will let you know. Regards, MarcoAurelio (talk) 08:10, 3 March 2017 (UTC)
While removing an interwiki to horizon: may not be supported, changing the identifier to something else (e.g. horizonlabs:) could be. — xaosfluxTalk12:30, 3 March 2017 (UTC)
+1 to removing horizon in favor of horizonlabs. Generally speaking, I think we should be a little more vigilant on adding new IW prefixes to make sure they're not introducing super obvious conflicts like this one. ^demon[omg plz]17:47, 3 March 2017 (UTC)
Is there anyway of getting a new password if there is no email address registered for the account? I created a login account two days ago and although I am sure of the password I used I am obviously wrong?
Also CAPTCHA is giving the same word every time, and will not reset either?
Missing comment for admins in speedy deletion templates
Until recently, any speedy deletion template had a small message which said something along the lines of "Admins, please check the page history before deletion", when the word "deletion" was a link to the deletion page, with the deletion reason already filled out. Any idea what happened to that message? עוד מישהוOd Mishehu13:27, 7 March 2017 (UTC)
I see this with various links on all examined pages in Category:Candidates for speedy deletion: Administrators: check links, history (last), and logs before deletion. It's only displayed to admins. Can you give an example where you don't see it in your admin account? It's made by {{Db-meta}} and I also see it on the template page. PrimeHunter (talk) 14:03, 7 March 2017 (UTC)
I also see the text there. Maybe MediaWiki:Group-sysop.css isn't working for you. What is your skin and browser? Do you see text here: This text is in class="sysop-show". I see This text is in class="sysop-show". I use Vector and Firefox. PrimeHunter (talk) 20:40, 7 March 2017 (UTC)
Hi, Is it possible to disable the overlay on the WikiMiniAtlas for a specific page. On Ottawa River page the {{coord}} 100km scale is substituted by the 2km scale of the overlay. thx --YB✍13:22, 8 March 2017 (UTC)
Not that I really mind, but over the past couple of days the captcha for IP editors does not update properly.
Tonight it is "glibhaber"-- every time.104.163.140.193 (talk) 08:28, 5 March 2017 (UTC)
Request for all uses of Template:Open-source attribution to be updated to Template:Free-content attribution
Hi
The template Template:Open-source attribution has been moved to Template:Free-content attribution, this is causing me problems in tracking where content from different organisations is being used on Wikipedia. Please could a friendly wizard be able to change all instances of {{Open-source attribution to {{Free-content attribution ? It is less than 100 pages.
Thanks PrimeHunter, all the pages using Template:Free-content attribution that have a publisher are added to a category for free content from that organisation, this allows any organisation to understand where the content from their organisation is used. Unfortunately Template:Open-source attribution doesn't have this functionality. Also it will make thing much easier in future when doing tracking tasks to not have to account for a small number of files in another category. --John Cummings (talk) 12:46, 7 March 2017 (UTC)
The code in 9 is what I need, its a really helpful tool that makes it possible to measure page views. Basically it will add all the open license text reuses to Category:Free-content from UNESCO, which means I can use TreeViews to easily measure page views for the content. Having them all under one template will also allow me to use other methods to look at which articles come from specific publications using a Regex Search. Basically having two templates doubles the amount of work I have to do for any metrics collection. Can you explain why it is a problem to switch the template names? I don't understand why its a problem. --John Cummings (talk) 14:49, 7 March 2017 (UTC)
As I said, the used template name has no effect on categories. You still haven't given an example so I cannot see what the real issue is but I guess it's an unnamed parameter. See WP:NOTBROKEN about changing working redirects. Some users don't like additions to page histories, watchlists and recent changes for something so minor with no effect on the result. PrimeHunter (talk) 19:18, 7 March 2017 (UTC)
I'm sorry I'm not explaining myself very well, here is an example of where having two templates names different things breaks the metrics tool, it can't pick up on both the templates at once. Thanks --John Cummings (talk) 21:48, 7 March 2017 (UTC)
As I said, hastemplate:"Free-content attribution" also finds pages using redirects so you can just use that instead of insource:"Free-content attribution". insource is an inefficient and unreliable method to find template use. PrimeHunter (talk) 22:34, 7 March 2017 (UTC)
Hi PrimeHunter, ok thanks, that works, thanks for being so patient explaining things. One last question, I'm getting a weird result and I don't understand why, if I search for hastemplate:"Free-content attribution" UNESCO I get a different result to hastemplate:"Free-content attribution" unesco.org despite both terms being present in all pages that come up when I just search UNESCO. Do you know why? This will be problematic when trying to do searches for specific subsets of information.
At Special:NewPages I noticed when I hovered over Jbignell's name that WP:NAVPOP omits their account creation date, "1336 edits since: , last edit on 2017-03-08". It doesn't seem to be a popup error because it's also happening at Special:ListUsers/Jbignell. I've seen this behaviour before on other accounts but I can't recall which accounts were affected. Anybody got an idea what's going on? Thanks, Cabayi (talk) 11:38, 8 March 2017 (UTC)
What xTools reports is not when the account was registered, but rather when the first edit was made. What other tools use is when the accounts registered. Some accounts predate when account creation timestamps where logged.—CYBERPOWER(Chat)11:47, 8 March 2017 (UTC)
Apologies to Jbignell, I didn't mean to alarm you, but nor did I want to talk about your account behind your back.
Thanks to Cyberpower678, zzuuzz, & PrimeHunter for putting me straight. I had looked at Special:ListUsers/Koavf, "(Created on 5 March 2005 at 20:22)", who lies outside the date range given, yet still has an account creation date. The only difference I can see is that Koavf has been granted extra permissions over the years. Cabayi (talk) 15:26, 8 March 2017 (UTC)
I once read somewhere that some old account creations from before the log was introduced were added later based on some data. The alleged account creation is the same minute as the oldest edit so maybe the edit was used. Koavf is not listed in the user creation log Special:Log/newusers. PrimeHunter (talk) 15:39, 8 March 2017 (UTC)
Problems editing in desktop view on a mobile device
I sometimes access Wikipedia with a tablet when I don't want to boot my computer up. I love the app for reading, but when I'm in "editing mode" (ie I'm looking at internal pages, page histories, contributions, watchlist, as well as actually editing) I use the desktop interface through Chrome, as I'm doing now. I appreciate that this makess me a 'power user' and not a typical case, but in the last week or so, I've frequently been redirected to the app when I've tried to load a Wikipedia page in Chrome (which for "Special:" pages results in being redirected back to chrome but to the mobile site). Selecting "request desktop site" or clicking the "desktop" link on the page has no effect. The only way to get back to the page I want is to manually manipulate the URL in Chrome after being re-re-directed. Has anyone else had similar issues? Is there anything that can be done about it? Thanks, HJ Mitchell | Penny for your thoughts? 15:41, 8 March 2017 (UTC)
incidentally I got stuck in this looposition again as I saved the above comment. The edit saved but the page opened in the app and I couldn't get back here in Chrome without making the app redirect me to the mobile site and then manipulating the URL. HJ Mitchell | Penny for your thoughts? 16:44, 8 March 2017 (UTC)
Is there a category or template that logs pages with deliberate errors on them? I'm thinking about Document pages mainly, where having an error on display is useful to teach the user what to look for and how to fix it. - X201 (talk) 11:28, 7 March 2017 (UTC)
I have never seen a category that tracks deliberate errors. Several templates/modules have a technique to not add a category when a deliberate error is shown on a documentation page. For example, {{val}} uses nocategory=yes and {{navbox}} uses tracking=no, while {{convert}} only includes a category on articles, so nothing is needed for documentation pages. Johnuniq (talk) 21:41, 7 March 2017 (UTC)
I just found out about Special:AbuseFilter/550, and I'm curious: is adding nowiki tags a frequent indicator of vandalism or something? It seems like something non-regulars wouldn't know about.
Even if someone can answer this particular question, I'm more curious if these were established by community consensus somewhere (on meta?) and where I can find that info.
Adding nowikis is often the mark of a newbie doing something they shouldn't, probably using the nowiki button on the formatting toolbar. Considering the filter has been disabled a couple of times, and the last entry in the notes says, "Enabling for a short time. Need to test ...", I'd suggest it's probably a candidate for disabling. A lot of filters are created without much discussion. There's some talk in the archives here. The filter's original name was, "Page mutilated by visual editor", which seems to accurately reflect its origin. -- zzuuzz(talk)11:08, 9 March 2017 (UTC)
(edit conflict) Ah, right. I forgot there was a button. I always do it manually, and it's essentially the only filter I've triggered that I could figure out what it was supposed to do, just not why. (A bunch of random edits to my own talk page in autumn 2015 apparently triggered filter 1, but I don't really know or care why, and filter 650 makes obvious sense.)
See also Wikipedia:Edit filter/Requested. VisualEditor used to add a lot of nowiki tags the user didn't write. VisualEditor wouldn't let users write markup code directly so it automatically added nowiki tags to any attempt or anything it thought was an attempt. PrimeHunter (talk) 11:16, 9 March 2017 (UTC)
Huh. That's interesting. I've been ignoring VisualEditor, honestly. Never understood the appeal; my technophobe dad figured out wiki markup for himself, so I find it difficult to imagine the community is expanded a lot by VE's existence. Hijiri 88 (聖やや) 11:23, 9 March 2017 (UTC)
References with the same name
Dear editors: I occasionally accidentally give two references the same name; usually the parser complains loudly in red ink, prompting me to fix the problem. Today, however, when I was working on a draft in my user space, HERE, the software combined two references with different content but the same name. In this case it was because the citation tool automatically named the magazine issues by the year. I noticed it because I've only just started on this draft and there were only three references, so I easily saw that one was not showing up. Is this a new "feature", or is it a bug? I can fix it on my draft by changing the reference name to something else, but I fear that in a longer article the merging may go unnoticed.—Anne Delong (talk) 08:35, 9 March 2017 (UTC)
Thanks, John of Reading; I hadn't noticed that. A "feature, then. It seems an odd choice to have the little blue number from one reference be used to represent a different one, when the software has already detected that it's an error. However, since the problem will be flagged right away when a page is moved to mainspace, I'll leave my CSS as is so that I see what everyone else sees, and just take care to recheck the references each time I move a page.—Anne Delong (talk) 13:57, 9 March 2017 (UTC)
A minor thing - on Template talk:Did you know I see a separate scrollbar for the left-hand sidebar menu; it looks like it's being treated as a separate pane. This doesn't seem to appear on any other pages (which is a bit of a shame, as it's quite useful). I'm just curious as to what causes that, and whether I can get other pages to display the same way. It only seems to work when I'm logged in to my main account, so I'm guessing it's one of the scripts I'm running... (browsers used are Chrome 56.0.2924.87 and Firefox 51.0.1, FWIW). Any ideas? Yunshui雲水14:40, 8 March 2017 (UTC)
I see a scrollbar in the table of contents on the right, made with {{Fancy TOC}}. The sidebar is where the Interaction and Tools menus are. Is it really there you have a scrollbar? What is the first and last item? What is your skin? Maybe Fancy TOC interferes with something for you. Do you see it at other pages at Special:WhatLinksHere/Template:Fancy TOC? PrimeHunter (talk) 15:22, 8 March 2017 (UTC)
Doesn't seem to be the {{Fancy TOC}} template - none of the other pages that use it seem to show the same effect. The scrollbar affects everything on the left, from the Wikipedia logo at the top down to the Languages links at the bottom. I do have ResponseHelper running, which does mess about with some of options there, as well as igloo and reFill. I'm using the default Vector skin, if that's any help.
To be honest I wouldn't suggest you lose any sleep over it - I'm asking more to satisfy my own curiosity than anything. Thanks for the response nevertheless. Yunshui雲水14:33, 9 March 2017 (UTC)
I am a long-term editor, but in the last couple of days I've been unable to edit from my laptop while logged on because I get the message: Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in.
I've logged off, logged on again, and each time I log on I get the slightly weird message: Central user log in - No active login attempt is in progress for your session. - Return to the previous page. though the logon appears to succeed. But I still can't edit. I've also rebooted the laptop.
Can you try going to https://login.wikimedia.org and logging in and out there ? If that works, please do report back on success. If that doesn't work, you will need to delete the cookies for the wikipedia.org and wikimedia.org domains. Information on how to do that in Chrome can be found here. —TheDJ (talk • contribs) 14:41, 9 March 2017 (UTC)
Oh, and do you use Firefox ? There is a known problem with Firefox atm and loss of cookies, so if you could confirm or deny usage of that browser, then that would also be very useful. —TheDJ (talk • contribs) 14:59, 9 March 2017 (UTC)
@TheDJ: Definitely Firefox-related: I've just tried to log on and edit using the Edge browser which comes with Windows 10, and managed to do a test edit to my sandbox. So in practical terms I can continue editing, though I'd be much happier if I could do so in Firefox. Is there a workround for the Firefox problem or are we waiting for them to mend their code? 92.5.97.181 (talk) 15:10, 9 March 2017 (UTC)
The work around is to delete all cookies that firefox has for all *.wikipedia.org and *.wikimedia.org domains. They are going to be releasing a fix for this in the next month or so, but for now, deleting all the cookies is the only workaround. —TheDJ (talk • contribs) 15:21, 9 March 2017 (UTC)
Thanks (both you and Cryptic). I must have known this, once upon a time, but clearly not any longer! Fram (talk) 14:12, 10 March 2017 (UTC)
Interesting 2017 update edits on Wikipedia article in comparing to 2015
There were interesting update edits which were done on Wikiproject tabulations for 2017 here [58]. There is still alot of blank 'white' space in that graph and possibly there is a way of preserving the old data results by simultaneously adding the old data from 2-3 years back into the graph to stand as column graphs superimposed and next to the brand new 2017 columns. There's lots of 'white' space unused in the chart space area and it might be nice to see the growth aspects of Wikipedia charted in comparing the old data from 2015 to the new data in 2017. Can these graphs be superimposed side-by-side? ManKnowsInfinity (talk) 16:42, 10 March 2017 (UTC)
The API returns primary coordinates only by default. The coordinate wasn't marked as such, I did that now. It is possible to request secondary coordinates, however the result is pretty useless as it includes e.g. coordinates mentioned in passing. Max Semenik (talk) 22:22, 8 March 2017 (UTC)
Idea: Make the use of ping more easy for new users (phab:T159908)
Browsing through talk pages I noticed the following: A new user had asked another user a question and started it with @username. He probably expected the other user to be notified, but as it does not work this way in mediawiki, never got an answer.
So, it would be easy to do a javascript, that scans through input boxes and if a "@" at the start of a line or preceded by a space is found, then if the following word matches an user name or a sig of an user that is either mentioned on the page or can be verified by an api call to be a local user, then the script opens a box with a text that tells an ip-user to login and then use ping, or asks a logged in user, if this should be transformed to a wiki link to that user.
But this does only make sense, if it is not an user script or gadget, but only if it is integrated in the system javascript of all wm-sites.
Additionaly there could be gadgets to allow experienced users to opt out or alternatively to skip the box questioning, if the transformation should be made.
Local wikis could set a configuration variable, so that the script inserts a local ping template instead.
Flow's system is kind of nice for that: it pops up a box that searches for the username (which is particularly helpful when you're trying to remember the exact spelling or capitalization for an unfamiliar name). But absent something like that, I think that PrimeHunter is right: it's going to be difficult to detect the end of the username. Whatamidoing (WMF) (talk) 16:33, 8 March 2017 (UTC)
The script could search through the page for [[user:(.*){\|\]} (sigs with a space) and if there are matches, that contain a space, use the found prefixes to test "@" sequences. --𝔊 (GradzeichenDiſk✉Talk) 19:33, 8 March 2017 (UTC)
Good question. What I imagine might be possible though idle speculation up ahead: is to use the edit filter system to at least give other users a way of finding those attempts and explaining how pinging works. Maybe a filter that looks for the addition of @ in the various talk namespaces by non-registered and new users. (Limit should probably be higher than merely (auto)confirmed, someone who's been around a few days and made maybe two dozen edits is still almost as likely to make that mistake as a non(-auto-)confirmed user is.) Probably should have at least the more common e-mail providers in as exceptions lest it throws around false positives like candy every time a new or IP-user tries to add a hotmail (or gmail/msn/yahoo/etc.) address in a talkpage message.
Could add a tag like 'possible failed pinging attempt' or the likes so other editors can at least find them and explain how to actually ping (and who knows, some of the new/IP users might actually click the link and figure out what they did wrong). Maybe throw up a warning explaining what's going on, too, provided it's actually possible to append a custom 'warning' to a specific filter rather than the general 'might be unconstructive' warning I know filters can throw up—that one would be counterproductive and confusing here, not helpful. AddWittyNameHere (talk) 20:05, 9 March 2017 (UTC)
@Whatamidoing (WMF): That would only be a problem, if both "Are you" and "Are you suree" have posted before on the page in question,. But even in that case. it would not be a problem, because the script does not automatic translate the text, but open a box, to ask the user, if the transformation should be made (and can then tell, what username has been found). --𝔊 (GradzeichenDiſk✉Talk) 20:29, 9 March 2017 (UTC)
This is not going to fly, sorry. Perhaps something that was opt-in would be ok, but many editors (I'm one) are not keen on being pinged all the time. When indenting is not quite enough to clarify what my reply is addressing, I may prefix a comment with "@Example" and I definitely do not want an automatic ping generated. Rather than generating automatic pings, development should be done to show a pop-up alerting the sender about how many pings they have sent because editors are still confused and think that fixing a typo in a ping will cause a new ping to be sent. Johnuniq (talk) 00:59, 10 March 2017 (UTC)
Perhaps opt-in: IP-users cannot opt-in, new users will not know about an opt-in.
many users (I'm one) (== power users) -> this users could opt-out (and will know how to)
definitely not automatic: It is not automatic, but asks, if you meant to ping, and tells you how to (unless you opt-out)
development should do a pop-up: There is: in preferences/notifications enable "successful notifications" / "failed notifications"
WMF/WMDE do spent money to find new authors for wikipedia. But if a new user comes here, he finds an unusual, strange and complicated editing system. Emulating known notification behaviour of other sites would help new users.
You will need a separate account on the Beta Cluster to try this out. It can have your usual name, etc., but please please please heed the warning against re-using a password from any other account. Whatamidoing (WMF) (talk) 04:07, 12 March 2017 (UTC)
Another update (you'd think that the quarter was ending in another couple of weeks or something: ;-)
In 2011, the German Wikipedia requested that Mediawiki and Cite.php be updated to automatically provide columns, without needing a template or user script, if there were more than a few <ref>...</ref> tags on a page. Six short years later, this request has been granted, and it's finally ready for production.
This is a major improvement for accessibility, simplicity, performance, etc. It provides dynamic columns based on each reader's screen width, but keeps a single column if there are fewer than 10 refs on the page. (IMO this feature is particularly nice because it eliminates any need to manually update the reflist template if someone adds or removes a lot of sources from a page.)
Also, it is (sort of) incompatible with the current state of the {{reflist}} template, whose use has since doubled(!) at the English Wikipedia in the meantime.
So to avoid screwing up a minority of articles here, this feature is being deployed "default-off" everywhere. Getting it turned on at a local wiki requires a config change by the devs. If you are aware of a wiki (Wikipedia or any other project) that's ready to go, then please let them know (e.g., file a Phab task or leave a note at mw:Talk:Editing/Projects/Columns for references). But otherwise, I think that the main point to remember when you see Tech New on Monday is that this is not changing anything visible right now. Whatamidoing (WMF) (talk) 04:33, 12 March 2017 (UTC)
I have the gadget called "Add an [edit] link for the lead section of a page" enabled, and have done for as long as I can remember. Just in the last couple of days, probably since Thursday, the "edit" link for the lead section shows in a different font from the "edit" links for all of the other sections on the page. This is happening in every namespace, as far as I can tell. Is it just me?
The lead section "edit" link shows in a serif font, and the regular edit links show in the usual sans serif font used for body text on pages. I am using the Vector skin and have made no changes to my skin or Preferences recently. – Jonesey95 (talk) 04:20, 11 March 2017 (UTC)
I've tried to run IABot via Fix dead link tool at the List_of_wheel-well_stowaway_flights, but after analyzing nothing happened: the statistics said "Links analyzed: 79 Links rescued: 0 Links tagged: 0 Links archived: 0". The page still contains unfixed dead links. Why is that? Is this feature still in development? Brandmeistertalk15:52, 10 March 2017 (UTC)
That IABot does not fix the links right away is normal. This is an feature that tries to ensure that the bot does not replace links that are not accessible intermittently. Pywikibots weblinkchecker works in the same way. Both bots should replace the links on the second run.--Snaevar (talk) 19:42, 12 March 2017 (UTC)
Find out textual context (header) from where module was transcluded
Is there some way to find out which ==Level 2 Header== a module was invoked under? Is this possible if the invocation happened through a template instantiation? Moberg (talk) 08:33, 12 March 2017 (UTC)
No, apart from guessing. I sometimes copy the wikitext of an article to a local text editor, then paste half of the article into a sandbox and preview the result. If it shows the module as being used, I halve it again, etc. In principle you can view the module documentation to see whether it is supposed to be used with a template, then search for the template in the article's wikitext. Or, use "what links here" on the module page and set the namespace to "template" to see what templates use it. Johnuniq (talk) 23:16, 12 March 2017 (UTC)
You may be able to Cmd-tab or Ctrl-tab on each of the level 2 section edit links to open each section in a new tab in edit mode. Then, in each tab, scroll down to "Templates used in this section:" and fold it down to see what is in there. Tedious, but it might get you what you want. – Jonesey95 (talk) 00:30, 13 March 2017 (UTC)
Could I use a category intersection to create a list of topics, then feed that list into a wikidata search and retrieve additional data? Could I then create a Web page that displays this info in the form of a table? Could this be done without a lot of human intervention? Thanks. SharkD Talk 19:42, 13 March 2017 (UTC)
I've just gotten the schedule for the next round. The first outage will be on Wednesday, 19 April 2017, and the second will be on Wednesday, 3 May 2017 (two weeks later). The time of day is still be discussed, but it will probably be during the afternoon in Europe and Africa, and the morning in the Americas. Please mark your calendars.
Last year, we did extensive communication work to let editors know what was happening, and it seemed to be successful. I'm planning to do something similar this year: announcements to the Village Pumps, notices in Tech News, etc. OTOH, the projects are constantly changing, so if there's something new that you think needs to be done, or something that seems less useful than it was in the past, then feel free to share your ideas with me. Also, if someone is on IRC and wouldn't mind posting these dates to relevant channels, then I'd appreciate that. Whatamidoing (WMF) (talk) 20:26, 13 March 2017 (UTC)
503 unavailable
I've been getting errors when saving pages, for the past couple of hours. Sometimes it just sits there forever, others it gives the WMF error-screen, saying "503 service unavailable" and the page about IRC, etc.
I'm pretty sure it's not a problem on my side; everything else is working fine, as is reading anything. I'm on a good connection too.
It's just taken me 10 attempts over about an hour to save this edit - I left it "waiting for en.wikipedia..." for 10 mins, tried again, after a few minutes got the error-screen, tried again, and so forth. Same thing has happened on other pages. 86.20.193.222 (talk) 01:07, 14 March 2017 (UTC)
Is some hidden toolbar changing "Trump" do "Drumpf"?
Recently I've seen a number of reports by users who were "just" editing one part of an article, and yet in a totally different paert of it the edit included changing "Trump" to "Drumpf". Most recent was this edit. Is this due to several users who think they can get away with such lies, or is this the result of some web browser addons? עוד מישהוOd Mishehu07:48, 14 March 2017 (UTC)
I usually help with drafts in the userspace for AfC (Category:Pending AfC submissions in userspace), but recently many pages in user sandboxes that are multiple years old and have not been submitted for AfC review are being shown in the category. I'm pretty confused - the only similarity between them are that they have the Template:Template sandbox embedded on the page, but I have cleared the template and have found no issues (I have also purged the category). Could anyone else verify that this is happening, and why? Thanks. -Liancetalk/contribs06:26, 14 March 2017 (UTC)
There are currently nine pages in the category. I see a big "Review waiting" box at the bottom of all of them. This edit today added {{AFC submission}} to {{Template sandbox}}. It was reverted later but after a template edit it can take a very long time before category listings affected by the template are updated. A purge will not update it. You have to null edit the listed page (not the category page). PrimeHunter (talk) 10:33, 14 March 2017 (UTC)
Heads up on a UI change
To all of the people who had problems with the size of the edit summary box recently:
This time, they're planning to do the same thing to the 'Save' button (and the other buttons next to it). I hope that I'm wrong, but I'm guessing that if you had a problem when the edit summary box was converted to the standard scheme, then you may find that this is problematic, too. Please report any problems here (or in Phabricator).
For everyone else: The save button is going to be big and blue. The other buttons will be bigger, too. Since few of us on this page actually look at this button any more (you just tab out of the editing box, add your edit summary, hit return, and you're done, right?), it's likely to be something that we all find weird for a few days, and then don't really think about after a while. But (based upon a recent conversation with a guy running a third-party wiki and whose boss hates big blue buttons), it looks like it's pretty difficult to completely override this kind of change.
This is just the next step in the multi-year UI standardization/update/tweaking. It may not affect all editing systems, although the two oldest wikitext editors and the new-ish code editor were definitely on the list the last time I checked.
I can't guarantee a deployment date; it's already been delayed at least once. However, I currently believe that this will ride the deployment train next week, which means that we may see a round of "Thursday blues" somewhat more literally than usual. Whatamidoing (WMF) (talk) 22:44, 10 March 2017 (UTC)
(you just tab out of the editing box, add your edit summary, hit return, and you're done, right?) Right—when I don't click the looking glass to preview, that is. —ATS 🖖 talk22:54, 10 March 2017 (UTC)
@Whatamidoing (WMF): Quick question. On my WMF account I have #wpSave{background-color:#b5deff} (turns the save button blue) in my common.css to remind myself which account I'm logged into. Can I still do something similar with the new button? (Obviously I'm going to have to pick another colour!) Sam Walton (talk) 22:56, 10 March 2017 (UTC)
@Whatamidoing (WMF): by the way, is there any documentation about this stuff? I was able to return the edit summary to its normal size in my global.css, but I could not find how to disable the thick blue frame when it is focused (although its animation is removable through the CSS). — Mikhail Ryazanov (talk) 01:57, 11 March 2017 (UTC)
The blue border doesn't seem to be added by CSS, so it must be JavaScript, which means that it will be difficult to turn off. --Redrose64 🌹 (talk) 08:39, 11 March 2017 (UTC)
I'm used to the larger edit summary and heading boxes. What I would like to know is where they get the list of what I can put there without typing more than the first letters. I can't seem to get a response on the Computing Reference Desk. They got hung up not on the detail of my question, but the incorrect heading that I typed because I didn't know the terminology.— Vchimpanzee • talk • contributions • 17:08, 11 March 2017 (UTC)
Over several years, I have learnt lots of CSS, and am aware of pseudo-classes; but when I use my browser's "Inspect element" feature, I cannot find any evidence that pseudo-classes are in use. It's not like the bell and car-door icons for notifications, which use ::before and :;after. --Redrose64 🌹 (talk) 20:09, 11 March 2017 (UTC)
@Vchimpanzee: They're not explaining it because you didn't ask for it to be explained. You started off by asking about web sites listed when you click on the URL; you seemed to mention edit summaries only tangentially, in the fourth sentence (I get a different list when starting to type a section heading or edit summary), so it's not at all obvious that this was your primary problem. --Redrose64 🌹 (talk) 19:26, 12 March 2017 (UTC)
Just a guess, but if you want to know how Microsoft Edge chooses or prioritizes its auto-fill information, then you might have better luck at a support forum for Microsoft Edge. Whatamidoing (WMF) (talk) 18:22, 14 March 2017 (UTC)
Did something happen to to screw up the sort order of languages in the left sidebar of articles? I'm looking at the Vichy France article for example, and the languages list starts thus: "Euskara, Polski, Español, Occitan, Magyar, Kiswahili, Brezhoneg, Ελληνικά, پنجابی, Svenska, and ends thus: Azərbaycanca, Кыргызча, 粵語, Ido, Čeština, Bahasa Indonesia, 中文, Scots, Latina, Français, What's going on? P.S. The sort order is correct in the German article. Mathglot (talk) 19:49, 14 March 2017 (UTC)
Now that "size of edit box" has been removed from preferences, is there any way to change the settings? Because I use a variety of devices ranging from phones and notebooks to 5120x2880px Apple behemoths, this was probably only setting in prefs I regularly changed, and its sudden disappearance a couple of months ago has left it locked at the 80-line depth I happened to have it set to when the setting box disappeared, which is long enough to be irritating to use on smaller devices. (If there is still a way to change it—or even a way to restore it to the default—it doesn't appear to be documented anywhere, and I don't think it's unreasonable to say that I know more about the under-the-hood operations of Wikipedia than most, and if I can't find the setting new and newish users will certainly struggle.) ‑ Iridescent13:18, 13 March 2017 (UTC)
In the bottom-right corner of the edit box, you should see six dots in a triangle. Hover your mouse there, the pointer should turn into the up-down double arrow ↕ - click and drag up or down. Unfortunately, such resizing persists for this edit alone, it's not permanent.
The styling applied to the <textarea>...</textarea> element includes the property min-height: 5em; which prevents you from shrinking it below a height of 5em, and the property max-height: 100vh; which prevents it from becoming taller than your viewport. --Redrose64 🌹 (talk) 14:04, 13 March 2017 (UTC)
One could easily write a gadget that stored those dimensions in your browsers localstorage. However that would cause the screen to 'relayout' while opening an edit page, and people have found that to be rather annoying in the past. Sizing textareas in browsers, is one of those things that hasn't really been dragged into 2010's yet in my opinion. —TheDJ (talk • contribs) 14:11, 13 March 2017 (UTC)
Here, 25em is just an example - set anything you like within the bounds set by the declarations min-height: 5em; max-height: 100vh; --Redrose64 🌹 (talk) 14:14, 13 March 2017 (UTC)
Ta. Any idea why it was removed from preferences in the first place, given that it had happily sat there for a decade without causing any apparent problems? I can't be the only one who's been caught by this—anyone who uses both a laptop/tablet and desktop PC to edit presumably finds it convenient to flick between different edit-box sizes. ‑ Iridescent16:06, 13 March 2017 (UTC)
Two or so years ago they decided to trim down the available preferences, this has taken some time: the columns/rows options at Preferences → Editing were still there (between "Edit area font style:" and "Prompt me when entering a blank edit summary (or the default undo summary)") in October 2016. IIRC those prefs which have been removed were selected on the basis that only a small number of people had altered the pref away from the default setting, so few people would be impacted. Each pref removed marginally improves page load time for logged-in users. --Redrose64 🌹 (talk) 17:23, 13 March 2017 (UTC)
You'd think if they're going to remove the ability to change a pref, they'd at least have a "restore to default" option (or forcibly restore those who had altered it). Locking everything in place at whatever setting it happened to be at for each individual editor at the time of removal is as WMF a fudge as I've ever seen. ‑ Iridescent17:34, 13 March 2017 (UTC)
We didn't lock it in place for every editor where it'd been set prior. It was hardcoded to the original default value that users would have had they never edited it (or pressed reset on their own preferences). In your case, 80 columns happened to also be the default, which is why you didn't see it change. From the change itself: "Used defaults of 80 columns and 25 rows in places that still were asking for it." ^demon[omg plz]19:10, 13 March 2017 (UTC)
@^demon: No, it's locked for me at 80 rows, not 80 columns—see screenshot to the right. I happened to be editing on a computer with an enormous monitor, and had the preferences pushed up accordingly to avoid a screen-full of whitespace, at the time the choice was removed from preferences, and consequently have this 80-line edit window enforced even if I'm just editing from a phone. It's an annoyance rather than a massive inconvenience for me, but for someone using a setup where having to constantly use the scrollbars is more difficult, it would be quite a serious accessibility issue. ‑ Iridescent16:04, 14 March 2017 (UTC)
Ok, I see what you mean now. That's odd, and I wonder if you have some userland JS or CSS that is doing this (maybe a Gadget?). I only say that because there's no way that MediaWiki would know about the old preference you have: it's been removed. Yes, there's still a legacy entry still hanging around in the database, but nothing is using it... ^demon[omg plz]16:38, 14 March 2017 (UTC)
Ah, thank you, and sincere apologies for wasting everyone's time. I have absolutely no recollection of adding that to my personal css (I have no recollection of adding anything to my personal css), but I obviously did—I checked my vector.js page to see if there was any code in there that could be doing it but it never occurred to me to check css as well. ‑ Iridescent16:52, 14 March 2017 (UTC)
I was thinking of the bit at the bottom that says "Edit summary (Briefly describe your changes)". It's nice and sharp - unfortunately, Chrome is no longer supported for Windows XP. --Redrose64 🌹 (talk) 20:28, 14 March 2017 (UTC)
I'd like to echo both of Moxy's sentiments: thank you for the script and it's surprising(and frankly speaking, not a positive surprise, either) to have Wikipedia go backwards as far as accessibility goes. AddWittyNameHere (talk) 18:42, 13 March 2017 (UTC)
I write CSS rules - my edit of 14:14, 13 March 2017 (UTC) provided exactly one CSS rule, consisting of one selector and one declaration. Snippets I don't know about, scripts I can't write to save my life. I once borrowed a book on JavaScript, keyed in the "Hello World" example, clicked the button it displayed - and it crashed my PC, losing two docs I was working on at the time. Never again. --Redrose64 🌹 (talk) 21:13, 14 March 2017 (UTC)
Forgotten articles not showing in category
I'm currently clearing Category:Pages using infobox single with unknown parameters, as I've cleared this category I've noticed something that I can't find an answer to. Correct me if I'm wrong but shouldn't an edit to a Template eventually trigger a recompile of an article and with it any category membership triggered by that template? If so, it doesn't seem to be working. This article {Back It Up (Swami song)) has just appeared in the category, an editor has just edited part of it and because of that it caused a recompile, triggering the template to add the article to the error category (the user didn't add the error). The previous last edit to that article was in 2014, there have been numerous edits to the Infobox single template in the intervening period, so why didn't any of the template edits cause the page to recompile and join the category? - X201 (talk) 15:53, 10 March 2017 (UTC)
Yes, the job queue is supposed to eventually cause a new rendering of a page when a used template is edited. It occasionally fails but here it would have required many failures during years so it may be something else. The parameter error in the article is the nasty looking | [ Recorded = 2009-2012]. My guess is that the MediaWiki software previously treated that as the value of an unnamed parameter. It's currently treated as an assignment of a parameter called [ Recorded. The English Wikipedia got mw:MediaWiki 1.29/wmf.15 yesterday but any MediaWiki change since the last article rendering could be the cause. An equals signs in an apparently unnamed parameter will be treated as a parameter assignment unless the equals sign is interpreted as being part of a syntactic element. This may be a border case which has changed behaviour. PrimeHunter (talk) 17:00, 10 March 2017 (UTC)
This may be related to T132467: categorization takes days or months when templates or modules change, or T157670: categorization takes months or forever when MediaWiki code changes. – Jonesey95 (talk) 19:08, 10 March 2017 (UTC)
The tracking category was added to the infobox code 29 April 2016 [59] so it's "only" 10 months delayed if MediaWiki hasn't changed behaviour. That actually looks plausible. It's a hidden category so it isn't displayed visibly in the Internet Archive or Google's cache but hidden categories are in the html source for everybody. They just get class="mw-hidden-cats-hidden" to hide them. If you enable "Show hidden categories" at Special:Preferences#mw-prefsection-rendering then they get class="mw-hidden-cats-user-shown" instead. The Internet Archive cached the article 8 November 2016 [60] and the category is in their cached html source. Sometimes a page is rendered to display a category long before the category page is updated. A purge of the page will not update the category page but a null edit will. PrimeHunter (talk) 22:00, 10 March 2017 (UTC)
@PrimeHunter and Jonesey95: Thanks for the info/explanation. The obvious follow up question is about to arrive. When I've finished cleaning that category it will be empty, except that I know that there will be sleeper articles out there, just waiting for a genuine or null edit to put them in the category. It has an added importance as there is currently an RFC about merging a number of Infoboxes (single/song/etc) into the same template. Obviously, cleaning up any errors before the merge - if it happens - would be desirable to ease the roll out of the new merged infobox. So how do I force a full re-render of all articles that transclude Infobox single? A bot to null edit all transclusions? or do I just run AWB over every article to check for errors? - X201 (talk) 09:01, 14 March 2017 (UTC)
I'm not convinced they did - I'm still confused. What exactly is the issue? What PrimeHunter said seems to make sense. Sam Walton (talk) 23:44, 11 March 2017 (UTC)
In short: this page's Wikidata link "Wikidata item" [tools menu] is not the link to the Wikidata:Village pump.
That is what I wanted to note for fellow editors here. There was no original 'issue' or question. I am working to get involved in Wikidata. On a presumed simple quest for their WD:village pump page, I lost hours & patience. Allow me to save others that experience. @Samwalton9: -DePiep (talk) 18:54, 15 March 2017 (UTC)
You just chose the wrong Wikidata link. "Wikidata item" under "Tools" always links to the Wikidata page where the equivalent pages in Wikimedia wikis are listed. There is usually also data about the subject when it's an article. The link has mouseover "Link to connected data repository item". "Wikidata" under "In other projects" always links to the equivalent of the page at the Wikidata project itself. Like all projects in that menu there is no mouseover. It may be a little confusing that both links include "Wikidata" but they both go to Wikidata so I think it makes sense. The inclusion of "item", the placement in the Tools menu and the mouseover all give clues to the difference. A long permanently displayed description (as opposed to the mouseover) would be annoying. Most pages, e.g. articles, only have the "Wikidata item" link. PrimeHunter (talk) 20:00, 15 March 2017 (UTC)
Watchlist option hide page categorization check box is always checked when I got to my watchlist and I uncheck it. But I just noticed after I do the search it re-checks itself. Was there a recent change that caused this or was it doing it all along and I didn't notice? Richard-of-Earth (talk) 08:31, 17 March 2017 (UTC)
Check the watchlist section of you preferences. Hiding categories is an option there and IIRC was set to default hide when introduced. Unchecking on the watchlist itself is a temporary override only. Nthep (talk) 09:10, 17 March 2017 (UTC)
The reference was defined in both articles with minor differences. I have fixed it by commenting out the new definition.[61] It could also be deleted but that would make it harder to fix if the transclusion changes later. PrimeHunter (talk) 19:25, 17 March 2017 (UTC)
My home-wiki (da-wiki) recently had a large discussion regarding WikiProject templates, up until the end of 2016 we used roughly the same yellow banners you use for WikiProjects, placed on the talk pages. A group of users claimed it was annoying to click a blue talk page link to see that there was no discussion about the article, but just a bunch of project templates. While I disagreed (massively) with their reasoning, they unfortunately prevailed in a majority vote about the issue and now the WP-templates have to be removed from the talk page.
Now, obviously noone wanted to eradicate the classification system that WikiProjects provided, so me and another user tried to make some templates that might allow the templates to be placed on article pages without being intrusive to a non-editor. The other user's proposal was rejected, and I decided not to propose my own as it was too intrusive and also looked stupid. Then I had an odd idea, and I want to ask if it's even possible.
Would it be possible to make a MediaWiki gadget, browser plugin or some other gizmo which does the following:
Check the talk page of an article (without the user actually navigating to the talk page).
See if the talk page consists only of transcluded templates.
If the above is true, change the talk page color to red or some third color to indicate that it only contains templates.
As an example, let's say I click on the article .st. Since the talk page only contains templates, the link would be red (or purple etc., you get the idea).
Is this possible? I know this has nothing to do with en-wiki, but your language fork is by far the one with the most experienced coders when it comes to templates & gadgets.
An easier and more efficient check than "does it contain only templates" would be "does it contain a level2 header". By WP:TP guideline, discussions all go in sections, whereas the project banners and related notices all go above the first header (in the "lede"). Now obviously we do get talkpages where someone starts the first discussion without making a header. But this could also be an opportunity to check for that situation and add headers. DMacks (talk) 20:13, 17 March 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes this week
You will be able to show references from <references /> tags in more than one column on your wiki. This is the list of footnotes for the sources in the article. How many columns you see will depend on how big your screen is. On some wikis, some templates already do this. Templates that use <references /> tags will need to be updated, and then later the change can happen for all reference lists. [62][63]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 March. It will be on non-Wikipedia wikis and some Wikipedias from 15 March. It will be on all wikis from 16 March (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 14 March at 19:00 (UTC). See how to join.
Future changes
Some old web browsers will not be able to use JavaScript on Wikimedia wikis in the future. If you have an old web browser on your computer you can upgrade to a newer version. [64]
CSS in templates will be stored in a separate page in the future. [65][66]
FYI to curious readers, "old web browsers" in Future changes means browsers that don't support ES5 strict, so IE 10+ (including Edge), FF 4+, Chrome 13+, Safari 6+, and Opera 12.1+ is a short list of browsers that will still be fine. --Unready (talk) 23:59, 17 March 2017 (UTC)
That's certainly useful, thank you Graham87! But what I meant was a tool that would go through a page and remove all but the first occurrence of each wikilink (if it was smart it could have options to ignore the infobox and/or the lead). Does anyone know of anything that does this? Justlettersandnumbers (talk) 21:42, 18 March 2017 (UTC)
AWB will make it easier for you, doesn't do the work for you but at least it will identify the terms multi-linked. Nthep (talk) 21:57, 18 March 2017 (UTC)
I'm fairly certain it's used directly in the mobile frontend, where it has a more obvious use ("take a picture of this thing which has an article! and then add the image!"). --Izno (talk) 12:47, 16 March 2017 (UTC)
You are mainly talking about the magic word #coordinates, which is specifies coordinates for a lot of things, among those is Special:Nearby. Special:Nearby is an nice example of that and I will oversimplify what #coordinates really is in the following description. Special:Nearby obviously shows users which subjects are near to them. In order to give you this information Special:Nearby needs information on where the subject of the article is situated, e.g. the GPS of the subject, and the location (GPS) of you, which it gets from your browser. The GPS data of your browser is then compared to the GPS of the article and converted from an coordinate over to an distance like kilometres from said subject. Special:Nearby knows where the subject is due to the #coordinates magic word, which was implemented into Template:Coord shortly after that feature was added. Of course there are more coordinates on some articles than just the location of the subject the article is about, but that does not cause major issues as the #coordinates magic word has an marker called "primary" which marks which coordinate represents the location of the subject the article is about. Hopefully this was simple enough for you.--Snaevar (talk) 19:21, 18 March 2017 (UTC)
@Redrose64: It's probably because calling {{Coord}} from the infobox template rather than the article causes problems with the parser function. Since infoboxes are being converted so that {{Coord}} is inserted in |coordinates=, replacing separate lat/long parameters, it shouldn't be a problem after they're all converted. Jc86035 (talk) Use {{re|Jc86035}} to reply to me10:06, 19 March 2017 (UTC)
This simply doesn't stand up. Writing
{{Infobox UK school
...
| latitude = 51.3742
| longitude = 0.0186
| dms = yes
...
}}
will plug the appropriate values into {{coord}} exactly as if we had used
directly. Why should it behave any differently? What is there to say "this is inside an infobox and so must be disregarded"? --Redrose64 🌹 (talk) 11:30, 19 March 2017 (UTC)
The page was moved from the title you can see in the edit summary. Logs are not moved - the log's here. Someone might chip in to say how old this issue is and whether it will be fixed.. -- zzuuzz(talk)11:40, 18 March 2017 (UTC)
So basically it's a known problem for at least five years now and no one worked on it? Okay, thanks. You learn something new each day. Regards SoWhy13:14, 18 March 2017 (UTC)
Logs have pretty much always been left behind when pages are moved - ever since the page-move feature was first added, waaaaay back in 2003. --Redrose64 🌹 (talk) 23:16, 18 March 2017 (UTC)
Thanks for the heads-up. Weird that the other bugs mentioned by Jo-Jo Eumerus have not been closed then. Or does this refer to other problems? Regards SoWhy09:25, 19 March 2017 (UTC)
Hmmm, any chance you could just add an easy cross-reference to logs under previous names in the output, rather than move the log? I can see why people would get antsy about moving log files, since the whole idea of logs is not to mess with them. Wnt (talk) 16:14, 19 March 2017 (UTC)
{{DYK user topicon}} seems to be malfunctioning as of today. No icons are showing, just the alt-text and link. There's no edits on the template page. EvergreenFir(talk)16:21, 20 March 2017 (UTC)
Is it possible, at all, to use a ref name tag inside a reference bundle? When I preview the reference bundle with a ref name tag inside it does not appear to work, so I was wondering if there was a way, at all, to work around the issue? ElectrodeandtheAnode (talk) 16:17, 17 March 2017 (UTC)
I would like to see an example of where this is to be done - if a ref itself needs to be referenced, there's probably something wrong. Refs should be able to stand up for themselves without justification. --Redrose64 🌹 (talk) 11:23, 19 March 2017 (UTC)
Before I swapped to using {{efn}} I used #ref in an explanatory note that needed sourcing. But that's about all I can envisage. Nthep (talk) 11:48, 19 March 2017 (UTC)
I don't think I've tried to explain this very well. If I use an example from an article I am currently working on to try and promote its status to Good Article (Casualty (series 30)), a suggestion was made that the article uses reference bundling. This was an example of a paragraph using a reference bundle:
Henry previously appeared in several episodes in 2011. Tom Chambers made two guest appearances as his Holby City character Sam Strachan in episodes twenty-three and twenty-four, whilst Emily Carey returned in the role of Grace Beauchamp in a storyline which reunited Sam with Connie, his former partner and Grace's mother. Rosie Marcel made a guest appearance as her Holby City character Jac Naylor in episode twenty-three.[1]
As you can see in this reference bundle all the references use a cite web tag. However, later on in the Series 30 article, two of the references which have been used in the reference bundle (the references about S30–E23 and S30–E24), appear again, used to reference a different part of the article. So, what I'm wondering is, can you put the ref name tag inside a bundle and the reference bundle still work? Because what is happening at the moment, is this:
[Random use of ref:] "Hearts and Flowers", written by: Dominique Moloney, directed by: David Innes Edwards.[2]
Henry previously appeared in several episodes in 2011. Tom Chambers made two guest appearances as his Holby City character Sam Strachan in episodes twenty-three and twenty-four, whilst Emily Carey returned in the role of Grace Beauchamp in a storyline which reunited Sam with Connie, his former partner and Grace's mother. Rosie Marcel made a guest appearance as her Holby City character Jac Naylor in episode twenty-three.Cite error: A <ref> tag is missing the closing </ref> (see the help page).
So is there a way to use a ref name inside a reference bundle and not have the message pop-up about a Cite Error. Have I made myself a little clearer now? Sorry about the confusion. ElectrodeandtheAnode (talk) 17:32, 19 March 2017 (UTC)
#ref would probably work but I'd ask the more basic question, why bundle the refs? If they are all saying the same thing then that is WP:OVERCITE. There's also a question of style, the rest of the article doesn't use bundled refs and if you want a GA there should, IMO, be consistency of appearance. Nthep (talk) 18:04, 19 March 2017 (UTC)
I'm not sure that it will work. You could compromise by bundling the ones that aren't re-used, but I think it's important to remember the WP:GACR do not include a criterion of "use the exact WP:CITEVAR that the reviewer likes best", so the article can't legitimately be failed over that anyway. WhatamIdoing (talk) 18:46, 20 March 2017 (UTC)
Minor edits can be significant but very difficult to track down. It took me several minutes to find the edit made by an IP at [70]. It was a correct edit, inserting italics around Equus mosbachensis, but it could easily have been disruptive. It would be very helpful if edits could be made easier to find, for example by putting + and - sign next to each line which has been changed. Dudley Miles (talk) 11:28, 20 March 2017 (UTC)
(edit conflict) I see a light blue background for the added apostrophes. It's easy to see for me. If your browser or eye sight makes it hard then it has class="diffchange diffchange-inline". The styling can be changed in your CSS. Or you can try "Display diffs with the old yellow-and-green colors and design" at Special:Preferences#mw-prefsection-gadgets. The code is in MediaWiki:Gadget-OldDiff.css. You can also try wikEdDiff for an alternative way to display diffs. PrimeHunter (talk) 11:46, 20 March 2017 (UTC)
You suggest "by putting + and - sign next to each line which has been changed" - it already does this, and IIRC has done for as long as I've been around (almost 8 yrs) --Redrose64 🌹 (talk) 17:23, 20 March 2017 (UTC)
I suspect that Dudley is asking for the diff page to mark the relevant line-on-his-screen (70 characters on mine) rather than the line-in-the-wikitext-database (1,575 characters). Whatamidoing (WMF) (talk) 18:57, 20 March 2017 (UTC)
Can't be done. We have no way of knowing how wide a user's screen is, so what with word wrapping, no way of knowing how many "lines" down the change is. For the edit in question, I see sixteen "lines", with the actual change being on "lines" 4-5: that's if we assume that line 4 begins "from the northwest" and line 5 begins "mosbachensis'' and are". --Redrose64 🌹 (talk) 19:16, 20 March 2017 (UTC)
Pending changes is restraining the wrong edits
This is one example but I've seen this a bunch of times. When I went to the edit history at Cameron Diaz, I noticed that all four edits before this one were waiting for a response from a pending changes reviewer. User:XboxGamer22408 has been here almost four years, User:Red Jay has been here over eleven years, neither has ever been blocked, and both are pending changes reviewers. Why didn't their edits get automatically accepted? CityOfSilver18:38, 20 March 2017 (UTC)
Both editors were reverting back to an unaccepted revision containing vandalism from an unregistered user. That's how it's supposed to work. If they'd reverted manually then they would have had an option to accept the edit(s), but they were both using rollback so wouldn't have had the option. -- zzuuzz(talk)18:46, 20 March 2017 (UTC)
@Zzuuzz: Got it, thank you. I know this is contrarian (and given how powerful rollback is, probably impossible) but it seems like if someone can be trusted to review pending changes, they should be allowed to undo good work and restore vandalism since the presumption is that they're going to keep working from there. That yellow background on good editors' contributions is confusing and played hell with my ability to assess the damage at Diaz's article. CityOfSilver19:18, 20 March 2017 (UTC)
If done automatically that would only cause a lot more vandalism to remain. PC reviewers can actually do what you suggest, but it needs to be a conscious decision to tick a box. "That yellow background" is a useful sign that something has probably slipped through the net. -- zzuuzz(talk)19:35, 20 March 2017 (UTC)
@Zzuuzz: I mean, I know. I just applied to become a reviewer because I can see how I'd need it to react to situations like these in the future. CityOfSilver19:38, 20 March 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The Save page button now says Publish page or Publish changes on the Wikimedia wikis except for Wikipedias and Wikinewses. This change will come to Wikipedias later. The point is to make it more clear that the edit will change the page immediately. Publish page is when you save a new page and Publish changes when you edit an existing page. [71]
You can see monthly page views when you click on Page information in the sidebar. Developers can also get monthly page views through the API. [73]
The Linter extension is now on smaller Wikimedia wikis. It helps editors find some wikitext errors so they can be fixed. It will come to other Wikimedia wikis later. The extension will be able to find more errors later. [74]
The MediaWiki-Vagrant portable development environment has been updated to use Debian Jessie. This means local development and testing will be more like on the majority of Wikimedia production servers. [75]
Problems
On 15 March some interwiki links to other languages were not correctly sorted. This has been fixed. If you still see pages where the interwiki links are not sorted as they should be, they should be fixed automatically with time or you can edit the page and save it without changing anything. If this doesn't work, please report it. [76]
Changes this week
When you edit with the visual editor, you will be able to switch the direction you write in from right-to-left to left-to-right as you are editing. This is especially important for editors who edit in languages that write from right to left. You can do this with a tool in the editing menu. You can also use the keyboard shortcut Ctrl+Shift+X on PCs or Cmd+Shift+X on Macs. [77]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 March. It will be on non-Wikipedia wikis and some Wikipedias from 22 March. It will be on all wikis from 23 March (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 21 March at 19:00 (UTC). See how to join.
I am the one who was fetching those pages because i need to discover all content pages. I have successfully harvested all pages in Turkish and Arabic Wikipedia. But i have been having problems in English wikipedia. Any estimated time you can fix the issue and return that feature back? Or any chance you can dump somewhere all content pages links?BurstPower (talk) 15:38, 20 March 2017 (UTC)
@Reedy where is this API that can let me fetch content pages' URLs? I am checking dumps but there are so many stuff and i don't know which one of them i can obtain URLs of the content pages. Any help is appreciate. Thank you. BurstPower (talk) 16:07, 20 March 2017 (UTC)
@AKlapper (WMF): Ty for the answer. However i do not see anywhere in the api Special:AllPages feature. If you could provide me all pages links' dump i would appreciate a lot. I mean all links of "5,363,329 articles in English" which is written in top left main page. Any ETA when will Special:AllPages return? I would expect WikiPedia to have pagination but i think it doesn't have right? BurstPower (talk) 16:19, 20 March 2017 (UTC)
The API has an "all pages" module that is detailed at [79]. Yes the Special Page does have pagination. That's how you're making continuation queries. But that doesn't help when many requests are made simultaneously. Of course, AllPages doesn't tell you which are actually content pages, just which are in the right NS. Some wikis have content pages in other namespaces. For the dumps, see [80], you want "Wiki page-to-page link records." ala enwiki-20170301-pagelinks.sql.gz and possibly "List of page titles in main namespace" which is enwiki-20170301-all-titles-in-ns0.gz. Technically, also, you don't need the URLs, you just need the page names. https://en.wikipedia.org/wiki/ + pagename would give you the URL Reedy (talk) 16:29, 20 March 2017 (UTC)
Yes, I think this is the real question. The best way to get those URLs is going to depend on what you want to use them for. The different ways of accessing the data (data dumps, the API, and the Tool Labs database replicas via e.g. quarry) all have their strengths and weaknesses. — Mr. Stradivarius♪ talk ♪22:16, 20 March 2017 (UTC)
Special:AllPages re-enabled
Special:AllPages is back again. But the filter for redirects is gone as the cause of the performance problem. It might come back again in the near future, but is likely to take a while, as it could require a new DB index. Reedy (talk) 20:16, 20 March 2017 (UTC)
BurstPower, please tell us what you're trying to accomplish. There may already be a tool for it. Someone here may be able to save you a lot amount of time and energy (or the servers). The regulars on this page are often incredibly helpful. Even if your project is "just" for fun, please tell us about it. Whatamidoing (WMF) (talk) 01:12, 22 March 2017 (UTC)
Page size tool
I just tried running the page size script at User:Dr pda/prosesize.js (which usually works perfectly) on the article Standing wave ratio. The script got a certain way through the article (as shown by the yellow highlighting) and then stopped. It seems it stops on every inline instance of <math>\Gamma</math> in the article. There are a couple of other math expressions that stop it as well, but it does not stop on every inline math expression. By inline, I mean inline with the article prose as opposed to an expression on its own line. This is quite strange, I have not come across it before, despite using this script for many years. Does anyone have any ideas how to fix this? SpinningSpark15:56, 21 March 2017 (UTC)
01:01:04.982 TypeError: id.childNodes[i].className is undefined 1 index.php:90:1
There is a lot of other stuff from when the page loads, but this seems to be the only line generated by running the page size script. SpinningSpark01:15, 22 March 2017 (UTC)
It seems the bang template "{{!}}" (magic word) has fallen through the documentation cracks, and needs more explanation somewhere(s). It was even TfD'ed again in December 2016 to merge with {{pipe}}, as if parser function "{{#if:}}" should be merged with "{if}" to avoid so many #/colon characters! There are templates designed to allow wp:subst which avoid simple "{{!}}" and use "{{SAFESUBST:<noinclude/>!}}" instead, which further shows the need to explain how using "{{!}}" is not a template call any longer. I will put an {ombox} at top of Template_talk:! to clarify usage. I plan to reset Template:! back as "&124;" to generate bar pipe "|" if the template is force called as "{{! |}}", but I will discuss that at Template_talk:!. When did "{{!}}" become a magic word to bypass the template? -Wikid77 (talk) 11:44, 21 March 2017 (UTC)
Thanks. I see "{{!}}" operates the same, while double "{{!!}}" is only a template, which lists below during edit-preview. But I need to note the subst'ing for "{{!}}" still requires "{{SAFESUBST:<noinclude/>!}}" or similar to avoid literal "{{!}}" being stored inside the page. -Wikid77 (talk) 22:13, 22 March 2017 (UTC)
Editnotices for (new?) users creating new articles poorly formatted in VE
@Xaosflux:, did you switch from source editor to VE in one session by chance? Starting with Visual Editor (i.e. for Abortion) shows the edit notices for me (albeit in a squished display as mentioned). Starting with source editor and then switching to VE looses the edit notices (they should still be available clicking on the exclamation mark in the menu) --> this seems to be a bug (Windows XP, Vector, Firefox). GermanJoe (talk) 02:27, 22 March 2017 (UTC)
@TheDJ: Just reproduced on another computer, with a vanilla Chrome install - generic wiki account using Vector but with text editor default. Open the page, got the edit notice, switched the VE - no more edit notice. — xaosfluxTalk23:42, 22 March 2017 (UTC)
First of all, I apologize in advance if VP/T is the wrong place to ask this. I'm trying to figure out how to add a "navigation template" of some kind to the tops of my archived user talk pages as well as to either fix or remove (if it can't be fixed) the red-linked "Archive 1" in the archive box on my main user talk page. I've tried reading through H:ARC, but can't seem to figure out what to do. Basically, I'd like to be able to move chronologically from one archived page to another without having to return to my main user talk. My archives were set up by another editor back when I started editing; I asked them for assistance early last year, but they no longer appear to be active. So, if anyone can advise me on how to do this type of thing or where to better ask for assistance, then I'd be most grateful. -- Marchjuly (talk) 04:40, 23 March 2017 (UTC)
Thank you so much for taking the time to do all that. If you don't mind, then sure please fix the old pages as well. -- Marchjuly (talk) 05:33, 23 March 2017 (UTC)
I guess you mean navigation templates. They are deliberately omitted in mobile to save bandwidth and screen space. Mobile does not have collapsible tables so they would all be expanded. They are excluded from the download so you cannot make them visible with user CSS. PrimeHunter (talk) 11:11, 23 March 2017 (UTC)
Media widget?
Who develops the media player used to play movies on Wikipedia/Wikimedia? Is there a discussion page just for this widget? Thanks. SharkD Talk 21:10, 23 March 2017 (UTC)
Do you think you could patch in a "Repeat" button? I have made cyclical animations such as this one that are meant to be looped back to the beginning and played again over and over. Thanks. SharkD Talk 21:49, 23 March 2017 (UTC)
This may not be the appropriate venue, but if I try to reach the Afrikaans main page (Tuisblad), I just get a blank page
Has it been hacked? The Afrikaans community is in bed now because of the time difference, so if anyone can help here, I'd appreciate
Jcwf (talk) 02:27, 24 March 2017 (UTC)
I am confident in Lua, but I thought I would ask for help instead, so I do not break anything. Concerning Module:Redirect, which retrieves the target of a redirect page, the module uses .prefixedText to return the target of the page. However, I am looking to add (not necessarily replace) the option to use .fullText, and return the contents from that call.
For example, calling {{#invoke:redirect|main|List of Daredevil episodes|fulltext=y}} would return "Daredevil (TV series)#Episodes", where {{#invoke:redirect|main|List of Daredevil episodes}} would still return "Daredevil (TV series)".
This is so that I can check if a redirecting page links to a particular section on a the target article (e.g. the example already given), or if it does not. (For example, Vikings (season 5) redirects to "List of Vikings episodes", no section.) Cheers. -- AlexTW09:32, 19 March 2017 (UTC)
The .prefixedText was added subsequent to my editing, and I don't think I ever thought about this issue. The edit summary for Stradivarius' addition here credits @Jackmcbarn: for the request, so I'll ping him. Wnt (talk) 16:11, 19 March 2017 (UTC)
While I imagine this change would not affect most modules using the getTarget function, some of them may be relying on the fact that the returned title string doesn't include a fragment, so adding one may break them. To avoid breaking them, there are basically two choices: a) go through all the modules using getTarget and alter them to work with fragments if that is necessary (that search gets 103 hits, so it's doable); or b) edit the getTarget function in such a way that it doesn't break existing uses. For b) you could add a flag to either return a fragment or not, or my preferred solution would be to write another function like getTarget that returns a mw.title object instead of a string, and then use that function from the main function instead. If I were to write getTarget again, I'd make it return a title object, as that is more flexible than just a string. — Mr. Stradivarius♪ talk ♪22:34, 19 March 2017 (UTC)
I wasn't thinking about fullText when I wrote that originally. My preference now is actually to switch to that altogether, assuming that it wouldn't break anything. Jackmcbarn (talk) 17:34, 20 March 2017 (UTC)
Also, I'm not too sure what you mean by "a way to do it just for this module". Pretty much anything is possible - for example, you could copy the whole contents of Module:Redirect to a new module and then just edit that a little if you wanted. The important thing is what is going to be maintainable and reusable over the long run. Imagine that you are going to have to come back in six months and edit this module again - what would you do to make that process as easy as possible for yourself? — Mr. Stradivarius♪ talk ♪14:50, 23 March 2017 (UTC)
I can think of a straightforward if inefficient way to go about this. You set up a parameter fulltext as suggested which makes FullTextFlag true; otherwise it's false. Then you replace *.prefixedText with FullTextFlag and *.fullText or *.prefixedText wherever it appears in the module. Then you preview each of the modules where you change the invoke to have the fulltext parameter set, and if need be save them like that for a few days/weeks to see if you get complaints. When every calling module (saving the most used for last) has successfully had the parameter set, you can then safely change that code above to *.fullText. And with no further complaints, you can revert each of the modules you changed the parameter in before. There are probably more sophisticated ways to do this... I personally don't think I'd trust my ability to preview all those modules and/or write up sufficient tests for all of them at once before committing to an edit. Wnt (talk) 22:43, 24 March 2017 (UTC)
Just can not edit Wikipedia
For last 2 hours, I am unable to edit Wikipedia. "Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in." I tried logging out and logging in. Now trying to post now from IP. -- User:Titodutta posted from the 2406:E00:100:EC26:C4E7:B356:863E:4C75 (talk) 18:00, 25 March 2017 (UTC)
a) login.wikimedia,org suggestion did not work here, I am using Firefox 52.0.1 (32 bit). a) I was able to to save edit from private window from my account Titodutta and b) general window anonymously (like the post above), but can not make edit once I log in to my account from Firefox. Chrome is working. --Tito Dutta (talk) 18:31, 25 March 2017 (UTC)
I deleted wikipedia.org and wikimedia.org cookies from Firefox, and then logged in. It is Working now. Wow. Thanks. --Tito Dutta (talk) 18:49, 25 March 2017 (UTC)
It still takes some work to figure out what problem you perceive. San Fernando, Cebu doesn't use {{PH barangay parts}} but if it's previewed there then it displays a collapsed list of the names at wikidata:Q316318#P150. Module:Text count counts the number of names. There are 21 names in the Wikidata item, there are 21 names in the list displayed by {{PH barangay parts}}, and it correctly counts there are 21. So I see no problem in Module:Text count. Are you thinking of the sorting made by Module:Sorted plain list? It places "Sangat" before "San Isidro" while it's probably more common to say space sorts before letters so "San Isidro" should come first. {{#invoke:sorted plain list|asc|San Isidro, Sangat, SanH, SanJ}} produces:
I'm not a Lua coder but it looks like the module simply calls the Lua function table.sort which uses a default Lua sort order. It's possible to supply your own order function but I guess it would complicate matters and hurt performance. If there is no serious problem with Lua's sort order then I think we should stick to it. Ignoring spaces and some special characters seems like a valid option to me. PrimeHunter (talk) 14:53, 24 March 2017 (UTC)
yes, the sort is based on the default string ordering in LUA. it is possible to change the comparison function (indeed we do something special for numbers) but you would need to do some additional string processing. Frietjes (talk) 18:19, 24 March 2017 (UTC)
Certainly you can add a parameter to use a different sort function; that wouldn't adversely affect performance anywhere it wasn't specified. But what order do you want? You'll have to be very clear. Wnt (talk) 22:54, 24 March 2017 (UTC)
Sorry I had a bit of it wrong when I started this question. I had the {{PH barangay parts}} ready to get the problem, as I hadn't actually committed the update. So yes it should have been same as Frietjes tried. As I said, a better looking problem can see in Siquijor, Siquijor. Basically, it should have the list emitted "normally". {{#invoke:sorted plain list|asc|San Blas, San Carlos, San Isidro, San Tomas, Santa Fe, Santa Ursula, Santat }} produces:
San Blas
San Carlos
San Isidro
San Tomas
Santa Fe
Santa Ursula
Santat
I think it should be the first approach at Alphabetical order#Treatment of multiword strings. [ As an aside, but there was a problem with a name including a comma. There was only one. I had to change Juan Climaco, Sr. (Magdugo) to become Juan Climaco‚ Sr. (Magdugo): {{#invoke:sorted plain list|asc|Juan Climaco, Sr. (Magdugo) }} –
Juan Climaco
Sr. (Magdugo)
versus {{#invoke:sorted plain list|asc|Juan Climaco‚ Sr. (Magdugo) }} –
the sort order is determined by the result of the LUA string comparison, so if you want a different sort order, you have to create a different string comparison function. as for the comma in "Juan Climaco, Sr. (Magdugo)", clearly, if you asking it to split on the comma, it will split on the comma. if you have commas in the entries, then use a different delimiter. as for an actual problem in an article, when I check Toledo, Cebu there seems to be no actual problem in the list in the infobox since you used "," instead of "," for the comma. Frietjes (talk) 13:03, 25 March 2017 (UTC)
Reading the first option, it basically treats space as the highest alphabetical value, whereas the second omits it. I was disappointed to find that ~ and @ have the same treatment as space, but still {{#invoke:sorted plain list|asc|SanZZZZZZIsidro, Sangat, SanH, SanJ}} -> >
SanH
SanJ
SanZZZZZZIsidro
Sangat
. We can do a simple substitution of all the input parameter spaces to ZZZZZZs and then back again in the output, and put a note on it that the module doesn't work on text containing ZZZZZZ when the alternate sort algorithm parameter is set. Then we have a working option with only a small linear-time overhead for the substitution, rather than doing the whole sort more slowly. (This is still an awful kludge ... there must be a better way someone is about to tell me...) Wnt (talk) 19:19, 25 March 2017 (UTC)
Unexplained italics in an article
Several paragraphs in the Cowdenbeath article appear in italics even though they aren't enclosed in a pair of double apostrophes. It looks odd and I've tried to remove it but I've had no success and can't figure out what is causing the problem. Can anybody diagnose and fix this nonsense as it has me stumped! Keresaspa (talk) 00:58, 25 March 2017 (UTC)
this seems to fix it. My method was to remove ... stuff ... until the italics went away. The DIVs were obvious candidates, both in terms of their location immediately above the first instance, and then because they're just plain not the way we do things here. Why they had the result they had is above my pay-grade. --Tagishsimon (talk) 01:29, 25 March 2017 (UTC)
My user script files (local and global) and gadgets have stopped working consistently
I have local (User:StevenJ81/common.js) and global (m:User:StevenJ81/global.js) script files that I use regularly here. Up until about two weeks ago, they generally ran correctly. Every once in a while I'd have a problem that they didn't automatically load; I attributed that to issues with MediaWiki upgrades, because by a week later or so, when the next upgrade was loaded, things starting working right again. However, this time, it's been about 2.5 weeks, and things are still not working right.
Here are some technical details:
Started two weeks ago, I think right after a MW upgrade.
I've seen the problem on two different computers. One is running Windows 7 Enterprise, and I've had problems both under Google Chrome (my usual browser, v. 56.0.2924.87) and also under IE (v. 11.0.9600.18537). The other is running Windows 10, again with Chrome. However, I don't have the problem on my iPad (iOS 10, running Safari, running in desktop rather than mobile mode).
Bypassing the cache helps sometimes, but not always.
Similarly: sometimes my script files load properly, sometimes they don't. On enwiki, they probably load properly more often than they don't, but no more than about 2/3 of the time. On Meta, they rarely load properly at all.
Looking at the JS console, even when pages run correctly, I am told I'm using some deprecated modules. When the pages don't run correctly, I also get an Uncaught TypeError: Cannot read property 'add PortletLink' of undefined and then gives me links to four different times it could not do so.
Testing the situation by removing certain tools from the script files one at a time does not consistently help.
To repeat: until 2.5 weeks ago, things were working correctly.
If this were only affecting my script files, maybe that would be my problem. But it also affects gadgets and mw:Extension:Translate.
I did test it in my user sandboxes beforehand, where it didn't change the display of the transcluded template. The issues linked there are different, the first is people having the wrong content model on a page where it is supposed to be JS and the second was an issue with how the page history interacts with content model changes. Jo-Jo Eumerus (talk, contributions) 19:21, 26 March 2017 (UTC)
My humble opinion is that changing the content model should occur only when it provides a substantive benefit. I think the only effect in the above example is that Template:Divbox/style/gray looks pretty, and that is not sufficient to balance the confusion to people wondering why it looks pretty and what a content model is. On that last point, can someone explain the implications of setting a content model? The waffle at mw:Help:ChangeContentModel does not do the job. For example, does the js content model enable execution of script? Johnuniq (talk) 01:50, 27 March 2017 (UTC)
@Johnuniq: Content model changes change the way the page displays, like introducing the boxing for JSON pages, syntax highlighting in JS and CSS pages and forming the list format in MassMessage pages. So yeah, it's mostly a cosmetic thing - I'll stop doing it. Unless it's on an userspace page, then changing the content model from and to CSS/JS can cause the automatic protection that user JS and CSS enjoy to disappear (or appear), so one must be careful there. Jo-Jo Eumerus (talk, contributions) 14:46, 27 March 2017 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
When you edit with the visual editor, you can see a visual diff as well as a wikitext diff when you review your changes. [81]
Problems
Special:AllPages was disabled for two days due to some performance issues. It is back, but the filter for redirects is gone as the cause of the performance problem. It still needs to be fixed. [82][83]
The new version of MediaWiki will be on test wikis and MediaWiki.org from March 28. It will be on non-Wikipedia wikis and some Wikipedias from March 29. It will be on all wikis from March 30 (calendar).
I've had this problem maybe 200 times in 43,000 edits spread over 7 years. (so it's only happening about once in 200 edits) So I assumed it was common and thought I could find it in the archives but couldn't. Each of these times is a case where there is a new line in the editing text but the text is all run together, i.e. there is no line break where there should be one.) when the page is displayed. Usually I can fix it by just entering a new line. This morning I just had the most stubborn one ever (at the bottom of the wp:ver talk page by the subsection title "Force line break") where the line break was badly needed where nothing I put in could cause a line break until in desperation I put in a section header just to cause a line break. This has been on many different computers although the only browser I use is Firefox. Does anyone know the cause or fix of the problem? Is it likely to show only on my computer (in which case I could just leave it) or would the problem show up all over the place? North8000 (talk) 19:55, 24 March 2017 (UTC)
Thanks! Also curious about the more common case where a blank line is all that it takes to fix it. North8000 (talk) 21:08, 24 March 2017 (UTC)
The default behaviour of wikitext has always been that a newline in the source does not produce a newline in the rendering.
This sentence is on its own source line but the rendering doesn't show that.
To get a new rendered line you need something other than a single newline, for example a blank line (i.e. two consectuive newlines), a <br />, or at least one of the two lines starting with a colon or asterisk. See more at Wikipedia:Line-break handling. PrimeHunter (talk) 21:30, 24 March 2017 (UTC)
Wow. I remember the days when <p> was a self-closing tag and closing it was frowned upon. It surprises me that closing it is now obligatory, and failing to do so creates a hard to find bug ... was MediaWiki always like that, or was something changed? Wnt (talk) 23:05, 24 March 2017 (UTC)
The wikicode parser has many quirks. I didn't know this one, but it doesn't surprise me either. When you mix html parsing, with wikicode parsing and then need several sanitizer runs, things start behaving weird :) Doubt it's new behavior however, we almost never make changes to the parser anymore (exactly because it's impossible what weird stuff would break). —TheDJ (talk • contribs) 13:05, 25 March 2017 (UTC)
Yes, I was replying to "Also curious about the more common case where a blank line is all that it takes to fix it." I omitted indentation to demonstrate that a single newline has no effect. PrimeHunter (talk) 23:50, 24 March 2017 (UTC)
Thanks to all! I never noticed that a single line break never forces a new line. I guess I missed it because it's rarer to do that than I realized. Usually line breaks are also a paragraph breaks or something else like bulletting. Sincerely, North8000 (talk) 16:42, 27 March 2017 (UTC)
Local clock gadget apparently enabled without user intervention
I do not recall enabling the clock. I noticed it for the first time today on my personal toolbar and the time has caused some confusion (since the UK is on BST and is presently a UTC+1 time zone).
It would seem that the gadget was enabled automatically and this is arguably undesirable. Assuming that this gadget is somehow enabled by default, I propose that it not be.
@Martin Ming: It is not enabled by default. Usually when reports like this come in, people have managed to accidentally enable a gadget by exploring their preference, or they enabled in the past, but for various reasons it didn't work for them back then. Then something in the flow of the website, or their browser changed, causing the gadget to suddenly start working, giving the perception of it having been freshly enabled. —TheDJ (talk • contribs) 14:47, 28 March 2017 (UTC)
section headings not functioning correctly
At Wikipedia:Redirects for discussion/Log/2017 March 27 there are 13 level 4 section headings, however headings 1.6-1.9 ("Agie", "Mankri", "Amtrak acs64 622" and "Twenty One Pilots (album)(redirects)") have no edit links, and their content is visible when you click to edit section 1.5 ("First aerial victory by the U.S. military") as if they were subheadings. All the wikimarkup in those sections works as expected and the anchor links from the table of contents work exactly as they should too. I can't see anything in section 1.5's code that is obvious to me but I'm no coder. Thryduulf (talk) 08:08, 28 March 2017 (UTC)
Fixed, I think. A bracket mismatch in a link meant everything after an opening {{ was considered part of a template. Nthep (talk) 08:18, 28 March 2017 (UTC)
I bumped into this with an edit made by Headbomb. WikEd will automatically convert actual non-breaking spaces to their HTML entity representations. I think this is broadly a good thing, though it can be unexpected. --Izno (talk) 11:27, 28 March 2017 (UTC)
"In this Philippine name. The family name is {{{first}}} ."
The correct dabnote/hatnote wording should be
"In this Philippine name, the family name is {{{first}}} ."
I have no idea how to fix this issue. Could someone type out the code-fix here explaining the whys etc and then go fix it on the page? I tried to look at the code but am *so* not a coder and it all just looks like mush to me. Plus I don't understand how to get the different results listed on the Template's page. Explanations of the changes are really appreciated - they help me learn how to maybe do this sort of thing the next time. Thanks in advance O Smart Ones - Shearonink (talk) 17:04, 28 March 2017 (UTC)
Wednesday, 3 May 2017 (two weeks later), starting at 14:00 UTC
Those who remember last year's similar project already know the drill: Please share the news with your friends and favorite bot ops (it's possible that a bot or two will need to be restarted), don't try to save something important at the last possible second (because you might lose your work), and could someone make sure that the IRC help channels are aware of this event?
If you are a MediaWiki hacker, then please note that the normal deployment schedule has been canceled during both of those weeks.
Recently, my Twinkle just stopped appearing on my screen. I have checked my preferences, but Twinkle option is applied. However, when I checked Twinkle preferences, it said that I did not have Twinkle installed. Can you help me out? --Cheers, FriyMantalk16:36, 29 March 2017 (UTC)
I do not know if this is magic or something else, but the second I entered the history of my common.js page, the Twinkle started working. Thank you for advice. --Cheers, FriyMantalk20:36, 29 March 2017 (UTC)
I never encountered this. It made editing the pmid very weird, both in AWB and in Wikipedia's editing window.Headbomb {t · c · p · b}21:47, 29 March 2017 (UTC)
It appears to be the Hebrew word which Google says translates to "Foundation". Hebrew script does make editing very difficult, as it goes in the opposite direction to English. DuncanHill (talk) 21:50, 29 March 2017 (UTC)
It's definitely related to that. geo: is in mw:Manual:$wgUrlProtocols like http://, https:// and many others. They behave similarly (just displaying without doing anything) in wikilink syntax with a space right after the protocol: [[geo: something]], [[http:// something]]. Compare to unspaced [[85]] ([[geo:something]]) or [[86]] ([[http://something]]. They are interpreted as external link syntax where the inner brackets make the external link while the outer brackets have no syntactic function but are just displayed. [geo: something] should display "something" on a link to [geo:], but no external link can actually be made when there is nothing after the protocol. So [[Geo: Geography and Environment]] was never supposed to make a wikilink. It was supposed to make an external link to [geo:] with link text "Geography and Environment" and some arbitrary characters which happen to be brackets displayed around the link. Summary: It's a quirk, just ignore it. PrimeHunter (talk) 02:16, 30 March 2017 (UTC)
There are some changes to the OOjs UI. Some old functions will not work anymore or not work as they used to. This could be a breaking change. [3]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 February. It will be on non-Wikipedia wikis and some Wikipedias from 8 February. It will be on all wikis from 9 February (calendar).
Thanks, Cyphoidbomb (talk) 17:56, 7 February 2017 (UTC)
Resolved
Fixed. There was an unclosed "div" tag that appears to have been messing up the mobile view. Pinging White Arabian Filly. – Jonesey95 (talk) 00:10, 11 February 2017 (UTC)
_movements.gif)
_movements.gif)
Thank you for contacting the right people! DennisPietras (talk) 04:11, 11 February 2017 (UTC)
DennisPietras (talk) 20:33, 11 February 2017 (UTC)
Done Thanks, all sorted - I had changed back to MonoBook but had a custom .css that I had last edited in 2009 including "#talkheader {display:none;}", funnily enough that suppressed the talk header. Please ignore my stupidity! |→ Spaully ~talk~ 12:07, 18 February 2017 (UTC)
_2017-02-19.png)
—ATS 🖖 talk 02:38, 17 February 2017 (UTC)
Resolved Thanks, User:Deskana (WMF). @Nyttend: I simply typed the characters and normal spaces on a regular US keyboard. Thanks for your help. AHeneen (talk) 22:29, 24 February 2017 (UTC)
Done. — JJMC89 (T·C) 05:42, 23 March 2017 (UTC)
Working now. Wow. Thanks. --Tito Dutta (talk) 18:49, 25 March 2017 (UTC)
_movements.gif){kind=link}
You are invited to join the discussion at WT:NFCC#Template:Missing rationale2. -- Marchjuly (talk) 06:08, 29 March 2017 (UTC)