Open main menu

Wikipedia:Village pump (technical)

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
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 bug 1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your 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 have problems making your fancy signature work, check Wikipedia:How to fix your signature.
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.
For server or network status, please see Wikimedia Metrics.
« Archives, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176


Suppress rendering of Template:Wikipedia booksEdit

As many are aware Wikipedia books has not worked in a few years and there's no light down the tunnel of any fixes coming...Reading/Web/PDF Functionality (no update on WikiBooks in a year). I am proposing suppressing the rendering capability of Template:Wikipedia books ( related =Template:Book bar & Template:Books-inline) and removal of the Book Creator in the sidebar. This is for our readers so they don't keep going to books that don't work and haven't worked in a few years..plus these types of lists exist in outlines already. I'm thinking suppression of the template(s) is better than outright deletion in case the WMF finally does come up with something...then poof...they can all appear when transclusion is implemented again. Currently PDF rendering per page has been implemented so the link seen at Wikipedia:Books about an external program is no longer needed as our in-house PDF system is running.--Moxy 🍁 22:57, 6 August 2019 (UTC)

Discussion (Wikipedia books)Edit

  • Good idea and a future-proof solution. Support per nom. Wug·a·po·des​ 01:20, 7 August 2019 (UTC)
  • I think this is a good idea. Headbomb did some work with this stuff years ago and he might also have some comments about it. Killiondude (talk) 06:08, 7 August 2019 (UTC)
  • Support. Ruslik_Zero 08:42, 7 August 2019 (UTC)
  • Support, I didn't even know it's not working. Stryn (talk) 10:37, 7 August 2019 (UTC)
  • Seems like phab:T224922 may be relevant here, as mw:Extension:Collection is the extension behind "books". Anomie 12:10, 7 August 2019 (UTC)
  • Support per nom. Masum Reza📞 14:22, 7 August 2019 (UTC)
  • Book namespace entirely is dead. There'd be no harm in scrapping it completely. – Ammarpad (talk) 16:24, 7 August 2019 (UTC)
  • Comment if outlines are more up to date and maintained and are basically redundant, get rid of books. But wait.... these things are for readers, right? Are readers more likely to look for "books" or "outlines"? Maybe we should migrate the excellent and maintained content from outline to "books" and then get rid of outlines. We still reduce fluff but combine maintenence with readership. NewsAndEventsGuy (talk) 17:58, 7 August 2019 (UTC)
  • If it's dead, it's dead. Can be suppressed until and if things come back online. Headbomb {t · c · p · b} 18:04, 7 August 2019 (UTC)
  • Support. Hrodvarsson (talk) 04:52, 9 August 2019 (UTC)
  • Support per nom. SD0001 (talk) 20:11, 14 August 2019 (UTC)
  • Support No point offering something to users that can't be used.Nick Moyes (talk) 12:10, 16 August 2019 (UTC)
    Striking my !vote as I now realise the issue is more complex than I had initially thought. Nick Moyes (talk) 20:17, 10 September 2019 (UTC)
  • Restored from archive......should we close this and move on to the technical part of the RfC.--Moxy 🍁 03:29, 26 August 2019 (UTC)

Note: Votes below have been cast since the initial close was reverted — Cheers, Steelpillow (Talk) 07:52, 4 September 2019 (UTC)

  • Strong oppose: The Book Creator is still in use as a vital tool in preparing books for rendering by external services. See discussion below. — Cheers, Steelpillow (Talk) 05:43, 2 September 2019 (UTC)
  • Oppose. Seems the original premise above is incorrect, so oppose this strongly per Steelpillow. P. I. Ellsworthed. put'r there 00:50, 3 September 2019 (UTC)
  • The external tool doesn't really seem particularly usable, so I think it's reasonable to suppress the links and templates. Support. --Yair rand (talk) 04:56, 4 September 2019 (UTC)
  • Support The book program is not working and there is really no point in lead us to a pay site for info that is free. — Preceding unsigned comment added by 2605:8d80:540:6525:d552:87b7:e57c:c4d8 (talkcontribs) 21:41, 5 September 2019 (UTC)
    There is every point if the WMF have an agreement with the provider concerned. The payment is not for the information, it is for the bookbinding and postage. — Cheers, Steelpillow (Talk) 10:32, 6 September 2019 (UTC)

This discussion has been notified at mw:Talk:Reading/Web/PDF Functionality. — Cheers, Steelpillow (Talk) 10:32, 6 September 2019 (UTC)

  • Strong oppose: As per Steelpillow. The original proposal and essentially all the supports (so far as I can see) are based on a misunderstanding of the status of the book creator. I had been following the very long and ongoing discussion about the work related to the PediaPress and the mediawiki2latex solutions, because having a properly functioning pdf book creator is a valuable part of wikipedia so far as I'm concerned. It is clear that people here who want to kill this function don't understand what they are killing off. Gpc62 (talk) 19:11, 6 September 2019 (UTC)
    @Gpc62: Would you consider mediawiki2latex to be a properly functioning/usable tool? --Yair rand (talk) 04:24, 9 September 2019 (UTC)
  • Strong oppose I think that PDF creation of books is important and should be kept. I see that not everyone is happy with my mediawiki2latex solution. Possibly users should raise their voice asking wmf to allocate funds for the development of a better in-house solution, but this should be done in an other discussion. Dirk Hünniger (talk) 08:29, 7 September 2019 (UTC)
  • Oppose The loss of the rendering system for books certainly made Wikipedia less useful from my point of view. Even without it the Book Creator interface is something I find useful. It allows the rapid and interactive collection of topical pages into useful order/format. Doing that by hand is a pain. Killing the function has a very small marginal benefit to the people who do not use it and a high cost to those of us who do. Jbh Talk 18:55, 9 September 2019 (UTC)
  • Support per Dirk below: since I got quite some anarchistic thoughts, I kind of enjoy business models explode in huge fireballs. People make money off these books, but they do not serve our readers well. Time to explode in huge fireballs, or at least hide the template. Levivich 04:36, 10 September 2019 (UTC)
    In what way does the PediaPress print-on-demand-service (the only pay-for bit) not serve our readers well? — Cheers, Steelpillow (Talk) 09:03, 10 September 2019 (UTC)
  • Support per above. Old/buggy, and no longer being developed. Leaving this out in the open begets opportunities for an exceptionally poor reader/user experience -FASTILY 00:53, 11 September 2019 (UTC)
    @Fastily: Factually you are wholly incorrect. The PediaPress PoD service is not buggy, the MediaWiki2 LaTeX softcopy service is not old but new and under continued bug-squishing. Have you not read the discussion below? — Cheers, Steelpillow (Talk) 10:05, 11 September 2019 (UTC)
    Right, and that's your opinion. Obviously I disagree, hence my support !vote. -FASTILY 01:13, 12 September 2019 (UTC)
    No, it is not my opinion, it is factual. You have no evidence to support your opinion that the PediaPress service is buggy. You have no evidence to suggest that MediaWiki2LaTeX is either old or moribund, in fact it has been usefully updated during the discussion, which you would know if you had followed it, and you can ask the lead developer when he wrote it if you like, he is participating here. There is far too much opinion and not enough fact in this thread, please do not make it worse. — Cheers, Steelpillow (Talk) 08:02, 12 September 2019 (UTC)

Note: This discussion has been notified at mw:Extension talk:Collection. — Cheers, Steelpillow (Talk) 08:49, 12 September 2019 (UTC)

  • Support removal of the sidebar link It is embarrassing that a link from the main page (which is viewed about 6 billion times a year), and from every other page, leads directly to a page that has, right at the top, "Book Creator is undergoing changes. Due to severe issues with our existing system, . . . " No opinion on changes to the template. UnitedStatesian (talk) 13:14, 20 September 2019 (UTC)
    It would make more sense to update the misleading message per the discussion below. — Cheers, Steelpillow (Talk) 17:16, 20 September 2019 (UTC)

Discussion after reverted closureEdit

Reverted close: WP:SNOW close with consensus for proposal. I am fully aware that RfC's usually should run for 30 days and willing to re-open if there are any concerns. (non-admin closure) --Trialpears (talk) 23:26, 31 August 2019 (UTC)}}

