Wikiafripedia:Village pump (technical)

From Wikiafripedia, the free encyclopedia that you can monetize your contributions or browse at zero-rating.
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikiafripedia. 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: Wikiafripedia: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 Wikiafripedia: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, no archives yet (create)

Suppress rendering of Template:Wikiafripedia books[edit source | edit]

As many are aware Wikiafripedia 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:Wikiafripedia 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 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 Wikiafripedia: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 (Wikiafripedia books)[edit source | 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 Wikiafripedia 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 per "does not work" If it gets fixed in the future, discuss re-implementation then. — Ched (talk) 11:48, 30 September 2019 (UTC)

Sidebar link[edit source | edit]

  • 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)
    That message also seems misleading when the "Learn more" link is clicked and sends readers to this page. The latest update, 15 July 2019, indicates that a PDF renderer is in place and in "maintenance mode" while feedback is encouraged. So that misleading message noted by editor UnitedStatesian needs to be updated at the very least. P. I. Ellsworthed. put'r there 14:40, 21 September 2019 (UTC)
    It is in the Special namespace, so I assume it needs the software maintenance community to update it. I guess we also need to wait for the outcome of this RfC before we can define the changes needed. — Cheers, Steelpillow (Talk) 08:58, 22 September 2019 (UTC)
    It's not clear what part of the special page you're saying is misleading ("can export the book in different formats (for example PDF or ODF"?), however it can probably be changed by editing pages in the MediaWiki namespace without any involvement of the software maintenance community. * Pppery * it has begun... 15:57, 28 September 2019 (UTC)
    To Pppery: it's the message in the warning box at the top of the page, which reads, Due to severe issues with our existing system, the Book Creator will no longer support saving a book as a PDF for a short period of time. We are working hard to replace our system and re-enable PDFs within the Book Creator. Put that together with the info found on the "Learn more" page, plus the next notice about single-page downloading, and it all adds up to a distinct possibility that somebody forgot to update those warnings. P. I. Ellsworthed. put'r there 06:52, 29 September 2019 (UTC)
    To Pppery: Yes, the message that "You can export the book in different formats (for example PDF or ODF)" is outdated. The suggestion in the warning box that "we are working hard", when the "Learn more" links to a page saying that it has since been shrugged off to PediaPress in the hope that something will happen, also needs updating. It also needs making clearer that the Book Creator can be used to prepare books for rendering and/or post-processing by services such as MediaWiki2LaTex. But I cannot find any page on MediaWiki with this content (e.g. including the phrase "With the book creator") as you suggest might be there - am I missing something? — Cheers, Steelpillow (Talk) 13:59, 29 September 2019 (UTC)
    (replying to both comments) You are missing something -- the text of the "due to severe issues" box is MediaWiki:Coll-warning-disable-pdf-text, and the "You can export" message is MediaWiki:Coll-book creator intro. If you think either of those boxes should have different content, you could submit an edit request at the talk page for each message. * Pppery * it has begun... 15:12, 29 September 2019 (UTC)
    Thank you. Quite why this search does not find it, despite my copy-pasting the search phrase from the page you gave, is beyond me. Also, you don't happen to know where the "Learn more" text and link is maintained? The reading/web team have passed maintenance of the Collection Extension on to a maintenance team (whose identity I have managed to misplace), so the Learn More link should probably be updated accordingly. However, as I said, I will wait for this RfC to run its course before I ask for any changes. — Cheers, Steelpillow (Talk) 17:33, 29 September 2019 (UTC)
    The text "Learn more" is MediaWiki:coll-warning-learn-more. The page on that it links to is hardcoded and cannot be changed easily (although that page is on a wiki, so the contents of that page could be edited). If you are intending to ask something about the social aspect of who maintains the extension rather than the technical aspect of how it works, then that's beyond me. * Pppery * it has begun... 18:53, 29 September 2019 (UTC)
    Thank you again. The extension hardcodes a fair number of special pages. Looks like the place to engage will have to be the Collection project on phabricator. — Cheers, Steelpillow (Talk) 10:24, 30 September 2019 (UTC)
  • Comment. I thought it useful to post the following message I received here: "...the Collection extension ... is a valuable tool for the wiki that I'm running ( Once we have the resources, we'll try and figure out a solution to get it back up and running. We're anxiously waiting for a new version of the Collection extension and we will happily devote some ressources maintaining and improving it ." Wikimedica is a medical wiki where French-speakers are building a resource of medical knowledge. This helps us to understand the implications of what our software can mean to others, even if they do not come to our village pump. — Cheers, Steelpillow (Talk) 19:17, 23 September 2019 (UTC)
  • Support -- It doesn't appear to be doing the English Wikiafripedia any good. Quite honestly, it doesn't matter to me in the slightest what a non-Wikimedia organization of any sort does. Our site comes first.-- Dolotta (talk) 02:25, 24 September 2019 (UTC)
  • Strong oppose because the book creation button (while too buggy for PDF now) is still required to download the readable EPUB offline e-books. 2001:16B8:5C64:FA00:C0BE:7F14:48C8:A226 (talk) 11:15, 25 September 2019 (UTC)

Discussion after reverted closure[edit source | edit]

Reverted close: WAP: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 Wikiafripedia 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 Wikiafripedia: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 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 Wikiafripedia 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 , 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)


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 Wikiafripedia 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 Wikiafripedia 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 Wikiafripedia 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 Wikiafripedia 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 Wikiafripedia 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

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 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)


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 Wikiafripedia 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 Wikiafripedia, 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 Wikiafripedia 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 Wikiafripedia 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)

Wikiafripedia 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)

Alarming "only a preview message"[edit source | 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)
Thanks for pinging me, User talk:Xaosflux. That's correct, we've amended the message box to follow all standard warnings across pages and products. phab:T232414 was just the latest. This has been changed to provide users consistent system message appearances. While we do understand that this might be unusual for users knowing the before state, it's meant to make orientation for all users simpler. As I've seen there are already ways described below for dealing with the change for people who would like to have a toned-down warning instead. Volker E. (WMF) (talk) 05:10, 21 September 2019 (UTC)
Yet another unwanted "improvement" that no one asked for, and yet again you suggest that it's all right and users should invent workarounds on their own. — Mike Novikoff 06:35, 21 September 2019 (UTC)
@Volker E. (WMF): - could you let us know the following: how many editors stated they wanted a more consistent style; why no warning, or at least an FYI, wasn't given here, if you think workarounds are beneficial, why not create a meta page explaining/summarising how? Nosebagbear (talk) 09:40, 21 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:

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 Wikiafripedia:Take me back. Good idea? PrimeHunter (talk) 14:43, 20 September 2019 (UTC)
Seems like a great idea to me User:PrimeHunter. Jdlrobson (talk) 18:40, 26 September 2019 (UTC)
I made a similar suggestion for someone who wanted to move the third column for Timeless down the way; making it a subpage of WAP:Skin or WAP:Customization would be great. --Izno (talk) 20:00, 26 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
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)

My personal choice here would be {display:none}, as usual.

Unfortunately, all these {display:none}'s don't bring back the lost performance, especially with this case that turned my 1Ghz CPU into a toaster. It's a real pity that MW becomes a bloatware, and worse yet, that the devs just won't listen. — Mike Novikoff 21:21, 22 September 2019 (UTC)

Above discussed change does not negatively affect the performance at all. It has actually reduced CSS code sent to all users by using the standard warning box and not a specific override for solely the previewnote – regardless if the users are editing the page or not. Volker E. (WMF) (talk) 06:46, 3 October 2019 (UTC)
But my 1Ghz CPU is already a toaster when it comes to a page history or user contributions. You know, I have an indigestion every time I even hear of Phab since the last time I've cried in despair and had got nothing but a warning (isn't that an ad hominem?). Everything else just confirms the pattern. — Mike Novikoff 13:07, 4 October 2019 (UTC)

Maplink time expired[edit source | edit]

I noticed a problem about two weeks ago and wrote the following to describe it. However, by the time I got around to posting it a day later, the problem had gone away. It has returned and FWIW here it is.

Previewing the following (extracted from {{Infobox road}} in Heartland Expressway) in a sandbox gives "The time allocated for running scripts has expired" with a result similar to "Lua time usage: 12.751/10.000 seconds" in the NewPP report in the page's HTML source.

