Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 213.151.215.195 (talk) at 20:23, 13 March 2016 (→‎NBSP is not working). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


Unresolved issue is archived - How to "UN-Archive"?

Greetings, A problem awaiting resolution is now archived here and tracked at phabricator:T126553.

If it's not possible to pull back from archive, does it need to be re-posted again?

Regards,  JoeHebda (talk)  19:04, 27 February 2016 (UTC)[reply]

@JoeHebda: Just post the new question, with a link back to the archived thread. --Redrose64 (talk) 21:39, 27 February 2016 (UTC)[reply]
If I re-post again here, will it be archived again before the issue is solved? Just wondering... JoeHebda (talk)  02:19, 29 February 2016 (UTC)[reply]
Possibly; archiving bots do not take any notice of whether a thread has been replied to or not. Threads on this page are archived if they've not been posted to for five days. So if nobody responds here before the next bot run that occurs after 10:30, 5 March 2016 (UTC), it will be archived. --Redrose64 (talk) 10:30, 29 February 2016 (UTC)[reply]
Redrose64 – Thanks for the update. Yesterday I did repost the new VPT archive link to Wikipedia talk:User scripts#Fix needed: Gadget only works with Vector skin, script error which was orginally posted on Feb. 15th. Wondering if there might be a better place to post where the issue can be fixed? Without waiting for months for a resolution? If I knew anything about scripts (which I do not) I would attempt to fix myself. Regards,  JoeHebda (talk)  13:39, 29 February 2016 (UTC)[reply]

1) ω Awaiting a solution – also see: MediaWiki:Gadget-mobile-sidebar and Wikipedia:Gadget.  JoeHebda (talk)  13:45, 29 February 2016 (UTC)[reply]

@JoeHebda: You can use {{DNAU}} to prevent archiving. nyuszika7h (talk) 21:26, 29 February 2016 (UTC)[reply]

2) ω Awaiting a solution — JoeHebda • (talk) 12:08, 2 March 2016 (UTC)[reply]

3) ω Awaiting a solution — JoeHebda • (talk) 18:12, 3 March 2016 (UTC)[reply]

FWIW, i copied User:Brion VIBBER's script locally, and verified it works with "monobook" and "modern" after minor changes. i had to modify about 5 lines to use mw.util.$content instead of $('#content'), and add a line to incease z-index specifically for monobook: for some reason the left edge of the mobile image was overshadowed by the right edge of the content in monobook (i'm sure there's more . you can try User:קיפודנחש/mobile-sidebarcopy.js to verify it indeed works with other skins (you'll probably want to disable the gadget, or you may get 2 of them...). peace - קיפודנחש (aka kipod) (talk) 20:55, 3 March 2016 (UTC)[reply]
קיפודנחש – Thanks for helping. I know about testing computer programs in other languages but nothing about js scripts. If you or anther editor could explain the steps to test, I would be willing to try testing. So far, I did un-check existing Gadgets option to disable Mobile sidebar preview option. Regards, — JoeHebda • (talk) 21:36, 3 March 2016 (UTC)[reply]
to test the modified script, add to your personal script file the following line (if you copy from edit screen, *do not* include the "code" tags):
importScript('User:קיפודנחש/mobile-sidebarcopy.js');
(if the file does not exist yet, create it, add the line, and save. more detailed instructions and explanations about personal scripts can be found in WP:JS). peace - קיפודנחש (aka kipod) (talk) 22:15, 3 March 2016 (UTC)[reply]

קיפודנחש – Followed the test instructions & same results = Mobile sidebar preview works only with Vector skin & not the other skins. I did the Purge and logout for each; not seeing the little toolbar icon to activate preview. I know it is running the test version because I have the Gadgets one unchecked with Vector & icon shows & works correctly. — JoeHebda • (talk) 22:37, 3 March 2016 (UTC)[reply]

you are correct. it turned out to be more elaborate than i thought - the code Brian wrote displayed the phone nicely, but placing the icon for turning it on/off on the menu turned out to be a bitch... anywhoo, i at least made it so that you can use it now, though it's not really pretty when you use a skin other than vector. peace - קיפודנחש (aka kipod) (talk) 00:10, 4 March 2016 (UTC)[reply]
@JoeHebda: update: could not get the mobile on/off icon to look acceptable on monobook, modern and cologne blue, so on these skins, the on/off switch is text only (top row for mo*, left-menu under "Edit" for cologne). peace - קיפודנחש (aka kipod) (talk) 16:34, 4 March 2016 (UTC)[reply]
@קיפודנחש: – So far, it looks good and okay to me. For Cologn Blue, I am confused because I can not find any "Edit" anywhere on the page; not on top or left sidebar. I do see a "Mobile view" but that is just for switching the entire page between Mobile/Desktop views. Wondering where to look? — JoeHebda • (talk) 16:48, 4 March 2016 (UTC)[reply]
@JoeHebda: i practically never use cologne, and not aware of all its idiosyncrasies. for me, using this skin, when i am on a page i am allowed to edit, i see in the left-hand menu column "Edit". i verified that this is so even as anon (you can test any skin by appending to the address line "?useskin=<skinname>". this works for anons too. names are [ vector monobook modern cologneblue ]). i also verified that the script causes "Mobile" to appear there even for anons. there might be something in your prefs that causes it not to show, or maybe it *does* show and for some reason you missed it. HTH, peace - קיפודנחש (aka kipod) (talk) 17:58, 4 March 2016 (UTC)[reply]

קיפודנחש – Yes, I did find it now. I had to set my custom CSS font-size to 155 percent for Cologne Blue skin to help overcome a line-height issue making that skin very hard to read. And the Mobile preview sidebar works okay there as well. Just a FYI, I found a report of User skin preferences at Wikipedia:Database reports/User preferences#Skin. Thanks so much for getting Mobile to work correctly with these skins! IMO not seeing the little toolbar icon is a lesser (non-structural) issue.

Now in order to go live with this script, what needs to be done? Once it is out there I will check On in Gadgets. Then, could the Mobile sidebar preview line of Gadgets be moved out of the Testing and development section? Perhaps move into Appearance section? Cheers! — JoeHebda • (talk) 19:13, 4 March 2016 (UTC)[reply]

@JoeHebda: i saw this more as an experiment, to gauge the amount of change needed to make mobile-sidebar work with other skins. ideally, User:Brion VIBBER would patch the script on meta to work with all skins (TBH, Brion needs me to tell him how to do that exactly as much as i need my grandson to teach me to suck eggs). if, for any reason, Brion doesn't do it, enwiki can decide that limiting this gadget to vector is acceptable. the very last resort would be to change the gadget on enwiki to consume Brion's css file from meta, and the modified js file from my userspace (or some copy of it). this last option is both undesirable and unlikely. if none of those options is executed, people who do not use vector can consume my modified script privately, the same way i listed above and you tried. peace - קיפודנחש (aka kipod) (talk) 20:31, 4 March 2016 (UTC)[reply]
@קיפודנחש: – Thanks for the answer. It sounds complicated, but I think I understand. For now, I will leave the test js in place and wait until resolved. Cheers! — JoeHebda • (talk) 13:51, 5 March 2016 (UTC)[reply]

Edit toolbar rarely loads

