User talk:Trappist the monk/Archive 10

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)

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)

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)

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)

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)

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)

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)

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)

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)

  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 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)

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)

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 error message.

—Trappist the monk (talk) 18:27, 2 January 2020 (UTC)

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)

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)

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)

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

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)

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

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)

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)

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)

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)

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)

I've had problems with AWB blanking pages when using external scripts. I found using "Skip" tab options to make sure the page has content seems to work around it. -- GreenC 16:43, 5 January 2020 (UTC)

There isn't a 'skip-if-no-content' checkbox so which of the options that do exist ensures that the page has content before it is saved?

I suppose one could use the 'Doesn't contain' field set to .+ with regex checked; I don't know if that test occurs before or after the script has run.

I have added a test to see if the ArticleText variable is null or empty just before my script returns it; if it is, skip with a summary saying that ArticleText is null or empty:

if (string.IsNullOrEmpty(ArticleText))										// experiment to see if the script is ever at fault when pages get blanked
	{
	Skip = true;
	Summary = @"ArticleText is empty or null";
	return ArticleText;
	}

—Trappist the monk (talk) 17:28, 5 January 2020 (UTC)

• I'm looking through old xml cfg files and I think it was: skip->doesn't contain->regex->[^ ] with "Check after" ie. after the edit, check the article contains something. -- GreenC

You got it above, just need to add the "Check after" box. I went through the same route checking for empty articles before passing back to AWB and it was never the problem. One reason I stopped using AWB for the article uploads. If you want another easy way to upload/dowhload articles check out my command-line program wikiget (on git) but it requires having OAuth keys which is pretty easy with instructions how to get them. -- GreenC 17:53, 5 January 2020 (UTC)

Doh! read right past that check-after checkbox.

—Trappist the monk (talk) 17:55, 5 January 2020 (UTC)

In process

This article is in-process I needed to manually make changes, then upload further fixes via automated bot. There was an hour or so diff. Please let me work on it without reverting. -- GreenC 16:36, 5 January 2020 (UTC)

Fixed. This uncovered a bug where webcite URLs without a |archivedate= were not being fixed. -- GreenC 17:55, 5 January 2020 (UTC)

Mostly. Your fixes broke this template which was not broken before your edit. It was this error that drew me to the article in the first place. I have fixed it.

—Trappist the monk (talk) 20:12, 5 January 2020 (UTC)

Arena Monterrey

I don't care that you reverted other editors' changes to Arena Monterrey, but your reversion undid good fixes I had done, including changing m² to m<sup>2</sup>. I have edited Arena Monterrey again. Cheers! —Anomalocaris (talk) 22:45, 10 January 2020 (UTC)

@ Anomalocaris: I think that you are confused. I have ever edited Arena Monterrey.

Blaming me for the things that I have done is ok – I am fallible; it is not ok to blame me for things that I have not done.

—Trappist the monk (talk) 22:53, 10 January 2020 (UTC)

You're right. My comment was for another editor. Not sure how I got to your talk page. —Anomalocaris (talk) 00:09, 11 January 2020 (UTC)

I got to your talk page because the reverter at Arena Monterrey included this in the edit summary:

Reverted to revision 933015275 by Monkbot (talk): ...

and I clicked on "talk" there instead of that editor's own "talk". Sorry. —Anomalocaris (talk) 00:13, 11 January 2020 (UTC)

May I ask...

Hello Trappist, hello and happy new year. I edited this article today. After that, you replaced my {{fr}} with your {{in lang|fr}}. It doesn't bother me, not at all, but I can't see any visible diference on the edited article. May I ask you why you introduced such change? Kindest regards. Kintaro (talk) 18:03, 16 January 2020 (UTC)

You may. {{fr}} is a redirect to one of hundreds of similar templates that are in the process of being deleted (see {{fr icon}}). Monkbot/task 15 has trolled through approximately 270k articles replacing the {{xx icon}} templates, their redirects, and {{link language}} and its redirects with the single parameterized template {{in lang}}.

The first ~250 of these templates to be deleted are listed as a subpage to Wikipedia:Templates for discussion/Log/2020 January 10 § Link language wrappers with under 100 transclusions – {{fr icon}} is not included in this tranche).

—Trappist the monk (talk) 19:03, 16 January 2020 (UTC)

Thank you for your answer but I still don't get it. Indeedly indeed, you mentioned a redirect... but there's no workable link in the edited article, neither on my edition ({{fr}}) nor on yours ({{in lang|fr}}). Both codes, when edited, display "(in French)", between brackets and with no link, thus with no redirect. Anyway, I don't want to waste your time, apologies if I'm disturbing you for nothing. Kintaro (talk) 19:29, 16 January 2020 (UTC)

Redirects allow Wikipedia to have multiple names for the same thing. The template {{fr icon}} has these 'names' that redirect to it (clicking any of the links in the list will take you to {{fr icon}}):

• {{Fr}}
• {{Fr li}}
• {{FR-icon}}
• {{Fr-icon}}
• {{French icon}}
• {{Ref-fr}}

Click this link. It takes you to Template:fr without redirecting you to {{fr icon}}. You can see there that it is a redirect to Template:fr icon.

If you want to link to the language article from {{fr}} (or {{fr icon}}), the template does not support that. But, {{in lang}} does:

{{in lang|fr|link=yes}} → (in French)

—Trappist the monk (talk) 19:45, 16 January 2020 (UTC)

Ok! Thank you... "If you want to link to the language article from [...]". No, thank you, it is not necessary. Cheerio! Kintaro (talk) 21:30, 16 January 2020 (UTC)

Question

Hello, I need an information from a sysop. Which is the correct way to deal with an anonymous user who suddently starts removing content and sources from a page and keeps doing it using different IP ranges? 151.64.164.131 (talk) 08:24, 18 January 2020 (UTC)

WP:Dispute resolution is not something I spend any time doing. It might be better to ask this of editors who do that sort of thing with regularity. Consider asking for help at WP:HELPDESK.

—Trappist the monk (talk) 12:09, 18 January 2020 (UTC)

Editors in "cite book" template

Hello, Trappist! :)

I have an unusual question that may be coming from my own ignorance in this subject.

I was using the "cite book" template in the Albanian Wikiquote and when I entered the parameter for the editor of a book, the results were a little strange. We got it formatted like this: më Editor Name (red.).

The (red.) part is normal. That's the way editors are marked in Albanian. The më part looks very strange to me though. I was searching to see where it comes from and apparently it is the Albanian translation of the preposition in in the configuration page at the CS1 module. That translation is indeed correct but why is it needed in a case like this? Why do we say in Editor Name (ed.).?! That doesn't make any sense to me in Albanian or English. Maybe I've translated it wrongly but as I said, I don't understand it logically even in English. Can you help me with this? - Klein Muçi (talk) 11:02, 7 January 2020 (UTC)

When a book is a collection of writings by a variety of authors, the names of the various authors do not normally appear on the book's cover; the names of the book's editor or editors is/are preeminent on the front cover. An example:

{{cite book |last=Leung |first=Julian Y.M. |chapter=Education in Hong Kong and China: Towards Convergence? |editor1-last=Chan |editor1-first=Ming K. |editor2-last=Postiglione |editor2-first=Gerard A. |title=The Hong Kong Reader: Passage to Chinese Sovereignty |publisher=[[Routledge]] |isbn=978-1-315-48835-6 |chapter-url=https://books.google.com/books?id=SckYDQAAQBAJ&pg=PT141 |url=https://books.google.com/books?id=SckYDQAAQBAJ&printsec=frontcover |date=2016}}

Leung, Julian Y.M. (2016). "Education in Hong Kong and China: Towards Convergence?". In Chan, Ming K.; Postiglione, Gerard A. (eds.). The Hong Kong Reader: Passage to Chinese Sovereignty. Routledge. ISBN 978-1-315-48835-6.

In this example, Editors Chan and Postiglione have their names on the book's cover while chapter-author Leung has his name on the chapter.

So, the book is credited to and cataloged under the editors' names; you cannot go to the library and expect to find The Hong Kong Reader: Passage to Chinese Sovereignty authored by Leung.

Because we are citing Leung's chapter, we say that we are citing his chapter in Chan and Postiglione's book. Make sense?

—Trappist the monk (talk) 14:30, 7 January 2020 (UTC)

Oh, I see. That's good we have a way to be correct even for those specific cases. I must change the translation a bit though, to match the context how the preposition is used. But how about when that's not the case? In my case I was citing from a translated book of The Origin of Species. I put down all the details related to it: Title, trans-title, author, translator, editor, chapter, trans-chapter, page, language, publisher, date and location. All formatted well except for the editor part. Here "the editor" refers to the person in charge of modifying the translator's words (or the author's words in other examples) in order to fix any misspellings and harmonize the sentences and different parts of paragraphs better together. This is how we use that parameter most of the time (if not all the time) in SqWiki/SqQuote. What should we be doing in this case? - Klein Muçi (talk) 15:17, 7 January 2020 (UTC)

A link to that citation or a copy of it here?

If I understand what it is that you are saying, then |editor= may not be appropriate. All books have editors; Harry Potter and the whatever had an editor but we don't name that editor (even when we know who that is); All of those things that you listed that we done by this editor are things that every book's editor does. Knowing the editor's name doesn't help en.wiki (or sq.wiki/quote/...) readers locate a copy of the source that supports our text.

—Trappist the monk (talk) 15:31, 7 January 2020 (UTC)

See here. The only reference in the article. As for the importance of the editor, I'm a bit skeptical. You understood correctly what I'm saying. In SqWiki/SqQuote, whenever we use the editor parameter is for that kind of thing. That's why I couldn't make sense of the use you explained to me before the explanation. I searched the web after what you wrote and I saw that in the English world the editor was only important when talking about different text collections, as in newspapers, magazines and certain books like the ones you described, so you're correct on that one. But I'm not sure that applies to the Albanian literary culture as well. I come from a family that has dealt with books for at least 2 generations. My grandmother has worked in a printing house and my mother works in a publishing house (unrelated to each other). They have always put a great importance to book editors. And seeing that book editors' names are almost every time written in the back of the books, sometimes even when translators' names are missing (can't say that for sure), I've always thought that they deserve to be written when citing book sources just like other information related to them. I may be biased on this one as I don't know for sure how the cultural Albanian community really feels to this but judging by what I said above, I've always had that kind of attitude regarding it and it was only today that I started doubting it.

So what do you suggest I do in the above case? Not put it at all? Not saying that I oppose that but I'm a bit skeptical of omitting the editor's name/s from references when they're known. Maybe we could add some lines specific to our module to make way for this kind of thing? I'm not sure we should though since you put me in doubt with what you said. I'd have to see how Albanian academic writing handles editors in book references to know for sure. Or maybe we could have a different approach on this? Let me know what you think after seeing the specific case in the above link. - Klein Muçi (talk) 17:16, 7 January 2020 (UTC)

It is not whether [editors] deserve to be written when citing book sources; it isn't about who does or does not deserve inclusion in a citation; it is about helping the reader locate a copy of the source; that is the purpose of a citation. Information that isn't necessary to the reader's search can (should) be omitted because it is superfluous.

Just because I was curious, I copied the value from |trans-title=Prejardhja e llojeve me anën e seleksionit natyror ose ruajtja e racave më të përshtatura në luftë për jetë into google's search box. It didn't give me much but there is an online site, Arbëreshë Sites Electronic Library, that identifies two holdings that appear to match the source used at sq.quote: one without editor's name and the other with editor's name. Not much help there; too much like WorldCat I suspect, where what you get is what the local librarian decided to give you when they created the bibliographic record. That's the problem with lists that aren't carefully curated.

Beyond the obvious 'consult with your community', I think you know what I suggest: omit |editor= unless or until you can convince yourself (and the sq.wiki/quote/... community) that Albanian citation norms require editor names for single-author books when citing a chapter in that book. i18n is hard, and special cases a pain, but if it is necessary for the sq.community to have cs1|2 support |editor= differently for single-author books when citing a chapter in that book, I suspect that we can concoct a way to do that.

—Trappist the monk (talk) 19:28, 7 January 2020 (UTC)

I understand your practical way of seeing it but I was talking more about the citation style rules/guidelines that are to be used in academic writings, most of which, if not all, Wikipedia follows too. That's what I meant with "importance", not how much credit does the editor get or not. :P

I'm surprised you even found online information about that book. Most of our old books (and even some new ones unfortunately) don't even have ISBN numbers - the one we're discussing here doesn't either. If you do know another online page which I could use for cases like this, it would help me a lot with book citations so feel free to tell me. Although by what you described above, I don't think you do. You've helped me even with that page though. :)

As for the specific case we're discussing, I'm talking with some people about it, in and outside of Wiki World, and I believe I was wrong. I believe that what you said is true even within the Albanian academic community too: Editors are only mentioned in citations when referencing books that are collections of different authors. I'll have a definitive answer on that in 2-3 days and I'll tell you here if there's a need for a different kind of support for that parameter for our community, even though I must say I'm starting to believe there won't be a need for that.

Meanwhile I have another query: Is the "in" preposition in the messages in Moduli:Citation/CS1/Configuration used anywhere else except for the editors case? I want to fix its translation but its translation changes depending on how it is used. - Klein Muçi (talk) 13:18, 8 January 2020 (UTC)

You're right, I don't know of any other online source of book information; I just googled the book title to see what was out there...

The messages['in'] code is only used for edited works.

—Trappist the monk (talk) 13:59, 8 January 2020 (UTC)

Thank you then! I'll write to you 1 final time about this thing in a couple of days. - Klein Muçi (talk) 14:12, 8 January 2020 (UTC)

Hello back, Trappist! :) So I've talked with a lot of people, some of them Albanian linguistic professors, and it turns out you're right. The editors should be omitted in citations coming from single authors books. That's settled now. But I do have some other questions though, not regarding editors anymore. I'm writing them below:

I'm working with the CS1 error's help page, translating the date errors' and solutions.

• The module works fine if you put dates in Albanian. The same is true with dates in English but not for other languages. Is it possible to make it find an error even with dates in English too? And maybe it suggests to use Albanian instead? Or maybe translate them automatically to Albanian?
• Some other details change too regarding this translation thing. For example, we don't use commas in our date expressions, months should be all in lower case letters, the format is set as dd mm yyyy, etc.
• Undated = n.d. - Where is this configured? I'd like to be able to translate it in Albanian. Maybe the same thing for "circa". - Klein Muçi (talk) 12:34, 14 January 2020 (UTC)

Also, can you help me by pointing out where are the ISBN types of errors configured so I can translate the messages? I just found out they're in English for us. - Klein Muçi (talk) 13:38, 14 January 2020 (UTC)

For the date issues, try these:

• in sq:Moduli:Citation/CS1 search for date_name_xlate. Uncomment those three lines. The module should then translate English month names to the local language month names
• in sq:Moduli:Citation/CS1/Configuration, change local global_df = get_date_format (); to local global_df = get_date_format () or 'dmy';

Caveat lector: for date manipulations, all dates in a citation template must be error free before any are manipulated.

For translation, these properly belong in ~/Configuration; I'll move them before the next update:

• c, n.d., and nd are defined in ~/Date validation
• ISBN error messages are defined in ~/Identifiers

—Trappist the monk (talk) 14:07, 14 January 2020 (UTC)

I fixed the L10n aspect of the date. As for the translations of c, n.d., nd and the ISBN errors, I'm really having trouble finding them because my eyes haven't really adjusted to the code of the other subpages (since I generally work at the ~/Configuration subpage, obviously). If you're planning to add them to the configuration page, I'm thinking of waiting until they appear there. If not, can you please help me a bit to find them? I did check the whole code of the page and even used pagesearch but still couldn't locate them. - Klein Muçi (talk) 15:24, 14 January 2020 (UTC)

Speaking of translations, should I translate the following sections at ~/Configuration?