{{maplink|frame=yes|plain=yes|frame-align=center|frame-width=290|frame-height=290|type=line|raw={{Wikiafripedia:Map data/Wikiafripedia KML/Heartland Expressway}}}}

The same problem can be seen at Interstate 84 in Oregon and possible other articles. Any thoughts? Johnuniq (talk) 07:53, 28 September 2019 (UTC)

The last change to Module:Mapframe added an additional condition. Ruslik_Zero 08:13, 28 September 2019 (UTC)
A few things. First, why is what looks to be a json page not being stored as one? Second, why is it being stored in Wikiafripedia space rather than Template space? --Izno (talk) 12:52, 28 September 2019 (UTC)
Three tings. Firstly the Maplink module is in beta, and thus not coded to be efficent just yet. Secondly the json kml file is large (it is almost 85 kilobytes) and has coordinates where the difference between either the langitude or longitude is less than 0.01. Thirdly, to explain the intermittent issue, templates and modules that run close to the limit can go over it when the server is under higher load than normal.--Snaevar (talk) 14:13, 28 September 2019 (UTC)
Yes, but no reasonable Lua module should use 12 seconds. Johnuniq (talk) 07:59, 29 September 2019 (UTC)

I played around with {{maplink|raw={{Wikiafripedia:Map data/Wikiafripedia KML/Heartland Expressway}}}} from Heartland Expressway. The NewPP report for the article shows Lua time usage: 12.047/10.000 seconds. The pages used are Template:Maplink + Module:Mapframe + Wikiafripedia:Map data/Wikiafripedia KML/Heartland Expressway. The module finishes with a call to display a large (87,101 bytes) <mapframe> file which apparently uses mw:Extension:Kartographer. Previewing an edit to the module which does everything except call Kartographer requires 0.34 seconds of Lua time. Conclusion: Kartographer is taking nearly 12 seconds and that fails because the time is counted against Lua which has a 10-second limit (more than enough for anything reasonable using pure Lua). I was thinking about investigating the module which has a dozen unintended globals and might need tweaking. However, the basic problem might be Kartographer, or the fact that Kartographer's time is debited to Lua. Johnuniq (talk) 07:59, 29 September 2019 (UTC)

Johnuniq, I was able to get a couple others to work by using Module:Mapframe KML but now instead of issuing a script error, they simply fail to show the map like this one. so, perhaps not an improvement. note that User:Mr. Matté was able to fix a couple of them by simplifying the map files. there is some related discussion at WAP U.S. Roads. Frietjes (talk) 18:45, 1 October 2019 (UTC)

Tens of thousands of new articles in Category:Pages with script errors[edit source | edit]

It appears that tens of thousands of articles have appeared in Category:Pages with script errors recently. It may be conincidence, but many of them appear to call the newly created Module:String/i18n. Do any Module-savvy / i18n-savvy technical folks care to take a look? – Jonesey95 (talk) 19:20, 29 September 2019 (UTC)

Jonesey95, That module has pruposefully been kept empty and should be salted and deleted as quickly as possible. This is causing a lot of damage. --Trialpears (talk) 19:25, 29 September 2019 (UTC)
It's now deleted. -- WOSlinker (talk) 19:40, 29 September 2019 (UTC)
Previously, at Wikiafripedia:Village_pump_(technical)/Archive_166#Module:Infobox/i18n

[pings omitted] Wouldn't it be easier to just revert the edit by Ans, instead of protecting lots of /i18n subpages which will never be needed? I find it unlikely that some random module is going to have an /i18n subpage which needs to supersede the i18n table of Module:Wikidata (which is apparently what the change is supposed to allow for). Jc86035 (talk) 21:38, 26 June 2018 (UTC)

This is still a good idea. * Pppery * it has begun... 20:30, 29 September 2019 (UTC)
(the actual edit that would need to be reverted is Special:Diff/804685646, not Special:Diff/804076706 as the quoted comment claims, but the point still stands). * Pppery * it has begun... 20:32, 29 September 2019 (UTC)
I thought that we'd sorted this. Informing participants from last time: Emir of Wikiafripedia, Home Lander, Johnuniq, Nthep, RexxS, Thayts and Xaosflux. --Redrose64 🌹 (talk) 21:27, 29 September 2019 (UTC)
Would support that, doesn't seem to be used outside of Module:Adjacent stations/i18n which could be handled separatley (found by looking at all modules with i18n in their names). --Trialpears (talk) 21:28, 29 September 2019 (UTC)
Module:Adjacent stations/i18n is entirely unrelated to this system. * Pppery * it has begun... 21:42, 29 September 2019 (UTC)
I noticed this too and thought it was related to Module:Wikidata, but apparently not. Out of curiosity: what were the contents of Module:String/i18n? Module:I18n checks if the i18n submodule table is not empty by using next(res) and then references res.i18n. So if the table has at least one key, but no key named i18n, then an error will be thrown. Instead, Module:I18n should check if that key exists. Thayts ••• 07:26, 30 September 2019 (UTC)
Module:String/i18n was a dummy module with correct syntax that returned a string instead of a table of i18n text. Errors would have occurred when the calling module tried to index the expected table. I am currently trying to work out why Module:String/i18n is "used" at Hideaki Yamada. It is the {{cite Sports-Reference...}} reference that causes three i18n items to appear in the "Pages transcluded" list. Johnuniq (talk) 08:17, 30 September 2019 (UTC)

At Hideaki Yamada, replacing all content with {{cite sports-reference|url=}} and previewing shows the three i18n modules being called (Module:I18n + Module:String/i18n + Module:Wikidata/i18n). Repeating that after adding |check-wikidata=no shows that no i18n modules are called (wikitext {{cite sports-reference|url=|check-wikidata=no}}). {{cite sports-reference}} calls various string templates such as {{str find}} and somehow one of them must lead to Module:String/i18n being tested for existence. If anyone has some time to pursue this, please let us know how Module:String/i18n ends up being called. Johnuniq (talk) 11:02, 30 September 2019 (UTC)