Recently I am experiencing problems when editing wikicode that edit toolbar rarely loads. Also box with symbols under edit window is not clickable and I cannot initiate page to edit it in Visual Editor.--Juandev (talk) 17:29, 5 March 2016 (UTC)[reply]

@Juandev: I'm not sure if this is the reason, but i would highly advice against messing with the load order. —TheDJ (talk • contribs) 11:04, 9 March 2016 (UTC)[reply]

Many thx, I am testing that.--Juandev (talk) 08:05, 12 March 2016 (UTC)[reply]

Images not showing, attempting to click on their root page will result in 404 error

Hi, I posted the same issue six months ago and the problem has not been solved for me. It occurs on all devices, logged in or out, and is not network-dependent or operating system dependent (happens on Ubuntu 15.10 and Windows 7/10). Both Wikimedia Commons and Wikipedia-based images do not load. I believe that I have seen the issue occur on Internet Explorer and Firefox -- but I cannot remember for sure (this issue is a regular occurance, but is very transient and random at the same time). Thanks, My name isnotdave (talk/contribs) 17:34, 5 March 2016 (UTC)[reply]

How do you know its not related to network or ISP?--Juandev (talk) 19:18, 5 March 2016 (UTC)[reply]
It's not ISP-specific because I receive the same problem at another house, or at school for example. My name isnotdave (talk/contribs) 20:34, 5 March 2016 (UTC)[reply]
So you know, that another house or school does not have the same ISP for sure? I think we need to look on it in deep and check these:
  • DNS (try google DNS 8.8.8.8.)
  • browser (try different browser)
  • wp user settings (try to do that, when log off)
  • other PC settings (try to test friends PC at home)
  • ISP (try it with your computer via different ISP)
  • bandwith (test your bandwith, when the problem starts)
  • PC performance (see for free disk space on your PC and other free available resources)
  • local geoblocking (contact your ISP weather there is any of these in your area or ask on the Internet)
Juandev (talk) 07:58, 7 March 2016 (UTC)[reply]
@Juandev: I know that both my grandads use different ISPs, one uses Virgin Media and the other uses TalkTalk respectively -- I use BT. I did try that DNS but it caused too many issues in the way -- I will try others. My name isnotdave (talk/contribs) 13:53, 8 March 2016 (UTC)[reply]
I am not here so often, but you can conntacte me via cs:Diskuse s wikipedistou:Juandev, if I dont respond longer time.--Juandev (talk) 08:08, 12 March 2016 (UTC)[reply]

“TypeError: mw.util is undefined”

Error messages from Firefox. First I'm told that mw.util is undefined, then I'm told that something else is deprecated and that I should use mw.util instead. As a result, I don't see a number of links which are supposed to be created by my global.js script. Any idea what's wrong? Note that Firefox also produces warnings that a bunch of other things also are deprecated between these two warnings, but I don't see anything which would explain why I'm told to use something which is apparently undefined. --Stefan2 (talk) 21:27, 5 March 2016 (UTC)[reply]

Looks like a load order error. If it's running before some stuff from the mediawiki (shortcut mw) object is defined, wrapping it in $().ready(function () { /* code goes here */ }) might help; otherwise I'd be suggesting the mw.loader.using helper. {{Nihiltres |talk |edits}} 01:27, 6 March 2016 (UTC)[reply]
It seems that the problem disappeared when I added $(mw).ready(function(){ at the beginning of my userscript and }); at the end of my userscript, but I think that it would be better if Mediawiki did this automatically for all userscripts instead of confusing users. I suspect that quite a lot of userscripts depend on the mw object. Thanks for the help! --Stefan2 (talk) 11:51, 6 March 2016 (UTC)[reply]
@Stefan2:. Thats still wrong unfortunately (and only works per chance). Please see ResourceLoader documentation, for the right way to write userscripts that depend on resourceloader modules. And you need to declare this dependency on mw.util, because the only modules that are always loaded by default are mw and mw.loader. Because many other components also load mw.util, it can often go unnoticed that you had forgotten to declare this dependency, but global scripts are loaded a bit earlier than most other user scripts, so that might surface the problem a bit quicker than other modules might have. —TheDJ (talk • contribs) 11:15, 9 March 2016 (UTC)[reply]

Search error in Template:Search deletion discussions

Clicking on "Search Deletion Discussions" in Template:Search deletion discussions (which is transcluded on Wikipedia talk:Articles for deletion) will always generate "An error has occurred while searching: Search request is longer than the maximum allowed length." regardless of what you type in the search box. Even leaving the box empty will generate that error when you click on the button. GeoffreyT2000 (talk) 03:51, 7 March 2016 (UTC)[reply]

The error message ends with for example "(663 > 300)" for me. A length limit of 300 was set in September at phab:T107947. {{Search deletion discussions}} must be changed to greatly reduce the length. There is another problem. It uses {{Search prefixes}} which makes searches with a syntax that doesn't currently work when you select multiple prefixes. For example, {{Search prefixes|Wikipedia:Articles for deletion|Wikipedia:Categories for discussion}} produces:
A search on X becomes X prefix:Wikipedia:Articles for deletion|Wikipedia:Categories for discussion. It's apparently meant to search two prefixes separated by a pipe but that doesn't happen. It gives no results and maybe interprets it as a single long prefix. PrimeHunter (talk) 09:55, 7 March 2016 (UTC)[reply]
The template could be fixed, but since it isn't used much, I wonder if it would be better to get rid of it and hard-code the searching code into Wikipedia:Deletion process. — This, that and the other (talk) 11:00, 8 March 2016 (UTC)[reply]

External links by page type

I'm looking at a Special:LinkSearch page:

https://en.wikipedia.org/w/index.php?target=www.ted.com&title=Special%3ALinkSearch

but am finding results in user pages and so on; I only want links in articles.

Adding &namespace=0:

https://en.wikipedia.org/w/index.php?target=www.ted.com&title=Special%3ALinkSearch&namespace=0

doesn't do the trick; is there another method I can use? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:54, 7 March 2016 (UTC)[reply]

It's trivial to search for URLs using Special:Search and insource:. E.g. www.ted.com. More info at mediawikiwiki:Help:CirrusSearch#insource:. --Izno (talk) 15:55, 7 March 2016 (UTC)[reply]
Thank you. Unfortunately, that does not number its results, making it harder to determine the total number found. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 7 March 2016 (UTC)[reply]
quarry:query/7901. --Edgars2007 (talk/contribs) 16:49, 7 March 2016 (UTC)[reply]
@Edgars2007: Thank you - that looks like what I need. Two Qs: Is "en" in FROM externallinks enel the identifier for the English Wikipedia (and so frel for French. etc)? and how do I get http and https links? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:57, 8 March 2016 (UTC)[reply]
I modified the query, so it "answers" to both questions. --Edgars2007 (talk/contribs) 12:02, 8 March 2016 (UTC)[reply]
That was very helpful, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 11 March 2016 (UTC)[reply]

@Pigsonthewing: The quarry search from Edgars2007 is sensational, but for completeness it is also possible to write a script which uses the API. That can produce formatted lists for contemplation. See this VPT archive for my example in case it is of interest. Johnuniq (talk) 04:10, 11 March 2016 (UTC)[reply]

Thank you. I'll take a look. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 11 March 2016 (UTC)[reply]

Error when attempting to delete files

