Wikisource:Scriptorium/Help/Archives/2020

Please do not post any new comments on this page. This is a discussion archive first created in 2020, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Page:2019-12-02-report-of-evidence-in-the-democrats-impeachment-inquiry-in-the-house-of-representatives.pdf/11

Okay so I set up a TemplateStyle to make this simple. And then the template style completely fails to actually apply to the table?

Have I got the wrong selectors? ShakespeareFan00 (talk) 14:00, 27 December 2019 (UTC)

Is this now working? This page has whitespace:nowrap; applied to the first column, which appears to work for me. Side note: using the existing classes for "generic" table styles as a reference, shouldn't wnw1 be __wnw1? Inductiveload—talk/contribs 11:56, 31 December 2019 (UTC)

Updated, and styles now being applied :) ShakespeareFan00 (talk) 11:40, 1 January 2020 (UTC)

A limitation of CSS?

Page:Impeachment of Donald J. Trump, President of the United States — Report of the Committee on the Judiciary, House of Representatives.pdf/572

First item should not have a bullet. ShakespeareFan00 (talk) 12:45, 30 December 2019 (UTC)

Have you tried transcluding pages? —Justin (koavf)❤T☮C☺M☯ 12:55, 30 December 2019 (UTC)

Because ul's have list-style-image set on them by the CSS from load.php (list-style-image: url(/w/skins/Vector/images/bullet-icon.svg?872f1);), you have to also unset it with list-style-image:none;, as well as setting list-style-type:none; Inductiveload—talk/contribs 21:02, 30 December 2019 (UTC)

Thanks. Updated. It would be nice if there was a way of marking "continued" list items over multiple pages, like can be done with "follow" for references and so on... ShakespeareFan00 (talk) 11:26, 1 January 2020 (UTC)

You can and with wikitext. Special:Diff/9818228 means to wikicode so that the page concatenates without using <li>. If you have numerical you just do #<li value=N>, though you do need to double your use of :: inside the noinclude. I do the continuing lists all the time with DNB stuff, so do others [1] — billinghurst sDrewth 11:58, 1 January 2020 (UTC)

Meaning of "Thousand"

As you may have noticed, I enjoy transcribing Annie Besant pamphlets. When looking for scans I often come across ones with something like

[SIXTH THOUSAND.]

in the front matter (example).

What does this mean? (How) Is it different from an edition? Are "Xth thousand" versions interchangeable with versions not so marked? BethNaught (talk) 17:45, 30 December 2019 (UTC)

I have always understood this to refer to a print run, not an edition. Presumably, this was printed as part of the sixth set of one thousand. I would interpret that to be part of the same edition as the previous printing, merely a different print run, and so interchangeable with other printings from the same edition. --EncycloPetey (talk) 18:17, 30 December 2019 (UTC)

Yes, 5001-6000 printed, changed title plate, other plates all the same. — billinghurst sDrewth 12:00, 1 January 2020 (UTC)

Clone request :

Source: Index:2019-12-02-report-of-evidence-in-the-democrats-impeachment-inquiry-in-the-house-of-representatives.pdf
Pages: 1 to 123

to

Destination: Index:Impeachment of Donald J. Trump, President of the United States — Report of the Committee on the Judiciary, House of Representatives.pdf Pages: 217 to 339

As the latter pages seem to be the exact same report appended or annexed. ShakespeareFan00 (talk) 13:39, 1 January 2020 (UTC)

Thanks in advance. ShakespeareFan00 (talk) 13:39, 1 January 2020 (UTC)

Movement request of proofread pages after removed duplicates

I removed pages 36 and 37 in the source DJVU for https://en.wikisource.org/wiki/Index:On_the_Sublime_1890.djvu because they were duplicates and uploaded the corrected version to commons now that the source DJVU is in proper shape. Now it would be great if someone could delete the duplicates in the proofread pages and move the following proofread pages back two (up to page 51). Thanks in advance. MarkLSteadman (talk) 22:21, 1 January 2020 (UTC)

Done. Mpaa (talk) 23:07, 1 January 2020 (UTC)

Footnotes - The Works of Lord Byron (ed. Coleridge, Prothero) - Volume 5

I have transcribed some pages of the above, mostly the prefaces to the longer poems. The prefaces are peppered with lengthy footnotes, which are generally manageable as I am familiar with the standard footnote method, for which I use <ref> </ref> and {{smallrefs}}, the footnote continued on one of more of the following pages <ref name=xx>, <ref follow=xx>, and a footnote within a footnote where the nested footnote is on the same page, for which I use {{#tag:ref|TOP LEVEL REFERENCE<ref group="I">NESTED REFERENCE.</ref> TOP LEVEL REFERENCE|group="O"}}{{smallrefs|group="O"}}{{smallrefs|group="I"}}. I may even have done examples (in another book) where the nested footnote is all on one page but the main footnote carries on over more than one. However, I am stuck at present because in the preface to Werner on pages 338 and 339 there is a footnote containing a footnote where both the footnote and the nested footnote continue onto the following page. How do I deal with this and still maintain footnote integrity during transclusion?

User:Xover has provided a possible solution using {{pb|label=Primus}} {{smallrefs|group="primus"}} {{pb|label=Secundus}} {{smallrefs|group="secundus"}} but also referred me here.

Regards,Chrisguise (talk) 13:03, 2 January 2020 (UTC)

@Chrisguise: Note, of course, that the primus/secundus stuff is just to make the nesting obvious (please don't use that in any actual work to be transcluded!). The key points are that there are two issues at play: nested footnotes (for which you need to use {{#tag:ref|…}}), and footnotes over multiple pages (for which you need to use <ref name="…">…</ref> and <ref follow="…">…</ref>). The two methods can be combined when both issues are relevant; and both methods can be combined with other normal methods for defining and formatting references. In particular, the use of reference groups is because I took the original work to have separate groups of references; but I do not believe reference groups are technically required to realise nested footnotes spanning multiple pages. --Xover (talk) 13:33, 2 January 2020 (UTC)

Undesired line-break in interwiki transcluded pages

When a "Page" namespace page is transcluded from an other language wiki using the {{iwpage}} template, a line-break appears at the top of the page body. It is clearly visible when the page contains text in the header, for example you may compare Page:The Greek bucolic poets (1912).djvu/184 which is transcluded from el.wikisource and Page:The Greek bucolic poets (1912).djvu/185 which is not transcluded. Is there any way to get rid of it?
Αντιγόνη (talk) 10:21, 6 January 2020 (UTC)

I expect the problem is caused by the <poem> tag at the top the source page. The poem tag causes all sorts of problems, and interacts badly with other format elemants. --EncycloPetey (talk) 21:22, 6 January 2020 (UTC)

It seems not, you may check this page Page:On two Greek inscriptions, from Kamiros and Ialysos, in Rhodes, respectively (1878).djvu/11, it does not contain the <poem> tag but the line-break is present again.
Αντιγόνη (talk) 21:58, 6 January 2020 (UTC)

Probably something in mul:MediaWiki:InterWikiTransclusion.js from whence the code emanates. If you can get the same problem at mulWS then it is something that they can investigate and address, they own that code. — billinghurst sDrewth 22:05, 6 January 2020 (UTC)

Scan not appearing at Page:Annie Besant - The Story of Afghanistan.pdf/15

As per the heading.

I've purged all the relevant pages I can think of, and you can see the page on Commons.

Can anyone help? BethNaught (talk) 22:30, 9 January 2020 (UTC)

I think it is connected with task T188885 (which was reported almost 2 years ago). --Jan Kameníček (talk) 00:57, 10 January 2020 (UTC)

I opened task T242517, there is something that has been changed for PDF files recently.Mpaa (talk) 17:23, 11 January 2020 (UTC)

@Mpaa: See WS:S#404:Not Found (thumbs) and phab:T242422. @Jan.Kamenicek: phab:T188885 is almost certainly a different issue: the current problem seems very likely to be something introduced in the new version of MediaWiki that was deployed yesterday. --Xover (talk) 20:00, 11 January 2020 (UTC)

search and replace / regex

I've found it handy to have a search-and-replace feature built into Wikisource (the magnifying glass icon in the upper right, within the "Advanced" editing window). But it seems pretty limited. I'm curious if there's something I'm missing.

• It seems to me that it's not possible to restore text from the search string. In other programs I'm used to being able to call "variables" like "\1" -- so that, for instance, if I wanted to replace "1A" with "2A" and replace "1B" with "2B" etc., I could search for "[0-9]([A-Z])" and replace it with "2\1". Is there a way to reinsert part of the search string in Wikisource's implementation?
• More generally, it seems it might just be impossible to use any code in the "replace" field. I can't even put in a new line character with "\n" -- it just puts in the string "\n" instead of a carriage return.

Is there any way to accomplish these things with Wikisource's built-in search-and-replace function, or do I need to keep using an external editor for such tasks? -Pete (talk) 19:40, 15 January 2020 (UTC)

Gadget m:TemplateScript has been around for years has regex capability for on demand or permanent. Can save searches, or you can build then into your common.js. Wouldn't leave home without it, and it saves much much work. I set mine to run from my global.js so I can utilise the feature at all wikis, though I keep my regex scripts local. — billinghurst sDrewth 13:02, 16 January 2020 (UTC)

Lack of Citation

Hello all- I have recently gotten a warm reception from the community and gotten off to a great start of Wikisource some good work done on the Afghanistan-China border. However, I noticed that the Chinese character version of the treaty on the zh.wikisource lacks any citation ([:zh:中华人民共和国和阿富汗王国边界条约]). I want to be able to alert the readers that see that page that what they are reading doesn't have a known source. Is there a template like "citation needed" or anything similar that can be used on that page? What would be done if this were happening on en.wikisource? Thanks for any help. --Geographyinitiative (talk) 12:20, 16 January 2020 (UTC)

{{no source}} is what we use locally. I suggest you see if that template has a interwikilink through to zhWS, and utilise its equivalent. Hopefully one exists. — billinghurst sDrewth 12:57, 16 January 2020 (UTC)

It seems that zh:Template:No source is intended only for pictures… If you do not find any suitable zh template you can try leaving a message at the talk page of the page there. --Jan Kameníček (talk) 22:29, 16 January 2020 (UTC)

Or just use it and let them fuss the detail. — billinghurst sDrewth 01:01, 17 January 2020 (UTC)

A very complex footnote

The footnote to Mediaeval Hymns and Sequences/Stola Regni laureatus is very complex, containing both a table that continues over a page break, and also a nested footnote. I'm having a bit of trouble getting either of these features to display properly, and any assistance would be appreciated. —Beleg Tâl (talk) 16:41, 16 January 2020 (UTC)

Thoughts only, rather than a guarantee. I would suggest that you see if you can leverage {{authority reference}} directly or see if you can utilise its logic. I think that I set it up so you could just do jigsaw pieces, but it was a while ago. Basically implant sections, then utilise ye olde section transclusion to pull the requisite parts together. A Compendium of Irish Biography has its {{IrishBio ref}}. I think that I also did some complex footnote'd components in The Life of Captain Matthew Flinders, R.N. though maybe I am misremembering somewhere (unhelpful). — billinghurst sDrewth 22:01, 16 January 2020 (UTC)

Thanks. Based on that template, I've got the table transcluding correctly now. Nested footnote is still outstanding. —Beleg Tâl (talk) 13:47, 17 January 2020 (UTC)

I've got the nested footnote working now using the suggestions at H:REF#Nested footnotes. What a mess. Oh well. —Beleg Tâl (talk) 13:53, 17 January 2020 (UTC)

What a mess indeed. Congratulations, and thank you for documenting what you did in a comment. In case you're not satisfied with this approach, is there a way to replicate the format without using an HTML table at all? E.g. something CSS-based? -Pete (talk) 20:21, 17 January 2020 (UTC)

New

Hi I'm new and I want to help out on something. —unsigned comment by Danielstreets (talk) .

Welcome. Thanks for the heads up. I have left a welcome message on your user talk page, as it contains the most pertinent information. For new users we think that the Wikisource:Proofread of the Month is a good place to start on a collaborative work. Do feel that you can ask questions of those doing the work, or ask here if you want some advice or explanation of why we are doing things. — billinghurst sDrewth 05:03, 17 January 2020 (UTC)

Thank you. I'm doing some proofreading now and am gradually starting to get the gist of things.

Missing pages

I have uploaded File:Poet Lore, volume 27, 1916.pdf to Commons, but two pages are missing there. O found them in a different file (where unfortunately some other pages were missing). I uploaded the two pages to https://drive.google.com/file/d/1-ieqFjAHcXpPbEfxLe1BXxYnjlIkfS6K/view?usp=sharing . May I ask somebody for 1) adding the two pages to the pdf file between pages no. 232 and 233, i.e. at the beginning of the Summer Number, and 2) converting the file into djvu?

Thanks! --Jan Kameníček (talk) 22:06, 17 January 2020 (UTC)

I'd be happy to do this, but it will be 24 hours or so before I can get to it. I'll check here first to make sure I'm not duplicating somebody else's effort. -Pete (talk) 22:20, 17 January 2020 (UTC)

No problem, no need to hurry :-) --Jan Kameníček (talk) 23:45, 17 January 2020 (UTC)

@Jan.Kamenicek: I have created the file: File:Poet Lore, volume 27, 1916.djvu However, the pdf2djvu command I used gave a "segmentation fault" on the new pages, and I see the new pages appear rather grainy (but still readable). I'm not sure what I need to do to fix the problem. I can try to figure it out, but in the meantime maybe this file is helpful. -Pete (talk) 05:21, 18 January 2020 (UTC)

Yes, those two are very grainy (it looks like they suffer the same problem as [2], which was also created from a much better PDF), but the most important thing is that the pages are not missing and the following ones are not shifted. Thanks very much! --Jan Kameníček (talk) 09:28, 18 January 2020 (UTC)

step by step

I'm a new member here, could you tell me step by step guide for a beginner like me?

--PutriAmalia1991 (talk) 03:45, 20 January 2020 (UTC)

@PutriAmalia1991: The welcome message that I put on your user talk page will help with the basics. For newbies, we invite them to the Wikisource:Proofread of the Month which is a collaborative work where you can see others at work, before or after your edits. We find it a great way to learn, and to participate in a new work being produced each month. — billinghurst sDrewth 07:05, 20 January 2020 (UTC)

Why is right margin not working with img float?

I am trying to use img float to add an image as initial capital letter on this page, and find the text running right up against the image on the right despite "style=margin-right:10px." Other style attributes work fine, so what’s preventing this one? Levana Taylor (talk) 01:05, 21 January 2020 (UTC)

Looking at the actual page source from HTML (choose "view source" from your browser, likely Ctrl+U):

.img-floatright{float:none!important;clear:none!important;margin:0 auto!important;padding:0!important}}.mw-parser-output

as well as

.img-floatright{float:right;clear:right;margin:0 0 0 1em;padding:0 0.5em}

So it appears that your margin-right:10px;margin-top:5px; is overridden in the cascading style sheet by an !important rule. Adding !important to your rule manually didn't work so maybe the rule can be added automatically into the template?

As an aside, why did you use a black-and-white picture for the image? —Justin (koavf)❤T☮C☺M☯ 01:47, 21 January 2020 (UTC)

A quite separate issue is that {{img float}} generates conflicting CSS rules: in short the expansion of polygon completely overrules any margin style.

Instead of

{{img float
|file=Initial O with Holly and Bells (transparent).png
|align=left
|width=230px
|polygon=0 0, 230px 0, 230px 258px, 168px 258px, 168px 304px, 140px 304px, 140px 361px, 0 361px
| alt=O
| style=margin-right:10px;margin-top:-5px
}}

try something like

{{img float
|file=Initial O with Holly and Bells (transparent).png
|align=left
|width=230px
|polygon=0 -5px, 240px -5px, 240px 253px, 178px 253px, 178px 299px, 140px 299px, 140px 356px, 0 356px
| alt=O
}}

You may still have to tweak this! 114.78.171.144 02:19, 21 January 2020 (UTC)

OK thanks. Note to self: do not use both margins & polygon. I think that should be in the documentation of Img Float.

As for why I went with a transparent background, that was due to someone’s parenthetical remark, a couple weeks ago, about how their mobile browser didn't use a white background which made images-as-initial-letters look weird. Is there a downside to using transparent backgrounds if you have them available? Levana Taylor (talk) 02:30, 21 January 2020 (UTC)

While you are quite right about the "ought to make a note in the template documentation" point perhaps it is worth noting the sometimes chaotic development of some templates: {{img float}} added style early in 2012, moved toward standardised styling in early 2019, added polygon in May just past… which would be the first point when your note could even possibly have started to make sense… I shall almost bet none of those 2012 editors are still contactable or would have remembered the implications of style=margin:… on the back-then non-existent CSS "shape" attributes.

I don't think Koavf was objecting to the image transparency so much as the book scan had blue and orange areas which appear to have been converted to monochrome. 114.78.171.144 03:13, 21 January 2020 (UTC)

Those blue and orange areas are scan artifacts, the original pages were printed in black-and-white. Levana Taylor (talk) 03:24, 21 January 2020 (UTC)

That was in fact what I mean, 114. It's incredible that the weird scan gaussing problems (or whatever) resulted in a very beautiful coloration on that image, actually. Great work, Levana. —Justin (koavf)❤T☮C☺M☯ 03:42, 21 January 2020 (UTC)

I've added a note about the CSS shape-outside parameter overriding the margin box (this is a general CSS thing).

BTW, this image appears to have lost its transparency - the background is now white for me. The only downside to transparency I can think of is that if someone is using a e-reader app in night mode (light text on dark background), the image will be very low contrast. I'm not sure if that's better or worse than having a white background on all the day-mode e-readers which have a white image background on their off-white page backgrounds: e.g. File:Wikisource ePub export - The Sweeper of Dunluce.jpg.

Example of transparency: normal mode and night mode. Inductiveload—talk/contribs 09:59, 21 January 2020 (UTC)

Thanks for pointing out that the image edit I did had removed the transparency, I’ve reverted it now. As for night mode e-readers, well, you can’t have everything, and I figure that’s used a lot less than off-white backgrounds ... Levana Taylor (talk) 13:03, 21 January 2020 (UTC)

Yes, in my opinion too, it's better to get normal-mode readers looking great than night-mode, since that's surely a pretty small user-base. I much prefer the transparent approach, as, other than very dark backgrounds, it allows the reader to set their own background colours. Inductiveload—talk/contribs 13:54, 21 January 2020 (UTC)

caption above in {{Img float}}

I am trying to recreate the captioned image on this page using {{Img float}} and as you can see, the "above" parameter puts the top caption very far above the image. Is there anything I can do about that (while still floating the image)? Levana Taylor (talk) 20:44, 23 January 2020 (UTC)

{{img float}} is a span-based template, it does not expect a div-based template like {{center}} in the captions. This is because it's designed to float within paragraphs. There is a br-element after the top caption (not sure if that's actually required). It is that extra line break you were seeing. The solution in this case is to remove the center template, which wasn't necessary anyway, due to the capalign=center parameter. Inductiveload—talk/contribs 22:14, 23 January 2020 (UTC)

Ok, thanks. I’ll get this right eventually. Levana Taylor (talk) 01:42, 24 January 2020 (UTC)

Mediawiki being pedantic about Section syntax interaction with tables again..

A Naval Biographical Dictionary/Promotions - Lieutenants and the underlying pages..

It won't display the page numbers cleanly, DESPITE resolving the lint errors on the underlying pages..

