User talk:Trappist the monk/Archive 26

Unmarking dead links as dead

Why are you unmarking dead links marked as dead? : https://en.wikipedia.org/w/index.php?title=National_University_of_Natural_Medicine&curid=5916377&diff=1182997534&oldid=1179004373 The 3 links are all dead. RudolfoMD (talk) 23:09, 3 November 2023 (UTC)

|url-status= is a control parameter that determines which of |url= or |archive-url= links |title=. It has no other purpose. cs1|2 templates assume that the inclusion of |archive-url= with an assigned value means that the value assigned to |url= is dead. Repeating that signal by including |url-status=dead is unnecessarily redundant and so does nothing to improve the quality of the rendered citation. The important keyword for |url-status= is live. That keyword causes the rendering to be different. Here are some examples:

• without |url-status=:

  {{cite book |title=Title |url=https://example.com |archive-url=https://archive.org |archive-date=2023-11-03}}

  Title. Archived from the original on 2023-11-03.

• with |url-status=dead:

  {{cite book |title=Title |url=https://example.com |archive-url=https://archive.org |archive-date=2023-11-03 |url-status=dead}}

  Title. Archived from the original on 2023-11-03.

Notice that both of those renderings are identical.

• But, if you set |url-status=live, that does change the original- / archived-url order in the rendered citation:

  {{cite book |title=Title |url=https://example.com |archive-url=https://archive.org |archive-date=2023-11-03 |url-status=live}}

  Title. Archived from the original on 2023-11-03.

I remove |url-status=dead from cs1|2 templates that have |archive-url= with an assigned value because |url-status=dead does not make better citations.

—Trappist the monk (talk) 23:25, 3 November 2023 (UTC)

Ok, makes sense now. Thanks. --RudolfoMD (talk) 02:09, 4 November 2023 (UTC)

I understand this, and I've checked the discussion at the CS1 talk page, but like SMcCandlish argued over there, I still don't understand the point of these cosmetic edits. DFlhb (talk) 18:33, 4 November 2023 (UTC)

Show me the evidence that you have to support your cosmetic edits accusation. Removal of |url-status=dead is always secondary to some other reason for me to be editing an article. Lately the other reasons have been to clear Category:CS1 maint: uses authors parameter by replacing |authors= (a discouraged parameter) with individual enumerated |authorn= parameters and to pluck off the low hanging fruit from Category:CS1 maint: multiple names: authors list by removing a comma from |first=<name>, <generational suffix> per MOS:JR.

—Trappist the monk (talk) 18:51, 4 November 2023 (UTC)

This was neither accusation nor threat; thanks for fixing CS1 errors, because I sometimes do those manually and it's a pain. With |url-status=dead, I just don't see why you'd bother, since the change has no functional impact. Maybe my intent would have been clearer if I hadn't linked to that policy? DFlhb (talk) 19:06, 4 November 2023 (UTC)

I remove |url-status=dead, as I've explained more than enough times recently, because |url-status=dead does nothing, is meaningless, is just clutter. I have a user script that makes it painless – one click and |url-status=dead parameters are gone. The awb version of the script will also remove the equally pointless |url-status=live from cs1|2 templates that don't have |archive-url= with an assigned value. So, I bother because it doesn't cost me anything to bother (though I'm beginning to question the validity of that statement).

—Trappist the monk (talk) 19:41, 4 November 2023 (UTC)

On that last point: please go ahead, I didn't mean to be a pest. People will do it all of this anyway, it might as well be done by script. I also hadn't noticed, in the diff that brought me here, that there were other changes besides that parameter DFlhb (talk) 18:57, 7 November 2023 (UTC)

Seem counterproductive to me, and a violation of wP:Bot policy, which I just read. I didn't know there was a larger problem. I had thought there were substantive changes too - one fixing a CS1 error - but upon looking closer, I can find none. You claim, " Removal of |url-status=dead is always secondary to some other reason for me to be editing an article." But in the case of this edit, I see no substantive edit. The closest thing to that is removing a comma that arguably shouldn't even have been removed (though the consensus is in favor). The policy states, "Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change." Do you see that per the linked definition Wikipedia:Bots/Dictionary#Substantive_edit, your edit was perhaps not in accord with policy? (It includes, "However, the term cosmetic edit is often used to encompass all edits of such little value that the community deems them to not be worth making in bulk, even though those edits might change the output HTML or readable text in subtle ways.") Maybe don't keep making such edits?

Perhaps you can help with something particularly valuable instead? I could really use some help debugging a template change I'm trying to make. I'm trying to get Template:Infobox drug/sandbox (and the main template) to show there's an important safety warning based on wikidata I'm importing. The code works in a page, but not when I move it into a template. I can't figure it out. Could save lives. RudolfoMD (talk) 00:26, 5 November 2023 (UTC)

If you are going to accuse me of violating Wikipedia:Bots/Dictionary § Substantive edit, you must show evidence of that violation. You wrote: But in the case of this edit, I see no substantive edit. What edit?

—Trappist the monk (talk) 00:45, 5 November 2023 (UTC)

I suspect that whatever problems you may be having with Template:Infobox drug/sandbox are caused by too many {...} pairs. This line for example:

{{{#ifeq:{{{#invoke:String|match|s={{{#property:P3493}}}|pattern=boxed warning|plain=true}}}|one}}}

should perhaps be rewritten:

{{#ifeq:{{#invoke:String|match|s={{#property:P3493}}|pattern=boxed warning|plain=true}}|one}}

Double {{...}} for templates, module invokes, magic words, and parser functions. Tripple {{{...}}} for template parameters.

—Trappist the monk (talk) 00:55, 5 November 2023 (UTC)

Thanks, but I first tried it (the template code) with double instead of triple curly braces and it didn't work. That's the problem: " The code works in a page, but not when I move it into a template. " That's why I tried every combination of 2 and 3 matching curly braces. I've put it back to two braces. Result doesn't work (when I temporarily edit Brincidofovir to use the sandbox template).

I showed evidence of your edit that "was perhaps not in accord with policy" of course. Link in the OP of this thread. I thought it was obvious that it's the edit being discussed, but it had been posted a couple days earlier. RudolfoMD (talk) 23:08, 6 November 2023 (UTC)

I haven't inspected your sandbox code since my post about extraneous {...} pairs. Just looking more closely at the code above I have to wonder, do you really need Module:String? Brincidofovir is brincidofovir (Q15411004) so, to fetch legal status (medicine) (P3493) on this page:

{{#property:P3493|from=Q15411004}} → boxed warning

If I want to know if the returned string is boxed warning I can write this:

{{#ifeq:{{#property:P3493|from=Q15411004}}|boxed warning|yes|no}} → yes

What do you want the output to be when the infobox is rendered?

The 'substantive' portion of the edit was only the removal of a comma that violates MOS:JR but that removal gets the article out of Category:CS1 maint: multiple names: authors list – first you remove the low hanging fruit so that you can see what remains and then attack the next lowest hanging fruit; wash rinse repeat.

—Trappist the monk (talk) 00:12, 7 November 2023 (UTC)

Some drugs have several legal statuses. So I think yes? e.g. https://www.wikidata.org/wiki/Q57055. Wostr came up with the code.

I want the output when the infobox is rendered to be ${\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}$.

It seems to be working almost correctly. The footnote appears at Brincidofovir&diff=prev&oldid=1183863257#References, but ${\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}$ does not appear in the infobox. The code works in a page, but not when I move it into a template. I can't figure it out.RudolfoMD (talk) 07:04, 8 November 2023 (UTC)

It isn't working because the {{#ifeq:...}} is malformed. The syntax is:

{{#ifeq: string 1 | string 2 | value if identical | value if different }}

In your test, string 2 is the Boxed warning wikilink, <math>...</math> and <ref>...</ref> markup. The string returned from wikidata will never match that.

Still not obvious to me why you think you need this:

{{#invoke:String|match|s={{#property:P3493}}|pattern=boxed warning|plain=true}}

Consider simplifying your test to looking for an identical match to the string boxed warning. Get that working first and then, if it is necessary, use Module:String to match variants of boxed warning. Here is a simplified test that works:

{{#ifeq:{{#property:P3493|from=Q15411004}}|boxed warning|[[Boxed warning]]}}

Boxed warning

To use that in Brincidofovir, remove |from=Q15411004 from {{#property}}.

I suspect that your use of <math>...</math> markup violates accessibility rules because 'WARNING' is not a mathematical equation (screen readers may not read and speak the 'warning' correctly). Because your warning box is so large, you might want to discuss this proposal at WP:MED before you implement it in a live article.

—Trappist the monk (talk) 15:29, 8 November 2023 (UTC)

Like I said, "Some drugs have several legal statuses. So I think yes [we really need Module:String] for e.g. https://www.wikidata.org/wiki/Q57055..

Sinc you don't get it, here are some specifics. Thus {{#ifeq:{{#property:P3493|from=Q57055}}|boxed warning|yes|no}} doesn't do the appropriate calculation as [result:General sales list (UK), FDA-approved, boxed warning|boxed warning|yes|no}}] compares on"General sales list (UK), FDA-approved, boxed warning" should be yes - hence the need for Module:String:

"General sales list (UK), FDA-approved, boxed warning" != "boxed warning"

so your simplification doesn't work. RudolfoMD (talk) 05:59, 14 November 2023 (UTC)

https://www.wikidata.org/wiki/Wikidata:How_to_use_data_on_Wikimedia_projects#Multiple_values explains why. I may have been "inadvertently" led to put the data into wikidata this way to make the overall task harder to accomplish. RudolfoMD (talk) 06:36, 14 November 2023 (UTC)

I think I got it:

boxed *** warning

nil

:-)

RudolfoMD (talk) 07:21, 14 November 2023 (UTC)

References

Biotin carboxyl carrier protein#References

Hi, have you got a tool to (semi-)automatically clean up this mess? Leyo 08:17, 20 November 2023 (UTC)

Alas, I don't. But, I realized that all of that mess is a listing of most (all?) of the chapters in a single book, so I created a single {{cite book}} template for the book and deleted the mess. Not the optimal solution but better than what we had.

—Trappist the monk (talk) 14:51, 20 November 2023 (UTC)

Okay, thank you. --Leyo 16:05, 20 November 2023 (UTC)

ArbCom 2023 Elections voter message

Hello! Voting in the 2023 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 11 December 2023. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2023 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:32, 28 November 2023 (UTC)

Phabricator T348928 (accented characters in citations in mobile view)

Tracked in Phabricator
Task T348928

Dear Trappist the monk, thank you very, very much for having logged the bug T348928 "mobile view uses URL encoding when it should use anchor encoding", concerning accented characters in shortened footnote citations in mobile view. Such bugs, I have the impression, take a long tome to be fixed.

I found a work-around that consists of giving the correct name with the accented characters in "Cite book"'s "author" or "last" parameter but defining an unaccented equivalent in its "ref" parameter. I then use the unaccented equivalent in Harvnb. Please see "Ó Ciardha" (2009) in Richard Hamilton (officer) for an example. I intend to implement this work-around extensively from now on. With many thanks and best regards, Johannes Schade (talk) 12:55, 28 November 2023 (UTC)

Don't hold your breath.

—Trappist the monk (talk) 13:46, 28 November 2023 (UTC)

You might change your hidden note to include a reference to phab:T348928 so that others can know what problems are being avoided.

—Trappist the monk (talk) 13:53, 28 November 2023 (UTC)

Chilling

I welcome your intervention. Jonesey95 "would rather not hear from [me] again". The feeling is mutual. So I won't engage Jonesey95 further unless engaged, thank you very much, unless you insist I override that request. I already acknowledged my error, in several ways including 1. Struck warning. 2. "Partly." 3. "Struck warning." AND 4."I have now figured out that ... your edit did reduce later indentation back to normal also., before you intervened. If you think my warning, "You can not like it, but stop falsely portraying my proposed edit as adding unreferenced info to wikipedia and not following the RFC." was unfounded as you see it, please explain why, and if not, please say so. Am I mistaken that no explanation has been given? If it should have been better expressed, I'm open to suggestions and learning from them. It seems unambiguous that 1)he made the claims, repeatedly, and 2)I made it readily evident they lacked foundation. You can see I'm not above admitting error, yes? It seems clear to me that Jonesey95 hasn't even acknowledged error in falsely portraying my proposed edit as adding unreferenced info to wikipedia and not following the RFC, let alone explicitly apologized for it. How do you think that makes me feel? My error, which I promptly acknowledged, was due to lack of obscure technical knowledge.

I said, Be aware that that false assertions of personal attacks are themselves personal attacks. while Jonesey95 said, Claiming someone keeps accusing someone of things that are untrue is wrong. _{(almost exact wording)} These say much same thing in a different way, showing we agree on principle. And facts matter.

By the way, why don't you move my edit live? What holds you back? Curious that no admin cares to even respond when, as a bonus, warning of these particularly important safety issues may, just perhaps, thereafter regularly prevent iatrogenic catastrophes. And even though Jonesey95 indicated * Pppery * misread their comment as an objection to my edit. RudolfoMD (talk) 03:30, 30 November 2023 (UTC)

I added my comment because you left this:

You know...you've already pissed me off several times by making false claims, don't add to it by editing my comments. Lint schmindt. Don't do it. This.

That indicates to me, regardless of what you now claim here, that you still believe that Editor Jonesey95 was in the wrong. He was not. I am not interested in the rest of the discussion on his talk page.

I will not move Template:Infobox drug/sandbox to Template:Infobox drug because I believe that you should not be using math markup for presentation for reasons of accessibility. I've said as much before (this discussion here).

—Trappist the monk (talk) 04:01, 30 November 2023 (UTC)

A barnstar for you!

	The Technical Barnstar
	Fell down a rabbit hole of your contributions spanning many years. Thank you for all the technical work that you do: especially that relating to citations. It is noticed, and appreciated 🙂 Johnson524 15:49, 30 November 2023 (UTC)

Superfluous warning

Perhaps it doesn't matter very much, but any idea why your harv/sfn error highlighting script is unhappy with Roux (1992) in Elba? AFAICS the word "Roux" only appears twice in the wikitext (in the sfn and the CS1 template) so perhaps the issue is a syntax error elsewhere which is breaking the parsing? Best, Wham2001 (talk) 11:38, 16 December 2023 (UTC)

Are you sure? I'm not seeing any script messages in Elba; 'Roux' is not in the wikitext (or the rendered article); the article does not use {{sfn}} or any to the {{harv}} templates. Some other article perhaps?

—Trappist the monk (talk) 12:50, 16 December 2023 (UTC)

Ebla not Elba. I guess I need another coffee! Thanks Wham2001 (talk) 12:59, 16 December 2023 (UTC)

{{Early Rulers of Mesopotamia}} has a reflist which has Roux 1992.

—Trappist the monk (talk) 13:14, 16 December 2023 (UTC)

Ohhhh I see! The lua module check doesn't expand templates hence it's not in the maintainence category, and by default it's rendered collapsed so I couldn't find it with ctrl-F in the browser. Thank-you for enlightening me! Wham2001 (talk) 13:22, 16 December 2023 (UTC)

Merry Christmas and a Prosperous 2024!

Hello Trappist the monk, may you be surrounded by peace, success and happiness on this seasonal occasion. Spread the WikiLove by wishing another user a Merry Christmas and a Happy New Year, whether it be someone you have had disagreements with in the past, a good friend, or just some random person. Sending you heartfelt and warm greetings for Christmas and New Year 2024. Happy editing, GoingBatty (talk) 19:49, 24 December 2023 (UTC) Spread the love by adding {{subst:Seasonal Greetings}} to other user talk pages.

GoingBatty (talk) 19:49, 24 December 2023 (UTC)

Template:Limited access

You are the sole editor of Template:Limited access/doc, so I thought you might be interested in a merge discussion at Wikipedia:Templates for discussion/Log/2023 December 28 § Template:Limited access. Daask (talk) 23:42, 28 December 2023 (UTC)

Thanks. Replied there.

—Trappist the monk (talk) 00:29, 29 December 2023 (UTC)

It's that time of the year again... (CS1 update)

Hello Trappist and happy soon to be new year! (if you celebrate it)

I'm updating the suite of CS1 for my homewiki and I noticed that there has been increased i18n support in /Config file. At least it has been made more obvious.

This makes me unsure now if I should do some changes I usually do in the other files or not. I'm listing them below.

This is the self-notice I had given myself in regard to knowing what local extra changes we have beside the EnWiki version:

utilities.set_message ('err_language_missing'); -- emit an error message and add to category (Main) + GABIM ME PËRPUNIMIN MATEMATIKOR (COinS) + 3 lines True (Configuration - Exports) + gjuha → language (Suggestions) + this edit (Date validation)

That all means I need to add that first line in the main page (which I've done here), I need to update a single string in the COinS page (which I've done here), I need to change 3 lines into being true in the Configuration page, Exports part (which I haven't done yet as I haven't touched the Config. file yet), I need to add +1 suggestion in the Suggestions page (which I've done here) and lastly I need to make this edit in the Date validation page (which as you can see I've already accomplished it).

Now, do I still need to make those changes even with the updated version of the ~/Configuration page? I know I do need to translate that string in COinS and add that suggestion in Suggestions (in the past we've talked about transporting that string elsewhere and incorporating the suggestion in the EnWiki version but you've been against both those suggestions, I suppose you still are); I'm asking about the other remaining edits.

Thank you in advance! - Klein Muçi (talk) 16:52, 29 December 2023 (UTC)

I think that you need to make all of those changes because making changes to the en.wiki version of the cs1|2 module suite to support only one language-variant is not something that I'm willing to do. That just opens the door to making small customizations for each and every wiki the uses the modules; cs1|2 is bloated enough without that.

Not surprisingly, I don't recall talking about |gjuha= and the need for it to be listed in ~/Suggestions. Surely your robot can be trained to replace that with |language= and so remove the need for that one parameter to be included in ~/Suggestions, can't it? Or, if that parameter is somehow important, you can add it at line 265 in ~/Configuration.

—Trappist the monk (talk) 17:35, 29 December 2023 (UTC)

Maybe you're confusing my requests a bit.

Regarding those edits I listed, I wasn't expecting changes to be done to the en.wiki version. I thought those changes were for some reason already implemented in it. I was led to believe this because of the series of switches that have been "lately" (?) added to the top part of ~/Configuration. In there I saw at a quick glance switches about "auto-changing" numbers, date formats and even auto-categorizing local languages, which is more or less what those edits I listed do. That's why I'm asking "Do I still need to do those edits or will the said switches - and other changes I have yet to check in ~/Configuration - take care of those functionalities now?".

In regard to this line and |gjuha= this is where what you've said above is true. We've talked about these issues in the past: About how that line is the only string in ~/COinS that needs to be localized and thus if it can be exported in ~/Configuration to free that page (COinS) from the need of localization and how a common "mistake" Albanian editors make is to put |gjuha=language name to try and solve the language missing problem and thus if it can be added in the en.wiki version together with the other suggestions for other languages, again, to free that page (Suggestions) from the need of localization. You haven't elaborated much about the said string (COinS - L-139) but have said - like you just did - that the en.wiki version one is already bloated enough without starting to incorporate specific local requests in it and that the foreign strings that are already there are there because they are very present in en.wiki articles, unlike |gjuha=.

My bot is trained to fix that. The problem is that my bot gets activated once a month. Editors want to fix the "diabolic red error" immediately and panic if they can't, hence the suggestion. Exporting it into ~/Configuration comes with the newly made assumption that every parameter must work with its Albanian homologue which is not true. - Klein Muçi (talk) 18:05, 29 December 2023 (UTC)

MATH RENDER ERROR appears in three archives of this talk page:

• User talk:Trappist the monk/Archive 19 § Module update where I wrote: The only people who will ever see that text are those who consume cs1|2 citations using reference management software so I wouldn't bother translating it.
• User talk:Trappist the monk/Archive 22 § And so it begins... where I wrote: I don't see any need for that to be translated because only those who consume cs1|2 citations via the metadata will ever see it.
• User talk:Trappist the monk/Archive 23 § CS1 - Miscellaneous where you mentioned MATH RENDER ERROR; I had nothing new to say about that so didn't.

I continue to believe that MATH RENDER ERROR does not need to be translated.

The current version of sq:Moduli:Citation/CS1/Configuration (9 July 2022) has at lines 2133–2136 the same four settings flags as en.wiki. In the current en.wiki version of ~/Configuration those settings flags have moved to the top of the module code. We added a new setting to that list: enable_sort_keys. Because those settings have only moved, you will likely want to set them the same as the 9 July 2022 settings.

—Trappist the monk (talk) 18:49, 29 December 2023 (UTC)

I understand now. Thank you for the extra clarifications! I will continue with the ~/Configuration update and hopefully won't need much help from here. - Klein Muçi (talk) 22:45, 29 December 2023 (UTC)

Asking questions on real time so I don't forget and get confused in the end:

• What do local use_identifier_redirects = true; and local enable_sort_keys = true; do in a simple language?
• Can you provide two rendered examples of ['art'] = '$1 Art. $2', and ['vol-art'] = '$1 Vol. $2, art. $3', so I have context to translate them?

- Klein Muçi (talk) 23:18, 29 December 2023 (UTC)

At sq.wiki you already enable use_identifier_redirects. The purpose of that switch is to prevent cs1|2 templates from flooding sq:Speciale:LidhjetKëtu listings for identifier articles. For example, at en.wiki there are 1.6 million articles that have some sort of cs1|2 template with |isbn=. If the templates all linked to ISBN (the canonical article title) it would be impossible to know which links came from articles. By linking to the ISBN article through ISBN (identifier), Special:WhatLinksHere/ISBN lists actual links from articles to ISBN.

enable_sort_keys is new. Setting this flag to true causes Module:Citation/CS1 to add sort keys to category links when the page is non-mainspace. The sort keys are Greek letters so when enabled, non-mainspace pages are listed at the end of the category listing. The sort keys are ω (omega) Wikipedia; τ (tau) template; Δ (delta) draft; ο (omicron) all others. See this category page for an example.

|article-number= is new and is supported only by {{cite journal}} and {{cite conference}}. {{cite journal}} does not require any translation

{{cite conference |title=Conference Paper |book-title=Proceedings |article-number=12345}}

"Conference Paper". Proceedings. Art. 12345.

{{cite conference |title=Conference Paper |book-title=Proceedings |volume=XIV |article-number=12345}}

"Conference Paper". Proceedings. Vol. XIV, art. 12345.

—Trappist the monk (talk) 00:05, 30 December 2023 (UTC)

Thank you! The examples helped a lot. Apparently I need to translate only the "vol" part.

QoL idea: Add (new) as a comment on newly added features? - Klein Muçi (talk) 01:54, 30 December 2023 (UTC)

I finished updating the configuration module and I have my, hopefully, last questions for this update:

• Can you give me a general outline of the category changes that were made? What was newly introduced and what was removed and possibly some general reasons? I'm specifically interested about this category: maint_overridden_setting but I'd appreciate any extra info.
• I already asked about the 7 settings at the top of the page but would it be possible to provide some concrete examples about how the date and digit features would affect my homewiki? Currently I've set everything to true.
• Can you tell me what this whole C S 1 _ C O N F I G _ G E T code block is about in general terms?

- Klein Muçi (talk) 12:55, 31 December 2023 (UTC)

We created Module:Citation/CS1/doc/Category list to answer the category changes question. You have a copy of that (though it looks like it needs an update).

Albanian uses the western digits, right? If so, the two digit settings can/should be set to false because you aren't translating those.

For rendering consistency, we have created {{CS1 config}} which in and of itself does nothing. The module reads that template in wikitext and applies the settings that it finds to all cs1|2 templates in an article. At en.wiki some editors prefer to render only three author names + 'et al.' in references with more than three authors (this sort of thing seems especial prevalent in medical articles). To accomplish that, they can set |display-authors=3 in each and every cs1|2 template with more than three authors. Instead of doing that editors can add {{CS1 config|display-authors=3}} so that the module automatically limits the author display to three authors.

—Trappist the monk (talk) 15:06, 31 December 2023 (UTC)

Thank you!

What happens if we translate them nonetheless? Extra computational power wasted? Asking just out of curiosity, I'll switch to false.

Regarding the category changes, I didn't want the list per se. I was mostly interested in what "purpose they served" so that I could know what to write in their description pages. For example, I do understand what the ones for medRxiv or Bibcode actually do but I'm unsure about the ones for numerical names or especially the one regarding overridden settings. If you already have created them here though, I'll try to study from there I suppose.

Regarding Moduli:CS1 documentation support, I'd beg you consider a small overall rearrangement of its code in the future. I dread every update of it: There are localized strings everywhere and that forces you to update manually line per line. Not to mention that some of its translatable text is chopped down between different strings (to make up a full sentence) which sometimes means rewriting the whole thing when translating. :/ - Klein Muçi (talk) 16:14, 31 December 2023 (UTC)

Only wasted power up the power plant's exhaust stack in the form of CO₂ and waste heat.

Yeah, look at our categories for explanations. If you don't find your answer there ask again.

I hacked sq:Moduli:CS1 documentation support. The hack was required because you updated from en.wiki directly to your live module suite thereby breaking Moduli:CS1 documentation support. Don't do that. Update from en.wiki to your sandboxen, make your fixes there. Test, then update the live module suite from the sandboxen. With the sandboxen behind the live (older than live) Moduli:CS1 documentation support won't necessarily produce accurate results for sq:Moduli:Citation/CS1/doc/Category list.

—Trappist the monk (talk) 17:14, 31 December 2023 (UTC)

Yes, that was a mistake from my part. It took me 3 days to complete the update and had another user from my homewiki contact me about all our citations being broken meanwhile. I totally forgot about that practice because it had been around half a year without dealing with CS1.

I'm a bit confused about your edit: Should I treat it as something permanent or is it supposed to be temporary? Are you going to integrate it in the EnWiki version as well? I didn't know that module didn't support symmetrical parity (if you can call it that). - Klein Muçi (talk) 17:32, 31 December 2023 (UTC)

In your OP you wrote: This is the self-notice I had given myself in regard to knowing what local extra changes we have beside the EnWiki version. Add to that a note to update to the sandboxen from en.wiki. At the next update, where sandboxen are ahead of live, you can undo the change to sq:Moduli:CS1 documentation support. Maybe make a one-time note about that too.

—Trappist the monk (talk) 17:44, 31 December 2023 (UTC)

I probably will indeed. Thank you one more time and happy new year! 😄 - Klein Muçi (talk) 18:00, 31 December 2023 (UTC)

On w:sq:Moduli:Citation/CS1/doc/Category list I get ~60 non-existing property categories I have to create about different scripts. The results are all in English which makes me believe that maybe an error has been made but not sure where. Also the word "Category" everywhere in that page should be "Kategoria" but again, not sure where to change that. - Klein Muçi (talk) 00:13, 3 January 2024 (UTC)

You need to translate line 700 and change 'en' to 'sq' at line 695.

—Trappist the monk (talk) 01:06, 3 January 2024 (UTC)

Thank you - Klein Muçi (talk) 01:33, 3 January 2024 (UTC)

In the said category list I get two categories in English about Classical Syriac and Ottoman Turkish. I vaguely remember we have talked about those in the past and I think I should do some kind of remapping. Can you tell me more what is going on? - Klein Muçi (talk) 02:34, 3 January 2024 (UTC)

On the same matter, I also vaguely remember that the Montenegrin language CNR also needed some kind of remapping... - Klein Muçi (talk) 02:36, 3 January 2024 (UTC)

Also, this doesn't exist for you... - Klein Muçi (talk) 02:47, 3 January 2024 (UTC)

MediaWiki doesn't know the Albanian names for ota, syc, or cnr so it falls back to English:

• {{#language:ota|sq}} → Ottoman Turkish
• {{#language:syc|sq}} → Classical Syriac
• {{#language:cnr|sq}} → Montenegrin

You need to add those to the remap tables (see your ~/Configuration/sandbox where you did it in a previous version).

—Trappist the monk (talk) 13:23, 3 January 2024 (UTC)

Impeccable.

Hopefully last question: What am I doing wrong here? - Klein Muçi (talk) 14:13, 3 January 2024 (UTC)

Fixed.

—Trappist the monk (talk) 14:17, 3 January 2024 (UTC)

Much gratitude for your expertise! Thank you! - Klein Muçi (talk) 14:21, 3 January 2024 (UTC)

smallem

What is the method for finding the total number of regex lines? I checked your archives (you've answered this question twice now) but I can't seem to be able to replicate the old methods. Maybe something has changed or maybe I'm doing something wrong? - Klein Muçi (talk) 03:05, 4 January 2024 (UTC)

At the bottom of sq:Përdoruesi:Trappist the monk/sandbox I see a regex count for {{#invoke:Smallem|lang_lister|plain=yes|lang=en}} (Regex count: 986). What are you doing that you don't see that?

—Trappist the monk (talk) 13:17, 4 January 2024 (UTC)

I see that. I want to see the grand total of all languages. - Klein Muçi (talk) 13:21, 4 January 2024 (UTC)

Did sq:Moduli:Smallem ever do that? I scanned through all of our smallem discussions in my talk page archives and didn't see anywhere that we discussed having smallem count all regexes. You say that I've answered this question twice now. Where did I do that?

—Trappist the monk (talk) 15:00, 4 January 2024 (UTC)

Yes, search for "42288" in your 16th archive and you will find the first occasion. - Klein Muçi (talk) 15:46, 4 January 2024 (UTC)

Whatever we did no longer works, even with the 12 November 2020 version of smallem. For me, the current version runs out of memory. The world has not been static since then; there are more wikipedias, more supported languages, so I guess I'm not surprised that at some point we crossed the boundary into the realm or this-hack-don't-work-no-more.

—Trappist the monk (talk) 16:27, 4 January 2024 (UTC)

I see.

I have this regex:

(r"\{\{((?!\s*(?:Cite[_\-\s]*(?=arxiv|AV media|AV media notes|biorxiv|book|CiteSeerX|conference|encyclopa?edia|interview|Journal|Magazine|mailing ?list|map|newsgroup|(?:News(?!group|paper))|podcast|press release|report|serial|sign|speech|ssrn|techreport|thesis|Web)|Citation(?=\s*\|)))[^\{\}]*)\}\}", r"__0P3N__\1__CL0S3__"),

Which should help in preparing citations before Smallem works its magic. (The comment for it reads: Temporary clean up of citations from templates that block regex replacements)

Should I add any new templates in that that might have been added meanwhile? - Klein Muçi (talk) 16:57, 4 January 2024 (UTC)

Why are |Journal|Magazine capitalized? Doesn't matter because smallem regexes are case insensitive? Add |document, |episode, |medrxiv. Change |techreport to |tech ?report.

—Trappist the monk (talk) 18:36, 4 January 2024 (UTC)

Yes. I will decapitalize them anyway. Thank you! - Klein Muçi (talk) 20:39, 4 January 2024 (UTC)

Mostly out of personal curiosity... I have this list of replacements about deprecated parameters:

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)author(\d*)?((?:first|given|last|mask|surname))(\d*)?\s*=\s*", r"\1author\2-\3\4="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)booktitle\s*=\s*", r"\1book-title="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)chapterurl\s*=\s*", r"\1chapter-url="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)conferenceurl\s*=\s*", r"\1conference-url="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)contributionurl\s*=\s*", r"\1contribution-url="),

(r"(\{\{\s*cit[aeio][^\}]*)\|\s*dead-?url\s*=\s*(?:true|yes|y)\b", r"\1"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)dead-?url\s*=\s*no\b", r"\1url-status=live"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)displayauthors\s*=\s*", r"\1display-authors="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)displayeditors\s*=\s*", r"\1display-editors="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)doi-(?:broken|inactive)-date\s*=\s*", r"\1doi-broken-date="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)editor(\d*)?((?:first|given|last|link|surname|mask))(\d*)?\s*=\s*", r"\1editor\2-\3\4="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)embargo\s*=\s*", r"\1pmc-embargo-date="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)episodelink\s*=\s*", r"\1episode-link="),

(r"(\{\{\s*cit[aeio][^\}]*)\|\s*event-format\s*=\s*", r"\1"),

(r"(\{\{\s*cit[aeio][^\}]*)\|\s*event-?url\s*=\s*", r"\1"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)interviewer(\d*)?((?:link|mask))(\d*)?\s*=\s*", r"\1interviewer\2-\3\4="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)last-?author-?amp\s*=\s*(?:true|yes|y)\b", r"\1name-list-style=amp"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)mailinglist\s*=\s*", r"\1mailing-list="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)mapurl\s*=\s*", r"\1map-url="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)name-list-format\s*=\s*", r"\1name-list-style="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)no-?cat\s*=\s*", r"\1no-tracking="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)nopp\s*=\s*", r"\1no-pp="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)publicationdate\s*=\s*", r"\1publication-date="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)publicationplace\s*=\s*", r"\1publication-place="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)registration\s*=\s*(?:true|yes|y)\b", r"\1url-access=registration"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)sectionurl\s*=\s*", r"\1section-url="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)serieslink\s*=\s*", r"\1series-link="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)series(?:no|number)\b\s*=\s*", r"\1series-number="),

(r"(\{\{\s*cit[aeio][^\}]*)\|\s*series-separator\s*=\s*", r"\1"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)subject(\d*)?link(\d*)?\s*=\s*", r"\1subject\2-link\3="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)subscription\s*=\s*(?:true|yes|y)\b", r"\1url-access=subscription"),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)timecaption\s*=\s*", r"\1time-caption="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)titlelink\s*=\s*", r"\1title-link="),

(r"(\{\{\s*cit[aeio][^\}]*\|\s*)transcripturl\s*=\s*", r"\1transcript-url="),

I'm not sure how its end of life should come. Should I keep those parameters forever? Should I remove some of those/all of those? Something in-between? I thought to ask about your opinion on it. - Klein Muçi (talk) 06:46, 5 January 2024 (UTC)

I have no opinion. If you decide to remove some or all of these regexes, you can always restore them if the deprecated parameters start filling the unsupported parameter category.

—Trappist the monk (talk) 13:06, 5 January 2024 (UTC)

Okay then. That concludes the adventure. Thank you for your continuous support! - Klein Muçi (talk) 14:28, 5 January 2024 (UTC)

Can you...

... make a script to replace <“> and <”> with <">, and <‘> and <’> with <'>? 2804:14D:5C32:4673:5DBE:2F80:27B7:584 (talk) 09:18, 12 January 2024 (UTC)

You might try: meta:TemplateScript. I expect that you will need to be logged in to use that.

—Trappist the monk (talk) 14:28, 12 January 2024 (UTC)

Revert @ Shepody, NB

Thank-you for your interst at Shepody, NB. I do not see an investment of work on your part. Your revert with explanation "Unsupported edit" does make a contribution to the article's improvement. You can join the conversation at the talk page of the same. PonapsqisHous (talk) 19:48, 22 January 2024 (UTC)

Question

Hello,
I saw one of your edits in the pending changes feed, was this an error? Because you are clearly not a new user.
A confused  Thanks Geardona (talk to me?) 18:43, 23 January 2024 (UTC)

Almost all of the work on articles that I do is gnoming fixes to cs1|2 templates. Because of that, I have no idea if my edits to pending-changes articles 'confirm' something that ought not be confirmed; this, I think, is a fatal flaw in the pending changes scheme of things. Usually I don't notice that an article if pending-changes protected until after I have made the edit. When I do notice that the article has pending changes protection, I will generally not edit it. When I don't notice the pending-changes protection until too late, I unset my automatic approval hoping that someone who cares about the article will look more deeply than just my edit to make sure that I haven't confirmed an edit that ought not have been confirmed. Does this make any sense?

—Trappist the monk (talk) 19:07, 23 January 2024 (UTC)

 Thanks just a little confused as I am new to PC, wanted to be sure I did not mess some thing up! Geardona (talk to me?) 22:23, 23 January 2024 (UTC)

SqWiki - Module:Charts

Hey there, Trappist!

Some time ago you helped set up this module. I was wondering, is there any enhancements that can be made to it to facilitate category update? After some time without checking it I have no idea which of the categories involved in it are still present or should be removed. I can of course check one by one manually but that obviously is cumbersome, at least more cumbersome than having an automatic mechanism, whatever that might be. - Klein Muçi (talk) 10:59, 29 January 2024 (UTC)

sq:Moduli:CS1 charts/data/doc

—Trappist the monk (talk) 16:12, 29 January 2024 (UTC)

Thanks a lot! 3 4 related questions:

1. Can we separate different types of errors (for example, error messages and maint messages)?
2. Can we also add the category as a comment to follow the suit of the existing list items?
3. Can the color assigning function be automatic instead of a hardcoded list so I don't have to manually count and update the said list when the number changes?
4. Do the subcategories about numeric and multiple part names really don't exist?

- Klein Muçi (talk) 11:03, 30 January 2024 (UTC)

Answers:

1. error and maintenance keys are already separate because the lists are alpha sorted so error keys precede maintenance keys
2. I cannot parse that sentence
3. color assignment is automatic so I don't know what it is that you are asking
4. the names of the multiple- and numeric-names categories categories are different from all others that are charted. These names are manufactured as they are needed so there isn't a key in sq:Moduli:Citation/CS1/Configuration for numeric names author list. There is a base key maint_numeric_names which is used to build the author-, contributor-, editor-, interviewer-, translator-name list category name.

—Trappist the monk (talk) 14:57, 30 January 2024 (UTC)

1. Yeah, understood that a tiny bit later. Some more visual distinction would be nice but that can be manageable as it is;
2. Check the module in the current state. Some entries have comments showing their categories, some don't. I asked if the category could also be added to the doc page you created;
3. On line 269 on ~/Data you've specified ~70 colors. I asked if maybe there existed a way that would allow you to not do that hardcode approach but instead have the module choose a random color for each entry. Why? Because given that category numbers are prone to change, I need to manually update that list if the number increases or has already increased beyond ~70;
4. So I am to understand they actually exist, no matter what the notice says, right?

• Bonus question: Maybe it could be better to have the whole list show instead of only what is missing or extra and have the interested entries appear in a different color? The reason I say this is because I struggle a bit to know where to actually put the new entries so I can preserve the lexicographical order. Notepad++ helps with that but it's one more extra job.

- Klein Muçi (talk) 16:44, 30 January 2024 (UTC)

Answers:

1. —
2. probably. I notice that you have uncommented err_language_missing which causes Kategoria:Gabime CS1: Mungon parametri i gjuhës to swamp the other categories. Was that what you really wanted to do? To test the addition of category names, I'll comment out that key.
3. sq:Moduli:CS1 charts imposes a limit of 64 bars in bar charts and 26 slices in pie charts. There should not be a need to change the content of chart_colors_t.
4. the keys that are hand-built in ~/data (Mirëmbajtja CS1: Emra shifrorë: lista e autorëve and the like) do not exist in ~/Configuration so the code reports them as 'maintenance category keys not found in Moduli:Citation/CS1/Configuration'. This is because the code can't know that these, or any future hand-built keys, are not typos or some other form of erroneous text so it simply reports the non-existence.

Right now, the sequences maint_cats_order_t and error_cats_order_t specify the order in which the data are displayed. For example, you moved Mirëmbajtja CS1: Emra shifrorë: lista e autorëve and the others to the end of maint_cats_order_t so now, those categories show at the far right of the bar chart and are listed at the end of the accompanying list at sq:Kategoria:Mirëmbajtja CS1. You can arrange the keys in those two sequences to have any order that you'd like. Because of the way Lua works, the raw list of keys-not-found will not be in any particular, meaningful order. That is why the lists are alpha sorted before the result is rendered.

—Trappist the monk (talk) 17:51, 30 January 2024 (UTC)

• It was a mistake;
• I had forgotten about that limit. Thank you for reminding me;
• I understand;
• I see. I just pushed them in the end because I was sorting the remaining list lexicographically with N++.

- Klein Muçi (talk) 18:36, 30 January 2024 (UTC)

Category names added for the list of keys not found in ~/data. Can't add category names to list of keys not found in ~/Configuration because ~/data doesn't know about non-existent categories.

—Trappist the monk (talk) 23:46, 30 January 2024 (UTC)

Thank you very much! Was able to update easily after your update. Now only the hand-built key categories are left. I wonder if something can be done about them visually, like enclosing them in a collapse box or something similar. They can also stay like that I suppose. - Klein Muçi (talk) 10:24, 31 January 2024 (UTC)

|url-status=dead

We briefly talked about this last year, but I noticed that you still occasionally remove |url-status=dead from citations while claiming to repair them. It is true that this field–value combo is not required, yet optionality is not grounds for removal. Furthermore, |url-status=dead indicates that this source has been checked and intentionally marked as dead, whereas the lack of this parameter can occur when an editor archives a still-live source but forgets to add |url-status=live, requiring another editor to re-check and re-tag it later. I am not saying that one should go around and forcibly add |url-status=dead everywhere, but neither should such tags be removed in a semi-automated manner. Regards, IceWelder [✉] 21:25, 24 January 2024 (UTC)

You have the advantage of me. I remember no such conversation with you. Regardless, if we did have that conversation, you know that I disagree with just about everything you have written here. The purpose of |url-status= is not to indicate that some editor checked the state of the source. Were that the purpose, then we would be using a parameter with a different name that accepted a date-of-last-check value. The purpose, when set to live, is to tell Module:Citation/CS1 that it should link the value in |title= with the url in |url=. That is the only defined purpose of |url-status= and its predecessors |deadurl= and |dead-url=.

For the record, I never, never, edit an article where the only thing I do is remove |url-status=dead and then claim that as a 'cite repair' edit. If you are accusing me of that, you are mistaken.

—Trappist the monk (talk) 23:01, 24 January 2024 (UTC)

The parameter's functioning on a technical level is not lost on me. Still, I believe the implicit use I outlined can be valuable to some editors; |dead-url=yes was used in the same way for years. In contrast, I see no benefit in removing the parameter outside trimming 16 characters from a citation. As for you making cosmetic-only changes -- of course not, and I did not want to insinuate that. Although, edits like this one, where the summary reads "cite repair;" but the 127/128 (99.2%) of parameter changes are non-repair-related, may obscure the intended fix. IceWelder [✉] 10:31, 25 January 2024 (UTC)

@Trappist the monk: None of this is described in the citation popup template that is available from the editor pane: "Cite->cite web>Show/hide extra fields>URL status..?." then hover over the question mark to reveal the text: "Mark the live/dead/usurped status of the original URL, defining it's relevance versus the (required) archive URL." The hover text needs to be improved, (not sure where that is stored) or this bot's process needs a better description.

About this example repair "|url-status=Live" which I don't understand. The "url-status=Live" was "repaired" by completely removing it. Telling the CS1 module that the link is live, tells it to link the value in the title. If the title is present, does it remove the url-status?

Also, it removed the publisher and the location information |publisher=ICE Office of Public Affairs, |location=United States. I can create a separate section for those two as well, but I figure this topic probably covers both of those as well. -eximo (talk) 21:26, 31 January 2024 (UTC)

I have nothing to do with WP:RefToolbar. Tool tips for WP:RefToolbar apparently come from MediaWiki:RefToolbarMessages-en.js. That particular tool tip was modified at this edit by Writ Keeper following discussion at MediaWiki talk:RefToolbarMessages-en.js § Urlstatus. I agree with you that the tool tip needs to be improved; suggestions for better text should be discussed somewhere other than my talk page. The obvious place is WT:RefToolbar.

I don't know what bot's process you are talking about. What bot?

I don't know which example repair you are talking about. I can say that |url-status=Live is malformed because the assigned keyword Live is not accepted; all keywords defined for cs1|2 templates are always lowercase so |url-status=live is the correct form.

Similarly, it removed the publisher and the location information; what is it? Is that the unnamed bot?

Which article(s) did the unnamed bot edit?

—Trappist the monk (talk) 23:25, 31 January 2024 (UTC)

Stationery

Dear Monk, I don't know if it is cruel and horrid of me to be very slightly crying with laughter over Stationary vs. Stationery in this edit. If it is then I apologize. It's the fact that it's a transport article that finished me off. Thank you for making my evening. Cheers DBaK (talk) 19:33, 4 February 2024 (UTC)

By the way

Given you do a lot of Lua work, I thought you might like to see the template parser I put together over at Wiktionary: wikt:Module:template parser, which is designed for doing large-scale data scraping very quickly (e.g. wikt:人 accesses the contents of hundreds of other pages, and this parser has to be run for every single one). It's taken several months to put together and is (loosely) based on mwparserfromhell, though it's essentially my own design at this point. It can handle arbitrary levels of complexity with templates, arguments, HTML comments, parser tags and include tags, and I've gone over the native parser's PHP code to ensure it's fully accurate: I haven't yet managed to find a testcase it fails, even with extreme levels of nesting of various different objects. It was initially part of an even more ambitious project to design a pure-Lua markdown parser (which was becoming necessary due to major issues with memory constraints on Wiktionary), but that's on the backburner since the Wiktionary memory limit was doubled to 100MB.

I thought it might come in handy for the Wikipedia community if you need to do any large-scale data scraping: I've been really happy with the performance on Wiktionary, and I'm reasonably confident it's the most powerful markup parser that has yet been designed in Lua. It's not quite fully finished, since although it can parse parser tags (e.g. <ref>), I haven't yet implemented the various special behaviours that each tag needs. However, unless that's really needed, it's essentially ready for use. Theknightwho (talk) 15:35, 13 February 2024 (UTC)

Thanks for that. I don't think that I have a need for for this but perhaps others do. You might be better posting about your parser at WT:LUA.

—Trappist the monk (talk) 15:51, 13 February 2024 (UTC)

Thanks - I've posted there. Theknightwho (talk) 16:34, 13 February 2024 (UTC)

Overriden settings

I fixed all the pages from the "Overridden settings" category [[Category:CS1 maint: overridden setting]]https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&search=deepcat%3A%22CS1+maint%3A+overridden+setting%22&advancedSearch-current={%22fields%22:{%22deepcategory%22:[%22CS1%20maint:%20overridden%20setting%22]}} https://en.wikipedia.org/wiki/Category:CS1_maint:_overridden_setting a few days ago. Now, this category is empty, which means that there are no articles on Wikipedia that have citation options in particular templates overwritten by the main "cs1 config setting". I wrote a message to you about that earlier as a reply, but I am not sure that you saw that message. I remember you mentioned about this category. There were more than 500 pages in this category. It turned out that the majority of the issues were caused by some templates that had specified parameters, in particular, citations that were overridden by the "cs1 config" in the articles in which these templates were included. When I fixed those templates by removing these parameters from templates, the issue was resolved without modifying each of the pages. I'm also taking a look into other categories, such as the PMC format or Vancouver style. Whenever something appears in these categories, I try to fix that.

I have also been monitoring the "invisible character" category and fixing any issues that I come across. It's a never-ending task, but I am dedicated to ensuring the accuracy and quality of citations on Wikipedia.

Additionally, I am contributing to the development of the Citations bot via Github, as you might be aware of.

Thank you for your time and dedication in maintaining the integrity of Wikipedia article format when it comes to mostly techinical issues, and your contributions to the cs1 library. Your support is greatly appreciated.

I just wanted to update you on my progress in resolving issues related to overridden settings in citation templates. With this category now empty, we can ensure that all articles on Wikipedia have accurate and consistent citation options.

If there are any further steps or actions needed from me regarding this matter or other matters, please do let me know how I can be helpful. Maxim Masiutin (talk) 14:07, 14 February 2024 (UTC)

Module:Age

Hello, Trappist! On October 2023 you helped me solve a date problem with Module:Age in SqWiki. The conversation was held in the Helpdesk but given the dynamic nature of that page (and the lack of archives?) I couldn't find that conversation anymore. I have to ask again about it, if you find some time to help me:

On this article I'm having date format errors. In the beginning, the death date was showing problems which were solved when I switched the format from ymd to dmy. Then I did the same to the birth date and now that's the date that is showing problems. Logically we should be using the dmy format for every date so I believe something should be changed about birth dates? Also, does our module needs any kind of other update to be synchronized with its EnWiki homologue? - Klein Muçi (talk) 09:11, 14 February 2024 (UTC)

sq:Stampa:Birth date does not use sq:Module:Age. That template expects YMD. Presuming that you intended DMY input order, it is unclear what the actual birth date is because day/month numbers are inconsistent:

{{birth date|11|06|1894}}

{{Death date and age|df=y|27|03|1952|06|11|1894}}

Regardless, assuming that the numbers in {{birth date}} are in DMY order, this works (and matches the birth date in the article's first sentence):

{{birth date|1894|06|11|df=y}}

—Trappist the monk (talk) 12:36, 14 February 2024 (UTC)

Hmm... I see. So I'm a bit confused in regard to the df=y parameter-value pair. Can I have a ymd format and add that (df=y) and have the result convert in dmy? - Klein Muçi (talk) 13:32, 14 February 2024 (UTC)

If you omit |df=y the birth date is rendered MDY:

{{birth date|1894|06|11}} → (1894-06-11)June 11, 1894

Include |df=y to render DMY format:

{{birth date|1894|06|11|df=y}} → (1894-06-11)11 June 1894

—Trappist the monk (talk) 14:16, 14 February 2024 (UTC)

I see... If my words are worth anything, I'd say that the current state of the birth/date/age templates it's a bit confusing in format matters (especially when there are templates that aren't part of a single module) but that solves my problem. I really hope I don't have to ask again about this topic.

Thank you! - Klein Muçi (talk) 16:12, 14 February 2024 (UTC)

The original discussion is: Wikipedia:Help desk/Archives/2023 October 26 § Module:Age - Date format. I contend that you brought this on yourself by conflating DMY date format with |Y|M|D positional parameter order. Now you have two more-or-less related templates that use dramatically different positional parameter ordering. For one the documentation is wholly missing; for the other what documentation there is shows big red error messages.

—Trappist the monk (talk) 16:38, 14 February 2024 (UTC)

I understand your POV but I believe that having them to show errors if ymd was not followed in positional code would be kind of the same because we don't write dates like that in Albanian. Maybe it could help with translations though. It's really annoying having no smart way to navigate these format problems. With smart I mean a way for "the system" to understand the user's intention in writing dates and facilitate format issues. The whole thing looks really brittle and very prone to user errors, especially when considering translations. - Klein Muçi (talk) 17:04, 14 February 2024 (UTC)

Same citation many times

Hello! I'm working on an article on my community where most information comes from only 2-3 sources. This is reflected in the reference list where you'll see the same reference duplicated many times, sometimes in a row. Can you tell me what would be the most preferred way in general to handle such cases? I wanted to learn so I can improve even on future similar situations. Given that the said article is in the sandbox, you are free to make any changes to it if you think they can help you better illustrate your answer to my question. - Klein Muçi (talk) 13:16, 21 February 2024 (UTC)

Why, oh why, do women wear so much makeup? and why such scarlet lipstick? Ack!

If those references will always be the same use <ref name="..."></ref> for the definition and <ref name="..." /> for the repeats. But, why make your readers hunt through an hour-long interview to locate the small portion that supports your article's wikitext? Use the citation to tell them where to find the relevant position or link to it.

I would write the base citation slightly:

{{cite AV media |date=7 shkurt 2023 |title=Klodiana Shala: Si e përjetova lajmin e mjekëve për të braktisur sportin në kulmin e karrierës |type=emision |language=sq |url=https://www.youtube.com/watch?v=0_ZLCvfSDto |access-date=21 shkurt 2024 |via=YouTube |publisher=Report TV |ref={{sfnref|Report TV|2023}}}}

I would then use {{sfn}} to link to specific timestamps:

{{sfn|Report TV|2023|loc=[https://www.youtube.com/watch?v=0_ZLCvfSDto&t=1708 28:28]}}

The timestamp value in the YouTube url is in seconds so simply add &t=<timestamp> to the end of the base url. To convert <minutes>:<seconds> to <timestamp>:

<timestamp> = <minutes> × 60 + <seconds>

—Trappist the monk (talk) 14:52, 21 February 2024 (UTC)

Haha! Okay, I'll try to do it like that and report back here if I face any difficulties. Thank you! - Klein Muçi (talk) 15:37, 21 February 2024 (UTC)

The reference list is not displayed!

Thanks for the response. But what can be done now? Arbabi second (talk) 20:50, 26 February 2024 (UTC)

One discussion in one place. An answer has been given at Wikipedia:Village pump (technical) § The reference list is not displayed!

—Trappist the monk (talk) 22:45, 26 February 2024 (UTC)

Nomination for deletion of Template:Limited access/doc

Template:Limited access/doc has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Gonnym (talk) 08:42, 11 March 2024 (UTC)

Nomination for deletion of Template:Edit taxonomy/styles.css

Template:Edit taxonomy/styles.css has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Gonnym (talk) 10:45, 13 March 2024 (UTC)

Luwian template

I need a {{lang-xxx|}} type template for Luwian that wraps both Anatolian hieroglyphs and Hittite cuneiform.

However I am not sure which code to use for this template since ISO 639-3 and Linguist List have no single code for all of Luwian and instead use xlu for Cuneiform Luwian and hlu for Hieroglyphic Luwian.

Can something be done regarding this? Antiquistik (talk) 14:38, 23 March 2024 (UTC)

If the Luwian text is written using hieroglyphs use {{lang-hlu}}; if written in cuneiform use {{lang-xlu}}. If you think that ISO 639 should have a 'generic' Luwian language tag, you will have to take that up with the ISO 639 custodians; Module:Lang does not (and will not) support Linguist list language tags.

—Trappist the monk (talk) 16:09, 23 March 2024 (UTC)

Alright! I will see what I can do. Antiquistik (talk) 19:26, 23 March 2024 (UTC)

Just fyi: Unichar template has been enhanced

Your reply at template talk:sfn prompts me to mention {{Unichar}} template has been enhanced. It now fetches the canonical name, no more need to state what is already obvious. So for example, a simple

• {{unichar|00E9}}

produces

• U+00E9 é LATIN SMALL LETTER E WITH ACUTE

But if you prefer,

• {{unichar|00E9|nlink=é}}

produces

• U+00E9 é LATIN SMALL LETTER E WITH ACUTE

Just fyi, may save you a little time one day. 𝕁𝕄𝔽 (talk) 17:48, 12 April 2024 (UTC)

Never liked the output of that template; it doesn't need to shout. So thanks, but no thanks.

—Trappist the monk (talk) 18:01, 12 April 2024 (UTC)

Template:ThePlantList

Do you want to puzzle out the best way to yank this out of Category:CS1 maint: others? Izno (talk) 17:35, 20 April 2024 (UTC)

I guess my question is: why does that template use |others= at all? The template defaults to one of two values: Missouri Botanical Garden and Richard Pankhurst. Visiting The Plant list pages linked from ~/doc, those that list Missouri Botanical Garden don't mention the Garden at all; those that list Pankhurst, mention RJP as a source: 'The record derives from RJP...'; not sure that warrants mention in a citation.

The thing that is being cited is a page on a website so |work= in the template should simply be: 'The Plant List' – for which |website= is the more appropriate parameter.

Why is |publisher= different for different identifiers? The reader gets the information from 'The Plant List' website regardless of which sponsoring organization is listed as 'publisher'.

And then there is this: 'Note that this website has been superseded by World Flora Online'. That tagline sort of suggests that 'The Plant List' will one day go away so why bother maintaining the template?

—Trappist the monk (talk) 23:30, 20 April 2024 (UTC)

The template is a bit of a hybrid. A few comments:

• It's widely used for external links, which I assume is why the superseded by World Flora Online was added. It would be better to replace this with a WFO link rather than using a "citation" template. Is there a way to search for cases where it is in the external sources section
• The three ancillary templates seem an unnecessary complication. I'd remove them and keep it as a simple citation template, but I don't know if that would break something. Getting the ID from wikidata might be useful for an external link, but inappropriate for a citation (editors need to have seen what they are linking to at the time of the access-date).
• I can't find any examples of |others= using "rjp" but there are some with other values (e.g. "kew") where it returns a blank rather than "Missouri Botanical Garden".
• The |others= parameter is stating the work from which the Plant List record is derived. This is at best unnecessary, potentially inaccurate if the record has errors (which has plagued The Plant List).

In short, I'd suggest a simple citation with |website=The Plant List (that is the name of the website) and |publisher=Missouri Botanical Garden (as that is the hosting website), which was how the template was created. @Plantdrew and Peter coxhead: might have some helpful thoughts. —  Jts1882 | talk  08:12, 21 April 2024 (UTC)

This search would suggest that the template is widely used in references (~490 articles with <ref ...>{{ThePlantList|...}}</ref>). The template count tool says that the template is used on ~550 pages; the link count tool concurrs. That suggests that the template's predominant use is as a reference. If the template is used in both the article body (as reference) and in §External links, the §External links use is redundant and should be removed.

I can't find any examples of |others= using "rjp" Not sure what you mean by that. Regardless, I agree that the template's |others= assignment is superfluous. To my mind, the |publisher= assignment is also superfluous and the simple |publisher=Missouri Botanical Garden that you suggest should be omitted from a rewritten template because it is not at all obvious from the website that Missouri Botanical Garden is in fact the hosting organization. Were it important to the MBG, it would be stated so at How to Cite The Plant List and/or Terms of Use for The Plant List.

—Trappist the monk (talk) 13:58, 21 April 2024 (UTC)

I created the template as a wrapper for {{Cite web}} by copying (and modifying) {{PLANTS}}. Support for |others= was added by subsequent editors. We ought to replace all references to The Plant List (most of which aren't using this template) to an updated source (either World Flora Online or Plants of the World Online); that's something I've thought about working on, but it's way down on my to-do list. Plantdrew (talk) 15:36, 21 April 2024 (UTC)

As noted above, The Plant List is obsolete, and ideally all uses as an external link would be removed, and all uses as a citation would be replaced by a more appropriate taxonomic database. This will eventually happen, I guess, but in the meantime, simplifying the template is a good idea and I support it. Peter coxhead (talk) 16:26, 21 April 2024 (UTC)

I didn't expect this many people to chime in, I just thought this would be a remove/replace. Oh well. I've removed others now without comment on the rest. Izno (talk) 18:47, 21 April 2024 (UTC)

Script

Hello, do you know any script that translates {{cite}} templates from Portuguese to English? Regards, RodRabelo7 (talk) 23:44, 24 April 2024 (UTC)

{{cite}} is a redirect to {{citation}}. pt.wiki has a template: pt:Predefinição:Citation which is a modified older version of {{citation}}. pt.wiki also has a redirect pt:Predefinição:Cite which redirects to pt:Predefinição:Aviso-cite fonte which has nothing to do with the en.wiki {{citation}} or its {{cite}} redirect.

en.wiki does have these cs1 templates: {{cite book/Portuguese}}, {{cite journal/Portuguese}}, {{cite news/Portuguese}}, and {{cite web/Portuguese}}. These templates automatically translate Portuguese parameter names to their English equivalents. You can rename whatever Portuguese {{citation}} template you have to one of the cs1 forms and, to retain the cs2 styling, include |mode=cs2:

{{citation |...}} → {{cite book |mode=cs2 |...}}

Did I answer your question?

—Trappist the monk (talk) 00:53, 25 April 2024 (UTC)