Tracked in Phabricator
Task T128096
Tracked in Phabricator
Task T129212

In trying to delete File:Iiac.png and File:SLAF Palaly Crest.jpg as orphaned files in batch deletion via Twinkle, I run into similar error messages: Error deleting file: The file "mwstore://local-multiwrite/local-deleted/a/j/b/ajbyzg02hhch9vwtsilxeaqnhdxfpz8.png" is in an inconsistent state within the internal storage backends. I ran into this problem when trying to delete other files, but I was able to get them deleted on the second try. I simply can not get the two aforementioned files deleted. Attempting to delete the files individually has not resolved the problem. Any ideas as to why this issue is occurring? — ξxplicit 02:50, 8 March 2016 (UTC)[reply]

That phab is so 4-days-ago and was closed. It happened again later, see phab:T129212, and (again) seems resolved. DMacks (talk) 22:58, 8 March 2016 (UTC)[reply]

Preferred protocol for external links templates

I recently modified {{TED speaker}} to use https://www.ted.com/speakers/ instead of http://www.ted.com/speakers/.

Would it be better to use //www.ted.com/speakers/? Is there a policy/ MoS page describing this? Should we apply the latter to all external link templates for sites which use both protocols? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:50, 8 March 2016 (UTC)[reply]

We only serve our content as https these days, so there should be a preference for https (since relative protocol does nothing in that case). I know of at least one user (Bender something or other) actively converting Internet Archive and Google links to https, so there is precedent. --Izno (talk) 12:14, 8 March 2016 (UTC)[reply]
@Pigsonthewing: There is no policy, but we do have an essay, WP:PRURL. --Redrose64 (talk) 16:43, 8 March 2016 (UTC)[reply]
WP:EL mentions it at WP:External links#Links to Wikimedia vs. to elsewhere. That essay hasn't been updated to take into account the two RFCs regarding IA and Google, or the fact we only serve our content via HTTPS, so I would be careful referencing it (especially since the word "preferred" gets used, when in fact it's not). --Izno (talk) 17:11, 8 March 2016 (UTC)[reply]

Thank you, all. Time for an RfC? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 8 March 2016 (UTC)[reply]

