User talk:SMcCandlish/Archive 172

Latest comment: 3 years ago by SMcCandlish in topic Drago's century
Archive 165 Archive 170 Archive 171 Archive 172 Archive 173 Archive 174 Archive 175

March 2021

Good article drive notice

This message has been sent to users signed up for the Good articles newsletter. Add or remove your name from the list to subscribe or unsubscribe from future updates. Alternatively, to opt-out of all massmessage mailings, you may add Category:Wikipedians who opt out of message delivery to your user talk page.

-- For the drive co-ordinators, MediaWiki message delivery (talk) 15:27, 21 February 2021 (UTC)

Mumbai/Bombay, Bangalore/Bengaluru

Hi, think you might now. Where is the Geo guideline that says use modern/current WP:RS? In ictu oculi (talk) 09:55, 12 March 2021 (UTC)

Maybe what you're looking for is WP:MODERNPLACENAME: "we are interested in what reliable English-language sources now use" and this "depends on ... having become predominant in common global usage. That can be assessed by reviewing up-to-date references to the place in a modern context in reliable, authoritative sources ...". It discusses Mumbai as a specific example. See also the explanatory note at MOS:GEO. There's also WP:NAMECHANGES. — BarrelProof (talk) 18:07, 12 March 2021 (UTC)
Yes, and there have been various previous discussions probably between the talk pages of those page and at various article pages, on using time-period appropriate names. E.g., in an article on the British Raj, we would not call it Mumbai since it was not called that then, though we probably should write "Bombay (modern Mumbai)" at first occurrence. Similarly, the capital of modern-day Turkey (and the late Ottoman Empire) is named Istanbul, and we don't refer to it in that context as Constantinople, nor use Istanbul in the context of the Byzantine Empire.  — SMcCandlish ¢ 😼  03:29, 13 March 2021 (UTC)
@BarrelProof: many thanks both of you. Crouch also pointed me at WP:MODERNPLACENAME. Should have known it was on the geo naming not Title. Cheers. In ictu oculi (talk) 12:31, 13 March 2021 (UTC)

Austria-Hungary

Do you agree with the Austria-Hungary example at MOS:DUALNATIONALITIES? I was preparing to comment on the RM at Talk:Travancore–Cochin in support of the dash, after the discussion at Talk:Brown–Forman, but now I'm rather confused. — BarrelProof (talk) 18:05, 12 March 2021 (UTC)

I do not. I'm going to raise a discussion about that on the MoS talk page, since insertion of that claims that "Austria–Hungary" is "wrong" has forced MOS:DASH to contradict itself, and the rationale given for it is bunk.  — SMcCandlish ¢ 😼  12:52, 13 March 2021 (UTC)

Disambiguation link notification for March 14

 
  Fixed

An automated process has detected that when you recently edited Steve Gibson (computer programmer), you added a link pointing to the disambiguation page Symantec.

(Opt-out instructions.) --DPL bot (talk) 06:32, 14 March 2021 (UTC)

Trouted

 

Whack!

You've been whacked with a wet trout.

Don't take this too seriously. Someone just wants to let you know that you did something silly.

You have been trouted for: having the most positively convoluted userpage I've ever seen (and tricking me into thinking you were an admin) :þ Swaare (talk) 16:50, 14 March 2021 (UTC)

Heh. Yeah, I'm no admin, just a WikiFossil. I've been on the system longer than probably 90% of the active admins. I guess the userpage is getting a bit crufty. Accumulates over time. I'm like an e-hoarder.  — SMcCandlish ¢ 😼  03:38, 15 March 2021 (UTC)

Feedback requests from the Feedback Request Service

 
  Done
 – all 4

Your feedback is requested at Talk:Woody Allen and Talk:Michael J. Fox on "Society, sports, and culture" request for comments, and at Wikipedia:Village pump (proposals) on a "Wikipedia style and naming" request for comment, and at Wikipedia:Requests for comment/Adminship term length on a "Wikipedia policies and guidelines" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 04:48, 19 March 2021 (UTC)

Thank you ...

 

... for improving articles in March! On Bach's birthday --Gerda Arendt (talk) 23:14, 21 March 2021 (UTC)

Thanks. That's music to my ears. After I compose myself, I'd better get bach to work, though.  — SMcCandlish ¢ 😼  04:55, 22 March 2021‎ (UTC)

Happy Nowruz!

Wishing you a happy Nowruz and spring season. Thinker78 (talk) 01:50, 22 March 2021 (UTC)

Definitely a better time of year to have a New Year's celebration than the dead of winter. The Persians thought this through.  — SMcCandlish ¢ 😼  04:57, 22 March 2021 (UTC)

Books & Bytes – Issue 42

The Wikipedia Library

