User talk:Tom.Reding/Archive 2

This is an archive of past discussions about User:Tom.Reding. 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.

Archive 1

Archive 2

Archive 3

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?

As far as I can see, the basic task for the Meanings of minor planet names and its partial lists have all been done.

I have now began to revise the citations with their references (a "prototype"/pilot MoMP revision is done for Meanings of minor planet names: 2001–3000). In order to finalize it the {{MinorPlanetNameMeaningsTableHeader}} should be amended.

Currently, the table header looks like this (partial example):

Number–Name	Prov. Designation	Source of Name
2601 Bologna	1980 XA	Bologna, Italy DMP
2602 Moore	1982 BR	Patrick Moore, British amateur astronomer DMP
2603 Taylor	1982 BW₁	Gordon E. Taylor, British amateur astronomer DMP
2604 Marshak	1972 LD₁	Samuil Marshak, Russian poet and writer MPC
2605 Sahade	1974 QA	Jorge Sahade, Argentinian astronomer MPC

Which should be changed in order to:

add a new column Ref · Cataloge, and to
add a back to top as in {{List of minor planets/header2}}

Named minor planet	Provisional	This minor planet was named for...	Ref · Cataloge
2601 Bologna	1980 XA	Bologna, Italy	DMP · 2601
2602 Moore	1982 BR	Patrick Moore, British amateur astronomer	DMP · 2602
2603 Taylor	1982 BW₁	Gordon E. Taylor, British amateur astronomer	DMP · 2603
2604 Marshak	1972 LD₁	Samuil Marshak, Russian poet and writer	MPC · 2604
2605 Sahade	1974 QA	Jorge Sahade, Argentinian astronomer	MPC · 2605

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 – talk 14: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).

These are just a few thoughts for the long-term and irrelevant at the moment. Rfassbind – talk 09:48, 22 February 2017 (UTC)

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)

Rfassbind, I don't see a downside so I think I'll do this later today fyi. ~ Tom.Reding (talk ⋅dgaf) 15:29, 16 March 2017 (UTC)

Regarding those 3 proposals:

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 :)
Agreed; also similar to the LoMPs.

~ Tom.Reding (talk ⋅dgaf) 02:27, 14 March 2017 (UTC)

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 – talk 22: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...

What ya think? Best, Rfassbind – talk 20:05, 24 March 2017 (UTC)

Rfassbind, sounds good; I'll take care of both. ~ Tom.Reding (talk ⋅dgaf) 13:52, 3 April 2017 (UTC)

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 – talk 14: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.

MPs missing an infobox

~ Tom.Reding (talk ⋅dgaf) 15:23, 10 April 2017 (UTC)

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 – talk 05: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.
I have collected some of these LOMP#Rs. There are definitely many more of these (with superseded #X01-anchors).
I propose to summarize these created PotatoBot redirects, and amend the target/formatting of all those that now point to LoMP.
A better target would be MoMP, so Rozhdestvenskij would point to {{MoMP}}, i.e. Meanings of minor planet names: 5001–6000#360.
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.

What you think? Rfassbind – talk 13:56, 28 March 2017 (UTC)

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 – talk 10: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.

Given these issues, I think the simplest solution would be to make a separate template. How should we proceed? ~ Tom.Reding (talk ⋅dgaf) 16:51, 17 April 2017 (UTC)

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
8627 Kunalnayyar (primary #R) upon naming on 30 November 2015‎.

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 – talk 15:33, 19 April 2017 (UTC)

{{Partial minor planet designation}} created! I will populate it over the next few days. Good name choice :) ~ Tom.Reding (talk ⋅dgaf) 16:17, 20 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 – talk 02: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 – talk 09: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  would help me to expanded/enlarge my revision I just mentioned above. Rfassbind – talk 10: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)

435 potential provisionally named P#Rs (task #2) documented at User:Rfassbind/Revision minor planet single-redirs from short name § Provisional redirects.

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.

I have amended {{Partial minor planet designation}} in order to fix the problems mentioned above. I also amended the template's message box and its documentation (I removed {{R unprintworthy}} from MP#Rs that redirect to MP-object articles). Rfassbind – talk 11:40, 31 May 2017 (UTC)

124 P#Rs with multiple matches in MPNames The project page documents in what type of redirect these 124 pages with multiple matches turned into. Half of them turned into {{disambiguation}} pages, which took many hours to compile. Rfassbind – talk 11:40, 31 May 2017 (UTC)

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 – talk 21:38, 31 May 2017 (UTC)

Another search question

Hi there. I want to search for all instances of:

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✿ / ^talk 07: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)

A barnstar for you!

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

MoMP Revision: removal of column "provisional"

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 – talk 01: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.
The template, {{MinorPlanetNameMeaningsTableHeader}} needs to be amended and the width of the first column could be somewhat increased.

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 – talk 23: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 – talk 12: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:

