To stop Monkbot, add a message to its talk page. Comments and questions about Monkbot are welcome here.

Hello! I've mentioned this one before but as I fix more citations, this is being brought back to my attention many times now. There are 3 ways people translate titles:

1. Using the |trans-title= parameter if a translated version of the specific work exists together with the title in the original;
2. Using the |trans-title= parameter just to literally translate the title only for the reader's curiosity - cases where a translated version of the specific work doesn't exist;
3. Spoofing the |title= parameter and hardcoding the translation in brackets beside the original title like it would appear if we were to use the |trans-title= parameter - used in cases where a translated version of the specific works exists or no

We don't do any kind of tracking whatsoever on any of these cases and you've said that the first one is the correct way but it is not explicitly said so anyway and the standard appears rather weak and left on the editor's interpretation.

Can we do something about it? I believe distinguishing 1 from 2 can be rather hard, if not impossible, to do automatically but we can maybe track 3? - Klein Muçi (talk) 12:07, 28 June 2022 (UTC)[reply]

I don't know how to distinguish improper use of [...] markup from legitimate use of [...] markup. Here is a search at sq.wiki. For humans, many of those are obviously improper; teaching the module to do something that is inherently human is not possible. Simply detecting [...] markup in |title= will result in too many false positives.

—Trappist the monk (talk) 13:06, 28 June 2022 (UTC)[reply]

We can't do anything even for the 3rd case? :/ Maybe prop-cat tracking? - Klein Muçi (talk) 15:33, 28 June 2022 (UTC)[reply]

No, because: I don't know how to distinguish improper use of [...] markup from legitimate use of [...] markup. and [simply] detecting [...] markup in |title= will result in too many false positives.

—Trappist the monk (talk) 16:06, 28 June 2022 (UTC)[reply]