Books & Bytes
Issue 42, January – February 2021

  • New partnerships: PNAS, De Gruyter, Nomos
  • 1Lib1Ref
  • Library Card

Read the full newsletter

Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --11:28, 22 March 2021 (UTC)

Hmm, PNAS and De Gruyter is tempting.  — SMcCandlish ¢ 😼  22:52, 22 March 2021 (UTC)
You should already be qualified to both of those - see https://wikipedialibrary.wmflabs.org/users/my_library/ which should let you access everything that's in the Library Bundle. -- Ealdgyth (talk) 23:34, 22 March 2021 (UTC)

Feedback requests from the Feedback Request Service

 
  Done
 

Your feedback is requested at Template talk:Infobox country on a "Politics, government, and law" request for comment, and at Talk:Enrique Tarrio on a "Biographies" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 22:31, 22 March 2021 (UTC)

Putting a comment in the Survey subsection of the MoS Internet discussion

I see you made a joke in reply to a comment in the survey subsection of the Internet discussion on the MoS talk page. I can't say I'm unamused :) There is only one small problem: I'd like to keep that area clear of any replies for readability, and I would have just moved your comment to the Discussion subsection, but because it's a joke, I'm not sure what to do with it. I guess it doesn't really matter if that one reply is up in the Survey subsection, but then there's inconsistency, and it might cause others to continue to reply in the Survey subsection too. I hesitate to move it to the Discussion section because it isn't actually discussion as such. Do you have any advice? :) Thanks, DesertPipeline (talk) 10:10, 21 March 2021 (UTC)

@DesertPipeline: This should do it.  — SMcCandlish ¢ 😼  20:28, 21 March 2021 (UTC)
I was actually thinking of that solution after I'd logged off – initially I was thinking "well shouldn't I add the response indicator if I move it? That seems a bit overkill for a joke response". Moving it and not adding a response indicator is probably the best solution :) DesertPipeline (talk) 02:57, 22 March 2021 (UTC)

Notwithstanding the beneficial tweak above, pretty much all of your comments on that page appear solid, and from what could be recognised as position of understanding of the issue. Frankly, I had nothing substantial to add given that you largely nailed it. Chumpih. (talk) 20:39, 21 March 2021 (UTC)

