User talk:Trappist the monk/Archive 8

Localization of the CS1 input and output numbers

Hi. I am trying to adapt CS1 module for use in fawiki and with Farsi numerals, so that it can work with both Farsi and English numbers as input, and outputs the numbers (such as ISBN) in Farsi numerals. I tried replacing the local_digits in CS1/Configurations, but it does not work (returns errors). Is there any built-in feature in the module for doing this? Thanks. Mensis Mirabilis (talk) 21:48, 29 December 2018 (UTC)

It looks like you have a recent version of ~/Configuration but a not-so-recent version of ~/Date validation. Nothing should be expected to work when the modules aren't all from the same version. The current version of ~/Date validation at en.wiki does the digit translation that fa:~/Date validation does not do. So, I would recommend that you import ALL of the cs1 modules to their equivalent sandboxen from the live versions at en.wiki. Since you appear to have a current copy of ~/Configuration which you have modified keep that one. If all goes well, you should not need to edit any other of the cs1 module suite. Try that and report back if you are still seeing date problems. At the present time there is not support for the numeric identifiers like ISBN (you are the first to have noted a need for that) so I'll have to think about how to do that. Dates first.

—Trappist the monk (talk) 23:01, 29 December 2018 (UTC)

It occurs to me to wonder if fa:Special:BookSources works with Farsi numerals. Does it? Part of the reason that there is an ISBN error on fa:کاربر:Mensis_Mirabilis/صفحه_تمرین is because there are only 9 digits; ISBN must 10 or 13 digits.

—Trappist the monk (talk) 00:26, 30 December 2018 (UTC)

I updated ~/Date validation and it seems to work with Farsi dates now. But the problem with ISBNs remains. As can be seen in the examples I put in my sandbox, The current fawiki citation template accepts both Farsi and English numbers as input, returns a converted (to English) string to fa:Special:BookSources while always printing a Farsi string in the final output citation text. Since this kind of en->fa/fa->en number conversion occurs too often, we have a module for it and do the conversion using it when importing modules for localization. (Another issue is that CS1 should print ISBN LTR not RTL, because numbers are always read LTR even in RTL languages.) Mensis Mirabilis (talk) 05:04, 30 December 2018 (UTC)

Updating just the one module is not sufficient. You should be able to provoke a date error message by setting |date= to some non-date value. That is not working. When I wrote: import ALL of the cs1 modules I meant that. cs1 will not work correctly until you do. cs1 now uses WP:TemplateStyles so you must also have a copy of Module:Citation/CS1/styles.css.

—Trappist the monk (talk) 10:50, 30 December 2018 (UTC)

OK, I updated the whole module (located here). The |date= parameter is OK (yields error for invalid dates) but ISBN is not; see my sandbox. Thanks. Mensis Mirabilis (talk) 14:16, 30 December 2018 (UTC)

I think that ISBN is now working but I can't know for sure because the ISBN check digit scheme works when the number is written ltr and when written rtl:

ISBN 2-7451-3449-3

ISBN 3-9443-1547-2

Clicking on the ISBN links from your sandbox all link to fa:Special:BookSources/2-7451-3449-3. Is that where cs1 should link?

—Trappist the monk (talk) 15:15, 30 December 2018 (UTC)

Yes, that's the correct ISBN. Thanks a lot. Now the only (minor) issue is the order of the blocks of numbers (between dashes) of the ISBN. You can see this in the 2nd citation in my sandbox: it reads "3-3449-7451-2" instead of the correct "2-7451-3449-3" (it doesn't affect the Special:BookSources search though, and appears correctly there). Mensis Mirabilis (talk) 15:32, 30 December 2018 (UTC)2-7451-3449-3

I suspect that the reversed ISBN is a browser issue. When in this editing window I paste on a new line this: 'صفحه_تمرین' (because it's convenient to do so) and then paste '2-7451-3449-3' at the right end of it, the browser, reversed the ISBN and places it at the left end of the Farsi text. If I do the same thing with just a four-digit number (no hyphens) the digit order is not reversed and the four-digit number is also placed at the left end of the Farsi text. So, the browser is treating a hyphenated string of digits as a string of characters and not as a 'number'. The obvious simple solution is to wrap the displayed ISBN string in <bdi>...</bdi>. But, before I do that, what about other right-to-left scripts: Arabic, Hebrew, ... Do they all render numbers left-to-right? Is ISBN a 'number' or a string of characters? Is the way that fa.wiki currently renders ISBNs using the old template actually the correct way that Farsi ISBNs should be rendered?

—Trappist the monk (talk) 16:24, 30 December 2018 (UTC)

Yes, that is exactly how ISBNs appear in printed books. They should be treated as numbers, as they are sometimes entered/displayed without hyphens (Special:BookSources works with hyphens removed too). And it has to be the same in other rtl languages and ISBNs should appear as numbers, with the firstly entered block of the ISBN appearing at the left side of the final displayed ISBN, even though it appears at the right side of the text being entered in the editor console, because of the rtl environment. (I can also ask my friend @Huji: who has much more experience dealing with rtl issues to leave a comment on this) Mensis Mirabilis (talk) 17:35, 30 December 2018 (UTC)

Without having looked at the code here, I can just tell you that ISBN numeric part should be preceded with a ‎ so the output is LTR. We do it already in fa:Template:ISBN, which also links to the correct page so use that as a model. huji—TALK 17:43, 30 December 2018 (UTC)

Hebrew and Arabic also read numbers left to right. --Gonnym (talk) 17:51, 30 December 2018 (UTC)

I have wrapped the wikilink display in <bdi>...</bdi> tags for the nonce. Should probably move that into presentation section of ~/Configuration because it is presentation. What about the other identifiers especially those like |doi= that can be pretty much anything? Identifiers like |pmc= and |pmid= are always numeric so should not be at issue.

—Trappist the monk (talk) 18:25, 30 December 2018 (UTC)

I tried several doi strings and apparently it's OK. One issue is determining whether to use English or Farsi numerals to display numbers. In the current citation template in fawiki there is a parameter lang that if left blank all numbers in the citation will be displayed in local digits (even if input numbers are in en), and if set to anything else (such as en), all numbers will be displayed in English numerals irrespective of the Farsi or English input numbers. Is it straightforward to implement this for all numeric outputs of CS1, such as dates, pages, volumes, and others? (If not, I think there some other ways to do this outside the CS1 module.) Thanks for your time. Mensis Mirabilis (talk) 20:15, 30 December 2018 (UTC)

Sorry for the delay, I was distracted by other matters.

I suppose some sort of feature could be devised (|lang= is already taken up as an alias of |language=); the module suite will do simple month name translation so translating digits would certainly seem possible. Is such a feature truly needed? Does fa.wiki offer multiple language versions of articles? Do other fa.wiki templates do this thing as standard practice?

—Trappist the monk (talk) 10:19, 1 January 2019 (UTC)

The convention in fawiki is to always use English digits for foreign-language citations, equations, and texts and always use Farsi numbers anywhere else (see this for example). That is why we already have a copy of CS1 module (with a /en prefix) for English citation templates, but for Farsi citation templates still the old core template is used. But implementing this in CS1 is not really necessary (if doing so can cause too much trouble); for Farsi citation templates I can simply use another wrapper template and convert input numbers using {{formatnum:}} before feeding them into CS1. (assuming CS1 works with Farsi digits in any of its numeric inputs)Mensis Mirabilis (talk) 13:23, 1 January 2019 (UTC)

That seems a consistency-maintenance headache (Gropp & Shahbazi refs at your example page) but to each its own. If this is something that many wikis do I would be more inclined to support it. It doesn't seem worth the effort to do the work that will not be used anywhere else – I don't like special case code.

Module:template wrapper might be useful to you.

—Trappist the monk (talk) 13:45, 1 January 2019 (UTC)

Thanks, it is indeed very useful. But one problem with it is that since in Farsi citation templates, enumerated parameters use Farsi digits for enumeration, when setting enumerated parameters like زبان#:lang# in |_alias-map=, template wrapper does not recognize Farsi enumerated parameters, which ultimately leads to an error in CS1. Is there any way to convert all the digits in the input parameter names in fa:module:template wrapper to English? We normally do these conversions for a string by including fa:module:Numeral converter in a module (local convert = require( "Module:Numeral converter" ).convert) and convert("en", string, but not sure how it can be done here. Mensis Mirabilis (talk) 19:14, 2 January 2019 (UTC)

It appears that you have a solution of sorts. It is very difficult for me to make sense of mixed ltr / rtl like appears in fa:الگو:Cite book/fa. If your cs1 modules fa:Module:Citation/CS1/en/Configuration and fa:Module:Citation/CS1/en/Whitelist are configured correctly, there should be no need for |_reuse= in Cite book/fa because the cs1 module will handle the aliasing. Of course that won't work with fa digits so a possible solution to that is to add local convert = require ("Module:Numeral converter").convert at the top of fa:Module:template wrapper and then in _main() change this:

for k, v in pairs (_pframe_args) do						-- make a copy that we can modify
	pframe_args[k] = v;
end

to something perhaps like this:

for k, v in pairs (_pframe_args) do						-- make a copy that we can modify
	k = convert ('en', k);								-- convert local digits to western digits
	pframe_args[k] = v;
end

Does that work?

—Trappist the monk (talk) 23:01, 2 January 2019 (UTC)

Thanks, I will try it now. Besides the above issue (which I avoided by explicitly entering the enumerated parameters), one more important issue is that when a date is given in the form "2 January 2019", the name of the month (here "January") should be replaced with the equivalent local name based on the settings in ~/Configuration. Also various date strings should be put in bdi tags similar to what you did for the identifiers (see the first example on my sandbox). And lastly, there is a , appearing between editor's name and the word "editor", that is not replaced by its equivalent separator (،) given in ~\Configuration. (see the second example on my sandbox). I think these are all that should be done to make CS1 compatible with fa and other rtl wikis. Thanks a lot. (the cs1 module that I'm working with is located at fa:module:Citation/CS1/en/sandbox) Mensis Mirabilis (talk) 23:35, 2 January 2019 (UTC)

Is date_name_xlate() commented out in fa:Module:Citation/CS1/en?

—Trappist the monk (talk) 00:05, 3 January 2019 (UTC)

uncommented now and the months are translated and also the ltr issue for date is resolved. Thanks a lot. (But for some reason, the digits are now shown using western digits even if I feed Farsi digits into the citation!) Mensis Mirabilis (talk) 00:30, 3 January 2019 (UTC)

The comment there says:

-- set date_name_xlate() second argument to true to translate English digits to local digits (will translate ymd dates)

Are digits are not translated regardless of the setting of the second argument?

—Trappist the monk (talk) 02:17, 3 January 2019 (UTC)

Facing an issue related to a module

In the file [styles.css], please check why there is an error in line 1. In malayalam wikipedia, the English source file was copied as it is.Adithyak1997 (talk) 06:55, 3 January 2019 (UTC)

You must get an administrator to change the page content model to sanitized css. See mw:Help:ChangeContentModel.

—Trappist the monk (talk) 09:34, 3 January 2019 (UTC)

Need fresh eyes

Hey, I saw you updated the module, I'll test it out shortly. I have a small bug that is driving me crazy that I was hoping fresh eyes might help me.

I have an "args" table that has two optional values - args.EpisodeNumber2 and args.Serial. I have a need for an if check where it enters if Serial is empty and EpisodeNumber2 is not.

Since Module:Arguments is told to not remove blank variables, I have a utility function that checks if it has any value:

local function hasValue(param)
	if (param ~= nil and param ~= "") then
		return true
	else
		return false
	end
end

Checking each one alone, gives me the correct result. Checking them with

return (args.Serial ~= nil and args.Serial ~= "") == false and (args.EpisodeNumber2 ~= nil and args.EpisodeNumber2 ~= "")

also gives me the correct result. But checking them with

return (hasValue(args.Serial) == flase) and hasValue(args.EpisodeNumber2)

does not. Any idea what I'm not seeing? --Gonnym (talk) 15:19, 8 January 2019 (UTC)

Well, your module forced me to fix any global variables I missed and it helped here also by pointing the fact that I wrote "flase" and not "false". So you did help :) --Gonnym (talk) 15:47, 8 January 2019 (UTC)

(edit conflict)

In the last I presume that you mean false not flase.

hasValue() returns true or false. false == false returns true. Isn't what you want something like:

return not hasValue(args.Serial) and hasValue(args.EpisodeNumber2)

not false (args.Serial not set) returns true so when args.EpisodeNumber2 is set true and true returns true

—Trappist the monk (talk) 15:56, 8 January 2019 (UTC)

Yeah, your style is probably better semantic, but I'm pretty sure it was just my stupid typo there causing my errors. I tried doing something which wrecked tons of havoc in my code and after hours of writing code I can't even see it anymore, so it's time to take a break and start fresh tomorrow :) --Gonnym (talk) 19:43, 8 January 2019 (UTC)