Me sad. :( - Klein Muçi (talk) 16:08, 28 June 2022 (UTC)[reply]

Hello! Sorry for coming back this fast for a simple thing but can you help me understand what I'm doing wrong here with the sfn template? I'm very bad with those templates and I want to be better so I can help my community more. - Klein Muçi (talk) 15:41, 29 June 2022 (UTC)[reply]

PS: I do notice our Module:Footnotes does need some updating but I don't think those errors are related with that. - Klein Muçi (talk) 15:46, 29 June 2022 (UTC)[reply]

This is why we have template documentation...

((sfn)) does not have |last<n>=, |first<n>=, |year=, or |pages= parameters. The names are surname-only in individual positional parameters followed by a 'year' positional parameter; to distinguish between single page and multiple pages, ((sfn)) has |p= and |pp= named parameters.

((sfn|last=Cankja|first=Drita|last2=Hatellari|first2=Manjola|year=2014|pages=12-13)) → ((sfn|Cankja|Hatellari|2014|pp=12-13))

—Trappist the monk (talk) 16:05, 29 June 2022 (UTC)[reply]

I thought I had already done that here. I only tried adding the other parameters as a desperate attempt to make it work before asking here. Apparently even the first time I hadn't done it correctly. I had forgotten to remove the ref tags and the year parameter. Unfortunately I strongly believe I would still be here even if I wouldn't have forgotten that because I didn't know that |pages= was NOT an alias for |p= AND |pp=. Apparently they work totally differently from the cite templates. Thank you! :) - Klein Muçi (talk) 16:36, 29 June 2022 (UTC)[reply]

((sfn|Cankja|Hatellari|2014|p=12-13)) does not create an error and neither does ((sfn|Cankja|Hatellari|2014|pp=12)). Shouldn't they? - Klein Muçi (talk) 16:42, 29 June 2022 (UTC)[reply]

Template talk:Sfn § p vs. pp detection; pretty much why cs1|2 doesn't emit page number errors. Additionally, |p=12-13 may refer to a page range (page 12 and page 13) or it may refer to the chapter 12 page 13; one reason en.wiki uses ndash separators in ranges.

—Trappist the monk (talk) 16:51, 29 June 2022 (UTC)[reply]

But... Naive question but shouldn't that be considered a mistake? The page parameter should be for pages (not chapters?) and it should have it clear correct way(s) to be completed? If allowing totally free text completion as acceptable values is ground to create misunderstandings between different users, shouldn't we strive to solve these misunderstandings to facilitate information finding, the main goal of citations?

I'm not pushing to set up a standard (although I usually do love standards) - I'm just confused by what I read. In my mind that (the example and your explanation) reads as we haven't created automatic error detection because different users use the same symbols to communicate different things in different citations and the system would be confused by that. But isn't that confusing even for humans themselves? Maybe my conceptualization is an oversimplication and there are certain factors I'm failing to consider. Or maybe I'm fully misunderstanding it. - Klein Muçi (talk) 17:04, 29 June 2022 (UTC)[reply]

See the table of contents at pdf-page 18 of this document: Department of Defense World Geodetic System 1984; note that page numbers for pages in chapters and appendices are hyphenated. cs1|2 must accommodate real-world pagination. Because the authors/editors of Department of Defense World Geodetic System 1984 elected to hyphenate chapter page numbers, properly citing one or more pages in that document requires cs1|2 to allow that form.

—Trappist the monk (talk) 20:01, 29 June 2022 (UTC)[reply]

Ah! So it is an already established real common practice. The example you brought was a good one, thank you! I had never encountered that before so I thought it was just a styling preference of editors on-wiki. That more or less answers my question but I'll push my luck one last time: Considering that some cases bring ambiguity with their usage and we want to preserve (rightly so) their real-world usage without setting up standards that would diminish their complexity, wouldn't it be better if we had some ways to clear that ambiguity? For example (a very, very crude one) with extra parameters that actually explained if the hyphen meant a range or a chapter like |range=yes or |hyphen=range. - Klein Muçi (talk) 22:39, 29 June 2022 (UTC)[reply]

cs1|2 has too damn many parameters already. For the most part, cs1|2 can figure out what is meant and does the right thing:

((cite book |title=Title |page=12-34)) → Title. p. 12-34. ← page is hyphenated

((cite book |title=Title |pages=12-34)) → Title. pp. 12–34. ← pages is an ndash-separated range

((cite book |title=Title |pages=12-34-12-40)) → Title. pp. 12-34–12-40. ← pages is an ndash-separated range of hyphenated pages

I'm not going to try to dream up something that is more complex than cs1|2 can do right, but if you encounter something like that, the accept-this-as-written markup ((...)) can be applied to the value assigned to |pages= so that cs1|2 will render that value exactly as written.

—Trappist the monk (talk) 22:53, 29 June 2022 (UTC)[reply]

The too-many-parameters thing was worrying even to me when I suggested that. Okay then, that explains it I guess. Thank you for the time! - Klein Muçi (talk) 02:32, 30 June 2022 (UTC)[reply]

Would I need to do any changes to local patterns_date in Module:Footnotes if I imported it to SqWiki? - Klein Muçi (talk) 18:39, 29 June 2022 (UTC)[reply]

No.

—Trappist the monk (talk) 20:01, 29 June 2022 (UTC)[reply]

An automated process has detected that when you recently edited Aegae (Achaea), you added a link pointing to the disambiguation page Pausanias.

(Opt-out instructions.) --DPL bot (talk) 19:50, 2 July 2022 (UTC)[reply]

Hello!

I'm doing a periodic update. I've yet to update the configuration page but I do see there have been some rather major changes in the main page. I don't believe I'll need to change anything there, no? Any values? Any translations? Maybe you can give me a general idea what they serve for?

I'm also guessing I'll still need to do this edit even though some things have changed in regard to dates in the config. page, no? - Klein Muçi (talk) 02:41, 6 July 2022 (UTC)[reply]

Help talk:Citation Style 1#Update the module. Any changes that you make to the module suite that are unique to sq.wiki will need to be retained.

—Trappist the monk (talk) 10:53, 6 July 2022 (UTC)[reply]

Thank you!

Some questions given that I finished dealing even with the configuration page now:

1. A user made this edit some days ago which I have a feeling is unneeded but I can't really formulate why. Am I right?
2. Staying on the same topic, many months ago you decided to remove support for languages such as Classical Syriac and Ottoman given that they were unused in articles at that time. I decided to keep them because we collect data about languages in general and our updates are not so dynamic in nature so it's always better to include and future-proof things because you never know when the next update will be (or if there will ever be one on the short future - I'm the only one dealing with it for years now). Keeping that in mind, I don't believe there are other cases like this which I can "future-proof" with code inclusion and category creation, no? This update was a short one so I wanted to dedicate the "spare time" to situations like this. If my question doesn't make much sense, feel free to correct my knowledge on languages.
3. Any new categories that were created during this update? Maybe prop ones? I don't believe there were changes to the existing ones.
4. Can you check my 2 last contributions here on the module's sandboxes that have question marks on the edit summaries and revert them if they're not needed?
5. We've talked about this in the past but I thought I'll give it a try again: Many times when updating the configuration page, what happens from a non-EnWiki POV is that we check for changes that are "non-symmetrical" in the diff page. This can include parts where a lot of text changes in non-symmetrical way, new paragraphs/sections are introduced/removed or a lot of space is colored (added/removed). Most other changes that are symmetrical in nature are ignored because they generally are showcasing only that a translation has happened, which is what you want to achieve. After many iterations, when I finally achieve a rather symmetric look in the diff page comparing SqWiki with EnWiki I understand I've finished updating the configuration page correctly. Can something be done that actually helps in this direction? Maybe by accentuating these kind of "non-symmetrical" changes? Maybe not by the module/Lua itself by with a user script? The symmetrical changes are basically noise that we need to ignore most of the time. I believe that anything can lower that kind of "noise" would be very helpful to all non-EnWiki projects. I wanted to know your opinion on this. - Klein Muçi (talk) 13:31, 6 July 2022 (UTC)[reply]

Answers

