User talk:RexxS/Archive 37

Archive 30

←

Archive 35

Archive 36

Archive 37

Archive 38

Archive 39

Archive 40

Thanks!

Hi RexxS, it was nice to run into you on Wikipedia today. Thanks again for your assistance. I hope you don't mind me leaving a note here... I enjoy your above cube :)

There is a small list of Cochrane Review updates to perform on Hyperbaric Medicine. I know that you are knowledgeable in this field and I am not! Would you prefer if I attempt the updates and you can critique them, or do you prefer to tackle them yourself? I am working through this list.

Article Hyperbaric medicine (edit) old review PMID:22513920 new review PMID:26106870 - 00:53, 23 February 2017 (UTC)

Article Hyperbaric medicine (edit) old review PMID:22592699 new review PMID:27123955 - 00:53, 23 February 2017 (UTC)

Article Hyperbaric medicine (edit) old review PMID:16034959 new review PMID:25387992 - 00:53, 23 February 2017 (UTC)

Article Hyperbaric medicine (edit) old review PMID:18646121 new review PMID:26709672 - 00:53, 23 February 2017 (UTC)

Article Undersea and Hyperbaric Medical Society (edit) old review PMID:15106239 new review PMID:22513920 - 02:14, 23 February 2017 (UTC)

Kind Regards, JenOttawa (talk) 18:15, 23 May 2017 (UTC)

Hi Jen, it's always my pleasure to help out when I can. I hope you don't mind that I linked your reviews above? It's much easier to check when you can just click – and you may be pleased to see how easy it is to make wiki-links to PubMed now.

You'll always learn best when you do things, so I'd advise you to get stuck in with the updates – be bold!

The elephant in the room for Hyperbaric medicine – and particularly for Hyperbaric oxygen therapy – is its off-label use as a "treatment" for autism. There's no evidence for any effectiveness, but lots of pressure groups believe in it and want to make the case for approval for reimbursement in the USA. So you may find some unintuitive phrasing in the article.

The article is on my watchlist, so I'll inevitably review any changes you make, and I'd be more than happy to fix any problems you encounter. Ping me if you need me, and I'll let you know if I change anything. Cheers --RexxS (talk) 19:21, 23 May 2017 (UTC)

Thanks for adding the links. I will try out wiki-links next time! I will get to the updates this week. I appreciate your feedback! JenOttawa (talk) 00:51, 24 May 2017 (UTC)

Hi RexxS, I am performing the updates, and I am wondering on how you feel about the use of these two Cochrane reviews in this sentence:

"HBOT is recognized by Medicare in the United States as a reimbursable treatment for 14 UHMS "approved" conditions. A 1-hour HBOT session may cost between $165 and $250 in private clinics, and over $2,000 in hospitals. U.S. physicians (either M.D., D.O., D.D.S., D.M.D., D.C.) may lawfully prescribe HBOT for "off-label" conditions such as stroke,[92][needs update][93][94] and migraine.[95]"[needs update][96][97]

92

Authors'conclusions "We found no good evidence to show that HBOT improves clinical outcomes when applied during acute presentation of ischaemic stroke. Although evidence from the 11 RCTs is insufficient to provide clear guidelines for practice, the possibility of clinical benefit has not been excluded. Further research is required to better define the role of HBOT in this condition."

95

"There was some evidence that HBOT was effective for the termination of acute migraine in an unselected population, and some evidence that NBOT was similarly effective in cluster headache. Given the cost and poor availability of HBOT, more research should be done on patients unresponsive to standard therapy. NBOT is cheap, safe, and easy to apply, so will probably continue to be used despite the limited evidence in this review."

Thanks, JenOttawa (talk) 02:03, 11 June 2017 (UTC)

Hi Jen, thanks for the updates. I've looked hard at the new reviews, and I'm having difficulty with your suggested wording. We really ought not to be quoting sources where we can adequately summarise the conclusions ourselves, and in particular, I'd recommend never quoting "authors' conclusions" directly, particularly the bit about "more research is needed" – that's a conclusion of virtually every study and it really doesn't tell the reader anything; however, it does tend to give the impression that "if only we had more research, we could show that xyz is effective". I spend a lot of time countering woo-woo studies that give that sort of false impression,so I'm naturally antipathetic to that kind of statement.

I see our article quotes 16 conditions approved for reimbursement, but you say only 14 - can you give me the source for that? It looks like we need to fix something there.

We tend not to quote costs of treatment, drugs, etc. as it is usually too specific to a particular country (the cost in the UK is borne by the NHS, for example), and tends to go out of date, but you can mention it if you've got good sourcing. The legal aspects of prescription are interesting and probably worthy of inclusion, especially if we can find how it is dealt with in more countries.

