Jump to content

User talk:Trappist the monk

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Trappist the monk (talk | contribs) at 18:27, 2 January 2020 (→‎IUCN template). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

CS1This user is responsible for those
CS1 error messages (help).
Comments are welcome. If your comments are about my work on a particular article, please make
them at the article's talk page so that everyone who has an interest in the article may participate.

IUCN template

I see you are switching these back in for the journal cites. IIRC, we started using the latter a couple years ago because the IUCN had shuffled all the IDs around, had done so a few times before, and there was no indication that they wouldn't do it again in the future; and the journal cites were supposed to be somewhat proof against that. Has something changed there? Or are you only doing that for "oldredlist" entries? Cheers --Elmidae (talk · contribs) 00:26, 19 December 2019 (UTC)[reply]

Those changes that I am making are the result of discussion at User talk:Tom.Reding § Help with dead IUCN links. If that does not answer your questions, give a shout.
—Trappist the monk (talk) 00:32, 19 December 2019 (UTC)[reply]
Well, that seems exhaustively figured out. It appears then that {{cite iucn}} is the way to go now; I'll keep that in mind. Thanks! --Elmidae (talk · contribs) 00:59, 19 December 2019 (UTC)[reply]
In updating IUCN citations, is there a reason not to retain the "accessdate" parameter? Given the periodic updating of the source, it seems to be useful in indicating to the reader the likelihood of the value of checking for a more recent assessment. From my perspective, this is a more compelling usage than its original use in random citations using urls. WolfmanSF (talk) 02:25, 20 December 2019 (UTC)[reply]
A good thing that iucn have done is to notify readers when a linked assessment is stale. For example:
Panthera pardus 2016
gives a warning that the linked page is not the most recent assessment and offers links to:
global assessment: Panthera pardus 2019
Mediterranean: Panthera pardus 2010
A bad thing that iucn have done is to cause assessments with Digital object identifiers (doi) to redirect to the current assessment. This is a bad thing because a doi is supposed to be a persistent link to a source.
Because an iucn assessment has a publication date, because a stale assessment provides a link to the current assessment, and because |doi=, when present and correct, redirects to the current assessment, |access-date= is not really needed.
—Trappist the monk (talk) 11:39, 20 December 2019 (UTC)[reply]
My concern is whether the access date is useful and desirable. Your comments reflect what an editor sees after he/she clicks on the IUCN link, but what is in question is whether the editor needs to click that link at all. I am one of the editors who sometimes reviews lots of species articles to see if the IUCN status and/or citation needs updating. An old assessment date, coupled with an old retrieval date, indicates I need to check the IUCN's species page for a possible update. If I find no update is needed, I can simply update the retrieval date and spare another editor the need to do the same thing in the reasonably near future. Thus, proper use of the access-date field facilitates the process of keeping our species articles up to date. So, it is clearly useful and desirable, even if not absolutely needed. Thus, I request that you and others stop removing this field from the iucn citations. Thanks, WolfmanSF (talk) 06:26, 24 December 2019 (UTC)[reply]
I wish that you had found it within yourself to say in your first post what you have just said in your second post. Your first post talked about readers, whom I assert, are unlikely to make any connection between assessment dates and access dates. In your second post you wrote (about my comment) Your comments reflect what an editor sees after he/she clicks on the IUCN link.... I'm pretty sure that my answer was not about editors (I did not use that word) but about readers because your first post was about |access-date= as an [indication] to the reader. For editors, as you've noted in your second post, there is a demonstrable use. Alas, I suspect that changing the script now, more or less after almost all {{cite journal}} and {{cite web}} templates that have or had |url= is shutting the barn door after the cows have escaped.
It occurs to me that a useful thing that might be done to benefit the work you are doing is to have Module:Iucn categorize iucn citation templates according to the assessment date in |year= or |date= or, as a fallback, in |volume=. It would be best if MediaWiki allowed category sorting by the specific value of a sortkey rather than by the first character of the sortkey but it doesn't. So, Module:Iucn could add articles to assessment year categories. For example, Atlantic salmon has {{cite iucn}} with |year=1996 so that article would go into Category:1996 IUCN assessments or some-such. Reviewing that citation, an editor would update the template to reflect the appropriate assessment (and, for Atlantic salmon, resolve the discrepancy between |doi= and |page=) and Atlantic salmon would move to Category:2008 IUCN assessments. If you think that such a scheme would help you, let me know and I will implement it. An alternative that doesn't involve template-code changes would be insource searches like:
hastemplate:"cite iucn" insource:/\{ *cite iucn[^\}]*\| *year *= *1996/ → results
—Trappist the monk (talk) 12:13, 24 December 2019 (UTC)[reply]
There is an error generated when the doi is used in the cite iucn template and the page is an erratum. In these cases the page name stays the same as it was before and the url is revised. See Mackerel scad. Quetzal1964 (talk) 09:16, 29 December 2019 (UTC)[reply]
I am not at all sure that I understand your complaint. Here is the history of edits to the {{cite iucn}} template in Mackerel scad:
  • 27 November 2019
    {{cite iucn | author1 = Smith-Vaniz, W.F. | author2 = Williams, J.T. | author3 = Pina Amargos, F. | author4 = Curtis, M. | author5 = Brown, J. | last-author-amp = yes | year = 2015 | title = ''Decapterus macarellus'' (errata version published in 2017) | work = [[The IUCN Red List of Threatened Species]] | volume = 2015 | page = e.T190117A115308983 | url = http://dx.doi.org/10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en | accessdate = 27 November 2019}}
    Smith-Vaniz, W.F.; Williams, J.T.; Pina Amargos, F.; Curtis, M.; Brown, J. (2015). "Decapterus macarellus (errata version published in 2017)". The IUCN Red List of Threatened Species. 2015: e.T190117A115308983. Retrieved 27 November 2019. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
    resolves to: https://www.iucnredlist.org/species/190117/115308983 – via doi resolver from |url=
  • my edit 15 December 2019 – removed |work=
    {{cite iucn | author1 = Smith-Vaniz, W.F. | author2 = Williams, J.T. | author3 = Pina Amargos, F. | author4 = Curtis, M. | author5 = Brown, J. | last-author-amp = yes | year = 2015 | title = ''Decapterus macarellus'' (errata version published in 2017) | volume = 2015 | page = e.T190117A115308983 | url = http://dx.doi.org/10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en | accessdate = 27 November 2019}}
    Smith-Vaniz, W.F.; Williams, J.T.; Pina Amargos, F.; Curtis, M.; Brown, J. (2015). "Decapterus macarellus (errata version published in 2017)". IUCN Red List of Threatened Species. 2015: e.T190117A115308983. Retrieved 27 November 2019. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
    resolves to: https://www.iucnredlist.org/species/190117/115308983 – via doi resolver from |url=
  • my edit 21 December 2019 – convert |url= to |doi=; delete |accessdate=
    {{cite iucn | author1 = Smith-Vaniz, W.F. | author2 = Williams, J.T. | author3 = Pina Amargos, F. | author4 = Curtis, M. | author5 = Brown, J. | last-author-amp = yes | year = 2015 | title = ''Decapterus macarellus'' (errata version published in 2017) | volume = 2015 | page = e.T190117A115308983 | doi = 10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en }}
    Smith-Vaniz, W.F.; Williams, J.T.; Pina Amargos, F.; Curtis, M.; Brown, J. (2015). "Decapterus macarellus (errata version published in 2017)". IUCN Red List of Threatened Species. 2015: e.T190117A115308983. doi:10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help){{cite iucn}}: error: |doi= / |page= mismatch (help)
    resolves to: https://www.iucnredlist.org/species/190117/115308983 – url from |page=e.T190117A115308983
    resolves to: https://www.iucnredlist.org/species/190117/115308983 – via doi resolver from |doi=
  • your edit 29 December 2019 – convert |doi= to |url=
    {{cite iucn | author1 = Smith-Vaniz, W.F. | author2 = Williams, J.T. | author3 = Pina Amargos, F. | author4 = Curtis, M. | author5 = Brown, J. | last-author-amp = yes | year = 2015 | title = ''Decapterus macarellus'' (errata version published in 2017) | volume = 2015 | page = e.T190117A115308983 | url = http://dx.doi.org/10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en}}
    Smith-Vaniz, W.F.; Williams, J.T.; Pina Amargos, F.; Curtis, M.; Brown, J. (2015). "Decapterus macarellus (errata version published in 2017)". IUCN Red List of Threatened Species. 2015: e.T190117A115308983. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
    resolves to: https://www.iucnredlist.org/species/190117/115308983 – via doi resolver from |url=
As you can see, in every case, no matter which link is chosen, the reader lands at https://www.iucnredlist.org/species/190117/115308983. That is the desired result is it not?
If you are complaining about the {{cite iucn}}: error: |doi= / |page= mismatch error message, you can see that the identifiers are quite different:
|doi=10.2305/IUCN.UK.2015-4.RLTS.T190117A16510627.en
|page=e.T190117A115308983
This difference is not something that the template or my script can resolve; editors must do that. The standard choices are:
  1. delete one of |doi= or |page=
  2. change |page= to match |doi= – for this example, |page=e.T190117A16510627 so that title link resolves to: https://www.iucnredlist.org/species/190117/16510627 (an assessment that has been superseded) and the doi link resolves to https://www.iucnredlist.org/species/190117/115308983 (the erratum assessment)
  3. find an alternate source
This is all expected behavior and not a bug in {{cite iucn}}. Did I answer your complaint?
—Trappist the monk (talk) 12:55, 29 December 2019 (UTC)[reply]
I agree with Quetzal1964 that there shouldn't be an error message in examples like Mackerel scad where there is an erratum.
  1. The citation accurately reproduces the form on the IUCN page.
  2. The link generated from the electronic page number takes you to the correct version of the assessment.
  3. Following the doi link takes you to the page determined by the IUCN doi resolver.
The citation does what is expected of it. Where there is an issue it is because of the IUCN's use of dois as non-permanent links. In the mackerel scad example the doi currently takes you to the correct page, but this might not be the case in the future. If there is a further amendment it will resolve to the new version, not that seen by the editor. This would be an error. If, as in this case, the |url= is set to the doi url to avoid the error, the citation is less accurate than the version giving the error message, which uses the url generated from the page number. The citation should use the url created from the electronic page number, not the doi. When the assessment number in the electronic page and doi differ, it is not a citation error, but an accurate reflection of how the IUCN handle the numbers.   Jts1882 | talk  15:13, 2 January 2020 (UTC)[reply]
I have sent an email to IUCN:
  1. I asked if they have or can they provide for us a map of .../detail/<taxon ID>/0 urls to .../species/<taxon ID>/<assessment ID> urls
  2. I pointed out that doi names are redirected to current assessments when they should not be
I fully expect to be ignored. But, on the off-chance that I am not (I'm not going to hold my breath) my email may result in a change at IUCN (not holding my breath for that either). Until such time as I finally come to the sad realization the IUCN are ignoring me, I'm not inclined to change the behavior of the template. There are, as of this writing, only 85 articles with the {{cite iucn}}: error: |doi= / |page= mismatch error message.
—Trappist the monk (talk) 18:27, 2 January 2020 (UTC)[reply]

To: Monkbot

From: SmilyChase

(: Smilychase (talk) 10:34, 26 December 2019 (UTC)[reply]

Wikipedia:Bots/Requests for approval/Monkbot 15

Wikipedia:Bots/Requests for approval/Monkbot 15 has been approved! Please see the BRFA for details. Happy editing! --TheSandDoctor Talk 10:12, 27 December 2019 (UTC)[reply]

Date format modification

I would like to know what change needs to be made in order to make both the dates "22 December 2019" and "2019 December 22" as a valid one. Note that I need to change this in Malayalam Wikipedia. As of now, this change is suggested. If in any case it is not required, I may revert it. I mean if any strong opposition comes. Adithyak1997 (talk) 13:01, 27 December 2019 (UTC)[reply]

In ml:Module:Citation/CS1/Date validation search for case-sensitive 'yMd'. At en.wiki that format is not supported so anything to do with that format is commented-out. Uncomment (there are multiple places that this must be done).
—Trappist the monk (talk) 13:54, 27 December 2019 (UTC)[reply]
Thank you. It worked. Adithyak1997 (talk) 16:14, 27 December 2019 (UTC)[reply]

in lang capitalisation

Hello. When the bot switches {{LL}} to {{in lang}} please can it ensure the language code is put in lower case otherwise eg this produces red-linked categories (contrary to WP:REDNOT) such as Category:Articles_with_Japanese-language_sources_(Ja). There's quite a lot from the last day or so. TIA Le Deluge (talk) 22:00, 29 December 2019 (UTC)[reply]

Thanks for pointing that out. Fixed in Module:Lang/utilities (see your example). A null edit should fix those articles with redlinked categories caused by non-lowercase language code.
—Trappist the monk (talk) 22:50, 29 December 2019 (UTC)[reply]
Thanks. The other thing we're getting is that in lang is creating WP:REDNOT categories based on three-letter codes when the two-letter category exists, eg fin and fi or nor and no. You can see them here - most of them are at the bottom, but eg the Norwegian ones is #5. I don't know what they best way to handle it is, presumably there's some lookups you can do on three-letter codes to convert them, or test for the existence of two and three letter categories? Le Deluge (talk) 11:48, 31 December 2019 (UTC)[reply]
Fixed in Module:Lang/utilities. Thank you.
—Trappist the monk (talk) 12:24, 31 December 2019 (UTC)[reply]

Monkbot blanking pages

Tracked in Phabricator
Task T241614

Looks like somebody already added a comment to "Stop Monkbot" but it should probably be rolled back ASAP. SnowFire (talk) 21:07, 30 December 2019 (UTC)[reply]

Hi, that was me. I found this one for example. Is there a way to roll back all of the mal-edited articles automatically (articles with 1000+ deleted bytes or something)? --ElLutzo (talk) 21:16, 30 December 2019 (UTC)[reply]
I undid a few of them, but there are tons of these. It's not feasible to roll them back individually; they should just be mass-rollbacked, including the non-blanking edits which are now suspect as well. SnowFire (talk) 21:30, 30 December 2019 (UTC)[reply]
Beta-Testing was on 8 December 2019 (20:48 [1] to 20:53 [2] UTC). The bot started on 27 December 2019 at 22:44 [3] UTC with Task 15. --ElLutzo (talk) 21:45, 30 December 2019 (UTC).[reply]
It seems, that the first problematic article was at 30 December 2019, 20:26 UTC: [4]. All edits before this one look good. --ElLutzo (talk) 22:13, 30 December 2019 (UTC)[reply]

Special:ShortPages has been flooded with about 160 0-byte (blanked) articles. – wbm1058 (talk) 22:47, 30 December 2019 (UTC)[reply]

Thanks for the notice. I've reverted (I think) all of the bad edits. This has happened before on AWB based bot tasks, not just task 15. Restarting AWB and then restarting the bot has always resulted in good edits to the same articles that got blanked. So I'll do that and make an AWB bug report.
—Trappist the monk (talk) 00:06, 31 December 2019 (UTC)[reply]
FWIW, I was running a PHP-based bot (coded myself, using botclasses framework) that ran into errors overnight. I had similar page-blanking errors with my bot before I fixed the framework to trap these errors. Now, it retries 10 times before giving up, and stopping the program. It crashed at 1:36 AM Eastern time. Basically it's a data connection problem. Your bot sends off a request for data into the Internet, and then nothing comes back. After waiting so long without the expected response, the operation times out. wbm1058 (talk) 00:29, 31 December 2019 (UTC)[reply]
Bot console report
__________
56826 Retrieving Tactical unit categories...
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=categories&titles=Tactical+unit (0.090004920959473 s) (407 b)

Category:All article disambiguation pages -- disambiguation page Retrieving Tactical unit contents...
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=Tactical+unit&rvlimit=1&rvprop=content|timestamp (0.12800693511963 s) (823 b)
cURL Error: Operation timed out after 158314 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (175.65682888031 s) (0 b)

 *** Retry query, attempt 0 ***
cURL Error: Operation timed out after 29999 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (30.25373005867 s) (0 b)

 *** Retry query, attempt 1 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998716115952 s) (0 b)

 *** Retry query, attempt 2 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998716115952 s) (0 b)

 *** Retry query, attempt 3 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998715877533 s) (0 b)

 *** Retry query, attempt 4 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998715162277 s) (0 b)

 *** Retry query, attempt 5 ***
cURL Error: Operation timed out after 29999 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998715877533 s) (0 b)

 *** Retry query, attempt 6 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998716115952 s) (0 b)

 *** Retry query, attempt 7 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.999716043472 s) (0 b)

 *** Retry query, attempt 8 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998716115952 s) (0 b)

 *** Retry query, attempt 9 ***