1. You are not right because: ((#language:cnr|sq)) → 'Montenegrin' instead of the Albanian form: 'malazisht' as your user noted.
2. Doesn't make much sense. Yeah, you could add all of the language tags supported by ISO639-3 but not supported by MediaWiki – there are a lot. Most of those languages would never be used so why bother? You might troll through the lists at sq:Stampa:Citation Style documentation/language/doc and fix MediaWiki so that the ((#language:<tag>|sq)) returns the proper Albanian language names. That would seem to me to be more beneficial.
3. Not really new but renamed:
   • CS1 Belarusian (Taraškievica orthography)-language sources (be-tarask)
   • CS1 Belarusian (Taraškievica orthography)-language sources (be-x-old)‎
   • CS1 Hungarian (formal address)-language sources (hu-formal)‎
   • CS1 Brazilian Portuguese-language sources (pt-br)
   • CS1 European Portuguese-language sources (pt-pt)‎
   • CS1 davvisámegiella (Ruoŧa bealde)-language sources (se-se)‎ (phabricator: T311933)
   • CS1 Tajik (Cyrillic script)-language sources (tg-cyrl)
   • CS1 Uzbek (Cyrillic script)-language sources (uz-cyrl)‎
   • CS1 Classical Chinese-language sources (zh-classical)‎
   • CS1 Chinese (China)-language sources (zh-cn)‎
   • CS1 Simplified Chinese-language sources (zh-hans)
   • CS1 Traditional Chinese-language sources (zh-hant)
   • CS1 Chinese (Hong Kong)-language sources (zh-hk)
   • CS1 Chinese (Macau)-language sources (zh-mo)
   • CS1 Chinese (Malaysia)-language sources (zh-my)‎
   • CS1 Chinese (Singapore)-language sources (zh-sg)
   • CS1 Chinese (Taiwan)-language sources (zh-tw)
   • CS1 Cantonese-language sources (zh-yue)‎
4. ok
5. I don't have an answer for that.

—Trappist the monk (talk) 15:28, 6 July 2022 (UTC)[reply]

Okay so I'm supposing I should also add the language name remap for cnr then, no? As for the other languages, your suggestion makes a lot more sense and I'm thinking I should go and remove those languages and their categories now. I am surprised though that there are no sources in Ottoman. In my part of Europe our archives are dominated by Ottoman-era documents and artifacts. How come EnWiki doesn't have any sources in that for any kind of article, even for articles of the Ottoman Empire itself? Maybe they are listed as another language or the language is not listed at all? Your suggestion does present a problem though: If my knowledge is correct, MediaWiki automatically gets the data for languages from Unicode CLDR and from what I can get from here, U-CLDR is open for contributions only on specific times of the year. The website appears a bit hard to navigate for a first timer (as me), being more bureaucratic in nature when compared with Wikipedia and thus making the volunteering process harder (also it is apparently already on a migration). Long story short: I'd love to help but I'm not sure how. If you are more informed than me on this subject, I'd appreciate your help.

Did the aforementioned categories exist priorly? I'm getting kinda confused because I remember connecting them on Wikidata with the Albanian versions but they're not connected to any language now. But, for example, this exists in Albanian so...

I wonder how much sense would make a request for a "symmetrical-diff-noise-reducing user script" for the gents at WP:US/R. I'm not sure if the problem I explained above to you could be explained in a shorter and more straightforward way for people who may not be aware of such situations. - Klein Muçi (talk) 17:20, 6 July 2022 (UTC)[reply]

Yes, remap 'malazisht'.

This search finds 10 articles at en.wiki that are purportedly written in Ottoman Turkish. What we don't have, apparently, is |script-title=ota:... though we did at one time else I would not have created the category and added ota to script_lang_codes (line 988).

The list of categories above did exist at en.wiki except that the parenthetical language tag was just the language subtag and not the whole IETF-like tag:

CS1 Belarusian (Taraškievica orthography)-language sources (be) instead of CS1 Belarusian (Taraškievica orthography)-language sources (be-tarask)

I was not thinking about fixing CLDR but instead, I was thinking about tweaking MediaWiki's implementation of CLDR. That has been done before, see T256649 (incomplete and still open... so may never be completed without someone to champion the cause – not me).

Have you tried using Special:Preferences#mw-prefsection-gadgets → Editing → wikEdDiff? You may have to make your comparisons here since that is not an option at sq.wiki.

—Trappist the monk (talk) 18:06, 6 July 2022 (UTC)[reply]

So... I'm confused... We should keep those languages? We should remove them from script_lang_codes?

I understand. I will redo the WikiData connections then.

I see. The task you mention looks a bit too much for me currently though.

I haven't. I'll try it and maybe import that as a gadget to SqWiki if it's helpful.

Question: I happened to use ((Reflist-talk)) on a talk page with a reference that had errors and I was surprised to see that the talk page got categorized together with other pages that have citation errors, same as main pages would behave. Is that intended? - Klein Muçi (talk) 23:04, 6 July 2022 (UTC)[reply]