Thankee. I'll add that the purpose of my joke to was to defuse what appeared to be an intent to personalize / polarize / wiki-politicize the discussion; I ignored the jab and made a further joke building on the joke at the end of the jab, to lighten the mood and dismiss the jab by refusing to comment on it. Moving this banter out of the !vote section mostly thwarts the purpose of my response (which already got a Thank). But I don't think it's a big deal. The outcome of that RfC (discussion at which is winding down) is already pretty clear. I disagree vehemently with the direction it's going, but I know when I'm outvoted and am not going to WP:BLUDGEON about it; my response to Dicklyon will probably be my last there. I'm the first to point out that no one is happy with 100% of what MoS or any other guideline says, and no P&G line-item has buy-in from 100% of editors, so I have to live with that as well. In fairness, since this medium lacks facial expression, voice tone, etc., it is actually possible that the personalized animosity in the original post was itself intended as a joke, in which case my joke response helps to reinforce it as a {{FBDB}} situation; either way, I think my joke reply was the correct approach. I understand DesertPipeline's "thread management" purpose and observe that it has had the effect of keeping the !vote section clearer and easier to assess; I've sometimes taken this refactoring approach myself. In retrospect, another tactic I could've used would've been EEng's style of making joke replies with sidebars, but that thread is already heavy with those.  — SMcCandlish ¢ 😼  20:52, 21 March 2021 (UTC)
My heart swells with pride to see that my philosophy of giving humor serious consideration is diffusing more and more among our esteemed fellow editors. EEng 21:04, 21 March 2021 (UTC)
Well, pride is a deadly sin, so you're clearly bound directly for Hell.  — SMcCandlish ¢ 😼  21:24, 21 March 2021 (UTC)
I'm relatively new to those pages, and the levity and charm of those sidebars was a delight. Nice one User:EEng.Chumpih. (talk) 23:44, 21 March 2021 (UTC)
For sure it's tricky for the spirit in which a comment was made to be conveyed by the comment itself. There's some quote along the lines of "it is the curse of those who express themselves to be misunderstood" - I'll try and find it.
And re. the whole "Internet" issue: language shifts over time, even in more formal circles. Your stance strikes a sensible balance. Chumpih. (talk) 23:31, 21 March 2021 (UTC)
Karl Popper: "Always remember that it is impossible to speak in such a way that you cannot be misunderstood: there will always be some who misunderstand you." (on reflection, I think the words above are sweeter) Chumpih. (talk) 23:34 + 23:44, 21 March 2021 (UTC)
The outcome of that RfC ... is already pretty clear.
I'm obviously going to be biased here, but I feel like those of us in favour of capitalisation for Internet as a name have a stronger position than those who favour no capitalisation. Their position is "others don't do it any more" and ours is "it's a proper noun" – which I still feel is true, and still feel can't be taken away by popular opinion. I probably shouldn't speak without checking, but has anyone who is against capitalisation put forward the position "it's incorrect to capitalise it"? I'm pretty sure all that's been said is "it's not done now", so they're not suggesting it's wrong. There may be more responses in the "don't capitalise" subsection, but this is exactly why I placed that reminder about WP:NOTVOTE – yes, that option has the numerical advantage, but I don't think those in favour of it are giving convincing rationales. Again though: Most probably biased :) DesertPipeline (talk) 02:57, 22 March 2021 (UTC)
Nah, the entire argument for lower-case "internet" is simply the WP:Common-style fallacy. I.e., whatever is most common, stylistically, in news and other lowest-common-denominator media is somehow what WP must do. (If this fallacy were not a fallacy, WP would have no need of a style guide at all; we'd just follow AP Stylebook, since it accounts for by far the dominant style in English-language news publications by count of both number of works and number of readers.)  — SMcCandlish ¢ 😼  04:53, 22 March 2021 (UTC)
Perhaps you could mention that in the discussion section under a new bullet point? It's a good point :) DesertPipeline (talk) 07:54, 22 March 2021 (UTC)
Someone else should. I've already said over-much there, and the point is already implicit in what I've posted in several comments.  — SMcCandlish ¢ 😼  10:55, 22 March 2021 (UTC)

Template:Db-g11

I am not sure what problem your edit of 21:57, 13 December 2020 of Template:Db-g11 was intended to solve. In Draft:DJ Omen we have {{db-spam|category=biography|reason=biography}}, and with the help of Special:ExpandTemplates, we see that the newly inserted </b> in your edit shows up here as stripped. —Anomalocaris (talk) 07:44, 25 March 2021 (UTC)

@Anomalocaris: You can just test this stuff for yourself in a matter of moments. See User:SMcCandlish/sandbox22 (the template and its sandbox will need to be in the same state when you look at that page as they were was when I wrote this).  — SMcCandlish ¢ 😼  09:20, 26 March 2021 (UTC)
OK. I went to User:SMcCandlish/sandbox22, edited it, and clicked on lintHint, which I have installed, and it reports a stripped </b> for the markup {{Db-g11|category=biography|reason=My comments}}, but not for the sandbox version. This agrees with what I reported before. Anomalocaris (talk) 09:29, 26 March 2021 (UTC)

@Anomalocaris: Well, look at the actual rendered output. The intended difference is working (the boldface of "This template may meet ... Requester's additional rationale:" does not continue on and boldface the full text of that rationale). Not sure what to tell you. The rendered HTML received by the user agent is well-formed:

                              <b>
                                 <i>
                                    This user page may meet Wikipedia's
                                    <a href="/wiki/Wikipedia:Criteria_for_speedy_deletion" title="Wikipedia:Criteria for speedy deletion">
                                       criteria for speedy deletion
                                    </a>
                                 </i>
                                  because in its current form it serves only to
                                 <a href="/wiki/Wikipedia:Spam" title="Wikipedia:Spam">
                                    promote
                                 </a>
                                  or publicise an entity, person, product, or idea, and would require a fundamental rewrite in order to become encyclopedic.
                                 <br/>
                                 <i>
                                    Requester's additional rationale:
                                 </i>
                              </b>
                               My comments: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum..

So, maybe lintHint has some kind of problem. Oh, what might be happening is that the parser maybe isn't smart enough to recognize an explicit </b> as closure of a <b> element that was opened by means of ''', so it is injecting a closing ''' after this, at whatever point such a closure is forced by the beginning of a new block element, and then later stages of the parser are removing that as dead code, so lintHint sees it being stripped out. This seems like a non-problem to me, the parser doing its job. I'm not sure how to "fix" it anyway. If we told the underlying meta-template to use explicit <b>...</b> HTML, it would still end up getting another one to strip out later (because the template would say to insert it there; it wouldn't be auto-generated). If we wrapped |reason='s input in a <div>...</div> with font-weight:normal, that would (being a block element) force auto-closure of the <b>, and again produce a redundant </b> later (auto-generated as in the current code). If we wrapped |reason='s input in a <span>...</span> with that CSS, it would be invalid if the input contained any block elements, like an explicit <p>...</p>, a {{pb}}, or even just a blank line that autogenerated a para. break.  — SMcCandlish ¢ 😼  09:52, 26 March 2021 (UTC)

I don't think it is correct to infer from the fact that rendered output is well-formed HTML that wikitext is correct. I did a simple test.

{|
|<b>This is bold with a closing tag.</b>
|This is normal
|<b>This is bold without a closing tag.
|}
out of table

This generated generated the following HTML:

<table>
<tbody><tr>
<td><b>This is bold with a closing tag.</b>
</td>
<td>This is normal
</td>
<td><b>This is bold without a closing tag.
</b></td></tr></tbody></table>
<p>out of table
</p>

The parser fixed my missing </b> for me, but the tag is still missing.

I agree with you that your addition of </b> does something useful, but note that Information for "Draft:DJ Omen" reports 1 stripped tag. It's not just lintHint, the error is really there. —Anomalocaris (talk) 10:26, 26 March 2021 (UTC)

This seems to be philosophic/semantic hair splitting. Whether the wiki code that's fed into the parser is perfect is ultimately irrelevant as long as it's within the parser's known handling capabilities, produces end-user correct HTML, and (ideally) on the editorial side isn't confusing, or at least not so confusing that s question or a review of talk comments doesn't resolve the confusion. We depend on every single day on the parser's own cleanup capabilities with regard to input – in parsing of talk pages, for example, which do all kind of awful things with list markup (by design) and in handling people's accidental or ignorant markup mistakes (like many a non-closed element, and frequent use of invalid elements, and so on). Even a lot of the markup used in our articles is blecherous (mismatching types of list markup, etc.).  — SMcCandlish ¢ 😼  10:37, 26 March 2021 (UTC)
I agree with you that the parser fixes a lot of mistakes and that it is helpful that it does this. But I also think that responsible Wikipedians should work to avoid lint errors, not intentionally introduce them, and cooperate with efforts to eliminate them. Your edit introduced a closing </b> in the middle of an existing <b>...</b> generated by {{db-meta}}. It really is an error. However, any transclusion of {{Db-g11}} would be expected to be temporary. If this were a navigation template I would definitely insist that even a low-priority lint error must be fixed. Given the intended brief duration of any transclusion of {{Db-g11}}, for the moment I will let the matter drop. I may revisit it, though. Cheers! —Anomalocaris (talk) 11:33, 26 March 2021 (UTC)
@Anomalocaris: I'm not meaning to suggest it should not be fixed, but I care (as I think most editors do) about end results at the user side, so I can't get worked up about this. I already have "work[ed] to avoid [the] lint error", as I've already walked you through in some detail. I've hardly been "irresponsible", I simply have limited amounts of volunteer time, and have to devote them to thing that actually make a practical difference. There is no simple solution, without doing a bunch of Lua (which I'm not really competent at) in the meta-template/module behind this stuff, to detect a </b> in input and suppress the one that would normally be generated otherwise. Or, on some additional thinking, it might actually be as simple as moving the original </b> or ''' (whichever it is), so that it it occurs before |reason=, and thus that parameter would no longer need any means of ending the boldface sooner. If we go that route, it would also be nice to move the closing "." so that it not forced after |reason=, which is apt to result in ".." since most people add a "." at the end of whatever sentence they'll write in there. But this is such a internal-oriented and short-term template I don't care much, honestly. :-)  — SMcCandlish ¢ 😼  12:02, 26 March 2021 (UTC)
I do not anticipate that ''' being closed by </b> will be supported forever if at all in the future when Parsoid becomes the one parser. Best to try to sort out the issue today rather than later. Izno (talk) 21:19, 26 March 2021 (UTC)
Sure. Again, I have no objection to finding a fix, it's just not rating high on my personal priority list. I think tweaking the underlying meta-template is the solution. I'm pleased to see that it ({{db-meta}}) is a regular template not a Lua module, so it should at least not be difficult.  — SMcCandlish ¢ 😼  01:05, 27 March 2021 (UTC)

Drago's century

Just occurred to me that Drago's century might be faster than 3:31, akin to trimming Ronnie's maximum time from 5:20 to 5:08. Splićanin (talk) 06:41, 27 March 2021 (UTC)

That'll be something to raise, with reliable sources, at the talk page of his article that or that of the event or where ever the claimed record belongs.  — SMcCandlish ¢ 😼  13:11, 27 March 2021 (UTC)
@Splićanin: forgot to ping you.  — SMcCandlish ¢ 😼  06:49, 1 April 2021 (UTC)

Feedback request: Politics, government, and law request for comment

 
  Done

Your feedback is requested at Talk:Cultural Marxism conspiracy theory on a "Politics, government, and law" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 21:31, 29 March 2021 (UTC)

Feedback request: Language and linguistics request for comment

 
  Done

Your feedback is requested at Talk:Goths on a "Language and linguistics" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 18:32, 31 March 2021 (UTC)