ONE common solution please, so I can Document how cross-page tables/sections like this are SUPPOSED to be done. ShakespeareFan00 (talk) 10:41, 26 January 2020 (UTC)

The section runs from label 'Promotions - Lieutenants' to label 'Appointments' — section 'Promotions - Lieutenants' is not the only thing required. Try substituting:

<pages index='A Naval Biographical Dictionary.djvu' from='1362' to='1363' onlysection='Promotions - Lieutenants' ></pages>

with:

<pages index='A Naval Biographical Dictionary.djvu' from='1362' to='1363' fromsection='Promotions - Lieutenants' tosection='Appointments' />

114.78.171.144 11:02, 26 January 2020 (UTC)

Nope solution suggested did NOT solve the problem. ShakespeareFan00 (talk) 11:09, 26 January 2020 (UTC)

Oops. Needed an explicit section end just above ## Appointments ## label. You were right about this bit:

<pages index='A Naval Biographical Dictionary.djvu' from='1362' to='1363' fromsection='Promotions - Lieutenants' tosection='Promotions - Lieutenants' />

114.78.171.144 11:34, 26 January 2020 (UTC)

Page:Sir Walter Raleigh by Thoreau, Henry David,.djvu/121

I've repaired a lint error concern here, but was wondering if any of the other contributors better versed in arcane markup interactions, knew of a more elegant solution?

As currently implemented it manifests a known issue concerning how content at the end of a page is 'wrapped' sometimes incorrectly. ShakespeareFan00 (talk) 15:12, 26 January 2020 (UTC)

Note in passing: the transluded result at Sir Walter Raleigh/Notes#95 is without flaw. The Page: space rendering (due to an implicit </p> being inserted between the penultimate and final lines) is disappointing but ultimately meaningless. 114.78.171.144 21:15, 26 January 2020 (UTC)

This is an issue that's been known about for over a decade and has still not been adequately resolved though, which is a shame as it complicates proofreading. ShakespeareFan00 (talk) 21:59, 26 January 2020 (UTC)

{{block center}} allows for a parameter that sets the font size; it is not necessary to call another template. --EncycloPetey (talk) 21:44, 26 January 2020 (UTC)

Block formatting in a reference...

In the following : Page:King Solomon's Mines (1907).djvu/227 - A lint error arises because the reference contains block level formatting, and the current Cite extension cannot handle this cleanly (as it treats references as being mostly span based). It is my understanding a work-around was previously discussed for this? ShakespeareFan00 (talk) 23:00, 26 January 2020 (UTC)

I usually handle these situations like this --23:19, 26 January 2020 (UTC)

@EncycloPetey:  Comment Whilst I agree with your improvement, the <poem> tag itself introduces a <div> — but in all honesty I don't know whether lint objects to this; or somehow knows that because it brought in by an extension everything is O.K. Can anyone throw any light on this? 114.78.171.144 03:43, 27 January 2020 (UTC)

It's possible to remove the div as well, using <br /> to place the line breaks. My demo was the elimination of the block template. Personally, I don't use the <poem> tag because it causes too many issues. --EncycloPetey (talk) 04:48, 27 January 2020 (UTC)

The LintError wasn't showing up in the page but on the transclusion:- King Solomon's Mines/Chapter XVI, I couldn't find anything other than this reference with a DIV issue in the pages themeselves.. ShakespeareFan00 (talk) 08:49, 27 January 2020 (UTC)

Converting both references in the chapter to {{#tag:ref|{{#tag:poem|...}}}} seemed to temporarily silence the lint concern, but a longer term stable solution is needed ( as using a lot of parser functions isn't good on performance.) ShakespeareFan00 (talk) 08:54, 27 January 2020 (UTC)

And despite having done the above I'm still getting the "div-span" swap concern when the pages are transcluded. (sigh) :(

Block level elements in a REF tag is a known issue - see https://phabricator.wikimedia.org/T49544 and https://phabricator.wikimedia.org/T57674, but , there has not been progress made on a fix at present. ShakespeareFan00 (talk) 09:14, 27 January 2020 (UTC)

•  Comment A reference should be able to contain block level formatting, so if that is throwing a lint error, then go back and talk to those doing the lint stuff, it would seem to be false error that needs addressing. — billinghurst sDrewth 10:45, 27 January 2020 (UTC)

Did you read the tickets I linked above? At the date it was written ref tags were SPAN based. Was there a subsequent patch which changed this?

ShakespeareFan00 (talk) 11:18, 27 January 2020 (UTC)

The patch linked from the phabricator ticket was - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Cite/+/276183/ which form asking in the #mediawiki channel had not been merged yet. ShakespeareFan00 (talk) 11:31, 27 January 2020 (UTC)

No, and I have zero interest. The simple fact is that refs from WS's perspective require formatting and require to be blocks. So why would we be fucking around trying to pay attention to lint errors that complain about spans. Ignore them and move on, don't be dictated to by a lint error. Or tell them that they need to be ignored as refs need to allow for blocks, and don't be dictated to by lint errors. Give me strength. — billinghurst sDrewth

And I am now going to go back to my previous position of ignoring you in these forums. You do my nut in. Tail wagging the dog! From my perspective, there are more important things in this place than 95% of the stuff that you unceasingly complain about. — billinghurst sDrewth 11:37, 27 January 2020 (UTC)

The trouble here is that we're bound by the rules of HTML (because those are the rules the web browsers of our readers obey), and when we put block level elements inside inline elements we get weird formatting problems that directly impact presentation of works; completely irrespective of what the linter extension chooses to flag. It doesn't help, of course, that the linter is not just something that pops error messages in a log somewhere: that whole part of the stack also makes changes to HTML output to try to make sure the emitted HTML is valid. Very well-meaning, but it means the net effect of a given bit of wiki markup is often unpredictable and entirely inscrutable. We can of course debate how much weight, and attendant effort, should be expended on lint errors; but the fact is that the linter is trying to warn us about actual problems that come about from our use of wiki markup. The linter is a part of Mediawiki core, and these can change from "silent warning in a log somewhere" to "no longer supported, all your pages are broken now, so sorry (not sorry)" at any time. Or put another way, the linter errors are in effect the WMF / Mediawiki devs. telling us "You really shouldn't be doing this!". Completely ignoring them is not a winning strategy in the long term.

PS. But, ShakepeareFan00, for the block/inline and refs thing, the linked Phab/patch is the way to solve this issue, so until that gets merged there's really not much point expending energy on this. If there's no visible problem, we should just ignore the lint errors until the software gets fixed: before that it's a lose—lose proposition. --Xover (talk) 11:59, 27 January 2020 (UTC)

I am more prepared to accept this as a 'known' issue, and move on, linking the existing tickets to show that it was 'known', as expending effort on solving "un-fixable" problems (including contributors such as myself that implement inefficient and incompetent over complex and badly communicated solutions in response to technical limitations) isn't as others have said worth the effort. ShakespeareFan00 (talk) 12:27, 27 January 2020 (UTC)

Tables... (again)

Following on from my earlier concerns, I was attempting to remove yet more "fostered content" concerns:-

A Naval Biographical Dictionary/Appointments to Ships B 

However this seems to generate a missing end DIV concern. I can't find a missing end tag in the transcluded pages, after having edited them to resolve the "fostered content" concerns, and the missing DIV doesn't appear when lint checking the individual pages themselves.

However, checking the Main space pages indicated a LOT of missed closing DIV's. The DIV's seem to be used for controlling the margins. Wasn't this why dynamic layouts were provided?

The side issue concerning page numbering on page spanning tables is https://phabricator.wikimedia.org/T232477,( which if adequately resolved should eleminate the hacks and workarounds that lead to the "overloaded" use of {{nop}} which I feel is the cause of a LOT of these fostered content Lint concerns.) ShakespeareFan00 (talk) 09:54, 27 January 2020 (UTC)

I also raised https://phabricator.wikimedia.org/T216350 in the past, but it doesn't seem to have generated a response.

see also https://phabricator.wikimedia.org/T184021 https://phabricator.wikimedia.org/T162935 and https://phabricator.wikimedia.org/T185221

ShakespeareFan00 (talk) 10:04, 27 January 2020 (UTC)

 CommentIn tables, we should use {{nopt}} (span based) to lead the section rather than {{nop}} (div based). Otherwise I am not sure what point you are trying to make. — billinghurst sDrewth 10:39, 27 January 2020 (UTC)

What I am trying to say is

1. A co-ordinated effort to reduce the Lint error backlog (from technically adept users) would be appreciated. 2. If the relevant phabriactor tickets were (at some future date) dealt with the {{nopt}}, {{nop}} usages wouldn't necessarily be needed, as Mediawiki (and the relevant extensions.) would be able to cope directly with the SOL/EOL context directly. 3. Having 'fixed' DIV based layouts using inline margins, to "fix" table widths didn't seem like a good idea.. Now that TemplateStyles exist, wouldn't styling the table element directly be a better and less error prone way of doing this?

In some instances {{nopt}} isn't the whole picture as I've found using it (or the comment line directly, which is what I've done when transcribing table in new contributions) modifes the linespacing of the last entry of any table cell in the page header, This results in a slightly disrupted appearance on preview, which complicates but doesn't prevent proofreading.

ShakespeareFan00 (talk) 10:48, 27 January 2020 (UTC)

See - https://en.wikisource.org/w/index.php?title=Page:A_Naval_Biographical_Dictionary.djvu/1366&oldid=9893395 for an example of a 'disrupted' end of row cell when using {{nopt}} vs {{nop}}. ShakespeareFan00 (talk) 10:55, 27 January 2020 (UTC)

The Heart of Voltaire

Right now, this is what the title and decorative initial of "The Heart of Voltaire" look like. At first, though, I tried to come up with a way of putting the title next to the picture, something like so -- It seems like the only sensible thing to do with all that white space. @Inductiveload: and other CSS jugglers, do you have any ideas for an elegant thing to do? Levana Taylor (talk) 05:22, 27 January 2020 (UTC)

I see the ever-industrious typesetters of the mid-1800s are at it again! The solution you have hit upon is pretty good if you ask me. The main problem with it is that when the page shrinks, the div wraps onto the next line. {{flow under}} seems to work too, but differently. Short of isolating the initial "I" as a separate image by removing the background and using two images, one in the centre, one as the drop initial, I can't really think of a better way to deal with this with the tools we have. Because on mobile, the image can change size, anything which blocks out text using pixels as a measure is doomed to failure there. But it might just have to be.

In terms of the big white void, I can't really think of a workaround for that. Again, you could split the image, or define a default layout that looks right (I guess Layout 2). Inductiveload—talk/contribs 08:45, 28 January 2020 (UTC)

I have a thought. Maybe this: Separate the pyramid from the initial I (it would take a little Photoshop twiddling). Use the I as dropcap. Above that, use something like flex box to put the pyramid and title side by side if possible, with the pyramid always aligned to the left of the page, and the title either centered in the right column or else above? You’d just have to make sure that there was no space between the bottom of the pyramid and the top of the initial letter; if they didn’t line up perfectly horizontally, because of resizing separately, it wouldn’t be very noticeable.

Here and Here are a pair of images for test purposes; I’ll do better ones with Photoshop later. Levana Taylor (talk) 09:42, 28 January 2020 (UTC)

You could also take some artistic licence and separate the letter and the pyramid entirely, removing the background behind the I and trimming the shadow back a bit: File:Voltaire vignette (pyramid).png and File:Voltaire vignette initial I.png. Not sure how acceptable it is to do that, but it's one solution that "works" properly on the web, approximately how it was intended to work originally. Then you don't need to stress about getting the I in the right place.Inductiveload—talk/contribs 11:12, 28 January 2020 (UTC)

This is, I think, the best solution. —Beleg Tâl (talk) 13:38, 28 January 2020 (UTC)

Withholding of Ukraine Security Assistance

Hello all- last week, I made my third Wikisource entry- the GAO Report on Withholding of Ukraine Security Assistance. The page is linked on English Wikipedia's 'Trump–Ukraine scandal' page. I would like to direct the community to this page to bring it up to standard with whatever Wikisource community standards I am not yet fully aware of so that we can provide a good resource for people interested in this issue both today and in the future. --Geographyinitiative (talk) 12:48, 28 January 2020 (UTC)

@Geographyinitiative: A couple of tips:

• Generally we don't want links to Wikipedia inside the texts we host, unless the original work also linked to Wikipedia - see WS:ANN for details.
• Headers and footers like "Page 2" and so forth should be placed in the header and footer so they don't get transcluded - see H:HEADER
• See H:NOTES for guidance on how to set up footnotes.

—Beleg Tâl (talk) 13:45, 28 January 2020 (UTC)

@Geographyinitiative: One more tip: use {{nop}} instead of <br /> to prevent paragraphs from joining up over a page break. I've tidied up the text, so all that remains is to proofread for fidelity to the original. —Beleg Tâl (talk) 14:20, 28 January 2020 (UTC)

Wikipedia:Template limits

I'm working on Index:United States Statutes at Large Volume 33 Part 2.djvu, and have developed a whole suite of templates to massively increase both rapidity and accuracy of proof-reading. And believe me, there is no practical way of doing this without templates. Don't ask me why I'm doing it (not sure I even know why I'm doing it!), but there are thousands and thousands of federal pension grants and increases in these pages, so of passingly important social history/military history/PhD/genealogical value to somebody, and I'm pretty sure the Library of Congress isn't going to cover these in its digitisation project because they are technically Private Acts.

However, with an average of 4 or 5 templates per page, and so far 270+ pages transcluded on United States Statutes at Large/Volume 33/Fifty-Eighth Congress/Private Acts of the Second Session, we have inevitably smashed through MW's Template limits. Ahah, I hear you say - easy! Once it's all proofed, ask AWB to subst: everything and the problem goes away. This is completely true, and the templates have even been deliberately written to respond correctly to this, but...

In its current "semi-structured" state, the data set is conceivably only a step away from being machine-readable/searchable (each pension has at least the following fields: date=, grantee=, quality=, rate=, gender=), whereas once everything is subst:ed, it just goes back to being in a sense "dumb" data again. I know this is not WS's mission, but does anyone have any ideas about who might want to host such data? Is it WikiData's bailiwick? Is there a potential SMW hoster out there somewhere? It would be such a shame to lose all the (accidentally) carefully applied data structure which should be of value to someone...CharlesSpencer (talk) 14:29, 4 February 2020 (UTC)

@CharlesSpencer: You could try asking over on Wikidata where Wikimedia's datagluttons tend to hang out. I'm not entirely sure this will fit their approach, but they'll be best placed to say something to that. I very much agree that if we've created structured data through manual effort, we should try very hard to preserve that in some fashion, but I don't really see how we could do that sanely on enWS. --Xover (talk) 14:39, 4 February 2020 (UTC)

Thanks @Xover: - message duly ported to Wikidata! CharlesSpencer (talk) 15:00, 4 February 2020 (UTC)

Much of the issue is due to all the #if: and #ifeq: (see w:Wikipedia:Post-expand include size). Try transcluding to smaller parts, or look to see if someone can write in Lua as that will take out parts of that. Pulling data from WD may help, though there is still lots of decision-making there. — billinghurst sDrewth 05:16, 5 February 2020 (UTC)

Preferred approach for Marginal Section Headings and Chapter contents?

New to Wikisource (but have worked on other wikis)

Question 1: The book I am working on places section headings in the outside margin (repeated on subsequent pages if the section continues)... one solution I see but haven't tested is to use dynamic layouts and code them in with 4 CSS classes (one for the initial appearance (left or right page), one for repeated occurrences (left and right pages) so that they can be set to display:none). Alternatively, I can achieve something close with wikitext and templates such as outside or sidenote: example ==={{outside RL|''section heading text''|size=0.75em|height=1}}===, or a better result with ==={{right sidenote|''section heading text''|display:inline-block;font-size:0.75em;line-height:1.1em;padding-top:0.5em}}===

Is there a preferred approach or have I overlooked something in the style guide and/or available templates?

Question 2: The first page of each chapter has a list of the chapter's sections (although not always verbatim to the headings that appear in the margins) - a sort of mini-TOC, or in TEI (text encoding initiative) nomenclature would be probably labelled "arguments"... Should these just be rendered as text or is there a template/code for this?

An example of the text showing both the Contents and a section heading is here Page:Abstract_of_the_evidence_for_the_abolition_of_the_slave-trade_1791.djvu/31

Thanks RT764 (talk)

1. Sidenotes are not easy for us, and honestly drive some of us "spare", as they are truly an artefact of the book as typeset at the time. There are numerous examples of them around the place, and rendering them onto mobile screens and wide monitors reliably is problematic. Maybe start with Help:Sidenotes, and there are a number of templates available, and often our answers are case by case due to each work's peculiarity.
2. For those chapter linear ToC, like that generally we would say keep it simple and utilise {{hanging indent}} though it does not inherit parent formatting. We don't tend to put anchors into them, though if it makes sense for the work, then we have {{anchor+}} for the targets, and wikilink naturally. Some of those peripheral aspects like extra navigation can wait to the end, or you might do a chapter and look to transclude to see how it looks, and what it needs. — billinghurst sDrewth 21:57, 4 February 2020 (UTC)

Improving performance... Index:Chronological Table and Index of the Statutes.djvu and Chronological_Table_and_Index_of_the_Statutes/Chronological_Table sub-pages...

A while back I reworked these to enable them to be subst more cleanly, and updated them to use template styles in the header.

Any chance someone technically adet use something like AWB to do a mass subst of uses, because it would greatly improve performance in respect of the sub pages of: Chronological_Table_and_Index_of_the_Statutes/Chronological_Table.

I could do it manually, but the replacement could easily be automated, and thus less error prone.

It's currently split up because of the sheer number of template calls, blew out the transclusion limits when it was made. As templatestyles need only be called ONCE per page, it should be possible to reduce it to five or six template calls per page instead of the one or more call per row currently.

When I did a similar change to the underlying pages here Short Titles Act 1896/First Schedule, I was able to bring the WHOLE first schedule back onto a single page, which is quite an impressive performance improvement.ShakespeareFan00 (talk) 13:47, 27 January 2020 (UTC)

I cannot understand what you are asking. If you want help, you need to be clear. Mpaa (talk) 21:14, 30 January 2020 (UTC)

Before you mass-subst all these, wouldn't it make sense to take advantage of the fact that the very use of the templates carries semantic content? For example, {{Statute table/chapter}} is

|-
|{{ts|padding-left:0.25em;padding-right:0.25em;}}{{!}}{{gap|1em}}{{{Override Chapter|c. {{{Chapter Num}}}.}}} {{{Alternate|{{{Chapter Name|}}}}}} 
|{{{Topic| }}} 
|{{{Repeal| }}}

By defining a row style with :nth-child() formatting as needed, you can simplify to only, say,

|- class="__st_chapter"
| content A
| content B
| content C

and define all styling in the CSS (which is what CSS is for, style is the middle S). By subst'ing with the current raw table markup and inline CSS, you lose all the semantic information about which row means what, and the resulting inline CSS will be a real pain to convert to "classy" CSS after the fact. Whereas now you have a template, you can do it all in the template, and then subst.

And please document the CSS. CSS comments look like this /* comment */. Inductiveload—talk/contribs 12:32, 31 January 2020 (UTC)

Thanks.. Documentation isn't my strong point... but I've tried.. and updated the templates as you suggested.. ShakespeareFan00 (talk) 18:19, 31 January 2020 (UTC)

If there was a way to import a Tempaltestyle into a table directly, I think even more improvements could be made... ShakespeareFan00 (talk) 18:53, 31 January 2020 (UTC)

Looks good to me. Certainly will be much simpler wikicode after subst. I am unclear as to what you mean by "import a Templatestyle into a table directly". You just invoke the CSS page as you do in Template:Statute table/header. Doing in that the header of the Page: pages is a little clunky, but, as you know, doing it automatically per-index without adding code relies on phab:T226275 finding a suitable resolution. Or do you mean place the templatestyle tag within the table content? Because that actually does work, AFAICT. No idea if it's a good idea though. TS calls are de-duplicated, so I imagine it should be fine, but I kind of doubt it's a tested configuration. Note, the CSS in inlined up front, so you can't have the CSS apply only after a certain point. Inductiveload—talk/contribs 20:05, 31 January 2020 (UTC)

I meant having something in the table syntax for wikitext markup that does what TemplateStyles (or {{table class/import}} does albiet on a per table basis... I can of course set id= on the table and use that id as a suitable selector if I want to classes to a specfic table... ShakespeareFan00 (talk) 09:30, 1 February 2020 (UTC)

The inlined upfront, is why I'd like to see the phab ticket you mention resovled (2021 Tech wishlist maybe?) , and agree on a naming convention so styles don't conflict between imported stylesheets (this was partly why I had prefixed stuff with __ ShakespeareFan00 (talk) 09:30, 1 February 2020 (UTC)

You mean "scope" the CSS to only apply to a certain table? There is such a thing as scoped CSS, but TS would have to have a scoped=1 parameter or something so it can inject it inline as need, and not de-duplicate, and there would probably be many other practicalities. I think just a CSS ID or class selector will work for all likely cases.

As far as naming conventions go, as I said before, I think a prefix (e.g. of "_") is a good idea to avoid clashing with built-in Mediawiki classes and to make it obvious it's a TS class. Namespacing work/domain-wise with "_prefix_" based on work is probably a good idea too, if for no other reason than making it easy to search for without popping up hundreds of difference instances of generically-named "_table" classes. Cross-work conflicts are unlikely, as the pages would not usually get transcluded together, but it would a frustrating bug to find if you did encounter it.

Perhaps reserve "__" for "global" classes, so if you see it you know it's not a work-specific style, though I still feel that global classes should be limited.

One other issue with "_" is that it's a bit tricky to search for, but if you do insource:/_classname/, it works.Inductiveload—talk/contribs 10:22, 1 February 2020 (UTC)

I'm considering if multi-line repeal- entries should be split? for semantics reasons.. This would also allow for the extensive use of {{gap}} to be reduced.ShakespeareFan00 (talk) 15:03, 6 February 2020 (UTC)

I'd say whatever makes the Wikitext most obvious and tractable for editing. Your just-added {{statute table/repeal-follow}} seems to fit that bill.

WRT to "performance", the post-expand include size of these pages currently looks you can include page 30 of that document something like 800 times before the limit is reached (avoiding thousands of bits of repeated inline CSS is probably to thank for that). I would suggest that, regardless of technical ability to do so, you do not transclude as one leviathan table, not because of "performance", but because a page that long will be annoying to navigate. Remember, originally, it was paginated as pages, not as 30 metre-long scroll.

I also suggest that you not subst this, as you will regret it if you later find you want to tweak the Wikitext of every row somehow. It doesn't look like you will ben needing to hack around the limit anyway. Inductiveload—talk/contribs 16:04, 6 February 2020 (UTC)

I have other reasons for NOT making this one long scroll, Organisaing it by Mornachs and Regenal years seemed to be how other related publications did it. ShakespeareFan00 (talk) 17:07, 6 February 2020 (UTC)

In relation to the original request.. Given the improvements made to the underlying templates a subst isn't now needed.ShakespeareFan00 (talk) 17:07, 6 February 2020 (UTC)

Why does templating something generate an error?

Two examples:

:<div style="text-align:left; margin-left:1em">allotments in right of glebe, on inclosure, leasing of allotments, &c.</div>

:{{left|allotments in right of glebe, on inclosure, leasing of allotments, &c.|1em}}

The first example works perfectly, the second which SHOULD be generating the exact same code doesn't seem to, and causes a LintEror when used at the start of the body of a Page: Consistency of behaviour would be nice. ShakespeareFan00 (talk) 21:34, 3 February 2020 (UTC)

By comparison I created {{Left-shift}}, effectively removing the line feed at the end of {{left}}, and the LintError went away.. Mediawiki should be robust enough not to rely on contributors having to recall whitespace minutiae. The cause of the LintError generation in the latter example above is an already reported issue. ShakespeareFan00 (talk) 21:54, 3 February 2020 (UTC)

Does someone have a more elegant solution, that doesn't rely on creating groups of templates, to work around "known issues"?

The "known issue" being (T134469)

ShakespeareFan00 (talk) 21:54, 3 February 2020 (UTC)

These aren't entirely identical. the template has a line break in it, which will not play well with the colon as a margin setting device. Any any case, using a colon before a <div> is poor syntax. --EncycloPetey (talk) 23:44, 3 February 2020 (UTC)

That's partly why I asked if there was a better way to do this. (I'm trying to shift some entries on a specfic page), Is there a way to do that shift directly in markup, avoiding the need for a templated shift? ShakespeareFan00 (talk) 09:32, 4 February 2020 (UTC)

Noooo... you asked why one worked and the other did something different. If you identified the page, I could offer suggestions. There shouldn't be any reason to use a margin shift and a colon on the same section of text. --EncycloPetey (talk) 02:02, 5 February 2020 (UTC)

Page:Chronological_Table_and_Index_of_the_Statutes.djvu/402. which is using {{ws_diclist}}. I have a feeling a rethink of the nesting used in this work and the relevant template might be needed. ShakespeareFan00 (talk) 11:41, 6 February 2020 (UTC)

Page:Hill's manual of social and business forms.djvu/108

Perhaps someone here can come up with a way of doing this in a way that doesn't involve one template call for each definition (that actually works properly), instead of the approach here, which clearly does not work as intended, as evidenced here.

What is supposed to occur is that the definition list gets flattened, currently this is done using floats which is not ideal. Doing it as inline, results in there being no line-feeds and one large unformatted block which is as bad as no formatting at all.

I've tried to get this working in a sensible way and not got it to do so, perhaps someone else can?

It is increasingly "offensive" to find that well-intentioned approaches are running up against limitations in Mediawiki and CSS due to their apparent inability to cope with certain use cases. As I have said REPEATEDLY, expecting normal contributors to know the minutiae of under-documented internals in order to implement what should be relatively simple templates and moderate CSS is unacceptable. I do not appreciate having to essentially abandon templates (and change a LOT of invocations to code I know isn't that efficent) because Mediawiki or CSS can't apparently cope. ShakespeareFan00 (talk) 23:58, 5 February 2020 (UTC)

This page is an excellent example of when using poem tags is a good idea. Simply use a {{sc}} template for each lead term and then follow it with the definition. Do each entry on a different line, start and finish the page with poem tags, and it's all done without any need for extra arcane templating. Beeswaxcandle (talk) 02:32, 6 February 2020 (UTC)

Whilst that clearly works, it's going backwards in terms of performance.. I eventually solved the layout issue by updating the stylesheet using a ::before rule for DT elements (that creates a blank block for what would otherwise be an inline element, but that seems like a kludge that SHOULD not be necessary. ShakespeareFan00 (talk) 09:03, 6 February 2020 (UTC)

So, the KISS principle is not applied, all for the sake of getting a page onto someone's screen a few pico-seconds quicker? You asked for a solution that flattens the list, without using line-feeds or floats. This, I provided. I have no idea whether your supposed solution works as I cannot see any difference on the page between this morning, when I responded, and now. The page continues to have a proofreading error on every line, that cannot be fixed short of disposing of your (poorly explained) templates and strange initial punctuation on each line and then implementing a simple solution.

In terms of your comments about "offense", what is actually becoming offensive is tripping over these snide asides almost anywhere across the Wikisource namespace, including in edit summaries. There is no perfect solution to every situation out there. There never will be. Live with it and deal with it as best you can. Also, you complaining about poor documentation is somewhat hypocritical given the dearth of comments in your template code, and incomplete documentation subpages. Beeswaxcandle (talk) 09:33, 6 February 2020 (UTC)

The strange punctuation is definition list syntax, which when used for something that is a semantically "definition list" should have been an obvious use case. I'll certainly consider going back to the approach you suggested because apparently there are not only limits in Mediawiki, but in the ability and expertise of contributors to maintain certain solutions (for various technical reasons). ShakespeareFan00 (talk) 09:56, 6 February 2020 (UTC)

If you think the documentation pages are lacking, some hints on where there could be expanded would be appreciated, as I've tried recently to update some of it (and add some more comments in the CSS stylesheets, I've created.) ShakespeareFan00 (talk) 10:56, 6 February 2020 (UTC)

WRT to "performance": what metric are you even targeting? Pages are cached on save, so render times are generally negligible for readers, since they only need to be rendered once every now and again when changing templates and if it gets evicted from the cache. The Wikimedia servers aren't particularly overstressed AFAIK and the only technical "performance" limit you might run into is the template arg length, template depth or Lua memory usage. As long as the page renders, performance isn't something you need to be overly stressed about. If you want to be taken seriously when "optimising" anything in life, you should have some metric to show that it's 1) an issue and 2) you have a way to show a proposed remedy helps. You might also consider the size of the inline HTML/CSS as a metric, but that's just text so it's pretty small in general (100s of kB, maybe a few MB for the bigger works). Premature optimisation is famously the root of all evil.

WRT to "but that seems like a kludge that SHOULD not be necessary.", that seems like a ^{[citation needed]} moment. How exactly do you think this should be working, and how will you justify to the W3C committee or Mediawiki maintainers that your use case (transcribing a book's physical formatting from 1881 into HTML via Wikitext with some unspecified limit on "performance") merits the associated technical debt and should be considered when drafting web standards? It seems to me that TemplateStyles and CSS has almost entirely solved the whole issue very neatly (you're actually mostly lucky dt/dl is a good semantic fit and Wikitext has a convenient markup for it). Who says Wikicode and CSS has to "cope" with what you/we want it to do? Working with what you have is just reality. Inductiveload—talk/contribs 11:12, 6 February 2020 (UTC)

Having had a previous transcription effort blow out the template transclusion limit due to a lot of effectively repetitive calls, I was trying to minimise repeated use of a repetitious template call, 26*2 calls over an entire set of pages is going to be considerably lower workload than say 500 or more by doing a call to {{smallcaps}} on each new definition. On transcluding, TemplateStyles code is de-duplicated anyway isn't it?

Aside: reducing repetitive calls was partly why the Stylesheets of {{Table class}} were developed. BTW. I might need some assistance expanding the documentation.}}

Maxim: Don't make "opinion" calls when writing comments. If something really isn't necessary other better coders will tell you so, and why. Document what you did, why and leave it at that.. ShakespeareFan00 (talk) 11:26, 6 February 2020 (UTC)

I'm based on recent behaviour probably not the best person to comment on web standards, but the technical concern I had was that there should be cleaner way of forcing a new-line for a DT element, whilst maintaing the "inline" behaviour needed for the flat-line appearance. Having a force-newline/force break param (does that actually exist and I've missed it in the documentation?) would in this instance be useful to explicitly state to a browser or web client that was the desired rendering approach. ShakespeareFan00 (talk) 11:32, 6 February 2020 (UTC)

