User talk:Trappist the monk/Archive 22

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


For later[edit]

Just posting this here, for consideration later, because I know you're busy:

The red warning messages about deprecated parameters seem to bother people. It might not be a bad idea to have a sort of phased deprecation, in which such warnings are first only visible to people who are logged in (or even extended-confirmed), and only later to everyone. This could reduce the stress for editors and help them understand that not everything needs to be fixed instantly. WhatamIdoing (talk) 05:09, 27 January 2022 (UTC)[reply]

(talk page stalker) This has become a no-win situation. Deprecated parameters are often removed quite quickly by diligent gnomes. If they are removed but there is no warning message visible to some editors, those editors will complain that they were removed for no reason. If the parameters are then changed to unsupported at the next module update, editors will complain that they never got a chance to see a deprecation message. On the other hand, if we deprecate a parameter and start removing it without showing error messages to anyone, the torches and pitchforks will be brought out because there are no warning messages. On the gripping hand, if we visibly deprecate a parameter that is used in hundreds of thousands of articles, giving people plenty of warning before any action is taken, the torches and pitchforks are trotted out yet again, with editors complaining that articles are full of a sea of red error messages. Different people at the RFC complained about parameters being removed before error messages were shown at the exact same time that other people were complaining that showing messages resulted in too much red. If you know of a fourth way, by all means share it. – Jonesey95 (talk) 05:28, 27 January 2022 (UTC)[reply]
I think the "Deprecated parameters are often removed quite quickly by diligent gnomes" comment says it all. Gnomes will remove the lay source parameter. As in delete. If they do follow the help link it says "if the source named by these parameters is important to the Wikipedia article, create a cs1|2 template for that source with all of the appropriate bibliographic information". I don't understand why the first part is necessary. Someone clearly thought the source was important as they added it. And "cs1|2 template" is computer speak and technically wrong as nobody is creating a template. They might be using one, but that's a different thing. I think you should consider turning off this warning ASAP until a solution has been agreed upon. It would also de-escalate the conversation at multiple locations.
In future, I suggest you separate RFCs for features users want, from RFCs for making changes you (as template maintainer, say) want. Separate the non-contentious "we've added these shiny new buttons" from the contentious "we are (eventually) taking away these buttons". Because I saw that RFC had people wanting features and nobody really considering the effect of the deprecations. If you deprecate a parameter used in thousands of articles, then some effort needs to be made to contact/publicise that change, and your RFC was way way too obscure, with a hundred proposed changes in a hidden box. -- Colin°Talk 11:06, 28 January 2022 (UTC)[reply]
What he ↑ said.
—Trappist the monk (talk) 15:58, 27 January 2022 (UTC)[reply]
We currently have a two-stage process:
  • Parameter is deprecated and everyone, including logged-out readers, see a sea of red warnings.
  • Parameter is removed.
I am suggesting that you consider a three-stage process:
  • Parameter is deprecated but logged-out readers and IP editors can't see that. Logged-in editors still see a sea of red warnings.
  • Parameter is deprecated and everyone, including logged-out readers see the sea of red (only it's smaller now, because there's been time to clean it up).
  • Parameter is removed.
You will still get complaints, but editors could be reassured that the "broken" citation problem won't be visible to readers, which might reduce the stress for some. WhatamIdoing (talk) 23:40, 27 January 2022 (UTC)[reply]
These are the categories that have more than 1,000 articles that show error messages visible to everyone:
These two are hidden because drama; errors associated with these categories are visible only to those (comparatively) few editors who have set their css according to Help:CS1 errors § Controlling error message display:
I'm skeptical that cs1|2 bleeding new error messages when there are more than 100k articles already showing error message is the real problem. The problem is 'new' and I'm coming to believe that en.wiki editors hate, hate, hate new.
css is not my strength, but I don't think that there is css that can distinguish between a logged-in reader and a not-logged-in reader. Sure, it can be done with .js, but that would require logged-in readers to enable that .js or, MediaWiki would have to make it available by default to all logged-in readers. Modules cannot know if a reader is logged-in or not.
For this particular deprecation I marked the |lay-*= parameters in the sandbox deprecated on 3 October 2021. Also, on that day, I tweaked the deprecated parameters table and primary parameter documentation. I did this because at some past drama, editors suggested that at the very least, the documentation should show that parameters are deprecated before they actually are deprecated. This was the beginning of the 'pre-deprecation' phase, if you will.
The shall-we-update-cs1|2 rfc opened 28 November 2021. The rfc included notice that the |lay-*= parameters would be deprecated. That rfc closed 15 January 2022.
There was some discussion commencing 17 January 2022, some tweaks made to Module:Citation/CS1/Configuration/sandbox‎ and to Module:Citation/CS1/Whitelist/sandbox on 20 January 2022.
On 22 January 2022‎ I updated the cs1|2 module suite from the sandboxen. This marks the end of the |lay-*= 'pre-deprecation' phase and the beginning of the deprecated phase. Total time in 'pre-deprecation': 3 months and 19 days
—Trappist the monk (talk) 00:45, 28 January 2022 (UTC)[reply]
WhatamIdoing: Should we also hide {{citation needed}} and {{copy edit}} and {{unreferenced section}} etc. etc. from readers? The messages let everyone, including readers, know that something may not be quite right in the vicinity of the message, and that they should proceed with caution. That is a valuable service provided by messages. Why would we deny that information to readers? – Jonesey95 (talk) 00:55, 28 January 2022 (UTC)[reply]
I don't think that displaying a note that amounts to "eventually, we plan to change something about the formatting of this citation" is actually a valuable service that provides relevant information to readers. I especially don't think that it is an urgent message that they need to see at the earliest possible moment.
Maintenance tags do not exist for the purpose of warning the readers. Even if they were, I've no reason to believe these maintenance banners effectively communicate to non-editing readers that something may not be quite right in the vicinity of the message. I'd like to believe that readers are not so stupid that they can't see for themselves whether or not there are any little blue clicky numbers in a section, whether that tag is there or not. WhatamIdoing (talk) 01:12, 30 January 2022 (UTC)[reply]

South African Discord[edit]

Interested in joining the South African Wikipedia Discord?



If you are interested in a joining, please visit Wikipedia:Meetup/South Africa/Discord for more Infomation or click the button below

Everyone in Southern Africa is Welcome, for any technical issues or questions about Discord, Please ask User:TapticInfo on his talk page

Join Server

Hi, I would like to invite you to the Wikimedia South Africa Discord Server.

Discord allows instant text, voice and video communication and is used for all the South Africa Wikipedians monthly meetups.

See Wikipedia:Meetup/South Africa, the next one is on 26 February 2022 at 10:00am SAST Wikipedia:Meetup/South_Africa/South_Africa_15

TapticInfo (talk) 10:06, 31 January 2022 (UTC)[reply]

شیراز[edit]

شیراز 5.119.104.185 (talk) 11:12, 31 January 2022 (UTC)[reply]

Module:Lang[edit]