I have reverted my close due to concerns raised on my talk page about insufficient notifications to the book making community and insufficient discussion about working external tools. I have posted notifications to WT:BOOKS and Help talk:Books. --Trialpears (talk) 20:24, 1 September 2019 (UTC)
  • Need help in removing the book creator from the side bar--Moxy 🍁 15:49, 1 September 2019 (UTC)
    That can only be done by requesting a site change on Phabricator. I am not sure the above demonstrates the necessary consensus for that change. --Izno (talk) 16:44, 1 September 2019 (UTC)
    @Moxy: That would require an interface admin to add #coll-create_a_book { display: none; } to Mediawiki:Common.css. --Yair rand (talk) 18:11, 1 September 2019 (UTC)

Note: the following two-part post was made before the initial close was reverted — Cheers, Steelpillow (Talk) 07:52, 4 September 2019 (UTC)

YIKES! STOP EVERYBODY! The Book Creator tool remains an essential feature in order to create and edit Wikipedia books for external services such as PediaPress print-on-demand and the MediaWiki2LaTex independent PDF rendering service. It is only our in-house rendering that has gone (and may yet come back, as PediaPress have undertaken to provide a replacement). Please roll back all these stakes through its heart! — Cheers, Steelpillow (Talk) 19:08, 1 September 2019 (UTC)

Specifically, the OP's rationale that "Currently PDF rendering per page has been implemented so the link seen at Wikipedia:Books about an external program is no longer needed as our in-house PDF system is running," is wholly wrong-headed. Yes we have a new article renderer, but it is a totally unrelated function from book rendering. That needs entirely different software in two parts - the book creator/designer which lists articles for inclusion and the book renderer which pulls all the articles together. We have only lost the book rendering, the old book creator/editor is still functional and still in use. The linked external book rendering service is still also operational. It has absolutely not been withdrawn or overtaken by the new article renderer. — Cheers, Steelpillow (Talk) 20:16, 1 September 2019 (UTC)

Removed {{warning}} from your comment. Hope that's okay. --Yair rand (talk) 03:47, 3 September 2019 (UTC)
Yep, it's done its job. — Cheers, Steelpillow (Talk) 10:03, 3 September 2019 (UTC)
  • Close reverted I have reverted my close due to concerns raised on my talk page about insufficient notifications to the book making community and insufficient discussion about working external tools. I have posted notifications to WT:BOOKS and Help talk:Books. --Trialpears (talk) 20:24, 1 September 2019 (UTC)
    Good call ....best wait till the concerns raised on your talk are brought here for discussion.--Moxy 🍁 23:59, 1 September 2019 (UTC)
    What else needs to be brought here besides what I already said just above? The Book Creator is still in use. End of. — Cheers, Steelpillow (Talk) 02:39, 2 September 2019 (UTC)
    So leave the link in the side bar and leave all the books so we can lead our readers to a third party? Is the main purpose going to be fixed? --Moxy 🍁 18:48, 2 September 2019 (UTC)
    Depends what you regard as the "main purpose". The PediaPress PoD pay-for service has always been an integral part of Wikipedia Book delivery. The WMF have accepted an offer from PediaPress to write a new Mediawiki PDF book renderer for us too and they have made an alpha build available at https://pediapress.com/collector , however there is no timeframe for completion/rollout. You can find out a little more at mw:Reading/Web/PDF Functionality and the associated talk page and archives. As far as I know their software is not tracked on phabricator. Meanwhile Dirk Hünniger has made his own MediaWiki2LaTeX open-source PDF book renderer pull service available to fill the gap. In that sense the "main purpose" of having both PDF and PoD WikiBooks available is currently fulfilled. As long as the Book Creator (aka the Collection Extension) delivers its part of that functionality, as required by the WMF, it will stay in the MediaWiki build and we need to support it with UI widgets to the best of our ability. — Cheers, Steelpillow (Talk) 19:50, 2 September 2019 (UTC)
    Pppery, should the change to Module:Subject bar be reverted in light of the change to this RFC outcome? – Jonesey95 (talk) 21:19, 2 September 2019 (UTC)
    I personally consider the reversion of the closure to itself be improper, so I won't revert the change to Module:Subject bar myself, but another template editor could of course do so. * Pppery * it has begun... 22:23, 2 September 2019 (UTC)
    It was perfectly proper. The closer did not wait the required 30 days, noting in their closing statement that if anybody objected the discussion could be reopened. I objected both here and on their talk page so they reopened. Nothing whatsoever improper about that. What was improper was the OP's failure to place any notification on the affected template's talk page or the Book project's talk page, until after the closure. Paine Ellsworth and I were actually discussing and updating the template while this discussion was going on, but without ever being informed of its existence. That is a gross breach of procedure on the part of the OP. I don't know anything about Module:Subject bar but any change to it has arisen as a result of this failure to consult properly. I would be most grateful if somebody could see their way to reverting it. — Cheers, Steelpillow (Talk) 10:35, 3 September 2019 (UTC)
    Yes, thought it best to remove the commenting, at least until we sort all this out. P. I. Ellsworthed. put'r there 15:09, 3 September 2019 (UTC)
  • I'm confused. Is there a working system for converting books to PDF or not, on-wiki or off-? It looks like MediaWiki2LaTeX is for converting individual pages, just like the built-in converter? --Yair rand (talk) 03:05, 3 September 2019 (UTC)
    Yes, it is working. To convert a book, you give its page location to MediaWiki2LaTex. The service then pulls all the articles linked in its contents and builds the entire book. Or, you can give it a single article and it will render that alone. I see that various options for conversion mode and output format have been added since I last used it. So it provides either book or single-page conversion, depending on what you give it. Either way, you need only give it a single page location, tell it what you want and it figures out the rest, that may be what is puzzling you. (By contrast, if you use the built-in converter on a Book page, it will just convert the page to PDF, which is seldom very helpful) — Cheers, Steelpillow (Talk) 10:35, 3 September 2019 (UTC)

Hi,

I am the maintainer of mediawiki2latex. Maybe it is a bit off topic, but I got two views on this point. Firstly mediawiki2latex currently provides a way to get PDFs from books hosted on Wikipedia and keeping this possibility might be an advantage for some users of the content, particularly those with small financial resources, which is a good thing as such. The resources on the web interface to mediawiki2atex (which is hosted by wmf) are quite limited so that book may a most contain a few dozens of articles. mediawiki2latex is also provided as a binary package for Debian Linux without any limits on the number of articles per books.

Removing the books from Wikipedia would not cause any financial consequences to me since I am only doing this as an unpayed hobby project in me spare time. Still pediapress financially relies on the book feature on wikipedia. So closing the book feature might cause pediapress to stop all business activities in this field, which causes me to have a monopoly, which is the greatest thing you can get in capitalism. So the choice is yours. Dirk Hünniger (talk) 14:37, 3 September 2019 (UTC)