As for stroke, the section Hyperbaric medicine #Neuro-rehabilitation currently contains the blunt sentence: In stroke HBOT does not show benefit. and that's quite well sourced. I don't think I've read anything that contradicts the conclusions of Bennett et al, 2014.

References

Looking at the 5 updates, I don't think I see much that has changed, except for Bennett et al, 2015 which is rather more positive about the effectiveness of normobaric oxygen treatment on cluster headache, but obviously that's not directly relevant to our article on HBOT. That review may actually provide us with something more to say about HBOT and termination of migraines, but I'd recommend being cautious in updating conclusions. Why not have a go at adding something about migraine in your own words? I can always tweak it for you if needed. Cheers --RexxS (talk) 13:16, 11 June 2017 (UTC)

Hi RexxS, Thanks for the quick response. I am sorry about the confusion. I only pasted what the wiki article already says and I pasted the authors conclusions directly from the reviews. I have not made any edits yet because I was not sure if you wanted to change the article text (from above). I agree with you and I never quote the conclusions directly! I also agree with you about the text in the present wiki article. I do not know how the editor came to the conclusion of 14 vs 16. I noticed the text because it seemed strange to me that those Cochrane Reviews were being used to support it. Especially the review on stroke, which was negative. Unfortunately I am out of time today to go through this. For now, I will leave the article as is. I will be back to read through your comments more carefully. Sorry about the confusion with me pasting in the present wiki article. I should have been more clear that it was not my edit! Have a great day! JenOttawa (talk) 14:27, 11 June 2017 (UTC)

Gosh, you're right, Jen - I can't believe that stuff was already in the article at the bottom. I'd forgotten that it was stitched together from two articles, Hyperbaric medicine and HBOT. It's badly in need of a thorough overall to clean out all of the poor writing and dubious conclusions. I think that will only happen if somebody takes the time to read all of the up-to-date sources and re-writes the article from scratch. Thanks so much for finding all the sources that you do – those are going to be vital if we're ever going to improve the article. --RexxS (talk) 18:32, 11 June 2017 (UTC)

I will add in a sentence about migranes, but put it in a different section. Stroke looks good. I will remove the cochrane references from the "cost" section. I don't always see "cost" sections in articles, I will leave it as is for now, as I am not familiar enough with the field to make the judgement call. Hope this will help a little bit at least! Please feel free to edit my edits as you see fit! Thanks again for helping to take at look at these. JenOttawa (talk) 00:46, 12 June 2017 (UTC)

Facto Post – Issue 1 – 14 June 2017

Facto Post – Issue 1 – 14 June 2017 Editorial This newsletter starts with the motto "common endeavour for 21st century content". To unpack that slogan somewhat, we are particularly interested in the new, post-Wikidata collection of techniques that are flourishing under the Wikimedia collaborative umbrella. To linked data, SPARQL queries and WikiCite, add gamified participation, text mining and new holding areas, with bots, tech and humans working harmoniously. Scientists, librarians and Wikimedians are coming together and providing a more unified view of an emerging area. Further integration of both its community and its technical aspects can be anticipated. While Wikipedia will remain the discursive heart of Wikimedia, data-rich and semantic content will support it. We'll aim to be both broad and selective in our coverage. This publication Facto Post (the very opposite of retroactive) and call to action are brought to you monthly by ContentMine. Links Engaging with Data blogposts around WikiFactMine Carly Strasser talks to Open Science Radio Thoughtful WikiCite blogs including discussion of data models on Wikidata: {{Hatnote}}, Wikicite 2017, and the 7 features Wikidata needs most Katie Mika, Ernst Mayr Library, The role of librarians in Wikidata and Wikicite Fact mining in the digital humanities: Andrew Gray, Introducing: Six Degrees on Wikidata A predecessor: Project X newsletter archive Editor Charles Matthews. Please leave feedback for him. If you wish to receive no further issues of Facto Post, please remove your name from our mailing list. Alternatively, to opt out of all massmessage mailings, you may add Category:Opted-out of message delivery to your user talk page. Newsletter delivered by MediaWiki message delivery

Charles Matthews (talk) 14:13, 14 June 2017 (UTC)

As I have learned from Doc James just now, WT:MED is impervious to the charm of most newsletters, even mine. Could you mark my card for some members of the project who might be sympathetic? Charles Matthews (talk) 14:57, 15 June 2017 (UTC)

Verious

1. Something for you to read. If you think I'm nuts don't hesitate to tell me.
2. Are you going to Wikimania? I have 7 days left to decide whether or not I splash out $2,000 to go. Kudpung กุดผึ้ง (talk) 00:29, 15 June 2017 (UTC)

