Hey Trappist! Wanted to ask you about something, mostly to get your opinion on it. I'm following the discussion about The automatic taxonomy system which I started some time ago. That was my first contact with systems that are basically impossible to import singlehandedly. Some days ago I was having this conversation which deals with another similar system. Are these edge cases or are there really a lot of "systems" like these in the "background of everyday Wiki use"? Is there hope for any kind of change in the near future? (The discussion about the taxonomy sure gives me a bit of hope.) Or are we supposed to either accept that we need a lot of users or we need to embrace the Wikidata way? (Which is starting to get suggested to me a lot lately.) I have nothing against Wikidata per se, I'm just not that agile with it. And lastly, even though I know the whole babel thing is not that important in general, given that it doesn't deal with the mainspace, any ideas in regard to that other than what was discussed with Xaos? - Klein Muçi (talk) 15:06, 11 October 2021 (UTC)[reply]

I don't think that I have any answers for you. For auto taxonomy, Editor Peter coxhead has demonstrated that wikidata won't work. The sheer number of taxonomy templates makes the auto taxonomy system unwieldy and difficult for editors at small wikis to implement. Extracting the data from the taxonomy templates into a far fewer lua data modules (<200 v 87,000+) may make it more difficult to edit the data but all of the data can be had for the cost of importing fewer than 200 data modules.

I know nothing about babel except that it exists.

—Trappist the monk (talk) 23:30, 11 October 2021 (UTC)[reply]

Yes, I understand. Thanks for answering anyway. :) - Klein Muçi (talk) 23:34, 11 October 2021 (UTC)[reply]

Given that there are efficient ways of accessing Wikidata from language wikis, my question is why can't there be efficient ways of accessing templates (or Lua modules) in one language wiki from another? Peter coxhead (talk) 06:46, 12 October 2021 (UTC)[reply]

@Peter coxhead, maybe I haven't understood you correctly but if I have, this is the closest thing to what you're saying. - Klein Muçi (talk) 09:18, 12 October 2021 (UTC)[reply]

@Klein Muçi: yes, it's the closest thing, but still involves copying (and it's not clear that automatic localization would be desirable for taxonomy templates). Ideally, perhaps, it would be possible to specify the equivalent of "if this template exists on the local wikipedia, use it, otherwise use the one with the same name on the <LANG> wikipedia", i.e. avoid copying/duplicating unless necessary. But then the wikilink in a taxonomy template stored on another wiki should go to the local wiki, which might be ok for the scientific name – which is universal – but not when the link is to a vernacular name or some other location (such as a section of an article). This problem wouldn't change if the taxonomy templates were held in Lua modules. I think that there are too many decisions made by and for the English wikipedia embedded in our taxonomy templates to make any kind of purely automated transfer possible. There would need to be extensive post-transfer checking and editing. (I'm not saying it's your view, but part of the problem is a widespread view among non-biologists that classification/taxonomy is somehow objective and fixed, whereas it is actually subjective and constantly changing, especially as larger and larger gene sets are used in molecular phylogenies.) Peter coxhead (talk) 11:08, 12 October 2021 (UTC)[reply]

@Peter coxhead, I was referring to the problem in general, not specifically to the taxonomy case. (Given that the discussion was also supposed to cover the Babel system case.) That is a problem the complexity of which far exceeds what I sent above, even on such simple cases as the vernacular terms, as you said. And yes, I am aware of the "dynamics of the tree of life" but then again, so is everything that is ever-evolving, when you think of it, no? Give enough time and geopolitical boundaries start becoming "old" and their respective articles/infoboxes/categories would need changes. I know the web is more complex in biological taxonomy but let me hope in a future where we (small wikis) too can also have a fully working taxonomic system. :P Given the language and other sociological barriers our hope for communities with large number of users is small. We have to rely on automatization of some sort if we even hope to try and follow the same intellectual standards as EnWiki.

Just to put that into perspective, today is the day SqWiki (my homewiki) celebrates its 18th birthday. Yesterday was the day the 84 000th article was written. Let's estimate a bit and say that after 2 years, SqWiki will have 100 000 articles. How much would it take for the 1 millionth article to be written with the same trend? And that's where the numbers get scary. It would take 200 years, making a lot of us starting to delve in introspective philosophical questions. :P - Klein Muçi (talk) 11:38, 12 October 2021 (UTC)[reply]

@Klein Muçi: I take your point, but I'm perhaps more doubtful than you about follow the same intellectual standards as EnWiki. Being written in a global language is both a blessing and a curse! Yes, there are more editors, but there are also many more less knowledgeable (to be polite) people able to contribute, and more scope for cliques to develop, leading to factionalism and inconsistent approaches in different parts of enwiki. Peter coxhead (talk) 16:29, 12 October 2021 (UTC)[reply]

Hello Trappist! I'm finding something strange on maybe IABot's contributions. Check this article and its citations. Search for "archive-url" and "archiveurl". You'll see that some citations have the archive links duplicated, most likely by IAB (no?). Is that an intended feature? Should I write to its maintainers or am I supposed to somehow let Smallem deal with cases like these? - Klein Muçi (talk) 13:50, 13 October 2021 (UTC)[reply]

This edit done by iabot. It is not a feature. File a bug report at meta:User talk:InternetArchiveBot. Don't hold your breath for a rapid response; that has not been my experience when I've reported bugs in that bot.

—Trappist the monk (talk) 14:02, 13 October 2021 (UTC)[reply]

Thanks for the clarification! :) - Klein Muçi (talk) 14:19, 13 October 2021 (UTC)[reply]

At what temperature do charts melt? - Klein Muçi (talk) 16:55, 13 October 2021 (UTC)[reply]

That used to work. You know it did. What have you changed?

—Trappist the monk (talk) 17:24, 13 October 2021 (UTC)[reply]

Only this. :/ - Klein Muçi (talk) 17:37, 13 October 2021 (UTC)[reply]

broken chart within

100 200 300 400 500 600 Gabime CS1 (34 nga 64 kategori bosh janë fshehur)   Gabime CS1: Adresa 91 faqe   Gabime CS1: Adresa e arkivimit 4 faqe   Gabime CS1: Adresë e zhveshur 76 faqe   Gabime CS1: ASIN 1 faqe   Gabime CS1: ASIN TLD 1 faqe   Gabime CS1: bioRxiv 1 faqe   Gabime CS1: Burim bosh 41 faqe   Gabime CS1: Datat 93 faqe   Gabime CS1: Datë aksesimi pa adresë 64 faqe   Gabime CS1: DOI 1 faqe   Gabime CS1: Formatimi 102 faqe