Could use your help again. Module:Sandbox/Gonnym/sometest3 is used to create a row. On example #23 at User:Gonnym/sandbox I'm using it to also create a rowspan-ed row. I've managed to make it work, but I'm having a color style visual bug. Every time I try and add any style to the new row, it messes up the entire row. The initial row is created at _main() on line 620 and the relevant color is "TopColor". When I need to create new "sub" rows, I do that at createMultiRowCells() on line 520, but anything other than "tr" messes it and the scope goes crazy. Did I need use the correct method to create rows? Or is there something else? --Gonnym (talk) 16:51, 9 January 2019 (UTC)

I have never used the scrubuntu html library so I may not be of much help. Perhaps others have done tables with rowspan cell so maybe spend some time trolling modules that specifically mention rowspan. This search.

And I'm in the middle of trying to get my first lua replacement of infobox chinese to do the right thing. Some of it is and some of it isn't and that's making my head hurt.

—Trappist the monk (talk) 17:09, 9 January 2019 (UTC)

Thanks for the link, I'll check it out! Yeah, I know the feeling. Yesterday night I went crazy until I just left it alone and came back to it today and suddenly code started working. --Gonnym (talk) 17:12, 9 January 2019 (UTC)

A barnstar for you!

	The Brilliant Idea Barnstar
	Dual barnstar, for your technical contributions to language infoboxes on Wikipedia. Thanks for converting the complex Chinese language infobox into lua. And brilliant idea to create Module:Infobox multi-lingual name which may play a much larger role here in the future. Tom (LT) (talk) 01:11, 13 January 2019 (UTC)

Cite repairs question

Hi, Trappist the monk. I saw your recent cite repair update on José Manuel Garza Rendón's page regarding URL subscriptions. What's the difference between having subscription=yes and url-access=subscription? Also, is there a way I can run a script to fix this in other articles? I've used subscription=yes for many years. MX (✉ • ✎) 14:40, 18 January 2019 (UTC)

Compare these:

Barajas, Abel (8 June 2001). "Operador en Matamoros". Reforma (in Spanish). Mexico City: Infoshare Communications Inc. {{cite news}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

Barajas, Abel (8 June 2001). "Operador en Matamoros". Reforma (in Spanish). Mexico City: Infoshare Communications Inc.

The obvious difference of the subscription-required indicator at the link that is behind the paywall is more useful than the text version where that annotation is some reading distance from the linked title. Editors do use |subscription=yes to indicate that external links created by the named identifiers are behind paywalls. In the days before the access icons, it was not possible for a reader to determine if the subscription annotation applied to the |url=-linked title or to one or more of the named identifiers. Now that we have the access icons, that ambiguity disappears; in cs1|2, |url=-linked titles are always presumed to be free-to read unless otherwise marked and, similarly, all named identifiers are presumed to be behind paywalls unless otherwise marked.

—Trappist the monk (talk) 15:02, 18 January 2019 (UTC)

Got it. Thank you for the explanation. I'll use the icon option moving forward. Is there a script I can run to fix this at once in other articles, instead of doing it manually? MX (✉ • ✎) 15:22, 18 January 2019 (UTC)

I don't know of any particular script that does that. I think that such a script would be problematic because editors may have used |subscription=yes to mark named identifier links. Still, if you are using the wikitext editor (not ve) you can use the search and replace function from the Advance menu (magnifying glass icon at far right):

Search for: \| *subscription *= *yes

Replace with: |url-access=subscription

check the box at Treat search string as a regular expression

—Trappist the monk (talk) 15:43, 18 January 2019 (UTC)

Major issue with Template:Infobox Chinese output

Your recent edit to this template has caused a major issue that needs fixing ASAP, if necessary by undoing your edit:

Where multiple Chinese names are given in the infobox and a showflag is selected, the first name is shown multiple times instead of each name being shown once. See Zisi, Confucius, and Sun Tzu for examples. Scriptions (talk) 23:43, 22 January 2019 (UTC)

I don't think that I have broken {{Infobox Chinese}}. I think that you can prove this to yourself by doing this simple experiment:

1. Copy one of these article names to your clipboard: Zisi, Confucius, or Sun Tzu
2. Click this link (opens the last pre-Lua version of {{Infobox Chinese}} in edit mode)
3. paste the article name that you copied at step 1 into the Preview page with this template text box (bottom of the screen)
4. click the adjacent Show preview (not the one between Publish and Show changes)
5. inspect the rendering of {{Infobox Chinese}}

I think that you will see that the rendering produced by this legacy version of {{Infobox Chinese}} is a very close if not exact match to the new Lua version rendering (that close match was the intent of the first version of the module). I agree that transcription elements that have been made visible in the infobox by |showflag= should not also be repeated in the collapsed transcription child infobox. It is on my todo list for this template/modules to fix that (among a bunch of other things – list to come sometime after I return from wikibreak).

—Trappist the monk (talk) 00:26, 23 January 2019 (UTC)

I've checked how the infoboxes appear on multiple computers in multiple locations and the issue is the same everywhere, so yes, you have definitely broken the template. For example, in the article Zisi, Zǐsī used to appear under the headline ‘Courtesy name’ and Kǒng Jí under the headline ‘Personal name’, but now Zǐsī appears under both headlines, making it seem like Zǐsī is the personal name.

This is not some minor issue that can wait until you're back from your wikibreak. Articles are effectively providing incorrect information. You either have to fix this issue now or undo your edits until such time as it can be fixed. Scriptions (talk) 01:00, 23 January 2019 (UTC)

I think that I have fixed it – the change will take time to propagate to all affected articles; null edit is your friend. Where showflag renders redundant elements is not fixed.

—Trappist the monk (talk) 01:46, 23 January 2019 (UTC)

Module:Extract short description issue

Hey Trappist, I just noticed an issue with Module:Television episode disambiguation description or Module:Extract short description and I don't know how to solve it. When I placed the short description on a mainspace article with Module:Television episode disambiguation description, the short description text was also set as the short description of the article. When I invoked Module:Extract short description directly ({{#invoke:Extract short description|extract_short_description) it did not do that. Any idea? --Gonnym (talk) 11:17, 22 January 2019 (UTC)

A difference I noticed in two functions are:

local function extract_from_template()
text = frame:preprocess (text):match ('<div[^>]-class="shortdescription.->(.-)</div>');		-- preprocess and extract shortdescription text

local function extract_from_article
text = text:match ('^[^|}]+|%s*(.+)%s*}}$');

Could this difference be it? --Gonnym (talk) 11:39, 22 January 2019 (UTC)

Where did you do this so that I can see what it is that you see?

—Trappist the monk (talk) 12:42, 22 January 2019 (UTC)

I high-jacked This Is Your Sword to test this. But we can test it on the test page you created for us back then (forgot its name). --Gonnym (talk) 13:03, 22 January 2019 (UTC)

From your series of edits:

{{Television episode disambiguation description|name=This Is Your Sword (Arrow) }} returns:

"This Is Your Sword" (Arrow), 22nd episode of the third season of Arrow

{{#invoke:Extract short description|extract_short_description|Oliver Queen (Arrowverse)}} returns

fictional character in a television series

Oliver Queen (Arrowverse) has this:

{{short description|fictional character in a television series}}

{{#invoke:Extract short description|extract_short_description|This Is Your Sword (Arrow)|Television episode short description}} returns

22nd episode of the third season of Arrow

Article title This Is Your Sword (Arrow) when wikilinked is a redirect that has:

{{Television episode short description|episode_num=22 |season_num=3 |series_name=Arrow}} which gives:

<div class="shortdescription nomobile noexcerpt noprint searchaux" style="display:none">22nd episode of the third season of <i>Arrow</i></div>

Are these not the correct return values? If not, which is wrong? Why is it wrong?

—Trappist the monk (talk) 14:30, 22 January 2019 (UTC)

The text is correct, the problem is that extract_from_template() causes the page to also use the text as a short description, which should not be the case. It should just be plain text. --Gonnym (talk) 15:28, 22 January 2019 (UTC)

I'm still confused. What page? Did this not used to work? Nothing has changed at Module:Extract short description since 11 October 2018 so that suggests (assuming that it ever worked properly – and you are the one who would have made that determination) that something else somewhere else has changed.

—Trappist the monk (talk) 19:47, 22 January 2019 (UTC)

I'm really not sure how to explain this again, could you at least tell me what you are confused about so I can try and explain that part differently? Your module has two access points - they do not work the same. Both output a valid text, but one ALSO has it wrapped (I think) in a short description template, which is not what is expected. This might have always been around and I've just not noticed it as I haven't rapidly implemented yet. It does not matter what page. Please create for us the test page we used to work on and I'll show you the output, or just revert the page I've tested on and see the results yourself. Could you at least explain why there is a difference in the code above? --Gonnym (talk) 19:55, 22 January 2019 (UTC)

The purpose of extract_from_template() is to find and extract article short description that is provided by {{Television episode short description}}. It does this by preprocessing {{Television episode short description}} which template uses the parameters provided to it by the article. extract_from_template() then searches the result to find the short description html. The purpose of extract_from_article() find and extract article short description that is provided by a {{short description}}. This is a simpler task because the short description exists as plain-text in the template call. An undesirable artifact of the former is that it, apparently, applies short description to a dab page when Module:Extract short description is {{#invoke:}}'d from that dab page.

I looked at where Module:Extract short description is used in mainspace. All of them are dab pages that use {{Television episode disambiguation description}} and all have inappropriate short descriptions.

Module:Extract short description has not changed since 11 October 2018; Module:Television episode disambiguation description has not changed since 28 November 2018. Were these modules working at that time? If yes, what has changed?

—Trappist the monk (talk) 12:30, 23 January 2019 (UTC)

It might have always been like this and I've failed to notice this. The short description used has |noreplace= which means that if another page has a short description set, this doesn't show. Maybe the pages I've checked had that, could be also that I maybe checked this on non-mainspace pages and it could be also that I just didn't notice. Do you think this issue is solvable? --Gonnym (talk) 13:39, 23 January 2019 (UTC)

Another optional method - can an infobox have a hidden text field? If so, do you think this could be a good idea, to set the short description text here (in addition to the current process), then when we want to extract, we just need to extract template.parameter instead of template.template.text? --Gonnym (talk) 13:43, 23 January 2019 (UTC)

Is a fixed row number template possible?

Hello. Thanks for creating Template:Row numbers.

Please see: Help:Sorting#Adding row numbers with Template:Row numbers

The only problem is that they are not static row numbers. They can only rank one column. When other columns in the table are sorted, those columns are not ranked or freshly row numbered.

Note the section before it:

• Help:Sorting#Auto-ranking or adding a row numbering column (1,2,3) next to a table

It used a fixed row number column. But it is very unwieldy, and will only work consistently with narrow tables.

It would be wonderful if there could be a Template:Fixed row numbers. See also: phab:T42618. -- Timeshifter (talk) 23:58, 22 January 2019 (UTC)

I don't think that it is possible with {{row numbers}} to 'fix' the numbers so that they remain constant while the other rows in the table are sorted unless that functionality is made part of the java script that does the actual sorting. {{row numbers}} operates on the table only during the page publication process so cannot be made dynamic like the java script sorter. It would seem that class=fixed at the top of a column (and the code to support it) would be necessary in order to do what it is that you want done.

—Trappist the monk (talk) 01:00, 23 January 2019 (UTC)

Thanks. I don't understand this stuff. But there are various methods discussed within this thread: phab:T42618. Some of which work now, but haven't been finalized into a template like yours. -- Timeshifter (talk) 02:44, 24 January 2019 (UTC)

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

The 2018 Cure Award

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

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

Question

Hi, could you remind me why we switched from <br> to <br /> in infoboxes? And are we still doing that? Thanks - wolf 22:01, 25 January 2019 (UTC)

We didn't. We switched away from both of those to proper list markup. See Template:Infobox ship begin/Usage guide#Diverse stylistic issues and Category:WPSHIPS:Infobox list errors.

Give an example of where you think we have made a declaration regarding <br> and <br />? Both are valid html but the latter works with a commonly used wiki syntax highlighter while the former does not so using <br /> is a courtesy for editors who use that highlighter (Editing→Syntax Highlighter).

—Trappist the monk (talk) 15:38, 26 January 2019 (UTC)

I happened to notice this thread since I am in the thread above it. <br /> is something I dislike. I have had to revert people adding it to pages such as at Help:Sorting. Sometimes they tried to replace many examples of <br>. A help page is supposed to make things easier for editors.

So I suggest doing whatever is necessary to fix any cases where somehow <br /> is felt necessary. -- Timeshifter (talk) 22:42, 26 January 2019 (UTC)

If your sole reason for changing <br /> to <br> is because you dislike <br />, then you should probably stop doing that (both are acceptable in html5). In general these kinds of changes that have no effect on the rendered page that readers see should be avoided. I agree that the handling of certain html tags – <br> and <p> among them – should be tweaked in the Editing→Syntax Highlighter. Going the other way (<br> to <br />) prevents a single <br> from painting an entire edit window pink and thus masking possible syntax errors caused by improperly closed html markup.

—Trappist the monk (talk) 17:54, 4 February 2019 (UTC)

@Ttm - ::That's just it, I don't have an example. I see both used, but I seem to recall something awhile back where it was requested that <br /> be used instead of <br>, but I don't recall where or why and so I thought I'd ask you as you are usually familiar with this stuff. As you say, one works with a commonly used syntax while the other doesn't, so I would suppose it had something to do with that. But I also recently noted someone actively changing all instances of <br /> to <br> in an infobox, with no reason given. I wasn't sure if this was appropriate so that is what prompted my question in the first place. Cheers - wolf 00:55, 27 January 2019 (UTC)

There are accessibility rules that are violated if lists in infoboxen are created with <br /> tags. While these lists look ok to those of us who read infobox data with our eyes, this same markup is improper for those who use screen readers. Lists must use list markup:

• unordered: * (html: <ul><li>...</li></ul>)
• ordered: # (html: <ol><li>...</li></ol>)
• definition: ;: (html: <dl><dt>term</dt><dd>definition</dd></dl>).

If the person changing <br /> to <br> in an infobox was doing it in a ship infobox, that infox has support for making plain lists from unordered list markup.

—Trappist the monk (talk) 17:54, 4 February 2019 (UTC)

No it was an "official post" infobox (this was the edit) - wolf 18:20, 4 February 2019 (UTC)

In that infobox, |member_of= would be better written as:

|member_of            = {{plainlist|
*[[Cabinet of the United States|Cabinet]]
*[[United States National Security Council|National Security Council]]}}

because that parameter contains a list of two discrete items.

—Trappist the monk (talk) 18:39, 4 February 2019 (UTC)

Module:Citation/CS1

Hello! I'm an admin at the Albanian Wikiquote. Wikiquote projects aren't as active as Wikipedia ones but I'm trying to make it an active community little by little. I've had to work with it basically from scratch and in the following months I've added the Citation/CS1 module to help with the citation process. I've modified some parts of it by removing or translating them (mostly category names and language/date terms). Since it seems to work good, these days we've started to use the modified version to our Wikipedia too. I checked all its sub-pages and saw that you were the biggest contributor to it. Would you mind taking a look at our modified version here and its sub-pages and telling me if everything is alright or not? Here are it's categories if it helps. As I said, there are some parts I've removed purposely from different sub-pages but mostly are just not updated to new changes. (I wish Wikipedia and the other projects would notify us when a corresponding Wikidata item has been edited and what has changed upon it.) I understand you'd have a hard time checking out all the sub-pages, especially in a language you don't understand so it's okay if you don't have time to do it. Thank you anyway for contributing to it, you've helped us much already! :)

PS: I've noticed some spelling errors in different pages of the module regarding the one in English. I'll try to find time to fix them in the corresponding talk pages. A little thing to repay the favor. :) - Klein Muçi (talk) 02:56, 31 January 2019 (UTC)

@Klein Muçi: If the module suite is working for as it is then great. Save me the detective work and tell me what it is that you have deleted and why. I would like the modules to be universally functional regardless of language so that the only changes required at the various language wikis are limited to parameter names and static text contained in ~/Configuration. If I know what you deleted and why you deleted it, perhaps I can re-write those sections of the code so that in future such deletion is not necessary.

—Trappist the monk (talk) 13:32, 4 February 2019 (UTC)

I understand. I don't remember with certainty what has been changed to us but for what I recall, I remember they were mostly preference changes, as in, we wanted to have it like that. For example, I know we've removed the categorization of articles using the original wiki language (English in here, Albanian in us) because we're good knowing references are in Albanian. The reason being is that 90% of our citations are in English and so we really want to know when something is in Albanian and don't consider it an error or think maintenance is needed. Another part I remember having deleted is the code related to seasons. I had difficulties in translating it and we have yet to use a citations with season values so I removed it. Maybe I readd it in the future if it is needed. As for me, I'm worried more about having the most up-to-date version of it. The many pages of it make it a little hard to know if there have been substantial changes or not but I guess I'll just have to get them in my watch pages. Another problem I had is that many times I've translated terms not really knowing if they should be translated or not. Many times they didn't have to be translated and I have had to get them back to English. (The warning about the anchor changes saved me a lot of work.) Maybe it's not the right place to ask, but since almost all the world is already using the same module for citations by now, can't it be an integrated part of MediaWiki and be activated with a single script or something? At least the most part of it. And the translation would be taken care in the Meta, like any other translation. - Klein Muçi (talk) 15:03, 4 February 2019 (UTC)

If you are worried about keeping the sq.wikipedia and sq.wikisource module suites up-to-date with en.wiki, perhaps what you should do is import the current versions of the en.wiki sandbox modules. Then, one module at a time, identify and document the changes that you need so that together we can modify the en.wiki sandbox to meet those needs and still accommodate other language wikis (also please import the module suite documentation pages so that navigation between live and sandbox modules is easier). For example, having a sandbox version will let us work out how to properly support Albanian seasons without the need to delete anything.

The cs1|2 module suite has not at all been universally adopted and where it has, it is often well behind the current en.wiki version. There is phab:T121470 which is a task to create a mechanism that would support global templates but that is apparently something that is difficult to do. And once we have that ability, how to handle preference changes, as in, we wanted to have it like that will be a significant challenge because many wikis want something slightly different from what en.wiki wants.

I don't know what you mean by 'anchor changes' when you wrote: The warning about the anchor changes saved me a lot of work.

—Trappist the monk (talk) 16:21, 4 February 2019 (UTC)

Thank you for the detailed answer! With "anchor changes" I meant the code that matches the help page accompanying the module. Search the configuration page for Anchor changes require identical changes to matching anchor in Help:CS1 errors if you don't remember. Thank you for giving the link to that task! I'll check it now. I'm aware of the (not-so) little differences there exists between different languages but all of them (don't they?) use citations in the articles with a certain style of citation. That thing could be universal and local Wikis could be allowed to personalize how they see fit. When I started working with SqQuotes I was baffled to see we couldn't actually make citations. I thought it was a ingrained thing in every wiki like turning some text into bold or creating a wikilink until I learned about the aforementioned module. As for the documentation pages and sandboxes, I'll try but unfortunately that is one example when SqWiki is behind the EnWiki one. We almost never use the sandbox and document pages in templates or modules and I don't know if I'll be able to do what you say without blindly copying code and making it work with trial and error. Anyway, these days I'll try to find time to check if the module we use is up-to-date with the one here and learn some more about what you write. If I can do correctly what you ask, I'll write to you again. - Klein Muçi (talk) 16:57, 4 February 2019 (UTC)

While I check what I said earlier, can you help me with something? Languages that are the same as the local wiki are not categorized. As I mentioned earlier, we want to change this so we can know how many articles actually use Albanian language sources and compare it with articles which use English language sources. How can I edit the module so it also recognizes the local language like it does with all the other ones? - Klein Muçi (talk) 00:59, 5 February 2019 (UTC)

Languages that are the same as the local wiki are not categorized refers to |language=sq or |language=albanian. The module only knows the language of a source when editors specify it using |language=. As long as you understand that, it should be relatively easy to add a configuration flag to allow categorization when |language= refers to the local wiki's language. Before we do that, please import the en.wiki sandbox modules so that we are working with the most up-to-date code set – it can be painful to switch between current and obsolete versions.

—Trappist the monk (talk) 01:33, 5 February 2019 (UTC)

Displaying quotation mark in citation title

Thanks for checking that! I reproduced the issue I was facing. On checking the old citation further, I noticed that an editor had used two apostrophes to represent a quotation mark in the title: https://wiki.riteme.site/w/index.php?title=Leiomano&action=edit&oldid=878330177

Since I hadn't modified the title when I updated the citation, the title displayed incorrectly every time I clicked on the "Show preview" button. Do you think that this is a common enough error to include a row on the help page table telling people to replace a double-apostrophe with a quotation mark? --JECE (talk) 17:18, 14 February 2019 (UTC)

Probably not. Perhaps it was the original editors intent to have the reference render with italics for that portion of the title. Who knows? We can't and shouldn't create help text for every misuse of punctuation / wiki-markup.

—Trappist the monk (talk) 00:38, 15 February 2019 (UTC)

Well that wasn't the original author's intent. The source clearly shows quotation marks in its title in the same places.--JECE (talk) 04:20, 15 February 2019 (UTC)

Template:Sclass

Hey, in 2012 you created Template:Sclass-. Does that template handle Template:Sclass and Template:Sclass2 completely? Asking as I'd like to nominate them at TfD so they can be officially added to the Holding Cell and be redirected/deleted. --Gonnym (talk) 08:35, 22 February 2019 (UTC)

{{sclass-}} has nothing to do with {{sclass}} or {{sclass2}}. The common code shared among these three, and {{sclass2-}}, is {{sclass/core}}. In the olden days, ship class articles were not hyphenated. At some point WP:SHIPS determined that ship class names should be hyphenated. {{sclass-}} and {{sclass2-}} were created to facilitate the transition from unhyphenated to hyphenated article names at which point {{sclass}} and {{sclass2}} could go away, {{sclass-}} and {{sclass2-}} could be renamed to {{sclass}} and {{sclass2}}, and the articles that use these templates updated accordingly.

—Trappist the monk (talk) 11:32, 22 February 2019 (UTC)

I see, but if {{sclass-}} has nothing to do with {{sclass}}, why does the documentation say to use it instead? --Gonnym (talk) 11:47, 22 February 2019 (UTC)

{{sclass|Natick|tugboat}} → [[Natick-class tugboat|''Natick''-class]] [[tugboat]] → Natick-class tugboat – [[Natick class tugboat]] is a redirect

{{Sclass|Natick|tugboat}} → [[Natick-class tugboat|''Natick''-class]] [[tugboat]] → Natick-class tugboat – [[Natick-class tugboat]] is the article link

Because most or all ship-class article-titles are now hyphenated (Natick-class tugboat) the proper template to use to link to these articles is {{sclass-}} which produces the correct hyphenated article title link. {{sclass}} can be used because it will get you to the article when there is a redirect (unhyphenated redirects may, or may not, exist).

—Trappist the monk (talk) 12:09, 22 February 2019 (UTC)

Template:Template parameter doc

Could you please explain to me what that template is trying to do? {{3x|p}}ery (talk) 03:02, 23 February 2019 (UTC)

Because that abomination that is ve requires templates to have two separate, redundant, yet wholly incompatible sets of documentation (whoever thought that was a good idea?), this template and its attendant module were experiments to explore the how one might create some sort of documentation format that would hold raw documentation data using complete wiki syntax to be formatted prettily for the template's doc page and from that same source, create ve-compatible TemplateData (stripped of wikimarkup and templates, etc). Discussion

—Trappist the monk (talk) 11:10, 23 February 2019 (UTC)

Seems to me to be redundant to Template:Format TemplateData. {{3x|p}}ery (talk) 15:14, 23 February 2019 (UTC)

Defining a new Ref parameter for CS1

Hi. I'm trying to add a second |Ref= parameter (|Ref2=) for CS1, which if passed to the cite templates, will be concatenated to the existing anchor that is generated when ref=harv is set. I tried defining Ref2 in ~/Configuration and in ~/Whitelist, and concatenated Ref2 after the anchor in the main module too. But still it does not even recognize Ref2 as a parameter, let alone generating an anchor concatanted with it. Is there anything else that I need to do? Mensis Mirabilis (talk) 14:28, 8 March 2019 (UTC)

After you realized that this:

local Ref2;
sepc, PostScript, Ref, Ref2 = set_style (Mode:lower(), A['PostScript'], A['Ref'], A['Ref2'], config.CitationClass);

sets Ref2 to nil, you rewrote to this:

local Ref2 = A['Ref2'];
sepc, PostScript, Ref = set_style (Mode:lower(), A['PostScript'], A['Ref'], config.CitationClass);

Does it still not work?

How are you testing this?

—Trappist the monk (talk) 15:06, 8 March 2019 (UTC)

I also defined Ref2 in the correct place in ~/Whitelist and the module now accepts it as a parameter. But it seems the anchor is not modified. I am testing it here where the inline citation template generates a "CITEREFDoe1397XYZ" (appends a "XYZ" to the "CITEREFDoe1397"), but it is not linked to cite book even though I have set Ref2=XYZ. Mensis Mirabilis (talk) 15:20, 8 March 2019 (UTC)

What is it to be? |Ref2= or |ref2=? cs1|2 prefers lowercase parameter names. In ~/Whitelist you specify |Ref2=; in ~/Configuration you specify |ref2=. These must agree. The concatenation is not happening because A['Ref2'] is an empty string.

—Trappist the monk (talk) 16:03, 8 March 2019 (UTC)

Yes, A['Ref2'] was empty, and it is resolved now by changing ['Ref2'] = {'ref2','ش'} to ['Ref2'] = {'Ref2','ش'} in ~/Configuration. Thanks. Doesn't ['Ref2'] = {'ref2','ش'} mean defining Ref2 as the main name of the parameter and corresponding |ref2= and |ش= to it as aliases? Mensis Mirabilis (talk) 16:13, 8 March 2019 (UTC)

No. In ['Ref2'] = {'ref2','ش'}, Ref2 is the key of a key / value pair in the aliases{} Lua table. This means that |ref2= and |ش= are aliases of each other but |Ref2= is unknown (as it should be). Lua table key A['Ref2'] gets the value from the first set parameter from |ref2= or |ش=. When you declare the local variable Ref2 you also assign it the value from A['Ref2']. In other words, if the cs1|2 template uses |ref2=XYZ, Ref2 should be set to 'XYZ'.

I think that ['Ref2'] = {'Ref2','ش'} is poor form. That aliases{} table assignment should be ['Ref2'] = {'ref2','ش'} so that only |ref2= and |ش= are accepted; this is in keeping with the lowercase-only convention for cs1|2 parameter names.

—Trappist the monk (talk) 16:49, 8 March 2019 (UTC)

 Done. Thanks for the suggestion! Mensis Mirabilis (talk) 17:09, 8 March 2019 (UTC)

Slight unexpected behavior in empty / ignored text cases

I'm playing around with useful test cases for CS1 (because our current test case module has too many cases and doesn't explore all of the code paths systematically). I usurped what was the sandbox module at Module:Citation/CS1/testcases/errors. You can see the test cases there and the results on the talk page.

You'll note the two comments of puzzlement on the test case page.

Any thoughts? Worth solving? --Izno (talk) 01:34, 11 March 2019 (UTC)

line 3481 of the live module:

z.message_tail = {};

so the table that had all of the accumulated error messages is not empty. I did not write this particular bit of code but I think that I agree with it; the essentials are missing so the empty citation message should be sufficient.

—Trappist the monk (talk) 02:47, 11 March 2019 (UTC)

Re: your edit: Actually, cs1|2 does find unrecognized_thing but, because unrecognized_thing is not valid, nothing gets rendered for it (error messages have not yet been rendered at line 3481) so the rendering at that point is an empty citation and the error message for unrecognized_thing was in z.message_tail until line 3481 where z.message_tail is blanked. This same holds true for |unrecognized_parameter=unrecognized. You can prove this to yourself:

1. comment out line 3491 in Module:Citation/CS1/sandbox
2. add Module talk:Citation/CS1/testcases/errors to Preview page with this module text box
3. click the adjacent Show preview button. All sorts of error messages.

—Trappist the monk (talk) 13:38, 11 March 2019 (UTC)

Oh, I believe you; I was being short there. "catches it but dumps it later for the empty citation notice" works too. :^) --Izno (talk) 13:41, 11 March 2019 (UTC)

Relief Map of Far Eastern Federal District.jpg

Hi, Trappist the monk! In the article Balagan-Tas, I tried to add a relief map of the Russian Far East, where the location of the area would be shown in more detail. This map works in the Russian segment wikipedia, but for some reason it does not work in other segments. Maybe you have an idea how to make this card work?

Most likely this map will be needed for other articles in this region. — Preceding unsigned comment added by Modun (talk • contribs) 01:05, 14 March 2019 (UTC)

Balagan-Tas
Балаган-Тас
Balagan-Tas Sakha Republic, Russia
Highest point
Elevation	993 m (3,258 ft)
Prominence	300 m (980 ft)
Coordinates
Naming
Native name	Балаҕан Таас (Balaghan Taas) Error {{native name checker}}: list markup expected for multiple names (help)
Geography
Location	Sakha Republic, Russia
Parent range	Chersky Range
Geology
Rock age	266,000 ± 30,000 years
Mountain type	Cinder Cone
Last eruption	1775

I think that what you want is this:

|map=Russia Far Eastern Federal District

and all other map parameters blank.

Maybe you have an idea how to make this card work? What is a card?

—Trappist the monk (talk) 10:49, 14 March 2019 (UTC)

Yeah, thanks. I mean “map”, not card--Modun (talk) 11:50, 14 March 2019 (UTC)

Cite template code in articles

Hi, can you take a look at Beijing-Zhangjiakou Railway, Zeng Fengnian and The Tomb of Lu Xun there appears to be some expansion of the cite template code in the wikitext of these articles. Thanks. Keith D (talk) 23:27, 24 March 2019 (UTC)

Not the fault of the cs1|2 templates or Module:Citation/CS1. All of these problems appear to result from translation tools. Beijing-Zhangjiakou Railway and The Tomb of Lu Xun were translated using mw:Content_translation and mw:Content_translation/V2, Zeng Fengnian with mw:Content_translation. You might comment at mw:Talk:Content_translation and mw:Talk:Content_translation/V2 where there is mention of referencing problems. Also ping the original translators and ask those editors to fix their work. May be related to phab:T209493 though that phab task is about copy/pasting named references using that abomination that is ve, but, if the translation tools somehow shares ve code... The symptoms are similar...

—Trappist the monk (talk) 00:15, 25 March 2019 (UTC)

Chimpanzee ref style

Hi, I started a discussion on the talk page. Briefly, policy is not to change ref style; another editor made a sudden and in my view unjustified decision to impose Vancouver on this article in January, As I noted in an edit comment, this ought to be reverted. There is also no tradition of Vancouver in animal articles. All the best, Chiswick Chap (talk) 04:26, 29 March 2019 (UTC)

butt-deletion

• Just in case the ping didn't work, please see my post about "butt-deletion" on Help talk:Citation Style 1. I guess there's a tiny possibility that I've been hacked, but butt-deletion seems far more likely. ♦ Lingzhi2 (talk) 01:43, 1 April 2019 (UTC)

DFN

Discrete Fracture Networks (DFN) are very well known in Geoscience. What do your need to insert this abbreviation in the list? Regrettably there is no page in Wikipedia (yet) — Preceding unsigned comment added by Jpvandijk (talk • contribs) 09:04, 2 April 2019 (UTC)

DFN is a disambiguation page (a list of links to articles) not a list of definitions. The rules for disambiguation pages are listed at WP:DAB.

—Trappist the monk (talk) 09:40, 2 April 2019 (UTC)

Ira Glass

I noticed you repaired the ref for the article in the Ira Glass. That is a very long interview with multiple pages, so to be able to direct readers where to find the quotes, I'm using page numbers. Thanks, but it wans't broken!--Esprit15d • talk • contribs 17:27, 8 April 2019 (UTC)

As you wish. At the time I saw the article there was one broken {{sfn}} template which (had it worked would have) pointed to the cs1|2 template in §Works cited; seemed rather pointless. As I write this there are there are two {{sfn}} templates, one broken, one not, both referring to page 1.

—Trappist the monk (talk) 17:36, 8 April 2019 (UTC)

Ahimsa

down the list of the cited cites (phew) is a Levins with details, it's the only thing I could find and now someone has to find that too Dave Rave (talk)

Umm, what are we talking about? Neither of us appear to have edited Ahimsa.

—Trappist the monk (talk) 18:17, 7 April 2019 (UTC)

you a busy man, it's okay ... this one, it shows a National Trust board report paper cite with

Levins, C. and C. Macarthur, J. Ecob, R. Marni, and T. Gilbert. 1995, 'Ahimsa - Cheltenham -Background Paper, Board Meeting no. 55, Agenda item 5j, ' National Trust of Australia, NSW, Sydney, National Trust Archives, Sydney.

and now that I think of it, why haven't I looked at her page, she has one, and an ADB with these details, and other links which make much better sense than a dim double link to a paper we can't read. SHe had a BDM note so theres probably a trove if we're lucky. Dave Rave (talk) 07:54, 8 April 2019 (UTC)

Is that ref really necessary? It's used only once here to support a single sentence that is also supported by this ref (at the bottom of §§Historical notes) which itself appears to rely on the Levin et al. mystery source. ADB agrees.

—Trappist the monk (talk) 11:02, 8 April 2019 (UTC)

that supporting ref is the reason for this ref, trying to further validate that ref, which, from the link, is no validation because we can't read it. SHR do crap cites Dave Rave (talk) 18:49, 8 April 2019 (UTC)

Edit summary

Arguably there's no need for offensive edit summaries such as "remove pointless worldcat urls; fix buggered-up author/editor parameters". It takes only a small amount of imagination to reason that editors will be offended by such, and that being offended, will shy away from engaging with wikipedia. --Tagishsimon (talk) 15:06, 10 April 2019 (UTC)

Are the worldcat urls not pointless? Did not ve / citoid write malformed author/editor parameters? Show me that these things are not true and we have something to discuss. I do not go out of my way to offend people; that takes too much energy but, I shall not be censored.

I must presume that 'buggered-up' is the term to which you refer. Alas, that is a term with more than one definition. I am using in its 'broken, ruined' sense, not its sodomy sense; context is everything.

—Trappist the monk (talk) 15:34, 10 April 2019 (UTC)

Outstanding contributions recognition

	Outstanding Contributions Recognition
	Your work and contributions are exemplary. With intelligent and most helpful inputs at the Help desk, you truly are an outstanding contributor. I don't think I've seen anyone provide such excellent responses for coding queries, as you do from time to time at the Help desk. Keep up the great work! :) Lourdes

Ditto. Eric ^talk 01:25, 24 April 2019 (UTC)

X-ray crystallography cleanup

Your ref-cleanup edits were interleaved in a set of copyvios. I rolled back the article prior to the whole circus, which means some of your changes likely got lost. Some were in the content I removed--it was too difficult for me to selectively undo the bad edits. Sorry! DMacks (talk) 03:27, 28 April 2019 (UTC)

ArbCom 2019 special circular

Administrators must secure their accounts The Arbitration Committee may require a new RfA if your account is compromised. Use strong, unique passwords for your Wikipedia account and associated email Change your password now if your Wikipedia account password or email password is reused on another website, exposed, or weak Enable two-factor authentication now for improved security

View additional information

Why have I received this message? All administrators are receiving it. What prompted you to send this message? Recently, several Wikipedia admin accounts were compromised. The admin accounts were desysopped on an emergency basis. In the past, the Committee often resysopped admin accounts as a matter of course once the admin was back in control of their account. The committee has updated its guidelines. Admins may now be required to undergo a fresh Request for Adminship (RfA) after losing control of their account. What do I need to do? Only to follow the instructions in this message. Check that your password is unique (not reused across sites). Check that your password is strong (not simple or guessable). Enable Two-factor authentication (2FA), if you can, to create a second hurdle for attackers. How can I find out more about two-factor authentication (2FA)? You can find out more about 2FA at m:2FA.

This message was sent to all administrators following a recent motion. Thank you for your attention. For the Arbitration Committee, Cameron11598 02:54, 4 May 2019 (UTC)

Olive branch

You may remember that I was a bit cantankerous (for a couple of years) at WT:CS1, and sometimes testy with you in particular (for which I apologize). You may have also noticed that I've mostly stayed away from the venue for a long stretch; the latter is by design, because I realized I was being unfair and insufficiently collegial. My reappearance there isn't a renewal of old habits, but a new approach, aimed at problem-solving.  — SMcCandlish ☏ ¢ 😼  21:02, 3 May 2019 (UTC)

Were our interactions as heated as you suggest, surely I would remember them. I don't. I remember other discussions with other editors but I just have no memory of such discussions with you. I suppose that I'd rather things remain that way. So now that I have this olive branch, what to do with it? Are olives like poplars? If I push it into most ground will is grow into a tree?

—Trappist the monk (talk) 00:55, 4 May 2019 (UTC)

I don't recall the deets of various prior disagreements myself; you were just on my list of people to make up with. :-) I have a "black thumb"; probably couldn't keep a weed alive. I have no idea whether olive trees can grow from cuttings! Not sure it would be very convenient given all the pickling and stuff needed to make olives edible ...  — SMcCandlish ☏ ¢ 😼  09:17, 4 May 2019 (UTC)

Invalid parameter

Crowdus, Gary (1995). "Richard III by Laurence Olivier". Cinéaste. 21 (3): 53–54. JSTOR 41687396. {{cite journal}}: Invalid |jstor-access=subscription (help)

DrKay, the documentation for Template:Cite journal (and the help text linked in the error message) explains that the only acceptable value for |jstor-access= is free.

If you are objecting to |jstor-access= being listed in the |<param>-access= requires |<param>= section of the Help page, here is an example showing that |jstor= is required when |jstor-access= is used.

Crowdus, Gary (1995). "Richard III by Laurence Olivier". Cinéaste. 21 (3): 53–54. {{cite journal}}: |jstor-access= requires |jstor= (help)– Jonesey95 (talk) 19:20, 1 May 2019 (UTC)

Help talk:Citation Style 1 is the best forum for discussion of that documentation. – Jonesey95 (talk) 19:20, 1 May 2019 (UTC)

(edit conflict) Editor Jonesey95 is so damn fast ...

By deleting |jstor-access= and |jstor= from the table at Help:CS1 errors#|<param>-access= requires |<param>= with the edit summary: doesn't work, you made an unsupported claim that something was broken in cs1|2. I take such claims seriously because I wrote most of the code that supports the cs1|2 templates; if something doesn't work, I want to know about it.

—Trappist the monk (talk) 19:28, 1 May 2019 (UTC)

Jstor access to that article is not free. DrKay (talk) 20:36, 1 May 2019 (UTC)

No one said that it was. Your example above uses |jstor=41687396, a named identifier. Named identifiers are not presumed to be free-to-read; named identifiers are presumed to lie behind a paywall or registration barrier. Because of that presumption, |jstor-access=subscription would be redundant and therefore superfluous so cs1|2 does not support that parameter/value combination.

—Trappist the monk (talk) 20:54, 1 May 2019 (UTC)

Jonesey has written "jstor-access=free" above. Anyway, you have confirmed that both my edit summary and my removal of the defunct parameter at the article was correct[1]. DrKay (talk) 21:10, 1 May 2019 (UTC)

Drive-by comment: It would seem to be harmless to enable |jstor-access=subscription, even if it's redundant, and it'd likely be helpful, since editors who don't work with jstor stuff all the time are unlikely to know or remember that the assumed default for this is subscription and that the parameter presently only supports free. Probably better to have a not-necessary but valid para/val pair show up and maybe get auto-removed by some tool (I wish there were one stripping out |lang=en, |lang=en-US, etc., more often!), than for the template to throw a red error.  — SMcCandlish ☏ ¢ 😼  09:30, 4 May 2019 (UTC)

|lang=en is currently hidden by the templates, just the way you suggest it should work here for non-default access parameters. It doesn't feel gross to me as a result to suppress rather than error here. --Izno (talk) 16:17, 4 May 2019 (UTC)

Administrator account security (Correction to Arbcom 2019 special circular)

ArbCom would like to apologise and correct our previous mass message in light of the response from the community.

Since November 2018, six administrator accounts have been compromised and temporarily desysopped. In an effort to help improve account security, our intention was to remind administrators of existing policies on account security — that they are required to "have strong passwords and follow appropriate personal security practices." We have updated our procedures to ensure that we enforce these policies more strictly in the future. The policies themselves have not changed. In particular, two-factor authentication remains an optional means of adding extra security to your account. The choice not to enable 2FA will not be considered when deciding to restore sysop privileges to administrator accounts that were compromised.

We are sorry for the wording of our previous message, which did not accurately convey this, and deeply regret the tone in which it was delivered.

For the Arbitration Committee, -Cameron11598 21:04, 4 May 2019 (UTC)

CS1 foreign sources categories

I noticed the issue at Lonicera × bella, where I used a German language source in a CS2 citation. I only use CS1 when forced to by the established style, so I was surprised (and unhappy) to see the article categorized in Category:CS1 German-language sources (de), which I now see is only one of a set of categories with "CS1" in the title. Should they not all be called something like "CS1/CS2" sources? Peter coxhead (talk) 20:00, 12 May 2019 (UTC)

There is a lot of stuff that is uses the cs1 appellation: the module suite, error categories, maintenance categories, properties categories, Help:CS1 errors, |cs1-dates= in {{use xxx dates}}). Pretty much all of that is also used by cs2. Do you really want us to go around and rename it all? Is the effort rewarded with significant benefit? If you do, Help talk:Citation Style 1 (yep, another ...) is your venue...