Hi Kudpung, No, you're not nuts. Your concerns are real, and the case you make is compelling. I'm naturally cynical about the chances of getting anywhere, but that certainly shouldn't stop you from trying. Please tell me if I can be of any use to you in any campaign that develops.

I am going to Wikimania after all. If you do decide to splash out, it would be great to meet up and share a few drinks. Let me know once you decide. Cheers --RexxS (talk) 00:28, 16 June 2017 (UTC)

Your draft article, Draft:Tibet women's soccer

Hello, RexxS. It has been over six months since you last edited your Articles for Creation draft article submission, "Tibet women's soccer".

In accordance with our policy that Articles for Creation is not for the indefinite hosting of material deemed unsuitable for the encyclopedia mainspace, the draft has been nominated for deletion. If you plan on working on it further, or editing it to address the issues raised if it was declined, simply and remove the {{db-afc}} or {{db-g13}} code.

If your submission has already been deleted by the time you get there, and you wish to retrieve it, you can request its undeletion by following the instructions at this link. An administrator will, in most cases, restore the submission so you can continue to work on it.

Thanks for your submission to Wikipedia, and happy editing. IM3847 (talk) 12:23, 18 June 2017 (UTC)

It's not my article and I don't submit my created articles to AfC. I merely created a draft of an article that 2A01:E34:EE0E:ABD0:B854:9C74:3C1F:E26D (talk · contribs · WHOIS) had made in their talk page. User talk:2A01:E34:EE0E:ABD0:B854:9C74:3C1F:E26D #Tibet women's soccer refers. I've now moved the draft into mainspace as it seems the IP user hasn't edited it since last year. --RexxS (talk) 13:43, 18 June 2017 (UTC)

This is to inform you that an attempt is being made to overturn an RfC that you voted on

This is to inform you that an attempt is being made to overturn an RfC that you voted on (2 RfCs, actually, one less than six months ago and another a year ago). The new RfC is at:

Wikipedia:Village pump (policy)#RfC: Allow private schools to be characterized as non-affiliated as well as religious, in infobox?

Specifically, it asks that "religion = none" be allowed in the infobox.

The first RfC that this new RfC is trying to overturn is:

• 15 June 2015 RfC: RfC: Religion infobox entries for individuals that have no religion.

The result of that RfC was "unambiguously in favour of omitting the parameter altogether for 'none' " and despite the RfC title, additionally found that "There's no obvious reason why this would not apply to historical or fictional characters, institutions etc.", and that nonreligions listed in the religion entry should be removed when found "in any article".

The second RfC that this new RfC is trying to overturn is:

• 31 December 2015 RfC: RfC: Religion in infoboxes.

The result of that RfC was that the "in all Wikipedia articles, without exception, nonreligions should not be listed in the Religion= parameter of the infobox.".

Note: I am informing everyone who commented on the above RfCs, whether they supported or opposed the final consensus. --Guy Macon (talk) 03:38, 26 June 2017 (UTC)

Cite Q: Publisher links

Hi, Could you tweak {{Cite Q}} so that when the publisher has an article, e.g.

• {{cite Q|Q29581763}}
• Stefania Crowther; Lois Reynolds; Tilli Tansey, eds. (2009). The Resurgence of Breastfeeding, 1975-2000. Wellcome Witnesses to Contemporary Medicine. London: History of Modern Biomedicine Research Group. ISBN 978-0-85484-119-6. Wikidata Q29581763.
• History of Modern Biomedicine Research Group

the publisher is linked, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 30 June 2017 (UTC)

There's a call in Module:WikidataIB that does that job already (and deals with redirects, etc.):