Not the fault of sq:Moduli:CS1 charts. Here is a broken chart derived from the chart at sq:Kategoria:Gabime CS1. Moduli:CS1 charts does not exist at en.wiki so this chart is directly rendered by the en.wiki Module:Chart. The problem appears to require a certain number of groups (11 seems to be the minimum), requires |links <n>= (apparently |links 10= is important), and requires some magic value (apparently greater than 500) for one of the |group <n>= parameters. There are some notes in the Module:Chart {{#invoke:}} that may be useful. I'm guessing that the problem is related to chart scaling; but why does the presence or absence of |links 10= matter?

Probably best for you to discuss at Module talk:Chart.

—Trappist the monk (talk) 20:10, 13 October 2021 (UTC)[reply]

So it was "faulty" per se at certain limits. Can you rephrase shortly what I should ask there to get the best results?

I would have gone with something as simple as "can someone help me fix this thing here because it started behaving strange" but I'm afraid whoever will try to help will be initially confused by the small changes that have been made when Module:Chart was converted to Module:CS1 charts. - Klein Muçi (talk) 22:03, 13 October 2021 (UTC)[reply]

Module:Chart was converted to Module:CS1 charts. That is not true. To create the carts at sq.wiki we did not convert sq:Moduli:Chart. sq:Moduli:CS1 charts builds an {{#invoke:}} by creating all of the settings and data necessary to get :sq:Module:Chart to draw the charts. That is demonstrated here because the chart on this page is broken and doesn't use Module:CS1 charts (which does not exist at en.wiki).

can someone help me fix this thing here because it started behaving strange should be sufficient. Feel free to link to this discussion. Further discussion should continue at Module talk:Chart; it should not continue here.

—Trappist the monk (talk) 22:23, 13 October 2021 (UTC)[reply]

Okay then. Thanks for the guidance! Maybe is better to place a collapse box around the chart here meanwhile though. It literally makes the text unreadable. - Klein Muçi (talk) 22:30, 13 October 2021 (UTC)[reply]

Hello! :)

I was having this conversation and I was thinking that you're pretty gifted with Lua and maybe you could be able to help. This is outside your usual interests though (as far as I know) and the user there did mention that it was a tricky thing to accomplish so I fully understand if you can't help with it.

Side info: If you're interested, the chart problem was solved with this edit. - Klein Muçi (talk) 01:49, 20 October 2021 (UTC)[reply]

Umm, Module:RFX does not exist nor does sq:Moduli:RFX so I have no idea what you're talking about.

—Trappist the monk (talk) 13:34, 20 October 2021 (UTC)[reply]

That's because apparently I haven't filed the needed report. :P

Module:RFX report - Klein Muçi (talk) 14:36, 20 October 2021 (UTC)[reply]

Sorry, not interested in that. For the moment I have enough to keep me occupied with the taxonomy templates and a prospective bot task and a project to update how non-Enlgish cs1|2 templates are translated to English.

I'm sort of disappointed in the resolution of the melting-chart problem. It doesn't explain why |links 10= was a contributor to the problem...

—Trappist the monk (talk) 14:50, 20 October 2021 (UTC)[reply]

Yeah that's what I was thinking. The auto-taxon problem should get priority over that request given that the benefits of it would be enjoyed on a global scale ideally. That can wait. As for the chart problem, I know what you mean because I strive for future-proofing projects generally and having unexplained code magic that could potentially malfunction in the future is a bit unsettling. But, if it helps, it can be argued that my case was a bit extreme and was only caused by the IABots malfunction. So it will take a while until the stars align again for the even-more-edge cases to be experienced, if they exist. However reassuring can that information be. :P - Klein Muçi (talk) 15:40, 20 October 2021 (UTC)[reply]

An article that you have been involved in editing—stv.tv—has been proposed for merging with another article. If you are interested, please participate in the merger discussion. Thank you. GMc^(talk?) 13:30, 21 October 2021 (UTC)[reply]

@Editor GMc: I have never edited that article but my bot has. Alas, my bot is wholly unqualified to give an opinion on the matter. Please don't invite my bot to any more of these kinds of parties.

—Trappist the monk (talk) 13:37, 21 October 2021 (UTC)[reply]

I didn't realise it was a bot. No need to be rude. Thanks. GMc^(talk?) 17:55, 21 October 2021 (UTC)[reply]

Hey Trappist!

Lately I've started reading more about Lua itself wanting to be able to understand a bit more than basic invocations and dictionary tables. I had a pretty basic question out of curiosity and I thought that you'd be the best to answer it: What are Lua's advantages over wikimarkup in regard to templates? Why have we started switching almost all important templates to module invocations? I believe that a module allows you more flexibility in governing more stuff at the same time, at the same place but that's as far as I can go with my guess.

I made a question here about an error related to Lua and that got me interested to learn more about the details. - Klein Muçi (talk) 01:34, 24 October 2021 (UTC)[reply]

Because Lua is a real programming language? Because Lua is easier to read than wikimarkup where whitespace matters (a lot)? Because Lua allows for the creation of variables? cs1|2 is implemented with eight modules; I cannot imagine how many templates would be required to implement the same functionality using wiki markup.

—Trappist the monk (talk) 11:45, 24 October 2021 (UTC)[reply]

My knee-jerk reaction would be to say that "variables" can be "created" with templates and meta-templates but your point on CS1|2 really ends the discussion. Klein Muçi (talk) 12:15, 24 October 2021 (UTC)[reply]

@Klein Muçi: template code is a partial functional programming language – partial partly, but not entirely, because of the absence of recursion. As in all such languages, the effect of variables can be achieved by passing values to auxiliary templates whose parameters become the required variables. But that just reinforces Trappist's point: even quite simple tasks can require multiple templates to avoid repeated calculation of the same values. Peter coxhead (talk) 16:22, 24 October 2021 (UTC)[reply]

@Peter coxhead, yes, I do understand that. Given the subject, is there a con we can say when comparing Lua to templates? Beside the fact that Lua falls a bit on the "dark side" in regard to the average user. - Klein Muçi (talk) 21:42, 24 October 2021 (UTC)[reply]

I have a vague and perhaps mistaken impression that Editor Pppery has, in the past, expressed a rather strong preference for templates over modules. I don't remember how it is that I came to have that impression...

—Trappist the monk (talk) 21:55, 24 October 2021 (UTC)[reply]

You remember correctly. I went on a crusade of nominating Lua modules for deletion because the same functionality could be implemented in Wikitext circa Spring 2018. Even then, though, I would likely not have objected to the use of Lua for Taxonomy templates.

I'll now make an attempt to answer Klein Muçi's original question at the top of the thread as I see it:

1. There are several things, most obviously templates supporting an infinite number of parameters, that simply cannot be done with wikitext at all and have to use Lua somewhere.
2. There are several more things, that could in theory be done using some absurd hacks in wikitext but have a native implementation in Lua. {{str len}} is one of these: there was an implementation of that template before Scribunto was installed that abused the padleft: function as a means of length testing and used that primitive to do a binary search to find the length of the string. People's tendency to write code like this was in fact what led to Scribunto being installed in the first place.
3. I sometimes see people writing things in Lua to avoid running into the post-expand include size limit on large articles. This seems somewhat dubious to me, but it does count as an advantage.

What I disagree with (both in 2018 and now, although I've realized that my viewpoint does not enjoy consensus so have stopped pushing for it) is uses of Lua that don't fall into any of the above three cases and are instead done solely for the sake of internal complexity. They often end up leading to dilemmas like Wikipedia:Requested templates/Archive 16#Reinstate Type parameter in CFD, and/or Template talk:Cfd#The module has dropped a line-break somehow, Template talk:Template link general#Nowiki stopped working (all cases in which I personally cleaned up after someone else's conversion of something to Lua) for no obvious benefit. * Pppery * _{it has begun...} 22:37, 24 October 2021 (UTC)[reply]

@Pppery thanks a lot for your insight! :)

Now I have a somewhat naive question to end it (for which I hope I can express myself clearly enough to be understood): If we agreed to implement a whole new language beside the traditional existing one, is there place to believe that we're going to implement other coding languages as well in the future? The question is naive on its own because I'm aware that we already have .css and .js files around Wikipedia. But none of those feel as much prevalent as Lua, maybe because of Lua having its own namespace which doesn't require special privileges to work on.

Also keeping on with the same idea: Is the current Lua implementation "static"? Can new features related to it be requested if so needed? - Klein Muçi (talk) 22:53, 24 October 2021 (UTC)[reply]

There is lots of css and it's everywhere. Editor Pppery's signature has it; any template or module that employs TemplateStyles has it. Pretty much any html that is styled is styled with css. Javascript is also ubiquitous. User scripts, common things like Wikipedia:RefToolbar, and essential under-the-bonnet-stuff-that-I-know-exists-but-don't-know-what-it-is; some of that appears in the html of an article.

The Scribuntu version of Lua is at 5.1 while the 'official' current lua release is 5.4.3. Because scribuntu has intentionally limited or disabled certain capabilities available in standard Lua (see mw:Extension:Scribunto/Lua reference manual#Differences from standard Lua) I imagine that upgrading to another version of Lua is a bit of a job so won't be done until there is a distinct need to do so (doing such an upgrade might break a lot of existing module code so must be done carefully).

No doubt, if the need can be demonstrated, the current Lua implementation can be modified by creating a new mediawiki library. When the time comes that you think that such an improvement is necessary, phabricator is that-a-way →.

—Trappist the monk (talk) 23:32, 24 October 2021 (UTC)[reply]

Where's the spoiler alert? I haven't gotten to that section yet. :P

I understand. Thanks for the answer! All of you. Really insightful. :) - Klein Muçi (talk) 23:40, 24 October 2021 (UTC)[reply]

Some wikis, such as the English Wikinews, have built their own programming languages on top of Lua (See n:Module:Wikilisp). Aside from some oddities like that. I believe there are also some plans in the works related to Wikifunctions that could be described as a new programming language, but I'm not following that very closely. Aside from that, I don't see how the circumstances that lead to the introduction of Lua could recur. I don't think I have anything to add to Trappist's comments about the mutability of the programming interface, other than to say that bugs reported on Phabricator can often languish for months to years without action. * Pppery * _{it has begun...} 01:23, 25 October 2021 (UTC)[reply]

@Pppery, uhmm... Since you brought that up... Do you have any information how things work at the Phabricator? Up until recent times I've been thinking that all the people involved there are paid WMF members. These days I think I've read around Mediawiki/Wikitech that a lot of users there can actually be casual volunteers. Is that possible? How does a casual volunteer actually fix a bug/make a new feature whatsoever? How does it have the needed access for that? - Klein Muçi (talk) 03:18, 25 October 2021 (UTC)[reply]

See mw:How to become a MediaWiki hacker. I was interested in solving Phabricator tickets a few years ago, but the the slow code review process made me lose interest. * Pppery * _{it has begun...} 03:28, 25 October 2021 (UTC)[reply]

@Pppery, oh, so you don't actually have shell access. You solve the bug and someone else actually accepts it. - I'll try starting the installation procedures just out of curiosity soon I guess. - Klein Muçi (talk) 10:10, 25 October 2021 (UTC)[reply]

In the last day or two, dozens of transcluded, nonexistent taxonomy sandbox templates have appeared in Wikipedia:Database reports/Transclusions of non-existent templates, which usually contains a complete list of transcluded, nonexistent templates but now appears to be overflowing the report's limit. I'm guessing that this has something to do with your taxonomy module experiment. If these transclusions can be avoided easily, that would be helpful for those of us who process that report periodically in order to fix WP:REDNOT problems.

If this problem is not easy to fix, don't worry about it too much. There is plenty of other stuff to work on, and when these transclusions are eventually avoided by the new module, the bot will remove them from the report the next day. – Jonesey95 (talk) 15:27, 30 October 2021 (UTC)[reply]

I have a choice. In lua I can

1. call the #ifexist parser function – this bumps the expensive counter
2. create a title object and fetch the content of the 'article' (in this case a template) which will be nil when the template does not exist – a non-existent template is listed as a transclusion and so shows up in your report
3. create a title object and test for 'existence' – a nonexistent template is listed as a transclusion, so shows up in your report, and bumps the expensive counter
4. call the template in protected mode which allows me to detect the existence of a template without halting module execution (calling a non-existent template from lua halts the module and emits a bold, brash error message) and when the template exists, get its data (all of this in one go) – a nonexistent template is listed as a transclusion (of course), so shows up in your report

I have been using the last of these because it gives me what I need all in one step. If this experiment is ever successful, the 87,000+ taxonomy templates will go away, but ... In order to make it easy for editors to create and edit taxonomy data and so they don't have to muck-about in the lua data table modules (which are likely to be protected), the experimental module looks for a template first before it consults the data modules.

Because it won't be dozens but hundreds, thousands, of no-longer existing templates that will show up in your report, I have adopted #1 above. I have not yet published that version of the experimental module.

—Trappist the monk (talk) 16:47, 30 October 2021 (UTC)[reply]

OK, thanks for the attention. I wonder why it looks for so many /sandbox templates, though, when this set of templates almost never uses sandboxes, AFAIK. I can understand it looking for a few templates that, for some reason, do not exist and could benefit from being created (until the module is fully operational), but the module looking for so many sandboxes is the part that confuses me. – Jonesey95 (talk) 15:44, 31 October 2021 (UTC)[reply]

Because, if the experiment is successful, all of the Taxonomy templates go away except for a handful of new and edited templates. In order to test the module that reads the templates and the lua data modules it is necessary for the module to read both. The data in the data modules is compiled from the templates. Because those templates exist, there would be no opportunity for the module to fetch data from the data modules. So, I force the module to look for sandbox templates which, as you note, are rather few and far between. The module then fetches data from both sandbox templates (when they exist) and the data modules. At Module talk:Sandbox/trappist the monk/taxonomy, the module fetches most of the data displayed there from the data modules but, because it exists, also fetches data from Template:Taxonomy/Angiosperms/sandbox which proves that the code in its current configuration does the right thing.

—Trappist the monk (talk) 16:19, 31 October 2021 (UTC)[reply]

Template:Cite DVD notes/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:33, 6 November 2021 (UTC)[reply]

Template:Cite episode/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:33, 6 November 2021 (UTC)[reply]

Template:Cite newsgroup/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:34, 6 November 2021 (UTC)[reply]

Template:Cite mailing list/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:34, 6 November 2021 (UTC)[reply]

Template:Cite interview/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:34, 6 November 2021 (UTC)[reply]

Template:Cite AV media notes/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:36, 6 November 2021 (UTC)[reply]

Template:Cite thesis/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:36, 6 November 2021 (UTC)[reply]

Template:Cite report/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:36, 6 November 2021 (UTC)[reply]

Template:Cite podcast/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:37, 6 November 2021 (UTC)[reply]

Template:Cite techreport/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:37, 6 November 2021 (UTC)[reply]

Template:Cite speech/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:38, 6 November 2021 (UTC)[reply]

Template:Cite serial/old has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Did Q28 make a mess today? 05:39, 6 November 2021 (UTC)[reply]

Hi, I am not sure how to reference my addition that was deleted. The obituary of Gardner in The Independent, Aug. 2010....." He was born Barry Laurence Gardner in Hackney, London, in 1943.....". He used Barry when he was working w Dr. W. Pearson on Lorna Doone and possible Doone (or Doune) connections to Scots nobility. He authored a couple books as Barry G. Including Lorna Doone's Exmoor 1990 and both belonged to the Anglo American Lorna Doone Society. In Gardner's later years he used Laurence in lectures and his books like Bloodline of the Holy Grail (dedicated to memory of Whitman Pearson). It is what it is. Ronblackmore (talk) 18:11, 10 November 2021 (UTC)[reply]

@Ronblackmore: You are talking about this edit? That edit was reverted by Editor Doug Weller whose edit summary of the revert (If this editor actually is Blackmore than perhaps they can find a source) suggests that your edit was reverted because you did not include any sources to support the claims made in your edit.

The best place to discuss the Laurence Gardner article is at Talk:Laurence Gardner.

—Trappist the monk (talk) 18:28, 10 November 2021 (UTC)[reply]

I don't know if you can adjust your script to this, but I just noticed that this template automatically triggers an error message on any page it's used.

• United States Congress. "Trappist the monk/Archive 21 (id: A000303)". Biographical Directory of the United States Congress.

— Maile (talk) 22:53, 11 November 2021 (UTC)[reply]

I guess I don't understand what you really mean. You start out talking about [my] harv errors script (presumably User:Trappist the monk/HarvErrors.js). You then switch to talking about a template [that] automatically triggers an error message on any page it's used.

HarvErrors.js is javascript user script, not a template. Presumably the template that is giving you problems is {{CongBio}} because that is the template you included in your message. If there is something wrong with {{CongBio}} then you should voice your concerns at that template's talk page.

If you think that there is something wrong with the HarvErrors.js script then can you more clearly explain what the problem is? I do not see any errors here (HarvErrors.js is installed in my common.js).

—Trappist the monk (talk) 23:16, 11 November 2021 (UTC)[reply]

OK. I understand now. Thanks. — Maile (talk) 23:37, 11 November 2021 (UTC)[reply]

Edits Special:Diff/1054891812 and Special:Diff/1054891773 resulted in blanking, instead of the execution of task 19. —Mainframe98 _talk 16:55, 12 November 2021 (UTC)[reply]

Thanks for the report. I don't know what is causing that. I just reran task 19 on those two articles and they were not blanked. I hate intermittent problems because they are damned difficult to debug. There may be problems with AWB as well. I have a skip filter enabled that should skip articles that are blanked. That apparently isn't working as it should. Sigh.

—Trappist the monk (talk) 17:09, 12 November 2021 (UTC)[reply]

Well, the skip filter apparently works. I did a simple test with an awb options tab find and replace where I used a regex:

find: .+

replace: (left blank)

That find and replace finds anything and replaces it with nothing. I then set the skip filter as a regex to skip if the edited text doesn't contain .+ (anything) and to do the skip test after the replace-anything-with-nothing operation has been done. The test skipped as it should have.

Because Monkbot/task 19 is written in c#, I repeated the test by disabling the awb options tab find and replace and using the default c# module. In the default module code, I replaced:

ArticleText = "test \r\n\r\n" + ArticleText;

with

ArticleText = "";

This sets the variable ArticleText to empty string before it is returned to awb for publishing. With the skip filter set the same, my 'script' did not attempt to publish my now empty sandbox.

An alternate of the above experiment is:

ArticleText = null;

This causes a NullReferenceException error and halts processing. I'm not seeing any of these.

These tests were performed logged into awb both as myself and as Monkbot. I think that these tests indicate that Monkbot/task 19 itself is not to blame because it is not blanking ArticleText before it returns control to awb. If Monkbot/task 19 were blanking ArticleText then the awb skip filter would have caught the error.

—Trappist the monk (talk) 18:05, 12 November 2021 (UTC)[reply]

Nice comprehensive investigation! I had a glance at the code too but I couldn't see anything amiss. Perhaps the planets just aligned in such a way to conspire against Monkbot. I'm happy to see the edits did succeed a second time. —Mainframe98 _talk 18:36, 12 November 2021 (UTC)[reply]

Hi. Today I have carried out some fixes on Aru flying fox, Angel Island mouse and Atelopus varius after Monkbot did funny things. Would you mind taking a look? YorkshireExpat (talk) 19:04, 12 November 2021 (UTC)[reply]

Thanks for the report. Found the bug that made CRE from PE and fixed that (typo in a regex). The Atelopus varius issue is more complex and may take a while to suss out.

—Trappist the monk (talk) 19:38, 12 November 2021 (UTC)[reply]

No worries. Thanks for the update. YorkshireExpat (talk) 21:11, 12 November 2021 (UTC)[reply]

I think that the Atelopus varius issue is fixed.

—Trappist the monk (talk) 23:29, 12 November 2021 (UTC)[reply]

Thanks! YorkshireExpat (talk) 12:01, 13 November 2021 (UTC)[reply]

Hi Trappist! Regarding your reversion of my edit to Category:CS1: Julian–Gregorian uncertainty, could you please fix the error on User:Madicart/Salvatore Catalanotte so the category won't appear on Wikipedia:Database reports/Polluted categories anymore? Thanks! GoingBatty (talk) 18:55, 13 November 2021 (UTC)[reply]

Done. Simple fix. Only Module:Citation/CS1 should be adding pages to cs1|2 categories. cs1|2 never adds user-space pages. Please fix these kinds of problems when the occur rather than masking the problem by adding {{polluted category}} to the category.

—Trappist the monk (talk) 21:08, 13 November 2021 (UTC)[reply]

Thank you! I make fixes when I can, and only add {{polluted category}} as a last resort. GoingBatty (talk) 00:31, 14 November 2021 (UTC)[reply]

Hello, I am Aftabuzzaman from bnwiki. i saw this. If you help me, I am interested to implement your method on bnwiki. Please tell me what should i need to do. --আফতাবুজ্জামান (talk) 22:01, 13 November 2021 (UTC)[reply]

There is nothing ready to be implemented because what exists is mostly hacks I wrote to prove the concept. Fetching and displaying preexisting data is the simple part. I do not have a solution for the hard part: making it easy for editors to create and maintain the taxonomic data when those data are stored in lua data modules nor even were the data stored as tabular data at commons. That ease of creation and maintenance is the singular advantage of using wikidata but editors there are disinclined to support a set of QIDs and associated properties dedicated to the automatic taxobox system. Perhaps someone more eloquent and persuasive than I can ever hope to be will come along and champion the idea; perhaps a consensus will arise among the many other wikis so that support for an automatic taxobox system at wikidata will become inevitable. Until either of those or something else happens, I fear that the idea's time has not yet come.

—Trappist the monk (talk) 22:47, 13 November 2021 (UTC)[reply]

I understand your concern. However, current situation is even worse on bnwiki, we have almost nothing & importing 80K templates is impossible. I don't think a better solution will be come anytime soon (or years). Something is better that nothing, you solution might not be perfect but i'm willing to give it a try if you help (e.g. how to incorporate Module:Sandbox/trappist the monk/taxonomy with Module:Autotaxobox + some extra customaization for bnwiki). --আফতাবুজ্জামান (talk) 23:32, 13 November 2021 (UTC)[reply]

@আফতাবুজ্জামান, sorry to intervene and, of course, TTM will explain better, but I believe that what you ask is technically impossible. It needs the Wikidata aspect so it can generate data for the different species. Without that you'd more or less be left with just doing a similar "import 80K templates manually" job. But take my words with a lot of salt because most likely I'm wrong on at least half of them.

I followed up that Wikidata conversation and was sad to see it die out. I even contacted some of the involved editors privately but... I'm really not sure what our next move as small wikis should be. A similar thing of what you describe is what's happening at SqWiki. I don't deal with biology articles myself and that's my only consolidation but from a perspective of someone who deals with those it must be very frustrating to have some of the most active and big communities just shrug their shoulders when presented with this problem and not even have someone working on solving it actively (if we don't count TTM's attempt). The only solution is to work on a case by case basis, creating articles and following the trail of needed templates just for that and just enough so it works well enough for that article....

I'm almost inclined to ask if we at least can have a global bot to do the needed importations while offering some small localization support in some main strings. (Even though the system of EnWiki is almost unmaintainable in small wikis.) But I hardly believe someone from EnWiki will start an initiative like that for as long as the current system here works fine locally. - Klein Muçi (talk) 09:16, 15 November 2021 (UTC)[reply]

Using the compiled lua data modules as the data source for the automated taxobox system does not require wikidata. I wonder though (and I have not fully thought this out) if the |link= parameter from taxonomy templates might be replaced with a related wikidata qid as an aid to i18n. For example: Template:Taxonomy/Angiosperms has:

|link=Flowering plant|Angiosperms

What if, instead it had something like:

|link=Q25314|Angiosperms

Module:Autotaxobox could then be modified to use something like this to fetch the local wiki's article title for use in the wikilink:

wd_article = mw.wikibase.getSitelink (QID, this_wiki_lang_code .. 'wiki');			-- fetch article title from WD; nil when no title available at this wiki

In the above, this_wiki_lang_code is the language code of the local wiki (en for English, bn for Bengali, sq for Albanian, etc). If mw.wikibase.getSitelink() returns nil (no matching article at the local wiki) then Module:Autotaxobox can link to the label or put up an error message or ... For my example, wikidata lists quite a few articles (though not for sq.wiki).

This would solve some of the internationalization problem but does nothing to solve the editability problem...

—Trappist the monk (talk) 15:21, 15 November 2021 (UTC)[reply]

Just to let you know, I reverted this Monkbot edit. It broke the page. —Bruce1ee^talk 06:28, 13 November 2021 (UTC)[reply]

Hmm, that's peculiar. I'll have to think about that one. Thanks for the report.

—Trappist the monk (talk) 12:46, 13 November 2021 (UTC)[reply]

I think that I have fixed this issue. Task 19 has reedited Kosrae crake without apparent breakage.

—Trappist the monk (talk) 16:52, 13 November 2021 (UTC)[reply]

Thanks... —Bruce1ee^talk 16:57, 13 November 2021 (UTC)[reply]

Hey: I also reverted Monkbot edits, e.g. this one, because Monkbot 1) added obsolete parms like |volume= and |doi=; 2) removed the parm |author-link=; but 3) unnecessarily changed the ref name. 4) This ref and also the other one were already up to date. – BhagyaMani (talk) 08:56, 19 November 2021 (UTC)[reply]

