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.
The Internet Achive link at Martin Luther#External links returns 18 271 results. Adding |birth=1483|death=1546|sopt=t only reduces them to 18 265. Is there a way to reduce the results returned?
A direct link to the IA page with relevant filters didn't work, maybe because the brackets in the link messed it up:
I wanted to exclude results like Martin Luther King, but now, as I scroll down the results, these do not apppear to turn up. Books in foreign languages do, however, turn up, and I think they should be excluded. Jonund (talk) 15:48, 20 March 2019 (UTC)
@Jonund:, cases like this are difficult because it is a common 2-word name who is popular. About the only way is to build a custom search that filters other known Martin Luthers. Because Internet Archive now uses an infinite scroll it's impractical to scroll to the end to see what might be there. The site Internet Archive Classic Search allows paged viewing to get deeper into the results. Looks like filtering out "luther king" helps a lot: 6,012. BTW I don't think we should filter English language because end-users can easily do that through the side bar. I've added this custom search to the template. -- GreenC16:49, 20 March 2019 (UTC)
I noticed something in the infobox on the England, Wales, Northern Ireland, and Scotland articles (tho it might be on more). When you hover hover the the biggest "zoomed in" part of the map, the tooltips have some css in them (eg, Scotland's is Location of .mw-parser-output .nobold{font-weight:normal}Scotland (dark green) – in Europe (green & dark grey) – in the United Kingdom (green)). I tried poking around the wikitext used in the templates, but I can't seem to find the cause (might be due to how templatestyles injects Template:Nobold/styles.css, but that would probably require a phab ticket). --Terra(talk)06:57, 18 March 2019 (UTC)
It's due to the usage of {{nobold}} in {{Infobox_country_UK}}. I'm not a fan of adding templatestyles to inline and 'style only' templates like that. It makes no sense, because the CSS belongs with the template USING nobold, and the nobold template should be removed from a template that is using it really. —TheDJ (talk • contribs) 07:35, 18 March 2019 (UTC)
Hello all, sorry about this but I am a complete novice when it comes to this stuff, hence why I am asking for help..... The clean-up list for WP Yorkshire has been going to a blank page with 502 Bad Gateway error for about five days now; anybody any ideas how to resolve this? Is it as simple as repointing the link? Help! *Clean up list is here. Thank you and regards. The joy of all things (talk) 19:33, 18 March 2019 (UTC)
and you zoom at different levels, you will often have lists broken up over multiple columns. Is there a way to have everything on Header 1/Header 2/Header 3 kept together, much like {{nowrap}} prevents things from spilling over multiple lines, so you have something like
Request for testing and feedback: Automated article section recommendations
The Wikimedia Research team is developing a new method for automatically recommending sections to add to stub articles. This method uses machine learning to suggest sections that could be added to an article, based on the sections that exist in other articles on similar topics.
We think this method could be useful for helping new editors find useful onboarding tasks to do. But before we build anything, we need to test the quality of the recommendations.
We are looking for experienced editors to evaluate these recommendations and provide feedback to help us improve them. We have built a testing tool that makes it easy to provide quick, survey-style feedback on the quality of the recommendations, and we are also interested in more detailed feedback on the project feedback talkpage.
If you are interested in giving us feedback, please get started by reading the instructions here and then start rating articles!
If you have questions about the project or more general feedback, you can reach us here.
@Capankajsmilyo: I don't know of such a list. Normal wikitext searches won't work for this because most child infoboxes also have names beginning with "infobox".
I don't think there are any policies that would directly affect infoboxes in this way. Wikipedia:Manual of Style/Infoboxes does not have any guidance on this, and the language implies (but does not explicitly say) that one infobox is the default. Regardless, as you've probably noticed, in practice there are a number of pages which include more than one infobox, often to describe multiple topics or entities covered in the same article (e.g. Great Belt Fixed Link), or to separate information into groups (e.g. Georgetown University). Jc86035 (talk) 14:35, 20 March 2019 (UTC)
Not all infoboxes permit nesting in that manner. Then there are articles with two independent infoboxes because they deal with two different objects or two different events, that share an article because they have certain things in common, such as location - for these, nesting would not be appropriate. For example, Manchester Piccadilly station where there is one in the lead and another at Manchester Piccadilly station#Piccadilly tram stop. Then there is Rail accidents at Morpeth which has five, none being in the lead. --Redrose64 🌹 (talk) 16:50, 21 March 2019 (UTC)
But the UTC time in the source is in the future. It's from a new user. I guess they haven't learned to sign with four ~~~~ which adds a time stamp. They probably wrote the time manually in their own time zone and copied "(UTC)" from another post without knowing the meaning. Maybe their teacher is to blame :D PrimeHunter (talk) 10:51, 22 March 2019 (UTC)
I noticed that the Template:Infobox settlement has two population fields: population_total, and population_density_km2. A person asked a related question at the help desk and when trying to answer the question, I noticed that these aren't text fields, and so you can't put a year in parenthesis ex: (2019) after the values, in case they are from different years. I tried to add citations after the numbers, and population_total allows it, but if I try to put a citation after population_density_km2, the field disappears. Is this the intended behavior? The article I tested this with is Jeju City if you want to see if you can duplicate this. TimTempleton(talk)(cont)00:34, 22 March 2019 (UTC)
Template talk:Infobox settlement is active. You can ask questions there. Some numeric infobox parameters are used for calculations, e.g. conversion between km2 and sq mi, or density = population/area. This requires pure numbers (commas may be stripped but not always). If they are not numbers then calculations may be omitted or produce errors, or the parameter may be ignored. If population_density_km2 is set to auto then it's calculated from population_total and area_total_km2 so those parameters cannot have a reference in this case. population_note can be used for a reference. If the infobox cannot convert density between km2 and sq mi then it appears to omit the field. I suppose it could be coded to just output whatever was put in and hope it makes sense. PrimeHunter (talk) 10:14, 22 March 2019 (UTC)
@Timtempleton: This is why the |population_as_of= parameter was provided. There is also |population_footnotes= for the reference, and |population_note= should additional text be necessary. --Redrose64 🌹 (talk) 15:50, 22 March 2019 (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 later this week
When you use rollback you will be able to get a confirmation prompt on most wikis. It asks you if you wanted to do the rollback. This is to avoid misclicks. You will have to opt in to get it. On German Wikipedia it will be an opt-out feature from 28 March. [2][3]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 March. It will be on non-Wikipedia wikis and some Wikipedias from 20 March. It will be on all wikis from 21 March (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 20 March at 16:00 (UTC). See how to join.
Future changes
Admins will be able to block someone from editing a page or a namespace. This already works on a few Wikimedia wikis. You can read more. If your wiki wants to be an early tester of this, you can tell the developers. [4]
Toolforge will shut down the Ubuntu Trusty job grid. This will happen the week of 25 March. Tools that use this grid needs to be moved to the new Debian Stretch job grid. If they haven't, they will be taken offline. Maintainers can restart the tools later. Users may not be able to use them in the meanwhile. You can see a list of affected tools.
About the "Partial blocks": My team isn't involved, so my information may be out of date, but this is supposed to let admins block someone from ≤10 specifically named pages, or from one namespace (e.g., no direct editing of articles or templates), so it might be useful for enforcing some types of TBANs in software. If the English Wikipedia wants to try this out, then I believe that the team will need proof of community consensus, and that if you don't specifically request it, then it won't be offered here until most of the other wikis have tried it out first (because scale). Whatamidoing (WMF) (talk) 19:34, 22 March 2019 (UTC)
Being able to block editing based on one or more categories would be absolutely aces for topic bans.--Jorm (talk) 19:37, 22 March 2019 (UTC)
That team has talked about it, but hasn't figured out how to make it happen yet. I suggested once that they consider planning for hidden cats like "Category:Pages covered by ArbCom case Example", rather than a regular content cat such as "Category:Cancer" (which might be added or removed by people who didn't understand the related effects). Of course, it wouldn't be perfect (for example, if you're banned from editing about a subject, then you're banned from creating pages on that subject, too, even though those new pages won't be in any category yet), but it might be helpful overall. Whatamidoing (WMF) (talk) 19:50, 22 March 2019 (UTC)
Another danger is someone adding or removing the category to screw around with what someone else's block covers. True, in most cases that would lead to a swift block for the user/IP doing the screwing-around, but we do have plenty of wikilawyers around who might take "broadly construed" pretty broadly... Anomie⚔02:14, 23 March 2019 (UTC)
Changes not being marked as read immediately
Seems to have started a few days ago. If I view a diff for a change made on whatever page, it still shows up as bold in my watchlist. Amaury (talk | contribs) 13:26, 22 March 2019 (UTC)
@Amaury: I find that if you remove the affected article from your watchlist temporarily (remove it, then add back ... with that "star" by the read, edit and view history tabs), it will clear the bold. Still annoying, but that's one workaround. MPFitz1968 (talk) 07:02, 23 March 2019 (UTC)
New Tool: Whodunnit
I just threw together a git blame-like tool to help visualize who the text on a page came from. It could be useful for cleaning up after problematic editors, or just for the curious. It's still fairly WIP, but it works well enough. It's available at toolforge:whodunnit; the source is here. Gaelan💬✏️06:57, 23 March 2019 (UTC)
Redrose64, not quite the same thing—WikiBlame searches for a specific phrase, while my tool displays the text of the page, color-coded by the user that added it (and lets you hover over a piece of text to see the specific edit). Gaelan💬✏️15:25, 23 March 2019 (UTC)
I have the following in my vector.js: LocalComments = { dateDifference: false, dateFormat: 'mdy', timeFirst: false, twentyFourHours: false, dayOfWeek: false, dropDays: 0, dropMonths: 0 };
This changes signature display for me from 2:21 pm, 9 March 2019, Saturday (12 days ago) (UTC−8) to March 9, 2019, 2:21 pm (UTC−8). I want to further customize it to capitalize the AM/PM and remove the time zone (UTC -X), since I know that all times are in my time zone of Pacific. Is that possible? CC: Redrose64. They directed me here after I asked them on their talk page here here. Amaury (talk | contribs) 05:38, 23 March 2019 (UTC)
Numbers OK in "Desktop View" - but Very Low in "Mobile View"?
Question: Numbers added to the "Template:NFPA 704 diamond" are *entirely* OK in the usual "Desktop View" (see, for example, the noted diamond and added numbers in the "Ammonia" article) - HOWEVER - the added numbers are all *significantly lower* in the noted diamond in the "Mobile View" of the same "Ammonia" article (esp with Windows 10/Dell8930/Chrome-Firefox-Opera Browsers) - Thanking you in advance for your help with this - Enjoy! :) Drbogdan (talk) 20:08, 24 March 2019 (UTC)
I guess you mean it varies whether the numbers are centered in the squares or appear in the lower part. I see the same. Alignment like this can be tricky. I posted the example {{NFPA 704 diamond|F=1|H=3|R=0|S=-}} above. Special:ExpandTemplates shows the complicated code it produces with an image map:
<div style="width:100%; background:transparent;"><div id="container" style="margin:0 auto; width:82px; font-family:sans-serif"><div id="on_image_elements" class="nounderlines" style="background:transparent; float:left; font-size:20px; text-align:center; vertical-align:middle; position:relative; height:80px; width:80px; padding:1px;">
<div id="diamond_image_and_mw_ImageMap" style="position:absolute; height:80px; width:80px;"><imagemap>
File:NFPA 704.svg|80px|alt=NFPA 704 four-colored diamond
poly 300 0 450 150 300 300 150 150 [[NFPA 704#Red|Flammability code 1: Must be pre-heated before ignition can occur. Flash point over 93 °C (200 °F). E.g., canola oil]]
poly 150 150 300 300 150 450 0 300 [[NFPA 704#Blue|Health code 3: Short exposure could cause serious temporary or residual injury. E.g., chlorine gas]]
poly 450 150 600 300 450 450 300 300 [[NFPA 704#Yellow|Reactivity code 0: Normally stable, even under fire exposure conditions, and is not reactive with water. E.g., liquid nitrogen]]
poly 300 300 450 450 300 600 150 450 [[NFPA 704#White|Special hazards (white): no code]]
desc none
</imagemap></div><div style="width:12px; text-align:center; position:absolute; top:12px; left:35px;">
[[NFPA 704#Red|<span style="color:black;" title="Flammability code 1: Must be pre-heated before ignition can occur. Flash point over 93 °C (200 °F). E.g., canola oil">1</span>]]</div><div style="width:13px; text-align:center; position:absolute; top:31px; left:15px;">
[[NFPA 704#Blue|<span style="color:black;" title="Health code 3: Short exposure could cause serious temporary or residual injury. E.g., chlorine gas">3</span>]]</div><div style="width:13px; text-align:center; position:absolute; top:31px; left:54px;">
[[NFPA 704#Yellow|<span style="color:black;" title="Reactivity code 0: Normally stable, even under fire exposure conditions, and is not reactive with water. E.g., liquid nitrogen">0</span>]]</div></div></div></div>
Image shows the issue indeed. My thoughts: the creator (could be me ;-) ;-) ) used css styles that are discarded when in mobile view. -DePiep (talk) 20:51, 24 March 2019 (UTC)
@PrimeHunter and DePiep: Thanks for your comments - is there some easy way of centering the numbers in both, the "Desktop View" and "Mobile View"? - or maybe - it may be too difficult - and - perhaps best - to leave well enough alone at the moment - iac - Enjoy :) Drbogdan (talk) 20:57, 24 March 2019 (UTC)
I'd say: rebuild css/style from scratch, but don't distrust <imagemap> for now. It's these pesky little 'style=""' details mobile view ignores, per my first suspicion. -DePiep (talk) 21:05, 24 March 2019 (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 new version of the content translation tool will be used for all new translations. The older version will still be used for translations that were started with it. Most users won’t see any change. More than 80% of the published translations are already using the new version. [6]
Problems
There was a problem with editing with Safari on iOS. When you wrote an edit summary you couldn't save the edit. This has now been fixed. [7]
The editing toolbar sometimes disappears when you scroll on iOS devices. This will be fixed soon. [8]
Wikis can over-ride interface messages on-wiki. A problem meant that sometimes an old versions of any changed messages were shown instead. This included the sitenotice and other important parts of the interface. This was fixed at around 2019-03-22 16:00 (UTC). Logged-out users may still get the wrong message. Purging the page should fix it for them. [9]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 27 March at 16:00 (UTC). See how to join.
@Michael Hardy:vi as in the *nix text editor? We don't have a 'edit in vi' mediawiki hotkey. You could install text editor extensions in to your browser. What browser are you using? — xaosfluxTalk20:08, 23 March 2019 (UTC)
@Michael Hardy: lately? There used to be an option in Special:Preferences#mw-prefsection-editing for "use external editor", but that was removed 5+ years ago. See mw:Manual:External editors. This still required you to configure such an editor (such as vi) in your browser it didn't force a specific application on your computer to launch. You certainly could still have a browser extension for something similar. If anyone else has an idea, hopefully they will chime in and add or correct this below! — xaosfluxTalk21:15, 23 March 2019 (UTC)
I've never seen it but there is a browser extension known as "it's all text" which I believe can be configured to use whatever editor you like when normally a browser edit window would open. Google that phrase for information. I just copy from the browser edit window to my editor, then copy back if I want to post what I edited. Johnuniq (talk) 21:49, 23 March 2019 (UTC)
(edit conflict) (multiple) This feature was at Preferences → Editing, under the "Advanced options" heading, and was titled "Use external editor by default (for experts only, needs special settings on your computer)". It was always disabled for new and logged-out users, I'm guessing that Michael Hardy must have enabled it at some point after registering. It was removed from Preferences with the deployment of MediaWiki 1.22/wmf2 to English Wikipedia on 22 April 2013; AFAIK the removal of this preference also disabled it for all users who had previously enabled it. --Redrose64 🌹 (talk) 21:52, 23 March 2019 (UTC)
To see whether any extensions are installed in Chrome: Click the three vertical dots at the top right, then "More tools" and "Extensions". PrimeHunter (talk) 01:25, 24 March 2019 (UTC)
I have played around with a few external editors tied to browsers, but -- at least to me -- cutting and pasting the source into an external editor, editing (and saving a copy -- occasionally having a copy comes in handy) and pasting it back works really well. Getting off-topic here, but for anyone using Vi or Vim, I highly recommend NeoVim.[10] (In particular. read the section "The Codebase".) [11][12] --Guy Macon (talk) 16:06, 25 March 2019 (UTC)
It's not possible to easly check which user in these categories was recentlty active. Is there list with users speaking certain language by activity? Eurohunter (talk) 18:47, 26 March 2019 (UTC)
Thank you to TheDJ for pointing this question out on irc. Broadly speaking bug reports and technical questions about Toolforge should be made via the cloud mailing list, the #wikimedia-cloudconnect channel on Freenode, or Phabricator. The various wiki village pumps are not monitored for such reports because of lack of staff to watch pages in 800+ Wikimedia wikis. --BDavis (WMF) (talk) 01:26, 27 March 2019 (UTC)
Problem with editing text after inline citation in Visual Editor (in Microsoft Edge)
There seems to be another bug in the Visual Editor (people tell me there are so many bugs in it). If you have an inline citation you cannot set the insertion point to edit any text to the right of the citation. Has anyone else noticed this? 81.139.163.204 (talk) 11:01, 27 March 2019 (UTC)
works in my browser.. Which browser and version of that browser do you use ? If you know how to, maybe make a screen recording that shows your problem ? —TheDJ (talk • contribs) 12:00, 27 March 2019 (UTC)
If I open Equinox in the Visual Editor and try to edit the words after inline citation [7] the insertion point appears between "[7]" and "It" and refuses to move. This is on Microsoft Edge. I don't have the problem on Google Chrome or Firefox. 81.139.163.204 (talk) 12:43, 27 March 2019 (UTC)
The thing that makes things look like a paper letter
I remember fairly recently seeing Wikipedia newsletters with a background that looked like a page with a folder corner on the top left. I'm trying to find them again, and I've been searching for half an hour without much luck. Does someone know the CSS class that makes this happen, or failing that, an example of such a newsletter? Headbomb {t · c · p · b}15:10, 27 March 2019 (UTC)
What happened here? Some spaces seem to be replaced by spaces of a different kind. After this edit, the items type and fatalities are no longer displayed in the infobox. --FredTC (talk) 07:54, 15 March 2019 (UTC)
But how did such spaces get there? I have no way to detect that they are there. When I edit the version I mentioned, and select/copy (ctrl-C) the code for the infobox, then paste it to a notepad.exe file, I cannot see a difference. Can I produce it by accident? How? --FredTC (talk) 11:13, 15 March 2019 (UTC)
Some text editors highlight NBSPs (for example LibreOffice Writer) or have an option to do so (the Show all formatting marks, ¶, option in Microsoft Word). There are feature requests for MediaWiki at Phabricator:
The translation tool also inserts the 160 nbsp character which I have removed several times while cleaning another of its bizarre habits, most recently at diff. Johnuniq (talk) 23:01, 22 March 2019 (UTC)
The current featured article is William Matthews (priest). Clicking Pageviews on its history goes here. That displays "Error querying Pageviews API - Unknown". I don't recall using this tool before. Is that a known issue which clears up in due course, or should I hassle its devs? Johnuniq (talk) 02:06, 28 March 2019 (UTC)
@Johnuniq: It works for me. Do you by chance have a privacy or adblock browser extension, such as Privacy Badger? That is a common cause for this tool failing. Otherwise, please share which browser and version you are using. Better, follow the steps at WP:JSERROR, which will give us even more debugging info. Best, — MusikAnimaltalk02:43, 28 March 2019 (UTC)
Sorry about the noise. I normally check unexpected issues in another browser and when I did that just now it worked. I have NoScript but I thought I had disabled it. There is some issue here, thanks. Johnuniq (talk) 03:09, 28 March 2019 (UTC)
Greetings - On 23 March,I posted a notice here about enwp10 tool being down. Wondering if anyone here knows how to do this move? It's totally beyond my knowledge. Regards, JoeHebda (talk) 00:29, 26 March 2019 (UTC)
Documentation is at wikitech:News/Toolforge Trusty deprecation, but migrating tools requires maintainer intervention. Pinging Kelson. The other maintainer listed is "tmoney" but I'm not sure what their username is here.
Just FYI, there are a LOT of tools that were not migrated to Stretch and probably broke today. Maintainers should have received numerous emails about this over the past two months. — MusikAnimaltalk02:53, 26 March 2019 (UTC)
Today is the day (for the first time since the toolserver migration 5 years ago), where we will find out how many tools are not being used (broken but no complaints) and how many are not being maintained (complaints but no one to fix them)... —TheDJ (talk • contribs) 08:13, 26 March 2019 (UTC)
Is there a way to automatically collapse a table on mobile?
WP:CRAPWATCH displays fine on the desktop view, but loading up the mobile website seems to lose the collapsible tables (class="mw-collapsible mw-collapse"). One of the big reasons to make these tables collapsible is to make the mobile view more manageable, so it's a bit annoying that this doesn't work. Headbomb {t · c · p · b}18:11, 28 March 2019 (UTC)
If you are referring to the navbox, which is the only collapsible thing that I see on the page and which is not a table, the navbox class is not displayed on mobile. See WP:NAVBOX. – Jonesey95 (talk) 19:00, 28 March 2019 (UTC)
Yeah, I suppose I should have searched the page for "show" and "hide" like a smart person. Sorry about that. Anyway, I think your question will need an answer by someone more familiar with the interface configuration files like MediaWiki:Common.js and the other files listed at Template:CSS and JS MediaWiki messages. My guess is that the collapsible show/hide stuff is not rendered on mobile for some reason. – Jonesey95 (talk) 21:12, 28 March 2019 (UTC)
It's mostly to display automatically collapsible article content in articles for phones that have old browsers / browsers without javascripts. Wondering if there's a way to bypass that, and support collapsible tables for modern mobile browsers, which do support collapsible tables. Headbomb {t · c · p · b}21:25, 28 March 2019 (UTC)
Template:More citations needed section is a talk page?
@Eman235: Because of a page move by @Anthony Appleyard - I reverted the move, but now the prior template needs to be undeleted. I blanked the page, so for now it shouldn't show up on pages when it is transcluded. --DannyS712 (talk) 17:49, 28 March 2019 (UTC)
Warning: Authority control with VIAF, and also double identities
While editing the article Henry Moskowitz (activist), a "Warning: Page using Template:Authority control with "VIAF", please move this to Wikidata if possible (this message is shown only in preview)." displayed on the screen. Also, there are two Template:Authority control assigned to this article and both have this warning message. I don't know how to fix this issue. Mitchumch (talk) 22:32, 28 March 2019 (UTC)
This might be better asked at Template talk:Authority control. However, the issue is that the article contains {{Authority control|VIAF=190653772}} (and a second) and the warning is saying it should just be {{Authority control}} and the VIAF value should be placed at Wikidata. To do that, click "Wikidata item" in the toolbox on the left and play around with the VIAF setting. Problem: Wikidata already has VIAF=21135876 with a claim that it was imported from enwiki. Some checking of the VIAF values needs to take place to determine what's going on. There should be only one VIAF, and it should be at Wikidata. Johnuniq (talk) 22:57, 28 March 2019 (UTC)
It looks like the bot that maintained that page no longer runs and stopped right around the time Wikidata started, but I don't see if a similar automated process was set up on Wikidata. --Izno (talk) 13:01, 29 March 2019 (UTC)
Both VIAF and ISNI are federated databases. A close look at the two VIAF records or at the corresponding two ISNI records shows that they originate from different national libraries. One identity [13][14] comes from US and Israel, while [15][16] comes from the Netherlands, Ireland, and France. Each attributes a different birth year (1878 vs. 1880), which may have delayed ISNI in recognizing and resolving the duplication. A simple heuristic of referring to the lowest-numbered VIAFid (the former) will avoid having a duplicate Q number in such cases, and when the VIAF and ISNI deduplicates are eventually done, that lowest number will either be used or redirected. A more challenging problem arises when the VIAF or ISNI records conflate identities, as is almost unavoidable for common names, but this too is well understood by librarians.LeadSongDogcome howl!16:43, 29 March 2019 (UTC)
Talk page button on Kindle gone
I often browse WP from my Kindle eBook reader, including Talk pages. Up until a few days ago, at the bottom of each article page there was a button to link to the Talk page (it does not appear on my desktop in Chrome). The Kindle browser does not display the usual WP top-of-page menu (talk history &c) so this was very handy. Now the <Talk> button no longer appears. Was this a recent WP change, or do I assume it was a Kindle update? --D Anthony Patriarche (talk) 12:11, 29 March 2019 (UTC)
D A Patriarche I also happen to do that sometimes. Best solution could be to use desktop view by going to the very bottom in mobile view (I think it uses that by default) and pressing "Desktop". SemiHypercube15:35, 29 March 2019 (UTC)
I forgot the password for my account and there's no email attatched, is it possible to put an email onto my account?Muur (talk) 18:28, 29 March 2019 (UTC)
Something appears to have broken the {{Indian states and territories image map}} clickable map, and a quick check shows that this 2011 edit now throws up a "Invalid coordinate at line 61, must be a number." and subsequent versions don't render (prior versions still work; example). I am assuming this is a recent issue unrelated to an edit made to the particular template, since the error otherwise would surely have been spotted sooner. Anyone have an idea what the issue could be and how to resolve it?
Honestly I'm not too sure. The last time I edited the template was back in 2014, and it was working well back then. Looking at the revision history in 2011, the map was edited to add the shapes of states as polygons as opposed to before, when just a rectangle for a link was present for each state. That could be where the problem lies. I recall adding more polygons to the map using ImageMapEdit. --RaviC (talk) 22:34, 28 March 2019 (UTC)
Is it working properly, even after that change? Hovering my mouse over various parts displays two different pointers - an arrowhead for non-sensitive areas, and a finger for sensitive areas. The sensitive areas do not cover the whole map, missing out the southern portions. Clicking on a sensitive area displays a criss-cross tangle of blue lines covering a roughly rectangular shape, before going to the article for the relevant state. --Redrose64 🌹 (talk) 23:14, 28 March 2019 (UTC)
I think it is working "as written". The issue you point to is due to the fact that not all states have a clickable area defined by their polygonal boundary corresponding to their borders. Many states (eg, 7, 15 etc) have a clickable area defined by a much smaller rectangle that covers only (approx) the numerical index in the image. The way to resolve this would be for someone to trace the boundaries of the latter group of states and update the template code. The current version is non-ideal but functional. Abecedare (talk) 23:37, 28 March 2019 (UTC)
It doesn't seem to be working properly for me as it used to before. I'm not sure why, but the polygons for some states (e.g. Maharashtra, Tamil Nadu) aren't there any more. Clicking near Gujarat brings up a hyperlink for the Siachen Glacier. Something has happened to the template and it probably needs to be rewritten now. --RaviC (talk) 00:01, 29 March 2019 (UTC)
You are right! What I was interpreting as "x.y" coordinates, seems to be just the x- or y-coordinate to two or three decimal places. My converting them to "x y" made the result acceptable syntactically, but completely mucked up the location of the polygons. So undoing that edit.
It's possible that for some reason 'poly' now accepts only integer parameters; but would be good to know that defnitively before someone puts in the effort to repair or rewrite the template. Abecedare (talk) 02:13, 29 March 2019 (UTC)
I think your guess was correct. It wasn't much effort to round all the poly co-ordinates to integers using a perl command on a text file of the wikitext - perl -i -pe 's/(\d*\.\d*)/int($1+0.5)/ge' filename, so I've done that. There's this recent gerrit commit that's probably related. --Begoon02:56, 29 March 2019 (UTC)
Abecedare, See also phab:T217087. A change in the behaviour of the php parser, caused these numbers to throw errors. Because of this, the sanitisation was changed to become more strict and instead of implicitly ignoring the floating part, it now creates errors. This also makes our image maps aligned with HTML behaviour of image maps. —TheDJ (talk • contribs) 09:19, 29 March 2019 (UTC)
Thanks. Fwiw, I agree with your comment there that the rounding/typecasting should ideally happen after the scaling. Abecedare (talk) 14:35, 29 March 2019 (UTC)
Yes, that loss of precision was my concern with rounding the co-ordinates to integers as I did - but since that was all the extension currently accepts I didn't have much option if we wanted the template to work at all. I've added those thoughts to the phab ticket. --Begoon01:27, 30 March 2019 (UTC)
@Begoon: You clearly chose the right and only available option, and the extra decimal places most likely represented false-precision in this instance. My comment was more of a pedantic quibble over 'poly' (unlike 'rect') accepting only integer parameters, which makes the graphics less scalable in theory. Of course this would matter only for scale values >> 1 and I'd be hard-pressed to find examples on wikipedia where it makes a practical difference. Abecedare (talk) 01:42, 30 March 2019 (UTC)
PS: Read Begoon's comment at phabricator and realized that we here are already on the same page and just preaching to the choir :-). Abecedare (talk) 01:44, 30 March 2019 (UTC)
This has worked fine since I created the template two weeks ago, but now it is miscalculating the previous month.
{{#time: M Y |now}} → Jan 2025
{{#time: M Y |now - 1 month}} → Dec 2024
{{#time: M Y |now - 2 months}} → Nov 2024
{{#time: M Y |now - 3 months}} → Oct 2024
The second result, for now - 1 month, is wrong: it should be Feb 2019.
This looks to me like a bug in {{#time}}, probably connected to March being longer than February. If so, similarly glitches will occur at the end of several other months?
@BrownHairedGirl: so yes its a bug, but its not really a mediawiki bug, its a php bug, but it's also not really a "bug" but a "feature". Month math only operates on the "month value" so in this case it takes 2019-03-30 and sets it to 2019-02-30, then the php date fixer comes and "fixes" that to 2019-03-02. If you want to do month math, you have to program for it. — xaosfluxTalk17:40, 30 March 2019 (UTC)
More, this is also because the #time parser uses entire datetimes, your filter doesn't lower the precision it just doesn't display that part of the output. — xaosfluxTalk17:42, 30 March 2019 (UTC)
You might try this to lower the precision:
{{#time: M Y |{{#time:M Y|now}} - 1 month}} → Dec 2024
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.
An image!
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.
Fusce convallis, mauris imperdiet gravida bibendum, nisl turpis suscipit mauris, sed placerat ipsum urna sed risus. In convallis tellus a mauris. Curabitur non elit ut libero tristique sodales. Mauris a lacus. Donec mattis semper leo. In hac habitasse platea dictumst. Vivamus facilisis diam at odio. Mauris dictum, nisi eget consequat elementum, lacus ligula molestie metus, non feugiat orci magna ac sem. Donec turpis. Donec vitae metus. Morbi tristique neque eu mauris. Quisque gravida ipsum non sapien. Proin turpis lacus, scelerisque vitae, elementum at, lobortis ac, quam. Aliquam dictum eleifend risus. In hac habitasse platea dictumst. Etiam sit amet diam. Suspendisse odio. Suspendisse nunc. In semper bibendum libero.
If you're talking about openaccess sidebar adding padding-left:5em to Lorem, then use sidebar-v2 as a type. Too bad that it isn't mentioned in template documentation (or maybe it is in some other place?). --MarMi wiki (talk) 23:47, 30 March 2019 (UTC)
I am currently working on creating required modules and templates in Wikipedia Incubator. I would like to know the mechanism through which the name of a module is being converted into uppercase. Take for example, the template Template:View. In that template, the code actually invokes the module navbar. But when checking the list of modules being used from the option 'Templates used', I am able to see the module with the name 'Navbar'. When I checked the redirects present on the 'Page Information' of the module Module:Navbar, I didn't find anything. If anybody know that mechanism, please comment. Adithyak1997 (talk) 10:26, 31 March 2019 (UTC)
Is there a magic word or similar for a user's image size setting? What I'd like to do is set the size of the images in a gallery to the user's default. Hawkeye7(discuss)19:25, 30 March 2019 (UTC)
The source code of the tool is available at [Github]. If anybody is interested, they can adopt that tool and thus become a maintainer of that tool. Adithyak1997 (talk) 13:43, 31 March 2019 (UTC)
In the more general, why does toolslab have to be so slow and/or crap? Every other day it's giving 404s and 501s etc. Can't the WMF spend just a percentage of its hard-earned (read: given), and provide us with the tools we need to actually improve the encyclopedia? I assume that's what the donations are given towards, rather than merely allowing various unnamed yet by no means unknown characters pissing about in Lear Jets Transatlantic Stylee [/RANT] ——SerialNumber5412915:37, 26 March 2019 (UTC)
Serial Number 54129, because we editors do crazy stuff ;) Seriously though, what people don't realise is that keeping things working requires investment by people. All maintainers of these tools received several emails over the last 4 months that they needed to do something because their software was running on 5 year old operating systems that had been deprecated for 3 years. And really in most cases the maintainers didn't have to do much, other than follow several instructions. They did nothing at all however and thus those tools are now down. I don't see how to fix that problem. If anything, this is a result of WMF continuously giving maintainers of tools maximum liberty, while they should have been more forceful 3 years ago to get people to put in the work of upgrading their software. —TheDJ (talk • contribs) 16:20, 26 March 2019 (UTC)
Not to say there isn't a lot wrong with toollabs that can be improved, there most definitely is (but this is also happening, and if you are a toolcmaintainer it is notable noticeable). At the same time, there are many tools that haven't seen their official maintainer log in for several years, yet being used by thousands of people. The WMF is not an adoption agency for that code just because it runs on their servers. —TheDJ (talk • contribs) 16:22, 26 March 2019 (UTC)
I'm glad to hear that you appreciate my work. I'm sorry if you feel that I have been shirking my duties, but I must clarify that I am not tech support at the WMF's beck and call.
The WMF is not an adoption agency for code, but the flip side of that coin is that we editors and tool maintainers have no obligation to do any more work than we want to. Personally, I'll keep doing what I've been doing. But as it is right now, priorities list wise, this will always sit comfortably below doing what it takes to put a roof over my head and keep the lights on. Which should give you one hint to "fix the problem", in my case at least. I hope this helps. →Σσς. (Sigma)17:32, 26 March 2019 (UTC)
Σ, oh don't get me wrong, that wasn't a value judgement of your work, far from it, it is an observation of how this works. This is exactly why often when Wikipedians say "we need more time", "you should give better announcements" etc etc. I note that it is pointless to do so, because volunteers won't do 'low prio' things until stuff starts breaking. Most volunteers just don't have the bandwidth to handle much of this and neither do I personally as a fellow volunteer expect them to (my hiatuses often stretch for months). Within the tech circles of Wikimedia this is also pretty much universally recognized. But that's also what makes these services completely different from the production level services. Having these tools unavailable once in a while is a sacrifice that needs to be made simply because WMF can't go and hire every tool developer fulltime to turn it into a production level service (although they have hired a sizeable portion of them through the years). Simply respecting things for what they are and then working from there to see how to improve them within those constraints is probably more fruitful than passing around blame. The fact is that our tools can virtually grow infinite in number, but our maintainers of them are not, nor usually have access to the tools of those who left. And after 5 years there is now a moment where that became unavoidably visible. —TheDJ (talk • contribs) 19:07, 26 March 2019 (UTC)
+1 to TheDJ. The 404s/502s/whatevers are usually because of maintainer neglect. WMF Cloud Services merely provides the infrastructure for volunteers to host their tools. They are not and should not be responsible for maintaining code they didn't write. Yes the platform has problems, many of them, but all things considered it is in my opinion a pretty phenomenal service for being free. From my data, actual percentage uptime (at least on VPS) is somewhere between 3 to 4 nines. Many for-profit websites don't come close to that.
Thanks for all the answers, and apologies if it sounded like I was digging anyone out or being particularly unappreciative :) I was not. If anything, it's the WMF I am unappreciative of, as although WP:VOLUNTEER is a sound enough principle for crowd-sourcing an encyclopaedia, it sounds like they could start putting some bloody money into what yous all do. If not by direct payments (although I don't see why not, since the tools directly affect WMF income) then at least with support. Imagine an employee of Google getting 404 when they need to check a copyright status! We might be smaller, but the principle applies, as many of these tools are fundamental to the structure we operate within. Buy the bloody techies a drink for X's-sake! ——SerialNumber5412919:07, 26 March 2019 (UTC)
Serial Number 54129, I note that several tools services over the last years have been upgraded to production services over the last year based on prioritization by the Community wishlist surveys. From advanced search, to xtools, maps, page view stats etc etc. Please contribute again next year in those surveys to continue that effort and celebrate the goals they are achieving. —TheDJ (talk • contribs) 19:15, 26 March 2019 (UTC)
While many tool developers/maintainers are paying attention.. Because of the size of Wikimedia websites and in prepping for future development, several major changes to the core of MediaWiki have been made over the past two years and will be made in the upcoming year.
If your tool talks to the database replicas and does things with editsummaries or log files, usernames, and/or revisions (yes that is a like 90% of what you use that database access for most likely), you should check out the new comment table, the actor table and probably the Slots table if you do a lot with the contents of revisions. At some point in the future, some of the columns that you rely on right now will likely have moved their contents into these new tables and their backwards compatible view will at some point disappear.
For that reason, you should definitely subscribe to the cloud-announce@ mailinglist to keep up to date about the deadlines for such eventual changes.. The one for comments just happened for instance, and since new services on jessie were just made impossible, if you currently run on jessie, now is the time to think about when in the next 1,5 year you are updating your tool, so that when the time comes in 2020, you won't have the same problem as the tools that broke today. —TheDJ (talk • contribs) 19:43, 26 March 2019 (UTC)
All of the database reports (except for lists of edit counts) generated by the Bernstein Bot haven't updated in five days when they are typically updated daily. TheDJ, are you saying that it is likely they won't be updated ever again in the future? Because they are necessary for maintenance of the project. I've contacted the bot operator but a fellow editor said on his talk page that this was a WMF issue of deprecation. LizRead!Talk!18:57, 29 March 2019 (UTC)
Liz if a tool is not maintained, then at some point it might stop working. Maybe if a new volunteer maintainer can be found, the bot can be handed over and brought up to date ? —TheDJ (talk • contribs) 19:58, 29 March 2019 (UTC)
Is PetScan affected by this? I've tried to run some queries today, but they all spin for several minutes before throwing a "502 Bad Gateway nginx/1.13.6" error. --Redrose64 🌹 (talk) 14:57, 31 March 2019 (UTC)
Noprint and metadata classes
I noticed that amboxes have the "metadata" class in their code, so I'm trying to find out the differences between that class and the "noprint" class. Also, where can I find the CSS rules for those classes? --CaiusSPQR (talk) 01:05, 30 March 2019 (UTC)
noprint is do not print, metadata means not part of the main content and what happens with such blocks can depend on the medium, the usecase and the transformation or the user. 14:05, 30 March 2019 (UTC) — Preceding unsigned comment added by TheDJ (talk • contribs)
Izno, there are many more places where they are listed. Our CSS is generally not 'defined in a single location' as our usecases tend to be very complex. CSS targets classnames, it does not define classnames. Our CSS rules are then delivered when needed. noprint doesn't have to be in MediaWiki:print.css, because it is defined by the core 'print only' CSS style rules, which are only downloaded and activated when you actually print. —TheDJ (talk • contribs) 13:31, 31 March 2019 (UTC)
@TheDJ: I chose deliberately not to comment on the use versus definition--only where it was currently used. Naturally, yes, there must be other locations targeting these classes given that their uses in the above are not sufficient to get us to a print-worthy state. In that regard, .metadata is not used in core and .noprint is used in mediawiki.legacy/commonPrint.css. --Izno (talk) 15:51, 31 March 2019 (UTC)
Permission error You do not have permission to view a page's deleted history, for the following reason: The action you have requested is limited to users in one of the groups: Administrators, Oversighters, Researchers, Checkusers.
I am sure that this has to do with me not being an interface administrator (though my limitation here is not that I am not administrator ..). However, I do object to the fact that I am not allowed to see the deleted history/content, but I am allowed to see the history and current content when the page exists, and allowed to delete it (though it is fully understandable and correct that I am not allowed to restore the file). --Dirk BeetstraTC18:34, 31 March 2019 (UTC)
@Xaosflux: nah, I don't need it, thanks. I was merely interested whether there was a history which I was blocked from and resulted in above sentiment. I agree with the phab ticket that we should be able to investigate history, and that real abuse should be handled by oversight. --Dirk BeetstraTC19:34, 31 March 2019 (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 later this week
Notifications tell you about things that happen on the wiki. You can turn on notifications about new links to pages you created. For performance reasons you can no longer get e-mails about this. [18]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 3 April at 15:00 (UTC). See how to join.
The project needs a bot to detect and alert the project of any article, draft, etc. that may be related to the WikiProject. The articles or draft may not have a project stub on it. The project already has Inception bot running, but we need a bot that can review older stuff on Wikipedia. Mitchumch (talk) 04:21, 1 April 2019 (UTC)
@Mitchumch: oh, thats a lot harder. I can generate lists from categories and tag the articles in those, but I don't think I'm the right user to help you out with the rest. --DannyS712 (talk) 04:23, 1 April 2019 (UTC)
You shouldn't need to choose a bot yourself. A number of bots are already approved for this kind of task, and a request at WP:BOTREQ will draw the attention of their operators; one who is willing to take the task will usually step forward fairly soon. What they will want to know are the criteria for tagging - "pages in categories X and Y but excluding pages already tagged for WikiProject Z" is the kind of thing. Please be specific about the categories - avoid saying "... and all their subcategories", since in the past this has led to a lot of mistagging and a great deal of work to undo again. --Redrose64 🌹 (talk) 08:25, 1 April 2019 (UTC)
Hi, I'm trying to add this image [19] to this article Logi Már Einarsson. I searched the English Commons but it doesn't exist there. Is there a quick way to import the image to the English Commons? I can use google translate to transfer the Icelandic text to English. -- Somedifferentstuff (talk) 22:27, 28 March 2019 (UTC)
Looking at the original image, it's taken from the Alþingi website, and appears to be under copyright. Therefore, to use it on English Wikipedia, you need to satisfy all ten of the non-free content criteria; and straight off, I can say that it will fail criterion 1 since the subject is still alive, and so there is a reasonable chance that a free image may be created - perhaps when making a public speech. --Redrose64 🌹 (talk) 23:25, 28 March 2019 (UTC)
Redrose64, according to the copyright section on the photo, it says "Höfundaréttshafi hefur veitt leyfi fyrir að nota myndina - The copyright holder has granted permission to use the image." I assume that is because the person in the picture is an active politician and the Alphing is the Iceland government website. -- Somedifferentstuff (talk) 00:22, 29 March 2019 (UTC)
That being in the template is:Snið:Leyfi-rétthafa. Have they granted permission to Icelandic Wikipedia alone, or to all Wikimedia projects? If the former, they also need to grant permission here (see Wikipedia:Donating copyrighted materials) before we can use it. If the latter, where may the permission be examined?
From Google translate: The copyright holder has granted permission to use the image. It may not be used for marketing or reproduction unless otherwise stated. To the person who uploaded the image: Specify the type of use allowed. All images that can be used for marketing purposes and make reproductions transfer to the Commons. Explanation of fair use. Downloaded wikipedia with informed consent of editor althingi.is; "Portrait photographs of members of the Althingi taken in 2016 and later marked as photographers and with the following text on their permission for re-publishing: The re-use of this photograph is free, provided that the name of the photographer appears where it can be found. In addition, the copyright rights of the author must be respected so that re-use does not improve or alter the author's work to impair his or her authorship or identity." --- Is there a way to tell if this is only for Icelandic Wikipedia? -- Somedifferentstuff (talk) 00:54, 29 March 2019 (UTC)
The files from Althingi where discussed awhile ago at the Icelandic Village pump. One of the users there emailed Althingi, which along with the rights organization of photographers in Iceland decided that the pictures of the congressmen where under an Non-Commercial licence. Their response is quoted in the linked discussion in a comment on November 11 2009, at 23:20 by Jabbi. There is no Icelandic Wikipedia specific restriction on those files, but obviously the Non-Commercial clause does stop them from being transferred to Wikimedia Commons.--Snaevar (talk) 17:22, 29 March 2019 (UTC)
Snaevar, so a government photo can be used on the Icelandic Wikipedia but not the English Wikipedia? I am not well versed on Commons, copyright, etc., but I find that strange. Is it to protect the rights of the photographers? -- Somedifferentstuff (talk) 20:07, 29 March 2019 (UTC)
What? No. It is perfectly fine to use the image on the English Wikipedia, given that it passes the rules here. Maybe I did not make that clear enough.--Snaevar (talk) 14:11, 31 March 2019 (UTC)
So, this isn't a "technical issue". @Somedifferentstuff: there is no "import" process for media from iswiki, assuming it is available under a non-free exemption, you can just download it, then upload it here - and credit the source. If it was actually a free image, you could move it to commons and use it anywhere. Keep in mind, we take image use seriously here (see the comments above) and if the upload violates our rules it will be deleted. — xaosfluxTalk19:35, 1 April 2019 (UTC)
Seen changes not marked as such in the watchlist
Original topic heading: Green watchlist bullets do not turn blue
Today is Thursday. And now when I visit a link from my watchlist, and then go back to the watchlist, the green bullet stays green instead of turning blue. This problem occurs even for deleted redlinked pages. GeoffreyT2000 (talk) 23:36, 14 March 2019 (UTC)
Wow, you just beat me here by like 3 minutes. I've noticed this a couple times today, but in both cases, my watchlist had green bullets for articles in which I had made the most recent edit. If I actually go back to the article, the bullet will go back to blue. –Deacon Vorbis (carbon • videos) 23:40, 14 March 2019 (UTC)
I'm a monobook user and have "unseen changes" set as a filter and "expand watchlist to show all changes" set in preferences. Until recently, if I viewed a change and returned to the watchlist, that change would no longer be showing. Now the item remains stuck in the watchlist. This would seem to be the same problem as above. I think they might clear on browser restart, but I'm not sure on that point – I'll try that in a moment and report.SpinningSpark13:13, 15 March 2019 (UTC)
I'm finding that on all the WMF wikis where I'm active, pages are only inconsistently marked as read after I look at the changes. I'm pretty sure this problem started less than 48 hours ago. It's really frustrating and makes my watchlist hard to use. —Granger (talk·contribs) 14:22, 15 March 2019 (UTC)
@TheDJ: If this is a timing issue, then it is persistent for an extraordinarily long time. Yesterday, I had items in my watchlist that hadn't cleared after several hours. I eventually dealt with it by "mark all pages visited" nuclear option. There does seem to be some inconsistency - I was looking at the possibility that it was connected with the number of unseen edits on an individual page or whether one viewed the page or the diff, but for the last couple of hours it been somewhat better behaved and I didn't get anywhere with that. SpinningSpark14:41, 15 March 2019 (UTC)
I now think the way it works is this: if there are multiple unseen edits on a page and the one you look at is not the first one made, then that edit will get stuck on your watchlist, even if you then go back and view the first one, which will also stay stuck. Those who don't have their watchlist expanded to show all edits don't have a choice; they are going to view the last edit and it will stick on the watchlist unless it was the only one made. If you actually make an edit to the page it's taken off the watchlist. SpinningSpark19:13, 15 March 2019 (UTC)
To me it seems much more random and inconsistent than that. Sometimes editing the page doesn't even solve the problem—I just edited wikivoyage:Wikivoyage:Travellers' pub, and my own edit (along with the other recent edits to the page) is still displaying on my watchlist as if I haven't yet visited it. —Granger (talk·contribs) 00:04, 16 March 2019 (UTC)
I'm seeing my own edits that I've just made show up on my watchlist too, whereas previously they hadn't. I often can't clear those pages from the watchlist, even if I visit the current incarnation of the page or view the last diff. Has been happening since 10am Pacific for me. —Joeyconnick (talk) 03:26, 16 March 2019 (UTC)
I'm having the same problem. If I visit a page any way other than by clicking on it on my watchlist, it's not marked as read. TheDJ, Neither of those links are working for me. Is that broken too? Natureium (talk) 18:59, 18 March 2019 (UTC)
Also an issue: if there's a long list of unseen changes, and I compare the oldest unseen and the subsequent, say, 3 changes (but there are more than 3 changes unseen after that), then return to the article History, it lists all revisions as seen. Definitely not what should be happening, because I haven't seen those other revisions. —Joeyconnick (talk) 02:41, 19 March 2019 (UTC)
I've noticed this issue too. It doesn't interfere with my workflow, so I haven't brought it up, but I can imagine it might bother other editors. —Granger (talk·contribs) 13:53, 19 March 2019 (UTC)
It seems they overfixed this, as I now have the opposite: a page which is marked as "visited" now stays marked as "visited" even after new edits have been made to it (I don't use the green and blue, I use the blue circle / filled blue circle version, FWIW). Fram (talk) 14:58, 21 March 2019 (UTC)
Looking at this further, it seems as if a page stays "read" until a new section is posted, while in the past it changed to unread as soon as anything was posted. I don't know if this change was deliberate or not, but I prefered the old way, certainly since there is no per section watchlisting. Fram (talk) 16:21, 21 March 2019 (UTC)
I have the opposite problem: after refreshing my watchlist, there are new diffs marked as having being visited, even though I have not. If I go to the history page then they are correctly marked as unread. Has anyone seen this problem? isaacl (talk) 21:21, 29 March 2019 (UTC)
Am I the only one suffering from painfully slow JS load times? This started today out of nowhere. Everything is slow to load.Cp678(T•C•G•E)23:23, 1 April 2019 (UTC)
Generating a page log
What mechanism is responsible for generating a log entry for a given page or action? In particular: why does this command show an entry for the adding of an {{unreferenced}} tag whereas this command does not, even though both articles are tagged with an unreferenced template? More specifically, what would need to happen in order to cause the action of adding a {{PROD}} tag to an article to also generate a log entry for said action? Thank you.--John Cline (talk) 07:19, 23 March 2019 (UTC)
@John Cline: the logging of adding maintenance tags, deletion tags, etc is a part of the page curation system (see WP:NPR for more) while just adding the template manually (or semi automatically using twinkle) does not. --DannyS712 (talk) 07:29, 23 March 2019 (UTC)
Thank you both for this information. I am not sure how to use it to reach the end I desire which is an effective method of ascertaining whether or not an article has ever survived the proposed deletion process, effectively retiring that process for the given topic. Right now the determination is entirely too cumbersome to glean yet there are situations where policy stipulations mandate that it must be considered in concert with other pending or contemplated actions. I would like to see this problem solved. Can it be resolved? Thanks again.--John Cline (talk) 09:20, 23 March 2019 (UTC)
Addition of PROD probably should tag the edit as attempted proposed deletion, which is possible with an edit filter I believe. You will need to leave a request at WP:EFN to see. --Izno (talk) 14:03, 23 March 2019 (UTC)
Alternatively, it might be good if Twinkle did it at runtime and that would probably take care of the majority of PROD taggings. --Izno (talk) 14:08, 23 March 2019 (UTC)
Personally, I would find it very helpful if there was a way of finding out a page's entire move history. Special:Log/move is tied to the title rather than the page itself, so it would only show moves that originated at the current title. -- King of♥♦♣ ♠ 18:56, 23 March 2019 (UTC)
I agree. As it stands, an idea to incorperate a bot to assist with this is being pursued here. I recall seeing it mentioned that it would be helpful if evaluating iterations of the page being discussed, where it may have existed under a different title, was part of the bot tasking. King of Hearts it would be great if you look in on that discussion to help ensure that we endeavor a best effort in this regard; I know you have a surplus of insight regarding XfD. Anyone else interested in seeing this done right is not only welcome, as well, they are entreated to help, if they so kindly will. Sincerely.--John Cline (talk) 02:26, 24 March 2019 (UTC)
@King of Hearts: Regarding a true move log, it is unclear to me if Mediawiki even retains the information you would need. When researching all previous names, I usually have to do detective work. Diffs in the history don't even seem to remember what article name they were originally diffs of. They proudly announce they are diffs of the current article name, whatever if happens to be at the moment. EdJohnston (talk) 16:03, 25 March 2019 (UTC)
@EdJohnston: page moves are currently recorded in the history of both source and target title (e.g. if you move Foo to Bar, this action is recorded in the history of both titles) but this was not always the case and such a note was only left in the history of the old title (Foo in this example). I think the changed happened circa 2006. Thryduulf (talk) 13:06, 2 April 2019 (UTC)
Typically yes, you should wait at least 24-36 hours before concluding something is wrong, especially on the 1st of the month since there is a lot of other per-month data being generated. However this time it seems there was an outage. More at phab:T219842. The Analytics team is working to restore the missing data. — MusikAnimaltalk13:55, 2 April 2019 (UTC)
TemplateStyles gave a new option "Sanitized CSS". mw:Content handlers says "For sanitized CSS intended for use with TemplateStyles". I'm not sure of the difference from the normal CSS setting but it's a template page so I set it to Sanitized CSS. PrimeHunter (talk) 20:58, 30 March 2019 (UTC)
The normal CSS type is for use with e.g. MediaWiki:Common.css or user common.css. It doesn't do any validation, just syntax highlighting. The "Sanitized CSS" type validates that the content is valid, known-safe CSS, which means it's safe to be edited by all editors and can be loaded via wikitext with <templatestyles />. Anomie⚔13:26, 31 March 2019 (UTC)
mw:Help:TemplateStyles says that the sanitized CSS content model is the default for subpages in the Template namespace that end with .css. Is this not the case on English Wikipedia for some reason? isaacl (talk) 15:17, 2 April 2019 (UTC)
@Isaacl: it is, for pages created in the Template: namespace. In the example above, this page was created in the Wikipedia: (Project:) namespace and then moved. — xaosfluxTalk15:19, 2 April 2019 (UTC)
Take a read through the epic phab:T60485. Basically, not everyone was in agreement, nor appears to be now, about whether such a thing would be good or not. If the sysop left a blocking template (not done above) you can thank them for that edit; otherwise, a friendly talk page note would of course be welcome. ~ Amory(u • t • c)18:23, 2 April 2019 (UTC)
@A-wiki-guest-user: this can be caused by a few less-nefarious issues - 1st check the date and time on your computer, if they are off they can cause SSL errors. 2nd, you could be using a network that intercepts SSL for various purposes (company network, unsecured wifi that you haven't accepted terms of service for yet) or it could be something nefarious like someone intercepting your traffic. In any case, unless you know what is going on you should not send passwords over that connection. — xaosfluxTalk13:21, 2 April 2019 (UTC)
@A-wiki-guest-user: make sure you have a current version of chrome, and possibly restart your computer. If it persists we can help, but will need more information on the certificate error you are getting. This error says that the Certificate Authority on the chain is not valid for chrome, but it doesn't say more, can you provide us the entire SSL Chain you are seeing, especially the CA? — xaosfluxTalk15:02, 2 April 2019 (UTC)
Also, check your network / connection settings in Chrome and make sure that it's set correctly, and that it's not set to use any proxy server for your connection. It should usually be set to "auto-detect connection settings". ~Oshwah~(talk)(contribs)18:29, 2 April 2019 (UTC)
Greetings, The "Templates for discussion" here is now closed. Wondering when change can be done so that "Subject bar" will appear in Mobile view? I posted at talk page of "Template:Subject bar" with fewer than 30 watchers without responses.
If we just remove the navbox class from the module, we get / Which works on mobile devices. From User:Hawkeye7. I have zero knowledge of how to do this so if a more experienced admin could make the change please. Regards, JoeHebda (talk) 14:33, 2 April 2019 (UTC)
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
^Balestra, Martina; Zalmanson, Lior; Cheshire, Coye; Arazy, Ofer; Nov, Oded (2017). "It was Fun, but Did it Last?". Proceedings of the ACM on Human-Computer Interaction. 1: 1–13. doi:10.1145/3134656.
I see the problem in Vector, but Timeless, Minerva (and mobile domain), Modern, Cologne Blue, and Monobook are all unaffected. --Izno (talk) 03:21, 2 April 2019 (UTC)
It's the same with safemode=1 and at other wikis, e.g. nn:0. The title is "Editing 0" in preview, as normally. Archive.org shows the title was displayed 12 February but not 23 March and 29 March. It must be a MediaWiki bug unrelated to 1 April. PrimeHunter (talk) 09:29, 2 April 2019 (UTC)
Also, I checked another Wiki to see what's happening there, and for example ArchWiki doesn't have this problem. They're on MediaWiki 1.32.0, while we're on 1.33.0-wmf.23, so it's probably recent. Also, the change I mentioned was first included in -wmf.22, which was deployed on 21 March, which matches with the dates PrimeHunter found on Archive.org. rchard2scout (talk) 10:48, 2 April 2019 (UTC)
Has there been a software change along the lines of if (title) then display title, in a language which regards the string value "0" as false (as Perl does)? Certes (talk) 11:39, 2 April 2019 (UTC)
PHP is widely used in MediaWiki and has the same convention. If some fix replaced $title by $title || "" to guard against an unset variable, which works for almost all titles, that would have the unfortunate side-effect of changing "0" to "". I'm looking through relevant parts of the release notes for such a change but can't see one at the moment. Certes (talk) 16:53, 2 April 2019 (UTC)
The issue is that as stories get added, the cutoff date doesn't change. So I'm looking at a way that you can, instead of specifying a cutoff date, you can specify the number of articles to keep in the sidebar. Headbomb {t · c · p · b}01:37, 31 March 2019 (UTC)
@Pppery: The 'more articles' expanded table doesn't seem to work sadly, unless a break/start date is specified. See updated examples. Headbomb {t · c · p · b}00:45, 3 April 2019 (UTC)
@Headbomb: What, exactly, is supposed to happen in that case. I see that you've added a default limit of five articles; does that mean that all uses of the template for tags with >|limit= articles should include a breakpoint after the |limit=th article?. {{3x|p}}ery (talk) 01:31, 3 April 2019 (UTC)
@Pppery: The way I'm imagining things, the template would collapse everything exceeding the limit under "more articles". So if you have |sortdir=ascending, show the first 5 articles in ascending order, and articles 6+ under "more articles". And if you have |sortdir=descebing (the default option), show the first 5 articles in descending order, and articles 6+ under "more articles". With the relevant modifications when |limit=3 or |limit=10 is set. Headbomb {t · c · p · b}01:34, 3 April 2019 (UTC)
@Headbomb: Would this change completely replace the |break_date= parameter? I seem to be having technical issues getting the templates to work right with both numerical and date limits. {{3x|p}}ery (talk) 02:00, 3 April 2019 (UTC)
@Pppery: That would be the idea. I suppose it would be good to check with @Smallbones: to see if they agree with that, but the idea here would be to more or less throw to present (by default at least) the five most recent stories on a topic, even if you're browsing something from 2012. Otherwise you could go from an article from 2017, to an article in 2007, and then lose your way back to the other articles in the topic because you landed on a page with the old presentation that had only the 3 oldest stories from before 2007. Or land on a page which said to display articles from after a certain date, and now there are 104 of them, rather than the 3 that were present at the time of writing. Headbomb {t · c · p · b}02:04, 3 April 2019 (UTC)
@Headbomb: OK, after spending far too much of my tile struggling with this, it should finally work. (I completely removed support for the date-based parameters) {{3x|p}}ery (talk) 02:10, 3 April 2019 (UTC)
@Pppery: Thanks a bunch. I mayyyyyyyyy have some more request later, but I'll let you get a day of rest at least :p. Unless you're in the mood for some more technically wizardry involving scripts this time. Headbomb {t · c · p · b}02:13, 3 April 2019 (UTC)
If you mean JavaScript, then, while I do know that programming language, I have little interest in doing that on Wikipedia. {{3x|p}}ery (talk) 02:15, 3 April 2019 (UTC)
@Pppery:... actually... not quite done. Expand these boxes. In the first case, the 25 March 2015 article is present both in the uncollapsed and in the 'more article' section, rather than the other articles. And I'll find someone else to bother for scripts if it comes to that. Headbomb {t · c · p · b}02:16, 3 April 2019 (UTC)
@Narutolovehinata5: its based on an issue related to one of the database tables (mw:Manual:Database layout) - "Unknown column 'rev_comment' in 'field list'". This is likely because rev_comment has been deprecated in favor of the comment table. Instead, rev_comment_id should be retrieved, which matches with the new comment_id in the comment table. --DannyS712 (talk) 03:01, 3 April 2019 (UTC)
I don't think dumps.wikimedia.org (production) would be affected by the Debian Stretch upgrade on Toolforge. phab:T219718 comes to mind, which also happened around the 25th, but that is about metrics.wmflabs.org and not dumps.wikimedia.org. So, I'm not sure :( I would contact the Analytics team. — MusikAnimaltalk00:12, 2 April 2019 (UTC)
I would like to add a link at the top of my screen to where when I click on it it would take me to The Pending changes log. I have already modified my User:A 10 fireplane/common.js page once and want to know if I change all the New User To Pending chances if it would work A 10 fireplaneImform me17:26, 3 April 2019 (UTC)
Yes. Specifically, replace Special:Log/newusers with Special:PendingChanges. You should also probably change pt-newusers to something unique like pt-pendingchanges. ~ Amory(u • t • c)20:38, 3 April 2019 (UTC)
V • T • E (Navbar) template links not working on a phone
You know those drop down templates found at the bottoms of articles, such as Template:Xiamen? Also know how there are three buttons at the top left on all of them that say "V", "T", and "E", for "view", "talk", and "edit"? I'm on Chrome on a Huawei phone, and none of the buttons work at all. Pressing them only brings up descriptions of the buttons, "edit this template", etc. I can still edit them of course, but it's kind of inconvenient. How do I fix this? Woshiyiweizhongguoren (🇨🇳) 11:17, 28 March 2019 (UTC) (Originally asked at the Teahouse but later moved here)
@Pipetricker: That's not really a solution, though. (And a better workaround is to click on the gear icon on the tooltip and uncheck "Show tooltips over text with a dotted underline in Reference Tooltips style".) The problem comes from the gadget's interaction with <abbr>...</abbr>. Perhaps something to be dealt with at MediaWiki talk:Gadget-ReferenceTooltips.js. Nardog (talk) 09:21, 4 April 2019 (UTC)
Within the "ref" template at the end of the first paragraph of Collins–Valentine line, this appears:
{{citebook|author=Francis M. Carroll|title=A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842|pages=74–79, 85, 163|publisher=University of Toronto Press|year=2001}}
Thus what is seen in the "References" section looks like this:
Francis M. Carroll (2001). A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842. University of Toronto Press. pp. 74–79, 85, 163.
I would like to add a parenthetical remark so that it will look like this:
Francis M. Carroll (2001). A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842. University of Toronto Press. pp. 74–79 (see in particular the map on p. 76), 85, 163.
{{cite book |author=Francis M. Carroll |title=A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842 |pages=74–79 (see in particular the map on p. 76), 85, 163 |publisher=University of Toronto Press |year=2001}}
Francis M. Carroll (2001). A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842. University of Toronto Press. pp. 74–79 (see in particular the map on p. 76), 85, 163.
Which produces this under the hood: '"`UNIQ--templatestyles-00000083-QINU`"'<cite id="CITEREFFrancis_M._Carroll2001" class="citation book cs1">Francis M. Carroll (2001). ''A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842''. University of Toronto Press. pp. 74–79 (see in particular the map on p. 76), 85, 163.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Good+and+Wise+Measure%3A+The+Search+for+the+Canadian%E2%80%93American+Boundary%2C+1783%E2%80%931842&rft.pages=74-79+%28see+in+particular+the+map+on+p.+76%29%2C+85%2C+163&rft.pub=University+of+Toronto+Press&rft.date=2001&rft.au=Francis+M.+Carroll&rfr_id=info%3Asid%2Fen.wikipedia.org%3AWikipedia%3AVillage+pump+%28technical%29%2FArchive+173" class="Z3988"></span>
For those who haven't worked it out, Izno is concerned about pollution of the rft.pages parameter in the title attribute of that last <span>...</span> element. You could use the |postscript= parameter for the parenthesis:
Francis M. Carroll (2001). A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842. University of Toronto Press. pp. 74–79, 85, 163 (see in particular the map on p. 76).{{cite book}}: CS1 maint: postscript (link)
Indeed, that parameter. |postscript= as anything other than punctuation is also a misdeed, but not one checked for by the template today. :) --Izno (talk) 22:27, 2 April 2019 (UTC)
|at= is the correct parameter from a template standpoint, but I am surprised to hear that it also puts it in the same metadata element. I think putting it in |pages= as such is reasonable. The editor could also put the page distinctly in the list (without the note) rather than letting it be implied by the range. --Izno (talk) 00:19, 3 April 2019 (UTC)
COinS only gives us &rft.pages= as a general-purpose in-source location k/v pair (&rft.spage=, &rft.epage= (start & end), and &rft.tpages= (total) are available but not currently supported and don't answer this question). So, |page=, |pages=, and |at= all get shoehorned into &rft.pages=. My opinion, for what it's worth, is that notes like this should be placed outside the cs1|2 template so that editors don't get into the bad habit of stuffing any-odd extraneous text into any parameter as it suits their whims of the moment because, you know, inevitably formatting and templates and other stuff that definitely doesn't belong will be added ...
I'm sorry Trappist the monk, I should have said an explanatory footnote as associated with {{efn}}. To illustrate, consider the following example:
This represents an article's content with an inline reference.[1]
References
^Francis M. Carroll (2001). A Good and Wise Measure: The Search for the Canadian–American Boundary, 1783–1842. University of Toronto Press. pp. 74–79, [a] 85, 163. {{cite book}}: templatestyles stripmarker in |pages= at position 7 (help)
You name {{efn}} but use {{ref label}}. Regardless, the content of |pages= is made part of the citation's COinS metadata k/v pair &rft.pages=. Because |pages=74–79,{{ref label|id ref2a|a|a ∧}} 85, 163 has a template, that template is processed before the {{cite book}} template is processed. When processed, {{ref label|id ref2a|a|a ∧}} returns this:
So what what consumers of the metadata see is a page-number range, some (comparatively a lot of) meaningless gibberish, and two individual page numbers with appropriate spacing and comma separators. The 'meaningless gibberish' may have 'value' here in the rendered citation but is useless outside of the Wikipedia article in which is is used; it is contamination in the metadata because it conveys no meaning (the metadata are intended for use outside of Wikipedia).
Thank you for that very informative reply. I understood the points you raised, learned some things I am glad to now know, and agree with your conclusion. I appreciate you and wish you the best.--John Cline (talk) 14:01, 4 April 2019 (UTC)
Created redirect but want to display actual title
Given the length of the list that is the redirect target, I'm thinking this may not be a notable publication, but I wanted to include it in Sad (disambiguation). I used a piped link for Sad!: Doonesbury in the Time of Trump but the actual title is #Sad!: Doonesbury in the Time of Trump. I'm thinking the publication is not notable enough for its own article, though there is this, which mentions the publication briefly. Due to the special nature of Garry Trudeau's satirizing of Donald Trump, perhaps I'm looking at adding some information to the Doonesbury article.— Vchimpanzee • talk • contributions • 15:22, 4 April 2019 (UTC)
You can't use DISPLAYTITLE to add a character to a title. There's no need; the piped link on the disambiguation page is fine as it is, and there's not much point in styling the title on the redirect page, which normally isn't viewed by readers. --Pipetricker (talk) 19:16, 4 April 2019 (UTC)
I forgot to read that. Now I know what is supposed to happen. I knew the character was forbidden but didn't think about that section showing how to resolve the problem.— Vchimpanzee • talk • contributions • 20:54, 4 April 2019 (UTC)
"You have new messages" for old irrelevant messages for IP users
Original topic heading: The Wikipedia Notification system
Hello all,
I had opened this talk page Talk:List of Indian Nobel laureates which is currently the FL. I saw the familiar orange bar on top saying 'You have a New Notification.' I opened my talk page and saw a post from 2013, yet I receive this notification today, almost 6 years later. (FYI, I didn't make those edits in 2013) Shouldn't the Notification System be strong enough to understand that an IP user viewing a Talk 6 years later may not be the same person, and the notification means nothing to him? I know there are a lot of complexities in implementing this, but it can be done or rather it should be done. Regards 125.63.125.19 (talk) 14:53, 5 April 2019 (UTC)
Hi 125.., this is a core mediawiki function, not a specific setting from the English Wikipedia. You can suggest a "feature request" by following the information here. It sounds like your summary would be "Expire the newmessages status from unregistered accounts after an interval". — xaosfluxTalk15:01, 5 April 2019 (UTC)
Actually, I do, but it's distracting to have the link appear with nearly every diff in the history. I was given a way not to, but it's obviously not working.— Vchimpanzee • talk • contributions • 15:55, 5 April 2019 (UTC)
Friends! I come to you from a universe referred to as "Wiktionary". In my travels, I have passed through between this universe and that on many occasions. I call it an alternative warp. It's sort of a negative magnetic corridor where the two parallel universes meet. It's sort of a safety valve. It keeps eternity from blowing up.
And I come before you of Wikipedia today seeking your assistance for my holy cause. Here's a link to the state of the discussion of the problem on English Wiktionary's Grease Pit where I inspect magnetic communications satellites. You believe me, don't you?
The audio files won't play for Mandarin Chinese. Essentially, it's a kind of physical warp in which none of our established laws apply with any regularity. Complete disruption of normal magnetic and gravimetric fields, timewarp distortion, possible radiation variations. And all of them centring on the general area which you are now patrolling. The question is, are these natural phenomena or are they mechanically created, and if they are, by whom? For what purpose?
There's still time. It's not too late. But I- but I- need-- need your help.
You'll join me in my holy cause? Is it such a large price to pay for the safety of two universes?
Until recently, this thing used to come just once, for the first edition, and didn't reappeared after. But nowadays it reappears each time you want to edit. That's pretty annoying since it hinders editing every time. Could that be repaired? Thank you in advance (and please no reply like "create an account") 193.54.167.180 (talk) 15:17, 6 April 2019 (UTC)
Hi 193, can you provide some more details? Is it happening when you read, edit, or both? What interface are you using (e.g. web, mobile web, app)? What does this message say (perhaps a screen shot would help)? — xaosfluxTalk15:35, 6 April 2019 (UTC)
I'm pretty sure 193 is talking about the welcome popup regarding switching to the visual editor when you edit on desktop as an unregistered user. Galobtter (pingó mió) 20:14, 6 April 2019 (UTC)
The page Talk:Muhammad Ali is missing the "index" link in the "Archives" section. Also, archives 1 thru 4 don't have the three archive selection immediately beneath the "This is an archive of past discussions." statement. It allows navigation before and after the viewed archive page.
You're autopatrolled, therefore all articles you create can be visible on Google search any moment after you click publish button. The 90-day wait (which is not absolute itself) is only for articles created by some subset of users and also when it's not marked as patrolled by a New page reviewer; which can be as fast as few minutes after creation.
Thanks, Ammarpad; relieved to hear it shows for someone, so I know it's out there. Could it be because I hit so many times on every other site that comes up (State Dept, Treasury, and news sources, while I was researching and building the article) that Google wants to feed those to me instead? Is there something I need to know or do about WikiData? I get no infocard on the right. SandyGeorgia (Talk) 09:28, 7 April 2019 (UTC)
Well, frankly I don't know, but it may be so, since Google sends a lot of cookies to track your activities. I don't think there's anything you need to do now rather than just wait for a few days and check back. – Ammarpad (talk) 09:55, 7 April 2019 (UTC)
Only manual intervention by someone with write access to the database, looks like; attempting to delete or create both throw errors. Take it to phab. —Cryptic01:38, 6 April 2019 (UTC)
Looks like it's left over from an incident back in 2012-06-11. The external store master went down and it looks like between about 23:38:47 UTC and 23:52:37 UTC revisions couldn't be created because the revision content couldn't be saved. Apparently attempted page creations during that time created the page row despite failing to create the initial revision. Anomie⚔23:25, 6 April 2019 (UTC)
{{GeoGroup}} fails with this page that says "not currently serviced". The archives show previous problems related to the template's use with Google Maps, but I don't see anything about OSM. Firefox current. ―Mandruss☎09:31, 8 April 2019 (UTC)
I see that, in order to autofill the data on the deletion page from the "delete" tab at the top of the Wikipedia page, I can use <span id="delete-reason" style="display:none"> and <span id="delete-criterion" style="display:none"> tags. Is there a similar way to autofill the data on the move page from the "move" tab? עוד מישהוOd Mishehu15:07, 8 April 2019 (UTC)
@Adithyak1997: if you are asking if you should go edit all those User (and especially User_talk:) pages - then:no. Ideally, they should be fixed to be the right value, and user_talk: base pages should be fixed by a bot (if they need 'fixing' at all that is) to avoid throwing the "new messages" banner. — xaosfluxTalk11:35, 5 April 2019 (UTC)
<source inline>...</source> emits inline markup: <span>This is inline markup.</span> Also, what are those ❮❯ characters intended to be? They show as little boxes in my browser. --Redrose64 🌹 (talk) 18:33, 5 April 2019 (UTC)
@Redrose64 Unicode right and left arrows; presumably used to ensure that <code> in the header and edit summaries doesn't get treated as an HTML element. ‑ Iridescent18:38, 5 April 2019 (UTC)
The title of this section
It turns out that the original title of this section, == Replacing <nowiki><syntaxhighlight></nowiki> with <nowiki><code></nowiki> ==, doesn't work well with the auto-generated edit summary feature as the HTMLish tags get stripped. It turns out that that's exactly the problem: changing it to == Replacing <syntaxhighlight> with <code> ==, which displays identically and wouldn't even need {{anchor}}, would have worked fine. There was no need to use lookalike Unicode characters such as ❮❯ or 〈〉. Anomie⚔11:47, 8 April 2019 (UTC)
I don't know if this is by design or by oversight, but a lot of notices don't display well in the mobile version of Monobook.
For example see.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
text
text
Deadlines (UTC) Current time is 2025-01-09 14:53:12 (
Going to @Isarra: on this, since I believe you have something to do with the mobile view of monobook. Memory could be failing me though. Headbomb {t · c · p · b}02:02, 7 April 2019 (UTC)
FYI, this appears to be related to rules in MediaWiki:Monobook.css rather than to the skin itself. As far as I can tell it's accidental, the width:100% is still there but hiding or removing the image cell somehow or other makes the table itself not size to fill the available width. That happens even on non-mobile widths and other skins, BTW, if the mbox-image cell is removed or hidden by other means.
Anomie, this is mbox magic yes ;) you cannot really hide the image cell without causing this. It's some sort of CSS autosizing rule of tables. I've changed the rule to only hide img elements. —TheDJ (talk • contribs) 07:40, 8 April 2019 (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
More wikis are now testing visual editor section editing for mobile users. You can read more.
A map update caused some problems on 29 March and 30 March. It was rolled back. [24]
Pages on some Wikivoyages had problems with the top headline. This has been fixed. [25]
Changes later this week
When you add an edit summary the VisualEditor will search your recent edit summaries in case you want to re-use one. This works in both the visual and wikitext modes on desktop. It also works on the mobile site. [26]
The {{REVISIONID}} magic word will no longer work. This is for performance reasons. When you preview a page it will return "" (empty string). When you read a page it will return "-" (dash). For now this will only affect content namespaces. [28]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 10 April at 15:00 (UTC). See how to join.
Future changes
You will be able to preview references. This means that when you hover over the link you will get a popup that shows you a preview of the reference. It will work much like page previews. This is so you don't have to go to the bottom of the page to see a reference. This will now be available as a beta feature on German and Arabic Wikipedia. [29][30]
The Wikidata JSON output will change. Empty containers will be serialised as empty objects. This is a breaking change that will affect tools that use JSON outputs and APIs. It will happen on 30 April. You can read more and see how to test your code.
There are several categories related to amusement park rides attached to Parliament Hill Rehabilitation. However, they don't show up when I try to edit the page, and they can't be removed with HotCat. They should be removed, but I'm not sure how. How can this be remedied? FYI, browser is latest chrome.— Preceding unsigned comment added by Schetm (talk • contribs) 07:29, 4 April 2019 (UTC)
This is a WP:TCAT situation. Probably what should happen is that the categories be added to the articles by bot and removed subsequently from the templates. --Izno (talk) 22:21, 4 April 2019 (UTC)
Appending |auto-cat=no to the infobox worked perfectly. The village pump has delivered! Many thanks. schetm (talk) 23:16, 4 April 2019 (UTC)
The infobox does seem oriented towards amusement park rides; is it the best to use for the page in question? isaacl (talk) 16:13, 5 April 2019 (UTC)
I didn't place the amusement park infobox there - I just noticed the miscategorization during normal browsing. I'll look at the infoboxes when I have the time. schetm (talk) 04:53, 9 April 2019 (UTC)
I wasn't suggesting you'd put it there (I thought it unlikely, considering your question), only letting you know about the others. Cheers, BlackcurrantTea (talk) 05:21, 9 April 2019 (UTC)
pre and floating elements
Is there a way to stop these sorts of overlaps, where pre's 'grey box' extends into another 'div'?
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
@Headbomb: The gray is part of the background. Background always extends behind floating elements by default, because floating elements only push content (aka text) out of the way. You can set either the background of the floating element for a visual effect, or force the other block to render in it's own 'block formatting context' (this really is a rather esoteric concept of CSS). This can be done by specifying overflow:hidden as a style attribute. This latter technique is also used by the headings to avoid colliding with infoboxes for instance.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Thanks, I'll remember that in the future. But is there a reason for why this isn't default behaviour in the case of pre/syntax highlight? I yet to see any of these overlaps considered desirable by anyone. Headbomb {t · c · p · b}14:28, 8 April 2019 (UTC)
Headbomb, yes overflow:hidden hides content that overflows and that isn't uncommon in code examples. (a url for example).. I guess we could try it out for a while, see if there are any complaints... —TheDJ (talk • contribs) 08:48, 9 April 2019 (UTC)
Not sure if this is the right place for this, sorry if I've posted incorrectly. I've setup archiving on Talk:Jackie Walker (activist), but after several days it's still not working. I must have done something wrong, but I'm not seeing it. What did I do (or not do)? Jayjg(talk)17:10, 9 April 2019 (UTC)
Why are you surprised? The articles were really linked. Whether this was achieved by modifying a template or directly the article is irrelevant. Ruslik_Zero19:05, 9 April 2019 (UTC)
I think it's a fair complaint. Adding the template to an article should give a notification but here the link was added to the template between two unrelated article edits. I don't know how it's supposed to work but it would seem reasonable if the job queue updates link tables after the template edit without causing link notifications for articles using the template. When the article is edited next time, the link was there right before the edit so a notification can be omitted. Updates of link tables after template edits are often very delayed. Is it supposed to work like I say but failed because the link table was never updated before the article edit? Or is the next article edit always meant to cause a notification? PrimeHunter (talk) 21:13, 9 April 2019 (UTC)
@Ruslik0: it's not a huge issue, I agree, but imagine if you wrote an article that was then linked from a high-transclusion template with many linked articles (e.g. Template:United States topics) and received a notification every time the other articles were next edited, rather than one notification for the link from the template. – Teratix₵01:46, 10 April 2019 (UTC)
I am not sure that the parser cares about templates. There is one link table per article, which includes all links including those from templates. On other hand if includeonly tag is used, the link may not be present in the template's link table at all. Ruslik_Zero08:34, 10 April 2019 (UTC)
Is there a way to get the rendered size of page?
I'm looking for a tool that would let bots, scripts, and users know that
Quark cost roughly 525 kB of data to download. The cached version would be fine for this purposes. It's not in accessible through &action=info, so I'm wondering if there's another way to get this. Headbomb {t · c · p · b}03:39, 10 April 2019 (UTC)
Not really, since it depends on which image formats and compression formats the user-agent supports. I will also change every time the software is updated and/or styling or Javascript is changed for the wiki in question. —TheDJ (talk • contribs) 12:49, 10 April 2019 (UTC)
@TheDJ: Well, that's why I wondered about the cached size. Surely that's not something browser-dependent. More interested in a ballpark figure than an exact size for this purpose. Headbomb {t · c · p · b}14:26, 10 April 2019 (UTC)
Image format in PDF output
From this discussion it is my understanding that Incnis Mrsi is proposing to change $wgPdfOutputExtension configuration variable at this wiki to set the images output format to png in PDF output files. This results in higher quality images. Without this, the output is rendered very poorly and is difficult to read or share. Do we have consensus for such a change? --Gryllida (talk) 23:18, 2 April 2019 (UTC)
Anything which wasn't created to be a graphic. Most photography is more correctly JPGs than PNG, if we're talking a lossy format. --Izno (talk) 20:51, 3 April 2019 (UTC)
On the contrary, I think that if you compare the rendering in 'this discussion' linked above, you will see low quality jpeg rendering. Gryllida (talk) 19:52, 6 April 2019 (UTC)
@Gryllida: en.Wikipedian people don’t easily get the meaning of “PDF” in this context (not surprisingly, given that its presence in Wikipedia articles is marginal) and confuse it with PNG. Here’s not Phabricator nor even Wikimedia Commons; be careful next time, please, to check that your vis-à-vis gets what do you tell properly. 18:24, 10 April 2019 (UTC) — Preceding unsigned comment added by Incnis Mrsi (talk • contribs)
Changing the case of a template
In the template Template:Country data AUS, I would like to know the place where I can change the case of starting letter of the word 'Country' in the template name. Please do note that I am not going to make any changes here. Adithyak1997 (talk) 18:32, 10 April 2019 (UTC)
I have recently posted a question in Wikipedia:Village Pump (Technical) with the section heading "Changing the case of a template". I actually know from [this] that capitalisation is done by Mediawiki. The problem lies in this page in the bottom most section. I haven't asked this in Community Portal in Incubator is that I have not got any results for the questions posted 4 days ago. Adithyak1997 (talk) 19:07, 10 April 2019 (UTC)
@Adithyak1997: I'm afraid I can't make much sense of that page, given I don't speak...Urdu? But if you tell us what exactly you're expecting, or what exactly you're trying to do, maybe we can help. Headbomb {t · c · p · b}19:12, 10 April 2019 (UTC)
@Headbomb: Actually, I also doesn't know Urdu. I am just working on templates as well as on modules. What I need to achieve is that the word 'country' needs to start with upper case in the text "Template:Wp/khw/country data WIN". Adithyak1997 (talk) 19:20, 10 April 2019 (UTC)
As you have been told, this cannot be done with the structure of the pages/template as they are now. Nor is it that important. Why do you want to do this? --Izno (talk) 19:42, 10 April 2019 (UTC)
You have not explained what you are trying to do and the text "Template:Wp/khw/country data WIN" does not occur in the linked page. You are making us waste time trying to guess what your problem is before we can attempt a solution. Maybe you want country data templates to be named "Template:Wp/khw/Country data ..." with upper case C, and still work without having to create redirects at "Template:Wp/khw/country data ..." with lower case c. If this is what you want then the templates have to always be called with an upper case C. Here is a search showing some templates which currently call with lower case c. PrimeHunter (talk) 21:03, 10 April 2019 (UTC)
css help request: hiding help link in watchlist and contributions (mw-helplink?)
You've added the selector .mw-helplink to the selector-list of a rule that has a declaration-list containling only the declaration display:none;. What were you trying to do, why do you think it's wrong? --Redrose64 🌹 (talk) 19:34, 10 April 2019 (UTC)
display: none !important; or a more specific selector is required. It also hides other help links. Do you want to hide all of them or only on watchlist and contributions? PrimeHunter (talk) 20:18, 10 April 2019 (UTC)
(edit conflict) I don't like !important, it's a cop-out. You could whack the specificity right up with the selector
I don't know if this is the right place to post this. If not, please point me in the right direction.
When you click the "Re-use" button in the "Add a citation" screen in VisualEditor, it changes <ref> in the chosen citation to <ref name=":0"> (see here). This breaks all the rules of WP:REFNAME: it is purely numeric, it has no "semantic value", and it has quote marks where no quote marks are required. Why can it not use something like name=Autogenerated1, name=Reference1 or, if you're fond of quote marks, name="Reference 1"?— Preceding unsigned comment added by Scolaire (talk • contribs) 18:42, 10 April 2019 (UTC)
(edit conflict) Please sign your talk page posts using four tildes (~). As for your question, Visual Editor is still very much in beta, with many bugs yet to be resolved. Here are a few that I found related to the referencing naming that you have noticed: T215867, T92432 (a four-year-old bug), T212609, T169841, T94712. Be careful out there. – Jonesey95 (talk) 19:08, 10 April 2019 (UTC)
@Scolaire: It's not purely numeric - there is a colon before the zero. The presence of that colon not only makes it non-numeric, it also makes the quote marks mandatory. However, you're right that it has no "semantic value" - but Visual Editor isn't intelligent enough to pick a ref name that does have semantic value. --Redrose64 🌹 (talk) 19:28, 10 April 2019 (UTC)
Sorry about not signing – a mistake I rarely make. I take it there's no prospect of this being fixed in the near future, then? @Redrose64: quotation marks are optional if the only characters used are letters, digits, and symbols including the colon. Scolaire (talk) 19:34, 10 April 2019 (UTC)
Cite error: The <ref> tag name cannot be a simple integer (see the help page).
Testing ~. No, it is incorrect to say it is all numeric, as Redrose remarks. As it happens, the requirement here is not a soft requirement but a hard one: the software will fail to process an all-numeric reference name. I do not know why the software has this basic requirement, but there it is. --Izno (talk) 19:44, 10 April 2019 (UTC)
As for "why cannot it use a certain text", the "certain texts" would need to be localized. The developers thought it would be easier to include the notation they did because a) it skips that problem and b) eventually you see enough ":1" and you know it was created by VisualEditor. The Phabricator tasks above are of interest of course. --Izno (talk) 19:48, 10 April 2019 (UTC)
Attribute values need not be quoted if they consist only of digits, letters (of either case) the hyphen-minus character and the full stop character. If any characters other than those 64 are used (such as a colon), the quotes are mandatory. --Redrose64 🌹 (talk) 20:04, 10 April 2019 (UTC)
On my sandbox, I have a Navbox template copied from Chinese Wikipedia. Since I don't know how to translate several of the template parameters into English, it's full of error messages. Is there some sort of discrepancy between the way Navbox templates work on the Chinese and English Wikipedias? Woshiyiweizhongguoren (🇨🇳) 13:13, 11 April 2019 (UTC)
@David Biddulph: Since they say they have copied from Chinese Wikipedia, I went over there and checked out their {{to}}. Their template {{to}} is different from ours. The Chinese one is used to show an arrow pointing right like this →180.151.77.7513:37, 11 April 2019 (UTC)
I do believe the file string ending triggered the blacklist, correct, that should have bee overlooked even though the new target was not dup strings. - FlightTime (open channel)19:08, 11 April 2019 (UTC)
History search
I was interested in knowing when and by whom RFA was modified to reflect the following wording:
"In December 2015 the community determined that in general, RfAs that finish between 65 and 75%..."
When I did a search, I was surprised to find that it was added in a 2005 edit.
That's obviously wrong. I'm guessing there is a transclusion throwing off the search results. how can I figure out when, and more importantly, by whom, that wording was added?S Philbrick(Talk)18:59, 11 April 2019 (UTC)
I had a look through the bug reports for wikipedia, but I'm not sure if this has been discussed (I'm sure it must have done), and I'm hoping someone could help me with how editing works on Android.
When searching through recent edits on the android chrome watchlist, clicking the link to the edit in question brings up the diff (as expected). However, if you wanted to edit the article yourself, clicking the article name brings up the indivdual edit of the page, and so attempting to edit the page only allows a view source, rather than editing. The only way to solve this is to click any blue links that occour on the page before (usually only shows when someone edits a particular section of an article/talk), or to go to the previous edit, and then the latest edit, which brings up the page itself.
Is this designed to work this way? I quite often check for updates to articles on my phone, and also make small edits this way. However, it's quite a faff to do the solution listed above to sort this out.
There's also no way to revert an edit on chrome. Is this also intentional, or am I missing a simple way to do so?
It works, but it seems to introduce a very large gap between the X and the item. It's workable, although ugly. Is there a general page for gadget tweaks? There's a few of them that could use a bit of love. Headbomb {t · c · p · b}21:07, 11 April 2019 (UTC)
URL shortener for the Wikimedia projects will be available on April 11th
Hello all,
Having a service providing short links exclusively for the Wikimedia projects is a community request that came up regularly on Phabricator or in community discussions.
After a common work of developers from the Wikimedia Foundation and Wikimedia Germany, we are now able to provide such a feature, it will be enabled on April 11th on Meta.
What is the URL Shortener doing?
The Wikimedia URL Shortener is a feature that allows you to create short URLs for any page on projects hosted by the Wikimedia Foundation, in order to reuse them elsewhere, for example on social networks or on wikis.
The feature can be accessed from Meta wiki on the special page m:Special:URLShortener. (will be enabled on April 11th). On this page, you will be able to enter any web address from a service hosted by the Wikimedia Foundation, to generate a short URL, and to copy it and reuse it anywhere.
The format of the URL is w.wiki/ followed by a string of letters and numbers. You can already test an example: w.wiki/3 redirects to wikimedia.org.
What are the limitations and security measures?
In order to assure the security of the links, and to avoid shortlinks pointing to external or dangerous websites, the URL shortener is restricted to services hosted by the Wikimedia Foundation. This includes for example: all Wikimedia projects, Meta, Mediawiki, the Wikidata Query Service, Phabricator. (see the full list here)
In order to avoid abuse of the tool, there is a rate limit: logged-in users can create up to 50 links every 2 minutes, and the IPs are limited to 10 creations per 2 minutes.
In order to enforce the rate limit described above, the page Special:URLShortener will only be enabled on Meta. You can of course create links or redirects to this page from your home wiki.
The next step we’re working on is to integrate the feature directly in the interface of the Wikidata Query Service, where bit.ly is currently used to generate short links for the results of the queries. For now, you will have to copy and paste the link of your query in the Meta page.
Documentation and requests
If you have any question or requests, feel free to leave a comment under this Phabricator task
Thanks a lot to all the developers and volunteers who helped moving forward with this feature, and making it available today for everyone in the Wikimedia projects! Lea Lacroix (WMDE) (talk) 11:54, 3 April 2019 (UTC)
@Lea Lacroix (WMDE): The feature is up and running, and I created some short links. However, I'm having trouble making the mediawiki software recognize them as links. Putting them as plaintext, external links, or internal wikilinks all fail to generate a working link - see User:DannyS712/sandbox#Short links. Any chance you can help? --DannyS712 (talk) 17:47, 11 April 2019 (UTC)
@DannyS712: there is no wiki-magic going on here, this is just a URL shortener, they w.wiki/A is the same type of link and text handling as something like bit.ly/A - you still have to use a protocol identifier. — xaosfluxTalk17:51, 11 April 2019 (UTC)
@Lea Lacroix (WMDE): Thanks! However, shouldn't the URLShortener output the URL with https:// in front of it so people can easily paste it? I'm pretty sure people will find it problematic to just paste something like "w.wiki/tS" (link to this discussion) because many applications might not detect that this is a valid URL. Also, can you maybe try to get some more .wiki-domains like en.wiki, de.wiki etc.? That way, links could be customized to reflect the language/project. Regards SoWhy07:23, 12 April 2019 (UTC)
@DannyS712: Awesome, thanks! I'm going to add it in the doc as well, so other projects can create a similar template if they want to.
@SoWhy: Thanks for your feedback. The idea of directly including the prefix is mentioned in this ticket.
As for adding more domain, I'm not sure that it's part of the purpose of the tool. The URL shortener is cross-projects, it links to Wikipedias but also Commons, Wiktionaries, Phabricator, Mediawiki, the Wikidata Query Service, etc. So structuring it for language versions of Wikipedias is a bit too restrictive. Lea Lacroix (WMDE) (talk) 08:58, 12 April 2019 (UTC)
One does not preclude the other. The tool can be cross-project but still output different domains that allows people to immediately see which project the link will lead them to. For example, w.wiki/tS links here but when I mistakenly typed w.wiki/Ts, it took me to ru-wikibooks. If the domain had been ru.wiki/..., I would have known not to use that link. Also, xx-wiki is a common abbreviation used, so if not for the URL shortener, those URLs could be used as alternatives, e.g. people could type https://en.wiki/Germany instead of https://en.wikipedia.org/wiki/Germany. Just something that you guys and gals might want to consider. Regards SoWhy09:10, 12 April 2019 (UTC)
watchlist articles not being marked as read after having been seen/visited
I hate to be a broken record but is there anyone working on fixing the issue where you go view pages on your watchlist, you have the filter for "unseen changes" on, and yet when you reload your watchlist, the fact that you've already viewed a page (or pages) isn't recorded immediately? This is extremely problematic if you are a frequent editor with a long watchlist and depend on the watchlist to accurately represent what changes you have and haven't seen. This seems like very core Wikipedia functionality and I'm really surprised issues with it not functioning properly have lingered well over a week. —Joeyconnick (talk) 23:02, 9 April 2019 (UTC)
Do you use live updates? They usually work fine for me, although I was tinkering with it a couple days ago and after a page refresh managed to get one of my own edits displayed in bold. I'm not sure exactly what I did to cause that, though... DaßWölf00:26, 10 April 2019 (UTC)
Nope, don't have Live Changes on and don't plan to turn it on. I'm not a fan of pages changing without any action on my part. I tolerate the little notification thing that pops up at the top of the list as that still requires my input before it loads the new changes. I just want the displayed "unseen changes" to actually be accurate, like they have been for years until this recent change. I'm all for updating stuff but not if it breaks essential functionality. —Joeyconnick (talk) 01:35, 10 April 2019 (UTC)
I had the same issue recurrently last week (never longer than half an hour). No idea where does it come from, or even of which side this is.--Ymblanter (talk) 09:01, 10 April 2019 (UTC)
I've seen this, too (Monobook, no live changes/updates, JavaScript usually off). I thought whatever was causing it had been fixed after the last time this was reported, until yesterday when a page stayed bold ('unread') on my watchlist after I looked at it twice. 14 hours or so later, it still appeared unread. After I looked at it again, it finally changed to plain text ('read'), and I haven't had the problem again today. BlackcurrantTea (talk) 11:12, 10 April 2019 (UTC)
This has happened to me as well since a couple weeks ago (no live/JS). I even see my own edit marked as unread from time to time, especially if I close the tab immediately after saving it. It also seems that viewing the diff no longer makes the edit read. Nardog (talk) 18:19, 10 April 2019 (UTC)
It happened again just now. I looked at the two new diffs since I'd last checked the page, went back to my watchlist, and it was still marked as unread. I looked at the most recent diff (the latter of the two I'd already seen), still unread. Cleared my cache and waited several minutes, and it's still showing up as new. BlackcurrantTea (talk) 01:52, 12 April 2019 (UTC)
And now it's marked as read, without my having visited the page or looked at the diffs a third time. It would be helpful if this were fixed. BlackcurrantTea (talk) 02:16, 12 April 2019 (UTC)
I'm still having the opposite issue that I mentioned before: diffs being marked as read even though they weren't, but on occasion I also see the issue that everyone else is complaining about regarding diffs that have been read. isaacl (talk) 03:32, 12 April 2019 (UTC)
Maintenance of templatetransclusioncheck and DYK QPQ check
Original topic heading: "Opinion required"
I would like to know whether taking up the tools DyK notices (mentioned here) and TemplateTransclusionCheck (mentioned here) as a maintainer will benefit for someone here. Adithyak1997 (talk) 15:27, 4 April 2019 (UTC)
This task is done for Wikipedia in general not for specific WikiProjects. If any article associated with Wikipedia:WikiProject Civil Rights Movement has a file on Commons which happens to be nominated for deletion, the talkpage of the article will receive notification. I think this is also only done for files on Commons not for any other sister projects. – Ammarpad (talk) 14:00, 2 April 2019 (UTC)
I understand your point. I'm trying to find a way for the WikiProject to be notified of this delete nomination. The project uses a variety of notification bots or services, but none of them registered the delete nomination. If there is a bot that performs this task, then I'm not aware of it. I was wondering if such a thing exists. Mitchumch (talk) 23:53, 2 April 2019 (UTC)
how to disable the annoying "your edit was saved" pop up
Today I started getting an annoying pop up at the top of my screen every time I edit an article. I don't need a notification to interrupt me and grab my attention to make me aware that I'm doing what I know I'm doing. Does anybody please know how to disable this clever "feature"? Thanks very much! Dr. Vogel (talk) 23:35, 5 April 2019 (UTC)
Hi, thanks very much, I'll have a go. This looks like a hack, but if it works, it will at least remove the pointless distraction. I would be interested in hearing one good reason why somebody thought it'd be a good idea to create a notification that gets your attention and interrupts you to tell you that you're doing what you're doing, and there isn't even an option to disable it. Dr. Vogel (talk) 23:58, 5 April 2019 (UTC)
A p-value of 0.052 is not exactly significant or a major difference :) Also what about the people it annoys? But thanks for sharing that, it's consistent with what I felt was probably the case! Dr. Vogel (talk) 01:28, 6 April 2019 (UTC)
@PrimeHunter and Amorymeltzer: And more than that, Wikipedia needs to modernize with time. The popup in the top-center was good way back in 2012, but now with sophisticated Snackbars/Toasts (such as Google or this) existing in 2019, Wikipedia should move over to them. There is a huge problem with Wikipedia using old and outdated design styles. 125.63.105.110 (talk) 14:59, 9 April 2019 (UTC)
I wasn't thrilled about it when it was new, but since there, there have been a few times when I've been grateful for it. "Yup, worked" vs "Nope, time to file a bug" isn't always as clear as it should be. Whatamidoing (WMF) (talk) 17:18, 12 April 2019 (UTC)
@Pipetricker: Sorry, I should have removed this post. I have a local copy of the chemistry-project. I guess that I used that with AWB, because the day after I got a list without any deleted pages. (I used AWB, and AWB uses the API to get the categories...) Christian75 (talk) 17:44, 12 April 2019 (UTC)
I have poor and declining vision; needing to enlarge the size of text (significantly) for accessibility. Although some infoboxs do not present the following concern, many to perhaps most of the one's being used stretch horizontally in concert with the font's increase in size. Their presence, then, quickly dominates everything else (consuming the page's width) and it does become quite distracting.
It is my belief that every infobox template should be prevented (by default) from stretching beyond half of the page's width; with all of the excess stretching the IB vertically or, perhaps, by scrolling the horizontal overflow. My questions are: 1.) Is this thing worth fixing? 2.) If it is worth fixing, what recourse is available (from BOLD to an RfC)? 3.) What causes this problem and what will fix it (if not by changing the default coding for IB templates, perhaps by a script)? Thank you.--John Cline (talk) 02:09, 12 April 2019 (UTC)
Sorry to hear about your vision. I expect that there are other WP editors here who have similar challenges and can help you. How big a font size are you choosing? In Firefox, if I choose 28-point font in the Preferences (I normally read and edit using 14-point), I basically get three equal columns at, for example, John McPhee: one on the left with Main page etc., one column of content, and one column for the infobox. That doesn't seem too bad. YMMV with the size and resolution of your monitor. You might try a different browser, a different screen resolution, or if possible, a larger monitor. – Jonesey95 (talk) 04:26, 12 April 2019 (UTC)
John Cline, I'm sorry to hear of your vision problem. As an interim measure, you might try the MinervaNeue skin. I looked at the different skins with the page size increased, and at 300% (according to Firefox, article title ~1.25 cm (0.49 in) tall) using MinervaNeue, the infobox took up 1/3 of the page width, or 1/4 if I widened the browser window to full screen. BlackcurrantTea (talk) 05:34, 12 April 2019 (UTC)
John, I've also had good success with changing the default font size in the browser. In Safari, it's under Preferences > Advanced. In Chrome, it's Preferences, then scroll down to Appearances and select the Large or Very Large font size. In Firefox, go to Preferences or type about:preferences in the URL bar, and scroll down to set a font size that works better for you. The main advantage to this is that it will then work on all webpages, not just here. Whatamidoing (WMF) (talk) 18:49, 12 April 2019 (UTC)
extension imagemap was updated recently (i believe it was recent. TBH, i don't know when exactly - could have been months). one of the consequences is that it became more feisty with regard to its input, and in particular, the "coordinates" (the number passed to "poly" in particular). we found and fixed some occurrences in hewiki, and there's still quite a few in enwiki. two of the problems we found were
-1 as one of the numbers. before the update, imagemap could handle it. no more. (i assume -1000 would be just as bad - we had -1's)
comma as separator between the coordinates. before the update, worked fine with 1, 2, 3, 4. no more.
unfortunately, this extension does not attach tracking categories to pages with issues, but it _does_ display a big, red, ugly message instead of the image when it feels slighted.
@TheDJ: - we may be splitting hair here, but i beg to differ. "invalid" is in the eye of the beholder. there is nothing i could find in W3 documentation stipulating that all vertices of a polygon in "area" element within a map element must reside inside the map's borders (there is a case to be made why vertices outside the border may be useful). all browsers can deal with polygons with some vertices outside. so from html POV, these were not "invalid". the imagemap extension was happy to accept such polygons until some time ago, and as far as i could find, never mentioned such a constraint in its documentation. so i am not sure in what sense these maps were "invalid" before the change to the extension. twisi, imagemap extension introduced, perhaps unwittingly, a breaking change (to add insult to injury, this was never mentioned on any of the biweekly "tech news"). this is of course just lawyering - the point of my message was that something that used to work stopped working due to software change, and if we want to make it "working" again, we need to do something. and, while i have your ear, i think we should lobby MW to add some tracking category to imagemap errors (see 4yo phabricator:T106075).
as to phab:T217087: this one talks about "non-numerical" values. it's somewhat hard to argue that "-1" is "non-numerical". much easier to guess that the programmer applied stricter rules to "numerical" than was warranted. i reopened it. peace - קיפודנחש (aka kipod) (talk) 15:52, 10 April 2019 (UTC)
The two latest edits are by a user who reverted their own edit. Rollback reverts all consecutive edits by the latest editor. This currently means there is nothing to roll back. PrimeHunter (talk) 20:57, 13 April 2019 (UTC)
Please do visit the page [Users]. I would like to know the reason why the braces for talks and contribs present in that specific page is removed. I guess this has been done in all wiki projects. Adithyak1997 (talk) 14:07, 13 April 2019 (UTC)
@Xaosflux: Thanks for reporting in phab and replying. Please confirm whether there is any typo with the word 'preset' used by you in phab. You can remove this message once you confirm it. Adithyak1997 (talk) 15:38, 13 April 2019 (UTC)
@Xaosflux: Looks like gerrit:499364 broke it by changing a method (Linker::userToolLinksRedContribs()) used by more than just the one special page that patch was trying to change. I'm not at liberty to copy that into Phabricator at the moment, if you could do so that might help. You might also CC the people involved with that change. Anomie⚔23:13, 13 April 2019 (UTC)
{{Orphan}} used to become invisible after a month or two, but as of late (not exactly sure when) it seems to have become permanently visible, and I don't see any changes in the template's history. Does anyone know what caused that, and how it can be reverted back to the previous behavior? ♠PMC♠ (talk)04:49, 14 April 2019 (UTC)
@Thegooduser: that was not a permanent fix, just a test. You probably have something conflicting in your many .js files or a gadget. You can start disabling some to find out which one. If you have an immediate vandal problem please post at WP:AIV or WP:AN/I. — xaosfluxTalk03:19, 12 April 2019 (UTC)
Many Infobox templates (e.g. {{Infobox person/Wikidata}}{{Infobox software}}) are capable of using URL from Wikidata, but the result of rendering tends to be terrible with URLs that are even slightly longer than usual -- they just stretch the entire infobox with them. This happens with the website (P856 or P1581) field of Infobox person as well as P1324 for Infobox software. I figured the solution should take something like Module:URL or wdib.url2, but failed to make it work for infobox person around all the {{if empty}} magic and stuff. Would someone else please take a look into this and find the correct way to wrap these things?
Things I have tried for infobox person:
Wrapping the entire if empty in URL: Wikidata edit button explodes in my face
Wrapping the entire thing in wdib.url2: Field is gone
Wrapping the two getValues separately in wdib.url2: Field is gone
Using wdib.getWebsite for P856 and forgetting about P1851 for now: Field is gone
Sorry, false alarm. I forgot to look it up in View selection source and Inspect element. The link shows up normally in HTML, but has special CSS formatting in Inspect element, so it's something in my browser, most likely the adblock. DaßWölf23:20, 14 April 2019 (UTC)
Template errors being shown on page when they should be "shown only in preview"
The revisionid breakage is intentional. Coders of the modules in question should use mw.addWarning instead of revisionid. Mw.addWarning will only show up in preview anyway.--Snaevar (talk) 19:11, 12 April 2019 (UTC)
The issue we see here is indeed a bug in the software and we are now working to fix it. Having said that, specifically for a Lua module that wants to show a warning at the top of previews, mw.addWarning is a perfect fit that would be better in general, and also happens to not be affected by today's bug. --Krinkle (talk) 21:13, 12 April 2019 (UTC)
For cs1|2, the philosophy of error-message-at-the-top of a preview is a non-starter. What is wanted is a function returning a boolean that indicates that 'this' rendering is live vs 'this' rendering which is preview. cs1|2 takes the position that error messages should be rendered where they occur. At cs1|2 the 'preview' detection is used to show malformed archive url links in preview mode so that an editor can use that information to repair the url; if not in preview, malformed archive urls are not rendered.
You would have us use mw.addWarning() but that won't work for us because (at least according to the documentation) it doesn't provide a return value so cannot be used to control how the calling module acts. Until there is a function that will return a boolean indicating the rendering mode, the {{REVISIONID}} hack will have to suffice (give us a proper function to call and we won't have to use a hack). The facility must already exist else how does mw.addWarning() know when to render the warning message? Expose that facility.
There is a problem with error messages like this one:
Warning: Barack Obama is calling Template:Cite web with more than one value for the "publisher" parameter. Only the last value provided will be used. (Help)
Barack Obama has 140-ish {{cite web}} templates. Which one(s) is/are the offender(s)? MediaWiki knows which is/are the offender(s) so it can put the message right there (various other error messages related to citations end up in the right place). Yeah, there are tools that editors have developed to assist in fixing these errors but those tools would be a lot less necessary if the error message is rendered adjacent to the template that has the problem.
You are generally correct in that mw.addWarning() won't serve your use case if your use case requires that the warning appear inline in the page rather than at the top of the preview. Your middle paragraph has things backwards, though: mw.addWarning() doesn't actually know whether the page is being rendered in preview mode or not, all it does is add a warning to the list of warnings. The preview page shows that list of warnings, when the normal article view does not.
A better justification for the fact that it should be possible to add something that returns a boolean for preview mode is that {{REVISIONID}} itself is already doing that. That was suggested in code review of the patch making the change, but there's also a good argument to be made that rendering differently in preview versus non-preview mode somewhat defeats the point of doing a preview, so we wound up preserving the current hack without officially condoning it by creating a non-hacky way to do it.
Perhaps the thing to do would be to consider ways to make mw.addWarning() work. For example, would it work to have mw.addWarning() return a token that produces <!--W123--> in the HTML (for both preview and non-preview mode), and have some JavaScript on the preview page that used that to associate the top-of-page warning with the location in the wikitext? Or have the token produce <span id="W123"></span> in the HTML (again for both preview and non-preview) so no JS is necessary? Anomie⚔13:31, 13 April 2019 (UTC)
Backwards? More like wrong because, as I noted, the documentation does not say how mw.addWarning() works so readers like me are left to wonder just what is going on ... so we draw incorrect conclusions.
I don't know about js and and css as possible solutions to the page calling template with more than one ... message. Can css distinguish live from preview? Can js?
Hmm. Our Gerrit installation has two UIs, and apparently it still defaults to the old one (there's a link at the bottom to set a cookie or something for the new UI). The link works for the new UI. It doesn't seem possible to link to a specific comment in the old UI, but gerrit:294774 will get you to the change.
Yes, both CSS and JS can affect preview renderings specifically. I suppose the CSS would have to consider both the normal preview and VisualEditor, I'm not very familiar with the latter. Anomie⚔22:51, 13 April 2019 (UTC)
That bit about ve is concerning; (it is an abomination that I won't touch) but if it requires something special then what I am about to write may not be worth the time it takes me to write it.
cs1|2 wants to inspect archive urls and if they are flawed in certain ways not render them. Instead of the {{REVISIONID}} hack we might render archive links, dates, and static text wrapped in a <span>...</span> tag. When the archive links, dates, and static text may be displayed cs1|2 does not add a class. When errors of the kind that should cause cs1|2 to hide archive links, dates, and static text, cs1|2 adds class="cs1-archive-error" attribute where cs1-archive-error is defined in Module:Citation/CS1/styles.css. I don't really know how to write css selectors but each rendered html page has one of these:
Yesterday's deployment caused a bug in the handling of {{REVISIONID}}. Users Mélencron and Galobtter reported an issue with the Bill Shorten article, where a warning was displayed at the top of the page. I referenced addWarning() because it happens to be very good at doing that. Alas, it turned out that the bug in question actually affected both of these mechanisms, so it wouldn't have worked after all...
The {{REVISIONID}} magic word is still the supported and only way to detect preview mode for the purposes of producing different content within a page. The addWarning() function intentionally does not allow this, and actually internally stores its warnings separate from the page content. As optimisation for the subset of cases where the top of the page is your goal, this allows the parser result to be saved and re-used.
Per Krinkle's post, this might be moot but I'm posting my understanding of the issue to save time for others (and to invite corrections).
MediaWiki has an edit stashing feature whereby (given certain normal conditions) previewing an edit causes the rendered result to be temporarily saved (stashed). If the edit is saved without changes, the stashed copy is used to display the page.
That is a significant performance boost because saving a previewed edit does not require much extra processing.
Modules need a way to show a prominent message when a page with an error is previewed, and a different result when it is saved.
Using mw.addWarning to show a warning at the top of the page when there might be 100 templates that could have caused the problem is hopeless (the warning usually needs to be next to the problem).
Displaying the same result for preview and save is very unhelpful when templates with an error are involved.
To illustrate the last point, {{convert|12|m|abbr=off}} is a normal {{convert}}, while {{convert|12|m|abbr=of}} has a typo. For the typo, convert displays an in-your-face error message when previewing, but a discreet asterisk when saved.
A prominent error message during preview is required to help the editor notice the problem.
A prominent error message when saved would unnecessarily degrade the article, so only an asterisk and error-tracking category are added.
Only a very small number of articles ever have a convert error so there is no performance problem from the fact that convert shows two different kinds of messages. I monitor Category:Convert errors and it is usually empty, with perhaps four problems per day. The situation is different for other cases where, for example, an infobox might have a typo that persists for a long time. That is a different situation which might need a different solution. Johnuniq (talk) 01:40, 13 April 2019 (UTC)
Some of you might be interested in the upcoming presentation described at mw:Tech talks#Upcoming tech talks 2019 season. Srishti is going to give a general talk about how developers and their allies (designers, documentation writers, testers, etc.) can contribute to MediaWiki and related software. If you are (a) a dev-type person yourself or (b) hang out at this page, then you might find this useful.
Time: April 24, 2019 at 18:00 UTC (11:00 a.m. PDT), for about 45 minutes
If you're online during the talk, then there will probably be an opportunity to ask questions (maybe on m:IRC?). These talks are normally recorded, so you can watch it later. Whatamidoing (WMF) (talk) 16:02, 12 April 2019 (UTC)
You can't wikilink a wikilink. The infobox creates a wikilink [[Presidency of ...|...]] for both predecessor and successor. This suggests that there should already be articles: Presidency of Jaime Lusinchi and Presidency of Octavio Lepage. There is not for the latter so you might want to create a redirect from Presidency of Octavio Lepage → Octavio Lepage and cleanup the |predecessor= and |successor= parameters in the infobox.
I'm glad to see that visual editor edit summary box will now show past summaries in a drop-down box ([34], mentioned in the weekly update above) but I don't like that the first one is automatically selected, so I can't use the ctrl+enter shortcut to submit it. Is there a way to change this functionality? Reywas92Talk06:08, 14 April 2019 (UTC)
I and Whatamidoing (WMF) both left a comment on the task that you linked therein. You don't need to support it any further, just subscribe to the task and either it will change there or on a task linked from there. --Izno (talk) 23:35, 14 April 2019 (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
All wikis now have the TemplateWizard for the wikitext editor.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 17 April at 15:00 (UTC). See how to join.
Future changes
Wikidata will get a new constraint status called suggestion. This will change how the WikibaseQualityConstraints constraint checking API works. [35][36]
You can test the depicts property for structured data on Commons.
The first item above may result in a greater need for the Template Data programming code that is stored in template documentation pages. Those of you who understand and are interested in the esoterica of adding Template Data may want to give some attention to the templates listed at Wikipedia:TemplateData. – Jonesey95 (talk) 06:16, 16 April 2019 (UTC)
Wikipedia:Vorlagenfehler/Vorlage:TemplateData
Resolved
This revision to the TemplateData code block in a template's documentation appears to have resulted in that template's documentation page being added to Category:Wikipedia:Vorlagenfehler/Vorlage:TemplateData. Based on web translation, that looks like a category used for pages with TemplateData errors. Why is it in German? How can we activate an English-language version of this category here on en.WP? It would be useful to have such a category to catch TemplateData errors. – Jonesey95 (talk) 06:04, 16 April 2019 (UTC)
Thanks. For some reason, I didn't think to search for the category name in Template space. Silly me. I have translated the template's error message and category into English and created the maintenance category. – Jonesey95 (talk) 10:08, 16 April 2019 (UTC)
Agree this is hideous, takes up about 1/3 of my vertical screen as well. The prior incarnation (shown IN the phab ticket description) had the selectors laid out side by side, @Bradv: is right, restoring that layout alone would greatly improve this. Anyone got a hack for just that? — xaosfluxTalk21:09, 8 April 2019 (UTC)
Agreed. Is this a bug? That is, were the elements supposed to be on one line, but something went wrong? If so, then let's not pile on with the anti-WMF snark just yet. Shit happens. But if this intentional, I'd really like an explanation. Suffusion of Yellow (talk) 01:00, 9 April 2019 (UTC)
It adds an extra click for every page, which is an unacceptable waste of the editors' time. Needs to be reverted back or made collapsible or made opt-in/opt-out.--Ymblanter (talk) 08:18, 9 April 2019 (UTC)
Clarification: For me, it takes more than 1/2 of the screen, pushing the first edit in the history off the first screen.--Ymblanter (talk) 08:23, 9 April 2019 (UTC)
Can somebody please translate the above tech stuff for a Luddite like me? How do I get rid of this and go back to how it was before? Glad I'm not the only one that's pissed off with it... GiantSnowman12:07, 9 April 2019 (UTC)
@GiantSnowman: to be clear, adding an @import to your css/js pages means that it will also copy whatever the current contents of that other page are in to your running session, keep in mind - anything they change in the future (purposefully, or if their account is compromised) will also be loaded to you. Admins should take extra caution when importing from other users. You can always go to that page and just copy/paste the code to your page if you want a point-in-time version. (Think of the @import like a template transclusion). — xaosfluxTalk12:48, 9 April 2019 (UTC)
Hi everybody, Volker E. (WMF) here, one of the folks behind the original change. After looking through feedback here, the comments on phab:T107069 and talking to other long-term contributors, we've merged a patch to Beta Cluster by my colleague Jon Robson to collapse form by default and make it expandable. As the overwhelming majority of use case seems NOT to involve interacting with the form at all.
With the patch we're focussing on three sides:
if functionality is rarely used, it's useful to have it hidden by default,
if vertical space is main issue – collapsing is providing more vertical space than before OOUI transformation without
introducing technical/user experience debt by inlining form elements unlike other OOUIfied forms.
The change can already be tried out on Beta Cluster and we could SWAT it 24h of now to all wikis, depending on feedback either on the tracking Phabricator task or here from you volunteer contributors…
What I'd like is a way to opt out of this completely, not a way to get round it. I don't want to change my css or use JavaScript to hide it; I have, for now, but I want to opt out. Please. BlackcurrantTea (talk) 04:04, 10 April 2019 (UTC)
Complete opt-out and keeping the old code would be the best solution for me too. The new one takes a noticeable additional time to load, and this is irritating. Tricks that diminish or hide the box are rather trivial, I can even implement them myself, but they don't bring back the lost performance. — Mike Novikoff10:04, 10 April 2019 (UTC)
Is there a way to go the old history page toolbox back, perhaps using the Gadget menu? I get that this is simpler and more intuitive but it's also slower because it's JS heavy. I found the old one much faster, especially since the things I wanted were often only one or two clicks away. For example if I wanted to go back to the year 2007 I'd just select the year box, type "2007" and press enter, while now I have to make six clicks. DaßWölf00:21, 10 April 2019 (UTC)
Daß Wölf, when you say slow, you mean 'slow to operate' ? In my opinion, it would help if the date widget would be able to autocomplete based on what I type. It's rather 'mouse'-heavy, I either need to type out the full date, or part of the date and then select the day by mouse. —TheDJ (talk • contribs) 12:32, 10 April 2019 (UTC)
@TheDJ: slow to operate, and also slow to load, although the latter is probably unavoidable given the ubiquitous CSS and JS heavy design choices that WP seems to be adopting. <rant>A little annoying that my internet connection is 1000 times as fast as ten years ago, yet websites take longer to render.</rant> I would also appreciate an autocomplete feature. For example, it would be nice if it could autocomplete e.g. 2017 or 17 to 2017-12-31. DaßWölf20:59, 10 April 2019 (UTC)
Volker E. (WMF), having read the comments on the Phabricator task and yours above, both of which state that the form (or similar functions) isn't used much (the overwhelming majority of use case seems NOT to involve interacting with the form at all), I'm wondering why the response to this unpopular change is if functionality is rarely used, it's useful to have it hidden by default rather than 'if functionality is rarely used, it's useful to have it off by default'.
Why is this something we have to work to get rid of, rather than an option? I understand that it's meant to help users on mobile devices. Why not make it part of the mobile interface – preferably one that users can turn off if they don't like it – and an option for desktop editors? BlackcurrantTea (talk) 02:29, 11 April 2019 (UTC)
@BlackcurrantTea: If I understand you correctly, you're asking why can't it be visible for desktop users and hidden for mobile users? And a collapse/expand functionality is left out of the question. It's important to say that there is not one homogenous group of users. There might be a majority of users that don't interact with that page any different than to look up recent changes for a specific page and never touch the form. It doesn't matter for the main use case if they are on mobile or desktop, any form is in their way. There might be a minority of users that want to limit the revisions shown to a certain date. It doesn't matter for where to access the filter functionality as long as it's accessible, no matter what device they are on. There might be a minority of newcomer users that have no idea yet, what a tag filter is. But later on they are curious and try the functionality and instead of hiding it away in a setting, that needs to be explained in complete different context (settings page) and maintained and kept working for years, it's in a minimal interface on the place where it is meant to be without confusing to the first group. With these examples I'd like to share that no matter what solution it should please the main use case user while not excluding other use case users independently of the device. Volker E. (WMF) (talk) 03:11, 11 April 2019 (UTC)
Thank you for your quick response, Volker E. (WMF). No, I'm asking the opposite (let it default to 'on' for mobile users, 'off' for desktop), based on the suggestion at Phabricator that this is supposed to help mobile users. What I want as a user is a way to turn it off. I belong to the group of users that don't interact with that page any different than to look up recent changes for a specific page and never touch the form. It doesn't matter for the main use case if they are on mobile or desktop, any form is in their way. I want to remove it from my screen entirely. Not hide it nor collapse it: I want to turn it off. Can you make that possible, please? BlackcurrantTea (talk) 03:52, 11 April 2019 (UTC)
Volker E. (WMF), whilst I appreciate the help and suggestions from you and others here, I feel strongly that we shouldn't have to fight the software. As I said, I don't want to change my css or use JavaScript to hide it; I have, for now, but I want to opt out. and I want to remove it from my screen entirely. Not hide it nor collapse it. By 'it', I mean this new version that has been imposed on us. The old version was fine. It worked. It didn't take up an inordinate amount of my screen.
The new version should be optional, and something anyone can turn on or off with preferences. Not something that requires mucking about with css or JavaScript to get rid of it or to get a semblance of the old version back. BlackcurrantTea (talk) 00:32, 12 April 2019 (UTC)
Volker E. (WMF), you must be kidding. Are we supposed to teach the developer what {display:none} is and how it differs from turning the bloat off? Ok, I'll do: it's always the last resort when nothing else could be done, it's practiced by users when developers are out of reach, source code is unavailable, insufficient knowledge to modify it, etc. But it's you who can really change the underlying code, and that's what we ask of you. Let me repeat that magic word: 'please'! — Mike Novikoff18:00, 12 April 2019 (UTC)
At the very least, reduce the width of the "Tag filter:" box - I don't see why it has to be full width, when Special:Contributions has one that is about 15em wide, and has sideways scrolling so will accept more input. That way you can put everything (labels, input items and checkboxes) on one line. --Redrose64 🌹 (talk) 08:15, 11 April 2019 (UTC)
Shhh! Don't talk about the form at the top of Special:Contributions, lest the WMF decide to do their shit (read OOUI-fication) on that too. SD0001 (talk) 09:04, 11 April 2019 (UTC)
Completely concur with Redrose64. All elements inside <form id="mw-history-searchform">...</form> could easily be shown in one line (or at least as inline-blocks). Nardog (talk) 09:14, 11 April 2019 (UTC)
Does anyone have the HTML code of the box before the OOUI-fication, so that we can make a script to restore the old version? SD0001 (talk) 09:23, 11 April 2019 (UTC)
In Vector skin, it was
<formaction="/w/index.php"method="get"id="mw-history-searchform"><fieldsetid="mw-history-search"><legend>Search for revisions</legend><inputtype="hidden"value="Events"name="title"><inputtype="hidden"value="history"name="action"><labelfor="year">From year (and earlier):</label><inputid="year"maxlength="4"size="7"type="number"value="2019"name="year"><labelfor="month">From month (and earlier):</label><selectname="month"id="month"class="mw-month-selector"><optionvalue="-1">all</option><optionvalue="1">January</option><optionvalue="2">February</option><optionvalue="3">March</option><optionvalue="4">April</option><optionvalue="5">May</option><optionvalue="6">June</option><optionvalue="7">July</option><optionvalue="8">August</option><optionvalue="9">September</option><optionvalue="10">October</option><optionvalue="11">November</option><optionvalue="12">December</option></select> <labelfor="tagfilter"><ahref="/wiki/Special:Tags"title="Special:Tags">Tag</a> filter:</label> <inputname="tagfilter"size="20"value=""class="mw-tagfilter-input mw-ui-input mw-ui-input-inline"id="tagfilter"> <inputtype="submit"value="Show"></fieldset></form>
Excellent! Those who want to revert back to the old version: Add importScript('User:SD0001/oldSearchHistory.js'); to your js page, and @import url("//en.wikipedia.org/w/index.php?title=User:SD0001/oldSearchHistory.css&action=raw&ctype=text/css"); to your css page. The latter (css) is optional but prevents the new version of the box from flashing momentarily. SD0001 (talk) 13:57, 11 April 2019 (UTC)
I would also much appreciate having this as a gadget or in general as a preference that lets user not waste time by rendering/loading both the old and the new search box into memory - especially since the CSS hack doesn't seem to be working for me (the new box still displays for 1-2 seconds). DaßWölf20:45, 14 April 2019 (UTC)
Go to the history of any given page, let's say this page, i.e. [37]. Select a date, let's say 31 December 2018, and click "Show revisions". You are led to this page. Now click "older 50". You are led to this page, which shows you the exact same things as the previous page. This time, click "newer 50". This one works. But click "newer 50" again. You are led to here, which shows you the exact same things as the previous one. Tested on Chrome & Firefox. What is going on here? In the meantime, the previous version, as much as you can't choose a specific date, still works. Nardog (talk) 22:02, 11 April 2019 (UTC)
What happened is that the cook mixed in grasshoppers and live maggots in all editors' food even so he knew that only a few might enjoy it and on top he didn't even check for mold before forcing it down our throat. Same business as usual here. (Yes, I like to point out shortcomings due to missing professional oversight and authority on Wikipedia).--TMCk (talk) 20:19, 12 April 2019 (UTC)
Actually, that specific page has undergone a minimum of 1300+ edits on 16th. So, when you click on the "Older 50" button, I guess you will experience a repetition. Just click on the number 500 present near to "older 50" and then just click on the "older 500" link two times and check if your getting any changes in the date. Adithyak1997 (talk) 15:23, 16 April 2019 (UTC)
I don't suppose it's possible to see the edit that removed the wording I had a problem with. The problem language was gone by 23:59 on April 15 and, of course, the article was started on the 15th but then, that's the date I complained.— Vchimpanzee • talk • contributions • 15:50, 16 April 2019 (UTC)
Error
Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.
See the error message at the bottom of this page for more information.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request from 98.21.227.217 via cp1085 cp1085, Varnish XID 371130561
Error: 503, Backend fetch failed at Tue, 16 Apr 2019 18:36:41 GMT
It's been at less than 10/min since about 19:20, so it seems to be fixed for now. I saw some WMF Operations people in IRC trying to find the root cause, it doesn't seem like there's anything us mere mortals volunteers can do right now but wait for the incident report. rchard2scout (talk) 20:02, 16 April 2019 (UTC)
@Xaosflux: No, I found that one earlier. I was thinking we might be running MessageCommons, but we're not. I've been actioning file rename request and the page header where you enter the new filename needs some link target updates. I'll get a screenshot in a few and post a link here. Thanx for your reply. - FlightTime (open channel)22:37, 16 April 2019 (UTC)
Is it possible to have a "back to top" link added to the footer, of automatically appear at end of page, say, after categories, or even in the categories box.
I mostly read, and often edit, via iPad, and getting back up to select watchlist or search or some other option is creating callouses on pages like thisClubOranjeT08:18, 17 April 2019 (UTC)
Thanks @DannyS712:, works fine. I do still think it would be worth adding it into page coding so it appears automatically for everyone without having to install a script. Not everyone knows how or has the confidence to. ClubOranjeT09:10, 17 April 2019 (UTC)
Do we have any good tools for scouring away duplicate wikilinks from sections like Mahesh Bhatt#Filmography? Years ago I remember seeing some javascript tools. I tried two of them, but they didn't work consistently. Seems like the things that it would need to do are:
Spot duplicates
Be able to convert piped wikilinks to text. (Ex: [[Om Prakash (cinematographer)|Om Prakash]] → Om Prakash)
Leave the first instance of a link, or a number of links the user specifies. "Keep the first _2_ links"
I don't know that running it on an entire article would always be the best way to go. If there was some way to limit it to when you click Edit on a section, that might be ideal, unless it could process each section uniquely.
Sometimes sections (like a film soundtrack) have introductory text that may intuitively have wikilinks that are duplicated in a secondary area like a soundtrack table. Maybe some flexibility would be helpful there.
Can't someone figure out why English phonology#Onset is throwing up the error Cite error: A list-defined reference named "FOOTNOTEMcColl Millar200763-64" is not used in the content (see the help page).? It has multiple instances of {{sfnp}}, inside {{efn}} inside {{notelist|refs=}}, and for some reason only one of them is resulting in an error. Upon toying with the code on Special:ExpandTemplates, it seems MediaWiki is parsing nested <ref>...</ref> tags in a peculiar way. Nardog (talk) 13:37, 17 April 2019 (UTC)
@Redrose64: Thanks. I wonder, then, what is the best way to offer an in-article list of footnotes. I've seen various ways, from {{ref}}/{{note}} to simply superscript numerals and an ordered list. <ref group="xxx">...</ref> seems most straightforward but the long superscript links ("[xxx 1]") can be annoying and disrupting the flow of the text. Nardog (talk) 14:44, 17 April 2019 (UTC)
Just use {{efn}} in the documented way (With lower-alpha labels), but put the {{notelist}} in the section of prose rather than in a section at the bottom. --Redrose64 🌹 (talk) 15:07, 17 April 2019 (UTC)
Ah, obvs. That wouldn't work if the article already uses {{efn}} for a footnotes section for the entire article, but such an article structure would probably be stylistically objectionable. Nardog (talk) 15:36, 17 April 2019 (UTC)
Per User talk:Iridescent#Double notification, is there any way we can disable the double-notification when a username is linked in both the text and the edit summary? I was aware this was an issue when "ping from edit summary" was first introduced (example), but thought it had been fixed months ago. Given the habit many editors have of copying the first line of their comment (which is also where the @whoever ping is most likely to be) to use as the edit summary, this is a bug that's going to keep on annoying people. ‑ Iridescent09:04, 18 April 2019 (UTC)
Anyone else getting this error white trying to edit? I've had it happen intermittently three times around the past half hour while either trying to view changes or submit changes. Here's a sample of the output, where it's throwing a ConfigException. Opencooper (talk) 10:42, 18 April 2019 (UTC)
I have also seen something like this. It may be to do with the PHP7 beta feature. Has anybody not using PHP7 seen this error? BethNaught (talk) 10:56, 18 April 2019 (UTC)
FYI, it seems to have been resolved as of 12:20:39 UTC, although the root cause has not yet been determined. Watch the Phabricator task for further details. BJorsch (WMF) (talk) 12:57, 18 April 2019 (UTC)
Nonsense dates
Nonsense dates appear on the screen tables for running the app for "Page statistics" from the edit history page of many if not most articles, in the fields for "First date" and "Last date". The two that I have just run are Herman Melville here [41], and the film article for The Favourite. Could someone look at this? CodexJustin (talk) 14:54, 17 April 2019 (UTC)
@CodexJustin: I see what you mean. For those who haven't found them, they are in the Top editors section, in both the "First edit" and "Latest edit" columns, where dates like "2013-55-29 18:" and "2018-11-9 17:" are displayed. These are linked to diffs, from which I see that these two dates should have been displayed as "2013-11-29 18:55" and "2018-03-09 17:11" respectively. Something is dropping the true month value, and moving the minutes value to the position intended for the month; it might be a simple matter of "MM"/"mm" confusion in a date formatting string. It's definitely one for the tool maintainer, you should file a Phabricator ticket. --Redrose64 🌹 (talk) 22:09, 17 April 2019 (UTC)
For the past few months I've noticed Special:Nuke is very inconsistent. Maybe 1/3 to 1/2 of the time it loads for 20/30 seconds, then sends it to a WMF error screen. When it does work it's still extremely slow to load the list of pages, even (I tested) when it's 2, 1, or 0 pages, but once I'm there and press delete it very quickly deletes everybody without trouble. Anyone else notice this, and is this a concern? The Blade of the Northern Lights (話して下さい) 16:45, 18 April 2019 (UTC)
With Media Queries Level 5 (and in particular, prefers-color-scheme) getting moved into Google Chrome and Mozilla Firefox (67) (Safari has supported this since "dark mode" was added to MacOS Mojave), I'm wondering if it's not time to start including support for this within the various skins available here? Windows also has a "dark mode" toggle, and it appears this system value is used by both Chrome and Firefox to set the value within the browser (so websites can adapt to the mode selected by the user). IIRC, Microsoft is going to switch to using Chrome for Edge at some point, so that would cover all the major browsers for support. —Locke Cole • t • c06:33, 18 April 2019 (UTC)
I went to [42] and then ran importScript('Wikipedia:AutoEd/complete.js'); which yielded jQuery.Deferred exception: autoEdUnicodify is not defined. Looking at Wikipedia:AutoEd/complete.js, it's easy to see why. It's yet another case of someone trying to "structure" their code by splitting it up across different pages and then loading those pages with importScript or mw.loader.load. Needless to say, that has never worked and never will. importScript and mw.loader.load are both async and neither allow for a callback to be ran when they have finished fetching a script. This means that they cannot be used to fetch something that is needed for other code to work. They are only fine to use when loading completely unrelated and contained scripts. Nirmos (talk) 01:33, 19 April 2019 (UTC)
Having incorrectly edited {{Colorbull}} with the intention of adding a description option, I am unable correct this edit (in which I mistakenly included <span title=n> inside <span style=n>) without being greeted by this error message: Required property "paramOrder[4]" not found. I have tried reverting my edit but to no avail. Please help, thanks. Neveselbert (talk·contribs·email) 10:57, 18 April 2019 (UTC)
How do I prevent every page I edit from being added to my watchlist? I can't find an appropriate setting to change in preference menu.--Megaman en m (talk) 09:06, 19 April 2019 (UTC)
The title of the collapsed box is defined by MediaWiki:History-fieldset-title, which since previously is customized to "Show revision history" on this wiki.
Some time ago, I unprotected Elephant as a test (it had been protected for years, so I wanted to see if continued protection were warranted), but vandalism quickly recurred and I re-protected it a few days later. No problems. But if you look at the page log, you see a bizarre pair of entries:
05:21, 20 September 2013 Nyttend (talk | contribs | block) protect (It's been seven years since Tripling Elephants, and a year and a half since we last attempted any reduction in protection)
05:21, 20 September 2013 Nyttend (talk | contribs | block) changed protection level for Elephant [move=sysop] (indefinite) (It's been seven years since Tripling Elephants, and a year and a half since we last attempted any reduction in protection)
Any idea what happened here? Only the latter item appears in the protection log. There's no indication whatsoever of what I did in the former one; it should tell you what kind of protection I imposed, at least. Nyttend (talk) 13:10, 20 April 2019 (UTC)
Huh. There must have been some tick box to protect both article and AFT, or protection must have been necessarily bound up together; I remember doing the protection and was definitely interested only in the article. I had no idea that it was even possible to protect the AFT. Nyttend (talk) 14:40, 20 April 2019 (UTC)
My page history link says: Changed visibility of the article feedback tool on "Elephant": It's been seven years since Tripling Elephants, and a year and a half since we last attempted any reduction in protection ([Visibility=Enable for all users] (indefinite)). I said the log entries no longer displayed properly. Don't assume it was a protection just because the bad log entry currently starts with "protect". PrimeHunter (talk) 14:52, 20 April 2019 (UTC)
I noticed all the links were red for Wikipedia:Help desk/Archives/2019 April 13. I went to the Help Desk history and found where Scsbot had supposedly archived. All the bot did was remove the text; it did not create the archive. So I went to the last edit before the archiving took place, clicked on "edit", and copied the text that should have been removed in the next edit. When I tried to create the archive with that text, I got a big pink box telling me a URL was blacklisted. I removed one use of the URL and saved the edit. I restored the URL and the edit still got saved.— Vchimpanzee • talk • contributions • 21:56, 19 April 2019 (UTC)
@Vchimpanzee:phab:T36928 has been open for 5 years asking for a way to allow certain accounts to override this. Perhaps scs can check the operations of their bot, to see if it can more gracefully recover from this type of error. — xaosfluxTalk23:06, 19 April 2019 (UTC)
The url said http://www.anupmandalcom.wordpress.com when the bot tried to archive [45]. You didn't restore the full url but changed it to anupmandalcom.wordpress.com in the archive.[46] This doesn't create a link so the blacklist doesn't care. It was blacklisted at meta in [47] between the original addition to the help desk and the attempted archiving. PrimeHunter (talk) 23:23, 19 April 2019 (UTC)
This is trivial to check for when making a save it will return an error if it did not save. The bot should check for errors and abort/log these cases. -- GreenC23:38, 19 April 2019 (UTC)
For future reference (on smaller pages, not WP:HD), the blacklist can be worked around a couple of ways. If it's merely a link getting removed, rollback will work to put it back. If it's really important, a history merge can resolve the situation (if a page already contains a link, saving a new revision with the same link will not be rejected), but it would require moving a revision from one page to another, which would be rather silly if it weren't important. Nyttend (talk) 14:45, 20 April 2019 (UTC)
Admins shouldn't use such methods to circumvent the url blacklist. We have MediaWiki:Spam-whitelist for that. If a page contains a blacklisted url then editing will easily fail in the future, as already happened here. PrimeHunter (talk) 18:47, 20 April 2019 (UTC)
Thanks for that. Oversight on my part. In future, Help talk:Citation Style 1 is a better venue – because a missing category isn't really a 'technical' problem ...
I don't think there's any change from the software. Looking at the stuff in that page it just means you've now crossed the limit. That limit has been in force for a long time. – Ammarpad (talk) 06:05, 21 April 2019 (UTC)
Are you sure? I ask because the work page looked normal when I made this edit, which did not involve a template at all, late on the 19th. Something does seem to have changed since then. It's as if the limit was lowered since the 19th. Paine Ellsworth, ed. put'r there07:58, 21 April 2019 (UTC)
Just moved a lot of the template material to a different page, but the work page still does not render correctly, so there must be something we're missing. Paine Ellsworth, ed. put'r there08:18, 21 April 2019 (UTC)
It's caused by {{EP/doc|bare=yes}} after this edit to {{EP/doc}} by Jc86035. Other pages transcluding it are also affected by template loops or template include size. If {{PAGENAMETDOC}} is used in a template documentation then the documentation is not suited for transclusion outside the template. We should maybe do something about that. PrimeHunter (talk) 09:21, 21 April 2019 (UTC)
@PrimeHunter: That... looks like a problem. I don't think it's possible to fix that without updating all of the transclusions to include the template name as a parameter value. Jc86035 (talk) 09:25, 21 April 2019 (UTC)
Thank you. That's confusing; it refers to exporting an XML file, then using "Special:Import on destination wiki" to import it there, but the latter has no option to import XML. It's done now, anyway, via an ordinary cut & paste. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:03, 21 April 2019 (UTC)
Done - Thank you for the ping. I actually just fixed that bug! The 'original' code had an overabundance of loops, which overlapped slightly in that edge case; now simplified. ~Tom.Reding (talk ⋅dgaf)14:21, 21 April 2019 (UTC)
It's up, but for some reason it doesn't like your user name. Works for WBG and me (tried with space, _ and +), and for TheCofE (empty table). Shows error 500 for The_C_of_E, even if _ is replaced with other characters (space, +, %20). --MarMi wiki (talk) 20:41, 20 April 2019 (UTC)
Already asked Shubinator, my above statement was unfortunate - implied that operator of DYKUpdateBot is Betacommand, while bot name was only used as a link to discussion with Shubinator about this topic. --MarMi wiki (talk) 23:41, 21 April 2019 (UTC)
Interesting technical issue with duplicate references
At the article List_of_Pokémon_episodes_(seasons_14–current) you can see a citation error here. This error is due to the fact that the overall article is made by linking other list articles like List of Pokémon: XY episodes into the article, but these articles use the same ref tag to give an explanation about how the episodes are ordered. Now I first considered going to the individual list articles and changing their ref names so that the error message for duplicate messages would not appear. However, this would have the unfortunate consequence of cluttering up the Notes section of the main article with duplicate refs. Is there a workaround? 文法楽しい (talk) 21:27, 21 April 2019 (UTC)
If they were all exactly the same it wouldn't be a problem. But Black & White and XY are all like this (referring to Cartoon Network), while Sun & Moon has one version for the first season and another for the two "Ultra" seasons (both referring to Disney XD, with slightly different wording). Anomie⚔22:14, 21 April 2019 (UTC)
Oof, I didn't realize that the notes were actually different. That means I can just change the ref names then and not have to worry about duplicate notes. 文法楽しい (talk) 21:44, 22 April 2019 (UTC)
Issue with Citations, Possibly Corrupted Code?
Hello Everyone, I noticed something very strange when I was creating an article this morning. When I tried to input a citation, whether it be automatic or manual, an error message appeared, and has still not disappeared. The message reads: "Lua error in Module:Citation/CS1/Configuration at line 458: attempt to index local 'content' (a nil value)." I'm not sure why. Does anybody know what is going on? BluePankow✉14:37, 20 April 2019 (UTC)
I just noticed the messages above this. Is it possible that something could have been messed up when @Nardog: did something with it? Not to point fingers, sorry, just trying to figure this out. BluePankow✉14:41, 20 April 2019 (UTC)
Where? Always say where you are encountering such errors. There was an update to the cs1|2 module suite this morning. Because all of the modules in that suite cannot be updated simultaneously, there will be a period of time (usually less than 30-second) when the actual live modules will be a mix of the old and the new. The usual fix for this is to remain calm, don't panic, pause for a moment (go get a coffee), and then try a null edit. If the problem is temporary, the glaring red error message will be gone, you'll have a fresh coffee, and life begins again renewed.
I"m seeing the same "Lua error in Module:Citation/CS1/Configuration at line 458: attempt to index local 'content' (a nil value)" today, whenever I try to use a cite template in visual editor. I can use the manual form, but none of the other options, when citing a source in visual. Penny Richards (talk) 01:21, 23 April 2019 (UTC)
Category counts are often off. See phab:T195397. It's probably two independent errors and not a page being counted as a subcategory. The most common problem is that the count isn't decreased when a page is deleted while it's in the category. According to category watch (disable "Hide categorization of pages" at Special:Preferences#mw-prefsection-watchlist on an account with a small watchlist), the only changes in the last 30 days are removal of two pages: [48][49]PrimeHunter (talk) 08:59, 23 April 2019 (UTC)
I've noticed a number of ITN notice templates on discussion pages showing a date in the future when the correct date was in the past. Is this wrong use of the template or an error in the template code?
Following template code was used {{ITN talk|21|May|2018|oldid=842358283}}
Result: Date appears as 21 May 2019.
The template seems to be coded so that the current year is shown when the date is formatted as above. The year used (in this case 2018) seems to be ignored. The same isn't true about day and month. The template asks for the date to be spelled without and | in between, but some editors seem to misuse and at first, there's no issue because the current year is still the correct one. But after new year, the wrong date is suddenly shown.
I suggest the code is either changed to display an immediate warning when the template is misused (so as not to suggest all is fine), or adjust it so that the above way of inputting the date doesn't cause any trouble. The current situation is unsatisfactory. Unfortunately, I don't know enough about templates to fix it myself.
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 advanced search function URL now shows which namespaces you search in. The namespace field is collapsed by default on the search page. You can also add new fields to the search interface through a hook. [50][51][52]
The wikis now look slightly different in the mobile web version. [53]
Changes later this week
There is no new MediaWiki version this week.
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 23 April at 15:00 (UTC). See how to join.
Future changes
Wikipedia articles will have the sameAsmeta property. It adds structured data. This makes it easier for search engines to find Wikipedia articles. It also makes it easier to reuse content. There will an A/B test. [54][55]
I suppose this topic has been covered before, but haven't ever noticed such. My issue: I have just discovered that "curly quotes" can break the <ref name = "xxx" /> format if the name (xxx) is surrounded by curly quotes instead of straight. Am I correct, and is there a chance the wikimedia software can be modified to silently handle this circumstance and produce the expected results? Error seen in IE 11; Firefox 66; Chrome 73 here.DonFB (talk) 10:37, 22 April 2019 (UTC)
DonFB, they break the reference in that the software sees them as different characters to non-curly quotes. It's as if someone named a reference 1Rpt1 and then typed lRptl – it won't be recognised as the same reference name. They look almost the same on my screen in the edit window, but in preview (and with saved changes) the different font makes it clear that the first Rpt has the digit one to either side, and the second one has a lowercase L. BlackcurrantTea (talk) 11:30, 22 April 2019 (UTC)
Right, I was just wondering if it's feasible for the software to be updated so it can recognize either curly or straight quotes for the purpose of correctly producing the result intended by the ref name routine. In pseudo code, something like: "If routine is ref name and value of surrounding punctuation marks equals straight quotes or equals curly quotes, then recognize 'name' as originally specified." DonFB (talk) 16:17, 22 April 2019 (UTC)
This will probably not be done because it would be inconsistent with everything else that uses a mark (that's anything that has a tag-gy markup). Why should we not change the parser for every case? That would be inconsistent with the rest of the Internet.
What might be more interesting is for the parser to flag (in all cases, not just the ref tag) where a curly quotation mark has been used. I don't know how feasible that is. --Izno (talk) 16:33, 22 April 2019 (UTC)
At least within <ref...>, there is some validation performed. If you try to do <ref name=2> or <ref name=foo bar> or even <ref name="hello"world>, it reports an error. See Help:Cite for details of what is valid and what is checked. Sounds like a reasonable phab ticket to file, and a simple bit of validation if someone wants to get hacking into MW code. DMacks (talk) 18:32, 22 April 2019 (UTC)
(edit conflict) @DonFB: Curly quotes break all attribute values, they must not be used to enclose such values. This is not merely a MediaWiki restriction, it also applies to HTML, XHTML, XML, etc., etc. We must not introduce an inconsistency when everybody uses straight quotes universally. --Redrose64 🌹 (talk) 18:36, 22 April 2019 (UTC)
Hmm, ok. I wonder then if MediaWiki could provide a specific error message, rather than the generic "invoked but never defined". Something like: "Use straight quotes, not curly quotes when defining 'name'". It took me long minutes to ascertain the problem in the article, though from now, I'll be able to more quickly diagnose, but I wonder how many other editors, now or later, may spend too much time searching for the error when the text appears to be correct (or fixing "dozens of these" if they keep getting added). Just out of curiosity, where the heck do curly quotes come from if one is using a standard keyboard? DonFB (talk) 19:15, 22 April 2019 (UTC)
For someone with awb, there are about 1100 articles with <ref name=[“”]... (I have my awb currently occupied or I would fix these)
Curly quotes are an allowed character in reference names so <ref name=“Rpt” /> works if the definition also says “Rpt”, at least if the name has no spaces or other characters which require straight quotes around the ref name. All curly quotes should still be changed to straight quotes to avoid confusion and future errors. The error message Cite error: The named reference “Rpt” was invoked but never defined (see the help page) is made by MediaWiki:Cite error references no text. We could check the parameter name for wrong quote characters and produce a special error message but I'm not sure it's worth it. PrimeHunter (talk) 20:14, 22 April 2019 (UTC)
Even if it's "allowed", it's going to be weird and confusing. Also, I suspect that it'll get normalized to name="“Rpt”" the next time VisualEditor touches it, because theoretically all ref names are supposed to have straight double quotes around them. Whatamidoing (WMF) (talk) 22:05, 22 April 2019 (UTC)
"theoretically all ref names are supposed to have straight double quotes around them" - Why is that? I've always tried to avoid using names that would require quotes. Help:Footnotes says that quotes are optional if you're only using printable ascii (with a few exceptions), and most examples on that page don't use quotes either. rchard2scout (talk) 10:30, 23 April 2019 (UTC)
I agree with rchard2scout's Help:Footnotes observation; in my experience quotes are not needed for a named reference. Also when I use a reference name it seems to be required that there be no blank spaces within that name. --Ancheta Wis (talk | contribs)10:53, 23 April 2019 (UTC)
Because you do not think quotes are necessary, when I use a reference name it seems to be required that there be no blank spaces within that name is true. If you used quotes, you can name the <ref> anything you please, including spaces. --Izno (talk) 14:19, 23 April 2019 (UTC)
Since spaces delimit attributes, it is a universal requirement that whenever spaces occur within an attribute's value, there must be a pair of delimiters for that value. The character used for that purpose may be double straight quotes, or single straight apostrophes. --Redrose64 🌹 (talk) 16:04, 23 April 2019 (UTC)
AIUI Cite.php expects double-quotes, and when they're not present in the wikitext page, then the parser inserts them before processing the page. So one way or another, there will be quotes in the end. Omitting them from the wikitext page is basically a harmless personal aesthetic preference (well, you could argue that it's not quite harmless because it adds a very tiny fraction of a second to the parsing time, but if that ever turns into a problem, Ops will tell us). Whatamidoing (WMF) (talk) 17:48, 23 April 2019 (UTC)
There is a practical benefit to this exercise. There are 13 refs here and no error messages. Then comes this edit by Tom.Reding (talk·contribs) which straightened up the quotes and which now shows an error, which in turn was fixed by this bot edit - and the article now shows 14 refs and no error. So curly quotes were causing a silent problem: basically, <ref name=“eng time” /> was being treated as if it were <ref name=“eng /> with an extra unrecognised attribute, time”. --Redrose64 🌹 (talk) 16:19, 23 April 2019 (UTC)
PrimeHunter said above that We could check the parameter name for wrong quote characters and produce a special error message but I'm not sure it's worth it. I'm not sure it's worth it either and don't have the software expertise to find out, but that's my request: modify the software so that it produces an Error message in Preview that says something like: "Curly quote marks not allowed; use Straight quote marks." DonFB (talk) 21:11, 23 April 2019 (UTC)
Somewhere in the middle of this page (Wikipedia:Edit filter/False positives/Archive 18), there's a coding issue, most likely HTML, that is causing green text to appear in about half of the page. I attempted to put </font> tags in a few places, but to no avail. Any assistance in the matter to resolve this is appreciated. Steel1943 (talk) 01:21, 25 April 2019 (UTC)
"View" button replaced all the action buttons at the top of pages
Something has happened to the buttons at the top of article pages - and I mean it happened just within the past few minutes. Instead of buttons for “edit”, “history”, and “watch”, I now have a single button, “Views”, with a dropdown menu with those options. There isn’t even a star at the top of the page to tell me whether I have watched that page or not. What happened? and is there a way to reverse it? -- MelanieN (talk) 23:09, 24 April 2019 (UTC)
Thanks for responding. I use Vector. And I haven't changed a thing since I started editing this morning, at which point everything was normal. The above happened to all pages - article, article talk, user, user talk - within the last hour or two. -- MelanieN (talk) 23:34, 24 April 2019 (UTC)
@MelanieN: adding ?safemode=1 to the URL - it should disable userscripts and css, as well as gadgets and some other features. Does the problem go away? --DannyS712 (talk) 23:37, 24 April 2019 (UTC)
Yes, that brought back the regular action buttons for this page; not for any other pages. The Twinkle button disappeared. -- MelanieN (talk) 23:45, 24 April 2019 (UTC)
@MelanieN: The twinkle button should go away when you do that. So, if the problem went away, the issue is a user-side issue (not the server/software). Did you make any recent changes to your gadgets/beta features/preferences? --DannyS712 (talk) 23:47, 24 April 2019 (UTC)
No, I haven't even opened my preferences today as far as I can remember. Would this be under Appearance or where? -- MelanieN (talk) 23:55, 24 April 2019 (UTC)
@MelanieN: Appearance, gadgets, beta, I'm just guessing. As far as I can tell, you haven't changed your personal JS in a while, nor have the JS files that you automatically load been changed. --DannyS712 (talk) 23:56, 24 April 2019 (UTC)
Well, under Appearance: next to Vector which is checked, Preview is blue, Custom CSS is red, and Custom Javascript is blue. (Sorry to be so literal, I am not a techy person.) Are you able to look at my preferences, or is that something only I can do? -- MelanieN (talk) 00:03, 25 April 2019 (UTC)
@MelanieN: Its something only you can do, but those don't seem to be the cause. Having imported your vector.js as well as the js and css for all user groups, I can still see "edit" buttons. However, based on your description in appears that the p-views object, which controls the list of "edit", "history", "watch", etc, changed its class from vectorTabs to vectorMenu. To debug this, can you
Open the "inspect element" view (ctrl-shift-I in chrome)
Navigate the element structure to
body -> div (mw-navigation) -> div (mw-head) -> div (right-navigation)
I just noticed another change: the Wikilove button is missing. I noticed that just now because the "Enable showing appreciation for other users with the WikiLove tab", in the Editing section of Preferences, is still checked. -- MelanieN (talk) 00:11, 25 April 2019 (UTC)
Unfortunately, I have to go out for a few hours. If someone else solves, great. If not, I'll try to help when I'm back. --DannyS712 (talk) 00:16, 25 April 2019 (UTC)
Just tried it both places. Nothing happened. I use a Mac; maybe that control-shift-1 option operation is specific for Windows? (I wondered because you mentioned right-click which is a Windows thing, not a Mac thing.) Nothing urgent here, this can be explored at your or anyone else's convenience. -- MelanieN (talk) 00:23, 25 April 2019 (UTC)
BTW I have been wondering if I accidentally changed something in my preferences, but I can't have, because I would have been alerted to click a "save" or "publish changes" or some such button before leaving the page, so I would have been aware of it. -- MelanieN (talk) 00:27, 25 April 2019 (UTC)
Things were normal using Safari, but that was my alternate account. I'll log off from Chrome and log on using Safari and see what happens. -- MelanieN (talk) 00:46, 25 April 2019 (UTC)
I am now using Safari with my main account, and the buttons at the top of the page are normal. It must be a Chrome-specific thing. -- MelanieN (talk) 00:49, 25 April 2019 (UTC)
Wow, looks like that fixed it! (Didn't need to mess with the vector.js.) Thank you very much, xaosflux and all of you! -- MelanieN (talk) 01:05, 25 April 2019 (UTC)
@MelanieN: This is probably unrelated but these lines
don't belong in your common.css. If you want to use responseHelper, they should be in your common.js or vector.js (take your pick) instead. In any case they're likely causing your browser to barf on your CSS page so should at least be removed from there. I still have no idea what caused the original problem. Suffusion of Yellow (talk) 01:17, 25 April 2019 (UTC)
Yep, looks good! Depending on how your browser was interpreting the bad CSS before, your rollback links may have all just disappeared. (That's what should have been happening all along, but the offending lines above may have prevented that). If you didn't want that to happen, remove the last three lines as well. Suffusion of Yellow (talk) 01:36, 25 April 2019 (UTC)
Yes, I did have rollback links disabled. I hate rollback, but as an admin I can't refuse it. So I made it invisible. -- MelanieN (talk) 01:40, 25 April 2019 (UTC)
Yes, thanks, Danny, the problem has been solved! Turned out it was related to Chrome somehow, and what worked was cleaning out all caches and cookies and restarting. A slightly more elaborate version of what I call the Microsoft Solution (aka "did you try turning it off and on again?"). Nobody has any idea what caused the problem in the first place but at least it is solved. Thanks for your help! -- MelanieN (talk) 04:54, 25 April 2019 (UTC)
The second of the two tq2 templates added in this edit of mine contains a numbered list. Despite my having followed the guidance on the template's usage page (AFAICT), the numbered list is not rendered as though part of the quote.
With both Chrome and Firefox, I see a stray bullet on the indented item in the first list, but not in the second. That stray bullet seems to sometimes manifest in rendered wikitext and sometimes not. I've noticed this for years and have worked around it by using a colon instead of an asterisk for all but the final indent in unordered lists, but I've not asked about it.
The problem is that a sublist needs to be part of an item of its parent list. Compare the following different wikitexts:
*[[Abortion debate]]
*[[Category:Abortion by country]]
**[[Philosophical aspects of the abortion debate]]
*[[Abortion debate]]
*[[:Category:Abortion by country]]
**[[Philosophical aspects of the abortion debate]]
The first one is as it is in the article, the second as you used it here. In the first one, the category link doesn't render in the article (it categorizes the article instead), which means the sublist is inserted in an empty item in the parent list, which renders as a stray bullet.
Note Wtmitchell didn't use that colon in his post here. The colon was added by a bot fixing the accidental category link on this discussion page. That said, the proposed solution is also what I'd recommend: either add the colon so it produces a link in the list or remove the category from the list, depending on what's intended. Anomie⚔11:41, 23 April 2019 (UTC)
Whenever somebody makes an edit to the infobox using the visual editor, it not only adds a bunch of unnecessary spacing, it also adds a bunch of unnecessary/unused fields, and it did not used to do this, which is why I've had the visual editor turned off for a long time. I only turned it on to report this since I've started seeing issues appear a little more often from other editors using it.
Using the visual editor here, all I am changing is the audio format parameter from [[Stereo]] to Test, but you can see that once the edit is published, that is not the only thing that was changed. Here in the source editor, I make the exact same edit, changing the exact same thing, and it only changes exactly what I wanted changed: [[Stereo]] -> Test. Amaury (talk | contribs) 17:21, 25 April 2019 (UTC)
Please read the comments on Phabricator. It maybe related to something in TemplateData of the infobox template or the VE itself. I don't use VE at all and neither familiar with its TemplateData stuff. – Ammarpad (talk) 19:08, 25 April 2019 (UTC)
Amaury, this is happening because this edit (and several others that day) told Parsoid to add all that extra white space and to insert those ("suggested") fields. If you don't like it, then you can change the TemplateData to make all of them use the formatting style that you prefer. Whatamidoing (WMF) (talk) 00:45, 26 April 2019 (UTC)
Many articles appear to transclude themselves, but why?
/** hejiraYearFix
*
* Description: It checks the hejira years and convert all to Gregorian. It is helpful when working on hejira years or you working on persian articles
*
*/
function hejiraYearFix(){
var txt = document.getElementById("wpTextbox1").value;
var res = txt.replace(/\b\d{4}\b/g,function(m){
return parseInt(m)+621});
document.getElementById("wpTextbox1").innerHTML = res;
}
window.hejiraYearFix = hejiraYearFix;
There will be changes to Wikidata's database. If you know what this means, then this will probably affect you:
If you directly query the Labs database replicas for anything, then you need to update your code. The Wikidata development team will drop the wb_terms table from the database in favor of a new optimized schema on May 29th.
I don't have time to read that in detail at the moment but it seems to be an attempt to address a very worthwhile issue, namely how can templates and modules be shared between Wikipedia projects. It appears to involve a bot that, if certain conditions are met, will overwrite a local copy of a template/module with a central copy maintained at mediawiki.org. That might work for some small Wikipedias but there would be a bunch of problems. For example, see the deletion notice at Module:Cycling race (which is updated from d:Module:Cycling race). Or, see Module:Date and the different c:Module:Date. Or, Module:Convert/text and bn:Module:Convert/text. Johnuniq (talk) 11:09, 25 April 2019 (UTC)
I don't think those are problems. First, the system is completely opt-in, the bot will only do work if you link the local template/module to the mediawiki.org origin via Wikidata sitelinks. Also, the bot will only update local pages if they're exactly identical to a former version of the origin page. This means local changes won't ever be overwritten. All in all, this certainly looks like it could work. rchard2scout (talk) 15:03, 25 April 2019 (UTC)
... the way [Module:Cycling race] is coded is atrocious to me: lots of dead code, global variables, a wiki variable that always returns the same thing, duplicate code everywhere, and i18n for other languages. * Pppery *has returned 19:25, 16 April 2019 (UTC)
Up to a few days ago, I was able to MOVE categories using the More/MOVE button in my edit session. Now the More/Move button has disappeared and I cannot correct minor mistakes, etc. It still appears when I am editing articles. What went wrong here? Thanks Hmains (talk) 19:14, 27 April 2019 (UTC)
@Pppery, Hmains, and Jevansen: such a policy should be developed - c.f. Special:Permalink/893297167#User:Jevansen. The current difference in maving pages vs categories is that someone can execute uncontroversial page moves themselves, but category moves are generally sent to speedy CfD. If all category moves should be done via CfD / CfD(s), then I'm not sure why page movers need the right, and if there are exceptions, they should be documented and agreed upon. --DannyS712 (talk) 19:42, 27 April 2019 (UTC)
It's actually the same revisions being linked from both contributions pages. When querying for a registered user, Special:Contributions looks up the revisions by user ID. For an unregistered user (including IP users), it looks up the revisions by the user name field on the revision instead. If you look at the corresponding API request you'll find that the userid on those revisions is 108476, which is the ID for Thewayforward.
BTW, MediaWiki is being changed to remove those denormalized user name fields from the database in favor of assigning an "actor" ID to all names, registered and unregistered. Once the configuration here is changed to use the actor ID fields rather than the user ID/name fields, Special:Contributions/Wonderfool won't show them anymore since the actor ID assigned to those revisions follows the user ID rather than the name. I don't know when exactly that configuration will be changed here, we're waiting for fixes for some slow queries that turned up when we enabled it on other wikis before we turn it on here. Anomie⚔23:03, 27 April 2019 (UTC)
Indeed. The reason those edits appear in that user's contribs is because they were deleted when he was renamed then subsequently undeleted, and deleted edits used to not be transferred over with renames. I thought those sorts of situations had already been cleaned up, but the script mentioned above will fix them once and for all. Maybe the original script didn't deal well with edits that were deleted before Wikipedia was upgraded to MediaWiki 1.5, when deleted revisions started getting revision IDs; revisions deleted before then would get new revision IDs when they were undeleted. Graham8700:30, 28 April 2019 (UTC)
I uploaded it to portray a character in a film. By itself that is fine. However I have found a photo that shows the two actresses that portray the character, one in film and the other in TV. I have uploaded this 2 in 1 photo which makes the one needing deleting redundant and means I don't need a second photo.
Adding ?uselang=... (or &uselang=...) to URLs is a neat trick for transiently seeing how things look in another language (rather than making a more permanent change in Special:Preferences). It's also the only way to see the Mediawiki: names of user interface messages (uselang=qxx). However, this URL submission parameter does not get propagated into links in the resulting page: any subsequent click returns to the Special:Preferences language. Is there a way to make uselang more sticky? That would be useful as an editor when previewing edits that behave differently for different languages. And it's the only way (that I can think of) to find the Mediawiki names of strings that are part of the preview and other toolbox link responses. For example, I would like to be able to click on [Preview] and learn that the "This is only a preview; your changes have not yet been saved!" message is apparently supplied by MediaWiki:Previewnote. DMacks (talk) 07:54, 25 April 2019 (UTC)
useskin also does not persist. I would be interested in a Javascript gadget that persisted the temporary option(s) until removed from the URL and resubmitted to the browser. There is a similar task on Phabricator. --Izno (talk) 13:32, 25 April 2019 (UTC)
I believe that ?setlang=... and ?setskin=... are the things to use when you want it to persist. Then switch it back when you're done. NB that I don't know how this would interact with GlobalPreferences or various user scripts. Whatamidoing (WMF) (talk) 00:35, 26 April 2019 (UTC)
@Whatamidoing (WMF): You're right, ?setlang=... makes it to persist, I never knew about that. But unfortunately it only works for valid content languages. ?setlang=fr works, but ?setlang=qqx doesn't; and it's the latter that we want here since ?setlang=fr is just duplication of what alreay exists in preferences. – Ammarpad (talk) 05:12, 29 April 2019 (UTC)
I just tried setskin and that did not change the skin (my skin is a global preference though). Did it work for you in any regard? --Izno (talk) 13:32, 26 April 2019 (UTC)
Login to Wikipedia from a device you have not recently used
Someone (probably you) recently logged in to your account from a new device. If this was you, then you can disregard this message. If it wasn't you, then it's recommended that you change your password, and check your account activity.
-- It would be really helpful if such email gives more information about the activity (IP (or at least city, country), device details). I got the last message 2 minutes ago. I feel confused. For example today I was reading Wikipedia from mobile (account has been logged in), but I can not understand if it is the same activity. Regards. --Titodutta (talk) 12:39, 29 April 2019 (UTC)
Titodutta, this is phab:T174388. It comes with some privacy constraints, as well as quite a few limitations that need to be tackled. Because of that it has not received as high a priority as some other things. —TheDJ (talk • contribs) 14:01, 29 April 2019 (UTC)
@Mitchumch: There's a strong chance your report won't be generated this month either :( We've made some changes and I think things will go smoother next month. I estimate it'd be mid-March by the time the bot gets to Civil Rights Movement. However in the meantime, I wanted to let you know you can get (almost) the same data using Massviews. The difference from it and the popular pages report is that it doesn't include redirects to the articles. In most cases this wouldn't change the rankings. To use Massviews, plug in the category for the WikiProject articles using "Category" as the source, and check "Include all subcategories" and "Use subject page instead of talk page". See [56] for an example. Hope this helps, MusikAnimal (WMF) (talk) 18:41, 29 April 2019 (UTC)
Actually I can just run the report for Civil Rights Movement directly. I went ahead and did this, so you now have results for March. Here's the Massviews results, for comparison. As you can see they're fairly close, with the ordering for the top 15 being the same. At any rate, apologies for the long delay! Hopefully we want have any issues next month. Regards, MusikAnimal (WMF) (talk) 19:20, 29 April 2019 (UTC)
Even more bizarrely, if you go to one of the pages, say [57], copy the link without changing it, and paste it into a new tab, you'll also receive the same message. (Additionally, when I preview, the link I posted right in this message works fine, but same again, copy-pasting to a new tab fails and displays the error.) I suspect something on the WMF tools server is checking if the link was referred from Wikipedia, and rejects the request otherwise, but it is indeed rather odd behavior. It may be intended to prevent rogue sites from using the tools server and its resources to display OSM links? SeraphimbladeTalk to me02:22, 28 April 2019 (UTC)
Confirmed to be referrer. I used a referrer spoofer to always send Labs this page as the referring URL, and it then works fine to either pop the link into a new tab or change it as Nyttend did. So the question is if this is a bug or by design. If it is by design, it's poorly designed though—with this being the case, even saving the link as a bookmark will cause the "Don't disturb Wikipedia" to appear when the bookmark is used, since the referrer would then be null. SeraphimbladeTalk to me03:33, 28 April 2019 (UTC)
Turns out that it's not just the English Wikipedia; when I dumped the link into the de:wp sandbox and clicked it, I got the desired map. But this link works properly only with Wikipedia, not all WMF sites — I dumped a link into the Commons sandbox and clicked it, and the error message appeared. For future reference, why would a request be treated differently based on the referring URL? I can imagine reasons you'd want to know where someone found a link (e.g. a site's admin wants to learn what other places are driving his traffic), but not reasons why you'd accept requests referred by one website but not requests referred by another or requests without a referring website. Nyttend (talk) 22:36, 28 April 2019 (UTC)
I'd tend to classify it as a bug and think it should be reported as such. Aside from bookmarking, there are certainly other legitimate use cases, such as if someone were to email the OSM link to a group they're planning visits to NRHP locations in an area with. Everyone who receives the email will receive the big "Don't disturb Wikipedia" page when they click on that link, and of course they're not disturbing it at all. If it is intended for some kind of security or prevention of misuse, it needs to be (re)designed to prevent only that and allow legitimate uses. SeraphimbladeTalk to me23:20, 28 April 2019 (UTC)
PrimeHunter, that doesn't look like quite the same issue, that was an issue with resource overloading and the service shutting down. The service is running now (else it wouldn't work from Wikipedia either), and that bug ticket doesn't mention anything about blocking or denying requests by referrer. So, same tool, but I think a separate issue. (As Nyttend's earlier tests confirmed, requests referred from Commons are being blocked, so that's why Commons users were seeing the error page.) I'll see if this issue is already on a ticket and if not file one. SeraphimbladeTalk to me14:26, 29 April 2019 (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 Wikipedia app for Android now invites users to add Wikidata descriptions to Wikidata objects that have Wikipedia articles but no Wikidata descriptions. It will only invite users who have added a number of Wikidata descriptions in the app without being reverted. This is to avoid spam and bad edits. [58][59]
Problems
Tech News was late last week because of a MassMessage bug. Other newsletters had the same problem. [60]
Changes later this week
You will see when you last refreshed the recent changes page. This is so you can see how recent the changes are. [61]
When you write a comment in Structured Discussions but have not posted it yet your web browser will save it in local storage instead of session storage. This means you do not lose them even if you close your web browser. Structured Discussions used to be called Flow. [62]
You will be able to turn off milestone notifications. Milestone notifications congratulate you when you have made certain numbers of edits. [63]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 April. It will be on non-Wikipedia wikis and some Wikipedias from 1 May. It will be on all wikis from 2 May (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 1 May at 15:00 (UTC). See how to join.
Future changes
The Wikidata wb_terms table will be dropped. This will affect some Wikidata tools. They need to be updated. The table has become too big which is causing problems. This will happen on 29 May. You can read more. You can ask for help if you need it.
Wikimedia wikis will soon use a token when you log out. This changes how the API works. Some tools might need to be updated. [64]
Certain tables in certain articles look fine in my desktop browser (Firefox 66.0.3 running under macOS Mojave v. 10.14.4) but in my phone's browser (iOS Safari v. 12.2) show an extra, empty column on the righthand side, which I cannot fix nor find the reason for. The articles and sections are:
It doesn't appear in the desktop view so it's probably the mobile view rendering causing the issue. --qedk (t桜c)10:07, 1 May 2019 (UTC)
I can see it on Chrome if I use devtools to emulate a mobile device. For some reaon the wikitable class has a border: 1px solid #54595d;. This border doesn't render for me when using m.wikipedia or when using ?useskin=minerva, but it does show up when using the mobile device emulation. It also show up my Android phone (Android 9, Chrome 73). rchard2scout (talk) 10:37, 1 May 2019 (UTC)
Rchard2scout, oh, that's not an extra column. It's because all tables are 100% wide on mobile and you are seeing the background of the table because the columns are so narrow they do not take up the full width of the table. —TheDJ (talk • contribs) 13:04, 1 May 2019 (UTC)
URL shortener
Hi, I pasted [65] into the WikiMedia shortener page [66] and it generated "w.wiki/3X9". when I placed 2 brackets (one before and one after "w.wiki/3X9", it does not generate a link. Kindly advise. CASSIOPEIA(talk)05:34, 1 May 2019 (UTC)
Because they are not intended for links at Wikipedia. They are for external (outside Wikipedia) use. Johnuniq (talk) 05:45, 1 May 2019 (UTC)
@Johnuniq and Eman235: thanks guys for the info. Is that anywhere we could get WikiMedia to display "https://" when it generates the shortener? If it is as the present form, it doesnt make sense to use it, better still, to get add in one of the feature in Wikipedia for shorter link. CASSIOPEIA(talk)05:49, 1 May 2019 (UTC)
Is it possible for the widths of the TFA/DYK and ITN/OTD sections of the Main Page to be automatically adjusted based on the length of the content in the two columns? For example, if the TFA and DYK sections on a particular day are particularly short, can the width of the column containing TFA and DYK be narrowed? Currently, TFA/DYK is set to 55% and ITN/OTD set to 45%, which can result in a lopsided main page depending on content length. feminist (talk) 10:13, 1 May 2019 (UTC)
One fundamental problem is how the length is calculated. Each of the first five boxes contains an image and some text. The image sizes are nominally fixed, but the browser zoom level can alter that. The font size of the text is also affected by zoom level but also by several other factors, hence the length occupied by the text is even less calculable. --Redrose64 🌹 (talk) 13:32, 1 May 2019 (UTC)
I'm asking this question because there have recently been many instances where admins have added an old hook to the DYK section or removed the oldest item from ITN to maintain main page balance. To me at least, it's much more effective to adjust the size of the container than to adjust its contents. I take it that the main effect of TemplateStyles for the main page is responsive design (i.e. using only one column when the screen is narrow)? In that case it doesn't alleviate the concerns raised by DYK admins. The only difference would be, instead of editing Main Page to adjust column width, an admin now has to edit Template:Main Page/styles.css. feminist (talk) 16:03, 1 May 2019 (UTC)
Every so often, I accidentally log out by means of a erroneous finger tap on a mobile device. What's really annoying is that it also logs me out of my desktop. Is there some way to make logout only apply to the single session? Even better, is there some way to make logout require confirmation, so a single bad finger tap doesn't cause it to happen? This is particularly annoying because I have 2FA enabled, and don't always have my phone with me to generate a new token. -- RoySmith(talk)12:25, 1 May 2019 (UTC)
The act of logging out invalidates all login cookies that have your login ID in them, no matter which device they were set on. The logout action is triggered by a client but is preformed entirely on the servers; when a client that believes itself to be logged in next accesses Wikipedia and sends back its freshest login cookie, that will not be recognised by the servers and the client will be served a page for a logged-out user. This is a useful feature: if you log in on a machine that is not your own, and forget to log out there, you merely need to go to any machine, log in and explicitly log out again. Similarly, if you believe that somebody else has gained access to your account (possibly because you disclosed your password), you should immediately change your password, then log out. Changing your password won't kill their cookie, but explicitly logging out will do so. --Redrose64 🌹 (talk) 13:20, 1 May 2019 (UTC)
Hmmm. I was actually expecting the answer to be, "You dummy, you must have enabled this in preferences and then forgot what option it was". It's, um, unexpected that this is "working as designed". I agree that the ability to remotely revoke all your login cookies across all sessions is a useful feature, but it's crazy that it's the default behavior. Thanks for the explanation. I've commented on the two phab tickets. -- RoySmith(talk)16:23, 1 May 2019 (UTC)
@DannyS712: After I tried it it showed me it's "restricted to top 50 pages only" so it's useless. As I said I would like to know just which pages I'm currently watching. Eurohunter (talk) 23:46, 1 May 2019 (UTC)
<thead>, <tbody>, and <tfoot> are treated as fostered content lint errors instead of valid markup. This happens only in Wikipedia, not in real HTML. What is going on? —Anomalocaris (talk) 04:18, 2 May 2019 (UTC)
See Help:Table. Do a find on the page for "thead". You will see the thead, tbody, tfoot, colgroup, and col elements are currently not supported in MediaWiki, as of April 2017. That means if you put a thead tag in an HTML table, it will be processed as stray (fostered) text. See T6740 for a long-standing feature request. – Jonesey95 (talk) 06:39, 2 May 2019 (UTC)
@Mitchumch: Duplicate drafts aren't exactly an issue, although if one is copied from the other, it is a cause of concern (lack of attribution, copyright). If duplicated content exists in mainspace, it can be A3ed, and/or merged, but nothing like that applies to draftspace, for obvious reasons, as two people might be working on same topics separately. --qedk (t桜c)19:58, 2 May 2019 (UTC)
I have created a hangout to improve collaboration and coordination among editors of various wiki projects. I would like to invite you as well. Please share your email to pankajjainmr@gmail.com to join. Thanks Capankajsmilyo(Talk | Infobox assistance)16:30, 29 April 2019 (UTC)
@Capankajsmilyo: This sounds like you are trying to create an off-wiki cabal. Please note that I disapprove of such secret societies; the point about Wikipedia is that it is all-inclusive, therefore, discussion about Wikipedia matters should take place on-wiki, in full view of anybody who may be concerned. --Redrose64 🌹 (talk) 20:08, 29 April 2019 (UTC)
As for a secret society, it would seem odd to advertise such a thing on-wiki. I have participated in discussion on WP topics via Facebook, Quora, Slack, and G+. The main reason for off-wiki was, better software. Our software is made for collaborative editing of documents; it serves that purpose with a modicum of competence but is dreadfully clumsy for operating a forum. Oh, I've also discussed WP matters in E-mail echo groups, and in past years I was summoned to several closed meetings in a basement. The main topic there was, what should we do at our open meetings in the next few months? My preference would be to do much less discussing off-wiki. However, as I say, primarily it's because our software stinks, and secondarily, there are some (few) matters that work better with some degree of confidentiality. Jim.henderson (talk) 21:18, 29 April 2019 (UTC)
I have tried invite links before. But some editors are not comfortable in joining hangouts whose links are public. This way is more comfortable to them as only wiki editors will join. Capankajsmilyo(Talk | Infobox assistance)07:13, 30 April 2019 (UTC)
As far as secret society is considered, you can always join and police the matters being discussed. You won't be stopped from making those discussions public on Wikipedia (if you can find a good place to discuss multi-wiki topics and sufficient number of editors are aware of that system). Getting to know the multi-wiki system was not easy for me too. And still I know almost nothing. And there's a huge gap between how communities work and form policies. It's like different worlds altogether. I don't think that's a good experience for a reader to switch from English to Hindi and read two different stories about a person. Further, if a person from Malayalam wiki wants help in tech from enwiki, he will have to learn enwiki culture before he can do anything. Capankajsmilyo(Talk | Infobox assistance)07:21, 30 April 2019 (UTC)
On a related point, I have been collecting types of off-wiki and on-wiki communication tools at mw:Talk pages consultation 2019/Tools in use. Please add any that you find are missing. I'd love a few examples, including some public links, but generally the catalogs are kept on Meta. For example, Jim.henderson mentioned "E-mail echo groups", and I'm not sure if those are different from mailing lists. (We've got the "meetings in a basement"; face-to-face meetings are primary communication channels for many groups, including the core community at the German Wikipedia.) Whatamidoing (WMF) (talk) 17:55, 3 May 2019 (UTC)
Finding deleted article
Per the result of a query ticket:2019050210005769, I'm trying to track down a deleted page about the Hartford Police Department.
I have a note to myself that using Special:Undelete and appending "&fuzzy=1" will do a fuzzy search and find close matches, but I'm not seeing documentation.
Why not just create a new article? Why do we need to get the text from such a long-deleted article? It would seem to me that just starting from scratch would be less trouble. --Jayron3218:27, 2 May 2019 (UTC)
Graham87, Thanks for looking. I've seen a lot of articles about the police departments of modest sized cities, so I was surprised that there was not one for Hartford, especially given that someone thought they had seen it. S Philbrick(Talk)20:22, 3 May 2019 (UTC)
I couldn't even find deleted drafts or userpages/subpages that were relevant. My guess is that they are actually referring to the "Police" section of the article on the city, which was both shortened and aggregated into the "Government" section in the last year. Someguy1221 (talk) 21:36, 3 May 2019 (UTC)
Template parameter in wikitext
I expect the first of the following results, but not the others:
({{{1}}}) → ({{{1}}})
({{{1|}}}) → ()
({{{1|hello}}}) → (hello)
Of course that's how it is supposed to work when a template is expanded, but has it always worked like that in bare wikitext? Johnuniq (talk) 10:17, 3 May 2019 (UTC)
This is always how this has worked. The reason we don't often see this on the template page itself is because those are often includeonly/onlyincluded (and I hate that we have keywords like those two). --Izno (talk) 13:14, 3 May 2019 (UTC)
Working as designed. Templates are merely normal pages that have their own namespace. They have no special syntax, unlike modules or JSON pages. --Redrose64 🌹 (talk) 13:27, 3 May 2019 (UTC)
The only thing special is that they don't need a namespace qualifier to be transcluded probably. --qedk (t桜c)14:41, 3 May 2019 (UTC)
Thanks, it's the lack of specialness about template space which is key, I guess. I often preview stuff while investigating things and sometimes forget to replace template parameters with text I'm testing so I see the parameter syntax in the first case above. I thought I had seen it with the other cases as well but it sounds like I'm mistaken. Johnuniq (talk) 23:48, 3 May 2019 (UTC)
Ah, of course, I just previewed the following in a sandbox and each of the above shows "(first parameter)". {{:Wikipedia:Village pump (technical)|first parameter}} Johnuniq (talk) 23:52, 3 May 2019 (UTC)
SineBot down again
I noticed SineBot (talk·contribs) is down again. I have dropped a note on Slakr's talk page, and I suspect as soon as he reads it it'll be rebooted and all will be well. However, I'm not happy about (IMHO) essential services being run by external parties on closed source code. While Slakr is free to distribute his code under whatever licence he likes, it means we end up with one person being indispensable, with no possibility of the bot being transferred to somebody who's around more often, or giving a few more devs charge of it so the uptime is improved. I'm sure Richard Stallman would have harsh words to say to Slakr on this, and rewrite the bot in Scheme in an afternoon, but on a more pragmatic note, is there any appetite for doing an open source rewrite? Ritchie333(talk)(cont)11:31, 3 May 2019 (UTC)
It's always to good for bots to have two botops in opposing timezones so that things can get back on track asap. You can try wikitech IRC, I think (correct me if I am wrong) the admins can restart services as well, that would be the fastest way. --qedk (t桜c)15:39, 3 May 2019 (UTC)
Right, I forgot that closed-source aspect of SineBot. Although, I did intend for a general answer as well, since Ritchie said he doesn't like essential services being run externally. The VPS is not exactly the easiest (or reliable) for botops to use, so I can understand why someone would not. ¯\_(ツ)_/¯ But in this case, maybe it would be good to have atleast another botop, even if just to restart services. --qedk (t桜c)15:46, 3 May 2019 (UTC)
I can't believe I'm not sure where to post this after all these years. I also don't know where to post this if people say that this issue needs to be seen by the relevant devs or needs further discussion.
I want to know why has the development of the mobile browser view been ignored so much in favour of the app, given that I would reckon (if someone knows hard figures, provide them) majority of our readers view the former. The app, while great, will probably be used by a smaller niche group. I recently tried it out and as actually outraged that it was so good compared to the mobile view which I been using. I would still prefer to continue using mobile view despite all this. Ugog Nizdast (talk) 16:47, 28 April 2019 (UTC)
The reading team has been working on revamping mobile web editing experience for sometime now. Part of the improvement has been already deployed on some wikipedias as a beta. You can read more details about the project at mw:Reading/Web/Advanced mobile contributions and you can leave feedback for them. So mobile web editing is not completely ignored. – Ammarpad (talk) 17:05, 28 April 2019 (UTC)
@TheDJ: a fair question. I'm not into advanced UX but I have one basic UI gripe that's on my mind since ages: the lack of an easy way to scroll through the Table of Contents for any decently sized article. Try it on mobile view, it's horrible. The app, however, has that nice scroll bar: which is persistently present as you read and can collapse, showing the relevant (sub)sections for even quickly jumping to. You won't get lost in an article wondering how to get back to a said section that was on your mind.
I'm browsing through the links given above to see if this has been pointed out or is a long term plan. To me, this seems like a problem most would love solved. Ugog Nizdast (talk) 12:25, 29 April 2019 (UTC)
In re "a problem most would love solved": I have sometimes wondered whether "most" of the core community members would care, or even notice, if the mobile site disappeared. The core community at the older Wikipedias are heavily invested in the desktop site. Half the world reads on the mobile site, but only a tiny percentage of highly active editors use it regularly (including me: I'm a laptop-only editor). Thank you for volunteering to give a voice to the concerns that regular users have. That team will really appreciate it. And if you ever want to try out the mobile visual editor, then feel free to talk to me about it. Whatamidoing (WMF) (talk) 17:47, 3 May 2019 (UTC)
Agree with you :) The only way I began to look at mobile viewing more seriously is when I took my indefinite Wikibreak...no longer being an editor but a reader. Of course, when I said most I was referring to the readers, not the community. Be well, Ugog Nizdast (talk) 05:44, 4 May 2019 (UTC)
After testing I've found the following:
If {{OSM Location map}} is used inside a section with a heading (any level), the map will appear as blank when viewed on mobile.
Templates in headings are rarely a good idea. Is there any reason that it can't be on the next line instead? --Redrose64 🌹 (talk) 16:46, 1 May 2019 (UTC)
Ok, so for some reason the Graph:Chart template is making the OSM map displays correctly. The chart can be in any position and in any (sub)section of the article, or even outside of a section, as long as it is there somewhere. I'm going to test this with other template to see if it is only exclusive to Graph:Chart or not. Nehme1499 (talk) 21:06, 4 May 2019 (UTC)
I have no specific idea why, in mobile rendering, the "CD Blocks" OSM map comes out right, but the infobox (which is above the section header) comes out as an empty box labeled "Barast II". But (based on many years of programming) it sure looks a scoping problem. Likely an unbalanced terminator. One approach: copy that page to a sandbox, check that the problem displays, then start taking stuff out until the problem goes away. Tedious, but effective. ♦ J. Johnson (JJ) (talk) 22:22, 4 May 2019 (UTC)
@J. Johnson: On my mobile view the infobox in Barasat II comes up perfectly. I "solved" the problem by adding {{Graph:Chart||type=pie||width=0||height=0||x=0||y=0}} in any location in the article (Lebanese Football League, I added it underneath the external links section but I could have put it anywhere in the article). This solves the problem, though it seems like a "crude" way of doing it. Nehme1499 (talk) 22:50, 4 May 2019 (UTC)
Yes, also works for my sandbox. And {{Graph:Chart}} is so simple! Is the essential bit doing the safesubst? Or the css style? If I had the time I would start digging. Depending on where the problem comes from, could even come up with a minimal {fix.m} template. Alas, no time. ♦ J. Johnson (JJ) (talk) 23:17, 4 May 2019 (UTC)
Citoid/refToolbar does not work with ScienceDirect
When I change a short description, I don't see any trace of it in preview mode, although I have my preferences or whatever it is set, so that I see them when viewing articles. Is there something else I need to set to view them in Preview, or is this a sw change request? Mathglot (talk) 03:50, 5 May 2019 (UTC)
This is not currently supported, so you've to make a request. I'm not sure how feasible or useful that'd be, though. – Ammarpad (talk) 12:22, 5 May 2019 (UTC)
Populated places in Austria
A recent deletion discussion, Wikipedia:Templates_for_discussion/Log/2019_February_17#Template:Infobox_Town_AT, had the result of deleting a specialized infobox template for populated places in Austria, and replacing its uses with the standard {{Infobox settlement}}. However, the process of doing this has caused a major categorization fustercluck, which I need some input into how we can fix.
The problem is that the deleted template was violating WP:TEMPLATECAT, by taking entry fields from the infobox to artificially generate and transclude geographic categories for "[Type of populated place] in [Austrian state]" in lieu of those categories actually being directly declared on the articles themselves. But the replacement process did not properly account for this, and thus pulled a significant number of the affected articles entirely out of the Category:Populated places in Austria tree. I've caught well over 600 articles about populated places in Austria that got left completely uncategorized by the infobox replacement, and have had to be added to the uncategorized articles queue — and I have no way to even guess at how many other articles might have been pulled out of the Populated places in Austria tree and just haven't been detected as such because they still had other categories on them. I also have no way to even guess at what categories the pages might have been in before the replacement, since they were autogenerated by a deleted template and thus don't show up in the edit histories, so I also have no way to either restore the old category or figure out if some categories have been completely deleted because they got emptied out by all of this.
Again, I don't have any issue with the template replacement itself — but the process of replacement should have noticed and accounted for this issue at the time, because none of the rest of this ever should have happened at all. The replacement should never have left a single article decategorized, let alone 600 of them, and I'm struggling to identify how to fix it. It's possible that it may actually require at least a temporary restoration of the deleted template, so that we can check the edit histories of the affected articles to determine which categories disappeared from pages in the process, but I obviously don't want to do that arbitrarily — and even if the template were restored, the fact that it isn't transcluded anywhere anymore means that there wouldn't be anything in its "what links here" list to work with. I would somehow need to get a complete list of every article that transcluded that template while it existed, and/or a list of the complete contents of the Category:Populated places in Austria tree as of a time prior to the replacement/deletion process, but I also don't know if either of those things is even possible to generate.
I'm restraining my urge to smack anybody over the head with a baseball bat over this, but it should never have happened in the first place and template replacements need to take more care to ensure that nothing like this ever happens again. Ultimately, the deleted template should never have been used to artificially transclude its pages into categories, in lieu of actually applying those categories directly to the pages themselves, in the first place — but given that it was doing that, the people who undertook the replacement project should still have caught and dealt with it in the process.
It might be reasonable to construct a module which takes any place understood by an {{infobox settlement}} to be in Austria (requiring some string manipulation) to then categorize per the parameters of interest as translated to infobox settlement parameters. Subsequently to be replaced by categorizing on the pages-proper (using bot or otherwise) and removal of the module (i.e. the use of this would be a temporary fix). --Izno (talk) 01:45, 4 May 2019 (UTC)
I have a small suggestion. Will recreate the template -> Find the articles using this template using What Links Here -> Replacing this template with the required one -> Delete the template works? Adithyak1997 (talk) 08:00, 4 May 2019 (UTC)
Good idea. I've been able to at least temporarily resolve the problem, by running through each Austrian state's geo-stub category in AWB with skips for "does not include infobox_settlement" and "already includes 'Cities and towns in [State]' category" and then adding "Cities and towns in [State]" to pages AWB stopped on, and then crosschecking the complete contents of the repopulated Category:Populated places in Austria tree against the search string Zackmann gave me to generate a list of all Austrian places that were calling the current infobox template in order to catch any non-stub stragglers — so as of now, every Austrian place article has been recategorized at the state level at least. However, many (although not all) of the Austrian places that didn't get decategorized by this were and are actually subcategorized more specifically than their state, mainly by district within the state — so the dump report would still be useful, in the hopes of potentially identifying whether some or all of the articles I batched through last night were actually in more specific district categories before the changeover (and/or whether there are any other articles hiding in the weeds that still got missed for technical reasons). Thanks for the assistance with this, let's hope this works out. Bearcat (talk) 15:15, 4 May 2019 (UTC)
I'm wondering that too. There hasn't been a response to the request at all — and while I read Snaevar's request when I was informed of it, I didn't review the whole talk page at the time, but you're right, it was the first new request made there since 2011. It looks like a dead project, and dump reports apparently now have to be requested somewhere else. But where? I do not know. Bearcat (talk) 16:16, 5 May 2019 (UTC)
The deletion discussion on the template was initiated on February 17 of this year, and closed on February 25 with the replacement project starting after that. So I guess sometime during that week would be the best choice if possible — but if there aren't any dumps available within that week, then the last available date before the 17th would be the next best thing. Bearcat (talk) 16:32, 5 May 2019 (UTC)
In the category VIAF not on Wikidata, I opened 3 to 4 articles present in that category. But all of them were having VIAF IDs on Wikidata. When I clicked the Purge button, no change happened. Please confirm whether the category counts are correct or not. Adithyak1997 (talk) 18:05, 5 May 2019 (UTC)
Purge will update which categories are displayed on the page but will not update the category page. The category currently says there are 637 pages. Do you expect us to check all of them? None of the ten examples I checked had VIAF on Wikidata. When you post here, always include a link or example showing the reported issue if it's possible. ALWAYS. PrimeHunter (talk) 18:38, 5 May 2019 (UTC)
Should redirect pages have Authority control templates?
Most of the pages in this category are redirects. Should redirects have Authority control templates on them? (Not strictly a technical question, I know.) – Jonesey95 (talk) 20:49, 5 May 2019 (UTC)
Time to deprecate Foreign character warning boxes?
Perhaps it's time to deprecate most uses of those templates under Category:Foreign character warning boxes? The huge majority of systems nowadays should have no problem rendering Arabic, Cyrillic, Hebrew, Thai, etc. scripts by default. The templates for Chinese, Korean and Japanese have already been deleted via TfD.
Templates for rarer scripts should probably remain though. The question is which ones to keep. If the most widely supported scripts are identified, it shouldn't be a problem bringing them to TfD. --Paul_012 (talk) 09:56, 5 May 2019 (UTC)
I agree. There's only a couple dozen of them, they should probably be examined individually. For rare scripts that aren't widely supported, they can stay; for the widely supported scripts, they can be deleted through TfD. It'd be great if we could get an overview of which scripts are supported on which platforms - I imagine this would be useful for far more people, but a quick google didn't turn up anything. rchard2scout (talk) 11:01, 6 May 2019 (UTC)
This is because they've not been reviewed by a new page reviewer. Once they're reviewed, you'll be able to find them by Google search. – Ammarpad (talk) 04:31, 6 May 2019 (UTC)
No, don't. Editors who are here for promotional purposes are disproportionately more likely to ask this question and in doing so, attract the necessary admin attention. MER-C11:35, 6 May 2019 (UTC)
Should all templates have their documentation as a separate subpage?
I was recently told that some editors have been steadily working over the years to move the documentations of templates into separate /doc subpages. The intention apparently is to have all templates have their documentation be in a separate subpage. The justification appears to be based on the last paragraph of Wikipedia:Template documentation#Where to place it, which says:
Text that is on a template page itself adds to the amount of text that must be processed when displaying the template, which is limited for performance reasons. Placing the documentation in a transcludable subpage avoids this. MediaWiki developers, who create the program that the Wikimedia Foundation's wikis run on, have recommended this placement for this very reason.
Now, this indeed seems to suggest that a separate doc page is always good, but it's justified by a a link to a 2006 statement that seems to recommend it only for templates whose documentations are big and frequently edited. Nonetheless, does the reasoning really extend to all templates? Should we strive to always have the documentation be in a separate subpage, so that there's ultimately less load on the servers? – Uanfala (talk)22:02, 5 May 2019 (UTC)
@Uanfala: "server load" shouldn't be a concern here (as both /doc and direct documentation are noincluded anyway). One place to strongly encourage use of /doc pages is if the template is protected. And once a template gets "big" it is normally a good idea as well, but for small templates it doesn't really matter. — xaosfluxTalk22:31, 5 May 2019 (UTC)
I can't say that "the amount of text that must be processed" seems like a huge concern to me, and I note that there does not seem to be a pre-expand include size anymore as mentioned in the link from 2006 (possibly it was removed in rev:43835 in 2008?). More interesting is that having the documentation on a /doc subpage means that edits to the documentation don't trigger reparsing of every page transcluding the template, while editing documentation included on the template page itself does. Anomie⚔22:55, 5 May 2019 (UTC)
That's interesting. How significant is this extra load for reparsing the transcluding pages? I guess that should be negligible for a small template with 100 transclusions whose documentation gets edited once a month? At any rate, we should probably remove the quoted paragraph from Wikipedia:Template documentation#Where to place it, and if replace it with more up-to-date information about the performance aspect of things, we should be careful not to leave the impression that it's advisable to split out the documentation solely for performance reasons (especially in light of disadvantages to maintenance that having separate subpages entails). – Uanfala (talk)
Yes, you were more specific about those disadvantages on my talk page. And perhaps those, too, should be included in any policy or guideline that shapes the way editors see the need for separate /doc subpages for templates? It is a common misnomer that noincluded parts of a template's code should not be a concern, because while noincluded parts do not appear where a template is transluded, they will still cause reparsing of every transclusion of the template when edited. And even if there are relatively few transclusions of a template, none of us have a crystal ball to show us if and when an editor might see a template and increase its transclusions significantly. Since Uanfala has raised this concern, I find myself wondering if my work to separate documentation out of template code and onto its own, separate /doc subpage has been in vain? Paine Ellsworth, ed. put'r there14:36, 6 May 2019 (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
Special:Watchlist can show the wrong information. It does not always show which edits are read and which are unread. The developers are working on solving the problem. [67]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 May. It will be on non-Wikipedia wikis and some Wikipedias from 8 May. It will be on all wikis from 9 May (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 8 May at 15:00 (UTC). See how to join.