• SPECIAL CASE TRANSLATIONS - the part used in get_dispaly_names() and the 'archived_copy' (I've translated the first part)
• KEYWORDS
• LANGUAGE REMAPPING

I'm not sure what they stand for.

Also, can I use the ALIASES table to translate commonly used parameters? Say for example I put "data e aksesimit" (which is Albanian for "access date") besides "AccessDate". Would that make it possible for editors to use "data e aksesimit" instead of "accessdate" as a parameter and still get the same results? Would that be a good practice to follow depending on your experience with the I18n of the module at other Wikis? - Klein Muçi (talk) 15:37, 14 January 2020 (UTC)

special_case_translations – if you have translated the maintenance category names in maint_cat, then yes, translate these. If sq.wiki has any bots that create the Albanian equivalent of the the English 'Archived copy', then you should translate that; remember that it is a Lua pattern so if you need help with that let me know

keywords – do not replace with translations but add translations (because cs1|2 templates often imported from en.wiki):

['affirmative'] = {'yes', 'true', 'y'}, → ['affirmative'] = {'yes', 'true', 'y', 'po', ...}, (Google translate says that yes is po ...; I don't know if it is or not)

language remapping – argh! MediaWiki has done some monumentally stupid things one of those things is to use already standardized language codes (ISO 639) for language name wholly unrelated to the code For instance, bi is the ISO 639-1 code for the Bihari languages but MediaWiki uses that code as the second-level sub-domain for Bhojpuri Wikipedia (bh.wikipedia.org); Bhojpuri is assigned ISO 639-3 code bho. For bn, MediaWiki uses the endonym, Bangla, instead of the correct exonym, Bengali. Editors at en.wiki have chosen, in some cases, to name articles differently from the language names associated with the language codes by the ISO 639 custodians. When en.wiki editors prefer a different name, cs1|2 accommodates that by remapping the names/codes. So, language remapping / naming etc can be a minefield. I have a module that can list the language names that MediaWiki returns for that various codes. That tool might be useful.

aliases – yes; do not translate the English, just add Albanian parameter names. You must also add the Albanian parameter names to the appropriate tables in ~/Whitelist (all parameters used by cs1|2 are listed in one or more of the tables there).

—Trappist the monk (talk) 14:44, 15 January 2020 (UTC)

(edit conflict) – undetected; I hate it when edit conflict detection doesn't

In sq:Moduli:Citation/CS1/Date validation

c is at lines 633, 634, and 636

n.d. is at lines 642 and 643

nd is at lines 644 and 645

How to implement i18n for these is a bit perplexing because they are keywords but the standard keyword check for them would bomb when the date-holding parameter holds a date. I have to think about how best to do i18n for these.

The isbn error message supplements are in plain-text in sq:Moduli:Citation/CS1/Identifiers (function isbn()) so you shouldn't have any problems finding them.

At en.wiki ~/Identifiers/sandbox and ~/Configuration/sandbox, I have hacked a solution to error message supplemental text. That facility isn't used much (but could, perhaps should). Another error message that gets supplemental text is the |vauthors= error. There may be more but I can't call them to mind at the moment.

—Trappist the monk (talk) 15:50, 14 January 2020 (UTC)

I was able to find the part of the code for the ISBN error messages. I haven't translated them yet but I don't believe I'll have any kind of problem with them. Thank you for that! As for the date, unfortunately I wasn't able "to find it". I mean, surely, I found the part of the code related to it but I don't know how to act on it to translate the words I'm after. I can't quite follow you on the reason why I19n would be difficult for them, meaning, I lack the technical knowledge to understand what you're saying that but if I got the message correctly, you too are saying that the translation process can't be achieved that easily on them right now. If that's the case, I guess I'll have to leave them in English for the moment being.

What about the config. translation questions I asked? And the ALIAS part? Did you see them? To make myself clear, those were unrelated to the discussion we were having about the date/ISBN parameters. - Klein Muçi (talk) 17:16, 14 January 2020 (UTC)

I'm being kinda dumb here but apparently I can't find even the code for the ISBN error messages. What I had found was the part for the bibcode. This part err_type = 'length';. :/ - Klein Muçi (talk) 18:58, 14 January 2020 (UTC)

ALSO (many also-s today), I just finished updating all the pages of the module in SqWiki, getting the code from the sandboxes here. I always use the Harry Potter article to check for any problems with the module since it has more than 250 different citations. And unfortunately, it does. It seems like it is a bug related to the code in ~/Identifiers/sandbox. I thought it may be coming from my part of not having copied the code like I should in any of the pages but I double checked it and everything appears to be identical (apart from the L10n parts) so I thought I should probably tell you. Please, take a look at the references here: Harry Potter. References 49 and 151. - Klein Muçi (talk) 19:44, 14 January 2020 (UTC)

I just had an eye exam where the doctor dilated my eyes so everything is still a bit fuzzy. I think that you have deleted the line label = 'PMID', with this edit. Why did you do that? I can't prove this because I can't edit sq:Moduli:Citation/CS1/Configuration and you don't appear to have a sandbox version. Why no sandbox? The purpose of the sandbox is to catch stuff like this so that errors like these lua script errors don't get into articles with the attendant oh-my-god-something-is-broken-somebody-fix-it ...

In testing what I could test, I made a simple template with |doi= and |pmid= that I stole from some article in my sq.sandbox:

{{cite journal |title=Title |doi=10.1016/S2542-5196(18)30261-4 |pmid=30528905}} → "Title". doi:10.1016/S2542-5196(18)30261-4. PMID 30528905. {{cite journal}}: Cite journal requires |journal= (help)

Works here, doesn't at sq.wiki.

For interest, I replaced |pmid= with |pmc= in my sq.sandbox:

{{cite journal |title=Title |doi=10.1016/S2542-5196(18)30261-4 |pmc=6358127}} → "Title". doi:10.1016/S2542-5196(18)30261-4. PMC 6358127. {{cite journal}}: Cite journal requires |journal= (help)

works here, doesn't at sq.wiki. At sq.wiki, the PMC label is missing from the rendering. I think this is because an interim update is missing from sq:Moduli:Citation/CS1/Configuration. At en.wiki, every id_handler has a link field. The code first looks in WikiData for the name of an associated article at the local wiki; at en.wiki the article for PMC is PubMed Central. Because WikiData has that, when it comes time to render the PMC, the module will use the value from WikiData if available, else it will use the value in the link field, else the empty string. WikiData does not have an sq.wiki article for PubMed Central (Q229883) so it fell-back on the link field which, being non-existent, caused a further fall-back to the empty string; and identifier without a label.

Remedies for these appears to be: copy all of the id_handler{} table from en.wiki/~/Configuration to sq.wiki/~/Configuration. That should restore (or create) the proper identifier structure. Create a sandbox.

I'll answer your other questions tomorrow.

—Trappist the monk (talk) 00:41, 15 January 2020 (UTC)

Apparently, you're right. I doublechecked all the pages of the module but I had missed 3 details at the config. page, one of which is what caused the error with PMID. As for the missing sandbox, the reason is that, sadly, we don't a practice for creating sandboxes in our community and therefore I'm not familiar with them. I don't know how to operate the module and test it using them. I can trial-and-error-learn it but I'm already spending many hours just to update it and that would be a bit of an overkill. If I had someone to teach me that would be good but at our community I'm the only one who deals with it so... :/

I have translated the maint cats. I'll go on with the translations then and ask you again in the future if something strange comes up.

I don't understand what you mean with this sentence though: If sq.wiki has any bots that create the Albanian equivalent of the the English 'Archived copy', then you should translate that;

As for the adding translations part, does it accept spaces? Talking about config. and whitelist here.

And finally about the language remapping part... I know that. But does it need any kind of translation? For example, I know the Tosk Albanian is one of the problems (the als code being used for a different language). Do I need to replace "Tosk Albanian" with "toskërishte", the Albanian term for it? - Klein Muçi (talk) 01:35, 16 January 2020 (UTC)

PS: The only operating bot regarding citations in SqWiki is IA Bot. - Klein Muçi (talk) 01:40, 16 January 2020 (UTC)

In English Wikipedia, when IABot cannot find the title of a URL for a citation it edits/archives, it will add "Archive(d) copy" (see Category:CS1 maint: archived copy as title). It probably uses a different phrase on sq.wp. You will have to research what that phrase is. --Izno (talk) 02:11, 16 January 2020 (UTC)

The translation is over and nothing unusual came up. Thank you for fixing the translation problem with the ISBN errors! :) Looking forward to a simplified solution about the dates too (circa/n.d.). I decided not to add to the Albanian aliases because nobody uses Albanian words in cite templates' parameters now. My plan was to give that as an option but it would just make the updating of the module harder in the future and still not a lot of editors wouldn't use them so, it wasn't worth the extra work. I'm still curious for future cases if those tables do accept words with spaces in them or not though.

As for the IA Bot... Thanks for explaining, Izno! Actually, I'm the only one who looks after IA Bot at our community and I'm not sure how to check for that. I checked the page where the bot's behavior is configured but I don't think I see anything related to it.

The question with the lang-remmap is still the same. - Klein Muçi (talk) 03:09, 16 January 2020 (UTC)

IAbot uses the phrase 'Kopje e arkivuar' for 'Archived copy'; both are used (someone added the translation here – but, didn't use the proper |trans-title=Kopje e arkivuar – don't corrupt the title metadata by adding extraneous stuff to |title=). There is a TODO: for me; I need to figure out how to detect both 'Archived copy' and whatever it is that IAbot uses in other-language wikis.

Because parameter names in the ~/Whitelist and ~/Configuration tables are in quotes, spaces are allowed.

For languages, do yourself a favor and import Module:cs1 lang lister and Template:Citation Style documentation/language/doc. The pair of these should list code → language name, and language name → code for all of the languages that MediaWiki supports; the language names should be returned in Albanian. Once you have that information, you can make better decisions about what needs to be done.

—Trappist the monk (talk) 14:50, 16 January 2020 (UTC)

Thank you for your detailed answer! I don't know for sure about the "Kopje e arkivuar" thing but I've been the one to translate almost all titles in that page like that. I actually learned that method in EnWiki, in a cite template doc page, if I'm not wrong. Some years later I started dealing with the citation module and by learning cite templates more in details, I started using the trans-title parameter for title translations. So maybe I'm the one to blame.

For languages, I took a quick eye at the links you've posted but I couldn't quite understand what are they for. I'll deal with them a bit later and write back if I don't understand them or if everything's all right. Thank you for your time! :) - Klein Muçi (talk) 23:38, 16 January 2020 (UTC)

Oh, I now see what you mean. The template gives the Albanian names for most of the languages. Where are they fed from? Translate Wiki? How does this relate to what I asked with the configuration subpage though? You're suggesting I should translate the languages there with terms used in that page (template)? - Klein Muçi (talk) 01:00, 17 January 2020 (UTC)

I don't actually know, but I think that MediaWiki uses these language-names lists. The lists are not all the same. For example, CldrNamesSq.php does not have code crh. I think that MediaWiki falls back to CldrNamesEn.php when it can't find a code in the specified language list. So:

{{#language:crh|en}} → Crimean Tatar – get language name for crh in English

{{#language:crh|sq}} → Crimean Tatar – get language name for crh in Albanian; did not work; fall-back to English

but,

{{#language:nv|en}} → Navajo – get language name for nv in English

{{#language:nv|sq}} → navahoisht – get language name for nv in Albanian

Module:cs1 lang lister and Template:Citation Style documentation/language/doc should show you which language codes MediaWiki supports for Albanian. If those names are correct, are exonyms, could be copied and pasted into the search box to get readers to the language-name article, then good, nothing to do. But, we already know that you must replace 'Tosk Albanian' with 'toskërishte' for als because Alemannisch (fall-back to the English list) is completely wrong. There may be others. The purpose of sq:Kategoria:Mirëmbajtje CS1: gjuhë e panjohur is to identify language-codes and names that are not known to MediaWiki / the cs1|2 templates. If not now, then sometime in the future, someone will add a cs1|2 template with a valid language-name or code that isn't supported by MediaWiki for Albanian; that language-name or code belongs in the language remapping tables. Alas, when MediaWiki falls back to the English list, there is no way for cs1|2 to know that that happened. I suppose that I could tweak Module:cs1 lang lister so that it gets the codes from the English list and attempts to get the associated names from the Albanian list ...

Did you import Module:cs1 lang lister and Template:Citation Style documentation/language/doc? It would be interesting to compare the sq.wiki list against the en.wiki list.

—Trappist the monk (talk) 13:35, 17 January 2020 (UTC)

I see. I don't know much of the gerrit part of Wikimedia stuff. Only lately I've started fiddling with some stuff there, mostly because of the WikiLove extension. I find your explanation kinda hard to follow through given my lack of technical information but I get the general idea of what you're saying.

(Although I'm still not sure if I do need to change this:

['als'] = 'Tosk Albanian', -- MediaWiki returns Alemannisch

['bh'] = 'Bihari', etc.

into this:

['als'] = 'Toskërisht', -- MediaWiki returns Alemannisch

['bh'] = 'Biharisht', etc.)

I did import them but I tried it at SqQuote instead of SqWiki. I tend to try new features at SqQuote before going to SqWiki because of the lower number of active users there. You can see the pages here and here. - Klein Muçi (talk) 15:25, 17 January 2020 (UTC)

I can't tell you what to do. The needs of sq.wiki must dictate what you do. It's pretty obvious from looking at wikiquote:sq:Stampa:Citation_Style_documentation/language/doc that most of the ISO 639-1 language codes supported by en.wiki are supported by sq.wiki; but these aren't and they all fall back to English:

• Avestan
• Bhojpuri – should be 'Biharisht' ('biharisht'? – language names in the list are all lowercase)
• bengalisht
• Cree
• esperanto
• Hiri Motu
• Moldovan
• Pali
• Tagalog
• Zhuang

Perhaps more surprising is that CldrNamesSq.php doesn't list aae (Arbëreshë Albanian), aat (Arvanitika Albanian), or aln (Gheg Albanian).

What does sq.wiki need? Is it possible (likely) that someone will write an article and cite a Gheg Albanian source? If the answer to that is yes, then add that to the language remapping tables. The tables as they exist at en.wiki list language codes and names that answer en.wiki's needs and may not, probably won't, answer sq.wiki's needs. You don't have to make decisions about this now, sq:Kategoria:Mirëmbajtje CS1: gjuhë e panjohur collects articles with templates using language codes and names that cs1|2 doesn't recognize; troll through that to see if you need to add names / codes to the remap tables (enabling the maintenance message display will be helpful).

—Trappist the monk (talk) 18:35, 17 January 2020 (UTC)

Maybe I'm not explaining myself clearly. The point is that I don't exactly know how that remap table is used (although I do get the general idea now). I'm not sure if the languages added in that list do appear somewhere written just like they are written there or not. If they do appear somewhere, it'd be better to appear in Albanian and I'd be better translating that. If those are there only to help the module do its work, then they are good in English. The more I translate, the harder it becomes to preserve the translations during module updates. That's what I was asking. I hadn't thought about adding to the list. But now that you mention it, maybe that could be a good idea. At least theoretically. I don't think people are likely to put "Gheg Albanian" as a value at the language parameter, even if that parameter is indeed in that dialect. Mostly they would just put "Albanian" to it. - Klein Muçi (talk) 03:43, 18 January 2020 (UTC)

This is how the remapping tables are used.

When cs1|2 encounters |language= with a language code, it first searches the lang_code_remap table for a match. If found, it uses the name provided in lang_code_remap for that code when it renders the template. When the language code is not found in lang_code_remap, cs1|2 looks in the WikiMedia-provided language tables and uses whatever MediaWiki thinks the language name should be. When not found in the MediaWiki tables, cs1|2 renders the language name as written and adds the article to the unrecognized language maintenance category.

Something similar happens when |language=<language name>. cs1|2 looks first for the language name in the lang_name_remap. If found, cs1|2 uses the assigned name and language code for the visual rendering and for creation of the language property category name.

At en.wiki, editors can write in cs1|2 templates:

|language=bn or

|language=Bangla or

|language=Bengali

MediaWiki returns Bangla for code bn; that name is an endonym (a name the language speakers use to name their language). Because en.wiki is uses English, we are 'outsiders' so cs1|2 wants the exonym: Bengali.

So:

for |language=bn: cs1|2 finds bn in lang_code_remap; that code has the value: Bengali; cs1|2 uses that value as the name when it renders the citation (in Bengali) and uses the name and code when it creates Category:CS1 Bengali-language sources (bn).

for |language=Bangla or |language=Bengali: cs1|2 finds bangla and bengali in lang_name_remap; that name has an assigned table that holds the en.wiki preferred name and the matching language code: Bengali and bn; cs1|2 uses that language name for the rendering of the citation (in Bengali) and uses the name and code when it creates Category:CS1 Bengali-language sources (bn).

I do understand that translation is difficult and I struggle to find ways of making it easier. Suggestions from anyone on that topic are welcome.

—Trappist the monk (talk) 13:08, 18 January 2020 (UTC)

Thank you! Now it is perfectly clear to me. I went on and tried the als-code-case in our sandbox. This is what happened: link As you explained, the text was just like in the remap table. It also automatically categorizes the page according to the code used. This is all done in English and therefore should be translated in Albanian. I also know how to add new inputs to that table if needed, again, thanks to your explanation. This concludes all my queries for the moment being.

As for the translation part, I'm not that an expert and I hardly believe my suggestion is something you haven't thought before but maybe it can be made possible so the module gets some of its values from Meta? Translations there are easier to implement because of its infrastructure. That wouldn't help much with other details of l10n, such as when we asked for a special way to be able to have maint cats for local languages or citations without parameters, or even the date l10n aspect of changing formats from those used in EnWiki to local ones but it would suffice for 90% of the work with configuration page that has to be done during every update. If that could be made possible (although I find it hard to think of a practical way to implement on the module since we're not talking only about the local messages but also for the local categories, etc.) the other l10n aspects I mentioned above maybe could be grouped closer to each other, or have a sort of "read me" part that explains how to deal with them. Not very technical solutions but that's all I could think.

To be honest, from the eyes of a not-so-technical-editor like me, it seems strange that a colossal work like this is all maintained by 1 single person and you have to manually update every subpage when needs for that do arise. I've always thought that the features provided by CS1|2 module should be core features in MediaWiki and I think that would make everything much easier and smoother but I've seen that EnWiki doesn't want to standardize the use of 1 particular style of citations over others so I'm not going to suggest anything on that direction. :P - Klein Muçi (talk) 15:04, 18 January 2020 (UTC)

There is a movement to create a central repository of templates and lua modules – something sort of akin to how commons works for media – but, I cannot remember where I last read about that. I think that I recall that there are significant hurdles to making that work not the least of which is the translation problem.

—Trappist the monk (talk) 13:19, 19 January 2020 (UTC)

That sure looks like the right way to go on solving this problem although it doesn't give much hope of solving it in the near future since we're talking about gigantic steps. How about developing a bot with a central configuration page similar to IA Bot that deals with the update process in different Wiki-s that use the module? Different wikis can put the translations needed there, select what they do and don't need as special local features and the bot would take care of the update process, tech+trans. You can even have a page for bug reports and one for requesting new features. Maybe Cyber could be interested in helping on the idea? Maybe IA Bot itself could have these extra features implemented on it? - Klein Muçi (talk) 13:40, 19 January 2020 (UTC)

Also I did the translations but I'm not getting something. See the category in this link. How do I make it that I get Faqe me burime në toskërisht (als), which is the format how all the other languages' categories are named, instead of Faqe me burime në als, which is what I get when using codes from the remap table? - Klein Muçi (talk) 14:24, 19 January 2020 (UTC)

Are you sure that you want to? There are relatively few two-character ISO 639-1 languages codes; there are almost 7,900 three-character ISO 639-2 / -3 codes. At en.wiki we categorize three-character language codes into the single category Category:CS1 foreign language sources (ISO 639-2) (4,680) so that we don't have to create 7900-ish categories or periodically create new categories as editors add new three-character sources. Were I you, I would re-translate ['foreign_lang_source_2'] = 'CS1 foreign language sources (ISO 639-2)|$1' and, if you haven't already done so, create that category.

Also, for lang_name_remap:

• add ['toskërisht'] = {'toskërisht', 'als'}, so that when editors write |language=toskërisht, the module does the right thing
• change ['tosk albanian'] = ... to ['tosk albanian'] = {'toskërisht', 'als'}, because imports from en.wiki.
• do the same for biharisht

—Trappist the monk (talk) 15:27, 19 January 2020 (UTC)

I had already done those changes (I hadn't removed the English equivalent) but I undid them because I couldn't find any difference in the way citations behaved. I was expecting that after putting ['tosk albanian'] = {'toskërisht', 'als'}, our sandbox page would be categorized at a category for pages using citations in toskërisht if I put  |language=toskërisht, like it does if you add, for example, |language=Italian, but that didn't happen. That still doesn't happen even after I did what you said (latest change at the ~/Configuration subpage). See here. No category whatsoever shows up.

As for ['foreign_lang_source_2'], I translated it to the Albanian equivalent of Pages using citations in languages with their ISO code made up from 3 characters. Is that okay? I didn't want to use the name "foreign" since all of our dialects go there too so they're not really foreign. - Klein Muçi (talk) 16:53, 19 January 2020 (UTC)

Now that I think of it, it'd be good that for the language values to be in English since we write Italian/English/etc, and not Italisht/Anglisht/etc (Albanian) for the other languages. I only want it to appear in Albanian when the change is saved. So, in other words, to be able to write |language=Tosk Albanian and get në toskërisht. Maybe I shouldn't remove the English equivalent? Or is that a completely different thing from what I'm saying? Anyway I don't think I'm doing it the right way since I don't get any categories for the page (I always do for the other languages although the categories are hidden), as I mentioned above. I'm sorry I'm taking your time with this but this is new information (the new kinds of languages) and I'm struggling a bit. - Klein Muçi (talk) 17:32, 19 January 2020 (UTC)

The category does show up if I use "Albanian Tosk" instead of "toskërisht" as a value in the language parameter. Even after I removed the English equivalent from the config. page. It also does with the code als as a value (but we already knew that) although it doesn't with "toskërisht" as a value. I'm a bit lost now. Again, I'm sorry for the many messages I've written but I'm really confused on this subject. - Klein Muçi (talk) 17:47, 19 January 2020 (UTC)

I'm pretty sure that I wrote:

• add ['toskërisht'] = {'toskërisht', 'als'}, so that when editors write |language=toskërisht, the module does the right thing

If you don't tell the module that toskërisht is a valid language name, it will not recognize it so no category except sq:Category:Mirëmbajtje CS1: gjuhë e panjohur. Maintenance categories are hidden so you won't see the gjuhë e panjohur category at the bottom of a page unless you enable 'Show hidden categories' at Special:Preferences#mw-prefsection-rendering, or you add the appropriate css to your custom css page (see Help:CS1 errors § Controlling error message display) – this last doesn't show the category but does show maintenance messages which link to the category page. Properties categories are always hidden so the only way to see them on a page is to enable 'Show hidden categories'.

—Trappist the monk (talk) 18:08, 19 January 2020 (UTC)

Oh... I had completely missed that line. What about the category name in Albanian? Is it logically correct to name it like that? Don't worry about the details. I just want to know that I'm correct on the general logic of the category. - Klein Muçi (talk) 18:27, 19 January 2020 (UTC)

In general I think I like your idea of changing the ISO 639-2 / -3 category name away from 'foreign'. I think that I was influenced to name the category as a foreign language category because of the name I used for the base category for the two-character-code languages (Category:CS1 foreign language sources so, perhaps I'll move to Category:CS1 language sources (ISO 639-1) and Category:CS1 language sources (ISO 639-2, -3) or some (hopefully better) variants.

If what you wrote here as the translation of your proposed category name is an accurate translation then I think I object. You wrote:

Pages using citations in languages with their ISO code made up from 3 characters

The citations are in Albanian or English or whatever language but |language= does not apply to the citation but it applies to the source. I also object to including 'Pages using ...', 'Articles with ...' in category names because categories only list pages or articles so such prefixes in category names are redundant at best. Google translate's version of Faqe me burime në gjuhë me kod ISO 3 shifror is (of course) wholly bogus:

Source pages in ISO 3-digit language

Of course, if your category name makes sense to Albanian readers, then who am I to object. It's your wiki, make the category names be meaningful to you and your readers.

—Trappist the monk (talk) 19:05, 19 January 2020 (UTC)

I tried adding that line and everything works fine now. I even understand why you told me to remove the English parts now. :P In the end I decided to not add it since, as I said, in every other language we use only the English name for it and I didn't want to make "toskërisht", or any other language for that matter, an exception to it. It would be a different story if it was possible to use the Albanian term for every possible language but since I think that would require gigantic efforts from us (and since nearly no one is doing it now, they all already use English values in the language parameters), I decided to not work in that direction.

As for the category name, it's my bad. I should have wrote "sources" instead of "citations". In Albanian it says exactly that. I was wondering more about the expression "ISO codes with 3 digits". If that was right or not. You don't seem to see a problem with it so I'm going with that idea.

I guess that really concludes all my queries for the moment being. I still think that a bot update for the module would be a great thing to have in the future, if that was possible, but given that I cannot help in that direction, I won't "insist" on it (insist here means just writing to you again about it :P ). I'm surprised you had the nerves to deal with all our problems as a community and I want you to know that your work is really appreciated, if you don't know that yet. (I hardly believe that's the case with all your messages you get here but anyway... :P ) Thank you again! I hope I don't need to write to you too soon for any other problems. :P - Klein Muçi (talk) 02:17, 20 January 2020 (UTC)

Umm, I'm pretty sure that I did not tell you to remove the English parts. I think that non-English wikis should keep many of the English names because then the module suite will continue to recognize those names when they appear in cs1|2 templates that are imported from en.wiki.

In English, digits are numbers (0, 1, 2, ...); ISO 639 does not use digits in its language codes. The English translation of Faqe me burime në gjuhë me kod ISO 3 shifror that you gave me used the term 'characters' which is correct; google translate of that same category name used the term 'digit' which to my English-speaking mind is completely wrong. If you are content that Albanian readers will understand the category name, then you're done.

—Trappist the monk (talk) 15:26, 20 January 2020 (UTC)

Maybe again I expressed myself badly in English. I was talking about this part: change ['tosk albanian'] = ... to ['tosk albanian'] = {'toskërisht', 'als'}, because imports from en.wiki. do the same for biharisht. I understood that to mean change this ['tosk albanian'] = {'Tosk Albanian', 'als'}, to this ['tosk albanian'] = {'toskërisht', 'als'},, which is what I did (with all the languages which I changed). That's "removing the English part" (Tosk Albanian). I hope I've understood you correctly on that one.

As for the digits, apparently I hadn't thought of that detail because I really meant digits. I'm changing it to something more suitable now. - Klein Muçi (talk) 15:46, 20 January 2020 (UTC)

Yeah, that was correct as far as it goes. You changed

['als'] = 'Tosk Albanian', → ['als'] = 'toskërisht',

and you changed

['tosk albanian'] = {'Tosk Albanian', 'als'}, → ['tosk albanian'] = {'toskërisht', 'als'},

That works for the two cases where editors write:

|language=als

|language=Tosk Albanian

but does not work when editors write:

|language=toskërisht

which they very well might do because they have seen the rendering: (in toskërisht)

So, I think that you should add:

['toskërisht'] = {'toskërisht', 'als'},

to lang_name_remap{}

—Trappist the monk (talk) 16:06, 20 January 2020 (UTC)

Your logic is correct but I don't feel comfortable adding it for 2 reasons:

1. We only use English values for the parameter |language= because that's how it works with the other languages (2 characters ISO codes). I don't want this to be an exception as I'm afraid this will led to confusion if they try to do the same with other languages and they get "unknown language" as a category.
2. None of the editors go as far as to put the dialectic name of the language when citing sources. We're lucky if they even put a value to the |language= parameter. (In this case they'd just put sq as a value.) That's why we've asked for a specific error message that alerts users when they've forgotten to complete that parameter when needed. (Something you made possible.) I just translated it "just in case" but I don't want to do it an exception to the rule. I'll check the "unknown language" maint cat often to see the trends there and act accordingly if I see that that behavior starts to be the norm.

I also changed the name of the aforementioned category to use the word "letters" instead of "digits". - Klein Muçi (talk) 16:21, 20 January 2020 (UTC)

Dead-link / url-status at bs.wiki

Hey, Trappist. Sorry to bother you, but I didn't know who else to ask... Could you, when you get the chance to, change the Citation/CS1 module over at the Bosnian Wikipedia so that it doesn't display an error when url-status is used (e.g. here) since we haven't updated the module since the dead-link parameter was changed to url-status. – Srdjan m (talk) 18:08, 6 January 2020 (UTC)

I'd rather not. You are using a very old version of the module suite. It will be a pain for you at bs.wiki, but I would strongly urge you to update to the new version. Another wiki asked a similar question this morning to whom I have given pretty explicit instructions. See that discussion at Help talk:CS1 errors § Help fix errors in references on sdwiki article.

—Trappist the monk (talk) 18:48, 6 January 2020 (UTC)

Hey again. I copied all the code, but I'm having trouble setting the acceptable date formats – the rest of the localization I can do on my own. Could you take a look at the sandbox version and make it so only the following two date formats are accepted:

• 1. 1. 2020
• 1. januar 2020

No leading zeroes, with spaces between the day and the month, and with no period at the end of the year. Any other format, such as:

• January 1, 2020
• 1 January 2020
• 1. jan 2020
• 1. jan 2020.
• 01. 01. 2020
• 01. 01. 2020.
• 1.1.2020
• 1.1.2020.

should not be accepted or should be automatically converted to the first format – 1. 1. 2020? Or better yet, allowing the first two formats with the ending period, but stripping it in the output so they're not doubled like this? Or if you can't, is there someone who would be able to help? – Srdjan m (talk) 21:47, 6 January 2020 (UTC)

I have added patterns that I think should work for

• 1. 1. 2020
• 1. januar 2020

These patterns are the top two in the patterns{} table in bs:Modul:Citation/CS1/Date validation/igralište. Do they work?

—Trappist the monk (talk) 23:00, 6 January 2020 (UTC)

Hm, doesn't seem like it. I made some testcases with {{cite web}} using the sandbox version of Citation/CS1 that you can use to test. – Srdjan m (talk) 23:41, 6 January 2020 (UTC)

Fixed the 1. 1. 2020 format.

I have to think about the trailing dot problem. I also have to think about the en.wiki dMy 1 January 2020 vs the bs.wiki dMy 1. januar 2020. For the English dMy date format case we want to constrain the month-names-test to the names in cfg.date_names['en'] but in the Bosnian dMy date format case we want to constrain the month-names-test to the names in cfg.date_names['local'] – we don't want to accept 1. January 2020 or 1 januar 2020. Haven't had a need to do that before so it will take some thinking. I think that auto-reformatting shouldn't be too difficult but that will come later; first these other two issues.

—Trappist the monk (talk) 00:57, 7 January 2020 (UTC)

All right. Thank you for the help so far. Take your time. – Srdjan m (talk) 01:01, 7 January 2020 (UTC)

Hey. Any update on this? – Srdjan m (talk) 13:33, 13 January 2020 (UTC)

You did say Take your time. The bs.wiki cs1|2 module suite (now out of date because en.wiki was updated over the weekend) supports the two date formats that you required along with all of the en.wiki formats (which should be retained because many wikis import articles from en.wiki). I am working on several other things so, unless what you want is now critically important, I will get to the non-critical changes you want when time permits.

—Trappist the monk (talk) 14:25, 13 January 2020 (UTC)

I took the opportunity to sync all the modules-related files (I didn't overwrite any code changes you made in /Date validation). Do you think I should start replacing dead-link with url-status at this point or should I wait for the sandbox version to be synced with production on bs.w? – Srdjan m (talk) 17:52, 13 January 2020 (UTC)

You could. Because the default state for |dead-url= is yes, which is the same as the default |url-status=dead, wherever in bs.wiki you encounter any of |url-status=dead, |dead-url=yes, or |deadurl=yes, you can delete the parameter without any worry of harm. Changing |dead-url=no or |deadurl=no to |url-status=live will create additional errors until you update your live module suite from your sandbox module suite.

There is no perfect way to accomplish the transition quietly. Here, when we deprecated |deadurl= and |dead-url= there was an uproar because all of a sudden there were red error messages. To quell the furor we hid the deprecated parameter messages (error_conditions.deprecated_params.hidden = true in ~/Configuration). You might do the same thing with error_conditions.parameter_ignored – caveat lector: doing that will also hide the error messages for all unrecognized parameters.

—Trappist the monk (talk) 23:31, 13 January 2020 (UTC)

Hey. I replaced the dead-url parameter, and I've moved the sandbox version to production. However, I've run into a problem. Even though I put in aliases here, they don't seem to work. See this article as an example. I'm not sure what I'm doing wrong... – Srdjan m (talk) 19:54, 20 January 2020 (UTC)

Parameter names must be defined in the ~/Whitelist so that the module knows that they are good parameter names. I've added a note to that effect in my copy of the ~/Configuration/sandbox.

—Trappist the monk (talk) 20:17, 20 January 2020 (UTC)

Question about IPA-x templates

As the one of all things language-template-related, can I get your opinion on this? I was looking at the IPA-x template family and was wondering if they could be merged, similar to how in-lang|x was done. However, I noticed that unlike the xx-icon family, these have very different code. As an example - Template:IPA-ja, Template:IPA-gsw and Template:IPA-hmn (and I wouldn't be surprised if there are more, I just sampled a few). What do you think? --Gonnym (talk) 08:42, 19 January 2020 (UTC)

I have only looked at a handful of these templates. For the most part, the templates that I checked seem to follow the model used by {{IPA-ja}}. Though is initially 'looks' different, {{IPA-hmn}} calls {{IPA-all}} which looks to be, more-or-less, the same as {{IPA-ja}}.

I am a bit perplexed by {{IPA-gsw}}. Alemannic German is the name for a group of related dialects. Is the purpose of the unqualified (without language-code keyword) template to provide for those cases where pronunciation is common among the four dialects: Swiss German (gsw), Colonia Tovar, (gct), Swabian German, (swg), and Walser German (wae)? The keywords gsw, gct, swg, and wae are not documented; there are redirects to {{IPA-gsw}} from {{IPA-gct}}, {{IPA-swg}}, and {{IPA-wae}} but these redirects are simple redirects they don't call {{IPA-gsw}} with the appropriate keyword set as one would expect them to do.

Of course these differences are to be expected when there are a large number of similar templates all purportedly doing the same thing. So, yeah, I'm in favor of consolidation. You might want to talk to the editors who appear to be the primary contributors to these templates. Getting them on-board would go a long way to easing the transition. Start a conversation somewhere public (is there an IPA project?) and let me know where it is.

—Trappist the monk (talk) 13:02, 19 January 2020 (UTC)

Started a discussion at Wikipedia talk:WikiProject Linguistics#IPA-x templates. --Gonnym (talk) 11:40, 22 January 2020 (UTC)

ISO 639 name templates

Another language-family templates question. You created Module:ISO 639 name which says is intended as a replacement for {{ISO 639 name}} and the plethora of {{ISO 639 name <code>}} templates (see Category:ISO 639 name from code templates)). Are the templates there like Template:ISO 639 name aat ready for TfD? --Gonnym (talk) 11:44, 22 January 2020 (UTC)

I haven't thought about that module in a while. It is being used by {{ISO 639 name link}}. That template's mate, {{ISO 639 name}} would need to be updated before any contemplation of TfDing the individual templates. Then some mechanism must be devised to either modify all of the various {{ISO 639 name <code>}} to call {{ISO 639 name|<code>}} instead of simply returning the plaintext language name as they do now. Then, some other mechanism can replace calls to these individual {{ISO 639 name <code>}} templates with direct calls to {{ISO 639 name|<code>}}. Once that is accomplished, the {{ISO 639 name <code>}} templates can be deleted.

Caveat lector: I have not fully thought this out so the above may be adequate, incomplete, or wholly wrong.

—Trappist the monk (talk) 16:40, 22 January 2020 (UTC)

Dave Taylor - no payment for art

Hey Trappist,

Just curious if you added the part to Dave Taylor about paying for art and not getting it. I'm in the same situation and wanted to see what you did about it? — Preceding unsigned comment added by Pootrzew (talk • contribs) 10:29, 24 January 2020 (UTC)

I did not. That is not the sort of editing that I do.

—Trappist the monk (talk) 11:56, 3 February 2020 (UTC)

Question

I'm hoping it's OK to ask, since you are virtually the only editor in the history at Module : Citation/CS1: Revision history, if you were the coder who made "website=" italicization mandatory? --Tenebrae (talk) 20:35, 1 February 2020 (UTC)

(talk page stalker) It appears that the {{cite web}} template has italicized the names of works since before it was converted to use the CS1 modules. Here's a comparison between the current template and the pre-module template, as far as I know:

Cite web comparison

Wikitext	{{cite web|title=Title of web page|work=Website}}
Old	"Title of web page". Website.
Live	"Title of web page". Website. {{cite web}}: Missing or empty |url= (help)
Sandbox	"Title of web page". Website. {{cite web}}: Missing or empty |url= (help)

I could be wrong. – Jonesey95 (talk) 02:10, 2 February 2020 (UTC)

Of course it is ok to ask. The answer is: no. History:

• |website= is an alias of |work=. The first version of {{cite web}} italicized |worktitle=. |worktitle= was simplified to |work= with this edit.
• |website= was introduced to Module:Citation/CS1/Whitelist with this edit and then activated with this edit to Module:Citation/CS1/Configuration.

—Trappist the monk (talk) 12:04, 3 February 2020 (UTC)

I appreciate your graciousness, Trappist. Thank you, truly.

To respond to Jonesey95: Indeed, "Cite web" has italicized that field for quite some time. But it only recently made that italicization mandatory by removing the ability to use two quote marks to de-italicize. That change never went through Manual of Style consensus — and WP:Consensus#Determining consensus says that how-to and template documentation pages "have not formally been approved by the community through the policy and guideline proposal process, thus have no more status than an essay." So there was no consensus to make website italicization mandatory. I'm just trying to find the coder who did so in order to open a discussion and establish collegial communication. --Tenebrae (talk) 22:49, 3 February 2020 (UTC)

The (consensus-based) discussions about stripping italic markup for those parameters are in the Help Talk:CS1 archives, at some combination of Help talk:Citation Style 1/Archive 56, Help talk:Citation Style 1/Archive 57, and Help talk:Citation Style 1/Archive 60. There may be other links from those pages that help you understand the changes that have been made. – Jonesey95 (talk) 00:00, 4 February 2020 (UTC)

(edit conflict)

So that is the real question that you are asking and what it is that you mean by 'mandatory'. That coder was me. All cs1 and cs2 templates generate COinS metadata. Those metadata, while not directly visible to the general readership, are read and consumed by readers using reference management software (Zotero is one such tool). The COinS standard has limited capabilities. It is the responsibility of the cs1|2 templates to render a properly formatted citation (font style, punctuation, etc) and to create correct metadata from the template parameters.

Wiki-markup for bold and italic font-faces is not permitted in any of the |journal=, |magazine=, |newspaper=, |periodical=, |publisher=, |website=, and |work= parameters because that markup is not part of the 'name' assigned to those parameters – it is The New Yorker, not ''The New Yorker''. Module:Citation/CS1 detects and removes bold and italic wiki-markup before the citation is rendered and before the metadata are created. The error message serves as an indicator to editors that the markup is extraneous and should be removed. Example:

{{cite web |url=//example.com |title=Title |website=''Example''}} → "Title". Example. {{cite web}}: Italic or bold markup not allowed in: |website= (help) – the value assigned to |website= is italicized because {{cite web}} has always italicized |work= and its aliases.

—Trappist the monk (talk) 01:04, 4 February 2020 (UTC)

Again, thank you for your collegiality. You're absolutely correct: "website=" has always italicized. But only recently has that field begun to not allow Wiki markup, specifically two single quotes on either side of the entry, to de-italicize. And unlike names of periodicals, there is no Wikipedia MOS requirement for non-periodical website names, such as NASA and Sears, to be italicized. Indeed, the major styles AP and Chicago Manual of Style do not italicize them. --Tenebrae (talk) 01:26, 4 February 2020 (UTC)

Also, I do want to compliment you and thank you for your coding work. I understand you're voluntarily contributing work that can cost upwards of $300 an hour, and you're offering that expertise for free to make Wikipedia better. I thought it was important to acknowledge that. --Tenebrae (talk) 01:34, 4 February 2020 (UTC)

(edit conflict)

Thank you.

As I have said before, cs1|2 is not CMOS; cs1|2 is not AP; cs1|2 is not MLA; nor any other style but its own. Because WP:CITESTYLE allows any consistent citation style, MOS exercises very limited control over the the chosen style: MOS does not direct how citations using CMOS style are to be rendered; does not direct how citations using MLA style are to be rendered; does not direct how citations using cs1|2 style are to be rendered (except that cs1|2 complies with a subset of MOS:DATEFORMAT). Rendering of citations is solely the remit of the citation style chosen for the article.

—Trappist the monk (talk) 01:51, 4 February 2020 (UTC)

I understand. What's happening, though, is that the vast majority of editors see "cite web" and use it for everything online. And since there's no "cite database" or "cite organization," that means all website names are in italics, even ones that are never italicized, like NASA and Rotten Tomatoes. I hope I'm explaining things right. And I'm hoping you can see the issue — that everyone uses "cite web", which forces that non-standard italicization, and that there doesn't seem to be any template alternative without corrupting metadata. Thank you again for taking the time to read this. Am I explaining OK, or being muddled?--Tenebrae (talk) 21:35, 4 February 2020 (UTC)

I suppose that could be because editors have failed to read and understand the first sentence in the {{cite web}} documentation:

This Help:Citation Style 1 template is used to create citations for web sources that are not characterized by another CS1 template.

Yeah, there isn't much there and it is sandwiched between the TOC and some other stuff, but there it is nonetheless. Documentation can always be improved. If you can find better ways of saying that {{cite web}} should not be editor's first choice when citing online sources, please say what that way is.

We disagree about what should and what should not be italicized. A NASA-published website is a NASA publication so without any other title available, |website=NASA should be italicized because that is an eponymous publication and we cite the publication, not the publisher; same for Rotten Tomatoes... You disagree, I know that, so there is no need for you to repeat your arguments here; we've been there before...

—Trappist the monk (talk) 22:48, 4 February 2020 (UTC)

I understand and respect your position; most mainstream styles disagree, but there's room for everyone's take on this. I'm wondering: Do you not think we ought to have a choice of whether to italicize or not? --Tenebrae (talk) 23:02, 4 February 2020 (UTC)

Because cs1|2 is used in millions of articles, I want it to be as simple (I know, it's not) and as consistent as it can be. Too many options are just too many options; kinda like the cereal isle at the market. It is the duty and responsibility of the cs1|2 templates to do all of the necessary formatting that it can so that template renderings are consistent with each other citation-to-citation and article-to-article. cs1|2 is a general purpose tool that is perfectly adequate for most citation needs. It will never be all-things-to-all-editors.

—Trappist the monk (talk) 23:23, 4 February 2020 (UTC)

Thank you!

		All-Around Amazing Barnstar
		For all your time and effort on the technical and coding side of Wikipedia, for your generosity of spirit, for your help in creating a much-needed template for WikiProject:Film, and for your patience and graciousness throughout the process ... thank you! Tenebrae (talk) 23:33, 5 February 2020 (UTC)

Citation Style 1 parameter output

Also @RudolfRed: Referring to Wikipedia:Help_desk/Archives/2019_November_25#Help:Citation_Style_1_parameter_output, I would like to, once more, point out to you the fact that – as opposed to your statements – for neither of the three parameters arXiv, Bibcode, and doi (as used e. g. in Milky_Way#cite_note-ssr100_1_129-1), a space is rendered after the colon. I've checked with several different browsers and gadgets.--Hildeoc (talk) 18:30, 7 February 2020 (UTC)

This citation, right?

{{Cite journal | last1 = Gerhard | first1 = O. | title = Mass distribution in our Galaxy| journal = Space Science Reviews | volume = 100 | issue=1/4| pages = 129–138 | doi = 10.1023/A:1015818111633 | bibcode=2002SSRv..100..129G| arxiv=astro-ph/0203110| year = 2002 | pmid = | pmc = }}

Gerhard, O. (2002). "Mass distribution in our Galaxy". Space Science Reviews. 100 (1/4): 129–138. arXiv:astro-ph/0203110. Bibcode:2002SSRv..100..129G. doi:10.1023/A:1015818111633.

Here is what cs1|2 outputs for the three identifiers you mention from that citation:

for arXiv:

[[:en:ArXiv|arXiv]]:<span class="cs1-lock-free" title="Freely accessible">[//arxiv.org/abs/astro-ph/0203110 astro-ph/0203110]</span>.

for bibcode:

[[:en:Bibcode|Bibcode]]:[https://ui.adsabs.harvard.edu/abs/2002SSRv..100..129G 2002SSRv..100..129G].

for doi:

[[:en:Digital object identifier|doi]]:[//doi.org/10.1023%2FA%3A1015818111633 10.1023/A:1015818111633].

No space between the identifier labels and the colons; no space between the colons and the identifier hyperlinks. Like this:

<identifier label><colon><identifier>

This is as it is supposed to be as I noted in that other conversation.

Also in the other conversation, I wrote:

In your OP, you appear to be asking about Help:Citation Style 1#csdoc_bibcode and yes there is, and is supposed to be, a space after the colon there.

Just because there is a space after the colon in the help page text about the bibcode identifier, it does not mean that in the rendered citation, the identifier label, the colon, and the identifier hyperlink will be separated with space characters. The space following the colon on the help page is merely a matter of style adopted by the editor who wrote that text (first version of the help text). But, again, the help text, which has a space character, is not the same as the citation rendering, which does not have a space character.

—Trappist the monk (talk) 19:03, 7 February 2020 (UTC)

Hello again, and thank you very much indeed for taking the time and trouble to give this detailed comment! Now I got it: You were referring to the Help page as such, while I actually meant the mere use of Citation Style 1 (as, for instance, in Template:Cite journal, used in the given reference). Hence, I have to expressly apologize for that imprecision of mine! Do you happen to know why exactly there is supposed to be no space rendered after the relevant identifiers (and colons)?--Hildeoc (talk) 20:56, 7 February 2020 (UTC)

In cs1|2, support for the doi identifier was the first of the colon-separated label/hyperlink pairs to be added. The doi handbook indicates that proper presentation is <doi><colon><doi name>; see the handbook. I suspect that as the other colon-separated label/hyperlink pairs were added, the editors simply followed the doi model for consistency.

—Trappist the monk (talk) 23:12, 7 February 2020 (UTC)

February 2020

Hello, I'm Mark299. I wanted to let you know that one or more of your recent contributions have been undone because they did not appear constructive. If you would like to experiment, please use the sandbox. If you have any questions, you can ask for assistance at the help desk. Thanks. Mark299 (talk) 19:33, 10 February 2020 (UTC)

@Mark299: Yeah, I've been around long enough to know about the sandbox. I am going to revert your revert. If you believe that my edits are truly not constructive, feel free to continue this conversation here.

—Trappist the monk (talk) 19:41, 10 February 2020 (UTC)

Another technical question

Hi, your knowledge helped me sometimes. Now I am seeking an answer I could not get anywhere: when a multilingual file is shown on the file page, something in the system knows about the built-in text switch and a box "Render this image in:" appears with all the languages (at e.g. File:Gerrit patchset 25838 test.svg) in a drop-down menu. Is there any possibility − by a template, a module, a script − that I can access that list of languages (ISO codes), when it had been read and built? sarang♥사랑 17:07, 12 February 2020 (UTC)

Alas, if there is a way to do that, I don't know it. From the debug console is possible to:

create a file title object:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File') → File:Gerrit patchset 25838 test.svg

determine that the file exists:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.exists → true

discover that it does not have multiple pages:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.pages → nil

get the image width:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.width → 345

and height:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.height → 214

and size:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.size → 7961

and MIME type:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').file.mimeType → image/svg+xml

but, the file is not a content page:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File').isContentPage → false

so it is not possible to get its content:

=mw.title.new ('Gerrit patchset 25838 test.svg', 'File'):getContent() → nil

Seems to me that such a facility might be handy, though at the moment I don't know how such facility might be used. I would imagine that the reason might be that the language support that is available in .svg is not available in .png, .jpg, .gif, and other supported file formats. And what if something language-specific isn't included in the .svg file? For example, what if one .svg source switch was inconsistent: de 'Grün' omitted? – which switch language list would be returned? Given that, I suspect that the simple ability for a module to get the content of a .svg file and parse it apart to suit its own particular needs would be the best that you could hope for (presuming you can convince MediaWiki to provide the ability to get the .svg content in the first place ...).

—Trappist the monk (talk) 18:17, 12 February 2020 (UTC)

Thank you for answering and searching all the facilities. As a matter of fact, I do not know anything how such an appearing file page is produced, and how mediawiki(?) analizes whether there are "system language' entries; I think that the SVG source code is checked to create that table I mentioned. I hoped that you might know whom to ask; and I hoped that such an access to the language table could be enabled on request. Currently we have the unsatisfying situation that the file page shows the language table which is up-to-date valid, while a template which wants to show all languages cannot know about the last additions, and needs an update. With the desired access to the language table things could have been actualized automatically. sarang♥사랑 09:43, 13 February 2020 (UTC)

You might try asking at WP:VPT someone there might know or know who to ask.

—Trappist the monk (talk) 11:37, 13 February 2020 (UTC)

Do not undone my valid edits

I have removed duplicate wiki links from shaadi.com article. Don't undone my valid edits. Having same link more than 1 time in same articles look like spam & junky. Editiorman (talk) 15:41, 14 February 2020 (UTC)

@Editiorman: You did indeed remove a duplicate wikilink with this edit. I have no dispute with that. But, in that same edit, you wikilinked the word 'Matrimonial' in a {{cite news}} template which creates an error:

{{cite news |title=Shaadi.com voted the best [[Matrimonial]] Website in the 2011 Reader's Choice Awards|url=http://www.business-standard.com/article/press-releases/shaadi-com-voted-best-matrimonial-website-in-2011-reader-s-choice-awards-111060100107_1.html|newspaper=Business Standard|accessdate=18 July 2015}}

"Shaadi.com voted the best [[Matrimonial]] Website in the 2011 Reader's Choice Awards". Business Standard. Retrieved 18 July 2015. {{cite news}}: URL–wikilink conflict (help)

I reverted but retained the valid part of your edit so that the citation template is no longer broken and the duplicate wikilink removed. How is it that I have done you wrong by this?

—Trappist the monk (talk) 15:54, 14 February 2020 (UTC)

Oh, i didn't noticed that. sorry it was my mistake. Editiorman (talk) 16:03, 14 February 2020 (UTC)

CS1_errors#Unknown_parameter_|xxxx=_ignored

Hi, I had referenced your 1 June 2019 comments on the |dead-url deprecation in the CS1-errors page, but it was quickly (5 minutes later) edited out, with a short addition to introductory English substituted.

Instead of a useless edit war, I've started a discussion future ways to add gory, technical details, over at

Help_talk:CS1_errors#Unknown_parameter_|xxxx=_ignored

and I thought you might want to participate, as you have supplied great info in the past. --Lent (talk) 06:52, 16 February 2020 (UTC)

On the automated side of things, I made a suggestion for an automated suggestion for the now removed, previously deprecated, dead-url and deadurl, to url-status.

See: Wikipedia:Village_pump_(technical)#Automated_suggestion_for_|dead-url=_|deadurl=_to_|url-status --Lent (talk) 10:03, 16 February 2020 (UTC)

Haunting hour episode list "wrong number"

A goof in the summary that says "It turns out the Adriana" when it's supposed to say "It turns out that Adriana" instead. Can you please fix it? — Preceding unsigned comment added by Riders&Rangers (talk • contribs) 16:54, 22 February 2020 (UTC)

Thank you.

For fixing that goof in that list. — Preceding unsigned comment added by Riders&Rangers (talk • contribs) 17:11, 22 February 2020 (UTC)

Random question

Hello there, I asked another editor a question, and I did not get a reply. But I thought you might be willing to answer it. I asked at User_talk:Dawnseeker2000#Random_question in case you have the time and inclination. Best wishes, Biosthmors (talk) 17:31, 24 February 2020 (UTC)

Author & Professional Dating Coach Alan Roger Currie

I have a request for help from you: Can you kindly provide me with some support for the Alan Roger Currie article that I created in April 2015?? I would VERY MUCH appreciate your support and assistance. Thank you. The Discussion is HERE Chicago Smooth (talk) 16:41, 2 March 2020 (UTC)

I think that I shall decline. I rarely participate in deletion discussions where the thing to be deleted is not technical (templates, modules, yes, articles, no).

—Trappist the monk (talk) 19:30, 2 March 2020 (UTC)

Citation question

Hi, I was "taught" years ago by an admin to cite Newspapers.com with |via=. My reading of {{citenews}} shows that seems to be correct, as Newspapers.com is a "aggregator of the resource that provided the digital version". I see this edit changing via to |website=. Is either OK, or is one method preferred? MB 14:53, 3 March 2020 (UTC)

In that edit, Editor Derek R Bullamore allowed ReFill 2 to make (yet another) bogus edit. That 'tool' changed this:

1. {{cite news|title=Broken Back Helped Heidt To Success in Show World|url=https://www.newspapers.com/clip/2913993/daily_capital_journal/|agency=Capital Journal|date=August 6, 1951|page=17|via = [[Newspapers.com]]|accessdate = July 30, 2015}} {{Open access}}

"Broken Back Helped Heidt To Success in Show World". Capital Journal. August 6, 1951. p. 17. Retrieved July 30, 2015 – via Newspapers.com.

to this:

2. {{cite news|title=Broken Back Helped Heidt To Success in Show World|url=https://www.newspapers.com/clip/2913993/daily_capital_journal/|agency=Capital Journal|date=August 6, 1951|page=17|website=[[Newspapers.com]]|accessdate = July 30, 2015}} {{Open access}}

"Broken Back Helped Heidt To Success in Show World". Newspapers.com. Capital Journal. August 6, 1951. p. 17. Retrieved July 30, 2015.

Neither are correct.

In #1, Capital Journal is in |agency=; Capital Journal is a news paper, not a news agency so |newspaper=Capital Journal is correct. Because the clipping cited is 'distributed' by an entity that is not the newspaper's publisher, |via=Newspapers.com is correct.

The edit to make #2 is wrong because the citation isn't citing Newspapers.com but is instead citing a clipping (article) from a newspaper (the work) via a third-party (Newspapers.com).

In both, {{open access}} is improper because the term 'open access' carries with it certain licencing agreements between the publisher and a re-user. Wikipedia has no business making claims of re-usability for something published by someone else. Further, cs1|2 templates do not highlight the norm so |title= linked with |url= is presumed to be free-to-read unless marked otherwise (|url-access=subscription etc).

I think that the correct citation should be:

{{cite news |title=Broken Back Helped Heidt To Success in Show World |url=https://www.newspapers.com/clip/2913993/daily_capital_journal/ |newspaper=[[Capital Journal (Oregon)|Capital Journal]] |date=August 6, 1951 |page=17 |via=[[Newspapers.com]] |access-date=July 30, 2015}}

"Broken Back Helped Heidt To Success in Show World". Capital Journal. August 6, 1951. p. 17. Retrieved July 30, 2015 – via Newspapers.com.

—Trappist the monk (talk) 15:26, 3 March 2020 (UTC)

I agree, FWIW. Capital Journal is the newspaper in question, so it should be in |website/work/newspaper= (they are equivalent in this template). – Jonesey95 (talk) 15:56, 3 March 2020 (UTC)

{{Open access}} implies no "licencing agreements between the publisher and a re-user". It simply means the source is free to read. However, the problem is that this is often misleading, because {{Open access}} is vague about what it applies to. Capital Journal? Newspaper.com? Headbomb {t · c · p · b} 16:23, 3 March 2020 (UTC)

Perhaps free-to-read is what editors who use {{open access}} intend. For citing clippings at Newspaper.com, {{open access}} is inappropriate.

Open access does imply an agreement between the re-user and the publisher. Suppose you are the author of a paper that has been published in a peer-reviewed, open-access journal. Suppose that another author is writing another paper and wants to use a table of your data and some accompanying graphs from your paper in their paper. There must be an agreement between you or your publisher and the reusing author that allows the re-user to publish your data and your graphs in their paper. The agreement could be something as simple as an acknowledgement that you and/or your publisher are the source of the data table and of the graphs under a CC-BY license or the licensing could be something much more complex. There is still a licence between the re-user and the copyright holder.

—Trappist the monk (talk) 17:43, 3 March 2020 (UTC)

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

please help translate this message into your local language via meta

The 2019 Cure Award

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

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

Cite PMC limit

I've just updated the PMC check limit to 8000000, see https://en.wikipedia.org/w/index.php?title=Module:Citation/CS1/Identifiers&diff=944269085&oldid=938748668 , because PMCs have just gone beyond the 7000000 limit: see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7003341/ . I've also updated Help:CS1 errors to match. I hope I haven't messed up your release staging, but I'm pretty sure this is a harmless change that won't break anything. -- The Anome (talk) 19:32, 6 March 2020 (UTC)

Proofreader category and Translated page templates

Hey, do you think you can convert Template:Proofreader category to use one of the newer modules? This can help clear a bit of uses from the "ISO 639 name x" templates. --Gonnym (talk) 14:23, 1 March 2020 (UTC)

Also, Template:Translated page. --Gonnym (talk) 14:25, 1 March 2020 (UTC)

I don't know why the ISO templates are used in {{translated page}}. The documentation for that template says to get the language code of the source (translated) article from meta:List of Wikipedias which I suspect gets its language names from the {{#language:}} magic word which does not always return ISO 639 language names and also supports wholly non-ISO 639 language codes that Module:lang does not support. So, the fix for that template would be, I think, to replace the ISO 639 template calls in {{translated page}} with calls to the {{#language:}} magic word.

I think that the same might be applied to {{proofreader category}}. There is damn-little documentation for this template and the user-box template that populates it so one might construe that to mean that editors who use these user-box templates may be translating from something other than another-language Wikipedia. There is no ISO 639 language code simple but:

{{#language:simple|{{CONTENTLANGUAGE}}}} → Simple English

There will be other oddities:

{{ISO 639 name ksh}} → Kölsch – correct according to ISO 639-3

{{#language:ksh|{{CONTENTLANGUAGE}}}} → Colognian

and

{{ISO 639 name jpn}} → Japanese – not an ISO 639 code

{{#language:jpn|{{CONTENTLANGUAGE}}}} → jpn

Still, I think, that for these it would be best to use {{#language:}} instead of the templates.

—Trappist the monk (talk) 16:30, 1 March 2020 (UTC)

Ok, so I tested this out on Category:Proofreaders fr-en and it displays Proofreaders from français to English. instead of Proofreaders from French to English., which isn't ideal. Is there anything else that can work here? --Gonnym (talk) 21:04, 8 March 2020 (UTC)

I just replaced the first sentence in the template with:

Proofreaders from {{#language:{{{1}}}|{{CONTENTLANGUAGE}}}} to English.

Then, when I previewed Category:Proofreaders fr-en, I got:

Proofreaders from French to English.

Did you omit the {{CONTENTLANGUAGE}} bit?

—Trappist the monk (talk) 22:00, 8 March 2020 (UTC)

And for {{Translated page}} it fails creating a category with Category:Pages translated from {{#language:{{lc:{{{1}}}}}}} Wikipedia. --Gonnym (talk) 21:07, 8 March 2020 (UTC)

If {{{1}}} is fr then:

Category:Pages translated from {{#language:{{lc:fr}}}} Wikipedia → Category:Pages translated from français Wikipedia

But, with the {{CONTENTLANGUAGE}} bit:

Category:Pages translated from {{#language:{{lc:fr}}|{{CONTENTLANGUAGE}}}} Wikipedia → Category:Pages translated from French Wikipedia

—Trappist the monk (talk) 22:00, 8 March 2020 (UTC)

Oh! I completely missed that 2nd part. Thanks, that does indeed work! One more question, I noticed that Template:User Translator uses {{#invoke:ISO 639 name|iso_639_name|{{{1}}}}}, should I maybe change Proofreader category to use that also?--Gonnym (talk) 08:46, 9 March 2020 (UTC)

The userbox template should probably change to use {{#language:}} because the userbox links to Wikipedia:Translation which is about translating Wikipedia articles. If you are going to be mucking about in {{User Translator}}, fix the doubled documentation. Also, {{User Translator 2}} ...

—Trappist the monk (talk) 11:51, 9 March 2020 (UTC)

Ok, changed the above templates. Last two templates (that I found) using this template. Template:Rough translation and Template:Cleanup translation. What should they use? The #language function, the ISO module, or something else? --Gonnym (talk) 12:34, 9 March 2020 (UTC)

And also these?

• {{Not English}}
• {{Rough translation}}
• {{Hidden translation}}
• {{Proofreader needed}}

I've just been wondering if it wouldn't make sense to write a module that can be used for all of these templates that uses MediaWiki's builtin language-names list. That could give us code_to_name(), name_to_code(), is_lang_code() and perhaps other functionality that the simple {{#language:}} magic word doesn't give us. Code for code_to_name() and name_to_code() functionality has already been written and is in use in Module:Citation/CS1 and Module:cs1 documentation support though alas, that code is specifically tailored for cs1|2 so can't just be require()'d into a new module.

—Trappist the monk (talk) 13:36, 9 March 2020 (UTC)

No idea how I missed {{Hidden translation}}, and wasn't checking for Module:ISO 639 name uses so didn't even check {{Proofreader needed}} (there are probably more like this). {{Not English}} uses {{Lang2iso}}, which shares the family of templates of {{Iso2language}}, {{Iso2country}} and {{Iso2nationality}} (which were going to be part of a future question I wanted to ask you, but you beat me to it). I've just been wondering if it wouldn't make sense to write a module that can be used for all of these templates that uses MediaWiki's builtin language-names list - I'm all in favor of merging these language templates and their code. To me (with limited knowledge in this field disclaimer), it seems like we have a lot of templates that do the same thing. Even something like the ISO templates, I'm not sure why a code cannot be evaluated to see if it belongs to any of the language lists. I'm looking at the errors in Category:ISO 639 name template errors and one of the categories is Category:Translators zh-cn-en, yet Template:ISO 639 name zh-cn says it's supported (I'm sure there is a reason for this, just from the outside it seems very strange). Anyways, if the code is already available in the Citation module, I'm sure separating it to a different module, allowing both module ("require") and template calls is not that complicated. Can I help in any way?

Unrelated to the above module discussion, but I've noticed that some of the invocations of {{ISO 639 name}} or its redirects are being used in the same way {{In lang}} is. See Strait of Gibraltar crossing as an example at the EL section. Do you think your bot can check if the template is used near a link and covert those to In lang? --Gonnym (talk) 14:04, 9 March 2020 (UTC)

Module:Sandbox/trappist the monk/mw lang:

{{#invoke:Sandbox/trappist the monk/mw lang|name_from_code|nv}} →

{{#invoke:Sandbox/trappist the monk/mw lang|code_from_name|Navajo}} →

{{#invoke:Sandbox/trappist the monk/mw lang|is_code|Navajo}} →← (not a recognized code so returns empty string)

{{#invoke:Sandbox/trappist the monk/mw lang|is_code|NV}} →

As an IETF language tag, zh-cn means Chinese as spoken in China. MediaWiki returns .

I don't think that converting wholly unrelated templates to {{in lang}} is within the Monkbot/task 15 remit. There are relatively few transclusions in article space so it just might be that making the bot, or a bot, do this task is not worth the effort.

—Trappist the monk (talk) 14:57, 9 March 2020 (UTC)

Nice, that was fast. How do you see these being used? (I'm not sure I see your vision yet). Also, how are "code_to_name", "name_to_code" and "is_lang_code" different from "name_from_tag", "tag_from_name" and "is_ietf_tag" in Module:Lang? --Gonnym (talk) 15:57, 9 March 2020 (UTC)

The MediaWiki supported language code are a mix of standard ISO 639 codes as some codes that someone made up for use as second-level domain names

{{#language:simple|{{CONTENTLANGUAGE}}}} → Simple English

{{#invoke:Sandbox/trappist the monk/mw lang|name_from_code|simple}} →

{{#invoke:lang|name_from_tag |simple}} →Error: unrecognized language tag: simple

Module:lang does not and should not support these odd-ball language codes because its primary purpose is to make sure that non-English text is properly marked in the html. To do that, it should only support codes that are known to browsers and other user agents through the IANA language subtag registry; the odd-ball codes are not listed in the registry.

For the list of templates that we have been considering in this discussion, that are related to the various language versions that use these peculiar codes, {{#language:}} works fine as long as you only need language name from code but it doesn't work if you need the code from the language name or just need to know of the code is valid so that's where I see the sandbox module being useful.

—Trappist the monk (talk) 16:29, 9 March 2020 (UTC)

Possible publisher to work conversions for Monkbot task 14

Some possible additions to Monkbot task 14's publication list.

Also "Rocksound Magazine" as found in Mallory Knox, Don Broco, and probably others. – Jonesey95 (talk) 16:40, 18 March 2020 (UTC)

Macworld Magazine, MacWorld Magazine, and MacWEEK added; Rocksound Magazine not added. When I started making the list of periodicals that task 14 will recognize I settled on the requirement that the periodical name must be an en.wiki article or a redirect to an en.wiki article. By doing that, I avoid any accusations that replacements made by the bot use names that I have concocted.

—Trappist the monk (talk) 16:59, 18 March 2020 (UTC)

Fair enough. I see that the bot is running and making tons of edits. Thanks for running it. – Jonesey95 (talk) 18:27, 18 March 2020 (UTC)

note re draft for wikifauna

hi! thanks so much for your edit and for your help with the article for Wikipedia:WikiPrairie Dog. glad to have you there!!!!

by the way, I have a draft that I've been writing on some possible new wikifauna to add. if i do decide to add these, I will make sure to post a link at the talk page first. since this is a few changes at once., I want to give people a chance to comment.

anyway, would you be interested in reading this draft and letting me know what you think? any and all comments would be totally welcome. these are just some ideas to play around with.

so feel free to express any comments at all; negative or positive comments are equally welcome. just a way to have a little fun tossing some ideas around if you want. I may even add some whole new ones at some point. anyway, feel free to comment. thanks!!

• here's the link, to the draft. thanks!!
  • LINK: User:Sm8900/Wikifauna_drafts

Please ping me if you reply. thanks!! --Sm8900 (talk) 20:04, 19 March 2020 (UTC)

MonkBot

MonkBot keeps trying to change "publisher" to "work". This is incorrect per the documentation, it looks wrong, and there is no consensus for it. Please correct. Hawkeye7 (discuss) 21:29, 19 March 2020 (UTC)

Monkbot - database.motorsportmagazine.com

Hello there. Monkbot made an edit to an article I've been working on, Charles Montier. This is really impressive stuff! I have one slight possible niggle, or discussion point, as I'm not entirely sure if one set of changes the bot made is correct or not.

Motor Sport (www.motorsportmagazine.com) is indeed a magazine or, at least, the website of a magazine. However, it is arguable that database.motorsportmagazine.com is a website published by Motor Sport as it is, as the subdomain implies, a database. I imagine what's happened here is that they've built this database up using their illustrious archives (the magazine was first published in 1924!).

I think there's a case to be made for database.motorsportmagazine.com to be cited with {{Cite web}} and publisher=Motor Sport rather than {{Cite magazine}} with magazine=Motor Sport. However, as you no doubt know way more about this than me I'm happy to defer to your judgment.

Please ping me if you reply. --kingboyk (talk) 22:57, 18 March 2020 (UTC)

Bots aren't very smart. This one looks at the content of |publisher= and from that decides if it should change the name of the template and adjust the parameters used in the template. The bot does not look at |url= because that parameter is not required for any of the periodical parameters except {{cite web}} and because there can be a variety of dissimilar urls that can get the reader to the same place. Because you wrote |publisher=[[Motor Sport (magazine)|Motor Sport]], the bot thinks that you really do mean Motor Sport the magazine.

A requirement of this bot is that the value assigned to |publisher= must match the en.wiki article about the periodical or one of that article's redirects. That suggests a way around this issue for you. Your original:

{{Cite web|url=https://database.motorsportmagazine.com/database/drivers/charles-montier|publisher=[[Motor Sport (magazine)|Motor Sport]]|title=Charles Montier | Motor Sport Magazine Database}}

"Charles Montier | Motor Sport Magazine Database". Motor Sport.

Monkbot's version:

{{cite magazine|url=https://database.motorsportmagazine.com/database/drivers/charles-montier|magazine=[[Motor Sport (magazine)|Motor Sport]]|title=Charles Montier | Motor Sport Magazine Database}}

"Charles Montier | Motor Sport Magazine Database". Motor Sport.

an alternative:

{{cite web |url=https://database.motorsportmagazine.com/database/drivers/charles-montier |website=[[Motor Sport (magazine)|Motor Sport]] Database |title=Charles Montier}}

"Charles Montier". Motor Sport Database.

You will notice that I stripped the extraneous stuff from |title=; that parameter should hold only the title. Because there is more text in |website= than just the wikilink, Monkbot/task 14 will not attempt to edit this template.

—Trappist the monk (talk) 23:34, 18 March 2020 (UTC)

I think I'm going to need more coffee before I digest all this info :) In the meantime, suffice to say the title was copied directly from the HTML source; however, I do rather like your suggestion of "Charles Montier". Motor Sport Database..

To the coffee machine! --kingboyk (talk) 00:33, 19 March 2020 (UTC)

On reflection, citing the db as a magazine isn't the end of the world and the time it would take me to manually change all 11 occurrences in the article mentioned, and any occurrences in the other affected articles I have watchlisted, would be wasted. Likewise, it would not be a good use of your time to modify the bot to look at the url parameter and check for this particular case. Will leave as is. Thank you for your amazing bot and for the detailed reply. --kingboyk (talk) 01:07, 19 March 2020 (UTC)

There's a simple rule of thumb here that the bot can follow: if it looks like a URL (eg. motorsportmagazine.com) then - and only then - website is appropriate. Otherwise, it should be using publisher.

This is okay:

{{cite web |url=https://database.motorsportmagazine.com/database/drivers/charles-montier |website =database.motorsportmagazine.com |title=Charles Montier}}

This is wrong:

{{cite web |url=https://database.motorsportmagazine.com/database/drivers/charles-montier |website=[[Motor Sport (magazine)|Motor Sport]] Database |title=Charles Montier}}

Hawkeye7 (discuss) 21:34, 19 March 2020 (UTC)

Appology

I'm sorry if error reports weren't wanted, I've deleted the report. Please keep up the good work and ignore a still relatively junior editor. Once again sorry for wasting your time. Martin of Sheffield (talk) 23:16, 21 March 2020 (UTC)

Do not apologize for that false positive report. I want to know if the code is broken. Yeah, I know I suck at writing documentation but since you complained, I didn't know if you had read the help text and found it wanting; so I asked. I will restore your trouble report because my reply to a non-existent post doesn't make sense to other readers without it.

—Trappist the monk (talk) 23:26, 21 March 2020 (UTC)

Please stop removing orig-year, publication-place and location information from citations

Hi Trappist, I recently ran into a number of edits (like this: [5]) where you removed the contents of the |orig-year= parameter and changed |publication-place= into |location=, thereby removing the former contents of the latter parameter, although both can exist at the same time (per documentation). You are thereby significantly reducing the value of the affected citations and hindering further research. This is really annoying, please stop it.

I know that the parameter names (and the context-sensitive double-usage of the |location= parameter for different types of information) are somewhat unfortunate, however, this is long established and documented practise. I proposed several times to change the parameter names to something better (f.e. |orig-date= and |written-location=), and I would also support displaying the location information in a less prominent location in the templates' output. However, there is no consensus to remove it.

Also, I saw you removing the |url-status=, |archive-url= and |archive-date= parameters, apparently because the url was pointing to Google Books. However, links to Google Books cannot be considered permanent identifier links, therefore, it is better to have them archived as well. It is counter-productive to remove this information. --Matthiaspaul (talk) 20:39, 24 March 2020 (UTC)

So why did I:

• delete |orig-year=1978-11-05? If this really is |edition=1st printing, 1st and the publication |date=1979 then |orig-year= is meaningless or confusing.
• delete |location=[[University of North Carolina at Chapel Hill]]? Where the book was written, does not help a reader locate a copy of the source so inhibits a clear understanding of the citation.
• change |publication-place=Potomac, Maryland, USA to |location=Potomac, Maryland? Naming the country of publication is only necessary when city disambiguation can't be accomplished with county or state.
• delete |url-status=live |archive-url=https://web.archive.org/web/20200320183710/https://books.google.de/books?id=x84mAAAAMAAJ&redir_esc=y |archive-date=2020-03-20? The archived url, https://books.google.de/, is different from the url in |url=https://books.google.com/books?id=x84mAAAAMAAJ. Also, neither the live url nor the archived url link to a copy of the book that readers can read so these urls are pointless. Because I deleted |archive-url=, I deleted |archive-date= which requires |archive-url= and I deleted |url-status= because it is meaningless without |archive-url=. I should also have deleted |url= because it does not link readers to a copy of the book that they can read and |access-date= because it requires |url=.

Yes I know that cs1|2 supports the simultaneous existence of |publication-place= and one of |location= and |place=. This mechanism was created for news articles so that datelines could be included; this is recognized somewhat in the template documentation. To find a copy of a book, the general reader doesn't need to know about datelines or where that book was written. In some of the citation templates I've fixed, |location= or |place= appear to have been used merely as a way to name the author's employer; again, information not needed to help a reader locate a copy of the source.

Yep, I know that you proposed alternate parameter names to accommodate what you think are citation essentials. You did it a WT:CS1. You did not get any support for that proposal. As I read the whole of that conversation and its predecessor, you will say I'm biased and I will agree with you, I get the sense from participants in those conversations that cs1|2 support for |publication-place= with one of |location= and |place= should be discontinued and all three of those parameters should become equal aliases. The place to persuade others to your way of thinking is at Help talk:Citation Style 1 § publication-place, place, or location and their proper use (cont.), not here in the fetid backwater that is my talk page.

—Trappist the monk (talk) 00:09, 25 March 2020 (UTC)

CE1913 template

Your recent edits to the CE1913 template have broken it, please check it out and fix it. many thanks Wayne Jayes (talk) 07:08, 7 April 2020 (UTC)

I realize that you are angry, but that anger doesn't help me to check it out and fix it. Can you give an example in an article someplace and say a little bit about how it is broken?

—Trappist the monk (talk) 07:37, 7 April 2020 (UTC)

I'm not angry, just stating facts. On the page Original Sin the link to the CE1913 template {{cite CE1913|wstitle=Original Sin|volume=11}} gives this hyperlink. https://en.wikisource.org/wiki/Wikisource:Catholic_Encyclopedia_(1913)/Original_Sin The link should be https://en.wikisource.org/wiki/Catholic_Encyclopedia_(1913)/Original_Sin Wayne Jayes (talk) 08:32, 7 April 2020 (UTC)

Fixed, I think:

{{cite CE1913|wstitle=Original Sin|volume=11}}

Herbermann, Charles, ed. (1911). "Original Sin" . Catholic Encyclopedia. Vol. 11. New York: Robert Appleton Company.

—Trappist the monk (talk) 10:16, 7 April 2020 (UTC)

Thank you, yes fixed, much appreciated Wayne Jayes (talk) 09:37, 8 April 2020 (UTC)