• {{#invoke:WikidataIB |getValue |qid=Q29581763 |P123 |fetchwikidata=ALL |onlysourced=no |noicon=true}} → History of Modern Biomedicine Research Group

So I've used it in {{Cite Q}} and it seems to work:

• {{cite Q|Q29581763}} → Stefania Crowther; Lois Reynolds; Tilli Tansey, eds. (2009). The Resurgence of Breastfeeding, 1975-2000. Wellcome Witnesses to Contemporary Medicine. London: History of Modern Biomedicine Research Group. ISBN 978-0-85484-119-6. Wikidata Q29581763.

You should test it further, though. Let me know if there are problems. --RexxS (talk) 16:29, 30 June 2017 (UTC)

Looks good, but I'll keep an eye on it. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 30 June 2017 (UTC)

Distributed web crawling

Can you take a look at Distributed web crawling? It seems off just like last time...

PS: How did you add the hypno-cube up there ^^^^

Darklight Shadows 21:54, 1 July 2017 (UTC)

It's User talk:RexxS/Editnotice, see WP:EDN. --Redrose64 🌹 (talk) 21:57, 1 July 2017 (UTC)

WikidataIB oddity

Hi RexxS. Any idea why {{#invoke:WikidataIB|getValue|P571|fetchwikidata=ALL|onlysourced=no|qid=Q29384167}} returns 1860s, c. 1862 ? In Woman Seen from the Back (Q29384167) the value is 1860s, which is what is returned by {{#Property:P571}} in Woman Seen from the Back... Thanks. Mike Peel (talk) 22:30, 27 June 2017 (UTC)

Yes Mike, it's because that's what the value stored actually is. If you preview {{#invoke:Wikidata|Dump}} in Woman Seen from the Back and search (Ctrl-F) for "P571", you'll see that ["P571"].mainsnak.value.time = "+1862-01-01T00:00:00Z", with a precision = 8 (decade) and two qualifiers which have earliest date (P1319) as "+1860-01-01T00:00:00Z" and latest date (P1326) as "+1864-01-01T00:00:00Z" (both precisions = 9 (year)). In other words, it represents the time range 1860 to 1864. Neither WikidataIB nor #Property implements arbitrary time ranges yet. In this particular case, WikidataIB represents "1860–1864" as "1862", while #Property represents "1860–1864" as "1860s". Ya pays yer money and ya takes yer choice, as they say. If I can summon up some enthusiasm, I'll update the code to implement date ranges. --RexxS (talk) 23:47, 27 June 2017 (UTC)

That's very wierd. :-/ If you look at the entry on Wikidata, you see (and can edit) 1860s, so I expected that would be passed through to here. Maybe that's something to raise on phabricator. It's not urgent, since there's a work-around, but it would be good to get this sorted out at some point. Thanks. Mike Peel (talk) 23:59, 27 June 2017 (UTC)

But Mike, you can't actually look at the entry on Wikidata. It's a common mistake made by everyone used to editing Wikipedia. All you see is a JavaScript-generated user interface that translates the RDF as stored in the Wikidata database into readable/editable sections. As far as I am aware, "1860s" is not a value stored anywhere on Wikidata. --RexxS (talk) 00:14, 28 June 2017 (UTC)

Hmm, OK. To test this, I just changed the value to 1950s, and it came out as a 1950 timestamp. It's not great when the basic interface does interpretation like this. :-( Ah well. Thanks. Mike Peel (talk) 00:19, 28 June 2017 (UTC)

@Mike Peel: Actually, we did explicitly add the mean estimated date and a precision factor to Wikidata (creating "1860s"), after running through a calculation based on the earliest and latest possible dates (did the same for many items). If we hadn't done it this way, when it called the date, you would have just gotten the earliest date outputted, in this case "1860". Which isn't far off in this case, but sometimes there is a range for artworks of hundreds or thousands of years.--Pharos (talk) 18:43, 29 June 2017 (UTC)

BTW, do you know if it's possible to get the URL associated with IDs on Wikidata? E.g. in Woman Seen from the Back (Q29384167), is there a way to access the URL for The Met object ID? Thanks. Mike Peel (talk) 23:53, 28 June 2017 (UTC)

Yes Mike, but only on a case-by-case basis. In the case of Woman Seen from the Back (Q29384167), the The Met object ID (P3634) has the value:

• {{#invoke:WikidataIB|getValue|P3634|fetchwikidata=ALL|onlysourced=no|qid=Q29384167}} → 283121 

so the url is:

• http://www.metmuseum.org/art/collection/search/{{#invoke:WikidataIB|getValue|P3634|fetchwikidata=ALL|onlysourced=no|qid=Q29384167}} → http://www.metmuseum.org/art/collection/search/283121 .

Obviously you don't need the |qid=Q29384167 for use in the article infobox, and you might or might not want to add |noicon=true.

The formatter URL (P1630) can be found at The Met object ID (P3634) and retrieved thus:

• {{#invoke:WikidataIB|getValue|P1630|fetchwikidata=ALL|onlysourced=no|qid=P3634}} → https://www.metmuseum.org/art/collection/search/$1, https://collectionapi.metmuseum.org/public/collection/v1/objects/$1 

although it's far more efficient just to hard-code it into the infobox, as it's fixed for the Met object ID (hopefully permanently). HTH --RexxS (talk) 01:06, 29 June 2017 (UTC)

Thanks! I'm thinking about writing a template that can fetch all of the info about an ID just based on the property number, i.e. something like {{Wikidata ID|P3634|qid=Q29384167}}, which can then be included in infoboxes as needed (perhaps with a series of property numbers that are relevant for that infobox), which avoids hard-coding things but does mean things are less efficient... Thanks. Mike Peel (talk) 01:32, 29 June 2017 (UTC)

I figured out a way to fetch the formatter URL, so {{Wikidata ID}} (and {{Wikidata ID line}}) now exists and works, although it's not the nicest code! If there's anything you can do to help tidy it up, I'd appreciate it. :-) Thanks. Mike Peel (talk) 21:52, 29 June 2017 (UTC)

Sorry, another request. [1] doesn't work - any chance of adding qid support to Module:Wikidata or unit support to Module:WikidataIB please? Thanks. Mike Peel (talk) 00:03, 30 June 2017 (UTC)

Hi Mike. It's quicker to add qid support to Module:Wikidata, unless it gets reverted, of course:

• spouse (P26) of Bill Clinton (Q1124) is Hillary Clinton
• height (P2048) of Eiffel Tower (Q243) is 330 metre
• Units of height (P2048) of Eiffel Tower (Q243) is metre, 300 metre, 330 metre

I'll eventually get around to implementing units in Module:WikidataIB, although using WikidataIB returns the units with the value of the property:

• height (P2048) of Eiffel Tower (Q243) is 324 metre, 300 metre, 330 metre 

Is that enough to get you working for now? --RexxS (talk) 16:13, 30 June 2017 (UTC)

Thanks, that seems to be working nicely! Mike Peel (talk) 14:43, 1 July 2017 (UTC)

I have another request, sorry! Would it be possible to split out the blacklist code into a new module that I can also call directly? That way I can use the same system to suppress fields that I'm currently using convert, coord, etc. at Template:Infobox artwork/wikidata, rather than having to come up with a separate one. I think it should be quite simple code? Basically, I want to do something like {{check_blacklist|name=coord||suppressfields={{suppressfields|}}}}}, which I can then use in an #if statement to determine if the rest of the line should be shown. Thanks. Mike Peel (talk) 20:31, 1 July 2017 (UTC)

@Mike: OK - is this what you want?

• {{#if:{{#invoke:WikidataIB |checkBlacklist |name=Joe |suppressfields=Dave; Joe; Fred}} | not blacklisted | blacklisted}} → blacklisted
• {{#if:{{#invoke:WikidataIB |checkBlacklist |name=Jim |suppressfields=Dave; Joe; Fred}} | not blacklisted | blacklisted}} → blacklisted

That displays the first option if the name is not on the blacklist (so you can leave out the second and make it display nothing when it is blacklisted). Or do you want the opposite logic? --RexxS (talk) 23:59, 1 July 2017 (UTC)

That should work, thanks! I'll test it and get back to you. BTW, I think the bug I just posted at WikidataIB's talk page is unrelated to this, sorry again. Thanks. Mike Peel (talk) 00:04, 2 July 2017 (UTC)

It is working nicely, thank you! Mike Peel (talk) 00:24, 2 July 2017 (UTC)

FYI

You will be very interested in this and may wish to comment there. Kudpung กุดผึ้ง (talk) 02:53, 16 July 2017 (UTC)

Thank you, Kudpung. It's indeed an interesting discussion, but I've got little to add, really. My position is in a small minority as I object to all paid editing, because I don't accept that anyone can edit in an unbiased way when their income depends on them making the edits. Of course, I don't have a problem with Wikimedians-in-Residence editing articles while being paid to do so, as long as they are not directly editing the article about their employer, but that ought to go without saying. I'll keep an eye on that discussion anyway. --RexxS (talk) 16:54, 17 July 2017 (UTC)

Perhaps that minority is not as small as you think … there are at least two of us! Justlettersandnumbers (talk) 10:12, 19 July 2017 (UTC)

Horse breed infobox, yet again

Hi, RexxS! There's still a (minor) problem with display in the horse breed infobox: the |female_height= and |male_height= parameters are right-justified (correctly so, IMO), but |height= is not. That creates inconsistencies – see Hungarian Sport Horse for an example. Can this be resolved? I know I can't fix it. Justlettersandnumbers (talk) 10:10, 19 July 2017 (UTC)

Hi Justlettersandnumbers, I looked at Hungarian Sport Horse, and can see the difficulty. However, it seems that the infobox is using both |height= and |female_height=, while the documentation seems to require that you should "Use either the general height parameters OR the split male/female height parameters, not both". If that happens, the problem goes away. On the other hand, I can see that a case might exist where you only know the value for both sexes and the value for the female (or the sources give a range and an average, etc.). My advice would still be to avoid mixing |height= and |female_height=, and perhaps discuss the heights in the article, leaving one or the other parameters out of the infobox.

If you really want to use both, then can you tell me how you would like it resolved? As one example, I've made the image a bit wider in Hungarian Sport Horse to ease the line-wrapping in that particular case, but it's not a general solution. Optionally, I could right-justify all of the weights and heights, but maybe that would then be unsatisfactory aesthetically in Arabian horse, for example. Are you considering having height/weight right-justified only when male_/female_ height/weight are also used? If so, you'll probably want to get consensus from WP:EQUINE first (and that would give me time to figure out how to implement it :P). Cheers --RexxS (talk) 17:30, 19 July 2017 (UTC)

Thanks for looking at it. The documentation was written by one person, without discussion or consensus. Of course I don't mean that the problem is in the horse breed template, it's in the animal breed one. Anyway, it looks as if I can botch that particular occurrence (and perhaps some others) with {{right}}, so why don't we leave this aside for now? It's probably never going to be possible to cater for all eventualities whatever you do, however skilfully you do it, and it's anyway somewhere around two on a 100-point scale of importance of things to get right in Wikipedia. Thanks again, Justlettersandnumbers (talk) 22:00, 19 July 2017 (UTC)

To be honest, I would generally expect that a work-around that solves the odd edge case is a decent solution, so you've probably done the right thing for now. Cheers --RexxS (talk) 01:24, 20 July 2017 (UTC)

Preferred ranks problem

Hi RexxS. I'm having problems with preferred ranks and Module:Wikidata / Module:WikidataIB. After making this edit to Corisca and the Satyr (Q29016906) to only show one of the listed creators, the modules still return:

• Artemisia Gentileschi, Aniella di Beltrano, Massimo Stanzione
• Artemisia Gentileschi, Aniella di Beltrano, Massimo Stanzione 

Any idea why this is happening? Thanks. Mike Peel (talk) 22:17, 8 July 2017 (UTC)

Yes Mike, it's because getValue() in both of those modules ignores ranks and return all values for any value that is a Wikibase entity (i.e. a linked item). They both contain code written when ranks were in their infancy and were liable to be changed almost randomly, so the design philosophy for Module:Wikidata was that if the property value was worth including in Wikidata, it was worth fetching for the infobox. The code exists to use ranks, as it's deployed in the image/caption calls (which only make sense for single-valued properties), but I'm not convinced that for most properties that are not single-valued, there is a good case yet for only fetching the best ranked value(s). I can see that going forward, there would be a case for making use of the facility, on the assumption that the ranks will be curated better on Wikidata – it's a very simple and subtle form of vandalism to swap ranks. You also need to consider how we would handle the case when different Wikipedias wanted different values to be the preferred one. I'm not keen on enabling ranks across the board right now, but I guess I could add a new function, something like "getPreferredValue()" when I get an hour or so to create and test it. --RexxS (talk) 12:15, 9 July 2017 (UTC)

Update for you, Mike:

• {{#invoke:WikidataIB|getValue|P170|fetchwikidata={{{fetchwikidata|ALL}}}|qid=Q29016906|onlysourced={{{onlysourced|no}}}|{{{artist|}}}}} → Artemisia Gentileschi, Aniella di Beltrano, Massimo Stanzione 
• {{#invoke:WikidataIB|getPreferredValue|P170|fetchwikidata={{{fetchwikidata|ALL}}}|qid=Q29016906|onlysourced={{{onlysourced|no}}}|{{{artist|}}}}} → Artemisia Gentileschi 

Have fun! --RexxS (talk) 16:11, 17 July 2017 (UTC)

Thanks, it seems to be working nicely! Although I think that getPreferredValue would be the better approach to use in place of the current getValue behaviour by default. Thanks. Mike Peel (talk) 22:55, 21 July 2017 (UTC)

Well, Mike, that may become true at some point, but I find Wikidata too chaotic this early in its existence to be sure that preferred ranks will be used sensibly at present. However, I don't have to make those sort of decisions – that's up to the folks like yourself who are using the calls to build infoboxes, and you now have a choice. All the parameters are the same, so switching from one call to another is just a few letters away. Cheers --RexxS (talk) 14:15, 22 July 2017 (UTC)

reflist in talkpage

re your reversal [2] of {{reflist-talk}} I used. As you say in the es: "reflist-talk is best left with the section where it relates". That was where I put it (bottom of section). {{reflist-talk}} documentation also promotes this. Since the section was last on the page, that happened to be bottom of page, but that does not matter. BTW, no "messing up archiving" was in play. Incidentally, as you reinstalled it, there appeared a stray (uncontrolled so standard positioned) reference at the very bottom of the page. -DePiep (talk) 14:50, 22 July 2017 (UTC)

@DePiep: QuackGuru fixed Doc James' omission of the third ref-talk, so that problem has disappeared. Why do you find it necessary to "tidy up" other people's talk page contributions? You know what you're doing, and you understand that it makes no big difference to the display, but it sets a really bad example for newer editors who could easily take that as licence to add {{reflist-talk}} in inappropriate places. The maxim "if it ain't broke, don't fix it" surely has some relevance here? --RexxS (talk) 15:09, 22 July 2017 (UTC)

I added that template on the place as advised per documentation, which fixed that last one (and as you apparently approve as done by QuackGuru). I only pointed out that your reversal & es had these flaws, and you simply could have responded to that. The argument you put up here is different from your editsummary. -DePiep (talk) 15:24, 22 July 2017 (UTC)

You're still missing the point. You removed templates that other editors had placed sensibly. If the template is placed immediately after the paragraph that sources it, there is no good reason to move it. It's make-work. The WP:TPG are far more relevant than a badly-though-out piece of documentation that nobody looks at. Secondly, once editors start to think that it's ok to collect up all the ref-talk templates and drop one at the bottom of the section, they'll think it's more important to have a single template than it is to respect the intentions of the original poster and to keep the convenience of having the reference near where it is invoked, even on the longest and most convoluted of threads. What do propose to do when a long discussion is broken up into smaller sections? Move the ref-talk back into the sub-section where it is related? I agree that my original edit summary was mistaken and I thought you were moving the template to the bottom of the page, which of course you were, although your intention I can now see was that it was only meant to be the bottom of the thread. The issues I see in relation to refactoring other editors' talk page contributions remain though. --RexxS (talk) 17:57, 22 July 2017 (UTC)

Talk archives

RexxS, I am not sure I've been properly creating autoarchiving for article talk pages. If I want to archive everything after x days (60, 90, 180, whatever) and create new archives when one is full up, can you point me to an article talkpage that has the proper syntax for me to swipe? Thanks. Montanabw^(talk) 22:35, 30 July 2017 (UTC)

Congrats on your Editor of the Week award! There's a functioning archive on Talk:Chiropractic that you can look at. The bits that do the job are:

Archiving by lowercase sigmabot III:

{{User:MiszaBot/config
|archiveheader = {{aan}}
|maxarchivesize = 300K
|counter = 39
|minthreadsleft = 0
|algo = old(20d)
|archive = Talk:Chiropractic/Archive %(counter)d
}}

Note that the archives there are currently at number 39 (counter=39) – obviously you'd start a fresh archive at counter=1 (unless some manual archives already existed). The archiving is done every 20 days (algo = old(20d)).

Creating the Archive box that indexes the archives:

{{Archives|search=yes|auto=short|bot=MiszaBot|age=20|index=Talk:Chiropractic/Archive index}}

Note that {{Archives}} is all that's needed, but the |auto=short makes the display compact.

That talk page actually has an extra: Talk:Chiropractic/Archive index, indexing every section header, which is created by

{{User:HBC Archive Indexerbot/OptIn|target=Talk:Chiropractic/Archive index|mask=Talk:Chiropractic/Archive <#>|leading_zeros=0|indexhere=yes}}

That isn't necessary, but is a convenience for searching when the talk archives get long.

There are very full instructions at Help:Archiving a talk page #Options, but you can always ping me if you get stuck. Cheers --RexxS (talk) 12:47, 31 July 2017 (UTC)

Second tech problem

I should have noticed this after a decade, but {{WikiProject_Indigenous_peoples_of_North_America}} doesn't show "importance" ratings in the project box... as a result, lots and lots of articles in this project are unassessed and those that are, the assessment doesn't show up. Can you do some magic wiki-foo on this template to make it work? Thanks. Montanabw^(talk) 01:23, 31 July 2017 (UTC)

@Montanabw: I've added the importance parameter to the template, so now it's just a case of working through Special:WhatLinksHere/Template:WikiProject_Indigenous_peoples_of_North_America and filling in the values for |importance=. Have fun! --RexxS (talk) 13:00, 31 July 2017 (UTC)

A lot of them were already assessed, such as Sitting Bull. Those assessments now appear, so we are good --other than having zillions more articles to assess. (Is there a shortcut that can do this...?). Montanabw^(talk) 19:22, 31 July 2017 (UTC)

I've added the new param to the doc page. --Redrose64 🌹 (talk) 07:00, 1 August 2017 (UTC)

Nested footnotes

Hi RexxS, you know more about reference templates, so once again I ask your advice on a vexatious problem. In Underwater_diving#Risk_management I needed to reference the footnotes, and discovered several ways that it cannot be done. The article was consistent in having all the ref defs in the reflist, but if it is possible to do this for nested footnotes, I have been unable to find the way. The help file appears to say it is not possible, but it is not very clear, and may be out of date. I have managed to do it with the ref defs inline, but this nudges my OCD. Do you know if it is possible, and if so, how to do it? Cheers, • • • Peter (Southwood) ^(talk): 12:31, 31 July 2017 (UTC)

@Peter: I can't see an easy way do that either. I've created a cut-down version of the problem in User:RexxS/sandbox3 to be a bit more manageable in trying out solutions, but so far I've hit the same brick wall as you have, Peter. Please feel free to tinker with that page if you have any ideas to try out and I'll do some more research to see if anyone has a solution. Cheers --RexxS (talk) 13:52, 31 July 2017 (UTC)

OK • • • Peter (Southwood) ^(talk): 14:03, 31 July 2017 (UTC)

@Peter and RexxS: Hi guys - you may want to take a look at a draft of mine at User:Robevans123/sandbox/Tredegar Town Clock. I've created a list of nested footnotes with references which is want I think you're after. The syntax is a bit different - I've used efn and notelist to create the footnotes. The bullets are created using the bulleted list template within the efn. Look at the section Conception and footnote b for details. Hope this helps. Robevans123 (talk) 15:10, 31 July 2017 (UTC)

Thank you Rob, but the problem we're struggling with is that of removing the content of the footnote out of the article text as list-defined references do. It would be nice to have just a named footnote in place in the text, just as you have the named references with the {{r}} template.

However, you started me thinking about {{efn}}/{{notelist}} and that works! @Peter: take a look at User:RexxS/sandbox3 - we have "list-defined footnotes!" using {{efn}} and {{notelist}}. I'm just going to see if I can extend it to refn/reflist with groups. --RexxS (talk) 15:47, 31 July 2017 (UTC)

And that works as well now. See User:RexxS/sandbox3a. It doesn't matter whether the names are in quotes or not as they are template parameters, not tag attributes. --RexxS (talk) 16:08, 31 July 2017 (UTC)

Now I understand, but glad to have nudged you in the right direction! Good to see your sandbox examples working well. I'd forgotten/didn't know you could define footnotes with {{efn}}s in the {{notelist}}. Much neater and avoids bracket fatigue. Cheers Robevans123 (talk) 16:58, 31 July 2017 (UTC)

There are a couple of anomalies, or maybe two examples of the same one. There are two backlinks from Administration, which is only used once, and two backlinks from "OHS answers" which is used three times. Also, when I applied the method at Underwater diving#Notes, I get an error message Cite error: A list-defined reference named "OHS_answers" is not used in the content (see the help page)., and this is in the notes section, not the references section where the definition actually is. I also get an extra backlink symbol from Engineering, but the extra backlink doesn't actually work. Cheers, • • • Peter (Southwood) ^(talk): 20:00, 31 July 2017 (UTC)

(edit conflict) I spoke too soon. Looking carefully at User:RexxS/sandbox3 and User:RexxS/sandbox3a, there are subtle errors: Notes b. has two backlinks, but only one invocation; whereas References 1. has only two backlinks although it is invoked three times. This solution is also causing errors in Underwater diving. --RexxS (talk) 20:05, 31 July 2017 (UTC)

It looks like the implementation really is bugged, Peter. I'd restore the previous version of Underwater diving while I investigate further. --RexxS (talk) 20:07, 31 July 2017 (UTC)

I will do that now that you have had a chance to see it. • • • Peter (Southwood) ^(talk): 07:52, 1 August 2017 (UTC)

Pretty sure this has come up before, and the only practical solution seems to be to stay away from WP:LDR. You were heading towards the right lines by using {{refn}}, but personally I would use that only for the actual refs - the notes would be marked up with {{efn}}. The {{efn}} template will happily enclose either {{refn}} or {{sfn}} according to the general ref style of the article. The article footers will contain a {{notelist}} and a {{reflist}} in that order, with an optional heading between. Don't use the |group= parameter for any of these templates. --Redrose64 🌹 (talk) 07:18, 1 August 2017 (UTC)

But the whole point is to use LDR to make the article source text more readable and manageable. It's obvious that efn/notelist works if each definition is made within article text (as does refn/reflist+group because efn hard-codes a default "group=lower-alpha" version of refn). There's clearly no good reason why defining refs in the Reference section works but defining notes in the Notes section doesn't. The version of the article using {{refn|group=note}} has functional footnotes, but the wiki-text of the Risk management section is almost undecypherable. --RexxS (talk) 09:57, 1 August 2017 (UTC)

ANI

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Lynn (SLW) (talk) 12:02, 1 August 2017 (UTC)

You have been taken to AN/I by someone

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. We hope (talk) 21:20, 2 August 2017 (UTC)

There always appears to be a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Have you entered a competition to win the experience of being me or Eric circa 2010? ‑ Iridescent 21:23, 2 August 2017 (UTC)

No, but thanks for the suggestion. I'm really not cut out for such an honour, although I must admit that as the years go by, I find myself increasingly less tolerant of poor editors, and unfortunately I do seem to find myself regularly telling them so. Oh well. --RexxS (talk) 21:30, 2 August 2017 (UTC)