Please continue at Wikipedia talk:WikiProject Tree of Life § Monkbot/task 19.

—Trappist the monk (talk) 15:35, 19 November 2021 (UTC)[reply]

Hi, updating IUCN status is a great thing, but there is a quirk. IUCN assessment is often used for statements in the text. Automatic updates risk attributing statements to IUCN that were true once but are not true for the updated version. This is quite likely to happen for organisms with long assessment cycles (e.g., amphibians). I have seen this happen many times for well-intentioning but unwary human editors. The only way to avoid this, I fear, is to keep the old IUCN assessment for the main text, perhaps flagging the article as requiring attention? What do you think? Cheers, Micromesistius (talk) 08:23, 17 November 2021 (UTC)[reply]

Real-life example of an article that meets these criteria?

—Trappist the monk (talk) 14:23, 17 November 2021 (UTC)[reply]

I did find an example at South American fox. The article wasn't using the iucn citation for a conservation assessment. Instead it used the IUCN reference as an example of a source still using he an old genus name. The new assessment uses the new name, so wasn't a suitable source. However, the comment was out of date and needed updating (fixed with this edit). So the end result was an error detected and fixed. —  Jts1882 | talk  14:40, 19 November 2021 (UTC)[reply]

In this edit Monkbot combined two references but missed one use which did not have the exact same refname format. This was later caught by AnomieBOT, so it was fine, but thought I'd drop a note in case it was worth adjusting Monkbot so that it can read the refnames with the flexibility AnomieBOT apparently has. CMD (talk) 09:42, 19 November 2021 (UTC)[reply]

Alas, a known problem for which I have not yet found a solution.

—Trappist the monk (talk) 15:39, 19 November 2021 (UTC)[reply]

Your updating of the IUCN citations is removing the dab & xrefs of the authors. For an example, see Compsophis laphystius. Lyttle-Wight (talk) 13:08, 19 November 2021 (UTC)[reply]

I've added the author links with this edit. I think it is preferable to have the iucn references using the {{cite iucn}} template. This will facilitate any updates if they change their website and link formats again. It also makes it possible for bots to find pages where the iucn have an updated assessment of the species. —  Jts1882 | talk  14:40, 19 November 2021 (UTC)[reply]

Please continue at Wikipedia talk:WikiProject Tree of Life § Monkbot/task 19.

—Trappist the monk (talk) 15:39, 19 November 2021 (UTC)[reply]

Hello! Voting in the 2021 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 6 December 2021. 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 2021 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:31, 23 November 2021 (UTC)[reply]

Hey Trappist! It's been a while. :)