Do you have any stats in how often it's used? We know that people don't order Wiki books as most are 9,000 pages plus and thus simply not feasible. The question real is do we keep books to simply link them to a third party site?--Moxy 🍁 03:36, 4 September 2019 (UTC)
The web interface is roughly used once an hour, so about 20 times a day. It cannot be used much more since there is a time limit of one hour and at most one process may run at a time due to the limited resources. The statistics of the Debian package are given here . Still it is quite hard to infer anything from the Debian statistics since only very few Debian users take part in the statistics survey at all. Dirk Hünniger (talk) 06:31, 4 September 2019 (UTC)
You need to understand that this is a dynamic situation. When the original in-house service became progressively more and more unmaintainable - both hardware and software stacks - the quality of output got left behind as the rest of MediaWiki and user templates got more sophisticated. Usage consequently also fell away until that low usage began to be used as a "reason" why fixing the system was an equally low priority. Here we see the same fallacy again. MediaWiki2LaTeX is under active development. Compared to its launch state its hardware and software have both improved substantially, allowing the maximum book size to be increased. This is still only a small, low-resource system by Wikipedia standards but usage has picked up accordingly, as Dirk says it is near maximum for the WMF hosted instance, and this upward trend will continue. The priority for this facility is not reflected in where it is now but where usage will/would be when further developed and deployed. "Do we keep books so we can link to 3rd party sites?" is the wrong question, not the real one as you suggest. The real question is, "Do we want Wikipedia Books in any form?" Once we answer that, we can make decisions about in-house vs. third-party. As already pointed out, the involvement of PediaPress in the Wikipedia Books project and its UI upload link to PediaPress goes back a decade or more to day one. The Books project has always linked to a third party because this is inherent in the pay-for model of print-on-demand and the WMF does not do pay-for services. Any decision to pull the plug on the PediaPress upload would have to be agreed in consultation with the highest levels within the WMF; our local village pump is quite the wrong venue to bandy about such far-reaching consequences. I would suggest that, since PediaPress have volunteered out of the goodness of their hearts to try and develop a replacement in-house renderer for us, then stuffing them where it hurts would not be either wise or ethical. We have two competing pdf renderers and a third, commercial PoD service here, all supported in different ways by the WMF due to the current dynamics of the situation - and you suggest we kill the whole deal. — Cheers, Steelpillow (Talk) 07:38, 4 September 2019 (UTC)
I raised some issues with the lead developer of MediaWiki2LaTeX through their official Requests page. I found these with my usual test case Book:Wings of Hamburg. He did a quick update to one of the config files for template processing. Compared to the quality when this discussion was opened, the book is no longer bloated by over-expanded infoboxes and navboxes, but comes in at almost half the previous file size and page count and is far more readable. Some other issues I realised will take longer to fix, but this does underline the dynamics of the situation and the active and ongoing support.— Cheers, Steelpillow (Talk) 12:13, 6 September 2019 (UTC)

I think it's high time we invited the WMF over to participate in this discussion. I am not sure of the best way to do that, but I have tried what I can. If anybody knows the correct place to post an advisory over there, please do so. — Cheers, Steelpillow (Talk) 12:13, 6 September 2019 (UTC)

Well, the majority seems to have a clear opinion. Many contributors have brought forward their arguments, currently there seem to be no new arguments. I am really looking forward to a decision being taken. In my impish mind I will be really pleased to see these fireworks go off. Especially when imagining that these relaxed well paid, socially secured people, well assured that there is never any problem, will suddenly have to work quite a lot. My systems will keep running. But possibly I should better change my telephone number. Good Luck Dirk Hünniger (talk) 14:36, 6 September 2019 (UTC)

I do not understand this comment. I feel like I'm missing some context? --Yair rand (talk) 04:26, 9 September 2019 (UTC)
Well, Pediapress earns money from selling the printed copies of wikipedia books. If we remove the template their sales will drop by (lets guess) 80%. Futhermore pediapress pays parts of money the earn from selling each book directly to wmf. So also wmf will have a considerable decrease in income. So in this case there will be a meeting between wmf and pediapress very soon, and this will be quite a stormy affair. But since I got quite some anarchistic thoughts, I kind of enjoy business models explode in huge fireballs. But yeah, I thinks it is better for the users to keep these option available for the users, so I voted for keeping the template. Dirk Hünniger (talk) 08:31, 9 September 2019 (UTC)
Got an email from the boss...found stats Book Tool sales data.--Moxy 🍁 21:15, 9 September 2019 (UTC)
So, €341,776 in revenue over 40 months. Even if we assumed that the books cost nothing to produce (unlikely), and that 100% of income is donated, that would be about €100,000 per year, compared to the WMF's $100,000,000+ in donations per year. I don't think it can be considered "a considerable decrease in income". --Yair rand (talk) 04:26, 10 September 2019 (UTC)
Contrary to your "half-empty" pessimism, I see these stats as "Wow! Real $$$!" It does seem grossly unfair that the Book project generates five-figure sales year on year and receives zero inward investment in return. If say half the WMF income from books was reinvested in the Books project, even €2,000 a year would be a hugely significant increase in the project's resources. It would allow the project to improve quality, boost uptake, increase income and make everybody's life better in a nice, socialistic upward spiral. — Cheers, Steelpillow (Talk) 13:50, 10 September 2019 (UTC)
Those stats are unfortunately a bit out of date. Levivich 04:31, 10 September 2019 (UTC)

Since the usability of mediawiki2latex is discussed. I provide to examples of the output of the large document server http://mediawiki2latex-large.wmflabs.org/

I choose these two examples since I think to remeber to have seen them in this discussion. So everyone can now look at them and find his / her own opinion. Everyone is also wellcome to add examples and of you to send me bug reports on what he / she wants changed.Dirk Hünniger (talk) 12:34, 10 September 2019 (UTC)

So we get an error because they are to big.......how small do they have to be?--Moxy 🍁 10:59, 11 September 2019 (UTC)
There are two servers:
I used the big one in both cases. But I think the normal one should do a well for the Wings of Hamburg Book, but not for Canada Book. Furthermore the server only processes one document at a time, and an error message will be displayed if an other user request a conversion while a conversion is already running ("Not enough resources availiable to process your request!"). The software can basically run requests in parallel, but the maximum number of parallel requests was set to one in order to account for the limited hardware resources. The limits on the hardware resources, were set by wmf, and you should contact them directly if you feel they need to be increased. But if you want to find out if mediawiki2latex serves your needs I strongly recommend to install the Debian package and test with that since there are no limit in the package at all. The main limiting resources is random access memory. You need roughly 5 MByte per page. Dirk Hünniger (talk) 11:23, 11 September 2019 (UTC)
Moxy, thank you for highlighting what is essentially an issue with the user documentation. I have now updated the user manual accordingly. Note also that the maximum size of around 800 pages on the large-book server is larger (ISTR about 200 pages more) than the old OCG could manage. Since the template config has been tweaked this has reduced the time my own test books run for, meaning that if a document is accepted for processing then even more pages can likely be processed before timeout. — Cheers, Steelpillow (Talk) 12:25, 11 September 2019 (UTC)
This is disappointing as alot of our books are way over 800 pages...shit been fighting to keep a books smaller for years as seen here just to find out the smaller version is still to big...dame.--Moxy 🍁 20:45, 12 September 2019 (UTC)

Hi,

As one of the founders and current CEO of PediaPress, I'd like to express my point of view. The book creator / collection extension was created more than 10 years ago and is still in active use today. Check the original press release from 2007. PediaPress donates 10% of its gross revenue from Wikipedia books to the WMF every year (more than €70,000 total over the last ten years). After a couple of failed attempts to create print products from Wikipedia, the partnership with PediaPress was established to allow for a consistently available, self-service, and good quality print export of Wiki content. The relevance of this use case has declined over the years but it is still relevant for a small group of avid users (I can share full revenue data if desired). The collection extension has been vital in enabling this feature. Without an easy to use interface, most Wikipedia users will never be able to explore this. Even though I had only limited time to work on the new book renderer in the past few months, I/PediaPress is committed to delivering high quality PDF and print export for Wikipedia and other wikis in the future. We agreed to release the new HTML renderer as open source and to sponsor the PDF book rendering going forward. I would hope that this feature would not be shut down and I am very open for talking about how to make book export better and more relevant. Ckepper (talk) 13:31, 12 September 2019 (UTC)

So it seems more logical to link PediaPress over our books that dont work...or do we need the book pages for Pedia press to work? --Moxy 🍁 20:15, 12 September 2019 (UTC)
We need the collection extension along with its Book Creator GUI to provide the upload function to the PediaPress service. Technically a book page can be built in user space and designed manually, but the Book namespace and Book Creator make life a lot easier. — Cheers, Steelpillow (Talk) 07:00, 13 September 2019 (UTC)
@Ckepper:Thank you for your perspective! It's very encouraging that there's signficantly better support for books than there appeared to be at first. Looking at some of the previews I have a few potential improvements, first there were quite a lot of weird tags such as <indicator> around padlocks, <templatestyles /> and </ref> tags. These obviously shouldn't be there. I also was wondering if the preview was actually loading or just broken when trying to open it. An explicit "Your preview is currently being typeset" message would avoid this problem. For more general improvements I feel like some templates simply shouldn't appear in printed versions, such as sound samples and protection levels. They're simply not relevant. I could try looking into the template aspects of implementing such a feature if that would be desirable. --Trialpears (talk) 21:04, 12 September 2019 (UTC)

