From Wikisource
Jump to navigation Jump to search
Warning 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.


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)[reply]

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? Inductiveloadtalk/contribs 11:56, 31 December 2019 (UTC)[reply]
Updated, and styles now being applied :) ShakespeareFan00 (talk) 11:40, 1 January 2020 (UTC)[reply]

A limitation of CSS?[edit]

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)[reply]

Have you tried transcluding pages? —Justin (koavf)TCM 12:55, 30 December 2019 (UTC)[reply]
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; Inductiveloadtalk/contribs 21:02, 30 December 2019 (UTC)[reply]
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)[reply]
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)[reply]

Meaning of "Thousand"[edit]

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


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)[reply]

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)[reply]
Yes, 5001-6000 printed, changed title plate, other plates all the same. — billinghurst sDrewth 12:00, 1 January 2020 (UTC)[reply]

Clone request :[edit]

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


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)[reply]

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

Movement request of proofread pages after removed duplicates[edit]

I removed pages 36 and 37 in the source DJVU for 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)[reply]

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

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

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)[reply]

@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)[reply]

Undesired line-break in interwiki transcluded pages[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]
I opened task T242517, there is something that has been changed for PDF files recently.Mpaa (talk) 17:23, 11 January 2020 (UTC)[reply]
@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)[reply]

search and replace / regex[edit]

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)[reply]

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)[reply]

Lack of Citation[edit]

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)[reply]

{{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)[reply]
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)[reply]
Or just use it and let them fuss the detail. smileybillinghurst sDrewth 01:01, 17 January 2020 (UTC)[reply]

A very complex footnote[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]


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)[reply]

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

Missing pages[edit]

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 . 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)[reply]

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)[reply]
No problem, no need to hurry :-) --Jan Kameníček (talk) 23:45, 17 January 2020 (UTC)[reply]
@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)[reply]
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)[reply]

step by step[edit]

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)[reply]

@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)[reply]

Why is right margin not working with img float?[edit]

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)[reply]

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)TCM 01:47, 21 January 2020 (UTC)[reply]
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
|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
|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! 02:19, 21 January 2020 (UTC)[reply]
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)[reply]
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. 03:13, 21 January 2020 (UTC)[reply]
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)[reply]
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)TCM 03:42, 21 January 2020 (UTC)[reply]
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. Inductiveloadtalk/contribs 09:59, 21 January 2020 (UTC)[reply]
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)[reply]
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. Inductiveloadtalk/contribs 13:54, 21 January 2020 (UTC)[reply]

caption above in {{Img float}}[edit]

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)[reply]

{{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. Inductiveloadtalk/contribs 22:14, 23 January 2020 (UTC)[reply]
Ok, thanks. I’ll get this right eventually. Levana Taylor (talk) 01:42, 24 January 2020 (UTC)[reply]

Mediawiki being pedantic about Section syntax interaction with tables again..[edit]

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)[reply]

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>
<pages index='A Naval Biographical Dictionary.djvu' from='1362' to='1363' fromsection='Promotions - Lieutenants' tosection='Appointments' /> 11:02, 26 January 2020 (UTC)[reply]
Nope solution suggested did NOT solve the problem. ShakespeareFan00 (talk) 11:09, 26 January 2020 (UTC)[reply]
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' /> 11:34, 26 January 2020 (UTC)[reply]

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

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)[reply]

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. 21:15, 26 January 2020 (UTC)[reply]
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)[reply]
{{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)[reply]

Block formatting in a reference...[edit]

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)[reply]

I usually handle these situations like this --23:19, 26 January 2020 (UTC)
@EncycloPetey: Pictogram voting comment.svg 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? 03:43, 27 January 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 and, but , there has not been progress made on a fix at present. ShakespeareFan00 (talk) 09:14, 27 January 2020 (UTC)[reply]
  • Pictogram voting comment.svg 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)[reply]
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)[reply]

The patch linked from the phabricator ticket was - which form asking in the #mediawiki channel had not been merged yet. ShakespeareFan00 (talk) 11:31, 27 January 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Tables... (again)[edit]

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,( 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)[reply]
I also raised in the past, but it doesn't seem to have generated a response.
see also and

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

Pictogram voting comment.svg 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)[reply]

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)[reply]

See - for an example of a 'disrupted' end of row cell when using {{nopt}} vs {{nop}}. ShakespeareFan00 (talk) 10:55, 27 January 2020 (UTC)[reply]

The Heart of Voltaire[edit]

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)[reply]

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). Inductiveloadtalk/contribs 08:45, 28 January 2020 (UTC)[reply]
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)[reply]
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.Inductiveloadtalk/contribs 11:12, 28 January 2020 (UTC)[reply]
This is, I think, the best solution. —Beleg Tâl (talk) 13:38, 28 January 2020 (UTC)[reply]

Withholding of Ukraine Security Assistance[edit]

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)[reply]

@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)[reply]
@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)[reply]

Wikipedia:Template limits[edit]

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)[reply]

@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)[reply]
Thanks @Xover: - message duly ported to Wikidata! CharlesSpencer (talk) 15:00, 4 February 2020 (UTC)[reply]
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)[reply]

Preferred approach for Marginal Section Headings and Chapter contents?[edit]

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)[reply]

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

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)[reply]

I cannot understand what you are asking. If you want help, you need to be clear. Mpaa (talk) 21:14, 30 January 2020 (UTC)[reply]
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 */. Inductiveloadtalk/contribs 12:32, 31 January 2020 (UTC)[reply]
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)[reply]
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)[reply]
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. Inductiveloadtalk/contribs 20:05, 31 January 2020 (UTC)[reply]
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)[reply]
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)[reply]
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.Inductiveloadtalk/contribs 10:22, 1 February 2020 (UTC)[reply]
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)[reply]
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. Inductiveloadtalk/contribs 16:04, 6 February 2020 (UTC)[reply]
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)[reply]
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)[reply]

Why does templating something generate an error?[edit]

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)[reply]

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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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. Inductiveloadtalk/contribs 11:12, 6 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
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
<dt>Term</dt><!-- look ma, a line break, this is why there's a space after your em-dash -->
whereas what you want is this:
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. Inductiveloadtalk/contribs 12:23, 6 February 2020 (UTC)[reply]

Inductiveloadtalk/contribs 12:23, 6 February 2020 (UTC)[reply]

Let's move the extended discussion to the talk page of the relevant Template? ShakespeareFan00 (talk) 13:05, 6 February 2020 (UTC)[reply]
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)[reply]

ditto inside dotted TOC[edit]

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)[reply]

@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. 07:17, 6 February 2020 (UTC)[reply]
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)[reply]
Perhaps someone needs to rethink the approach used by both templates? ShakespeareFan00 (talk) 09:01, 6 February 2020 (UTC)[reply]
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)? Inductiveloadtalk/contribs 10:17, 6 February 2020 (UTC)[reply]
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. Inductiveloadtalk/contribs 13:08, 6 February 2020 (UTC)[reply]
@Inductiveload: Thank you for fixing {{ditto}} and for doing the due diligence on why the fix is correct. 14:17, 6 February 2020 (UTC)[reply]
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)[reply]
@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. 14:17, 6 February 2020 (UTC)[reply]
Yes, thanks, noted. Thanks to everyone for working on this. Levana Taylor (talk) 14:51, 6 February 2020 (UTC)[reply]

Misbehaving footnote[edit]

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?[reply]

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)[reply]
Esme Shepherd (talk) 22:18, 6 February 2020 (UTC) Thank you. Glad I have nothing more to do![reply]

Updating obsolete Greek characters[edit]

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)[reply]

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. Inductiveloadtalk/contribs 13:54, 6 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
Pictogram voting comment.svg 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)[reply]
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)[reply]

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

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)[reply]


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)[reply]

@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)[reply]

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

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)[reply]

@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)TCM 01:06, 11 February 2020 (UTC)[reply]
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)[reply]
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)TCM 09:07, 11 February 2020 (UTC)[reply]
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)[reply]
(Aside) Is there something like jsfiddle in the Wikimedia sphere? ShakespeareFan00 (talk) 09:17, 11 February 2020 (UTC)[reply]
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)[reply]
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)[reply]

Error in Index namespace title[edit]

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)[reply]

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)[reply]
(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))[reply]
@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)[reply]
@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)[reply]
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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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.[edit]

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)[reply]

What to do about this printer's error?[edit]

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)[reply]

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)[reply]
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)[reply]
Pete, I would <noinclude>'d it and either {{SIC}}'d or left a rem'd comment. — billinghurst sDrewth 11:04, 16 February 2020 (UTC)[reply]
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)TCM 23:16, 14 February 2020 (UTC)[reply]

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

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)[reply]