I'm currently dealing with infoboxes at my homewiki and updating some of them to similar standards as EnWiki's. During this journey I saw that infoboxes can vary wildly in technical aspects. I wasn't particularly happy about this because given the VAST use they have, each small change to them is usually accompanied with lots of changes on the articles they are used on, to reconfigure the parameters. And these kind of stuff is what usually make people grab their pitchforks and torches. Being that they don't have a well crystallized standard throughout all EnWiki, they're usually prone to dynamical changes which in small wikis are hard to replicate because of the numbers of users, tools and bots needed to clean after these changes. I asked around and was shown The Infobox Wars and The Wikidata Way. Taking the Wikidata route seems actually better at first sight but I worry about some details: not finding enough technical counseling, straying further from EnWiki, which is what we are mostly tied with as a community for templates/modules and for articles lately (because of Content Translation Tool - CTT already has problems dealing with infoboxes which was 50% of what made me start the whole update thing, the other 50% being lint errors) and having to change every infobox ever gradually to start implementing the wikidata way. Therefore I've settled to just continue updating them with EnWiki in mind and maybe in the future consider Wikidata again.

Having said all that, I stumbled upon {{Chembox}}. First of all, it's the first template I find that doesn't follow the naming "convention" of having "infobox" in its name. But as I said, I'm not surprised by these changes anymore. I'm just surprised by its large number of templates in its suite. Some being compromised of only 1-2 lines of codes. I think that kind of infrastructure is to make way for its modular function but halfway through importing them, I got tired and thought about asking before finishing them: I don't think it can be done anything to it, no? In my mind "a lot of templates" = "old design, needs to be redesigned in a simpler manner with Lua" but I'm not sure if that's the case here. I thought I'd ask so, if maybe my belief is correct, I wouldn't have to delete them all from the start. Your expertise would be valued. :) - Klein Muçi (talk) 10:00, 15 November 2021 (UTC)[reply]

Yikes. If you are suggesting that all of those 200-ish templates could/should be consolidated into a smaller suite of lua modules, you'll get no argument from me. I shall not be the one to do it – outside of my areas of interest.

—Trappist the monk (talk) 16:23, 15 November 2021 (UTC)[reply]

Hmm, mostly I wanted to know if the consolidation was possible or no. Apparently it is possible. I was also hoping for you to lead me somewhere where to ask for help because I saw your latest contributions and I understood that you are still dealing with the taxonomic problem so you wouldn't be able to help much currently. (I'm grateful for that to be honest.) But I suppose I might give it a try at the talkpage of the template? And then, if nothing changes, I'll keep importing the remaining templates. - Klein Muçi (talk) 18:16, 15 November 2021 (UTC)[reply]

...Also... It's been a while I've wanted to get more involved with Lua, as you may remember. I'm 90% sure what I'll say next doesn't exist but if we already had somewhere something very similar with what needs to be done with the chembox template suite, I'd be happy to use that as an opportunity to learn and do the module consolidation work myself. But I believe if something similar enough for me to work on it existed, you'd have finished the work yourself, so... - Klein Muçi (talk) 19:10, 15 November 2021 (UTC)[reply]

I don't think that I know of any such place or thing though it would not surprise me to learn that such things exist – I did not know that {{chembox}} is as complicated as it is until you showed me.

—Trappist the monk (talk) 19:59, 15 November 2021 (UTC)[reply]

I see. I'll try my luck on the talk page then.

Just so that I don't start a new discussion precisely about this: What are your thoughts on this discussion? I was thinking to ask at WT:LUA but maybe there's no need. - Klein Muçi (talk) 21:50, 15 November 2021 (UTC)[reply]

Sorry for the disturbance but maybe you have missed my last comment here? - Klein Muçi (talk) 08:44, 19 November 2021 (UTC)[reply]

That is a developer issue; some developer or team of developers would have to figure out how to implement one-line-only editing. I very much doubt that the developers would see one-line-only editing as something beneficial to the MediaWiki editing tool-set. What might be nice is some way to choose a line (for example this line), click 'something' that would open the page in the editor and take you to that line. It used to be that clicking the back-trace links in the Script error popup like:

: in function "is_valid_accessdate"

would open the editor and jump to the specified line; hasn't jumped to the specified line for quite a while. But, this scheme could only work for modules that are smaller than 100k bytes because the line numbering is part of the syntax highlighting which is disabled for modules larger than 100k bytes. Not going to hold my breath for that. Would be nice to have the back-trace links working again...

—Trappist the monk (talk) 20:56, 20 November 2021 (UTC)[reply]

@Trappist the monk, oh yeah? I didn't know that used to be a functionality. That's what I'm suggesting as well there in that discussion (after I was told that editing single lines wouldn't be that much of a good idea): To be sent there to the line you wanted to edit or at least to have the specific line highlighted. The only change being that I was thinking of having an edit button be shown on the side of each line every time you hovered over a line and if you pressed that, it would work just like the back-trace link you talk about. Do you think it would be a good idea to ask for such a feature at Phabricator? And if so, how would you paraphrase it to be more easily understood by others? Your technical terminology is usually better than mine. - Klein Muçi (talk) 23:22, 20 November 2021 (UTC)[reply]

You could ask but I doubt that your request would be honored. As a first step, you might try hunting about in phabricator to see if the no-longer-working back-trace links have been reported and, if they have, what the resolution was. If reported and the result was something akin to 'won't-be-fixed-in-our-lifetime' then there is no point in asking about clicking a highlighted line at a module/js/css/json page to open the editor and jump to that line.

—Trappist the monk (talk) 00:28, 21 November 2021 (UTC)[reply]

Okay then, if I find anything in regard to it, I'll report here. If not, maybe you can help me formulate a request for that. :) - Klein Muçi (talk) 08:39, 21 November 2021 (UTC)[reply]

Hello back! I wasn't able to find anything after searching for some terms. Can you help me formulate the text to make a request for what we talked? - Klein Muçi (talk) 19:09, 24 November 2021 (UTC)[reply]

Rlink2 has given you a turkey! Turkeys promote WikiLove and hopefully this has made your day better. Spread the WikiLove by giving someone else a turkey, whether it be someone you have had disagreements with in the past or a good friend. Happy Thanksgiving! For your work on cite repair and CS1 error fixing Rlink2 (talk) 19:42, 25 November 2021 (UTC)[reply] Spread the goodness of turkey by adding {{subst:Thanksgiving Turkey}} to their talk page with a friendly message.

Hi Trappist, I just wanted to ask your advice on something. Is there a module which could read multiple values of instance of (P31) and look at their respective subclass of (P279) and tell me whether or not a particular entity is an instance of something? My particular use case is to know whether something is a lighthouse (Q39715) or not, and there are various subclasses it could be, e.g wooden lighthouse (Q66088335) or sparkplug lighthouse (Q7573695). Thanks — Martin (MSGJ · talk) 14:06, 27 November 2021 (UTC)[reply]

What I know about wikidata will fit in a thimble. Have you tried Module:WikidataIB and Module:Wd? Those are the only lua modules that I know of that deal with wikidata.

—Trappist the monk (talk) 14:14, 27 November 2021 (UTC)[reply]

Okay will do. Sorry I thought it might be related to your work on taxonomy — Martin (MSGJ · talk) 15:51, 27 November 2021 (UTC)[reply]

Hi,

I've been working on several categories on the CS1 maintenance page, and just stumbled onto "Category:CS1: abbreviated year range". I notice that it's on the CS1 properties page, not CS1 maintenance. Are the articles on this page supposed to be corrected, or are they just for some type of tracking purposes? The year formats seem to be contrary to Wikipedia:Manual_of_Style/Dates_and_numbers#Ranges but I want to be sure before systematically taking on these articles.

Ira

Ira Leviton (talk) 14:57, 29 November 2021 (UTC)[reply]

The discussion that created Category:CS1: abbreviated year range is at Help talk:Citation Style 1/Archive 71 § Request for new maintenance category for abbreviated year ranges in the date= parameter.

Properties cats, in and of themselves, do not indicate a need for 'maintenance' nor do they indicate that something is in error. Mostly they exist as tools to aid decision making when we consider future development in the cs1|2 module suite.

—Trappist the monk (talk) 15:28, 29 November 2021 (UTC)[reply]

Here are some of the generic titles for archive sites. Sometimes, when an archive is broken, or doesn't properly archive, these are some of the titles that come up

• "archive.ph"
• "Webpage archive"
• "archive.md"
• "ghostarchive.org"
• "Ghostarchive search"
• "Archiving error | Ghostarchive.org"

The rationale behind these ones, is that sometimes the archive sites will put up a captcha on their sites meaning that bots can not access the archived content. When this happens, the title of the page is simply "Webpage archive" or similar. Or sometimes, someone will put an archived link in a citation, not actually check to see if the page is archived, and then when a bot tries to fill the title, it gets the archived error title.

And of course, I am 99% percent sure you know of "attention required!" generic title on sites using DDOS Protection, but i am leaving that here in case you didn't know.

Rlink2 (talk) 00:53, 5 December 2021 (UTC)[reply]

Umm, what is this for? If this is about cs1|2 detecting generic titles, the proper place to discuss is at Help talk:Citation Style 1. If there is a bot or bots creating these titles then perhaps the best place to discuss is at the bot talk pages.

I looked for the titles that you suggest and found only three; not really enough of a problem for cs1|2 to worry about:

• "archive.ph" – 2

  Adam Dunn: added by your awb script

  Vijay Award for Best Find of the Year: added by Editor Hebrides using an awb script

• "Webpage archive" – 1

  AMCHA Initiative – not a bogus title

• "archive.md" – 0
• "ghostarchive.org" – 0
• "Ghostarchive search" – 0
• "Archiving error | Ghostarchive.org" – 0
• "attention required" – 0

—Trappist the monk (talk) 12:49, 5 December 2021 (UTC)[reply]

Ok, next time I will take it to the help talk page instead. I just thought i would let you know if there may been a problem, you would have the firsthand knowledge. Keep up the great work Rlink2 (talk) 13:02, 5 December 2021 (UTC)[reply]

A recently closed Request for Comment (RFC) reached consensus to remove Autopatrolled from the administrator user group. You may, similarly as with Edit Filter Manager, choose to self-assign this permission to yourself. This will be implemented the week of December 13th, but if you wish to self-assign you may do so now. To find out when the change has gone live or if you have any questions please visit the Administrator's Noticeboard. 20:07, 7 December 2021 (UTC)

An automated process has detected that when you recently edited Gangs of London (TV series), you added a link pointing to the disambiguation page Gareth Evans.

(Opt-out instructions.) --DPL bot (talk) 05:59, 10 December 2021 (UTC)[reply]

For some reason, all references using {{Cite newspaper The Times}} are showing a "redundant parameter" error, displayed as "More than one of |at= and |page= specified (help)". Anything to do with your recent edit to the template? Mjroots (talk) 07:13, 23 December 2021 (UTC)[reply]

Indeed, Category:CS1 errors: redundant parameter has suddenly grown from 0 to 250. I looked at a few, which were using "page=" in {{Cite newspaper The Times}} rather than "page_number=". Oculi (talk) 12:15, 23 December 2021 (UTC)[reply]

@Oculi: that template has used |page= since it was created. Mjroots (talk) 12:58, 23 December 2021 (UTC)[reply]

I know nothing about the template; I am merely quoting from {{Cite newspaper The Times}} which gives |page_number= and not |page= under "Usage". I agree with Trappist the monk (below) that this is inconsistent (and unexpected). Oculi (talk) 13:20, 23 December 2021 (UTC)[reply]

Thanks for the report. Fixed. I think that |page_number= and |page_numbers= should be deprecated in favor of |page= and |pages= (and their cs1|2 aliases |p= and |pp=). The |page_number(s)= parameter names are too long and the underscore separator is inconsistent with the hyphen separator used in {{cite news}} (and all other cs1|2 templates) upon which {{cite newspaper The Times}} is based.

—Trappist the monk (talk) 13:11, 23 December 2021 (UTC)[reply]

Template talk:Cite newspaper The Times § parameters that ought to be deprecated and removed