While it's possible to download or reading a book it's not very convenient. Rendering a book with MediaWiki2LaTex often takes many hours and some setup if someone else is using the online resources and the pediapress preview doesn't show the entire book. Would it be possible to upload a pre-rendered book from MediaWiki2LaTex on the book pages ready to be downloaded or read. If that was the case this would be even better than when there was an inhouse pdf renderer. --Trialpears (talk) 21:23, 12 September 2019 (UTC)

Wikipedia does not store rendered books. Each time one is requested the collection extension compiles a new edition from the current state of its content articles. This ensures that the book always aligns with the current encyclopedia content, which is what readers would expect. Also, storing every edition of every compiled book, the inbuilt journaling/rollback storage functionality of the mediawiki software, could also create a space/speed problem. PediaPress used to make their print pdf available for free download but have stopped doing that, I guess too many folks were using them as an ebook repository or something. — Cheers, Steelpillow (Talk) 07:00, 13 September 2019 (UTC)
Most readers would also expect to be able to read the book without having to wait for several hours. I think it's definitley worth the quite minor drawbacks in favor of a massive advantage in terms of usability. --Trialpears (talk) 07:17, 13 September 2019 (UTC)
Yeah, this is possible. I did some experiments on that to estimate the costs:
In short it will only cover featured book and take one year to calculate, as well a $2000 server costs. So if someone want to pay for that we can do it. Dirk Hünniger (talk) 06:43, 13 September 2019 (UTC)
Yikes, that's a lot more than I expected. What if Mediawiki2Latex uploaded all books it's requested to render using the Wikimedia resources as well as providing them to the person requesting it? Then the books with the highest demand would be uploaded without using additional ccomputational resources. --Trialpears (talk) 07:17, 13 September 2019 (UTC)
I can call a shell script with the name of the book as well as the pdf file, each time the server generates a book in the book namespace. All remaining work would be up to you. Convincing the community that such a bot is Ok to run. Convincing that there needs to be a template linking to it. Writing the lua of that template. And finally writing the upload bot. So if you want to do that work, you are welcome to do so. Dirk Hünniger (talk) 07:53, 13 September 2019 (UTC)

Overreaching scope of changesEdit

At the point I intervened to get the SNOW close reverted, editors here were going way beyond the mere deactivation of Template:Wikipedia books, which is the subject of this RfC. Pppery made changes to Module:Subject bar, also since reverted, and Moxy was trying to remove a link from the main sidebar menu. Neither of those changes was part of the RfC discussion and they were not justified even if the close decision had stuck. Moxy, the OP, had also failed to advise interested parties of the discussion or even to post a notice of it on the talk page of the subject template. It might help those of us involved with the Books work to understand your case here if you could explain your conduct and why you felt this issue allowed you to override our normal community consensus process? — Cheers, Steelpillow (Talk) 08:26, 12 September 2019 (UTC)

If you were to read the RfC yes the side bar was part of the proposal as was related templates. As for notification ..you are correct that the project page was not notified as it seems dead for years (my bad) . But you have corrected this ...may I ask why you saying all this all again? All is now in order and it seems your simply bitter about the current progress. --Moxy 🍁 20:12, 12 September 2019 (UTC)
Fair enough, my mistake on the scope and I must apologise for that. But I do still think the title of this thread is misleading and that gives some partial justification for my error. On notification, when I pointed out your failure to notify on your talk page, you responded by getting upset with me. When I made that point again, more publicly in the main discussion, you ignored it. This third mention is the first time you have acknowledged you got it wrong, so thank you for clearing the air. I am not so much bitter as irritated and mildly baffled by the disinformation being constantly pumped out by the supporters of this RfC, despite repeated corrections and clarifications by not only myself but also the software developers involved and, since your original flawed justification began that trail, my approach to you has naturally been tainted by that. I am pleased to see that we are getting past these issues. — Cheers, Steelpillow (Talk) 07:19, 13 September 2019 (UTC)
Have no clue where I got upset...all I have been doing is asking questions trying to figure out if it's worth one in 30,000 people who click on other services offered by a third party that may or may not work is worth it. As for no reply... clearly No Malice intent on my part so I felt no need to respond as it does nothing to move the conversation forward. (Like this whole section that could be collapsed) --Moxy 🍁 01:24, 14 September 2019 (UTC)
Perhaps your phrasing on your talk page was grumpier than you realised, we all fall for that one. Then, given your misguided justification in your original post, it was initially less obvious to some of us that no malice was intended. I am glad we have got that straight now. Should we just delete this whole subsection from the thread? — Cheers, Steelpillow (Talk) 08:29, 14 September 2019 (UTC)

Help with LUA and shoving a string into a templateEdit

In Module:JCW, I have in this version, the following,

function p.pattern (frame)
	local n = mArguments.getArgs(frame, {parentOnly = true})
	local length = TableTools.length(n)
	local text = string.format ('*%s', n[1] or '')
	n[1] = nil --make next loop only target arguments >=2
	for i, j in ipairs(TableTools.compressSparseArray(n)) do
		text = text..string.format("\n** {{replace|%s|.*|<code>.*</code>}}", j)
	end
	return text

The line text = text..string.format("\n** %s", j) is apparently shorthand for 'dumbass that can't code LUA', because if if you have a string like '*Bibcode*', you don't get, as I'd expect

    • .*Bibcode.*

but rather an un-parsed

    • {{replace|.*Bibcode.*|.*|.*}}

If someone could de-dumbassify my code, that would be peachy. The goal is if the substring '.*' is present in a string like '.*Bibcode.*', I want those to become wrapped in code tags, like so <code>.*</code>Bibcode<code>.*</code>.

@Galobtter: maybe? Headbomb {t · c · p · b} 13:59, 11 September 2019 (UTC)

I think you need to escape the special characters (. and *) in your search. See this tutorial and this manual. I think you need something like %.%* to find '.*'. – Jonesey95 (talk) 14:18, 11 September 2019 (UTC)
I'll double check, but it would be a bit weird since {{replace|.*Bibcode.*|.*|<code>.*</code>}} works fine. Headbomb {t · c · p · b} 14:47, 11 September 2019 (UTC)
Nope, throws off a bunch of errors if I do that. Headbomb {t · c · p · b} 14:51, 11 September 2019 (UTC)
@Headbomb: Templates won't be expanded from lua output. To use a template, you'd need to use frame:expandTemplate. However, in this case, there's no reason to use lua to call {{replace}}, since that template is just going to call back to a lua module anyway. Just do:
 text = text .. "\n** " .. mw.ustring.gsub(j, "%.%*", "<code>.*</code>")
mw.ustring.gsub is just the unicode-compatible version of string.gsub. --Ahecht (TALK
PAGE
) 15:01, 11 September 2019 (UTC)
Yeah that works. Thanks. Still got other issues, but less pressing ones. Headbomb {t · c · p · b} 16:13, 11 September 2019 (UTC)
Plain string.gsub works fine in Ahecht's code because there is no search for Unicode characters: it's just searching for dot and asterisk. Johnuniq (talk) 23:44, 11 September 2019 (UTC)
True, but I always prefer to use the unicode-compatible versions as a matter of habit since it makes re-using the code later easier. --Ahecht (TALK
PAGE
) 20:04, 12 September 2019 (UTC)
Unicode is definitely better than non-unicode. A lot more scalable. Headbomb {t · c · p · b} 20:12, 12 September 2019 (UTC)

Thank button changing into rollbackEdit

I have noticed that on Win10 using Chrome that upon loading a page history that the page is reformatted after a couple of seconds, I guess because of CSS or script mods. When this happens the rollback button moved exactly to where the thanks button was. Not, in itself a big problem but, embarrassingly, if I click thanks before this change occurs (from ~0.5 to ~3 seconds) the interface reads it as a rollback. Anyone have any ideas? I use the script that should hide rollback on my watchlist - sometimes it does some times not - but it is useful from page history. As an aside, is there a way to add a thanks button to the watchlist? Jbh Talk 14:37, 11 September 2019 (UTC)