@Pigsonthewing: As Izno indicated, Bender235 has for some time been changing http: to https: for Google and Internet Archive (Wayback Machine), per this RfC result, with no objections that I am aware of. PRURL could have been used instead in those cases, but he and others decided https: was preferable. If this is the same situation I don't see the need for another RfC. Here's some related user talk from last year. ―Mandruss ☎ 11:34, 9 March 2016 (UTC)[reply]
I don't see any reason to still use PRURL. Wikipedia is now delivered HTTPS-only, and this won't change any time soon.--bender235 (talk) 15:21, 9 March 2016 (UTC)[reply]
Because HTTP HTTPS might be extremely slow as companies use a single server to MitM and we have reusers who use HTTP and dislike the expense and complexity of encryption. Also, I've noticed we're being overrun by political activists who are undermining the encyclopedia's neutrality to benefit their own groups. — Dispenser 17:21, 10 March 2016 (UTC)[reply]
I assume you had a typo there and meant HTTPS ("because HTTP"). Those rationale are not a defense of continuing to link to HTTP rather than HTTPS where we know that there is an available HTTPS link. --Izno (talk) 17:46, 10 March 2016 (UTC)[reply]
Dispenser: Those who dislike the expense and complexity of encryption will avoid Wikipedia in the first place. Check your address bar, Wikipedia uses encryption. Re your political activists comment, I don't see how that applies to this thread. ―Mandruss ☎ 20:47, 10 March 2016 (UTC)[reply]
(Fixed typo, sorry) Making HTTPS available is (mostly) non-political, disabling HTTP is political. Why close the option to our reusers? — Dispenser 23:02, 10 March 2016 (UTC)[reply]
Fixed your typo fix per standard (this allows future readers to make sense of Izno's response). ―Mandruss ☎ 23:20, 10 March 2016 (UTC)[reply]
Why are our reusers relevant? The ones who care about their security will accept the HTTPS; the ones who don't but who don't want HTTPS and care will rewrite the various linkage; and the ones who don't and don't and don't care... well, we don't care about them. This was mostly covered in the two RFCs related to HTTPS linking for IA and for Google. --Izno (talk) 02:04, 11 March 2016 (UTC)[reply]
Reuse is part of the WP:Five pillars, that's why its important. And your argument amounts to more pointless work for reusers. — Dispenser

db-c1

Does {{db-c1}} (empty category) contain a timer like PROD to say when four days are up? Should it be added when a category is first empty, or should one wait four days before adding? How does one tell whether a category has been empty for four days? JohnCD (talk) 12:33, 8 March 2016 (UTC)[reply]

The template does contain a timer; you should add {{db-c1}} when the category is first empty. -- John of Reading (talk) 12:55, 8 March 2016 (UTC)[reply]
It relies on two things: (i) that nobody edits the cat page after the {{db-c1}} is added, otherwise {{REVISIONTIMESTAMP}} gets reset; (ii) that someone or something WP:PURGEs the cat page at some point after four days, to get the cat page out of Category:Empty categories awaiting deletion and into Category:Candidates for speedy deletion/Category:Candidates for speedy deletion as empty categories. --Redrose64 (talk) 16:51, 8 March 2016 (UTC)[reply]
(i) is gnerally not an issue - empty categories are rarely edited. As to (ii), these categories do end up at CSD on a fairly regular basis - I believe that Joe's Null Bot is responsible for this. עוד מישהו Od Mishehu 11:33, 9 March 2016 (UTC)[reply]

Why a url is blacklisted?

How do I find out why a url, for "llegalemapas", is blacklisted? It is in the black list but I cannot see it in the black list log ? I wanted to use it in Samdech Euv High School. Eno Lirpa (talk) 15:25, 8 March 2016 (UTC)[reply]

@Eno Lirpa: If you can't find a URL on the English Wikipedia's blacklist (MediaWiki:Spam-blacklist), then you should check meta's one (meta:Spam-blacklist). From a little digging it was added there in July 2007 as a result of this request. Sam Walton (talk) 15:28, 8 March 2016 (UTC)[reply]
Thank you. Eno Lirpa (talk) 11:26, 9 March 2016 (UTC)[reply]

Implementation of editormeter, that depends on time.

Wikipedia has counter of edits, but can it depend on time? For example, with {{NUMBEROF:|Edits|en|01.01.2016 10:00:01|01.01.2016 12:00:01|N}} we will obtain the number of changes, that were made from January 1, 2016 from 10 hours 00 minutes and 01 seconds to 1 January 2016 to 12 hours 00 minutes and 01 seconds. Is it any technical realization of such or similar counter? Thanks! Ігор Пєтков (talk) 19:34, 8 March 2016 (UTC)[reply]

I'm not aware of any template that gives edit counts on a specific date or time. There is, however, a well-maintained page with the exact time of 10 million edit increments and a Wikiproject dedicated to edit counters. It is likely possible to make a module loop around to find a diff number at a specified time to get what you're describing, but you'd need to be careful not to exceed the expensive operation limit. Mamyles (talk) 20:28, 8 March 2016 (UTC)[reply]
This feature is incorporated to X!'s tools on a user basis. For example, see my edits. – Finnusertop (talk ⋅ contribs) 21:14, 8 March 2016 (UTC)[reply]
True, Range Contributions is close to his requirements, but is for a specified list of users and does not use time. Mamyles (talk) 22:51, 8 March 2016 (UTC)[reply]
It's not currently possible to do this in Lua - the Lua API doesn't include any access to page histories or user contributions. It would have to be done via some other means (probably a tool or bot). — Mr. Stradivarius ♪ talk ♪ 23:46, 8 March 2016 (UTC)[reply]

Cross-wiki notifications alive on Beta on your wiki March 11th, 00:00UTC

Greetings!

As you may have noticed on the last Tech News issue, Collaboration team is please to announce that Cross-wiki notifications will be available as a Beta feature on all wikis by March 11th, 00:00UTC (it has been rescheduled).

Cross-wiki notifications will help you know about some activity on another wiki. How does it work? Imagine someone thanks you on Commons - the next time you open a page on English Wikipedia, you'll see that notification from Commons! We hope this will help everyone who is active on multiple wikis. You will find more information in the documentation.

Of course, it is a Beta Feature. We have tested many possible cases on test wikis, and then release that feature one month ago on MediaWiki.org, Commons, Wikidata, French and Hebrew wikis. That first release allowed us to solve encountered problems, but if you experience some bugs (and we are sorry about that), please report them on the dedicated page. That page is also open to feedback and suggestions.

To activate the feature, you will have to go on the 11th of March to your preferences, Beta tab, and select the "Enhanced notifications" checkbox. You will then receive Notifications when they happen on any other wiki (and may the unread ones posted a long time ago). You will receive these notifications only on the wiki where you have activated the feature. If you do not activate it, nothing will change on your Notifications panel.

If you have any questions, please mention me.

All the best, Trizek (WMF) (talk) 11:14, 10 March 2016 (UTC)[reply]

Yay! --Izno (talk) 17:48, 10 March 2016 (UTC)[reply]
The beta feature is enabled now. You can enable it by going to the beta tab on the preferences page and enabling "Enhanced notifications". We hope you like it, and should you encounter any issues, please let us know. --Roan Kattouw (WMF) (talk) 00:34, 11 March 2016 (UTC)[reply]

Server migration will prevent editing

Just an update on the codfw server migration:

Regulars here may recall that Ops is planning to temporarily put all the wikis into read-only mode when they're launching the new data center in Texas during the week of 21 March. Here are a few more details:

What to expect

  • The read-only disruption will happen TWICE, once on Tuesday, 22 March (at the start of the tricky bits) and once on Thursday, 24 March (at the end of the tricky bits).
  • There will probably be a five-minute test of read-only mode next week. Details are being discussed.
  • The time of day has not been determined yet. Ops normally does things during low traffic periods, so my guess is approximately 07:00 UTC (midnight in California).
  • The read-only mode for the actual event will probably last 15 to 30 minutes each time (longer than initially hoped for, but this estimate sounds more realistic). If you try to edit or save during this time, then you'll get an error message about the wiki being in read-only mode (not the 'blue screen of death').
  • If you get that error message when trying to save the page, just hang on; you should be able to save your edit once everything's back to normal. (But please make a copy first, just in case it fails.)
  • Bots and scripts may need to be restarted afterwards. Some pages may need to be purged (or just wait a bit for the jobs to catch up), e.g., if you see a redlink but the page was recently created.

Communications issues

  • If you are a regular on the IRC channels, please be prepared for lots of people reporting the "unexpected outage". It might be a good idea to change the headers during these events to let people know what's going on. I hope to get an explanation for this project posted soon, so a link to that might help.
  • I'm working on CentralNotices and MassMessages to all the wikis.
  • I'd like to see watchlist notices up at the bigger projects, starting approximately now. What do you all think of that idea?

I'll post more here as their plan develops. Please share this information. Whatamidoing (WMF) (talk) 16:55, 10 March 2016 (UTC)[reply]

We can certainly watchlist notice this - is there a good link to a page describing the activity, etc (besides this?). — xaosflux Talk 17:00, 10 March 2016 (UTC)[reply]
Midnight in California is 7:00 UTC from March 14 to November 6 because it is Daylight Saving Time. 63.251.215.25 (talk) 17:24, 10 March 2016 (UTC)[reply]
Xaosflux, there's no useful page at the moment, but I hope that one will be available soon. There's a Phab project, and various pages on mw.org that discuss technical aspects of it, but there's nothing in plain English or intended for humans. What do you think about a watchlist notice that says something like this:
Wikimedia Technical Operations is planning a major infrastructure migration on Tuesday, 22 March and Thursday, 24 March. This process is expected to take 15 to 30 minutes each time. During these times, you will be able to read, but not edit any page. We apologize for the disruption.
When we get a useful page posted, then we could link the words "a major infrastructre migration" to that explanation. Whatamidoing (WMF) (talk) 17:37, 10 March 2016 (UTC)[reply]
Sounds good to me. Titoxd(?!?) 18:47, 10 March 2016 (UTC)[reply]
Whatamidoing (WMF) We usually don't like to run these more than a week in advance, when ready (hopefully with the completed link) please drop a note at MediaWiki talk:Watchlist-details and we will get it live. — xaosflux Talk 23:13, 10 March 2016 (UTC)[reply]

Vaguely related question: I had understood that the servers were in Florida, does this mean they will all then be in Texas? And, if so, does that have any legal ramifications for us as editors, or is state law not relevant and only Federal law is controlling? BMK (talk) 02:59, 11 March 2016 (UTC)[reply]

IMHO, now you could post some small notice, that it will happen (in case, there are some planned editathlons etc.). Some watchlist notices, big notification in pumps and other things could be done some few days before the thing. Because if the only sent message will be now (11 days before it will happen) most people will forget it. --Edgars2007 (talk/contribs) 09:33, 11 March 2016 (UTC)[reply]
BMK, I'd have to ask, but I believe that the main servers are in Virginia. There are also some in Amsterdam and California. I'm not sure that there are any servers in Florida.
Edgars, I'm thinking about watchlist notices soon, and sitenotices at the "last minute". (Someone suggested the last two hours before it happens.) Whatamidoing (WMF) (talk) 18:04, 11 March 2016 (UTC)[reply]
If memory serves, there are no servers in Florida anymore, but another cluster is being set up in Texas.Jo-Jo Eumerus (talk, contributions) 18:21, 11 March 2016 (UTC)[reply]
You are correct. I had a chance to ask about the setup, and I have learned the following: The main data center is in Virginia. The new one in Texas (this whole thing about temporarily not being able to edit has to do with work on the new one) is going to be a full copy of the main data center. The other two are cacheing servers. The one in Florida was dismantled a while ago. The basic idea with this process is to make everything (or everything they can, since the new data center doesn't have quite everything yet) run from the Texas data center for two days, and then to go back to Virginia. They have multiple reasons for doing this, but it's also good for disaster recovery – sort of like making sure that you can actually restore from a backup if you needed to, rather than waiting until your computer dies and then discovering that your backup drive failed, too. A tornado in Virginia could wreak a lot of havoc on Wikipedia, and we'd all like the servers to get back up and have Wikipedia be editable ASAP after that.
BTW, Ops posted their schedule at https://wikitech.wikimedia.org/wiki/Switch_Datacenter#Schedule_for_Q3_FY2015-2016_rollout Presumably that would be a good place to look for updates (keeping in mind that when Ops says that all the wikis will be in read-only mode, that even Ops won't be able to edit that wiki page). Whatamidoing (WMF) (talk) 19:54, 11 March 2016 (UTC)[reply]
Thanks for the correction and the information, much appreciated. BMK (talk) 00:02, 12 March 2016 (UTC)[reply]
Yes, the move from Florida to Virginia was just over three years ago, see Wikipedia:Village pump (technical)/Archive 107#Brief read-only test on English Wikipedia in 25 minutes and Wikipedia:Village pump (technical)/Archive 107#Wikimedia sites to move to primary data center in Ashburn, Virginia. Read-only mode expected. --Redrose64 (talk) 11:05, 12 March 2016 (UTC)[reply]

What to do about tens of thousands of unnecessary parser functions on user talk pages?

The template {{Welcome to Wikipedia}} was poorly coded for a substantial length of time (now fixed), which resulted in large quantities of unsubstituted parser functions being added to many user talk pages.

This search suggests possibly thousands of pages being affected, and those that are, will have around eleven nests of 1 * parser function acting on the result of 1 * module invocation.

If only half the total user talk pages from that search have 10 of these nests each, that's around 100,000 unnecessary wastes of server resources! This guesstimate is ballpark.

Prior to the poor coding, the template was not leaving unresolved parser functions behind, the wording of the substed result has been altered over time, and unfortunately my suggestion to add a tracking link years ago went down like a lead balloon - so it isn't trivial to find the broken ones (manually).

So, with that said, I ask:

  1. Should these stray and unnecessary parser functions out in the wild, be fixed?
  2. To do it manually would be insensible; is there a currently approved bot that can be tasked to do the work?
  3. Would it be acceptable to set about fixing these things by use of the API in a semi-automated fashion?

etc.

Originally posted at Wikipedia:Administrators' noticeboard/Incidents#What to do about tens of thousands of unnecessary parser functions on user talk pages?, and reposted here by suggestion. I considered coming here first, but figured that major automated editing is pretty much certainly going to need approval from the higher ups eventually, so why not cut to the chase? fredgandt 02:31, 11 March 2016 (UTC) and going to sleep now[reply]

I'm no technical expert, but my understanding is that simply "fixing" these by removing the parser functions with a new edit doesn't save any server resources whatsoever, since the "bad" edit is kept in memory anyway. Now, if having those parser functions (whatever they are) is doing something bad (as opposed to just taking up space), that could be an argument for getting rid of them, but that doesn't seem to be the argument you're making. In any event, I could well be entirely wrong, so let's see what someone more technically knowledgeable than I has to say about it. BMK (talk) 02:55, 11 March 2016 (UTC)[reply]
We shouldn't generally be worried about using server resources, and I don't think the module calls and parser functions would increase the time for the page to be parsed by very much anyway. The main advantage is that by expanding the parser functions etc. you are guaranteed to have the same text on the page each time. As it is, changing Module:IPAddress would change the text that was displayed on those talk pages. There is also the fact that it makes the page's wikitext easier to understand, which is likely to be more helpful for newcomers. — Mr. Stradivarius ♪ talk ♪ 05:41, 11 March 2016 (UTC)[reply]
It would be significantly more disruptive to edit all those pages to expand those parser functions than whatever downside they currently have. Even if you use a bot account to suppress new messages notifications, you'd still be adding watchlist entries and whatnot. Legoktm (talk) 06:03, 11 March 2016 (UTC)[reply]
Manually fixing one affected user talk page (selected with no prejudice) gives these results:
Before
<!-- 
NewPP limit report
Parsed by mw1255
Cached time: 20160311084804
Cache expiry: 3600
Dynamic content: true
CPU time usage: 0.499 seconds
Real time usage: 0.748 seconds
Preprocessor visited node count: 8919/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 61821/2097152 bytes
Template argument size: 18596/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 9/500
Lua time usage: 0.054/10.000 seconds
Lua memory usage: 1.75 MB/50 MB
Number of Wikibase entities loaded: 0-->

<!-- 
Transclusion expansion time report (%,ms,calls,template)
100.00%  344.405      1 - -total
 22.24%   76.588     11 - Template:Category_handler
 16.33%   56.250      1 - Template:Flatlist
 15.32%   52.777      9 - Template:Lang
 15.29%   52.670     17 - Template:Xt
 13.81%   47.559      1 - Template:Citation_needed
 10.76%   37.046     45 - Wikipedia:Signpost/Template:Cover-item
  9.29%   31.997      1 - Template:Fix
  7.98%   27.500      1 - Template:Lafc
  6.36%   21.894     50 - Template:Ping
-->

<!-- Saved in parser cache with key enwiki:pcache:idhash:47307636-0!*!0!!en!3!* and timestamp 20160311084803 and revision id 708865513
 -->
After
<!-- 
NewPP limit report
Parsed by mw1239
Cached time: 20160311085217
Cache expiry: 3600
Dynamic content: true
CPU time usage: 0.475 seconds
Real time usage: 0.725 seconds
Preprocessor visited node count: 8831/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 61371/2097152 bytes
Template argument size: 18596/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 9/500
Lua time usage: 0.036/10.000 seconds
Lua memory usage: 1.57 MB/50 MB
Number of Wikibase entities loaded: 0-->

<!-- 
Transclusion expansion time report (%,ms,calls,template)
100.00%  297.007      1 - -total
 20.72%   61.548     11 - Template:Category_handler
 15.72%   46.687     17 - Template:Xt
 15.15%   44.988      1 - Template:Flatlist
 14.20%   42.177      1 - Template:Citation_needed
 14.17%   42.085      9 - Template:Lang
 12.96%   38.479     45 - Wikipedia:Signpost/Template:Cover-item
  9.06%   26.906      1 - Template:Fix
  8.76%   26.011      1 - Template:Lafc
  7.93%   23.553     50 - Template:Ping
-->

<!-- Saved in parser cache with key enwiki:pcache:idhash:47307636-0!*!0!!en!3!* and timestamp 20160311085217 and revision id 709504667
 -->
Multiplied by an guesstimated minimum of 5000 pages = significant IMO.
Aside from the performance concerns, Mr. Stradivarius makes a fair point that the intended result of these clusters of code isn't reliable. fredgandt 09:11, 11 March 2016 (UTC)[reply]
P.S. Not to mention the removal of 1295 bytes of unnecessary markup. fredgandt 09:20, 11 March 2016 (UTC)[reply]
Exactly what is being saved here? Hundredths of a second? Considering that user talk pages aren't heavily trafficked to worry about saving a few hundredths of a second, it simply isn't worth the trouble. —Farix (t | c) 12:31, 13 March 2016 (UTC)[reply]
I agree with Farix: it's not worth the trouble. Since the traffic is so small, and the number of pages affected also small relative to the overall size of the Wikipedia page set, I think this is not a significant enough issue to be worth going back and fixing retroactively. We have far bigger problems that need fixing more urgently than this. Having said which, if you want to go write a bot to fix this, I won't object to your doing so -- but please note that it's unlikely to save any significant amount of resources relative to overall use. -- The Anome (talk) 12:50, 13 March 2016 (UTC)[reply]
Although the ms savings per page seem relatively tiny, if we say 5000 pages * edited twice per month * 24ms of CPU time = 4 minutes of CPU time per month for nothing.
Even if only in principle, I think the saving is worth the effort. If I build a bot to resolve wild parser functions (don't hold your breath), should I make it specifically for this set or include an option to train it for other cases? fredgandt 14:05, 13 March 2016 (UTC)[reply]
"Saving" 4 minutes a month of CPU time is woefully insignificant compared to the number of hours you will take to create, test, and execute a bot to "fix" these parser calls wasting far more CPU time than you are "saving". And I serous doubt that 4 minutes is anything but a gross over estimation of the amount of time it takes to render these pages. If you are worried about 4 minutes per month, then I must point you to Wikipedia:Don't worry about performance. —Farix (t | c) 14:34, 13 March 2016 (UTC)[reply]
I've already been pointed at wp:PERF and read it, and point you to the last three significant sections. The hours I spend doing anything is entirely my concern; what's relevant here is whether to clean a little unnecessary muck from the gears or not? A simple question which doesn't need to be so aggressively challenged. You've stated you opposition, and it's been read. fredgandt 14:57, 13 March 2016 (UTC)[reply]

User:Amylieumedia query

Hello all. I have been tracking certain abuse filter logs and was stumped by one particular edit filter entry. As per this edit filter entry, User:Amylieumedia made (or rather, tried to make) a certain edit which the edit filter recorded. But as per the user log, such a user does not exist and in fact is not even registered. How is that possible? Any inputs would be welcome. Many thanks. Xender Lourdes (talk) 12:32, 11 March 2016 (UTC)[reply]

User talk:Amylieumedia shows a renaming. It's also in the user rename log. PrimeHunter (talk) 12:38, 11 March 2016 (UTC)[reply]
There you solve it in a jiffy while I thought I had found a bug. Many thanks again. Xender Lourdes (talk) 12:41, 11 March 2016 (UTC)[reply]

Strip marker problems with nowiki tags

Whence came the oddness in infobox television episode?

Example 1
Above
Header
Example 2
Above
Header

Compare the infobox formatting in The Foretelling and The Archbishop - the title in the blue header in the infobox is larger and horizontally-centred in the latter (which is correct), but smaller and left aligned in the former (which is wrong, I think). I've recently made an (unrelated) edit to The Foretelling, so presumably it's showing the change there because the caches were flushed by my edit. Test editing The Archbishop shows the same defect in it, were it to be saved. The infobox by itself, in my sandbox, has the defect. So I think there's something gone wrong with the infobox template(s). That infobox is {{Infobox television episode}}, which depends on {{Infobox}}. I don't see a relevant change in the history of either. It's a pretty subtle change, so I can well understand how it can have been overlooked for some time. Can anyone see what might be causing this? -- Finlay McWalter··–·Talk 14:30, 11 March 2016 (UTC)[reply]

Oddly, the issue is caused by the addition of {{abbr}}. See the current sandboxed version utilising the HTML entity . in place a a natural period character - Template:Infobox television episode/sandbox. This appears to be the fix. I would appreciate confirmation from other editors before pushing the change live. fredgandt 14:57, 11 March 2016 (UTC)[reply]
Request placed at the template talk page - awaiting feedback. Albeit a seemingly trivial change, look what a dot in the wrong place can do! fredgandt 15:03, 11 March 2016 (UTC)[reply]
At least in my sandbox, your proposal doesn't seem to manifest as a fix ☹ Finlay McWalter··–·Talk 15:07, 11 March 2016 (UTC)[reply]
Yeah, that's not good . However, although not a fix, it is the problem. At least that's one part of the equation. I'll continue looking into it. fredgandt 15:15, 11 March 2016 (UTC)[reply]
Whoever fixes this might also fix the centering of the title parameter in mobile view. – Jonesey95 (talk) 15:28, 11 March 2016 (UTC)[reply]
Apparently whatever happened during my initial evaluation was an anomaly which I cannot duplicate; some kind of caching ghost or something. I thought it unusual that the use of a period in a simple template should be any problem, but that's what I saw. I will have another look at it in a while, but need to bathe my dog and rest my eyes (too many curly braces!). It's more than likely something more obvious that a stray period - like a style declaration -_-  fredgandt 15:38, 11 March 2016 (UTC)[reply]
We had a similar problem with {{Infobox television}} today. (See the discussion). The problem there seemed to be related to links to a subpage. The ability to customise the colour used in Infobox television was removed a long time ago but {{Infobox television/colour}} exists to allow 14 of the 37,122 articles using the infobox to still have differently coloured infoboxes. (I don't know why!) In order to solve the problem I simply commented out the links.[1] I don't know why it worked, as there have been no recent changes to the template and this has been working for years. --AussieLegend (✉) 15:44, 11 March 2016 (UTC)[reply]
I've now made the same change at {{Infobox television episode}} and the problem seems to be fixed. Please hold all applause for the person who can explain why this fixed the problem, because I have no idea. --AussieLegend (✉)
I believe there was some change to how nowiki tags are parsed since this seems to have fixed it. Frietjes (talk) 16:25, 11 March 2016 (UTC)[reply]
another one and here. Frietjes (talk) 16:28, 11 March 2016 (UTC)[reply]
I added two examples to show that it's <nowiki> tags that are causing the problem. Frietjes (talk) 16:32, 11 March 2016 (UTC)[reply]
this may be a _major_ problem considering how many of these color templates are using <nowiki> tags, e.g., all the meta/color templates ... Frietjes (talk) 16:35, 11 March 2016 (UTC)[reply]
Yep, someone has changed how the nowiki (and perhaps other) stripmarkers are rendered. This is a percent encoded version of a nowiki stripmarker:
%7F%27%22%60UNIQ--nowiki-0000000E-QINU%60%22%27%7F – the %27%22%60 and %60%22%27 are new
The previous version was just
%7FUNIQ--nowiki-...-QINU%7F
If they changed this, no doubt they changed how nowiki stripmarkers are handled. Was there a reason for this change?
—Trappist the monk (talk) 17:03, 11 March 2016 (UTC)[reply]
@Trappist the monk: The weird "nowiki" text occurs when you put a "ref" tag after the pipe in a piped link: [[Main Page|<ref>https://en.wikipedia.org/wiki/Main_Page</ref>]] displays as [1]. 63.251.215.25 (talk) 17:24, 11 March 2016 (UTC)[reply]

References

  1. ^ https://en.wikipedia.org/wiki/Main_Page
3425 templates with "color" or "colour" in the title and "nowiki" in the source. So this isn't going to be fixed manually. Right? fredgandt 17:38, 11 March 2016 (UTC)[reply]
Fred_Gandt can you provide an example where one of the meta/color templates are now broken? all the places that I have checked thus far, e.g., Aberdeenshire#Governance and politics, are still working. also, Template:Infobox election and Template:Composition bar aren't broken, as far as I can tell (probably because they don't use {{infobox}} or {{navbox}}). but, there may be some uses which are broken? Frietjes (talk) 18:22, 11 March 2016 (UTC)[reply]
@Frietjes: - Short answer = "no", which is my point. I'm not trudging through thousands of templates by hand to find which might be broken by this. A root or automated fix solution is needed; assuming the nowiki handling isn't broken, but rather is changed - I'd like to think this problem is an edge case which needs a special solution.
It seems that with vast numbers of these meta/colo[u]r templates, it would be prudent to scrap them all and utilise MediaWiki:Common.css to apply classes. The argument of course will be that only admin can edit it, but that shouldn't be a problem (all things considered). fredgandt 07:50, 12 March 2016 (UTC)[reply]

mw.html?

Example 1
Example 2
Example 3

the first two infobox examples used to render the same. the odd thing is that example 3 works, which makes me think that it's a combination of nowiki tags and the HTML builder (mw.html) that's barfing? checking further, I get some interesting results from the following

Input Output
{{str left|{{Green Party (United States)/meta/color}}|5}} [[:Te
{{str left|#0BDA51|5}}
  1. 0BDA
{{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}} [[:Te
{{#invoke:string|sub|#0BDA51|1|5}}
  1. 0BDA
{{#invoke:string|len|{{Green Party (United States)/meta/color}}}} 52
{{#invoke:string|len|#0BDA51}} 7

Frietjes (talk) 22:31, 11 March 2016 (UTC)[reply]

This is the Example 1 infobox output according to Special:ExpandTemplates:

<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid ?'"`UNIQ--nowiki-00000000-QINU`"'?;">Example 1</th></tr></table>

and it's accompnying raw html output window:

<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid&#160;?&#39;&quot;`UNIQ--nowiki-00000000-QINU`&quot;&#39;?;">Example 1</th></tr></table>

This is the output when the infobox is wrapped in {{code}}

'"`UNIQ--templatestyles-0000003E-QINU`"'<table class="infobox"><tr><th colspan="2" class="infobox-above" style="border-bottom:2px solid [[:Template:Green Party (United States)/meta/color]];">Example 1</th></tr></table>

This is the output as it is in my browser's source: 

<table class="infobox" style="width:22em">
<tr>
<th colspan="2" style="/* invalid control char */">Example 1</th>
</tr>
</table>

—Trappist the monk (talk) 23:32, 11 March 2016 (UTC)[reply]

It looks like the strip markers are being changed to /* invalid control char */ by HTML Tidy. That would explain why they appear in the HTML for the Special:ExpandTemplates preview but not in the HTML for this page. The change in nowiki tag behaviour doesn't seem to be caused by Lua. Strip markers have always been visible - and editable - from Lua, and Frietjes' example of {{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}} would have worked the same way before. The nowiki tags are converted to strip markers before they are passed to Lua, and MediaWiki converts them into whatever they are supposed to be after they are returned back from Lua. If you edit them while they are in Lua then they won't be recognised properly by MediaWiki after they are returned, which is what is happening in Frietjes' example here - the remaining characters left after the operation on the strip marker are just being treated as normal wikitext. The change in the nowiki tag behaviour seems to have something to do with how the strip markers are processed after they have been returned from #invoke, or from other templates or parser functions. — Mr. Stradivarius ♪ talk ♪ 02:18, 12 March 2016 (UTC)[reply]
Mr. Stradivarius, it seems to be #invoke (and padleft?) and not templates in general. as far as I can tell, {{Infobox election}} isn't having any problems, but I had to change {{Infobox political party}} to use the div hack. Frietjes (talk) 14:10, 12 March 2016 (UTC)[reply]

Infobox on Dutch language looks broken

Hi! The Dutch language article's infobox is kind of not correct looking, because the name of the language (Dutch / Nederlands) is in fairly small print and left-justified, making it hard to read. Click this link to see a screenshot (PNG, 275kb) of the issue. The <th> and <td> tags have style="/* invalid control char */" which looks wrong. The issue happens in Firefox Developer Edition 47.0a2, and also appears to happen in Google Chrome "Version 48.0.2564.116 (64-bit)". Could this be fixed? Thanks :) Goldenshimmer (talk) 20:54, 12 March 2016 (UTC)[reply]

@Goldenshimmer: This edit has fixed Dutch language but it's knackered the template's own doc page. I've not undone my edit: given the choice of broken article or broken template doc, I'd go with the latter. --Redrose64 (talk) 21:14, 12 March 2016 (UTC)[reply]
Thanks @Redrose64! Yeah, I would agree that broken article is much more important 😛. I feel something of a fool now, since I skimmed this discussion yesterday, but didn't make the connection when I saw the issue today, even though I looked for a report… i think i might have assumed that it had to do with Template:Infobox language specifically…. Anywho, thanks again :) Goldenshimmer (talk) 21:33, 12 March 2016 (UTC)[reply]
I made a further change, which does not affect Dutch language but has fixed the documentation. The sum of my two edits is this: every instance of <nowiki>#rrggbb</nowiki> has become /**/#rrggbb
The /**/ is a valid CSS comment, and it's passed through untouched by the MediaWiki parser, and its presence hides the hashes so that they're not converted to ordered-list item markers, but remain valid RGB hex triplet markers. --Redrose64 (talk) 21:38, 12 March 2016 (UTC)[reply]
Seems that the bgcolor= attribute of table cells doesn't like that technique. Never mind; it's obsolete in HTML5 anyway, so an edit like this is also necessary. --Redrose64 (talk) 21:50, 12 March 2016 (UTC)[reply]

Redirects from plurals

Template:R from plural and the pages transcluding it such as numbers say '"`UNIQ--nowiki-00000000-QINU`"' instead of [[link]]s. GeoffreyT2000 (talk) 00:12, 13 March 2016 (UTC)[reply]

I wonder if this is the same issue causing the infobox fuckery above. The Template:R from plural page for me seems to contain the same delete character (0x7f) that shows up in the discussion of the broken infoboxes. I'm seeing: <snip /> Huh, the deletes are turning into 0x3f for some weird reason in the saved page, so let's try this: <snip /> Dafuq? I get why the entity I left the semicolon off of isn't working, but the first one? Let's try this again…

This redirect link is used for convenience; it is often preferable to add the plural directly after the link (for example, &#x7f;'"`UNIQ--nowiki-00000000-QINU`"'&#x7f;). However, do not replace these redirected links with a simpler link unless the page is updated for another reason (see WP:NOTBROKEN).

/me googled it. Turns out html entities are decimal by default and need to be prefixed with an x to use hex… D'oh. :-S Goldenshimmer (talk) 00:58, 13 March 2016 (UTC) Update: Refactored comments and cut out some stuff to make it less ugly to read. Goldenshimmer (talk) 01:01, 13 March 2016 (UTC)[reply]
I can't get those entities to work for some weird reason (I'm probably missing something obvious…) so yeah, just use your imagination that the "&#x7f;"s are actually, ya know, like, 0x7f. Goldenshimmer (talk) 01:08, 13 March 2016 (UTC)[reply]
(Edited comments again, cause I seem to have a semicolon deficiency today…. Goldenshimmer (talk) 01:10, 13 March 2016 (UTC))[reply]

Examples of the problem that lead to the above (the third example works with no problem):

  • {{code|<nowiki>[[link]]s</nowiki>}} → [[link]]s
  • {{#tag:syntaxhighlight|<nowiki>hello</nowiki>|lang="text"}} → 
    hello
  • {{#tag:syntaxhighlight|<nowiki>hello</nowiki>}} → 
    hello

A workaround would be to remove the nowiki and replace "[" with &#91;, but a fix for the underlying problem is needed. Johnuniq (talk) 01:22, 13 March 2016 (UTC)[reply]

@GeoffreyT2000, Goldenshimmer, and Johnuniq: No need to encode the square brackets; if you check the documentation for {{code}}, it says "the template uses the <syntaxhighlight> tag with the attribute enclose="none". This works like the combination of the <code> and <nowiki> tags", therefore, there is no need to provide your own <nowiki></nowiki> tags, so I removed them. --Redrose64 (talk) 10:26, 13 March 2016 (UTC)[reply]
OK, I did this search for "UNIQ--nowiki" and got four hits. Two were <nowiki>...</nowiki> inside {{code}}; two were <ref>...</ref> inside wikilinks. All fixed. --Redrose64 (talk) 10:57, 13 March 2016 (UTC)[reply]
Thanks, that has fixed Template:R from plural. However, my point was to show the wikitext in the template that used to work and which now results in a broken strip marker. Perhaps the nowiki should never have been in {{code}}, but should placing it there cause a strip marker to become visible? Johnuniq (talk) 10:59, 13 March 2016 (UTC)[reply]
@Redrose64: I wasn't trying to encode the square brackets. Rather, I was trying to encode the delete character U+007F. Goldenshimmer (talk) 17:48, 13 March 2016 (UTC)[reply]
Indeed; but see comment by Johnuniq above, beginning "A workaround would be ...". --Redrose64 (talk) 18:09, 13 March 2016 (UTC)[reply]

MarkBlocked

The gadgets proposal page is a little dead, so a touch of spam here. Please see this: Wikipedia:Gadget/proposals#MarkBlocked. Keegan (talk) 23:05, 11 March 2016 (UTC)[reply]

MediaWiki:Protectedpagetext

Information icon There is currently an edit request at MediaWiki talk:Protectedpagetext. Thank you. -- SLV100 (talk) 07:26, 12 March 2016 (UTC)[reply]

Can't get on mobile pages without app

This wasn't happening earlier yesterday (like before 4 p.m. central US time), but started last night and is still going on. When I type, say, "saddle" into Google, it brings up the Wikipedia article as one of the top results. When I click on the link to our article on saddle, I get an error message that says, "No app found to open url". This has never happened before and I'm pretty sure it's a bug. If I type in Wikipedia's address, it loads the site and I can then search. I don't want to download the Wikipedia app because I may switch phones soon anyway and don't want my memory taken up by yet more stuff. Is this issue being tracked or fixed? White Arabian Filly Neigh 20:41, 12 March 2016 (UTC)[reply]

Do you have an Android phone? If so, open Settings, go to Apps, and tap the three dots icon at the top right. Then tap "Reset app preferences". As far as I know, this is an Android issue, not a Wikipedia issue, though my searches indicate it's mostly linked to the Google search app. clpo13(talk) 01:01, 13 March 2016 (UTC)[reply]
Yep, phone is Samsung Galaxy S4. I've complained to the company before, and didn't get any results. I will try the fix you suggested. Thanks. White Arabian Filly Neigh 20:22, 13 March 2016 (UTC)[reply]

NBSP is not working

What's wrong with the NBSP? See this table. Thanks, 213.151.215.195 (talk) 18:10, 13 March 2016 (UTC)[reply]

What NBSP? There are none in that table - indeed, none on the whole page. --Redrose64 (talk) 18:16, 13 March 2016 (UTC)[reply]
The &nbsp; is introduced by {{FlagIOC}} and is indeed not working. We're doomed (I'm not in the best frame of mind to even think about fixing it). fredgandt 18:27, 13 March 2016 (UTC)[reply]
The only &nbsp;, that I can find in {{FlagIOC}}, is shown if the third argument is given, which it is not in this case. Ruslik_Zero 18:51, 13 March 2016 (UTC)[reply]
It doesn't use {{FlagIOC}}. The only template directly used in that table is {{Ih}}. For the usages here, it pulls in the following templates: {{Country data BEL}}; {{Country data Belgium}}; {{Country data Czechoslovakia}}; {{Country data FRA}}; {{Country data France}}; {{Country data HUN}}; {{Country data Hungary}}; {{Country data TCH}}; {{Flaglink/core}}, and of those, the only one to include any nbsp is {{Flaglink/core}}. --Redrose64 (talk) 19:35, 13 March 2016 (UTC)[reply]
There's definitely nbsps being injected into the tables, traced as far as {{Flagicon/core}} but got tired. I'll hazard that part of the reason it's not having the desired effect in this case, is because it's a text node between inside and at the end of a <span> and folowed by an <a>, in a <table> (which does all kinds of formatting things by default) - nowrapping would be better (as mentioned below). The simplest solution is simply to give the table contents a little more room to breathe. fredgandt 19:37, 13 March 2016 (UTC)[reply]
This is the code emitted by {{Flaglink/core}} for each of the four countries: 
<span class="flagicon">[[File:Flag of the Czech Republic.svg|23x15px|border |alt=|link=]]&nbsp;</span>[[Czechoslovakia men's national  ice hockey team|Czechoslovakia]]
<span class="flagicon">[[File:Flag of Hungary.svg|23x15px|border |alt=|link=]]&nbsp;</span>[[Hungary men's national ice hockey team|Hungary]]
<span class="flagicon">[[File:Flag of France.svg|23x15px|border |alt=|link=]]&nbsp;</span>[[France men's national ice hockey team|France]]
<span class="flagicon">[[File:Flag of Belgium (civil).svg|23x15px|border |alt=|link=]]&nbsp;</span>[[Belgium men's national ice hockey team|Belgium]]
One nbsp, between flag and link, is that wrong somehow? It's not been altered since 19:59, 15 March 2015 - 364 days ago. --Redrose64 (talk) 19:50, 13 March 2016 (UTC)[reply]
No RedRose - it's fine, but tables do weird things to what is in reality a kludge anyway. The tables can be made wider or some whitespace nowrapping applied. It's just a browser fart; an edge case; HTML fun and games \o/ fredgandt 19:54, 13 March 2016 (UTC)[reply]
Instead of using &NBSP; use the {{nobr}} or {{nowrap}} template per MOS:NBSP. That is much more wiki-like and easier to edit later if needed. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 19:01, 13 March 2016 (UTC)[reply]
I added style="white-space: nowrap" to the affected table. fredgandt 20:03, 13 March 2016 (UTC)[reply]

@Koala Tea Of Mercy, Fred Gandt, and Redrose64:
I have an idea: Let's edit {{flaglink/core}} and put all this code into the nowrap:
[[File:{{{flag alias-{{{variant}}}|{{{flag alias-{{{altvar}}}|{{{flag alias}}}}}}}}}|{{#if:{{{size|}}}|{{{size}}}|23x15px}}|{{{border-{{{variant}}}|{{{border-{{{altvar}}}|{{{border|border}}}}}}}}} |alt=|link=]]&nbsp;
213.151.215.195 (talk) 20:23, 13 March 2016 (UTC)[reply]

Read only mode March 15, 22 and 24

Just in case anyone misses seeing this in the Signpost: Wikipedia Signpost#2016-03-09/Technology report, so not so many people post over here asking why WP went into read-only mode. — Maile (talk) 20:00, 13 March 2016 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=709903699"