http://dispenser.homenet.org/~dispenser/cgi-bin/rdcheck.py?page=Template:Dwarf_planets

What you think? Best, Rfassbind – talk 10:29, 26 April 2017 (UTC)

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.

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

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 – talk 08: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 Ellsworth ^put'r there 16: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 4 August 2011‎ – (48411) 1985 RB3 was created by Merovingian
- on 17 August 2011‎ – Talk:(48411) 1985 RB3 was created by Shirt58
- on 8 February 2015‎ – pages were moved to 48411 Johnventre and Talk:48411 Johnventre, respectively, by Eibenag
- 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?
Fith, I didn't know that {{R from move}} and its removal has anything to do with being/not being categorized as an unsynchronized talk page redirect (Category:Unsynchronized talk page redirects currently shows 6 unsync'ed talk-pages such as Talk:(6875) 1994 NG1). Well, that was probably just sheer dumb luck on my side, as we would have otherwise had this conversation much earlier. Don't you think? Cheers, Rfassbind – talk 18:15, 5 May 2017 (UTC)

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 Ellsworth ^put'r there 16:40, 7 May 2017 (UTC)

Rfassbind & Paine Ellsworth, I'll work on #1 since we're all in agreement.

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 Ellsworth ^put'r there 15: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).

I support adding {{Talk page of a redirect}} on s-MP#Rs and I'm agnostic about other changes to them, but I'll help make whatever the desired changes are. ~ Tom.Reding (talk ⋅dgaf) 16:38, 9 May 2017 (UTC)

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?

Hope I didn't miss anything. What do you guys think? Thx, Rfassbind – talk 14:41, 12 May 2017 (UTC)

(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 Ellsworth ^put'r there 16: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 – talk 11: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 Ellsworth ^put'r there 14: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 – talk 16: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.

Maybe @TAnthony: could enlighten us? Rfassbind – talk 17:12, 15 May 2017 (UTC)

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.— TAnthony^Talk 19: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 – talk 18: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.— TAnthony^Talk 21:44, 18 May 2017 (UTC)

Rcat shell bot isn't perfect

Hi, just a heads-up, here's an edit where you added the Rcat shell around one template, but left the other ({{R to section}}) outside. -- intgr [talk] 09:48, 7 June 2017 (UTC)

Thanks! I'll do a complete retroactive search & fix for this and apply it going forward shortly. ~ Tom.Reding (talk ⋅dgaf) 10:32, 7 June 2017 (UTC)

Fixed! I found ~50 edited pages with this & other predictable errata. ~ Tom.Reding (talk ⋅dgaf) 20:43, 7 June 2017 (UTC)

Barnstar awarded

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

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)

So why do this manually, rather than by bot? Headbomb {t · c · p · b} 02:55, 10 June 2017 (UTC)

Easier to just do it myself. Should I stop? ~ Tom.Reding (talk ⋅dgaf) 02:58, 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)

Ok, I'll isolate the multiple-{{R}} #Rs and do those at least, and submit a bot request at some point for the singles. ~ Tom.Reding (talk ⋅dgaf) 04:03, 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)

Headbomb, I just put in an RfA for TomBot. Thanks for remembering it :) ~ Tom.Reding (talk ⋅dgaf) 14:43, 17 June 2017 (UTC)

Please be careful when you make edits like this that you don't create duplication. The {{Redirect category shell}} template automatically detects the protection level, so if you leave {{R semi-protected}} in place, it displays twice. --Redrose64 🌹 (talk) 09:45, 12 June 2017 (UTC)

I see, thank you. I'll remove protection-level {{R}}s from edits I've made and going forward. ~ Tom.Reding (talk ⋅dgaf) 14:34, 12 June 2017 (UTC)

7 pages found & corrected with redundant protection-level {{R}}s and their aliases. ~ Tom.Reding (talk ⋅dgaf) 11:19, 13 June 2017 (UTC)

Thank you --Redrose64 🌹 (talk) 11:34, 13 June 2017 (UTC)

Breed name redirects

Hi again! I see you're going around doing something to the hundreds of animal breed redirects of the form Laticauda (sheep). Perhaps it'd more useful if you just removed the {{R from incorrect disambiguation}} from any such redirect unless there actually is an error? There's nothing wrong with "Laticauda (sheep)", for example. Justlettersandnumbers (talk) 11:46, 14 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.

List

Also, I haven't checked each one individually to be sure that they actually carry the template, rather than simply transcluding it via {{R from alternative disambiguation}}. If I've made mistakes, complain or something! Thanks again, Justlettersandnumbers (talk) 14:21, 14 June 2017 (UTC)

