User talk:CalendulaAsteraceae

An addition to WD version

If it were still a simple template, I might be trying to add an "if P2679" (author of forward) to it for a {{WD forward}}. So, I took a look at the module. Truly, it was easier to behold, without the {{{{{{{{|}}things}}}}}}}}}}}}}} }} in it, but I am hesitant to mess with it. I think just:

	version_info.forward = p.WDStatement({
		['item'] = item,
		['prop'] = 'P2679',
		['prefix'] = ', forward by ',
		['getLink'] = true
	})

And probably a request to another module somewhere.... So, eh, could you?--RaboKarbakian (talk) 11:52, 22 March 2024 (UTC)

Outside R/L

These do not always work well with Dynamic layouts. If you can make them work with Dynamic layouts so much the better. See also {{MarginNote}}, {{margin block}}, {{numbered div}} etc.. If you've already started on a consolidation,there is sense in doing a whole scale overhaul of all of these.. :) ShakespeareFan00 (talk) 08:12, 15 April 2024 (UTC)

Page:Provisional_Collection_of_Taxes_Act_1968_(UKPGA_1968-2_qp).pdf/5 - Here Outside L/R might need a manual shift adjustment( The template doesn't take into account that the margin on a list/indetation might have been tweaked, hence one of the sidenotes that is a reference to another act isn't flush with the left/right hand side respectively. ShakespeareFan00 (talk) 08:32, 15 April 2024 (UTC)

Ideally Outside(L/R) etc , and left/right sidenote should all do the same thing! Outside L/R however have the ability due to being floated to have clear(left/right) setup (to avoid overlaps) as opposed to left/right sidenotes that are absolute positioned. This may need a MASSIVE (and possibly breaking change) overhaul.

(Aside: I will continue with rh migration when I have time.)

ShakespeareFan00 (talk) 08:32, 15 April 2024 (UTC)

A minor "linter"- https://petscan.wmflabs.org/?psid=28031835 This tracks Mostly mainspace pages where there is both an Outside L and Outside R. With the exception of the legislation in the query, other items should be made consistent in Mainspace(on transcusion0 bu using the RL or LR variants appropriately for the works concerned. ( Fixes required are an afternoon's effort at most.) ShakespeareFan00 (talk) 09:43, 15 April 2024 (UTC)

Outside R/L and other templates..

Would it be possible to make Template:Outside/styles.css aware of dynamic layouts? (such as those in MediaWiki:Gadget-PageNumbers-core.css Thanks. ShakespeareFan00 (talk) 11:40, 20 April 2024 (UTC)

There may be other templates that do "clever" layout tricks that should also be examined with a view to having ALL templates that need to be aware of the 'dyanmic' layout behaviour updated. (including the various approaches used for sidenotes/Outside/overfloats etc..)

The need for consolidation to one common schema is obvious :). ShakespeareFan00 (talk) 11:40, 20 April 2024 (UTC)

The_Economics_of_Climate_Change:_a_Primer

This was showing up as having paired missing/stripped tags , and the only reason seems to be that a DIV in a list, confuses the linter. Not sure how to solve this, so can you take a look?
ShakespeareFan00 (talk) 08:20, 12 July 2024 (UTC)

Template:Math

Can you take a look into the continued need for this? it is seemingly in use on some specific works, I thought Wikiosurce used <math></math>? ShakespeareFan00 (talk) 17:38, 30 July 2024 (UTC)

I agree that math tags are a better way to go. The template has 205 transclusions in pagespace (and 248 uses total), so transitioning would take a little time but should be perfectly doable. —CalendulaAsteraceae (talk • contribs) 16:59, 2 August 2024 (UTC)

Wide left-hand pline numbers -- testcase and possible fix?

I noticed that the line numbers in a version of Beowulf were overlapping with the poem's text. I am a longstanding Wikipedia editor, a somewhat experienced Wikisource editor, but I have never tried to update a template before, and I have minimal expertise with CSS. I thought I might try this in the sandbox.

I found the pline testcases that you made here Template:Pline/testcases, and added a test case for wide numbers, copied directly from Page:Gummere_(1909)_The_Oldest_English_Epic.djvu/107. When rendered, it showed overlapping numbers and poem text, the same as what occurred in the original Beowulf page.

Then I edited the CSS in the pline sandbox here Template:Pline/sandbox/styles.css, and saved the sandbox CSS template. I switched from -3em to -5em in the left margin, and also adjusted the corresponding width.

This did seem to fix the overlap of numbers in rendering the testcase page, while not messing up the rendering of shorter numbers. But, confusing me, the testcase rendering is now fixed (non overlapping) for what it claims is both the ordinary pline template version (which I didn't change), and the sandbox pline template version. I do not understand why. I am presuming that this is a bug in the test case.

I have verified that in the original Beowulf page, the page is still rendering with overlapping numbers and text, even after purging its cache, so I don't think that I have managed to inadvertently change a globally used template (just a sandbox version).

Since you seem to be intimitely familiar with this template, I thought I should ask you to review my work, revise it however you please, and consider making a similar change to the master pline template.

Thank you for your contributions to Wikisource! -- Gnuish (talk) 17:58, 11 August 2024 (UTC)

Just wanted to note that I've seen this, appreciate your efforts, and will review the code when I have time! —CalendulaAsteraceae (talk • contribs) 16:46, 14 August 2024 (UTC)

(One thing I haven't tested is whether the modified pline in the sandbox works well for WIDER texts (with narrow numbering), perhaps one where the long lines of poetry are actually being line-wrapped onto multiple lines by the HTML renderer, since I don't have such a poem readily to hand.) Gnuish (talk) 21:55, 6 September 2024 (UTC)

Dates of Shakespeare plays

I see you're setting some of these based on date of first performance but others on date of first publication, and possibly some with date of first written. --EncycloPetey (talk) 22:53, 30 August 2024 (UTC)

On a related note, I think it's more useful to categorize our plays by decade than by individual year. We seldom have two plays from the same year, so we're effectively creating a separate category for each play, and no means for people to easily find plays that are roughly contemporaneous other that visiting each year's category. Could we double list by both year and decade? --EncycloPetey (talk) 22:58, 30 August 2024 (UTC)

I'm happy to defer to you on the question of what year to use for play categorization, and double-listing plays with year and decade sounds fine to me. —CalendulaAsteraceae (talk • contribs) 23:43, 30 August 2024 (UTC)

At least for older plays, it's often better to use date of first performance, because we are more likely to know that and it's more representative of the play. Consider, for example, that the plays of ancient Greece were first "published" centuries after being written. But I want to think over the implications first. For 20th-century plays, for example, the play often premiered a year before being published, and that can have copyright implications.

As for double categorization, I think it will be more useful to our readers. If it's handled automatically, then we have the option at a future date to undo that, if we so choose. But in the past 15 years, we've not exactly had a wealth of dramatic works added to the project. --EncycloPetey (talk) 23:57, 30 August 2024 (UTC)

I also notice that for some plays, like Abraham (Roswitha, Lambert 1922), you have removed Category:Plays without placing it into any subcategories. All plays should at minimum be classified by form. --EncycloPetey (talk) 00:35, 31 August 2024 (UTC)

IMO works which have several versions should have categories which apply to all versions placed on the versions page, e.g. Abraham (Hrotsvitha). —CalendulaAsteraceae (talk • contribs) 00:39, 31 August 2024 (UTC)

That's an opinion I disagree with, for multiple reasons. For one, it leaves many of our transcribed works without categorization by form or genre. --EncycloPetey (talk) 00:42, 31 August 2024 (UTC)

So, if you're browsing Category:Elizabethan drama, you prefer to see every version of every Shakespeare play that we have? —CalendulaAsteraceae (talk • contribs) 00:51, 31 August 2024 (UTC)

Yes. Same for Greek tragedy, where I want to see the translations. And for Category:Plays, I want to see all the Plays, which is what we've been doing with base-level form categorization since I started here. You've unilaterally enacted a change to that without discussion. --EncycloPetey (talk) 00:53, 31 August 2024 (UTC)

OK. I find your preferences baffling, but that doesn't mean you're wrong, so I will take a step back, do some research, and consider next steps once I have a better understanding of common practice and how people want to use categories. —CalendulaAsteraceae (talk • contribs) 00:59, 31 August 2024 (UTC)

Looks like there are two issues here.

1. The first issue is the question of what is a work that needs to be categorized. Help:Categorization has a straightforward answer: "The base page of every work in the main namespace should be placed in the basic categories which are outlined below." I find this actively detrimental to my browsing experience when works have multiple versions, but apparently some people like it, and in any case the policy is clear. I'll put a pin in this one until I have the bandwidth for a full-on policy discussion.
2. The second issue is the question of which categories are diffusing categories. I don't suppose we have an equivalent of Wikipedia:Categorization § Subcategorization which outlines the relevant principles?

—CalendulaAsteraceae (talk • contribs) 01:22, 31 August 2024 (UTC)

I think it is almost certainly time to reexamine our categorization practices and policy, and change it where needed, but if nothing else it would raise community awareness of the category system. For my own part I have mostly ignored it entirely (apart from technical categories), as, I suspect, many do. But our improved ability to automatically categorize some things combined with the recent inactivity of one of our most active manual categorizers probably changes some tradeoffs that it would be good to explore. Xover (talk) 06:25, 31 August 2024 (UTC)

Sadly, no. AFAIK we have never laid out clear guidelines in written form for categorization. There is a lot of oral history. The root cause of most of our differences from Wikipedia categorization is that our system was developed to mimic what library catalogs such as the Library of Congress and Sears List of Subject Headings do, rather than classify articles into a nested hierarchy in the way a taxonomist would. And we have never had a separation of work classification from edition classification, just as the LoC does not. What the LoC does is tags individual items as Work or Instance, and that's displayed when you receive your search returns. --EncycloPetey (talk) 21:09, 10 September 2024 (UTC)

Some of what you're doing is a fundamental change to the way categorization at Wikisource has been done for more than a decade, and should be discussed before being implemented, as it is a major change to the way we've been doing things. Removing works from their base form categorization, in favor of date-form categorization is contrary to what I was taught when I started here. --EncycloPetey (talk) 00:51, 31 August 2024 (UTC)

Duplicate ID's

Can you take a look into some of the big templates that are creating them, like Module:Author which is causing most Author pages to appear in the listings?.

Also any Transcluded work that has pages with the same id (such as "img" or "–" used for blank or un-numbered pages..) is appearing. Would it be possible to adjust the underlying Page number script to "force" a unique identifier for <pages> by appending the DJVUpage in the id? I.e you get "pagelistid$dvu-pageid" used instead of the current "pagelistid" anchors used. Whilst this will not solve all the Duplicate ID's it should reduce the 'noise' considerably... ?

Yes it would mean some links might have to be updated. But that would be less work than sifting therough the noise.. ShakespeareFan00 (talk) 19:12, 27 September 2024 (UTC)

I've fixed Module:Author and a couple of other templates. I don't know of a good way to fix the issue automatically, but the duplicate IDs through {{pline}} and {{numbered para}} can be fixed by manually editing the ID.

Every page number already has an ID of the form "pageindex_filepagenum". The easy fix for duplicate IDs, which I could implement, would simply be to remove the outer ID that's just the page number display from MediaWiki:Proofreadpage pagenum template. However, as you note, this would require a lot of work looking for and updating links that use the old anchor system, and for that reason would also require more community discussion ahead of time.

The more elegant solution for duplicate page number IDs would be to add an ID parameter to the MW template, so that the ID could be specified separately from the page number, and then add the file page to the display page number only when necessary for disambiguation. This would have fewer backwards-compatibility problems, since there are going to be far fewer links anchoring on pages with non-unique names like "img". Getting this to work would require a deeper dive into the workings of the Proofread Page extension, and possibly a bug report, but I do think it would be a better result, so I'll look into the issue. —CalendulaAsteraceae (talk • contribs) 06:31, 28 September 2024 (UTC)

An alternate (such as here [[1]] ) would be to use 'pagename_sectionname" as all relevant information is present in the pages tag.
Can you possibly do a mock up of what a Pages tags and page /Section/Lst magics do in Lua to allow for testing of new functionality like this) ( A Lua Module:PageCollate would also be useufl for things like building TOC on Index: pages where a Pages tag cannot currently be used)
ShakespeareFan00 (talk) 15:55, 28 September 2024 (UTC)

Giving the Proofread Page page generated page numbers (Pagenumber.JS as well as the extension IIRC) unique identifirer might also make it much easier to link to specific images or un-numbered pages in transclusions I think. ShakespeareFan00 (talk) 06:55, 28 September 2024 (UTC)

To be clear, the Proofread Page extension already lets you link by the file page numbers—for example, Frank Leslie's Lady's Magazine/Volume 25/Number 3/My Mysterious Mademoiselle#182 and Frank Leslie's Lady's Magazine/Volume 25/Number 3/My Mysterious Mademoiselle#pageindex_156 point to the same place. —CalendulaAsteraceae (talk • contribs) 06:59, 28 September 2024 (UTC)

:Template:Note

Can you convert {{ref}} and {{note}} over to a module and implement {{note-multi}}? I'm seeing a few instances in the duplicate ID's that would be helped by having a single note that can refer bck to multiple refs. ShakespeareFan00 (talk) 12:27, 29 September 2024 (UTC)

Could you link these instances so I know what we're dealing with? —CalendulaAsteraceae (talk • contribs) 03:31, 30 September 2024 (UTC)

Page:The Czechoslovak Review, vol3, 1919.djvu/171 Shared ref inside a table is one. ShakespeareFan00 (talk) 08:15, 30 September 2024 (UTC)

Thank you! Done. —CalendulaAsteraceae (talk • contribs) 19:42, 2 October 2024 (UTC)

cesura

I was reminder yesterday that {{cesura}} exists, and this template has not had its syntax updated in ages. It is a bit like {{gap}}, but is desinged for a very specific situation that occurs in formatting Old English poetry, two create a set-width gap in the middle of a poetic line.

The current syntax is very fussy, and the gap it creates depends upon the font style where it's used. See for example Beowulf (Wyatt)/Beowulf 34, where the gap is the correct size inside the font block, but if you copy the text to a Sandbox and remove the font block, the gap shrinks to almost nothing.

Do you think you could update the template so that (a) it is more consistent, and perhaps CSS customizable, so that if it isn't creating a gap of the correct width, a style applied to the work would correct the issue? --EncycloPetey (talk) 17:42, 2 October 2024 (UTC)

I'm happy to work on making this template more consistent and CSS customizable! Could you elaborate on what you mean about the syntax being fussy? It seems pretty straightforward to me. —CalendulaAsteraceae (talk • contribs) 18:43, 2 October 2024 (UTC)

The size gap it produces is highly variable, depending on the surrounding syntax. If you test what I suggested, it should demonstrate the problem, though it might also be slightly browser dependent as well. One serious limitation is that, on works where this is used, it will be use a lot, once per line for the entire work. So it can push the limits on the number of template calls if it's too complex. --EncycloPetey (talk) 19:14, 2 October 2024 (UTC)

Sounds like I made a good call in not adding a width parameter to the template, then. —CalendulaAsteraceae (talk • contribs) 19:26, 2 October 2024 (UTC)

Notes again..

Note 17 here-
Page:Principles_for_creating_a_single_authoritative_list_of_the_world’s_species.pdf/1
I've put the common ref as ref0-display, but the general idea is that it should display like wikipedia footnotes do, number followed by a,b etc..

Can you tweak the module to handle this more cleanly?
ShakespeareFan00 (talk) 22:27, 2 October 2024 (UTC)

Can I ask why you're not just using normal footnotes? —CalendulaAsteraceae (talk • contribs) 05:31, 3 October 2024 (UTC)

That is indeed a fair consideration. If you feel they should be converted feel free. ShakespeareFan00 (talk) 08:23, 3 October 2024 (UTC)

Links in links..

Special:LintErrors/wikilink-in-extlink

All seem to be in a single page, and apparently caused by a missing {{LangSwtich}} template here on English Wikisource. ShakespeareFan00 (talk) 08:27, 3 October 2024 (UTC)

@import

SF suggested I ask you this. I am just going to paste it:

<paste>All that chat recently about a shared stylesheet among the same project, I have been thinking about @import, which would allow adding to the stylesheet for individual indices (Index:'s).</paste>

So, in a bunch of volumes, there would be a style sheet at Index:Volume One.djvu/styles.css (or somewhere else, even) and this would be used via @import by the next volumes, which would allow for additional style per volume.

Really, the question is: if wikimedia allows @import?--RaboKarbakian (talk) 10:10, 3 October 2024 (UTC)

I just tried adding @import url("https://en.wikisource.org/wiki/Index:The_Black_Moth.pdf/styles.css"); to a stylesheet, and it didn't work, so looks like the answer is no. (Given the security issues, it makes sense.) If you want all volumes to have the same stylesheet, you can ask at WS:AN for the other volumes' index pages to be created as redirects, but if you want some shared styles and some volume-specific styles, I'm not sure there's a good solution available. —CalendulaAsteraceae (talk • contribs) 15:45, 3 October 2024 (UTC)

Here is something else that doesn't work @import url([[Index:Arabian Nights Entertainments (1728)/styles.css]]). Pity. Thanks for looking into it!--RaboKarbakian (talk) 21:01, 3 October 2024 (UTC)

I have been thinking about this: Index:Arabian Nights Entertainments (1728)-Vol. 6.djvu/styles.css, that also failed. Apparently the wiki really respects those c++ comments in .css namespaces.--RaboKarbakian (talk) 11:55, 2 December 2024 (UTC)

Wrong content model; I think I've taken care of this one now. —CalendulaAsteraceae (talk • contribs) 03:46, 3 December 2024 (UTC)

Template:Paragraph number

I see you added an ID parameter to the template. I was thinking of making the added parameter some sort of prefix instead (after all, if you just wanted the ID you would use {{anchor+}} directly), what do you think? Arcorann (talk) 23:17, 6 October 2024 (UTC)

As long as you handle backwards-compatibility/checking old uses, I'm fine with whatever you want to do here! —CalendulaAsteraceae (talk • contribs) 20:32, 7 October 2024 (UTC)

I've written a few notes on the template talk page, would like your thoughts. Arcorann (talk) 23:28, 7 October 2024 (UTC)

Category:Works originally in Czech

Hello. I think that it is quite redundant categorise works into Category:Works originally in Czech if they are already in one of its subcategories, such as Category:Czech short stories or others. See e.g. The Vampire (Neruda). -- Jan Kameníček (talk) 21:44, 10 October 2024 (UTC)

Fixed! —CalendulaAsteraceae (talk • contribs) 04:32, 12 October 2024 (UTC)

You used the nolanguagecat parameter which solved the problem in the previously mentioned case, could you do it in other cases as well, please? Example here, but I noticed more. --Jan Kameníček (talk) 07:19, 5 November 2024 (UTC)

In fact there was only one more, so I have already fixed them both. --Jan Kameníček (talk) 07:31, 5 November 2024 (UTC)

Sidenotes -

https://en.wikisource.org/wiki/The_Statutes_at_Large_(Ruffhead)/Volume_1/Crown_Debts_Act_1275
Can you make the sidenotes not overlap, without having to migrate too many templates? ShakespeareFan00 (talk) 08:28, 15 October 2024 (UTC)

Template:Uksi/paragraph

This template is broken.. and it's to do with the whitespace handling.. I'm giving serious consideration to just deleting the whole thing and asking someone else to "start again" because it seems to be very tiresome to get it to be 'whitespace neutral' in any consistent manner. ShakespeareFan00 (talk) 13:15, 15 October 2024 (UTC)

Linter tracked syntax concerns...

Any chance you could take a look at clearing the remaining high priority Lints (with the exception of the duplicate ID's which is going to need a lot more investigation)? The bulk of the remaining edits seems to be Tidy Font bug in User Talk pages, and it's not's possible for a normal user to make corrective edits to those. {@Zinnober9: seemed to have cleared a lot of them, until I asked them to stop, as the edits had became contentious for some users. ShakespeareFan00 (talk) 10:10, 18 October 2024 (UTC)

They aren't as high prority as Content namespace issues though, and through my efforts earlier in the year, most of Content (i.e Page:) lints are either unpaired formatting , or in respect of specfic work (which I was 'advised' not to attempt repairs on) unterminated <P> tags. ShakespeareFan00 (talk) 10:10, 18 October 2024 (UTC)

Portal parameters

Hello. What is the advantage of this? Jan Kameníček (talk) 14:12, 2 November 2024 (UTC)

Not a major difference. Makes it easier to read IMO, which is why I bothered to switch to numbered parameters as long as I was adding a portal anyway. In the long run, I'd like to stop splitting portals at the slashes, so it's not a whole production with / to link to portal subpages, but that would require a lot of migration work, so I'm not pushing for it anytime soon. —CalendulaAsteraceae (talk • contribs) 11:46, 3 November 2024 (UTC)

As this is influencing a really large number of pages, it should have been definitely discussed first. I have started a discussion at WS:Scriptorium#Portals in headers. --Jan Kameníček (talk) 12:02, 3 November 2024 (UTC)

Running headers

I cleaned out (barring test case, and talk page examples) cleaned out the vast majority of named parameter inovactions. Can we take another look at how rh/1 etc are being dealt with?

Deprecating {{leafsig}} back into a modified rh would be advantageous. ShakespeareFan00 (talk) 01:32, 6 November 2024 (UTC)

Thank you very much! I'm a bit busy at the moment, but will definitely come back to this when I have time. —CalendulaAsteraceae (talk • contribs) 06:10, 9 November 2024 (UTC)

Minor lint..

https://en.wikisource.org/w/index.php?title=Template_talk:PD-Canada&action=edit&lintid=2029229

Any chance you could look over this and any other lints you find? The aim is to try and reduce the counts outside Page: namespace to a close to zero as possible. Some might not be fixable. ShakespeareFan00 (talk) 13:12, 8 November 2024 (UTC)

Theodore Christian Ernest Laugesen

If you think he deserves a Wikipedia entry, but worried it will be rejected, you can write a full Wikipedia style biography at Familypedia. It is part of Fandom, which is the for-profit version of Wikipedia started by Jimbo Wales. You can work on it there and link to it in Wikidata. You can always migrate it over when it is complete. Fewer biographies get rejected if they are complete when first seen at Wikipedia. RAN (talk) 18:22, 12 November 2024 (UTC)

Page:Clarissa, Volume 2.pdf/385

This page, created by you, is not linked from the related index - possibly due to changes there. Can I put it for speedy delete ? -- Beardo (talk) 22:28, 11 December 2024 (UTC)

• It was because of this edit. TE(æ)A,ea. (talk) 22:38, 11 December 2024 (UTC)

Yep, go ahead! Looks like the file was changed so it now only has 384 pages, and since there's no meaningful content that might need to be moved to the new page, speedy deletion is 100% appropriate. ( Done) —CalendulaAsteraceae (talk • contribs) 23:23, 11 December 2024 (UTC)

Template:FIS-c

You deprecated this. float:center isn't proper CSS, and so won't actually do anything. ShakespeareFan00 (talk) 23:33, 1 January 2025 (UTC)

Good point, thank you! —CalendulaAsteraceae (talk • contribs) 03:57, 2 January 2025 (UTC)

I think before reimplementing the template's functionality, I'd want to see some proposed use cases, both so I'd know how to do it and so I could avoid putting effort into something there's no real demand for. You don't have to provide them if you don't have any, but I wanted to explain my thinking here. —CalendulaAsteraceae (talk • contribs) 08:26, 3 January 2025 (UTC)

Module:Lang

Hello. I have reverted the last change to the module:lang, because it caused the text wrapped in the {{lang}} template to be moved one line lower. It was happening e. g. at Page:East_European_Quarterly,_vol15,_no1.pdf/71. After the revert everything works well again. -- Jan Kameníček (talk) 08:26, 8 January 2025 (UTC)

Good catch, and sorry! —CalendulaAsteraceae (talk • contribs) 20:22, 8 January 2025 (UTC)

Something broke: https://en.wikisource.org/wiki/Special:LintErrors/stripped-tag?wpNamespaceRestrictions=104&titlecategorysearch=&exactmatch=1&tag=all&template=all

Every page using an /e block is showing up with stripped tags. Can we go back to a STABLE version please? ShakespeareFan00 (talk) 20:57, 8 January 2025 (UTC)

OK, I've fixed that issue, and the test cases page doesn't throw any lint errors. Anything else you'd like me to test for? —CalendulaAsteraceae (talk • contribs) 05:42, 9 January 2025 (UTC)

That seems to have cleared, thanks. BTW If you can come up with a way to reduce the Duplicate ID problem still further. Based on where I'd got to in 'Missing tags' whose count seems to track also the Duplicate ID count, there are betweeen 20 and 40 thousand pages to be resolved. Most appear to be relatively straightforward changes to template invocations. THat said the vast majority of Duplicate ID's issues in Mainspace seem to be from Proofread Page, which I can't solve directly. ShakespeareFan00 (talk) 08:39, 9 January 2025 (UTC)

Yeah, the Proofread Page issue is tricky, since we want to be able to anchor on pages given only the display number, but there isn't good handling for works with repeated display numbers. I'll think on this, and possibly also look at the non-PRP results. —CalendulaAsteraceae (talk • contribs) 09:21, 9 January 2025 (UTC)

Recent Changes text

The change you made now gives me a vertical list in full-sized text when I go to Recent Changes. However, when I look at the version in MediaWiki: it looks the way that it used to. Thus, I'm not sure what's happening when RC pulls the text in. Beeswaxcandle (talk) 18:50, 11 January 2025 (UTC)

Templatestyles only works inside .mw-parser-output, and on the message's page it is wrapped in that, but not at RC itself. (See MediaWiki talk:Recentchangestext) — Alien  3
3 3 19:09, 11 January 2025 (UTC)

Oof, good catch >.> Does this also apply to templates that use templatestyles? And is there a better way to test this kind of thing than just trying things and causing problems? —CalendulaAsteraceae (talk • contribs) 05:43, 12 January 2025 (UTC)

Well, to system messages that use templatestyles, as parser output is nearly always in .mw-parser-output. I'm not aware of a way to test. Templatestyles is good, but it has other issues, e.g. for some reason it doesn't work inside links: the styles tag does not get added if it's in a link display, but if you readd manually the templatestyles outside of the link, it works. Xover might be able to tell you more about that, I only know what it does, not why. — Alien  3
3 3 08:21, 12 January 2025 (UTC)

Yeah, TemplateStyles being broken inside links is really annoying. It's an effect of how they chose to implement it. They spit it out at the point of use instead of hoisting it up and spitting everything out in the HTML head, which means the special processing for wikilinks ends up hiding the style tags behind strip markers). They could fix it relatively easily, but they're afraid of that breaking other things. It's also really hard to change stuff in the parser because we're running two parsers right now (one old regex-based parser written in PHP, and one "new" parser written in JavaScript / Node.js) both of which need to stay bug-compatible with eachother, and both need to preserve 20+ years of bad wikimarkup design and applied quirks that the projects depend on. And with the new Visual Editor (that does not look like it'll support Wikisource in the foreseeable future, but still must be supported by parser changes). It's a mess.

Trouble with TemplateStyles in system messages is another consequence of the design choices for TemplateStyles, but this one is mercifully much easier to work around in most cases: just wrap the whole thing manually in <div class="mw-parser-output">…</div>. Xover (talk) 14:53, 12 January 2025 (UTC)

Oof. Well, I now have several additional complaints, but thank you for sharing a solution! —CalendulaAsteraceae (talk • contribs) 22:04, 12 January 2025 (UTC)

Long s descending

Hi, I'm seeing your replacement of {{S|2}} with {{ls}} in Proposals for the Speedy Settlement of the Waste and Unappropriated Lands on the Western Frontiers of the State of New-York. In general, I have no issues with replacing {{s}} with {{ls}}, but in the instances where {{s|2}} was being used it's to match the usage in the text. In a few cases the descender is there because of italics, but in others it representing shillings. I see mention of migrating {{s}} to {{ls}}, but the later doesn't support specifying the long s with descender character (and {{esh}} states that it should not be used for cases like this). Is there a better way to handle these instances where the scan supports using ʃ over ſ? @ShakespeareFan00: too since they're making similar migration from {{s}} to {{ls}} in the book. —Tcr25 (talk) 18:30, 14 January 2025 (UTC)

FWIW, the italicized long s with descender, when used for shillings, is still just an italicized long s. (See for example The Dancing Master, which uses an italicized regular s for shillings. This is pretty common.)

I have yet to encounter any cases where the long s with descender is used other than as the italicized form of the long s. The only other use of ʃ that I've seen is in EB1911 "Number", where it's not a long s at all. —CalendulaAsteraceae (talk • contribs) 18:48, 14 January 2025 (UTC)

It's an italicized long s, but ſ doesn't display as ʃ, which is a distinction in the original scan. Is there a reason to prefer {{ls}} over {{s}} in this instance when the later is providing a character that the former isn't? I see discussion of merging the two templates, but nothing on the template pages that actually depreciates the use of {{s}}. —Tcr25 (talk) 19:00, 14 January 2025 (UTC)

Yes, the reason is that ſ is officially, and generally recognized as, a variant of the lowercase S. By contrast, ʃ is simply a character that looks a lot like a long S. This matters for document searches and speech-to-text, among other reasons. It's the same reason we write blackletter text like this and not 𝔩𝔦𝔨𝔢 𝔱𝔥𝔦𝔰.

The other reason is that descending versus non-descending long s is essentially a font detail, and per Help:Fonts#Editing Wikisource this is not the level of font detail we replicate. —CalendulaAsteraceae (talk • contribs) 19:09, 14 January 2025 (UTC)

Fair enough. It would probably be helpful to officially depreciate {{s}} or at least note somewhere that its use for s is not preferred. —Tcr25 (talk) 19:12, 14 January 2025 (UTC)

Now that most existing uses have been replaced, and I've reviewed the remaining ones, I think the best thing to is just redirect {{s}} to {{long s}}. (Fun fact, {{ſ}} is equivalent to {{S}} and {{s}} as far as MediaWiki's concerned.) —CalendulaAsteraceae (talk • contribs) 20:18, 14 January 2025 (UTC)

BTW, if you ever do come across a text where ʃ is used, you can insert it with {{esh}}. —CalendulaAsteraceae (talk • contribs) 20:21, 14 January 2025 (UTC)

Thanks! —Tcr25 (talk) 20:35, 14 January 2025 (UTC)

Help needed from kowikisource

Hello, I am writing because I am facing an issue while migrating the Module:License on kowikisource. (ko:Module:License) When using the license template in the main namespace, the template automatically moves to the bottom of the page (which is okay), but the same time the CSS style is not applied like this case. The issue does not occur in other namespaces. ("Wikisource" namespace) I have no idea what the problem might be. Thanks in advance. --Namoroka (talk) 09:38, 19 January 2025 (UTC)

Hmm, it looks like the templatestyles tag wasn't being included in mainspace? Switching to extensionTag seems to have fixed that, FWIW. —CalendulaAsteraceae (talk • contribs) 23:08, 19 January 2025 (UTC)

I am still experiencing the same issue as before. Could you check again, plz? I tried disabling all gadgets and changing the skin or web browser, but the issue remained the same. It seems that the issue might be due to an external factor rather than the module itself. (Maybe Common.js? Do I have to remove "Force Footer &/or end matter out of Dynamic Layouts"?). Same issue also occurs on paswikisource (Common.js), while mswikisource (Common.js) is okay.--Namoroka (talk) 00:13, 20 January 2025 (UTC)

I think, from looking at the HTML, that the JS that moves the footer outside of dynamic layouts moves it out of any .mw-parser-output; templatestyles only works in .mw-parser-output; you can wrap the template in .mw-parser-output for a temporary fix. — Alien  3
3 3 06:20, 20 January 2025 (UTC)

I thank you all for your help.--Namoroka (talk) 10:22, 20 January 2025 (UTC)

Deprecating ts?

Why are you replacing {{ts}} calls with direct formatting, Making it harder to maintain stuff? ShakespeareFan00 (talk) 00:54, 29 January 2025 (UTC)

Personally I think it makes it easier to maintain stuff, because I can actually understand the CSS without referring to a lookup table. However, I'm not actually planning to deprecate {{ts}}; that sounds like a lot of work, and boring work at that. —CalendulaAsteraceae (talk • contribs) 04:16, 29 January 2025 (UTC)

Module:Proofreadpage index template/styles.css

Can you take a look over this in respect of night mode, there seem to be some background assumptions, and they need to be paired with foreground color choices as well?.ShakespeareFan00 (talk) 11:59, 29 January 2025 (UTC)

Will do! —CalendulaAsteraceae (talk • contribs) 02:14, 30 January 2025 (UTC)

Template:Lst

This had been in good faith migrated to be part of a series of ligature templates. I migrated the intended new redirect/shortcut to {{ls+t}} and reverted, I was going to do the same for {{lsl}}, {{lsh}}, {{lsi}} etc.. but wanted a second view on which direction the standardisation should be before doing so. If {{lst}} is now going to be the ligature template, I can revert my revert. ShakespeareFan00 (talk) 09:13, 31 January 2025 (UTC)

I completely agree that {{lst}} should not do something other than be a wrapper for the parser function {{#lst:...}}; that sounds like a compatibility nightmare. I don't have an opinion on how to standardize the names of the ligature templates—do something sensible, I guess?

I don't think we should be trying to reproduce semantically-meaningless ligatures, really, but I guess it's better to have the template (which just produces {{ls}}t) than to have people trying to type ſt. —CalendulaAsteraceae (talk • contribs) 22:29, 31 January 2025 (UTC)

I went with {{ls+t}}, {{ls+i}}, etc.. BTW if you want to look over the paleographic templates I wrote for the Record Interpreter and other archaic works, feel free.. They do need documenting as well :(. ShakespeareFan00 (talk) 22:57, 31 January 2025 (UTC)

{{Left_block}}

Please CHECK your code, This is missing a closing tag somewhere. Appreciate the intent in rationalising the templates, but SLOW DOWN and check everything. ShakespeareFan00 (talk) 12:07, 23 February 2025 (UTC)

Right block and block right

The merge of the two templates changed the layout of this page:- https://en.wikisource.org/wiki/Page:Dido_and_Aeneas_(1689).pdf/6

I can appreciate what you are trying to do but SLOW down and check usages. The usage of {{right block}} vs {{block right}} were NOT the same in effect. Perhaps you'd care to check for the different usages (where the intent was to float a block instead?) ShakespeareFan00 (talk) 10:00, 25 February 2025 (UTC)

Susequent to the above I renamed right block to {{Floated Right block}} with a view to having {{frb}} as a shortcut.. They are as you found nearly identical apart from one very specific behaviour related to the application of a clear, which given a typical use of putting the floated portion "before" non floated content breaks layouts. I'm not sure how to solve this immediately. Usages of {{right block/s}} and {{right block/e}} were migrated to their {{block right}} versions. We need ONE meaning and ONE name obviously. ShakespeareFan00 (talk) 12:46, 25 February 2025 (UTC)

Template:Greek

Greek text is now displaying in a smaller font size than before, making it very hard to read. --EncycloPetey (talk) 15:30, 25 February 2025 (UTC)

Could you point me to an example? I see no change in my browser or in the CSS. I do find that GentiumPlus is smaller than most sans-serif fonts, FWIW. —CalendulaAsteraceae (talk • contribs) 16:32, 25 February 2025 (UTC)

That may be the issue then. It's occurring everywhere for me. --EncycloPetey (talk) 20:17, 26 February 2025 (UTC)

Index:The collected works of Henrik Ibsen (Volume 12).djvu/styles.css

This page was left orphaned when the parent page was moved without a redirect. Should the styles page also be moved ? -- Beardo (talk) 23:19, 11 March 2025 (UTC)

Module:Proofreadpage index template

Revert your most recent change; it breaks all indexes. TE(æ)A,ea. (talk) 23:25, 11 March 2025 (UTC)

(The issue was fixed by 19:15 UTC, it's only in the cache that stuff is still broken. Purge and it's fine.) — Alien  3
3 3 08:59, 12 March 2025 (UTC)

FreedImg module..

Somwhere there was an experimental {{FIS-c}} to have a {{FIS}} like behaviour but with a centered image like {{FI}}. Can you consider implementing this inside the main {{FIS}} template and related module. Ordinarily, float in Template:TL only permits left or right. Not a centered image, so a 'creative' approach is needed so that 'float=center' would function as intended (It's NOT a simple case of passing values directly to CSS as I recall, as float=center is not valid CSS.) ShakespeareFan00 (talk) 08:49, 13 March 2025 (UTC)

CSS Color

Hi,

If you are looking into retiring using certain colors directly due to dark mode.. I'd appreciate someone looking over my recent efforts to reduced the usage of direct colors with 'border:' entries in inline CSS on Page:'s (In some instances the inline CSS should probabbly be migrated to an Indexstyle.) ShakespeareFan00 (talk) 15:04, 14 March 2025 (UTC)

FreedImg and center

Iirc, a software runs through here converting {{FI}}s that are just centered images into the regular wiki markup. The reason I came up with on my own for this (meaning: there might be another reason but this one I thought of is good enough) is that "center" is not really a "float" option and was put into the template as an option for regular users (those who don't code or css) to use and it will just work.

It is not ideal to run a simple image (one that works already) through a template designed to float images when it does not need to be floated and in fact, can't be floated to where it needs to be.

The other thing I know about centered images is that the Ebook Exporter ignores the simple wiki [[File:Image name.png|center]]. This image will not be centered in exported texts.

God's Man has all it needs in its style. Causing the images to go through a template that is useless for floating to "center" and then to be centered due to the style that is there already is (maybe) a no brainer? That it is not something that should be done.

Do run these ideas through this CalendulaAsteraceae before converting more images too {{FI}} and for sure, check everything that I said here. I am pretty sure that this is right; but I get plenty of things wrong.--RaboKarbakian (talk) 15:24, 14 March 2025 (UTC)

Module:Template test case

I don't know why this was changed but a previously working template is now throwing lints. (see- https://en.wikisource.org/wiki/Special:LintErrors/stripped-tag )

I will assume you checked your code for 'silly' mistakes BEFORE you deployed it? ShakespeareFan00 (talk) 00:08, 26 March 2025 (UTC)

I was importing the updated code from w:Module:Template test case, and checked at Module:Template test case/testcases that everything seemed to be working. I don't suppose you've pinned down what the silly mistake is? —CalendulaAsteraceae (talk • contribs) 00:11, 26 March 2025 (UTC)

It seems to be limitations in the templates actually under test. So you are owed a massive apology ( I never thought it was your code, by the way), because the testcase is doing EXACTLY what it is supposed to, TEST and find bugs. See my recent contributions for possible fixes and comments. (I found some test-cases that I commented out as KNOWN failures.) Perhaps you can pin down the testcases that are showing up a lint in the calling template for this module, when the actual Error is in the template call/test case itself? It's a shame there isn't an easy way to do a lint test from Lua as understood it.:( ShakespeareFan00 (talk) 01:48, 26 March 2025 (UTC)

{{ppoem}} with no-params has a stray DIV.. Module:ppoem might need examining.. ShakespeareFan00 (talk)

Fixed! — Alien  3
3 3 08:01, 26 March 2025 (UTC)

@Alien333: can you take a look at the other test cases thrwoing lints? Author I think is that the Module is using a SPAN for the description over a DIV, which means when a list is used in the notes portion its technically malformed? ShakespeareFan00 (talk) 09:34, 26 March 2025 (UTC)

Override_author in the header

Hello. May I ask if you could have a look at the {{header}} template? When the override_author parameter is used, the preposition "by" is omitted for some reason. See e. g. the Bohemian-American Cook Book. -- Jan Kameníček (talk) 10:13, 11 April 2025 (UTC)

Is there a reason to use override_author instead of author with author-display? That would seem to achieve the same goal without losing the preposition. —Tcr25 (talk) 14:06, 11 April 2025 (UTC)

IIRC, prepositions for override_author were removed intentionally, because it's often used to replace the whole line (in cases when 'by ...' doesn't make sense). I'd agree with Tcr, author-display is what fits the use case here. — Alien  3
3 3 17:24, 11 April 2025 (UTC)

True, I am withdrawing the request. --Jan Kameníček (talk) 19:46, 11 April 2025 (UTC)