This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
New Wikiproject!
Hello, Tom.Reding! I saw you recently edited a page related to the Green party and green politics. There is a new WikiProject that has been formed - WikiProject Green Politics and I thought this might be something you'd be interested in joining! So please head on over to the project page and take a look! Thanks for your time. Me-123567-Me (talk) 03:58, 23 January 2017 (UTC)
Reference fixes
Please note that in some cases your automated edits to citation template parameters converted "|title=[Letter to the editor]" to "editor=..." - here. Shyamal (talk) 09:51, 26 January 2017 (UTC)
CSS styling in templates
Hello everyone, and sincere apologies if you're getting this message more than once. Just a heads-up that there is currently work on an extension in order to enable CSS styling in templates. Please check the document on mediawiki.org to discuss best storage methods and what we need to avoid with implementation. Thanks, m:User:Melamrawy (WMF), 09:11, 6 February 2017 (UTC)
MoMP revision
Hi Tom, long time no edit. Are you disposed to edit the MoMP-table-header tpl a bit?
The |top-link=no is already present in all partial MoMP pages. For the new column, I propose to use a parameter such as |refcol=yes as well, so that both old an new table-header versions can coexist.
Context: Basically all MP-citations can be found in at least one of ((JPL)), ((MPC)), ((DoMP)) (preferentially used in that order, i.e. using ((JPL)) whenever possible, and only using ((DoMP)) when the other two do not provide any citation-text. This preference has to with copyright concerns). For newly named MPs, this distinction is irrelevant and the JPL template will always be used.
When looking at Ref · Cataloge it would maybe look better if Catalog · Ref was used (i.e.inverted order to have a nicer vertical alignement), but that would not be consistent with the LoMP-table (here, with its Ref · Meaning header, that need to be compatible for toggling between MoMP and LoMP, which is one of the goals of this revision).
What you think? If you are on a wikibreak or rather occupied with other things, then no problem. I will implement these changes myself. Best, Rfassbind– talk14:10, 18 February 2017 (UTC)
Hey, yes, it's been a few months, eh? Maybe I should put a WikiBreak banner up. I'm definitely available on request though; I'm just not sure how much self-induced/inspired work I'll be doing for a while. Next week I think I can look into this/make the necessary changes. Will ping you then! ~Tom.Reding (talk ⋅dgaf)19:11, 18 February 2017 (UTC)
Great, here are some further possible improvements (for reference):
The year the citation was published in the M.P.C. could be added based on the curricular's reference number and a mapping date range from MPC's publication archive (which goes back to 1977). Of course this needs to be parsed and mapped for (20) thousands of NamedMPs and potential IP blocking by the MPC requires extra work (using the more complicated ((DoMPN)) source for example). For low-numbered (up to 1500) MPs, the The Names of the Minor Planets reference could be used, leaving a gap for those MPs named between 1959 and 1977.
Colorize table rows based on the type of naming (e.g. people, places, mythology, and others). People should have a date of birth/death, places a country, while others have neither of them. This could lead to a potentially interesting structure for table rows where the number of cells are not even, so a set of specific table-row templates could be used for all these types.
the minor planet designation in the first column could only be linked if there is an MP-object article, and not linked if it is a redirect to LoMP. This concept, however, might be too difficult for most editors (so they would link a redirect anyway).
Rfassbind, I've got some time now but it looks like you made all the required changes? I am tempted to edit the /doc to reflect those changes. However, I just went through every page that transcludes ((MinorPlanetNameMeaningsTableHeader)), and I found that each template call now contains |refcol=yes (I noticed that on March 1 this was not the case but I didn't have the time to help complete the transition). I'm also tempted to make |refcol=yes the template's default behavior and remove the need for this parameter. If you agree, I can do so later this week. ~Tom.Reding (talk ⋅dgaf)19:47, 13 March 2017 (UTC)
I don't see how this could be of frequent-enough interest to be included in the table, especially given the difficulty in performing the addition, and the added bulk to the already-bulky pages.
That would be nice to see, similar to what you did on the LoMPs :)
Thx Tom for the removal of the obsolete parameter |refcol=yes. Good to have you around again. Since my last post a few weeks ago, I came to realize that most naming citations in the partial MoMP tables need to be thoroughly revised before any new feature can be implemented. There are missing citations, a lot of WP:OR with hidden html comments, dead/unhelpful external links, missing internal links, excessive redlinks etc. But I acknowledge that the naming citation's year of publication may not be considered a useful addition to the table. Till soon, Rfassbind– talk22:39, 16 March 2017 (UTC)
Template and mass edit
Dear Tom, here are two proposed edits, concerning mass-change edits and intrinsic template programming, for which you are definitely the man:
Edit ((Infobox planet)): in the infobox'es designation section, the label for |alt_names= is currently "Alternative names". This has to be changed because it overwhelmingly contains (provisional) designations, not "names". I propose "Alternative designations" or something similar that does not use the word "name". As long as this amendment only applies to minor planets (i.e. |minorplanet=yes), this change is uncontroversial.
In the infobox, section designation, parameter |mp_name=: most if not all named minor-planet object articles do not display a parenthesis in their name. The label "MPC designation" is clear and uncontroversial: all named minor planets need to be displayed with a parenthesis around the catalog number. Example: 1296 Andrée has already been corrected. There are a few thousand articles that need such a change...
Cool. Thx Tom. Just to let you know: Minor-planet object articles that I'm revising since my first post above, do already include a parenthesis as described in #2.Rfassbind– talk14:24, 4 April 2017 (UTC)
Rfassbind, I'm working through these and I'm finding many exceptions. One of them is...the MP page doesn't even have an ((Infobox planet))! Thought you'd like to know so you can bump these up on your overall revision schedule :) I'm missing 1 atm and will add it to the bottom after I'm doing adding |mp_name= to all the remaining infobox'd pages.
I'm also thinking of changing |mp_name= to |mpc_name= since it's much more intuitive, matches the displayed text, and won't be mistaken for |name= by inexperienced editors. I'll make a new topic on the ((Infobox planet)) talk page informing ppl before I start that. ~Tom.Reding (talk ⋅dgaf)15:26, 10 April 2017 (UTC)
Thx Tom for listing those 16 remaining, low-numbered MP-object articles with no infobox (I added them to my previously incomplete list) and thx for adding any missing |mp_name= parameters (hope there aren't too many). Also, renaming this parameter to |mpc_name= seems fine to me (as stated on the templates talk page). Thx, Rfassbind– talk05:14, 11 April 2017 (UTC)
Revise unhelpful potatoes MP#R
Hi Tom, here's another suggestion for a mass-edit, which you might be interested in.
In 2010, user PotatoBot has created large numbers of MP#Rs such as Rozhdestvenskij. These are redirects that just use the minor planet's name without a number. All redirects have a ((R from short name)) template on the first line. There might be hundreds of these redirects.
Many of these redirects have change their targets over time. Those that now redirect to the list of minor planets are highly unhelpful.
In addition I also propose to create a redirect template, in analogy to ((NASTRO comment)), that explains that it is a name of a minor planet, and what to to/how to amend (e.g. to change target to a biography etc. if exists, of turn it into a ((Disambiguation)) page.
Rfassbind, I just finished going through all pages which transclude ((R from short name)) and contain the regex minor planet|asteroid|list of|\[\[\(?\d+\)?\s+'?\w. After removing obvious non-MP pages, and cross referencing the remainder with the MPC's MPNames.html and with the unnamed unnumbered asteroids on WP, I found ~6644 potato'd MP#Rs. ~6085 of the potato #Rs have a unique match to the MPNames list and can be handled relatively straight-forwardly. ~435 of them are provisional designation pages, some of which may by now be numbered, and should probably point to the appropriate provisional list/article and LoMP pages, respectively. The remaining ~125 have multiple MPNames hits and need further scrutiny.
The ones that point to (or should point to) the MoMP can be treated with ((R from short name))((NASTRO comment|do-not-cat=yes)). The (probably) small # of ones that point to (or should point to) actual MP articles can have something like ((R from short name))((NASTRO comment|do-not-cat=yes|r-templates=off)).
However, given the history of the MP#Rs and the large # of afflicted pages, yeah I think it's best to do as you suggest & make something like ((PotatoBot)), which produces the equivalent of ((R from short name))((NASTRO comment|do-not-cat=yes)), and ((PotatoBot|article=yes)) which produces the equivalent of ((R from short name))((NASTRO comment|do-not-cat=yes|r-templates=off)). ~Tom.Reding (talk ⋅dgaf)22:03, 16 April 2017 (UTC)
Thx, Tom. Good job. Can you post your results on this page? I do not understand how provisional pages and names go along (those 435 items, you mentioned). Also, since my first post in March, I was also thinking about just using a ((NASTRO comment)) with new custom params (instead of a dedicated template). And, I will formulate a custom redirect-message-text and post it on the above mentioned page. Best, Rfassbind– talk10:31, 17 April 2017 (UTC)
Will do.
On the topic of to-NASTRO-comment or not to-NASTRO-comment:
If all that's being added are the r-templates (i.e. |potatobot=yes would append ((R from short name)) & ((R unprintworthy)), and maybe an additional #R template), it would only be a minor addition to the ((NASTRO comment)). The |do-not-cat=yes parameter & message would be needed for & be seen on each potato #R. |potatobot=yes, however, would be nested under |do-not-cat=yes, so the typical P#R would have ((NASTRO comment|do-not-cat=yes|potatobot=yes)), which implies the existence of ((NASTRO comment|potatobot=yes)), which would not in fact exist. This makes it less intuitive for future editors and increases chances for error.
If ((NASTRO comment|potatobot=yes))did exist, then that would make the template code (and documentation) much longer and more complicated.
The interaction between |r-templates=off & |potatobot=yes would be similarly complicated.
These short-name P#Rs are in no danger of accidentally being turned into articles, so the justification for using/changing ((NASTRO comment)) directly is that much weaker.
I see the desire to combine/track all of the |do-not-cat=yes #Rs in 1 place. If ((NASTRO comment)) is used within ((PotatoBot)) (or whatever), then all of them will show up when looking for 'what transcludes ((NASTRO comment))'. A custom message would preclude the use of ((NASTRO comment)), however. But we can mollify this by mentioning ((PotatoBot)) in the ((NASTRO comment)) documentation so anyone looking for all the MP#Rs would know where to look.
Thx Tom for posting the list of all concerned pages on the project page. I respond to your 3 posted lists separately in #1, #2 and #3:
1. For the 6085 P#Rs with a unique match in MPNames.html, please proceed as you seem fit best (I was just worried about the longevity of such template). So if you want to use a dedicated template for these redirects that's fine with me. I wouldn't name it ((PotatoBot)) though. That's only circumstantial (and there are other reasons as well). A better name would describe what the template is about, namely a redirect that only uses the name-part of a minor planet's final/permanent designation. In short ((Partial minor planet designation))". If you come up with a better name for that template, please go ahead and thx for the effort.
2. For the 435 potential provisionally named P#Rs . This is another topic. They are those tertiary redirects (ter#Rs) of unnumbered provisional designations, for example:
1981 EU20 (tertiary #R; created: 19 April 2010) that is the unnumbered version of
(8627) 1981 EU20 (secondary #R; created: 22 February 2010 ) which has been moved to
Theses tertiary #Rs do not fit into the potato-R-from-MP-name-only task we discussed above. They have nothing to do with a "name" and are completely different. I propose to create a ((R from superseded designation)) [replace strikethrough text with: used ((R from former name))] for this specific group of ter#Rs and add it to a good fraction of secondary #Rs as well (those sec#Rs that were created by a move upon naming by the MPC).
Here are some details:
Per your list there are 435 items ("potential provisionally named P#Rs"). On your redirect candiate page I once listed all the possible variation of secondary redirects (double redirect).
Until now, I have simply used a "R from move" on the sec#Rs when I moved them upon naming by the MPC. Unfortunately "move" is circumstantial, it describes what happened, not what it is. I don't think these ter#Rs can be handled in the same manner, as they have been created after the secondary already existed, so a "R from move" would even be wrong.
We may want to create such a "R from superseded designation" and use ((R from former name))instead and "R from move" along with the category-shell, "R avoided double redirect" (if they are #Rs-to-LOMP). If created we should use it for those sec#Rs that were created by a move action as well.
3. For the 124 P#Rs with multiple matches in MPNames as you said, they need further scrutiny. Currently I don't know what "multiple" matches they are (article names or text in articles?). But in any case they are likely to join #1 as they are all "MP-names only"
Thx, Rfassbind– talk15:33, 19 April 2017 (UTC)
Good documentation. I think an additional comment in the "boilerplate message" and examples in the documentation will be helpful. Thx for the effort, Rfassbind– talk02:40, 22 April 2017 (UTC)
Rfassbind, I added ((Partial minor planet designation)) to the vast majority (95.1%) of the 6085 P#Rs with a unique match on MPNames.html (I didn't touch the 297 with diacritics). Nor did I touch the 124 nor the 432 potentially provisionally named MPs because they require a keener eye and more time than I can provide right now. Please try to finish these off. I may do some of these in the future, or I may not. If I do, I'll strike them off as done. ~Tom.Reding (talk ⋅dgaf)23:36, 14 May 2017 (UTC)
Sure, thx for your reminder. I amended ((Partial minor planet designation)) with a custom message (tentative) and started to revise those easy, tertiary cases such as 1989 WE1 which have no "name" as mentioned above under (#2), using an ((R from former name)) (instead of "superseded") as well as an ((R avoided double redirect)) in most cases. Rfassbind– talk09:44, 15 May 2017 (UTC)
follow-up: if you could do a search and give me a list of all MP pages containing the (hardcoded) html-comment <!-- Do not categorize this page, to avoid duplication. --> would help me to expanded/enlarge my revision I just mentioned above. Rfassbind– talk10:10, 15 May 2017 (UTC)
Luckily, I'm going to download the latest enwiki database and scan all redirect for something else I'm looking for. I will also scan it for all instances of <!-- Do not categorize .... ~Tom.Reding (talk ⋅dgaf)14:38, 15 May 2017 (UTC)
Tom, I'm now on task #3, 124 P#Rs with multiple matches in MPNames. I just noted that ((Partial minor planet designation)) does not display those automatically added templates as it should. For example:
Adamries with |article= set to "yes" should not display "listentry, anchor, and up", while
Leoconnolly pointing to MoMP, with no parameter set, does not display these templates, although it should.
297 P#Rs with a unique match and diacritics in MPNames.html, most of them redirect to MOMP, 2 or 3 were incorrect names, a couple of dozen had articles, and one or two I decited to redirect to a non-MP article or DAB page. By the way, since all the redirects had unique matches, what was the reason to exclude the diacritical names from the mass-revision you did on the non-diacritical ones? Rfassbind– talk21:38, 31 May 2017 (UTC)
Another search question
Hi there. I want to search for all instances of:
((Colbegin))
((reflist))
((Colend))
in the insource search bar, with an without capital letters. I'm not having any luck with the dashes. Maybe you know a better way? Thanks --Jennica✿ / talk07:09, 5 April 2017 (UTC)
Jennica, insource:/\{\{[Cc]olbegin))[\r\n ]*\{\{[Rr]eflist))[\r\n ]*\{\{[Cc]olend))/ should do the trick. Only the first sets of { need to be escaped to \{, since unmatched } don't need to be escaped (though you could escape } if you want if unsure). The [\r\n ]* takes care of white-space characters between the templates (carriage return, new line, and space, respectively). I only found 1 result :) ~Tom.Reding (talk ⋅dgaf)15:19, 9 April 2017 (UTC)
As a reminder to myself (and others), the regex character class \s contains all whitespace characters, but it does not work as intended in WP's insource: search function, so you have to enumerate them. ~Tom.Reding (talk ⋅dgaf)16:05, 9 May 2017 (UTC)
The column "provisional" in all the 500 partial pages of Meanings of minor planet names should be removed as it serves little to no purpose at all. Rarely a minor planet's name was inspired by its provisional designation, and if that's the case, it can easily be mentioned in the description (if not already done so). What do you think? Rfassbind– talk01:46, 23 April 2017 (UTC)
Details
Empty sections with a comment "There are no named minor planets in this number range" must have their |colspan= attribute reduced from 4 to 3.
The removal of column "provisional" should neither cause "double spaces" nor "touching double-pipes" in the source code.
Hmm, I think the Provisional column is non-trivial, though not by much. A better argument would be when/if there were more columns that could be added that are more useful than Provisional. ~Tom.Reding (talk ⋅dgaf)16:04, 23 April 2017 (UTC)
The problem I see with the entire Solar System/minor planet project is that there is so much redundancy, and so many tables with unhelpful extra information that are neither complete nor maintained. This is bad. Rather than excessive redundancy and details, we need more/better linkage between the various tables, article and categories and focus on the core aspects. In that respect we have already achieved quite a bit, such as, for example, the interconnection between the corresponding LoMP and MoMP records, and since they are now tightly bound to each other, I see no point in having the provisional designation in both these tables. Rfassbind– talk23:22, 25 April 2017 (UTC)
Rfassbind, if the column needed constant maintenance then I'd strongly support removing it, since the cost/benefit ratio would be high. As it is now though, my opinion is 'meh' (not worth the effort). ~Tom.Reding (talk ⋅dgaf)13:55, 9 May 2017 (UTC)
That's OK. Revising the content of all partial MOMP-lists is more important anyway. So no need for structural changes right now. As of May 2017, I think the overall revision of all partial lists will not be finished soon, so it's quite possible that I will come up with new ideas for additional features that might also change the table's structure before the revision is finished. Thx for your feedback, Rfassbind– talk12:27, 12 May 2017 (UTC)
Alias of template Dwarf planet
Some of the minor-planet object articles seem to use an alias for the footer template ((Dwarf planets)). I found one article that uses ((Plutoids)) rather than ((Dwarf planets)). If I'm not mistaken, that would be a perfect "search & replace" task for someone using AWB:
Rfassbind, Done, only about 50. And I realized this towards the end - this sort of fix, at least on a small scale, is probably ok, but on a large scale fixing template redirects is considered a 'trivial edit' by AWB. ~Tom.Reding (talk ⋅dgaf)14:53, 9 May 2017 (UTC)
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.
Mass-edits adding new templates to minor-planet redirects
Tom, @Paine Ellsworth:, I propose two mass-edits on minor planet redirects (MP#Rs for short):
Add ((R from former name)) to all provisionally designated (secondary) MP#Rs that have since been named. For example (6444) 1989 WW is the unnamed version of 6444 Ryuzin. As with (6444) 1989 WW, most provisionally designated MP#Rs of named minor planets already possess a ((R from move)), since they were created first and then moved (some years later) to the named version. So ((R from former name)) often goes along with ((R from move)). I think both templates are needed and are not redundant, as one describes the what (circumstances), and the other explains the why (relation). ((R from former name)) can be considered a synonym for "R from provisionally designated minor planet". The template should be added to any provisionally designated MP#R, irrespective of whether the named version is an article or another redirect (to the List of minor planets).
Add ((Talk page of redirect)) to all Talk-pages of primary MP#Rs using |othertalk= set to the main/parent Talk:List of minor planets. This facilitates discussions about minor planets that have no article on wikipedia with a talk page that is not frequently watched by others. For example Talk:48411 Johnventre is currently one of very few Talk-MP#Rs that has such a template, but its target is its corresponding partial list which contains 1000 minor planets for its number range. Since there are hundreds of partial lists, it would make more sense to chose Talk:List of minor planets as a single target for all MP#Rs. Note that, per convention, the talk pages of primary MP#Rs themselves, do never redirect to the List of minor planets (per convention). Also talk pages of secondary redirects, e.g. Talk:(48411) 1985 RB3, are of no concern for the addition of ((Talk page of redirect)) as they simply redirect to the primary MP#R's talk page, e.g. Talk:48411 Johnventre. Also, instead of "Talk:List of minor planets", User:Tom.Reding/Shortlist of minor planet redirect candidates could be used as an alternative target page.
Hope this wasn't too painful to read. I tried to be as clear as possible. What do you guys think about the two proposed changes? Rfassbind– talk08:53, 5 May 2017 (UTC)
Both appear to have a lot of merit if I understand them correctly. For #2, consider having an ((#ifexist:...)) function or equivalent so that talk pages that do not already exist will not be created just to put the Talk page of redirect template on them. Also, your edits to centralize discussions do make sense; however, I've noticed two things that concern me at Talk:(48411) 1985 RB3: (1) you redirected that page to Talk:48411 Johnventre, which is a soft redirect, so you now have a form of double redirect to a page that should have no future discussions. That results in extra clicks for readers who are trying to find a place to ask about or discuss something. Talk:(48411) 1985 RB3 should redirect to a usable talk page, shouldn't it? and (2) you removed ((R from move)) evidently to keep the redirect from being categorized as an unsynchronized talk page redirect. That talk page is the result of a page move and should be categorized as a redirect from a page move. Before we change anything, though, I want to see if I can figure a way to add another exception for these in the R from move template, so as to keep all of them out of the unsynched category. Paine Ellsworthput'r there16:28, 5 May 2017 (UTC)
Thx for your valuable feedback. While (#1) seems to be uncontroversial, you raised questions about (#2). Let me reiterate two things, so that we're on the same page. I'll stick to our example:
First, the chronology of the two pages for this minor planet (creation, move and redirect):
on 27 December 2015 – 48411 Johnventre was redirected to List of minor planets by Boleyn
Second, terminology. As of 2017, there is no article for this minor planet (MP). 48411 Johnventre redirects (#R) to the List of minor planets (LoMP). We call it a primary redirect (p-MP#R) which contains a notabillity-comment and several categories. The old version with the provisional designation (instead of a name) is called a secondary redirect (s-MP#R) and always has a ((R avoided double redirect)), no categories, and a warning.
Third, why not to synchronize talk-pages: Secondary MP#Rs of the type of the example above are a pain in the ass. The talk-page of these s-MP#Rs seem utterly useless, but they were created some time in the past and continue to exist after the minor planet was named. (If I was an admin, I would probably have deleted these secondary talk pages). No one links to them. Their content was moved to the p-MP#R upon naming. They really serve no purpose. That's why I simply put a #REDIRECT [[Talk:48411 Johnventre]]. This has the advantage, that no further amendments will have to be made in the future, irrespective of whether or not 48411 Johnventre will be turned into an article one day. Conversely, if we'd synchronize any of these two talk-pages to the LoMP-list, then future amendments seem likely to be necessary (as the example shows, talk pages are often forgotten by editors). That's why the extra clicks for readers are really not worth to be considered.
Fourth: I don't understand your "#ifexist" remark. Note: there are no primary MP#Rs with a missing talk-page (please check). And I doubt that there are >1% of s-MP#Rs talk-pages that are "missing" (well, since I consider them useless, they aren't exactly missing, but I created them for consistency nevertheless). Can you elaborate more about your concern?
To editor Rfassbind: Well, okay then, to begin with the third above, I'm not averse to centralizing discussions, and if the primary redirect may one day become an article, I see nothing wrong with redirecting to the soft double redirect, which will then lose the Talk page of redirect template and become an article talk page. If the secondary redirect remains a "hard" redirect, that lands it in the unsynchronized redirects category if the R from move template is used, and it should be used since the secondary redirect is the result of a page move. In regard to your fourth above, you can disregard what I said about the ((#ifexist:...)) function. I suggested that because I didn't know it wasn't needed. Now to your fifth above, yes, it is R from move that passes the code to sort unsynchronized categories so they can be fixed. A few weeks ago that category had more than 10,000 entries. Many were fixed by the exceptions, which are mostly the talk pages of template sandboxes, documentation pages and testcases pages that are redirects from moves and that centrally redirect to the main template's talk page. The rest were fixed just by synchronizing the talk pages to the subject pages (or vice versa if that was appropriate) just as I did at Talk:(48411) 1985 RB3 with this edit. There is of course no rush to figure all this out, and I'll get to it soon to find a way to make the secondary redirects exceptions to keep them out of the unsynchronized redirects category. Just sayin' that removing the secondary talk page redirects from Category:Redirects from moves may not be the best solution. Paine Ellsworthput'r there16:40, 7 May 2017 (UTC)
Regarding #2, if I've read everything above correctly, adding ((Talk page of a redirect)) to all named p-MP#Rs is still uncontroversial/no discussion needed? "Named" being the operative qualifier here, since those p-MP#Rs are under no threat of being moved/renamed. ~Tom.Reding (talk ⋅dgaf)15:28, 9 May 2017 (UTC)
I agree that there is no controversy surrounding the placement of ((Talk page of redirect)) on primary talk pages. What would you think about converting the secondary talk page redirects by replacing the REDIRECT code with Talk page of redirect and perhaps any project banner(s) that is appropriate? Paine Ellsworthput'r there15:55, 9 May 2017 (UTC)
We (WP:AST) definitely don't want banners nor astronomy-related categories (i.e. a tracking category is probably fine) on the secondary MP#Rs, only the primary MP#Rs. The primaries are much more important, relatively speaking of course (the p-MP#Rs are themselves the lowest importance on the project scale).
Task #1 Done. Using ((NASTRO comment|do-not-cat=yes)), I found 231 provisionally designated pages. Of these, 223 needed ((R from former name)), and 8 already had it. If anyone knows another/better way to find these provisional s-MP#Rs, I'd love to hear it! ~Tom.Reding (talk ⋅dgaf)20:41, 9 May 2017 (UTC)
Thanks guys for your help:
Paine Ellsworth: Thx for your feedback. OK, I agree with you on the talk-pages of secondary MP#Rs (let's name it: taks#3; as it is different form #1 and #2 mentioned above), such as Talk:(48411) 1985 RB3, where I removed the ((R from move)) and thereby (unintentionally) "resolved" the problematic issue of the page being listed as a Category:Unsynchronized talk page redirects. Alternatively, deleting s-MP#R-talk-pages is fine with me, and as I just realized, the example I used above, Talk:(6875) 1994 NG1 (click on it), has in fact just been deleted recently. However, new secondary MP#Rs will be constantly created on a monthly basis due to a moved-action (maybe 100 moves per year or so, slowly decreasing in number over the next, say, ten years). So this issue of non-synchronized and (most likely) unhelpful secondary talk-page MP#Rs will always show up. Please just let me know what you want me to do with these pages.
Task #1: adding a ((R from former name)) to all provisionally designated (secondary) MP#Rs, such as in, for example, (48411) 1985 RB3. Thx Tom for evaluating how many there are (a total of 223 s-MP#Rs). If you'd ask me for a criteria to find them, I'd say: any redirect that possess a ((NASTRO comment)) with a |do-not-cat= and a title/name that contains ( and ) in the pagename. Sorry if this is an obvious or unfeasible search criteria. Maybe less trivial might be the fact that whether or not a "move" template exists is not helpful for finding this type of s-MP#Rs. Does this task still seem uncontroversial to the both of you? To me it does, and I need your scrutiny because on the long term, I will created thousands of such redirects to already named MPs articles or redirects (without a corresponding talk-page, of course, see preceding point of my response).
Task #2: adding a ((Talk page of redirect)) to all talk-pages of primary MP#Rs, for example, such as in Talk:48411 Johnventre. However, unlike the example, we would use |othertalk= and set the target to Talk:List of minor planets, which is the parent talk page of all LOMP partial lists. This is the best alternative to synchronizing the talk page of primary redirects (see above for my rationale "why not to synchronize primary MP#R-talk pages"). To Tom.Reding, whether or not the p-MP#R is a named or unnamed MP is irrelevant: if an unnamed p-MP#R is moved, the ((Talk page of redirect)) template will also be moved (along with the ((WPSS)) and ((WPAstro)), as well as any exiting post on that page) to the named version. So ((Talk page of redirect)) has to be added to any primary redirect (i.e. a category- and ((NASTRO comment)) containing redirect). This task (#2) is uncontroversial to me. Please confirm/answer back, and also say whether:
(a) Order: should ((Talk page of redirect)) be added above (on top) or below the WPAstro/WSS templates (I favor a position below the WPAstro/WSS templates and above a potentially existing ((Old AfD multi)), such as in, for example Talk:1274 Delportia.
(b) Target:: Is Talk:List of minor planets really the best target page? I think so, but a dedicated talk-page similar to Tom's list might be more appropriate?
(edit conflict) Hi Rfassbind – I'll cover these in the order presented, and first your task #3 above... I see no reason why speedy deletion cannot be attached to any of these if they have no discussions, which they wouldn't if the discussions are moved to the primary talk page. I also would favor including Talk page of redirect, since that effectively makes the talk page a soft redirect. Task #1 still seems uncontroversial to me, so whatever you two whip together should work for me also. Task #2 also sounds uncontroversial, and as to the order, I usually favor placing the Talk page of redirect at the very top to immediately notify whoever sees it that the subject page redirects, where it redirects and the talk page where discussion about the redirect should take place. I think Tom also mentioned that the secondary redirects' talk pages really don't need project tracking. If a target is changed by the |othertalk= parameter, it doesn't really matter where as long as they all land editors on the same centralized talk page. Having said that, it seems that that the talk page that would most serve the community for centralized talks would be the list (LOMP) talk page. Paine Ellsworthput'r there16:12, 12 May 2017 (UTC)
Paine Ellsworth. OK. So we agree on #1 and #2. In case Tom wants to do the edits, I would let him decide where exactly he wants to put ((Talk page of redirect)). As for task#3, could you make at least one speedy-deletion edit of a secondary talk page (listed in the Unsynchronized category), so that I can follow your example in the future? Also, sorry about the edit-conflict, I hate that when it happens to me. Best, Rfassbind– talk11:05, 13 May 2017 (UTC)
To editor Rfassbind: I figured to use G6 "housekeeping", but Twink asked for a rationale. Rather than rack my brain, I decided to slap Talk page of redirect on all of them. So they're out of the unsynched category. Paine Ellsworthput'r there14:40, 13 May 2017 (UTC)
MP infobox > parameter "image_size"
Most minor planet articles with an image in their infobox should have a parameter |image_size= to define the size of the image. Currently, most non-default image sizes are defined together with the image-path in parameter |image=, e.g. as [[File:Vesta_in_natural_color.jpg|260px]]. Also see this edit that fixed the issue. If you want to do the amendments, please do so, otherwise I'll do them in the weeks to come. Best, Rfassbind– talk16:03, 12 May 2017 (UTC)
Rfassbind, the ((Infobox planet)) documentation is missing |image_size=, and using either |image=[[Image:Blah.jpg|300px]], or |image=[[File:Blah.jpg|300px]], or |image=Blah.jpg|image_size=300px works.
I'll add |image_size= to the documentation, leave it for a week or so, then go through the ~447 MPs I found that contain |image=[[Image:Blah.jpg|300px]] or |image=[[File:Blah.jpg|300px]]. Some of those 447 have additional parameters after the pixel size; I won't touch those and will put them in a shortlist for manual completion. ~Tom.Reding (talk ⋅dgaf)14:30, 15 May 2017 (UTC)
Actually, looking more closely at the documentation, I'm not comfortable making such a change because the pixel-size-in-image format is the prevailing format for not just |image=, but |symbol= & |orbit_diagram= & the top-most text inside the infobox examples, and |image_size= doesn't appear anywhere in the doc, and not using |image_size= doesn't break anything. ~Tom.Reding (talk ⋅dgaf)14:51, 15 May 2017 (UTC)
I based this post on TAnthony, who described this pixel-size-in-image format as a "deprecated infobox image syntax" (see example edit). I think he knows what he is doing (although he did not provide any link to a policy where this is stated clearly). My intention is to proactively add |image_size= in order to keep the customized image sizes before they are lost, but if the pixel-size-in-image format is not deprecated than, of course, this is not needed.
Hi, the deprecated syntax I was talking about is of course |image=[[File:Example.jpg]], not specifically the custom sizing. The use of this syntax in the |image= parameter of infoboxes places those articles into the maintenance category Category:Pages using deprecated image syntax. When I first started these "corrections", we were only dealing with specific infoboxes, like ((Infobox book)). In that particular case, custom image sizes are unnecessary 99% of the time, as infoboxes have a default image size when using the bare filename, and the image proportions for book covers are pretty standard. More recently however, the implementation of bare filename syntax to Module:InfoboxImage has basically affected every infobox template, and we are finding that some of these templates, like ((Infobox military conflict)) and ((Infobox election)), need specific updates or have non-standard image sizing that needs to be taken into account. With this in mind, I've been preserving custom sizing most of the time, in particular for templates with which I'm unfamiliar. The |symbol= in ((Infobox planet)) is not currently detected by the module change, but it looks like a specific image size parameter for that should be created in this template in anticipation of a future time when it is.
In the case of my edit used as an example above, I did remove the 250px sizing of the image because it seemed unnecessary to me as marginally different from the default. I did put it back with |image_size= after Rfassbind's objection, and this partially informed my preserving custom sizing moving forward. Still, if ((Infobox planet)) has a default size, I'm not sure why we are sizing standardly-shaped images. Per WP:IMAGESIZE we should not be using fixed custom image sizes, but rather relying on user image size defaults (primarily for accessibility). I was under the impression, though, that |image_size= was already available in the majority of infobox templates, but the gradual correction of this syntax is revealing many templates in which it is not.— TAnthonyTalk19:43, 15 May 2017 (UTC)
@TAnthony: thank you for your explanation. There is a large variety of images used in ((Infobox planet)) that have a completely different aspect ratio. A custom-sized image might be also relevant for an article's layout, as the default width of ((Infobox planet)) is rather small (in my opinion), and the number of displayed data can make it very long (and even longer if the size of certain images is not reduced (e.g. see 9906 Tintoretto vs. 9921 Rubincam). To me, it seems necessary to preserve any custom size whenever possible. My question: is it better to use |image_size= rather than the pixel-size-in-image format, in order to prevent the loss of such defined custom sizes due to future mass-edits? Which one is the better syntax in your opinion? As for the symbol-images, sorry, I have no opinion (only a very small fraction has them, while an infobox-image might be available to thousands of minor planets in the future). Best, Rfassbind– talk18:48, 18 May 2017 (UTC)
Sorry Tom.Reding if this discussion on your talk page is becoming bothersome! Rfassbind, |image_size= is really the only choice, since what you call the "pixel-size-in-image format" is deprecated. I've just created an AWB settings file to run through the transclusions of ((Infobox planet)) so over the next few days/weeks I will update the syntax and preserve the hardcoded sizes. FYI, |symbol= and |orbit_diagram= are not enabled for bare filenames yet anyway, so I will update only |image=. I'll make a note and at some point I will have this template looked at for updating. Thanks.— TAnthonyTalk21:44, 18 May 2017 (UTC)
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)
Redirect shells
Sure they make sense when you've got multiple R from... templates, but surely it's unneeded in cases like [1]? Headbomb {t · c · p · b}02:15, 10 June 2017 (UTC)
The reasons the documentation give are independent of the # of ((R))s ((Redirect category shell)) contains (namely, #R standardization, automatically sensing, describing and categorizing protection levels, and to help editors learn more about redirect categorization by use of the manifold sort), and the documentation explicitly states that it can and should be used with single-((R))-redirects, and even to use it when no ((R)) is present (to auto-populate Category:Miscellaneous redirects). ~Tom.Reding (talk ⋅dgaf)02:36, 10 June 2017 (UTC)
I'd argue it's certainly less of a waste of your time to get/demonstrate consensus, get a bot to do this (which you can probably run yourself as TomBot or RedirectBot or whatever), and let it loose while you sleep. There are tens of thousands, if not hundreds of thousands such redirects. There's also the many benefits of those being flagged as a bot edit. Headbomb {t · c · p · b}03:25, 10 June 2017 (UTC)
Well, the multiples are also very bot-friendly, and those ones certainly have community approval. Again, there's no rule that you can't do this manually, but near-mindlessly clicking "save" 140492 times must be awfully tedious. Headbomb {t · c · p · b}06:08, 10 June 2017 (UTC)
I'm just adding ((Redirect category shell)) to redirects with multiple ((R))-templates, not judging/evaluating the validity of each ((R))-template. However, Laticauda (sheep) does indeed seem undeserving of ((R from incorrect disambiguation)), and if you can provide a list of all such redirects (I only found ~34 of my edits which end in "(sheep)", as opposed to the hundreds you mention), I can remove the offending ((R)) if warranted. ~Tom.Reding (talk ⋅dgaf)13:17, 14 June 2017 (UTC)
Thanks! Here's a list, only very cursorily vetted, but a glance through it doesn't reveal any errors.
Justlettersandnumbers, I've created the code to do this, but after looking at ((R from incorrect disambiguation))'s documentation more closely, it does seem valid because the #Rs in the list above are of a format that does not follow Wikipedia convention; the only difference being the absence/presence of parentheses, a Wikipedia convention. ~Tom.Reding (talk ⋅dgaf)16:45, 14 June 2017 (UTC)
What convention is that? There's no consensus on how these articles should be disambiguated, though there was a lot of argument about it a couple of years ago. Justlettersandnumbers (talk) 17:56, 14 June 2017 (UTC)
What I mean is, where do think you see such a convention? Usage in the actual articles is mixed. No consensus was reached in the interminable arguments at the time, nor has it been since. Justlettersandnumbers (talk) 21:09, 14 June 2017 (UTC)
Also, a large set of standardized page titles trumps mixed-use in the respective articles when it comes to determining the prevailing convention. ~Tom.Reding (talk ⋅dgaf)21:28, 14 June 2017 (UTC)
You misunderstand. There's already been interminable tedious discussion of this topic (see Talk:Teeswater sheep). No consensus was reached. The very last thing any sane person would want to do is to start all that all over again. Anyway, please forget I asked. Justlettersandnumbers (talk) 21:43, 14 June 2017 (UTC)
I'm quite unfamiliar with the goings-on over at WikiProject Agriculture, so perhaps some exposition would have been useful, no? I can make 4 observations:
Going solely by the closing admin's statement at Talk:Teeswater sheep#Requested move 25 August 2014, and not knowing whether any intervening discussions occurred on this topic at that WikiProject: there is no consensus.
Going on the fact that, after a cursory search, I find many fewer articles which include (<common name>) (like Wensleydale (sheep)) in the title than <common name>: there is no consensusorthere is consensus +/- a few unfixed outliers.
The larger convention in question appears to be whether or not to even include the common name after the breed (with or without ()) - for which there are examples of (Beltex et al. on Talk:Teeswater sheep). The best way to find out which one is more prevalent is to simply count all the breed articles with and without their common name in the article title and set some threshold for 'prevailing'. Consensus undetermined/unclear.
Perhaps this consensus exists: if the name of the breed is unique among Wikipedia topics, don't put the common name (i.e. Beltex et al.) because it's redundant; if the name of the breed isn't unique among Wikipedia topics, put the common name (i.e. Welsh (pig) in your list above) because disambiguation is necessary.
Given this state, and especially #4, please:
don't remove ((R from incorrect disambiguation)) until such consensus has been reached, nor solicit others to so for you, and
undo your removals of ((R from incorrect disambiguation)) and ((Redirect category shell)) (at most ~108 by my count as of ~4 hours ago), the latter of which should be on all redirects, regardless of how many redirect templates they have, per documentation. If you prefer, I'll do this semi-automatically in the near future.
Hi Tom, thanks for your housekeeping of redirects. I notice some of them are being marked up as redirects "from a page name that has a currently unneeded disambiguation qualifier". I should perhaps explain why I created some of these. I translate a lot of articles from German Wikipedia. Occasionally they are disambiguated in German because they have several articles with the same name e.g. "Polenz" is the name of a river and also of 2 settlements. In English Wikipedia the settlements don't have articles, so "Polenz" is the title of the river article. But translated articles referring to it will often have "Polenz (river)" (the translation of the German link). Allowing these links speeds up translation (because the link automatically works) and prepares for the time when the other articles are created. I often do this down the line. So I'd say that, while these redirects are not strictly necessary, they are still useful. Bermicourt (talk) 07:47, 16 June 2017 (UTC)
I agree; keep it up. After a quick look to find an ((R))-template that matches your situation, ((R from another language|de|en)) looks relevant. Namely, the second bullet's text This redirect leads to its target in accordance with the naming conventions for titles in other languages and can help writing and searches. Consider placing these on the redirects you've created and that fit this criteria. If you produce a list, I can help add the template semi-automatically. ~Tom.Reding (talk ⋅dgaf)14:52, 16 June 2017 (UTC)
Paine Ellsworth, towards the end of my list I relaxed some of my skip-settings that auto-skipped pages with > 1 #REDIRECTs and/or > 0 ((Redirect category shell))s so that I could take care of a small subset of redirects like this. I forgot to reinstate those protections after I was finished, but it was towards the end of my run. Also, my edit was a case of garbage in, garbage out, since it already contained 2 uncommented #REDIRECT statements. Both of these factors combined to produce a very rare error. I looked through all of my edited pages which currently have > 1 #REDIRECT and/or > 1 ((Redirect category shell)), and I literally found nothing! How did you find it? ~Tom.Reding (talk ⋅dgaf)17:39, 22 June 2017 (UTC)
From the discussion at the VP, it seems fairly unlikely that you'll get consensus for single redirect templates, but the way I read it, I'd say there is consensus to use the shell when there are
Multiple redirect templates
Single redirect templates, when they have some form of protection
Some other non-cosmetic change (e.g. when fixing double redirects?)
There seems to be no need to update redirects otherwise, either semi-automatically, or automatically. Would that logic be fine with you? Headbomb {t · c · p · b}02:44, 28 June 2017 (UTC)
Headbomb, as far as auto & semi-auto edits go, yes. There still seems to be agreement for using the shell on #Rs without any #R-templates, but only if they're done manually. Even the 3rd bullet should probably be caveated with "if the cosmetic change doesn't affect a very large # of single-((R)) #Rs" or something along those lines (to please the largest # of people while displeasing the least). ~Tom.Reding (talk ⋅dgaf)11:25, 28 June 2017 (UTC)
From my reading manually here means "added organically by editors" rather than added "semi-automatically on large scales", since that would effectively be the same thing as a bot, without the benefits of a bot. Headbomb {t · c · p · b}13:38, 28 June 2017 (UTC)
I am writing to you behalf of Eastern Anatolia Observatory (DAG) directorate. First of all, we thanks to edit DAG page on wikipedia. But we are kindly asking to you correct some statement about DAG if you can make. In second paragraph part of "... with the scientific and technical coordination of TÜBİTAK National Observatory and financial support of the Ministry of Development..." is not correct. Could you please remove this part? Thanks in advance, for further information, please mail me: tugrul@atasam.atauni.edu.tr
Sayın beyefendi/hanımefendi,
Doğu Anadolu Gözlemevi (DAG) adına sizlerle iletişime geçmiş bulunmaktayım. Öncelikle DAG hakkında wikipedia girdileriniz için teşekkür ederiz. Ama yanlış olan bir kısmı düzeltmeniz için sizden ricada bulunuyoruz. İkinci paragrafta
"... with the scientific and technical coordination of TÜBİTAK National Observatory and financial support of the Ministry of Development..." kısmı taxmen yanlış olup tarafınızca kaldırılmasını rica ediyoruz. Şimdiden teşekkür ederiz. Haberleşebilmek için lütfen mail yazın: tugrul@atasam.atauni.edu.tr
IP, in the time it took you to write this, you could have made this edit yourself. Just say something like "does not appear in the reference" in the edit summary, if that is indeed true. All I've done is improve a reference on the page. ~Tom.Reding (talk ⋅dgaf)14:12, 5 July 2017 (UTC)
What exactly is the problem with the redirect ((rcat shell)) compared to calling its target ((Redirect category shell)) directly?
Is there some general policy or guideline that discourages the use of template redirects?
Is there a catastrophic (as opposed to minor) caveat for the performance of the MediaWiki software?
Or is it just a readability issue?
Upon reading further, I guess this may be related to the denied BRFA mentioned one section above. (I see that you used AWB, but under your main account, for the edit in question here.) My questions still stand. --SoledadKabocha (talk) 22:09, 26 July 2017 (UTC)
@SoledadKabocha: There is no problem at all with invoking a template via one of its redirects. It behaves in exactly the same way. If AWB is being used to bypass redirects (template or otherwise), this is not just against WP:NOTBROKEN but also WP:AWBRULES item 4, possibly rule 3 as well. --Redrose64 🌹 (talk) 07:10, 27 July 2017 (UTC)
I monitor the two categories to which your sandbox has been sorted, and I wonder if you have completed your tests, so that your sandbox can be removed from these categories? I was going to blank the sandbox, but then I thought better of it and wanted to ask you first. Paine Ellsworthput'r there16:18, 2 August 2017 (UTC)
Could you briefly explain the advantage to the author template, wherein each first name and each initial and each last name (whew!) is preferred vs my method of listing "authors"? Thanks, --Smokefoot (talk) 17:13, 12 September 2017 (UTC)
Smokefoot, sure—as Category:CS1 maint: Uses authors parameter states, Author names assigned to |authors= (or any of its aliases) are not made part of the template's COinS metadata. For this reason, use of |authors= is discouraged. Having that metadata is an asset (follow the link to learn more). Plus, the CS1 citation templates perform more checks on |author= than they do on |authors=, reducing common errors. ~Tom.Reding (talk ⋅dgaf)23:11, 12 September 2017 (UTC)
Thanks
You will receive the actual Award sometime in mid-January. It was supposed to be a surprise until then so I'm always curious when this "pre-awareness" glitch happens... And how it happens. Did you get a "ping"? No problem. I just want to know so I can fix if necessary. Take care and thanks. ―Buster7☎19:44, 9 December 2017 (UTC)
I did get a ping! And I figured I'd let you know so it doesn't happen unintentionally in the future :) (...also I'm part of 2 additional WikiProjects that I've now displayed :) ~Tom.Reding (talk ⋅dgaf)19:58, 9 December 2017 (UTC)
Reverting redirect. OpenACS and ACS deserve two separate articles, particularly consider that OpenACS is alive and well
I just saw that you reverted my change to the OpenACS redirect. I really feel that OpenACS deserves to have its own separate article. It's alive and well, and many of us make our living from it. Having it as a mention in another article isn't sufficient, particularly given the original ACS is now dead. If anything, the ACS should redirect to the OpenACS article, and could feature in a history section. Can you explanation your intentions? --Brian Fenton (talk) 14:15, 2 October 2017 (UTC)
Brian Fenton, I was hoping that in your search you would discover that 1) it was not I that reverted your changes, 2) you would actually read the edit summary to see that it is a result of this already-closed AfD, and 3) the article has not been improved on since it contains only WP:Primary sources. I agree with the original editor, Onel5969, that this should remain a redirect, unless it is improved. ~Tom.Reding (talk ⋅dgaf)16:50, 2 October 2017 (UTC)
Tom.Reding Sorry Tom, I'm not that familiar with the Wiki ins and outs. I just spotted a notification with your name on it. Anyway, I'm not going to argue with you. I have zero energy for dealing with deletionist nonsense. Apologies for misdirecting my irritation at you. --Brian Fenton (talk) 17:05, 2 October 2017 (UTC)
Jr. hacking
Tom, thanks for all your work on this. We had a discussion about defaultsort, and decided to leave out the comma before Jr. there, too, since Jr. can often follow a first name with no comma. I see you've gone the other way. We had some disagreements on which was best, but Mandruss and I, who did move of the work, agreed to do without. Dicklyon (talk) 00:12, 16 October 2017 (UTC)
Well, I haven't touched Jr/Sr on any existing ((DEFAULTSORT))s; the examples pages given at WP:JR/SR show no consistent usage so I thought it best to avoid changing (including reverting one of my previous edits) and to defer to others who've given that much closer inspection and much more thought. A handfull of my edits did add a ((DEFAULTSORT)) where none had existed, though, but it was the WP:GenFixes code which produced it, not my own. Given your direction, I'll modify any new WP:GenFixes DEFAULTSORTs which may arise to remove the preceding comma. Thank you for the background. ~Tom.Reding (talk ⋅dgaf)02:40, 16 October 2017 (UTC)
Correct, that was automatically produced by WP:GenFixes. I think this would qualify as a bug report to phabricator. Or, better yet, it might not even be a bug at all; it might instead be a case of GIGO, because the page on which it is operating has not had its unnecessary comma removed. I'll move the page and rerun GenFixes and see what happens. ~Tom.Reding (talk ⋅dgaf)03:30, 16 October 2017 (UTC)
The corrected page without the comma doesn't change ((DEFAULTSORT:Morgan, Carey Elmore, Jr.)), so this would qualify as a maintenance/bug fix. ~Tom.Reding (talk ⋅dgaf)03:36, 16 October 2017 (UTC)
If you goto Wikipedia talk:AutoWikiBrowser/Bugs "File a new bug report", you'll be taken to the Phabricator site (you may need to create an account, or have it recognize your Wikipedia account to log in), which you can use to fill out the form. If you want, I can file it tomorrow and add you as a subscriber so you can follow it. You'll probably be able to more precisely describe the problem than I or answer any questions that arise, too. ~Tom.Reding (talk ⋅dgaf)05:00, 16 October 2017 (UTC)
I see the moves are all done; congrats and thanks! Still need cleanup edits; should we have a bot do that, too, or should I just chip away at them manually? Dicklyon (talk) 01:58, 29 October 2017 (UTC)
Manually/semi-automatically is best now - they need a human eye, especially when a page uses a trailing comma after [JS]r., which may or may not need to be kept depending on the context. I stopped my Jr/Sr fixes while the BotReq was active, partly b/c I put in restrictions to exclude wikilinks from comma-removal. I can remove those restrictions now that all are done! Feels good. ~Tom.Reding (talk ⋅dgaf)14:29, 29 October 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This is not intended as a criticism of you, but I do not understand why the taxonbar template is of use when added to articles like Gonialoe variegata. The only database that is actually in line with the article, namely the World Checklist of Selected Plant Families, is not included. The Plant List, which is there, contains a very old extract from WCSP which is now well out of date. So the taxonbar contains a link which is just an out of date copy – the current WCSP information is at [2]. I can only assume that you don't actually look at the links you are adding – yet if these were separate external links it would have to be shown that each is relevant, and many of them clearly aren't. Peter coxhead (talk) 07:59, 23 October 2017 (UTC)
Here's another example. At Haworthiopsis pungens not only is the Plant List link out of date, but as with Gonialoe variegata, the IPNI link is wrong. It goes to the synonym, Haworthia pungens, and not the name used in the article, Haworthiopsis pungens. Peter coxhead (talk) 08:04, 23 October 2017 (UTC)
I'm afraid that's a result of the age-old garbage in, garbage out problem. ((Taxonbar)) gets its info from WikiData, so you'll have to update the information there. There could also be some transclusions which hard-code a species identifier (not on any pages I've edited though), but if WD info exists for that identifier, the WD info is used instead. And if no WD info exists for that page, the template hides itself. ~Tom.Reding (talk ⋅dgaf)11:58, 23 October 2017 (UTC)
But my question is why we here, in the English Wikipedia, should be adding templates that pick up "garbage" from Wikidata. If I added an incorrect link, like one to the wrong species, as a separate External link entry, I would expect it to be reverted. So why is it ok to add such links within the taxonbar template? Shouldn't we be checking that the Wikidata data isn't "garbage"? Peter coxhead (talk) 14:58, 23 October 2017 (UTC)
Yes, we should be checking WikiData, and you (or anyone else) are encouraged to do so. WT:TOL would be a better and broader venue for that, as my experience with, and ability to semi-automatically update it (I am looking though), are limited.
The underlying question here is then: what fraction of ((taxonbar))s produce "garbage", and what qualifies as "garbage", i.e. where > 50%? of the available links are too far off-topic? I'm far from being one to judge, of course. How about I pick 52 pages from the ~48k pages under Category:Species by IUCN Red List category (2 randomly chosen from each starting-letter, or perhaps fully-randomly), and we (perhaps the WT:TOL community) figure out how many of those are above and below the threshold? Jts1882, MCEllis, do you have any input? ~Tom.Reding (talk ⋅dgaf)15:32, 23 October 2017 (UTC)
I had a look at Wikidata, and it seems to me that this is yet another example of where the design of their database is simply wrong. The entity Q15516206 is described as a species of plant, i.e. the entity in the database is the species. But the entity in many of the linked databases, certainly IPNI, WCSP, Tropicos and TPL, isn't the species but the scientific name. (Well, to be really accurate, it's fully the name in the IPNI, and partially the name and partially the taxon in WCSP, etc., which give lists of synonyms.) Haworthia pungens is the same species as Haworthiopsis pungens, but they are different names and hence rightly have different entries in IPNI. It's not possible as far as I can tell to set up the entry in Wikidata so that the one species (entity Q15516206) links to multiple names each linked to a different entry in IPNI, WCSP, etc. (This is the essentially the same problem that arises when you try to link articles which are divided differently in different wikipedias. We divide Berry and Berry (botany), but other wikis have only one article – Wikidata only allows you to link one of our articles to theirs.) Scientific names and taxa and the database entries that correspond to them simply don't have 1:1 relationships to one another, but Wikidata insists they do.
The question still remains: what fraction of pages in Category:Species by IUCN Red List category have this problem when it comes to ((taxonbar))? If the error-fraction is, say, < 15% (subject to community discussion) I think the template is worth putting on, and having it removed from problematic pages.
Also: can these problematic pages be identified in some way? Perhaps through some wording or comparative testing in/within the article? ~Tom.Reding (talk ⋅dgaf)17:00, 23 October 2017 (UTC)
Am I correct in understanding that you are adding the ((Taxonbar)) to taxa pages based on the IUCN red list pages. If so, the absence of the genus Gonialoe from the IUCN database suggests that the taxa is erroneously on the red list or that the name has been changed since it was added. Either way this needs to be flagged and the appropriate wikipedia article(s) corrected. The Taxonbar wikidata link takes it to Aloe variegata rather than Gonialoe variegata, which has a much sparser collection of links. Jts1882 | talk17:08, 23 October 2017 (UTC)
The issue with Gonialoe variegata is that this is a recent name change from Aloe variegata. Many other wikis haven't caught up yet; we're ahead. The only way I can see to identify such problems is to look at the Wikidata entry. If you see that different scientific names are used for the same entity, then you know immediately that there is a problem, since the IPNI, WCSP, Tropicos, etc. links will be to only one of these scientific names and will be wrong for any wiki using another one. (Wikidata could be edited so that the link/identifiers match our scientific name, but then would be wrong for wikis using a different scientific name.) I don't know enough about the API to Wikidata to know whether you can automate the detection of different names; I suspect not, not least because in some cases articles are at the common name, which hides the underlying scientific name. Peter coxhead (talk) 21:40, 23 October 2017 (UTC)
Article titles using a common name aren't an issue as long as |taxon= or (|genus= & |species=) are available. The main issue is indeed semi-automating WikiData access just so I can perform a simple if-statement. ~Tom.Reding (talk ⋅dgaf)22:32, 23 October 2017 (UTC)
Taxonbar improvements
@Peter coxhead: If you see such glaring issues with Taxonbar links, rather than shaking your fists in the air and demanding the removal of Taxonbar from a page, you could simply fix the problems by adding missing data to Wikidata and linking the Wikipedia article with the correct Wikidata item. Wikidata is a place to organize data, and experienced Wikipedia editors need to understand that contributing missing information to Wikidata will actually help improve Wikipedia articles and make the life of other editors easier. Wikidata should not be treated like it is some lab experiment gone wrong. I have addressed the issues and re-added Taxonbar to Gonialoe variegata. Of course things go wrong with taxonomy changes. Taxonbar now fully supports the latest WCSP, which I agree should be the standard Wikipedia follows for plant taxonomy. --MCEllis (talk) 02:22, 29 December 2017 (UTC)
@MCEllis: personally, I continue to regard the taxonbar template as pointless, but I have no wish to interfere with other editors who want to add it, unless it is wrong. Both of the links to Wikidata in the Gonialoe variegata article (the one in the margin and the one in the taxonbar) are wrong. They suggest there are no articles about this taxon in other wikipedias, whereas there are 17. The problem remains that Wikidata has no way of representing the fact that Q159136 and Q39719922 are one and the same taxon under different names. The least bad link is Q159136. Peter coxhead (talk) 09:26, 29 December 2017 (UTC)
A problem with Wikidata is that the entries are usually incomplete. There are properties for taxon synonyms (incorrect names), replaced synonyms (for nov. nom.), basionyms, and origin combinations (see WikiProject_Taxonomy). Normally synonyms seem to get added to the "also known as" element, which isn't really part of the data structure. I've added a replaced synonym statement to wikidata:Q39719922 (although it needs a reference), so the Gonialoe varigata item now has a link to the wikidata item on the name it replaced. This now indicates that they are the same species.
A second problem is that there is one Wikidata and many language Wikipedias. If other language Wikipedias point to Wikidata item of an old name, there doesn't seem to be a way of directing people to the newer name. What is needed is an "accepted name" property to add to the Aloe varigata item to indicate the name has been replaced. The WCSP database has multiple entries (490610 and 298109), but their page on the older name has a link to the new accepted name.
In lieu of an accepted name property, the reccommended approach is to use an "instance of synonym" statement. I've added one to the Wikidata item for Aloe varigata to indicate that it is an instance of synonym of Gonialoe varigata. This now seems to make the relationships between the two "taxa" clear both ways. Jts1882 | talk13:37, 31 December 2017 (UTC)
A question for Wikidata is whether the Gonialoe varigata item should point to other lanaguage wikipedia articles that haven't been updated (they are on the same species, just with a different name). If they are it will lead to inconsistencies between Wikipedias and Wikidata, but if they aren't there is consistency due to ignorance. Jts1882 | talk11:24, 29 December 2017 (UTC)
@Jts1882: my answer to the question you asked above is that the English Wikipedia article should link to all the other wikipedia articles on the same taxon – the articles are about the taxon, not the name. When editors could add inter-language links to articles, this is what we would always have done. But now that we have (foolishly in my view) handed this ability off to Wikidata, we are stuck with their incorrect data analysis and representation. So the least bad move is to link all the wikipedia articles to Aloe variegata (Q159136). Peter coxhead (talk) 12:23, 29 December 2017 (UTC)
@Peter coxhead, Jts1882, Tom.Reding, and Plantdrew: All of these are fair points (except for calling Taxonbar pointless), I agree with Peter that considering the setup we have now it would be best if all the Wikipedia articles remain linked together to the same Wikidata item, irregardless of taxonomy issues. So for Gonialoe variegata, it would be best to associate the article with Aloe variegata (Q159136).
IN ADDITION, it seems to me that Taxonbar should always be linked to the correct taxonomy. So on Gonialoe variegata, I would use the code ((taxonbar|from=Q39719922)). Does this seem logical?
@MCEllis: note that when you use the 'correct' Q39719922, taxonbar picks up fewer databases, because they haven't been updated to include the now accepted name.
What I think is needed to make taxonbar more useful is to be able to include Wikidata identifiers for all synonyms, given that the Wikidata entities are actually names, not taxa. We need syntax like ((taxonbar|from1=Q39719922|from2=Q159136)) which would then show multiple links to those databases that have entries for each of the synonyms. In default of that, you need to add multiple taxonbar templates to articles like Gonialoe variegata, one for each synonym that exists in Wikidata.
I like the idea of |from1=, |from2=, etc., but that would just be a kludge. Surely WikiData:Taxonomy (what's the correct link, anyway? the one a few comments above is effectively a redlink) has had a discussion on this topic. Did they consider these possibilities?
If we take the time & effort to enumerate all of the synonym IDs in taxonbars on en.wiki, we might as well do it in WikiData, and instead we would make a ((taxonbar)) parameter like |synonyms=yes (or |synonyms=no) that toggles synonym displays from whatever their default state would be. |from= could be a short-term stop-gap measure available for editors not familiar with WikiData (myself kind of included), to then be subsumed into WD by someone knowledgeable (we could even make a tracking category). ~Tom.Reding (talk ⋅dgaf)16:29, 29 December 2017 (UTC)
I would not support mixing links of two different Wikidata entries into one Taxonbar. This would cause confusion. They would have to be clearly seperated, and possibly labeled as synonym identifiers.--MCEllis (talk) 17:34, 29 December 2017 (UTC)
Ok, so perhaps |fromN=is the right next step—case-by-case refinements, no large-scale changes/breakages/complaints/etc; a tracking cat would be nice/needed to easily keep track of which templates use |fromN=, though. We can take a look at the field after a while and go from there.
Peter coxhead & Jts1882, in an effort to create a short(ish) list of sorts where ((taxonbar)) has the highest probability of being useful, my time playing with the IUCN APIs might have helped. What do y'all think of this scheme for stricter placement of the template:
The taxon must exist in the IUCN database (Gonialoe variegata, Aloe variegata, Haworthia pungens, Haworthiopsis pungens, for example: allfourdonot).
The ID produced by this |taxon=/|binomial= IUCN lookup must also match the weblink lookup. I've found this to eliminate most of the WP pages (I haven't found any problem pages yet) that deviate from the IUCN, either by synonym or other discrepancy.
Avoid pages with (((Taxobox)) or ((Speciesbox))) and (|subspecies=<something>, |trinomial=<something>, |binomial2=<something>, or |subdivision_ranks=(Sub)?Species).
Verify that the WikiData value for the IUCN ID matches the IDs in filter #2.
This seems a sensible approach. Only add the Taxonbar when it adds at least one verified and useful source. I think the IUCN certainly qualifies for this, at least with animals and especially mammals. With plants it strikes me that the Kew WCSP checklist is the most suitable data source, but this isn't handle by Taxonbar. I saw somewhere that it was discussed but the discussion seemed to peter out after it was suggested that the Plant List already includes the information. From the comment by Peter coxhead above it seems that the Plant List version isn't updated as frequently. This suggests to me that it should be added to TaxonBar.
I have been looking at the reliability of the IUCN status entries in Wikidata and it seems they are very reliable. If the IUCN assessment name matches the Wikipedia page name (or a redirect) and the Wikipedia article points to a Wikidata item with an IUCN assessment statement, then the IUCN status and assessment link on Wikidata are correct (in all the cases I've tried). There are some IUCN pages where there is no corresponding Wikidata entry with an IUCN assessment (e.g. recently renamed species like Gonialoe variegata), but here the the information is not available rather than incorrect and your protocol wouldn't add the Taxonbar. A status mismatch sometimes occurs when the IUCN subspecies assessment redirects to an article on the species which has a different status overall to a rare subspecies, but the Taxonbar will point to the species item so there is no error on Wikipedia. There are also a few oddities where the common name (and Wikipedia article) covers more than one species assessed by the IUCN. However, these all fail to find a Wikidata IUCN status rather than yield incorrect results. If a Wikidata IUCN status entry can be found it is reliable. Jts1882 | talk13:25, 11 November 2017 (UTC)
Re: where the common name (and Wikipedia article) covers more than one species assessed by the IUCN, would my filter #3 or #4 apply to these pages, and, if not, is there a way to filter them out? I would argue that these pages have incorrectly used |binomial= or |taxon=. Is that correct, and is there a way to find them? Semi-automatically checking for an entry in WikiData is not an option unfortunately, as far as I know. ~Tom.Reding (talk ⋅dgaf)13:42, 11 November 2017 (UTC)
My test ran for over 3800 mammals from the IUCN assessment list and checked wikidata for each. One of the mismatches was the Anoa, which includes species Bubalus quarlesi and Bubalus depressicornis. The ((taxobox)) used |binomial= and |binomial2=. The Wikipedia page pointed to Wikidata Q30571870, which is a sparce page with no useful information. My understanding is your scheme would find the Anoa Wikipedia page via the redirects. Checking I see you did add the taxon bar, which only has the Wikidata item. If you could also check Wikidata for an IUCN entry, you wouldn't add the Taxonbar without one. Jts1882 | talk15:07, 11 November 2017 (UTC)
I see, so you scraped the HTML of the WP page to find the WD ID? Then scraped the WD HTML for the species ID? Then I can check that that ID matches the IDs from filter #2?! Yeah, that's a hell of a kludge, but it should have a 0 or near-0 false positive %.
My scheme doesn't look at the redirects. It starts off by first looking at the |binomial= or |taxon=. If that doesn't work then it tries to create one using |genus= & |species=, assuming the subspecies giveaways in the other filters don't exist. When I was adding the ((taxonbar)) to Anoa, however, I wasn't aware of these issues, so I didn't perform any checks. ~Tom.Reding (talk ⋅dgaf)15:35, 11 November 2017 (UTC)
I didn't use the HTML. I used the APIs for the IUCN red list, wikipedia and wikidata to get the data with a JS script, as follows:
Used the IUCN API to get a list of species ("/api/v3/species/page/1")
For each scientific name, used the Wikipedia API to get the wikibase item ("/w/api.php?action=query&format=json&prop=pageprops&titles=Panthera%20leo&redirects=1&formatversion=2&ppprop=wikibase_item"). The call handles the redirects from the scientific name to the appropriate Wikipedia page (same name, synonym or common name).
Used the Wikidata API to get data for the Wikidata ID ("/w/api.php?action=wbgetentities&format=json&ids=q140").
Then I just compared the wikidata values for the IUCN id (P627) and IUCN conservation status (P141) with the data from the IUCN. Jts1882 | talk16:43, 11 November 2017 (UTC)
Filter #5 added to use WikiData. I never knew about the WP & WD APIs! That's great! I'll definitely poke around a bit with them.
I prefer to start with the WP page text though, since that's the most straight-forward way, and the easiest way for anyone to double-check and/or fix. I've included |binomial2= in my filters too. ~Tom.Reding (talk ⋅dgaf)17:53, 11 November 2017 (UTC)
Request
One thing I find valuable about taxonbars is the absence of expected databases. If I see that the taxonbar for a plant species doesn't display a link to The Plant List, it's likely that TPL treats that species as a synonym, or at best, unresolved, and Wikipedia should perhaps not have an article on that species. Absence of a taxonbar IUCN link is a real problem for anything that has an IUCN status. When I editdTaraxacum farinosum, it had an IUCN status, but it's not actually listed in IUCN. In my experience, this situation is usually the result of somebody copy-pasting a taxobox from a related species and neglecting to remove IUCN status parameters. Any chance you could filter for species with an IUCN status that aren't actually listed in IUCN? Plantdrew (talk) 04:28, 13 November 2017 (UTC)
Not quite. I've since realized what I wanted to find probably isn't possible. Taxoboxes are typically generated by copy-pasting from a related species into a new article. Not infrequently, I find conservation statuses that have been inappropriately copy-pasted to a species where they don't apply. I was hoping to filter for articles that had an IUCN status (inappropriately), but which weren't actually in the IUCN database. But I don't think these cases can readily be separated from cases where the species is in the IUCN database, but under a synonymous scientific name. Plantdrew (talk) 15:29, 17 November 2017 (UTC)
This is doable and worthwhile. I think I can search IUCN for synonyms/aliases (need to double check that). Then I'll just need your help with refining what not/to filter. For example, how is Kukumainot what you're looking for (it seems to have an erroneous LC, that's for Chrysichthys grandis instead of Bathybagrus grandis)? ~Tom.Reding (talk ⋅dgaf)15:40, 17 November 2017 (UTC)
Chrysichythys grandis is a synonym of Bathybagrus grandis. I understand you are being cautious and avoiding any cases where the scientific name used by the IUCN doesn't match the name used by Wikipedia, and taxonomic synonyms fall into that area. Gonialoe variegata aside, I don't think there is necessarily anything wrong with including IUCN status for cases where Wikipedia treats the name used by IUCN as a synonym. We definitely need to have a reference that establishes that synonymy though. I'm not sure if possible to easily separate the IUCN synonym cases from the copy-paste error cases I'm concerned about. Plantdrew (talk) 15:58, 17 November 2017 (UTC)
It wouldn't make any sense not to include IUCN assessments just because Wikipedia uses a different synonym. As you say, we just need a proper reference to verify the synonym. In many cases the IUCN assessment will provide that.
The IUCN API does provide searches for synonyms (/api/v3/species/synonyms/Chrysichthys grandis) and common names (/api/v3/species/common_names/Chrysichthys grandis). In this case it returns the common name Kukumai, but not the synonym Bathybagrus grandis. One thing to be wary of is a common name used for more than one species. Unfortunately, you have to know the name used by the IUCN, you can't use a synonym for find the relevant IUCN article. The new combination Bathybagrus grandis is the valid name according to Fishbase, which cites the Catalog of Fishes. However, Catalog of Fishes currently has Chrysichthys grandis as the valid name, as does FishwisePro. Fortunately, the wikipedia article uses the common name. Jts1882 | talk08:29, 18 November 2017 (UTC)
I have a list of ~800 pages which produced a "species not found!" errors from a little over half of the pages with a red list category. I'll remove the ones with a valid synonym to decrease the false-positive rate and post the results here. ~Tom.Reding (talk ⋅dgaf)14:15, 18 November 2017 (UTC)
Of those 800, I was only able to straight-forwardly use the IUCN API to find the synonym for 1 page, Syncope bassleri. Very disappointing! Jts1882, I now see why you grab the redirects to a particular page. I suppose the only other alternative is to parse the text in the |synonyms= parameter, but that would get messy and presumably less reliable. (WP:ASTRO has a similar #R-structure for their oft-renamed meteors, but there is a preference for the most up-to-date name)
Plantdrew, this is still doable though. I could iterate through each of the redirects to each of the 800 pages, and remove one of the 800 if at least one of its #Rs has an IUCN match. If no IUCN match, via API and via #R-enumeration, that would qualify as a true-positive, yes? Jts1882, what would you say the false-synonym-rate is in this #R structure? ~Tom.Reding (talk ⋅dgaf)04:03, 19 November 2017 (UTC)
I'm a bit confused about exactly what you are asking. I assume #R means redirects. I didn't do anything explicitly with redirects as the wikipedia and wikidata API calls can be used with a redirect flag. I started with the IUCN scientific name (lists of a order or family) and the redirects find the appropriate wikipedia page when different names are used. This mostly helped with subspecies assessments by the IUCN. For instance, the 340 IUCN assessments in Carnivora returned 267 matches to wikidata. The redirect helped in 14 matches, four for species synonyms and ten involving subspecies. My understanding is that you are starting from wikipedia pages so I'm not sure this helps. Jts1882 | talk16:57, 1 December 2017 (UTC)
I'm about to start cycling through the #Rs (shorthand for redirects) to find relevant synonyms, as using the synonym API (and starting from the wikipedia pages) for these cases was essentially useless.
I'm most concerned about the thoroughness of the synonym #Rs, and if all (or most) pages have all (or most) of their synonyms as #Rs. I.e., if only 50%ish of pages have all of their synonyms #R'd, I probably wouldn't bother. It seems implied though, from what you've said on the matter, that this % is higher. ~Tom.Reding (talk ⋅dgaf)17:22, 1 December 2017 (UTC)
Across all organisms, the number of synonym redirects is pretty low. Generally speaking, |synonym= in taxoboxes gets filled in before any redirects are created, and there are only 81,469 of 268,999 taxoboxes with |synonym= (granted, there are some species, mostly recently described, that simply don't have any synonyms). However, for species with IUCN assessments, I'd expect that the number of synonym redirects will be relatively high (~47k articles with manual taxoboxes have a ((para|status} and ~27k have both |status= and |synonyms=). Plantdrew (talk) 18:02, 1 December 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
WL Sources
Hi Tom, could you please stop making edits like this one? It's not required to have such links within citations, and on some articles we've established a consistent citation style that eg. links only on first appearance. Nikkimaria (talk) 15:37, 24 October 2017 (UTC)
I page is still internally consistent, yes? I've gotten some thanks on these edits too, so I'll halt editing but defer to WT:Canada for guidance (all of the WLs I'm adding are related to Canada). ~Tom.Reding (talk ⋅dgaf)15:45, 24 October 2017 (UTC)
No, it wouldn't be internally consistent, as you're not doing this for all sources but only selected ones - other sources would not follow that model. And even if it were, that's verging on a WP:CITEVAR issue. Nikkimaria (talk) 15:53, 24 October 2017 (UTC)
That would be less problematic but it's still possible for articles at those levels to have an established citation style. Why do you want to do this in the first place? Nikkimaria (talk) 16:04, 24 October 2017 (UTC)
I do a lot of reference-gnoming and, while doing so, noticed many well-formatted and consistent authors/editors/publishers/work/agencies on Canadian-related pages. Figured I'd take it a step further. ~Tom.Reding (talk ⋅dgaf)16:13, 24 October 2017 (UTC)
Okay. Previous discussions around this issue have not reached a consensus in favour of this type of linking, certainly not to the level you'd need to do it via AWB (which requires that the change be non-controversial). See for example 1, 2. Nikkimaria (talk) 16:57, 24 October 2017 (UTC)
That is some excellent archive-diving there. Are we in agreement then that I can continue as long as I restrict WLs to the first appearance only, and only for stub, start, and C class articles? Perhaps later to > C class articles, if no further objections at that point? ~Tom.Reding (talk ⋅dgaf)17:09, 24 October 2017 (UTC)
Hm. I wouldn't object to that, but I'm not convinced this is something you could or should be doing via AWB without an established consensus for it. Nikkimaria (talk) 17:23, 24 October 2017 (UTC)
Hi Tom.Reding. I see that you've been spending a lot of time adding wikilinks to publisher names in citations. Such links are really not very useful. A reader looking at a citaition in an article is rarely going to want or need to see the article on the publisher of the cited work. Wikilinks to citation publishers aren't really harmful, but they are pretty much a waste of time, and they clutter the references with unnecessary links that distract from the actual useful links to the cited content.--Srleffler (talk) 02:40, 9 November 2017 (UTC)
I believe your WP:Overlinking concern is satisfied by my WLing the first occurrence only. Further, I'm only applying WLs to pages with <= 25 references, <= C class, and so far only on articles in the WP:Astronomy hierarchy to a depth of 5. Whether or not it's "a waste of my time", however, is of no one's concern but mine. ~Tom.Reding (talk ⋅dgaf)22:15, 9 November 2017 (UTC)
When updating IUCN status, update the citation too
It is great too see somebody doing IUCN status updates. But please pay attention to updating the citations too, as needed. Like here for Aquiloeurycea praecellens, you updated the status to PE (from the 2016 assessment), but the citation given is for the 2010 assessment, which was CR. Facts should be consistent with the corresponding citations. Micromesistius (talk) 18:21, 7 November 2017 (UTC)
Will do. The only time this can't be (quickly) done automatically is when the reference given in |status_ref= is used elsewhere on the page. I might be able to code for this too, but it will take some time. ~Tom.Reding (talk ⋅dgaf)18:29, 7 November 2017 (UTC)
That exception has now been accounted for; ~160 pages to go. There are some other minor exceptions, but this will cover the bulk of them. Will update here when done back-updating |status_ref=s. ~Tom.Reding (talk ⋅dgaf)17:10, 10 November 2017 (UTC)
Hi Tom, I've seen several edits on pages like here where you've coded the |access-date= in a reference with ((CURRENTDAY)) ((CURRENTMONTHNAME)) ((CURRENTYEAR)). Won't that make the date retrieved always be the current date? So it would appear that the reference had been checked and updated, if needed, every day? I don't think that's what I'd intend if I were doing it. Am I understanding this right? SchreiberBike | ⌨ 07:08, 9 November 2017 (UTC)
Ahh, damn it. I tried subst'ing at first but it doesn't work. I thought I was just using the wrong syntax, but it might be because it's doubly nested in an infobox and citation? Will have to hard code. I was going to go through them again with my author parser anyway, so will make the access-date change concurrently. ~Tom.Reding (talk ⋅dgaf)12:13, 9 November 2017 (UTC)
Hello, Tom.Reding. Your account has been granted the "extendedmover" user right, either following a request for it or demonstrating familiarity with working with article names and moving pages. You are now able to rename pages without leaving behind a redirect, and move subpages when moving the parent page(s).
Please take a moment to review Wikipedia:Page mover for more information on this user right, especially the criteria for moving pages without leaving redirect. Please remember to follow post-move cleanup procedures and make link corrections where necessary, including broken double-redirects when suppressredirect is used. This can be done using Special:WhatLinksHere. It is also very important that no one else be allowed to access your account, so you should consider taking a few moments to secure your password. As with all user rights, be aware that if abused, or used in controversial ways without consensus, your page mover status can be revoked.
One thing I find valuable about taxonbars is the absence of expected databases. If I see that the taxonbar for a plant species doesn't display a link to The Plant List, it's likely that TPL treats that species as a synonym, or at best, unresolved, and Wikipedia should perhaps not have an article on that species. Absence of a taxonbar IUCN link is a real problem for anything that has an IUCN status. When I editdTaraxacum farinosum, it had an IUCN status, but it's not actually listed in IUCN. In my experience, this situation is usually the result of somebody copy-pasting a taxobox from a related species and neglecting to remove IUCN status parameters. Any chance you could filter for species with an IUCN status that aren't actually listed in IUCN? Plantdrew (talk) 04:28, 13 November 2017 (UTC)
Not quite. I've since realized what I wanted to find probably isn't possible. Taxoboxes are typically generated by copy-pasting from a related species into a new article. Not infrequently, I find conservation statuses that have been inappropriately copy-pasted to a species where they don't apply. I was hoping to filter for articles that had an IUCN status (inappropriately), but which weren't actually in the IUCN database. But I don't think these cases can readily be separated from cases where the species is in the IUCN database, but under a synonymous scientific name. Plantdrew (talk) 15:29, 17 November 2017 (UTC)
This is doable and worthwhile. I think I can search IUCN for synonyms/aliases (need to double check that). Then I'll just need your help with refining what not/to filter. For example, how is Kukumainot what you're looking for (it seems to have an erroneous LC, that's for Chrysichthys grandis instead of Bathybagrus grandis)? ~Tom.Reding (talk ⋅dgaf)15:40, 17 November 2017 (UTC)
Chrysichythys grandis is a synonym of Bathybagrus grandis. I understand you are being cautious and avoiding any cases where the scientific name used by the IUCN doesn't match the name used by Wikipedia, and taxonomic synonyms fall into that area. Gonialoe variegata aside, I don't think there is necessarily anything wrong with including IUCN status for cases where Wikipedia treats the name used by IUCN as a synonym. We definitely need to have a reference that establishes that synonymy though. I'm not sure if possible to easily separate the IUCN synonym cases from the copy-paste error cases I'm concerned about. Plantdrew (talk) 15:58, 17 November 2017 (UTC)
It wouldn't make any sense not to include IUCN assessments just because Wikipedia uses a different synonym. As you say, we just need a proper reference to verify the synonym. In many cases the IUCN assessment will provide that.
The IUCN API does provide searches for synonyms (/api/v3/species/synonyms/Chrysichthys grandis) and common names (/api/v3/species/common_names/Chrysichthys grandis). In this case it returns the common name Kukumai, but not the synonym Bathybagrus grandis. One thing to be wary of is a common name used for more than one species. Unfortunately, you have to know the name used by the IUCN, you can't use a synonym for find the relevant IUCN article. The new combination Bathybagrus grandis is the valid name according to Fishbase, which cites the Catalog of Fishes. However, Catalog of Fishes currently has Chrysichthys grandis as the valid name, as does FishwisePro. Fortunately, the wikipedia article uses the common name. Jts1882 | talk08:29, 18 November 2017 (UTC)
I have a list of ~800 pages which produced a "species not found!" errors from a little over half of the pages with a red list category. I'll remove the ones with a valid synonym to decrease the false-positive rate and post the results here. ~Tom.Reding (talk ⋅dgaf)14:15, 18 November 2017 (UTC)
Of those 800, I was only able to straight-forwardly use the IUCN API to find the synonym for 1 page, Syncope bassleri. Very disappointing! Jts1882, I now see why you grab the redirects to a particular page. I suppose the only other alternative is to parse the text in the |synonyms= parameter, but that would get messy and presumably less reliable. (WP:ASTRO has a similar #R-structure for their oft-renamed meteors, but there is a preference for the most up-to-date name)
Plantdrew, this is still doable though. I could iterate through each of the redirects to each of the 800 pages, and remove one of the 800 if at least one of its #Rs has an IUCN match. If no IUCN match, via API and via #R-enumeration, that would qualify as a true-positive, yes? Jts1882, what would you say the false-synonym-rate is in this #R structure? ~Tom.Reding (talk ⋅dgaf)04:03, 19 November 2017 (UTC)
I'm a bit confused about exactly what you are asking. I assume #R means redirects. I didn't do anything explicitly with redirects as the wikipedia and wikidata API calls can be used with a redirect flag. I started with the IUCN scientific name (lists of a order or family) and the redirects find the appropriate wikipedia page when different names are used. This mostly helped with subspecies assessments by the IUCN. For instance, the 340 IUCN assessments in Carnivora returned 267 matches to wikidata. The redirect helped in 14 matches, four for species synonyms and ten involving subspecies. My understanding is that you are starting from wikipedia pages so I'm not sure this helps. Jts1882 | talk16:57, 1 December 2017 (UTC)
I'm about to start cycling through the #Rs (shorthand for redirects) to find relevant synonyms, as using the synonym API (and starting from the wikipedia pages) for these cases was essentially useless.
I'm most concerned about the thoroughness of the synonym #Rs, and if all (or most) pages have all (or most) of their synonyms as #Rs. I.e., if only 50%ish of pages have all of their synonyms #R'd, I probably wouldn't bother. It seems implied though, from what you've said on the matter, that this % is higher. ~Tom.Reding (talk ⋅dgaf)17:22, 1 December 2017 (UTC)
Across all organisms, the number of synonym redirects is pretty low. Generally speaking, |synonym= in taxoboxes gets filled in before any redirects are created, and there are only 81,469 of 268,999 taxoboxes with |synonym= (granted, there are some species, mostly recently described, that simply don't have any synonyms). However, for species with IUCN assessments, I'd expect that the number of synonym redirects will be relatively high (~47k articles with manual taxoboxes have a ((para|status} and ~27k have both |status= and |synonyms=). Plantdrew (talk) 18:02, 1 December 2017 (UTC)
Plantdrew, I'm starting to work on this, and finding errors like Northern death adder, which have an IUCN status in their infobox but don't exist (afaict) in the IUCN database; and skipping things like Popta's buntingi, which was found on IUCN via its first mainspace #R. If the article title/infobox binomial DNE on IUCN, I'm then using WP #Rs, and IUCN synonyms of those #Rs, if necessary (i.e. if the #R itself fails the IUCN check) to validate IUCN existence. I'm using IUCN's weblink api as my validation mechanism, as long as it doesn't say "species not found". Let me know what you think of this approach. Should produce better results than previous attempts above (even this one result makes it better...). If no problems, will post results later on. ~Tom.Reding (talk ⋅dgaf)15:02, 2 March 2018 (UTC)
The status for northern death adder is bogus. Could you give me a few more examples of the matches you're finding by this approach? I'm concerned that in cases of synonymy due to species lumping/splitting, the IUCN assessment may not apply to the broader/narrower species concept. There shouldn't be a problem when the synonymy is due to transfer to a different genus. I'd be wary of cases where the species epithets are totally different as that can indicate lumping/splitting. If all but the last two characters of the epithet match, that gets at genus transfers (the ending of the epithet changes to be in agreement with the grammatical gender of the genus; e.g. americana can become americanus).
With splitting there is going to be one intractable (I think) problem; one of the split entities retains the original name. There's a bit of a mess with the giraffe articles; we have several species articles, including northern giraffe, with Giraffa camelopardalis redirecting there, but G. camelopardalis is also the name used if only one (living) giraffe species is recognized. IUCN recognizes a single giraffe species. I'm not sure how you'd catch this problem (although the taxobox was removed from northern giraffe a couple of days ago, so this particular case won't show up in your search at the moment). Plantdrew (talk) 19:12, 2 March 2018 (UTC)
Plantdrew, sure - picking 3 from the beginning, middle, and end of my original list of ~800 species suspected to not be on the IUCN: Luzula sylvatica nor its 9 #Rs, Western warbling vireo nor its 6 #Rs, & Labidochromis chisumluae (0 #Rs) were programmatically confirmed as not existing on IUCN. The more #Rs a page has, the more confidence there is in the outcome (hopefully). I've confirmed that ~400 of them do exist on IUCN and tentatively confirmed that the other half do not. For those that DNE on IUCN: there are ~182 with 0 #Rs (mostly sub/stubs), 72 with 1 #R, 56 with 2 #Rs, 24 with 3 #Rs, 20 with 4 #Rs, 13 with 5 #Rs, 25 with 6-9 #Rs, and 11 with 10 #Rs. Let me know which or how many you want (possibly the ~200 with >= 1 #R?), if all ~400 is too much to go through manually.
What I did may or may not pick up problems similar to giraffe. I think it would probably come down to what #Rs are available and where they're pointing, hence the need for manual followup, and at least it's a bit more manageable now. ~Tom.Reding (talk ⋅dgaf)01:41, 3 March 2018 (UTC)
Whoops. I didn't review the entire thread earlier. I forgot I'd kicked this off, and where I had been going with it. In my previous comment I was thinking you were looking through synonyms to find articles that didn't have IUCN status but should. You can pretty much ignore that comment. You're looking for articles that do have an IUCN status but shouldn't (as I'd requested initially).
OK. You are picking up some anomalies. Luzula sylvatica was evaluated against IUCN criteria for United Kingdom populations only. Conservation status in taxoboxes should be global (although national assessment systems can be appropriate for species endemic to that nation). The UK status is referenced though, so I could maybe move that out of the taxobox and into the text. Western warbling vireo is apparently treated as a subspecies now, Vireo gilvus swainsonii, and was removed from the IUCN database (it's a Polbot created article, so I'm pretty certain it was in IUCN previously). I should look into editing that article for subspecies treatment. Labidochromis chisumluae is a misspelling of Labidochromis chisumulae that apparently originated on IUCN and has since been corrected (Polbot created the enwiki article and viwiki also has a bot created article at the misspelling). I should move the article to the correct spelling.
Figuring out what should be done with these three took some time, and the solution for all is more complicated than simply deleting the IUCN status. The ~200 with >=1 #R will keep me busy for awhile. Let's start with those. Plantdrew (talk) 02:46, 3 March 2018 (UTC)
Plantdrew, great! I hope you won't mind me posting it to your talk, or somewhere else if you'd like (sometime later tonight, or tomorrow since I'm rerunning parts of it). I'll include a detailed explanation of where the list came from, condensed from above, for continuity. At first, I left this discussion here as a to-do reminder and now it's holding up my archiving(!), which I want to keep more-or-less chronological. ~Tom.Reding (talk ⋅dgaf)03:34, 3 March 2018 (UTC)
Dicklyon, thanks for thinking of me! Unfortunately, I don't have the permissions to semi/automate page moves in AWB, nor any experience using PyWikiBot, so this has to be either a WP:BOTREQ like the Jr/Sr fixes, or ping the bot-op who performed that request (found them). It will go a lot faster this time though, since you've already taken care of the VPP part. ~Tom.Reding (talk ⋅dgaf)12:00, 17 November 2017 (UTC)
I meant I could use your help setting up a bot request; whatever you did last time. I did the centralized discussion for approval after you had it ready to go, iirc, and maybe won't have to do that again as you say. Or I can ask him myself if that's your preference. Was there any data preparation needed, or did you just point him at the page that Certes made? Dicklyon (talk) 03:41, 18 November 2017 (UTC)
Oh, I'm not really invested in the Station moves, so it would be best for you to do it (plus it'll be good practice :). All I did (after properly vetting the Jr/Sr pages for false positives) was submit this bot request by clicking the "Make a new request" button at the top of the page. Use it as a starting point, and include a link to the VPP discussion. The request then got picked up by a willing & able bot operator. The bot operator then has to go through their own process, WP:BRFA, which may or may not need your input (i.e. if the request has any flaws/caveats/exceptions; you'll be notified if so). I already watch those pages and will help if I can. ~Tom.Reding (talk ⋅dgaf)14:33, 18 November 2017 (UTC)
If you would do that, and collect a list of which ones moved and which ones didn't, I'll work on the leftovers (I think there won't be a lot), and AWB users like Tom can help with the case cleanup in the articles. Thanks! Dicklyon (talk) 17:59, 20 November 2017 (UTC)
Thank you! I'll have a closer look at Avondale. Ntitle=o howls of protest, so I've started the page edits to fix titles etc. I'm working alphabetically and have paused at Beijing in case there is a reaction. Would you be able to shift Baltiysky Railway station to small r manually for me please? There's a redirect with history in the way. Courtesy ping: Dicklyon. Certes (talk) 01:30, 6 December 2017 (UTC)
@Dicklyon: I've sorted out ambiguities in Avondale, Grafton, Huntly and Linden. There are still a few to go: Kingland, Marton, Morningside, Panmure, Penrose and Stoke. Unfortunately this is a very slow process: keeping all the links working involves a lot of intricate edits to templates in non-obvious locations. (Example: Warsaw breaks Düsseldorf Hauptbahnhof until you edit ((Nederlandse Spoorwegen stations)).) I am unable to fix all of the breakage in New Zealand, because ((NZR sl)) only recognises "Railway Station" as specified in WP:WikiProject NZR/Manual of style. Has anyone spoken with the NZ people yet? Certes (talk) 16:04, 7 December 2017 (UTC)
As for going through the text of these semi-automatically, I'm afraid I'm buried pretty deep (mentally & emotionally) in reference/citation syntax with my IUCN efforts. Perhaps after I climb out. ~Tom.Reding (talk ⋅dgaf)16:10, 7 December 2017 (UTC)
That does look pretty horrible; essentially unmaintainable code. If something changes, which breaks the template's expected behavior, and someone notices the problem, it's still very difficult for them to figure out how to fix it, or where to ask to find someone who can fix it, right? Or is it not as bad as it seems to me? Dicklyon (talk) 04:35, 17 December 2017 (UTC)
I think I've sorted out all the complex cases (most required more moves and a dab page) so I've resumed the bulk edit (A-C done). Do we want to edit the 496 templates too? That would tie up the loose ends but might have unintended consequences. I've already changed several templates manually where safe, especially in New Zealand, and an IP editor has helped. (New Zealand was using upper case to distinguish their Panmure Railway Station from an Australian namesake Panmure railway station. Both now link to a new dab. There were several other similar cases.) Certes (talk) 18:13, 11 December 2017 (UTC)
Heh, actually this is still on my to-do list, just farther down (after IUCN conversion, but before all the remaining Jr/Sr fixes still out there). I don't mind discussion here, but if there's a more appropriate venue, go with that. ~Tom.Reding (talk ⋅dgaf)12:23, 22 December 2017 (UTC)
The end?
@Dicklyon: It's been a while but I think we're finally there, or as close as we're likely to get. Changes have been particularly extensive in China, New Zealand and Thailand. The one area outstanding is Malaysia and Singapore. I've done as much as I can, especially with the lines around Kuala Lumpur, but I'm going to declare the rest out of scope as it uses Station rather than Railway Station. An old discussion at Template talk:LRT Station suggests firm support for keeping the naming inconsistent, so I doubt there's much chance of improving pages such as ((Rapid Rail network)) and ((Kelana Jaya Line)). Thanks to Tom, Dick and any other helpers who may be following this thread. Certes (talk) 21:32, 22 January 2018 (UTC)
We just had a bunch moved in Singapore, by multi-RM discussion at Talk:Aljunied_MRT_station#Requested_move_7_January_2018. Station, not railway station. I'll keep working on such clusters. This RM was about the MRT stations, but mentioned that LRT stations need to be done, too. Similar in some other countries. That quarry tool is awesome. It shows we have about 15,000 "%_Station" and 26,000 "%_station". Progress. Dicklyon (talk) 23:56, 22 January 2018 (UTC)
I'm disappointed that you can't Quarry articletext though, or so it seems from the documentation. Not as powerful as I originally thought, but still useful.
@Dicklyon: Done. I only allowed decapitalization for the list of stations in the RfC (with or w/o the intervening "MRT/LRT"). The only exception I found was on Chinatown MRT station @ "Chinatown MRT Station Exit E." I wasn't sure if this was in titlecase or if Exit should be capitalized or not.
You're right to add page_is_redirect = 0 but we also need to do something (different) with redirects. I've created a couple of hundred duplicates like Manuyo Uno LRT station so that pages that link to "Manuyo Uno LRT Station" retain their links when the S in the text of ((LRT Station)) changes to an s. I think I've done everything necessary for "railway station" but more duplicate redirects are needed for "station". I don't have a full list as I was only aiming to compelete "railway station" but Malaysia, Singapore and the Beijing Subway stand out as incomplete. Certes (talk) 12:09, 23 January 2018 (UTC)
I think there are still a smattering of over-capped Exit and Customer Service Center and fan types. But at least they're not in titles and links, so easier to clean up. Dicklyon (talk) 01:46, 25 January 2018 (UTC)
Yeah, in my infinite OCDness I decided to scan the latest dump for page titles matching \b[ML]RT(.[LM]RT)? [Ss]tation and look for stragglers. I found ~1000 total pages: 380 articles & the rest #Rs. I couldn't find any "Station" articles, except for one of the #Rs which lead to Central Station (a dab), so it looks like all the moves are done! I'm going to create all of the missing #Rs like Tao Poon station in that list of 380 (~half are missing), since I found myself leaving a small wake of redlinks while doing the followup case fixes. I'll also check to make sure that all the appropriate "MRT/LRT Station" #Rs exist pointing to their "station" counterpart (unlikely that I'll find m/any, but still worth the small effort to check). Then, I'll feel much more comfortable going through the articles themselves and making the case changes. Phew. ~Tom.Reding (talk ⋅dgaf)14:09, 27 January 2018 (UTC)
Thanks! I did a similar exercise for "X Railway Station" a few weeks ago and identified 777 missing redirects. I found that I only needed to create about 200, as the rest weren't plausible even after proposed template changes, but it may be quicker just to create them all. The time-consuming bit was sorting out the few dozen cases where "X Railway Station" and "X railway station" redirected to different pages and the incoming links needed to be checked, creating new dabs where necessary. Certes (talk) 14:36, 27 January 2018 (UTC)
I fixed most (I think; at least a lot) of the overcapitalization issues on all of the 380 "MRT/LRT station" pages. The notable remaining exceptions are: Bang Son Station (cap "S", found while correcting Bang Son MRT station), and Cochrane MRT station & Merdeka MRT station (for their excessive (but consistent!) capitalization).
To my surprise, I found 193 missing "MRT/LRT Station" #Rs... Here I thought I'd only be patching up a few holes, but 50% are missing(!), so I'd like to get everyone's opinion on whether or not these should be created (@Certes, Dicklyon, and JJMC89:). My thoughts are that if they're left as redlinks, they would serve as an extra step to help prevent people propagating "Station" usage. I could go either way on this, though, since they could also be considered convenient/useful. ~Tom.Reding (talk ⋅dgaf)18:10, 27 January 2018 (UTC)
Can't forget Paine... ~Tom.Reding (talk ⋅dgaf)18:37, 27 January 2018 (UTC)
I wouldn't create any redirects from titles ending in uppercase Station unless there are incoming links which we don't intend to change. I hope we will eventually have all pages titled and linked as X station, with X Station as redirects to them used only by the bits we didn't bother to fix. Certes (talk) 18:15, 27 January 2018 (UTC)
Hi Tom, thanks for the ping. Whoever said that cleanup after moving ~150 pages would go quickly and that "post-move cleanup edits are less than a minute each, so we're looking at a few hours of work" just has no idea what needs to be done. If you really don't want re-creations of the uppercase, then you have to go through each article and make ALL the case changes from S → s and from L → l in "line". Else readers will see an uppercase "l" or "s" and think the article needs to be moved (back). Then there are the template names to be changed and their redirects bypassed, the Wikipedia and Commons categories to be renamed, the Commons galleries to be renamed, and all these pages have Wikidata pages to be updated. I'm still working on the cleanup of the twelve pages I moved under Talk:Disneyland Resort line#Requested move 6 January 2018. It takes several hours for each page and I'm still less than halfway done. It's okay to leave redirects as long as they're tagged with ((R from miscapitalisation)) (not "other capitalization"). Cheap stuff and also helps to curtail move reverts if they have more than one edit. After having said all that, it's important also to let you all know how grateful I am that you're working on all this. Thank you so much!Paine Ellsworthput'r there21:59, 27 January 2018 (UTC)
I don't know who said that, but I am curious now.
Good point about the 2-edit thing. That might just be a net positive, even with the gross negatives. Will wait for others to chime in. ~Tom.Reding (talk ⋅dgaf)04:55, 28 January 2018 (UTC)
I said it only takes a minute per article to clean up; I guess I do less cleanup than some, and intended to minimize the effort at that point. I'd like to see a clear checklist of the kind of cleanup that Paine is talking about. I don't usually bother with commons cats, but I do the case changes in the article text. And wikidata I have no idea about. Dicklyon (talk) 05:16, 28 January 2018 (UTC)
To complete the job properly, we'd need more cleanups like this example. I'm not sure how many more articles we'd have to check; my search timed out after finding 144,000. Fortunately, Wikidata should take care of itself. Wikipedia page moves automatically edit the attached Wikidata item, though it's polite to check. Certes (talk) 11:18, 28 January 2018 (UTC)
Actually, those who move pages are usually reminded on the successful-page-move screen to update the Wikidata item, and there are similar reminders at Commons. But not to worry, because there are Wikidata and Commons editors who help look after things there, thank goodness. The automation at Wikidata seems to kick in for identifiers and such; however, the page titles (labels) still seem to need manual updates. As for a fairly good list of cleanup needs, it can be found at Wikipedia:Requested moves/Closing instructions#Cleaning up after the move. It doesn't mention category renaming or Commons category and gallery renaming because those are usually very rare cleanup needs. Thanks again, you extraordinary people!Paine Ellsworthput'r there12:56, 28 January 2018 (UTC)
I've followed the instructions but usually find Wikidata has updated itself if I wait a couple of minutes then refresh the Wikidata page. But as you say, it's best to check and fix if necessary. Certes (talk) 13:08, 28 January 2018 (UTC)
My experience has been a little different. I've actually come across WD pages that sported different labels many days after their respective pages were renamed on Wikipedia or Commons. Maybe it has to do with "server load" and "how many things are in the queue" and all that great dev-talk stuff? Anyway, it's all good!Paine Ellsworthput'r there13:59, 28 January 2018 (UTC)
Just came across an interesting example, Certes, at this WD history page. You'll note first that the editor renamed the Commonscat from "commonswiki:Category:Tung Chung Line" to "commonswiki:Category:Tung Chung line" (beat me to it), and then I renamed the WD label to "Category:Tung Chung line". However, the label was still "Category:MTR Tung Chung Line" when I changed it. The category name on Commons had been changed from "Category:MTR Tung Chung Line" to "Category:Tung Chung Line" back on 7 June 2016 (it's there on that history page), but the WD page title (label) still hadn't dropped the "MTR". So the page title/label still seems to be in need of manual editing either by the page mover or eventually by a WD editor (or by someone else who happens across it like I did). Paine Ellsworthput'r there15:01, 28 January 2018 (UTC)
Interesting. I've never renamed a Commons category. Perhaps Commons isn't as good as Wikipedia about updating Wikidata, or maybe things have improved since that edit. (Wikidata was less mature in 2016.) But I think we're agreed: check, and fix if necessary. Certes (talk) 15:08, 28 January 2018 (UTC)
Yeah, Commons is definitely more fragile than WD. Back when I was helping with the WP:JR/SR fixes, I purposely avoided changing the ((Commonscat)) entries until I had the time/desire to update it (since it's more tedious than a simple visual check in AWB, and might include moving dozens or hundreds of files). There's probably some left, come to think of it... If all I did was remove the errant "," in WP then the link to Commons would be broken and the user wouldn't be able to see any additional content there (at least not immediately, without doing additional searching), and might even be so bold as to remove the template entirely... ~Tom.Reding (talk ⋅dgaf)15:27, 28 January 2018 (UTC)
Well, here's a more recent example from Wikipedia: I moved the West Rail line article on 20 January 2018, and I just checked the WD page to find that it still had not updated. Notice my two recent edits in the history – about eight days apart from each other. It recorded when I moved the page on Wikipedia, but it didn't update the label at all. I just did that today. And Tom, when you want to rename categories of any size, Cat-a-lot is your best friend. (Works on Wikipedia, too!) Paine Ellsworthput'r there18:29, 28 January 2018 (UTC)
What is with all these 'Rep typographic ligature "fi" with plain text' edits? I don't see any ligatures, just plain text "fi" being replaced with ... plain text "fi". ~ J. Johnson (JJ) (talk) 21:02, 20 November 2017 (UTC)
At Seattle Fault and Columbia River Basalt Group I see you have indeed removed a ligature (having looked at the previous version in edit mode). Which is all the more puzzling, as in both cases it was text that I originally typed in, and my keyboard doesn't do ligatures. Any idea of where they come from? ~ J. Johnson (JJ) (talk) 23:30, 20 November 2017 (UTC)
Hmm, interesting... I can confirm that on all of my browsers (Chrome, Firefox, Opera, and IE, all for Windows 7) the symbols were replace by their 2 component characters. Could you perhaps be using a font package which splits these, or otherwise makes them transparent to casual searches? ~Tom.Reding (talk ⋅dgaf)23:42, 20 November 2017 (UTC)
Oh, I misunderstood. Could you have cut/copy & pasted that text, or used an external text editor, instead of typing it directly into the edit window? The same comment though, that there are font packages which produce the ligature, and perhaps insert it while you're typing. It would be worth a test. Although I only found about 500 pages with "fi" on them via insource:/fi/, and I suspect it'd be higher if "simply typing" was the culprit. Based on my searching of fringe cases, it seems to most frequently be a copy/paste phenomena. ~Tom.Reding (talk ⋅dgaf)23:52, 20 November 2017 (UTC)
Just did a database search since insource was only giving me 30ish pages at a time after the first 500, and found ~2000 more. So I suspect some combination of browser/text editor interaction and copy/paste. If that isn't the problem, then the only other source I could think of are some the WP editing aids themselves, though I'd assume that they go through some strict vetting so are more likely not to be the cause. ~Tom.Reding (talk ⋅dgaf)14:01, 21 November 2017 (UTC)
As a matter of fact – yes, I did copy-and-paste. I didn't believe that made any changes. And as I do that routinely for article text (and much Talk text) why haven't I seen massive problems? So is there an intermittent problem? Time for some tests. By the way, I am using Ubuntu with xfce. Sometimes I copy from a text file opened in the vi editor, sometimes I dump text to the terminal window and suck it up with the mouse. My mouse uses the standard Linux "psmouse" driver. And I doubt any of that does any ocr-like processing that might generate a ligature.
So here is ligature: "fi" (bolded for clarity), which the cursor jumps over as a single character.
Here is a sample copied from a vi window: Pacific1. "fi" are two characters, okay.
Here is a sample copied from the command line: Pacific2. ditto
What I see on preview is what I expect. I'll do an interim save on this, and see how they look.
And after saving and reopening this text, they still appear as expected.
So the next step is check my source files. Unfortunately, the text for the files where you found ligatures is not at hand. However, on a small sample (Siletzia, Puget Sound faults, and Earthquake prediction) I have found the ligature in the article, and in my text files. Notably, they all seem to be in article titles, or quotations, which I often scrape from pdfs. And (again on a very small sample) I have found the ligature in the pdf text. I doubt the original authors put those in, and suspect it might be a characteristic of how the pdf was generated. When I get time enough to collect more samples I will explore that further. ~ J. Johnson (JJ) (talk) 23:46, 21 November 2017 (UTC)
I think the PDF is a likely source. I often copy text from PDFs and some characters don't get transcribed properly, mostly non-alphanumeric characters (e.g. > ~ ) and accents but also sometimes fi and ff (it might be more common when the pdfs are created via OCR from scanned documents). Thanks to your discussion I now know this involves "ligatures" and can search for an explanation, which might be helpful (e.g. in here). Jts1882 | talk08:20, 22 November 2017 (UTC)
I don't believe anyone spells "Pacific" as "P a c fi c", so a problem in the pdf creation process is highly likely. And I suspect an OCR problem, in most cases. But (given that link) can it also be a (e.g.) latex problem? With a sufficiently large, and diverse, collection of pdfs it would be useful to see if any processes are more prone to this problem than others. Another consideraton is the pdf reader: some will do an OCR scan themselves, which must be carefully checked. (The one I use, Foxit, likes to pop-in a lot of unicode codes, which at least have the advantage of being obvious. I have not previously considered there might be less ovbvious errors.) One consideration out of all this is whether we should have some kind of script or function editors can use to check individual articles (or text) for these kinds of errors. ~ J. Johnson (JJ) (talk) 19:18, 22 November 2017 (UTC)
I've seen you editing recently and you seem knowledgeable about Wikipedia's policies and guidelines.
Would you please consider becoming a New Page Reviewer? Reviewing/patrolling a page doesn't take much time but it requires a good understanding of Wikipedia policies and guidelines; currently Wikipedia needs experienced users at this task. (After gaining the flag, patrolling is not mandatory. One can do it at their convenience). But kindly read the tutorial before making your decision. Thanks. — Insertcleverphrasehere(or here)09:47, 23 November 2017 (UTC)
Your signature
Please be aware that your signature uses deprecated <font> tags, which are causing Obsolete HTML tags lint errors.
Thanks, it's now corrected. I've seen 1 or 2 people correcting their old signatures. Perhaps I should do the same, or is there a bot for that? ~Tom.Reding (talk ⋅dgaf)12:36, 27 November 2017 (UTC)
Thanks! FYI, the final in your sig got dropped, which is maybe what you wanted. Yes, I encourage you to de-lint old signatures, and there is a discussion about this at User talk:BD2412#Your signature. Perhaps you can collaborate to enhance the capabilities of BD2412's bot. —Anomalocaris (talk) 17:27, 27 November 2017 (UTC)
It seems to me the edit summary of edits such as this one are essentially false because the jstor links in citation templates are automatically a url to the source, so an accessdate is quite appropriate. Maybe jstor links should be excluded from Category:Pages using citations with accessdate and no URL. Do you agree? If so how do we eliminate this issue? ww2censor (talk) 11:41, 2 December 2017 (UTC)
Ww2censor, there is no issue: |jstor= produces a stable URL via the CS1/2 module, similar to many other parameters, such as |pmid=. If JSTOR's/PMID's URL translation were to change, it would be reflected in the CS1/2 module. Because of this behavior, |access-date= only applies to |url=, as written. ~Tom.Reding (talk ⋅dgaf)14:26, 2 December 2017 (UTC)
December 2017
Hello, I'm Gaarmyvet. I noticed that you recently removed content from Band of Brothers (book) without adequately explaining why. In the future, it would be helpful to others if you described your changes to Wikipedia with an accurate edit summary. If this was a mistake, don't worry; the removed content has been restored. If you would like to experiment, please use the sandbox. If you think I made a mistake, or if you have any questions, you can leave me a message on my talk page. I reverted your edit to BoB (book) because you did not explain you reason. A url not being present does mean an editor did not access the book.Georgia Army VetContribsTalk15:23, 2 December 2017 (UTC)
Since you couldn't be bothered to read Category:Pages using citations with accessdate and no URL on 2 occasions, the relevant passage is: When the online resource has a publication or other fixed date associated with it, |access-date= is of limited value though may be useful in identifying an appropriate archived version of the resource. Without |url=, |access-date= is not considered useful.~Tom.Reding (talk ⋅dgaf)17:03, 2 December 2017 (UTC)
I would agree with you if anywhere in the pop-up template implementation, the code explained that access-date (or accessdate) requires a url, but it doesn't. WP compounds the error by intentionally hiding the error message so a user has no opportunity to amend his or her error. If the parameter were on-line-access-date, things would be so much clearer. FYI, I'm taking this to the template talk page because I think unhiding the error message is the simplest solution.--Georgia Army VetContribsTalk17:28, 2 December 2017 (UTC)
Gaarmyvet, once again you would be best served by simply reading Category:Pages using citations with accessdate and no URL. If you want to unhide the error message, the relevant passage is:
Editors who wish to see all of the CS1|2 error messages can do so by updating their common or skin CSS stylesheet to include:
.citation-comment{display:inline!important;}/* show all Citation Style 1 error messages */}
Updating IUCN references on articles with list-defined references
Hello Tom.Reding, I just wanted to let you know that a few of your recent updates of IUCN references produced either a duplicate reference (old format and updated format) or a cite error, as here. I fixed some articles that were on my own watchlist. Thanks for all your hard work in updating IUCN references to the cite journal format. Declangi (talk) 10:10, 5 December 2017 (UTC)
Ugh, I hate list-defined references, and forgot to compensate for them; will do so now along with back-checking. Thank you for the heads up. ~Tom.Reding (talk ⋅dgaf)12:53, 5 December 2017 (UTC)
Hey, just as a courtesy heads up, I moved the XfD discussion for Module:IUCN status to TfD. There was a recent discussion at the TfD talk page about moving modules to TfD instead of MfD because TfD has a more technical audience than MfD. It kind of petered out without anything ever being done, and I was reminded when I saw your nom, so I went ahead and implemented the change and moved your nom over. ♠PMC♠ (talk)08:20, 17 December 2017 (UTC)
PMC, ahh, thank you. I was a bit unsure of which one to do, since I could conceive of arguments for both. Also, Twinkle failed to put the MfD template on the module (maybe it would work if I hit the TfD option?). Linking to the TfD here for reference. ~Tom.Reding (talk ⋅dgaf)17:19, 17 December 2017 (UTC)
No problem, it was little-advertised recent discussion, so you didn't do anything wrong. I found the same thing, Twinkle didn't put the TfD template on it either. But I looked at some other Modules that were recently MfD'd, and they never had the templates on them at all. So I assume it's a feature, not a bug. ♠PMC♠ (talk)23:39, 17 December 2017 (UTC)
Yeah, I'm surprised it even got that far! (I have some experience with large pages & 503 errors) I could view it, but I wasn't able to blank it... The MfD tag wasn't even able to get saved.... Email (received) ftw! ~Tom.Reding (talk ⋅dgaf)18:15, 29 December 2017 (UTC)
Playing with APIs to check taxonomic accuracy
@Plantdrew, Tom.Reding, and Jts1882: Hi Tom, I was late to the discussion regarding IUCN APIs and Taxonbar, and still not sure how you went about compiling a list of species that matched your IUCN check criteria. How difficult would it be to create a list of plant (or animal) articles on Wikipedia that are filed under unaccepted binomial names according to catalogueoflife.org?
It would be interesting to create a template that could indicate to the reader if the current name is accepted. Thoughts?--Mellis (talk) 20:19, 29 December 2017 (UTC)
To get my starting list, I used WP:AWB to recurse Category:Species by IUCN Red List category to a depth of ~9, returning ~49k unique main-space pages (depth=20 gives the same result). A lot of those are redirects too.
As for the WCSPCatalogue of Life, I can run through any list of pages and filter through those where ArticleTitle matches their |binomial= or |taxon= values, then run those through the catalogueoflife.org lookup, and just html-scrape for <name_status>synonym</name_status> (per the Aloe variegata example). I could do that tomorrow.
I don't know of any templates which do external html or api queries and parse them, probably for good reason (i.e. overloading/straining the non-WP server). Solutions would be to do a scan periodically, per above, to generate a list and post it to WT:TREE or elsewhere, or an AWB run that adds a cleanup template like ((Taxonomic articles using a binomial synonym)) with an embedded category. I think the choice of solution depends on how big the resulting list is, and how difficult it will be to correct the associated pages. ~Tom.Reding (talk ⋅dgaf)21:41, 29 December 2017 (UTC)
Thanks Tom, preforming the query would initially just be used to give us an idea of what percent of pages might have questionable taxonomy. A pie chart of articles using accepted vs synonym names would be interesting. A list of unacepted names next to their currently accepted names would also be worth looking at.
There might not be an immediate need for a template that checks if a binomial name is currently accepted, as you say it have to be based on periodic updates, perhaps by a bot. This would me more intricate but if a tracking category were created it could have good use in the long-run.
Just getting a feel for the sheer number of articles that could be off taxonomically would make for some great insight into Wikipedia.Mellis (talk) 22:15, 29 December 2017 (UTC)
I think it would be a good exercise to get an idea of the accuracy of the taxonomy. I'd imagine it is pretty good for groups using the automatic taxobox and taxonomy templates, whereas other groups could be quite dated. Some data on this would be interesting. A key issue would be what is considered the authorative source. WCSP seems a good choice for plants, as it is highly respected and regularly updated (shame about the API). On the other hand, MSW3 is used on wikipedia as the primary authorative for mammals and this is very out of date (the new version was due out in 2017, but there is still nothing on a due date in 2018). This leads of a mixture of articles where editors adhere strictly to MSW3 and others using various newer sources. Birds, amphibia and fishes have several good sources (regularly updated DBs), some with APIs.
A question on the catalogue of life. The "Aloe+variegata" search returns three results. The third identifies an infra species and the first two both indicate it is a synonyn. However, they point to two different accepted names, the first to Gonialoe variegata and the second to Aloe vera. How would this be handled? Jts1882 | talk08:58, 30 December 2017 (UTC)
@Jts1882: this is where simple scraping runs into difficulties. The CoL entry for Aloe variegata Forssk. crucially adds "nom. illeg.", so this should be ignored as a possible article title.
More generally, we must all beware of the assumption that there is an accurate taxonomy. Taxonomy is a highly disputed subject (and taxonomists have a reputation for being disputatious!) Different wikipedias and different areas of one wikipedia can legitimately chose different sourced taxonomies. Thus here "bird" and "dinosaur" editors use different and incompatible systems, both based on automated taxoboxes. (That's the major reason why we have "skip" templates.) We use APGIV for the higher taxonomy of plants, but every recent publication I've read on the taxonomy of APG's Scilloideae treats it as the family Hyacinthaceae. Even at the species level, different taxonomies are in use. The Albuca article uses WCSP species, but the references used in the article use different schemes, supported by different experts in the taxonomy of the group. We use the World Spider Catalog for genera and species, but for tarantulas, the German wikipedia uses the standard German reference book on the group. And so on... All of these variant taxonomies are "accurate" in their way. Peter coxhead (talk) 10:46, 30 December 2017 (UTC)
@Tom.Reding: Where would the term "nom. illeg." appear? In the article or an addition to what you are scraping? "nom. superfl." would be an equivalent.--Mellis (talk) 18:24, 30 December 2017 (UTC)
I see now from above comments how messy the scraping can be with all the name results. Not as straightforward as hoped. Might need to filter them out based on the name's author and ignore subspecies somehow. --Mellis (talk) 18:46, 30 December 2017 (UTC)
(edit conflict) Sorry for moving your comment, but I wish to use #Scan details to keep track of what scan parameters I've already used, and discussion up here/elsewhere. That way it's easy for others to see what I've done.
Peter coxhead mentioned "nom. illeg." as appearing in a subspecies example, if I'm not mistaken (a link would be nice btw, since simply appending +Forssk to the name in the URL doesn't return the text in question). I'm using my #Revisited - Filter #3 & #Revisited - Filter #4 (both far above, in an related discussion in early November), which I'll add to the scan section (I should've added it before), so it's likely that I won't come across any subspecies, but you never know, and it's trivial to add a filter, so I'd rather be safe than wrong. ~Tom.Reding (talk ⋅dgaf)18:54, 30 December 2017 (UTC)
Yes comments are better here. This is the example with the <name_html><i>Aloe variegata</i>Forssk., nom. illeg.</name_html>, if you read all the results that come up you'll see it could be tricky to select for the correct name.:
Ahhh thank you. Yes, finding the "correct" name(s) will probably be a whole other discussion, but for now I'm happy to just make a list of possible discrepancies. ~Tom.Reding (talk ⋅dgaf)19:21, 30 December 2017 (UTC)
Amazing work! I just discovered the incredible Catalogue of Life list-matching-service. It was made to do this! Rather than taking 24 hours to scrape and process, it only takes a few minutes to processes your list of scientific names (with or without the authors?) and then it spits out a list of statuses by the thousands. I could definitely see this helping us tremendously to visualize taxonomic quality per taxonomic groups like plants. ~ Mellis (talk) 07:07, 1 January 2018 (UTC)
Seems I was a bit too eager to scan. I also assumed, from the first example, that only 1 <name_status> exists on each page, which isn't necessarily true. I'll have to rerun my scan, but it doesn't seem worth it now... ~Tom.Reding (talk ⋅dgaf)12:24, 1 January 2018 (UTC)
It would be worth running your 38,925 names through the list-matching-service to see how the results compare. Yes the multiple <name_status> results per search likely impacted the results. The list-matching-service doesn't seem to accept Author citation input in the search, and returns two results for Aloe variegata:
I decided to run it again with some code tweaks (it's faster & easier for me to run it again than write/debug a script that goes through the output of the list-matching service). I'm storing each taxon's entire list of name_statuses now — sometimes it's 10 identical instances of <one of the 6 available name_statuses>, and sometimes there's at least 1 deviant/interloper thrown in. So I'm thinking that I'll only list those taxons which have all-identical non-"accepted name" name_statuses (especially if "synonym"). Then, depending on how many multi-name_statuses there are, I could list them for anyone wishing to dig further, or just give a count of how many there are. ~Tom.Reding (talk ⋅dgaf)19:17, 1 January 2018 (UTC)
The list matching may allow author citation checks if the appropriate header and separators are used. The Taxon Comparison Tool on the ITIS website (which might be the same or similar to the CoL tool) uses pipes and requires a comma between authority name and date as described here. Jts1882 | talk13:20, 2 January 2018 (UTC)
Scan details
I'll update this section as I go.
I'm starting from a list of 75,944 unique main-space pages compiled from:
The first 25,000 pages which transclude ((Taxobox)) (total transclusions = 264k; need an admin if we want to check them all)
The first 25,000 pages which transclude ((Speciesbox)) (total transclusions = 72k; same deal)
When I get to the scraping part (the above will take several hrs), I'll treat "nom. illeg." (and try to look for equivalent wording) the same as <name_status>synonym</name_status>. Please let me know of any other exclusions I should use, even if seemingly trivial from those already mentioned, above this section (I want to keep a compact log here). ~Tom.Reding (talk ⋅dgaf)15:18, 30 December 2017 (UTC)
38,925 binomial pages found using the above criteria. Querying catalogueoflife.org should take ~24 hrs. I'm throttling requests to one every 2 seconds, so as not to raise many(?) eyebrows. If anyone can recommend a faster or slower rate, please let me know (and why) above. ~Tom.Reding (talk ⋅dgaf)23:15, 30 December 2017 (UTC)
@Tom.Reding: I don't think I quite understand what your categories mean. Consider "onlysynonym". I looked at species I recognized in this category, and they all seemed to me to be at the clearly accepted name. Dipsacus fullonum is in this list, for example, but it's the accepted name in the Plant List (and in all the recent Floras I have on my shelves). Peter coxhead (talk) 15:07, 2 January 2018 (UTC)
@Peter coxhead and Tom.Reding: The Dipsacus fullonum entry on The Plant List is from 2012. CoL, WorldPlants, and GBIF consider it to be a synonym of Dipsacus sativus. This wasn't an issue with Tom's scan, but a disparity in taxonomic acceptance depending on the authority.
It looks like I just messed up the manual data reduction bit, condensing multiple name_statuses. Dipsacus fullonum definitely isn't an accepted name on CoL, but it definitely shouldn't be in my "only ambiguous synonym" category either. Will redo & repost (but not reping; sorry for my hasty pings) when I can (RL calls atm). ~Tom.Reding (talk ⋅dgaf)23:18, 2 January 2018 (UTC)
Table corrected. The most major change was that 10 pages were moved from their erroneous "only ambiguous system" cat to their correct "multiple tags, NOT including accepted name" cat. Everything else pretty much stayed the same aside from some alphabetical sorting. Let me know if you find any other discrepancies. ~Tom.Reding (talk ⋅dgaf)13:58, 3 January 2018 (UTC)
Sorry, Tom. I did bookmark your page with the results of this search right after you'd posted it, and had meaning to get back to it. I do appreciate your work on this. I've been pretty intimidated by the number of results. And now you've given me the IUCN status mismatches I'd brought up before you played with the CoL API. Plantdrew (talk) 03:35, 4 March 2018 (UTC)
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)
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.
Reason for changes to National Boxing Association webpage
I am requesting further information as to why the page for the National Boxing Association was deleted. From what I can gather the reasoning is copyright violations? If it is due to the name, the National Boxing Association (NBA) is a registered Florida corporation founded on 07/18/1984. Proof can be found freely on the State of Florida's website: www.sunbiz.org. Further, the NBA is a registed non-profit 501c by the United States Government. If there were copyright violations neither the State of Florida nor the United States government would have issued these to the NBA. If Wikipedia has their own laws on copyrights, please let me know, because it is not inline with the United States government's view of the National Boxing Association. If it was a question as to the content added, it is freely available on the official website of the NBA: nbaboxing.com. Any questions can be directed to myself as Chairman of the National Boxing Association, or to current President Damon Gonzalez.
Hello, Tom.Reding. Please check your email; you've got mail! It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the ((You've got mail)) or ((ygm)) template.
Hi Snek01, I prefer to keep all normal (i.e. non-sensitive and not-huge) communication on-Wiki, since it's the easiest (and best) way to collaborate on WP things. To answer your question though, I'm not sure, but at least a month or 2. ~Tom.Reding (talk ⋅dgaf)20:57, 10 January 2018 (UTC)
Hi Tom, I'm trying to fix things in Category:Pages with citations using unsupported parameters and your last change to Progomphus stumped me. What's 'last-assessor-amp = yes'? It's showing as an error because it's optional in IUCN but unsupported in cite journal, but without knowing what it signifies I can't figure out what to change it to, or if it can be deleted safely. Mortee (talk) 12:43, 13 January 2018 (UTC)
Thanks, that was a nested-template bug in my rules. Instances of |last-assessor-amp= should be changed to |last-author-amp=. I'll go through and correct what remains. ~Tom.Reding (talk ⋅dgaf)13:05, 13 January 2018 (UTC)
I've been thinking about checking typo rules for false positives on existing article titles. For example, "\b([Rr]e|[Ee])v(?:[olutin]{3,9})n+(?<!volution|Revillon)(ary|aries|ize[ds]?|s)?\b" can catch Evoluon and Revunions. Is it worth adding that sort of catch in, or does it just slow things down for little benefit? Certes (talk) 16:57, 18 January 2018 (UTC)
Yeah, this isn't a very good rule - [olutin]{3,9} is just sloppy/too open-ended. It is in the "New additions" section, so it needs vetting. I think we can grow the exceptions to some extent, but if they get too long/and/or complicated, it will need to be made more specific, or possibly disabled. ~Tom.Reding (talk ⋅dgaf)17:12, 18 January 2018 (UTC)
Thanks. Those are the only exceptions in article titles for that regex, and I can't find any English words. I've checked the rest of the newer additions and found a few other cases but I they're all pretty obscure except for the first one.
Certes, up to you. I won't be free for another 2 hrs or so, but will either check your additions (if you choose to make them), or add them myself, later today (whichever ones don't seem too obscure). Either way, nice job finding them :) ~Tom.Reding (talk ⋅dgaf)18:57, 18 January 2018 (UTC)
I just meant that it wouldn't be long before I looked at it; feel free to ping me if you want some regex assistance in the future. As for the exceptions:
Insource search wasn't very cooperative when searching for "archology", but, just from a cost-benefit perspective, trying to find mis-corrected "archology" needles in the "archeology" haystack makes it useful to include.
"Susque"/"Susques" show up enough
Similianus only appears on 2 pages, only once on each, and AWB didn't catch either of them (due to ((not a typo)) & a wikilink) so not needed
"Jabal `Umayyid" - orphaned stub...I was tempted to just ((not a typo))-it, but when it comes to non-English words, I'm tempted to just include the exception so it doesn't get lost; it hasn't gotten deleted yet, and someone will eventually unorphan, etc.
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)
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:
Tom:Forgive me for asking this, but you are addin manually the same wikidata Q number that shows up when the entire taxonbar is published. My question is what if the species page is updated to another genus or species. Doesn't you manually adding the Q number lock that species in and doesn't allow an automatic update?....Pvmoutside (talk) 21:25, 1 February 2018 (UTC)
Pvmoutside, yes, the primary WD QID is being added, specifically for tracking purposes (as described in the link in the summary). There is no 'locking in' though, actually, since ((Taxonbar)) shows and will show the current WD QID automatically no matter what the |from#= parameters provide. What adding the (current) primary QID does is let us know via tracking categories (see Category:Taxonbar cleanup) if and how the QID has changed over time. The tracking cats aren't live yet but should be in the near future. ~Tom.Reding (talk ⋅dgaf)21:40, 1 February 2018 (UTC)
@2601:5CC:100:697A:F936:60EF:A894:2959: (I'm not even sure if IP pings work) thanks for your help. Unfortunately, Jarekt's solution is a bit cumbersome, and, at least to me, seems only marginally better than my hypothetical brute-force GetHTML method. I think the simplest, most computationally efficient, 1-module way would be to repurpose the public class LinksOnPageOnlyRedListProvider in the ListProviders.cs AWB file; specifically the ApiMakeList()/EvaluateXmlElement() functions. If you could get that to work it would be gold for finding redlinks. I plan on playing around with it soon as soon as I get the time. ~Tom.Reding (talk ⋅dgaf)00:57, 2 February 2018 (UTC)
A stalker writes: does the regex handle piped links? The pipe symbol is correctly excluded from the set of characters in the linked page title, but it looks as if it then expects ]] immediately after the title when it could be | (or #). Certes (talk) 13:55, 2 February 2018 (UTC)
Thanks for the reminder; I have not, yet. This started as a curiosity related to the MRT/LRT station moves, and, by being explicit in which 'Stations' get changed to 'station', was easy enough to work-around. By being explicit, I could easily check which targets & redirects did or didn't exist. Perhaps others were not as careful, however (not the main actors, of course), so I figured it'd be good to double-check all the related pages for redlinks. Given that getting this to work will take some time, might not even be successful, and that the added value is relatively small (but still there!), I likely won't attempt this until I find a larger problem this could help solve. ~Tom.Reding (talk ⋅dgaf)13:29, 4 March 2018 (UTC)
If you want it, I believe Reguyla on Wikia Military has created some code to do this. He might be willing to share that but since he is banned here he might not and even if he did, you might not be allowed to profit off his work here anyway. It's up to you if you want to ask them for it. 2601:5CC:100:697A:95BA:D5C3:683C:12E (talk) 01:29, 7 March 2018 (UTC)
Hi. I see you blowing up my watchlist with this big task putting the the Q$s into taxonbars. I applaud you for taking that on. I have a question though: The |from= parameter allows for multiple taxa to be listed, which is helpful for any monotypic taxon. Do you account for this in your AWB script? An example I recently edited by hand is Himanthalia elongata. The page serves for the the species, genus, and family. I assume that the script would not remove any |from parameters, but would it add the other taxa as |from2= etc.? Not trying to nitpick, just trying to see what's up. Nessie (talk) 16:45, 2 February 2018 (UTC)
No, the run of |from=-additions will not remove any |from=/|from#= parameters, nor will it add any parameters beyond the 1 (and only 1) allowed to point from Wikidata to each Wikipedia page. In fact, ((Taxonbar))s containing any additional text are in the vast minority (at least the ones I have not gotten to yet). I'm skipping those with any additional text, for now, and will address them by hand after the bulk are complete. At that time, |from1= will only be added if |from1=<any text> does not exist, and if none of the existing |from#=s contain the current WD QID associated with the page. Also, I personally would not feel comfortable adding any additional |from2=, etc., parameters, unless explicitly requested to by someone more knowledgeable than I in the area.
As for your watchlist, I will slow down. I'm only editing pages < 2000b so as not to be too disruptive (Polbot's were taken care of first), and will submit a formal bot request for much larger pages (also since I have a several-week-old bot request stuck in the approval process). ~Tom.Reding (talk ⋅dgaf)17:20, 2 February 2018 (UTC)
@Tom.Reding: I'm delighted to see all the taxonbars you're fixing on my watchlist, since I think this is an important move. Thanks for the work you've been doing in setting this up.
I guess it would be possible to automate the addition of other from parameters, based on the taxobox (e.g. if any of the synonyms listed in the taxobox have a Wikidata item, they should be added to ((Taxonbar)). But I'm not recommending we try automating this – at least for now. Peter coxhead (talk) 17:54, 2 February 2018 (UTC)
That definitely seems doable after the |from= additions are done. I could create a list of potential additional |from#=s for each page based on its (properly formatted) taxobox for vetting, then add only the community-accepted QIDs semi-automatically. Will ponder this in the meantime... ~Tom.Reding (talk ⋅dgaf)18:10, 2 February 2018 (UTC)
You reverted several edits of mine in "list of unnumbered minor planets" articles. If similar edits happen by AWB users (who aren't bots), you might want to consider using ((not a typo)). --I dream of horses If you reply here, please ping me by adding ((U|I dream of horses)) to your message (talk to me) (My edits) @ 17:24, 7 February 2018 (UTC)
Why did you spam ((nobots)) on List of unnumbered minor planets and a bunch of its subpages? That template is intended as a temporary measure while issues with a bot are discussed with the bot operator, but I don't see that any bots have edited that page (or a few of its subpages that I spot checked) recently. Anomie⚔12:29, 8 February 2018 (UTC)
Anomie, see the discussion immediately prior to this one. Also see the edit histories leading up my addition of ((nobots)). Edits like this were made to that family of ~19 pages (I ((nobots))'d a couple preemptively as a result), which are unwanted. My use of this template seems in-line with the /doc: These templates tell bots and other automated editing tools and scripts that they either should or should not edit a page that has the template.. If inappropriate, could you suggest an alternative? I'd rather not do I dream of horses' suggestion of adding ((not a typo)) around every single-digit date in May, which might go unseen by someone updating large portions of the page. I haven't tested whether or not that will work either, since it might be WP:GenFixes making the change instead of a WP:AWB/Typo. Courtesy ping to their creator & maintainer, Rfassbind. ~Tom.Reding (talk ⋅dgaf)12:49, 8 February 2018 (UTC)
But the template documentation also says Avoid using the template as a blunt instrument and Address the root problem with the bot owner or bot community. I also note that ((bots|deny=AWB)) would be more specific to deny AWB without denying every other bot on the wiki. Anomie⚔12:53, 8 February 2018 (UTC)
I also agree with ((bots|deny=AWB)), because AWB makes alot of erroneous fixes to minor-planet designations as in this edit, where 1980 KG was changed into 1980 kg (kilogram). So thx Tom for this improvement (I also added this template to the header-template for all p-LOMPs). Rfassbind– talk14:17, 8 February 2018 (UTC)
Thanks for updating the radio station pages with edits such as these to fix the deprecated image fields. Much appreciated! :) - Neutralhomer • Talk • 04:36 on February 19, 2018 (UTC)
images in ship infoboxen
((infobox ship image)) has a default image size of 300px so it is not necessary to set |Ship image size=300px. In olden days the 300px image size was required; that is no longer true. Perhaps when making these kinds of fixes, it would be best to simply omit |Ship image size=300px.
Trappist the monk, the documentation explicitly uses |Ship image size=300px for all of its examples, so perhaps it's still desired? I don't feel comfortable updating the doc (I'm basically an outsider). If you do, could you? ~Tom.Reding (talk ⋅dgaf)16:22, 24 February 2018 (UTC)
Old documentation. I've removed |Ship image size=300px from the examples.
Your edits like this one seem to change nothing at the article, but add some hidden link to the unreliable sister site some people want to add everywhere they can. Any good reason for these additions? They don't seem to help readers or editors, and the Q-number is already for no good reason visible in the taxonbar anyway. Fram (talk) 15:34, 26 February 2018 (UTC)
Yep, and it doesn't really indicate why this is considered a good idea. The template works perfectly without the "from" parameter anyway, and the WD item stays linked with the article as well even if it is moved, so the usefulness of your additions seems extremely minimal at best. Fram (talk) 15:47, 26 February 2018 (UTC)
Which is a reason not to use Wikidata of course... Or, as I have just tested and shown at Ancistrocheirus, by not using the "from" parameter in the first place. If you hadn't used the "from" parameter at that page, it would never have shown up at that "desynced" cat and would not have shown the wrong Qnumber and more important other links. So no, the "from" parameter is not clearly useful at all. Fram (talk) 16:10, 26 February 2018 (UTC)
Hello, could you please run a bot for such edits? I see the category has 100k pages in it, it's a bit annoying to have them in my watchlist. Thanks, Nemo07:40, 1 March 2018 (UTC)
Nemo bis, I'll think about it - I'm doing this on a template-by-template basis with constant program changes so I don't feel especially comfortable leaving it alone. It's also only for image params which only have an associated size, or no relevant text. So the use case is pretty specific and certainly won't bang out the whole category. If/when I make a general-purpose case that is able to handle alt text, captions, their aliases, etc., then a bot would be a lot more appropriate. ~Tom.Reding (talk ⋅dgaf)12:48, 1 March 2018 (UTC)
Hi Tom, I plan to add a few articles on endemic creepers of India. I don't quite understand how template:Taxonbar works? Do I have to add all the values or find just one value and add it? Will others appear by themselves? Thanks in advance AshLin (talk) 07:24, 16 March 2018 (UTC)
AshLin - tl;dr: all you have to do is add ((Taxonbar)), and it does the rest!
ts;du: It draws all its taxon IDs from Wikidata. If you don't see a particular ID that you know should be on the bar, you can add that parameter manually to the bar, but most of the time you won't have to. Since you're creating articles, the most likely result is that the bar won't show up once you've saved the page, which means there is no link yet to Wikidata. If you don't know how to do that, it's best to watch someone else do it on a page you've created (you'll need to check "Show Wikidata edits by default in recent changes" in your preferences). Adding ((Taxonbar)) in this case puts the page into one or more Category:Taxonbar cleanup tracking categories (not all of them are active yet) for others to clean up/further investigate. ~Tom.Reding (talk ⋅dgaf)12:48, 16 March 2018 (UTC)
I've been noticing noticed your efforts to do this fix Category:Pages using deprecated image syntax; WP:GenFixes on, using AWB) for several days. In fact it's been flooding my watchlist nwhich has around 30,000 pages on it. I'm wondering if it would not be better to create a bot to do this, because literally 100s of thousands of pages are probably affected. Kudpung กุดผึ้ง (talk) 01:22, 17 March 2018 (UTC)
I should've asked you this months ago, but I was wondering whether you could add changing taxobox parameters with "status_system = iucn3.1" "status_system = IUCN3.1" (and iucn2.3/IUCN2.3) to your workflow when AWB editing articles with taxoboxes. It's basically a minor cosmetic edit not worth doing for it's own right, but the capitalization variants show up separately in TemplateData reports, and drive me a little nuts. I change them myself when I'm editing taxoboxes for other reasons, but I'd guess you'll still be hitting a bunch of articles with Taxonbar edits before I get around to doing automatic taxoboxes. Plantdrew (talk) 01:38, 17 March 2018 (UTC)
I starting fixing "iucn" pretty quick after I first saw it, but only when I was doing the status update & the ((IUCN))-to-journal conversion (b/c the text was nearby). I have not (unfortunately) included it in ((Taxonbar)) additions. Maybe b/c I was only focused on cosmetic fixes near the main fix? Whatever the reason, I wish I had! Say no more... ~Tom.Reding (talk ⋅dgaf)01:59, 17 March 2018 (UTC)
Thank you. There are a couple more taxobox parameters that bother me. |image_width= is deprecated in taxoboxes in favor of |image_upright=. There are ~1500 automatic taxoboxes with "image_width = 250" specified, and maybe a few more automatic and speciesboxes with an empty value for this parameter. |image_size= does nothing at all in taxobox family templates, but is included in some taxoboxes. Remove all |image_size=, and maybe |image_width= as well in your future edits. (EDIT CONFLICT) (well don't worry about it if it requires changing any already approved BRFAs)Plantdrew (talk) 02:26, 17 March 2018 (UTC)
Will-do for |image_size=<any text>, which doesn't appear anywhere in ((Taxobox)), and |image_width=<null>. Will make similar checks for the other taxo infoboxes.
I don't feel comfortable messing with |image_width=<something> though, at least not immediately. I need to give MOS:UPRIGHT & the associated policy page a read through first. ~Tom.Reding (talk ⋅dgaf)03:34, 17 March 2018 (UTC)
Plantdrew, I don't remember the pages, but I think I've seen surrounding {[()]} being removed from the various |authority= parameters periodically by experienced editors. If useful, I could tack this onto my manual cleanup checklist. I would only do this in the KISS-iest of scenarios - if and only if 1 matching pair of brackets were used at the beginning and end of the authority string, with no brackets in the middle, with the exception of (Botanist), etc., in wikilinks like ([[Henry A. Gleason (botanist)|Gleason]]). ~Tom.Reding (talk ⋅dgaf)14:35, 21 March 2018 (UTC)
I appreciate the thought, but don't do this. The presence/absence of parentheses is not stylistic issue; it has meaning in taxonomy. Basically, when parentheses are present, it indicates that a species has been moved to a different genus from where it was originally described (see author citation (zoology)/author citation (botany) for more detail).
I'm sure there are hundreds of articles where Wikipedia has the parentheses wrong, as many editors aren't aware of the taxonomic conventions for parentheses. But I don't see any easy fix, short of comparing the authority strings on Wikipedia against a reliable taxonomic database. There are basically three scenarios where I can readily detect possible parentheses errors (without first checking against a database, although checking is required to confirm):
1) Very recently described species with authority parentheses. If something was described 1-2 years ago, it is unlikely to have been transferred to a different genus in that time and presence of parentheses is an error.
2) Species described a very long time ago in groups where there has been significant splitting and authority parentheses are absent. Not as straightforward as case 1, but I'm a little suspicious if a see a species described by Linnaeus with no parentheses.
3) A plant with only a parenthetical authority. Botanical convention is different from zoological convention; in botany the name of the original authority is placed in parentheses, followed by the name of the person who placed the species in its current genus (the "combining authority" is omitted in zoology). If a plant has only a parenthetical authority, either the parentheses are erroneously included, or the combining authority has been omitted. Plantdrew (talk) 17:07, 21 March 2018 (UTC)
Just to let you know, I'll be reviewing those tomorrow. I wanted to give the community a week at least for feedback before making a decision. Headbomb {t · c · p · b}02:33, 17 March 2018 (UTC)
AWB: Broken infobox image size, full image syntax is acceptable for infobox software
Your edit Special:Diff/830621539 caused the screenshot to blow up and you may have not noticed this. According to Template:Infobox software/doc, the syntax before your edit replaced it was acceptable and working as intended for this scenario.
I think the old syntax is better than my following hack to fix it: Special:Diff/830945138. Any replaced screenshot would now blow up to 100% width if the next editor or uploader at Wikimedia Commons doesn't notice this. 84.250.17.211 (talk) 21:27, 17 March 2018 (UTC)
The old syntax is and has been deprecated for this infobox since June 2013, when Module:InfoboxImage was first invoked. 300px has also been the default for |screenshot= since then. The /doc has now been updated to reflect the deprecation. ~Tom.Reding (talk ⋅dgaf)04:02, 18 March 2018 (UTC)
AWB edits on talk pages appending WP Bio
Is there any way that you can, using AWB, determine whether the subject that the article is based on is living or not living and adjust the WP Bio parameters, as your edits (which are still useful) are filling up the 'Biography articles without living parameter', which I try to unclog manually. Wpgbrown (talk) 15:53, 18 March 2018 (UTC)
Wpgbrown, if a Category:Living persons or a yyyy-deaths category exists, I can do that. That should take care of most of them (I'm guessing). The rest are best done individually.
Thanks. There are categories for living and dead people (and they seem to be based off infoboxes). Wpgbrown (talk) 16:26, 18 March 2018 (UTC)
Ancient Winners
Hi Tom. I see you have added a number of ancient Olympic winners to the Olympic project. This is generally a good thing, and I'd like to contribute in that field. But unfortunately the whole sector has been frozen by a merge vote two or three years ago. Since then every edit in the whole field has been considered antidemocratic and immediately undone. Now you understand why there is not the slightest progress made.
The best example is the landmark article Pantacles of Athens. When the decision was taken everybody boasted, that this stub could never ever be expanded. Though most of them had never studied more than five minutes on ancient Olympic Games they were so sure, completely ignoring the huge progress mady by ancient history and archeology in our times. This is exactly what happened, and if you take a look now at the international articles on Pantacles, for example the one in Modern Greek, you can notice that there is a lot of new evidence on that athlete since 2015. But English Wikipedia will never have any of those news, because it is forbidden to edit that redirect. Any idea what can be done to restart that sector?Lamassus (talk) 23:14, 19 March 2018 (UTC)
Due to a lot of sympathetic treatment I have given up on it and so I guess it must stay like that for the next century. Thanks anyway.--Lamassus (talk) 22:06, 20 March 2018 (UTC)
Would it be possible to add antweb.org to database lists for the taxonbar, its about the most comprehensive database for Formicidae online right now, creative commons licenced, and many of the images used on the Wiki pages are originally from antweb and are transferred over to commons. It would be a good addition for sourcing to articles like Cananeuretus and Linguamyrmex.Thanks!--Kevmin§23:30, 2 April 2018 (UTC)
A request for Cleopatra and Cleopatra-related pages
Hi Tom! I don't really know anyone with AWB privileges, so I thought I'd approach you first and make a small request. I'm in the middle of GA nominations for Cleopatra, Early life of Cleopatra VII, Reign of Cleopatra VII, and Death of Cleopatra. The GA reviewer has requested that I contact someone with AWB access in order to change all hyphens to en-dash (–) or something. Would you be able to do that? More importantly, would you have the time to do that for me, please? I don't know if it's asking a big favor or not, but it would be greatly appreciated, as it would help the GA candidacy of these articles. Regards, Pericles of AthensTalk15:59, 4 April 2018 (UTC)
Pages with taxonbars and no taxobox and vice-versa?
Hi there.
Seeing as you're a taxonbar jedi, i thought i'd ask you: is there a maintenance category forarticles with taxoboxes but no taxonbars and/or vice-versa? If not, how could one be set up and populated? I think it would be helpful to catch some of these articles that have fallen through the cracks, despite all herculean efforts. Nessie (talk) 04:26, 8 April 2018 (UTC)
Nessie, unfortunately that's not possible to do, b/c one template isn't able to know the contents of another, nor any other text on the page. Even if it were, not all pages with a taxobox-type infobox deserve a taxonbar (i.e. dung beetle), so they'd be permanently lodged in that category. The best way to find pages with taxo infoboxes & without taxonbar are with this PetScan query (11,441) and this inverse query (1350). Goto the "Templates&links" tab to see the differences. May the force be with you ~Tom.Reding (talk ⋅dgaf)14:22, 8 April 2018 (UTC)
@NessieVL:, I was just playing around with the search for Taxonbar articles with no Taxboxes a couple of days ago; Tom's search is missing some of the templates in the Taxobox family, try this one instead. It turns up some articles that should have taxoboxes, but don't, as well as some articles that have taxonbars that shouldn't. I do want to address these as I can find time.
There are a lot of articles that could be using ((Paraphyletic group)) that aren't. That's another thing on my to-do list, but nowhere near the top. Digging around through the subcategories of Category:Animal common names will turn up some articles that are about paraphyletic groups rather than taxa. Plantdrew (talk) 21:50, 9 April 2018 (UTC)
Re: [3][4] - the birth and death categories are explicitly for people, according to the text on the category pages. Please update your AWB settings or filters or search criteria accordingly. Mitch Ames (talk) 09:28, 16 April 2018 (UTC)
There will be some changes to the way wikitext is parsed during the next few weeks. It will affect all namespaces. You can see a list of pages that may display incorrectly at Special:LintErrors. Since most of the easy problems have already been solved at the English Wikipedia, I am specifically contacting tech-savvy editors such as yourself with this one-time message, in the hope that you will be able to investigate the remaining high-priority pages during the next month.
There are approximately 10,000 articles (and many more non-article pages) with high-priority errors. The most important ones are the articles with misnested tags and table problems. Some of these involve templates, such as infoboxes, or the way the template is used in the article. In some cases, the "error" is a minor, unimportant difference in the visual appearance. In other cases, the results are undesirable. You can see a before-and-after comparison of any article by adding ?action=parsermigration-edit to the end of a link, like this: https://en.wikipedia.org/wiki/Arthur_Foss?action=parsermigration-edit (which shows a difference in how ((infobox ship)) is parsed).
Hi! I see that you've been adding ((Authority control)) to several pages where it apparently serves no purpose – Giovanni Natoli is an example. So I wondered why you were doing that, and if it was based on community consensus? If not, and you're using AWB to do it as is suggested above, you should perhaps put that task on hold for a bit. As we have seen, repeated "inconsequential" automated edits that make no difference to the rendered page can annoy other editors, sometimes to the point that remedies are sought. Regards, Justlettersandnumbers (talk) 08:53, 21 April 2018 (UTC)
Justlettersandnumbers, template documentation states this template should be added to all biographies, whether or not there are authority control identifiers in Wikidata already. You're welcome to discuss at template talk to change it. In the meantime, I'll restrict addition only to where an ID exists on Wikidata. ~Tom.Reding (talk ⋅dgaf)12:39, 21 April 2018 (UTC)
@Justlettersandnumbers: like all such templates that potentially link to Wikidata, it is useful to add them even when there is not yet a Wikidata item, since it's unlikely that if a Wikidata item is created over there, the editor will come here and add ((Authority control)), so it's better to anticipate it here. Peter coxhead (talk) 08:42, 25 April 2018 (UTC)
Note to self: 'Please confirm classification' sorted
Thank you for being one of Wikipedia's top medical contributors!
please help translate this message into your local language via meta
The 2017 Cure Award
In 2017 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.
Hi, @Tom.Reding: I'm editing the List of the Child Ballads as well as related Murder Ballads and noticed you removed Category:Murder ballads from the song Omie Wise. I have numerous citations indicating the category is appropriate, and the song's Wikipedia article also clearly identifies the song as a murder ballad. However, I didn't want to revert without checking with you. Here are two of many citations of note: Fresno State Ballad Index and Peggy Seeger. I look forward to your reply. Thanks... Allreet (talk) 12:59, 27 April 2018 (UTC)
I am not sure about the validity of the transcription, especially the VIAF attribution of the elephant as the author (and not the subject) for the books mentioned. Afaik - the scope of the VIAF entries is for people - per Template:Authority_control. I am not sure I have seen any other VIAF authority control templates for non-human authors. Shyamal (talk) 16:49, 1 May 2018 (UTC)
Shyamal, yeah that's beyond my understanding - authority control identifiers can definitely apply to more than just people, but I don't know if that's also true for VIAF. However, it just sounds like a database input/transcription error at VIAF. Other than article or template talk, you can also check the history of the Wikidata item that ((Authority control)) is drawing from to see who added VIAF and ask them. ~Tom.Reding (talk ⋅dgaf)18:00, 1 May 2018 (UTC)
As a current or past contributor to a related article, I thought I'd let you know that I've started WikiProject Western Governors University, a collaborative effort to improve Wikipedia's coverage of WGU. If you would like to participate, you can visit the project page, where you can join the project and see a list of open tasks and related articles. Thanks! Paul Smith111977 (talk) 08:52, 6 May 2018 (UTC)
Automating parent categories for "Xs described in YEAR" categories
Hi, you offered to run a bot to fix some of the "Xs described in YEAR" categories, in particular adding a standard header template.
I've been thinking about this, and came up with an idea I'd like to run past you first before a more general discussion.
However, doing just this would still allow editors to make some years have different parent categories to others, and would still need a bot to change the parent categories if this were agreed in future. So another idea is to code the new template in Lua, reducing the required parameters to the year and the name of the group (e.g. ((Category described in year|1989|fish))), and have a "configuration" module which given "fish", for example, sets up the parent categories (for fish by centuries but for other groups by decades, and for fish "Animals" but for other groups "Plants", "Fungi", etc.) This would make it much easier to maintain consistent categorization schemes, and is simple to program in Lua. We would need bot runs to add the new template, removing any manual stuff.
Peter coxhead, I like it, and for using Lua. It can be done via template syntax too, but it would be quite tedious to write and maintain for all the different groups, potentially with different caveats for each group. We can go 1 step further, though - "fish", etc., and year can be grabbed from calling category's name, and wouldn't even need to be passed as parameters. The calling cat's name would be checked for the format "X described in yyyy" and other variants before applying the necessary parent cats. Yeah the whole category tree can be maintained in the Lua module; excellent! ~Tom.Reding (talk ⋅dgaf)12:29, 8 May 2018 (UTC)
I'm constitutionally against picking up information from the page title after working on taxoboxes! The automated taxobox system was originally designed so that you could just write ((Automatic taxobox)) and everything would work. For taxoboxes, it makes the code very complicated (because it has to handle disambiguated titles, monotypic taxa, hybrid names, subspecies, etc.) and very prone to breaking, particularly when the page is moved. So it all depends on how much would end up hidden in your and other variants. But I guess it should be ok in this case, given that in "Xs described in YYYY" only the first and last 'words' matter, so if only these are picked out, the titles could be changed to "formally described in", for example, with no problems. I'm busy with other things for the next few days, but can work up a draft module later, unless you have time to do it first. Peter coxhead (talk) 18:01, 8 May 2018 (UTC)
Sadly I have some much more boring work to do than programming this in Lua, so over to you! In the final version, I favour using a separate configuration function or even module that just gives mappings like "Fish --> century, Animals / Plants --> decade, Species / Spiders --> decade, Animals" so that it's easier to add groups or change their categorization. Peter coxhead (talk) 18:13, 8 May 2018 (UTC)
Peter coxhead, the template now works (still only as an exhibition, don't click save yet) for fish in the Category:Fish described in 1901 & Category:Fish described in the 20th century type categories (perhaps the latter century-cat was not necessary, but since one of the parents of 1901 is Category:Animals described in 1901, I felt the need to include the other parent; but I don't have a problem with this functionality being removed/dormant if not desired). The category map/configuration is contained within the map local variable at the top of the module. I think that's enough to get/show the gist of how it would function and the way the category structure would be represented and updated. What do you think about that, especially in terms of ease? ~Tom.Reding (talk ⋅dgaf)02:55, 9 May 2018 (UTC)
Looks good so far. I like the way the configuration is set up. I would be inclined to allow optional parameters for the information that can be picked up from the title, just in case. Do you propose to implement the navigation by year or decade within the module or separately? Peter coxhead (talk) 07:03, 9 May 2018 (UTC)
Peter coxhead, nav templates can certainly be added for further 'hands-off standardization', which makes a lot of sense here. Different headers will also be available for each type of cat (year/decade/century), which I'll probably add to map to keep everything together and to be more self-explanatory. ~Tom.Reding (talk ⋅dgaf)11:56, 9 May 2018 (UTC)
Peter coxhead, done for Fish, except for any optional parameters. What sort of parameters/functionality do you anticipate? That is, passing the entire Fish tree is unreasonable, and passing parent cats would be redundant. I'm afraid that having parameters as well as consuming-all-header-and-nav-templates is going to be a possible conflict of purpose, since putting all of the extraneous info + cats requires that there be no ambiguity, and allowing user input would jeopardize the exactness required. An example would be helpful though, and it might be ok under very specific/controlled circumstances. ~Tom.Reding (talk ⋅dgaf)17:13, 9 May 2018 (UTC)
On reflection, I think that it's right to pick up the group and the year/decade from the name of the category, since this forces consistency on the category names, which is desirable (to most editors, anyway). Given that the new template will add the navigation bar, there's the issue of the lowest year to be displayed (|min= in the existing template). For zoological names, there's an argument that this should be 1758, based on ICZN Art. 5, but spiders currently allow 1757. For botanical names, it's 1753. I'm not sure about bacteria or viruses. This can also be set in the module and doesn't need to be a parameter. Peter coxhead (talk) 10:20, 10 May 2018 (UTC)
Looking at some of the Animals described in cats, I think it would be useful to have "default category tree style(s)" to save on unnecessary labor inputting them all individually into the module.
If the vast majority of groups are to be of a certain style (i.e. without decades), and only a few dissimilar-oddballs (for homogeneous-oddballs see #2), then a prototypical tree can be fully fleshed out in the module as an example (Fish?), and only require further input for weird ones (i.e. Spiders). Is Fish a good prototype cat tree?a very strange sentence when taken out of context... And what are the remaining weird ones that deserve to be preserved in the module?
Another option, if there are to be a few different-style trees (i.e several groups using decades, several without, with no dissimilar oddballs), is then a simple array of groups which are to be 'Fish-type' cat trees, and another for groups which are to be 'Spider-type' cat trees, which would be most user-friendly for this scenario.
I guess this depends on the outcome of your RfC too, but at least the basic programmatic framework I think is laid out, which should accommodate all reasonable eventualities. ~Tom.Reding (talk ⋅dgaf)16:43, 10 May 2018 (UTC)
The issue of decade cats is an interesting one. Some major trees have decade categories, like the top-level Species (e.g. Category:Species described in the 1780s) and Plants (e.g. Category:Plants described in the 1780s). I completed the Spiders tree, which had been patchily created by others, using the Plants tree as a guide. On reflection, I would not now create the decade categories. They result in small categories, with only 10 members, and cause confusion over the exact boundaries of centuries, which the MoS says run e.g. 1801 to 1900, not 1800 to 1899. So I agree that the default should be no decades. Peter coxhead (talk) 07:46, 11 May 2018 (UTC)
Done. Fish is now the default if the group doesn't exist in map, and I've applied the template to Category:Fish described in the 20th century and subcats only, for now. My placement criteria is very strict - i.e. ((Category described in year)) is only added after all of the elements it replaces are removed from the cat and the cat text is empty, so if any extraneous text exists, that cat is skipped for further investigation. So far, so good, with 0 skips.
The logic of my proposal is that in the first instance all category systems that aren't essentially complete would be removed. Personally, I don't see the need to replicate taxonomic hierarchies in the "described in" category system; I would use "Animals" throughout. "Arthropods" is definitely going. I suggest you work on the 'conforming' categories for now. Peter coxhead (talk) 09:51, 12 May 2018 (UTC)
seeing that my watchlist has gone absolutely gaga - thanks for all the fish work (leads me to think of comments and works from the late douglas adams and various scenes of monty pythons meaning of life and mister creosote ((the fish do say lets get out of here I am sure before he ...)) ).
I have tried to understand the miniutiea damnned word of the conversation above with peter - and hope that where there are either main space series (insects or animals that have had inadequate attention on either main space or talk pages) - that the simplifications to the series andtemplates still make it possible for those prepared to go in under water to play with irregularities (which has happened less in insects and animals) that there is either enough air or you and peter are online whichever comes first...
The reason for concern with issues about irregularities was that the banned user earflaps did similar things in his ventures into festivalising wikipedia and when irregularities appeared or needed fixing - the average editor would not be able to modify or edit the creation - leaving a particular tricky situation where categories or text on the main space were not modifiable without referring to the creator of the template - I do think (I havent looked) that such templates need bells and whistle indications of how and where and who can sort out issues (when they arise).
But if you and Peter say bugger off in monty python style - the templates are closed, it dont bother me - what concerns me is that though you might be around now - (the piano drops from the sky or the bus wipes you both out) what the recourse when something f's up - I would rather a manually created not automated individual tagged (I can rip into a few idiotic talk pages edits without fear or favour and would prefer that) than have to be confronted by an impervious automata with no recourse to manual adjustment JarrahTree15:07, 12 May 2018 (UTC)
JarrahTree, I think what will happen next is that: 1) other already-standardized category trees, ones that will not see any change, will receive ((Category described in year)), then 2) irregular trees will be discussed at either WT:TREE or the appropriate sub-WikiProject, which will either 3) summarily standardize any rogue catagoryographer's(sp) creations, or 4) more carefully discuss whether to standardize it, keep the existing irregular tree, or create/modify it to something more appropriate (probably in that order of likelihood).
When it comes to customizability, ((Category in year)) and ((Category by decade)) will still exist to provide any customization that might be required (though there really shouldn't be any need for that, or at most very few cases). Or, those 2 templates can be used to create a standard tree, which can then be converted seamlessly via this module when noticed, so I think everyone (except the odd rogue) can be satisfied. ~Tom.Reding (talk ⋅dgaf)15:27, 12 May 2018 (UTC)
I love it a new identification Category (not edmund gorey?) grapher (do we get engvar variant spelling for that?) -some of us are called gnomes - however my children and grandchildren are normal size for their ages (sic) - I think of myself as old rogue thanks for the explanation... so no options for over-ride when weirdness happens JarrahTree15:34, 12 May 2018 (UTC)
Correct, there will be no customization as far this module is concerned, as that can already be done via the 2 other templates, or just manually. If said weirdness has consensus though, and frequent-enough usage, it can definitely be incorporated into the module later, or not if it's very irregular (which it probably shouldn't be anyway), so it's best to consider real-world examples at this point instead of flights of fancy :) ~Tom.Reding (talk ⋅dgaf)15:52, 12 May 2018 (UTC)
Thanks for your infinite tolerance and explanation - I suspect the bird, nsect, fish et al are sufficiently clear of weirdnesses - as the Australias late comedian who really was a New Zealander used to say in his early radio shows, rather than say good evening, he used to say I'll get out of your way now - I think I shall likewise. JarrahTree15:57, 12 May 2018 (UTC)
@Tom.Reding: I could be wrong, but don't think you can do cross-wiki checks like that, because while the MediaWiki software knows how to convert [[:commons into [https://commons.wikimedia.org/wiki/, it doesn't actually have access to the database. I do know that the #ifexists parser function doesn't work on interwiki links, so I imagine Lua would have similar restrictions. The best you can do is check if P373 is defined. --Ahecht (TALK PAGE) 19:10, 14 May 2018 (UTC)
I would like to contact you about Pola Nirenska. I am a polish journalist, working on her biography: weronikakostyrko@gmail.com. I would like to ask about some sources, not aviable for me in Poland — Preceding unsigned comment added by 91.238.85.142 (talk) 12:59, 17 May 2018 (UTC)
Hi, I'm just wondering if you know why the AWB wiki gen fixes keep adding wikiproject athletics tags to Sanaa Atabrour. She's a taekwondo athlete not a track and field athlete. Red Fiona (talk) 21:35, 19 May 2018 (UTC)
I was wrong. Thanks for reverting the mistake I made. Didn't know the 21st century began in 2001, you learn something everyday. I hope you can forgive me and hopefully we can be friends. Iamthemostwanted2015 (talk) 16:06, 21 May 2018 (UTC)Iamthemostwanted2015
It's ok if not a bit tedious. Everyone make mistakes. Editors that are here to learn tend to fare the best though, so that's good. ~Tom.Reding (talk ⋅dgaf)17:14, 21 May 2018 (UTC)
Suraj Mal
Hi, is there any chance you could check the integrity of Wikidata rubbish before adding the authority control template? Eg: the stuff it added at Suraj Mal was mostly irrelevant and the bits that weren't irrelevant are not great in other respects. If Wikidata is going to have any use on Wikipedia (doubtful) then this sort of thing does not help the cause. - Sitush (talk) 16:49, 22 May 2018 (UTC)
Thanks for that. You can't fix what you can't see, though. Adding ((Authority control)) allows more editors to more easily see Wikidata's contents, and make the appropriate corrections/additions/removals, as you've just described, making the project stronger. ~Tom.Reding (talk ⋅dgaf)17:14, 22 May 2018 (UTC)
I'm a bit lost, sorry. Why can't you see it? I know that I struggle with the Wikidata interface (despite what it says in my contribution history, I've never directly edited the thing) but surely adding something without checking it is a no-no? And if you cannot check it then you should not add it? You're importing problems from Wikidata and that is one of the big issues that people such as Fram have been banging on about. - Sitush (talk) 13:00, 26 May 2018 (UTC)
Adding poor information with the excuse that we can then change it on Wikidata is one of the reasons many people don't like using Wikidata on enwiki. The purpose of using Wikidata on enwiki is to improve enwiki, not to improve Wikidata. "Adding ((Authority control)) allows more editors to more easily see Wikidata's contents" is a good argument to delete authority control, not to add it to 5 million articles. Fram (talk) 12:12, 27 May 2018 (UTC)
If the main reason you add is to improve the visibility of Wikidata and to get people to correct Wikidata, then yes, that's a reason to delete it. We add templates, external links, because they help our readers, not because they help the other site. Adding such a link which doesn't help our readers (as the info is wrong), and defending it because it may improve the other site, shows a serious problem with either the template (if that's its intention), or the editor defending the use of the template with that excuse, or both. That doesn't mean that I think "Wikidat should die in a fire", I don't think e.g. Findagrave should die in a fire either, but that doesn't mean that Findagrave is a good source for enwiki, never mind a Findagrave page which we know to be incorrect. Fram (talk) 13:00, 27 May 2018 (UTC)
Ah, well the point of adding AC is not to get people to improve WD; the point is to help improve the WP article. Neither WP nor WD are perfect and will require corrections/additions/removals, as wikis do. I understand the concern, but this is a wiki after all, and uncovering/exposing mistakes is the first step to improving it. I do think it would be good for someone to get statistics on what % of AC identifiers are wrong/bad vs. not, though if talk complaints vs. my thanks log is any indication, that % is small. Perhaps some of the WD bot ops which added (and possibly removed) AC IDs can give some insight; might do that later.
Re: Findagrave - useless/unreliable IDs can be removed from the template (i.e. so that they're not drawn automatically from WD, but can be overridden locally if/when desired) if there's consensus. We do the same with ((Taxonbar)). ~Tom.Reding (talk ⋅dgaf)13:30, 27 May 2018 (UTC)
A barnstar for you!
The Space Barnstar
For your astronomic contributions! For taking up so much space!
I'm sorry to bother you, I see you contributed to the Blood Order article. I am having some difficulty with an editor who know claims that the Blood Order and the Golden Party Badge are "trivial" awards and are not to be linked to in other articles. As you contributed to the Blood Order article, I'm hoping you don't consider it a trivial award? My problem is that I don't see what is wrong with linking to a stand-alone article, like the Blood Order, in another article, such as the Ernst Röhm article, which I've been adding content to. I don't see what function a stand-alone article serves if you are not allowed to provide a link to it in another article? I also don't see how it is now, based on one editor's say-so, a "trivial" award? I have asked him why I can't link to a stand-alone article but have received no reply, other than it is now menial and not permitted to be linked. This has happened to me on many occasions, with many awards and decorations. I have asked for a list of so-called "trivial" awards so I know not to link to them again, have my added content deleted and wait for the inevitable aggressive warning (see my talk page). Again, no such list has been made available by this editor, so what do I do? Just add links to stand-alone articles and hope for the best or just stop adding links to stand-alone articles? The thing is, I have added many awards and decorations to many articles, but they still stand, so I'm at a loss as to why it's ok to provide links in some articles but not the ones that the editor in question is monitoring. I'm not asking you to take sides or anything like that, what I would greatly appreciate is your input on the Ernst Röhm talk page. If you feel stand-alone articles are not to be linked, fair enough. If you think it's ok, it would be helpful for the consensus of editors ruling on this. If you also don't view the Blood Order or the Golden Party Badge or any others as "trivial", which I'm thinking you don't as you took the time to add to the article, it would be greatly appreciated if you could say so. I just don't see the problem with linking to stand-alone articles. If they're not link-worthy, what function do they serve?
I saw that you were the most recent editor for a page on General Robert Stobo.
I'm not an editor here, so I thought I would let you know that there is a very small part of Southwest PA that is named for him. Nearly my entire family is from "Stobo," which is almost a town-within-a-town located in Center Township, Beaver County. I wouldn't know how long it's been called Stobo, but I know that when my grandfather went to the one-room schoolhouse there, he said that *his* grandfather called it that. It's often very tongue-in-cheek called the "Capital of Center Township." We all were very excited to see that we've made it onto several maps and you can easily find us just by punching our name into Google Maps :)
Anyhow, it's probably not really relevant to the article but, since you had edited the page and I assume have some interest in Gen. Stobo, I thought I would let you know :)
I noticed that you removed the orphan tag from Statement analysis after I got some wikilinks to it. Thanks. Also, how did you do that? I couldn't even see that it had a tag on it and only knew it was orphaned because a bot swept the page up and sorted it into this list. I'm super not familiar with AWB and not really sure I want to get into semi-automated editing but it would be great to be able to take orphan tags off of things that I link to. Please ping me, I will not be following your talkpage. Rap Chart Mike (talk) 19:26, 9 August 2018 (UTC)
Rap Chart Mike, yes, I used WP:AWB and Quarry to find pages with 3 or more incoming, mainspace, non-redirect links. ((Orphan)) tags/templates are usually at the top of the page and you may remove them manually if appropriate. To manually check the incoming links, you can click "What links here" in the left margin of the page under 'Tools'. ~Tom.Reding (talk ⋅dgaf)19:43, 9 August 2018 (UTC)
::Awesome thanks. I saw the button on the side and was using that but since I wasn't actively editing the pages and just getting stuff linked to them I didn't notice the tags. But now I know and I'll cruise back thourgh and detag them before the bot goes collecting again on the 14th. Rap Chart Mike (talk) 19:58, 9 August 2018 (UTC)
The "numbered unnamed" category became obsolete due the numerous asteroid family categories which do contain both named and unnamed bodies.
The "unnumbered" contained de facto only 2 entries and can be listed directly in "Main-belt" as long as no family or orbital classification is possible.
The new Category:Background asteroids which is complementary to all family/dynamical group subcategories currently contains 14,381 items, unfortunately not much less than the 17,500 (at WT:AST) asteroids you tried to break-up in more categories in 2016. However, since then several thousand new MP#Rs have been created (and I will further categorize some of these background asteroids) so that the overall situation is now better in that respect than it was in January 2016.
Suggestions
Category:Minor planet redirects has once been criticized as a maintenance category. I think it is now possible to include this category directly into ((NASTRO comment)) (where |do-not-cat= is not set to "yes"). Furthermore:
Since my revision, the redirect category is always listed last, so removing it leaves no empty line.
The sortkey for said category is the "PageName", so inclusion into NASTRO-comment would be easy as well.
Wow, that's great! I've been busy IRL, and on-wiki with WP:TOL categories (aside from the usual I've-already-got-a-script-for-that sorts of things), so will need time to digest this more carefully. Thanks for summary. ~Tom.Reding (talk ⋅dgaf)16:44, 21 September 2018 (UTC)
Rfassbind, that looks like a good idea. I wouldn't mind doing it either; it's been a while since I worked in the asteroid field.heh I've thought about converting ((NASTRO comment)) to a Lua module, though, and this might be a good time to do that. What do you think? ~Tom.Reding (talk ⋅dgaf)12:49, 25 September 2018 (UTC)
Please go ahead and include the redirect category into NASTRO comment, so that the hard-coded version of said category can be removed from 23,000+ minor planet redirects (maybe you should remove them before amending the template). I already prepared maintenanceCategory: Minor planet redirects and documentation of Template:NASTRO comment § Category: Minor planet redirects.
Lua module: I think you know better than me whether or not the template should be converted into a Lua module. I thought this is to enhance performance, and I don't see why a template never used more than once on a single page needs a performance boost. I will need, however, adjust all my tools to that change.
When it comes to ((NASTRO comment))'s WikiData parameter, it's better to require the Q before the number (or strip any leading Q and add it, regardless), so it's more intuitive to other editors what that number is signifying, and since it's a very cheap identifier. This is done on all ((Taxonbar)) templates, and a few select ((Authority control)) templates (since they usually don't need a Q param). ~Tom.Reding (talk ⋅dgaf)13:06, 25 September 2018 (UTC)
We can include the Q-prefix later on when things are sorted out. Currently, it is not clear how to handle unnamed MP#Rs that are not yet –or will never be – associated to a Wikidata item. Rfassbind– talk13:28, 26 September 2018 (UTC)
Main-belt category results
Rfassbind, I'll start migrating the Category:Minor planet redirects to ((NASTRO comment)) today or tomorrow. I'll take before-and-after snapshots of the cat and template transclusions to make sure no #Rs were accidentally added or removed for whatever reason. Currently, as desired, all category pages transclude ((NASTRO comment)) (I only found 3 strays out of 23k, and quickly fixed them). I prefer to minimally disrupt the category contents so I'll add the cat to the template first, then remove the hard-coded cat from the #Rs. If all goes well, the cat and transclusion lists will go unchanged; fingers crossed... ~Tom.Reding (talk ⋅dgaf)19:16, 29 September 2018 (UTC)
Done! There were many fewer than expected, and before-and-after results are good.
I just realized - another benefit to using Lua is that Category:Named minor planets, and possibly others, can be detected automatically and added based on the structure of the page name. Just something to consider, and not any sort of priority. Because the other 2 name-cats are now obsolete, this isn't as useful now. It would have been much more useful years ago, but Lua's embedding into WP was in it's infancy (plus I didn't pick it up until recently). ~Tom.Reding (talk ⋅dgaf)22:02, 29 September 2018 (UTC)
On hold - Rfassbind, before I go too far down the road, can you go through that list of 191 comets and see if they all belong in Category:Minor planet redirects? I'm envisioning comet #Rs (either now or in the future) that rightfully deserve some form of ((NASTRO comment)) but don't deserve to be in Category:Minor planet redirects, and how to potentially deal with them. I wouldn't want to create a |minor-planet=yes parameter, as that would defeat the desired automatic behavior, but a |comet=yes param would be ok since there would be many fewer non-MP comet #Rs. ~Tom.Reding (talk ⋅dgaf)14:09, 30 September 2018 (UTC)
Hi Tom. I just came back from my vacation. Thanks for your efforts. As both, unnumbered minor planets (uMPs) and cometary redirects also use "NASTRO comment", additional changes need to be made. Your proposed |comet=yes seems straight forward. Alternatively, I would prefer, to rename our category to Category:Small Solar System body redirects, if MPs, uMPs and comets could be sorted separately in the category listing. I don't know, but is there a way that the template syntax can:
analyze the page name for containing slashes, parenthesis and/or ending with a digit?
or – as a second way to distinguish ~the different object types – check the redirect target to know whether it contains "List of minor planets" or not?
If this is not possible, then your proposed solution comet=yes would be best. The very few uMPs can be modified manually and receive a sortkey that is different from their page name.
Rfassbind, with this, we've definitely wandered into Lua territory, where doing things like page name analysis and parsing is easy and cheap. Unfortunately, there is no way to parse the #R target, as that is tantamount to parsing article text outside of a template.
Sure, I can ignore diacritical names when removing the hard-coded cat. Do you want to keep these b/c there's no appropriate R-template for them (i.e. ((R from diacritic)) is only for targets "of essentially the same page name without diacritics")? It might be time for a new R-template... ~Tom.Reding (talk ⋅dgaf)13:23, 5 October 2018 (UTC)
OK, then simply let us, as you suggested, use a comet=yes parameter, since Category:Comet redirects, created by myself just a few months ago, already exists... Thanks for checking (I am also thinking about another param, "r-sortkey" to set the sortkey if other than page name, so we can group the few uMPs). As for the second point, there is a misunderstanding: I am saying that you should have removed the hard-coded redirect category from all primary, NASTRO versions, but you did not do that for at least some redirects, all of them having diacritics in their name. I only checked a few pages (including the two examples above), and they still contain a hard-coded version. Let me know if you want me to do the removal. Rfassbind– talk13:51, 5 October 2018 (UTC)
Rfassbind, ah, I've only done a tiny fraction of the removal - I stopped when I noticed the comets. Will resume soon after |comet= (or possibly |true-comet= and |hybrid-comet=) is/are implemented. The idea being that hybrid objects should belong to both cats, and the template would behave accordingly. ~Tom.Reding (talk ⋅dgaf)14:08, 5 October 2018 (UTC)
Ah OK, that explains everything. So I presume you'll remove the hard-coded Category:Comet redirects as well. Currently this cat only contains numbered comets; redirects of unnumbered comets (e.g. P/2011 R3), do not have a ((NASTRO comment)), but will need one as well (if you can do a search for these "C/" and "P/" D/, X/ A/ type I would appreciate). Rfassbind– talk14:35, 5 October 2018 (UTC)
Rfassbind, the more I look into comets (I went through that list of 190-something), the more reluctant I am to make case-specific comet parameters that encode the different grey area designations between comet and asteroid, namely Jupiter-family comets, Encke-type comets, and possibly others(?). A simpler solution may be to instead use a |minor-planet=no parameter when the object shouldn't belong to Category:Minor planet redirects, and continue to use hard-coded comet categories. What do you think? ~Tom.Reding (talk ⋅dgaf)23:28, 7 October 2018 (UTC)
Sure, the simpler the better. This only concerns a few hundred primary NASTRO comment items out of a total of nearly 24,000, so if anything needs to be improved in the future, it can be done easily later. Thanks for the efforts. Rfassbind– talk12:19, 8 October 2018 (UTC)
I searched the latest WikiDump for all pages matching ^\d*[CPDXA]/, and found ~1000. I whittled this down to 529 comet #Rs (C#Rs), and added ((NASTRO comment)) as appropriate to 291 of them (maybe a handful of unnecessary |minor-planet=no's, but not a big deal). The remaining 238 (45%) are a bit trickier; many need to be as designated primary vs. secondary C#Rs. This will take a considerably longer amount of time than the first half, so if you're able to help, see my sandbox for the full list of 238 C#Rs. ~Tom.Reding (talk ⋅dgaf)18:28, 11 October 2018 (UTC)
Y I completely revised the group of 238 C#Rs (they already contained |minor-planet=no, and, as far as I see, NASTRO-comment does not yet include the redirect cat for C#Rs). I also created some missing numbered C#Rs (not listed), and corrected two erroneous C#Rs. I will also take a look at the second, "uncontroversial" part of the list. Rfassbind– talk20:38, 13 October 2018 (UTC)
Thank you. I think it would have taken me about a week to get through those.
Yes, I would be overstepping my bounds if I assumed that using ((NASTRO comment)) to automate comet cats was definitely a good idea (let alone to figure out the best way to implement it). ~Tom.Reding (talk ⋅dgaf)21:38, 13 October 2018 (UTC)
I've finished looking at all the articles that were placed in these three categories. All but one – where the century was the only category – had "described in year" and "described in century" categories, which is clearly wrong. Sadly this is only too typical of the mess that exists over much of the category system. Anyway, this little bit is sorted now!
More generally, there's the issue you raised earlier of whether we ever need the "described in decade" categories. I put them in for spiders, because some already existed, but I now wish I'd gone the other way. The arguments against decades are:
The categories are against MOS:CENTURY; the first decade should be YY01–YY10 not YY00–YY09 to fit properly in the century categories. The result is that when decades are present, "described in 1900" ends up indirectly in "described in the 20th century", but when decades are absent, it is (or should be) in "described in the 19th century". (This seems to be the reason why some organisms had the years in both the decades and the centuries categories, but this was regarded by most editors as overkill to fix an issue with only two years of each century.)
The complete set of years for a century are not excessive for a category and are easily navigated.
It makes yet one more set of categories that need to be maintained and often aren't. Simpler is better!
@Peter coxhead: indubitably... I'm currently slowly, but systematically, CfD'ing (not CSD'ing, though the thought did cross my mind) these decadal cats on a project-by-project basis, based on the response of your RfC and per our discussion a few months ago. I'm doing this piecemeal because
each category group (plants, spiders, fish, etc.) seem to have their own peculiarities, and, so far, are benefiting from more personal attention,
just in case a particular WikiProject chooses (and has a good reason (though I can't imaging one right now)) to keep their decadal cats, and
being a bit verbose is more likely to dissuade their future (re?)creation by being simultaneously informative and providing more reference points for consensus (i.e. someone at bivalves might not be watching TOL, etc.).
I'm currently waiting for one CfD to finish before starting another, though I might speed this up, either by grouping more into the same CfD or by making a few simultaneous CfDs separated by WikiProject, if I see a lot of commonality amongst the trees or continue to not receive any pushback.
Hi Tom. Hope you're well. If you recall, back in March you set a bot running to tag the talkpages of articles related to the Olympics that didn't have the WP:OLY tag on their talkpage. I was wondering if you could re-run it again? There's no rush, I'm more curious as to how many articles this would be in the six months since it was last done. Thanks in advance. LugnutsFire Walk with Me18:04, 29 September 2018 (UTC)
Hi Lugnuts, that's no problem. The petscan query used in the original run (which found ~13k articles that needed tagging) is here. It now returns only 248. I have a few other things on my to-do list, if you wanted to tag them yourself. Otherwise, I could do it myself in about a week's time. ~Tom.Reding (talk ⋅dgaf)18:26, 29 September 2018 (UTC)
Materialscientist, the apostrophe was changed from ’ to the WP:MOS#Apostrophes-preferred ', which affects the rendering of the page. I also fail to see why you'd think this would be controversial. ~Tom.Reding (talk ⋅dgaf)
Technically your changes do affect the page rendering, but nominally they do not. You may wish to consult users with extensive knowledge of such matters, like Magioladitis, MSGJ, Spinningspark, Xeno (he is around, but not much), etc. Materialscientist (talk) 05:27, 17 October 2018 (UTC)
Categories
The correct procedure (rather than emptying categories and then bringing them to cfd for deletion) is to bring them to cfd for merging and then a bot does all the work (assuming people agree - there is no automatic right of wikiprojects to make their own decisions re categories).
On the whole I agree with most of what you are doing but not everything. Category:Mammals by year of formal description is clearly wrongly named (or wrongly populated) and your edit is wrong (per higher authority than species by year). Many of these trees have been created and populated by rogue editors and should not be taken as exemplars. See eg Category:Films by date which in my opinion makes sense: by century has centuries, by decade has decades and by year has years. Or Category:Operas by date. I would also be suspicious of anything such as Category:Works by period of creation created by Stephanomione who moves on an exalted plane beyond the understanding of mere mortals. Oculi (talk) 16:18, 13 October 2018 (UTC)
For some reason, empty categories tagged with ((Db-c1)) are no longer automatically deleted after 7 days, this applies also for example to Category:Lizards described in the 19th century that you tagged. A remedy that immediately helps is opening the category page and making a null edit, and I have done that with a large number of tagged category pages yesterday. (I noticed that some of these pages were tagged more than 20 days ago.) But making null edits in every page is not a sustainable solution. Do you know who could help solving this problem permanently? Marcocapelle (talk) 06:25, 14 October 2018 (UTC)
@Marcocapelle: this may be a wider problem caused by the slowness with which the Wikimedia software updates template-added categories as opposed to those actually present on a page. Thus I find that articles that get put into the error-tracking category Category:Automatic taxobox cleanup because of an error in a taxonomy template stay there long after the error is fixed, and to remove them I have to make a null edit on the article, which is time wasting. Peter coxhead (talk) 13:15, 14 October 2018 (UTC)
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.
You asked for an example of a place where AutoWikiBrowser's replacement of "ie" with "i.e." was erroneous in linguistics articles. Here's one: [6]
(Sorry for breaking the "continue where started" rule, but the page where this conversation started has been archived already! I overlooked the notification of your response until now 'cause it was in amongst a bunch of failed login attempts spam.) 4pq1injbok (talk) 09:19, 16 October 2018 (UTC)
4pq1injbok, thanks! I do remember that. I just checked the current version of Lithuanian declension and the old version just before AWB's typo fix triggered (November 2010...), and it appears the rule has been fixed since then to ignore this proper usage of "ie". ~Tom.Reding (talk ⋅dgaf)12:42, 16 October 2018 (UTC)
Hi Tom. A bunch of the pages in the bamboo species category don't have any other taxonomic category. It looks like you may have noticed this and left the category in place on these articles. I'll go through and place the articles in question in more appropriate categories, but I do need them to stay in the bamboo species category for now so I can find them until I have a chance to recategorize them. Thanks for your efforts clearing out the species categories. Plantdrew (talk) 03:19, 10 November 2018 (UTC)
Plantdrew, yes indeed, I sorted out the bulk "normal" pages which had only 1 '... species' cat (I think I'll make an exception for Category:Invasive plant species, keeping it, and removing, for example, Category:Fern species) and the correct genus cat (correcting its sortkey while I was at it), and left the rest to sort out later. FYI, I found ~500 pages missing a genus cat under Category:Plant species, the vast majority of which don't exist, so I'm very happy for someone more qualified to judge whether or not they should be created. Another ~150 had non-binomial page titles so I didn't run any checks on those yet. Also, I'm still finding & fixing |status_system=iucn & |image_size= in my travels. ~Tom.Reding (talk ⋅dgaf)13:07, 10 November 2018 (UTC)
Tom, re plant species, there should only be a genus cat if the genus is sufficiently large. I can't claim to have looked at all of the members, but those I did look at all had a taxonomic category, e.g. a family category. Peter coxhead (talk) 17:36, 12 November 2018 (UTC)
First few partial pages with Template:TOC001
Hi Tom, ((TOC001)) is designed not to show 101s-links to the local wiki tables in the first six pages for both LOMP and MOMP. This should be a feature (rather than a bug) but I don't see any reason for this omission. Don't you think it would be better to always show the 101s-links? Rfassbind– talk22:19, 10 November 2018 (UTC)
Rfassbind, yes. I think this may have been for two reasons: 1) as an artefact from the fact that the lower pages used to be separated in increments of 500 (and the reason ((TOC001.5a)) & ((TOC001.5b)) exist, which incidentally I think I'll TfD), and 2) it might not have looked good for some reason. If it still looks good, I say go for it. ~Tom.Reding (talk ⋅dgaf)01:04, 11 November 2018 (UTC)
OK. The "looks" can't be any different since the header for all pages is the same. I also think this is a legacy thing, and the deletion of mentioned templates seems fine to me as well. Rfassbind– talk02:41, 11 November 2018 (UTC)
Y Done. It was a little bug. The "hundreds"-links were placed inside the (useful) condition that prevented the links to the preceding pages to become nonsensical (negative) when the current one is low enough. I moved them out of this condition and added a different set of "hundreds"-links for the first page (otherwise they would show 0,001 ... 0,101 ...). Rfassbind– talk03:46, 11 November 2018 (UTC)
Move "Category:Numbered minor planets" into "Template:Minor planets navigator"
The category is basically meant for articles of numbered minor planets, as minor-planet redirects do not contain it. Currently, the category contains 3,061 items, while ((Minor planets navigator)) has been transcluded 3,086 times. As WhatLinksHere shows, the difference comes from transcluded non-minor-planet object-articles such as Asteroid and Minor planet, and several pages in the User, Wikipedia and Template name spaces. Is it possible to add "Category:Numbered minor planets" to the MP-Navigator only for transcluded pages in the Article namespace? That would resolve the discrepancy for all but the two mentioned articles. Rfassbind– talk13:20, 13 November 2018 (UTC)
Great, thanks! (Now I can get back to where this all started, namely fixing the automatic italicization of article and taxobox titles. My initial fix ran into problems because of the incorrect parameter use in so many taxoboxes.) Peter coxhead (talk) 06:36, 19 December 2018 (UTC)
Our survey should take about 10-15 minutes of your time. We hope that you will enjoy it and find the questions interesting. All answers will be kept strictly confidential and will be anonymized before the aggregate results are published. Regretfully, we can only accept responses from people who live in the US due to restrictions in our grant-based funding.
As a reward for your participation, we will randomly pick 1 out of every 5 participants and give them $25 worth of goods of their choice from the Wikipedia store (e.g. Wikipedia themed t-shirts). Note that we can only reward you if you are based in the US.
Peace is a state of balance and understanding in yourself and between others, where respect is gained by the acceptance of differences, tolerance persists, conflicts are resolved through dialog, peoples rights are respected and their voices are heard, and everyone is at their highest point of serenity without social tension.
Continuing efforts to clean up taxonomy templates and thus simplify the coding of the automated taxobox system – which currently tries to cope with considerable variation (and indeed errors) in the input, making the code obscure in parts – I created Category:Taxonomy templates using capitalized rank parameters, expecting there to be a few templates to clean up. As of now there are 888. Sigh... Would you be able to run a bot to fix them? The first nonblank after |rank=, with variable amounts of white space, should be a lower-case letter; thus Template:Taxonomy/Acanthogobius should have |rank=genus. Thanks in anticipation. Peter coxhead (talk) 09:34, 6 January 2019 (UTC)
Might as well, use the section for a similar request. There are a lot of ((taxobox))es with accidental positional parameters (i.e. missing the =). In particular there seem to be 1771 with |infraordo=[[Heteroneura]], as revealed by the following search:
Done. I see that most of these errors went unnoticed since 2010! I also searched through all transclusions of ((Taxobox)) to find only 35 similar issues for (I think) all ranks via (\|\s*(?:unranked_)?(?:sub|super|infra)?(?:regnum|divisio|phylum|classis|ordo|zoodivisio|zoosectio|familia|genus|sectio|species))(\s*)(\[\[). Let me know if I missed any possible ranks.
I've used to notice, though rarely, that a sub/super/infra rank is listed at Wikidata for a species, but is missing from the infobox. I didn't expect this to be the reason... ~Tom.Reding (talk ⋅dgaf)02:53, 11 January 2019 (UTC)
@Jts1882: I relaxed & expanded the end of the regex to find more errors, and removed some false-positives in the beginning:
@Ganeshk: I plug the article title into the WP API, scrape the output for wikibase_item":"([^"]+), where $1 is the QID, then feed that back into the article text after processing/safety checks/etc. ~Tom.Reding (talk ⋅dgaf)04:45, 7 January 2019 (UTC)
MusicBrainz Authority control
Hey TR: saw you created 7 new cats for the abbreviated MusicBrainz authority control codes (MBAREA, etc); Module:Authority control already populates spelled-out categories whenever there is a MusicBrainz authority control entry. Aren't the new cats you created redundant to the previously existing ones, and therefore shouldn't they be deleted? UnitedStatesian (talk) 21:58, 22 January 2019 (UTC)
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.
I did a bunch :) and avoided pages with a disambiguation in their title (i.e. "(plant)"), which were done more carefully by others. I decided to refresh all of the ((Automatic taxobox)) pages to populate the category, instead of just letting it happen slowly & randomly, so all current (as of yesterday) transclusions have been updated with the most recent code. It actually coincided with my search for floating parameters (i.e. params not followed by a =), so I had all the necessary machinery already up and running. ~Tom.Reding (talk ⋅dgaf)13:48, 5 February 2019 (UTC)
Thanks for checking! I responded to the "Capitalisation" question on WP:AWB/T in an attempt to continue conversations on the same talk page that they started. Thanks! GoingBatty (talk) 15:41, 9 February 2019 (UTC)
Userboxes
On Productive Interests in your Userboxes, you have This user plays ultimate twice. I could have edited it, but I wanted to seek your permission before doing anything to your user page. Mstrojny (talk) 13:40, 9 February 2019 (UTC)
Tom, could you run a null edit on all the entries in Category:Taxonomy templates with different name and link text – no fixing, just a null edit to get it up-to-date with the latest module code? (I initially used a weak definition of "matching" for template name and link text, partly to see what the issues were. There's a stronger definition in place now, so many of the entries will disappear with time. It would be nice if they went faster!) Thanks. Peter coxhead (talk) 12:16, 18 February 2019 (UTC)
I found this red link in your userboxes: User:EliminatorJR/Userboxes/Curry Addict in the Opinions/Preferences/Personal section. Not sure whether you want to remove it more not. Mstrojny (talk) 19:42, 17 March 2019 (UTC)
My long term goal is to unify the coding of the automated taxobox templates into one main module: there's a lot of overlap in the template code; it's inefficient and hard to understand since values derived from the parameters have to be repeatedly worked out because of the absence of variables; there are subtle differences in the behaviour of the templates that are confusing to editors that use them.
One example of the last is whether and how the automated taxobox templates automatically italicize the page title. The main templates, ((Speciesbox)) and ((Automatic taxobox)), do, but others, like ((Infraspeciesbox)), don't.
However, I know from when I did something like this before that there are objections to pages in mainspace being left linked to sandbox versions of templates, so the changes need to be made more quickly than I can edit them manually.
@Peter coxhead: sure, let's coordinate. I'll be available for the next 1.5 hrs and after 4pm ET to remove ((DISPLAYTITLE)) after you update ((Infraspeciesbox)). Ping me in that edit summary or here and I'll take care of the rest. That's the best order to do it when AWB is available, since removing ((DISPLAYTITLE)) first has a 100% chance of changing the page display immediately, whereas updating ((Infraspeciesbox)) first has a < 100% chance of changing the display immediately. Without AWB, I'd say linking to the sandbox temporarily would be preferable over anything that changed the display (let naysayers neigh). ~Tom.Reding (talk ⋅dgaf)11:53, 9 April 2019 (UTC)
I recently did something similar (Template_talk:Cite_wikisource#new sandbox version that abandons citation/core). I created ((cite wikisource/interim)) precisely to preclude any whining that might have arisen from using ~/sandbox. In the edit summary, I include a link to the talk page discussion where I described what it was that I was doing. No complaints.
@Trappist the monk: yes, I guess that's another way to do it – create ((Infraspeciesbox/interim)) rather than link to the sandbox; I've certainly had whining when I left links to ~/sandbox even for a short time. However, I guess if Tom can do a run quickly after I update ((Infraspeciesbox)), so that the errors caused by having two occurrences of ((DISPLAYTITLE)) disappear quickly, then it should be ok to do it as he suggests. Peter coxhead (talk) 16:08, 9 April 2019 (UTC)
@Tom.Reding: I should be able to ping you again about 4:15pm ET (9:15pm here in GMT summer time if I have it right), so if we're both active let's do what you suggest: I'll update ((Infraspeciesbox)) and you then remove ((DISPLAYTITLE:...)) from all pages that transclude ((Infraspeciesbox)). Peter coxhead (talk) 16:08, 9 April 2019 (UTC)
@MilborneOne: US/American: for this case I agree, but a larger WP:AIRCRAFT survey is required - if you look at Category:Aircraft by country, "United States" is the convention, but for Civil aircraft, "American" should be used. My guess is that this there are multiple overlapping (sub)hierarchies using different standards.
Taiwan is officially the Republic of China, but Republic of China is also historically ambiguous, so I'd naively prefer Taiwan to disambiguate.
Politics and avoiding silly arguments? Some people object to using American for the United States and here you could argue it is ambiguous (compared to European aircraft). And anything to do with the naming of Taiwan can be contentious as China considers the Taiwanese to be Chinese. Jts1882 | talk14:47, 11 May 2019 (UTC)
Thanks for the comment, I will raise the US/American at project, American is not ambiguous in English, as for ROC/Taiwan wikipedia main article on the country is Taiwan so we should follow that. MilborneOne (talk) 15:20, 11 May 2019 (UTC)
Thanks for helping on AWB cleanup
Hi Tom,
I greatly appreciate your dedicated work on AWB cleanup and would love to hear from you about my latest project: User:Uziel302/Typos, where I upload lists of high probability typos and with a script I wrote I correct the real typos in one click. No need to set up AWB setting for each replacement, and if the replacement is inaccurate, you can put alternative replacement in a simple popup.
Hi Tom, I created settings XML of less frequent replacements and a list of the articles where they are found. You can load those lists from Wikipedia:AutoWikiBrowser/Settings/Autocorrect and the talk page and start fixing thousands of obvious typos across Wikipedia, few seconds per fix. I hope you will find this list useful. Any feedback is much appreciated! Uziel302 (talk) 14:18, 21 July 2019 (UTC)
I didn't get what you removed. If you had to skip, the typo was probably fixed before, or had no spaces around it, and it will show skip for the next user. I can make new list whenever needed, I scan the dumps in 2 hours on my laptop, I wanted to see if there is usage first. In short, simply remove to the point you got, don't waste time on editing the list. Uziel302 (talk) 20:14, 22 July 2019 (UTC)
@Uziel302: those 100 I removed were ones I corrected today, per instructions on the talk page. I skipped about 70 others while doing those 100, but chose to keep them on the list for the same reasoning. There were a handful of others that were invalid fixes, which I think I'll remove in a separate edit later. ~Tom.Reding (talk ⋅dgaf)00:56, 23 July 2019 (UTC)
I changed the instructions: "update the list so future users won't need to skip those fixed/skipped articles". If you have time to remove invalid fixes, please do so on the settings XML. Uziel302 (talk) 06:06, 23 July 2019 (UTC)
Thanks a lot for your exceptional work. I guess most of the skips were corrected since, it was based on December dump, I now downloaded July dump and I hope it will have less skips. I also need to filter anything without spaces on both sides, otherwise it replaces parts of legit words. I tried to use \([^a-zA-Z]\) in the find statement but with 7K replacements it really makes a performance drop and makes the process tiring. Uziel302 (talk) 06:57, 25 July 2019 (UTC)
@Uziel302:\b and \sshould be faster than a large user-defined range - have you tried those? "Beginnings are expensive" when it comes to regex, so you can try removing any leading [^a-zA-Z] and use a positive/negative lookbehind at the end (many examples in WP:AWB/T). Try each of those separately, then together, to see what yields the best performance. Also, how are you going to handle permanent false positives that will persist from dump to dump - a whitelist maybe? If so, how do you prefer to be notified of candidate pages - perhaps on an appropriately named subpage? ~Tom.Reding (talk ⋅dgaf)12:14, 25 July 2019 (UTC)
b seems to work better performance wise. I currently use titles of wiktionary as whitelist, so if some of the legit words should go there, add them there. Anything else put in the whitelist. Uziel302 (talk) 19:43, 25 July 2019 (UTC)
I made a new replacements list, I uploaded to my private wiki, because of size limits here: [7], output of the scan ordered by frequency: [8] and full articles and their replacements list: [9]. I updated XML and article list. b works great even on both sides. Uziel302 (talk) 06:12, 26 July 2019 (UTC)
I just tried the tool myself and I think it is less convenient than the user script verion. In my user script version I send the edits via JS so it's async and let you go over many typos without waiting for each edit to save. Uziel302 (talk) 08:51, 26 July 2019 (UTC)
Regarding your recent changes in Module:ConvertNumeric
Hey Tom,
Regarding your recent changes in Module:ConvertNumeric, there is no need to create duplicated tables that fork the same data.
I've put up a mock up of code that explains how I would have done it. There are two options that I can see, not sure which is more efficient, so would leave that up to you. The code is located at Module:Sandbox/Gonnym/sometest2. It currently looks for the hard-coded value of "nineteen" and returns the number (the original key).
@Gonnym: yes, I thought about doing something like that, but decided against it for 4 reasons: 1) hard-coding is faster, 2) more transparent, 3) the new tables (except eng_lt20) are not exact inverses of each other, and 4) there's no threat of forking, unless we collectively decide to stop using base 10. ~Tom.Reding (talk ⋅dgaf)17:20, 13 June 2019 (UTC)
I now see that the other 2 templates are different. There really is no need to that, as hardcoding should never be the option used, especially in this case where you are essentially duplicating the same code. I'm also not sure a longer code base equals more transparent code. Yes, you've might have made this part more transparent, but the entire code has become unnecessarily longer and more confusing because of the dups which can create confusion. I've added another example which is a full set of the code for up to 99, which includes a setup for higher values. It does it easily with the current tables and very few extra line. A few examples:
@Gonnym:whyshouldhardcodingneverbe used? Doing as you suggest is needless overhead. There's no code being duplicated, but 1 table inverted, and 2 new tables which share only words with another table but not numbers. If others have a problem with the length of table definitions (~200 total lines before, and ~230 now), then they can be moved to a /conf sub-module, or similar. ~Tom.Reding (talk ⋅dgaf)23:00, 13 June 2019 (UTC)
I'm not going to check the links you've posted as you've not really added line numbers to a specific point. I'm also not sure if you are serious or not, but any average coder knows why hardcoding is bad. Yes, when creating constants and with short pieces of code, hardcoding is ok, but this isn't it. Also, saying 2 of the tables are not hardcoded is just false, as I've literally showed you that I'm reusing them. Also, the overhead from my code is very minimal, compared to confusion of 3 duplicate tables which make the actual reading and debugging of the module code harder (the code line difference is 26 vs 21 + your 3 tables). Anyways, not going to argue this with you anymore, if you can't see why what you are doing is wrong and feel like fighting for it, then go ahead. --Gonnym (talk) 08:33, 14 June 2019 (UTC)
I'm not sure why you'd think I'm joking. Do you mean "sarcastic"? Regardless, neither are true.
What statement of mine is "saying 2 of the tables are not hardcoded is just false" referring to? Did you mistake the word "hardcoded" for "duplicated"? If so, then our definitions of the word "duplicated"...are different.
Re: "make[s] the actual reading and debugging of the module code harder": meh, but a /conf sub-module, or similar, is still the solution, especially if the dictionaries grow as functionality expands. ~Tom.Reding (talk ⋅dgaf)12:22, 14 June 2019 (UTC)
Renamed categories
Hi Tom, I noticed that you renamed the sequential subcats of Category:Knesset informally. Well, WP:IAR, when appropriate. However, you omitted to check backlinks to the old names, which in this case were left in the ((cat pair)) templates on each of the renamed pages. If you had used WP:CFD, this would have been caught as part of the implementation. Anyway, I fixed the links. – FayenaticLondon08:18, 21 June 2019 (UTC)
Hi. I just noticed that you reverted this back in even after multiple editors had called you out for it, and even marked the edit as minor. You also demanded that the nomination be withdrawn based on its inclusion of pages you added. I can't see how you could possibly think this behaviour to be appropriate, but I'm imploring you here and now to stop and let the original nomination proceed without your POINTy additions. Hijiri 88 (聖やや) 00:26, 9 July 2019 (UTC)
I have no idea what you are referring to. You altered another editor's comment to change what it meant, and in doing so misled several editors (including myself) into (temporarily) !voting the wrong way in an AFD. This is clearly disruptive, and wikilawyering over what policies and guidelines you think I cited (I am not going to click on the five diffs you provide with no context above) is not helpful. Hijiri 88 (聖やや) 04:05, 9 July 2019 (UTC)
@Otr500: my comment is indented the same as the previous editor because we're both responding to Rfassbind's proposal. If I increased my indent, I would appear to be responding to the editor immediately above, which isn't the case. If you're responding to Rfassbind (it looks like you are) then you should use the same indent. Bullets are actually appropriate here (I'll strike my suggestion that they're not), especially if more people chime in, and adding them to previous comments may be considered a housekeeping measure to aid readability, so feel free to add them if you think it's helpful. ~Tom.Reding (talk ⋅dgaf)12:56, 9 July 2019 (UTC)
Copyedits on Ectomycorrhiza
hi, I noticed that you had fixed some curly apostrophes in the article I'm working on, Ectomycorrhiza. If you're planning to do more edits, would you please let me know? It's a gnarly page and I'd hate to get into an edit conflict. Thanks! Logophile59 (talk) 23:16, 15 July 2019 (UTC)
I see that you have updated the SIMEC Atlantis Energy page!
It seems that the update isn't pulling through to google as when you google the company the "Atlantis Resources" logo still appears on the right hand side.
Not too sure what to make of it, as I see on wiki there is the correct logo.
thanks!
Molly
Can you help with this taxobox issue
The monthly template parameter check shows there are 527 taxonboxes using |infraclass=Neoptera rather than |infraclassis= (see list). All those I checked date back to the page creation in 2012. Can this be easily fixed with a bot? It's obviously not urgent, but any help would be appreciated. Jts1882 | talk09:01, 13 August 2019 (UTC)
Thanks. No rush, as they've been there seven years. It's nice to clear out erroneous parameters from the monthly parameter reports and 500 is too much to do manually. How would I go about learning how to do such things with bots? Jts1882 | talk16:39, 13 August 2019 (UTC)
(EDIT CONFLICT; yes bots would be nice) |infraclass= appears exclusively in species articles. We don't usually display minor ranks (sub-, infra-, super-) far down the taxonomic hierarchy. Minor ranks are shown only in articles where they are between the next highest major rank (so an article on an order could display subclass, infraclass, superorder, but an article on a species would display subgenus). Articles with |infraclass= also have |subphylum=, |subclassis=, |subordo=, |infraordo= and |superfamilia=. All of that should just be deleted.
@Jts1882:, I go through the parameter check every month when it first comes out and fix bad parameters used in few articles. There are several bad parameters that are used in hundreds of articles that I have not yet made the effort to fix. I figure it's not worth the effort to fix widely used bad Taxobox parameters on their own, when the articles should just be converted to Speciesbox eventually anyway, with the bad parameters eliminated in that process. I do periodically pick a bad parameter from the report to eliminate via conversion to Speciesbox, although I'm generally pretty busy converting plant articles to Speciesbox.
Tom, if eliminating other bad parameters in manual Taxoboxes feels like a productive use of your time, check out |cohorto= (list), |subcohorto= (list), and |zoodivision= (list). Cohorto/subcohorto aren't supported by Taxobox at all. Zoodivision should be |zoodivisio=. Mostly these three minor ranks appear in species/genus articles, along with other minor ranks that also shouldn't be displayed so far down the taxonomic hierarchy; the minor ranks should just be deleted. |subdivisionRanks= (list) is a bad parameter that should be changed to |subdivision_ranks=. Plantdrew (talk) 16:49, 13 August 2019 (UTC)
I'd never notice that Cohorts weren't supported in ((Taxobox)).
Clearly the best action would be convert these taxoboxes to ((speciesbox)), but that is much more involved. I don't think mass deleting a lot of taxa parameters that have been explicitly set in ((Taxobox)) is a good idea. This would be imposing automated taxobox policy on manual taxoboxes, which could further alienate some of the holdouts who oppose automated taxoboxes. Converting them to speciesbox is different as what is displayed in automated taxoboxes has been discussed extensively. Jts1882 | talk17:11, 13 August 2019 (UTC)
Discussions of which ranks to display have pretty much exclusively had manual taxoboxes in mind. At a glance, I'm not seeing any documention of WHEN to display minor ranks in the automated taxobox documention (there is documentation for HOW to display them). Template:Taxobox/doc#Classification addresses WHEN to display, as does (the very outdated) Wikipedia:How to read a taxobox. I do know display of minor ranks for gastropods has been a sticking point for one editor, but I'm not sure somebody who copy-pasted "infraclass" 500+ times without noticing was putting much thought into which ranks they were explicitly setting.
At any rate, Tom, just replacing |infraclass= with |infraclassis= would be an improvement, as well as replacing |subdivisionRanks= with |subdivision_ranks=.Plantdrew (talk) 18:00, 13 August 2019 (UTC)
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)
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! LizRead!Talk!20:34, 1 September 2019 (UTC)
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)
@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)
** 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) has given you a wiki free beer of your choice to wiki drink. This user advises you to not get too wiki-drunk or you could get a wiki-hangover.
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)
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)
@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)
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)
Some of the frequent suspect typos in my scan, if you want to add some to AWB:
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)
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.
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)
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)
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)
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)
@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)
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 likeif 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)
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)
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)
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)
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.
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?
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?
<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.
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.
@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)
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)
@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,964) 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)
-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)
@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)
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
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)
@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)
@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)
@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)
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)
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)
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)
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 ( ` ).
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))
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)
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 google-code-in-admins@lists.wikimedia.org, 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 google-code-in-admins@lists.wikimedia.org.
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
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)
Help with dead IUCN links
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.
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):
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?
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.
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 | talk17:21, 15 December 2019 (UTC)
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'?
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 | talk08:45, 16 December 2019 (UTC)
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 | talk13:18, 16 December 2019 (UTC)
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.
((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: 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 | talk08:35, 18 December 2019 (UTC)
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:
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 | talk13:30, 18 December 2019 (UTC)
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
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 | talk16:13, 18 December 2019 (UTC)
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.
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 | talk18:24, 18 December 2019 (UTC)
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.
Looking at the errors, I have a couple of comments:
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)
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 | talk11:53, 19 December 2019 (UTC)
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:
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 | talk14:28, 19 December 2019 (UTC)
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.
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)
((IUCN)) – 13462
((IUCN2006)) – 531
((IUCN2007)) – 45
((IUCN2008)) – 1587
((IUCN2009.1)) – 51
((IUCN2009.2)) – 183
((IUCN2010)) – 126
((IUCN2010.1)) – 43
((IUCN2010.2)) – 32
((IUCN2010.3)) – 75
((IUCN2010.4)) – 69
((IUCN2011.1)) – 56
((IUCN2011.2)) – 103
((IUCN2012.1)) – 41
((IUCN2012.2)) – 90
((IUCN2013.1)) – 90
((IUCN2013.2)) – 254
((IUCN2014.1)) – 37
((IUCN2014.2)) – 128
((IUCN2014.3)) – 245
((IUCN2015.1)) – 25
((IUCN2015.2)) – 37
((IUCN2015.3)) – 5
((IUCN2015.4)) – 6
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):
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 | talk08:33, 23 December 2019 (UTC)
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)).
It occurred to me that editors might want to simply copy the example citation from an iucn species page, drop it into a template that would auto-subst into a ((cite iucn)) template. So I have hacked Module:Sandbox/trappist_the_monk/make_cite_iucn and ((make cite iucn)) to do that. This tool is not extensively tested but all of the examples that I have tried work.
I think it is useful. Most of those I tested worked. The exception was one citaition with an ampersand after an Oxford comma, which ended up with an author name with the ampersand.
Jdeidi, T., Masseti, M., Nader, I., de Smet, K., & Cuzin, F. 2010. Leptailurus serval . The IUCN Red List of Threatened Species 2010: e.T11638A3299247. Downloaded on 27 December 2019.
While it can't be expected to catch all aberrant citations by the IUCN, this one wouldn't have been obvious from the subtituted result. Jts1882 | talk07:31, 28 December 2019 (UTC)
Not at all. I'm all in favour of keeping things in one place or in subpages when the module gets too large. I've deleted the main() and cite2() functions as all I'd hoped to do with them to bring all iucn citations into one place is now done by cite(). Thanks for what you have done on this. It's a shame there still some dead links because of the IUCN's changes, but I can't see what more can be done. Jts1882 | talk13:36, 28 December 2019 (UTC)
Right, did that; also deleted the unused data{} table.
And I found this:
Abreu-Grobois, A & Plotkin, P. (IUCN SSC Marine Turtle Specialist Group) 2008. Lepidochelys olivacea . The IUCN Red List of Threatened Species 2008: e.T11534A3292503. http://dx.doi.org/10.2305/IUCN.UK.2008.RLTS.T11534A3292503.en. Downloaded on 28 December 2019.
No <dot> after first author's initial. Meh, that's fixable. But what to do about (IUCN SSC Marine Turtle Specialist Group)? Is that a collaboration so assign it to |collaboration= or is it an affiliation so ignore it because cs1|2 does not support affiliations? Or, is it the third author? But if the third author, why in parentheses? cs1|2 renders collaborations in parentheses so I am inclined to do this:
((cite iucn |author1=Abreu-Grobois, A. |author2=Plotkin, P. |collaboration=IUCN SSC Marine Turtle Specialist Group |year=2008 |title=''Lepidochelys olivacea'' |volume=2008 |page=e.T11534A3292503 |doi=10.2305/IUCN.UK.2008.RLTS.T11534A3292503.en |access-date=28 December 2019))
I think collaboration covers what the IUCN specialist groups do very well. They are groups of people from all over the world (many different affiliations) who work on conservation actions for specific groups of animals (Turtles, Cats, etc). It's very much a collaboration. The authors of the assessment will be collating information from the wider group. Jts1882 | talk15:44, 2 January 2020 (UTC)
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)
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?
Possible connected issue. Go to Cranfillia fullagari and add ((Taxonbar|from=Q42734713)) – you get a single taxon in the taxonbar, namely Q42734713. The same happens if you add ((Taxonbar|from1=Q42734713)). However, if you change the "1" to any other number, e.g. ((Taxonbar|from2=Q42734713)), then the code adds the taxon synonym Q16749980. This may be (part of) why putting the from parameters in the 'wrong' order produces the 'right' output order. Peter coxhead (talk) 10:40, 27 December 2019 (UTC)