Simplifying the contents of that article to {{#invoke:String|match|{{#invoke:Wikidata|getPropertyIDs|P31|FETCH_WIKIDATA}},|Q5,|1|1|true|}} (code taken from {{cite sports-reference}}) results in a call to Module:String/i18n. There is probably a more concise case that would call it, but the only templates or modules trancluded by that code are Module:I18n, Module:No globals, Module:String, Module:String/i18n, and Module:Wikidata. Poking through Module:Wikidata, I see this code that might be relevant:
--require("Module:i18n").loadI18n("Module:Wikidata/i18n", i18n)
-- got idea from [[:w:Module:Wd]]
local module_title; if ... == nil then
	module_title = mw.getCurrentFrame():getTitle()
	module_title = ...
require('Module:i18n').loadI18n(module_title..'/i18n', i18n)
I got lucky with my initial guess at the start of this section. I do not expect to strike gold twice. Lua wizards are welcome to dig more. – Jonesey95 (talk) 14:11, 30 September 2019 (UTC)

I believe I understand how Module:String/i18n is being called, although the explanation depends on several obscure features and what may be a bug in how Lua is implemented. First of all, to answer some of the comments above, this is related to Module:Wikidata, specifically the block of code Jonesey95 quoted above.

In detail: arguments to Lua modules are evaluated lazily, meaning that in the simplified example {{#invoke:String|match|{{#invoke:Wikidata|getPropertyIDs|P31|FETCH_WIKIDATA}},|Q5,|1|1|true|}} , Module:Wikidata isn't actually called until Module:String attempts to access the value of its first argument. When that happens and Module:Wikidata runs and, since ... is not defined, calls mw.getCurrentFrame(). Due to what I think is a bug, that function returns the frame for the toplevel Module:String call, not the inner Module:Wikidata call, meaning that its getTitle method returns "Module:String", resulting in Module:i18n attempting to load Module:String/i18n.

The actual content of Module:String is mostly irrelevant here; all that matters is that it uses arguments; I could create a call of Module:BananasArgs/i18n via {{#invoke:BananasArgs|hello|{{#invoke:wikidata|pageId}}}} ( Hello, !), as you can see via the pages transcluded on this page. * Pppery * it has begun... 15:10, 30 September 2019 (UTC)

@Pppery: You're right about how this came to be. But I don't think that mw.getCurrentFrame() is bugged; it's supposed to return the toplevel frame. I've copied all relevant modules into sandboxes and played around with them, and I've found that if you use the frame that is passed to the called function of Module:Wikidata instead (e.g. p.getPropertyIDs = function(frame), see [1]), then the correct module_title is retrieved. So this can be solved by changing Module:Wikidata to load i18n differently, in a similar way as Module:Wd.
Next to that, the check in Module:I18n with next(res) should be replaced with a check to see if res.i18n exists and if that is a table. Thayts ••• 20:36, 30 September 2019 (UTC)
Or just revert the aformentioned edit by Ans; it's only purpose was to make Module:Wikidata insignificantly easier to move. * Pppery * it has begun... 20:51, 30 September 2019 (UTC)
I've modified Module:Wikidata so that it only attempts to load an internationalisation module on non-English Wikis. I think that should remove the problem here. I expect other language wikis that copy this module will create their own i18n module, so there won't be a problem with its absence. The issue with mw.getCurrentFrame() still needs fixing, of course. --RexxS (talk) 21:26, 30 September 2019 (UTC)
@RexxS: Thanks, but it will still be a potential problem on those other wikis. As far as I can see, the only work-around is to use the frame passed in the function call instead (or to revert Ans' edit). Thayts ••• 22:03, 30 September 2019 (UTC)
@Thayts: I thought the relevant code (lines 82–106) in this version worked fine in any wiki, but apparently it needed to be changed. Anyway, we can keep making work-arounds, but as long as mw.getCurrentFrame() fails to get the current frame (i.e. the frame invoked with the current code), we're permanently chasing our own tails. --RexxS (talk) 23:15, 30 September 2019 (UTC)
Yes, that worked fine except if the module were to be named differently on another wiki. Anyway, there are several possible solutions currently at hand. Thayts ••• 06:50, 1 October 2019 (UTC)
@Pppery: Looks like you're right, when mw.getCurrentFrame() is called at the module level (not inside a function) in the inner #invoke it picks up the frame from the outer #invoke rather than getting its own frame created for the module-level processing. You should file a task in Phabricator about it. Anomie 20:52, 30 September 2019 (UTC)
Reverting could of course also be done. Looking at the documentation of mw.getCurrentFrame(), it should return the frame object from the most recent #invoke. The laziness explains that mw.getCurrentFrame() is even able to get Module:String's frame object, but the most recent invoke is then indeed that of Module:Wikidata. Thayts ••• 21:17, 30 September 2019 (UTC)

Found problem[edit source | edit]

Hello- at the top of the Raid on Taipei article, there are two semicolons ("; ;") that are generated as part of Template:cjkv. I don't know how to fix this, but I think someone should fix this at some point. Thanks for any help. Geographyinitiative (talk) 04:24, 30 September 2019 (UTC)

I added |t=臺北大空襲 to the {{cjkv}} template. This removed the extra semi-colon in the article. It's not clear to me what the intent is when a parameter is missing. In this example, in the absence of |t= or |c= the template seems to assume that the Japanese is the same as tradition chinese and changes the text accordingly (but leaves the extra semi-colon). I assume this is correct as that was what was in the article. Ideally the template could be modified to avoid adding the extra semi-colon without the duplication, but that template code is convoluted.   Jts1882 | talk  06:34, 30 September 2019 (UTC)
@Jts1882: You changed this
{{cjkv|j=臺北大空襲|r=Taihoku Daikūshū|t=臺北大空襲|p=Táiběi Dà Kōngxí}}
to this
{{cjkv|j=臺北大空襲|r=Taihoku Daikūshū|t=臺北大空襲|p=Táiběi Dà Kōngxí}}
and so the |t=臺北大空襲 parameter now occurs twice. Also, the extra semicolon is still there. --Redrose64 🌹 (talk) 08:33, 30 September 2019 (UTC)
Oops. I made two changes. I first added |c=臺北大空襲 which removed the semi-colon.
Then I noticed that it said "chinese" instead of "traditional chinese" and replaced the |c= with |t=, which restored "traditional chinese", but didn't notice the semi-colon came back.
Looks like someone will have to delve into that template code if the problem is to be fixed.   Jts1882 | talk  08:47, 30 September 2019 (UTC)
The spurious semicolon is the eighth &#x3b;&#x20; pair. This is produced by the last of three complex tests thus:
{{ #ifexpr: {{ #if: {{{p|}}} | 1 | 0 }} or {{ #if: {{{tp|}}} | 1 | 0 }} or {{ #if: {{{cy|}}} | 1 | 0 }} or {{ #if: {{{w|}}} | 1 | 0 }} or {{ #if: {{{r|}}} | 1 | 0 }} or {{ #if: {{{k|}}} | 1 | 0 }} or {{ #if: {{{rr|}}} | 1 | 0 }} or {{ #if: {{{v|}}} | 1 | 0 }} or {{ #if: {{{l|}}} | 1 | 0 }} | &#x3b;&#x20; }}
--Redrose64 🌹 (talk) 20:19, 30 September 2019 (UTC)

WikiMiniAtlas not working on the Czech Wikiafripedia[edit source | edit]

Hello, sorry for asking here, but I got no response elsewhere. On cswiki WikiMiniAtlas gadget does not work anymore, could you help? We suspect this is due to changes in our Coord template. What should Coord template fulfill to make WikiMiniAltas work there again? Or do we have got some error in our gadget definition? (w:cs:MediaWiki:Gadgets-definition and w:cs:MediaWiki:Gadget-WikiMiniAtlas.js) --Dvorapa (talk) 10:25, 30 September 2019 (UTC)

What error do you get? Ruslik_Zero 20:59, 30 September 2019 (UTC)
@Ruslik0: I get no error (console log is empty), it just does not do anything. --Dvorapa (talk) 04:04, 1 October 2019 (UTC)
Dvorapa, it has to do with your template. The WMA script looks for the selector: "#coordinates > span > a" to find the geo hack link and your templates no longer match that content. —TheDJ (talkcontribs) 07:28, 1 October 2019 (UTC)
Maybe this should be configurable? --Dvorapa (talk) 17:21, 1 October 2019 (UTC)
Or more general (a[href^=//geohack] or something)? --Dvorapa (talk) 17:38, 1 October 2019 (UTC)

Tech News: 2019-40[edit source | edit]

16:49, 30 September 2019 (UTC)

Quick heads up: It appears that on WAP:THURSDAY there might be some CSS that needs tweaking. People who understand CSS might be able to divine the situation by looking at this edit. You can test this at now, as it's already Thursday there. ;-) Whatamidoing (WMF) (talk) 20:59, 2 October 2019 (UTC)

Weird ref, citation, white space interaction bug[edit source | edit]

Without the line feed the citation is messed up.



AManWithNoPlan (talk) 23:22, 30 September 2019 (UTC)

@AManWithNoPlan: Shouldn't it be:
I was under the impression we shouldn't be using wikimarkup inside CS1 parameters. --RexxS (talk) 23:56, 30 September 2019 (UTC)
Something is going wrong. People expect to be able to have quote marks and apostrophes . AManWithNoPlan (talk) 00:12, 1 October 2019 (UTC)
You have unbalanced markup. The parser doesn't know that you want an actual apostrophe. Use {{'}} for the apostrophe whenever you are writing the possessive of an italicized name, like this:[4]Jonesey95 (talk) 01:53, 1 October 2019 (UTC)
Jonesey is correct here. The other way to do it of course is to take the lone apostrophe and use the reference value for it instead. --Izno (talk) 02:05, 1 October 2019 (UTC)
Alas, Editor Jonesey95 is not correct here. The template {{'}} renders as this:
<span class="nowrap" style="padding-left:0.1em;">&#39;</span>
All of that styling is why that template is marked as not safe for COinS.
Trappist the monk (talk) 12:11, 1 October 2019 (UTC)
Rexx, generally. Some wikimarkup is supported in certain parameters. --Izno (talk) 02:06, 1 October 2019 (UTC)
Still odd that a line feed mattered. AManWithNoPlan (talk) 02:20, 1 October 2019 (UTC)
Just to prove that this isn't some artifact produced by Module:Citation/CS1, this <ref>''30 Rock'''s.</ref>[5] gives the same result. Here is the html from this page:
<li id="cite_note-5"><span class="mw-cite-backlink">'<i><a href="#cite_ref-5">^</a><b></b></i></span><i><b> <span class="reference-text"></span></b></i><b>30 Rock</b>s.</li>
And using &#39; <ref>''30 Rock''&#39;s.</ref>[6] and its html:
<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text"><i>30 Rock</i>&#39;s.</span></li>
Trappist the monk (talk) 12:11, 1 October 2019 (UTC)
The reason the newline matters is because the Cite extension displays the reference wikitext by substituting it into MediaWiki:Cite references link one. The resulting wikitext resembles '''foo''' ''bar'''s that happens to be interpreted in an unexpected manner. Including the newline puts a newline in that wikitext, and since apostrophe markup only works within a single line there's no ambiguity. Fixes might include replacing the ''' in MediaWiki:Cite references link one with <b>...</b> or <strong>...</strong> or formatting the citation with <i>...</i> to avoid the misinterpretation of apostrophe-wikitext. In the former case MediaWiki:Cite references link many format might also want a similar edit. Anomie 12:32, 1 October 2019 (UTC)
So, ref-tags don’t work perfectly, but how to fix them is the question with some suggesting adapting cite templates to work around the bug In most cases. AManWithNoPlan (talk) 02:17, 7 October 2019 (UTC)


  1. "30 Rock's".
  2. "30 Rock's".
  3. "30 Rock's".
  4. "30 Rock's".
  5. 30 Rock's.
  6. 30 Rock's.

Special:Blocklist[edit source | edit]


This link goes to Special:Blocklist with "Hide temporary blocks" and "Hide account blocks" ticked, while "Hide indefinite blocks", "Hide single IP blocks", and "Hide range blocks" are not ticked. Based on "hide account blocks", I would assume that the results would be restricted to individual IPs and IP rangeblocks. So why are some accounts showing up? User:Jstxanothrxstory, User:Clumsybrunnette05, and User:Sam sung are three of the accounts showing up here. Nyttend (talk) 03:39, 1 October 2019 (UTC)

It looks like they were all blocked between 17:23 and 20:26, on 11 July 2006, and they were all re-blocked by MZMcBride on 15 November 2008 with the message "per previous block; correcting database entry" ([5]). So there's probably something weird going on in the database there. MZMcBride, can you enlighten us? rchard2scout (talk) 11:27, 1 October 2019 (UTC)
Hi! I don't remember these blocks. I imagine if you query the database directly and look at the output, there might be a hint as to why these accounts are showing up when "Hide account blocks" is enabled. --MZMcBride (talk) 01:01, 3 October 2019 (UTC)

sandbox issue[edit source | edit]

Hello, Really like the sandbox and use it a lot. I cleared out an article I had posted and started a new one. Started a fresh page and new infox box using a template cut and pasted directly from the help pages. When I previewed it, just a straight line of all the text I had entered displayed but no actual inbox. Tried with different templates, still no real infobox, just a line of of the text I had entered. Cleaned my caches, ran anti-malware. Then went through all the how to fix it steps listed in the infobox help article, it still would not display correctly. Then cleaned my computer caches, registries etc, even reloaded the browser. Then purged the sandbox as per help page. Put up a test template in, saved it, it still will not display, nada, not even the line of text entered in the test infobox, which it did before. The editing area is there but when I preview it there is nothing but a box to the right that says "my name/sandbox." I use the firefox browser. Help pages said ad blocker could be the cause. I use ublock origin and have it turned off on Wiki. Have never had a problem with the same setup before. Just reloaded both. Still have the issue with same configuration that I had no problem with until now.

Would appreciate some help with this. Have spent a lot of time on it and do not understand why it is not working. Thank you. Ogmany (talk) 13:10, 1 October 2019 (UTC)

Hi @Ogmany: - I assume you're referring to User:Ogmany/sandbox? It looks like you've added an Infobox artist, but haven't filled it out with any data. Could you make and save the edit you previewed that was displaying your text in a straight line? It's hard to help further without knowing more about the edit you were trying to make. Sam Walton (talk) 13:13, 1 October 2019 (UTC)
Hello Sam Walton,
Yes, User:Ogmany/sandbox. Since I purged the sandbox the infobox preview displaying the text (I entered in the infobox template) as only a straight line of text, each info box separated by |, don't show up anymore. It looked like "name entered | birth place entered | each section I entered | etc |" as I recall. I did add Infobox artist, and filled out a test name and website. The editing area is there, can see that, but when I preview it there is no preview box even, no text I had entered, nothing but a small box to the right with "ogmany/sandbox" in it. Would show you a photo but will have to do that later today. Ogmany (talk) 13:40, 1 October 2019 (UTC)
Check your Preferences → Editing, under preview as there's an option to display the preview at the bottommost area. Also please upload screenshot. – Ammarpad (talk) 13:48, 1 October 2019 (UTC)
@Ogmany: In [6] you added the name and website inside <!-- -->. Those indicate source comments for editors viewing the source. Anything inside them are ignored when the page is rendered. See more at Help:Wikitext#Invisible text (comments). If a page displays your template code like it looks in the source then it's usually due to unclosed tags. Maybe a starting {{ is missing the ending }}, or a [[ is missing a ]] in one of the parameters. PrimeHunter (talk) 13:56, 1 October 2019 (UTC)
Sam Walton and PrimeHunter Very helpful. Adding the name inside the code was the problem. Small and obvious detail that I totally missed. Yikes! Appreciate the help and thank you.Ogmany (talk) 15:09, 2 October 2019 (UTC)

creating a rankings page from a website[edit source | edit]

Hello! I've been putting it off for quite a while, but I feel I need to find a way to do this soon. Here's what I'd like to do:

Currently, there are a few different ranking lists for pool players, such as the WAPA and Eurotour rankings. There is a similar list for snooker players such as at Snooker world rankings 2019/2020.

What I'd like is to be able to have a way to update infoboxes (such as Template:Infobox pool player/rankings, similar to how Template:Infobox snooker player/rankings works. However, these are updated with a quick copy/paste for the snooker version, which doesn't seem possible with the above ranking lists. I'd also like to be able to update a potential article for each ranking list for the rankings after each event. The main issue (other than importing), seems to be the sheer amount of article names that are different from the name given. They tend to use lastname, firstname, rather than how our articles work.

I'd really like a reasonably quick and clean way to update the lists. Is there a way to go about doing this, or should I work around an existing solution? Please let me know if I need to provide more information. Best Wishes, Lee Vilenski (talkcontribs) 16:13, 1 October 2019 (UTC)

For reference, I've written Draft:Euro Tour rankings from excel2wiki to this version, and put together a script (with a lot of help) to fix the names. I'd really like to have some help in fixing the look of this table, and the infobox issues. Thank you in advance. Best Wishes, Lee Vilenski (talkcontribs) 18:58, 2 October 2019 (UTC)

Webcitation[edit source | edit]

Webcitation is one of the main recommended in the Help:Archiving a source for archiving links. But now a lot (all?) of pages with non-Latin text are shown with a Specials (Unicode block)#Replacement character. For example [7] . Is the site is finally dying аnd no longer reliable? Can someone contact them to fix it? --Sunpriat (talk) 00:43, 2 October 2019 (UTC)

As of July 14, 2019 this WebCite does not accept any new archive requests; historically archived pages can still be accessed but this service cannot be used to make any new archives. AManWithNoPlan (talk) 21:14, 5 October 2019 (UTC)

Possible interaction of spam blacklist and citation archival-url[edit source | edit]

Note: see prior discussion for additional context, about an url recently added to the WAP:BLACKLIST.

Note: a parallel discussion is taking place at Help talk:Citation Style 1 about aspects relating more to the citation template aspects of this. Mathglot (talk) 02:48, 5 October 2019 (UTC)

JzG, I'm going through them, fixing them up. The fixes to the ones in citations are going smoothly. However, I triggered the filter, attempting to change the External link in Juliet Escoria from its current value, to the following value:

  • [ Interview with Catherine Faw Morris at ''Adult Magazine'']

Maybe the filter could be adjusted to excuse examples where it's embedded in a web archive url? Or should I code this valid archive link differently, so it can be saved? Mathglot (talk) 03:16, 3 October 2019 (UTC)

Hm, this time (at Azar Swan) I couldn't save the page after marking url-status usurped and adding this archive url:
  • |archive-url=
I ended up putting the archive-url in hidden text in order to be able to save it (rev 919328779), and it went through okay. The problem now, is that there is a live, blacklisted url in Citation 8 (this link is safe to click) in this article. This seems to be two problems, possibly interacting with each other:
  1. not sure how this got past the filter
  2. shouldn't |url-status=usurped have blocked display of this url, irrespective whether it is a spammy url or not?
Adding user Trappist the monk (talk · contribs) for comments on question 2 above. Mathglot (talk) 03:39, 3 October 2019 (UTC)
Aha, they are interacting. The doc for url-status says: "url-status: this optional parameter is ignored if archive-url is not set." SInce I had to put it in hidden text to successfully save because of the edit filter, that disables the effect of url-status. Now what? How do I fix this? Mathglot (talk) 03:47, 3 October 2019 (UTC)
I can envisage several possible solutions:
  • Move the url value out of the archive-url field and directly into the url field, but that might require some explanation in hidden text or something to prevent well-meaning editors from attempting to move it back to the archive-url field.
  • Leave the value in the archive-url field, and use the required url field to point to something else; perhaps the entry in the WAP:BLACKLIST that covers it, or the discussion on the talk page about it. This seems more like a work-around, though.
  • Allow usurped for citation parameter url-status to block display of the spammy url in the url field, even with no archive-url
  • Add a new value for url-status that would block display, even with no archive-url.
Thoughts? Whatever the solution turns out to be, we should document it somewhere for users bumping up against this. Mathglot (talk) 04:14, 3 October 2019 (UTC)

Discussion moved here from prior location because it possibly affects more than one area.   Mathglot (talk) 04:24, 3 October 2019 (UTC)

I've fixed it in this case by url-encoding the archive url: Diff/919328779/919369896. That's probably the correct option in most cases, but I do think that if url-status is usurped or unfit, the original url should be hidden, whether archive-url is set or not. rchard2scout (talk) 10:38, 3 October 2019 (UTC)
|url-status= and its predecessor |dead-url= both require |archive-url=. It is a misuse of a template to set one and not the other. --Izno (talk) 15:09, 3 October 2019 (UTC)
Not quite true, I think. While Module:Citation/CS1 ignores |url-status= when |archive-url= is omitted or empty, that is not the same as a requirement; were it a requirement, then we'd have to invent a new error message for that case. As it is, a stand-alone |url-status= is just clutter which is a different kind of problem ...
I have been experimenting in Module:Citation/CS1/sandbox (not saved yet) looking at how to handle the various cases of a blacklisted url by percent-encoding the url in the archive-url as Editor Rchard2scout did with the example discussed here. I will discuss this at Help talk:Citation Style 1 when I have something to say.
Trappist the monk (talk) 15:47, 3 October 2019 (UTC)
@Rchard2scout:, In a technical WAP:TPO violation, I've reversed the order of the revisions in your diff above. Previously, it showed your revision, still the latest/current, on the left side of the diff, and the earlier revision on the right. I assume this was not your intention. If it was, feel free to revert, but in that case, please add an explanatory note to make this clear. Thanks, Mathglot (talk) 22:29, 3 October 2019 (UTC)
Trappist the monk: Archive URLs are not exempt for spam blacklists. In fact it's a requirement archive URLs have the full target URL so that the spam blacklist can pick them up. Circumventing this process is a no-no. We've had RfCs about this before. There is also a MediaWiki policy about not using url-shortening services which is essentially what this becomes when hiding the real URL from the filters, because url-shortening allows spammers and malicious actors to insert bad things into Wikiafripedia. I've seen this many times using WaybackMedic, people use archive URLs to add stuff they shouldn't be. -- GreenC 19:09, 3 October 2019 (UTC)
I don't doubt you but, point me to an RFC that discusses this?
If archive-urls are required to hold the complete original url, shouldn't cs1|2 be checking that and be emitting an error message? Is this requirement publicly documented anywhere? Certainly, this requirement, if it is a requirement should be documented wherever |archive-url= is documented, shouldn't it?
Trappist the monk (talk) 19:18, 3 October 2019 (UTC) -- IAbot and WaybackMedic have been expanding to long form for years (where possible). IABot in particular is relentless and will get to all archive URLs eventually. CS1|2 could add a warning. Wayaback has no short-form option and WebCite is no longer taking new archives and all their URLs are long-form already (presumably). The providers with known short-form are webcite,,, freezepage, National Archives UK. Data at WAP:WEBARCHIVES. -- GreenC 19:40, 3 October 2019 (UTC)
I don't read that RFC closure as a 'requirement' but the shortening point is taken, though I see this more as a possible masking than a shortening. I have rolled back the edit. Because there are bots that routinely lengthen short archive urls, and because editors at the RFC did not like the idea of an automated tool admonishing editors to use the long-form archive urls, I do not foresee adding that kind of error checking.
Trappist the monk (talk) 22:40, 3 October 2019 (UTC)

Can we back up and take a 40,000 foot view for a second, to get some perspective about the locus of the problem? I think this may help inform the discussion. I see what's going on here, as a conflict between two desirable features:

  • Support Verifiability, by exposing to readers the url of a source that supports an assertion in an article.
  • Prevent the user from being exposed to ill effects, by clicking on an url that may contain malware.

I think the statement of the issue we are facing here is, how do we do both of these at the same time, when an url used to support the article (and maybe still does, in an archived version) but has been usurped by malware? A couple of corollary questions to consider:

  1. Is it okay to reduce verifiaibility a little bit in this case, by suppressing display of the url (and archive url, if any) completely? I assume that the answer here is no, but perhaps not everyone agrees.
  2. Is it okay to display the spammy url, if it is not hyperlinked? I tend to think not, as it still seems to violate the spirit of the spam filter, even if it is unclickable.

Are there other functional aspects we haven't considered? Airing out what ought to happen, and getting agreement here first, will help keep the discussion about how to find a solution more on track. When discussing functionality, are there other stakeholders who ought to be looped in, here? Adding xaosflux. Mathglot (talk) 23:10, 3 October 2019 (UTC)

If all sites on the blacklist were indeed malware, there would be no issue; but most are merely spammy sites, while some have been blacklisted for other reasons. Link removal involves not just the loss of verifiability, but potentially the permanent loss of the information cited, contrary to our mission. What ought to happen is that each instance is checked, and either replaced or whitelisted. Doing so requires knowledge of the subject and the original link. Hawkeye7 (discuss) 23:29, 3 October 2019 (UTC)
@Hawkeye7:, That would seem to imply that we need to retain the information somewhere, of what kind of nasty the items on the blacklist actually are, so that they could possibly be handled differently. Is that what you meant? (At least, in an ideal world; whether it's practical/feasible/priority is a separate issue.) Mathglot (talk) 23:36, 3 October 2019 (UTC)
Yes, that is what I mean. It should be recorded somewhere. Hawkeye7 (discuss) 03:26, 4 October 2019 (UTC)

A solution is remove the offending URL but retain a {{citation}}. Blacklists don't prevent citing only linking. However if something is blacklisted it would be advisable to find an alternative source. -- GreenC 00:33, 4 October 2019 (UTC)

If a citation provides other means to verify the material, the simplest approach is not to include the url. The problem appears when online verification is the only available option. Again, the simpler approach would be for the editor to find a non-blacklisted mirror. If there no such mirrors, and the editor believes that the material can not be verified otherwise, then the pre-infected archive copy could be used, after some procedure as below:

1. Filtering should alert the editor that the url is blacklisted
2. The citation editor could submit the "clean" archived url for whitelisting, to whoever maintains such lists
3. The option |url-status=whitelisted should be inserted in the template to inform other editors that the particular archived url has been vetted, even if the current version is unsuitable.

It is a cumbersome approach, but I believe it is viable. (talk) 13:19, 4 October 2019 (UTC)

Hmm.. but we would still be providing a link to a blacklisted website (even if via an archive version). Sites are blacklisted for many reasons, vetting a URL can be a matter of opinion if it is safe/appropriate/clean etc.. requiring community consensus which gets messy to maintain. If the only concern is V, perhaps there can be an admin-maintained list that is not visible to non-admins and if a user wants to verify a URL they can contact an admin who can discretely provide the URL for V purposes only. There would be note in the citation where to request the URL. It might require the requesting user have a working email contact so not posted in the clear. -- GreenC 14:48, 4 October 2019 (UTC)
I don't think that such burden of verification should be placed on readers. A better option may be for the citing editor to re-archive the material @ Wikisource? An explanation of the material's origin, without any offensive links, could be included at Wikisource, not at the citation which would now be considered sanitized. (talk) 17:06, 4 October 2019 (UTC)
The burden is always on the reader to verify. This burden is actually less then going to the library and checking out a book. Wikisource is for previously published public domain documents, like books and speeches. Also copyright restrictions. -- GreenC 17:16, 4 October 2019 (UTC)

Just a heads-up that there is a parallel discussion taking place at Help talk:Citation Style 1 about aspects relating primarily to the citation template aspects of this, which may overlap in part some of the discussion above. Mathglot (talk) 02:52, 5 October 2019 (UTC)

User contributions changes[edit source | edit]

I see some recent changes to Special:Contributions which make it much less useful for me. The search form is now hidden under a "Search for contributions" toggle, which means an extra click for me to change search settings, but I can live with that. However, when I use a CIDR range (needs to be enabled in Preferences/Gadgets), which I do many times a day to find edits by related IPs after I encounter anon vandalism (e.g. I search for, the list of IP addresses with edits loads above the list of recent edits. The list of addresses is often very large, and takes many seconds to load, and during this time if I scroll down to the list of recent edits (limited only to the most 50 recent edits by default), the loading list above keeps jumping the screen so I can't do anything useful. Until a couple of days ago, the list of recent edits was above the list of IP addresses, so I could ignore the loading of the latter. Is there a way to toggle off the list of IP addresses? There is a "toggle all" option, but that's not what I want; it shows edits sorted by IP address, but I want edits for the range of IP addresses sorted by date, as already appears at the bottom of the window. Alternatively, can I force the list of IP addresses to be a fixed size, rather than expanding as new addresses are found.-gadfium 20:53, 3 October 2019 (UTC)

WAP:ITSTHURSDAY and the latest round of OOUI "improvements"..... but the gadget stuff comes from MediaWiki:Gadget-contribsrange.js which hasn't really been maintained in a while. This should be able to get pushed down if someone wants to dig in to it. — xaosflux Talk 21:32, 3 October 2019 (UTC)
Isn't the search by IP range gadget entirely obsolete now? * Pppery * it has begun... 21:45, 3 October 2019 (UTC)
@Pppery: the No per-IP sorting or date headings, or any bells and whistles. note on the top of that task description says it isn't really a full-replacement. — xaosflux Talk 22:23, 3 October 2019 (UTC)
But it does appear to offer what Gadfium was asking for, by simply not displaying any list of IP addresses. * Pppery * it has begun... 22:25, 3 October 2019 (UTC)
Thanks, turning off the gadget gives me exactly what I want. Thanks Pppery.-gadfium 22:33, 3 October 2019 (UTC)
By the way, you can force the search interface to be shown by inserting this into Special:MyPage/common.css:
/* Quick hack to force the Search tab on [[Special:Contribs]] open. Credit: Volker E. (WMF) & Stwalkerster - [[m:Special:Permalink/19434096#Reverting the new "collapsed search interface" on Special:Contribs|Tech]] */ 
.mw-special-Contributions { display: block !important; }
.mw-special-Contributions .oo-ui-fieldsetLayout-header { display: none !important; }
— regards, Revi 00:35, 4 October 2019 (UTC)
Thanks, that works for me, avoiding that extra click.
I'm most impressed with the speed and quality of the technical help I've been given here!-gadfium 03:05, 4 October 2019 (UTC)
So we're currently looking into additional changes from the feedback given here. One is implementing a “pin” to let the form stay expanded phab:T234569 (edited link; making above CSS hack obsolete), the second is a technical error, that affected the user autocomplete phab:T234510. Volker E. (WMF) (talk) 04:24, 4 October 2019 (UTC)
@Volker E. (WMF): That first ticket is unrelated. Can you double check your links? --Izno (talk) 11:30, 4 October 2019 (UTC)
I think he meant phab:T234569. – Ammarpad (talk) 11:40, 4 October 2019 (UTC)
Edited and fixed above, thanks @Izno: and @Ammarpad: Volker E. (WMF) (talk) 17:40, 4 October 2019 (UTC)
  • I have another bug related to these changes: at least on my system (Chrome 77.0.3865.90, Windows 10 v.who-knows) the shortened User: box is not long enough to display a full IPv6 address, which makes it very difficult to use. Can it be restored to its original length? Ivanvector (Talk/Edits) 14:07, 4 October 2019 (UTC)
    @Ivanvector: I've tried on monobook, vector, and timeless - for each a ipv6 address (38 characters) is only taking up about half the box for me - what skin are you using, and how may characters are you fitting in the input box? — xaosflux Talk 17:30, 4 October 2019 (UTC)
    I'm using vector, and was viewing the contributions page by clicking on an IP address so the box was pre-filled. When I click on this, I see "2601:681:8400:26A0:CD73:" and then the rest is cut off. Ivanvector (Talk/Edits) 18:10, 4 October 2019 (UTC)
    Oh also my Windows display settings were set to zoom 125%. If I set that back to 100%, I see ... the same thing, but smaller. Ivanvector (Talk/Edits) 18:13, 4 October 2019 (UTC)
    @Ivanvector: can you try in safemode to see if you still have this problem? I'm not having the problem as seen here: File:20191004-ooui-contrib-page.JPG. — xaosflux Talk 18:52, 4 October 2019 (UTC)
    @Xaosflux: yep, that worked, I see the same as you with safemode on. If I remove the &safemode=1 I get the short box again. Ivanvector (Talk/Edits) 18:59, 4 October 2019 (UTC)
    @Ivanvector: hmm - possibly one of your scripts or gadgets is in conflict, try turning off your manual implementation of MediaWiki:Gadget-markblocked.js in User:Ivanvector/vector.js? — xaosflux Talk 19:03, 4 October 2019 (UTC)
    It appears this is actually due to Enterprisey's delsort.js (imported under his previous username) ~ Amory (utc) 23:24, 4 October 2019 (UTC)
    Hmm. I don't have delsort installed but I still see that behavior. I'll look into it. Enterprisey (talk!) 05:42, 5 October 2019 (UTC)
    Enterprisey, it seems like the causative factor is mw.loader.load( 'mediawiki.ui.input'), specifically the input. ~ Amory (utc) 10:44, 5 October 2019 (UTC)
    @Enterprisey:, the rule .mw-ui-input-inline { display: inline-block; } added by User:Enterprisey/mw-ui-input.css (being used in cv-revdel and unblock-review scripts) is the culprit. SD0001 (talk) 11:12, 5 October 2019 (UTC)
    And yeah, mw.loader.load('mediawiki.ui.input') is also causing the same issue. Bizarre, since this one is WMF-sponsored. Ping Volker E. (WMF). SD0001 (talk) 11:25, 5 October 2019 (UTC)
    Ah. Fun. Well, Ivanvector, .mw-ui-input-inline { display: block; } in your common.css should work. Enterprisey (talk!) 01:44, 6 October 2019 (UTC)
    @SD0001: With the fix of phab:T234510 not only the autocomplete works again, the issues with user scripts should actually also disappear, as we've removed a leftover .mw-ui-input-inline class from this specific input. Rolling out this week, should be live on enwiki by Thursday. Volker E. (WMF) (talk) 01:40, 8 October 2019 (UTC)
    I filed a task for this one at phab:T234733. --Izno (talk) 22:10, 5 October 2019 (UTC)
  • I dislike the new change but anyway the pin thing would help a lot - No one wants to have to click to expand the box every time they want to search a users contribs, Would prefer if it was expanded by default tbh. –Davey2010Talk 17:23, 4 October 2019 (UTC)
    Depends how you edit. Nearly every time I load Special:Contributions, it's from a user-specific link, so I rarely use the box and thus love the space gains. ~ Amory (utc) 23:27, 4 October 2019 (UTC)

Wikidata-fueled graphs not visible?[edit source | edit]

When checking whether this recent change was an improvement or vandalism (it looks to be an improvement), I came across List of the busiest airports in France, which starts of with two graphs, which are Wikidata-fueled. Ignoring whether this is wanted or not for now, my problem is that they simply don't seem to work. Firefox 69.0.2 on Windows, all I get is a small placeholder image. Other articles like List of the busiest airports in Germany also use this kind of graph, but through a template: in this case I don't even get the placeholder image but solely an empty section.

Is this a problem on my side, or a general problem with these graphs? Fram (talk) 12:44, 4 October 2019 (UTC)

According to Phab:T226250 this has been broken for some time, so we probably want to replace those graphs for now. Sam Walton (talk) 12:47, 4 October 2019 (UTC)
Thanks. Perhaps best to remove these for now then, has been broken for more than three months now. I'll remove them from a few pages where I can easily find them, but these may well be used by other articles and templates as well of course. Fram (talk) 12:59, 4 October 2019 (UTC)

Notices vs Alerts[edit source | edit]

Mondays amirite

Why do we have distinct Alerts and Notices menus on the top line? They're both just, "things that need your attention", with no logical distinction that I can see of which things go in which menu. I'd rather save the screen real-estate and have them in a single menu. Perhaps there's a way to configure that which I haven't found yet?

Other minor point: is it just me, or does the Notices icon look more like a USB-B connector than a mailbox? -- RoySmith (talk) 15:33, 4 October 2019 (UTC)

What goes where is explained at Help:Notifications#Triggering_events. Basically, talk page messages, emails, mentions, and rights changes are alerts while thanks, reviews, and cross-wiki are notices. ~ Amory (utc) 16:34, 4 October 2019 (UTC)
I personally see a distinction. Alerts are for communication, or things that directly affect your work (such as when your edit was reverted, user rights changes, etc.). Notices are editors thanking you, adding links to pages you created -- things that are interesting but don't necessarily need any follow-up. I'm not aware of a way to configure what types of notifications go where, but you can disable some of them at Special:Preferences#mw-prefsection-echo. MusikAnimal talk 17:11, 4 October 2019 (UTC)
I've had a user script on the back burner for ages that combines the two. It's a bit tricky. (To everyone) feel free to poke me in a month or so if you really want this, since I'm a bit busy at the moment. Enterprisey (talk!) 06:23, 7 October 2019 (UTC)
does the Notices icon look more like a USB-B connector than a mailbox? lol, was that ever intended to look like a mailbox? SD0001 (talk) 18:19, 7 October 2019 (UTC)
It's an inbox, like people (used to?) have on their desks. ~ Amory (utc) 21:39, 7 October 2019 (UTC)

Tacky color scheme for old revisions[edit source | edit]

Take a look at the top of any old revision - think this was a WAP:THURSDAY interface improvement - anyone else think the pink in yellow is tacky looking though? — xaosflux Talk 23:46, 4 October 2019 (UTC)

phab:T232415. The yellow is due to (now) using .warningbox while the red is because we use {{fmbox}} at MediaWiki:Revision-info. ~ Amory (utc) 00:09, 5 October 2019 (UTC)
We should remove the fmbox now. It would look better. – Ammarpad (talk) 00:15, 5 October 2019 (UTC)
Done by JJMC89. Still doesn't look great. I feel that the background colour ought to be red to draw attention to the fact that this isn't the current version of the page. SD0001 (talk) 11:29, 5 October 2019 (UTC)
MediaWiki:Revision-info-current also need attention.--Lam-ang (talk) 15:09, 5 October 2019 (UTC)
Did you mean Mediawiki:editingold? — xaosflux Talk 15:32, 5 October 2019 (UTC)
No. I took care of the one Lam-ang mentioned. Editingold doesn't currently cause me problems, but I'm using WTE2017. That said, it may in the future be one ofthe targets. --Izno (talk) 15:40, 5 October 2019 (UTC)
@Izno: this also gives pink-in-orange, however in visual editor the pink seems to be the only coloring (else it is just plain text on plain background) so it may be worth keeping - or perhaps changing to the same coloring as the orange.. — xaosflux Talk 15:44, 5 October 2019 (UTC)
Probably just means that VE hasn't been updated. Let's go ahead and remove editingold also. --Izno (talk) 15:49, 5 October 2019 (UTC)
I don't use VE but the pink isn't dark enough to get a person's attention.— Vchimpanzee • talk • contributions • 15:46, 7 October 2019 (UTC)

Changes for 2020 (upcoming) Community Wishlist Survey[edit source | edit]

The Wikimedia Foundation recently announced two major changes to this year's Community Wishlist Survey. I haven't seen it spread widely on-wiki, so I'm posting it here. The Community Tech team will only work on the 5 most popular requests, not the top 10. They will also not consider any proposals from Wikiafripedia projects. The announcement was on wikitech-l and other mailing lists. You can find more information at meta:Community Wishlist Survey 2020 and discuss the changes at meta:Talk:Community Wishlist Survey 2020. --AntiCompositeNumber (talk) 02:30, 5 October 2019 (UTC)

Cursor position wrong at Special:Search on Google Chrome[edit source | edit]

Based on this post at wp:AN, the cursor position on Special:Search is weird. To reproduce, type some text in the box, then try to click in the box, and see the cursor is several characters to the right of where you clicked. I am using Chrome, Windows 10. User:Nixinova reported IE and Edge working as expected. Chris857 (talk) 04:48, 5 October 2019 (UTC)

There's phab:T234170, given in the AN thread. – Ammarpad (talk) 14:30, 5 October 2019 (UTC)

Page categorisation[edit source | edit]

Is there a problem with page categorisations as I have had no entries on my watchlist for the last couple of days yet there are new/removed entries in the category Category:CS1 errors: dates that should have appeared? Keith D (talk) 10:17, 5 October 2019 (UTC)

It works for me. Is "Hide categorization of pages" disabled at Special:Preferences#mw-prefsection-watchlist? Is Category:CS1 errors: dates on your watchlist? You have to watch the category page and not just the articles. PrimeHunter (talk) 12:17, 5 October 2019 (UTC)
No it is not disabled and the category is on the watchlist. It is also not hidden on the selection screen for the watchlist. It was OK until about Thursday when it stopped giving the category changes. Keith D (talk) 18:19, 5 October 2019 (UTC)
I'm not sure what you mean by "not disabled" but the option "Hide categorization of pages" should be disabled, i.e. have no check mark. It's enabled by default. PrimeHunter (talk) 19:40, 5 October 2019 (UTC)
There is no check mark in the box. Keith D (talk) 20:25, 5 October 2019 (UTC)
Do you see categorizations at [8]? I see many when watching Category:CS1 errors: dates. Try to remove and readd the category to the watchlist. Do other categories like Category:Candidates for speedy deletion‎ fail to produce results? PrimeHunter (talk) 09:05, 6 October 2019 (UTC)
Yes I can see the categorisations using the link that you specified. It is all categorisations that I am missing from my normal watchlist entries such as Category:Start-Class Yorkshire articles‎. Keith D (talk) 18:31, 6 October 2019 (UTC)
Many thanks for the help I have just spotted what the problem is with the link you gave. I appear to have only got the (Main) namespace selected, for some reason, rather than All which it usually is. Back to normal now. Keith D (talk) 18:58, 6 October 2019 (UTC)

Global watchlist - Update 1[edit source | edit]

Deletion of file[edit source | edit]

I have uploaded a file, that is not fit for the intended use, and I want to delete it, but I don't know how. (Man, that was a long sentence – and please understand, that English isn't my first language.)

Anyways, I'd like to ask, if someone could help me deleting the file.

Cheers, Mrloop (talk) 17:40, 5 October 2019 (UTC)

Mrloop, I have requested speedy deletion for you per criteria G7. --Trialpears (talk) 17:45, 5 October 2019 (UTC)
Thanks :-) Mrloop (talk) 17:54, 5 October 2019 (UTC)
☒N Deletedxaosflux Talk 18:01, 5 October 2019 (UTC)
Thanks 👍 Mrloop (talk) 21:01, 5 October 2019 (UTC)

span data-segmentid="59" class="cx-segment"???[edit source | edit]

In Draft:Jaime Macías Alarcón, there's some very strange markup with every paragraph wrapped in <span data-segmentid="..." class="cx-segment">. My two guesses are some weird Visual Editor bug, or (more likely) somebody copy-pasted this from somewhere and the HTML markup came along for the ride. Earwig doesn't show any copyvio matches, and googling for bits of text from the draft draws a blank as well. Anybody seen this before? -- RoySmith (talk) 22:09, 5 October 2019 (UTC)

@RoySmith: got a feeling it is a remnant from a translation tool. — xaosflux Talk 23:01, 5 October 2019 (UTC)
And looks like that user has been doing various things related to translation. — xaosflux Talk 23:03, 5 October 2019 (UTC)
And have been trying over and over in different ways. — xaosflux Talk 23:05, 5 October 2019 (UTC)
(edit conflict) It was caused by mw:CX when attempting to restore translation. The problem was fixed sometimes ago (after that draft's creation date). – Ammarpad (talk) 23:13, 5 October 2019 (UTC)

OK, thanks everybody. I think I'm going to copy the source to my unix box and clean it up with some emacs magic. -- RoySmith (talk) 23:25, 5 October 2019 (UTC)

Possibly related: T218420, T213258, T111000, T90202. – Jonesey95 (talk) 00:26, 6 October 2019 (UTC)

Transclusion count[edit source | edit]

I'm sure it's been asked before, but I can't find it: is there an easier way to count the transclusions of a template than using the "what links here" page and counting how many pages? Circéus (talk) 02:05, 6 October 2019 (UTC)

There is a "Transclusion count" link in the "External tools" section of Special:WhatLinksHere when given a template as an argument. * Pppery * it has begun... 02:19, 6 October 2019 (UTC)
You can also add this script mw.loader.load('//'); which lets you count without leaving "what links here" page and is more flexible with namespaces, etc. SD0001 (talk) 05:14, 6 October 2019 (UTC)
You can also use Help:Searching#hastemplate: and see the reported number of search results. It can be combined with other search strings and search options, e.g. the namespace (only mainspace by default). PrimeHunter (talk) 08:47, 6 October 2019 (UTC)
Such searches are particularly useful because you can search for uses of the template with a particular parameter (e.g. here.   Jts1882 | talk  09:28, 6 October 2019 (UTC)
(You don't need to place the spaces internal to the metacharacters you have; this is also correct. --Izno (talk) 13:57, 6 October 2019 (UTC))
For templates with over 2,000 transclusions, there are weekly lists generated at Special:PrefixIndex/Module:Transclusion_count/data/. --Ahecht (TALK
) 18:04, 6 October 2019 (UTC)
Related thread at Template talk:High-use#Switch to automated transclusion count. --Redrose64 🌹 (talk) 22:49, 6 October 2019 (UTC)

Codebox[edit source | edit]

Please see the idea discussed at Template talk:CodeBox#External links. I *think* it's about code, and then giving an external link to show what it does, but I'm not entirely sure. This might be good, or there might be an even better way to accomplish the desired goal. WhatamIdoing (talk) 00:01, 7 October 2019 (UTC)

I think the issue here is more about policy. Runnable code snippets are popular on many Q&A, how-to and programming sites; but Wikiafripedia is not a how-to website. Also when you combine that with the external link issues, for instance questions about the site itself (, and the fact that this will have to be embedded in the middle of articles; it will become clear this is something unlikely to be allowed on Wikiafripedia. But creating the template is one thing; starting to use on articles (with or without consensus) is another thing. Currently its only use on mainspace is on Lua (programming language) and it was added by the author. – Ammarpad (talk) 06:06, 7 October 2019 (UTC)
I've reverted my change, due to general consensus appearing to be against it, and potentially it being against some rule I haven't heard of/noticed yet (Would appreciate pointers to what I violated, I realise now that I violated WAP:NOTHOWTO and WAP:ELNO. MoonyTheDwarf (Braden N.) (talk) 12:47, 7 October 2019 (UTC)

VE cut & paste[edit source | edit]

doesn't see to be working. Is this affecting anyone else? ——SerialNumber54129 11:57, 7 October 2019 (UTC)

It's a part of many issues: phab:T234489. – Ammarpad (talk) 12:15, 7 October 2019 (UTC)
Ah, thanks very much Ammarpad, well that's too rich for me. Any idea, though, how long that kind of thing takes to sort out? (It's just that I've read the phab ticket but I'd have more luck with Cantonese!) Thanks again, ——SerialNumber54129 12:22, 7 October 2019 (UTC)
@Serial Number 54129: The short version is it looks like a fix was uploaded yesterday by @DChan (WMF): that's currently awaiting review. Hopefully they can shine some light on how long these things usually take to go live. Sam Walton (talk) 12:30, 7 October 2019 (UTC)
The task was triaged with the highest priority tag, so one can assume it will not take long to get fixed, all other things being equal. – Ammarpad (talk) 12:38, 7 October 2019 (UTC)
Thanks very much Sam Walton and Ammarpad, for the update, and a big Thank You to all the technical folk on this board who enable content creation by doing what they do and also take the time to explain things to plebs like me! Cheers! :) ——SerialNumber54129 12:44, 7 October 2019 (UTC)

Is this the same issue that messes up the ref numbering in VE? When I test-edit articles in VE, almost all of them have the refs in the ref section with a higher number than in the article, making it hard to see which ref belongs with which number of course... Here the refs in the ref section are numbered 17 to 27, here 4 to 10, here 4 to 15, here 5 to 89; here the only reference is numbered "6"! Fram (talk) 12:45, 7 October 2019 (UTC)

I don't believe so, that looks to be T95176. Sam Walton (talk) 12:50, 7 October 2019 (UTC)
Thanks. Ouch, that's a task from 2015... Fram (talk) 14:04, 7 October 2019 (UTC)

{coord} location doesn't match Google Map location[edit source | edit]

This may be a known problem or a non-problem but, having noticed it, I thought I would mention it here.

Compare this Google Maps location with the 5°08′33″N 125°58′35″E / 5.1424303°N 125.9764215°E / 5.1424303; 125.9764215 location from {{coord}} and GeoHack->Google Maps. Maybe it's a rounding error or a cockpit problem on my part. Wtmitchell (talk) (earlier Boracay Bill) 14:23, 7 October 2019 (UTC)

@Wtmitchell: in your first example you seem to be using a "named location" on ("Miangas") not only the geo-coordinates like this - does that give you the result you are looking for? — xaosflux Talk 14:58, 7 October 2019 (UTC)
Specifying the named location appears to drop a pin on the named location while centering the map on the coordinates (at least approximately). For a more extreme example, try 125.1424303,125.9764215, which uses the named location of "Miangas" but coordinates much farther away. The coordinates of Miangas appear to be closer to 5°33′19″N 126°35′07″E / 5.5554°N 126.5854°E / 5.5554; 126.5854. – Jonesey95 (talk) 16:05, 7 October 2019 (UTC)
@Xaosflux: it's not odd, it's expected: consider that a URL goes into the value of a href="..." attribute of an <a> tag, any unencoded quotes will terminate that value. Try percent-encoding it, like this, where %C2%B0→°, %27→' and %22→". --Redrose64 🌹 (talk) 20:43, 7 October 2019 (UTC)
@Redrose64: yea not really 'odd' but it is phab:T17661. — xaosflux Talk 20:55, 7 October 2019 (UTC)

Tech News: 2019-41[edit source | edit]

15:34, 7 October 2019 (UTC)

Search function has a URL with "cirrus"[edit source | edit]

Is this explained anywhere? — Vchimpanzee • talk • contributions • 15:44, 7 October 2019 (UTC)

@Vchimpanzee: see more at mw:Help:CirrusSearch. — xaosflux Talk 15:58, 7 October 2019 (UTC)
Thanks.— Vchimpanzee • talk • contributions • 16:02, 7 October 2019 (UTC)

Page views data prior to February 2008[edit source | edit]

I am working on a research project related to the traffic of Wikiafripedia platform. Could you please help me to find the page views data of the early days of Wikiafripedia? Ideally, I would like to find 2001-February 2008. I understand that the metrics were different from the current metrics. — Preceding unsigned comment added by Vika-Wiki (talkcontribs) 03:59, 8 October 2019 (UTC)