Yup, they all contain {{R from incorrect disambiguation}}. What I'll do is remove that template iif the title of the #R matches the target after removing the #R's parentheses. When I'm done I'll separate the list into those I did and did not edit. ~ Tom.Reding (talk ⋅dgaf) 16:04, 14 June 2017 (UTC)

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)

The convention is to not put the animal's common name in parentheses. These redirects don't follow that convention (which is fine), and therefore require {{R from incorrect disambiguation}}, per the documentation. Look at all of the other non-animal examples in Category:Redirects from incorrect disambiguation. ~ Tom.Reding (talk ⋅dgaf) 18:33, 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)

The easiest way to find a/the formal convention is to ask the largest associated WikiProject(s) (WikiProject Agriculture in this case). Similar to WikiProject Astronomy's naming convention for minor planets, they will point you to where it is written; and if it isn't written somewhere you can determine consensus there. ~ Tom.Reding (talk ⋅dgaf) 21:24, 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 consensus or there 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.

~ Tom.Reding (talk ⋅dgaf) 23:02, 14 June 2017 (UTC)

Redirects from unnecessary dab

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)

Pinging Bermicourt, in case you missed my response. ~ Tom.Reding (talk ⋅dgaf) 14:44, 17 June 2017 (UTC)

That's really helpful, Tom, thank you. Bermicourt (talk) 17:18, 17 June 2017 (UTC)

Curious

Just wondered what happened with this edit and how widespread it might be, since you were using AWB. Paine Ellsworth ^put'r there 19:15, 20 June 2017 (UTC)

That's definitely a weird one...I'll take a look. ~ Tom.Reding (talk ⋅dgaf) 21:11, 20 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)

That's all good to hear! I found it because I monitor the Miscellaneous redirects category, and the lower version of the {{Redirect category shell}} on that page had no templates inside it. I'm glad it turned out to be just a small thing, and thank you very much for checking! Paine Ellsworth ^put'r there 17:51, 22 June 2017 (UTC)

Excellent. ~ Tom.Reding (talk ⋅dgaf) 00:17, 23 June 2017 (UTC)

Redirect shell

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)

Yup. ~ Tom.Reding (talk ⋅dgaf) 14:08, 28 June 2017 (UTC)

Eastern Anatolia Observatory

Dear Sir/Madam,

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)

Your BRFA

Hello Tom.Reding, your BRFA (Wikipedia:Bots/Requests for approval/TomBot) was denied due to lack of community support. Should you want to propose new tasks in the future, please file a new BRFA. Thank you, — xaosflux ^Talk 12:04, 8 July 2017 (UTC)

rcat shell vs. Redirect category shell

Regarding your edit on 0 (year):

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?

I have been categorizing redirects using "rcat shell" for many months. Have I done something bad? --SoledadKabocha (talk) 22:05, 26 July 2017 (UTC)

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)

@SoledadKabocha: Ah, that was at the very beginning of my run. I noticed this problem quickly and implemented checks to avoid such edits. Thank you for your vigilance. ~ Tom.Reding (talk ⋅dgaf) 21:51, 1 August 2017 (UTC)

Sandbox

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 Ellsworth ^put'r there 16:18, 2 August 2017 (UTC)

Whoops...blanked! ~ Tom.Reding (talk ⋅dgaf) 16:24, 2 August 2017 (UTC)

No problemo, and thank you! Paine Ellsworth ^put'r there 16:25, 2 August 2017 (UTC)

Authors vs author

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, please show me the offending edit. ~ Tom.Reding (talk ⋅dgaf) 14:19, 2 October 2017 (UTC)

Tom.Reding It's this one https://wiki.riteme.site/w/index.php?title=OpenACS&oldid=prev&diff=797661250 --Brian Fenton (talk) 16:33, 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)

See Wikipedia_talk:Manual_of_Style/Biographies/2016_archive#A_slight_expansion_of_MOS:JR. Dicklyon (talk) 00:16, 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)

So the addition here was automated? Can/should we fix the code that does it that way? It looks like Wikipedia:AutoWikiBrowser/General fixes#DEFAULTSORT insertion and fixes (SetDefaultSort) is incompatible with the examples at WP:MCSTJR. Who maintains the code for this? Dicklyon (talk) 03:16, 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)

And your cleanup pattern doesn't remove commas in that context (as I see it doesn't in this edit)? Where does such a bug report go to? Dicklyon (talk) 04:31, 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)

Thanks! If you file it and alert me, I'll chime in with details. Dicklyon (talk) 05:30, 16 October 2017 (UTC)

Tracked in Phabricator
Task T178800

Dicklyon, this is a curious case. I made bug report/feature request (b/c I can't figure out what's happening behind the scenes) at T178800. ~ Tom.Reding (talk ⋅dgaf) 13:15, 23 October 2017 (UTC)