Hey, Trappist! It's been a while! I was just about thinking about checking for updates for CS1 and judging by the messages I already found here looks like more or less we've all had the same thought. Last time I checked a RFC was on-going for that. However now I wanted to ask for something else. I help around at LaWiki and a user there noticed that some templates were missing while translating a certain article. The said templates were related to the aforementioned module and that module was dependent on some other modules and it kinda looked like it was related with Module:Language (I now think it isn't) which was dependent on some other modules and of course everything was missing from LaWiki and... Long story short I ended up importing 87 modules and templates manually in total (which, were only the tip of the iceberg as I noticed when I saw the category for its templates). Now, funny enough, even though I've read the documentation some times, I still don't know exactly what the module (and its templates) serve for in plain words. I know it assists in better rendering of specific scripts or at least better understanding of those from the machine side but that's as far as I can go. I wanted to ask for help, checked its history and found your name and here we are. So, can you explain me more about this? - Klein Muçi (talk) 18:35, 24 January 2022 (UTC)[reply]

I know it assists in better rendering of specific scripts or at least better understanding of those from the machine side. That is the most important purpose. If you look at the html of any la.wiki page you will find something like this:
<html class="client-nojs" lang="la" dir="ltr">
The lang="la" attribute tells browsers and screen readers that the base language of html pages at la.wiki is Latin (dir="ltr" indicates that text is written/read left to right). So that browsers and screen readers render and pronounce non-Latin text correctly, the browser/screen reader needs to know that the non-Latin text is not the same as the page's base language (set in <html>) and they need to know the non-Latin language.
{{lang}} wraps the non-Latin text with proper html and verifies that the language tag supplied is composed of known subtags. Subtags are extracted from the IANA language-subtag-registry file which is a plain-text file that is the definitive list of valid subtags known to browsers and screen readers.
So, {{lang|ja|黒澤 明}} (Akira Kurosawa's name) creates this html:
<span title="Japanese-language text"><span lang="ja">黒澤 明</span></span> → 黒澤 明
Here is Kurosawa's name as a romanization using slightly different language tags:
{{lang|ja|Kurosawa Akira}} → <span title="Japanese-language text"><i lang="ja">Kurosawa Akira</i></span> → Kurosawa Akira
{{lang|ja-Latn|Kurosawa Akira}} → <span title="Japanese-language text"><i lang="ja-Latn">Kurosawa Akira</i></span> → Kurosawa Akira
the rendering of those two should not look the same (different fonts; the latter is the correct font)
Most of the templates associated with Module:Lang are used as a standardized way to say "this is the word in this language". So, our article Gymnasium parenthetically uses:
{{lang-sq|Gjimnaz}} → Albanian: Gjimnaz
so that readers understand that Gjimnaz is not an English word (also prevents spell-checker-bots from creating nonsense). At en.wiki, non-English words using Latn script are to be rendered in italic font so Module:lang does that automatically. Text from languages that are written/read right-to-left (Arabic, Hebrew, etc) are automatically marked with the dir="rtl" attribute:
{{lang|he|יָם הַמֶּלַח}} → <span title="Hebrew-language text"><span lang="he" dir="rtl">יָם הַמֶּלַח</span></span> → יָם הַמֶּלַח
Is that enough? Did I answer what you were asking?
—Trappist the monk (talk) 19:50, 24 January 2022 (UTC)[reply]
Well... You did but... If I ping you at the LaWiki's VP can you also explain it to the community there? This of course begs the question why can't I do that instead of you but the problem is that I've already done that and they said me basically that that just isn't true. :P And they gave me an example in the Avestan language where the module basically failed at its job, at least according to some of LaWiki's most active users. This is what made me not trust myself and come here. Can I ping you there? - Klein Muçi (talk) 21:06, 24 January 2022 (UTC)[reply]
You may.
—Trappist the monk (talk) 21:37, 24 January 2022 (UTC)[reply]
The reply link wasn't able to find your name given that you don't have a user page I believe but I think I did it correctly manually. You should have gotten a notification. - Klein Muçi (talk) 23:07, 24 January 2022 (UTC)[reply]
In a continuation of this topic, can you help me by showing where are the red links are coming from in cases like here? I thought they were coming from Lang/data but most likely I'm wrong. - Klein Muçi (talk) 00:56, 30 January 2022 (UTC)[reply]
The name 'Ukrainian' comes from Module:Language/data/iana languages via Module:Lang/data. That is a list of some 8,000 active language tag/name pairs plus 200 deprecated tag/name pairs. Until the discussion at la.wiki, I hadn't given much thought to how other wikis might want to use Module:Lang. The data that it relies on is the international standard and I don't know if there is a translation of that data. I know that ISO 639-2 has an official list of language names in both English and French but that is a small part of the whole. But, MediaWiki has a language list derived from (I think) Unicode CLDR (same list as used by cs1|2) so it might make sense to tweak Module:Lang/data to allow use of the MediaWiki data so that at smaller wikis that don't need the whole thing can have something a little less intimidating. No guarantee that language names are available for all of the language tags that MediaWiki supports. So, instead of returning the English exonym, 'Ukrainian', Module:Lang might return the exonym in the local language. Alas, for la.wiki, {{mw lang|uk|la}} → Ucrainica so no help there but, {{mw lang|uk|sq}} → ukrainisht so this solution (if workable) might be acceptable at sq.wiki.
—Trappist the monk (talk) 01:43, 30 January 2022 (UTC)[reply]
Funny enough (x2), that is one module I don't remember ever dealing with in SqWiki and it's one of the few cases that I'm "supporting a product" at LaWiki which I'm not that familiar in using in my homewiki. Dealing with technical changes at LaWiki is most of the time really stressful considering that most of its active users and admins aren't really interested in the backend and if a template/module doesn't produce a noticeable result in enriching the article's content (the actual content, not metaphorically), they basically say it might as well be removed. (I've had problems convincing them in adopting the CS1 module in the past for the same reason.) If you followed the discussion there from the beginning, you might have seen that I got caught up with the lang templates rather accidentally and as more time passes more and more this whole ordeal is starting to feel like the worse possible case: Templates that serve mostly for the machine side, which I don't know as much as I'd like (I haven't dealt with them at my homewiki) and names that most likely are stuck in English and can't be modified easily manually. Of course this all gets worse when you consider we yet again face the "taxo-templates problem": There are countless of lang templates which I can't hope to import manually there. I'm very inclined to ask you if something can be done about that factor but I'm more sure than not that no solutions exist (given that we couldn't solve even the taxonomy templates situation). It feels weird having to find l11n ways for LaWiki for something rather random (and being suddenly classified as a proponent of it) but I started this now so I believe following with the proposed approach is the best step that we can take. - Klein Muçi (talk) 02:22, 30 January 2022 (UTC)[reply]
PS: Lately I've started dealing with Mediawiki bugs. Do you have any idea where Mediawiki might store these language names? I was wondering if maybe I could give some Albanian exonyms for the names that might be lacking. Ideally the same thing can be done with Latin exonyms but it will take the argumentative power of the whole Roman Senate to make the community participate in a multi-part ordeal like that. - Klein Muçi (talk) 02:27, 30 January 2022 (UTC)[reply]
Found the list (of lists): https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/cldr/+/dacffff2adc7636f5f98264389cf0be01c5a5cb1/CldrNames/
It is indeed derived from Unicode CLDR. Unfortunately Latin doesn't exist there (correct me if I'm wrong) so the whole thing wouldn't benefit that community at all.
I have a question though: In the past we've said that the Mediawiki language names are dynamic. Now reading about CLDR I see that lists get updates at most twice a year. I wonder what makes that list we've talked about be more dynamic than that. - Klein Muçi (talk) 03:18, 30 January 2022 (UTC)[reply]
So, do you think I should give the bad news to LaWiki now that they have to delete the lang module and all its associated templates? - Klein Muçi (talk) 23:12, 31 January 2022 (UTC)[reply]
Why do they have to delete the lang module and all its associated templates?
—Trappist the monk (talk) 23:49, 31 January 2022 (UTC)[reply]
Because if they can't be Latin according to the high council they deserve to be purged. - Klein Muçi (talk) 23:51, 31 January 2022 (UTC)[reply]
Then the high council can do the purge themselves. Before they do that though, they really ought to consider overriding at least the ISO 639-1 tags by clearing the override table in Module:Lang/data and adding the Latin translations for the ISO-639-1 languages there. They can add Latin translations of ISO 639-2, -3, -5 languages and any private-use tags that they create as they need them. Overriding the IANA data is what Module:Lang/data is there to do.
But, of course, high councils always know best...
—Trappist the monk (talk) 00:07, 1 February 2022 (UTC)[reply]
I think that's already done but it still didn't fix what started this conversation. - Klein Muçi (talk) 00:28, 1 February 2022 (UTC)[reply]
Nope. Someone tweaked a few of the overrides that we use at en.wiki. Replace the entire contents of the override table with just the two-letter tag/name pairs from Module:Language/data/iana languages then translate those names. ISO 639-1 tag/name pairs covers a lot of, if not most, language tagging needs.
—Trappist the monk (talk) 00:48, 1 February 2022 (UTC)[reply]
Oh... Well, that doesn't look like the most ever elegant hack but oh well... Thank you! - Klein Muçi (talk) 00:54, 1 February 2022 (UTC)[reply]
Is this edit correct? Do I go on with the translations now? - Klein Muçi (talk) 02:06, 1 February 2022 (UTC)[reply]
No. Just the two-letter tag/name pairs. Also, remove the braces and only one language name per tag so:
["bn"] = {"Bengali", "Bangla"}, → ["bn"] = "Bengali",
—Trappist the monk (talk) 02:50, 1 February 2022 (UTC)[reply]
Still not right: only one language name per tag.
—Trappist the monk (talk) 12:55, 1 February 2022 (UTC)[reply]
Tell me I finally got it right this time or the High Council will purge me instead. - Klein Muçi (talk) 13:05, 1 February 2022 (UTC)[reply]
You did.
—Trappist the monk (talk) 13:39, 1 February 2022 (UTC)[reply]
I thought that maybe Mediawiki was to blame for not importing the CLDR entries for LaWiki but, apparently, they don't exist at all: https://github.com/unicode-org/cldr/tree/main/common/main (search for "la.xml")
Do you have enough information about the whole CLDR thing as to know why they don't exist? - Klein Muçi (talk) 16:18, 1 February 2022 (UTC)[reply]
No. CLDR doesn't support Klingon either so perhaps it's because there aren't enough native speakers?
—Trappist the monk (talk) 16:37, 1 February 2022 (UTC)[reply]
And, assuming Klingons wanted to be able to volunteer in providing support for their language to CLDR, what would be the needed steps to be taken? I read about a biannual survey but I don't believe that's the right way to start support for a new language. - Klein Muçi (talk) 16:48, 1 February 2022 (UTC)[reply]

Module:Cs1 documentation support[edit]

Given that I'm updating everything related to CS1, I also dealt with this module. Even though not important as the CS1 suite, I'd like to localize it correctly, considering also that it doesn't contain many strings. Can you give me some context about them?

  • unknown error_conditions key
  • is not a valid parameter
  • Error: cs1|2 template name required
  • Error: can't find TemplateData
  • internal error: unexpected keyword in templates_t
  • TemplateData has errors
  • preprint and limited parameter sets
  • and 'unique and standard parameter sets' or 'standard parameter set' - Klein Muçi (talk) 00:01, 6 February 2022 (UTC)[reply]
