Jump to content

User talk:Tom.Reding

Page contents not supported in other languages.
This user has template editor rights on the English Wikipedia.
This user is a WikiGnome.
This user has AutoWikiBrowser permissions on the English Wikipedia.
Bot operator top icon
This user uses HotCat to work with categories.
Trout this user
This user is a WikiSloth.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Peter coxhead (talk | contribs) at 14:54, 26 December 2019 (→‎Taxonbar issue: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

You may want to increment {{Archive basics}} to |counter= 3 as User talk:Tom.Reding/Archive 2 is larger than the recommended 150Kb.

Please continue conversations on the same talk page that they started.
Click here to start a new conversation. Thank you!
This...should...do it!

Barnstar

The Original Barnstar
This barnstar is awarded to everyone who - whatever their opinion - contributed to the discussion about Wikipedia and SOPA. Thank you for being a part of the discussion. Presented by the Wikimedia Foundation, January 21, 2012.

A barnstar for you!

The Technical Barnstar
Congratulations, Tom.Reding, you've recently made your 1,000th edit to articles on English Wikipedia!

Thank you for all the great DAB work you've been doing recently, and for all your contributions to the encyclopedia. Keep it up! :) Maryana (WMF) (talk) 23:17, 16 April 2012 (UTC)[reply]

A barnstar for you!

Working Wikipedian's Barnstar
For your incredible WikiGnoming over the past few months. I am in awe. A2soup (talk) 23:25, 22 February 2015 (UTC)[reply]

Thank you! :)   ~ Tom.Reding & his 200-some-odd lines of regex (talk ⋅contribs ⋅dgaf)  02:03, 23 February 2015 (UTC)[reply]

A barnstar for you!

The Tireless Contributor Barnstar
You have nearly single-handedly eliminated the minor planet notability problem, which had stood for seven years before you decided to tackle it, because nobody wanted to do the massive amount of work required. If this doesn't deserve a barnstar, I'm not sure what does. StringTheory11 (t • c) 17:49, 3 May 2015 (UTC)[reply]

A barnstar for you!

The Tireless Contributor Barnstar
For dealing with the minor planet clusterfuck as efficiently as you have! Headbomb {talk / contribs / physics / books} 04:13, 1 February 2016 (UTC)[reply]

There's nothing quite like cleaning up a good, 'ol-fashioned clusterfuck. Thanks for pointing me in the right direction :)   ~ Tom.Reding (talk ⋅dgaf)  04:17, 1 February 2016 (UTC)[reply]

BTW, this isn't just for the recent banner tagging, but for the shear amount of effort involved in cleaning up the mess for the past year or so. Possibly longer. Headbomb {talk / contribs / physics / books} 00:27, 2 February 2016 (UTC)[reply]

A barnstar for you!

The Technical Barnstar
thanks for helping me with the search codes! Jennica✿ / talk 20:10, 9 April 2017 (UTC)[reply]

Thank you for being one of Wikipedia's top medical contributors!

please help translate this message into your local language via meta
The 2016 Cure Award
In 2016 you were one of the top ~200 medical editors across any language of Wikipedia. Thank you from Wiki Project Med Foundation for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a user group whose mission is to improve our health content. Consider joining here, there are no associated costs.

Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 18:08, 3 May 2017 (UTC)[reply]

Barnstar awarded

The Redirect Barnstar
Your diligent work in the area of redirect categorization and improvement is duly recognized and greatly appreciated. You are truly one of the unsung heroes of Wikipedia, and we hope you continue to enjoy your improvement of this awesome encyclopedia! On behalf of your fellow editors—and the millions of readers of our work—I sincerely thank you for your contributions that have improved the encyclopedia for everyone. Senator2029 “Talk” 08:33, 8 June 2017 (UTC)[reply]

A barnstar for you!

The Editor's Barnstar
Thank you very much for helping and editing the Joe Campos Torres article, your assistance put a BIG SMILE on my face!
Vwanweb (talk) 16:53, 31 December 2017 (UTC)[reply]
My pleasure; that was a satisfying edit :)   ~ Tom.Reding (talk ⋅dgaf)  16:56, 31 December 2017 (UTC)[reply]

Another barnstar for you!

The Bio-star
In recognition of your recent contributions to the Life Sciences on en:Wikipedia, analyzing and helping to improve the quality of articles, based on scientific data. Your efforts demonstrate tremendous potential into enhancing the scientific accuracy of The Free Encyclopedia.

I am tremendously appreciative of your efforts, especially on the preliminary Taxonomic analysis.

~ Mellis (talk) 23:48, 31 December 2017 (UTC)[reply]

Editor of the Week

Editor of the Week
Your ongoing efforts to improve the encyclopedia have not gone unnoticed: You have been selected as Editor of the Week in recognition of your constant positive demeanor. Thank you for the great contributions! (courtesy of the Wikipedia Editor Retention Project)

User:Buster7 submitted the following nomination for Editor of the Week:

I am always on the lookout for potential Editor of the Week candidates, for editors that fly under the radar, whose efforts are unknown except to a few. They don't make a splash, they don't emit a 'notice me' kind of behavior; they just quietly tackle the hard jobs. Tom.Reding is that kind of editor. A while back he "thanked me" via the Thanks Notification for awarding the Editor of the Week to a fellow editor. So, I looked into him and found an editor that does many important WP improving things. He is a working editor (535,847 live and undeleted edits) that fixes, populates, corrects, standardizes, cleans, parses, tries, peruses, adds, formats, listens, expands, updates, corrects, creates, assigns and (my favorite) "consistifies". A member of Wikiproject Astronomy and Wikiproject Tree of Life, he has recently been granted the page mover user right. He provides a human eye and understanding to "bot" problems that arise. In the area of redirect categorization he willingly puts his head together with other editors to work toward solution. A deserving recipient.

You can copy the following text to your user page to display a user box proclaiming your selection as Editor of the Week: 

{{User:UBX/EoTWBox}}
Project Med Foundation
Tom.Reding
 
Editor of the Week
for the week beginning January 28, 2018
Quietly tackles the hard jobs. 536000 live and undeleted edits. A page mover. Understands "bot" problems. A deserving recipient.
Recognized for
work in redirect categorization
Notable work(s)
Wikiproject Astronomy and Wikiproject Tree of Life
Submit a nomination

Thanks again for your efforts! ―Buster7 ☎ 20:38, 28 January 2018 (UTC)[reply]

! XD <3 TY!   ~ Tom.Reding (talk ⋅dgaf)  20:56, 28 January 2018 (UTC)[reply]

The AWB Barnster

The AWB Barnster
Fixing many depreciated syntax on infobox images. Iggy (Swan) 22:14, 12 February 2018 (UTC)[reply]

A barnstar for you!

Olympic Barnstar
For your excellent work in getting the bot up and running to tag biographies for the Olympic Wiki Project. Thank you! Lugnuts Fire Walk with Me 10:00, 17 March 2018 (UTC)[reply]
Thanks, my pleasure :)   ~ Tom.Reding (talk ⋅dgaf)  12:04, 17 March 2018 (UTC)[reply]

Thank you for being one of Wikipedia's top medical contributors!

please help translate this message into your local language via meta
The 2016 Cure Award
In 2016 you were one of the top ~200 medical editors across any language of Wikipedia. Thank you from Wiki Project Med Foundation for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a user group whose mission is to improve our health content. Consider joining here, there are no associated costs.

Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 18:08, 3 May 2017 (UTC)[reply]

Congrats on joining the million edit club!

The Tireless Contributor Barnstar
Congratulations on being the seventh editor on the English Wikipedia to do over a million non-bot edits! ϢereSpielChequers 12:14, 17 May 2018 (UTC)[reply]
Thanks! I never thought I'd do so much, but I just keep finding things to fix/improve :)   ~ Tom.Reding (talk ⋅dgaf)  13:12, 17 May 2018 (UTC)[reply]

A barnstar for you!

The Space Barnstar
For your astronomic contributions! For taking up so much space!

With apologies for the puns, Ira Leviton (talk) 20:17, 8 June 2018 (UTC)[reply]

A Dobos torte for you!

7&6=thirteen (☎) has given you a Dobos torte to enjoy! Seven layers of fun because you deserve it.


To give a Dobos torte and spread the WikiLove, just place {{subst:Dobos Torte}} on someone else's talkpage, whether it be someone you have had disagreements with in the past or a good friend.

7&6=thirteen (☎) 16:09, 15 October 2018 (UTC)[reply]

You have used your gifts well, Padawan

Bringing order out of chaos
OCD. It's not an affliction. It is a gift, and is part of the job description for being a Wikipedia editor. See WP:wikiholic.

"Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering."

Takes one to know one. Best regards. 7&6=thirteen (☎) 16:36, 15 October 2018 (UTC)[reply]

7&6=thirteen, thank you :) And I really should take the test, but I can't be bothered while editing...perhaps that is or should be one of the questions??   ~ Tom.Reding (talk ⋅dgaf)  16:49, 15 October 2018 (UTC)[reply]

Thank you for being one of Wikipedia's top medical contributors!

The 2018 Cure Award
In 2018 you were one of the top ~250 medical editors across any language of Wikipedia. Thank you from Wiki Project Med Foundation for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a user group whose mission is to improve our health content. Consider joining here, there are no associated costs.

Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 17:41, 28 January 2019 (UTC)[reply]

