User talk:Theknightwho

Welcome to Wikisource

Hello, Theknightwho, and welcome to Wikisource! Thank you for joining the project. I hope you like the place and decide to stay. Here are a few good links for newcomers:

• Help pages, especially for proofreading
• Help:Beginner's guide to Wikisource
• Style guide
• Inclusion policy
• Wikisource:For Wikipedians

You may be interested in participating in

• Proofread of the Month
• Monthly Challenge
• Requested texts

Add the code {{active projects}}, {{PotM}} or {{Collaboration/MC}} to your page for current Wikisource projects.

You can put a brief description of your interests on your user page and contributions to another Wikimedia project, such as Wikipedia and Commons.

Have questions? Then please ask them at either

• Wikisource:Scriptorium; or
• Wikisource:Scriptorium/Help

I hope you enjoy contributing to Wikisource, the library that is free for everyone to use! In discussions, please "sign" your comments using four tildes (~~~~); this will automatically produce your username if you're logged in (or IP address if you are not) and the date. If you need help, ask me on my talk page, or ask your question here (click edit) and place {{helpme}} before your question.

Again, welcome! Beeswaxcandle (talk) 06:17, 24 February 2022 (UTC)

Statutes of the Realm sidenotes...

https://en.wikisource.org/w/index.php?title=Page:The_Statutes_of_the_Realm_Vol_1_(1101-1377).pdf/23&action=edit&oldid=12185320

Noted, I was trying to fix a Div/Span swap Lint Error, as the ti template generates a DIV wrapper, whereas the sidenotes are SPAN based.

@Inductiveload: Do you have a suggestion as to what could go in an Indexstyles entry for this? ShakespeareFan00 (talk) 17:13, 28 February 2022 (UTC)

@ShakespeareFan00: I noticed on certain pages that you hadn't removed the corresponding }} for some of the sidenotes (i.e. there were still 6 curly brackets at the end rather than 4), so could that have been contributing to the issue? For example, this diff. Theknightwho (talk) 17:20, 28 February 2022 (UTC)

There was that , and I've now also moved the ti0 to the Indexstyles, so it should apply automatically. ShakespeareFan00 (talk)