Also somehow the OCR is not working.廣九直通車 (talk) 12:21, 12 February 2020 (UTC)[reply]
@廣九直通車: 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( '//' )") 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)TCM 12:54, 12 February 2020 (UTC)[reply]
@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)[reply]
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)[reply]
  • @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)TCM 13:43, 13 February 2020 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]

Page number in red[edit]

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)[reply]

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)[reply]
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)[reply]

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.
  • [136] where a {{nop}} (div) has been forced prior to the text
&#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.
  • [137] where the [ of a redlink abuts the top of body text
<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.)
  • 138 use of which is span
<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.

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

@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)[reply]
@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… 09:28, 19 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
@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? 11:47, 19 February 2020 (UTC)[reply]
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)[reply]
A workaround for that is to add 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. Inductiveloadtalk/contribs 20:54, 19 February 2020 (UTC)[reply]

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

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)[reply]

@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)[reply]
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)[reply]

DJVU index not functioning properly[edit]

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)[reply]

I have no clue how this is even possible. I suggest a phab: ticket. —Justin (koavf)TCM 22:40, 24 February 2020 (UTC)[reply]
OK, will do @Koavf:. Thanks! -Pete (talk) 23:14, 24 February 2020 (UTC)[reply]
@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)[reply]
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 *, 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)[reply]

Metadata standards[edit]

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)[reply]

Index pagelist offset problem[edit]

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.


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

@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)[reply]
@Xover: Thank you! -- Don Elbourne (talk) 18:07, 28 February 2020 (UTC)[reply]

Documenting ambiguous authorship[edit]

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) Klarm768 (talk) 11:31, 3 March 2020 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]
Well, I have transferred the file to Commons now.廣九直通車 (talk) 13:51, 4 March 2020 (UTC)[reply]

Volume 31 of a journal is in commons[edit]

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)[reply]

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. Inductiveloadtalk/contribs 18:00, 3 March 2020 (UTC)[reply]
@Inductiveload: Thank you! --The Eloquent Peasant (talk) 00:27, 4 March 2020 (UTC)[reply]

Metadata standards[edit]

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)[reply]

How to reproduce hanging indent styled indices?[edit]

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)[reply]

@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)[reply]

Edit text layer of a PDF?[edit]

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)[reply]

Frederick Douglass image has been replaced with porn[edit]

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:

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)[reply]

Problem with a <ref follow tag>[edit]

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)[reply]

Fixed --Jan Kameníček (talk) 21:49, 22 March 2020 (UTC)[reply]
@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)[reply]
Thanks! — Ineuw (talk) 12:00, 23 March 2020 (UTC)[reply]
@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)[reply]
@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)[reply]

Please review the status of this index[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]

Separating semantic and formatting information[edit]

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 this correct, or are there better ways? 🤔 -- Contrapunctus-1 (talk) 22:19, 22 March 2020 (UTC)[reply]

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)[reply]
... 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)[reply]
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)[reply]
👍 @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)[reply]

Brace formatting[edit]

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)[reply]

@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)[reply]
Beleg Tâl: beautiful! Thank you so much! -- Contrapunctus-1 (talk) 17:48, 25 March 2020 (UTC)[reply]

Tricky formatting, nearing the end of a 400+ page[edit]

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

Yes check.svg Donebillinghurst sDrewth 21:34, 25 March 2020 (UTC)[reply]

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)[reply]

Transcription of Immigration Restriction Act, 1901[edit]

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)[reply]

Better formatting possibility?[edit]

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)[reply]

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)[reply]

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

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)[reply]

Entirely different sidenotes question[edit]

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)[reply]

CSS concerns[edit]

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}}


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)[reply]

  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[edit]

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)[reply]

@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-Zimbabwebillinghurst sDrewth 12:58, 28 March 2020 (UTC)[reply]
@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 (talkcontribs) 22:37, 28 March 2020 (UTC)[reply]
@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)[reply]

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

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)[reply]

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)[reply]

Request to check availability[edit]

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)[reply]

I can access it from Canada. Will upload to Commons shortly. —Beleg Tâl (talk) 12:52, 16 March 2020 (UTC)[reply]
@Jan.Kamenicek: File:Heavens!.djvuBeleg Tâl (talk) 13:17, 16 March 2020 (UTC)[reply]
Perfect! Thanks!! --Jan Kameníček (talk) 13:48, 16 March 2020 (UTC)[reply]
@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)[reply]

Defoe DjVu request[edit]

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)[reply]

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

Poet Lore, volume 4[edit]

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)[reply]

@Jan.Kamenicek: File:Poet Lore, volume 4, 1892.djvu --Xover (talk) 15:31, 6 April 2020 (UTC)[reply]
Perfect, thanks very much! --Jan Kameníček (talk) 15:43, 6 April 2020 (UTC)[reply]

Waning of the Middle Ages[edit]

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)[reply]

@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)[reply]

Scrambled NLS uploads...[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Closed that discussion, and said we would sort it out locally. — billinghurst sDrewth 15:16, 7 April 2020 (UTC)[reply]

Getting proofreaders[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]

@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)[reply]

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)[reply]
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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

Google OCR broken[edit]

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)[reply]

@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 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)[reply]
Thanks I will report it to Phabricator. — Ineuw (talk) 18:53, 15 April 2020 (UTC)[reply]
It's working again as of a couple of hours ago. — Ineuw (talk) 02:44, 16 April 2020 (UTC)[reply]
  • 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)[reply]

Requesting validation[edit]

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)[reply]

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)[reply]

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

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)[reply]

Converting endnotes to wiki syntax[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]

Descrambling Some NLS uploads...[edit]

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)[reply]

'Show Preview' and 'Show changes' results displayed in bottom of page[edit]

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)[reply]

@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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]

@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)[reply]

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)[reply]

Transclusion of section headings[edit]

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)[reply]

@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)[reply]
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)[reply]

Converting to djvu[edit]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@Peteforsyth: If you think it is easy I will definitely try it :-) --Jan Kameníček (talk) 20:33, 29 April 2020 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
@Peteforsyth: Great, thanks very much! I am using Windows. --Jan Kameníček (talk) 08:05, 30 April 2020 (UTC)[reply]
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)[reply]

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)[reply]

@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)[reply]
@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)[reply]
Perfect, thanks very much! --Jan Kameníček (talk) 16:57, 1 May 2020 (UTC)[reply]

Help with lilypond (transcribing Gregorian chant)[edit]

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? 01:56, 6 May 2020 (UTC)[reply]

To note Help:LilyPond; @Beeswaxcandle:??? — billinghurst sDrewth 03:33, 6 May 2020 (UTC)[reply]
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. 17:09, 6 May 2020 (UTC)[reply]

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

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)[reply]

Yes check.svg Done I just tried not to italicize the hyphen. --Jan Kameníček (talk) 19:56, 6 May 2020 (UTC)[reply]
Eww, err, works! Thanks. Shenme (talk) 00:31, 7 May 2020 (UTC)[reply]
@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)[reply]
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)[reply]

Tables where cell content spans pages[edit]

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)[reply]

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

Attempts to resolve issues with FI..[edit]

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)[reply]

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)[reply]

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)[reply]

Whitespace handling...[edit]

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)[reply]

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..[edit]

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)[reply]

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)[reply]

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

The output should be the same.

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

Hwæt! wē Gār-Denain 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)[reply]

Searching for Recent Changes in a specific Work[edit]

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)[reply]

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)[reply]
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)[reply]

Pictogram voting comment.svg 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:CirrusSearchbillinghurst sDrewth 05:55, 13 May 2020 (UTC)[reply]

Images in footnotes[edit]

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)[reply]

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)[reply]

Hyphenated italics over a page break?[edit]

Is the behaviour when transcluding?

''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)[reply]

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)[reply]
Not sure I'm understanding SF's original question, but did the situation resemble my above posting, which Jan.Kamenicek solved by doing (essentially)
to get the effect of ''hithere'' across page boundary. The third option? Shenme (talk) 00:28, 11 May 2020 (UTC)[reply]

@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)[reply]

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)[reply]
Your method removed the hyphen but the main namespace text will display a space. — Ineuw (talk) 05:43, 11 May 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]

Pictogram voting comment.svg 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)[reply]

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)[reply]
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)[reply]
What is the purpose you see for {{hwe}}? --Xover (talk) 13:38, 13 May 2020 (UTC)[reply]
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)[reply]
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)[reply]
@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¢ 12:49, 14 May 2020 (UTC)[reply]