Right, but how exactly do you think it should work? What do you want to write in the editor and what do you want to see pop out? And when you say "force-newline/force break param", do you mean in Wikitext, HTML or CSS?

Wikitext is already throwing you a bone with mapping ; and : to dt and dd but the line-breaks and the requirement for ; to occur at the line start is always going to be a "thing" (and it's a "thing" in HTML in general: e.g. here):

; Term
: Definition

gives

<dl>
<dt>Term</dt><!-- look ma, a line break, this is why there's a space after your em-dash -->
<dd>Definition</dd>
</dl>

whereas what you want is this:

<dl>
<dt>Term</dt><dd>Definition</dd>
</dl>

I'm pretty sure you're just out of luck here - I can't imagine any way to indicate to Mediawiki that a certain bit of wikitext must have render out to collapsed whitespacing which wouldn't be overly complex to implement or use. Perhaps the best way is simply a per-line template and defer to TS CSS. Then you only have 'n' template calls and the inline content is "short":

<span class="__hillforms_term">{{{1}}}</span>—<span class="__hillforms_def">{{{2}}}<span>

Maybe add li or dt/dd as you see fit. Maybe you hit the limit due to the many many templates, in which case, split the index. Annoying, but que sera sera. Yes, sad that Mediawiki's magic ; didn't quite cut it this time, but this is far from what it was designed for. A quick experiment indicates that 1000 calls of a template like the above result in: Post-expand include size: 120,000/2,097,152 bytes, so you can fit somewhere around 15k template calls like that on a page before you surpass the template limits. Respect for peoples scrolling fingers should prevent you considering a 15k line page in the first place.)

WRT to documentation: "TODO: This model isn't ideal." is not a helpful comment if you're expecting someone non-telepathic to help you. Inductiveload—talk/contribs 12:23, 6 February 2020 (UTC)

Inductiveload—talk/contribs 12:23, 6 February 2020 (UTC)

Let's move the extended discussion to the talk page of the relevant Template? ShakespeareFan00 (talk) 13:05, 6 February 2020 (UTC)

Yes, but please take some time to ponder before creating a new template. Creating a template means to expose an API to users and commit maintainers to cope with it from now on. To "undo" a template can be very tricky and require a lot of effort. Also, you are not new in proposing deletion of your own templates, as being too complex etc.. Mpaa (talk) 21:45, 6 February 2020 (UTC)

ditto inside dotted TOC

On this page, it looks like {{ditto}} doesn’t work quite right inside {{Dotted TOC line}} (too far to the left}. Can anyone figure out why that is? Levana Taylor (talk) 02:17, 6 February 2020 (UTC)

@Levana Taylor: You poor thing. You seem to have bad luck with CSS issues! {{Dotted TOC line}} sets CSS attribute text-indent to 1em unless overridden by hi. {{ditto}} does not cope well with text-indent set to anything other than 0. You could either follow the rather clunky advice here and add the <span> suggested; or set hi=0 on the lines affected. 114.78.171.144 07:17, 6 February 2020 (UTC)

Template:Ditto/testcases#Testing_sandbox_version, the fix suggested in the documentation doesn't appear to work when directly implemented as patch to the template. ShakespeareFan00 (talk) 08:58, 6 February 2020 (UTC)

Perhaps someone needs to rethink the approach used by both templates? ShakespeareFan00 (talk) 09:01, 6 February 2020 (UTC)

Your sandbox has tow issues: one was a mismatched brace {{{embed|}}, and the other was the testcases had the embed parameter set on the outer {{hi}} template, not on the inner {{ditto}} template. Seems to works now. The question now is: are there any cases where setting text-indent:0 on the ditto is wrong (and therefore the embed parameter should be optional), or should it just be always set by the ditto template on its outer span (along with position:relative, etc)? Inductiveload—talk/contribs 10:17, 6 February 2020 (UTC)

According the CSS spec itself, text-indent:0 is the correct approach for display:inline-block element inside an indented block. Testcases and a quick survey of usages indicate it isn't breaking anything, and Levana's issue is fixed too. Inductiveload—talk/contribs 13:08, 6 February 2020 (UTC)

@Inductiveload: Thank you for fixing {{ditto}} and for doing the due diligence on why the fix is correct. 114.78.171.144 14:17, 6 February 2020 (UTC)

Maxim: "It's always a minor typo or mis-syntax if you think something is really broken!" I think it's time I took a break. I seem to be making too many mistakes of this type, which tragically leads to the kind of angry ranting (see many previous instances in the archives and edit summaries) that is not conducive to effective coding or documentation. ShakespeareFan00 (talk) 10:58, 6 February 2020 (UTC)

@Levana Taylor: Please note a small but important change to Page:Once a Week…/10 remains. For correct operation of {{ditto}} the repeated/hidden text fragment must be both identical and followed in each case by identical white space. i.e. the matching context should not change within any group of lines where the alignment effect is desired. 114.78.171.144 14:17, 6 February 2020 (UTC)

Yes, thanks, noted. Thanks to everyone for working on this. Levana Taylor (talk) 14:51, 6 February 2020 (UTC)

Misbehaving footnote

Esme Shepherd (talk) 19:38, 6 February 2020 (UTC) I have a footnote over three pages in Traits and Trials.pdf/pages 175-177 (book pages 169-171). These are enclosed by: page 175 <ref name=p169> </ref> page 176 <ref follow=p169> </ref> page 177 <ref follow=p169> </ref> However, on pages 176 and 177, the footnote text does not appear, only the legend ⧼cite_references_no_link⧽ I have done this many times before and, if I have made a mistake here, I can't see it. I have transcluded the whole story and the footnote does appear correctly at the end in all its portions. So that is okay, but these pages still need validation. Can you resolve this mystery for me?

You've done nothing wrong. It's a change in the software that wasn't backed out correctly. See WS:S#New error messages for the attribute “follow” for more details. It will be resolved. Beeswaxcandle (talk) 20:06, 6 February 2020 (UTC)

Esme Shepherd (talk) 22:18, 6 February 2020 (UTC) Thank you. Glad I have nothing more to do!

Updating obsolete Greek characters

In Newes from the Dead, I am trying to find a balance between updating character glyphs, and preserving original spelling. Per our common practice, I am updating ſ to s, but preserving characters like æ, œ, and &. I have also opted to preserve spelling features such as q́ꝫ (que) and (ος)—to me, these appear to be intrinsic spelling features, like preserving æ rather than expanding to ae.

However, there is a Greek word on page 8, spelled as follows: ὑςερόϖοτμον. This features two obsolete character choices: the use of ς mid-word instead of σ, and the use of ϖ instead of π. I do not know enough about these characters to determine what side of the balance these characters should fall on. Given the guidelines I have outlined above, should this word be transcribed per the original, or updated to ὑσερόποτμον? (Or perhaps, should only one of the characters be updated?) —Beleg Tâl (talk) 13:40, 6 February 2020 (UTC)

I'm not sure about the "pomega" (I think ϖ/π is basically equivalent to ſ/s, but I'm not sure), but that sigma actually is probably a Stigma, not a final-sigma, which makes the word υστερόποτμος, which makes some sense in the context of the work: supposed dead. Inductiveload—talk/contribs 13:54, 6 February 2020 (UTC)

Fantastic, thank you! I have updated the page to use the stigma ὑϛερόϖοτμον. I hope someone is able to answer regarding ϖ vs π, especially since the word also appears in the subpage title. —Beleg Tâl (talk) 14:15, 6 February 2020 (UTC)

Having done a bit more research, it looks like ϖ is the same type of alternate-glyph as ϐ, ϑ, and ϕ (cf. β, θ, and φ), so I will update it to π unless someone gives me a very good reason to do otherwise. —Beleg Tâl (talk) 14:23, 6 February 2020 (UTC)

 Comment I wouldn't have seen that we would necessarily have modernised the characters along the lines of long-ess to ess. The long-ess/ess conversion is about readability for our works, whereas the representation of the old Greek will be like like like like "all Greek to us" for many, so showing it "as is" is probably okay especially to the literal reader. I can see some value for someone doing a literal search for the characters, both for and against this case. — billinghurst sDrewth 04:42, 7 February 2020 (UTC)

From what I could tell, ϖ/π is less like ſ/s, and more like ɑ/a. Using ɑ in ɑ trɑnscription is not showing it "ɑs is" even if the letter ɑppeɑrs more like ɑ in the scɑn. The character ɑ exists for symbolic use, whereɑs the chɑrɑcter for the letter itself is a. It appears that the same is true of ϖ. —Beleg Tâl (talk) 13:28, 7 February 2020 (UTC)