You might also want to shift the font-sizing you do to be an Indexstyle as well. Ideally formatting for things like margin notes/sidenotes etc. should based on semantic meaning of the content, and not on a series of direct formatting. (This is if someone decides to implement a different approach for say a mobile vs desktop, its not a hassle re-formatting everything, when there's an issue.) ShakespeareFan00 (talk) 17:34, 28 February 2022 (UTC)

Thanks - I hadn't realised we could do styles like that. I'll have a think about the best way to do it. One thing I've noticed is that despite superficially being consistent, there are a large number of inconsistencies in the headings. Sizing, letter spacing (and so on) are extremely variable.

I'm also wondering how to tackle the scribal abbreviations. I'm pretty certain of what the Unicode needs to be for each of them, but that doesn't mean that it'll display well - or even in a way that is particularly similar to the text itself. The best example of this is the curl above the letters, which is actually U+035B ◌͛ ("combining zigzag above") and looks completely different in most fonts. (The Unicode name doesn't help, as a zigzag is only one style it can take...) Theknightwho (talk) 17:42, 28 February 2022 (UTC)

I got specfic advice on this off-wiki - https://github.com/psb1558/Junicode-font/blob/master/docs/Record_Interpreter_notes.pdf, the phabricator ticket to have the font added on WMF sites is still pending though. ShakespeareFan00 (talk) 17:59, 28 February 2022 (UTC)

Thanks - that's useful. I imagine the Phabricator ticket will be going for years, unfortunately. Theknightwho (talk) 18:03, 28 February 2022 (UTC)

See also the approach taken on - https://en.wikisource.org/wiki/Index:The_Statutes_of_the_Realm_Vol_8_(1702-7).pdf ShakespeareFan00 (talk) 18:06, 28 February 2022 (UTC)

Thanks - that's very useful. Theknightwho (talk) 20:26, 28 February 2022 (UTC)

Statutes of the Realm - "Contractions" table...

I've attempted to transcribe the 'contractions' table: Page:The_Statutes_of_the_Realm_Vol_1_(1101-1377).pdf/63 Page:The_Statutes_of_the_Realm_Vol_1_(1101-1377).pdf/64

Some of the glpyh's are still missing. Can you take a look and update it according to the templates You and I had created?

I'm also not understanding something, It appears to use a ᵹ to represent y, In other notes this is a lower case insular g. Have I mis-identified this, as I can't see why this would be so. ShakespeareFan00 (talk) 08:32, 4 March 2022 (UTC)

Hi - yes, I'll have a look at this. I'm unsure about ᵹ, if I'm honest - that does seem strange. It may be worth waiting to come across an actual usage example, as I haven't seen one yet. Theknightwho (talk) 17:30, 4 March 2022 (UTC)

@ShakespeareFan00 - it is ᵹ. There are usage examples in Appendix H II which show it clearly, and have a look at the history of the letter yogh which developed out of insular g. It's questionable whether the Record Commission should have been using ᵹ with texts from the 15th century instead of ȝ, but given that they specifically state Saxon characters and I haven't seen the source material, it's safest to go with that. If it becomes clear that they did in fact mean yogh, it's not hard to change. Theknightwho (talk) 17:48, 8 March 2022 (UTC)

ȝ and Ȝ are existing templates. Setting a typographic variant for yogh would be easy if the font supports it :) 88.97.96.89 08:09, 10 March 2022 (UTC)

Thanks - having done some more reading on this, I do think this is actually the letter yogh now. Theknightwho (talk) 12:06, 17 March 2022 (UTC)

Brace3

Hi, in Firefox 97.0.2 (latest version) on Windows 10, your new braces are showing as a single pixel dot. However, I can see them in Edge. I don't have enough coding knowledge to advise on what to do to have them appear as expected in all of the most common browsers. Hopefully, you've got some idea or @Xover, @Inductiveload: may have some ideas. Beeswaxcandle (talk) 02:04, 8 March 2022 (UTC)

@Beeswaxcandle Hi - the main point of brace3 is to allow variable height braces in tables, which is useful on narrow screens and when they span loads of rows. The best example is this page from Statutes of the Realm. If you set the height of a table cell to 1px and brace3 to 100%, it'll fill the height of whatever cell it's in. I've also added "brace" option to Template:ts to make it more intuitive to do.

It works in Chrome, Safari and Edge, but you're right that Firefox isn't displaying properly. There's probably some workaround, but off the top of my head I'm not sure what it is. Theknightwho (talk) 02:20, 8 March 2022 (UTC)

Uhm. Why do you expect that a box (the brace's div) sized to 100% of 1px (the height of the containing table cell) be anything but 1px? Xover (talk) 08:55, 9 March 2022 (UTC)

Because the cell isn't actually 1px due to other content. However, you need to specify some value or height:100% won't work. Theknightwho (talk) 08:58, 9 March 2022 (UTC)

@Xover - realise I forgot to tag you in my reply. Do you have any ideas for how to solve this for Firefox? It's working perfectly in Chrome, Safari and Edge, and it's extremely useful to have adaptive sizing for tables, so it'd be good to find some kind of solution. Theknightwho (talk) 12:43, 17 March 2022 (UTC)

No. I think this is an inconsistency in the spec. A percentage height is relative to the parent's height, and an element's height is equal to its extrinsic height if specified (otherwise overflow wouldn't work). So 100% of 1px should be 1px. The trouble is that elements with the table-cell display model have a special-case rule (to deal with the old pre-CSS table model in HTML) where intrinsic size seemingly overrides the extrinsic size. The spec is underspecified and inconsistent in this area, and it is not at all clear that Firefox's behaviour is in error. It is entirely possible that were a bug opened, Mozilla would choose to be "bugwards compatible" with Chrome; but it is by no means a certainty. I think the bottom line is that until the spec is clarified (and browsers adopt whatever the result is) we just can't rely on this behaviour. Xover (talk) 17:40, 17 March 2022 (UTC)

@Xover By coincidence, I have just solved this issue for all browsers. Firefox does play ball, but only if you also specify that the table cell or row is 100%, which necessitates giving the table itself a nominal height of 1px. That renders perfectly in all browsers.

I have abstracted this for usability purposes by creating the "bracetable" and "brace" arguments for {{ts}}, by the way.

See this page as an example, where I've managed to get a brace to span multiple pages. I also need to write up the documentation, as it can also do a few other things like asymmetric braces. Theknightwho (talk) 18:06, 17 March 2022 (UTC)

We're way way out in the weeds of hacky solutions. It relies on undocumented behaviour, that happens to work in the versions of those web browsers you happen to have tested, but with no guarantees it'll continue to work in future versions or other browsers. It's a really nifty trick, but it's entirely unsustainable.

PS. Whenever you see templatenameN it's a red flag. If you're about to create a template3 you should take a step back and consider whether you have a migration plan that leads to there being one true unnumbered template, because otherwise you're just adding to the confusion. Xover (talk) 18:39, 17 March 2022 (UTC)

Is there a CSS way to get the content height if it's set to auto or an unspecifed height which should logically be the actual content height? ShakespeareFan00 (talk) 18:47, 17 March 2022 (UTC)

@Xover I do agree that it's not ideal, but I'm not really sure what the alternative is - at least in the short term. I didn't really want to create a new template, but {{brace}} and {{brace2}} are both far too static to work in context (to the point where they're an active annoyance on mobile sometimes due to being completely out of whack with the text). I didn't really want to start making unilateral changes to widely-used templates, though.

Is it worth opening a Phabricator ticket to see if there's a way to get this implemented in a into MediaWiki's functionality via Javascript or something? Theknightwho (talk) 18:56, 17 March 2022 (UTC)

@Xover - this combination also works in all browsers, and avoids the nonstandard kludge:

1. Brace with height:100%.
2. Brace cell with height:100%.
3. Table with height:max-content.

Does that seem acceptable to you? I may be wrong, but it seems like this is a way to ensure that the table has a declared size that behaves in the same way as the special-case rule that you mention, meaning that everything's unambiguously within spec. Theknightwho (talk) 23:18, 17 March 2022 (UTC)

Page:The_Statutes_of_the_Realm_Vol_1_(1101-1377).pdf/34

Footnote 4:- Using Google Translate.

les queles furent faites per commun assent de tut le Roiaume.	which were made by common enough of all the Kingdom.
les queles furent faites pro commun assent de tut le Roiaume.	which were made for the common good of the whole Kingdom.

Is the former the actual intended reading or is there an erratum to note? ShakespeareFan00 (talk) 10:02, 9 March 2022 (UTC)

It's "les queles furent faites par commun assent de tut le Roiaume," meaning through the common assent in Anglo-Norman. I wouldn't trust Google Translate with this - it's too far removed from modern French. Theknightwho (talk) 18:48, 9 March 2022 (UTC)

Initial, medial and terminal i,j,u,v..

See - https://github.com/psb1558/Junicode-font/discussions/121 for context.

The thought was to have a wrapped span for the relevant letter which can then be classed using CSS..

However, on the Wikisource side this would mean appropriate templates, and a short form for marking, initial, medial or terminal position handling in any template names.

Your thoughts on this? ShakespeareFan00 (talk) 13:28, 11 March 2022 (UTC)

@ShakespeareFan00 So I wonder if it would work for the Junicode to have simple glyph variants for the specific letters, rather than trying to implement a ruleset. This would allow much easier implementation with CSS classes. That being said, the TEI approach may be better, as that also has scope for us outside of the Junicode font. I'm not sure that I'm a fan of displaying the expanded form underneath, but formatting is something that can be worked out (and in any event, there may be multiple possible approaches depending on what you're dealing with). Theknightwho (talk) 11:52, 14 March 2022 (UTC)

The intent was to allow for searching by an actual word (e.g search by union instead of looking for 'vinion') and have it rendered appropriately. I'm not sure doing it by character variation would do this easily given the varied rulesets mentioned in the response. Another approach is to have 'modifier' charcters, but those would break the flow of words, and thus not meet the criteria for making things searchable. Hmmm. ShakespeareFan00 (talk) 12:05, 14 March 2022 (UTC)

Might be worth seeing if we can get Wikisource to install Extension:TEI? Assuming it supports this feature. Theknightwho (talk) 12:41, 14 March 2022 (UTC)

Certainly worth suggesting. Would that also cover some books known to be in Early English Books Online? ShakespeareFan00 (talk) 13:20, 14 March 2022 (UTC)

And in response to something you mentioned elsewhere, there were some active National Library of Scotland contributors on English Wikisource (due to a project they were running during the Covid-19 lockdown). You might consider asking them about pre-union Scottish Statutes. ShakespeareFan00 (talk) 13:22, 14 March 2022 (UTC)

Court-hand Restored...

And I started as (transcription project) .

I'm at the moment working on the tables in it.

In respect of old manuscripts MartinPoulter (talk • contribs) might know which archives hold some of them. ShakespeareFan00 (talk) 14:21, 21 March 2022 (UTC)

Thanks - I've been meaning to bring this one up actually, as it's basically the The Record Interpreter's big brother.

You might also be interested in English court hand, A.D. 1066 to 1500, which is in two volumes. Only volume 1 has been scanned in to the Internet Archive, but that's because volume 2 is between A2 and A1 in size and contains all the plates of the texts described in volume 1. I've got a copy which I picked up cheaply a while back, which I'll scan in at some point. Theknightwho (talk) 15:49, 21 March 2022 (UTC)

Sir Hilary Jenkinson died in 1961 so it can't be hosted on Commons or Wikisource for a few years sadly. ShakespeareFan00 (talk) 18:21, 21 March 2022 (UTC)

Other Earlier English laws related texts

I'd also at some point generated an incomplete list of earlier works referenced by Own Ruffhead's collection of statutes: Talk:The_Statutes_at_Large_(Ruffhead)/Authorities

You are busy on a major project right now obviously, but it seems there's plenty more to do when it's finished :)

ShakespeareFan00 (talk) 14:23, 21 March 2022 (UTC)

Here's a good resource you probably want to have a look at, which has quite a few of the collections listed as well. They get quite confusing due to the overlaps and visual similarities, which is not helped by the way that the Internet Archive and Google both lack proper functionality for multi-volume works, so you end up finding them piecemeal. Theknightwho (talk) 15:53, 21 March 2022 (UTC)

Page:Tycho brahe.djvu/412

I think the abbreviated form I've left a comment for is 'com' , but I have no expertise in reading transcriptions from latin, and so would apprciate a second view.ShakespeareFan00 (talk) 13:38, 12 April 2022 (UTC)

@ShakespeareFan00 In this case it's "cum", meaning "with" or sometimes "at". Hi cum uno eodemque tempore accesserunt ("These came together at one and the same time"). I've added another redirect for it. Theknightwho (talk) 05:04, 2 August 2022 (UTC)

template:ct

Hi. The community has previously discussed on multiple occasions and discarded the idea of the typographic template:ct for the display of a joined "ct". I have replaced the uses and deleted the template. It is a separate situation from the long s which was an actual character and the community has determined that it can be presented in the Page: ns with the use of the template for that purpose. — billinghurst sDrewth 11:54, 1 August 2022 (UTC)

It is also not considered appropriate to simply recreate a deleted template that was the subject of a community discussion. Please do not do that again. — billinghurst sDrewth 11:57, 1 August 2022 (UTC)

@Billinghurst: It didn’t do the same thing, and was entirely stylistic by applying styles to the ordinary characters “ct”. The community reason for deleting it therefore wasn’t applicable because it never used the ligature Unicode character and therefore didn’t pose any of the problems that caused such as searchability issues. Deleting it has no advantages, and I don’t really understand why you’ve done that to be honest. It’s just undone time spent on enabling the possibility of faithful text reproduction if the reader wants it. Theknightwho (talk) 13:24, 1 August 2022 (UTC)

Also it’s not a separate situation to long S at all. That’s stylistic too, but Google just happens to treat it appropriately. Theknightwho (talk) 13:30, 1 August 2022 (UTC)

There is a clear consensus for what I did, the community has had very specific conversations about the "ct" typographic in its deletion discussion. It is also very distinctly explained at Wikisource:Style guide. You created the template over the deleted space. If you disagree with the community then open the conversation, not subvert the clear consensus of the community. Reverting an admin against a clear consensus and the style manual is not a good idea either. — billinghurst sDrewth 10:19, 2 August 2022 (UTC)

@Billinghurst That is outright untrue, as demonstratd by the ongoing discussion which you have been repeatedly tagged in. You are trying to unilaterally impose your view, and you are abusing your administrator privileges and bot in order to edit war, which is a clear abuse of your position. Disgraceful. Theknightwho (talk) 11:12, 2 August 2022 (UTC)

Please document template

Hi. Would you please document Template:Con. Undocumented templates are not good, especially when they are not glaringly obvious use case for the template. Thanks. — billinghurst sDrewth 10:23, 2 August 2022 (UTC)