—Trappist the monk (talk) 16:04, 23 December 2021 (UTC)[reply]

	Merry Christmas and a Prosperous 2022!!
	Hello Trappist the monk, warm wishes to you and your family throughout the holiday season. May your heart and home be filled with all of the joys the festive season brings. Here is a toast to a Merry Christmas and prosperous New Year!. scope_creepTalk 00:42, 24 December 2021 (UTC)[reply]

Template:Cite vf lineage has been listed at templates for discussion. You are invited to comment on the discussion at the entry on the Templates for discussion page. User:GKFX^talk 21:48, 24 December 2021 (UTC)[reply]

Hello can you remove my IPBE, it seems the block on my range has expired so I can still use SW viewer and other tools. I hope I can request it back when I need it. Cheers --Megan B.... ^{It’s all coming to me} till the end of time 19:05, 25 December 2021 (UTC)[reply]

I can, but why are you coming to me for this and not going to The Anome who granted your WP:IPBE on 13 December 2021 (Special:UserRights/Synoman_Barris)? Your request is outside of my normal bailiwick so it would probably be better for you to find another who can remove the exemption.

—Trappist the monk (talk) 19:25, 25 December 2021 (UTC)[reply]

Sorry, I thought one could ask any active admins, so I checked the logs and you were active so I asked. Otherwise I'll directly ask the Anome. Cheers --Megan B.... ^{It’s all coming to me} till the end of time 20:21, 25 December 2021 (UTC)[reply]

I can't see any reason for removing the IPBE, which is generally granted to any well-established editor who asks and doesn't usually need removal, but I will do so since Synoman Barris has asked.  Done -- The Anome (talk) 23:47, 25 December 2021 (UTC)[reply]

Template:Currency/new has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Gonnym (talk) 09:18, 31 December 2021 (UTC)[reply]

A token of thanks Hi Trappist the monk! I've nominated you (along with all other active admins) to receive a solstice season gift from the WMF. Talk page stalkers are invited to comment at the nomination. Enjoy! Cheers, {{u|Sdkb}} talk ~~~~~

MediaWiki message delivery (talk) 23:50, 31 December 2021 (UTC)[reply]

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:14, 4 January 2022 (UTC)

Hi! As you know we changed Cs1 on dawiki. THANKS A MILLION FOR THE HELP!

We started IABot again and I noticed that sometimes it uses {{Cite web}} and sometimes it uses {{Webarchive}}. I have not figured out when to use Webarchive instead of Cite web. Perhaps you can tell me? Do you also know how to configure the bot if we want to change the way the bot adds the templates? --MGA73 (talk) 11:17, 30 December 2021 (UTC)[reply]

I am not sure that I fully understand your question so maybe this answer is not the answer that you want. I am not an IABot expert but, I think that IABot creates {{Webarchive}} templates for plain external link markup. For example, the bot converted this:

<ref name="Fellow">[[Benjamin Penny]], Canberra, 2001, [http://www.nla.gov.au/grants/haroldwhite/papers/bpenny.html The Past, Present and Future of Falun Gong, A lecture by Harold White Fellow, Benjamin Penny, at the National Library of Australia], accessed 31 December 2007</ref>

to this:

<ref name="Fellow">[[Benjamin Penny]], Canberra, 2001, [http://www.nla.gov.au/grants/haroldwhite/papers/bpenny.html The Past, Present and Future of Falun Gong, A lecture by Harold White Fellow, Benjamin Penny, at the National Library of Australia] {{Webarchive|url=https://web.archive.org/web/20080325202921/http://www.nla.gov.au/grants/haroldwhite/papers/bpenny.html |date=25 March 2008 }}, accessed 31 December 2007</ref>

If the original citation had been written as a cs1|2 template, I suspect that the bot would have add |archive-url= and |archive-date= to that cs1|2 template.

Because I am not an IABot expert, I do not know anything about its configuration settings. Perhaps you should ask the bot's operator Cyberpower678 those questions.

—Trappist the monk (talk) 12:55, 30 December 2021 (UTC)[reply]

Thank you. I will ask Cyberpower678. I noticed that in some cases like da:Special:Diff/10969426 the bot creates a {{Cite web}} but in other cases it creates {{Webarchive}} (like in the example you mention). --MGA73 (talk) 11:01, 31 December 2021 (UTC)[reply]

Another question. The category Category:Pages containing links to subscription-only content does not seem to be added. Is that on purpose or a mistake? --MGA73 (talk) 14:13, 31 December 2021 (UTC)[reply]

Intentional. Removed as a result of Help talk:Citation Style 1/Archive 55 § Categorization of registration/subscription. Category:Pages containing links to subscription-only content is filled (at en.wiki) by {{Subscription required}}. I believe that cs1|2-filled categories should be filled only by cs1|2 templates; sharing with other templates just causes confusion.

If you are feeling adventurous, you might want to import Module:cs1 documentation support. With that you can create something like Module:Citation/CS1/doc/Category list so that you can see what categories your cs1|2 module suite uses.

Caveat lector: the code in that module is a hack and does not consider i18n. If you must make changes to make it usable, let me know what those are and I will attempt to tweak the en.wiki version to make future updates easier.

—Trappist the monk (talk) 14:46, 31 December 2021 (UTC)[reply]

Thank you. Yes I agree that there should be separate categories for cs1|2 stuff so it is not mixed with other stuff. User:Steenth have used some of the tricks in da:Bruger:Steenth/sandkasse70 so I will talk to him about the support module. --MGA73 (talk) 15:31, 31 December 2021 (UTC)[reply]

Hi! The Danish way to use hyphen and dash is not the same as the English way. I tried to fix it before I implemented the new version but I think it does still not work 100% correct so I/we have to go fix it.

I noticed that in the sandbox on enwiki the code has been moved from main module to ~/Utilities. I think we should do the same on dawiki to make sure the modules are as similar as possible.

Can you think of a better way to do it than we/I did on dawiki?

In short the rules in Danish are that we use hyphen (short) here:

• Pages and numbers are written like 34-35
• Years are written like 1963-1968 or 1963-68
• Day-ranges within the same month is written like 3.-5. juni 2019
• Month-ranges within the same year is written like maj-juni 2019

And we use dash (long) here:

• Combined ranges dm – dmy is written like 3. maj – 5. juni 2019
• Combined ranges dmy – dmy is written like 3. maj 2018 – 5. juni 2019
• Combined ranges my – my is written like maj 2018 – juni 2019

If you do know a better way I would be happy to get at tip before I start testing changes. --MGA73 (talk) 12:43, 6 January 2022 (UTC)[reply]

Hi there, I don't know if you remember me, but I remembered you and your very good knowledge of lua ;) Given that lua code https://commons.wikimedia.org/wiki/Module:Adjacent_stations and this problem https://www.wikidata.org/wiki/Topic:Wnhppy5q96kkf5ld Sorry it's in french, so I'll try to resume the problem : The adjacent stations module tries to collect data only from Wikidata and to build up a lua-table telling that that station goes there or there thanks to this subway line. In https://fr.wikipedia.org/wiki/Mod%C3%A8le:Stations_voisines#Exemples 95% tables will work with adjacent stations in their correct east/west or north/south direction. However, in ~5% of cases, the table will show weirdly because subway lines won't run in a clear bearing direction (zigzags, circular lines, etc). Would it be possible to build a simple lua function that would test the degree and tell if the adjacent is on its west, east, south, north thanks to bearings comparison ? Perhaps a kind of formula like there https://stackoverflow.com/questions/8123049/calculate-bearing-between-two-locations-lat-long That function would be bearing(the_current_station,the_neighbour_station) and would return their β like in https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ So that it would be possible to compare their bearings and organise the final table. Don't hesitate to tell me if it's annoying you, just asking. Sincerely, Bouzinac (talk) 20:35, 5 January 2022 (UTC)[reply]

Isn't this a question better asked of the module's author?

Still, for my own amusement, I hacked Module:Sandbox/trappist the monk/bearing which returns a bearing using the equations from https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/. Is that what you want?

—Trappist the monk (talk) 00:30, 6 January 2022 (UTC)[reply]

Hello, yes, it was that function I needed into Lua. Still testing https://commons.wikimedia.org/wiki/Template:Adjacent_stations#Sandbox with the creator Eru, thank you very much!

A Bouzinac (talk) 07:22, 7 January 2022 (UTC)[reply]

An editor has identified a potential problem with the redirect Template:Currency/new and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 January 7#Template:Currency/new until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. Gonnym (talk) 11:33, 7 January 2022 (UTC)[reply]

I wish you a Happy -and healthy- New Year! Many thanks for all your help! Your advice has done miracles for us at el.wikt (e.g. articles at declensions and lots of pages for functions). I would not be able to make them without you! Sarri.greek (talk) 15:16, 8 January 2022 (UTC)[reply]

Sorry to clog up the native_name discussion with off-topic stuff - but I figured there's no time like the new year for me to stop dragging my feet and finally address reworking {{nihongo}}, and its problem children/cousins.

The problem I've run into time and time again is that unlike {{lang-zh}}, none of the parameters in {{nihongo}}, and its sister template {{nihongo3}}, are marked. Both are written up as:

{{nihongo[3]|[English]|[Japanese text]|[romanisation]}}

- with the only difference being Nihongo3 displaying English text in brackets, and romanisation first:

• "flower" (花, hana)
• hana (花, "flower")

Because they're unmarked, I've seen editors place romanisation and English text in either end, and occasionally kanji in the wrong place altogether. I've seen text that actually has a place in the template booted to the |extra= parameter at the back as well.

The most basic fix would be the addition of parameter names to these templates. This would, at least, give editors a visual clue as to what goes where.

Building on this is that I think these templates could be combined altogether with the addition of an ordering parameter.

{{lang-zh}} does this well, though it has a few limitations; per the template, it allows editors to override default parameter order, but only supports the reordering of two values. Ideally, you'd want editors to be able to reorder text how they wished, with the obvious addition of the |links= and |labels= parameters. This would avoid the problems altogether, creating an easier to use {{lang-zh}}-style template. Text following the parameter ordered first would be placed in parentheses automatically.

I haven't mentioned a number of other nihongo templates in existence, and that's because I think we can bin 'em with no great loss, if we're going to rework {{nihongo}}. Here are the problem children:

• {{nihongo2}} (LinkCount)- identical to {{lang}}. No reason for its existence.
• {{nihongo krt}} (LinkCount) - places kanji first; defunct if {{nihongo}} gets reworked with a |first= parameter. Not many instances of this one iirc.
• {{nihongo foot}} (LinkCount)- places everything after the English into a footnote. Could possibly be fixed by an additional |fn= parameter? Would place everything after the first parameter in a footnote.
• {{nihongo-s}} - a simplified version of {{nihongo}} which handles instances where, if {{nihongo}} is called hundreds of times, the post-expand limit is exceeded. I don't have much technical knowledge, so I'm not sure about this one. LinkCount shows that it's barely used, so I have a notion this might have been intended to fix a problem in previous years that is no longer much of a problem.

Please let me know what you think - I'd love to put together a more comprehensive 'start here' guide for Wikipedia's language templates someday that would allow users to search for specialist templates for certain languages, as at the moment, it feels like anything outside of {{lang}} and {{transl}} doesn't obviously present itself. Sorting out these templates is a small start, but it's something. Thanks!--Ineffablebookkeeper (talk) ({{ping}} me!) 12:46, 1 January 2022 (UTC)[reply]

No templates in section headers ...

I too have seen mispositioned parameter values in {{nihongo}} so named parameters are not a bad remedy and can be done in parallel with their traditional positional parameters. No doubt a bot can be created to replace positional with named (except that such a change is transparent to readers so runs afoul of WP:COSMETICBOT). I suppose that we might create |eng= (or |trans=), |kan=, and |hep=. According to Template:Nihongo (Q6003159) there are 112 other wikis that use some flavor of {{nihongo}} though only 11 that use some flavor of Module:Nihongo (Module:Nihongo (Q99589699)). By choosing these prospective parameter names, at other wikis, |eng= can be replaced with the local ISO 639-3 language tag; kan and hep are not (currently) used by ISO 639-3. |kan= seems a suitable shortening of both kanji and kana and |hep= a suitable shortening of Hepburn which, as I understand it, is the standard used at en.wiki for Japanese romanization.

{{nihongo2}} – It might be possible to tfd this template and make it go away. Except for a user defined css class, class="t_nihongo_kanji" {{nihongo2}} is for all intents and purposes identical to {{lang}}. According to this search, there are only six users who have that class defined in their personal css, all but one recently active. If we are to believe the template documentation, there is another way to accomplish the styling enabled by class="t_nihongo_kanji". If the result of a tfd is keep, I think that the help code that used to be in the templates now rendered by Module:Nihongo can go away. So some improvement.

{{nihongo-s}} – survived a previous tfd (no consensus to delete); see Wikipedia:Templates for discussion/Log/2020 February 2 § Template:Nihongo-s.

Combining into one template:

|order= – I think that there are six possible orderings of the rendered parameters (E = English, K=janji/kana, H=Hepburn):

EKH (order for {{nihongo}}, {{nihongo foot}})

EHK

HEK

HKE (order for {{nihongo3}})

KHE (order for {{nihongo krt}})

KEH

did I miss any? I suppose that it is possible to create formatting tables for all of these but are all of them really necessary? And what about the template specific parameters:

|lead= – {{nihongo}}, {{nihongo foot}}

|post= – {{nihongo foot}}

|group= – {{nihongo foot}}

I suppose that the template can be made to be smart enough to know that |group= and |post= both require |fn=yes to function

I'm sure that there is more that I haven't thought about yet...

—Trappist the monk (talk) 22:43, 1 January 2022 (UTC)[reply]

Apologies for the inclusion of template links in a section header - that's something I should know not to do by now(!)

See, I'm not sure a bot would necessarily run afoul of WP:COSMETICBOT; it states that cosmetic changes "may be allowed in an edit that also includes a substantive change", defined as changes that "affect something visible to readers and consumers of Wikipedia, such as the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs, or when accessed through other forms of assistive technology". Seeing as this is an accessibility template we'd be changing, and not purely an aesthetic one, I think a bot would possibly have more of a leg to stand on, but I don't know.

I'd choose |eng= over |trans=, as the latter looks too close to {{transl}} and might get mixed up. As you say, it'll be useful for non-English language Wikipedias as well; the |kan= and |hep= parameters also look good, though if ISO codes using these letters do arise, I don't know how this would affect things.

If the only extra {{nihongo2}} adds at the minute is a CSS style very few editors use, then I think you're right in that a TfD could probably give this one the boot. I've never actually used a custom CSS style, but I'm sure I've seen mention that it's something user settings typically take care of; if this is the case, I'm not sure why a template has to pick up the slack.

{{nihongo-s}} - the TfD implies that it holds together a few very large articles at the minute, so I can see how it survived, even with no consensus. I could potentially see post-expand limits being less of a problem for Wikipedia in the future, as browsers improve and the max article size limit potentially increases. It may be we leave this for a few years and take it for a TfD spin again when things have changed.

I don't think you've missed any combinations of parameters there, unless I'm missing something myself. (I'm afraid I don't know what "formatting tables" means, so I can't help you there.)

Template-specific parameters - I haven't seen |lead= used that often but I'd encourage its enclusion. The |post= and |group= parameters could be included - I'd assume they don't violate the fact that language templates can mess up CS1 and CS2 formatting. I tend to use {{efn}} for all footnotes I use, so I don't think I'd really use them, but some editors might.--Ineffablebookkeeper (talk) ({{ping}} me!) 11:33, 4 January 2022 (UTC)[reply]

I'll note that {{nihongo-s}} survived TfD solely based on your comments Trappist the monk. If anything has changed with your opinion I'm sure the result would change as well. Gonnym (talk) 12:39, 4 January 2022 (UTC)[reply]

Are you sure? I think that what I wrote there is what I intended to write. I think that what I wrote was in support of my initial statement: I see no reason to prefer {{nihongo-s}} over {{nihongo}}. Here is the table from the tfd extended to include numbers taken today:

post-expand include size of articles using {{nihongo-s}}

from the tfd				as of 2021-01-04
article	transclusions	with {{nihongo-s}}	with {{nihongo}}	transclusions	with {{nihongo-s}}	with {{nihongo}}
List of Initial D chapters	670	404,449	1,376,806	724	818,008	1,436,474
List of manga artists	743	156,537	349,176	755	143,934	354,463
List of Naruto chapters (Part I)	217	521,659	688,945	217	491,503	673,978
List of Naruto chapters (Part II, volumes 28–48)	188	434,774	580,771	188	408,471	567,628
List of Naruto chapters (Part II, volumes 49–72)	223	476,681	647,965	223	446,691	633,585

—Trappist the monk (talk) 20:57, 4 January 2022 (UTC)[reply]

There were only 6 people that commented. Doug Mehus said that they support whatever Trialpears or Pppery suggest; Pppery commented that he won't comment on this; Trialpears leaned delete but wanted to hear from you; davidwr made an unrelated comment. I proposed the deletion. That leaves your comment. While you did write I see no reason to prefer [...]", everything that came after to me read as a keep, which is why I tried to understand your position; see my comment at I obviously understand the issue. I'm trying to understand what Trappist's position regarding that issue is. While I can't read Primefac's mind, he might have been confused here also. It would help if you used a bold "keep" or "delete" statement at the start so it would be easier to understand the rest. Gonnym (talk) 11:39, 5 January 2022 (UTC)[reply]

Numerical 'vote' tallies aren't to be considered when establishing consensus so I don't provide a 'vote' indicator. I want closers to actually read what I wrote and decide for themselves what I think; if they have questions about what I wrote, they should ask me.

—Trappist the monk (talk) 15:41, 5 January 2022 (UTC)[reply]

A bot that combines the various flavors of {{nihongo}} into a single template would, for example, change:

{{nihongo|'flower'|花|hana}} → {{nihongo|eng='flower'|kan=花|hep=hana|order=EKH}}

{{nihongo3|'flower'|花|hana}} → {{nihongo|eng='flower'|kan=花|hep=hana|order=HKE}}

Because the rendering that the reader sees does not change, because the underlying html does not change, that kind of change is cosmetic.

The formatting tables are in Module:Nihongo at line 91 ({{nihongo}}), line 146 ({{nihongo3}}), line 200 ({{nihongo krt}}), and line 265 ({{nihongo foot}}).

No {{nihongo}} family template ever belongs in cs1|2 templates except, perhaps in |quote=. If the cs1|2 citation is wrapped in a <ref>...</ref> tag, using {{nihongo foot}} in |quote= will cause a ref stripmarker in |quote= at position n message and a Cite error: A list-defined reference has no name message.

—Trappist the monk (talk) 20:57, 4 January 2022 (UTC)[reply]

@Trappist the monk: - I would've assumed language tags couldn't be used in |quote= as well. Assuming {{nihongo foot}} doesn't already break CS1 and CS2 formatting, am I correct in assuming the addition of |fn= to a reworked nihongo tag wouldn't break this?

Even if this would be a cosmetic change, I would still argue that we could seek consensus for a bot to undergo these edits; there's simply too many instances of nihongo templates on this wiki for even a handful of editors to reasonably deal with. Per WP:COSMETICBOT:

Consensus can, as always, create exceptions for particular cosmetic edits. For example, the community frequently determines that a particular template should be substituted so it can be deleted, even though the substitution does not change the output of the page. Consensus for a bot to make any particular cosmetic change must be formalized in an approved request for approval.

I think we could request approval and build consensus that this kind of bot really does have a place on-wiki. We could always have a look at how the consolidation of Wikipedia's once-numerous Chinese language templates was undertaken for examples, though I don't know if we'd find anything relevant.--Ineffablebookkeeper (talk) ({{ping}} me!) 11:30, 5 January 2022 (UTC)[reply]

{{nihongo foot}} in cs1|2 template |quote= parameters will break those templates when they are wrapped in <ref>...</ref> tags. The consolidated {{nihongo|fn=...}} will also break the cs1|2 templates are wrapped in <ref>...</ref> tags.

I wrote Monkbot/task 18 which was a wholly cosmetic task. The task was properly formalized at a BRFA. Editors did not like it and after an rfc and other drama, the task was withdrawn. I'm not interested in writing another cosmetic bot.

—Trappist the monk (talk) 15:41, 5 January 2022 (UTC)[reply]

@Trappist the monk: - sorry to hear that Monkbot 18 got skewered; this makes it a much larger task if we have to replace all 97,698 transclusions of {{nihongo}} and 12,013 of {{nihongo2}} by hand, though {{nihongo3}} has only 1,200.

I've noticed some bots go around replacing or deleting templates that no longer exist - how would this interact with a rolled-together nihongo template? I've found a few instances of the now-deleted {{nihongo4}} in the past that don't seem to have been scooped up by these bots; I know they can't get everything.

Perhaps we could have a bot that adds articles with instances of old nihongo tags to a special category? If I'm right, bot policy allows for: "the "administration of the encyclopedia", such as the maintenance of hidden categories used to track maintenance backlogs" - which cleanup of old templates would be, right? A maintenance category for template cleanup. It would allow us to track changes but it wouldn't necessarily be breaking WP:COSMETICBOT, I think.

I do think that a bot replacing {{nihongo2}} would still be ideal. It's a one-note template with the correct language code already baked-in - per bot policy, it doesn't have to work at the speed of light, and these wouldn't be edits that would have a higher chance of going wrong, seeing as the template has only one damn parameter. Replacing 12,000 instances of the same one-para template by hand is a gruelling task, and I genuinely see no benefit to having editors do this task over a bot.

I understand that watchlist spam is a pain, but if we have a bot chuntering away in the background at a pace that isn't the speed of light, we can go about handling the much more complex template replacements without having to worry about it. I understand per the RfC that Monkbot 18 would've handled somewhere in the realm of two million articles, with a number of parameters; this would be 12,000 transclusions with one parameter. I wouldn't be able to write the bot, but I would strongly suggest its existence as necessary.

And, if I'm right in reading this, so long as either {{nihongo foot}} or a new nihongo with |fn= don't get wrapped in ref tags, they won't break formatting - that doesn't seem any different to how things are now, so that shouldn't pose a problem. Language templates of any kind shouldn't be in a ref tag anyway.--Ineffablebookkeeper (talk) ({{ping}} me!) 12:28, 8 January 2022 (UTC)[reply]

Language templates of any kind shouldn't be in a ref tag anyway. Why not? If the language of text assigned to |quote= is not English, then it should be marked up with a language template so that it is rendered (browsers) or spoken (screen readers) correctly.

You can always take {{nihongo2}} to WP:TFD. If the decision there is to replace all instances with {{lang}} and then delete, there are mechanisms in place to handle that.

—Trappist the monk (talk) 20:02, 8 January 2022 (UTC)[reply]

I just came to say that I love the idea of merging all the nihongo modules into a single module with a "first=" function. Every time I see one of the nihongo modules, I often can't remember which variable shows first (except krt, where it's in the name). So this is definitely helpful for editors. (although it seems like a lot of coding might be required...) — JKVeganAbroad (talk) 02:39, 9 January 2022 (UTC)[reply]

Are there any books, wiki pages, websites, videos, etc... that can help me learn more about Scrubunto and Lua? I am working on cite templates on other language wikis so resources to help improve my skills are helpful. I thought that you would know. Thanks Rlink2 (talk)