Content model change - User:ShakespeareFan00/Sandbox/styles.css

Can this be changed from "CSS" to "Sanitized CSS" so I can use it for testing purposes? ShakespeareFan00 (talk) 09:15, 9 February 2020 (UTC)

Template:Uksi/doc

Whilst I understand some people aren't necessarily willing to talk to me right now given recent events, I wanted to ask if the documentation here is comprehensive enough. I'm slowly trying to document the various varaints of the template family in once place. I also added some comments to the core template (and the associated stylesheet), to try and explain what the code and styles are either doing or attempting.

If on the other hand certain contributors feel that replacing this wholesale with much more basic direct formatting templates directly in indviidual Page:'s would be easier for them to understand, then the loss of standardisation is perhaps justified. ShakespeareFan00 (talk) 11:41, 10 February 2020 (UTC)

@ShakespeareFan00: It generally looks nice. But for me, and this may just be me, I feel I need some examples to understand what's going on. Maybe a scan image for reference, and a two-column table showing the wikimarkup and the rendered output? Or maybe just a couple boxes showing the rendered output? Something that lets me visualise what the problem is that the template is trying to solve, and how it solves it. Then again, for someone that works often with this kind of text (and thus would be most likely to use the template) it may be blindingly obvious and the examples just needless clutter.

PS. I am very glad to see templates—even special case and per-work templates—get some love in the documentation department. It makes it sooo much easier for those who try to use them, and for anyone trying to maintain them later. We could probably all take this opportunity to remind ourselves that we can do better at documentation (I know I certainly can). :) --Xover (talk) 13:28, 10 February 2020 (UTC)

Page:Food and cookery for the sick and convalescent.djvu/17

Am I just being completely blind in my thinking here?

A locally set inline style with {{ts}} seems to be overriden by an inline one that's by an imported style-sheet.

I'm seriously considering giving up contributing long-term, because I don't seem to know enough to do it with it being completely inept. ShakespeareFan00 (talk) 00:44, 11 February 2020 (UTC)

@ShakespeareFan00: Now that page and the next at least display correctly separately. I haven't tried transcluding them together, of course. Does that help? —Justin (koavf)❤T☮C☺M☯ 01:06, 11 February 2020 (UTC)

That solved the issue for this specific example. What I was trying to do was to come up a way of doing a TOC like this using a simple table, and a stylesheet. I'd still like to understand why my attempts didn't render quite the way I thought they logcally should. (Stylesheet for the general case) and local or inline override for the header rows.). If imported styles are going to interact with inline ones in ways that aren't expected, then I'd ideally like to know where those interactions are likely to occur, so the relevant stylseheets can be designed accordingly. ( I already had to change the design of one stylseheet because certain rules interacted unexpectedly.). I also don't want to continually waste my (or other contributors) time trying to implement approaches, that seem to be incompatible with Mediawiki, other templates or as I'm increasingly finding the views and expertise of other long-standing contributors.ShakespeareFan00 (talk) 08:59, 11 February 2020 (UTC)

I have had trouble with conflicting CSS in the past as well and I tried !important rules that just got ignored by the software. :/ —Justin (koavf)❤T☮C☺M☯ 09:07, 11 February 2020 (UTC)

The question asked perhaps should have been, "In what order styles from are styles, applied? and how is the priority of conflicting rules applied?" , I have nasty feeling it might be browser-specific in terms of conflicting rules within an indvidual stylesheet, or as in the above example differing rules being applied inline to a parent, compared to a specfic rule on a child.. Perhaps someone should look into this more closely? ShakespeareFan00 (talk) 09:17, 11 February 2020 (UTC)

(Aside) Is there something like jsfiddle in the Wikimedia sphere? ShakespeareFan00 (talk) 09:17, 11 February 2020 (UTC)