Editing of certain texts[edit]

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)[reply]

@廣九直通車: You want labelled section transclusion. --Xover (talk) 13:23, 14 May 2020 (UTC)[reply]
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)[reply]
@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)[reply]

Pictogram voting comment.svg 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)[reply]

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)[reply]
@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)[reply]
  • 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)[reply]
    @廣九直通車: 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)[reply]
    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)[reply]

Question on US copyrights regarding foreign translated works and URAA[edit]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]

Unexpected effect with flex box[edit]

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)[reply]

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)[reply]
Yes, it’s fine now, and I still don’t know why ... Levana Taylor (talk) 22:23, 22 May 2020 (UTC)[reply]
While I don't know all the ins and outs of the div tag, padding is like a margin. When one column has a 12px padding and the other had 20px, that means the latter was "pushed in" 8 pixels more than the former. -Pete (talk) 22:40, 22 May 2020 (UTC)[reply]
Maybe this helps? If you want to specify padding for top, bottom, left, or right, you can do so...but if you don't, I believe the simple "padding" attribute affects all four sides equally. -Pete (talk) 22:42, 22 May 2020 (UTC)[reply]
The CSS box model, and the various parts of it you can manipulate using CSS.
In case it's useful for someone… (I think both of you know this stuff already)
In the CSS box model, "padding" is the area between the border of the notional box (the div element) and its contents, while the "margin" is the area between the box and its surrounding elements. Such a box has padding, border, and margin; and all three have a width (the border is most often 0; that is, it is invisible and takes up no space). Borders have different syntax in CSS, but for both padding and margin the shorthand syntax is either padding: top right bottom left, padding: top&bottom left&right, or padding: all. That is, if you give it four values they will apply to the four sides, starting with the top and going clockwise around the box; if you give it two, the first applies to the top and bottom, and the second applies to the left and right; and if you give it a single value it applies to all four sides.
The long form for these are actually of the form margin-left: 1em and padding-top: 12px (for all four sides, and for both margin and padding). These may be easier to remember, but are a little less convenient, especially when used inline.
Once you're into using Flexbox and other advanced stuff there is an infinity of details to keep in mind—like whether adjacent boxes' margins collapse or stack—but just the essence of margin, border, and padding are easy enough once you learn them and are widely applicable. --Xover (talk) 09:02, 23 May 2020 (UTC)[reply]

Issue with Djvu (text one page shifted)[edit]

I uploaded a converted Djvu and made an index (Index:The Carnegie institute and library of Pittsburgh (1916).djvu), but the Djvu text is off by one page. What would be the best way to fix this?

Thanks, Crocojim18 (talk) 01:11, 26 May 2020 (UTC)[reply]

@Crocojim18: The easiest way is probably to let me know and I'll regenerate it for you. You can do it yourself, of course, but it's a lot of technical fiddling so I don't usually suggest that as the first course of action (but I'm happy to help any way I can if anybody wants to dig into it!). In any case, this was an instance of phab:T219376 and the fix is to regenerate the DjVu from the source scans without the pages that trigger the problem (it's triggered by invalid hidden text layers attached to some pages, and it's usually the calibration page inserted before the start of the book). I've uploaded a fixed version. --Xover (talk) 07:27, 26 May 2020 (UTC)[reply]
Okay! Thank you!! Crocojim18 (talk) 16:34, 26 May 2020 (UTC)[reply]

Node-count limit exceeded?[edit]

I think this issue needs no description. Anyone, please visit THIS PAGE and tell me how I can fix this. Thanks in advance. — Ineuw (talk) 10:05, 26 May 2020 (UTC)[reply]