answers:
  • unknown error_conditions key – this one exists in two places and basically means the same thing.
    • line 902: help_text_cats(): this function is used at the bottom of every error message help-text in Help:CS1 errors to prevent self-referenced category links when the help text is transcluded into a category page. Because the category associated with an error message is known by Module:Citation/CS1/Configuration, cs1 documentation support fetches the category name from ~/Configuration using the error_conditions key. So, for example, the key err_generic_name tells cs1 documentation support to fetch the category name for generic name errors from error_conditions.err_generic_name. This unknown error_conditions key is emitted when the key in the {{#invoke:}} for help_text_cats() is not found in the error_conditions table. You are not using the help_text_cats() function at sq:Ndihmë:Gabimet CS1.
    • line 948: help_text_error_messages(): : this function is used at the top of every error message help-text in Help:CS1 errors to reinforce the reason why an editor has landed there when clicking the help link in a cs1|2 error message. Like the category name, the error messages are known to ~/Configuration so cs1 documentation support fetches the error message from the same table, using the same key. This message is emitted when the key in the {{#invoke:}} for help_text_error_messages() is not found in the error_conditions table.
  • is not a valid parameter – line 1105: param_error_msg() which is called (3×) from template_data_validate(). TemplateData is often filled with junk but the editors who add that junk don't know that it is junk. The template_data_validate() looks at the content of the Template data on the page where it is {{#invoke:}}ed and emits this error message when it finds a parameter name that is wholly wrong or is inappropriate for that template so editors driving that abomination that is ve should not be attempting to add that parameter when adding a the offending template to an article. See, for example, Template:Cite ssrn § TemplateData.
  • is not a valid alias of – line 1115: alias_error_msg() which is called (5×) from template_data_validate(). More-or-less the same as 'is not a valid parameter' except applies to inappropriate or wholly wrong alias assignments in TemplateData. See the same example.
  • Error: cs1|2 template name required – this one exists twice, both in template_data_validate() at line 1164 and line 1169. In order to validate the parameters and aliases in TemplateData, cs1 documentation support must know which template the TemplateData belong to and that the template is a cs1|2 template (this is poorly validated). The {{#invoke:}} requires a template name as the first (only) positional parameter usually provided by the {{ROOTPAGENAME}} magic word.
  • Error: can't find TemplateData – line 1184: template_data_validate(): before TemplateData can be validated, template_data_validate() must be able to find the JSON string that is the TemplateData in the cs1|2 template's doc page. This error message when the TemplateData don't exist.
  • internal error: unexpected keyword in templates_t – line 1223: indicates that the programmer (me) did something wrong when configuring the data in templates_t (line 970)
  • TemplateData has errors – line 1252: template_data_validate(): last bit of the error message header before the list of error messages
  • preprint and limited parameter sets – line 1251: template_data_validate(): Module:Citation/CS1/Whitelist is divided into tables of parameter names: basic_arguments, numbered_arguments, preprint_arguments, limited_basic_arguments, limited_numbered_arguments, and unique_arguments. Preprint templates {{cite arxiv}} etc, use preprint_arguments, limited_basic_arguments, limited_numbered_arguments so for those templates, that information is included in the error message header.
  • and 'unique and standard parameter sets' or 'standard parameter set' – both of these similar to the preprint message portion of the header.
—Trappist the monk (talk) 01:48, 6 February 2022 (UTC)[reply]
Thank you very much for the detailed information! I'll have to press on on the last 2 points though. What exactly means "preprint", "limited", "unique" and "standard" parameters in the Whitelist context? - Klein Muçi (talk) 02:01, 6 February 2022 (UTC)[reply]
Preprint refers to the preprint templates which cite sources that have not yet been formally published. Those templates are: {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}}. These templates are only allowed to use the parameters listed in their specific preprint_arguments table and the parameters listed in limited_basic_arguments and limited_numbered_arguments tables.
Unique refers to a subset of the cs1|2 templates that support parameters that only those templates may use. The templates are: {{cite av media}}, {{cite conference}}, {{cite episode}}, {{cite mailinglist}}, {{cite map}}, {{cite newsgroup}}, {{cite report}}, {{cite serial}}, {{cite speech}}, and {{cite thesis}}. These templates are allowed all of the parameters from the basic_arguments and numbered_arguments tables (the standard parameters) and the individual unique parameters from their subtable in the unique_arguments table.
All other templates use the standard parameters.
—Trappist the monk (talk) 14:40, 6 February 2022 (UTC)[reply]
Oh, so it is a Wikipedia naming convention. I understand now. Thanks a lot again for the details! :) - Klein Muçi (talk) 00:20, 7 February 2022 (UTC)[reply]
I don't know what you mean by Wikipedia naming convention, but whatever you mean, 'Wikipedia' has nothing at all to do with what I described above.
—Trappist the monk (talk) 01:20, 7 February 2022 (UTC)[reply]
I mean that names like "preprint arguments", "limited arguments", "standard arguments", etc. are not really universal names describing different types of arguments, like, for example, "boolean arguments". They're just the names that we have given to the arguments that the aforementioned templates here on Wikipedia use. - Klein Muçi (talk) 01:31, 7 February 2022 (UTC)[reply]

And so it begins...[edit]

I've finally gathered the courage to start the CS1 update for SqWiki. I've yet to deal with the configuration page which is where the difficult part is but still I have questions:

First of all, out of curiosity, is there a possibility you can TL;DR the main changes in 2 lines? The reason I ask that is because I see way more changes than usual, maybe because I've spent a lot of time without updating. The CSS page was also changed which rarely happens. And some parts of the main page were sent in other pages. I also saw that the technical name for maint and error cats were changed, which again seemed a bit unusual to me.

Secondly, a tiny, tiny, thing but I've noticed that in Module:Citation/CS1/COinS there is an error message in regard to math errors that needs to be translated. Could there be a possibility to send that message elsewhere? The question sounds silly but seen from a naive point of localization and if we are to ever have that global bot to auto-update the module globally, we need as many pages that don't need local changes. So far, if we don't count that small detail, everything can be blindly copy-pasted (generally speaking) beside the main and the config. page.

And finally, speaking of the main page... I have put some notes for myself that I need to do 3 changes there:

  1. Put the code for the sources missing language parameter error (which is extra from EnWiki and which I believe I'll have to modify this time but I've yet to work with the config page.
  2. Replace /sandbox with /Livadhi - self-explanatory
  3. Uncomment 3 lines for date localization reasons - This appears to have changed to make localization easier and... I don't have to do that anymore? If that would be the case, returning to the point above about the global bot, I would say I feel bad that we still have those extra 2 details in that page. You understand my point I believe. - Klein Muçi (talk) 12:44, 1 February 2022 (UTC)[reply]
There is no tl;dr. Because of politics here, it was a long time between updates. There is a list of the changes at the rfc that permitted the most recent update; Wikipedia:Village pump (proposals)/Archive 186 § list of prospective changes to the cs1/2 module suite
I keep hoping that someday we'll be able to remove the MATH RENDER ERROR but as time goes by, that seems more and more like a forlorn hope. I don't see any need for that to be translated because only those who consume cs1|2 citations via the metadata will ever see it.
The other questions:
  1. You will still have to do this if you want to keep that functionality.
  2. still have to do that unless you are content with using ~/sandbox instead of ~/Livadhi – you don't use the sandboxen anyway so why bother?
  3. to auto-translate English month names to the local language set date_name_auto_xlate_enable = true; in ~/Configuration
So long as individual wikis have their own peculiar requirements, a bot-facilitated update is, to my mind, a pipedream.
Be sure to add notes to Module:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki when you see something that would aid other wikis when they import or update.
—Trappist the monk (talk) 14:06, 1 February 2022 (UTC)[reply]
Ah, so we've transported that functionality in ~/Configuration. That's actually very good news. Can't we do the same with MATH RENDER ERROR? Can't we do the same with our and everyone's else peculiar functionalities? Transport everything in a ~/Configuration subsection dedicated to "peculiar local functionalities"? That would finally mean that we only need to deal with the config. page, making the bot dream seem closer to reality.
As for sandboxes, we do use them lately. Specifically for the config page as usually updating that page can take more than 1 day (category changes and Wikidata links take a lot of time). The wrong sandbox links would also remove the links to the main table and removing sandboxes altogether feels like a regression: Every CS1 page is protected so sandboxes give some democracy back. Removing that democracy when we already have it and it's working nice, even though it has yet to be utilized even once beside the config. page and the main one sporadically, looks like not the right thing to do. As for using them in English, well, that would break the current technical infrastructure in regard to sandboxes (Module:Documentation deals with that, if I'm not wrong) that we have, unless we chose to make this case an exception.
My hope is that it will be easier to add information to that page once the table we're discussing it's set up and we can have a better understandment of what the current global situation is. My suspicion is that most of the projects don't really have "peculiar requirements", instead they have crude hacks that they may have been stuck with just to get the job done because of the lack of information or the lack of sight in the bigger scheme of things. If that's proven to be true, most of those "peculiar requirements" can be squashed out gradually with more global discussion. And lastly, my dream is that this whole thing gets matured enough in here to be transported in Meta and eventually, hopefully, be transported as a native feature in Mediawiki (or at least an extension). Of course, everything can be just a pipe dream. - Klein Muçi (talk) 16:15, 1 February 2022 (UTC)[reply]
I've started dealing with ~/Configuration. Soon I'll have to work with the categories. Any raw list of category changes that have been made? It doesn't have to be 100% correct. I just want to have a general idea if we have a lot of changes in them or no. - Klein Muçi (talk) 03:31, 2 February 2022 (UTC)[reply]
Apparently there weren't a lot of category changes.
Can you tell me more about these 4 lines:
use_identifier_redirects = true, -- when true use redirect name for identifier label links; always true at en.wiki
local_lang_cat_enable = true; -- when true categorizes pages where |language=<local wiki's language>; always false at en.wiki
date_name_auto_xlate_enable = true; -- when true translates English month-names to the local-wiki's language month names; always false at en.wiki
date_digit_auto_xlate_enable = true; -- when true translates Western date digit to the local-wiki's language digits (date_names['local_digits']); always false at en.wiki
I understand the second one because I've been the one to ask for it. I also understand the third one might be the old change that we needed to do in regard to dates but what is the fourth one? Are there wikis who use different digits? And I don't understand much the first one. In SqWiki I've interlinked almost all redirects to EnWiki because we don't have articles for them yet. How does the first line affect that and what should I do? - Klein Muçi (talk) 12:43, 2 February 2022 (UTC)[reply]
Other questions:
  1. Unsurprisingly perhaps but the language missing error for us is, well, missing. That always happens during updates as I mess up details. Can you take a look at our module's main page and see what's wrong?
  2. [Naive] Repeating what I suggested above: Can that part be transported to the ~/Configuration page? Maybe in a section named something like: Local extra features?
  3. Can the sandbox → Livadhi feature be automatic by gathering data from Module:Documentation/config? Or maybe somewhere else? The idea is to autodetect what word the local wiki uses for sandboxes, same as the documentation module does. Or can we send that to the ~/Configuration page where users are asked to localize it among other terms?
  4. [Important] Can we create a tool (or enhance the existing one) that autochecks category synchronization backwards compatibility with the module? Currently we have a tool to check how the code for category creation corresponds to the categories themselves, if they exist or not. This helps a lot with new category creation and detecting localization mistakes. It would be nice to have a tool that checks the existing categories and how they correspond to the current code in the module. This would help a lot with the old categories deletion and detecting localization mistakes.
  5. Now that I'm currently doing the update, I feel that your overall idea here may be useful to have as a tool even without considering its ability to tell us how updated or not is a certain page. It would be nice to have a tool that checks the difference in bytes between the local page and its corresponding EnWiki page and if the discrepancy is too big, it notifies you about it. That would mean that you've most certainly done errors in your update. - Klein Muçi (talk) 13:23, 2 February 2022 (UTC)[reply]
To know category changes is why we created sq:Moduli:Citation/CS1/doc/Category list. If you import to your sandboxen, the Category list will tell you what categories are new and what categories are no longer needed. To your point 4, the category lister can only know about names that it can get from a module. There is no search capability built into Scribuntu so the category lister cannot search for categories that may once have been used by the cs1|2 module suite but now are not. You might spoof the category lister by overwriting the current ~/Configuration/Livadhi with older versions of the live ~/Configuration and then use the category lister to tell you the difference.
At en.wiki, |isbn= is used in 1.4-ish million articles. Each use of |isbn= used to create a direct link to International Standard Book Number. Doing that made the Special:WhatLinksHere/International Standard Book Number listing meaningless. To get 'round that we created a redirect ISBN (identifier). Readers still see a link to International Standard Book Number but now, WhatLinksHere has meaning because it is not swamped with a million extraneous links from cs1|2 templates (see this link count tool).
Arabic, Hindi, no doubt others.
Compare the if-then-else for if utilities.is_set (Language) then in the live module to the same in previous module.
I don't know what you mean by your [Naive] question.
I'll think about this. I had thought that it might be possible to extract the last '/<something>' from the title of the invoked module. If that '/<something>' is not 'CS1' then use it as the '/sandbox' indicator. But, some projects rename their modules to something that does not include '/CS1' so that won't work.
—Trappist the monk (talk) 15:02, 2 February 2022 (UTC)[reply]
No, I think you're overcomplicating the suggested category tool. I mean something like this: "You" (the tool) go to w:sq:Kategoria:CS1 (main CS1 category), fully expand the category tree in all its branches, compare the names there vs the ones in the module's/sandbox'es code, show what's there that currently is not in the module's/sandbox'es code. That's it. Does that make sense? I think the comparison should be easy to implement because it would be just what the current category lister does in reverse, more or less, no?
So, should I have the redirect option set to true or false? And what about the fact that I've used interwiki links in the id handlers? Does that make any difference?
My naive question means "transporting"
table.insert( z.message_tail, { utilities.set_message( 'err_language_missing', {}, true )}); -- emit an error message and add to category
to the config page somehow so that I wouldn't need to make local changes to anywhere else beside the ~/Configuration page. Doing whatever it takes to achieve that aim. (Maybe that can be a native feature of the module with a boolean true/false switch? Or too extreme for most wikis?) This also correlates with the sandbox autodetection feature obviously.
I'll try fixing that myself checking the old version. I'll report back if I fail to do so. - Klein Muçi (talk) 15:42, 2 February 2022 (UTC)[reply]
The category lister creates lists of category links that ~/Configuration expects and that ~/Configuration/sandbox expects, compares those lists one with the other, and renders the result of the comparison. I does nothing with the actual categories themselves. It would be a new tool to do what you want.
Didn't we decide quite a long time ago that using the redirects as you are is acceptable? You've been doing it since this edit. If you want to continue to use the redirects, you must set use_identifier_redirects = true;
If a goal for the cs1|2 modules is to be generally universal, special tweaks to satisfy the wishes of just one project are contrary to that goal of generality because they clutter the code with exceptions and special cases. Special cases are and should only be 'special' for some significant subset of the user community.
I started a discussion at Help talk:Citation Style 1 § i18n: live / sandbox selection.
—Trappist the monk (talk) 16:45, 2 February 2022 (UTC)[reply]
Yes yes yes... Don't forget to add to Module:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki whever you have some good info :-)
About translating categories and help text I guess it would be possible just to leave the English names and add redirects to a localized name. That way no changes are needed in the module so whenever there is an update you can just copy paste from enwiki. Users that do not understand English have to click the "(help)" link to get to a place where there is help to find. Sadly thats not an option on dawiki so I hope future changes does not mess the section with error messages and categories too much. --MGA73 (talk) 17:48, 2 February 2022 (UTC)[reply]
I agree in regard to generality. But at least I'd like to have all the needed manual changes gathered in 1 page.
Where would be the best place to ask for such a tool? That would be really helpful to me for detecting deleted categories.
Grateful for that discussion. :)
@MGA73, yes. As I've said above, I was hoping to finish working with the aforementioned table before working with details like that. - Klein Muçi (talk) 01:01, 3 February 2022 (UTC)[reply]
(edit conflict)
You mean the category comparison tool? It cannot be dynamic. We could write a module that would do the comparison if a human manually created a 'live category list' (sort of the same thing as sq:Moduli:CS1 chart/data). Scribuntu does not have access to categories; sure, it has access to the magic words so it can know how many pages or files or categories are in a category, but there is no access to content (category names).
—Trappist the monk (talk) 01:24, 3 February 2022 (UTC)[reply]
I'm starting to get confused.
I check the old versions to see what's wrong with the language missing error at us but I don't see anything. Still the category is empty. I think that I should finish importing the sandbox version of ~/Configuration to the live page and maybe it gets fixed. To do that I want to deal with the category changes. I check w:sq:Moduli:Citation/CS1/doc/Category list and I see no change between the sandbox and live versions. I see nothing about the sandbox versions to begin with. I thought maybe there are problems with that and so I check w:sq:Moduli:CS1 documentation support. There I get an error with another module which may or not be related with the code itself (maybe it's just related to the doc page). I'm really sorry to bother but... :/ - Klein Muçi (talk) 01:20, 3 February 2022 (UTC)[reply]
At w:sq:Moduli:Citation/CS1/doc/Category list under the heading I see:
Në versionin e livadhit por jo në atë kryesorin (1) kategori
sq:Kategoria:Gabime CS1: Emër i përgjithshëm – redlinked
under the heading:
Në versionin kryesor por jo në atë të livadhit (2) kategori
sq:Kategoria:Mirëmbajtja CS1: Tekst shtesë: $1 – redlinked
sq:Kategoria:Mirëmbajtja CS1: Është përdorur ref=harv – blue linked; we have stopped supporting that category
under the heading:
Në versionin e livadhit por jo në atë kryesorin (2) kategori
sq:Kategoria:Mirëmbajtja CS1: Datë e përkthyer automatikisht – redlinked
sq:Kategoria:Mirëmbajtja CS1: Gjendja e adresës – redlinked
under the heading:
Në versionin kryesor por jo në atë të livadhit (1) kategori
sq:Kategoria:Vetitë CS1: Vlera në gjuhë me shkronja jo latine – blue linked
under the heading:
Në versionin e livadhit por jo në atë kryesorin (4) kategori
sq:Kategoria:Vetitë CS1: Parametër i gjurmuar: $1 – redlinked
sq:Kategoria:Vetitë CS1: Vlera në abkazisht (ab) – redlinked
sq:Kategoria:Vetitë CS1: Vlera në Classical Syriac (syc) – redlinked
sq:Kategoria:Vetitë CS1: Vlera në kantonezisht (yue) – redlinked
blue linked here because these links are all external links... different blue from the blue used for internal wikilinks.
—Trappist the monk (talk) 01:38, 3 February 2022 (UTC)[reply]
I'm stupid. Apparently I had totally forgotten that we had already done a RFC a couple of months ago to switch from /Livadhi to /sandbox for every module and template ever in SqWiki. They would be "masked" under "Livadhi" but the sandbox pages would always be located under /sandbox for greater technical facilities and compatibility with EnWiki. The same for /doc and /testcases. Apparently after that RFC I had forgotten to specify that in w:sq:Moduli:CS1 documentation support and that's why that comparison tool wasn't working. I believe I should also revert the sandbox → Livadhi change I made to w:sq:Moduli:Citation/CS1, no? (Doing that now.) The discussion you've started is still a good thing because not all wikis will follow the same standard but SqWiki uses "sandbox" now.
I still get that error in regard to the Module:Lua banner though. And I'm yet to fix the missing language error category but at least now I can go on with the other category changes.
As for the tool, if that's not too hard for you and if there is a function/tool that can give us a list of the categories, (PetScan maybe?) we can settle for that. Otherwise it wouldn't be worth it I believe. - Klein Muçi (talk) 01:38, 3 February 2022 (UTC)[reply]
I finished the update process. Remaining problems and questions:
  1. What does this category serve for and should it be created here or not: Category:CS1 maint: date auto-translated
  2. Same question about this category: Category:CS1 tracked parameter: $1 - Also check this discussion
  3. Is the description in this category I created correct?
  4. Same question about this category.
  5. I did this revert. I believe it is correct, no?
  6. The category w:sq:Kategoria:Gabime CS1: Mungon parametri i gjuhës (missing language parameter) keeps being empty while in reality there should be around 10k articles in it. What am I doing wrong? Check the references here. The error there may help you.
  7. In w:sq:Moduli:Citation/CS1/doc/Category list I get some property categories in English. What's going on? - (talk) 02:44, 3 February 2022 (UTC)[reply]
In regard to the #7th question, I remembered this:
What do I do with Ottoman Turkish (ota) which doesn't follow format. Should I remap it somehow? - Klein Muçi (talk) 01:04, 3 August 2021 (UTC)[reply]
PS: Categories for languages' scripts with ISO codes (bo) and (dz) are currently missing at EnWiki. Can you create them so I do the Wikidata connections? I'm afraid I might forget to do it later. :P - Klein Muçi (talk) 01:24, 3 August 2021 (UTC)[reply]
You will have to add ota to lang_code_remap{} and lang_name_remap{} or not bother until there is something in that category. I have created Category:CS1 uses Tibetan-language script (bo) but not created the others because there is nothing in them. When it comes time to update the module suite again, I may decide to delete dz and ota – no point in supporting something that isn't bein used.
—Trappist the monk (talk) 13:02, 3 August 2021 (UTC)
I'm guessing I should go on with the remapping now, no? - Klein Muçi (talk) 11:37, 3 February 2022 (UTC)[reply]
Answers
  1. Category:CS1 maint: date auto-translated is not used at en.wiki. It is for other wikis that have date_name_auto_xlate_enable = true; to identify which templates have month names that were auto-translated from English.
  2. That category gets articles that have cs1|2 templates that use the tracked parameter named in the category title – $1 is a place-holder for that parameter name. This is a properties category so there is no messaging visible to editors who are using the outdated popup tool. Tracked parameters are identified in ~/Whitelist.
  3. yes
  4. yes
  5. if sq.wiki now supports ~/sandbox then yes
  6. we simplified error handling. Try this at line 3624: utilities.set_message ('err_language_missing'); -- emit an error message and add to category
  7. cs1|2 gets language names from MediaWiki; if MediaWiki does not have the Albanian form of a name, it may fall back to English or some other language. In this case:
    {{#language:syc|sq}} → Classical Syriac
    {{#language:ota|sq}} → Ottoman Turkish
    these can be remapped in ~/Configuration
—Trappist the monk (talk) 13:02, 3 February 2022 (UTC)[reply]
  1. I'm sorry to have to ask this question, but why do we track those articles? I created that and it skyrocketed to being the CS1 category with the most entries, surpassing even the error category for missing the language parameter. What's there exactly to maintain in these articles? Wouldn't it be better to be a prop-cat? Also, the cat-lister tool currently lists it as missing in EnWiki. Is that expected to be normal behavior?
  2. I understand. Currently there aren't any tracked parameters though, am I right? - Klein Muçi (talk) 14:46, 3 February 2022 (UTC)[reply]
This is why it is that I don't want to do special stuff for individual wikis. The auto-translated date category was created for User:MGA73 as the result of this discussion. And here you are complaining about that.
en.wiki is not currently tracking any parameters.
—Trappist the monk (talk) 15:17, 3 February 2022 (UTC)[reply]
Time does pass fast and my memory fails along the way. Apparently I had taken part in that discussion and I had totally forgotten about it. Funnily enough, I've said the same thing I have said these days. I must be obsessed with that idea apparently. :P I have yet to read carefully the part where the category rationale is discussed and will do so soon (I couldn't at the moment). I just replied because I was really surprised to read my words there. - Klein Muçi (talk) 15:39, 3 February 2022 (UTC)[reply]
@Trappist the monk, I'm sorry I'm still pressing on this subject but I read the aforementioned discussion and I'm still not totally sure what that category serves for. I do understand it serves to detect special cases of mistakes that may come from the auto-translation feature but I don't understand what these cases may be exactly and how do we fix them. :/ - Klein Muçi (talk) 01:58, 4 February 2022 (UTC)[reply]
The way I read it is that someone writes a bot that knows the English month names and their short versions and it knows the local language month names and their short versions. The bot then trawls the category replacing English month names with local month names. How useful is that? Don't know.
Since we're speaking of month names... Compare line 533 with line 534. sq.wiki apparently does not want short month names so you have made both data_names['local']['long'] and data_names['local']['short'] almost the same. Are they supposed to be the same?
—Trappist the monk (talk) 02:17, 4 February 2022 (UTC)[reply]
But... How can they be in English if auto-translation is enabled? You're talking about the source code? Not what's rendered?
Take this article: https://sq.wikipedia.org/wiki/%27s-Graveland
It is one of the articles that currently is on that category for us. That article has many issues but focusing on the matter at hands, what exactly is causing it to be there? It doesn't even have a date somewhere in its only citation... - Klein Muçi (talk) 02:25, 4 February 2022 (UTC)[reply]
And yes, they're supposed to be the same. (You stressing "almost" worried me now. :P ) In Albanian the concept of months abbreviation doesn't exist. Neither grammatically, nor in everyday life. - Klein Muçi (talk) 02:30, 4 February 2022 (UTC)[reply]
MediaWiki would disagree:
qer ← {{#time:M|2021-06-01|sq}}
—Trappist the monk (talk) 03:34, 4 February 2022 (UTC)[reply]
sq:Stampa:SHORTDESC:Place which looks to me like it has been vandalized. Apparently it is some sort of a default because sq:Stampa:Infobox settlement doesn't have a value for |settlement_type= – set |settlement_type=town and the cs1|2 template and its maint messages goes away.
—Trappist the monk (talk) 03:34, 4 February 2022 (UTC)[reply]
It was just a promotional article for a TV station - Now deleted.
And judging again by its 1 reference, I'm now sure the category really deals with dates that have been written in English. This is very similar in mechanics with what Smallem's main job is: Convert language names into ISO codes. Basically if we were to fix the problems with the said category we'd devise 12 different regexes (24 if we count the short versions) and just let Smallem convert all months from English to Albanian. (Hopefully I'm not overlooking something in that plan.) But, why? What exactly was the rationale behind the choice for using local dates? Was it because DaWiki has already localized every other detail? Was it because English dates were bringing harm to them somehow/corrupting anything? Any other reason? I'm trying to understand how this affects us (or other wikis in general) and if I should give more work to Smallem or not. To clarify: Not an accusation of any kind. I'm really trying to understand because up until this moment I had never thought of typing date values in English as a problem.
As for the months' short versions, our official language rules say nothing about abbreviations. They just say that they shouldn't be capitalized and how to write different date formats, when the day is mentioned, etc. Maybe in everyday life people may have adopted the 3 letter abbreviation method but that seems a bit strange for some months which have a rather short name and the abbreviation would just be the long name - 1 letter, at which point to some it may feel like a typo, not a deliberate abbreviation. Can you give me a full list of what Mediawiki thinks our abbreviations are? (This is coming from CLDR I believe, no?) - Klein Muçi (talk) 04:30, 4 February 2022 (UTC)[reply]
Don't know where the shortened month names come from; perhaps CLDR but if so, not from the same place as the language names. You can get a list of the long and short month names from Module:Sandbox/trappist the monk/i18n dates. Runs from the debug console so: Edit; then in the debug console enter: =p.main ('sq').
—Trappist the monk (talk) 12:34, 4 February 2022 (UTC)[reply]
Thank you! Just did. It must be CLDR because if you search for the names of the short months in the corresponding Albanian repository, they all appear there. Try CTRL+F-ing any one of them here: https://github.com/unicode-org/cldr/blob/main/common/main/sq.xml
Mediawiki must have located that information in another file.
As you may see yourself, our 8th month abbreviated form is just the long version minus 1 letter. And, as I've said below, there are no official rules in regard to date abbreviations in Albanian (be that for months or days). So I'm not sure if I should adopt them or not. :/ Maybe, given that CLDR has already adopted them may be a sign that the Albanian CS1 module should also do that. - Klein Muçi (talk) 15:53, 4 February 2022 (UTC)[reply]
... And found the (list of) file(s): https://gerrit.wikimedia.org/g/mediawiki/core/+/c82ced1ba18f5bb750b4989bb7d857e7ada1cafa/languages/i18n
The abbreviated date names are listed in a JSON file together with other phrases that are used in various commands or messages. - Klein Muçi (talk) 16:00, 4 February 2022 (UTC)[reply]

This is a long discussion and I'm not sure how to comment best here. Make an outdent? Reply below the one comment above I would like to comment on? So here it goes: The module translate:

  • 1 February 2022 into
  • 1 februar 2022 but the the correct would be
  • 1. februar 2022

But that would require that |df= is set in the templates if I understand it correct. So to make it easy we have the tracker category so it is easy to find and fix those dates. Another argument is that it is easier for users to understand the templates if what they see in source text is what they see on screen.

If the tracker category bothers some wikis then it should be easy to disable by with false instead of true so I do not see the problem? --MGA73 (talk) 10:35, 4 February 2022 (UTC)[reply]

@MGA73, so just to be absolutely sure:
We have this citation: {{cite book|title=Something|date=1 February 2022}}
Which get rendered like this: Something 1 February 2022 in EnWiki
In DaWiki it gets rendered like this: Something 1 februar 2022 because of automatic translation
Which isn't exactly correct so you go at the source code and change {{cite book|title=Something|date=1 February 2022}} → {{cite book|title=Something|date=1. februar 2022}}
Am I correct? Are there other cases where the automatic translation wouldn't be enough for you beside this which requires adding a period after the date? - Klein Muçi (talk) 10:48, 4 February 2022 (UTC)[reply]
Yes Klein Muçi, that is correct. Another example is {{cite book|title=Something|date=February 1, 2022}} which will get rendered like this: Something februar 1, 2022 in DaWiki. --MGA73 (talk) 12:16, 4 February 2022 (UTC)[reply]
@MGA73, and in that case you'd like it to be again with a period instead of the comma? Is that the only acceptable date format in DaWiki: date. month year? - Klein Muçi (talk) 12:22, 4 February 2022 (UTC)[reply]
Klein Muçi we we often copy templates from other wikis so English dates and formats are accepted as valid. But for correct Danish writing I think you could use 1. februar 2022, 1. feb. 2022, 1/2 2022, 1/2-2022 and 2022-02-01. In the article text we would normally prefer 1. februar 2022 but in the refs I think most users would not make an edit just to chose another format. --MGA73 (talk) 14:10, 4 February 2022 (UTC)[reply]
Hmm... I see. So you want to input manual formatting details so that the rendering is conform DaWiki's standards.
My first instinct would be to ask to formalize that in the code itself. Twist the CS1 module in such a way that it auto-translates the dates correctly, following your standard. But you've listed far too many variables above and writing code to differentiate between all those cases would be hard. So in that case I understand why you might need the said category.
The only question I have now is in regard to SqWiki. We don't have much specific details in regard to dates in Albanian. This is all what our spelling dictionary has to say about dates: http://www.drejtshkrimi.info/data
It literally lists only 5 rules, the main ones of which say that: Months shouldn't be capitalized, the chosen format is dmy and if numberals are used to express the date, (be that Arabic or Roman), they should be divided by a dot. These are all specifics that are already provided by the auto-translate function, as far as I understand. Do we really need that category if that's so? @Trappist the monk may be able to provide a better opinion. Again, that's not a rhetoric question, neither an accusation. It is a sincere naive question and I'd be okay with whichever answer I got. However, if the answer tends to go more towards "No", then I have a follow up question: How would we deactivate it? Do we switch from true to false in the exports section? Or do we remove it from the maint cats section? If the answer tends to go more towards "Yes" then I believe the only change that we'd make is plain translation without any added formatting rules, at which case, Smallem, my robot, could give deal with it with the power of regex. - Klein Muçi (talk) 15:36, 4 February 2022 (UTC)[reply]
I was again checking articles at the newly added date category. I still struggle with it. This article has a citation which only has a year as a value in the date parameter and it still gets put in that category. No translation whatsoever is happening. At least, to my understanding. What's going on? - Klein Muçi (talk) 01:13, 6 February 2022 (UTC)[reply]
line 2071 Why?
—Trappist the monk (talk) 01:55, 6 February 2022 (UTC)[reply]
Uhm, because Albanian uses the same digits locally as the whole Western World so "translating to the local language" would either be an improvement, somehow, or do nothing at all?
I wasn't sure what that would mean in our case to be honest, that's why I made this edit, hoping to get more information about it. - Klein Muçi (talk) 02:11, 6 February 2022 (UTC)[reply]
As far as I understand the module has actually automatically translated 1942 into 1942. No visible change but the automatic translation process has occurred and that's why it get categorized there. My understanding was that nothing would happen if there was nothing to translate. - Klein Muçi (talk) 02:23, 6 February 2022 (UTC)[reply]
Yes, it did as it was instructed to do and then reported that it had done so.
—Trappist the monk (talk) 14:48, 6 February 2022 (UTC)[reply]
line 527: why?
—Trappist the monk (talk) 02:07, 7 February 2022 (UTC)[reply]
Because I'm blind of course, what else did you think?
:P Fixing it now. (I'm looking forward to that automatic month detection feature even more now.) - Klein Muçi (talk) 02:15, 7 February 2022 (UTC)[reply]

A beer for you![edit]

For your comment at Wikipedia:Help_desk#Links_to_imdb_that_looks_like_wikilinks, it was quite helpful. Gråbergs Gråa Sång (talk) 18:20, 9 February 2022 (UTC)[reply]

Smallem - regexes[edit]

We're coming to the last part of the update process for SqWiki. (Finally!) After finishing with the modules and categories I go and update Smallem's source code with the language regexes that might have changed and any other maintenance regex that might have been deemed obsolete or added newly.

This time I removed (r"(\{\{\s*cit[aeio][^\}]*)\|\s*ref\s*=\s*harv\b", r"\1") and given that we decided to keep the category related to date auto-translation after its number fell down to a reasonable size (after I fixed the mistakes I had made) I'm wondering if Smallem can help with dates. The idea is to provide a similar support as to what it currently does for languages: Switch every date from English into a standard Albanian date. My vague idea is that this can be achieved by dealing with the months names but I also have the feeling that there exists much variety around which would made it an impossible feat. My first thought was to just be able to locate the date parameter and its value and then switch every English month name into its homologue Albanian one. The problem with that though is that we require DMY as a format and there may be many cases where that's not what's happening with the English value date and in those cases that regex would just serve to hide an incorrect date (by masking it as correct and removing it from that category). If we set some personal maximal, medium and minimal aims in this, it would be like this:

  • Maximal: Can a regex solution be found for every date in every language?
  • Medium: Can a regex solution be found for every case in English?
  • Minimal: Can a regex solution be found for the most common cases in English?

I value your advices on regexes so I'd be very interested in hearing your thoughts on this matter.

And lastly, the next case we need to deal with is the problem IABot caused during its manic episode. Take a look at the citations in this article and you'll immediately understand what I mean. There are around 3k articles with the same problem. Can you help me with a regex to deal with these cases (following the aforementioned ref=harv format)? I suspect that it should be relatively easy. - Klein Muçi (talk) 11:58, 6 February 2022 (UTC)[reply]

PS: We'd prefer the hyphenated form for standardization reasons, if you remember what we've talked in the past. - Klein Muçi (talk) 12:01, 6 February 2022 (UTC)[reply]
Since the bot broke those templates, shouldn't the bot or the bot's operator do the fixing?
Maximal, Medium, Minimal:
  • Maximal: yes but very difficult because all possible month names and all possible date formats must be known and a regex written for each
  • Medium: yes, for properly formatted en.wiki dates (those that are not listed in sq:Kategoria:Gabime CS1: Datat) and because sq:Kategoria:Mirëmbajtja CS1: Datë e përkthyer automatikisht lists translatable dates with English month names; YYYY-MM-DD dates can also be translated.
  • Minimal: because medium is possible this too is also possible.
—Trappist the monk (talk) 15:06, 6 February 2022 (UTC)[reply]
See my comment here: https://phabricator.wikimedia.org/T291704#7430259 What should I do more than that? I never got a reply. :/
Assuming you can't built another tool like Module:Smallem especially made for this purpose, I believe the maximal target can be considered practically impossible. As for the medium and minimal targets, can you give me 1 practical example and let me replicate the needed results for the other 11 months? Then we can see what other formats are lacking and if they can be regexified. My guess is that more than 60% of the articles currently in that category are with citations in English coming from EnWiki, so I believe providing regex solutions for those cases will be enough. - Klein Muçi (talk) 00:35, 7 February 2022 (UTC)[reply]
At en.wiki we support 13 date formats that involve month/season names (if I believe your sq:Module:Citation/CS1/Date validation you use the same formats – that makes it easier):
Mdy – month-initial: month day, year
Md-dy – month-initial day range: month day–day, year; days are separated by endash
dMy – day-initial: day month year
d-dMy – day-range-initial: day–day month year; days are separated by endash
dM-dMy – day initial month-day-range: day month - day month year; uses spaced endash
Md-Mdy – month initial month-day-range: month day – month day, year; uses spaced endash
dMy-dMy – day initial month-day-year-range: day month year - day month year; uses spaced endash
Mdy-Mdy – month initial month-day-year-range: month day, year – month day, year; uses spaced endash
My-My – month/season year - month/season year; separated by spaced endash
M-My – month/season range year; months separated by endash
My – month/season year or proper-name year; quarter year when First Quarter YYYY etc.
Sy4-y2 – special case Winter/Summer year-year (YYYY-YY); year separated with unspaced endash
Sy-y – special case Winter/Summer year-year; year separated with unspaced endash
Then there are 11 date-holding parameters:
|accessdate=
|access-date=
|archivedate=
|archive-date=
|date=
|doi-broken-date=
|lay-date=
|pmc-embargo-date=
|publication-date=
|airdate=
|air-date=
And, if course 12 month names and 12 abbreviated month names.
Start simple: dMy for |date= and 'January' probably looks something like this:
(r"(\{\{\s*cit[aeio][^\}]*\|\s*date\s*=\s*\d{1,2} +)January( +\d{4})", r"\1janar\2")
repeat for February–December; repeat for Jan–Dec. Then, shift to the next parameter. For dMy that should be 12×12×8=1,152 regexes.
—Trappist the monk (talk) 15:30, 7 February 2022 (UTC)[reply]
But, can't we use something that catches the [(-)date=] part so we account for each parameter simultaneously? I totally forgot that there exist different valid date formats. I was only thinking about dM/my. And I also forgot about the abbreviated names so in my mind I was only expecting 12 lines or so in total for EnWiki dates. - Klein Muçi (talk) 15:54, 7 February 2022 (UTC)[reply]
I have a vague memory that says we tried that for something else and whatever it was did not work. You can always try; if it works, great; if not, oh well.
(r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*\d{1,2} +)January( +\d{4})", r"\1janar\2")
—Trappist the monk (talk) 16:08, 7 February 2022 (UTC)[reply]
Thanks a lot! My plan is to create a list with 24 lines like that (long + short), try it isolated from the rest of the regexes, see what Smallem does in its first 5 edits and then if things go good, talk with you about the other formats. - Klein Muçi (talk) 16:19, 7 February 2022 (UTC)[reply]
Wrote 24 lines (l + sh), tested them, they worked correctly and the category size started getting smaller.
Can you give me examples for the other formats of which I can replicate?
Don't bother writing the (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s* part. Start at the equal sign which is the part that is supposed to be format specific. - Klein Muçi (talk) 01:01, 8 February 2022 (UTC)[reply]
Last of the simple ones:
  • d-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*\d{1,2}[\-–]\d{1,2} +)January( +\d{4})", r"\1janar\2")
  • Mdy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January( +\d{1,2}, +\d{4})", r"\1janar\2")
  • Md-dy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January( +\d{1,2}[\-–]\d{1,2}, +\d{4})", r"\1janar\2")
  • My: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January( +\d{4})", r"\1janar\2")
—Trappist the monk (talk) 01:35, 8 February 2022 (UTC)[reply]
Finished writing the lines (l+sh) and let Smallem do 5 changes. It keeps going well except for the fact that I noticed this kind of change. The change on itself is good, the problem is with the comma and the months before the date, both formats not acceptable in Albanian. And yet, the articles show no errors in regard to dates whatsoever. Do we have to live with that? Or do we enter the annoying part of changing the date validation page somehow? :/ - Klein Muçi (talk) 03:13, 8 February 2022 (UTC)[reply]
But isn't that what you asked for? The regexes are doing exactly that cs1|2 does when date_name_auto_xlate_enable = true;. There are no error messages because Mdy-format dates are supported at sq.wiki and the translated month name is a valid month name. If Mdy-format dates at sq.wiki are not to be supported, then yes, the annoying part of changing the date validation page is inevitable. No doubt the regexes above can be tweaked to reformat Mdy dates into some other format.
—Trappist the monk (talk) 12:38, 8 February 2022 (UTC)[reply]
Yes, we need to change then unfortunately. It's been quite a long time I notice dates to be acting weird but I've thought I'll deal with them once I've solved most of the other problems before. My hope was that the automatic translation would somehow know what is the right format for SqWiki by getting information from somewhere from Mediawiki and it would accordingly. I've tried convincing myself that those minimal mistakes I was seeing were edge cases but.. As time passed by, you've helped me solve all the other problems, even interface ones, Smallem came into existence and things have gone more or less smoothly so maybe this is the time to start worrying about the date (before we continue with further regexes).
So Albanian date rules are simple:
  1. If the date is a full one written in numbers (e.g. 8.2.2022) we are to use periods as separators. Only dots are allowed. And the format is always dmy.
  2. If the date is a full one with the month name written in words, then no separators whatsoever are to be used, format is always dmy and the month's name first letter never capitalized.
Those are the only rules that we have. We don't have rules about not full dates or abbreviated months, etc. So far I've interpreted that in the way that no other date is to be accepted beside dates being in one of those 2 conditions (full with numbers or words) but I changed mind after the CLDR month abbreviation episode. So now I'm interpreting that we need to stick to those rules for full dates and we can be generally acceptive and creative on other case, after all our spelling rules were revised for the last time in the '70s. What formats on EnWiki disagree with those rules, what changes would we need to make in date validation and how would that translate in regard to the regexes that we're writing?
Finally, a question: Are we sure we need to set up valid date formats manually? Can't that be extracted from Mediawiki somewhere per site automatically? - Klein Muçi (talk) 13:19, 8 February 2022 (UTC)[reply]
What formats on EnWiki disagree with those rules[?] All except dMy – if the two date formats that you named are really the only two allowed. Surely you don't mean that Albanian doesn't allow for:
  • 7–8 januar 2022 (d-dMy)
  • 27 januar – 3 shkurt 2022 (dM-dMy)
  • 27 dhjetor 2021 – 3 januar 2022 (dMy-dMy)
en.wiki does not allow for dates that are d.m.y format.
what changes would we need to make in date validation[?] We would need to create a rule set for the d.m.y format.
So far as I know, MediaWiki does not have date formatting functionality except as part of the {{#time}} parser function which is roll-your-own.
Mdy → dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January +(\d{1,2}), +(\d{4})", r"\1\2 janar \3")
—Trappist the monk (talk) 14:15, 8 February 2022 (UTC)[reply]
Yes, that's the "apply common sense and creativity part". Although the dash that you use for those dates seems strange to my eyes. We usually use the hyphen (-) for everything, although we don't have rules set up for that. The idea is that given that we use only 1 kind of line separator, I'm guessing we've never bothered to differentiate and that line is usually referred to just as "the line" in Albanian rules.
I'll see around in the Mediawiki files to check what kind of information it might have about dates. - Klein Muçi (talk) 14:27, 8 February 2022 (UTC)[reply]
Reverted all Smallem's changes, tried again the list of regexes with the proposed change, worked like a charm.
Whenever you can, give me the regexes for the other formats and tell me how to add the new rule for d.m.y. :) - Klein Muçi (talk) 02:12, 9 February 2022 (UTC)[reply]
In regard to the Mediawiki's date formatting functionality, this is what I found.
This is a file I've already shown you in the near past: https://gerrit.wikimedia.org/g/mediawiki/core/+/9da4e7da21463de5ac71783d12533ace4eddb91a/languages/messages/MessagesSq.php
In it, you'll see in the end that it does provide some date formatting.
I went along and ventured on some other languages to see the difference.
This is the the same file but for Arabic:
https://gerrit.wikimedia.org/g/mediawiki/core/+/9da4e7da21463de5ac71783d12533ace4eddb91a/languages/messages/MessagesAr.php
See its beginning. You'll see that the Arabic community has set up way more details in regard to date formatting functions when compared with us. You can try studying other languages by changing the language code in the xx.php part in the URL. Most of them make reference of a file called DateFormatter.php.
I was able to locate the said file here: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/parser/DateFormatter.php
I also found this in the same folder: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/parser/DateFormatterFactory.php
I haven't stopped to study them carefully but the header of DateFormatter.php is pretty interesting. Take a closer look.
Judging by all above I do think Mediawiki has date formatting functionalities, generally speaking, but I'm not sure if those can be utilized somehow by CS1. - Klein Muçi (talk) 03:31, 9 February 2022 (UTC)[reply]
That date formatting is available through the {{#dateformat:}} magic word but that facility is limited and has (for cs1|2) undesirable metadata:
{{#dateformat:2022-02-09|dmy}} → 9 February 2022 → <span class="mw-formatted-date" title="2022-02-09">9 February 2022</span>
—Trappist the monk (talk) 17:09, 9 February 2022 (UTC)[reply]
date translation:
  • M-My: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January[\-–]February +(\d{4})", r"\1 januar–shkurt \2") – one each for januar and shkurt–dhjetor; then, one each for shkurt and mars–dhjetor, etc until one for nëntor and dhjetor; also seasons following the same pattern
  • dM-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)(\d{1,2}) +January +[\-–] +(\d{1,2}) +February +(\d{4})", r"\1\2 januar – \3 shkurt \4") – one each for januar and shkurt–dhjetor; then, one each for shkurt and mars–dhjetor, etc until one for nëntor and dhjetor
  • My-My: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January +(\d{4}) +[\-–] +January +(\d{4})", r"\1 januar \2 – januar \3") – one each for januar and januar–dhjetor; then, one each for shkurt and januar–dhjetor; also seasons following the same pattern
  • dMy-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)(\d{1,2}) +January +(\d{4}) +[\-–] +(\d{1,2}) +January +(\d{4})", r"\1\2 januar \3 – \4 januar \5") – one each for januar and januar–dhjetor; then, one each for shkurt and januar–dhjetor
  • Sy-y: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)Winter +(\d{4})[\-–](\d{4})", r"\1 dimër \2–\3") – also one for Summer/verë
  • Sy4-y2: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)Winter +(\d{4})[\-–](\d{2}\b)", r"\1 dimër \2–\3") – also one for Summer/verë
date reformatting:
  • Md-dy → d-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January +(\d{1,2}[\-–]\d{1,2}), +(\d{4})", r"\1\2 januar \3")
  • Md-Mdy → dM-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January +(\d{1,2}) +[\-–] +February (\d{1,2}), +(\d{4})", r"\1\2 januar – \3 shkurt \4") – one each for januar and shkurt–dhjetor; then, one each for shkurt and mars–dhjetor, etc until one for nëntor and dhjetor
  • Mdy-Mdy → dMy-dMy: (r"(\{\{\s*cit[aeio][^\}]*\|\s*(?:access\-?|archive\-?|doi\-broken\-|lay\-|pmc\-embargo\-|publication\-|air\-?)?date\s*=\s*)January +(\d{1,2}), (\d{4}) +[\-–] +February (\d{1,2}), +(\d{4})", r"\1\2 januar \3 – \4 shkurt \5")
—Trappist the monk (talk) 17:09, 9 February 2022 (UTC)[reply]
I'm guessing these will also require the short versions no? Now we're starting to go on the really heavy duty part. Do I have any smart choice beside manually writing all what you suggested line by line? Only the first format looks like it needs a gigantic list of regexes. - Klein Muçi (talk) 23:42, 9 February 2022 (UTC)[reply]
(I've started working on it anyway.) - Klein Muçi (talk) 00:20, 10 February 2022 (UTC)[reply]
Please, can you confirm if I need the short versions in the regexes you wrote in your last edit or not? I've already completed 3 of them but they go by big bulks and I can't go further without knowing for sure if abbr. months are needed or not. Currently I'm not adding them and reading them later will be difficult if I add too much lines. - Klein Muçi (talk) 12:47, 10 February 2022 (UTC)[reply]
Depends on what you want to do. Since Albanian apparently doesn't support abbreviated month names you can replace the English month names in the regexes with something like this (don't bother with 'May'):
(?:Jan|January)
If you want to allow abbreviated Albanian month names then they will require separate regexes.
—Trappist the monk (talk) 13:56, 10 February 2022 (UTC)[reply]
Yeah, we do allow them ever since I saw our last conversation so I'm going on with the extra work. Thank you! :P :) - Klein Muçi (talk) 01:17, 11 February 2022 (UTC)[reply]
How does the pattern continue at:
Md-dy → d-dMy?
Same question for:
Mdy-Mdy → dMy-dMy
Also, the 2 formats above them have only summer and winter. Is it okay that they're missing spring and autumn?
And finally, relooking at the ~/Configuration module, shouldn't we also add lines for Fall, Easter, Christmas, and trimesters?
Bonus question whose answer I'm afraid of:
We have regexes for January - January = janar - janar and for Jan - Jan = jan - jan. What about January - Jan = janar - jan and all the combinations in between? That would quadruple some of the lists. :'( - Klein Muçi (talk) 12:54, 11 February 2022 (UTC)[reply]
Md-dy → d-dMy: just one month so: January → janar; February → shkurt; etc
Mdy-Mdy → dMy-dMy: same as dMy-dMy
Only summer and winter cross the year boundary. 'Fall' is part of My, M-My, My–My, so yes; quarters and named: yes.
January–Feb 2022 and similar are not valid date formats.
—Trappist the monk (talk) 14:19, 11 February 2022 (UTC)[reply]
Phew! Where do I need to add the quarters and the named ones?
And how exactly do I need to add the quarters? - Klein Muçi (talk) 14:26, 11 February 2022 (UTC)[reply]
Ranges not supported for named and quarter dates so: My.
First Quarter → Tremujori i parë etc.
Season, named, and quarter dates are not autotranslated (they probably should be) so articles with those dates will not appear in Mirëmbajtja CS1: Datë e përkthyer automatikisht.
—Trappist the monk (talk) 14:36, 11 February 2022 (UTC)[reply]
Just finished up the list of regexes and returned to add what I had missed. Started with "Fall". I have only 2 formats in where I've used seasons:
M-My and My–My
Those are the formats where you've mentioned adding seasons in the directions below.
You say I should also add it at My but I haven't add seasons there because you haven't mentioned it. Should I? - Klein Muçi (talk) 02:20, 12 February 2022 (UTC)[reply]
You also say I should add quarters only at My. (Beside the supposed seasons.) Have I understood you correctly?
Where do I add "named" though? You say that I should add translations for them but you don't specify where. Only My again? - Klein Muçi (talk) 02:29, 12 February 2022 (UTC)[reply]
My is the only place that named and quarter dates are allowed.
—Trappist the monk (talk) 12:23, 12 February 2022 (UTC)[reply]

I've completed and separated them by formats. ~1300 lines in total. Can I show you a file with them so you can take a look and see if you can catch any blatant errors? - Klein Muçi (talk) 12:42, 12 February 2022 (UTC)[reply]

If you want.
—Trappist the monk (talk) 13:28, 12 February 2022 (UTC)[reply]
Here. Because the lines are too long they get formatted badly. Copy-paste them in Notepad++ (or a similar editor) to see them clearly, 1 regex per line. - Klein Muçi (talk) 00:17, 13 February 2022 (UTC)[reply]
Click the 'raw' button. Stuff to consider:
  • ##dMy - seasons – comment doesn't make sense because seasonal dates don't have days
  • ##dMy - quarters – same
  • ##dMy - named – same
  • ##dMy - short – May → maj same as ##dMy - long; keep it or don't; there are others that might also go away or not; doubtful that these extras will overload smallem
  • ##Md-dy - long and ##Md-dy - short – why these if you also have ##Md-dy → d-dMy - long and ##Md-dy → d-dMy - short
  • ##M-My - seasons – any season to any season except itself within a single year is allowed because there are two hemispheres
nothing else jumped out at me (doesn't mean that there isn't other stuff to find...)
—Trappist the monk (talk) 01:29, 13 February 2022 (UTC)[reply]
Thanks for the observations!
Removed ##Md-dy - long and ##Md-dy - short, added the missing lines in ##M-My - seasons. I tried removing all the duplicate lines in the file. There were 7 line removed in total so I think May/maj is the only "problem". In general I haven't kept any duplicates so far but I kinda feel that in this case it would make working with them easier because there wouldn't be any "unexpected jumps" in months. Any suggestions for better comments? (XXX - named seemed bad ever since I first wrote it.) - Klein Muçi (talk) 01:55, 13 February 2022 (UTC)[reply]
Meanwhile, tried the list of regexes live. Did 15 edits, no problems whatsoever. I'll do a full run later. What do I need to change in ~/Date validation to add the new specific rule about d.m.y? - Klein Muçi (talk) 02:42, 13 February 2022 (UTC)[reply]
Add a pattern to patterns{} that might look something like this: 
	 																			-- day-initial numerical day.month.year
	['d.m.y'] = {'^(%d%d?)%.(%d%d)%.(%d%d%d%d)$', 'd', 'm', 'y'},
add an elseif to check_date()that might look like this: 
	elseif date_string:match (patterns['d.m.y'][1]) then						-- day-initial numerical day month year format
		day, month, year = date_string:match (patterns['d.m.y'][1]);
		if 12 < tonumber(month) or 1 > tonumber(month) or 0 == tonumber(day) then return false; end	-- month or day number not valid or not Gregorian calendar
		anchor_year = year;
—Trappist the monk (talk) 13:42, 13 February 2022 (UTC)[reply]
I added the new local pattern but I'm not confident enough to add the next part. Can you do that please? - Klein Muçi (talk) 14:18, 13 February 2022 (UTC)[reply]
No. Update the sandboxen so that they match the live modules and I'll do it there.
—Trappist the monk (talk) 15:08, 13 February 2022 (UTC)[reply]
Haha, sorry, I keep forgetting about the protection. Done. - Klein Muçi (talk) 15:17, 13 February 2022 (UTC)[reply]

Module:Citation/CS1 - error messages [translation][edit]

Now that the date validation is fixed (thank you) and Smallem is working fine (I keep checking on its contributions, hundreds done, no errors - thank you) there's only 1 last thing left to discuss:

There are some error messages that are present in Module:Citation/CS1 and which I haven't translated. One of the said messages can be found on my sandbox below the line. See the untranslated part in English. Skimming through the code, I think there are other cases like this. Can you help me locate them all? Is there a reason why they're there instead of ~/Configuration? - Klein Muçi (talk) 23:48, 13 February 2022 (UTC)[reply]

I had thought that I'd done that and in fact, I had – mostly. The missing prefix and three other message supplements are in ~/Configuration but for whatever reason, I did not fix the main module for those. To fix the modules at sq.wiki, see this diff.
—Trappist the monk (talk) 00:07, 14 February 2022 (UTC)[reply]
Thank you! Done. - Klein Muçi (talk) 00:23, 14 February 2022 (UTC)[reply]

Sandboxes[edit]

Do you need all those sandboxes? In particular, the taxonomy module ones. They're often cluttering search results for |journal=-related cleanup. Headbomb {t · c · p · b} 18:13, 14 February 2022 (UTC)[reply]

deleted.
—Trappist the monk (talk) 00:36, 15 February 2022 (UTC)[reply]

Purposeful error[edit]

Hey! I see you reverted my edit which added nowiki tags around a template throwing an error. I didn't know that you had it like that on purpose. I thought that you had somehow messed something up when adding the template so I added the nowiki tags so there wouldn't be that error. Thanks for letting me know! ― Blaze WolfTalkBlaze Wolf#6545 00:07, 17 February 2022 (UTC)[reply]

Nomination of Piri (1994) for deletion[edit]

A discussion is taking place as to whether the article Piri (1994), to which you have significantly contributed, is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or if it should be deleted.

The discussion will take place at Wikipedia:Articles for deletion/Piri (1994) until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.

To customise your preferences for automated AfD notifications for articles to which you've significantly contributed (or to opt-out entirely), please visit the configuration page. Delivered by SDZeroBot (talk) 01:02, 23 February 2022 (UTC)[reply]

Can I get you to check something for me?[edit]

I came across {{Hebrew name}}, {{Hebrew name 1}} and {{Hebrew name 2}}. I don't know if they actually encode template contents as Hebrew text, or, if they're like {{Script/Hebrew}}, they only mark it as Hebrew script, not Hebrew language. Could I possibly get you to dig around and check for me? I'd appreciate it a lot. Thanks!--Ineffablebookkeeper (talk) ({{ping}} me!) 14:07, 26 February 2022 (UTC)[reply]

I'm not sure what it is that you are asking. You, as an editor, provide the Hebrew Hebr-script text, the Hebrew Latn-script romanized text, English definition text, and whatever else the templates want. The templates provide more-or-less correct html markup for the Hebrew texts within the predominant left-to-right English text of an en.wiki article. Two of them use {{Script/Hebrew}} to provide styling for the Hebr-script text.
If you are thinking of using {{Hebrew name 1}}, consider using {{lang-he}} instead:
{{Hebrew name 1|לדוגמה|romanization|for example}} → Hebrew: לדוגמה, romanization, for example
{{lang-he|לדוגמה|romanization|for example}} → Hebrew: לדוגמה, romanized: romanization, lit. 'for example'
{{lang-he}} has better html markup and the labels may be more helpful to readers.
—Trappist the monk (talk) 15:36, 26 February 2022 (UTC)[reply]

Cite repair[edit]

Wouldn't it be better to repair these by making a second independent footnote? Adding a bullet to a existing footnote seems potentially confusing. ~Kvng (talk) 15:24, 26 February 2022 (UTC)[reply]

Maybe, but MureninC (no longer with us) apparently intended the |lay-*= parameter information to be part of a single reference. I am not interested in second-guessing an editor's intent so, to fix a broken citation, I bundle two citations into a single reference. If you believe, after due consideration, that it is better to unbundle the references, go ahead.
—Trappist the monk (talk) 15:48, 26 February 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Trappist_the_monk/Archive_22&oldid=1075507044"