cURL Error: Operation timed out after 30000 milliseconds with 0 bytes received
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (29.998715877533 s) (0 b)

Fatal error: Uncaught Exception: HTTP Error. in C:\php\botclasses2.php:235
Stack trace:
#0 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 10)
#1 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 10)
#2 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 9)
#3 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 8)
#4 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 7)
#5 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 6)
#6 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 5)
#7 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 4)
#8 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 3)
#9 C:\php\botclasses2.php(233): wikipedia->query('?action=edit&fo...', Array, 2)
#10 C:\php\botclasses2.php(789): wikipedia->query('?action=edit&fo...', Array)
#11 C:\php\shortpage-dabs.php(87): wikipedia->edit('Tactic in C:\php\botclasses2.php on line 235

Monday, December 30, 2019 1:36:33 AM
I can't exactly say what it is that my bot is getting or not getting. In essence, my bot script relies on awb to handle all of the internet connection and data transfer. AWB calls my c# script and hands me a copy of the article text. My script massages the article text and returns it to awb which then has the responsibility of transferring it to en.wiki. I know that my c# script got the article text because the edit summary that was returned to awb and then written to en.wiki with the blank page, shows that my task thinks that it did the right thing. If the problem is with awb as I believe it to be then it is out of my bailiwick but I shall continue to ponder how I might tweak my c# script to see if it is returning an empty string to awb.
—Trappist the monk (talk) 00:58, 31 December 2019 (UTC)[reply]
You missed one :0) You can double-check your work by checking Special:ShortPages to make sure there are no zero-byte pages at the top of that list. – wbm1058 (talk) 00:42, 31 December 2019 (UTC)[reply]
Sigh ... Guess I'll just go out in the yard and fall on my sward ... (yeah, pun – and it would be hard; ground frozen here). Thanks for catching that one.
—Trappist the monk (talk) 00:58, 31 December 2019 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Trappist_the_monk&oldid=933727769"