—Trappist the monk (talk) 21:42, 12 May 2019 (UTC)

Monkbot 13

Wikipedia:Bots/Requests for approval/Monkbot 13 was approved. Happy editing! --TheSandDoctor ^Talk 00:32, 13 May 2019 (UTC)

Monkbot Task 13 leaves blank lines behind

See diff:896938986. The bot removes the parameters but ends up leaving a blank line ("\n\n") behind inside the template invokation. I'm guessing the code has an assumption that citation templates are mainly unformatted and on one line; however, obsessive that I am, the cite templates on Hamlet are formatted like a source code block construct (multiline, one param per line). Depending on what your parsing approach is (regex based probably?), this may not be reasonably fixable but leaving those blank lines behind is… unfortunate. If the actual problem is not reasonable to fix, perhaps it can at least be detected and added to a log or tracking cat for manual cleanup? --Xover (talk) 06:04, 14 May 2019 (UTC)

I have tweaked the bot to remove the trailing whitespace when it removes |subscription= or |registration=.

—Trappist the monk (talk) 11:06, 14 May 2019 (UTC)

Quick question

Hey, hoping you can help me with a quick question.

local v = "List of The Tonight Show Starring Johnny Carson episodes (1992)"
print(mw.text.trim(v:match("^(.*)%(%d+%)$")) == "List of The Tonight Show Starring Johnny Carson episodes")