Seconded (Win7/Opera). I have probably inadvertently rolled back around half a dozen times, followed by an undo, and a red-faced summary, "self-revert; fat-finger error". Thanks, Mathglot (talk) 02:50, 12 September 2019 (UTC)
Hmm, I don't get the page reformatting issue. Perhaps related to a gadget or .js script? Sam Walton (talk) 15:26, 12 September 2019 (UTC)
@Jbhunley: It's probably due to my inline diff script; the view history button loads a little bit after the page does. I have a CSS hack that will reserve the space normally taken up by the button on page load--this prevents the script from significantly shifting any UI elements (at the cost of an ugly blotch of whitespace for a split second before the script loads in). If you'd like to try it out, you can add the following lines to your common.css page:
.mw-changeslist-edit .mw-changeslist-separator {padding-right:84px;}
.mw-changeslist-edit .mw-changeslist-separator~.mw-changeslist-separator {padding-right:0px;}
#pagehistory .mw-changeslist-separator {padding-right:84px;}
#pagehistory .mw-changeslist-separator~.mw-changeslist-separator {padding-right:0px;}
...which should fix the problem for both the watchlist and history pages. If you need more or less space (it could vary, depending on fonts and the like), you can adjust the 84px up or down. Let me know if this helps with the problem! Writ Keeper  17:11, 12 September 2019 (UTC)
Thank you. That works. I upped it to 120px which does not seem to cause issues on lower res displays. The button still jumps but it is to 'undo' on the laptop. I can catch the error before it commits the undo. Jbh Talk 19:03, 12 September 2019 (UTC)

503 errors on Wikimedia / Wikipedia pagesEdit

  Resolved: Resolved per below. --TheSandDoctor Talk 05:23, 14 September 2019 (UTC)

In case this is affecting anybody else: https://phabricator.wikimedia.org/T232698. The problem is under investigation. ↠Pine () 05:31, 12 September 2019 (UTC)

Update: the problem is believed to be related to network maintenance, and has been resolved. --↠Pine () 06:10, 12 September 2019 (UTC)

External links with embedded "[" and "]"Edit

  Resolved

How do I display an external link that contains "[" and "]"? Here is an example: The first result of this Google Scholar search takes you to a bioone.org page. But its url has "[" and "]" in it. I tried to paste that link into this Resource Request, but the "[" and "]" garble the result. Is there an escape character that can be used to "hide" the "[" and "]"? Thanks. —Bruce1eetalk 13:23, 12 September 2019 (UTC)

See Help:URL#Fixing links with unsupported characters: [1]. PrimeHunter (talk) 13:31, 12 September 2019 (UTC)
Thank you – that's what I needed. —Bruce1eetalk 13:34, 12 September 2019 (UTC)

Slow emails from Special:EmailUser?Edit

Anyone else noticing that Wikipedia emails seem to take a while to arrive lately (e.g. notice of one in the interface long before it shows in your inbox), or is that just me & my provider having issues? Received one that took around 20 minutes (from what I recall) to arrive in my inbox earlier this week (just had time/remembered to ask now). --TheSandDoctor Talk 20:44, 12 September 2019 (UTC)

Someone sent me one today, and I received it promptly after the notification. — JJMC89(T·C) 04:24, 13 September 2019 (UTC)
Huh. Thanks, JJMC89....it might be just me then....I wouldn't put it past that provider (used to be good, but down hill in recent years), but oh well. Thanks again! --TheSandDoctor Talk 05:22, 14 September 2019 (UTC)
@JJMC89: I accidentally stumbled across another user affected by this. Ticket filed (phab:T232928). --TheSandDoctor Talk 04:37, 16 September 2019 (UTC)

Easy way to find mismatched assessments?Edit

So I found Pullman Square entirely by accident when trying to find GA-class WP:MALLS articles. But for some reason, it was only assessed as a C-class Shopping Malls article despite being GA-class in every other Wikiproject. Is there an easy way to find articles that have contradictory assessments of this sort? Ten Pound Hammer(What did I screw up now?) 21:54, 12 September 2019 (UTC)

It should be possible with WP:PETSCAN, you need the intersection of Category:Good articles with subcategories of Category:C-Class articles etc.; you need to enable both mainspace and Talk: space. --Redrose64 🌹 (talk) 22:35, 12 September 2019 (UTC)
I also got a list using the page_assessments database: quarry:query/38930. There are a lot of false positives though, for instance if the article belongs to inactive WikiProjects. I don't think I can check for those. Same query but for FA: quarry:query/38931. I think category intersections such as with Petscan is going to work better. MusikAnimal talk 22:42, 12 September 2019 (UTC)

Template reformattingEdit

  Resolved

How can I reformat {{Anthony}} so that it is a tad wider and so that multiple links may appear on a line?-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:26, 13 September 2019 (UTC)

TonyTheTiger Increase width and remove bullets. --Trialpears (talk) 05:09, 13 September 2019 (UTC)
@TonyTheTiger: Alternatively, increase the width and alter |contentclass=plainlist to |contentclass=hlist. --Redrose64 🌹 (talk) 09:36, 13 September 2019 (UTC)
Redrose64 thank you. Also, thanks to Trialpears, but the other solution seemed easier to me.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 06:18, 14 September 2019 (UTC)

Contribs footer weirdnessEdit

Something about this particular username (maybe the asterisk at the beginning?) seems to be breaking a couple of the links at {{Sp-contributions-footer}}, but I'm afraid I don't know much about the features being used, so I'm not sure where the problem is exactly. Just thought it would be worth bringing up here. Thanks, –Deacon Vorbis (carbon • videos) 03:01, 13 September 2019 (UTC)

Template:Sp-contributions-footer should be fixed a little. I did these changes on fiwiki and extra characters in username are now rendering correctly. Stryn (talk) 08:58, 13 September 2019 (UTC)
Oh, actually not, now it's not working usernames where is a space like "Given name". Stryn (talk) 09:00, 13 September 2019 (UTC)
I fixed it, hopefully without causing any other issues. urlencode takes a formatting option, and using WIKI leaves leading * and : unadulterated (as if it were wikitext) and thus unacceptable for a url; changing to QUERY seems to take care of the issues. Interestingly, a leading # doesn't cause the same issue, not sure if that's intentional or not. ~ Amory (utc) 09:52, 13 September 2019 (UTC)
That also broke on usernames with spaces so I reverted it. I think it would work to wrap urlencode in {{encodefirst}}: {{encodefirst|{{urlencode:{{{1|Example}}}|WIKI}}}}. PrimeHunter (talk) 10:51, 13 September 2019 (UTC)
Urgh, thanks. I tested spaces, but... Anyway, seems DJ and xf took care of it. ~ Amory (utc) 12:57, 13 September 2019 (UTC)

Unable to edit my common.jsEdit

When I edit my common.js and save it by clicking the "Publish changes" button, there is no edit saved. I don't get the timed "Your edit was saved" popup afterwards either. It doesn't matter whether I'm trying to insert new code (e.g. to load another script) or add or edit an existing comment – none of them get saved. The history of the page shows the last edit was in May and my contribs don't show the edit either. I am able to edit User:AlanM1/sandbox as well as WP:Teahouse. Any ideas? —[AlanM1(talk)]— 09:50, 13 September 2019 (UTC)

Disregard. Enabling WikEd and then disabling it again solved the problem for some reason. I'll note for the record that the syntax-checking and coloring wasn't working either (and is now). —[AlanM1(talk)]— 10:00, 13 September 2019 (UTC)

Change mobile skinEdit

The skin preference doesn't affect mobile sites (*.m.wiki*edia.org). I can not change mobile skin no matter how hard I try. So we were chatting on #wikimedia-tech about this. Isarra told me there was a phab task about this problem, and Jon Robson commented there that there is a mobile skin preference but it is hidden. I asked Isarra and other people on #wikimedia-tech, but they didn't seem to know too. Some of them tried to enable it via api, but that ended in failure. Anyway, he told me to find some gadget maker nerds and ask them as "they might know". So I am asking here. How to change skins on mobile? Masum Reza📞 05:39, 14 September 2019 (UTC)