What I know about Lua and Scribunto I have learned from WP:LUA, internet searches, and trial and error.

—Trappist the monk (talk) 18:13, 10 January 2022 (UTC)[reply]

Some researchers associate the Oghuz dialect of Qara-qoyunlu with the Azerbaijani language. For example, Faruk Shumer noted that the Eastern Oghuz dialect of Qara-Qoyunlu is called the Azerbaijani language today, while Muhsin Behramnejad noted that he called the Azerbaijani language a legacy inherited from the Kara-Qoyunlu Turkoman tribes. Sultan Kara-Koyunlu 1435-1467 Jahanshah is a generally recognized representative of Azerbaijani poetry

(Sources) ⬇️⬇️⬇️ Aydın memmedov2000 (talk) 18:15, 21 January 2022 (UTC)[reply]

M. Faruk Sümer, «Kara Koyunlular», s. VIII:

M. Behramnejad, «Karakoyunlular, Akkoyunlular: Iran ve Anadoluda Türkmen Hanedanları», s. 14: Aydın memmedov2000 (talk) 18:15, 21 January 2022 (UTC)[reply]

I want to add the text above. There is a source, but the source is Turkish. I translated it from Turkish to English. I can also give the link of the books. The books are in Turkish and written by Faruk Sümer, the well-known historian of Turkey. Aydın memmedov2000 (talk) 18:16, 21 January 2022 (UTC)[reply]

Sorry, but I don't know what you're talking about. If this is about Azerbaijani language, perhaps you should be discussing at Talk:Azerbaijani language.

—Trappist the monk (talk) 18:35, 21 January 2022 (UTC)[reply]

Actually, I was talking about the Qara Qoyunlu state. I understand, never mind Aydın memmedov2000 (talk) 18:42, 21 January 2022 (UTC)[reply]

What's the new category? Because this was quite useful. Headbomb {t · c · p · b} 15:21, 22 January 2022 (UTC)[reply]

{{cite book |title=Title |ref=harv}}

Title. {{cite book}}: Invalid |ref=harv (help) → Category:CS1 errors: invalid parameter value

—Trappist the monk (talk) 15:26, 22 January 2022 (UTC)[reply]

That's a very very generic category. Not an improvement. Headbomb {t · c · p · b} 18:39, 22 January 2022 (UTC)[reply]

Hello Trappist the monk. I am currently in the RfC-before stage of developing an RfC and believe that you could help. There is an open request at Wikipedia talk:Consensus/No consensus RfC 2022#Request for help with statistics and search string formulation that would benefit from any help you are willing to give. Thank you.--John Cline (talk) 18:34, 23 January 2022 (UTC)[reply]

This a real improvement ... but is flooding my watchlist. I have lately been starting a string of articles on Corsican rivers, lakes, lagoons, reservoirs where there are two native languages, French and Corsican. I sometimes give the article the French name as title and add Corsican native name in the infobox, but much better would be title "Santa Giulia Lagoon" with

{{native name list |tag1=fr |name1=Étang de Santa Giulia |tag2=co |name2=Stagnu di Santa Ghjulia}}

Thanks for taking the effort to sort this out. But I wonder if template:Native name list or module:native name should be tweaked so that |tag1 defaults to {{{1}}}, |name1 defaults to {{{2}}} and so on, to allow a shorthand

{{native name list |fr|Étang de Santa Giulia |co|Stagnu di Santa Ghjulia}}

Aymatth2 (talk) 22:23, 9 January 2022 (UTC)[reply]

{{native name list}} is constrained to named parameters because supporting both positional and named parameters becomes a headache when an unlimited number of parameter sets is required/allowed. As it is, the error reporting is less than I would like so there is still work that needs doing.

—Trappist the monk (talk) 22:47, 9 January 2022 (UTC)[reply]

I am tempted to start a {{native name2}} template, that supports three positional language/name pairs and no other parameters, using module:native name for error checking and formatting. It would probably meet 99% of cases. Aymatth2 (talk) 00:42, 10 January 2022 (UTC)[reply]

Another approach would be to have the infoboxes ask:

| native_name =
| native_name_lang =
| native_name2 =
| native_name_lang2 =
| native_names = <!-- {{native name list |tag1= |name1= |tag2= |name2= ...}} -->

Some other templates take this approach. It is backward compatible, solves the two-language problem, allows all the advanced features for those who want them, but do not require typical editors to learn the {{native name}} or {{native name list}} syntax - they just fill in the fields. Aymatth2 (talk) 02:16, 10 January 2022 (UTC)[reply]

Were there but one infobox template that uses |native_name=, I might agree with you. But, there are some 200-ish infoboxen that use that parameter. Five of those, {{infobox body of water}}, {{infobox mountain}}, {{infobox river}}, {{infobox street}}, and {{infobox valley}}, the five that started me on this path, all had variants of the same code to handle (poorly) |native_name= and |native_name_lang= but none of the five had exactly the same code. Not good to clone code across a plethora of templates.

—Trappist the monk (talk) 18:11, 10 January 2022 (UTC)[reply]

They could all embed the same sub-template to format the prompt and generate the output. I am just concerned that a lot of editors are comfortable using cut-and-paste to copy an infobox into an article but may struggle with a template, and {{native name list}} has rather awkward syntax. Aymatth2 (talk) 18:54, 10 January 2022 (UTC)[reply]

I agree that |native_name= and |native_name_lang= would more intuitive for the many thousands of editors who do not edit frequently, don't know or understand templates, etc. I think requiring use of {{native name list}} for any number more that 1 is fine (that would work for maybe 95%). Either approach is going to require ongoing gnoming to clean up errors. MB 00:13, 11 January 2022 (UTC)[reply]

So a fairly simple solution, backward compatible, would be for each infobox to have parameters:

| native_name =
| native_name_lang =
| native_name_list = <!-- {{native name list |name1= |tag1= |name2= |tag2=...}} -->

The code for validating and formatting that should be the same in all the infoboxes, perhaps something like:

| label5 = Native name
| data5 = {{format native name |name={{{native_name|}}} |lang={{{native_name_lang|}}} |list={{{native_name_list|}}} }}

Aymatth2 (talk) 12:46, 11 January 2022 (UTC)[reply]

Looking at this search it is clear that cleaning up native names in articles will be a massive task. Backward compatibility seems essential. That is,

• Add |native_name_lang= and |native_name_list= parameters to templates that do not have them, and add {{format native name}} to validate and display the names
• {{format native name}} may need parameters to support legitimate infobox-specific variations in the appearance of the names
• {{format native name}} should probably support any of

  |native_name = Sint Maarten |native_name_lang=nl
  |native_name = {{native name|nl|Sint Maarten}}
  |native_name = {{native name list|tag1=nl|name1=Sint Maarten}}

• Do not reject names that fail native name checker: make the best guess at formatting, but add to hidden error categories

Then it will be possible for gnomes to work through the error categories cleaning up the articles, and the quality should steadily improve. Once the problem is reduced to a manageable size, add errors messages to discourage new garbage values. @MB: any comments? Aymatth2 (talk) 13:29, 12 January 2022 (UTC)[reply]

I agree templates should have |native_name= and |native_name_lang= as most user friendly/simply way for novice editors. Having the language parameter will encourage them to put something there, which can be a big help for a gnome to covert it to a proper country code. I am not sure we need |native_name_list=, I like the approach above where |native_name= supports plain text, {{native name}}, and {{native_name_list}}. MB 15:12, 12 January 2022 (UTC)[reply]

I was sort of thinking of support for {{native name}} as being transitional, with the goal being |native_name=text and |native_name_lang=ISO code for single names, which probably covers most cases, and |native_name_list={{native_name_list}} for multiple names. The multi-format nature of |native_name= would not be documented and would eventually be dropped. Not sure why that should be the long term goal though. It seems tidier to give each parameter a single format, maybe.

Should this discussion be somewhere more visible, like the Village Pump? The decision affects many of the common infoboxes. Aymatth2 (talk) 18:29, 12 January 2022 (UTC)[reply]

(edit conflict)

The search, I think, like many cirrus searches, should not be considered to be wholly reliable. Searches should be prefiltered so I included hastemplate:"Module:Infobox" and and modified your original search string to allow for the possibility of one or more space characters between the opening pipe and the parameter name and to not require a space character after the parameter name:

~538,000 results

You would think that you could write a similar search string that would return articles that have |native_name= without an assigned value and get a meaningful result; alas, no:

685

Go back to my first search and use your browser's string search (ctrl+f or whatever) with this: native_name = |. When I did it on the cirrus search results, ctrl+f found 1344 of 5000 search returns with empty |native_name=. So, roughly a quarter of 538,000 or 134,500 are blank which leaves 403,500.

Tweaking the search to look for |native_name_lang=: ~207,000 articles; ctrl-f for native_name_lang = |: 1713 so roughly a third are blank which leaves 138,000.

But, all of these huge numbers may be misleading. We know from what has appeared in Category:Native name template errors (0) and Category:Native name checker template errors (0) that nowhere near 400k articles have errors that need fixing. At this writing there are 855 articles in Category:Native name template errors of which 851 use {{Infobox river}} and 4 use {{infobox tree}}.

This search seems to suggest that very few of the infoboxen that support |native_name= and |native_name_lang= call {{native name}}.

—Trappist the monk (talk) 18:51, 12 January 2022 (UTC)[reply]

It is a massive problem. I was looking at what values were given for |native_name= in my crude search and see (skipping the blank ones) but not selecting otherwise:

• |native_name = Torre Pendente di Pisa
  |native_name_lang = it
• |native_name = <small>''Tywysog Cymru''</small>
• |native_name = <small>{{Script/Hebrew|הכנסת}}</small>
• |native_name = {{lang|sv|Nobelpriset i fysiologi eller medicin}}
• |native_name = ''Republik Indonesia''
• |native_name = {{native name|la|Regnum Hierosolymitanum}}
  {{native name|fro|Roiaume de Jherusalem}}
• |native_name = {{Script/Hebrew|רֹאשׁ הַמֶּמְשָׁלָה}}
• |native_name = Old Bailey
• |native_name = {{nobold|四国}}
  |native_name_link = Japanese language
  |native_name_lang = ja
• |native_name = {{lang|tr|Anadolu Selçuklu Devleti}}
  {{lang|fa|سلجوقیان روم}}
  Saljūqiyān-i Rūm