A barnstar for you!

The Original Barnstar
Jobe well done when it comes to the article on Prof. Helmut Veith (1971-2016). Terrenus (talk) 14:48, 26 November 2019 (UTC)[reply]

Thank you for being one of Wikipedia's top medical contributors!

please help translate this message into your local language via meta
The 2019 Cure Award
In 2019 you were one of the top ~300 medical editors across any language of Wikipedia. Thank you from Wiki Project Med for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a thematic organization whose mission is to improve our health content. Consider joining here, there are no associated costs.

Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 18:35, 5 March 2020 (UTC)[reply]

A barnstar for your efforts

The Working Wikipedian's Barnstar
Thank you for your continued service adding to Wikipedia throughout 2020. - Cdjp1 (talk) 14:01, 20 January 2021 (UTC)[reply]
:)   ~ Tom.Reding (talk ⋅dgaf)  15:40, 20 January 2021 (UTC)[reply]

A barnstar for you!

The Bot Creator Barnstar
For putting your OCD to good use when you created Tom.Bot. Scorpions13256 (talk) 23:27, 13 February 2021 (UTC)[reply]

I see we both have OCD. I had no choice but to give you this barnstar. Scorpions13256 (talk) 23:27, 13 February 2021 (UTC)[reply]

Thank you, comrade.   ~ Tom.Reding (talk ⋅dgaf)  04:21, 14 February 2021 (UTC)[reply]

A barnstar for you!

The Original Barnstar
thank you for all your help here. Paulhus15 (talk) 09:59, 1 March 2021 (UTC)[reply]

A barnstar for you!

The Original Barnstar
Just a barnstar for you!

Your userboxes were fascinating and you seem like a really interesting person. I also somehow see you on every page I edit.

Thanks for the contributions you have made! Hhzhang2345 Hhzhang2345 (talk) 16:16, 12 March 2021 (UTC)[reply]

A Barnstar for you!

The Tireless Contributor Barnstar
Thank you for helping edit Wikipedia and make the encyclopedia a better place for others. Thank you and keep up the good work. --ThanosYourGod (talk) 22:08, 12 March 2021 (UTC)[reply]

A barnstar for you!

The Tireless Contributor Barnstar
Thanks a lot for adding authority control to so many articles Paradise Chronicle (talk) 23:13, 5 April 2021 (UTC)[reply]

For improving Navseasoncats

What a Brilliant Idea Barnstar
…or rather, what a succession of brilliant improvements you have made to {{Navseasoncats}}! – Fayenatic London 19:58, 16 October 2021 (UTC)[reply]

Some authority control IDs which would be nice to see as an Australian

Dear Tom (@Tom.Reding:), I was hoping you might insert the following authority control ids into the authority control bar. Where they exist they would be useful for Australian editors and for readers anywhere, and if editors believe there are too many IDs, they can always exclude them. The IDs are: the NLA ID (NLA Trove people ID (P1315)), the DAAO ID (DAAO ID (P1707)), National Gallery of Victoria artist ID (National Gallery of Victoria artist ID (P2041)), Australian Dictionary of Biography ID (Australian Dictionary of Biography ID (P1907)), Auckland Art Gallery Artist ID (Auckland Art Gallery artist ID (P3372)). Cheers, MargaretRDonald (talk) 07:21, 20 August 2019 (UTC)[reply]

@MargaretRDonald: typically these requests are done at Template talk:Authority control, so I'll add this there with a ping.   ~ Tom.Reding (talk ⋅dgaf)  13:49, 20 August 2019 (UTC)[reply]
Thanks, @Tom.Reding: MargaretRDonald (talk) 21:28, 20 August 2019 (UTC)[reply]

Thank for your correction Adesanmi Idris Adewumi AA (talk) 10:35, 29 September 2019 (UTC)[reply]

Category:30 Rock (season 7) episodes

What is going on here? ―Justin (koavf)❤T☮C☺M☯ 20:29, 20 August 2019 (UTC)[reply]

 Fixed!   ~ Tom.Reding (talk ⋅dgaf)  20:36, 20 August 2019 (UTC)[reply]
Thanks! ―Justin (koavf)❤T☮C☺M☯ 20:50, 20 August 2019 (UTC)[reply]

Astronomical Unit

My changes are in line with Wikipedia MOS, as stated in the comments. The relevant discussion is on the astronomical unit talk page https://en.wikipedia.org/wiki/Talk:Astronomical_unit You must surely be aware that the internationally agreed symbol for astronomical unit is au, as decided by the IAU in 2012 and now used by MNRAS, ApJ, AJ, etc. The Wikipedia MOS page has adopted au as its preferred option, so presumably all Wikipedia entries will one day have to update to this. Why would you want to persist with an obsolete abbreviation? Please can you do me a favour and reinstate the changes I made, and save everyone else's time in the process. Thanks. Skeptic2 (talk) 22:10, 29 August 2019 (UTC)[reply]

@Skeptic2: then feel free to use au on astronomical unit. As for any other page, per MOS:UNITSYMBOLS, "Articles that already use AU may switch to au or continue with AU; seek consensus on the talk page", seek consensus on the talk page. Please also read Wikipedia talk:Manual of Style/Dates and numbers/Archive 157#Abbreviation for astronomical unit once again from last year, in its entirety. If you're concerned about 'wasting time', then you should seek other endeavors.   ~ Tom.Reding (talk ⋅dgaf)  22:36, 29 August 2019 (UTC)[reply]

Empty categories

Hello, Tom,

Do you expect to use these categories you've made (Category:User pages with BNC identifiers, Category:Miscellaneous pages with BNC identifiers, Category:User pages with NLR identifiers, Category:Miscellaneous pages with NLR identifiers, Category:User pages with RERO identifiers, Category:Miscellaneous pages with RERO identifiers, Category:Pages with BNC identifiers, Category:Pages with NLR identifiers, Category:Pages with RERO identifiers) or are they going to continue to be empty?

If you expect them to be sometimes filled, other times empty, please tag them with {{emptycat}} or they will likely be tagged and deleted. If they were created for some specific purpose and now you are done with them, I'll go ahead and tag them for future deletion. Just let me know. Thanks! Liz Read! Talk! 20:34, 1 September 2019 (UTC)[reply]

@Liz: these categories were created for their implementation in {{Authority control}}, and were somewhat quickly reverted due to their associated error categories (Category:Wikipedia articles with faulty BNC identifiers, Category:Wikipedia articles with faulty NLR identifiers, and Category:Wikipedia articles with faulty RERO identifiers) filling up rather quickly. It's unclear whether these issues were resolved, and I intend to investigate sometime this week. I'll tag them just in case so they don't get deleted. If I don't see a timely resolution possible, I'll speedy them. Thanks for the heads up.   ~ Tom.Reding (talk ⋅dgaf)  20:57, 1 September 2019 (UTC)[reply]

"Wikipædia" listed at Redirects for discussion

An editor has asked for a discussion to address the redirects Wikipædia and Wikipaedia. Since you had some involvement with the Wikipædia and Wikipaedia redirects, you might want to participate in the redirect discussion if you wish to do so. —Yours sincerely, Soumyabrata (talk • subpages) 11:35, 3 September 2019 (UTC)[reply]

Nomination for deletion of Template:Cite compare2

Template:Cite compare2 has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Izno (talk) 13:52, 5 September 2019 (UTC)[reply]

Wikipedia Awards

When you message me with a sarcastic comment such as "Are you new to Wikipedia", it becomes a issue. So don't send a template warning when you're the instigator. JudeccaXIII (talk) 16:01, 12 September 2019 (UTC)[reply]

@JudeccaXIII: Not sarcastic at all. Given your naive concerns there, I genuinely asked. Please refrain from personal attacks, and don't call other editors stupid.   ~ Tom.Reding (talk ⋅dgaf)  16:09, 12 September 2019 (UTC)[reply]
So I'm "naive"? It's your Barnstar that's on the line which would explain your current behaviour. — JudeccaXIII (talk) 16:18, 12 September 2019 (UTC)[reply]
@JudeccaXIII: No, your concerns there are naive, and betray a underlying misunderstanding and/or unawareness of the content creation/management aspects of Wikipedia. That's ok, and can be remedied. Stupidity can not.   ~ Tom.Reding (talk ⋅dgaf)  16:29, 12 September 2019 (UTC)[reply]
Whatever makes you feel better. — JudeccaXIII (talk) 16:31, 12 September 2019 (UTC)[reply]

Tom.Reding I would just like to apologize for the whole situation. My actions/responses were rude and unnecessary. — JudeccaXIII (talk) 18:47, 13 September 2019 (UTC)[reply]

Tom.Reding The consensus was in favor of keep, so I remastered it. See file. — JudeccaXIII (talk) 16:29, 15 September 2019 (UTC)[reply]
@JudeccaXIII: is there a v2.0 circle-slash symbol? That would be more appropriate than the red X (which looks more like a close-window button). If not, I was going to take care of it in the nearish future anyway.   ~ Tom.Reding (talk ⋅dgaf)  19:48, 15 September 2019 (UTC)[reply]
Tom.Reding I've updated the file. — JudeccaXIII (talk) 20:25, 15 September 2019 (UTC)[reply]