I reverted your cleanup edit at Chris Columbus, Jr.. This one was previously objected to, and I should have had it on the whitelist for that reason. It's a film, not a person. Dicklyon (talk) 04:41, 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)

Value of taxonbar template

Moved to Wikipedia talk:Wikidata § Value of taxonbar template

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.

So it's not a case of "updating the information" at Wikidata – where there are actively used synonyms, it can't be updated. Peter coxhead (talk) 16:45, 23 October 2017 (UTC)

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 | talk 17:08, 23 October 2017 (UTC)

Yes, as I said at WT:TREE#iucn_id, or similar, would aid automation. I'll remove it from any genus Gonialoe pages I edited (3).

Done

Is there a way to further identify which pages can safely utilize {{taxonbar}}, or at least identify which pages it will not be useful on? ~ Tom.Reding (talk ⋅dgaf) 17:16, 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 | talk 13: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 | talk 11: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?

So you would see:

Instead of:

--MCEllis (talk) 15:39, 29 December 2017 (UTC)

@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.

Unfortunately this doesn't solve the problem of the language links in the sidebar. Peter coxhead (talk) 15:59, 29 December 2017 (UTC)

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?

Apologies, the link was working at one point but I must have changed something. The taxonomy properties in wikidata can be found at WikiProject_Taxonomy. Jts1882 | talk 16:54, 29 December 2017 (UTC)

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.

Now's a good time to continue/copy/move the convo to Template talk:Taxonbar or Module talk:Taxonbar (I'm not sure I'd be able to get any AWB editing done with a layout/cosmetic discussion on my talk...heh; I already have a few ideas too...). I'll leave what and how to copy/move to your discretion, MCEllis. ~ Tom.Reding (talk ⋅dgaf) 18:57, 29 December 2017 (UTC)

Revisited

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: all four do not).
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 {{Infraspeciesbox}} and its aliases.
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.

? ~ Tom.Reding (talk ⋅dgaf) 22:42, 9 November 2017 (UTC)

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 | talk 13: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 | talk 15: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 | talk 16: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 editd Taraxacum 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)

Absolutely. I'm about to go through and add {{taxonbar}} to all pages under Category:Species by IUCN Red List category whose WD IUCN ID matches their actual IUCN ID. While I'm doing this I filter out many error cases, of which this is one. I've simply deleted the page from my work-list, though, instead of storing them. Kukumai, for example, gives a species name not found! error from the IUCN. Does that match what you're looking for? ~ Tom.Reding (talk ⋅dgaf) 13:30, 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 Kukumai not 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 | talk 08: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)

Jts1882, any thoughts on this? Since you work with these #Rs, I'd like to get a "it'll probably work" from you before I invest more time. ~ Tom.Reding (talk ⋅dgaf) 16:10, 1 December 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 | talk 16: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)

I see; ok. Perhaps I can restrict my edits to stub, start, and C class articles only? ~ Tom.Reding (talk ⋅dgaf) 15:56, 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)

To add interconnection between articles, and provide more information in references/sources/notes to readers. ~ Tom.Reding (talk ⋅dgaf) 16:08, 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)

WP:CLEAN


	Hello Tom.Reding: You are invited to join WikiProject Cleanup, a WikiProject and resource for Wikipedia cleanup listings, information and discussion. To join the project, just add your name to the member list. North America¹⁰⁰⁰ 05:12, 25 October 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)

Done back-updating! ~ Tom.Reding (talk ⋅dgaf) 19:26, 12 November 2017 (UTC)

Add my thanks for the updating! --Elmidae (talk · contribs) 11:55, 10 November 2017 (UTC)

Retrieved date

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)

Tom, you need to subst those references to the current date, e.g. {{subst:CURRENTDAY}}. Peter coxhead (talk) 10:58, 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)

Yes, I think you are right with the reason. You probably need safesubst:, but this is always a bit of trial-and-error so far as I am concerned. :-) Peter coxhead (talk) 16:16, 9 November 2017 (UTC)

Done, and yes, {{safesubst}} does the trick! ~ Tom.Reding (talk ⋅dgaf) 18:36, 9 November 2017 (UTC)

Ehhh, maybe not. I'll just use C#'s DateTime structure instead; much less clumsy. ~ Tom.Reding (talk ⋅dgaf) 19:25, 12 November 2017 (UTC)

Page mover granted

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.

Useful links:

Wikipedia:Requested moves
Category:Articles to be moved, for article renaming requests awaiting action.

If you do not want the page mover right anymore, just let me know, and I'll remove it. Thank you, and happy editing! Alex Shih (talk) 20:48, 10 November 2017 (UTC)

Thank you very much! :) ~ Tom.Reding (talk ⋅dgaf) 20:49, 10 November 2017 (UTC)

Request

Moved from #Value of taxonbar template

– (more like copied from)