VE and Edit conflictsEdit

I have two column edit-conflict enabled as a Beta feature and it seems that VE is unable to process any edit-conflicts. I was frequently conflicting with an IP over Rupi Kaur and every single time (thrice), the publish button returned a 404 error. I needed to relaunch the edit-page and re-write it, pending which it was possible to publish. WBGconverse 15:28, 14 September 2019 (UTC)

This seems to be (or related to) #cannot save edits 404 error. There are bug reports for it, such as phab:T230272. – Ammarpad (talk) 15:38, 14 September 2019 (UTC)

Can't follow links to .pdf'sEdit

  Resolved

--qedk (t c) 10:29, 15 September 2019 (UTC)

Recently, whenever I try to follow a link to a .pdf, such as for instance this, I only get a blank page, while other people seem able to access it without trouble. Admittedly, I am in the EU, and so I get shut off from various US media because GDPR, but the .pdf thing seems different. There's no message at all, just a blank page. Bishonen | talk 09:24, 15 September 2019 (UTC).

@Bishonen: What is your operating system and browser version? Does it happen for all links to .pdfs (for posterity, the .pdf on the link shows up fine on my Catalina 10.15 machine's Safari 13, Firefox 69, Chrome 76) or only some? --qedk (t c) 09:30, 15 September 2019 (UTC)
OS X El Capitan and Firefox Quantum extended support release, 60.9.0, and it applies to all .pdf's. And, aha, I just tried that .pdf in Safari and it works there. So I can manage. I'd like for the links to work in Firefox, since it's my usual browser, but I can manage. Thank you for your helpful questions, qedk! They made me realise I should try a different browser. Bishonen | talk 09:42, 15 September 2019 (UTC).
Works in Edge on Win10 in the EU too. DuncanHill (talk) 09:44, 15 September 2019 (UTC)
If you go to Options -> Applications on Firefox, what is PDF set to? Nardog (talk) 09:52, 15 September 2019 (UTC)
@Bishonen: you are not alone. DuncanHill (talk) 09:53, 15 September 2019 (UTC)
To spell that out: Click the triple horizontal bar "hamburger" menu button at top right, then click Options. Scroll down to "Applications / Choose how Firefox handles the files you download...". Near the bottom of the list you should see "Portable Document Format (PDF)". If it is set to "Save File", each time you click a pdf, it is downloading that pdf to your downloads directory. You probably have a hundred duplicate pdfs there! The location of the downloads directory can be seen in "Save files to" just above Applications. Johnuniq (talk) 10:01, 15 September 2019 (UTC)
Yeah, I probably have, I never look in dusty corners like my downloads directory (which I never knowingly direct any downloads to). I've now set the .pdf option to "Use Preview (default)", and it works. Thank you all! Bishonen | talk 10:15, 15 September 2019 (UTC).
Glad to know you found the culprit.   --qedk (t c) 10:29, 15 September 2019 (UTC)

Watchlist not showing editsEdit

I'm in Australia (GMT +10) and edited Wikipedia up until about 05:00 today. When I went to edit at about 14:35 today I updated my watchlist but it only shows edits from 07:53. I've changed nothing so I don't understand why it's only showing some edits from today. My prefs are set for 500 edits and the last 5 days but I'm showing nowhere near that. Is this an issue affecting anyone else? --AussieLegend () 06:36, 16 September 2019 (UTC)

Google auto-translate stupidity :-)Edit

 
What part of "fr" did you not understand?

This is kind of amusing. In the process of reviewing Draft:Manoir du Clap, I did a google search for "manoir du clap" and was surprised to discover we already had such an article on enwiki, at least according to Google. Problem is, I couldn't find it. My first guess was maybe this draft was once in mainspace and got draftified, but no evidence of that either. Lots of head scratching ensued. Turns out, the article really is on frwiki (and indeed, if you click on the link, it takes you to frwiki), and Chrome's auto-translation not only translated the text, but "helpfully" translated the hostname too. Mentioning it here in case anybody else has been tripped up by this silliness. -- RoySmith (talk) 16:00, 16 September 2019 (UTC)

This may be related to Project Toledo, even though the project's page does not mention translation back to English. But it's quite similar. – Ammarpad (talk) 16:58, 16 September 2019 (UTC)

No change in sizeEdit

In the mobile version, the diffs always says "No change in size" even if there is change in size. See for example [2].--SharabSalam (talk) 19:52, 16 September 2019 (UTC)

This is phab:T232941. PrimeHunter (talk) 20:30, 16 September 2019 (UTC)

The new updateEdit

I don't know if this is an appropriate place to put my feedback but I have to say that I am not impressed by the very new update to the mobile version, I hope Wikimedia doesn't go forward with this, for example what's the point of having the number of contributions bigger in diffs? I think it should actually be removed from diffs because there is prejudice against those who have few edits in Wikipedia community and therefore they usually get reverted often. Instead Wikimedia made the contribution number bigger! Also my phone screen is small and the numbers make the interface looks weird like the word "edits" disappear when the user has so many rights. Also what's the point of using these icons? to differentiate between anonymous and logged-in users? They are pointless. Anyone can differentiate between the IPs and the logged-in users. I feel like the new update didn't offer any improvement. If this update was the old version and the old version was the update I would actually count the old version as an improvement.-SharabSalam (talk) 00:12, 17 September 2019 (UTC)

It was a regression. It will be resolved together with the task mentioned above. – Ammarpad (talk) 06:02, 17 September 2019 (UTC)

AutoWikiBrowser fails to connectEdit

AWB (version 5.10.1.0, running on Windows 7 64-bit) is failing to connect, reporting:

Error connecting to wiki

An error occured while connecting to the server or loading project information from it. Please make sure that your internet connection works and such combination of project/language exist.

Enter the URL in the format "en.wikipedia.org/w/" (including path where index.php and api.php reside).

Error description: StartIndex cannot be less than zero.

Parameter name: startIndex

and then:

User check problem

Check page failed to load.

Check your Internet is working and that the Wiki is online.

So far as I can tell, my configuration files have not changed since I last successfully used AWB two days ago. Obviously my internet connection is currently working, and Wikipedia appears to be functioning for normal editing.

Is there a problem with the server? Mitch Ames (talk) 11:41, 17 September 2019 (UTC)

@Mitch Ames: seems to be related to phab:T233070. — xaosflux Talk 12:48, 17 September 2019 (UTC)
OK. Thanks. Mitch Ames (talk) 13:06, 17 September 2019 (UTC)

Pageviews tool not working on at least one articleEdit

[3]. "Error querying Pageviews API - Not found." Help? Gråbergs Gråa Sång (talk) 13:08, 17 September 2019 (UTC)

America (Maurizio Cattelan) was moved to the current title today. The tool doesn't use live data. The former name America (toilet) has data [4]. I suppose the tool could check whether the requested page exists currently and give another message but it still wouldn't have page view data. PrimeHunter (talk) 15:31, 17 September 2019 (UTC)

Suppressing inline cite backlinks (the little bold italic letters)Edit

Hello colleagues. When a citation looks like this:

a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk bl bm bn bo bp bq br bs bt bu bv bw bx by bz ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs ct cu cv cw cx cy cz da db dc Howard, Greg (2014-02-06). "The Big Book Of Black Quarterbacks". Deadspin. Archived from the original on 2019-03-04. Retrieved 2019-03-10.

Is there a better way? This is as a result of the source being used a lot in the article, and especially because it is used to source some, but not all, rows in a large table. Can those little letter backlinks (what are they called?) be suppressed, hidden, grouped, or something? It seems to me that it not only looks bad, but is entirely useless to a reader. Is there a doc that covers this? Thanks in advance! Levivich 17:04, 17 September 2019 (UTC)

@Levivich: If you want to hide them for yourself, it's easy - the CSS rule is
span.mw-cite-backlink {
  display: none;
}
and that goes in either Special:MyPage/common.css or Special:MyPage/skin.css, whichever you normally use. It hides both the subscripted letters and the up-arrows that occur when the ref is used just once. --Redrose64 🌹 (talk) 17:42, 17 September 2019 (UTC)
Thanks for the tip! That would hide all cite backlinks for myself; I was wondering if there was a way to hide them (or something) just for that one cite, for readers. Levivich 02:26, 19 September 2019 (UTC)

