User talk:Mikeblas/Archives/2020/February

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

New message from Mac Henni[edit]

Hello, Mikeblas. You have new messages at Talk:Mærsk Mc-Kinney Møller (ship).
Message added 00:57, 1 February 2020 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

I added what I did to fix this issue. But it's still not solved! Maccore Henni Mii! Pictochat Mii! 00:57, 1 February 2020 (UTC)[reply]

Gene Weingarten[edit]

Sorry about that. I knew I'd have to fix that but there were so many steps to complete I just forgot.— Vchimpanzee • talk • contributions • 17:17, 1 February 2020 (UTC)[reply]

No worries at all~ -- Mikeblas (talk) 17:37, 1 February 2020 (UTC)[reply]

Trying quick and dirty Fix to the CenPop problem[edit]

Hi,

I'm about to try a quick and dirty fix to the CenPop script duplicate reference problem. Quick and dirty because it'll still essentially duplicate references, but it won't cause an error because they'll have different names. I hope that's okay for now? (Also I'm going to temporarily revert one of your fixes to test it, so heads up there). DemocraticLuntz (talk) 12:50, 10 February 2020 (UTC)[reply]

Okay, tested it on Keizer, Oregon (after reverting your change). After checking, the bug introduced was incredibly subtle! Technically, the duplicate reference problem was introduced by User:TylerKutschbach back in July of 2019 [1] but since the duplicate references were exactly identical, it didn't show up as an error. When the CenPop script ran, it used a slightly different date of citation for an otherwise identical reference, and that then shows up as a duplicate reference error.

The quick and dirty fix I mentioned above will eliminate the duplicate reference errors by having the CenPop script create references (for 2018 esimates) of the form <ref name="USCensusEst2018CenPopScriptOnlyDirtyFixDoNotUse">, which unlike <ref name="USCensusEst2018">, should deter any human users from using it as a tag. It's far from perfect, obviously, since it potentially still duplicates references, but it will fix the errors I introduced since it'll be a distinct reference tag. I hope to get it fixed later to prevent the bug described above from happening without essentially duplicating references, but that'll take a little more work and I can't do it this morning. If this makes sense to you, I await your heads-up before more extensive re-editing with the script to fix the problems I caused. Thanks and sorry for the problem. DemocraticLuntz (talk) 13:14, 10 February 2020 (UTC)[reply]

CaptainEek if you want to say it's okay since you also weighed in, let me know. 13:17, 10 February 2020 (UTC)
DemocraticLuntz Thanks for looking into it! I don't understand why there needs to be two references. If the script can detect that "CenPopGazetteer2016" exists, why doesn't it update it? What's the point of having two references two the same URL, each with different access-dates? -- Mikeblas (talk) 16:25, 10 February 2020 (UTC)[reply]
@DemocraticLuntz: Any progress to report? If not, I'll get to manually cleaning up. (BTW, @CaptainEek:, looks like Luntz and I were linking when we meant to transclude!) -- Mikeblas (talk) 13:58, 12 February 2020 (UTC)[reply]
@Mikeblas:, I don't think you're understanding the problem. The problem is that some OTHER Wikipedian introduced duplicate references, but the Wikipedia backend recognized them as identical. I didn't write my script to deal with situations where the page itself has errors it; it's fixable but I don't have time right now. I'll just go ahead and have two references for now, it's ugly but oh well. — Preceding unsigned comment added by DemocraticLuntz (talkcontribs) 14:58, 12 February, 2020 (UTC)
I understand the problem quite well, though maybe I don't agree with your own assessment. Before your script made edits, no error was rendered to the page. You've said that there is a pre-existing error -- but I don't know what evidence you have to support that claim because no error message is visible. More pedantically, I also know of no docuemntation for wiki markup which says that two indentically defined references with the same identifying name are an error.
Further, I think that good software (including scripts) will defend itself against bad input. Even if we stipulate that two identical references are an error, then adding another definition is also an error; and certainly a more severe error, as it generates a visible error message and adds the topic to a category of pages with errors. The topics in question (many dozens of them) were not in the error topic until after your edits.
With two duplicate definitions, any reference to those definitions is unambiguous; even thoug there are two definitions, they're identical and therefore indescernable. The edits you made with your script made that condition false: after your edits, a reference to one of those definitions was entirely ambiguous because your changes made the definitions unique.
I do admin that I don't understand the point of your script. If two duplicate definitions exist, what goal is realized by changing only one of those definitions, but not the other? I also don't understand your "oh well" comment; does that mean you won't be fixing the errors your script caused yourself? And that you'll continue to run the script, despite the problems it causing?

-- Mikeblas (talk) 21:03, 12 February 2020 (UTC)[reply]

Please don't help Dblchecker (talk · contribs) vandalize List of ministers of the Universal Life Church (edit | talk | history | protect | delete | links | watch | logs | views) by leaving a non-notable person on the list. (It's a redlink.) "Articles should not contain red links to files, to templates, or to topics that do not warrant an article, such as a celebrity's romantic interest who is not a celebrity in their own right, and thus lacks notability" per WP:Red link. Thanks. Me-123567-Me (talk) 03:27, 15 February 2020 (UTC)[reply]

I'm sorry, but I've got no idea what you're talking about. -- Mikeblas (talk) 14:24, 15 February 2020 (UTC)[reply]