This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Hi, Not sure if it's just me but my thanks doesn't seem to be working?
I go to thank someone (it then says thanked as it should) but then when I thank someone else on the same page it doesn't do anything and then when I reload the page the edit I thanked no longer says "thanked" (I just have the option to rethank basically),
Thanks, –Davey2010Talk00:15, 20 February 2018 (UTC)[reply]
Davey, see if the thanks you tried to send are in your log. I don't know why it doesn't seem to work twice for you on the same page, but I do know that "thanked" reverting to "thank" when you come back to a page is an annoying issue that has irritated me for a while, but I've just kind of put up with it. If you want me to check if I get the same issue, reply to this, and I'll see if I can thank you for both edits from the page history. --Begoon01:13, 20 February 2018 (UTC)[reply]
Well, just to maybe add to the confusion, I thanked you both, from the page history, and each time I got the expected message, and "thank" said "thanked" for both edits on the page history after the second one. My log has 2 entries, one for MA, one for Davey... --Begoon01:35, 20 February 2018 (UTC)[reply]
Maybe you thanked before intermediate edits were made? Because that would mean Davey and I's edits are the most recent ones that aren't yours, if that makes sense. Either that or it is magically working for you but not others. @Begoon and Davey2010: What browser/OS/skin are you using? — MusikAnimaltalk01:39, 20 February 2018 (UTC)[reply]
Vector, FF 58.0.2, Win 7. And yes, you could be right, looking at the times of the edits/thanks they could well have been the last 2 edits that weren't mine (Nagual edited in the same minute, I don't have seconds to compare.) --Begoon01:47, 20 February 2018 (UTC)[reply]
Hi Begoon, I've never had an issue before but got your thanks (thanks! :) ),
@PrimeHunter: I was about to suggest the same. I'm going to up the task to Unbreak Now, but there's a chance it won't get fixed until tomorrow. So yeah, let's hide it. I don't think we can hide it on mobile too, can we? — MusikAnimaltalk02:22, 20 February 2018 (UTC)[reply]
I don't know a way we can hide it in mobile but I suspect the vast majority of thanks are from desktop. Pages with thanks links are harder to find in mobile and most editors are in desktop. PrimeHunter (talk) 02:31, 20 February 2018 (UTC)[reply]
Judging by the patch, I'm guessing the mobile version is unaffected. We might as well leave it hidden until the ticket is resolved, though. Thanks for figuring that out. Now I know where the mobile CSS is :) Which go figure is the SkinName.css — MusikAnimaltalk16:31, 20 February 2018 (UTC)[reply]
"thanked" link reverting to "thank"
I've put this in a subsection so as not to pollute the discussion of the above serious error, but I'd still be interested in an eventual answer to this, which was touched on above. While the thanks "links" on this page history for the thanks I just made today, above, still show as an unlinked "thanked" no matter how many times I refresh or purge, if I revisit the page histories for the thanks I sent yesterday the link has reverted to a blue-linked "thank", with the opportunity to do it again. Is this how it's supposed to work (ie the links revert after a period of time)? --Begoon02:27, 20 February 2018 (UTC)[reply]
I think you probably had the same issue. When you thank in the interface, it looks like it goes through, but if you refresh, it ends up having thanked the most recent revision. The ones you did today were probably the most recent revisions, hence why they worked. — MusikAnimaltalk02:36, 20 February 2018 (UTC)[reply]
No, I think it's separate. The edits which have reverted to "thank" are correctly shown as thanked in the log. Also, at least one of them was definitely the last revision when I thanked it (and still is, as I type). Also, also, this has done this, like this, for some time (weeks, maybe months), I've just never asked or "complained" till Davey mentioned something similar. --Begoon02:41, 20 February 2018 (UTC)[reply]
For as long as I can remember, any time I would log out and log back in, it would reset any edits I had thanked and allow me to thank them again. They remained in the log properly. Home Lander (talk) 02:49, 20 February 2018 (UTC)[reply]
Yeah, actually I do recall seeing that as well -- where the Thanks did go through but still reverted back to a Thanks link. For me it would revert back after a few days, not immediately, if I remember correctly. Anyway I agree this is probably an unrelated issue. I don't see a bug for it in Phabricator, so let's revisit it after the above bug is fixed.
I'm guessing this issue arose today; all my thanks in the log from yesterday and earlier appear to be correct. Guess I'm glad I didn't try to thank anyone today. Home Lander (talk) 02:59, 20 February 2018 (UTC)[reply]
I'm presenting problems with the thanks feature too. In the article's history the thank option disappeared from the edits, and reads as (undo | ). Only those edits I have thanked before appear as (undo | thanked). I noticed that in the Spanish Wikipedia my option is shown normally. --Jamez42 (talk) 03:24, 20 February 2018 (UTC)[reply]
The problem appears to be that the thanks function is thanking the last unthanked edit in the page, regardless of which edit is chosen, so in many cases it is thanking the wrong edit/user. If the edit you thanked happened to be the last unthanked revision you were possibly "lucky" and it will possibly have worked "ok", by chance. The logs seem to be correct, but the feedback you receive at the time of thanking may not be. Don't rely on it at all until it's fixed would be my advice, though. I'm guessing you must have done it from mobile though, and I don't think anyone has confirmed exactly what that is doing, or if there is any difference. --Begoon06:36, 20 February 2018 (UTC)[reply]
Yes, I am trying to figure it out because from the above, it seems to me like people are also not seeing the button at all. But I understand this edit now hid it, so I am now not seeing the button on desktop version, but still it appears and works in mobile. –Ammarpad (talk) 09:33, 20 February 2018 (UTC)[reply]
Can someone tell me why Visual Editor is blocked for all of the Wikipedia: namespace, it would be very helpful for Wikiprojects if it was enabled, especially when using tables.
John, you might talk to User:Kerry Raymond about her workaround for this limitation. Note that you will have to choose between the workaround or letting users have access to the 2017 wikitext editor, because the two are incompatible in a fairly dramatic way. Whatamidoing (WMF) (talk) 19:52, 21 February 2018 (UTC)[reply]
Why not copy the source text to a sandbox in your own userspace where VE is enabled, edit it there and then copy it back to the page? Or why not host the page in question in your userspace and transclude it to the WP page? Regards SoWhy20:09, 21 February 2018 (UTC)[reply]
For future ref, WP:VE#Limitations, first bullet, summarises the namespace restrictions. WP:NS has a table listing all of the namespaces for English Wikipedia. Namespaces numbered above 15 vary between different language Wikipedias, and also between other Wikimedia projects such as Commons. --Redrose64 🌹 (talk) 09:32, 22 February 2018 (UTC)[reply]
John, have a look at Special:WhatLinksHere/Template:VEFriendly to see what Kerry has been doing. It's not elegant, but it might be enough to get you through this one workshop. (Just make sure that nobody enables the new wikitext editor, or every page they use this on will be replaced by raw HTML.) The Help: namespace might be another alternative, if what you're doing is mostly instructions about how to edit, etc. Whatamidoing (WMF) (talk) 17:56, 23 February 2018 (UTC)[reply]
As Izno said, bugs ideally get reported on phab:Phabricator by someone. It might also be useful to leave a note at mw:Extension talk:Math, but I don't know how closely that page is watched.
Support for math rendering has historically been an area where volunteer devs such as User:Physikerwelt have contributed more than WMF staff. User:Debenben had a proposal up for the most recent m:Community Wishlist to make some substantial improvements in rendering, but it didn't get enough votes to win. The WMF is working on the plans for the upcoming fiscal year right now, and I've not heard anyone talk about math as a key area for improvements (which isn't proof that they're not). Whatamidoing (WMF) (talk) 19:52, 21 February 2018 (UTC)[reply]
For some reason the input \operatorname* is replaced with \operatorname {*} by the texvc "validation". My suggested fix is to get rid of the broken validation. @Whatamidoing (WMF): Is there a way to influence the plans to include math as an area for improvements?--Debenben (talk) 22:53, 21 February 2018 (UTC)[reply]
I believe that most of the changes you've outlined belong to the Reading team (because most of them are about how the formulas display to the readers), and probably User:Jkatz (WMF) knows the most about that team's plan. Eventually, the drafts will be posted on Meta, and any interested person can comment. Whatamidoing (WMF) (talk) 18:50, 23 February 2018 (UTC)[reply]
I think investing some time into improving the math rendering now would save the reading team a lot of work in the future. Currently there are various different incompatible workarounds used by the editors, each with its own set of problems affecting the readers: The svg and png images usually look bad (unreadably small on iPad1, broken image icons on android 2...), unable to handle languages with non-latin characters, uncopyable... The templates are difficult to use, non-standard, inaccessible to screenreaders and can't handle everything. All of these workarounds have to be maintained only due to the lack of a working rendering system like MathJax, which is what other websites use.
Also, I don't think any volunteer developer would help to re-integrate MathJax or enable client side, HTML-based rendering if it will not become default. As an opt-in via MathML-capable browsers, plug-ins or user-scripts it is already possible today and an alternative system for hiding rendering problems of average readers from the editors is not useful. This situation will not change until the problem that kept the MathJax rendering option from becoming default is resolved: Providing servers (or using a third party cdn?) capable of delivering web-fonts to readers that don't have any suitable math-fonts installed on their device. I believe the additional traffic should not be an issue anymore.
Finally, bad software that is completely useless will not attract volunteer developers. For example, I currently don't see the \operatorname* problem this thread started with ever getting fixed. I created a ticket for my proposed fix: phab:T188879, it would already help if it gets discussed and agreed on.
Special:Contributions/179.228.224.8 Aha, you mean this, which I have no idea what that's about, sorry. What I can do for you is take this to the phabricator team. They'll know what's going on. For now, I wouldn't worry. And you can always see those grey faces on the history list (go to the bottom and click on the green bar.) Sincerely, User: Zanygenius(talk page) 01:55, 25 February 2018 (UTC)[reply]
Several weeks ago I noticed I no longer get an edit tab for the lede (as I had long selected in my Preferences); to edit a lede I have to open the whole article. Any reason why? Also, about the same time I no longer have the drop-down Insert tab under the edit window that gives me a choice of Symbols, Latin, etc.; I get a box with everything (almost?) in it. I use the Vector skin, and had not made an changes to my preferences in a while. And now I don't even see (because I'm blind??) a check box for an edit tab on the lede. Anyone know what's going on here? ~ J. Johnson (JJ) (talk) 21:58, 2 March 2018 (UTC)[reply]
It should be at Preferences → Gadgets, as "Add an [edit] link for the lead section of a page" immediately below the "Appearance" heading. It's working for me, in MonoBook skin. Perhaps a different gadget has been amended in such a way that they now conflict with one another. --Redrose64 🌹 (talk) 23:03, 2 March 2018 (UTC)[reply]
This symptom is usually caused when you are using a gadget or script which has not been updated for the various and sundry changes made to the MediaWiki Javascript environment over the past several years. The less likely but still possible cause is the one that RR64 gives. Given that you have had multiple scripts stop working, I would guess it is the former. What gadgets do you have enabled? --Izno (talk) 03:49, 3 March 2018 (UTC)[reply]
In Preferences I unchecked "Add an [edit] link", saved, then re-checked and again; no change. (Are the changes effected immediately? Or only on login? Help:Preferences doesn't say.)
I switched to Monobook. Font changes immediately, but no tab. Logged out, back in, no change. (Answering the prior question.)
Under Gadgets I have enabled:
Browsing:
Suppress display of fundraiser banners
Enable the Teahouse "Ask a question" feature -
Reference Tooltips (it also is not working)
FormWizard
Watchlist:
Display watchlist notices
base style
Display green
Editing:
Citation expander
Syntax highlighter
Form for filing dispute
CharInsert
refToolbar
Add extra buttons
Appearance:
Add an [edit] link
Add a clock
Display an assessment of an article's quality
Show radio buttons
I have disabled each one and saved; no edit tab. I had "Wikitext syntax highlighting" enabled; disabling made no difference even after logging out. Any other ideas? ~ J. Johnson (JJ) (talk) 00:56, 6 March 2018 (UTC)[reply]
I hit the page reload button, but perhaps that just goes to the cache. Dang. So... do it all over again? :-< Tomorrow. ~ J. Johnson (JJ) (talk)
No joy. I unchecked everything under Gadgets (except "base style"), changed the skin to Monobook, saved, logged out, cleared my cache (ctrl-F5), and logged in again. No edit tabs. What .... wait a minute, standing by for a flash.
Yup, just found it. A month ago I added the "NoScript" extension to Firefox. And apparently it didn't quite understand that I trust Wikipedia absolutely, every last word, even if there are a bunch of funny characters running all over the place. :-) And now, back to the garden. ~ J. Johnson (JJ) (talk) 00:31, 7 March 2018 (UTC)[reply]
Invisible text bugs not fixed?
T188215 is said to be fixed in MediaWiki 1.31.0-wmf.23, which has been dpployed to all Wikipedias as of 1 March. However, I am still getting the same bug: When both the 2017 wikitext editor ("new wikitext mode") and syntax highlighting are enabled, I get invisible text on image pages. (Note: A workaround is to simply refresh the page, unless two edit tabs are enabled in preferences.)
Here is the 5th issue of the Bots Newsletter (formerly the BAG Newletter). You can subscribe/unsubscribe from future newsletters by adding/removing your name from this list.
While there were no large-scale bot-related discussion in the past few months, you can check WP:BOTN and WT:BOTPOL (and their corresponding archives) for smaller issues that came up.
The edit summary limit has been increased to 1000 characters (see T6715). If a bot you operate relied on the old truncation limit (255 characters), please review/update your code, as overly long summaries can be disruptive/annoying. If you want to use extra characters to have more information in your edit summary, please do so intelligently.
You will soon be able to ping users from the edit summary (see T188469). If you wish to use this feature in your bot, please do so intelligently.
Thanks, I should I specify I'm on Android. IIRC browsers on iOS in general are quite different, so it's possible they act different. --fireattack (talk) 04:52, 4 March 2018 (UTC)[reply]
The current system with user scripts is admirable. However, it becomes quite regular that users use the scripts of others. Editors without the edituserjs right (i.e. not Administrators) cannot edit the scripts of others. Unfortunately, this has lead to forking of scripts when a new feature is wanted or when the maintainer becomes inactive. Take for example User:Theopolisme/Scripts/adminhighlighter - based on User:Amalthea/userhighlighter.js which was in turn based on User:Ais523/adminrights.js. Then I made this one based on that: User:Bellezzasolo/Scripts/adminhighlighter. It would be far better to have one centralized script with parameters for custom features. At the same time, there are problems re. vandalism - user scripts are particularly sensitive, especially with malicious code possible. Possible solutions:
Centralized scripts generally editable - support - more maintainers oppose very risky
Centralized scripts editable by template editors/admins - support more centralized oppose those without bit may create forks
Template editors have edituserjs - support Better maintenance possible by technically minded editors oppose uncentralized, does not eliminate forking issue
Do nothing - support status quo, safe. oppose Forking and maintenance problems above.
Okay, here it is: I'd like to have a tab on pages that allows me to open the VisualEditor directly without having to open the source editor first and then switching. I know that this can be achieved by appending something to the URL, so what I now need is to add a tab to the page to take me directly there. Can someone with the technical skills tell me the code to use? Regards SoWhy13:22, 4 March 2018 (UTC)[reply]
Weird way to hide it there but thanks for pointing that out to me. I had it disabled initially because it was loading every time and so of course I didn't realize they now actually made it useful. Regards SoWhy17:12, 4 March 2018 (UTC)[reply]
Apologies for any alarm, this was a test. When I last looked it was a minor disruption, but it appears that it expanded as my contribs list grew in size both below and above the edit summary. I've collapsed it above - TNT❤15:50, 4 March 2018 (UTC)[reply]
This feature is to be primarily used in collapsible assistive boxes, not in articles, although one could find such a functionality useful to build collapsible serial map boxes for metro lines, where hide/show clickables, if used instead, would mess the box and annoy as the only clickable area to do expand/contract.
If you have a look in Template:Cheatsheet and el:Πρότυπο:Εργαλειοθήκη to compare, you will see a difference while hovering above the text of collapsible headers. By highlighting on hover, the reader gets a hint to click. For another demonstration, check el:Πρότυπο:Συγγραφή λήμματος (also in Greek) which is a collapsible help with sub-levels. There is no hint to click the collapsible, if hover highlighting is absent. And what about building a collapsible help, where click is done upon collapsible headers that reveal videos of 15 seconds each, to immediately assist an editor giving specific editing instructions? (coming soon)
It would be great if an admin could add this, it is a feature that manos has been working on for a long time, it has been already implemented on greek wikipedia and soon is going to be added in couple of more Mardetanha (talk) 07:39, 1 March 2018 (UTC)[reply]
I am transferring it in technical VP, from idea lab VP. The full code, as given here, is tested for months in Greek Wikipedia. An example of code usage is this:
<div class='hover-bgc' data-hover-bgc='#e5f0fe'>►hover over me</div>
►hover over me
You can enable in your own Common.js and see the result here and in the examples above.
instead of getting into technicalities, can someome please first explain what they are trying to do ? My first intuition tells me that this is something that doesn't work on mobile, and for people with screenreaders and the likes.. —TheDJ (talk • contribs) 06:59, 5 March 2018 (UTC)[reply]
Hello TheDJ, these are templates to be used inside the sandbox space of users, to help newbies create articles. The main tool can also be handy to advanced users who wish to work using their own page templates for article creation and publish directly to main space. User sandbox is not present in mobile devices as a link, so it is a safe place to put these tools for assistance, until collapsible becomes ready for mobile (if any). ManosHackertalk07:07, 7 March 2018 (UTC)[reply]
Image quality
I've noticed that the quality of PNG rendering has improved dramatically sometime in the last few months, and thumbnails are no longer blurred. However, is it just my imagination or have JPGs gotten a lot worse? I do a lot of work cleaning up logos, and whenever I remove the artefacts from a JPG and save at a reasonable compression I'm disappointed by the low quality of the images rendered in article space. (I realize that such small logos should probably be converted to PNG files rather than JPG.) The additional compression applied by the Mediawiki software when serving images at non-native sizes is understandable with large images but pretty woeful when it comes to smaller images, especially those smaller than 100,000 megapixels (such a Fair Use logos). It seems to me that, given the already small file sizes, it's hardly worth applying additional compression at all. Where can I look at the technical specifications and maybe stick my oar in? nagualdesign03:16, 5 March 2018 (UTC)[reply]
I am guessing you are referring to logos stored on wikis other than Commons (here on enwiki, probably?). This is likely due to a standardization of image processing that happened last summer that I forgot to communicate. When we migrated thumbnail processing to a new platform (which actually uses the same underlying image processing software and settings as before), we decided to not have special cases per wiki anymore - which are taxing to maintain - and we put the settings in line with Commons for all thumbnails. Commons (and now, "everything") optimizes JPGs for photos (using settings determined by the Commons community a long time ago), using enhancements like conditional sharpening. Which while they improve the visual quality of photo thumbnails, are indeed detrimental to logos and schematics. Because the workaround - and policy/expectation on Commons I believe - is to indeed upload non-photos as PNGs. I apologize about the disruption this change has caused, and I can imagine that re-uploading these images is going to be a significant amount of work. I encourage you to upload that type of image as PNGs if it's not too much trouble, as it fixes the problem and lets us keep image processing consistent across all of Wikimedia production.
FYI PNG processing hasn't changed recently. Maybe some underlying libraries have seen an update through Debian, but I'm not even sure that's the case, nor that it could explain a sudden improvement. Our integration tests compare reference images created 2 years ago to the current output with DSSIM and for PNG the threshold is 99% (it's only not 100% to let the tests pass locally on different platforms). Any drastic change in quality (for better or for worse) would be very likely have been detected by those tests.GDubuc (WMF) (talk) 09:39, 5 March 2018 (UTC)[reply]
I'm (often but not always) having problems editing pages. Sometimes the cursor is displaced horizontally or veryically or both from where I am actually editing; sometimes the text I have typed is randomly rearranged (the beginning of this message curfently reads "I'm (ofte nbu tnot always) havgpro niblems editing pages", but I'm pretty sure I typed it correctly). Sometimes when I view the preview it has randomwly inserted newlines, so that part of my message appears monospaced.
I've taken to saving the text and then going back and correcting the typos, because that's the only way I can get it to work.
I'm using Firefox 58.0.2 on two different Windows machines, and I've looked at my editing preferences in WP, and can't see anything that looks relevant.
Going back into editing after reviewing the text, I see that the first line displays correctly in review, but still appears as I copied it above in the edit window.
Thanks PrimeHunter. I forgot there was a "beta features" tab in preferences. I've tried turning that off - at the moment it seems to be behaving properly, but I'll try a few more edits over the next couple of days. It seems very likely that that is where the problem is (though it's obviously a bug somewhere, that needs fixing). --ColinFine (talk) 14:43, 5 March 2018 (UTC)[reply]
My skin is Vector, by the way. However, although I turned the mode off in my preferences and saved the change, before I replied above, it is now turned on again. --ColinFine (talk) 14:46, 5 March 2018 (UTC)[reply]
Thanks, Dan. As Pr9imehunter surmised, I had "Automatically enable all new beta features", and therefore had both Wiked 2017 and syntax highlighting on. I have just tried turning off syntax highlighting to see what happens. (I tried turning off Wikitext editor yesterday, but that didn't take effect, evidently because I had the automatic enable on) . --ColinFine (talk) 15:48, 6 March 2018 (UTC)[reply]
Extra padding on mobile for ul items generated using plainlist
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
On Special:AbuseLog you can now choose to list only actions that actually made an edit. Other actions are when the filter warned the editor or blocked the edit from being made. There are also more search options. [6][7]
Wikis can enable Citoid to provide automatic reference look-up in the visual editor and the 2017 wikitext editor, but it is complex. The tool will now warn in the JavaScript console if the configuration isn't correct. Soon Citoid will disable itself if the configuration isn't correct. Check that your wiki is configured correctly. You can ask for help if you need it. [8]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 March. It will be on non-Wikipedia wikis and some Wikipedias from 7 March. It will be on all wikis from 8 March (calendar).
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 6 March at 19:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 7 March at 16:00 (UTC). See how to join.
Future changes
In the future you will be able to use global preferences. This means you could change a preference for all wikis instead of having to change it every time for each wiki. You can now test global preferences and give feedback.
I can't seem to find the delete button in the "More" drop-down anymore. If I refresh a page quickly it's there and I can click on it and get the delete page, but if I let it load, it disappears. Could it be one of the scripts I've got? Anarchyte (work | talk)09:42, 6 March 2018 (UTC)[reply]
Does safemode work? It omits loading local js and css pages, also from gadgets and the MediaWiki namespace. You can preview personal js and css pages to see the effect of changes on that page (but not on other pages). Do you get a delete link when you preview blank versions of any js page at Special:PrefixIndex/User:Anarchyte/? If safemode fails then you can just say so and skip the js tests. What is your browser and skin? PrimeHunter (talk) 11:14, 6 March 2018 (UTC)[reply]
With the gadget enabled I have Delete, Move, Protect under the "page" tab in MonoBook but in Vector they just disappear from More. I guess the gadget tries to remove the links from More and add them to Page instead but the latter part fails. Tested on Example. PrimeHunter (talk) 12:18, 6 March 2018 (UTC)[reply]
I have all three links under "Page" in Vector with IE, Edge and Chrome. It only fails in Firefox where the only links under Page are:
Merge (admin feature for history merge) is also missing in Vector. That link is only added by MoreMenu and not part of the normal More tab. PrimeHunter (talk) 12:32, 6 March 2018 (UTC)[reply]
Yes it moves the More links to Page/User accordingly, to consolidate them. It should also remove the More menu if it is empty, but I guess that part was never implemented... Anyway, let make sure I've got this right -- Anarchytedoes have the relevant links, they just didn't realize they were moved under Page. Is that correct? Perhaps you recently enabled the gadget?
Meanwhile, even under "Page" the links are missing for PrimeHunter in the Vector skin while using Firefox. Can you try clearing your browser cache (or try in Firefox's "Private browsing")? All the links show up for me, in Chrome and Firefox. It's possible MoreMenu somehow has a cached version where it doesn't think you're an admin. — MusikAnimaltalk16:18, 6 March 2018 (UTC)[reply]
It also failed to display the Move link in a non-admin account where it should be present. But it worked to clear all website data in Firefox. I now have the missing links under Page. It wasn't enough to use Ctrl+F5 or clear cached web content. PrimeHunter (talk) 17:29, 6 March 2018 (UTC)[reply]
Glad you got it working! :) The only thing MoreMenu caches is your user rights. My guess is the initial API call to fetch your user rights failed, so it thought you were an unconfirmed user, hence why the Move link was missing. Reviewing the code, I don't think this (rare) failure is properly handled. I will look into it!
Unrelated, you say clearing the cache by itself didn't do the trick, which tells me that issue probably isn't MoreMenu, because it caches using localStorage. Maybe something with ResourceLoader... who knows! — MusikAnimaltalk17:56, 6 March 2018 (UTC)[reply]
Guys, could someone remind me, how to get page ID via API if I have page title? Did look trough action=query, but didn't find the right option. Actually, I would like to get page IDs for all pages linked from this page (specifically Wikipedia:Vital articles/Level/5/*** pages), but specific query for one page will be ok. --Edgars2007 (talk/contribs) 18:33, 6 March 2018 (UTC)[reply]
We wanted to take a moment to update you all about a reader-focused feature called Page Previews, which has also been popular as a Beta Feature among editors. The Readers web team at the Wikimedia Foundation has been working on a few things we’d like to share.
Most recently we:
Deployed the new HTML endpoint for generating previews, leading to better rendering of preview content (math equations work, more predictable formatting of information in parentheses, etc.) (T113094)
Completed two A/B tests on English and German Wikipedias. The results displayed a decrease in pageviews, but an overall increase in the number of pages readers interact with, indicating that they are more likely to explore a larger variety of topics when the feature is on. We also noted decreased usage of the back button and very low rates of disabling the feature. These experiments built on earlier qualitative and quantitive testing of the feature.
Refactored the code (that's fancy developer-speak of restructuring the code to be more performant and stable) (T149801)
Made sure Page Previews do not interfere with the functionality of Navigation Popups
As both can not be run simultaneously, users of Nav popups will need to disable the gadget in order to try out Page Previews.
Reviewed feedback from readers across the web [9][10][11][12]
If you haven’t already, you can enable the feature in your preferences under Appearance. Feedback on how things are working for you is welcome. The HTML endpoint change was deployed just last week and we’re very excited to see the improvements. We’re expecting some smaller bugs and edge cases, so please let us know if you notice something out of order. You can find out more about the feature on MediaWiki.org.
Hi I wanted refill on Marathi Wikipedia but I don't find the way out for it. I requested for it's translation on it's Transifex page yet no response. Can anyone create a version of it for Marathi Wikipedia? I and the community is ready to help in translation and templates needed. --✝iѵɛɳ२२४०†ลℓк †๏ мэ05:51, 7 March 2018 (UTC)[reply]
Have you tried doing this in the visual editor? The Marathi Wikipedia already has the citoid service installed, and the visual editor offers a "convert" button for bare URLs. Open the page (in the visual editor; you may need to enable that in your preferences), select the blue ref tag, and then click the "convert" button that will pop up. Whatamidoing (WMF) (talk) 18:29, 7 March 2018 (UTC)[reply]
@Whatamidoing (WMF) and MusikAnimal: While citoid is concerned we have just installed it few days ago and it's not working fine. I've seen the convert button there and it fills one reference at a time (currently not working). Marathi Wikipedia has a lot of bare urls so I needed this tool to convert them on a large scale. Any developer that can make the same type of tool? --✝iѵɛɳ२२४०†ลℓк †๏ мэ00:58, 8 March 2018 (UTC)[reply]
I certainly don't have time to work on it, sorry :( User:Dispenser has a similar tool, maybe he could assist with adding support for mrwiki? Otherwise, as I said ok my talk page, I would ask for help at User talk:Zhaofeng Li/reFill. According to the FAQ this is the means to request that new wikis be added. Best — MusikAnimaltalk06:18, 8 March 2018 (UTC)[reply]
Hi. I started using STiki today. Apparently, despite me attempting to revert only one edit, it is reverting the edit I intend to revert and the edit after that without my agreement. I had to go back and undo these changes. It seems strange for STiki not to work. I pressed Vandalism when I found vandalism and it reverted that edit and the edit after that. Why is this happening? I had to stop using this tool as I can't continue if it is blindly reverting without my agreement. Pkbwcgs (talk) 21:25, 7 March 2018 (UTC)[reply]
Hi, this sounds like a serious bug. I would ask about it at WT:STiki, and be sure to include what operating system you're using (Windows 10, MacOS Sierra, etc.). Best — MusikAnimaltalk06:30, 8 March 2018 (UTC)[reply]
Watchlist adding and removing fails intermittently
Has anyone else been having problems today adding pages to, and removing pages from, their watchlist? It started happening to me for no apparent reason at around 21:00 UTC, 7 March 2018 (I don't often have the need to do this regularly, so it's been probably at least a week since I've have to change my watchlist before today). I tried to add about 10 pages in a row (opened in different tabs) to my watchlist via the star-click method and the vast majority failed, giving a "An error occurred while changing your watchlist setting…" pop-up message. Retried, and all or almost all failed again. I tried using the Alt-Shift-w keyboard shortcut, same thing. Tried logging out and logging back in, same thing. Occasionally one attempt would work, but the majority of times failed with the same error message. Since the problem was intermittent (in particular, sometimes working), I figured it wasn't just a problem with the configuration of my browser (FF 52.4.0 on Gentoo Linux) or my particular wiki account, so I reported the issue at the Phabricator (phab:T189160); more details can be found there. Given that no one seems to be talking about this here at VPT or at VPM, it doesn't appear to be a widespread problem, but I figured I'd post about it here, anyway. It's still happening as I post this, although the failure rate is way down (looks like waiting just a few seconds after a failed attempt is enough now to allow for a success; that wasn't true even a few hours ago). - dcljr (talk) 05:17, 8 March 2018 (UTC)[reply]
Infobox title is not center-aligned on mobile
I don't know if this was brought up before, but the title of certain infoboxes is not center-aligned on mobile. It seems to break depending on which {{Infobox}} parameter is used to make the title. When you use "above", like in {{Infobox person}}, it's fine (see Albert Camus – screenshot), but when you use "title", like in {{Infobox company}}, the software seems to think it's a regular table caption and it applies text-align: left; to it (see Blizzard Entertainment – screenshot). – Srdjan m (talk) 08:22, 8 March 2018 (UTC)[reply]
The one is a header cell, and the other is a table caption. Due to the way table captions work, if they are too long, they overflow unhelpfully. If they are wider than the table, you would see the 'middle' part of the title, and not the start of the title. There aren't very simple fixes for that problem that could be found, so it was decided to keep them left aligned instead. —TheDJ (talk • contribs) 08:58, 8 March 2018 (UTC)[reply]
I was tipped to use this: {{button|{{int:publishchanges}}}}, to show Publish changes all right. Could someone give a link to int: documentation (help, WP, mw, ...). Likely it will also lead to the available options (like this 'publishchanges'). -DePiep (talk) 10:19, 8 March 2018 (UTC)[reply]
Redrose64, what are you trying to say? You think I did not search it? Or try WP:int:? To me, magic words look like __TOC__, and anything like {{#if: is a parser function (quote from there, lede: "* Parser functions: these take parameters and are either of the form {{foo:...}} or {{#foo:...}}, e.g. {{#invoke:}}. See also Help:Extension:ParserFunctions"). So far for mw consistency and documentation clarity. - DePiep (talk) 15:25, 8 March 2018 (UTC)[reply]
A search on help:int would have found information. I have added a hatnote to WP:INT. There are three types of magic words at mw:Help:Magic words#Localization. The term is most commonly used about behavior switches of form __TOC__, but built in parser functions of form {{int:}} with no # are also sometimes called magic words. Extensions like mw:Help:Extension:ParserFunctions can add more parser functions with # like {{#if:}}. Such added parser functions are not called magic words. PrimeHunter (talk) 17:38, 8 March 2018 (UTC)[reply]
This all may be OK, but: I did not find it. "You searched the wrong word spelling [stupid]" is not a reply I expect (yes, this is tough re good editors, but can one disagree?). Already above I pointed out (with links): mw help etc. is inconsistent. - DePiep (talk) 00:29, 9 March 2018 (UTC)[reply]
I didn't in any way imply you are stupid. I merely showed that searching the help namespace may be useful. I thought it was a helpful tip and didn't expect it to offend you. I don't know which inconsistency you refer to. Your only link was to mw:Help:Extension:ParserFunctions. It's a help page for a specific extension. {{int:}} is not part of the extension so it's not listed there, but the opening sentence links mw:Help:Magic words#Parser functions where it's listed. If there is a page incorrectly claiming that magic words can only look like __TOC__ and not {{int:}} then please identify it. PrimeHunter (talk) 10:56, 10 March 2018 (UTC)[reply]
I encountered int a while ago at Commons and for anyone noticing it there, they have an interesting trick. By convention (at Commons), [[MediaWiki:Lang/XX]], where XX is a language code, contains XX. That means {{int|lang}} is replaced with XX, where XX is the language code for the current user. For example, if your user language preference is French (or if ?uselang=fr is used in the URL), {{int|lang}} would be fr. That happens because c:MediaWiki:Lang/fr contains fr so lang is translated to fr for French. phab:T4085 is relevant. Johnuniq (talk) 22:10, 8 March 2018 (UTC)[reply]
"int" can be short for "interface", but it could also be short for "internationalise". The {{int:...}} function at Commons is exactly the same as it is here, at meta, wiktionary and all the others. At none of them does it mean integer; and I don't know where that i18n comes from. --Redrose64 🌹 (talk) 11:45, 10 March 2018 (UTC)[reply]
Bishzilla was admin in 2008 and 2009, perform some blocks, compare AN thread. See also example of block of specific user. Used to be log of these blocks! Now gone![13] How that happen? Where is block log? Pre-September 2009 block log by other admins also apparently erased. Why history erased? Especially considering old blocks still logged under blocked user. Is bug? Now look like Jimbo Wales never blocked Bishonen.[14] (He did, in 2009.) Disgraceful! bishzillaROARR!!10:33, 8 March 2018 (UTC).[reply]
Joking aside, it does indeed seem as if all blocks performed before ca. 20 September 2009 have been removed from the block log for all admins, which is probably not a good thing. Has this been communicated or discussed before? Fram (talk) 10:39, 8 March 2018 (UTC)[reply]
Not all of them are missing. The block log has plenty of entries for September 2009 and earlier, going right back to 23 December 2004 - those entries dated before 04:53 that day seem to be testing of a new feature. --Redrose64 🌹 (talk) 14:37, 8 March 2018 (UTC)[reply]
That's not what this is about, Redrose64. When I try to look at the blocks by an individual admin, such as Bishzilla or Jimbo Wales, it shows nothing earlier than September 2009. I know those blocks show up when you look in other ways: for instance, at the blocks of an individual user (example), or at the whole block log, as exemplified by you. Phabricator now says it's been fixed[15] and the fix is "being deployed" — I suppose not deployed yet, because the problem persists when I look. Bishonen | talk16:23, 8 March 2018 (UTC).[reply]
None of the previous comments state that it is only the blocks by an individual admin that are affected. Indeed, Fram wrote "all blocks performed before ca. 20 September 2009 have been removed from the block log for all admins". So I looked at the block log for all admins - and found thousands of entries. --Redrose64 🌹 (talk) 16:45, 8 March 2018 (UTC)[reply]
As I see it the authority control is a kind of navigation bar to other websites, specifically those that catalogue people, books and the like. It is clearly intended to assist identification of the subject. For various reasons related to reliability a number of indexes have been excluded, possibly due to reliability, although ORCID is also user-generated and is included.
Imdb is listed at the bottom of almost every article about an actor, it would make sense to have a template similar to Authority control but for biographies of people in the entertainment industry. I also don't see why there are links to all the library databases except ours, adding wikidata seems completely logical, especially as that is where the data is coming from. By having a set template, it would be easier to stop the proliferation of external links (often used as a store for promotional material), because the section would not be needed to link to IMDb/etc. It would also be easier to add the same template to all actors/musicians, and display better for people that are both. Prince of Thieves (talk) 10:39, 8 March 2018 (UTC)[reply]
All these sources are unreliable ones. Musicbrainz is already included in Authority control anyway (but should be removed from it as it is a wiki where the main text is just a reproduction of our article anyway), and Wikidata is linked from the left side panel. Adding Findagrave and the like to more articles, or institutionalizing it in a template, is the wrong way to go. Removing them from many more articles is what needs to be done. Fram (talk) 10:43, 8 March 2018 (UTC)[reply]
There is this big difference: {{Authority control}} ({AC}) only cross-links external identifiers, not additional information ("what is this article named in library system Xyz?"). Accordingly, {AC} is not part of the article content (same as navboxes). So if you want to link to WP:EXTERNALLINKS (that do have extra info and are within article content), that would require a different template. One can not use {AC} for this.
That said, by information approach: I think such an {AC}-like, and an MOS:EL-defined template is useful and needed. Today {{Chembox}} (an infobox), is overloaded with EL's in the identifiers section (e.g. Carbon monoxide). - DePiep (talk) 11:00, 8 March 2018 (UTC)[reply]
To be clear I am looking for a new template like Authority control, not to add imdb to the existing Authority control template, this would then be used instead of existing imdb, musicbrainz, discogs and fa grave templates. It would be used purely as an external link template, and would not allow people to cite imdb any more than they do already. Prince of Thieves (talk) 11:07, 8 March 2018 (UTC)[reply]
There are many more resources included in Authority control than there are listed in its documentation. Who decides about which numbers are included is not really clear, I suppose the handful of people reading the template talk page? A thorough discussion about which IDs should be included (or which ones should be included in some cases but not in others), and how to display this (removing the actual numbers and keeping only the database names would reduce the "heaviness" of the template significantly), is needed, but I'm not the one who is going to start it. Fram (talk) 09:10, 9 March 2018 (UTC)[reply]
Hi - I'm experiencing severe problems demonstrating Visual Editor during an editathon event in which we're seeing VE freeze at the 'Publish changes' stage. It will not allow me to switch back from VE to source editing, either.
We have reproduced this issue on two separate Windows machines, and in both Chrome and Firefox. In the latter instance I logged out as me and tried to edit as another autoconfirmed user here who, unlike me, has never changed any of their default settings or installed scripts or activated any beta functions. A third editor also recreated the problem via their account. There was no difference in what we experienced - VE froze. The accounts we edited from were mine, User:Jonxennialuk and User:Mainlymazza.
To reproduce the fault we edited Buxton & Leek College in VE, we tried to copy, cut and then repaste an entire section with its heading into a different part of the article. At times a few letters that we had not typed ourselves also appeared, and we deleted these. At times we lost formatting of the Heading without any user input. On hitting Publish changes the process froze, so we were unable to enter an edit summary. On trying to switch to Source editor we got as far as the 'confirm' you want to switch stage and could go no further; we had to close the programme. The same fault was recreated whilst editing another article in exactly the same manner.
@Malyacko: Thanks. I'm afraid I'm not sufficiently technical to be able to understand/investigate this further myself. I will have to 'leave this here' and hope others can attempt to reproduce the issue or advise whether this might be some local issue as a result of half a dozen editors at max logged on to the IP network accessing Wikipedia at once. I've advised fellow hosts at the WP:TH that I'm experiencing this issue in case other new editors do too. Nick Moyes (talk) 13:52, 8 March 2018 (UTC)[reply]
I also had some trouble there. I copied a section, and then pasted it just before the "References" section and VE magically added "Refer" between my paste and the references section. I then tried to click the publish button and the console reported: "TypeError: null is not an object (evaluating 'parentDomElement.lastOuterPost')". Might be something specific to that page ? —TheDJ (talk • contribs) 13:54, 8 March 2018 (UTC)[reply]
I get this occasionally. My mouse is old and sometimes the left button bounces, so that an intended single click goes through as two clicks. --Redrose64 🌹 (talk) 19:08, 8 March 2018 (UTC)[reply]
NOTICE: EducationProgram extension is being deprecated
Please help translate to other languages.. Thank you!.
Over the years many issues have been discovered from our engineering colleagues regarding the Education Extension, including security concerns. For this reason, and with a viable alternative platform available, we are starting the process to deprecate the extension and having it uninstalled where it has been activated. This includes this wiki Special:Courses.
This means that the following steps will be taken:
Current ongoing programs will be supported, until the month of June, 2018.
On June 30, 2018, the Education Extension will be shut down.
If you are still running an education program that uses the Education Extension, please take the appropriate measures and also reach out to your colleagues and communities so they are also aware.
It should be noted that data of previous programs that ran on the Education Extension will remain safe, and we are working on documenting how to access that data.
Thus, we invite all Education Program Leaders (and users of the Education Extension) to take the online training for the dashboard so that you can benefit from this tool and make your work easier.
If you have comments or questions, please reach out to the Education Team at educationwikimedia.org, or the Programs and Events Dashboard group at dashboardwikimedia.org.
This is just a dummy reply that contains a signature with a link to a user page so this thread will be archived. Graham8712:14, 9 March 2018 (UTC)[reply]
Article creation date
A researcher wrote to Wikimedia asking for help identifying the creation date of an article.
I responded that we typically equate the creation date to the date of the first edit.
I was slightly surprised I didn't find anything formally stating this.
I can think of a couple things to be concerned about if one adopted this is a rule (the intention, I believe, is to do a statistical analysis of the entire set of articles).
Some of the edits of the very oldest articles are missing, so that the first edit one can find in the existing database is slightly more recent than the original creation edit.
There may be some issues when a redirect is converted to an article. For example, if someone created a redirect 2010, and someone else converted it into a proper article in 2015, what is the creation date of the article? Depending on the nature of the study, one could make an argument for both dates and given that they might be separated by years, this is worth thinking about.
Are there other important classes of articles that could be an issue? In the case of deleted and restored articles typically the history is preserved so I don't see an issue there.
I would also urge the researcher to think about the definition of an article. For example, I believe we have more redirects than articles, and deciding to count redirects as articles would have major implications on average edits per article, for example.S Philbrick(Talk)21:26, 8 March 2018 (UTC)[reply]
If a draft is moved to mainspace then it can be discussed whether the first edit or the move is the creation date. Sometimes the first edit is from a sandbox used for other purposes. PrimeHunter (talk) 00:37, 9 March 2018 (UTC)[reply]
The Did You Know? project's criteria for a newly created article is the date on which it first appeared in mainspace. As PrimeHunter suggests, an article can be worked on by one or more people in Draftspace or user sandbox for a very long time - years even - prior to being moved into mainspace. Sometimes moving a draft from a sandbox is a simple copy/paste job into mainspace or to WP:AFC, thus losing every scrap of prior editing history. I'm not sure I'd ever consider that creating a redirect is the same as creating an article - in what circumstances might that seem to apply? Nick Moyes (talk) 09:58, 9 March 2018 (UTC)[reply]
Please test pings in edit summary
1. Read this:
"You can notify users in edit summaries. They will get a ping just as if they had been mentioned on a wiki page. phab:T32750"-- meta:Tech/News/2018/10
2. Sign up at https://en.wikipedia.beta.wmflabs.org/ using a different user name and password (not the one you use here). You may create multiple accounts if you like, just put a note on their user pages.
3. Edit a page and put a username link in edit summary. Confirm that you are receiving the notification correctly.
We used to be able to go to an account and look at all contribs in a certain year. Now we have to fiddle with a calendar and add start and end year, month and day. Does anyone know why this was changed, and is it possible to get the old interface back? SarahSV(talk)04:33, 9 March 2018 (UTC)[reply]
2015 Community Wishlist Survey, coming in 15th place overall. No, you cannot revert back to the old interface, but I agree the calendars don't really help your use case. Perhaps it's easier to type in the dates (YYYY-MM-DD format)? You shouldn't have to put in an end date — MusikAnimaltalk05:33, 9 March 2018 (UTC)[reply]
I guess it would help if you could just type "2008" in that field and it would automatically interpret that as 2008-01-01... It seems more strict on that fields validation now, than it has to be really. —TheDJ (talk • contribs) 08:01, 9 March 2018 (UTC)[reply]
I guess somebody could write some JavaScript that adds the appropriate <input /> or <select>...</select> elements to the existing form. --Redrose64 🌹 (talk) 10:04, 9 March 2018 (UTC)[reply]
@Redrose64: thanks, that's good to know. Pinging Kaldari too. Can the interface be changed to allow us to enter the year only, so that we have access to that year and everything before and after it as needed? That is, the way it worked before. The new interface is fiddly. It would be nice if we could easily bypass it. SarahSV(talk)02:13, 12 March 2018 (UTC)[reply]
Teahouse Ask-A-Question form fails to function in iOS
Screenshot of Teahouse's "Ask a Question" form on iPhone 5 showing overlapping text and no acccess to the question box itself.
Over the last few months we've seen a number of reports at the Teahouse that our page does not display properly in iOS, and especially that our "Ask a Question" tool doesn't work on iOS devices. See here, and here.
I can certainly confirm this to be the case, having first reported it myself in December 2017. The screenshot shown here was taken today, and is no different from how it displayed back then.
On clicking the blue "Ask a Question" form, it's possible to enter text into the "Subject" line, but there is no access to the box to complete the question text itself, and, as can be seen, other elements of the page overlap one another. - a real mess. I can also confirm that if I log in from my alternative account User:NM Demo (which uses only the default settings any newly signed up person would have), the problem is also seen there, too.
The issue is of special concern because new users who want to ask a question simply won't have sufficient knowledge to know what to do once the Teahouse's own form fails them. I'd really appreciate it if this could be investigated. Regards from the Teahouse, Nick Moyes (talk) 10:51, 9 March 2018 (UTC)[reply]
Oops, sorry. I can only speak for myself: iOS 10 (10.3.3 - if I'm reading my phone correctly). I've intentionally not updated to iOS11 as I understood that version 11 now saves image files in a format that renders them unreadable to Windows users. Please correct me if I'm wrong on that. Nick Moyes (talk) 11:02, 9 March 2018 (UTC)[reply]
@TheDJ: It's worth adding that I've just tried the similar-looking "Ask a Question" form at WP:CQ and I don't have any problem accessing the form's subject line, the main text entry box,or the Publish changes button, whereas that's not possible with the Teahouse's question box. Nick Moyes (talk) 11:07, 9 March 2018 (UTC)[reply]
@TheDJ: - thank you. I've just made a couple of test posts from a desktop PC and from my iPhone 5, and both post published OK. It's great when disabling something makes something else work properly. Regards, Nick Moyes (talk) 15:09, 9 March 2018 (UTC)[reply]
It does seem like a fairly important script. However it probably won't be trivial to rewrite it, at least if we use OOJS =p. I can't say if Community Tech would be able to work on this but feel free to create a phab task. You'd need to find something else to tag it with other than just community-tech, though :) — MusikAnimaltalk21:43, 9 March 2018 (UTC)[reply]
User talk namespace template message for updating accessdate
It's a common thing, I've noticed, for an editor to update the statistics for websites like Rotten Tomatoes and Metacritic, especially for films and television series, and not update the access-date parameter when they do so. Per the documentation of {{cite web}} for |access-date=: Full date when the content pointed to by url was last verified to support the text in the article [...] Note that access-date is the date that the URL was found to be working and to support the text being cited. This means that the parameter needs to be updated whenever the statistics are as well. For editors that do not do this, a user talk namespace template message would be handy; I was wondering if anything like this already existed. If it didn't, I was planning to create it. -- AlexTW12:23, 9 March 2018 (UTC)[reply]
Shortcuts (Ctrl+I, Ctrl+B etc.) don't work any more in source code editor
Hi, I recently discovered that these shortcuts don't work in source code editor. I remembered them to work before.
The weirder is, if you turned on syntax highlighting, upon pressing, say, ctrl+I, you can visually see the selected text became italic and then immediately changed back to normal.
I would like to get out all label=, lat= and long= tags. Do you know any linux commandline tool, which could do this? Sorry if that's not obvious to me.--Lazy Eight (talk) 07:22, 10 March 2018 (UTC)[reply]
I undid the last edit to the template, which seems to have fixed the problem for now. Honestly, I have no idea what that edit was trying to accomplish so I'm not sure if there would be a better way to do it. Paging DePiep, who made the edit. --R'n'B (call me Russ) 19:19, 10 March 2018 (UTC)[reply]
Is there any way to discard the "unsaved changes" of the visual editor. It's all very well that it saves them, but here am I, using VE for the automatic citation filler, then copyediting in source to use LDRs. Then, VE wants to revert those changes because they weren't made under VE. This is a problem, and could catch out somebody who discarded changes for a reason. ∰Bellezzasolo✡Discuss19:56, 10 March 2018 (UTC)[reply]
How to test that a date/time string is in "yyyy-mm-dd hh:mm:ss" format?
Need an explanation, or perhaps a pointer elsewhere. How can I check that a supplied date/time string is in yyyy-mm-dd hh:mm:ss format? Presumably with a suitable regex, but I can't find any parser functions for that. Do I have to dip into Lua? Is there a module for that? (I know regex, but having trying to avoid having to learn Lua.) ~ J. Johnson (JJ) (talk) 00:46, 11 March 2018 (UTC)[reply]
If you decide to go with Lua, I wrote a simple function dateFormat() that returns the format (dmy, mdy, iso, ymd) of a given date. In Module:Webarchive - it would need expansion to parse hh:mm:ss -- GreenC01:11, 11 March 2018 (UTC)[reply]
As others have said, please explain the purpose, preferably with an example of what would go in an article and what the wanted result would be. Module:Date can parse dates, see the examples in the documentation at {{extract}}. That template can tell you what format was used, but it only returns dmy, mdy or ymd.
If you use anything other than a plain regular expression, there is a danger the function will have limitations you didn't think about, like failing for dates before AD 100, regarding 29 February 1900 as invalid, etc. A full statement of the requirements is called for. Jc3s5h (talk) 02:24, 11 March 2018 (UTC)[reply]
Thank you all, those look like good ideas. The key element is that I want to check the format, not validate or return a date/time. Which I think I can work out now. ~ J. Johnson (JJ) (talk) 21:06, 11 March 2018 (UTC)[reply]
When we go to Preferences → Gadgets and scroll down to Appearance, the first checkbox is "Add an [edit] link for the lead section of a page". When this is checked, and when the "Move section [edit] links to the right side of the screen" preference is also checked, the edit link appears low enough to be sliced by the horizontal line that underscores the page title. This is unlike all the other edit links for later sections of an article. Those edit links are above the horizontal line that underscores section titles. Is it possible to raise the lead-section edit link so it appears above the line like the other edit links? (Note that if the "Move section [edit] links to the right side of the screen" preference is not checked, then the [edit] link comes right after the title and is positioned correctly above the horizontal line.) I use Windows 10 and have checked this in IE v11 and Chrome v65. Paine Ellsworthput'r there15:33, 11 March 2018 (UTC)[reply]
There is a rendering problem with this article, basically the title carries on way off the screen breaking the format and creating a bottom scrollbar where there would not be one normally, but the rest of the page stops short at it's normal breakpoint, leaving the title projecting on it's own. Prince of Thieves (talk) 01:15, 12 March 2018 (UTC)
~[reply]
The reported version is [16] which doesn't wrap the title for me in Firefox. I fixed the DISPLAYTITLE with word breaks to match the article name so the name can wrap at top of the article. It cannot wrap in other places like categories and search results. PrimeHunter (talk) 01:44, 12 March 2018 (UTC)[reply]
I see updated since my last visit in a lot of edit summeries. What does that mean? Is there some piece of automated software that's inserting that? It's a pretty useless edit summary, since it doesn't give somebody scanning the history any clue what changed, or why. -- RoySmith(talk)14:51, 12 March 2018 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Page Previews has been updated to use HTML for previews. This has fixed many issues. An A/B test was done on English and German Wikipedia to measure how it is used. Other changes were also made. [18]
Some edits have to be checked against too many conditions before they can trigger an edit filter. If that is the reason no filter is triggered the edit will be tagged for review. [19]
Auto-saving has been added to the visual editor and the 2017 wikitext editor. Right now it is meant to help if your browser crashes or if you accidentally close a tab. [20]
Problems
The abuse filter did not tag all edits that should have been tagged after last week's MediaWiki version had come to the wikis. It was fixed on 9 March (UTC). [21]
Changes later this week
You can notify users in edit summaries. They will get a ping just as if they had been mentioned on a wiki page. This was originally planned to happen last week. [22]
It is now possible to specify the block parameters for each filter in Special:AbuseFilter. The parameters include block duration and if the user should be blocked from editing their own talk page. The block duration is separate for anonymous and registered users. [23][24]
A hundred Wikimedia wikis will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 13 and 14 March. Other wikis will be recommended to switch soon when they have fixed the errors that must be fixed. Tidy will be removed in the middle of 2018. [25][26][27]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 March. It will be on non-Wikipedia wikis and some Wikipedias from 14 March. It will be on all wikis from 15 March (calendar).
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 13 March at 19:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 14 March at 16:00 (UTC). See how to join.
The English Wikipedia should be good to go as far as modifications to scripts are concerned, what hasn't been updated yet will be by Thursday. Keegan (WMF) (talk) 21:41, 12 March 2018 (UTC)[reply]
Enlarging text
Sorrowfully, I can't seem to find instructions for enlarging text in the edit window. I'll appreciate any help that comes in that regard. Thank you.--John Cline (talk) 05:55, 13 March 2018 (UTC)[reply]
On my browser I can do ctrl-mouse wheel rotation to enlarge or shrink all text. ctrl-shift-+ also enlarges. There would be a style sheet change that should change it too. Graeme Bartlett (talk) 06:01, 13 March 2018 (UTC)[reply]
OK style sheet change in User:John Cline/common.css: .mw-editfont-monospace {font-size: 200% !important;}
I've been thinking a lot about the gender gap on Wikipedia recently and would like to understand if there is a relationship between the gender of a biography articleand article deletions. Is there a way to know the gender of the subject of deleted biography articles?
The question I'd most like to understand is are biographies about women more or less likely to get deleted? and if there is a large difference, why does this happen.
Also related questions:
Are articles about women more or less likely to be nominated for deletion than articles about men and in general?
Are articles about women that are nominated for deletion more or less likely to be deleted than articles about men and in general?
Is the data to do this research available? And if so how ould it be collected?
Done Okay, I've asked them, and hopefully your question will be responded.Sincerely, User: Zanygenius(talk page) 16:49, 25 February 2018 (UTC)
Resolved
Wikis can enable Citoid to provide automatic reference look-up in the visual editor and the 2017 wikitext editor, but it is complex. The tool will now warn in the JavaScript console if the configuration isn't correct. Soon Citoid will disable itself if the configuration isn't correct. Check that your wiki is configured correctly. You can ask for help if you need it. [8]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 March. It will be on non-Wikipedia wikis and some Wikipedias from 7 March. It will be on all wikis from 8 March (calendar).
wikimedia.org, or the Programs and Events Dashboard group at dashboard