mw.user.optionsEdit

Is the mw.user.options object in the JavaScript interface a reliable area to store data through scripts (for later access from the scripts)? If so, I am guessing that it can be for setting up scripts for creating private to-do lists and custom watchlists, etc. SD0001 (talk) 06:43, 18 September 2019 (UTC)

You should store it in the actual user preferences (e.g. Just modifying the object client side won't actually store it). But yes, they are saved similarly to normal preferences like the one's in Special:Preferences and are an alternative to using localStorage to save stuff, and unlike localStorage will follow the person around if they log in on a different computer. See also mw:API:Options Bawolff (talk) 05:23, 20 September 2019 (UTC)

Determining what type of search result is returned by WikipediaEdit

Good afternoon Wikipedians!

I have a rather fundamental question.

When you send a search to Wikipedia using the:

http://www.wikipedia.org/search-redirect.php?search=George Washington

URL, it seems like this function returns 3 different manifestations of Wikipedia search:

1) An actual article 2) A disambiguation page 3) A list of articles, like a Google search

3 examples would be:

If you search for “George Washington”:

http://www.wikipedia.org/search-redirect.php?search=George Washington

Would return the George Washington Wikipedia article.

If you search for “tom jones”:

http://www.wikipedia.org/search-redirect.php?search=tom jones

This search returns the disambiguation page for “tom jones”

If you search for “akbur”

http://www.wikipedia.org/search-redirect.php?search=akbur

This returns a listing of articles, much like a Google search does.

My question is, when the pages are returned. How do I determine what type of page was returned, just by analyzing the HTML that is present? What keywords or phrases can my program look for in the HTML to definitively determine that I have come upon a Wikipedia article, disambiguation page or a search listing?

This is made more difficult by the seeming inconsistency of the search results. For instance, when searching and a disambiguation page is returned, some of these pages contain the phrase “may refer to:” and some may contain the phrase “may also refer to:”. And some of these key phases may, seemingly have 1, 2 or even 3 spaces, between these words, in these key phrases, which makes using key phrases, to figure out the type of page returned, that much more difficult.

Thank you!!!!!!!!!

Jroehl (talk) 18:16, 18 September 2019 (UTC)

