This is an archive of past discussions with User:RexxS. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hi! I just wanted to use the opportunity and say you another big thank you for helping me with Lua back at Wikimania 2017! These last weeks I have been able to provide some more features to the templates I have rewritten / created during the last years and I’m quite satisfied with what has become of the module we have once started (see doc). A hard-working group of users is helping me to spread the templates and to find potential bugs and recently a user from Kurdish WP even translated the module (not sure if it will be a success there, but anyway). Wouldn’t have been possible without your valuable help back then! So let me wish you an early happy and successful New Year 2019! Cheers, XanonymusX (talk) 15:10, 31 December 2018 (UTC)
Please check out "Happy" once more, for a smile, and sharing (a Nobel Peace Prize), and resolutions. I wanted that for 1 January, but then wasn't sad about having our music pictured instead. Not too late for resolutions, New Year or not. DYK that he probably kept me on Wikipedia, back in 2012? By the line (which brought him to my attention, and earned the first precious in br'erly style) that I added to my editnotice, in fond memory? --Gerda Arendt (talk) 14:43, 12 January 2019 (UTC)
WikiProject Issue
Hi RexxS! Hope you are well. We recently have a new, young, and zealous editor working in the rodeo area. He created a Rodeo Wikiproject with a Bull Riding task force. It's Wikipedia:WikiProject Rodeo. I noticed late last night that we now have some of the article talk pages he tagged showing up in the top level Rodeo category. Unfortunately, he took offense at some things I said (mostly me) and not so much MontanaBW. He has asked us both not to message him anymore, and it now he has said he won't work in this area anymore. He has not fixed the issue with the talk pages. MontanaBW is swamped right now with a personal project, so she asked me if I could see if you would look at the problem. Apparently, you have expertise in this area. It's at Category:Rodeo. I have been slowly looking through the sub-categories, but so far I have not seen this in any of them. Thanks for so much for listening! Happy weekend! dawnleelynn(talk)20:24, 19 January 2019 (UTC)
I've been making corrections to all of the wikiprojects he added to articles..and now it appears all of the talk pages have disappeared from the two categories I previously mentioned. dawnleelynn(talk)18:16, 20 January 2019 (UTC)
@Dawnleelynn: Sorry I've not got to most of the issues you've had, but these have been three busy days for me, and I've only just got back from the Oxford meetup. However those categories look a lot cleaner than when I glanced at them yesterday, so perhaps I don't need to do anything. It's likely that Redrose64 and possibly MontanaBW have the situation in hand – please let me know if there's something specific you need me to do. Cheers --RexxS (talk) 21:23, 20 January 2019 (UTC)
Hi RexxS No worries on the time issue, like I said before. We were most concerned about the talk pages in categories, which seems to have been resolved by my removal of one of two projects in talk pages he added. There were several talk pages where the full rodeo and bull riding projects were both added to some pages. I guess those were caused before montanabw persuaded him to make bull riding a task force of rodeo. Anyway, now that is done, there are a few other things: in the "Rodeo articles by quality and importance" table, all of the table cells are zero. So, it's not adding up the figures from the talk page templates and such. This is true for the Rodeo project and the Bull Riding task force tables. Also, the recognized content page seems to be working for the Rodeo project but not the Bull riding task force.
And I am not sure, how do we create the Requested Article pages on the projects? I mean when I click the red link, I get to where I can create a blank page, but I am not quite sure what goes in there. Or, should I perhaps take a look at what's in the horse equine project or something?
I hope that's not too much... thanks for getting back to me. Sorry to hear that you've been so swamped lately! This is not a rush by any means. dawnleelynn(talk)22:36, 20 January 2019 (UTC)
Recently Jimmy Wales has made the point that computer home assistants take much of their data from Wikipedia, one way or another. So as well as getting Spotify to play Frosty the Snowman for you, they may be able to answer the question "is the Pope Catholic?" Possibly by asking for disambiguation (Coptic?).
Headlines about data breaches are now familiar, but the unannounced circulation of information raises other issues. One of those is Gresham's law stated as "bad data drives out good". Wikipedia and now Wikidata have been criticised on related grounds: what if their content, unattributed, is taken to have a higher standing than Wikimedians themselves would grant it? See Wikiquote on a misattribution to Bismarck for the usual quip about "law and sausages", and why one shouldn't watch them in the making.
Wikipedia has now turned 18, so should act like as adult, as well as being treated like one. The Web itself turns 30 some time between March and November this year, per Tim Berners-Lee. If the Knowledge Graph by Google exemplifies Heraclitean Web technology gaining authority, contra GIGO, Wikimedians still have a role in its critique. But not just with the teenage skill of detecting phoniness.
There is more to beating Gresham than exposing the factoid and urban myth, where WP:V does do a great job. Placeholders must be detected, and working with Wikidata is a good way to understand how having one statement as data can blind us to replacing it by a more accurate one. An example that is important to open access is that, firstly, the term itself needs considerable unpacking, because just being able to read material online is a poor relation of "open"; and secondly, trying to get Creative Commons license information into Wikidata shows up issues with classes of license (such as CC-BY) standing for the actual license in major repositories. Detailed investigation shows that "everything flows" exacerbates the issue. But Wikidata can solve it.
@Janezdrilc: Unfortunately, I don't speak Slovene, but I've tried to figure out where the references came from. As far as I can tell, the sl:s:Modul:Wikidata adds references by default when the formatStatements function is invoked. You can turn them off by supplying |references=false in that invocation.
(Step 2) Once that is done, you would next edit sl:s:Predloga:Infopolje Oseba to add |references={{{references|}}} to each use of {{wikidata ...
(Step 3) Then you edit sl:s:Predloga:Avtor to add |references={{{references|}}} to the line below {{Infopolje Oseba.
(Step 4) Finally in a page like sl:s:Harriet Beecher Stowe, you can add |references=false in order to turn off references for that article.
Optionally, if you know that you want to turn off references for every instance of sl:s:Predloga:Infopolje Oseba, you just use |references=false in Step 2, and forget about steps 3 & 4.
Sorry that is complex, but that seems to be the chain of calls on Slovene Wikisource. Let me know if there's anything more I can do. --RexxS (talk) 21:23, 13 February 2019 (UTC)
@Janezdrilc: unfortunately, your version of sl:s:Modul:Wikidata doesn't actually suppress the references unless they are called via formatStatementDefault, which those templates don't use. There's also a problem that the module treats |parameter= (i.e. empty) as if it were false, but allows an omitted parameter to have a default value. In infoboxes |parameter= really needs to work the same as when parameter is omitted.
Anyway, I've made a modified version in sl:s:Modul:Wikidata/sandbox and briefly tested it by pasting {{#invoke:Wikidata/sandbox|formatStatements|property=p19|claim-module=Wikidata/Places|claim-function=formatPlaceWithQualifiers|value=|conjunction=, |plain=|references=false}} into sl:s:Harriet Beecher Stowe previewing it. Changing it to |references=true or |references= or omitting |references shows the references. There's still one linked superscript, but you can suppress that by setting |plain=true. See if that works for you. --RexxS (talk) 19:05, 14 February 2019 (UTC)
Ok, I copied your sandbox version into the Module:Wikidata. Now the infobox doesn't show reference superscripts as wanted, but references appeared back again in the article. --Janezdrilc (talk) 14:07, 15 February 2019 (UTC)
A huge thank you for your effort. It's so much better now I "dis-introduced" infobox references on sl.wikiquote too. Since only Wikipedia deals with biographic facts I supposed other sister projects really don't need this unnecessary "notes". Thanks again. --Janezdrilc (talk) 22:43, 16 February 2019 (UTC)
Hi, any thoughts regarding use of {{Ahnentafel}} from an accessibility point of view? Especially for mobile reading and in a default collapsed state? I've seen someone using it a fair bit recently on Indian articles and have several issues with its use, of which a gut feeling about accessibility is one. - Sitush (talk) 20:38, 24 February 2019 (UTC)
Thanks for that. Even the scrolling was an issue on my mobile but that may be because of impatience. I've had 3 friends die on me in 4 days and am probably reeling a bit. - Sitush (talk) 21:33, 24 February 2019 (UTC)
Moar sigs
Hello big dino, assistance requested as usual! Bishonen wrote something to a user called @Levivich: and I noticed his fine broken-off sig, and copied for myself. Can be seen at the bottom of User:Bishonen/Sigs. With less rotation than original, because bish is longer than ich and perhaps might push down into the next line. Now the problem is I wanted to also insert iconic darwincolors, red and lime as in my current sig, but it got very complicated. Dino help? PS, bad people deleting dino's modules? Want me to wander over and bite them? darwinbishBITE☠17:25, 20 February 2019 (UTC).
Done can be changed easy. Small makeover remove naughty font tags before RedRose64 see them. People OK, just hard merge-module when admin delete it before merge happen. --T-RexxS (rawr) 18:18, 20 February 2019 (UTC)
Thank you helpful dino! Easy to change colors now — good thing, because red + lime turned out surprisingly ugly! I'm borrowing great zilla's color scheme instead, for now. Tried and tested, that. darwinbishBITE☠19:23, 20 February 2019 (UTC).
Thanks Nick Number for the quick notification. I wish we had a transparent way of knowing what modules are dependant on a given module, so I could check those as a matter of course when I implement changes. Cheers --RexxS (talk) 23:05, 24 February 2019 (UTC)
You may want to consider using the Article Wizard to help you create articles.
A tag has been placed on Module:Linguistic, requesting that it be speedily deleted from Wikipedia. This has been done under section G4 of the criteria for speedy deletion, because the page appears to be a repost of material that was previously deleted following a deletion discussion, such as at Articles for deletion. When a page has substantially identical content to that of a page deleted after a discussion, and any changes in the content do not address the reasons for which the material was previously deleted, it may be deleted at any time.
If you think this page should not be deleted for this reason, you may contest the nomination by visiting the page and clicking the button labelled "Contest this speedy deletion". This will give you the opportunity to explain why you believe the page should not be deleted. However, be aware that once a page is tagged for speedy deletion, it may be deleted without delay. Please do not remove the speedy deletion tag from the page yourself, but do not hesitate to add information in line with Wikipedia's policies and guidelines. If the page is deleted, and you wish to retrieve the deleted material for future reference or improvement, then please contact the deleting administrator, or if you have already done so, you can place a request here. Pppery, the demodulator22:01, 25 February 2019 (UTC)
"Prior" consensus to infobox on FLT
From a bureaucratic POV, void of any context, you are correct in claiming the right of adding that box, but I want to inform you about a previous held discussion at the TP of Project Math, inclined to "not using this box". Even setting aside this fact, I am convinced of my right to revert the addition, and to require a discussion for reaching a consensus on the article's TP. Upsetting the BRD-process for my not explicit referral to a discussion elsewhere seems wrong under any circumstances (even your deterrent "welcome"). Purgy (talk) 08:55, 26 February 2019 (UTC)
(watching:) there are good and bad aspects in WP:BRD. I works when you can revert something bizarre ("bold") and demand discussion. Adding an infobox, however, is not bizarre but a quite common edit, so doesn't even fall under that guideline. You can spread this news, because it's ignored often. To demand that such a normal edit be discussed before making it (which you can find in many composers' articles as a hidden notice) borders the absurd and is not compatible with collaborative editing, imho. --Gerda Arendt (talk) 09:36, 26 February 2019 (UTC)
@Purgy Purgatorio: I'm sorry, but I don't recognise the right of any WikiProject to make content decisions that are binding on editors, and neither does the community as evidenced by WP:CONLOCAL:
"Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.
The relevant community-wide guideline is MOS:INFOBOXUSE:
"The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article."
That has been affirmed as a finding by ArbCom, and you breach that at your peril. Therefore I insist that where no prior consensus exists in a particular article on whether it should have an infobox or not, then it is not reasonable to revert the addition of an infobox without addressing the actual issue of having an infobox. Certainly, it is not within policy to try to insist that the addition of an infobox can be reverted merely because nobody has discussed it previously.
Your right to revert depends not upon your whim, but on your mustering of reasonable arguments to support the reversion. Your revert with edit summary "I am firmly convicted that there should be established consensus on implementing an infobox here, BEFORE doing so" is a perfect example of an revert without foundation. You have no right to demand "established consensus" before an edit, where no previous consensus exists.
I'm going to suggest that you acquaint yourself with WP:ARBINFOBOX2 #Remedies, in particular that discretionary sanctions are in force on discussions concerning infoboxes, and I'll drop an alert on your talk page as a formal reminder. --RexxS (talk) 22:28, 26 February 2019 (UTC)
Systematic reviews are basic building blocks of evidence-based medicine, surveys of existing literature devoted typically to a definite question that aim to bring out scientific conclusions. They are principled in a way Wikipedians can appreciate, taking a critical view of their sources.
PRISMA flow diagram for a systematic review
Ben Goldacre in 2014 wrote (link below) "[...] : the "information architecture" of evidence based medicine (if you can tolerate such a phrase) is a chaotic, ad hoc, poorly connected ecosystem of legacy projects. In some respects the whole show is still run on paper, like it's the 19th century." Is there a Wikidatan in the house? Wouldn't some machine-readable content that is structured data help?
Most likely it would, but the arcana of systematic reviews and how they add value would still need formal handling. The PRISMA standard dates from 2009, with an update started in 2018. The concerns there include the corpus of papers used: how selected and filtered? Now that Wikidata has a 20.9 million item bibliography, one can at least pose questions. Each systematic review is a tagging opportunity for a bibliography. Could that tagging be reproduced by a query, in principle? Can it even be second-guessed by a query (i.e. simulated by a protocol which translates into SPARQL)? Homing in on the arcana, do the inclusion and filtering criteria translate into metadata? At some level they must, but are these metadata explicitly expressed in the articles themselves? The answer to that is surely "no" at this point, but can TDM find them? Again "no", right now. Automatic identification doesn't just happen.
Actually these questions lack originality. It should be noted though that WP:MEDRS, the reliable sources guideline used here for health information, hinges on the assumption that the usefully systematic reviews of biomedical literature can be recognised. Its nutshell summary, normally the part of a guideline with the highest density of common sense, allows literature reviews in general validity, but WP:MEDASSESS qualifies that indication heavily. Process wonkery about systematic reviews definitely has merit.
Re [1], that edit arose from this AT discussion, in which an editor was confused by the term "plain text". They made a fair case that it's somewhat ambiguous. The meaning of the term there doesn't seem to bear much connection to Plain text. You and I know what the guideline means—we have a thorough understanding of the rationale for it—but it needs to be written for those who don't have that understanding. While I take your point, I'm unconvinced that "plain text" is the lesser evil. ―Mandruss☎15:00, 1 March 2019 (UTC)
Hi Mandruss. My perspective on which is the lesser evil is skewed by more than one experience of editors who won't accept that text in infoboxes is "already reduced". If the guidance were changed to that, we'd have twice as many uphill struggles to uphold the guidance. I also don't like "plain text" and have opened a thread at Wikipedia talk:Manual of Style/Accessibility #Font size wording to see if anybody can come up with something better. Cheers --RexxS (talk) 15:09, 1 March 2019 (UTC)
Usage of two functions from Module:String on the main page
Hi Rexxs. Regarding this discussion. It appears that {{str endswith}} is not being called directly from the main page. (At least I couldn't find it there). If it's being called indirectly through something else, doesn't that make your plan more difficult? You would then need to duplicate all the entities in the call chain leading to Module:String, in order to keep alive a special version of Module:String that wouldn't be included in the cascade protection of the main page. Thanks, EdJohnston (talk) 18:47, 4 March 2019 (UTC)
@EdJohnston: we tend to use string templates as wrappers these days and put all of the functionality into the string module. The wrapper makes the functionality more user-friendly for the average editor, but isn't actually needed here because we could directly call the function in the module from Template:Main page image (ironically, a template whose protection-level is 'template editor', which cannot be edited by template editors). As a concrete example, calling {{#invoke:String-mainpage|match|s={{if empty|{{{width|}}}|120}}|^%d*|ignore_errors=true}} – where Module:String-mainpage is the theoretical main page version of String – instead of {{str number/trim|{{if empty|{{{width|}}}|120}}}} within Template:Main page image would be more efficient, would reduce template expansion depth and would make it clearer what is being called. None of that is vital, of course, but might be worthwhile if we looking at tidying up template usage. --RexxS (talk) 19:16, 4 March 2019 (UTC)
You jarring swag-bellied miscreant
Rex, you remember the Shakespeare insult generator? User:Darwinbish/insultspout. A thing of beauty, originally, but not so much since something was changed in the way the site works which makes it necessary to click an extra time to clear the fucken cache. I think I complained at the time, and you said nothing could be done. But, really? Still nothing? Might there be a way to reconfigure it so that the cache-clearing is done as an action from inside the generator? If I'm making myself clear at all. It really is a pity. 😢 Bishonen | talk10:46, 5 March 2019 (UTC).
I've not been able to figure out a way, Chère. You are clear in what you're saying, but it can't be a solution. Any purge call originating from inside wikitext (the bit we can edit, anyway) is trapped by the MediaWiki software at a level higher than we have access to. If you have the little clock thingy enabled in your personal bar, that also does a purge, but from outside the wikitext, so it doesn't get trapped. We just can't get to that level from clicking something inside the main bit of the wikipage as far as I can see. Maybe one of the talk page watchers will come up with a stroke of ingenuity that can do the job? --RexxS (talk) 12:57, 5 March 2019 (UTC)
You cannot skip the extra step without using Javascript, which is what the clock Gadget does (it auto submits the form that would otherwise be required). --Izno (talk) 14:41, 5 March 2019 (UTC)
Indeed, Izno, and of course we have no way of ensuring that every reader has the bit of JavaScript to do an auto-submission just for the insult spout. I somehow doubt we're gong to convince the gatekeepers to add it to MediaWiki:Common.js.
OK, so I just realized that if I click the clock, instead of clicking the indicated here button in Darwinbish's text, the new insults are generated without fuss. Like you guys have been trying to tell me. ;-) But then, the problem isn't that I need a smoother way to get new insults; it's that I want other people to be able to. So as soon as everybody installs the clock, DB can simply tell them to click on that.. yeah.. IOW, it's hopeless. 😱 Bishonen | talk15:05, 5 March 2019 (UTC).
For the query string parameter action=purge the default is to request confirmation, and has been since about May 2016, see phab:T135170. Two gadgets that provide a purge link ("(S) Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation)" and "Add a "Purge" option to the top of the page, which purges the page's cache") were amended not long after so that confirmation step would be skipped. See history of mw:MediaWiki:Gadget-UTCLiveClock.js and MediaWiki:Gadget-purgetab.js to find out how they did it. --Redrose64 🌹 (talk) 00:39, 6 March 2019 (UTC)
I know Bishonen didn't come here for a gobbledegook lecture, but the reason it is no longer possible to purge a page with a simple click is to avoid denial-of-service attacks on the servers. If we could construct a link that purges a page, the URL of that link could be copied to a troll website where hundreds of people would click it multiple times. That would use a lot of server resources. Therefore, there is now a need to click a confirmation link, or use a script. Johnuniq (talk) 02:24, 6 March 2019 (UTC)
OK, I see. Thank you, all. Darwinbish is disappointed, and you know what she's like when she's disappointed, But she understands. Bishonen | talk04:35, 6 March 2019 (UTC).
Hi, Rex!! I've been seeing PHP7 edit summaries like the following example - . (→Other texts) (undo | thank) Tags: 2017 wikitext editor, PHP7 - do you know what the Tags: portion is all about? I remember something about PHP7 making it easier to find edits or something along that line but don't know how to apply it as an advantage. Atsme📣📧16:52, 12 March 2019 (UTC)
@Atsme: The Tags: in an edit summary are usually added by an edit filter, which automatically monitors all edits and takes actions such as disallowing the edit, or adding a warning or a tag to the edit summary.
In this case, though, the MediaWIki software (written in PHP) for Wikipedia currently runs on mw:HHVM (HipHop Virtual Machine), but HHMV is dropping support for running PHP, so we are in the process of migrating to PHP7 (see mw:Compatability #Software required to run MediaWiki) and we will eventually drop our HHVM compatibility. Some editors are using a beta test feature to try out compatibility with PHP7, see your Special:Preferences #mw-prefsection-betafeatures, section "PHP7". The links from there to the information and discussion will give you more information. We'll all be moving to PHP7 soon, so perhaps it's worth checking out. --RexxS (talk) 17:41, 12 March 2019 (UTC)