Bones part

Have we any bones where the diaphysis protruded in epiphysis.? — Preceding unsigned comment added by Sk Manowar Hossin (talk • contribs) 13:18, 15 September 2019 (UTC)[reply]

Bones

The parts of bones Sk Manowar Hossin (talk) 13:21, 15 September 2019 (UTC)[reply]

** Re: Your pending edit on Harcourt Street Station (which I approved)

I was just wondering (and I'm sure that your lacking this status is probably just some oversight) how come you don't have the Wikipedia "rollbacker" permission status which gives you approval or rollback rights? You've been editing Wikipedia pages way longer than I have and you probably know more about editing Wikipedia than I ever will. Cheers!

Beauty School Dropout (talk) 21:17, 21 September 2019 (UTC)[reply]

@Beauty School Dropout: thank you. I do a modest amount of anti-vandalism, so the stock undo & Twinkle options are good enough for me.   ~ Tom.Reding (talk ⋅dgaf)  21:47, 21 September 2019 (UTC)[reply]
@Tom.Reding: That make sense. Have a good rest of your day. Beauty School Dropout (talk) 23:47, 21 September 2019 (UTC)[reply]

Sept 25: WikiWednesday Salon NYC

September 25, 7pm: WikiWednesday Salon NYC

You are invited to join the Wikimedia NYC community for our monthly "WikiWednesday" evening salon (7-9pm) and knowledge-sharing workshop at Metropolitan New York Library Council in Midtown Manhattan. Is there a project you'd like to share? A question you'd like answered? A Wiki* skill you'd like to learn? Let us know by adding it to the agenda.

7:00pm - 9:00 pm at Metropolitan New York Library Council (8th floor) at 599 11th Avenue, Manhattan
(note this month we will be meeting in Midtown Manhattan, not at Babycastles)

We especially encourage folks to add your 5-minute lightning talks to our roster, and otherwise join in the "open space" experience! Newcomers are very welcome! Bring your friends and colleagues! --Wikimedia New York City Team ~~~~~

(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

dead-url migration

Hi, is there any need for doing this manually? I've been seeing Monkbot, who is a bot, do that task. – Uanfala (talk) 21:21, 23 September 2019 (UTC)[reply]

@Uanfala: yes.   ~ Tom.Reding (talk ⋅dgaf)  21:26, 23 September 2019 (UTC)[reply]
That's interesting. If I've correctly understood the linked discussion, you and others are making these edits by hand not because the bot doesn't do them, but because it does them too slowly? – Uanfala (talk) 21:31, 23 September 2019 (UTC)[reply]
Yes.   ~ Tom.Reding (talk ⋅dgaf)  21:33, 23 September 2019 (UTC)[reply]

New version of my typos tool

Hi Tom,

Thanks a lot for your efforts correcting typos on Wikipedia.

I just uploaded a new version of my tool: User:Uziel302/Typos. After adding the script to common.js, it allows correcting obvious typos in one click. This is meant for typos that occur less than 10 times in current dumps, so AWB isn't the answer. The process of uploading list of articles and settings to AWB is to hard to update. Will appreciate any feedback. Uziel302 (talk) 15:35, 27 September 2019 (UTC)[reply]

@Uziel302: I'm a bit wikioccupied elsewhere at the moment, but it looks like the limiting factor is creating the requisite custom typos list(s). Short of using WP:AWB/Typos, what you're doing seems like the easiest solution, as it/they can be updated easily to everyone using your script (I'll be using it soon enough). Making a helper script that creates typo entries for the custom/short list would be my only suggestion, but it looks like you're probably already doing that. Since there are no tools other than your own that that page has to interface with, then JSON, etc. formatting isn't necessary, and I like how you made it both human & machine readable.
A "rare" typo isn't necessarily grounds for exclusion in AWB, though, since many may have just been fixed in the meantime. If you have an older dump and find many instances of a typo, or the typo can be easily piggybacked onto an existing WP:AWB/T rule, then it would be good to add it (and keep it on your shortlist).   ~ Tom.Reding (talk ⋅dgaf)  16:38, 28 September 2019 (UTC)[reply]
The lists are created automatically by a short program I wrote. It includes 600K variations of popular words, excluding real words (currently based on Wikipedia and Wiktionary titles). Out of these 600K words I can't tell which will appear on the dumps, I just search and upload some of the output. Currently I have 35K typos to fix in English. In Hebrew Wikipedia we fixed over 14K typos with this tool, I have some options to widen the list of suspect typos. Uziel302 (talk) 19:09, 28 September 2019 (UTC)[reply]
Some of the frequent suspect typos in my scan, if you want to add some to AWB:
unveilled - 9  
receving - 9  
awll - 8
teching - 7  
coveres - 7  
appearanced - 7
adiation - 7
sceni - 6
unnotated - 6
predomnantly - 6  
featureed - 6  
I just uploaded: Wikipedia:Correct typos in one click/list by occurrence. Uziel302 (talk) 18:04, 30 September 2019 (UTC)[reply]

Race to grow the hottest pepper

Hello Tom, I have added zero in front of Red Savina in Race to grow the hottest pepper page table, because when you want to sort the peppers descending their SCU, this pepper appears as the hottest, but it is not true. This minor change fixes it. If you know another way to gain the same result, please implement it. Thanks — Preceding unsigned comment added by 147.33.10.154 (talk) 22:34, 28 September 2019 (UTC)[reply]

Fixed, using |data-sort-value="0,570,000"|.   ~ Tom.Reding (talk ⋅dgaf)  23:46, 28 September 2019 (UTC)[reply]

Re: new JWB rule for Regex Lookbehinds

Hi there, I'm continuing on your talk page as a reply to this question in which you pinged me, a long time ago. I haven't been active on this wiki for a long while and only now reading up on some messages left to me. So, to answer your question, yes, it would be technically possible to do that. However, I'm not sure in what way I should implement it to be absolutely 100% sure that the modified regex is still exactly the same. Considering that usually lookbehinds do have an effect on the expression they are included in, I am a bit hesitant to modify the expression to simply remove the lookbehind. I think it's safer to simply ignore any expressions that have a lookbehind, because not doing any replacements is better than performing an incorrect replacement.

Now, regarding that link listed in question 4: I find that quite interesting to read. I could try implementing a check that determines if the browser supports lookbehinds (which not all browsers do yet) and if so, keeps the lookbehinds completely intact. Not only would that avoid the issue of performing incorrect replacements because of the script editing the expression, it is probably also a bit easier to implement.

I'm curious to hear what you think. Joeytje50 (talk) 23:14, 9 October 2019 (UTC)[reply]

@Joeytje50: thank you very much for the reply. Pings to GoingBatty & Certes who where involved too.
The reason that conversation happened was b/c the next logical step, given the typo work we were all doing, and some of the other discussions we were having, was to introduce as many 'avoid self' look-behinds as were needed. Otherwise, the rules needlessly fire and clog up the 'typos fired' history tab in AWB (edit summaries are spared from this effect, I think?). Creating 'avoid self' look-behinds en masse would only be a good idea if JWB were unaffected or the work-around were trivial, or at least easy. If look-behinds may be coming soon to JavaScript is now true (or at least not on the perpetual horizon), then that would be the ideal scenario. I could try googling it myself, but I can only feel like that we be akin to trying to google-diagnose myself. Also I want to be surprised, either way.   ~ Tom.Reding (talk ⋅dgaf)  00:47, 10 October 2019 (UTC)[reply]
Oh, perhaps I misunderstood, is JWB run in your browser? I assumed it was a standalone application. I supposed if the largest # of JWB edits come from people using lookbhehind-supported browsers, then that would be acceptable? Can you run/create any user statistics to see if this is the case, if that's allowed?   ~ Tom.Reding (talk ⋅dgaf)  00:53, 10 October 2019 (UTC)[reply]
Yes, JWB is run entirely from the browser, but no, unfortunately I can't currently produce any usage statistics, and I fear it would be against the GDPR to start tracking usage statistics now without informing users. I'm not sure how the laws around that work, but I'm a bit hesitant to add tracking to it. If you happen to know what the rules about that are, I'd be happy to implement some tracking, and then I can let you know, but based on at least one user who posted some styling issues which I could only reproduce in Firefox, there are at least more than zero FF users, who are not supported it seems on https://caniuse.com/#search=lookbehind. So I could already implement supporting lookbehinds to allow Chrome users to perform more typo fixes, but I think until Firefox users are also supported, it would be unwise to include lookbehinds to every regex pattern, since that would exclude some users from performing typo fixes.
Also I'm a bit concerned this optimisation may in fact make the replacing of patterns slower as a whole. I'm not sure how exactly everything works behind the scenes, but the fact that lookbehinds are not supported universally yet, suggests to me that it's a relatively 'expensive' operation to perform. Although this may reduce the total amount of matches found and acted upon, I fear the regexes themselves may become significantly slower, undoing everything you were trying to optimise. I haven't done any research to these performance statistics though, so if you know more about this then I'm going to trust you on that. Joeytje50 (talk) 01:05, 10 October 2019 (UTC)[reply]
I've made a quick change to the Regex Typo Fixing script, which now supports lookbehinds for any browser that also supports it. So, as soon as every important browser supports lookbehinds, it is also supported by my RETF script. This also means that any expressions with lookbehinds will from now on work in up-to-date versions of Chrome and Opera. I'll add some information on the documentation page for that. Joeytje50 (talk) 01:28, 10 October 2019 (UTC)[reply]
@Smasongarrison: you've made by far the most efficiency improvements to WP:AWB/T - what are your thoughts on mass lookbehinds (only for cases where the rule could accidentally trigger on itself, not blanket-applied to all rules)?   ~ Tom.Reding (talk ⋅dgaf)  01:55, 10 October 2019 (UTC)[reply]
Honestly, right now I have zero thoughts on it. My new prof job has sucked up all my time. Smasongarrison (talk) 17:51, 10 October 2019 (UTC)[reply]
Can we enhance AWB to simply not make or log the change if the replacement text matches the replaced text? I've not explored the code but it may be something like
if find($text, $find) { $text = substitute($text, $find, $replace); log(...) }
which could become
$newtext = substitute($text, $find, $replace); if ($newtext != $text) { $text = $newtext; log(...) }
That may even be more efficient. By the way, I use Firefox. Certes (talk) 09:52, 11 October 2019 (UTC)[reply]
...The actual code, which of course is more complex than my pseudocode, seems to start at line 251 here. Certes (talk) 10:22, 11 October 2019 (UTC)[reply]
Well, given the possibility of a JS regex upgrade and the pretty big backlog of AWB pending tasks, I figured it'd be easier & faster to to just patch JWB in the meantime. But submitting a phab ticket is a good idea regardless of JWB regex transparency, as it might run faster if it's baked into the AWB program rather than each typo rule, and would decrease the size of the typo list.   ~ Tom.Reding (talk ⋅dgaf)  13:07, 11 October 2019 (UTC)[reply]
I'm not an experienced phab user but if anyone else wants to make a request, adding code to these currently blank lines of RegExTypoFix.cs should work:
256 string oldText = articleText;
258 if (oldText != articleText) {
278 }
!= may be the wrong string comparison operator (C# has four, and I've never used the language) and the formatting would need adjustment. Certes (talk) 14:09, 11 October 2019 (UTC)[reply]

Oct 23: WikiWednesday Salon NYC

October 23rd, 7pm: WikiWednesday Salon NYC

You are invited to join the Wikimedia NYC community for our monthly "WikiWednesday" evening salon (7-9pm) and knowledge-sharing workshop at Metropolitan New York Library Council in Midtown Manhattan. Is there a project you'd like to share? A question you'd like answered? A Wiki* skill you'd like to learn? Let us know by adding it to the agenda.

7:00pm - 9:00 pm at Metropolitan New York Library Council (8th floor) at 599 11th Avenue, Manhattan
(note this month we will be meeting in Midtown Manhattan, not at Babycastles)

We especially encourage folks to add your 5-minute lightning talks to our roster, and otherwise join in the "open space" experience! Newcomers are very welcome! Bring your friends and colleagues! --Wikimedia New York City Team 05:33, 22 October 2019 (UTC)

(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

Odontasaurs

I know Wikipedia is not a dating site, but you have to have the sexiest user page ever. Not sure if it was 2 master's degrees or admitting to having OCD, but you are exactly my kinda guy. >sigh< Please don't be a troll. In my head you look really hot. — Preceding unsigned comment added by SeaBeeDee (talk • contribs) 13:22, 24 October 2019 (UTC)[reply]

Margaret Magennis, Viscountess Iveagh

Tracked in Phabricator
Task T236729

Dear Tom, if I may call you so. I am a beginner in Wikipedia and lack your impressive track record and reputation as a top Wikipedian. I am puzzled by some of the edits you made on the article Margaret Magennis, Viscountess Iveagh on 23 October 2019, using AWB as it seems. Thank you for all the good and useful corrections, which are surely highly appreciated. I have to thank you in particual for fixing the self-link that I had introduced by copying the Family tree from another article. I will try to be more careful in the future. However, please allow me to ask you about two changes that look to me as changes not to the better but to the worse. The one is br to br/, the other the correction of a date format inside a quotation.

  1. br. In HTML4 and HTML5 the form is br. XHTML required "br /" (https://www.w3schools.com/tags/tag_br.asp). It seems that at same stage in the past Wikipedia's Text Editor's syntax highlighting could not cope with br and needed a closure, but now the syntax highlighting seems to have no problem with br. So why change it. Are you not perhaps using an old version of AWB?
  2. Date format in quotation. It is of course a good idea to standardise the date formats used in Wikipedia, but surely odd formats found in quotations from sources should, I think, be left as they are. However, your intervention on the article removed a comma from the date of the Battle of Landen from a quote from a book by Lodge published in 1798. This quotation is the argument of the "ps" parameter of the "sfn" template. Look for: sfn|Lodge|1798|p=...|ps=: "Lady Honora ... Landen, 29 July, 1693, ...". The comma between July and 1698 was removed. Would you not agree that this should not have happened?

With many thanks and sorry to take so much of your time. Johannes Schade (talk) 17:09, 26 October 2019 (UTC)[reply]

@Johannes Schade: here is the edit, for easier reference.
  1. <br/>: No, the text editor's syntax highlighting does not cope with unclosed <br>s (I have highlighting active now, and have just tested it in this edit window). Regardless, this is also a lowest-priority lint error, which is why I piggyback it on more significant changes.
  2. Yes, quoted text, {{sic}}'d text, etc. should be left as-is. The commas were removed via WP:GenFixes, and was not caught by me due to the length of the quote. I'll create a {{Phab}} ticket to fix this.
Thank you for bringing it to my attention.   ~ Tom.Reding (talk ⋅dgaf)  17:40, 26 October 2019 (UTC)[reply]
Dear Tom, thanks a lot for your effort. Johannes Schade (talk) 17:53, 26 October 2019 (UTC)[reply]
 Tracked in T236729.   ~ Tom.Reding (talk ⋅dgaf)  19:18, 28 October 2019 (UTC)[reply]

Draft:Blerf

Hello, Please is this draft Draft:Blerf, that I created "OK" Wiziesan (talk) 21:09, 27 October 2019 (UTC)[reply]

@Wiziesan: I ran my 'common errors' script over it and found nothing wrong, and no typos. You should rename it to Biographical Legacy and Research Foundation. For a more detailed vetting, I believe the WP:Teahouse is your best resource.   ~ Tom.Reding (talk ⋅dgaf)  21:17, 27 October 2019 (UTC)[reply]

Ok thanks sir Wiziesan (talk) 21:20, 27 October 2019 (UTC)[reply]

CS1 author list

Hi Tom, is this ability to correct CS1 author list, as User:Tom.Bot did here a standard part of WP:AWB? As I mistakeningly added a number of 'authors=' references myself, I'd like to go back and correct my edits. I have AWB access, any information would be welcome. Regards, Sun Creator(talk) 21:44, 27 October 2019 (UTC)[reply]

@Sun Creator: unfortunately, no, and I don't see it being part of WP:AWB except for the 1 or 2 most obvious cases. Instead, over the years (~10, wow), I've created a list of ~1200 regex rules and some C# code to process the many multiple-author/editor/translator/etc. variants, wikilinks-as-authors, and other common errors, which does, still, come across new user-input-error variants. If I see enough of one, and it isn't terribly complicated to fix, I put it in. Category:CS1 maint: multiple names: authors list (73,462) is at a not-too-unmanageable 31,363. Also, at the time, I didn't notice I was logged in as Tom.Bot; I should've switched before making those edits.   ~ Tom.Reding (talk ⋅dgaf)  22:14, 27 October 2019 (UTC)[reply]

-ictive

Sorry to be a stalker but I think this change should work if you just omit $1: substitution retains text matched with (?<=). I'd do this myself but I expect you have a testbed for it set up and I don't. Certes (talk) 17:03, 31 October 2019 (UTC)[reply]

@Certes: yes, it probably would, but it would make the edit summary less useful by not including the whole word, i.e. icitve → ictive, which is what I think almost all rules follow. If you don't mind this, or at least don't mind it for the slowest typo rules, in favor of the performance gain, please mention it at WT:AWB/T#The 76 slowest typos. Personally, I think it's worth it for these extremely slow 3-10 stdev rules, but I don't want to assume everyone would be ok with that.   ~ Tom.Reding (talk ⋅dgaf)  17:42, 31 October 2019 (UTC)[reply]

Last White Christmas page issues

Hi Tom, I hope I have solved the issues on the page you reported to me. Could you re-evaluate the page? Ciao e grazie--Massimoimpulse (talk) 17:13, 31 October 2019 (UTC), Massimo[reply]

 Done, looks good.   ~ Tom.Reding (talk ⋅dgaf)  17:50, 31 October 2019 (UTC)[reply]
Thanks! I worked a lot on it. Who can cancel the notices? I could do it, I believe according to the regulation, even personally. But it would seem to me that it was better for someone to remove it. What do you suggest me? Another question, if I can? If a page in English is correct (approved) can it be translated into another language without the risk of raising a doubt about encyclopedicity? If a page is encyclopedic for a language: is it for all? Ciao e grazie --Massimoimpulse (talk) 22:03, 31 October 2019 (UTC)[reply]
@Massimoimpulse: the quantity of sources has certainly improved (I did not check their quality). Re WP:GNG: I'm afraid this is out of my depth. I don't feel comfortable removing that notices since I don't have the time nor the interest in checking them. Please bring this up at the WP:Teahouse, where someone more willing & experienced than I can help you. Re interlanguage wiki translation: each wiki (I think) sets their own guidelines, so the WP:Teahouse again would be your best resource.   ~ Tom.Reding (talk ⋅dgaf)  22:22, 31 October 2019 (UTC)[reply]
@Tom.Reding:Thanks for everything! I'll do as you suggested. Ciao
@Tom.Reding: Ciao Tom I remember that the names of the bands that played at the concert had been removed. Why? Only one is still active (Raw Power). Can I put the names back? It seems to me a useful piece of information (encyclopedic) and that can favor the tracing of the page. Ciao e grazie, MassimoMassimoimpulse (talk) 21:59, 7 November 2019 (UTC)[reply]
@Massimoimpulse: as far as the text & content of this page goes, and there's a reference, sure. Those bands probably don't need to meet WP:GNG just to be mentioned; whether they should be made into red wikilinks is another matter.   ~ Tom.Reding (talk ⋅dgaf)  22:09, 7 November 2019 (UTC)[reply]

Category:Automatic taxobox cleanup

Someone must have messed up one of the taxonomy templates high up in the 'dinosaur hierarchy', which was then corrected, but left a huge number of articles in Category:Automatic taxobox cleanup. Real problems can't be found and fixed while all of these sit in the category. A null edit removes those that shouldn't be there. Is this something you can automate? Peter coxhead (talk) 10:27, 1 November 2019 (UTC)[reply]

 Working   ~ Tom.Reding (talk ⋅dgaf)  12:46, 1 November 2019 (UTC)[reply]
 Done!   ~ Tom.Reding (talk ⋅dgaf)  13:13, 1 November 2019 (UTC)[reply]
Many thanks (yet again!). Peter coxhead (talk) 14:48, 1 November 2019 (UTC)[reply]
What's the best way to do bulk null edits? They are also handy when pages still record bad links removed by a template fix. Currently I use JWB with no regex (fixing typos as I pass) but that's not ideal for more than about 100 pages. Certes (talk) 13:31, 1 November 2019 (UTC)[reply]
I use AWB to only prepend {{subst:null}} to a page, which eventually evaluates as no change, but first has to be parsed, so it triggers a page refresh. You might be able to do this with JWB, if not natively then via regex (i.e. find the first or last wikitext character and put the subst before it), but I've never used JWB so I'm just spitballing.   ~ Tom.Reding (talk ⋅dgaf)  13:50, 1 November 2019 (UTC)[reply]

UCLA School of Nursing

Can you explain your UCLA School of Nursing edits -- specifically why you changed apostrophe symbols to inch symbols?

I found this on Wikipedia about prime symbols: Although similar in appearance, the prime symbol should not be confused with the apostrophe ( ’ or ' ), single quotation mark ( '  or  ‘  or  ’ ), acute accent ( ´ ), or grave accent ( ` ).

thanks Rgale417 Rgale417 (talk) 23:09, 5 November 2019 (UTC)[reply]

@Rgale417: MOS:'.   ~ Tom.Reding (talk ⋅dgaf)  00:46, 6 November 2019 (UTC)[reply]
@Tom.Reding Ahhh...thank you very much! MOS answers a lot of questions for me. (is dgaf a message to me?) Rgale417 Rgale417 (talk) 23:58, 6 November 2019 (UTC)[reply]
@Rgale417: you're welcome. WP:Don't-give-a-fuckism is a part of my signature, and a way of life.   ~ Tom.Reding (talk ⋅dgaf)  00:02, 7 November 2019 (UTC)[reply]

Category:Taxobox articles missing a taxonbar

Category:Taxobox articles missing a taxonbar has 395,749 pages in it, but my (admittedly small) attempt at sampling shows that these articles do in fact have a taxonbar. Is there something I'm not getting? Abductive (reasoning) 08:24, 12 November 2019 (UTC)[reply]

@Abductive: thank you for checking. I've undone a recent change and it's now clearing out: Category:Taxobox articles missing a taxonbar (0).   ~ Tom.Reding (talk ⋅dgaf)  12:47, 12 November 2019 (UTC)[reply]
Thanks. I'm just glad I figured out who to ask.... Abductive (reasoning) 15:27, 12 November 2019 (UTC)[reply]

Sir Robert de Quincy (born c.1140-died c.1197) and Saer de Quincy, 1st Earl of Winchester (c. 1170 – 3 November 1219)

I was searching for the de Quincy line of my family and finally found Robert, son of Saher. I clicked on Saher and went down to Robert again. Robert has a son Saer and when I clicked on him it took me back to Robert's father. We have a circle going and it needs to be corrected but I didn't know how to tell you this until I found this section. You do great work for wikipedia and I know you know how to correct the link. Thank you, Crookedeye (Crookedeye (talk) 21:41, 12 November 2019 (UTC))[reply]

@Crookedeye: please tell me the page and the exact link that's the problem.   ~ Tom.Reding (talk ⋅dgaf)  14:30, 13 November 2019 (UTC)[reply]

The page would be Robert de Quincy 1st line is Sir Robert de Quincy (born c.1140-died c.1197), Justiciar of Lothian was a 12th-century English and Scottish noble. The link is for his father 1st line under Life Quincy was a son of Saher de Quincy and Matilda de Senlis.[1 AND the link for his son under Marriage and Issue 2nd line Saher de Quincy (died 1219), married Margaret de Beaumont, had issue.

Both of these links go to the same person, which is his son per birth and death dates. I'm pretty sure you probably meant some special number or ??? when you wanted the links but I'm not all that great with computer talk. Thank you, Crookedeye (talk) 09:58, 14 November 2019 (UTC)[reply]

Saturday Nov 16: Wikipedia Asian Month Edit-a-thon @ Metropolitan Museum of Art

Saturday November 16, 12:30 pm - 4:30pm: Metropolitan Museum of Art Edit-a-thon

The Wikipedia Asian Month Edit-a-thon @ The Met will be hosted at the Metropolitan Museum of Art on Saturday November 16, 2019 in the Bonnie Sacerdote Classroom, Ruth and Harold D. Uris Center for Education (81st Street entrance) at The Met Fifth Avenue in New York City.

The museum is excited to work with Wikipedia Asian Month for the potential to seed new articles about Asian artworks, artwork types, and art traditions, from any part of Asia. These can be illustrated with thousands of its recently-released images of public domain artworks available for Wikipedia and Wikimedia Commons from the museum’s collection spanning 5,000 years of art. The event is an opportunity for Wikimedia communities to engage The Met's diverse Asian collections onsite and remotely. Asia Art Archive will host a sister event in Hong Kong next week.

12:30 pm - 4:30 pm in Bonnie Sacerdote Classroom, Uris Center for Education
81st Street entrance, Metropolitan Museum of Art, 1000 Fifth Avenue


And there will be sandwiches and Wiki-Cake!

Thanks, and hope to see you there! --Wikimedia New York City Team 16:46, 14 November 2019 (UTC)

(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

ArbCom 2019 election voter message

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2019 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:12, 19 November 2019 (UTC)[reply]

Nov 20: WikiWednesday Salon NYC

November 20, 7pm: WikiWednesday Salon NYC

You are invited to join the Wikimedia NYC community for our monthly "WikiWednesday" evening salon (7-9pm) and knowledge-sharing workshop at Metropolitan New York Library Council in Midtown Manhattan. Is there a project you'd like to share? A question you'd like answered? A Wiki* skill you'd like to learn? Let us know by adding it to the agenda.

7:00pm - 9:00 pm at Metropolitan New York Library Council (8th floor) at 599 11th Avenue, Manhattan

We especially encourage folks to add your 5-minute lightning talks to our roster, and otherwise join in the "open space" experience! Newcomers are very welcome! Bring your friends and colleagues! --Wikimedia New York City Team 16:17, 19 November 2019 (UTC)

(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

Google Code-In 2019 is coming - please mentor some documentation tasks!

Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at the English Wikipedia.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to [email protected], so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at [email protected].

Thank you!

--User:Martin Urbanec (talk) 21:58, 23 November 2019 (UTC)[reply]

New Page - related to Helmut Veith

Hi! Jobe well done when it comes to the article on Helmut Veith. I am mapping Austrian computer science scene. I have created a new wikipedia article about Vienna Center for Logic and Algorithms, which was co-founded by Helmut Veith (1971-2019). The article is still in review, and it needs editors. Do you know someone who could review the article? Best

A barnstar for you!

The Original Barnstar
Jobe well done when it comes to the article on Prof. Helmut Veith (1971-2016). Terrenus (talk) 14:48, 26 November 2019 (UTC)[reply]

Speedy deletion nomination of Category:2010s Thai aircraft

A tag has been placed on Category:2010s Thai aircraft requesting that it be speedily deleted from Wikipedia. This has been done under section C1 of the criteria for speedy deletion, because the category has been empty for seven days or more and is not a disambiguation category, a category redirect, a featured topics category, under discussion at Categories for discussion, or a project category that by its nature may become empty on occasion.

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. UnitedStatesian (talk) 04:05, 13 December 2019 (UTC)[reply]

A number of pages have references with links of form |url=http://oldredlist.iucnredlist.org/details/8784/0. This is the backup site the IUCN created when they updated their website. They have now closed this site. However, they do now have redirects for the old urls (e.g. |url=http://www.iucnredlist.org/details/8784/0) or, more accurately, a system that creates redirects shortly after someone gets a failed link.

Anyway, there are 1435 pages using oldredlist links. Is it possible for you to change the http://oldredlist.iucnredlist.org to https://www.iucnredlist.org. This would fix most of the dead links left over from the IUCN website update. It would have been easier if they'd created the redirects in the first place, instead of creating the need to changing to oldredlist and back again.

Thanks in advance for any help you can give.   Jts1882 | talk  11:54, 15 December 2019 (UTC)[reply]

@Jts1882: sure can, next day or 2 probably.   ~ Tom.Reding (talk ⋅dgaf)  13:54, 15 December 2019 (UTC)[reply]
@Jts1882: are you sure that simply replacing http://oldredlist.iucnredlist.org to https://www.iucnredlist.org is the correct action?
I've been spending my morning fixing {{cite iucn}} template because of this change to Module:Iucn. Because I'm doing that, I added a test probe to my script to show oldredlist urls. I found one in House sparrow § Habitat (here):
http://oldredlist.iucnredlist.org/details/149100
which I changed to:
https://www.iucnredlist.org/details/149100
Neither of these work. So, I searched and found:
https://www.iucnredlist.org/species/103818789/155522130
which is a distinctly different url from either of the other two. This then leads me to wonder: is brute-force replacement of 'old' with 'new' a good and correct idea?
—Trappist the monk (talk) 16:28, 15 December 2019 (UTC)[reply]
From Ophisternon bengalense § Sources:
[http://oldredlist.iucnredlist.org/details/166410/0 Ophisternon bengalense] → Ophisternon bengalense
[https://www.iucnredlist.org/details/166410/0 Ophisternon bengalense] → Ophisternon bengalense
Neither work but search gives this url:
https://www.iucnredlist.org/species/166410/1131667
—Trappist the monk (talk) 17:18, 15 December 2019 (UTC)[reply]
(edit conflict)
@Trappist the monk:. I think it is the best approach. A brief summary of the changes and my reasoning.
  • The redlist website used to use url's like http://www.iucnredlist.org/details/149100 and http://www.iucnredlist.org/details/149100. The 2008 assessment for the sparrow article was added sometime in 2009 using the latter url. So this was the link added by a editor to verify the information added to the article.
  • Two or three years ago the IUCN updated their website using a new URL format, without using redirects. This cause all the links to IUCN references to be dead. The IUCN created oldredlist version at this time.
  • Unfortuately, these new urls couldn't be worked out from the id alone. However, it was possible if there was an electronic page number. I created the {{cite iucn}} at that time to try and facilitate conversion by generating the new urls from the page number. Using this template had to be done one reference at a time. Around the same time someone mass converted the old links to use the oldredlist links.
  • Earlier this year the IUCN closed the oldredlist subdomain, meaning all these converted links were now dead.
  • At some point they have put in a system that generates links from the old URLs to the new ones. We can only guess why they didn't do this at the time of the changeover. This means many of the orginal links now work again, which is why I propose changing them back.
  • The sparrow one doesn't work because it is a new assessment with a new ID number. But if you convert the link at Reindeer from http://oldredlist.iucnredlist.org/details/29742/0 (Reindeer) to https://www.iucnredlist.org/details/29742/0 (Reindeer), the latter is redirected to the new style url, https://www.iucnredlist.org/species/29742/22167140 (Reindeer). Curiously it didn't when I first tried it this morning but did when I retried it a few hours later. It seems the links are created after getting a failed attempt to reach the old URL.
In short, the oldredlist urls are dead. These were not the ones originally added to the article by editors, but the result of a mass conversion. The orginal urls now work in many cases, if still the latest assessment, so I think the conversion back is appropriate. Where there is a new assessment, these links will be dead but they will be the ones added by a living editor rather than a dead link to oldredlist.   Jts1882 | talk  17:21, 15 December 2019 (UTC)[reply]
I am not going to pretend that I understand all of what it is that you wrote. If the old-url and the new-versions-of-the-old-url (the new-old) are redirected to some other url (new-new), wouldn't it be better to have Module:Iucn add a maintenance category so that they can be fixed for good an all and so that there is but one kind of url pointing to the current assessment? Surely you do not believe that iucn will maintain these redirects indefinitely so isn't it prudent to know where both forms of the 'old' and 'new old' urls are and spend the time and effort to update them to the 'new new'?
—Trappist the monk (talk) 18:09, 15 December 2019 (UTC)[reply]
A maintenance category for any old-style url in {{cite iucn}} is a good idea, but my request is not about {{cite iucn}} references, which can be handled by the module. Only 31 of the "oldredlist" occurences use that template. That leaves about 1400 using {{cite web}} or {{cite journal}}. The oldredlist subdomain no longer exists so all of those are dead links. A large majority of them do redirect if converted to the original url. I estimate this would fix over a thousand dead links. Ideally they would be updated to the new style urls, but that needs to be done manually or with a bot that can search the IUCN API.   Jts1882 | talk  08:45, 16 December 2019 (UTC)[reply]
So then the task is:
when iucn url of any form appears in {{cite web}} or {{cite journal}}
convert these templates to {{cite iucn}}
remove |journal= and |work= when these name the redlist
when |page=e\.T(\d+)A(\d+) or |doi=10\.2305/IUCN[^\|\}]+T(\d+)A(\d+)\.en
convert old-url to current-form-url
else:
convert old-url to original-url
Right?
I have tweaked Module:Iucn to unconditionally add |publisher=[[IUCN]] and conditionally add |doi-access=free when |doi= is present and correct.
—Trappist the monk (talk) 12:44, 16 December 2019 (UTC)[reply]
Yes, I think that would be excellent and far better than my limited plan. One concern with converting all {{cite web}} and {{cite journal}} citations with a redlist url is that not all will be referencing species assessments. There is some addition technical information on the assessment process, conservation categories and conservation plans. Species assesments should have urls with "iucnredlist.org/details/" (old style) or "iucnredlist.org/species/" (new style).   Jts1882 | talk  13:18, 16 December 2019 (UTC)[reply]
I have a script that I think does what you want. Here are the first 10 edits:
In Acaena_exigua, this {{cite journal}} does not have |url= but does have |doi=. This type of citation should also be converted to {{cite iucn}} and I will add that functionality.
Also from Acaena_exigua the original:
{{cite journal |author=Gon, S.M. |author2=Keir, M. |author3=Kwon, J. |author4=Weisenberger, L. |author5=Sporck-Koehler, M. |author6=Chau, M. |last-author-amp=yes |title=''Acaena exigua'' |journal=[[The IUCN Red List of Threatened Species]] |volume=2016 |page=e.T44072A101442020 |publisher=[[IUCN]] |date=2016 |url=http://oldredlist.iucnredlist.org/details/44072/0 |doi=10.2305/IUCN.UK.2016-1.RLTS.T44072A78765906.en |access-date=10 November 2017}}
in the above, the identifier in |page= is different (errata version) from the identifier in |doi= (original 2016 assessment). My script uses whichever of |doi= or |page= follows |url= preferring |doi=. This may be the wrong philosophy. Since the doi appears to automatically redirect to the most current assessment, when the assessment part of the identifiers differs what to do? I think that lower assessment numbers indicate older (I have not proven that, but it seems likely) so:
doi == page; use either
doi > page; use page?
doi < page; use doi?
For now, I've instructed the script to skip when doi != page.
At present, iucn urls must be in cs1|2 or {{cite iucn}} templates and must not have |archive-url= with an assigned value. I'm wondering if such templates, where |doi= and/or |page= is present and correct, should be stripped of the archive parameters and modified as if they were not present. Because the script skips these templates, this topic can be deferred to a later date.
Tom, if you would prefer that this conversation continue elsewhere, just say so ...
—Trappist the monk (talk) 18:40, 16 December 2019 (UTC)[reply]
No problem at all! I don't mind - this is all relevant for me (though I've yet to read through this due to limited time).   ~ Tom.Reding (talk ⋅dgaf)  15:34, 17 December 2019 (UTC)[reply]
@Trappist the monk: Those examples all create citations with valid links where possible. The exceptions are when there is no redirect for an old style url (which seems to be for more obscure taxa) or when the taxon id has been replaced (e.g. the house sparrow which was split into two species with new numbers). But these currently give dead links anyway. A few comments and questions:
  • The electronic page number should be used to generate the new-style when both it and the doi are available. The page number goes to web page where the citation was taken (original or update), which we can assume is the page that was actually read by the editor. The doi number refers to the original version so a new-style url generated from it would link to the old version, although following the doi link takes you to the most recent version. Most updates are errata, but they could involve information that is being cited, so it’s better to use the electonic page number for the url, as that should link to the page the citation was taken from.
  • Should the bot be creating the new-style urls or should that be left to the module? If the bot just restores old style urls (removing oldredlist), the module can create the links and set tracking categories (which I see you’ve being creating).
  • There is one other option for old-style urls, using an IUCN API link (this is used by the {{taxonbar}} as that is how Wikidata is set up). In the case of Ophisternon bengalense (Bengal mud eel) this now gives a valid link, whereas the old-style url link doesn’t pick up this redirect (which is odd). However, when the taxon id has been replaced this returns an error message in JSON format, e.g. for the house sparrow before its species split. I don’t think this is appropriate, but this can be implemented later in the module if desired.
  • I chose to use the |trans-title= for |amended= because this appears after the linked title. If |type= is used it appears after the |journal= which suggests the whole redlist has been amended rather than the particular assessment.
  • If there is an electronic page number that can generate a new style url, I see no reason to keep the archive. The archive might give the wrong impression about the current validity of the reference. The archive is there due to a techical issue with the urls, not because the information was removed for some reason.
I see I have some work to do to bring myself up to date on the tracking categories. I will comment later on the module talk page.   Jts1882 | talk  08:35, 18 December 2019 (UTC)[reply]
Ok.
  • My script does use |page= to create a new-form url when |page= and |doi= are both present and both the same. It is easy enough to add another case to create a new-form url from |page= when it differs from |doi=. The script creates a new-form url from |page= when |doi= is missing or empty. Similarly, when |doi= has a value but |page= is empty or missing, the script creates a new-form url from |doi=. But, I've been wondering about that last case. The script also converts |url=http://doi.org/10.2305/IUCN.UK... to |doi=10.2305/IUCN.UK... so perhaps it is better when there is old-form url and |doi= to simply remove |url=.
    • A variant of this that we haven't discussed is {{cite iucn}} templates with |id=TTTT/AAAAA. I presume that if such |id= parameters are encountered, presuming proper form, the |id= value can be used to create a new-form url in the absence or invalidity of |page=, right? Or probably best, because the module creates new-form url from |id=, when old-form url exists with properly formatted |id=, delete |url=.
  • I'm not writing a bot; 1500-ish pages isn't worth the time it would take to get through WP:BRFA. But, to answer what I think is the essence of your question, I think that some script or other should be rewriting the wikitext templates because rendered citations that differ from the source data are confusing to editors (the doi resolver for iucn dois is one such example – reader clicks on doi 1234 expecting to go to doi 1234 but ends up at doi 5678; a poor decision on the part of iucn in my opinion because a doi is supposed to be permanent link to a specific source).
  • iucn api is outside the capability of an awb script and I don't think that we should be populating |url= with api calls
  • Yeah, I get why you are misusing |trans-title=. Misuse of template parameters, no matter how well-meaning, is still misuse. We might do as iucn does and add specific text to the citation title (see house sparrow). In reading that title, Passer domesticus (amended version of 2018 assessment), I wonder if |amended= is quite the right parameter name. That tense might be misleading as in "amended in YYYY" (2019 to produce the 2019 assessment). Perhaps |amends= as in "amends YYYY assessment". So, for house sparrow one might write:
    {{cite iucn |title=''Passer domesticus'' |amends=2018 |date=2019 |id=166410/1131667}}
    "Passer domesticus (amended version of 2018 assessment)". IUCN Red List of Threatened Species. 2019. 2019. {{cite iucn}}: error: title has extraneous text, no identifier (help)
  • I'm happy to remove archives to old-form urls and will implement that.
—Trappist the monk (talk) 12:51, 18 December 2019 (UTC)[reply]
Getting back to |amended=, I have to wonder if we really care? Do we? At present, |amended= appears to used in only six articles.
—Trappist the monk (talk) 13:00, 18 December 2019 (UTC)[reply]
You may be right about dropping |amended=. I probably added all the six uses as I was trying to follow the recommended IUCN citation style and didn't like that being part of the linked text. It's not essential to the citation (and perhaps implies major change rather than mostly errata) and is prominent on the page when anyone follows the link.
I agree with deleting the old style urls when there is a suitable id, electronic page number or doi. Is the new style URL a necessary parameter given that the electonic page number is the key parameter.
I'm not sure how often there is a new style id (i.e. taxonID/assessment). I was adding that because {{IUCN}} uses |id= (the old-style ID) to create old-style URLs, some of which work and some which don't. The reason I added the aliases for |assessor= parameters was looking towards using the module for the template. So I would favour also handling old-style IDs and using them to create old-style URLs when there is not page or doi.   Jts1882 | talk  13:30, 18 December 2019 (UTC)[reply]
I don't know what old-style IDs look like. the only ids that I can remember seeing have the form that I used above in my |amends= example: |id=166410/1131667 which is the same form as is used in the new-form url. I don't think that |url= in wikitext is necessary when there is one of |page(s)=, |id=, |doi= (all properly formatted). The module can (does) create |url= from |pages= and |id=.
I have been recently thinking about changing the module so that it will also create |url= from the identifier in |doi= so that the rendered citation title links to that specific assessment (because of iucn's peculiar notion of how dois should work). This would make the need for |url= in the wikitext unnecessary (maint cat and message for what becomes extraneous |url=). Because of that thinking, I'm also thinking about changing the script to remove |url= when there is |page(s)=, |id=, |doi= (all properly formatted).
That whole assessor-alias thing could be done better but I don't think that we should worry about that right now. First settle on getting the url-issues resolved
—Trappist the monk (talk) 15:44, 18 December 2019 (UTC)[reply]
By old-style id I mean a simple ID number that is used in old-style urls of form https://www.iucnredlist.org/details/ID/SUFFIX, e.g. https://www.iucnredlist.org/details/166410/0, where the zero suffix refers to a global assessment and other numbers refer to regional assessments.
The new style IDs use the same taxon ID with the addition of an assessment element as suffix in the form https://www.iucnredlist.org/species/ID/SUFFIX, e.g. https://www.iucnredlist.org/species/166410/1131667.
It might have been clearer to use taxonID for the common element and refer to old style suffixes (0-9, for global and regional assessments) and new style suffixes (unique numbers for versions of assessments).   Jts1882 | talk  16:13, 18 December 2019 (UTC)[reply]
Those old-style suffixes in urls are replaced with new-style suffixes when a url is converted to the new-form. Old-style suffixes are always single digit? If so then my script should not make a url from a single-digit suffix.
But, |id= is pretty rare in {{cite iucn}} templates; (this search finds 7 – of which 6 are malformed (no suffix) which is caught by the module and an error message emitted).
What I want to know is: should we migrate away from |url= in wikitext and have the module create the link to iucn from |page=, |id=, |doi= (in that order I think)? I would say yes.
—Trappist the monk (talk) 17:13, 18 December 2019 (UTC)[reply]
Agreed. The url is not a needed parameter. Also agree on order. The page unambiguously provides the numbers for the url, the id would be taken from the url by the editor (but see next points), while using the doi number would always point to the original version (not ideal).
Looks like those malformed ids are the taxonID part (first component) of the new-style two component ID. I checked the first three and the |id= matched the first component of both the |page= and |doi=. I suspect they are parameters left over when converting a {{IUCN}} template to {{cite iucn}}. The properly formed one is one I converted to {{cite iucn}} a few days ago and left the |id= from the {{IUCN}} template.
So on second thoughts, |id= is unnecessary in {{cite iucn}}. It should be ignored and only give an error message when they don't match with |page= and/or |doi=. The only reason for keeping it would be to convert {{IUCN}} templates in future, but for now it serves no use.   Jts1882 | talk  18:24, 18 December 2019 (UTC)[reply]
Ok, module tweaked to create urls from identifiers in the order listed above. I've tweaked my script to remove old-, original, and new-form urls when there are properly formed identifiers. When properly formed identifiers are not available, old-form urls are converted to original-form urls (the module categorizes these). I am of a mind to retain support for |id= at least for the nonce and revisit when the dust settles. I think that I am ready to start running the script.
—Trappist the monk (talk) 21:49, 18 December 2019 (UTC)[reply]
Looking at the errors, I have a couple of comments:
  1. When there is a mismatch between the doi and url this is not necessarily an error. This is correct when the url points to an amended assessment. The url and page should, match but the doi will still have the numbers for the original version. Examples at Pardofelis (refs 8 & 9)
  2. When there is a mismatch between the page and url this is an error The correct url should match the page id numbers, so it links to the updated page.. At the moment the url is being used for the link. Example at Honey badger (ref 1).
I've also noticed that new IUCN assessments are not including the doi in the citation (e.g. leopard). This could be a sign that they realise that dois that change the destination defeat their purpose.   Jts1882 | talk  11:53, 19 December 2019 (UTC)[reply]
iucn are not doing us any favors by their peculiar handling of doi identifiers. I think that the errors are correct because only an editor can determine how the citation should be written. Because this is a mess, we should probably refine the template's documentation to better explain why the message exists and what it means. This lets editors determine for themselves the best course of action. In your Pardofelis ref 8 for example:
It is for knowledgeable editors to determine what to do when these differences occur.
I hope that you are right and that iucn do realise that dois that change the destination defeat their purpose.
—Trappist the monk (talk) 13:57, 19 December 2019 (UTC)[reply]
The Pardofelis citation is written correctly. The editor must have been looking at a revised assessment, where the listed citation and the page url will have the assessment number of the revision. An amended assessment will always have a mismatch between the electronic page number (and its associated url) and the doi by design (the IUCN's peculiar design). The doi contains the assessment number of the original assessment, which can't be what the editor was looking at as it has a different page number and url. If both page and url match and differ from the doi, we can be certain that the revised assessment is the correct one.
When there is a mismatch between, the page and url parameters, then this is an editor error. If the url and doi numbers agree and the page parameter has a different value then we can be fairly sure that the page parameter contains the correct information. An editor can only get the new number from the revised assessment.
This is why I think we can rely on the page number parameter. The first case is not an error in the way the citation template was written (its due to the iucn's design). The second case is an editor error, but we can be fairly sure they have looked at an amended assessment (to get the new page number). I don't think it necessary to output the error on the page, a warning and tracking category should do.   Jts1882 | talk  14:28, 19 December 2019 (UTC)[reply]
To try and help keep track of the different numbers, I've written a background summary on at Module:Iucn/doc.   Jts1882 | talk  14:50, 19 December 2019 (UTC)[reply]
Good. I've tweaked it a bit.
—Trappist the monk (talk) 15:15, 19 December 2019 (UTC)[reply]
(edit conflict)
You know that, and I know that, and editors possibly know that, but readers certainly do not know that. The error message highlights a discrepancy that editors should resolve so that readers aren't confounded when they click a doi link that lands them on the same taxon/assessment page despite the different taxon/assessment identifiers in the doi. It is for the editor to resolve the discrepancy so that the rendered iucn links go to the correct places with the least amount of confusion to the reader. If the amended version is acceptable, delete |doi=; if not, change |page= to the doi's identifiers which will link |title= to the pre-amendment assessment; delete |doi= to avoid confusion. Don't do anything that can confuse readers.
—Trappist the monk (talk) 14:59, 19 December 2019 (UTC)[reply]

what about {{IUCN}} and similar?

Earlier in this discussion editor Jts1882 wrote: The only reason for keeping [|id=] would be to convert {{IUCN}} templates in future, but for now it serves no use. Since I am hip-deep in converting {{cite journal}} and {{cite web}} to {{cite iucn}}, why am I not, at the same time, converting the {{IUCN}} series to {{cite iucn}}?

Here is the current (as of this morning) count of these templates (17,321)

A spot-check of those templates indicates that they all call {{IUCN}}, create a url from |id= and support some parameters not supported by {{cite iucn}}:

|assessment_year=
|criteria-version=
|IUCN_Year=
|iucn_year=

This parameter is a native cs1|2 parameter; what value does it provide in the new red list scheme?

|version=

These are supported by {{cite iucn}} but should they be? All of the many {{cite web}} and {{cite journal}} templates converted to {{cite iucn}}, none use any of these because cs1|2 doesn't support these parameter names. I see no reason to continue to support these names so when / if {{IUCN}} and companions are converted, these parameters should be converted to the generic cs1|2 parameters.

|assessor= and variants
|downloaded=
|taxon=

The {{IUCN}} templates default to |mode=cs1 and |def=harv. |mode=cs1 is unnecessary because the {{IUCN}} templates use {{cite web}} and {{cite iucn}} uses {{cite journal}}.

So, conversion might look like this (from Giraffe):

{{IUCN|version=2018.1|assessor=Fennessy, S.|assessor2=Fennessy, J.|assessor3=Muller, Z.|assessor4=Brown, M.|assessor5=Marais, A.|last-assessor-amp=yes|year=2018|id=174469|title=Giraffa camelopardalis ssp. rothschildi|downloaded=2019-08-25}}
Template:IUCN

to:

{{cite iucn |author=Fennessy, S.|author2=Fennessy, J.|author3=Muller, Z.|author4=Brown, M.|author5=Marais, A.|last-author-amp=yes|year=2018|url=https://iucnredlist.org/details/174469/0|title=Giraffa camelopardalis ssp. rothschildi|access-date=2019-08-25 |ref=harv}}
Fennessy, S.; Fennessy, J.; Muller, Z.; Brown, M.; Marais, A. (2018). "Giraffa camelopardalis ssp. rothschildi". IUCN Red List of Threatened Species. 2018. Retrieved 2019-08-25. {{cite journal}}: Invalid |ref=harv (help); Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

Any reason that I should not do these kinds of conversions?

—Trappist the monk (talk) 15:58, 22 December 2019 (UTC)[reply]

The template documentation says the template is now obsolete and people should use {{cite journal}}. My thinking was to convert the template to use the module function, with the appropriate aliasing of parameters. However, if the template is no longer being added to pages and all uses are from old edits then there is no need to keep multiple templates. The version templates seem to just add the |version= parameter (while still requiring the year) so were of limited value.
The |version= parameter gives the version of the redlist, which is now takes the form 2019-3 (latest version) to reflect several updates to the list each year. In the past it referred to a published list, but in the electronic age it is a bit redundant, as it overlaps with the access date. Although I habitualluy add this when I make a reference, the IUCN's recommended citation no longer includes it. Perhaps it should be kept for older citations without the electronic page number.
The |criteria-version= refers to the version of categories and criteria use to make the conservation assessment. These go back to the early days of the IUCN assessments, when the IUCN was devloping their methodology and kept changing the categories and criteria, but all assessments since 2001 have used IUCN Red List Categories and Criteria. Version 3.1. There can’t be many assessments that old so its probably obsolete, although still use as a parameter in taxoboxes. It's no longer part of the IUCN's recommended citation so I see no reason to include it.
In short, not really, unless people are still actively using the template for new citations. It makes sense to have all the IUCN citations fully compliant with the CS1/2 templates and have one place to make any future updates.   Jts1882 | talk  08:33, 23 December 2019 (UTC)[reply]
The note in {{IUCN}} documentation needs a rewrite because as we've discussed, dois do not link to the specific assessment version (as they properly should do) but get redirected to the most current assessment. Original-form urls also redirect to the most current assessment so the only way to get to an older assessment is to know that assessment's electronic page number or find an archived copy someplace. Should also recommend {{cite iucn}} instead of {{cite journal}}.
I guess I think that we should not retain the |version= and |criteria-version= parameters from these templates. The url created by these templates gets redirected to the current assessment so |version= and |criteria-version= are meaningless at best and confusing at worst. If they conveyed meaningful information that could serve to help readers locate a particular assessment then retaining them would have benefit. In the current iucn website, there doesn't appear to be a way to locate older assessments. It might be useful to document how to construct an original- or old-form url from an electronic page number for editors who wish to seek older assessments at an archival site.
I'll pick away at code to convert these {{IUCN}} templates to {{cite iucn}}.
—Trappist the monk (talk) 11:51, 23 December 2019 (UTC)[reply]

Dec 18: WikiWednesday Salon NYC

December 18, 7pm: WikiWednesday Salon NYC

You are invited to join the Wikimedia NYC community for our monthly "WikiWednesday" evening salon (7-9pm) and knowledge-sharing workshop at Metropolitan New York Library Council in Midtown Manhattan. Is there a project you'd like to share? A question you'd like answered? A Wiki* skill you'd like to learn? Let us know by adding it to the agenda.

7:00pm - 9:00 pm at Metropolitan New York Library Council (8th floor) at 599 11th Avenue, Manhattan

We especially encourage folks to add your 5-minute lightning talks to our roster, and otherwise join in the "open space" experience! Newcomers are very welcome! Bring your friends and colleagues! --Wikimedia New York City Team 02:49, 17 December 2019 (UTC)

(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

Merry Christmas/Happy Holidays

Merry Christmas, Tom.Reding!
Or Season's Greetings or Happy Winter Solstice! As the year winds to a close, I would like to take a moment to recognize your hard work and offer heartfelt gratitude for all you do for Wikipedia. And for all the help you've thrown my way over the years. May this Holiday Season bring you nothing but joy, health and prosperity.CAPTAIN RAJU(T) 22:33, 23 December 2019 (UTC) [reply]

Taxonbar issue

I started a discussion at Template talk:Taxonbar#Order of entries which you may not have seen (it being the holidays!).

I'm puzzled by the behaviour of the code in Module:Taxonbar.

Consider the taxonbar at Cranfillia fullagari as an example.

I want these three to appear in the taxonbar in the order Cranfillia fullagari, Blechnum fullagarii, Lomaria fullagari. If in the article I put the parameters in the order I want, i.e. {{taxonbar|from1=Q42734713|from2=Q16749980|from3=Q42853943}}, then, as I would expect from reading the code, the one linked at Wikidata moves to the top, so I get Blechnum fullagarii, Cranfillia fullagari, Lomaria fullagari. However, Jts1882 pointed out a work-around. If I swap the order of the first two to {{taxonbar|from2=Q42734713|from1=Q16749980|from3=Q42853943}}, then the order becomes the one I want. However, this isn't what I would expect from reading the code; I can't at present figure out why.

What I would really like is for the item whose taxon name is the same as the article title to be moved first. We often have to link from the 'wrong' Wikidata item to ensure that the most language links are present.

So,

  • Can you see why the code behaves as it does? (But please don't fix it unless making the change below.)
  • How about changing to move forwards the article title?

Peter coxhead (talk) 14:54, 26 December 2019 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Tom.Reding&oldid=932521583"