The rule of thumb for CSS selectors is that specificity wins: a selector targeting a specific class will get overridden by a selector targeting an element with a class (specifying both the element name and the class makes it more specific). Inline styles (in the |style= attribute on an element override styles given in a stylesheet. !important should really not be used, but is, sadly, sometimes necessary in practice to get things to work (but try really hard to avoid them).

For Wikimedia wikis, the sources of styles I can think of are the basic styles of MediaWiki itself; the active skin (e.g. Vector); the project's Common.css; the individual user's common.css and skin.js; TemplateStyles; and styles set by JavaScript from either the project's Common.js, Gadgets, or user's common.js or skin.js; the user's browser's default stylesheet (which may be modifiable through preferences dialogs and such in some power-user browsers); and the user's browser's user stylesheet if set.

TemplateStyles will have a pretty high specificity because the extension does some magic to scope its effects to just the page content area (i.e. so it won't modify the toolbar or other site chrome). The style stuff on tables should have precedence essentially the same as an inline style attribute (I believe the parser transforms that wikisyntax to a HTML style attribute). Styles set from JavaScript will be essentially impossible to override from CSS, because they will typically be applied after CSS and override CSS styles unconditionally.

In the specific example here, without digging into it, I would also have expected your approach to work (the inline style provided by {{ts}} should have overridden styles from a stylesheet). However, provided I'm looking at the correct old revision, you're setting the style on the table row (tr), but the skin has a rule that targets the table cell (td). In other words, your inline style provides the default for inheritance, but the skin sets it directly. In addition, both "Chapter" and "Page" are the widest item in their column—i.e. the width of the column is determined by the width of the respective word—and so even if these were centered, the following cells in those columns will be aligned with the header's right edge, which looks like the whole column is right-aligned.

I can't dig in any detail right now, and I may have misunderstood depending on which revision of the page you referred to initially, so I don't want to go wading in there making changes. But hopefully something above may help you figure out the problem. --Xover (talk) 10:06, 11 February 2020 (UTC)

Can you copy this explanation to the Stylesheets talk page? Template talk:Table class/toc.css and we can continue the technical discussion on how to resolve it there? ShakespeareFan00 (talk) 11:35, 11 February 2020 (UTC)

Error in Index namespace title

How can I move this index from Index:A Prisoner of the Khalifa.djvu to Index:A Prisoner of the Khaleefa.djvu and have the pages align? — Ineuw (talk) 20:31, 10 February 2020 (UTC)

I have found it helpful to create a dummy page Page:A Prisoner of the Khalifa.djvu, and then move it with the "also move subpages" option enabled, and then delete the dummy page afterwards. —Beleg Tâl (talk) 20:35, 10 February 2020 (UTC)

(I also have found it helpful to ignore typos in File and Index page titles, because it doesn't really affect the final product. —Beleg Tâl (talk) 20:41, 10 February 2020 (UTC))

@Beleg Tâl:Thanks for the advice ths process is unclear to me. Followed your recommendation and I got the error message:

The page could not be moved, for the following reason: 
"Book page" content is not allowed on page Index:A Prisoner of the Khaleefa.djvu in slot "main"

I think the reason is that the file in Commons is called File:A Prisoner of the Khalifa.djvu and the name of the Index page has to correspond to it. So if you want to move our Index page, you need to move the Commons file first. I agree with Beleg Tâl that it is not necessary, the name of the Index page is insignificant. --Jan Kameníček (talk) 21:33, 10 February 2020 (UTC)

@Jan.Kamenicek: Thanks for the comments but I must learn the process. The commons category and book title has been changed and 100 pages were moved which is the limit. After this I am stuck. Also the moved pages are not in sequence. Already created the Index page. These are the questions that's keeping me awake at night. Could you please help me through this please? — Ineuw (talk) 04:55, 11 February 2020 (UTC)

Just recreate the forged Page:....djvu page and move it and the next 100 subpages. Rinse, repeat until complete. The pages are in a sequence, it is just not numerically ordered.

Moving it without a good reason is just a dumb reason, and this is what we were saying. The order of moving doesn't matter BUT it won't all be functional until it is all aligned. In the end the Index: / Page: / File: all need to align in their names, and then the transclusions need to be fixed and each of those is just an opportunity to create errors, and to have to run numerous checks for no designated value. So, we suggest not to move them without a good reason. — billinghurst sDrewth 07:10, 11 February 2020 (UTC)

NB! You now have ~100 redirects as subpages of that dummy page. I have no idea what will happen if you try to move the dummy page while those exist: my worry would be that you could end up in a situation where the redirect pages (which are new pages without edit history that were created by the first move) are moved over and overwriting the real pages (where all the content and edit history are). There are lots of reasons why that shouldn't happen, but I can imagine some circumstances where it would so I would recommend being very careful about that. Since the goal is to move everything anyway, I would recommend deleting those redirects before trying to move the next batch. --Xover (talk) 07:23, 11 February 2020 (UTC)

Dumb reason or not, I must learn and know what happens for numerous reasons. In any case corrected the file name on the commons and made the move for the first one hundred pages and so far it seems good. The loss was negligible and they are easily recreated. My next concern is to deal with the Page:A Prisoner of the Khaleefa.djvu file. Thanks for everyone's advise, warnings and concerns. — Ineuw (talk) 14:28, 13 February 2020 (UTC)

@Billinghurst: My last question is about the main namespace title. Internally I used A Prisoner of the Khaleefa but the full title is A prisoner of the khaleefa. Twelve years captivity at Omdurman (1899). This is how the title is written everywhere except in the printed book where the whole title is in uppercase which provides no clue. Can you please advise. Thanks. — Ineuw (talk) 19:23, 14 February 2020 (UTC)

Pick one and redirect from the other. I generally try to utilise the most unambiguous and how it most common referred (and these can be different). I doubt that the year is in the title. Here I doubt I think I would have gone for the shorter title as the primary for PAGENAME, and used the title and subtitle in the title parameter. (said without better exploring) — billinghurst sDrewth 11:23, 16 February 2020 (UTC)

Thanks for the advice. I will look into the possibility of incorporating the long name into the SUBPAGENAME. — Ineuw (talk)

Page:The Heimskringla; or, Chronicle of the Kings of Norway Vol 1.djvu/240 - Second view sought.

As the sidenotes here are in effect chapter headings, is the approach here worth continuing with, given that setting up a 'forced' layout is actively discouraged for browser compatibility issues? ShakespeareFan00 (talk) 10:35, 14 February 2020 (UTC)

What to do about this printer's error?

On this page, the printer printed a line which had already been printed in the main text (and clearly belongs there) in between two of the footnotes. I tried to address this using the {{annotation}} template, but I'm not sure that's the way to do it -- and even if it is, I think I did it incorrectly. Could I get some more expert eyes on this one? -Pete (talk) 22:03, 14 February 2020 (UTC)

I would comment it out using <!-- --> comment tags. That way the validator can see it, but it doesn't get reproduced in the text. Beeswaxcandle (talk) 22:09, 14 February 2020 (UTC)

That makes sense to me. To my eyes it's clearly an error, and there's no need to reproduce it for the reader...but I know that view can sometimes be out of step, so I wanted to make sure. Thanks for the guidance. -Pete (talk) 23:02, 14 February 2020 (UTC)

Pete, I would <noinclude>'d it and either {{SIC}}'d or left a rem'd comment. — billinghurst sDrewth 11:04, 16 February 2020 (UTC)

Agreed. I there are many times when it's totally valid to not reproduce exactly what was published on the page and this is a good one. An HTML comment is a good way to make sure that this is recorded for the benefit of editors rather than readers. I also downloaded it as a PDF and the HTML comment is removed entirely. —Justin (koavf)❤T☮C☺M☯ 23:16, 14 February 2020 (UTC)

Index:Railway Accident Investigation Report on Amagasaki derailment-English version.pdf

I am recently trying to edit Index:Railway Accident Investigation Report on Amagasaki derailment-English version.pdf. However, the source file (.pdf) also included some photos. How should these photos be dealt? Many thanks.廣九直通車 (talk) 07:49, 11 February 2020 (UTC)

Also somehow the OCR is not working.廣九直通車 (talk) 12:21, 12 February 2020 (UTC)

@廣九直通車: Great points. Re: the photographs, are you sure that they have a free license? If so, they should be inserted into the text. Probably the fastest way to get copies of the photos and insert them would be to go to the file at Commons, makes sure that you have CropTool activated, and extract individual files. As for the OCR, we have some sitewide problems with the default OCR. You can use alternatives like Tesseract (go to User:廣九直通車/common.js and insert "mw.loader.load( '//wikisource.org/w/index.php?title=User:Putnik/TesseractOCR.js&action=raw&ctype=text/javascript' )") or Google OCR instead. I hope that's not too much info dumped on you all at once. Let me know if you need more help. —Justin (koavf)❤T☮C☺M☯ 12:54, 12 February 2020 (UTC)

@Koavf:Yeah, I am pretty sure that the source scan is free (Template:PD-JapanGov:(R)ulings and judgments made by government agencies in proceedings of a quasi-judicial nature, and as the official translation). But the source scan does not come with the text layer. Anyways, I'll try with your suggestions, thanks.廣九直通車 (talk) 04:05, 13 February 2020 (UTC)

Seems that the Google OCR works well with this document, and it is also quite fast, so I recommend it. If you had some problems, I can provide the OCR text there too. --Jan Kameníček (talk) 11:01, 13 February 2020 (UTC)

• @Jan.Kamenicek, @Koavf:OK, now met with another problem:I just found the translated source scan is missing with some parts (I originally thought the excerpt means omitting some images). Should I note down "excerpt" in the title, or what should I do? The author has Japanese original text, but is seriously distorted. —unsigned comment by 廣九直通車 (talk) .

  @廣九直通車: First off, you need to sign your posts with four tildes (~~~~) for {{ping}} to work. Secondly, if I understand you correctly, are you saying that the PDF is missing pages? And furthermore, do you have the missing parts somewhere? —Justin (koavf)❤T☮C☺M☯ 13:43, 13 February 2020 (UTC)

  Yeah, it seems that the official translator just missed off some parts of the original report in Japanese.廣九直通車 (talk) 03:34, 14 February 2020 (UTC)

  You can transcribe the official translation and make a note that some parts are missing. You can also make an annotated version were you would add the missing parts (after translating them to English). Or you can make a Wikisource translated version with your own translation of the whole document. --Jan Kameníček (talk) 08:19, 14 February 2020 (UTC)

• OK, I give up. I can't translate the remaining Japanese into English, and perhaps it will be better if was the Japanese version get imported in Japanese Wikisource. Perhaps this try is better to be an exercise on dealing PDF texts.廣九直通車 (talk) 11:38, 17 February 2020 (UTC)

Page number in red

On The Poems of Sappho/Chapter 4, why is the page number for page 136 and several other pages showing in red? That's supposed to indicate the page hasn't been created, but when the page exists (as it does in this case) the page number should be displayed in blue. Neither null edits nor hard purges have any effect on this.

The only common factor seems to be that each affected page opens with red-linked text. Is the red link from the page text being incorrectly passed to the display of the page number? --EncycloPetey (talk) 22:14, 18 February 2020 (UTC)

Yep, it is a weird artefact of the page numbering. If you put a leading {{nop}} it disappears. I usually just create the link (author page) and it goes away. — billinghurst sDrewth 22:57, 18 February 2020 (UTC)

Creating the Author pages is a bit of a tricky issue for this bibliography. The first author on p136 is Louis Poinsinet de Sivry, who is an 18th-century French classicist. I do not know whether any English translations of his works exist, but it is unlikely that an English translation of the specific work cited would exist because the work is a French translation form the Greek, and who would translate a French translation of a Greek original? When I can find a native language Wikisource Author page, I link to that if one does not exist here. Failing that, I look for an English Wikipedia article. But Louis Poinsinet de Sivry does not have a page on the French Wikisource, nor on the English nor French Wikipedia. The only pages I find at Wikidata are on the German and Russian Wikipedias, neither of which would be helpful as a link. I may just de-link him. --EncycloPetey (talk) 00:02, 19 February 2020 (UTC)

┌──────┘
Capturing the html from the four page change overs (135, 136, 137, 138)—and not making any determination.

• [135] which is continuing text

... translated into&#32;<span><span class="pagenum ws-pagenum" id="135" data-page-number="135" title="Page:The_Poems_of_Sappho_(1924).djvu/141">&#8203;</span></span>English Verse; with Notes explanatory and poetical. To which are added the Odes, Fragments, and Epigrams of Sappho. London, 1735. 8vo. Sappho, pp. 247–279.
</p>

• [136] where a {{nop}} (div) has been forced prior to the text

<div></div>
&#32;<span><span class="pagenum ws-pagenum" id="136" data-page-number="136" title="Page:The_Poems_of_Sappho_(1924).djvu/142">&#8203;</span></span><div></div>
<p><a href="/w/index.php?title=Author:Louis_Poinsinet_de_Sivry&amp;action=edit&amp;redlink=1" class="new" title="Author:Louis Poinsinet de Sivry (page does not exist)"><span style="font-variant:small-caps">Sivry, Poinsinet de</span></a>. Anacréon, Sapho, etc., traduits en vers Francais. Poésies de Sapho de Mytilene, pp. viii, 24. Nancy, 1758. 8vo.
</p>

• [137] where the [ of a redlink abuts the top of body text

<div></div>
<p>&#32;<span><span class="pagenum ws-pagenum" id="137" data-page-number="137" title="Page:The_Poems_of_Sappho_(1924).djvu/143">&#8203;</span></span><a href="/w/index.php?title=Author:J.J._Mouteonnett-Clairfons&amp;action=edit&amp;redlink=1" class="new" title="Author:J.J. Mouteonnett-Clairfons (page does not exist)"><span style="font-variant:small-caps">Moutonnet-Clarifons</span>, J. J.</a> Anacréon, Sapho [pp. 95-118], Bion, et Moschus, traduction nouvelle en Prose. Paphos and Paris, 1773. 4to. (In 1780 another edition was issued, with illustrations by Eisen.)
</p>

• 138 use of which is span

<div></div>
<p>&#32;<span><span class="pagenum ws-pagenum" id="132" data-page-number="132" title="Page:The_Poems_of_Sappho_(1924).djvu/138">&#8203;</span></span>Anacreontis et Sapphonis Carmina Tanaquillus Faber. Saumur, 1670. 24mo.
</p>

and noting the <p> marker differentiation. (Full analysis of difference required.) — billinghurst sDrewth 01:07, 19 February 2020 (UTC)

@EncycloPetey: the quick and easy solution is to use {{nop}} at the start of the page on this occasion, rather than to terminate the page before. Yes, out of general guidance, though same difference in the end. It is an artefact of the positioning of the <p> though I cannot tell what mediawiki and the javascript for page numbering are doing differently. (beyond me). — billinghurst sDrewth 01:21, 19 February 2020 (UTC)

@Billinghurst: Umm. Gulp! I vaguely recall persuading George Orwell III to look at a related matter over five years ago: the result of which was this tweak which if I recall did the job but did not entirely satisfy either of us. Perhaps this latest case demonstrates the folly of acting on the redlink status of .parentNode.nextSibling (the implications of which wasn't well understood even back then and the parser has definitely changed since.)

As I recall GOIII wanted to make all page links "blue" without checking which would "hide" any problems but I had to open my fool mouth… 114.78.66.82 09:28, 19 February 2020 (UTC)

At worst a minor annoyance, and something that I have usually resolved by creating the author page. — billinghurst sDrewth 10:51, 19 February 2020 (UTC)

Ugh. We desperately need to clean up that script! When you don't control the dingus that creates the markup (the parser), traversing the DOM in this way is really fragile. Even though the failure mode in this particular case isn't catastrophic, it all adds up to the "death by a thousand cuts" that makes the site behaviour seem so arbitrary and confusing (especially for new and non-technical users). --Xover (talk) 11:17, 19 February 2020 (UTC)

@Xover: The shame is the users who best understood what you call "the dingus" were, in turn probably ThomasV and Eliyak, both of whom as far as I know have long ago left the project(s).

Rather a long shot but Tpt might have some knowledge in his capacity as Extension:ProofreadPage wrangler? 114.78.66.82 11:47, 19 February 2020 (UTC)

The biggest problem there is that MediaWiki:PageNumbers.js is unconditionally loaded for everyone from MediaWiki:Common.js, and it modifies the DOM on every page on the site (it then hides its toolbar entries in namespaces where it's not supposed to be active, but the DOM is still polluted). The net result is that it's impossible, in practice, to debug such issues, and impossible to experiment with new versions of the script (the old script always overwrites whatever you try to do in the new version). I have a long-standing edit request for a change to at least start this road, but due to our not-quite-functioning Interface Admin policy it's been lingering on unaddressed. With a clean DOM to examine it should be entirely manageable to at least figure out whether we can set redlink/bluelink status reliably, and, if not, discuss and decide which tradeoff to make on that (e.g. all-bluelinks vs. sometimes misleading redlinks). --Xover (talk) 12:27, 19 February 2020 (UTC)

A workaround for that is to add https://en.wikisource.org/w/index.php?title=MediaWiki:PageNumbers.js to your adblocker. For me, adding exactly that line to uBlock Origins "My filters" panel blocks the loading of the script and the page numbers logic never fires. This then means you can load your own locally-served or userspace JS as you wish. Inductiveload—talk/contribs 20:54, 19 February 2020 (UTC)

Proofread UI: I experimented with "Proofread tools" and layout, I regret that, need course correction

I wanted to try out the alternate layout during proofread editing, so I clicked "Proofread tools" and then the rightmost icon (popup text "Vertical/horizontal layout") under "Other". That 'worked'. Didn't like the interposed controls and spacing. Then I wondered if the other icon (popup "Show/hide this page's header and footer") might change things 'betterorer'. Decided I didn't like the alternate layout (or the colored formatting or the misplaced special character insertions) and so tried to change back. Whoops.

I can't get back to the original editing layout of edit textbox with page image to its right side - two columns. Instead the textbox is now always full screen width, and headers/footers below that along with page image to its right - so three sections. I'm stuck with something now unusable.

I've tried clearing cookies - no help. I tried using a different browser, which is okay until I login. Thus this bad setup is remembered at Wikisource.

When in preferences under Editor I disable "Enable the editing toolbar", all is well again, with edit having two side-by-side columns. But then I'd lose "Special Characters". I've tried the other settings (e.g. horizontal layout) but can't get the two column layout back.

Known problem? Kinda bad when you can't reverse course... Shenme (talk) 23:09, 19 February 2020 (UTC)

@Shenme: Not a known issue, and I can swap back and forth without ending up in the state you describe. Do you have any adblocker browser plugins, or other such that might conceivably interfere with loading of javascript or stylesheets, or insert themselves somewhere in the web page that might confuse the scripts handling the layouts? Do you have any particular gadgets enabled in the Gadgets section of the preferences here? There was also a software update to MediaWiki yesterday that made some changes to the editor. Did the situation by any chance improve? --Xover (talk) 18:03, 20 February 2020 (UTC)

In usual browser, disabled in-browser adblockers with no change. And with no out-of-browser adblockers, the attempt with another browser should have tested that, but there was no improvement there either. And again, the problem followed the logged in state.

Depressed and panicked, I tried the nuclear option, in Preferences "Restore all default settings (in all sections)". So far, that seems to have worked. So... there *is* something noxious I selected or accidentally strobed, that has now been reset. *If* I get adventuresome, there might be a postscriptum later. Dragons be here. Shenme (talk) 20:47, 20 February 2020 (UTC)

DJVU index not functioning properly

For this index page, (a) the forward- and back-navigation buttons do not appear on each page, and (b) the transclusion code in the main work does not pull the pages in. What am I missing? Index:Frances Wood Shimer 1826-1901.djvu -Pete (talk) 22:31, 24 February 2020 (UTC)

I have no clue how this is even possible. I suggest a phab: ticket. —Justin (koavf)❤T☮C☺M☯ 22:40, 24 February 2020 (UTC)

OK, will do @Koavf:. Thanks! -Pete (talk) 23:14, 24 February 2020 (UTC)

@Peteforsyth: It was this stuff introduced in this edit. Since there was no valid <pagelist … /> tag on the index, there was no way for ProofreadPage to find the pages for the Previous/Next links in the Page namespace or the <pages … /> tag in mainspace.

That escaping of | looks like something pretty MediaWiki specific: do you perhaps have any user scripts enabled that might conceivably have interfered? Bits of Twinkle or Popups cross-loaded from enwp, say? I can't really think of a likely culprit for that particular breakage: the fields you see in the diff are parts of the storage format for Index: pages and are never really exposed to the user. You need to get the wikitext through the API to see it, so it can't really be simple user error. --Xover (talk) 05:42, 25 February 2020 (UTC)

thanks @Xover: It must have been a script, I do have several in my profile. It could also be an interaction with my javascript-blocking browser extension (umatrix), though I have it set to allow everything for *.wikisource.org, so I kind of doubt that is interfering. I guess I'll keep an eye out for it happening again, and only worry about it if it's more than a one-off. -Pete (talk) 10:34, 25 February 2020 (UTC)

Metadata standards

What metadata standards does Wikisource use? —unsigned comment by Michaelbland1901 (talk) .

@Michaelbland1901: have a look at mul:Wikisource:Metadata for some of this information —Beleg Tâl (talk) 22:21, 27 February 2020 (UTC)

Index pagelist offset problem

I have a problem with an index file where page 1 image displays the text of page 2. Is there any way to fix that? I tried things like 0=1 and 1=0, but to no avail.

Index:Mormonism.djvu

Don Elbourne (talk) 15:12, 28 February 2020 (UTC)

@Don Elbourne: It's a combination of insufficient validation at IA, with ditto in DjVuLibre, and a bug in MediaWiki. There's no on-wiki way to fix it, but I've regenerated the file from the source scans in such a way that it will no longer trigger the MediaWiki bug, and the page offsets should be ok now. --Xover (talk) 17:47, 28 February 2020 (UTC)

@Xover: Thank you! -- Don Elbourne (talk) 18:07, 28 February 2020 (UTC)

Documenting ambiguous authorship

In the Imperial Dictionary of Universal Biography, vol. 1, page 404, three segments in sequence appear (undeniably, in my opinion) to all have been written by a single author. In sequence, the author initials are J. H. B., J. B., and J. H. B.. Both sets of initials can be found in the List of Contributors. The middle segment makes reference to the preceding segment. All segments are logically appropriate to author John Hutton Balfour, M.D., F.R.S., Regius Professor of Botany, Edinburgh University. In the middle segment J. B. initials are not perfectly legible in the Wikimedia specimen image. In my physical copy it is more clear but definitely cannot justify insertion of H.
To whom do I ascribe authorship of the middle segment? If it were attributed to Balfour, how would this be documented? 11:23, 3 March 2020 (UTC)
https://en.wikisource.org/wiki/Page:Imperial_Dictionary_of_Universal_Biography_Volume_1.pdf/438 Klarm768 (talk) 11:31, 3 March 2020 (UTC)

It depends somewhat on how attribution is handled elsewhere in the work, but I'd probably do contributor = James Brown and notes = This article may be misattributed and is probably by [[Author:John Hutton Balfour|]] or something like that. If you're certain it's by Balfour, you can just put contributor=John Hutton Balfour. —Beleg Tâl (talk) 13:55, 3 March 2020 (UTC)

Thanks. If it were your decision, would any acknowledgment/provision be made in list of works of Author:James Brown (1835-1890) mentioning any attribution of J. B. initials having been assigned to a different author? Klarm768 (talk) 14:40, 3 March 2020 (UTC)

If it were my decision, I would only note on the author page of James Brown that he was a contributing author to the Imperial Dictionary, but I would not bother listing the individual articles. —Beleg Tâl (talk) 14:42, 3 March 2020 (UTC)

File:Maharashtra Anti-Superstition and Black Magic Act.pdf

Does File:Maharashtra Anti-Superstition and Black Magic Act.pdf qualifies "Act of a Legislature" defined in Indian copyright law as per Template:PD-INGov? Many thanks.廣九直通車 (talk) 14:00, 3 March 2020 (UTC)

It looks to me that it is an "Act of a Legislature" as per the Indian law (and also an "edict of government" as per US law), even though it is by a state government rather than by the Government of India. —Beleg Tâl (talk) 14:29, 3 March 2020 (UTC)

Well, I have transferred the file to Commons now.廣九直通車 (talk) 13:51, 4 March 2020 (UTC)

Volume 31 of a journal is in commons

File in commons is a volume of the Journal of American Folk-Lore. How do I correctly move it to Volume 31? Meaning how do I name it?

Here is the file in commons. I don't want to mess it up. If someone knows how to, would you mind doing it so that I can begin transcribing. Also it is in English with Spanish text. Regards to all. --The Eloquent Peasant (talk) 17:27, 3 March 2020 (UTC)

This is only one issue from the volume. I have uploaded the complete volume from the Internet Archive at Index:Journal of American Folklore vol. 31.djvu. This issue (Number 121) starts on page 289 (which is Page:Journal of American Folklore vol. 31.djvu/299).

You can probably just leave File:Porto-Rican_Folk-Lore._Décimas,_Christmas_Carols,_Nursery_Rhymes,_and_Other_Songs.djvu alone. Inductiveload—talk/contribs 18:00, 3 March 2020 (UTC)

@Inductiveload: Thank you! --The Eloquent Peasant (talk) 00:27, 4 March 2020 (UTC)

Metadata standards

Does Wikisource use Dublin Core metadata standards? —unsigned comment by Michaelbland1901 (talk) .

@Michaelbland1901: I think that it would be honest to say that we are somewhere on the metadata spectrum between clueless and crap. In the early years there wasn't much scope, and you see a bit of a conversation at Wikisource:Scriptorium/Archives/2011-08#Template-generated Dublin Core metadata. At this stage we have tags in our header and author templates to try and capture data. When someone comes to us with a good solution, and maybe one that involves use of wikidata, then I think that would be great.

We are good transcribers, reasonable presenters, okay at categorisation, and as specified for metadata. — billinghurst sDrewth 21:12, 10 March 2020 (UTC)

How to reproduce hanging indent styled indices?

I want to reproduce the style of index as seen in Page:A_Handbook_of_Indian_Art.djvu/369 such as for entries 'Akbar' or 'Aryans'. In another work I was recently editing, many proofreading errors were because without the indentation people got lost in scanning the text. Thus I'm interested for more than just this work.

I've played with {{hi}} on this page (see towards bottom, entries under 'E' and 'F', and experiments at last)). It appears that {{hi}} uses <div> whereas interspersed normal text uses <p> which then causes unnatural line spacing within a section.

I have not yet found an example of any somewhat similar index page that doesn't use horribly convoluted tables.

It seems that if *every* line was encased by {{hi}} then all would display nicely. But that's painful too.

Does anyone have examples of this style of index done semi-naturally, without resorting to more formatting instruction text than text? Shenme (talk) 20:32, 10 March 2020 (UTC)

@Shenme: There is {{hii}} which you can use in the header and footer through the index, and just ensure you use it in the lede of the body section of the first page though it isn't perfect either. I have done over a hundred and I still don't have a standard process, so sometimes best to have a look at what has been done by others that suits your work. Intitle "Index" search main ns. Do note that adding {{anchor+}} to the letters, {{compactTOCalpha}} to notes field can add some useful navigation. — billinghurst sDrewth 21:04, 10 March 2020 (UTC)

Edit text layer of a PDF?

Does anybody know how to edit the text layer in a PDF file? Ideally I'd like to use free software on Linux, but any advice is welcome. -Pete (talk) 19:37, 11 March 2020 (UTC)

Frederick Douglass image has been replaced with porn

Hi -- I don't know how to change this, but I went to look at Frederick Douglass quotes and saw someone had changed his image to a pornographic one: https://en.wikisource.org/wiki/Author:Frederick_Douglass

Can you please change it back? This is so disrespectful.

Fixed on wikidata - d:Special:Diff/1136851178 --DannyS712 (talk) 02:19, 17 March 2020 (UTC)

Problem with a <ref follow tag>

There is something wrong with a reference follow tag placed on this page in Read mode, on my screen it appears as <ref follow=D142&amp;gt;. If it's possible to fix, can someone tell me what is wrong? Thanks — Ineuw (talk) 21:22, 22 March 2020 (UTC)

Fixed --Jan Kameníček (talk) 21:49, 22 March 2020 (UTC)

@Jan.Kamenicek: Thanks. Can you let me in on the secret?

@Ineuw: you had a broken closing ref tag. — billinghurst sDrewth 11:38, 23 March 2020 (UTC)

Thanks! — Ineuw (talk) 12:00, 23 March 2020 (UTC)

@Ineuw: As explained by billinghurst. BTW, the ping template works only in combination with your signature, if you omit the signature, the notification is not sent to the addressee. --Jan Kameníček (talk) 19:18, 23 March 2020 (UTC)

@Jan.Kamenicek: Forgot to sign it, just like forgot the < from the reference tag. Must take a break. :-) Thanks again. — Ineuw (talk) 19:34, 23 March 2020 (UTC)

Please review the status of this index

I noticed recently that the index of the book I'm proofreading has "Source file is incorrect" as status. I made the index some time ago and AFAIR I probably fixed the issues with the file, if any...could anyone please check if I can update the status? -- Contrapunctus-1 (talk) 17:48, 22 March 2020 (UTC)

It looks like @ShakespeareFan00: made that annotation, with the remark "duplicated frontispiece?" So I think the problem they saw was in p. 8 of the scan duplicating p. 10, and 9 duplicating 11. This doesn't seem like a big deal to me, as a fix (if even necessary) would not need to impact pagination -- just replace two pages with blanks. IMO it would be fine to change the status to "to be proofread" but perhaps SF has a reason I'm not seeing. -Pete (talk) 17:55, 22 March 2020 (UTC)

Usually comes about from the tissue paper layer next to a plate in a work being scanned and it is close to transparent under the intense light, so just use the no text option for the appropriate pages. — billinghurst sDrewth 04:45, 23 March 2020 (UTC)

Thanks, Pete and billinghurst. How do I "replace two pages with blanks", and what is the "no text option"? I went through the pagelist documentation, but couldn't find anything which seemed relevant :\ -- Contrapunctus-1 (talk) 07:58, 23 March 2020 (UTC)

@Contrapunctus-1: See help:page status; it is the grey one. I wouldn't fuss replacing them in the djvu, just ensure that you have one of each. You can make a note on the Index_talk: if it is not obvious what is occurring, or you can just leave a <!-- comment --> in the header. — billinghurst sDrewth 11:37, 23 March 2020 (UTC)

My guess is these are actual duplicates, as the tissue paper situation usually makes one of the scans blurry and hazy, which is not the case here. Either way, I agree with billinghurst: It's not worth fussing with the scan to replace the duplicated pages with blanks. By the "no text option" I suspect billinghurst means above the save button, choose the grey "without text" button instead of "proofread" or "validated" etc. for the duplicated page. Maybe it would be easier if I demonstrated, so you can see what the end result looks like. Let me know if you'd prefer that. -Pete (talk) 17:19, 23 March 2020 (UTC)

Thank you for explaining that, billinghurst and Pete. I've done it for page 8 and 9. -- Contrapunctus-1 (talk) 08:56, 24 March 2020 (UTC)

Separating semantic and formatting information

I'd like to separate the semantic markup of text (e.g. "chapter title"), and that of how it should be displayed (e.g. a specific font size, style, and alignment for all chapter titles), in hope of better exporting to other targets, like LaTeX. Is this viable on Wikisource? From reading around, dynamic layouts seem closest...is this correct, or are there better ways? 🤔 -- Contrapunctus-1 (talk) 22:19, 22 March 2020 (UTC)

Based on the formatting you're applying, e.g. here, it looks as though you're unfamiliar with our formatting conventions. For example, we don't use ===Header=== like Wikipedia does. We would format the example page I cited like this. You may find the Help:Beginner's guide to proofreading and the Help:Beginner's guide to typography helpful. --EncycloPetey (talk) 22:37, 22 March 2020 (UTC)

... because using sections puts section edit links in play; put ToCs in play. We use relative scaled formatting, unset fontfaces, etc. and that plays well with our layouts, and utilises whatever browser settings our readers have in place. Should also flow through to output formats. — billinghurst sDrewth 04:42, 23 March 2020 (UTC)

Thank you for demonstrating the improved formatting, @EncycloPetey, and thank you for the explanation, @billinghurst. I had a notion that I wasn't quite on the right track WRT formatting, but was focused on getting the content down first. Glad to learn there's a better way :D -- Contrapunctus-1 (talk) 07:15, 23 March 2020 (UTC)

👍 @Contrapunctus-1: glad we could help. It is why we are here; easy paths add to the enjoyment. — billinghurst sDrewth 09:28, 24 March 2020 (UTC)

Brace formatting

I have a formatting issue on this page - is there any way to align the text to the right of the brace such that it is in the middle of the second and third lines? -- Contrapunctus-1 (talk) 10:29, 25 March 2020 (UTC)

@Contrapunctus-1: I've reformatted it, with the brace and the content to the right of it in a single spanned row with vertical-align defaulted to middle. —Beleg Tâl (talk) 12:38, 25 March 2020 (UTC)

Beleg Tâl: beautiful! Thank you so much! -- Contrapunctus-1 (talk) 17:48, 25 March 2020 (UTC)

Tricky formatting, nearing the end of a 400+ page work...help?

I'm almost done proofreading this nearly 500 page book: Looters of the Public Domain It was a highly consequential book in regional history, but (I think) somewhat poorly received because its author was a notorious criminal, who implicated a number of government officials for their own crimes. It's astonishing to me that this book is not better known, and it would be great to have a complete transcription here on Wikisource, as it is not widely available elsewhere.

But this one page is causing me problems. I think some clever table construction is needed to reproduce it. Could somebody skilled at such things take a look? Page:Looters of the Public Domain.djvu/158

Done — billinghurst sDrewth 21:34, 25 March 2020 (UTC)

There are a few other pages that need lengthy tables transcribed. Those, I'm willing to do myself, as they are not complex...I just have to buckle down and do it. Fully-proofread-status is within reach! -Pete (talk) 16:41, 25 March 2020 (UTC)

Transcription of Immigration Restriction Act, 1901

I found this Australian archive website which contains a list of 7 individual .jpg scans of the Immigration Restriction Act, 1901. However, not only they are in low resolution, but 7 individual .jpg scans will also be an headache to deal with. The website also provides a .pdf transcription. Is it OK to use the .pdf scan? Many thanks.廣九直通車 (talk) 04:05, 26 March 2020 (UTC)

Better formatting possibility?

Is there a better way to format the right-aligned text here? It looks okay side-by-side, but not so much when viewed by itself (on a wider page). -- Contrapunctus-1 (talk) 07:29, 26 March 2020 (UTC)

Wrap it in a {{block center}} template and offset the right text. I've done it so you can see what I mean. Feel free to tweak as you see fit. Beeswaxcandle (talk) 08:30, 26 March 2020 (UTC)

Sidenotes misbehaving (probably not true - much more likely to be me misbehaving, actually!)

I have finally got round to rewriting Template:USStatPension/doc so that someone other than me might have a chance of understanding it! I have wrapped my example Acts of Congress in a {| class="wikitable" style="width: 65%;" |} to make them stand out a bit more clearly from the body text, but whether I put my {{sidenotes begin}} and {{sidenotes end}} inside or outside the table, the sidenotes still appear way off to the right of the page (actually off the right hand edge of my screen). Can anybody help me to move the sidenotes so that they hug the side of their appropriate single cell table rather than the page - actually the ideal outcome would probably be to have them appear within the table cell... Thanks. CharlesSpencer (talk) 13:39, 26 March 2020 (UTC)

Entirely different sidenotes question

I have just discovered the delights of {{default layout|Layout 2}} and have enthusiastically applied it to United States Statutes at Large/Volume 33/Fifty-Eighth Congress/Private Acts of the Second Session. However, the sidenotes are still showing in the default sans serif typeface. The sidenotes themselves are all generated by @George Orwell III:'s excellent {{USStatSidenote}} template. Does anyone have any ideas how to get {{default layout|Layout 2}} to apply its typeface settings to our {{USStatSidenote}} sidenotes? Thanks. CharlesSpencer (talk) 14:31, 26 March 2020 (UTC)

CSS concerns

In trying to get some sanity from certain templates, I wrote a stylesheet : Template:Uksi/styles.css

I then used it with success here:- Page:UKSI_1985-0173.pdf/1

However it fails to format unless I insert {{uksi}} (which is understandable given that is what calls TemplateStyles ...

{{uksi}}{{uksi/paragraph/1-2|s1=2|s2=1|title=Interpretation|text=In these Regulations "the main regulations" means the Traffic Signs Regulations 1981<ref>The Traffic Signs Regulations 1981 comprise Part 1 of the Traffic Signs and General Directions 1981 (S.I. 1981/859)</ref> as amended <ref>The amendments are made by S.I.1982/1879, S.I 1983/1088 and S.I. 1984/966.</ref> and a reference in Schedule 1 to these Regulations and Directions is similarly a reference to the Traffic Signs Regulations 1981 amended as aforesaid}}

Interpretation

2.—(1) In these Regulations "the main regulations" means the Traffic Signs Regulations 1981^[1] as amended ^[2] and a reference in Schedule 1 to these Regulations and Directions is similarly a reference to the Traffic Signs Regulations 1981 amended as aforesaid

Is there a way for this to be improved upon, given that the stylesheet is getting somewhat complex already?

ShakespeareFan00 (talk) 22:54, 26 March 2020 (UTC)

1. The Traffic Signs Regulations 1981 comprise Part 1 of the Traffic Signs and General Directions 1981 (S.I. 1981/859)
2. The amendments are made by S.I.1982/1879, S.I 1983/1088 and S.I. 1984/966.

Rhodesian Propaganda

I have a pamphlet of Rhodesian propaganda, printed by the Rhodesian Government Printer in June, 1966 and published by the Rhodesian Ministry of Information, Immigration, and Tourism for distribution at home and abroad. I would like to add this pamphlet to Wikisource, but I am uncertain as to the copyright involved. The pamphlet contains no explicit declaration of copyright (i.e. (c) or ©), but I understand that that isn't always necessary. Anyone here knowledgeable in such things? Regards, Guywan (talk) 20:34, 17 March 2020 (UTC)

@Guywan: Hard to give specific advice, Rhodesia then would have been crown copyright, however, with independence and becoming Zimbabwe it will depend how the government changed their copyright rules. Best I can do is point you to Commons and c:Template:PD-Zimbabwe — billinghurst sDrewth 12:58, 28 March 2020 (UTC)

@Billinghurst: Thanks for the response. I think this pamphlet (which is entitled Rhodesia: In the Context of Africa) falls under the following:

It is a artistic, literary, or musical work created under the direction of the state or an international organization and 50 years have passed since the date of its publication

Which means that the copyright naturally expired in 2016. The back of the pamphlet contains the following:

In the United States, this material is filed with the Department of Justice, where the required statement, in terms of the Foreign Agents Registration Act, of the Rhodesian Information Office, 2852 McGill Terrace, Washington D.C., as an agency of the Rhodesian Ministry of Information, is available for inspection. Registration does not indicate approval by the United States Government.

This seems to suggest that the pamphlet was published in Rhodesia and the U.S. simultaneously, and was unaffected by the renewed copyrights given by the Uruguay Round Agreements Act. Do you think it is safe to judge that the work is in the public domain? —guywan (talk • contribs) 22:37, 28 March 2020 (UTC)

@Guywan: Some intricate detail, though sounds reasonable to me. Crown copyright would have normally applied, and that would have lasted 50 years, so your call of 50 years by similar process seems reasonable. — billinghurst sDrewth 02:45, 29 March 2020 (UTC)

Unexpected Lint error: Page:A Collection of the Acts passed by the Governor General of India in Council, 1897.pdf/7

It claims stripped tags, All template calls are balanced. Suggestions on where I have misunderstood something please? ShakespeareFan00 (talk) 12:02, 28 March 2020 (UTC)

And re-doing the page from scratch, cleared them, which means somehow there was an obscure typo. ShakespeareFan00 (talk) 12:26, 28 March 2020 (UTC)

Request to check availability

Can somebody check whether the Google book Heavens by A. Šmilovský is available from somewhere (e.g. from the United States)? Thanks very much! --Jan Kameníček (talk) 22:37, 15 March 2020 (UTC)

I can access it from Canada. Will upload to Commons shortly. —Beleg Tâl (talk) 12:52, 16 March 2020 (UTC)

@Jan.Kamenicek: File:Heavens!.djvu —Beleg Tâl (talk) 13:17, 16 March 2020 (UTC)

Perfect! Thanks!! --Jan Kameníček (talk) 13:48, 16 March 2020 (UTC)

@Beleg Tâl: Oh, unfortunately the scan is quite bad with beginnings and endings of lines missing :-( Sometimes it is difficult to guess the missing parts for me. I will try to puzzle it out but I will have to borrow the Czech original first, hoping it will help me to get the meaning and thus guess the missing parts. --Jan Kameníček (talk) 16:21, 3 April 2020 (UTC)

Defoe DjVu request

Can someone generate a DjVu with text layer from (external scan)? This is the 1722 first edition of Daniel Defoe's A Journal of the Plague Year, which we are missing. This is an early novel, fictionalized from historical accounts of the 1665 plague, and might generate interest given current world events. --EncycloPetey (talk) 22:49, 3 April 2020 (UTC)

@EncycloPetey: File:A Journal of the Plague Year (1722).djvu --Xover (talk) 18:07, 6 April 2020 (UTC)

Thanks! --EncycloPetey (talk) 18:13, 6 April 2020 (UTC)

Poet Lore, volume 4

I would like to ask for help with File:Poet Lore, volume 4, 1892.pdf. There are three pages missing. I have extracted them from some other copy (which has different pages missing). Two of them I have uploaded here and they come before the title page with the poem by Tennyson (which is currently the 5th page of the file and should move to become 7th page of the file). The third missing page is frontispiece and is here. It should come before the first page of No. 1 (with the text A Modern Bohemian Novelist…). Could somebody add those three pages to the file, please? I would also like to ask for converting the file into djvu. --Jan Kameníček (talk) 14:42, 4 April 2020 (UTC)

@Jan.Kamenicek: File:Poet Lore, volume 4, 1892.djvu --Xover (talk) 15:31, 6 April 2020 (UTC)

Perfect, thanks very much! --Jan Kameníček (talk) 15:43, 6 April 2020 (UTC)

Waning of the Middle Ages

The current nomination for June 2020 PotM, and we finally found a scan. However it needs a DjVu to be used for the PotM. There is a google scan here. --EncycloPetey (talk) 18:28, 6 April 2020 (UTC)

@EncycloPetey: File:The Waning of the Middle Ages (1924).djvu. Minimal quality control. Let me know if it needs fixing. --Xover (talk) 12:11, 8 April 2020 (UTC)

Scrambled NLS uploads...

I've raised a concern here, User_talk:Gweduni#Wrong_uploads_or_mis-titles? about the scrambled nature of some NLS uploads.

The contributor there wanted to delete the list, but that seemed like overkill as it should be possible for an administrator at Commons to identify which scans belong to which metadata, and thus do some relocations and realignments of pages.

However, I'd like a third opinion on this, because it has been stated in the past that sometimes 'nuking' bad uploads and starting again IS a better option. ShakespeareFan00 (talk) 09:19, 7 April 2020 (UTC)

I made an amended list here Wikisource:WikiProject NLS/Scrambled, I don't think these are duplicates, as I checked when I made a list of those, and I certainly didn't see duplicates when looking at the thumbnails on Commons. ShakespeareFan00 (talk) 12:28, 7 April 2020 (UTC)

They can be moved easily enough. The issue is if the username is already in use that we are going to need to get the order right, and then get the right metadata in place. @Gweduni: If the NLS is able to quickly and easily run the upload scripts again then it is probably easiest to re-upload then if there is no other work having been done on them, eg. respective Index: pages here, and even proofreading here. Then we have a little work to do. I am able to do a deletion at clean up as required. — billinghurst sDrewth 13:15, 7 April 2020 (UTC)

Courtesy cross reference to Commons thread:- c:Commons:Administrators'_noticeboard#Mismtached_files/descriptions..., which can be closed if it's not needed. ShakespeareFan00 (talk) 14:59, 7 April 2020 (UTC)

Closed that discussion, and said we would sort it out locally. — billinghurst sDrewth 15:16, 7 April 2020 (UTC)

Getting proofreaders

Hi there, I have more or less finished a first pass of My People, which is generally acknowledged as the first Anglo-Welsh literary text. Is there a process for getting people to double check the text, or is it up to me to find volunteers? It is quite a short text, so I am hoping it will be reasonably easy to get it to a high standard. JimKillock (talk) 15:40, 21 March 2020 (UTC)

There is a Wikisource:WikiProject Validate, which is a group of people who work to validate (proofread a second time). You can find particulars on the Project page. --EncycloPetey (talk) 18:32, 21 March 2020 (UTC)

I've looked at a few pages, it looks good to me. I've made a couple notes in my edit summaries, but nothing major. -Pete (talk) 18:00, 22 March 2020 (UTC)

Thank you both, I've left a note at Wikisource:WikiProject Validate. I've done a second review myself; hopefully some people will come forward to help. I’m keen to make the text more widely available. Do you know if Project Gutenberg have a process for picking texts up from here? Or even Amazon ;) ? (My gut is that the latter doesn't, they don’t seem to pick up new texts as they enter the public domain, but I could be wrong about that.) JimKillock (talk) 21:33, 22 March 2020 (UTC)

@JimKillock: Good questions, and ones I've thought about a fair amount. I don't have definite answers, but I'll share my thinking.

I think that Wikisource generally doesn't score too highly on search engines mainly because the quality and completeness of its texts vary so widely, and because search engines have not (yet?) learned to distinguish between texts that are proofread, validated, or have other markers of quality. I hope @Kaldari: might comment on this, it's something they've been working on.

Project Gutenberg: I think it's more common for us to republish works from PG than the other way around. They have better search engine performance, but we have better scan-backing in our interface. I have never contributed to PG myself, but I'd imagine you could try to submit it there yourself.

Amazon: I believe it's generally independent booksellers who use the Amazon platform, rather than Amazon itself, that take public domain works and compile them into books for sale for profit. I don't really like the practice, but I suppose it does make works more accessible.

High quality incoming (and internal) links will make the Wikisource more discoverable. Are there Wikipedia articles that you could improve by using this as a source? Also, can you submit a link to the Online Books Page?

Hope some of this helps -- let me know if you have questions or other ideas. -Pete (talk) 02:15, 23 March 2020 (UTC)

@Peteforsyth: Wikisource scores very high with some works, but not with others. It depends on how saturated the internet is with a particular work. --EncycloPetey (talk) 03:01, 23 March 2020 (UTC)

@JimKillock: I've looked a bit more closely at this, and I think there are some opportunities. Some observations:

• Searching on the full title on Google, Wikisource comes up as the 9th hit (and then, it's the index page, which carries the full title, but not the mainspace page.
• The title of the Wikisource page is merely the first portion of the title of the book. At minimum, Wikisource should have a redirect from the full title to the shortened version; or, you might consider moving all the pages to the full title.
• There is a Wikipedia article and a Wikidata item, but the Wikidata item lacks a number of attributes that might make it tastier to search engines, such as the author's name and the WorldCat ID. I've added those and will try to add some other statements there.
• The index page did not have the "transcluded" attribute. I have no idea whether search engines are smart enough to look for this attribute, but they should, it's a good indicator of completeness. I added it.
• I don't know whether you're aware of John Mark Ockerbloom's Online Books Page, which I mentioned before, but it's essentially a free high quality incoming link, and I strongly urge you to submit it. Here are better links -- instructions on how to suggest a book and the form itself.

I hope some of these items help. Let me know if you want to discuss further. -Pete (talk) 02:20, 31 March 2020 (UTC)

P. S. Currently, the Online Books Page lists only a few Hathi Trust editions and a Gutenburg edition. It would be nice to add Wikisource to that list. -Pete (talk) 02:23, 31 March 2020 (UTC)

Thanks, I've made a submission to Online Books Page, and also moved the pages to the full title plus subtitle. Hopefully that will help with SEO. JimKillock (talk) 07:22, 4 April 2020 (UTC)

@JimKillock: You're welcome. I've been searching on DuckDuckGo, Google, and Bing every few days. Just today, the Wikisource transcription seems to have vaulted into the #1 spot on all three search engines, for the search "my people peasantry west wales"! I see that the Online Books Page did add a link. I suspect that OBP and/or the name change was probably the decisive stroke. Anyway, nicely done, and glad I could help! -Pete (talk) 21:52, 10 April 2020 (UTC)

Thanks, very helpful :) I’ve now finished doing the headers and footers to make anyone’s job wanting to validate the content a bit easier. JimKillock (talk) 13:38, 11 April 2020 (UTC)

Can you mark page articles you create in the Page namespace as "proofread" yourself?

I was copying scans from Google and then proofreading them myself. Can I go ahead and mark those pages as "proofread" or does someone else have to proofread it, and then a third person validates it? PseudoSkull (talk) 06:27, 12 April 2020 (UTC)

@PseudoSkull: Yes, please promote a page status when you believe that it passes the proofreading test as described.

Any one can proofread read (logged-in or logged out). A user not logged-in does not see the page status elements so cannot promote a work; whereas a logged-in user can see the page status, and can promote a page's status to one of proofread or validated, but not promote the same page twice. — billinghurst sDrewth 06:36, 12 April 2020 (UTC)

Google OCR broken

Tracked in PhabricatorTask T250312Resolved

When trying to use it, I get this error message. What steps can I take to remedy this?? I am not able to proofread without it. It is the only tool that reproduces extended Latin characters accurately. — Ineuw (talk) 18:21, 15 April 2020 (UTC)

@Ineuw: The error you're seeing is being returned from the server side of the Google OCR gadget, so there's nothing you can do to fix it beyond filing a bug report in Phabricator. It may be a transient problem caused by Wikimedia globally exhausting the API call limit for Google Vision that will go away on its own after some period of time. @Samwilson: It looks like the Google Vision API Proxy is returning a 403 Forbidden status, conceivably forwarded from Google and caused by an expired or revoked API key. Someone with access needs to poke around the logs on googlevision.api-proxy.wmflabs.org to figure out what's going on. Other random possible factor: there was a CloudVPS proxy change announced recently (and a NAT change, but I think that was abandoned). --Xover (talk) 18:51, 15 April 2020 (UTC)

Thanks I will report it to Phabricator. — Ineuw (talk) 18:53, 15 April 2020 (UTC)

It's working again as of a couple of hours ago. — Ineuw (talk) 02:44, 16 April 2020 (UTC)

• Sorry about this. Glad it's working again now (thanks to MusikAnimal and bd808). I've also just added a phab:tag/tool-wikisource-ocr project to track issues with the tool or gadget. Hopefully there will be some good action on that front in another few weeks (when we in CommTech move on to that wish). —Sam Wilson 08:32, 16 April 2020 (UTC)

Requesting validation

Is there an easy way to request validation of pages here, and bring community attention to proofread pages? PseudoSkull (talk) 18:32, 17 April 2020 (UTC)

Once you have proofread and transcluded a work, then we encourage users to add their completed works to {{new texts}}.

You can post here. Otherwise that is a weakness we have. Generally we haven't had a huge and continuous uptake in the "anyone want to validate my work" as we are either doing general maintenance and curating, OR we are working on our works. I do try, however, life is full of best intentions, and there is so much maintenance! No harm in asking though. There are some users who do like to validate, and someone like Kathleen.wright5 may if she has an interest in the work.

We used to spend a month a year (November) validating works through WS:Proofread of the Month though that has gone by the wayside it would seem. — billinghurst sDrewth 00:45, 18 April 2020 (UTC)

The Adventures of Paddy the Pelican/Piggy Bank Robbery problematic segment

Would any of you be able to make out what the two characters are saying in those instances of the episode, where in the transcript it says "illegible text" (even though it's spoken words, not text)? This is the page that's problematic, and the talk page explains why. Feel free to edit those pages if you come up with a definite answer. PseudoSkull (talk) 15:42, 18 April 2020 (UTC)

Converting endnotes to wiki syntax

What is the preferred method for converting endnotes to wiki syntax? I'm working on The History of Oregon Newspapers. Is it best to link the footnotes to the text on the pages at the end of the book, or to copy that text onto the pages from which it is noted? For instance, see this page which contains notes from this section (and the subsequent section). I have been moving them using the standard <ref></ref> format, but I'm wondering if there's a preferred method. -Pete (talk) 05:32, 16 April 2020 (UTC)

I think either way is a good one. I personally would be faithful to the way in which the notes are presented in the book, i.e. keep them in the separate chapter at the end of the book and link there from individual notes (if the authors wanted to have the notes directly at the end of every page or chapter, they would do it). But if you wanted to make them more accessible than they were in the original book by copying them into footnotes of individual chapters, I would not object. --Jan Kameníček (talk) 07:37, 16 April 2020 (UTC)

I created {{authority reference}} for this purpose, and you can see it implemented in {{Studies in Irish History ref}} (per cited at Page:Studies in Irish History, 1649-1775 (1903).djvu/81 and endnote at Page:Studies in Irish History, 1649-1775 (1903).djvu/123) resulting in Studies in Irish History, 1649-1775/Ireland under Charles II.. Keeps it all in place—only issue that I cheat upon is I don't try to do "follow" as that is just even more complexity for little value. — billinghurst sDrewth 12:45, 16 April 2020 (UTC)

Best to start with the end notes, and I found that I could do the formatting with a regex replacement as long as you paid attention to the preparation. — billinghurst sDrewth 12:47, 16 April 2020 (UTC)

@Billinghurst: Exactly what I was looking for, thanks. I think I have it sorted out, I'll play with it a bit more and then try applying regex as you suggest. @Jan.Kamenicek: In this case I plan to do it by chapter, because it's pretty clearly a convenience thing. I think the modern reader is a lot better served by having the notes easily accessible. -Pete (talk) 01:14, 19 April 2020 (UTC)

Descrambling Some NLS uploads...

Left a note here, User_talk:FrancineMillard#Scrambled uploads... but, renaming them and re-aligning them at commons is complicated by the fact that someone created Index: pages in good faith and also in good faith started transcription/proofreading under the in error names.

It can be salvaged, but would need someone with the right user rights to relocate things. ShakespeareFan00 (talk) 18:11, 27 April 2020 (UTC)

'Show Preview' and 'Show changes' results displayed in bottom of page

Perhaps someone knows why these pages the preview display and show changes at the bottom, below the Publish changes button? This problem also exists in the Vivaldi browser. This happens only when I am logged in. I disabled all gadgets, removed the .css and .js codes, logged out and deleted all wikimedia related cookies. Editing without logging in, the display is correct. If I log in, the display moves to the bottom of the web page. Anyone has a suggestion please? — Ineuw (talk) 04:49, 24 April 2020 (UTC) File:Proofread preview pane is on the bottom.jpg — Ineuw (talk) 18:20, 24 April 2020 (UTC) The problem still exists and is something related to my account. On leaving Wikisource, I delete all cookies then I login, and the problem reasserts itself. — IneuwPublic talk 01:03, 25 April 2020 (UTC)

@Ineuw: Sounds like you have changed your preferences Special:Preferences#mw-prefsection-editing, ensure that you have preview before edit box ticked (or whichever one it is like that, I don't remember the words). — billinghurst sDrewth 01:24, 25 April 2020 (UTC)

@Billinghurst: The problem must be with my login. The same problem exists on Wikipedia, Commons and Wikimedia. Preview appears at the bottom of the page.

Could the problem be because I also use the Vivaldi browser to edit on occasion. Could switching between browsers be the cause of the corruption? Ineuw (talk) 02:31, 25 April 2020 (UTC)

If you noticed that I made changes in Preferences, it was to reset everything to default to test the issue which showed up earlier.Ineuw (talk) 02:31, 25 April 2020 (UTC)

@Ineuw: We cannot see your preferences, they are yours, I am just presuming. Check your Special:GlobalPreferences also available through any wiki's prefs. — billinghurst sDrewth 06:32, 25 April 2020 (UTC)

@Billinghurst: How could my preferences in Wikisource affect the previews on other sites? I don't use global settings. On each Wiki site I edit, the codes are always stored in the local Vectra files. Ineuw (talk) 08:48, 25 April 2020 (UTC)

I have no idea what you have done or been editing. I am giving advice on the setting for preview below editing box, and how to check/change for local and global preferences. You seem to be in a reactive space, rather than a thinking space. You have to be using local/global preferences, they are preferences; see m:Help:Preferences. Your use of a skin, be it vector or another, is still a skin; see mw:Help:Skins. — billinghurst sDrewth 10:15, 25 April 2020 (UTC)

┌─────────────────────────────────┘
@Billinghurst: Don't know if you are interested in my issue, but I opened this task T251052 ticket. You were 100% correct. It may be that my global preference settings link to the local preferences is broken. User:IneuwPublic has no Global account and the edit preference of displaying the preview works. Ineuw (talk) 17:10, 28 April 2020 (UTC)

Every account is a global account per m:Help:Unified login and demonstrated via special:CentralAuth -> special:CentralAuth/Ineuw and special:CentralAuth/IneuwPublic both exist. If you have something broken in your connection to Special:GlobalPreferences then that is a Wikimedia issue and a phabricator is the right space. Either way, from your Ineuw account you should be able to change your global preference to have the preview above the edit box as a global setting. You should also be able to amend each wiki's local preferences to do per wiki. Nothing that we can do locally to fix, or resolve. — billinghurst sDrewth 13:21, 29 April 2020 (UTC)

Transclusion of section headings

I have noticed that when a page contains level 2, 3, etc. headings, and then it is transcluded with a <pages> tag, the headings are not transcluded properly but are included as a literal == Level 2 ==, === Level 3 ==, etc. This is in contrast to transcluding the page template-style like {{this}}. Is this behavior intentional and is there a way to override it?

I have discovered that the issue only appears when a heading is as the first line of a page. Putting a blank line first fixes the issue. Phillipedison1891 (talk) 16:52, 30 April 2020 (UTC)

@Phillipedison1891: It is unusual for us to use section headings in transcriptions as they tend not to reflect the works. I have seen them used in some modern works, typically reports, though quite unusual in older works. We would typically use one of the sized block templates, see {{larger block}}, typically wrapped in {{center}}. — billinghurst sDrewth 21:47, 30 April 2020 (UTC)

To answer your question however, due a work being transcluded the page is actually {...previous page text}{space}{==...}, and when transcluded there is no newline. Wiki section headings want to see the start of a line {^}==. As part of transcluding pages together, the pages also join without hard returns. Typically we use {{nop}} at the end of the preceding page, and that sort of guidance applies in this situation. All that wikiformatting of *, # etc. wants to see that it starts the line. — billinghurst sDrewth 21:58, 30 April 2020 (UTC)

Converting to djvu

May I ask for help with converting File:Seven Years in South Africa v1.pdf and File:Seven Years in South Africa v2.pdf into djvu? It seems that the files are too big for common online converters. --Jan Kameníček (talk) 15:53, 29 April 2020 (UTC)

I do not think that there is a big problem here: the page thumbnails just generate slowly as often for PDFs. I requested their pre-generation; in 1-2 hours they all should be available as you can see for first few tenth pages here. Unless the file is purged... Ankry (talk) 18:36, 29 April 2020 (UTC)

I've given up on the online converters, I typically use the Linux pdf2djvu command. Have you tried that? I'm happy to do that for you if you'd like Jan.Kamenicek. -Pete (talk) 18:49, 29 April 2020 (UTC)

@Peteforsyth: That would be great, as I know nothing about Linux :-(

@Ankry: I am sorry, but I did not get it. I do not have problems with generating PDF thumbnails, I just want to convert the files from PDF to DJVU, and when I tried some online converters I either directly got the message "The file size is too large" or they simply did not do anything. --Jan Kameníček (talk) 19:14, 29 April 2020 (UTC)

OK, I'm working on it. The pdf2djvu program is incredibly simple to use (and can be used on Windows or Mac too, I believe) -- I'd be happy to help you set it up if you'd like. I'm running it now, it's 100 pages into the 500+ page document, I expect it will take an hour or so. I should be able to upload in the next 3-4 hours. -Pete (talk) 19:56, 29 April 2020 (UTC)

@Peteforsyth: If you think it is easy I will definitely try it :-) --Jan Kameníček (talk) 20:33, 29 April 2020 (UTC)

I tried pdf2djvu on a file recently, and discovered that okular was showing the djvu as seriously downgraded relative to the original. Is this idiosyncratic to my file, or a problem with okular, or some feature I didn't use right?--Prosfilaes (talk) 00:38, 30 April 2020 (UTC)

File:Seven Years in South Africa v1.djvu

I will see if I can help you, Jan - are you on Mac or Windows? (It's easy to use, we will see how easy it is to set up -- I think it's possible, I will see if I can guide you!) @Prosfilaes: I don't know. I haven't used it in great depth, but it generally seems OK. I bet there are some parameters that determine resolution etc., I will see what I can learn from the man page. -Pete (talk) 01:33, 30 April 2020 (UTC)

p. 23 after pdf2djvu. Same page at IA.

File:Seven Years in South Africa v1 (temporary).djvu

File:Seven Years in South Africa v1 (temporary).djvu

p. 23 generated from source scans.

[@Prosfilaes: ↑↑↑↑ (the original ping was typoed)]

@Peteforsyth: I had a look at the above DjVu and it appears to have a huge white gutter around each actual page image, as if pdf2djvu worked like "print to DjVu" and placed the actual page image on a larger A4/Letter-sized canvas. Does it have any options to disable that behaviour?

I also looked a bit (quickly, superficially) at the image quality. Compare the legend in the top right of p. 23 in the pdf2djvu-made DjVu with the same page at IA (it's the same scan as the one at HathiTrust). The pdf2djvu output is essentially illegible where the original scan can still at least be interpreted (barely, but possible). That's mostly because the PDF input had excessive encoding artefacts and compression to begin with, but it doesn't help that it's been serially reencoded. And it looks like pdf2djvu has about doubled the pixel resolution from the PDF, which will only have the effect of magnifying the problems.

For comparison I grabbed the original scan images from IA and ran them through my custom DjVu pipeline (scripts wrapping tesseract and djvulibre), and the results look to be at least comparable to the original scans (despite reencoding from JPEG to DjVu wavelets). I have uploaded a temporary copy of this for reference (see second thumb at right). Without having studied this in depth, I am currently using the output from that pipeline as my reference for achievable quality (both for image quality and OCR). That's only anecdotally of course (though I've generated several tens of thousands of pages with it so far), so your mileage may definitely vary.

Anyways, I hope that's of some use when looking for the best settings to use. --Xover (talk) 07:48, 30 April 2020 (UTC)

@Peteforsyth: Great, thanks very much! I am using Windows. --Jan Kameníček (talk) 08:05, 30 April 2020 (UTC)

Thanks also @Xover: for the advice, though I have to admit I do not understand it a bit :-( Honestly, I hoped I will simply download some application (some safe one, I have already had some bad experience with freeware), open it and start converting, with results as good as the original was. (sigh: how the life could be easy, if PDFs worked well in Mediawiki environment…) --Jan Kameníček (talk) 08:05, 30 April 2020 (UTC)

Well, it seems like in my haste, I may have made a bit of a mess of things. @Xover: If you have made a better file, please feel free to overwrite the one I already uploaded. I'll try to learn the options in djvu2pdf better, and Jan, I'll follow up on your user talk page about how to install it on Windows. -Pete (talk) 21:38, 30 April 2020 (UTC)

@Peteforsyth: I'll have to do some quality control on them first: I generated them quickly mainly to have a comparison for the purely technical aspects, and so you'd have a reference for tweaking your own tool setup. Please let me know if there is anything I can do to help with that. I'm very much interested in improving the quality of our scans (and OCR), including efforts to improve tooling and expand the pool of contributors that have access to such tools. --Xover (talk) 07:33, 1 May 2020 (UTC)

@Jan.Kamenicek, @Peteforsyth: Vol. 1 has been overwritten and Vol. 2 uploaded (index). I've checked them as best I could, but you may want to look over them an extra time to make sure I didn't mess anything up. The index for Vol. 2 was created mainly for quality control so you'll probably have to tweak it to fit your preference. I'll go delete the temporary file now. --Xover (talk) 16:45, 1 May 2020 (UTC)

Perfect, thanks very much! --Jan Kameníček (talk) 16:57, 1 May 2020 (UTC)

Help with lilypond (transcribing Gregorian chant)

At the moment, I am trying to transcribe short extracts of Gregorian chant for inclusion at this page in the English hymnal. In so doing, I'm following the examples from the relevant documentation, i.e. this page here. There are some peculiarities with this particular example which need be dealt with (the clef is in a non-standard position; etc...), but none of these are major problems. However, I am having difficulties with transcribing the use of Gregorian ligatures correctly, as the effect remains in subsequent notes (see the effects here). Anybody have any experience with this? 107.190.33.254 01:56, 6 May 2020 (UTC)

To note Help:LilyPond; @Beeswaxcandle:??? — billinghurst sDrewth 03:33, 6 May 2020 (UTC)

I've managed to solve most of the issues (silly me, just had to add the text, and use "-" instead of "--" for hyphens). However, barlines are not still not showing so I'll keep this up here in case anybody does find a solution for that minor annoyance. 107.190.33.254 17:09, 6 May 2020 (UTC)

Hyphenated word across page, but within old-style quoted text

Here's a conflict between hyphenation across page boundaries, but where the text was italicized. How to do both auto-hyphenation and italics, both in page and main spaces?

The result in the main page was not good:

and that the answers to them by Mr. S. Rosenthal are satis- factory, I feel bound to declare that

The page end and beginning were:

“Having read ... and that the answers to them by Mr. S. Rosenthal are satis-

factory, I feel bound to declare that

One can do the {{hwe}} thing for page space, but I doubt it'd appear well in main space. Shenme (talk) 19:49, 6 May 2020 (UTC)

Done I just tried not to italicize the hyphen. --Jan Kameníček (talk) 19:56, 6 May 2020 (UTC)

Eww, err, works! Thanks. Shenme (talk) 00:31, 7 May 2020 (UTC)

@Shenme: Please note that these display templates are partially a gimmick on the lead page, and you can just poke the suffixed/hyphenated text into the footer section and format it without templates to get the effect. All the magic happens on the succeeding page, especially for the tranclusion, so there you can usually wrap the formatting on the outside, and/or the inside with normal nesting. [The reason for the gimmick is to simple lessen the conversation about header/footer, hiding things, etc. which confuses new users] — billinghurst sDrewth 00:23, 7 May 2020 (UTC)

Index:Sandbox.djvu and we have a sandbox for Index/Page: for playtime as needed. We used to have these synched with permanent links to Wikisource:Sandbox and Template:Sandbox though it is a while since I have played there. — billinghurst sDrewth 00:34, 7 May 2020 (UTC)

Tables where cell content spans pages

Page:CTSS programmer's guide.djvu/33 and Page:CTSS programmer's guide.djvu/36 is what I'm dealing with, transcluded in Compatible time-sharing system: A programmer's guide Phillipedison1891 (talk) 04:14, 7 May 2020 (UTC)

Nevermind, figured it out Phillipedison1891 (talk) 04:18, 7 May 2020 (UTC)

Attempts to resolve issues with FI..

I created a sandbox version of {{FI}}

and a minimal test case here: User:ShakespeareFan00/Sandbox/imgfloats

The nominal live version works as designed.

The sandbox version doesn't. WHY? ShakespeareFan00 (talk) 08:56, 7 May 2020 (UTC)

The main problem seems to be that for some reason the width attribute for the inner DIV and images are NOT being set up properly.

ShakespeareFan00 (talk) 08:56, 7 May 2020 (UTC)

Abandoned, because the approach used is clearly not going to work. If someone else want to look at the past revisions of the sandbox and figure out what went wrong, feel free, but I don't feel happy wasting my time continually fighting bad design and misunderstandings in the back-end and interactions of template markup.ShakespeareFan00 (talk) 09:32, 7 May 2020 (UTC)

Whitespace handling...

In connection with something I was working on :- User:ShakespeareFan00/Sandbox/CCEmovies

The whitespace between entries is a double line opposed to a single used between paragraphs within an entry. Within a single page this is reasonable, and it should be stated that there's no "visual" problems on the transclusion.

However, currently, the additional 2 lines at the end of the first transcluded page and then a NOP, means that whereas inside a page the additonal whitespace is 'tidyed' into the proceeding paragraph, at a nominal page-break it generates a blank paragraph and a blank div. In my example this is not an issue, but it's unreasonable to expect less experienced contributors to know about this whitespace handling issue long-term.

Is there a better solution to spacing out the entries, that doesn't rely on knowing precise whitespace behaviour (or a lot of unnecessary templates?

(Aside: Whist {{nop}} and {{nopt}} work as designed, I am increasingly of the view that they should be a "magic word" directive to Proofread page as opposed to the insertion of 'dummy' or 'empty' content into a page. There were apparently suggestions elsewhere that Mediawiki might eventually strip out "blank" tag pairs entirly, which would naturally break ALL content relying on the behaviour {{nop}} uses. ) ShakespeareFan00 (talk) 08:07, 8 May 2020 (UTC)

Alternatively, could {{nop}} be extended in an appropriate way so it could insert additional blank lines to accommodate the formatting used here?

ShakespeareFan00 (talk)

Rotated header in table cells..

Page:Quarterly Journal of the Geological Society of London, vol. 34.djvu/493

Yes the approach here is in good faith, but whilst {{rotate}} does rotate, the size of the surrounding table cell doesn't meaning it looks very ugly.

Is there a better solution , Supported in CSS for this specfic use case? ShakespeareFan00 (talk) 13:31, 8 May 2020 (UTC)

It seems that the style min-height does not work, so I tried to change it just for height and now it looks better. --Jan Kameníček (talk) 17:31, 8 May 2020 (UTC)

Different beahviour from span vs DIV based version of templates due to unnamed parmaeters

The output should be the same.

⁠Hwæt! wē Gār-Dena⁠in gēar-dagum ⁠Fol. 129a.

⁠Hwæt! wē Gār-Dena⁠in gēar-dagum ⁠Fol. 129a.

But the font or fonts param were not being passed down it seems. Temporary fix implemented but would appreciate a review.

ShakespeareFan00 (talk) 12:52, 9 May 2020 (UTC)

Searching for Recent Changes in a specific Work

How can I search for recent changes in a specific work? I am working on An_Exposition_of_the_Old_and_New_Testament_(1828) but this contains 6 huge DJVUs. I'd like to be able to go to Special:RecentChanges and search for the string "An Exposition of the Old and New Testament (1828)".--PeterR2 (talk) 00:02, 11 May 2020 (UTC)

Is your desire separate from "Related Changes" available from each DJVU index page? For instance, from Vol 1 index page in the left column under 'Tools' there is "Related Changes" for Vol 1. Clicking that link will show you changes in the last 30 days. The number of days and number of changes is personalized to you, so the tools link may show you fewer.

Here is the equivalent link for Vol 2., "Related Changes" for Vol 2. You will see that there *haven't* been any changes in 30 days.

Nor in Vol 3. or Vol 6. But Vols 4 and 5 *have* had activity. I don't know of a way to query all 6 volumes at once. Shenme (talk) 04:30, 11 May 2020 (UTC)

That's most helpful, thank you. I searched all over for quite a while before asking! Thank you also, Shenme and ShakespeareFan00 for the work you have done in Vol 4 and Vol 5 of An_Exposition_of_the_Old_and_New_Testament_(1828).PeterR2 (talk) 08:27, 11 May 2020 (UTC)

 Comment We have {{engine}} which can be used to search works in the page namespace, and if there are volumes of works that is still possible if the initial part of the stem of the pagenames is the same. Have a look at {{Index Alumni Oxoniensis}} as an example in a template; or Wikisource:WikiProject Biographical dictionaries/Catholic Encyclopedia where we have a couple looking at bits in works. It does nothing for time-related recent changes, though there is possible that function within mw:Help:CirrusSearch — billinghurst sDrewth 05:55, 13 May 2020 (UTC)

Images in footnotes

Within Index:Primevalantiquit00wors.djvu there are several pages that have images within or beside footnotes (for example this one, this one, and this one). The help pages Help:Footnotes and endnotes and Help:Adding images do not mention anything about this happening. What should be done in cases like this? DraconicDark (talk) 21:35, 12 May 2020 (UTC)

Add them, as best you can. If you want someone to have a go, then let us know. The help pages are just help pages compiled to cover situations, so will never comprehensively cover every subject. — billinghurst sDrewth 05:49, 13 May 2020 (UTC)

Hyphenated italics over a page break?

Is the behaviour when transcluding?

''A-'' ''B''

''A-''''B''

Or is is it a third case I haven't considered?

I have a possible way to handle this which is to wrap a SPAN tag around the portion to handle the italic formatting, if desired, but wanted to confirm the actual behaviour before writing 'yet another useless' template. (Especially given the concerns about SPAN DIV handling with respect to body/footer interactions mentioned elsewhere.

The proposed new template was {{iws}}{{iwe}} following on from {{hws}}{{hwe}} ShakespeareFan00 (talk) 10:53, 10 May 2020 (UTC)

I think it's a good concept, but the second example is wrong. The opening portion of the proposed template should only have the open tag, and the closing template should only contain the closing tag. I propose using HTML <i></i> for clarity in templates instead of wiki code. Also, this has nothing to do with hyphenation. — Ineuw (talk) 21:39, 10 May 2020 (UTC)

Not sure I'm understanding SF's original question, but did the situation resemble my above posting, which Jan.Kamenicek solved by doing (essentially)

''hi''-

''there''

to get the effect of ''hithere'' across page boundary. The third option? Shenme (talk) 00:28, 11 May 2020 (UTC)

┌─────────────────────────────────┘
@Shenme: The result of your solution is hi there. If you are using the Clean up OCR tool from the sidebar, that software is supposed to remove hyphens from the end of each text line to eliminate hyphenation and merge two separated words into one — and that is not the same.

To merge them into an unbroken word one should use the hws + hwe template. To enclose the text in italics and retain the hyphen in hi-there, I can only do it if the closing code is hidden in the footer and the opening code is is hidden in the header of the following page, as in ...

Page 1
Opening tag outside the template <i>{{hws|hi-|hi-there}} hidden in the footer </i>
Page 2
The opening italics tag <i> is hidden in the header and the closing tag is outside the template {{hwe|there|hi-there}}</i>.

The third option is move the end half of the word from the second page to the first and leave a note <!--hwe joined with hws--> and join them as hithere on one page. Also check your transcluded method on the main namespace page.— Ineuw (talk) 05:28, 11 May 2020 (UTC)

As I mentioned I wasn't sure of the desired result or problem. In my question I had italicized text that needed the hyphen to disappear stitching together as desired "satis" and "factory" to get "satisfactory", whereas I was getting instead "satis- factory", which you are pointing out? I wish the original question had included a problem example. Pictures for those having difficulties with "word problems" is nice. :-) Shenme (talk) 05:40, 11 May 2020 (UTC)

Your method removed the hyphen but the main namespace text will display a space. — Ineuw (talk) 05:43, 11 May 2020 (UTC)

Based on discussions elsewhere, the issue SF00 was having was a word that was split across pages and was italic. The solution for that case is, as Jan points out, to use ''hyphena''- and ''ted'' (will render as hyphenated on transclusion). ProofreadPage, so far as I can tell, doesn't care what precedes the hypen or follows the start of the next page: if a page ends with a literal hyphen (-) it will remove the hyphen and join the two pages without a gap, and you can plan your markup based on that. I have yet to run across a real-world case that actually requires the use of {{hws}}/{{hwe}} after this feature was implemented. Preserving a hyphen at the end of a page requires something like {{peh}}, but that's about it. --Xover (talk) 06:00, 11 May 2020 (UTC)

Theoretical discussions are easily resolved if you temporarily (as a test) insert the words as you see it, in two sequential pages in the page namespace which are already transcluded Save it and open the main ns page and look for the break (easy) and see what the result is. I am convinced that you are wrong. There will be a space between the two words in the main namespace where the two pages are supposed to be joined.— Ineuw (talk) 06:24, 11 May 2020 (UTC)

Xover's response is based on an ACTUAL test case in Page: namespace - See the 4th test case here User:ShakespeareFan00/Sandbox/hyphtest hws and hwe are no longer needed, because the backend code handling hyphenation WAS updated. However, if a genuine hyphen is needed at the end of a page you now have to explicitly indicate this with {{peh}}. A more intelligent syntax for how to handle 'split' styled content was something suggested on Phabricator a while back but can't recall which ticket number. ShakespeareFan00 (talk) 08:35, 11 May 2020 (UTC)

@ShakespeareFan00: You know a hell of a lot more than I do . . . especially about templates! The problem is whatever we do in the page namespace between two pages is only visible in the main namespace. Is it possible to see a transcluded main namespace article of these? — Ineuw (talk) 22:41, 11 May 2020 (UTC)

 Comment Why? why why? We don't need another damn template. On the first page just stick the formatted text in the footer. On the second page just use {{hwe}} and wrap it in italics. You can even have both components of the HWE template have italics within. the HWS/HWE templating is just to make things easier for us to explain to newbies, it has no other essential functioning and shouldn't be treated as some sort of magic bullet. — billinghurst sDrewth 06:00, 13 May 2020 (UTC)

Well, the template-based approach was presumably because at the time it looked like it was necessary in order to be able to split a word with formatting applied across pages. Once it was made clear you could just use something like ''hyphena''- and ''ted'', the templates were obviously no longer needed. Which applies to {{hws}}/{{hwe}} too, by the way. They are no longer meaningfully needed, and the little added value they provide is nowhere near sufficient to outweigh their added complexity. We should no longer recommend these templates for new users, and even experienced users with a habit should be encouraged to rethink it (mainly because new users tend to learn by example, so you get voodoo uses of them for all eternity). Was it not such a massive effort for marginal gain I would have argued for systematically replacing their use and actively deprecating them (and we have much bigger fish with much better value propositions to fry). --Xover (talk) 06:26, 13 May 2020 (UTC)

I know why they were created in the beginning and the evolution from {{hw}} to {{hws}}/{{hwe}} and I still support the use of {{hwe}}. It was the creation of an italics version that was doing my nut, and that the discussions gets legs and grows. I still somewhat support the retention of {{hws}} for newbies as it allows the continuation of the conversation of "type what you see" in the body, and multiple new users have struggled over the years to understand the header and footer components. I don't understand the dogged continued use of it by experienced users, well at least not in the body of the work. — billinghurst sDrewth 12:03, 13 May 2020 (UTC)

What is the purpose you see for {{hwe}}? --Xover (talk) 13:38, 13 May 2020 (UTC)

If there is a way to make hyphenated words within page-spanning footnotes work properly without the use of these templates, I would very much like to know it. If there is not, then that seems like reason enough not to phase out the templates. As to the question of why I "doggedly" used them for so many months after it was no longer necessary, it's simple (and I think reasonable): I don't pore over every Scriptorium announcement etc., and until very recently I simply didn't know that they were no longer necessary. No rebellious intent, just a lack of information. I'd imagine there are many others like me. -Pete (talk) 20:21, 13 May 2020 (UTC)

You learn something new every day… Thanks Pete, I hadn't thought of that case. That is indeed a very good reason to retain these templates, and once you need them for some cases it may be—as I think is part of Billinghurst's point above—simpler to communicate that you always use them for such cases (including outside ref tags) to inexperienced users. We should probably investigate the feasibility of making this case behave like the general case, but as that involves the interaction of mw:Extension:ProofreadPage and mw:Extension:Cite, and parsing rules and what works inside extension content is pretty arcane to begin with, that may be a tall order. --Xover (talk) 09:01, 14 May 2020 (UTC)

@Peteforsyth: Put crudely, before about September 2018 transcluded pages were essentially assembled with a space inserted between each one. No ifs or buts. Needless to say this messed up hyphenated words across individual pages.

Then came this change which mindlessly removed both the inserted space above and any adjacent hyphen. Great for English but (as you will see from discussion in the above change) a bit of a nuisance for certain cases in Chinese and German. And tough in the rare cases where you really wanted that hyphen to appear!

Cautious use of {{hws}}/{{hwe}} or {{lps}}/{{lpe}} can result in robust operation in all circumstances as use of these templates bypasses any so-called smart system handling—and as such it would be my personal recommendation to use them in all circumstances where you do not of absolute certainty know that you do not need to do so. My 2¢ 114.78.202.244 12:49, 14 May 2020 (UTC)

Editing of certain texts

How should I deal with texts in which a new text starts immediately after the previous text, causing there are 2 distinct text to be transcribed on related pages? An example will be Page:Acts of the Parliament of India 1955.pdf/121, in which I would like to first deal with the lower Untouchability (Offences) Act, 1955, many thanks.廣九直通車 (talk) 13:06, 14 May 2020 (UTC)

@廣九直通車: You want labelled section transclusion. --Xover (talk) 13:23, 14 May 2020 (UTC)

I believe that the the page that Xover referred to contains a lot of interesting information, but I personally do not understand there a bit although I often use sections here :-) I would suggest to have a look at some pages where the sections are used and learn there. The most common way is dividing the page into sections using ##s1##, ##s2## etc. If you need to end a section before another one starts (usually not necessary), you can do so using ####. An example is here. For an example of transclusion you can have a look here. --Jan Kameníček (talk) 22:38, 14 May 2020 (UTC)

@Jan.Kamenicek: You are entirely correct. I was too hasty here, and that page is way too technical to be very useful as user guidance on this. Mea culpa! @廣九直通車: Look at Jan's much more useful summary of how this works, and do please feel free to ask for assistance if you need it. Labelled section transclusion is kinda complicated to get started with, but starts to make sense after you've used it a bit. PS. My pings to you don't appear to get delivered. I'm not sure whether that's my web browser going off course somewhere around 东莞市 or mediawiki's Notify extension, but you may want to be aware of it. --Xover (talk) 06:26, 15 May 2020 (UTC)

 Comment The relevant local page for help is Help:Transclusion#How to transclude a portion of a page.

The #### methodology only works if you have the gadget turned on as it manipulates <section> begin and end tags. Personally I still use sections tags as that is my preference for tidy work, they make biographical works in the Page: ns difficult to read. — billinghurst sDrewth 06:35, 15 May 2020 (UTC)

I see no mention of a gadget at that link -- which gadget are you referring to? I use the #### methodology, but if there is a better way I'd like to learn it. I don't remember turning on a gadget to be able to do that...but maybe I did, a long time ago. -Pete (talk) 18:52, 15 May 2020 (UTC)

@Peteforsyth: It's the rather confusingly named "Easy LST" in the "Editing tools for Page: namespace" group in the Gadgets section of your preferences. The Labelled section transclusion extension actually uses html/xml-like start and end tags; the gadget lets you use the much simpler ####-style and converts them back and forth with the html-style tags when the page is saved / loaded for editing. The actual code lives at MediaWiki:Gadget-Easy LST.js, and as you can see it's a bit of a hack. Albeit a hack that has proven remarkably robust and problem free (my hat's off to GOIII!). --Xover (talk) 20:05, 15 May 2020 (UTC)

• So, I bet the result will be something like this, with the page requiring labelled section transclusion like this?廣九直通車 (talk) 04:33, 16 May 2020 (UTC)

  @廣九直通車: Yup, got it in one. You'll typically want to label every part of a given page, because the other parts will have the same problem (parts of multiple works on the same physical page) and needs the same solution. And you almost never need the #lst syntax: it's the native / generic syntax of the MediaWiki extension that adds labelled section transclusion, but the ProofreadPage extension (what provides the <pages …> tag) has specific support for this that makes it easier to use.

  ⁠• fromsection=…: on the page in the "from" parameter, only include this named section

  ⁠• tosection=…: on the page in the "to" parameter, only include this named section

  ⁠• onlysection=…: on all the pages in the range given by the "from" and "to" parameters, only include this named section (rarely needed)

  It's a little complicated, but it is a lot powerful. :) --Xover (talk) 08:10, 16 May 2020 (UTC)

  It is how we manage all our many biographical dictionaries and encyclopaedia: 70 volumes of DNB, EB1911, DAB, etc. As a general comment, we would not typically use the s1, s2, ... format for our sections, there we match them to the {{SUBPAGENAME}} as that allows for a lot more reliable and easier transclusion. For example, Page:Thom's Irish who's who.djvu/72.

  Very rarely use {{#section}} especially not in a raw format, typically templated in something like Template:Authority reference where we have to do some real magic to get the desired results. — billinghurst sDrewth 08:34, 16 May 2020 (UTC)

Question on US copyrights regarding foreign translated works and URAA

Hi to all! I again have a question regarding US copyrights for foreign works. Now my question relates to translated works, for which the copyright, AFAIK, is "constructed" from copyrights contributed by two parties: the first — copyright introduced by author of the original work from which the translation was made; the second — copyright contributed by translator of the work. And the question is: regarding copyright in the US for some tranlated work, which was created and published outside of the US completely in both parts (when both original and translation were published outside of the US) — how the total copyright state, and possible copyright restoration by URAA, is evaluated for this work — which of following options is used:

1) separately for both those contributions of copyright (one from original author and one from translator), and complete copyright state is summarized from both statuses, and possible 95-year copyright term expiration for any part is also taken in account;

2) or, the translation is evaluated as a whole, and its copyright status in US determined based only whether the translated work was as a whole in copyright on URAA date, and whether 95-year term for that translation has expired by now.

To make my question more clear, I also provide some specific case where this question makes a difference.

There is a work by Soviet leader Joseph Stalin — a newspaper article about Vladimir Lenin, that article was written by Stalin in Russian and published in 1924 year in the newspaper Pravda ("Truth"). The copyright for this work expired in the US on January 1 of this (2020) year since the 95-year term from publication date (1924) has expired, notwithstanding that the copyright in Russia has not yet expired, because Russia uses 70-year PMA term, with addition of 4 years for Great Patriotic war participants, so in Russia copyright for this work expires only in 1953 + 74 + 1 = 2028 year.

Also I have found a translation of this work to the Moksha language (one of languages of national minorities of Russia), that translation was created by anonymous author(s) and published in some Soviet Moksha-language magazine in 1936.

So, if: 1) to evaluate US copyright statuses of original work and translation, and summarize that statuses, then what we get:

1. The copyright of the original work by Stalin has expired in the US, though still has not expired in Russia.

2. The copyright status of the anonymous translation: it had expired in Russia on the URAA date of January 1, because by Russian laws of that time, 50-year protection term from publication date was applied for anonymous works, so its copyright had to expire in 1936 + 50 + 1 = 1987 year. So the copyright, contributed by translation itself, should not be restored by the URAA.

Finally, since both those copyrights are now invalid in the US (the author's one has expired and the translation's was not restorable under URAA terms), summarized copyright must be considered as invalid as well.

But, if: 2) to evaluate copyright status for work as a whole, then:

That particular translation taken as a whole, was copyrighted in Russia on the URAA date of January 1, 1996, since Stalin's works were generally (including that Russian original, and that translation being considered) under copyright, because 54-year term (50 years PMA basically + 4 years for Great Patriotic war participants) had not yet expired, so if treated as a whole, its copyright should be restored by the URAA, and should get standard 95-year protection term provided by US laws.

So, from the answer to this question the decision depends, whether the translation has expired copyright in the US now, or it is protected until 1936 + 95 + 1 = 2032 year (that is, even later than the copyright expires in Russia)?

I have failed to find myself any information how this case is treated by legal provisions of the US, so any help from any learners of the US copyright is greatly appreciated. --Nigmont (talk) 22:34, 20 May 2020 (UTC)

If the translation was copyrighted in the Soviet Union in 1996, it was restored. I don't see any way around it being restored, since it was copyrighted.--Prosfilaes (talk) 03:34, 21 May 2020 (UTC)

@Prosfilaes: "Hmm." The translation's Russian copyright expired in 1987 (anonymous = pub + 50). Stalin's original will expire in Russia in 2028 (pma. 70). As I understand it, the two copyright terms run independently for translations (as opposed to collaborative works like movies etc.). Thus, on the URAA date in 1996, the translation was in the public domain in the source country and not restored; and the original was in copyright in the source country and restored to a pub. + 95 US term that expired on January 1, 2020 (published in 1924). Only the parts of the translation that are separably Stalin's work were covered by the URAA restoration, and even those expired when the US copyright on the original expired. Where am I going astray here? --Xover (talk) 07:46, 21 May 2020 (UTC)

I don't think the copyright on derivative works is separable like that, but I have nothing to cite one way or the other.--Prosfilaes (talk) 06:00, 22 May 2020 (UTC)

Meh. What's the world coming to when you can't rely on Prosfilaes to give you the authoritative answer on these things! :)

But, ok, it does seem like the crux on this issue is whether the original author's work is separable from the translation's author's work for copyright purposes; which is, I think, the issue Nigmont was trying to highlight. And when even Prosfilaes doesn't know, the bottom line is probably that we can't give a definitive answer for this.

But I'll try to do a bit of "reasoning out loud" in case it's useful (including for sparking definitive arguments against my conclusion).

A translation is a derivative work of the original. The right to make derivative works is an exclusive right granted to the author of the original, and you need a license (in some form) to be able to make a derivative work (like a translation) from someone else's work. But the derivative work does create its own, new, copyright for the new work. This is why we have translations that are still in copyright even if the original's has expired. This, of course, does not supersede or invalidate the original copyright: both copyrights exist concurrently. There is also no general case that the original author's copyright extends to the new work: an unauthorised translation can be blocked (permission withheld) by the original author, but the original author cannot commercially exploit the translation (the translator's original contribution).

For a translation, that includes but modifies (translates) the whole of the original work, it is not very obvious that there are two distinct works in play. But consider something like painting or sculpture where one may repurpose bits and pieces of an original work, or music where one samples a small part or theme from an original to include in a much larger musical composition. Sean Combs (Puff Daddy) sampling Jimmy Page's guitar on "Kashmir" as a prime example: Jimmy Page and Led Zeppelin does not have any claim to most of "Come With Me", but does own the guitar riff and both could and very likely would have sued if there was no permission or license deal (this is common in the music field).

This argues strongly, to me, that there is nothing inherent to derivative works as such that make them inexplicably muddled together: so long as the derivative work contains distinguishable components with separate authorship, each author can and does retain an individual copyright for those parts. So any argument to the contrary would have to be based on the intrinsic properties of a translation, as distinct from derivative works in general.

And here we come to the concept of "separability". In the context of deciding what is eligible for copyright protection (original expression) and what is merely dictated by function and thus not eligible for copyright protection, the courts have applied a "separability test". For an ornate wooden chair, or a display case with various arrangements of flowers, design elements that necessarily follow from the object's function (being a chair, being a picture frame to hang on the wall, etc.) are not eligible for copyright protection, no matter how ornate or their artistic merit, unless they can be separated from the functional object of which they are part. There's a whole lot of nuance and detail to this (does it need to be physically possible to separate them, or is it sufficient to merely be able to imagine the element separately?), but the salient point is that the courts saw separability as a central test to distinguish between different parts of a work (those that are eligible for copyright and those that are not).

And, given we accept that distinct copyrights can exist for distinct parts of the same work, this issue for me becomes just such a "separability" question. Can we identify distinctly the parts of the translation that are the work of the original author and which are the work of the translator? To me it seems fairly obvious that the ideas and the ways to express them are the original author's, and the specific choice of words and idiomatic phrasing belongs to the translator, and that the two are distinct and distinguishable entities.

The counter-position would have to be that they are either collaborative works (where you can at best identify a proportion, but not assign each part to a specific author) or collective works (like a motion picture, where all parts, while distinguishable, are necessary to make the final product). But for a translation of a text, neither of these are a good fit. The original and the translation were produced entirely independently of the other, and each can be exploited entirely independently of the other. The two have different audiences and markets, and are not packaged together (except insofar as one was derived from the other).

Any thoughts or arguments would be welcome; and we will run into this issue occasionally so it would be useful to have an answer. --Xover (talk) 08:30, 22 May 2020 (UTC)

@Xover: Okay. I'm not entirely convinced, but it is a good case, and I won't challenge it.--Prosfilaes (talk) 08:17, 24 May 2020 (UTC)

Bleh! If you're not convinced, then I'm not convinced. But let's call the above then "the best I can come up with" as a disclaimer. If anybody comes across something that directly addresses the issue (in the Copyright Compendium or some such), I would very much appreciate a pointer. --Xover (talk) 08:35, 24 May 2020 (UTC)

Unexpected effect with flex box

On this page, the two poems at the bottom are both ten lines long and both are size "fine block," so the flex box ought to align them perfectly -- but one is a little lower than the other, how come? Levana Taylor (talk) 21:35, 22 May 2020 (UTC)

I'm no expert in the div formatting you used, but the padding seems different for the two columns; have I fixed the problem? -Pete (talk) 22:16, 22 May 2020 (UTC)