works and gives the correct true result, but

local exceptionList = {
	"List of The Tonight Show Starring Johnny Carson episodes",
	"List of The Tonight Show with Jay Leno episodes"
}

local title = "List of The Tonight Show Starring Johnny Carson episodes (1992)"

local function isOnExceptionList(title, exceptionList)
	for _, v in ipairs(exceptionList) do
		if (v == title) then
			return true
		elseif (mw.text.trim(v:match("^(.*)%(%d+%)$")) == title) then
			return true
		end
	end
	return false
end

gives me Lua error: bad argument #1 to 'gsub' (string expected, got nil) (can see this on my testcases). Any reason why? I'm not sure what I'm missing here. --Gonnym (talk) 11:25, 6 June 2019 (UTC)

When title is not in exceptionList ...

If you are trying to find 'Lost' in 'List of The Tonight Show Starring Johnny Carson episodes' (or the other way round), you won't so string.match() returns nil. mw.text.trim() uses string.gsub() to trim whitespace; string.gsub() chokes when the first argument is nil. You might do this:

elseif (mw.text.trim(v:match("^(.*)%(%d+%)$") or '') == title) then

so that mw.text.trim() never gets a nil argument.

—Trappist the monk (talk) 12:01, 6 June 2019 (UTC)

Thanks, obvious fix for that that I missed, but the issue with the equation is still there, where the top code works, but placed in the function it does not (eventhough, they both use the same values). --Gonnym (talk) 12:23, 6 June 2019 (UTC)

They don't both use the same value (if they did your code would not fail). In the testcases you have this:

{{#invoke:Infobox television season disambiguation check/sandbox|test|Lost (bad disambiguation)}}

so isOnExceptionList() gets 'Lost' for title. 'Lost' is not a member of the exceptionList table in Module:Infobox_television_season_disambiguation_check/sandbox. Your code looks at each member of exceptionList and tries to find 'Lost' in it. This is not the same as the very constrained test of looking for 'Johnny Carson' in 'Johnny Carson'.

—Trappist the monk (talk) 12:43, 6 June 2019 (UTC)

I'm not sure why you are looking at at completely different example than the one I've presented to you. Above there are 2 snippets of code. One uses the code that currently runs in the module/sandbox and one is a simple presentation of it. I pass to both pieces of code the same value as the title - "List of The Tonight Show Starring Johnny Carson episodes (1992)", one works, the other doesn't. Leave "Lost" or any other series out of this discussion as it is irrelevant to the actual problem. --Gonnym (talk) 12:55, 6 June 2019 (UTC)

I've added this as a testcase so you'll see the smaller code returns true. --Gonnym (talk) 13:00, 6 June 2019 (UTC)

(edit conflict)

Because you wrote: can see this on my testcases. I understood that explicit reference as the true root of your complaint because the error message was emitted there and, we both know this from our previous conversations, that contrived examples are often flawed. For example, these disections:

In your first example:

1. explicit title is: 'List of The Tonight Show Starring Johnny Carson episodes'
2. explicit v is: 'List of The Tonight Show Starring Johnny Carson episodes (1992)'
3. v:match("^(.*)%(%d+%)$") returns 'List of The Tonight Show Starring Johnny Carson episodes ' – has trailing whitespace
4. mw.text.trim(v:match(...)) returns 'List of The Tonight Show Starring Johnny Carson episodes'
5. List of The Tonight Show Starring Johnny Carson episodes == List of The Tonight Show Starring Johnny Carson episodes returns true

In your second example:

1. title is: 'List of The Tonight Show Starring Johnny Carson episodes (1992)' – different from first example
2. first v from ipairs() is: 'List of The Tonight Show Starring Johnny Carson episodes' – different from first example
3. the result of if (v == title) then is false
4. v:match("^(.*)%(%d+%)$") returns nil because dab is not present; dab is required in your pattern: ^(.*)%(%d+%)$
5. mw.text.trim(nil) emits ; processing halts here

What I wrote before still applies; just as 'Lost' is not found in 'List of The Tonight Show Starring Johnny Carson episodes', so too, 'List of The Tonight Show Starring Johnny Carson episodes (1992)' is not found in 'List of The Tonight Show Starring Johnny Carson episodes'.

—Trappist the monk (talk) 13:36, 6 June 2019 (UTC)

Amazing. I can't believe I didn't notice I was working on the exception title and not on the current title. Flipped the check and it works. Thanks again Trappist! --Gonnym (talk) 13:53, 6 June 2019 (UTC)

Re the original error message Lua error: bad argument #1 to 'gsub' (string expected, got nil): ~3 weeks ago I asked if we could get slightly less misleading errors @ mw:Extension talk:Scribunto/Lua reference manual#gsub error emitted by mw.text.trim(). No response yet though.   ~ Tom.Reding (talk ⋅dgaf)  14:07, 6 June 2019 (UTC)

Perhaps a phabricator ticket would get better results?

—Trappist the monk (talk) 14:13, 6 June 2019 (UTC)

 Done

Tracked in Phabricator
Task T225227

  ~ Tom.Reding (talk ⋅dgaf)  15:49, 6 June 2019 (UTC)

Help_talk:Citation_Style_1#Odd_PMC_error

Would be great if you could fix that. PMC numbers keep growing, and the 6500000 limit is not appropriate anymore. Cheers. Materialscientist (talk) 07:34, 6 June 2019 (UTC)

Generally, minor changes like this are not done in the moment because each such change dumps several million articles onto MediaWiki's job queue. But, in this case, because nothing else changes in Module:Citation/CS1/Identifiers and because the next update will not occur before the completion of a couple of rfcs (here and here), I have made an exception to the normal rule.

The new limit is 7000000. Remind me before pmc gets to that number so that it can be reset before the numbers exceed the test limit.

—Trappist the monk (talk) 10:24, 6 June 2019 (UTC)

Thanks! Materialscientist (talk) 22:10, 6 June 2019 (UTC)

A cup of tea for you!

Appreciating your work deprecating the old parameters for citations. Such parameters add additional clutter to articles that makes them even harder to edit, so I am fully supportive of your work. Tom (LT) (talk) 03:42, 8 June 2019 (UTC)

Monkbot changes to 2018 Winter Olympics

Hi, your bot made some changes to CS1 parameters in 2018 Winter Olympics article yesterday, some of which I want to query. Can I discuss here? Thanks. Rodney Baggins (talk) 14:58, 18 June 2019 (UTC)

Of course. I'll be out for the next few hours but will read and respond to whatever it is that you would like to say.

—Trappist the monk (talk) 15:06, 18 June 2019 (UTC)

Thanks. I'm quite "into" citations and that's usually my first port of call when I come across a new article that wants some work doing to it, so I've developed a few preferences (and possibly bad habits). Take a look at this diff from yesterday...

BBC Sport and BBC News articles are specifically issued via dedicated web pages, as opposed to through an alternative news outlet such as a newspaper, hence I've always thought it correct to use the {{cite web}} template rather than {{cite news}}. I've understood the latter to be applicable to newspaper articles, online news items from news outlets such as The Guardian, The Telegraph, etc. even when they have an online presence. BBC Sport is a department of the BBC that provides online sports coverage, it's not a newspaper, not even an online newspaper. It's part of a corporation that publishes information online, hence {{cite web}} is probably more appropriate. Having said all that, it doesn't actually affect the way the citation is displayed so it's not really a problem in the great scheme of things. However, the thing that I'm most puzzled about is that your bot has substituted the 'work' parameter for the 'publisher' parameter in the case of BBC Sport and BBC News, which I disagree with. I've always gone with 'publisher' because these are divisions of a company, as opposed to newspapers or stand-alone websites. The 'work' parameter always italicizes the name (as an alias of the 'newspaper' and 'website' parameters), but 'publisher' doesn't. You can see that the BBC Sport and BBC News articles don't use italics in their titles for the same reason.

Reuters – same argument. I think this should use 'publisher' not 'work'

The Straits Times – I agree that this should not use 'publisher' because it's clearly a newspaper and it should use a {{cite news}} template with 'newspaper' parameter.

Business Insider – I agree that this is a news website and hence {{cite news}} template and 'website' parameter with italics is correct. Rodney Baggins (talk) 18:39, 18 June 2019 (UTC)

There is no fast and hard link between {{cite news}} and |newspaper= and little difference between {{cite web}} and {{cite news}} in the final rendering except that {{cite news}} will render |volume= and |issue= if present and does not require |url=. In cs1|2, the 'periodical' parameters, |journal=, |magazine=, |newspaper=, |periodical=, |website=, & |work= are freely interchangeable (they all map to an internal meta parameter called Periodical). The variety of names is mostly an editor convenience because template names that reflect the type of the source are more semantically correct.

Almost everything that is online can be cited using {{cite web}}. But should it? An online facsimile of a book: {{cite web}} or {{cite book}}? An online PDF of a scientific paper: {{cite web}} or {{cite journal}}? An online news article about Ebola in Africa, about monsoon floods in Bagladesh, about 2019 World Cup: {{cite web}} or {{cite news}}? The {{cite web}} documentation states:

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

I see BBC Sport as a publication that is an online news source focused on sports news and that is published by BBC. As such, {{cite news}} is appropriate. Because BBC Sport is not a |journal=, |magazine=, |newspaper=, or a generic |periodical=, either of |website= or |work= is appropriate when naming the publication in a cs1|2 template. I prefer |work= because |website= was pretty-much created to be a companion to {{cite web}} (the move to Module:Citation/CS1 made |website= promiscuous).

In periodical cs1|2 templates, |title= names the article; |work= and aliases name the publication; |publisher= names the corporate entity responsible for publishing the publication that holds the article.

There are technical reasons for the choice of |work= (or an alias) over |publisher=. cs1|2 produces metadata for each citation. These metadata are machine-readable versions of the visual rendering. The metadata standard to which we attempt to adhere is not as full-featured as cs1|2. It is important that the correct information from raw cs1|2 template parameters gets into their matching metadata key/value pairs. Most of the parameters in cs1|2 that have matching metadata keywords are not confusing to editors; |<periodical>= and |publisher= are problematic because editors have a variety of opinions (or confusion) regarding the format of the rendered citation and whether a publication belongs in |work= or a publication belongs in |publisher=.

The metadata standard is limited. In the metadata, the cs1 periodical templates {{cite journal}}, {{cite magazine}}, {{cite news}}, and {{cite web}} are defined as journal objects. Journal objects do not support the concept of 'publisher'; that is reserved for book objects (see the table here) so any data in |publisher= for these templates does not make it to the metadata. It is perfectly legitimate for these templates to have |publisher= but they must also have |work=. For readers who consume these citations via their metadata, omitting |work= from a cs1|2 periodical template is like giving the reader only the chapter name but not the name of the book that holds that chapter. An upcoming change to Module:Citation/CS1 will emit error messages when periodical templates do not have |work= (or alias).

Further, many many of the citations that Monkbot task 14 is fixing have italic markup. Italic markup is only allowed in |title= (so that journal article titles that include scientific names, for example, render correctly). It is the responsibility of the templates to format and render the final citation so that editors don't have to. To facilitate that, the templates require the correct data in the correct parameters, and that these data are free from contamination (wiki markup, extraneous text, ...).

Monkbot task 14 is working now to reduce the number of error messages that will appear at the next update to the module suite.

BBC Sport (and BBC News) in cs1|2 citations are publications that hold articles. In this sense, they are no different from The Straits Times (a publication) that holds articles. The article titles are quoted plain text, the publications are italicized, and the publisher (if present) is plain text. I do not think that MOS:TITLE should ever be recognized as a paragon of clarity; especially this:

"Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized (Salon or HuffPost). Online non-user-generated encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online). Other types of websites should be decided on a case-by-case basis."

But, this part applies here:

"Online magazines, newspapers, and news sites with original content should generally be italicized..."

because BBC Sport is an online... news site with original content. It doesn't appear that the topic of italic title has ever been raised at those two articles.

—Trappist the monk (talk) 00:33, 19 June 2019 (UTC)

Thank you for your very comprehensive reply. I accept what you're saying, even if I don't understand all of it! My approach is clearly a lot more simplistic and, like I said before, I've probably developed some bad habits. The main thing that bothers me is the anomoly between rendering BBC News, BBC Sport, Reuters, etc. with italics in citations, but they are displayed everywhere else without italics, e.g. their article titles and all mentions of them in body text. Would it be correct to include both "website=BBC Sport/News" AND "publisher=BBC" because BBC Sport/News is the name of the website that is published by the BBC? In fact, to be more accurate, BBC Sport is a department of the BBC that runs its own website which also happens to be called BBC Sport, in which case the italics anomoly is not really a problem because the BBC Sport article is referring to the department as a whole, not just the website. Which brings me back to my original argument, which is that BBC Sport should be used as publisher parameter, because it is the publisher of the content, which just happens to be online! Interesting stuff. Rodney Baggins (talk) 07:45, 19 June 2019 (UTC)

When the name of the publication is largely the same as the name of the publisher, cs1|2 documentation suggests that |publisher= should be omitted; cf. {{cite news}}.

It can be confusing when the name of the publication is largely the same as the name of the publisher. Plain text shows that we are using the publisher's name to refer to the publisher as a corporate entity: Reuters. We use italics when referring to publisher's name as the publisher's publication: Reuters. In cs1|2 periodical templates, |title= is the 'article' inside the publication (|work= or alias); not inside the publisher (|publisher=). cs1|2 will soon require publication names in periodical templates.

So, BBC is a corporate entity that has a department BBC Sport. BBC Sport is also a corporate entity that publishes an eponymous online news site BBC Sport. BBC Sport is a publication that holds various news articles related to sports. BBC also has a department BBC News which has an eponymous publication BBC News for general interest news articles. Cite the article in the publication; publisher generally not required (except perhaps as some sort of disambiguator when publication name is similar to another publication name (|location= might a better choice for similarly named newspapers (cf. The Telegraph).

—Trappist the monk (talk) 11:56, 19 June 2019 (UTC)

OK, I think I get all that (just about). I have learnt that BBC Sport and BBC News are publications and as such should be recorded using the 'work' parameter rather than the 'publisher' parameter, and since 'work' is an alias of 'website' it makes it easy to remember that we're specifically referring to the online content of these publications. The wiki articles for BBC News and BBC Sport are about the individual business divisions of the BBC (responsible for radio and television output as well as online news coverage). Which brings me to my next question: Do you think the work parameter should be wikilinked through to the related article, e.g. work=[[BBC News]] ? This is essentially the source of my confusion because you see BBC News presented in italics in the citation, indicating the BBC News website, but the link takes you through to the wiki article for the BBC News business division, when the two entities are not logically equal. ...Oh dear, since writing that, I've just realised there's a BBC News Online article, so where does that come in? Should we be linking to that instead, and if so, why does that not have an italicized title? The equivalent for BBC Sport is the BBC Sport Online section inside the BBC Sport article. Still a bit confused but I guess I can learn to live with it! Rodney Baggins (talk) 17:53, 19 June 2019 (UTC)

The purpose of citations at en.wiki is to help readers locate the source that supports the text of an en.wiki article. If a wikilinked work helps readers locate the source by somehow clarifying the source, then wikilink; if there is little to be gained by wikilinking, or if wikilinking might cause confusion, then do not wikilink. Generally, I think, it is not necessary to wikilink the publication.

BBC News Online may be a form of en.wiki disambiguation that distinguishes it from BBC News; the actual website at www.bbc.com/news/ does not use that name (perhaps it once did but now doesn't? maybe because the site's presence 'online' is obvious so 'online' as a name component is superfluous?). The website at www.bbc.com/sport/ doesn't use 'online' either. Perhaps editors who work on BBC News Online (and BBC Sport Online) – why uppercase O? – might consider moving BBC News Online to BBC News (website) and creating a BBC Sport (website) redirect.

—Trappist the monk (talk) 19:06, 19 June 2019 (UTC)

OK, thanks for clarifying all that. I'll endeavour to use work in preference to publisher in future, and only wikilink if it's an obscure work that might need clarifying. I'm sure your bot will come across a few more articles that I've incorrectly cited, so I'll leave it to do its work. Have a nice day. Thanks again. Rodney Baggins (talk) 08:30, 20 June 2019 (UTC)

No good idea

AutoWikiBrowser, operated by Trappist the monk and who is it John Doe or who else? AVS (talk) 07:30, 26 June 2019 (UTC)

Monkbot question

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I noticed several changes to AllMusic refs that use {{Cite web}} from |publisher=AllMusic to |website=AllMusic. While this follows the Template documentation, it changes the appearance of AllMusic to AllMusic. Some editors believe that AllMusic shouldn't be italicized (recent FLC review: "Make sure AllMusic isn't italicized in refs 1, 10, and 59"). So, is it possible to have Monkbot add '' (two apostrophes) before and after AllMusic so it is not italicized. Or are the editors who believe this wrong? —Ojorojo (talk) 19:40, 27 June 2019 (UTC)

Concur. AllMusic is not an online periodical that would be italicized.

I've also noticed IGN being italicized by the bot. IGN in this context is an online network, not a periodical, and is no more italicized that CBS or Facebook Watch. Thank you for addressing these things. --Tenebrae (talk) 20:08, 27 June 2019 (UTC)

(edit conflict)

|publisher= in cs1 periodical templates ({{cite journal}}, {{cite magazine}}, {{cite news}}, {{cite web}}) and their equivalent in cs2 ({{citation}} when a periodical parameter is used) produces incomplete metadata. Whatever information is assigned to |publisher= in these cases is left out of the citation's metadata. This is not the fault of cs1|2 but a limitation imposed on us by COinS which is the metadata standard to which Module:Citation/CS1 follows because that standard does not support publisher information for periodicals. For those who consume article citation information via the metadata, the missing newspaper, magazine, journal, website title is a problem that we as an encyclopedia must not cause.

Wikimarkup in all cs1|2 parameters that are placed in the metadata is not allowed; see cite web doc. There is an exception made for |title= – species names in journal article titles, for example. One of the other things that Monkbot task 14 is doing is removing this extraneous markup from |publisher= and the various periodical parameters.

All of this is documented in the bot's task documentation, linked from each edit summary.

—Trappist the monk (talk) 20:18, 27 June 2019 (UTC)

Thanks. Not sure what you're saying, though. Is the bot going to continue italicizing AllMusic and IGN? --Tenebrae (talk) 20:48, 27 June 2019 (UTC)

The bot is not italicizing anything. It is repairing invalid parameter use in periodical templates by renaming |publisher= to an appropriate periodical parameter according to the periodical: as |publisher=The New York Times (with or without italic markup) → |newspaper=The New York Times so |publisher=IGN → |website=IGN and |publisher=AllMusic → |website=AllMusic. In the periodical templates, italic markup found in |publisher= and any of the periodical parameters is removed for the reasons I described above. cs1|2 citations cite sources. In cs1|2 source names are italicized. IGN and AllMusic are source names of their eponymous publishers. Therefore, these source names, in cs1|2 citations, are italicized.

—Trappist the monk (talk) 21:42, 27 June 2019 (UTC)

Thanks for the explanation. Others who add apostrophes should be made aware of this. BTW, Template:AllMusic produces AllMusic without italics (Erlewine, Stephen Thomas. Review of Physical Graffiti at AllMusic. Retrieved March 30, 2014.), which may lead to some inconsistencies (I've seen both used in the same article). —Ojorojo (talk) 20:49, 27 June 2019 (UTC)

The bot task is preemptively trying to fix as many of the errors as it can before the next release of Module:Citation/CS1 which will emit red error messages where |publisher= is misused and where wiki markup is found in |publisher= and the periodical parameters. The bot has fixed thousands of pages. Unless all of the editors of all of those thousands of pages have hidden bot edits on their watchlists (or are ignoring their watchlists altogether), there has been notification.

{{AllMusic}} does not fall within the purview of cs1|2. There was some discussion several years ago about making a meta or wrapper template for AllMusic. That discussion died without resolution.

—Trappist the monk (talk) 21:42, 27 June 2019 (UTC)

Now that Editor Tenebrae has opened a related discussion at the more public Help talk:Citation Style 1 § Monkbot, I am going to close this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Excessive zeal?

Regarding diff:894063156 and diff:894063648. Why did you remove |via=… and |ref=none here? --Xover (talk) 19:34, 27 June 2019 (UTC)

|ref=none does nothing useful, so it's clutter, and |via=JSTOR is useless, since it doesn't matter if you choose to read the source through the DOI link, or the JSTOR link, both link to the same paper. Headbomb {t · c · p · b} 19:42, 27 June 2019 (UTC)

Yep, ↑that's why. |via= attempts to minimize astonishment that can occur when clicking on a title-link where |publisher= says one thing but the reader ends up somewhere else. Clicking a JSTOR link and landing at JSTOR is not astonshing. For |ref=none: that parameter / value combination only has meaning for {{citation}} or when used in a cs1 template ({{cite book}}, etc) that also has |mode=cs2.

—Trappist the monk (talk) 19:54, 27 June 2019 (UTC)

Hmm, no, |via= indicates that the citation is to a copy on a different service than the publisher's (i.e. a database provider like JSTOR or Questia). Why you think DOIs and the URL generated by |jstor= is relevant is beyond me. And |ref=none suppresses the generation of the CITEREF link target,[struck as embarassingly insufficiently thought through. --Xover (talk) 06:34, 28 June 2019 (UTC)] which happens to be a useful hook for quality control tools (think HarvErrors) to highlight ciitation problems (and would be even more useful if CS1 would add a CSS class for |ref=none to distinguish it from |ref=). --Xover (talk) 20:18, 27 June 2019 (UTC)

Do doi:10.2307/908045 and JSTOR 908045 point to different papers? They don't. So |via= is useless in this situation. Likewise, in this situation, |ref=none does nothing different than no |ref= at all would. Headbomb {t · c · p · b} 20:29, 27 June 2019 (UTC)

Here are two simple {{cite book}} templates; one with, and one without, |ref=none. The important bit to look at is the <cite> tag in html view:

{{cite book |title=Title |author=Author |date=2019}} → Author (2019). Title. {{cite book}}: |author= has generic name (help)

'"`UNIQ--templatestyles-00000068-QINU`"'<cite id="CITEREFAuthor2019" class="citation book cs1">Author (2019). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2019&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AUser+talk%3ATrappist+the+monk%2FArchive+8" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>

{{cite book |title=Title |author=Author |date=2019 |ref=none}} → Author (2019). Title. {{cite book}}: |author= has generic name (help)

'"`UNIQ--templatestyles-0000006C-QINU`"'<cite class="citation book cs1">Author (2019). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2019&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AUser+talk%3ATrappist+the+monk%2FArchive+8" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>

For comparison, same basic templates but with |mode=cs2:

{{cite book |title=Title |author=Author |date=2019 |mode=cs2}} → Author (2019), Title {{cite book}}: |author= has generic name (help)

'"`UNIQ--templatestyles-00000070-QINU`"'<cite id="CITEREFAuthor2019" class="citation book cs2">Author (2019), ''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2019&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AUser+talk%3ATrappist+the+monk%2FArchive+8" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>

{{cite book |title=Title |author=Author |date=2019 |ref=none |mode=cs2}} → Author (2019), Title {{cite book}}: |author= has generic name (help)

'"`UNIQ--templatestyles-00000074-QINU`"'<cite class="citation book cs2">Author (2019), ''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2019&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AUser+talk%3ATrappist+the+monk%2FArchive+8" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>

Note how the first two and the last one do not have an id= attribute in their <cite> tag but the third one does. |ref=none in cs1 templates without |mode=cs2 contributes nothing to the citation.

cs1|2 does not have a Questia identifier so for a source at a Questia |url=, |via=Questia may be appropriate. Using |via= for the named identifiers is just repetition.

—Trappist the monk (talk) 22:54, 27 June 2019 (UTC)

This bot seems to be the fruit of sleepless nights! E.g. |ref=none is useless that's a totally shortsighted point of view. AVS (talk) 05:10, 28 June 2019 (UTC)

@Avernarius: then, do tell, what is the purpose of having |ref=none when |ref=none does exactly nothing? Headbomb {t · c · p · b} 05:40, 28 June 2019 (UTC)

E.g. The ref is not yet available/found but will be added later – it's a place holding device which can also be detected easily. AVS (talk) 07:46, 28 June 2019 (UTC)

You misunderstand the purpose of |ref= then, which is to create an HTML anchor that can be used by {{Harvnb}} and similar. Headbomb {t · c · p · b} 07:59, 28 June 2019 (UTC)

@Trappist: Indeed, and had I given it half a thought I would have realized that what I wrote there was nonsense (and I've struck it). My apologies for that!

My motivation for using |ref=none is actually precisely because it currently does nothing in those cases: I'm hoping we can get to some point where |ref=harv is the default, and so |ref=none will actually start to have an effect. In the mean time, it is an awkward and inefficient (in that it requires parsing wikitext), but doable way to distinguish between a cite where |ref= was left out and one where it is deliberately omitted (because the template is used to format an entry in a "Further reading"-type list).

But |via= is not identifier (or URL) specific: it applies to the whole citation. It tells the reader that the article's author accessed the cited source through a copy at a third party rather than from the publisher directly, and that thus it may have changes or errors not present in the original. That one of the links and identifiers provided with the citation happens to be labelled by the template with a text string that is similar to the name of that database service is completely incidental: whether a journal article is cited with just DOI and HDL provided, or also with a URL to jstor.org, is immaterial to the WP:V issue of through which database it was accessed. --Xover (talk) 06:34, 28 June 2019 (UTC)

It also goes against the purpose of |via=, which is to let readers now where a link will take them. Knowing where the article's writer read something goes against WP:SAYWHERE: Note: The advice to "say where you read it" does not mean that you have to give credit to any search engines, websites, libraries, library catalogs, archives, subscription services, bibliographies, or other sources that led you to Smith's book. If you have read a book or article yourself, that's all you have to cite. You do not have to specify how you obtained and read it. [emphasis mine]. Headbomb {t · c · p · b} 06:58, 28 June 2019 (UTC)

How is a reader to intuit from a citation with the 'via JSTOR' text that you, the editor, consulted the JSTOR copy of a source? To a reader, 'via' is a common English word indicating the path to the destination.

—Trappist the monk (talk) 10:47, 28 June 2019 (UTC)

More importantly, why should the reader care that you read a Physics Review Letters through a third party or not. It's the same article regardless of the method of access. Headbomb {t · c · p · b} 14:48, 28 June 2019 (UTC)

All About Jazz

Monkbot/task 14 lists All About Jazz as being a magazine, so some citations are being changed, example here. But it's a website, not a magazine (although a connected magazine, All About Jazz – New York, was published into 2011). EddieHugh (talk) 15:25, 29 June 2019 (UTC)

Monkbot task 14's list of periodicals is hand currated (by me). I am human, I do err. My source All About Jazz is the en.wiki article – which is itself contradictory:

1. the lead says: "All About Jazz is a website..."
2. the infobox has: |type=[[Jazz]] [[music]] [[database]]
3. the article is assigned to these categories:
   1. Category:American online magazines
   2. Category:Jazz magazines
   3. Category:Magazines established in 1995
   4. Category:American music magazines
   5. Category:Music websites
   6. Category:Magazines published in Pennsylvania

Yeah, any online source is a website. Because the en.wiki article is undecided/uncertain/unclear, I took the decision that All About Jazz is an online magazine and I told the bot to call it a magazine.

Before the bot's visit, the two templates citing All About Jazz were {{cite news}} templates that were misusing |publisher=''All About Jazz''. How is {{cite news}} better or worse than {{cite magazine}} for this application? Both will suffice. If you want to rename the template to something else and use any of the periodical-alias parameters, do so. Please don't misuse |publisher=.

—Trappist the monk (talk) 16:05, 29 June 2019 (UTC)

Wait! Don't shoot! I'm only the messenger. I'm just passing on information. Your choice was a reasonable one, based on the evidence, as you say. Those weren't my original edits on the Zoe Rahman article, so I wasn't (as far as I know) misusing 'publisher'. It came up in my watchlist, so I used it as an example. I don't know the answer to your question, but I thought that, if the bot's role is to correct things, then it's preferable to get things as correct as they can be, which would be (as far as I can see) to use 'cite web' for AAJ, barring evidence to the contrary. So I pointed it out. EddieHugh (talk) 18:06, 29 June 2019 (UTC)

I don't think that I was accusing you of anything; certainly that was not my intent. I can see on rereading my post that it may have come across that way. I apologize for that.

I disagree that {{cite web}} is a better choice than {{cite magazine}}. Looking at the All About Jazz online presence, I see something that looks and feels like an online magazine. That is this human's judgement.

The bot cannot be made clever enough to arrive at its own judgement. The trigger for the bot is the words All About Jazz with or without italic markup in |publisher=. If there is no conflicting periodical parameter, the bot will make the fix that I told it to make. This is why I do not want you to change back to |publisher=''All About Jazz'' (and because the next revision of the Module:Citation/CS1 suite – the engine that drives the cs1|2 templates – will emit red error messages when it finds periodical templates without periodical parameters and italic markup in |publisher=).

—Trappist the monk (talk) 19:11, 29 June 2019 (UTC)

Monkbot Task 14 bug

You probably already know about this and I don't really know where to report it but in this edit it caused another cs1 error by adding "website$224dash.com" instead of "website=24dash.com". Trialpears (talk) 18:54, 5 July 2019 (UTC)

I didn't, so thanks for the heads-up. Bug was only an issue with parameter values that begin with digits. Bug now squashed.

—Trappist the monk (talk) 19:45, 5 July 2019 (UTC)

Nzima

This is all redirected to Nzema and causing category redirects to be populated. Please can you amend the modules to prevent this. Timrollpickering (Talk) 10:32, 9 July 2019 (UTC)

Something must have been left out of your post. I have no idea what you are talking about. Please clearify.

—Trappist the monk (talk) 10:51, 9 July 2019 (UTC)

Fixed the cat. Timrollpickering (Talk) 11:58, 9 July 2019 (UTC)

~ work ~

Trappist, nice to meet you ~ does Monkbot take care of citations that use 'work=' instead of 'newspaper=', 'magazine='? The reason I ask is this edit here I noticed the replacements ~ and I have been using 'work=' only in my citations ~ do I need to change my style or will the bot take care of it? once again ~ nice meeting you ~mitch~ (talk) 20:09, 13 July 2019 (UTC)

@Mitchellhobbs: The template treats |work= and several other parameters (including those you mentioned) as synonyms. Don't worry if you use one or the other. The bot task is concerned with Other Things than what the name of that exact parameter is. --Izno (talk) 20:11, 13 July 2019 (UTC)

Thanks @Izno: ~mitch~ (talk) 20:13, 13 July 2019 (UTC)

Citing book reviews

I'm not convinced that changes like this to the |title= parameter of {{cite journal}} are helpful. There's no style guide, as far as I know, that recommends citing book reviews without making clear that what's being cited is a review – just giving the title as it's given at the top of the page is no doubt easier for automated citation tools but it runs counter to common sense. A citation that says "Buchanan, Tom (April 2010). 'The Spanish Civil War and the British Left: Political Activism and the Popular Front'" gives the impression that Tom Buchanan is the author of a work called "The Spanish Civil War and the British Left: Political Activism and the Popular Front", which isn't really the case. It's less of a problem in an article like this where it's clear that The Spanish Civil War and the British Left: Political Activism and the Popular Front is a book by Lewis H. Mates, because the book is the subject of the article, but it could certainly cause confusion in other contexts. – Arms & Hearts (talk) 13:11, 17 July 2019 (UTC)

Review articles have always been problematic within the scope of cs1|2. |title= should always hold the title of the article as the publisher of the article wrote it – that will be the thing that a reader most likely will search for in a paper copy of the journal; we shouldn't be making their search more difficult. Within a cs1|2 template one can do |type=Review or |department=Book Reviews, but the title should not be modified with extra text; in cs1|2 the square brackets are reserved to English translations of non-English titles (|trans-title= and related parameters).

• Buchanan, Tom (April 2010). "The Spanish Civil War and the British Left: Political Activism and the Popular Front". Book Reviews. The English Historical Review. CXXV (513): 492–493. doi:10.1093/ehr/ceq011.
• Ruiz, Julius (September 2009). "The Spanish civil war and the British left: political activism and the popular front. By Lewis H. Mates". The Historical Journal (Review). 52 (3): 846–848. doi:10.1017/S0018246X0900764X.
• Corthorn, Paul (July 2009). "The Spanish Civil War and the British Left: Political Activism and the Popular Front – By Lewis H. Mates". Reviews and Short Notices. History. 94 (315): 407–408. doi:10.1111/j.1468-229X.2009.00461_29.x.

—Trappist the monk (talk) 14:03, 17 July 2019 (UTC)

Fair enough, I suppose. Thanks for pointing out |type= and |department=, which I hadn't previously been aware of – one or the other of those is good enough as a way to signal that it's a review. I don't really agree that |title= "should always hold the title of the article as the publisher of the article wrote it", and I think there are good reasons why this isn't standard practice elsewhere, but that's obviously a discussion to have elsewhere than your talk page. All the best, – Arms & Hearts (talk) 17:13, 17 July 2019 (UTC)

Ship prefixes

Hi Trappist the monk. Can you please add more prefixes to Module:WPSHIPS utilities? The prefixes are "KLD" - Kapal Layar Diraja - which translates to His Majesty's Sailing Ship (Malaysia), and "KA" - Kapal Auksiliari - Auxiliary Ship (Malaysia). Thank you. Shuipzv3 (talk) 14:54, 28 July 2019 (UTC)

Cite repair changes

Hi Trappist the monk. You made cite repair changes to GreatAuPair that removed two HighBeam links and their archiveurls. HighBeam links no longer work, but the citation templates still had Wayback Machine archiveurls like https://web.archive.org/web/20151101005121/http://www.highbeam.com/doc/1G1-182605951.html and https://web.archive.org/web/20151101004941/http://www.highbeam.com/doc/1G1-149844457.html that worked. Would you restore these archiveurls? Thanks, Cunard (talk) 21:39, 28 July 2019 (UTC)

Yep, Highbeam is dead. Yep, archive.org has what appears to copies of the Highbeam pages. But, the archived pages are just the teasers that Highbeam used to get readers to signup for a subscription to read the whole article. At the bottom of the article extract on the teaser is a link: "To read the full text of this article and others like it, subscribe today!" Readers who follow that link and fill in the form, are, I suspect destined for disappointment.

You and I may see immediately that the archived page is an archived page, others may not. Nothing on en.wiki requires sources to be available on-line.

We should not offer something to readers that we cannot deliver.

—Trappist the monk (talk) 22:11, 28 July 2019 (UTC)

Thank you for explaining your reasoning. I think Wayback Machine links would be useful to be retained if the article extract they were able to archive verified the material in the text since that would provide some value to the readers. That was not the case for these two sources; the material was not in the teasers and were only in the full text, which is no longer accessible via HighBeam. I was able to find links from other websites for these articles, so I've changed the article to add them. Cunard (talk) 22:55, 28 July 2019 (UTC)

I suppose that there is a slight chance that the teaser extract might support text in an en.wiki article but one is always left wondering about that which cannot be seen so, yeah, what you have done is best for the readers.

—Trappist the monk (talk) 23:06, 28 July 2019 (UTC)

Any guidelines against 'it's my school project'?

Hi, Trappist the monk! :)
I'm turning to you as an active admin for some help or directions on commenting good-faith but wrong-directed efforts of some newbies. The most recent example I spotted was User:Slicedpotato. The user explains at the User:Theroadislong's talk page (which I stalk) in section #Leather Seat that they have created a want-to-be an article ‘because this is my project in school’. This happens quite often that teachers at schools or even universities run such projects which require creating new articles at Wikipedia. They probably usually do not realize how difficult task it is to create an acceptable article here, hence that their pupils' efforts are most probably doomed (as it happened to User:Slicedpotato/sandbox).

Here my question comes: how should we direct pupils or students to teach or direct their teachers to some explanation on the problem? Most important, how to do it in civilized manner, which will still be civilized one step higher (I mean, not causing any misunderstaning or conflicts between the pupil/student and his teacher/professor)?
Best regards. --CiaPan (talk) 09:56, 12 August 2019 (UTC)

PS. I'm starting to watch your talk page, so feel free to answer either at my talk page or here.

Way outside my bailiwick. Shouldn't this topic be raised in a much more public forum (one of the village pumps)? I found this which might be helpful.

—Trappist the monk (talk) 10:26, 12 August 2019 (UTC)

@CiaPan: I might recommend raising this question at Wikipedia:Education noticeboard. --Izno (talk) 04:17, 13 August 2019 (UTC)

WP:WEBHOST / WP:OWN would have part of an answer, I feel, although not a complete one. Headbomb {t · c · p · b} 04:20, 13 August 2019 (UTC)

MonkBot

Will the MonkBot be operational again? BabbaQ (talk) 18:13, 14 August 2019 (UTC)

There is no MonkBot. Monkbot is not dead. Why?

—Trappist the monk (talk) 18:35, 14 August 2019 (UTC)

I hate bots!

Bots are noobs! CamdenFreeway295 (talk) 18:42, 14 August 2019 (UTC)

FYI

I believe this might interest you (and you might be in a better position to accomplishing such): Template talk:Lang § Wikidata language item mappings. 50.53.21.2 (talk) 19:39, 15 August 2019 (UTC)

Notice of noticeboard discussion

There is currently a discussion at Wikipedia:Administrators' noticeboard regarding an issue with which you may have been involved. The thread is "Is there a semi-automated tool that could fix these annoying "Cite Web" errors?". Thank you. In case you do not receive pings. Ivanvector (^Talk/_Edits) 13:07, 3 September 2019 (UTC)

Cite template stuff

Hi Trappist, whatever the outcome of all of this Cite template stuff (like the change of deadurl to urlstatus), is there any way to have these ideas incorporated into the reFill projects and AWB? I don't know anything about the technical aspects of all that, but I thought I'd mention it in case you are so technically inclined. Seems like a simple bot working on this can be helped by humans. Regards, Cyphoidbomb (talk) 15:37, 3 September 2019 (UTC)

There is a BRFA for |deadurl= / |dead-url= → |url-status= which see. Will it be approved? Don't know.

—Trappist the monk (talk) 15:52, 3 September 2019 (UTC)

A barnstar for you!

	The Technical Barnstar
	It is a thankless job but I am glad someone like you is willing to do it. I wish you good luck. --- Coffeeandcrumbs 21:43, 3 September 2019 (UTC)

Another barnstar for you!

		The Citation Barnstar
		Many thanks for the work you've done updating and maintaining the citation modules and templates. My apologies for helping turn today into a drama-fest, and I'm especially sorry for suggesting that you should be blocked. Ivanvector (Talk/Edits) 22:09, 3 September 2019 (UTC)

Source editors

Hello Trappist'. Since your user page doesn't exist, I was unable to ping you on the Joseph LaBarge talk page. I am wondering why you removed two of the three editor's names from one of the sources used in the article. At archive.org three editors names are given. I realize that Martin's name is the only one listed on the title page, but unless there was a good reason for removing the other names or if it doesn't involve a policy/guideline issue, I would prefer to have all three names listed. -- Gwillhickers (talk) 22:17, 3 September 2019 (UTC)

A user page is not required for pings to work. I have been pinged a lot today.

This one?

{{cite book |editor-first=G. W. |editor-last=Martin |title=Collections of the Kansas state historical society, Vol IX |authorlink= |publisher=State Printing Office, Topeka, Kansas |orig-year=1875 |year=1906 |url=https://archive.org/details/collectionsofkan09kans/page/n3 |ref=Martin}}

Martin, G. W., ed. (1906) [1875]. Collections of the Kansas state historical society, Vol IX. State Printing Office, Topeka, Kansas.

When I followed the link to archive.org it drops me at the title page of the facsimile where the title is:

Transactions of the Kansas State Historical Society, 1905–1906 Vol. IX Edited by Geo. W. Martin and published in 1906 (the date that you include in the citation)

The metadata from archive.org that lists the various other editors and the years that they held office were either before or after GW Martin's tenure as editor. Dates are not editor names so that lead me to the recognition that not all of those editors should be listed. Though I didn't change it, I would suggest that the archive.org metadata are wrong about the book title as well (transactions, not collections). Answer your questions?

—Trappist the monk (talk) 22:55, 3 September 2019 (UTC)

Thanks for your prompt reply. Since there is only one name listed on the title page i.e.Martin, and given the doubt you've expressed, I can live with the source/citation as it's now listed, per your recent edit. Thanks for looking out. -- Gwillhickers (talk) 23:19, 3 September 2019 (UTC)

Recent changes

Trappist, I wonder whether disallowing "publisher=BBC News" is based on a misunderstanding.

Cite news is not only used for newspaper titles that need italics. BBC News is not a title (or "work") and should not be in italics. BBC News is a publisher, a division of the BBC. Similarly, it isn't always appropriate to use "website=" with cite web. Sometimes the publisher of that website is more appropriate, and publisher does not take italics (unless the publisher is also a title). For example, I might use cite web with "publisher=" for short reports, where I don't want the title of the report to be in italics:

• "Female genital mutilation". Geneva: World Health Organization. 31 January 2018.

In such cases, "website=www.who.int" is not appropriate, and in fact would look unnecessary and silly. The flexibility of these templates is a good thing, and I wish that flexibility could increase. Restricting them so that publisher= is not allowed would, I think, mean a certain number of people would stop using them. SarahSV ^(talk) 22:11, 3 September 2019 (UTC)

I don't think that there is a misunderstanding – on my part. Yes, there are news sources that are not newspapers, BBC News being one among many. When you talk about BBC News as a corporate entity (the business side of news journalism), the name is not italicized. When the corporate entity, BBC News, publishes an article, it does so in BBC News, the publication or work of BBC News the business entity. Because in this case, BBC News is a publication or work, it is italicized just as The New York Times is a publication of The New York Times Company.

So too, World Heath Organization website (who.int) is a publication of the corporate entity also called World Heath Organization. When citing the WHO website, the publication that you are citing is World Heath Organization. Because the publication and the publisher are the same, one may be dropped: publisher. There is no prohibition against |publisher=, it is allowed in all cs1|2 templates except the preprint templates ({{cite arxiv}} and the like).

Always, in cs1|2, you are citing a publication (because WP:V requires publication), never citing a corporate entity. Any utterances from a corporate entity must have been published in some sort of publication or work.

Beyond these semantic reasons there are also technical reasons why the periodical templates require a periodical parameter. If you wish I can explain that.

—Trappist the monk (talk) 22:43, 3 September 2019 (UTC)

I, and many others would disagree. Not all websites have names, and reusing the name of the publisher as a surrogate just isn't right either. When a website has a name, it should be given in italics, but where it doesn't exist, we shouldn't be forcing editors to make up one or duplicate the publisher. Imzadi 1979 → 23:02, 3 September 2019 (UTC)

Trappist, BBC News should never be italicized. It's not a title like The New York Times. Similarly, the World Health Organization is never italicized; it is a publisher. Those are style errors. I'm pinging Tony1 who may be willing explain further. Tony, the citation templates have been changed to disallow (?) "publisher=", so that entities such as BBC News are treated as titles (works) and are italicized. This is a misunderstanding, but Trappist (who has made the changes) is not accepting that. Can you assist? (Also see AN.) SarahSV ^(talk) 00:46, 4 September 2019 (UTC)

The BBC publishes a website called BBC News. It's one of many websites published by the BBC, including BBC Sport. It is a title; it's not a title of a paper publication like The New York Times, but the title of a website. (The WHO example is different, I agree.) Peter coxhead (talk) 01:31, 4 September 2019 (UTC)

That's not the name of a website. BBC Nine O'Clock News is a title. BBC News is the publisher. It's a division of the BBC. They don't italicize it: "BBC News has learned". [2] Anyway, the point is that we need publisher=. Trappist says it's allowed, but earlier all the articles I'd added it to were showing error messages. SarahSV ^(talk) 02:11, 4 September 2019 (UTC)

SarahSV, I agree with you that BBC News is an organisation, which publishes news. It is not a creative work, and should not be italicised. I have often thought that we need a pair of new parameters |program= and |programme=, so that the example you give would be coded using |publisher=BBC News and |programme=BBC Nine O'Clock News, with the programme title appearing in italics. Would be interested in your thoughts on this proposal. --NSH001 (talk) 09:48, 4 September 2019 (UTC)

• Agree with SarahSV: the name of an organisation is not italicised, and the "publisher" field is for non-italicised names of publishing outlets. Occasionally there's a grey area; but not here. Tony (talk) 02:52, 4 September 2019 (UTC)
• Trappist, I respect that you have a view on how these citation templates should be used, but it is not up to you to unilaterally enforce your view on the whole of Wikipedia. The simple fact is that you do not have consensus that the periodical parameters should be mandatory, only that its contents should be italicized if used. The AN thread shows that well over 90% of the people disagree with your stance regarding the periodicals parameters. I think it's well overdue now for you to acknowledge your mistake and revert your change making these parameters mandatory.Tvx1 05:14, 4 September 2019 (UTC)

Minor question about Monkbot task 16

Why does the bot remove the empty |df=? – Jonesey95 (talk) 20:01, 5 September 2019 (UTC)

Not just |df= which is very commonly empty so appears to be deleted specially (it's not), but any empty parameter that is found in a template that task 16 fixes. For instance, this diff. Why? that is your grace's part, because I like to take every legitimate opportunity to get rid of empty parameter clutter.

—Trappist the monk (talk) 21:59, 5 September 2019 (UTC)

Some people object fervently to removal of empty parameters. I do not know why they do so, but I try to avoid churning up their wrath. – Jonesey95 (talk) 23:58, 5 September 2019 (UTC)

Yours is a different experience from mine. Were you deleting all empty parameters on a page?

—Trappist the monk (talk) 00:38, 6 September 2019 (UTC)

No, I tend to remove only non-functional blank parameters, like |coauthors= and |month=, due to having seen editors complain about blank parameter removal (e.g. "They encourage other editors to fill in the blank information" or similar claims). I don't have an opinion either way, and I wish you clear sailing with your parameter removal. Thanks for taking care of the dead-url conversion with your bot. – Jonesey95 (talk) 02:05, 6 September 2019 (UTC)

It is not at all clear if that bot will ever run since the primary proposal at WP:AN includes reverting the deprecation.

—Trappist the monk (talk) 02:44, 6 September 2019 (UTC)

Clarity is not something that WP:AN is known for, which is why I almost always keep my distance. I agree with Primefac's assessment, however, that a mass revert seems unlikely. I think the requirement that |website= be present will be overturned, at least for a while, but the logic behind deprecation of |dead-url= in favor of |url-status= is strong, even though the error messages were annoying to many. – Jonesey95 (talk) 14:14, 6 September 2019 (UTC)