What's the application for this? It seems like there will be some simpler solution here. --Trialpears (talk) 18:32, 18 September 2019 (UTC)
This is being used for selecting a Wikipedia article on my website. Jroehl (talk) 18:44, 18 September 2019 (UTC)
There is a mw:API which is designed for programs. The normal interface is for humans. By default, the search function goes directly to a page if there is an exact match to the search phrase. The page may be an article, disambiguation page or redirect. If there is no exact match then you get search results. Add &fulltext=1 to the url if you always want search results. The API can be asked directly whether a page exists and what type of page it is. For example, https://en.wikipedia.org/w/api.php?action=query&prop=pageprops&ppprop=disambiguation&titles=Tom%20Jones%7CGeorge%20Washington%7CAkbur shows that Tom Jones is a disambiguation page, George Washington is not, and Akbur doesn't exist. PrimeHunter (talk) 18:58, 18 September 2019 (UTC)
Well, this was very helpful PrimeHunter! Thank you! Jroehl (talk) 19:03, 18 September 2019 (UTC)
@Jroehl: One thing that I notice is that you have spaces in your URLs. These are never valid (see Query string#URL encoding) - you either need to encode them, or use a recognised placeholder character: the plus sign is universal, and Wikipedia also recognises an underscore:
Try these instead. --Redrose64 🌹 (talk) 20:51, 18 September 2019 (UTC)

Thankyou very much Redrose64. It is always important to remember this! Jroehl (talk) 15:59, 19 September 2019 (UTC)

Woolworth BuildingEdit

Something is breaking the formatting on Woolworth Building. For some reason there is nearly a full page of blank space after the sentence "The ornate lobby contains various sculptures, mosaics, and architectural touches." I've tried a couple things but nothing worked. Ten Pound Hammer(What did I screw up now?) 06:36, 19 September 2019 (UTC)

I think your dummy edit (a minute before posting the above) must have fixed it because I don't see a problem now. Johnuniq (talk) 07:27, 19 September 2019 (UTC)
@Johnuniq: I'm still seeing it even after a reload and cache purge. Ten Pound Hammer(What did I screw up now?) 07:36, 19 September 2019 (UTC)
@TenPoundHammer: Please confirm we are talking about the second paragraph in the lead of Woolworth Building which has URL https://en.wikipedia.org/wiki/Woolworth_Building. What I mean is, you are not using the mobile website? I checked that there is nothing other than normal text following "and architectural touches." You pressed Ctrl+F5 or some other equivalent for the reload (not just F5)? Johnuniq (talk) 07:47, 19 September 2019 (UTC)
@Johuniuq: Even after a ctrl-F5, it still looks like this. Ten Pound Hammer(What did I screw up now?) 23:06, 19 September 2019 (UTC)
re-ping @Johnuniq: since I misspelled the first time. Ten Pound Hammer(What did I screw up now?) 23:06, 19 September 2019 (UTC)
So it's not after a sentence but after "The" at the end of a line. Your screenshot is in MonoBook. The default skin at Special:Preferences#mw-prefsection-rendering is Vector. I see no problem in any tests, and I tried MonoBook with zoom and window width adjusted to get the same line breaks as you. What is your browser? Does it happen in Vector or safemode or when you log out? Does the broken sentence continue with "structure" later? Exactly where relative to the infobox? PrimeHunter (talk) 23:36, 19 September 2019 (UTC)
It doesn't happen in Vector or Safemode. The "structure" sentence continues after the very bottom of the infobox. Ten Pound Hammer(What did I screw up now?) 01:52, 20 September 2019 (UTC)
What happens if you click the "is in MonoBook" link in PrimeHunter's comment? In theory, ?useskin=monobook should be the same as having monobook in preferences, but the different URL might get a different response from your browser? Johnuniq (talk) 05:13, 20 September 2019 (UTC)
I was able to reproduce this in Monobook, but only if the width of the page is exactly 1349 pixels (screenshot). rchard2scout (talk) 10:35, 20 September 2019 (UTC)

Aligning numbers in a tableEdit

demo
85.468
132.91
223

I have numbers in various 'sizes' in a table (see demo right). I want to have them aligned as decimal number, i.e., all decimal signs (=periods) below each other. What are today's best practices available? Any smart template I have not found yet? -DePiep (talk) 14:42, 19 September 2019 (UTC)

Maybe Help:Table#Decimal point alignment is still true. Thincat (talk) 15:32, 19 September 2019 (UTC)
thx. Should have found that before. -DePiep (talk) 15:41, 19 September 2019 (UTC)

Technical help needed on Slovak WikipediaEdit

Hi, I am sorry to bother you here on English Wikipedia but we do not have technical users on our one, so after wrongly using Phabricator for the first time, I hope this could be a place where I will find somebody that will be able to help.

What I need to help with: Our Community portal looks good when accessing it on desktop. This, however, does not apply for the mobile view. So I basically need help with making the page responsive so that it displays correctly on all kinds of displays.

Here is the detailed request (on Phabricator): phabricator:T231949

It was recommended to me to get inspired by this responsive template, so I hope that can help.

If you want to help, feel free to contact me on wiki (here, Meta, Slovak one, ...) or via e-mail and we can discuss further. If there is going to be a need to create a css or js file, I can request interface admin's rights and put it there, meanwhile, it can be tested on Testwiki.

Thanks a lot for reading this!

--Luky001 (talk) 16:02, 19 September 2019 (UTC)

Likelihood of User:Evad37/XFDcloser.js becoming a gadget?Edit

Per Wikipedia:Gadget, I'm attempting to start a discussion here about the likelihood of User:Evad37/XFDcloser (commonly referred to as "XFDcloser") being eligible to be promoted to "Gadget" status. For those who do not know what this script is used for, it is used to automatically close a majority of types of WP:XFD discussions. There are quite a few editors who use this script, including myself. However, if it can be, I think it is time for this script to become a gadget (provided that it meets all criteria in Wikipedia:Gadget#General criteria for gadgets.) The main reason I'm proposing this script become a gadget is not only because of several editors using it, but also since its creator/maintainer, Evad37, hasn't edited in almost a month and a half, and if it were promoted to a gadget, other editors could respond to update requests to the script. So ... does this look like a good candidate for "Gadget"-ification? Steel1943 (talk) 16:58, 19 September 2019 (UTC)

It can be hard to tell on these, but WLE results show <100 people are actually using this (and I haven't attempted to determine how many are active). If gadget-izing, the users would need to actually make a change to use the new gadget. The old script could possibly be changed with a "Deprecated" alert or something. I'd like to see if Evad37 has any comment on this first though; has anyone tried emailing him? — xaosflux Talk 17:21, 19 September 2019 (UTC)
I would be against gadgetizing this. This is a niche tool, not something that RandomJoe123 needs access to. Headbomb {t · c · p · b} 17:34, 19 September 2019 (UTC)
Actually, this reduces the number of people who can change the script: we go from all interface admins + Evad himself to just all interface admins. (It may increase the number of people willing to implement an edit request, but that is not a question of can but willing to.) --Izno (talk) 17:36, 19 September 2019 (UTC)
...Ah yes, I forgot about the recent addition of the interface administrator user right ... an admin exclusive. I'm tempted to say "Never mind about this whole thing" now. Steel1943 (talk) 17:48, 19 September 2019 (UTC)
@Izno: so yes, technically it reduces it by exactly 1 person. However: Evan could request access as he is an admin, as far as processing edit requests go: interface admins are much more likely to implement an edit request made for a gadget then to some personal user script. If the maintainer is inactive, another option for you @Steel1943: would be to fork the script, and make it Steel1943's XFD closer script. — xaosflux Talk 18:08, 19 September 2019 (UTC)

A few issues with Template:Graph:ChartEdit

I've discovered a few issues with Template:Graph:Chart. I made my first comment at the talk page a few days ago but it hasn't received any replies, so I'm hoping a message here will spark some interest. The sections are Template_talk:Graph:Chart#Problem_with_<nowiki>_and_this_template and Template_talk:Graph:Chart#showSymbols_doesn't_respect_opacity_values. 202.159.169.45 (talk) 23:52, 19 September 2019 (UTC)

Template:OrphanEdit

Looking at the source, I think this is meant to be an ambox, but it does not actually render for some reason. I found this issue when I proceeded to add the tag to Patchwork religion, currently linked only from this page and a 2010 RfD, to find that it had already been tagged in 2015. However, someone else may have noted that this tag is invisible. I cannot try to fix it myself because the page is template-protected. –LaundryPizza03 (d) 02:40, 20 September 2019 (UTC)

Please, read the documentation of {{orphan}}. Ruslik_Zero 04:35, 20 September 2019 (UTC)

Alarming "only a preview message"Edit

I use the MonoBook skin. Yesterday, when editing, I started to see a large pink box with an orange border:

This is only a preview; your changes have not yet been saved! → Go to editing area

I think the warning was there before, but it was not so jarring. Any ideas on how to tone it down? Aymatth2 (talk) 13:45, 20 September 2019 (UTC)

@Aymatth2: looks like that is getting its markups from the warningbox class, and from bolding at MediaWiki:Previewnote. That entire box is a div, class "previewnote" so you could just suppress it in your personal skin. Do you have a specific suggestion for what you think it should be changed to? — xaosflux Talk 14:00, 20 September 2019 (UTC)
It was changed to use standard warningbox class at phab:T232414. I also think the new style is too garish. – Ammarpad (talk) 14:14, 20 September 2019 (UTC)
Surely we should be encouraging the use of preview (to reduce typos, formatting errors, etc) rather than disconcerting those of us who do use it? DuncanHill (talk) 14:26, 20 September 2019 (UTC)
@DuncanHill: In my opinion "I think" it's too garish. I am not asking for it to be changed, but I'll change it for my account when I want. So I am not disconcerting anybody. Thanks. – Ammarpad (talk) 15:06, 20 September 2019 (UTC)
I wasn't suggesting that you were disconcerting anyone. I was suggesting that the message is disconcerting and perhaps counterproductive. DuncanHill (talk) 15:11, 20 September 2019 (UTC)
Ping to User:Volker E. (WMF) - the WMF staffer that drove that change. Volker, any options to soften this that would fit in with the rest of the UX? — xaosflux Talk 14:28, 20 September 2019 (UTC)
I've removed the bolding of the text, as it is now in a call out box. — xaosflux Talk 14:31, 20 September 2019 (UTC)
The message appears just under a large "Preview" header, so it is obvious that it is a preview. I would prefer to just drop the pink box and leave the message, unbolded:
Preview

This is only a preview; your changes have not yet been saved! → Go to editing area

Aymatth2 (talk) 14:33, 20 September 2019 (UTC)
It is possible to remove that h2 label, but the hl will still be there (in MediaWiki:Preview). — xaosflux Talk 14:39, 20 September 2019 (UTC)
@Xaosflux:, why does MediaWiki:Preview display a deletion log entry when there is a page that exists there, with the source being 'Preview'? Headbomb {t · c · p · b} 15:16, 20 September 2019 (UTC)
It's a Mediawiki "message" so it's reflecting the default from the source. When you add content it overrides the source message. The content was deleted because it's the same as the source. – Ammarpad (talk) 15:28, 20 September 2019 (UTC)
You could add this to your CSS:
.previewnote .warningbox {border: none; background-color: white;}
That reminds me, I have been thinking about creating a page for tips on reverting unwanted interface changes. There could be general tips (like clear your cache, update your browser, try removing broken user scripts), and a list of specific instructions for specific changes, but also a list of some things which cannot be reverted. It might be called Wikipedia:Take me back. Good idea? PrimeHunter (talk) 14:43, 20 September 2019 (UTC)
  • One of the very jarring thing about the warning is its non-standard size. It should be {{fmbox}} or {{ombox}} size. Something like
or
would be much better IMO. Headbomb {t · c · p · b} 14:58, 20 September 2019 (UTC)
I added
.previewnote .warningbox {border: none; padding: 0; margin: 0; background-color: white;}
and that put it back the way it was, I think. Maybe it should be a preferences option. Aymatth2 (talk) 15:08, 20 September 2019 (UTC)
Agreed. I thought it was some bug from last night, but it's still there now. At least there's a workaround. Thanks again to all the tech coders out there! Lugnuts Fire Walk with Me 17:01, 20 September 2019 (UTC)

Template expansion depthEdit

There has been a change to how the maximum template expansion depth is handled. The maximum is still 40 but the change has increased the expansion depth calculated for the page so that some deeply nested templates are now broken. This happens with a number of cladograms constructed using the {{clade}}, as can be seen in Afrophidia. Pages generating the error can be found at Category:Pages where expansion depth is exceeded. Strangely, some of the cladogram still look OK on the saved page but fail in edit preview. I think this is due to caching, but cannot explain why these pages look OK but already appear in the error tracking category.

The following code used to be able to expand 40 nested templates, but now fails at 21.

* Nest 21 templates: {{1x|1 {{1x|2 {{1x|3 {{1x|4 {{1x|5 {{1x|6 {{1x|7 {{1x|8 {{1x|9 {{1x
|10 {{1x|11 {{1x|12 {{1x|13 {{1x|14 {{1x|15 {{1x|16 {{1x|17 {{1x|18 {{1x|19 {{1x|20 {{1x |'''21'''}}
}}}} }}}} }}}} }}}} }}}}  }}}} }}}} }}}} }}}} }}}}
  • Nest 21 templates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 {{Expansion depth limit exceeded|21}}


You can see similar examples at Checking the current expansion limit and [5] :mw:Help:Expansion_depth#Nesting depth on the page itself. These still appear to allow transclusion to a depth of 40, but if you test in edit preview they fail at 21. Again, I think that this is because cached pages are being displayed.   Jts1882 | talk  16:13, 20 September 2019 (UTC)