• |native_name = {{native name|wa|Lîdje}}
• |native_name = {{nobold|{{lang|zh-Hans-CN|中华人民共和国全国人民代表大会}}}}
• |native_name = {{lang|cy|Ynys Môn}}
• |native_name = {{plainlist|1=<small>

* {{lang|eo|Respubliko de la Insulo de la Rozoj}}

* {{lang|it|Repubblica dell'Isola delle Rose}}</small>}}

A dog's breakfast. So if we change the display logic to render an error message when |native_name= does not hold what seems to be a valid {{native name}} entry, it will kick out almost all the values. In most of them there is an indication of the language. I like the parameter format

| native_name =
| native_name_lang = <!-- 2-4 digit ISO code -->
| native_name_list = <!-- {{native name list |name1= |tag1= |name2= |tag2=...}} -->

using

| label5 = Native name
| data5 = {{format native name |name={{{native_name|}}} |lang={{{native_name_lang|}}} |list={{{native_name_list|}}} }}

I think this is easy for novices to understand, but gives more expert users all they need. And it definitely should be the same across all infoboxes that have native names (or |name_native= as in {{Infobox river}} etc.) But if we add the parameters to all the templates and add the standard validate / format logic, it has to be very forgiving at first, just recording problems in hidden categories. Then after a clean-up phase, the rules can be tightened. Aymatth2 (talk) 22:59, 12 January 2022 (UTC) @Trappist the monk: I see that you are pressing ahead and have removed the |native_name_lang= parameter from {{infobox river}}. This makes the template harder for novice users, and forces changes to many articles. Much easier to retain the parameter and pass it and |native_name= to {{native name}} for formatting. I ask that you revert this change and open it up to a broader discussion at the Village Pump. Aymatth2 (talk) 16:29, 15 January 2022 (UTC)[reply]

Discussion about |native_name= and |native_name_lang= in a handful of templates has been at WikiProject Infoboxes since 27 December 2021. Every infobox that I have changed has, in the edit summary, linked to that discussion. I also added an {{mbox}} template to {{native name}} that links to the WikiProject Infoboxes discussion.

I have never accepted as valid the argument that templates are too complicated for editors to use. If that were really true, we would never have invented them and, you should have, long ago, taken {{coord}} and {{convert}} to task for being too complex for editors; after all, both of them are commonly used as inputs to {{infobox river}} ({{coord}} is even required by the template's documentation).

—Trappist the monk (talk) 17:17, 15 January 2022 (UTC)[reply]

Of course templates are too difficult for some novice editors to use. That is why we have refs added as Joe's website, or Joe's website with <ref> tags around it, or with a bare url. People make changes all the time who would not even know how to find the documentation for a template. I don't agree with removing native_name_language either, at least not without broader discussion and more clear consensus. MB 17:40, 15 January 2022 (UTC)[reply]

I apologize for my noobiness, but is there a way I can help you convert the templates in the wild and sort through errors? – Anon423 (talk) 01:34, 21 January 2022 (UTC)[reply]

The errors are listed in Category:Native name checker template errors. Most of those articles are there because the value in |native_name= is non-English without a clear declaration of the actual language of the 'name' elsewhere in the article. When I trawled that category I looked for an exact match for the 'name' elsewhere in the article. If the 'name' was found in a {{lang}} template or the language of the 'name' was found as plain text adjacent to the 'name', I would use that language as the language for the {{native name}} or {{native name list}} template in the infobox. Yeah, I did the easy bit. So, pick an article and determine what the language(s) of the name(s) is/are and add the appropriate {{native name}} or {{native name list template}}.

No need to apologize for noobiness, we were all new once.

—Trappist the monk (talk) 12:36, 21 January 2022 (UTC)[reply]

You have been a bit silent on the discussion at Wikipedia:Village pump (proposals)#Native name. Are you o.k. with the most recent version? Aymatth2 (talk) 14:02, 21 January 2022 (UTC)[reply]

Have I not already said what I think both here and at Wikipedia talk:WikiProject Infoboxes § native name parameters. Saying more-or-less the same thing at yet another venue seems to me to be a waste of my time.

—Trappist the monk (talk) 15:21, 21 January 2022 (UTC)[reply]

Well, yes, but ... the discussion at Wikipedia:Village pump (proposals) is much more visible than your talk page or Wikipedia_talk:WikiProject_Infoboxes. The village pump discussion has two editors essentially neutral, since their concerns have been addressed, and two strongly in favor of keeping |native_name_lang=, so there is no consensus in favor of removing the parameter. You have pointed out that many editors have no trouble using templates like {{convert}} or {{coord}}, so should have no trouble using {{native name}}. The counter argument is that some editors do have trouble with templates and may simply omit the native name from the infobox if they have difficulty. I have no idea how many is "many" and "some".

But the more important point is that continued support for an optional |native_name_lang= is easy to do without losing any functionality, greatly reduces the conversion effort, and precludes kickback from editors who are used to this parameter in {{infobox settlement}}, {{infobox person}}, etc. It is also important to launch with |errordisp=cat, and just display results as {{{native_name}}} ({{{native_name_language}}}) when there are errors. This is to avoid flooding articles using {{infobox settlement}} etc. with conspicuous red error messages where there were none before. Later, after clean-up, that can be changed to |errordisp=strict.

Implementing stronger validation and consistent formatting of native names will be an important improvement to many articles. It needs to be done in a way that minimizes disruption, or else it may generate angry resistance that blocks progress for years. I don't want to see this grind to a halt. Aymatth2 (talk) 14:10, 22 January 2022 (UTC)[reply]

I have been fixing some of the errors in Category:Native name checker template errors. Often the native language is obvious. In Denmark it is Danish and in Zurich it is German. But sometimes it is unknown and may never be known. Imagine that Captain Smith is exploring the Obongo river and asks a native what a tributary is called. The native answers "Bakanba", which may mean "reed bed" because that is what Smith is pointing to, but perhaps really is the name. It is recorded as Bakamba on the 1853 map. But Smith did not think to ask the native what language he was speaking, and at that time there were several languages spoken along the Obongo... We could just discard the name, but I would prefer to keep it and note that the language is unknown, perhaps as {{native name|und|Bakamba}}, which renders Bakamba (undetermined). Is that the best way?

A different problem is obscure languages. With Bunyip River a source says the name in the Boonwurrung language was Banib, which could be presented as Banib (uncoded) (Boonwurrung language). Not sure if that is the best way. Maybe the documentation should cover these cases. Aymatth2 (talk) 12:24, 25 January 2022 (UTC)[reply]

Presuming good faith suggests that someone had a source for Bakamba so you might write the template as you did, or perhaps, like this:

{{native name|und|Bakamba|paren=omit}} → Bakamba

Similarly, I have written uncoded names:

{{native name|mis|Banib|paren=omit}}  ([[Boonwurrung language]]) → Banib  (Boonwurrung language)

When using {{native name list}} with uncoded languages, this:

{{native name list |tag1=mis|name1=Banib|paren1=omit|postfix1=  ([[Boonwurrung language]])}} → Banib  (Boonwurrung language)

—Trappist the monk (talk) 14:22, 25 January 2022 (UTC)[reply]

Sometimes a name is given in a non-Latin script, followed by a transcription into Latin script. I think this should maybe be coded as {{native name|kk|Тәуелсіздік алаңы}} [Täuelsızdık alaŋy], which renders as Тәуелсіздік алаңы (Kazakh) [Täuelsızdık alaŋy]. Not sure Aymatth2 (talk) 13:49, 25 January 2022 (UTC)[reply]

When I encountered this sort of list I used {{native name list}}:

{{native name list |tag1=kk|name1=Тәуелсіздік алаңы |tag2=kk-Latn|name2=Täuelsızdık alaŋy}} →

• Тәуелсіздік алаңы (Kazakh)
• Täuelsızdık alaŋy (Kazakh)

Non-English text, whether in native script or romanized, should be wrapped in proper html markup so that browsers and screen readers render/speak the text correctly.

—Trappist the monk (talk) 14:22, 25 January 2022 (UTC)[reply]

Thanks. That all works for me. Aymatth2 (talk) 15:04, 25 January 2022 (UTC)[reply]

Could you please point me to the discussion where consensus to deprecate this was reached? Hog Farm _Talk 18:18, 26 January 2022 (UTC)[reply]

I don't think this edit was helpful. The autovalue was was harmless, and by removing it you are forcing people that pre-emptively add archive links for websites that are NOT dead an extra thing to do. For Cite web, it is a good thing for VE to add |url=live as autovalue. --- C&C (Coffeeandcrumbs) 21:00, 26 January 2022 (UTC)[reply]

I would guess that 99.99% of links added using VE are live. --- C&C (Coffeeandcrumbs) 21:01, 26 January 2022 (UTC)[reply]

|url-status=live when |archive-url= is missing or empty is just clutter. Without |archive-url= (with an assigned value), |url-status= conveys no meaning to the reader because readers can't see it; conveys no meaning to an editor because the value in |url= might not actually be live – may have been when the citation was first added but ... linkrot; and conveys no meaning to the cs1|2 template because there is nothing for the template to do with that parameter until |archive-url= has a value. It just takes up space.

I would guess that 99.99% of links added using VE are live. No doubt those same urls are also free-to-read. Since there is no point in highlighting the norm, |url-access=free is not a supported option. It really is the same for |url-status= without |archive-url=. And, since ve isn't smart enough to add |url-status=live only when adding a preemptive |archive-url=, it is better to avoid automatic inclusion and the attendant clutter.

—Trappist the monk (talk) 01:00, 27 January 2022 (UTC)[reply]

Then the better option is to remove the "suggested" parameter from all archive-url, archive-date, and url-status and leave the "autovalue" as "live" on url-status. That way when the user calls it up it autofills to live as a starting point. I use VE a lot and having the autovalue is a huge time saver and makes sure I don't inadventently direct to an archive unnecessarily. The way you have it now, we are going to end up with thousands of source links that point to an archive first instead of the original link which is still alive. You have to think about how people actually use VE. I get the distinct feeling that you don't often use VE and are not grasping what I getting at. --- C&C (Coffeeandcrumbs) 01:58, 27 January 2022 (UTC)[reply]

Looking at his contributions, it appears that he's never used the visual editor. WhatamIdoing (talk) 05:06, 27 January 2022 (UTC)[reply]

Yep, I don't use ve. If there is a better way to achieve the same thing: no addition of empty or meaningless parameters, I'm ok with that. For the next month or two, Category:CS1 maint: url-status will continue to collect its initial set of articles (the collection process began on 22 January 2022 and can take months to stabilize). After that, the category should not continue to accumulate new articles. If your fix to the template data can assure that, then go ahead.

—Trappist the monk (talk) 16:08, 27 January 2022 (UTC)[reply]

Hi! I see Module:Citation/CS1 etc. was updated on January 22. Yay! I plan to do the same updates on dawiki. But I noticed that there also were some updates on January 23 and 24. So I have 2 questions:

1. Do you expect more updates? (I know it can be hard to guarantee so if you say no but change the module anyway there will be no hard feelings)
2. Should the text in the sandboxes be changed from "History of changes since last sync: 2022-01-22" to "...2022-01-24"? (It does not bother me so only if you think its a good idea)

As I understand the RfC from now on smaller changes can be made without an RfC. It is only if you want to change something major or something you expect will make someone unhappy. So perhaps in future we will se updates more often.

I'm so happy you helped me update the module. It should be much easier this time. --MGA73 (talk) 16:39, 24 January 2022 (UTC)[reply]

Answers:

1. Yes. I buggered up |language= handling so I'm in the middle of rewriting that.
2. I thought about that last night and then got sidetracked...

Attempting to predict what will make someone unhappy is a waste of time and effort.

—Trappist the monk (talk) 18:25, 24 January 2022 (UTC)[reply]

I have now updated the versions in the Danish sandboxes and I have tried to make the changes so it is easy to see what I changed. I also made a note at the top of each (sub)module of that changes I made. That should make it easier for us to implement future changes at dawiki.

If other wikis also want to copy the English module to their wiki they can see what we changed on dawiki and how we did it.

It would be easier if all the date formats was implemented in the module and could be turned on or off with true/false etc. But that would require a lot of your time (and fill English module with extra code) so I know it is not likely to happen soon. But if you ever have some spare time you are welcome to check the changes on dawiki and perhaps you find something that would be easy to fix.

Sometimes just a short text like "Translate the names below" when ever there is something to translate. Sometimes ['local'] means that something should be translated and somethimes it should not. So for example the line in ~configuration

• {['en'] = {'page not found', true}, ['local'] = nil},

Should be translated but how?

• {['en'] = {'page not found', nil}, ['da'] = {'siden ikke fundet', true}},
• {['en'] = {'page not found', false}, ['local'] = 'siden ikke fundet'},

I have not translated those lines on dawiki yet because I do not know if it is relevant on dawiki. But I could imagine that an example could be helpful.

Thanks a lot for all your help! --MGA73 (talk) 15:47, 28 January 2022 (UTC)[reply]