@Ineuw: Drop the table formatting. All you need for this is a blank line between entries and two between letters (i.e. when switching from the As to the Bs). See Page:Merchant of Venice (1923) Yale.djvu/129 for an example. If you absolutely can't stand the amount of whitespace between entries (I say you shouldn't worry about it, but to each his own), you can break entries with a <br /> instead (it won't trip this particular Mediawiki limit). That index based on tables or other such complex approaches is never going to work. --Xover (talk) 10:32, 26 May 2020 (UTC)[reply]
Much thanks. I got it and will fix it. — Ineuw (talk) 11:11, 26 May 2020 (UTC)[reply]


I've started transcribing a dictionary which uses a ton of abbreviations throughout, and I thought a template to provide tooltips with the meanings of the abbreviations throughout would come in handy to the casual reader. To save me having to write the definition of the same abbreviations over and over again, I thought a custom template that invokes Template:Abbr would be more terse and less error prone.

I've set up a template, and it seems to work alright for the abbreviations I have entered so far. However, it is error prone - any abbreviations I forget to include in the list defined in the template still display with the unknown abbreviation and, unless I check every single one by hovering over it, I can't see at a glance which abbreviations aren't included in the list (or if I have spelled them wrong). So, outputting an error in place of the unknown abbreviation would be the sensible thing to do.

I realise the naïve way to set this up would be to have two lists of abbreviations, and check against both each time - once for checking for an error, and one to get the correct text for the tooltip - but I'd prefer to only maintain a single list if possible, to make it easier ad less error prone. Is there a way to set this up so that only one list of abbreviations has to be kept? I feel like I could do with a variable to store the result of the #switch (although I assume that would mean programming a module, rather than a template?)

Forgive me if this is an ignorant question to be asking, I'm still a template noob. And hopefully I'm asking in the right place - feel free to redirect me if not. Any advice would be greatly appreciated.— 🐗 Griceylipper (✉️) 17:46, 28 May 2020 (UTC)[reply]

You could also make the switch a second template (e.g. {{Nornabr/switch}}) and use an construction something like {{#if:{{Nornabr/switch|{{{1}}}}}||Unknown abbreviation}} to flag an error from the main template when the switch sub template doesn't find a match.
A module would probably be a valid solution too. Inductiveloadtalk/contribs 20:02, 28 May 2020 (UTC)[reply]
Of course! What a good idea, I shall try that. Thank you very much!— 🐗 Griceylipper (✉️) 21:17, 28 May 2020 (UTC)[reply]

Spam filter blocking edit of Sinews of Peace[edit]

I am a long-time Wiki editor for some 16 years, yet I am blocked from editing Sinews of Peace by a spam filter!?!

Currently, at the foot of the page:

==Video cuts of speech==
Does not agree with an edited video
http://w w w . y o u t u b e . c o m /watch?v=jvax5VUvjWQ
has a different order

But this link is broken (YouTube use account does not exist)

So, I tried to fix this by appending:

The above link is broken (YouTube account no longer exists); try:
<w w w . y o u t u b e . c o m / watch?v=DZBqqzxXQg4 Introduction by President Harry S Truman, Churchill's speech starts at 08:42.>

Note: I did not attempt to delete the previous link (even though broken) because it has the attached comment that the speech was not identical to the transcript (different order of presentation) and I have not attempted to transcribe or audit the the audio of this YouTube video and compare it to the transcript. Presumably this would be a worthwhile endeavour for such a historically important speech.

Anyway, I was advised to edit MediaWiki:Spam-whitelist - but I am blocked from editing that too.

Note also: I deliberately mangled the YouTube URLs to get past the spam filter, but the correct URLs will be obvious to homo sapiens...

Surely I have been editing WikiMedia sites for long enough. How is it that I am having to deal with this?

I appreciate some help.

Enquire (talk) 04:00, 30 May 2020 (UTC)[reply]

@Enquire: It's not you, it's Youtube. :) All of is blacklisted, so any individual video needs to be requested for whitelisting. You can post such requests on the administrator's noticeboard (include a good description of what page you want to use it on, and for what purpose, so the admins can tell whether the intended use is policy-compliant or not).
However, looking at this particular work it looks like that speech is not actually in the public domain or compatibly licensed (in addition to being unsourced and other problems; I'll list it at copyright discussions shortly) so there probably isn't much point in requesting a whitelist entry for this. --Xover (talk) 10:17, 30 May 2020 (UTC)[reply]
I added my comments copyright discussions. However, if there is a blanket YouTube block, I do wonder how the broken YouTube link was posted previously. Enquire (talk) 22:22, 30 May 2020 (UTC)[reply]

How to add the "LS" chop on legislation?[edit]

For example, are there any templates for this chop? I mean that "LS" in the circle on pages like Page:Terrorism (Suppression of Bombings) Act 2007.pdf/2. As a common feature of common law legislation, I bet there should be some sort of templates like this? If not, please advise how to do this, many thanks.廣九直通車 (talk) 05:27, 16 May 2020 (UTC)[reply]

Create the image and store it at Commons. Not sort of thing for which we would typically create a template — billinghurst sDrewth 08:18, 16 May 2020 (UTC)[reply]
@廣九直通車: I took a quick look at the options for doing something fancy here, but that seems to be a non-starter right now. There's no suitable character or function in Unicode, which we otherwise could have used. Mediawiki also doesn't support inline SVG or some other way to create vector graphics of the kind needed for this. And I found no signs this is likely to change any time soon.
However, as an experiment, I have created a very simple SVG version of this locus sigilli and uploaded it to Commons at File:locus sigilli.svg, and then wrapped it in a local template that just takes a size specification (any valid mediawiki image size specification) as an argument: {{locus sigilli}}. Thus, to get a 16px wide version you'd use {{locus sigilli|16px}}Locus sigilli
The default is 60px: Locus sigilli But you can request any size, like 120px: Locus sigilli
I'm not sure this is something a template is well suited for. For one thing, only the modern anglosphere acts use this particular simple locus sigilli; historically they are more likely to be ornate graphical jobbies that will need to be handled with individual images from the specific work. For the ones that are simple enough to generate in this way, I'm not sure there is sufficient variation that using a template is simpler than just using the image directly.
That being said, using a template does let us dynamically choose some aspects of the locus. We can set the background color, the stroke color of the circle, and the text color. We can do things like offer variants with "LS" or "L.S.". We can also offer different designs within the scope of simple geometric shapes. Due to limitations of the approach we will mostly have to create multiple images for the variants and have the template choose between them (similar to {{custom rule}}), which is non-optimal but feasible.
In any case, feel free to try it out; and if you have thoughts about extended use cases, do let me know. And you should of course also feel free to use the SVG image from Commons directly. --Xover (talk) 11:29, 16 May 2020 (UTC)[reply]
OK, many thanks to your effort to create the image and template. I literally have no knowledge on either SVGs and templates, so many thanks to your assistance.廣九直通車 (talk) 08:35, 4 June 2020 (UTC)[reply]


Hi. Could anyone who understands more about parentheses than I do please take a look at this page? Thanks. CharlesSpencer (talk) 13:58, 7 June 2020 (UTC)[reply]

CharlesSpencer Have a look now – I added another couple of columns in the table, and also made the brackets slightly taller too. Hopefully this is what you're looking for.— 🐗 Griceylipper (✉️) 18:16, 7 June 2020 (UTC)[reply]
Griceylipper, thank you so much - that is perfect! CharlesSpencer (talk) 10:21, 8 June 2020 (UTC)[reply]
@Griceylipper, @CharlesSpencer: {{brace2}} is a lot neater as a curly bracket. And personally, I wouldn't think that it is necessary to have the text so so so small. We have more flexibility than straight replication. — billinghurst sDrewth 13:31, 8 June 2020 (UTC)[reply]

Hws / hwe edge-case[edit]

For the dictionary I am transcribing, I have an odd formatting edge-case involving {{hws}} & {{hwe}}. The relevant pages and transclusion are here:

  • Page 137 (11): should display “ammel- (note the spacing)
  • Page 138 (12): should display tree”
  • Transclusion: should display “ammel-tree”, but I get “ ammel-tree” (with a preceding space, for some reason). If I use the spacing template in the second parameter of {{hws}} or {{hwe}}, things don't look good on the page: “<span title="ammel-tree">ammel- on the first page, and <span title="ammel-tree">tree” on the second. I also can't leave out {{hws}} and {{hwe}} either, as transcluding the pages consumes the hyphen, which is intended to stay!

The spacing here is important, as it conveys the meaning to the reader that this is another word referenced in the dictionary. So it is important to preserve this in the text. I wouldn't be so bothered about making sure the spacing works in the tooltip. For spacing I've been using {{nornsp}}, which is just my own template that invokes {{letter-spacing}} without having to specify a spacing of 0.08em every time.

Any pointers would be greatly appreciated.— 🐗 Griceylipper (✉️) 00:49, 9 June 2020 (UTC)[reply]

hws and hwe are just tools to make things easier when it can be easier. Don't let them trap you, the output is what is important. I have put the code into place. — billinghurst sDrewth 03:57, 9 June 2020 (UTC)[reply]
That's a big help, thanks so much!— 🐗 Griceylipper (✉️) 04:17, 9 June 2020 (UTC)[reply]
@Griceylipper: Since the solution based on {{hws}}/{{hws}} turned out to require a bit of fiddling in this case, I've tried a different approach (1, 2) using {{peh}} which makes for much simpler code. As best I can tell it gives the results you were after; but which approach to prefer comes down to, I think, whichever variant matches your mental model best. As Billinghurst points out, hws/hwe are just utilities: the important thing to keep in mind is that MediaWiki/ProofreadPage will join two pages with a space character, unless it ends with a hyphen, in which case it will not insert a space and additionally remove the hyphen. {{peh}} takes advantage of this to give the desired results when a page ends in a word that should be hyphenated. --Xover (talk) 05:49, 9 June 2020 (UTC)[reply]

Hi I'm on mobile.[edit]

Can I still edit here? What can I work on I'm confused. SugarredHumpbackWhales (talk) 11:08, 9 June 2020 (UTC)[reply]

@SugarredHumpbackWhales: You can still edit using mobile, there are absolutely no rules against it. However, you may find the editing interface on mobile is not that easy to use, because mobile screens generally do not have room for the side-by-side layout that is normally used to verify text against scanned works, especially when the on-screen keyboard is shown.
In terms of what you can edit, perhaps Validating text (checking already proofread text) might be easier than proofreading from scratch, as this generally requires much less typing and you might find it easier to do on mobile. But, again, there are no restrictions on what you may or may not do because you are using a mobile device. There are a few small validation tasks at Wikisource:WikiProject Validate, there are many proofread pages at the current collaboration (Leaves of Grass) that are yet to be validated, and all the many works in Category:Index Proofread are open for validation (any yellow pages need validation - once validated they will turn green). Inductiveloadtalk/contribs 11:24, 9 June 2020 (UTC)[reply]

Make a text exportable[edit]

Hello, I was wondering how to set properly a text for it to be exportable (into pdf/ePub for instance), and how to make it exportable then using templates. I haven't found so far an example of a text exportable, even looking into the texts of famous authors, while there are tons of exportable texts in the french wikisource. Thank you :) — Polochinoc (talk) 15:04, 28 May 2020 (UTC)[reply]

There is nothing in particular to do to make a text exportable: the "WS-export" tool is enabled on all pages. There should be a export link for each of ePub, Mobi and PDF in the left sidebar (or top right in mobile view). For example, this is the ePub for Agrarian Justice:
When aiming for export, avoid using certain formatting, especially fixed widths which might not fit on an ereader screen. For example, setting an element to have width:60em; will extend off the screen on most devices, prefer max-width:60em; to allow it to shrink to fit small screens. A quick check of Agrarian Justice indicates this work should be fine. Generally speaking, if it looks OK in Layout 2, it's probably be fine on an ereader.
Curating works for export is something that English WS does not do much of: there is no category or other list of "known-good" exportable works that I know of, or any procedure to check works export nicely. Inductiveloadtalk/contribs 15:32, 28 May 2020 (UTC)[reply]
There is a new project at Meta (+ accompanying discussion) aiming at export improvement. --Jan Kameníček (talk) 16:01, 28 May 2020 (UTC)[reply]
Oh, I didn't see the column at the left, thank you. Okay I understand, you don't have a category that can be added to a text, so that is it is known "good for export". By the way, I downloaded Agrarian Justice as pdf and saw it didn't keep the center alignment for the titles. But otherwise, it did render it pretty well. I'll check the pages as well — Polochinoc (talk) 16:12, 28 May 2020 (UTC)[reply]
Hmm, yes,the PDF using the side-bar link does lose the centre (and right) formatting, and seems to use a different for the tables too. The sidebar actually uses the "ElectronPdf" tool. Ws-export also can do PDFs, which does seem get the centre/right formatting right: Hopefully the project Jan linked above will address some of these quirks. I'd say that for me, generally, ePub and Mobi are the critical targets, since they allow the device to reflow text as needed for the small screen. Inductiveloadtalk/contribs 18:04, 28 May 2020 (UTC)[reply]
@Polochinoc, @Inductiveload: I think the Tech Team will appreciate if you write them what you observe that needs to be improved. --Jan Kameníček (talk) 07:13, 29 May 2020 (UTC)[reply]
I think, for a large proportion of enWS issues, problems are local:
  • Their first example of misalignment was Page:Trees Kilmer.djvu/9, which was using a <center> tag to centre a bordered div. This should be CSS margin:auto;. Possibly, WS-export could fix this on the fly, but it's better to just use the right markup in the first place. Agrarian Justice had this too with the tables, which used {| align=center instead of {| style="margin:auto;".
  • The same work (Trees and Other Poems) also does not use {{page break}}, so the ebook doesn't contain hard page breaks in the right place, so it has to split the div across pages as it doesn't know better. I don't think this is a defect in the WS-export, it's just how ePub/ereaders work when there's a div that won't fit on a page.
  • Works that use wide fixed-width formatting are likewise going to break ebook formatting through no particular fault of the export layer.
  • ElectronPDF should IMO, just, not be used at WS. It doesn't handle multipart works, so it's basically useless for any work with subpages. Agrarian Justice was just lucky in that it doesn't have subpages. Why not just use the WS-export PDF engine, which handles subpages and at least will be consistent with the eBub/Mobi outputs in terms of what pages are included? Plus ElectronPDF seems to strip quite a lot of a formatting, which probably makes sense when printing Wikipedia articles, but not so much for WS. What appears in the left sidebar is at least partly under local enWS control: WS-export options are from MediaWiki:Gadget-WSexport.js. I'm unsure ElectronPDF even maintained: mw:PDF_export says it's deprecated.
  • Making exported works first-class citizens like frWS (which has very high ebook engagement rates) does with clear icons in headers, prominent icons on all front-page works and categorisation into Category:Bon pour export is again down to local policy and not tool defects.
  • Having such a category would enable us to present an OPDS catalog of exportable works, so WS can be integrated directly into ebook readers like MoonReader+ and managers Calibre as a "net library". As it stands, an ODPS catalog of enWS works is likely to present rather variable-quality results, as not all works have been made with export in mind.
  • On-wiki instructions for eBooks are scattered and hugely dated: Wikisource:eBook and Help:Reading offline. Our first suggestion for finding an ebook is to find one for sale!
I'll try to distil some examples that I think are tooling-related and report them to the project. Inductiveloadtalk/contribs 09:14, 29 May 2020 (UTC)[reply]
@Inductiveload: Regarding Agrarian Justice{| align=center is wikimarkup, not HTML, so it's not really the equivalent of using <center></center> (in 2020?!?): it's a "bug" (fsvo) in Mediawiki more than a local issue. Not that we can't or shouldn't work around it for the benefit of our (ebook) users, but fair's fair.
Where is it you think there should be a {{page break}} that there isn't? The work does use them in what to me appears roughly the standard way, and the ePub looks fine here.
And generally, if there are significant local issues at enWS then it would seem a good first step would be to document them somewhere so we can learn and adapt. A list of observed problems, and a set of derived "Do's and Dont's", would be most helpful for those of us who almost never look at an ePub version. And it may show opportunity for making templates and other tools "ePub friendly" by default where they aren't today. --Xover (talk) 10:14, 29 May 2020 (UTC)[reply]
  • Sure, I meant alignment issues in general: center tags and align=center both don't work in ebooks. It's really not the ebook layer's fault that that alignment failed in either case. Perhaps it could be intercepted and tweaked by WS-export, but we can also just use margin:auto locally and it's done. I made a few changes to Agrarian Justice to tidy up the ePub (the only real issue was the table alignment), and it exports well (suitable for Category:Good for export, I say!).
  • Re page breaks: I meant in Trees and Other Poems (which is indefinitely protected): probably in the main namespace, between the "non-flowed" front matter pages. This would (probably?) resolve the issue reported in the meta project: meta:Community_Tech/Ebook_Export_Improvement#Formatting_&_Styles (the alignment failure being caused by a center tag, now resolved).
  • I did recently propose a list of suggestions for for making our works export-friendly, but didn't get support because a very small number of works have formatting that's not easy to ebook-ify: Wikisource:Scriptorium/Archives/2020-01#Curating_works_for_export. No-one seemed to support (or oppose for that matter) the idea of having a frWS-style "known good for export" process of some sort. I'd be more than happy to start the discussion again.
  • I have collected some material on some things for consideration when formatting ebooks: User:Inductiveload/Sandbox/Formatting for export Inductiveloadtalk/contribs 10:36, 29 May 2020 (UTC)[reply]
@Clockery, @Londonjackbooks, @EncycloPetey, @BethNaught, @Beleg Tâl: Note that in order to address the ebook problem flagged above I have modified the (featured) text at Trees and Other Poems to add {{pb}} between distinct pages of the front matter (particularly those that feature non-reflowable content, like the title page). Please let me know if you have any concerns or objections to this.
@Inductiveload: I think a quality control process that ends up with verified good ebook exports tagged with Category:Good for export is a good idea, at the very least so long as there is a significant chance that our works are not good for ebook export by default. Perhaps such checks should be incorporated into the featured text process too? --Xover (talk) 14:58, 29 May 2020 (UTC)[reply]
Thanks! The different front matter pages now render in my ebook readers (MoonReader+ and Calibre) on separate pages. The problem noted at meta no longer occurs (unless your font size is set so large and your screen so small that the title page content simply doesn't fit on the page at all, but there's not a lot to be done about that).
Re quality control process, I think there are a two parallel aims here:
  • Have some kind of process to check for the basic gotcha's for ebooks so people can check off works. I would say that egregious ebook fails are not that common, most works come out pretty well, all things considered. I can't see any critical issues on a selection of the current recent texts, for example. However, I would certainly says it's common that works can benefit from small tweaks to improve the ebook output, even after reaching validated status. Generally speaking, the tweaks are minor and don't affect the "normal" view of the work. For example, changing a "width:30em" to "max-width:30em" doesn't have any effect until the screen is narrower than 30em. I think it's rare indeed that a work is outright unsuitable for an ebook.
  • Some kind of listing mechanism, e.g. a category. Categories are good because they're easy to maintain (no manual formatting), well understood, easy to reason about and, critically, easy to query automatically, e.g. for providing a library catalogue of verified ebooks. We have Validated texts and Proofread texts, but most pages there are subpages or article pages (e.g. DNB00) which will clog up the list. IMO, "good for export" entails more than just proofreading status and should also be restricted to "top-level" works that you'd expect to see in such a catalogue.
I think the most critical thing about the process is that it should 1) be easy, to encourage people to do it and expand our repertoire of verified-nice ebooks and 2) should not require onerous or invasive changes to works, even if that means some works don't ever get a "good for export" tag. Inductiveloadtalk/contribs 15:35, 29 May 2020 (UTC)[reply]
@Xover: I always use page breaks (generally {{ppb}}) in front matter, I think there are very few works which would not be improved by inserting these in the appropriate places. —Beleg Tâl (talk) 03:15, 11 June 2020 (UTC)[reply]
+1 and have been for years+for+ages. Where the series it is not flowing the separation of the idea is best IMNSHO emphasised with a break. — billinghurst sDrewth 05:14, 11 June 2020 (UTC)[reply]

Header displayed twice in DNB page[edit]

I was visiting the Ponsonby, Henry (DNB00) page and see the header being displayed twice. Tried to fix it by removing {{DNB00}}, but in the preview it appears that removing the template results in the header not being displayed at all. Since I am not familiar with how the pages tag works, appreciate if anyone could lend a hand fixing it. Thanks in advance. ネイ (talk) 16:06, 10 June 2020 (UTC)[reply]

@ネイ, @ネイ: I'm trying to track it down. Will follow up on WS:S (there's an existing thread there). --Xover (talk) 17:12, 10 June 2020 (UTC)[reply]
Thanks! I'll have a look at that thread. ネイ (talk) 17:15, 10 June 2020 (UTC)[reply]

A question about pdf scans[edit]

In the page Help:Adding texts, it’s written that before typing the text in Wikisource, I must first upload the scan to wikimedia commons. There’s still one thing that I don’t understand though, I checked through other source like Republic of South Africa Constitution Act, 1961 and Unilateral Declaration of Independence, and I couldn’t find anywhere where they linked the scan. Do I just upload the scan to wikimedia commons without linking it anywhere on Wikisource? Also, if we enter wikimedia commons, we see that it’s not used anywhere in Wikisource. Thanks in advance, -RiverThames27 (talk) 11:43, 31 May 2020 (UTC)[reply]

Uploading scans is still not compulsory but it is true that it is highly preferred. The works which you have linked to were added to English Wikisource long time ago (in 2006 and 2009), i. e. before the pracice of uploading scans started. For an example of a scan-backed document see e. g. The Constitution of the Czechoslovak Republic.
If you want to add a scan-backed work, you have to follow these steps:
  1. Upload the scan to Commons (if it is in public domain both in the United States and its source country) or here (if it is public domain only in the United States).
  2. Found an index page (example).
  3. Profread the individual pages
  4. Transclude the work into the main namespace.
These steps are generelly not too dificult, but they may seem difficult to a novice contributor. For these reasons do not hesitate to aks for help at any stage of the work, you will always find help here. If you upload the scan, I can found the index page for you if needed. --Jan Kameníček (talk) 13:51, 31 May 2020 (UTC)[reply]
Thanks for the reply! I still have one question though. The text I would like to add is the 1965 constitution of Rhodesia, and it can be found here: It should be public domain in the U.S. because it’s a government document, but it’s source country doesn’t exist anymore. Should I upload it to Wikisource or to wikimedia commons? If to wikimedia commons, should the index page be in Wikisource or in wikimedia commons, thanks in advance, -RiverThames27 (talk) 09:34, 1 June 2020 (UTC)[reply]
Oh, and one more question, in this source the chapters don’t always begin on a new page. How will the Transclusion work? I was recommended to search on splitting it, which I haven’t done yet, but even then you have chapters that start in the middle of the page. Thanks in advance, RiverThames27 (talk) 09:38, 1 June 2020 (UTC)[reply]
Hello? -RiverThames27 (talk) 14:20, 2 June 2020 (UTC)[reply]
@RiverThames27: Unfortunately, I am not able to answer the question about Rhodesia. Maybe @Xover: or @Prosfilaes: could help.
As for chapters which do not begin on a new page: in such a case you must devide the page into sections and then transclude only the particular section.
The simplest way to divide the page is to use:
## s1 ##
Text of section one
## s2 ##
Text of section two
To transclude the text upto some section or from some section you use for example
<pages index="name of book.djvu" from=6 to=9 fromsection=s2 tosection=s1 />
<pages index="name of book.djvu" include=6 onlysection=s2 />
If needed, I can do the transclusion after the text is proofread. --Jan Kameníček (talk) 15:40, 2 June 2020 (UTC)[reply]
Thank you very much! -RiverThames27 (talk) 15:45, 2 June 2020 (UTC)[reply]
Oh and btw, I searched for ways to split the pdf pages since it's scanned in such a way that it shows 2 pages on 1 page, and all I have found was on extracting individual pages, and the only one that actually was what I was seacrhing for required a payed version of Acrobat Reader DC which I simply don't have. Since new chapters in any case begin in the middle of the page, would it be acceptable to upload this one despite the fact that one page actually contains several pages? And I would prefer to upload it to wikimedia commons so that it can be referred to in other wikis as well, but if ends up being copyrighted in it's country of origion (which doesn't exist anymore) I guess I will have to uplaod to wikisource. Thanks in advance, -RiverThames27 (talk) 16:37, 2 June 2020 (UTC)[reply]
I am very sorry, that is another thing I am not able to help with. I know Xover often helps people with scans, but according to the information on his user page he has been quite busy recently. But you can try to ask him on his talk page where he is more likely to answer. --Jan Kameníček (talk) 17:08, 2 June 2020 (UTC)[reply]
I've used gscan2pdf to split the side-by-side pages of the PDF. I uploaded the result to Commons and made a quick index at Index:Constitution of Rhodesia, 1965.pdf. Based on the wording that includes "antecedents of Zimbabwe" in the Commons commons:Template:PD-Zimbabwe template, I think it'll be OK at Commons. The file lacks an OCR text layer, but I'm not set up to deal with that at the moment. In the meantime, there should be an OCR button in your toolbar (which seems not to work), and there's a Google OCR button that you can enable here: Special:Preferences#mw-prefsection-gadgets. Inductiveloadtalk/contribs 17:09, 2 June 2020 (UTC)[reply]
Thank you very much! -RiverThames27 (talk) 18:14, 2 June 2020 (UTC)[reply]
@RiverThames27: On the copyright situation… Rhodesia was strictly speaking a British colony at the time this work was published, which would mean a Crown Copyright term of 50 years from publication. However, I would be inclined to say Zimbabwe is the successor in interest and the governing law; and in Zimbabwe the text of laws and related material is not eligible for copyright. The same is true in the US. That is, worst case (British law controlling), the copyright expired in 1965 + 50 = 2015. In other words, Commons should be fine. Oh, and the Index: is always here on Wikisource; we just outsource hosting the scan files themselves to Commons.
@Inductiveload: I'm tooled up for OCR with DjVu files, so I made a .djvu with text layer at File:Constitution of Rhodesia, 1965.djvu. I didn't bother making a separate index for it (if you prefer that one we can move the index and pages over; but if the Google OCR results are good enough it's probably not worth the effort).
@Jan.Kamenicek: Thanks for the ping. Right now my time is more unpredictable than all that limited, but I'm leaving the notice up because that situation will change based on the IRL situation in my neck of the woods. --Xover (talk) 18:59, 2 June 2020 (UTC)[reply]
@Xover: Thanks for the reply! About the OCR, I have already started typing one of the pages manually. Should I now just let it do that automatically? Thanks in advance, -RiverThames27 (talk) 19:12, 2 June 2020 (UTC)[reply]
@RiverThames27: That's up to you: the point of OCR is to save you manual typing.
PDF and DjVu-format files can contain a hidden text layer that Mediawiki knows to extract. When the file has such a text layer you will find the text box for each page prepopulated with that text. In addition, we have gadgets that give you an OCR button in the toolbar on each page. When you press the button the page image is sent to a server that runs OCR on it and sends back the results. In either case you end up with some text in the text field, it's just that in the latter case you had to press an extra button to get it.
The PDF file that you're currently transcribing against doesn't have a hidden text layer, so you'll need to use the OCR button. If you're happy with the results it gives you then there's no real reason to do anything else. If the results are very poor that way, we can try to move the Index: and Page: pages over to use the DjVu file which does have a text layer (that was made with a different OCR engine). It can some times make a big difference, but most of the time it's just six with one and half a dozen with the other. There's usually not a big reason to do so, I just happened to already have it processing before I saw that Inductiveload had already uploaded a PDF.
And if you want to type everything manually that's of course fine too. --Xover (talk) 19:56, 2 June 2020 (UTC)[reply]
Great! Of course, I'll be happy for the existing index to be migrated to the DjVu. Google OCR seems pretty good, but it's friendly to have the text layer. Inductiveloadtalk/contribs 21:29, 2 June 2020 (UTC)[reply]
@Xover, @Inductiveload: About migrating to the DjVu, is it just moving the page with Special:MovePage/Index:Constitution of Rhodesia, 1965.pdf to Index:Constitution of Rhodesia, 1965.djvu, and then repeat the same with the other pages that already exist, or is there more to it? Thanks in advance, -RiverThames27 (talk) 10:23, 3 June 2020 (UTC)[reply]
For this text it’s necessary since when I tried the OCR it recognised for the top part just the numbers, and for the bottom part just the text (it was a page from the table of contents) -RiverThames27 (talk) 10:25, 3 June 2020 (UTC)[reply]
It's better for an admin to do it, otherwise it makes a bit of a mess of redirects. For the OCR, try the Google OCR button, it's works well for the contents pages in this work. You can enable it under "Gadgets" in your preferences (look near the bottom). Inductiveloadtalk/contribs 10:34, 3 June 2020 (UTC)[reply]
I used the google OCR button and it’s actually quite good. It didn’t put it in the templates so it was all in one line at the beginning, but I have sorted this out. Thanks @Inductiveload:! -RiverThames27 (talk) 12:11, 3 June 2020 (UTC)[reply]
@RiverThames27: No OCR is going to give you a finished page; it'll always be just the text and with various levels of accuracy in recognising the letters. For some works the OCR engine used can make a big difference because different engines have different strengths and weaknesses. For most works it makes little difference. If Google OCR gives reasonable results you'll probably want to stick with that. For comparison, you can trick Mediawiki into showing you the hidden text layer of a file by going to a Page: link even if it doesn't have an index. So here are page 4 and 5 from the DjVu file: 4, 5 (please don't create these pages; they're not connected to anything). As you can see these need a lot of manual work too. If you you still want to switch to the DjVu then just let me know and I'll move the Index: and Page: pages over for you. --Xover (talk) 13:48, 3 June 2020 (UTC)[reply]
@Xover: I think the pdf version is good enough, google ocr is quite good in detecting text and I think the things that I actually had to correct were minor. -RiverThames27 (talk) 15:02, 3 June 2020 (UTC)[reply]
@Xover, @Inductiveload: Now all the table of contents is done. However, it shows me “This text needs to be proofread” How do I change it to “This text has been proofread but needs validating?” Thanks in advance, -RiverThames27 (talk) 15:24, 4 June 2020 (UTC)[reply]
Like in pages 1,6, and 7 -RiverThames27 (talk) 15:29, 4 June 2020 (UTC)[reply]
There are some buttons under the edit window to set the page proofread status. See Help:Page status for the whole process.

By the way, I have set up a template, {{CoR65 para/s}} to assist with the formatting, as those hanging paragraphs can be a bit fiddly. You can check the first few pages of the main text to see how they can be used. Inductiveloadtalk/contribs 15:44, 4 June 2020 (UTC)[reply]

Thank you very much! And btw, what’s with the page numbering? Why is there one more page 43 after page 92? I know it links to the proper page, but why does the text say 43? Thanks in advance, -RiverThames27 (talk) 17:20, 4 June 2020 (UTC)[reply]
That was in the original document. It is apparently the relevant clipping from the Southern Rhodesia Government Gazette (actually a Supplement). The page numbers for those pages are "1315 (43)" and "1315 (44)", where 1315 is (probably) the issue of the Gazette and 43/4 is the page number. Inductiveloadtalk/contribs 17:38, 4 June 2020 (UTC)[reply]
Thanks for you reply! Should those numbers stay that way or change? And can you check if I did the page Page:Constitution of Rhodesia, 1965.pdf/12 properly? I tried to imitate what you did in Page:Constitution of Rhodesia, 1965.pdf/11, but when I did the same that you did with the a, b, c it put the text after that in boxes like pre-formatted text. Thanks in advance, -RiverThames27 (talk) 17:48, 4 June 2020 (UTC)[reply]
You had a couple of misaligned start (/s) and end (/e) templates. There has to be exactly one /s for each /e. I fixed up p12 and now it seems to work OK. I also added the sidenotes. Inductiveloadtalk/contribs 18:03, 4 June 2020 (UTC)[reply]
Thank you very much! -RiverThames27 (talk) 18:46, 4 June 2020 (UTC)[reply]
Btw, I started working on Page:Constitution of Rhodesia, 1965.pdf/13, and every next line starts from the very beginning of the line. How did you make it so that every line starts from the same place as the previous one? Thanks in advance, -RiverThames27 (talk) 19:27, 4 June 2020 (UTC)[reply]
And btw, why does the progress say “Source file needs an OCR tex layer” if some of the pages are already ready? Thanks in advance, -RiverThames27 (talk) 19:32, 4 June 2020 (UTC)[reply]
You have to change the first template parameter from "0" (no level) to 1, 2 or 3 depending on the depth of the outermost number.
Progress is set manually with a drop-down in the Index page when you edit it. This file has no OCR text in it (you have to use the OCR button; if it had OCR, the OCR text would load automatically when you create the page). It doesn't mean you can't proofread it. When all pages are yellow, you can change the drop-down to "Needs validation". Inductiveloadtalk/contribs 20:09, 4 June 2020 (UTC)[reply]
Thank you very much! Now it works! Is there a way to make the side notes actually on the side like in the original text? Some of them are left side notes and others are right but it doesn’t seem to make any difference. Thanks in advance, -RiverThames27 (talk) 08:51, 5 June 2020 (UTC)[reply]
Yes, change {{left sidenote}} to {{right sidenote}}. Note: when "trancluded" (displayed in the main namespace), they will be rendered differently, according the the layout. Don't worry two much about perfect formatting for sidenotes, they will always be slightly different on a computer than they are on paper. Inductiveloadtalk/contribs 09:07, 5 June 2020 (UTC)[reply]
I mean some of them are left sidenote and others are right sidenote. They seem to look the same in practice. What’s the difference? -RiverThames27 (talk) 15:38, 5 June 2020 (UTC)[reply]
In the page Page:Constitution of Rhodesia, 1965.pdf/13 The first sidenote is a left sidenote and the second one is a right sidenote. What’s the difference? They look the same to me. Thanks in advance, -RiverThames27 (talk) 15:40, 5 June 2020 (UTC)[reply]
@Inductiveload, @Xover: What’s the difference between a left sidenote and a right sidenote because both appear exactly the same on screen. Thanks in advance-RiverThames27 (talk) 12:09, 6 June 2020 (UTC)[reply]
@Inductiveload, @Xover: Hello? -RiverThames27 (talk) 16:41, 6 June 2020 (UTC)[reply]
@RiverThames27: Left and right sidenotes display on the left and right side of the page, respectively, in the Page: namespace. When we transclude it for presentation in the main namespace the dynamic layouts will kick in and reformat them to fit the active layout. Looking at Page:Constitution of Rhodesia, 1965.pdf/13 the two first sidenotes are indeed on the left and then right side. The second one is hard to see on my computer due to the really rather unfortunate layout problems of sidenotes in the Page: namespace, but it definitely is there and displayed to the right. Does this not happen on your computer? --Xover (talk) 07:06, 7 June 2020 (UTC)[reply]
@Inductiveload: I was editing on my ipad, so it showed all the sidenotes on top of the text. I opened it on my computer, and it's a mess! It shows the text on the left part of the screen, and the image on the right part, and they collide with each other. Also, I noticed that there is a difference between the left sidenote and the right sidenote (on my ipad, they looked the same), and when I changed the right sidenote to a right sidenote, it started overlapping with the sidenote that was above! Is there any way to show the image bellow the text? Thanks in advance, -RiverThames27 (talk) 11:30, 7 June 2020 (UTC)[reply]
@Xover: Sorry, for some reason I didn’t notice you left the message and typed ping Inductiveload😅 -RiverThames27 (talk) 13:52, 7 June 2020 (UTC)[reply]
@RiverThames27: It is a mess in the Page: namespace, sorry, nothing to be done about that. It'll look better once it gets transcluded for presentation. The problem is that Mediawiki doesn't really have support for sidenotes so we've had to create a kinda hacky workaround. You can see an example of how sidenotes will look on The Solar System/Chapter 1.
There are also buttons in the editing toolbar to switch the order of the text edit field and the scan image (in the "Proofread tools" section; looks kinda like a Tetris block or something), but in my experience only the default side-by-side layout works well in practice. --Xover (talk) 17:40, 7 June 2020 (UTC)[reply]
However, it would be nice if at least the line-height parameter were allowed to be set up manually. If the line-height were smaller than the default 140%, the sidenotes would interfere much less.--Jan Kameníček (talk) 17:50, 7 June 2020 (UTC)[reply]
@Xover, @Jan.Kamenicek: Thanks for the reply! I understand. Surely there’s someplace where it’s possible to request support for sidenotes, isn’t there? In meta or in Mediawiki or somewhere. -RiverThames27 (talk) 19:42, 7 June 2020 (UTC)[reply]
Specific changes to the templates like {{Left sidenote}} can be asked and discussed here. As for changes to Mediawiki so that it supported sidenotes better, you can try Phabricator, but my experience with their responsiveness is not very good. --Jan Kameníček (talk) 20:01, 7 June 2020 (UTC)[reply]


@Jan.Kamenicek: setting line-height for sidenotes would require them to be divs, not spans, which would probably cause issues when they occur inside paragraphs. As they are (spans), they can't have a smaller line-height than the surrounding text. You can set it smaller in CSS, but it won't actually get smaller. It's the same reason {{smaller}} doesn't make line-height smaller, but {{smaller block}} does.
Adding display: inline-block to the span might be enough.
@RiverThames27: it's not really something that could be added from the MediaWiki side, it's more a problem finding a way to display then using HTML and CSS that works on all devices and screen sizes. Not a lot of love has been shown to them in the Page namespace, because that's a working area, the "presentation" area is in the Main namespace, where it's quite a bit better (but still not perfect).
There is a bit of scope in changing {{sidenotes begin}} for turning off one side, which would decompress the pages a bit, and then making the main column shrink to fit. Small windows will still be very tight, but might not overlap so terribly. Inductiveloadtalk/contribs 20:08, 7 June 2020 (UTC)[reply]
@Inductiveload: Well, I guess it will look fine🤷🏻‍♂️. It’s just weird that they the image shows up on the right side of the page, don’t they know that the text overlaps it? -RiverThames27 (talk) 12:12, 8 June 2020 (UTC)[reply]
"They" (by which I assume you mean the MediaWiki developers) probably don't really know, because we at enWS caused it though setting fixed widths (35em + 11em * 2) in the local {{sidenotes begin}} template. There's not a lot MW can do to help us that couldn't be sorted with a overhaul of the templates here at enWS first. Sadly, it'll always be a bit tricky as fitting six text columns (four sidenotes, two each for preview and scan, and two text bodies) size-by-side is always going to be a squeeze. Inductiveloadtalk/contribs 12:31, 8 June 2020 (UTC)[reply]
@Inductiveload: Oh. I see. Isn’t there an option to move the image though so that the text won’t overlap with the image? Thanks in advance, -RiverThames27 (talk) 12:38, 8 June 2020 (UTC)[reply]
There is an option to have the page vertically stacked in Edit mode (look in your preferences for the permanent setting, or there's a button in the edit toolbar to change temporarily). If you really want to have the stacked interface even when not editing, you could add the following to User:RiverThames27/common.css:
 * Top/bottom layout in Page namespace
.prp-page-content {
	float: none;
.prp-page-image {
	margin: 0 auto;
	float: none;
This is an ugly hack, but it might be good enough for your purposes. The real solutions are: 1) use a higher-resolution monitor (i.e. blame you, the victim) and, better, 2) we fix our templates. Inductiveloadtalk/contribs 12:52, 8 June 2020 (UTC)[reply]
For anyone with interest in sidenotes: I have a proposal at Template_talk:Sidenotes_begin#New_approach for a change that would prevent sidenotes spilling over the page image in Page namespace. If my calculations are correct, it should be a drop-in replacement in terms of parameters. It's not a resolution to every single sidenote issue, but it's a start and doesn't require botting all 21786 users of {{sidenotes begin}}. Inductiveloadtalk/contribs 14:38, 8 June 2020 (UTC)[reply]
@Inductiveload: Sounds good, but I’m not really qualified to make such decisions. -RiverThames27 (talk) 09:23, 9 June 2020 (UTC)[reply]
@Inductiveload, @Xover, @Jan.Kamenicek: Oh btw, some of the pages end with CoR65 para/e despite the fact that the paragraph continues on the next page. Will that make the text in the finished product start in a new line despite the fact that it’s the same paragraph? Thanks in advance, -RiverThames27 (talk) 20:03, 12 June 2020 (UTC)[reply]
An example: Page:Constitution of Rhodesia, 1965.pdf/14 -RiverThames27 (talk) 20:05, 12 June 2020 (UTC)[reply]
Put the end template in the footer, and the start template on the next page in the header and it should work. The header and footer are not transcluded into the main namespace. See Page:Constitution of Rhodesia, 1965.pdf/11 for example. Inductiveloadtalk/contribs 20:48, 12 June 2020 (UTC)[reply]
@Inductiveload: Thank you very much! I will fix it right away. -RiverThames27 (talk) 09:32, 13 June 2020 (UTC)[reply]
I put the end template on the footer just on pages where the the paragraph didn’t end and the start template on the header just on pages where the the first paragraph is actually the continuation of the paragraph on the previous page. That’s what should be done, right? And btw, what to do with pages where a word continues on the next page? For example, the word subscribe starts at the end of Page:Constitution of Rhodesia, 1965.pdf/15 and ends the beginning of Page:Constitution of Rhodesia, 1965.pdf/16. Will that effect the way it looks in the end product? I deleted the - so that it won’t show up in the end product, but they show up with a space in between? Thanks in advance, -RiverThames27 (talk) 09:51, 13 June 2020 (UTC)[reply]
@RiverThames27: If a word is split between pages, just leave it as sub- and scribe, and Proofread Page will remove the hyphen and join the words without a space character when transcluded. If you need to preserve the hyphen of a hyphenated word (like off-campus), replace the hyphen with the template {{peh}}. You can, if you prefer, get fancy and use {{hws}}/{{hwe}}, but I don't generally recommend that (it used to be needed for all split words, but these days it's only when a word is split inside a footnote, and it is needless complexity). --Xover (talk) 11:08, 13 June 2020 (UTC)[reply]
@Xover: Thank you very much! I added the hyphen back. -RiverThames27 (talk) 11:48, 13 June 2020 (UTC)[reply]
@Inductiveload: While editing the pagePage:Constitution of Rhodesia, 1965.pdf/20, I run into a problem with putting the title. Actually, I forgot how to do this😅, so I started searching in other pages how to do this. Then I noticed that in the page Page:Constitution of Rhodesia, 1965.pdf/13 there’s a problem with the chapters. The text Chapter III, and the title of chapter III appear, but the text part 1-composition doesn’t. Then I tried to search in the table of contents how to fix the chapter problem, and just made it worse, so I deleted it all together. However, I noticed that in Page:Constitution of Rhodesia, 1965.pdf/10 the text Chapter II and the title appear on the same line, which is also a bug that I don’t know how to fix. Can you please check what’s the problem? Thanks in advance, -RiverThames27 (talk) 12:50, 16 June 2020 (UTC)[reply]
You tried to use a template that only works inside the TOC table outside of a table. Just format it with {{center}} as normal text. For page /10, I just added a line after the center template opened. Inductiveloadtalk/contribs 12:57, 16 June 2020 (UTC)[reply]
Thank you very much! I wonder if there’s a page for the longest discussions in ws:s/h🤔 Since this discussion is quite long😅. -RiverThames27 (talk) 13:01, 16 June 2020 (UTC)[reply]
@Inductiveload, @Xover, @Jan.Kamenicek: Btw, about chapters that start in the middle of the page, I planned to leave this question for after all the pages are proofread, but it would be a pain to go through all the pages and fix it. I need to put the #s with s1 on the very top of the page, and them the #s with s2 just above the text Chapter <Chapter number>, right? And I only need to do this in pages where there’s a beginning of a chapter, there’s no point putting the #s with s1 on every page, right? Thanks in advance, -RiverThames27 (talk) 09:19, 17 June 2020 (UTC)[reply]
Correct on both counts. Later, you can refer to H:Transclusion#sections, which explains how to place only that section on the final page. Inductiveloadtalk/contribs 09:24, 17 June 2020 (UTC)[reply]
Thank you very much! -RiverThames27 (talk) 19:44, 17 June 2020 (UTC)[reply]
@Inductiveload: I tried to follow these instructions with the following page: Page:Constitution of Rhodesia, 1965.pdf/9 (the last page of the table of contents, and the first page of the actual constitution, but it just shows: 1. 1. "s1" ##. Could you please check what’s wrong? And also, should I put the label for section 2 before or after the text “IT is hereby notified that we, the Government of Rhodesia, have adopted, enacted and given to Rhodesia this Constitution.” I put it after and right before the text chapter one. And I also accidentally made it so that the text chapter I appears on the same line that the title. Thanks in advance, -RiverThames27 (talk) 19:55, 17 June 2020 (UTC)[reply]
The problem is caused by the quotation marks in ## "s1" ##, it should be just ## s1 ## --Jan Kameníček (talk) 20:12, 17 June 2020 (UTC)[reply]
Btw, I have managed to fix the problem with the title. -RiverThames27 (talk) 20:00, 17 June 2020 (UTC)[reply]
1) Don't use quotes in the section name, it breaks the magic. 2) It needs a {{nop}} to prevent the table row merging with the section header. 3) It also needed a nop at the top of each page to stop the first row of each page merging with the last row of the prior page. Yes, it's weird, sorry! It now transcludes OK with <pages index="Constitution of Rhodesia, 1965.pdf" from=1 to=9 tosection=s1 />.
@Inductiveload, @Jan.Kamenicek: What is the meaning of the section dummy in Page:Constitution of Rhodesia, 1965.pdf/9. Is it a must to put it in between every two chapters or is it something specific here because it’s in the table of contents? Thanks in advance, -RiverThames27 (talk) 09:23, 24 June 2020 (UTC)[reply]
All that means is the {{dhr}} can be excluded when the page is transcluded (<page .... to=9 tosection="s1"/> and <page .... from=9 fromsection="s2"/>). You could equally not use a dummy section and have it at the end of "s1" and no-one would notice, it'd just make a tiny blank gap at the end of the transcluded content. There is nothing special about the word "dummy", it's just another section. Inductiveloadtalk/contribs 09:57, 24 June 2020 (UTC)[reply]
@Inductiveload: Thank you very much! -RiverThames27 (talk) 20:29, 24 June 2020 (UTC)[reply]

{{Dotted TOC page listing}} formatting query[edit]

Is it possible with {{Dotted TOC page listing}} to have the page numbers nestling in under the entry column - as here, rather than out in Col3? Thanks. CharlesSpencer (talk) 17:52, 9 June 2020 (UTC)[