Wikisource:Scriptorium/Help

Trouble with file from commons

I have uploaded on commons a djvu file. It looks fine over there, but here and on wp the file is registered as being 0x0 (not as empty, though), and trying to link it just gives a link, not the file. Am I the only one having this problem, and can someone tell me how to fix it? — Alien333 (what I did — why I did it wrong) 19:48, 21 March 2024 (UTC)

I'm not seeing a problem with the file. Do you want me to create the Index: for you? Beeswaxcandle (talk) 02:13, 22 March 2024 (UTC)

Nevermind, apparently now it works. When I tried to create the index yesterday the pagelist did not work because the file was 0x0 pixels. I can take care of the index, thanks. Alien333 (what I did — why I did it wrong) 06:35, 22 March 2024 (UTC)

@Alien333: I had the same exact problem with an Index yesterday: File:The Plutocrat (1927).pdf. It is extremely weird, and I believe it's an issue on Commons' end. I was able to fix it in a few minutes, though. SnowyCinema (talk) 06:42, 22 March 2024 (UTC)

What did you do? Or did it just fix itself? Alien333 (what I did — why I did it wrong) 07:10, 22 March 2024 (UTC)

@Alien333: So here's exactly what happened. I uploaded the file (revision 1) and it appeared as 0x0 just like you described, and the Index page's pagelist threw an error that I can't remember now. So, what I did was I uploaded another version of the same PDF, just directly taken from IA instead of modified by me in a certain way, and then uploaded that with chunk upload (revision 2). It initially seemed to be a working file, but then I deleted and recreated the Index again, to find out that this revision was now broken. So I reverted to the previous revision (revision 1) as revision 3, and somehow that worked.

TLDR: Revision 1 was broken and when I uploaded revision 2, that revision appeared to work at first. But then it reversed out of nowhere, to where revision 1 was working now and revision 2 magically broke in its place. . . . If this is confusing to you, it's exactly as confusing to me so don't worry. I have no idea what the issue was. ☹️ SnowyCinema (talk) 07:15, 22 March 2024 (UTC)

The error was "Invalid interval" (at least for me). What I think is that the file got broken during some sort of transfer from commons to here (since it was also broken on wp). On top of being 0 x 0 pixels, Invalid interval probably meant it was 0 pages long (even an empty pagelist got an error). The file was still registered as being 1.something MBs long (here, on commons, and wp). I do not think it was an issue with the file I uploaded, as on commons everything looked good. That's what I know. I also had a vague suspicion of it being linked to the server switch on wednesday, but it might have nothing to do with it. Alien333 (what I did — why I did it wrong) 07:29, 22 March 2024 (UTC)

Servers and backends and deployment are quite finicky, and there are a million mysterious things that can go wrong all of a sudden. It's hard to really say exactly what happened without talking to someone who has the keys so to speak. Our global multisite system is bound to be quite complex on the backend, I'll say that much... SnowyCinema (talk) 07:41, 22 March 2024 (UTC)

@SnowyCinema It's just happened again with File:The Poems of Sir Thomas Wiat, volume 2.djvu. If this becomes a recurring problem, we should maybe ask about it to the commons people. Alien333 (what I did — why I did it wrong) 09:58, 23 March 2024 (UTC)

@Alien333:: Hi, I've "purge" the caches of the file in Commons and of the Index, and it seems to have fixed the issue. M-le-mot-dit (talk) 10:15, 23 March 2024 (UTC)

I tried purging the caches on thursday, and it didn't help. I guess this just fixes itself with time. Alien333 (what I did — why I did it wrong) 13:04, 23 March 2024 (UTC)

@Alien333@Beeswaxcandle@M-le-mot-dit@SnowyCinema I have experienced (and reported) the same issue. Although the problem sometimes seems to fix itself, I have a number of cases where it has not (>6 months, which I assume means never), and a number of cases where random pages in an otherwise functioning PDF are completely unreadable on WS. I've basically given up uploading PDF files (even though I have paid-for PDF editing software - Foxit) and default to DJVU. Converting PDF's to DJVU with 'Pdf 2 Djvu Converter' generally works OK. Chrisguise (talk) 13:17, 26 March 2024 (UTC)

I just had this same problem with Index:Florula Mortolensis.djvu, where the pagelist is broken and the file appears as 0x0 on WS (but works fine on commons. I used the IA upload tool.) Purging the caches didn't help, but hopefully it fixes itself, as it seems to. Cremastra (talk) 20:54, 27 March 2024 (UTC)

When I had the problem (here) I purged the cache on Commons first, then on Wikisource, and that seemed to work. Arcorann (talk) 08:16, 29 March 2024 (UTC)

Indeed, after having the problem with Index:Poems Coolidge.djvu, clearing the cache on commons and then here fixed it. Maybe doing it in the other order doesn't work.

@Chrisguise: I'd be curious if you could try to do this on those indexes you mentioned that did not fix themselves, to see if that method works. — Alien333 (what I did & why I did it wrong) 19:12, 7 April 2024 (UTC)

@Alien333@Arcorann@Beeswaxcandle@Cremastra@M-le-mot-ditI know I've seen something on here about how to purge Commons files (you add something to the address), but I can't find it. Could someone remind me please. Chrisguise (talk) 03:47, 13 April 2024 (UTC)

I just use the "purge clock" gadget, but I think it would be with something like "commons.wikimedia.org/w/index.php?title=[page title]&action=purge" — Alien333 (what I did & why I did it wrong) 07:58, 13 April 2024 (UTC)

Thanks. I hadn't previously delved around the gadgets section on Commons. Doing the two purges has fixed one of my problem files (a DJVU, unusually). I'll try it on a PDF. Chrisguise (talk) 08:18, 13 April 2024 (UTC)

@Chrisguise: In my case, I've first purge the Common file, then the Wikisource index.--M-le-mot-dit (talk) 08:19, 13 April 2024 (UTC)

Thanks, my first attempt with this approach worked. Need to dig out some more of my problem files to try. Chrisguise (talk) 08:22, 13 April 2024 (UTC)

Proofreading Paragraph Problem.

Sometimes while proofreading, I finish a page where the lines are not joined, but then the last editing "line breaks" in a page create new paragraphs. I don't know why this should be- my usual workaround is just to have no line breaks on the source page for the last paragraph. But this looks messy and it is annoying. Is there some obvious reason that this happens that I can avoid in the future? @Mpaa, perhaps you know the answer, I know sometimes you prefer that lines not be joined, so you have likely run into this problem.

Example page. The last line should not be its own paragraph.

Sorry if 1. The question doesn't make sense or 2. There's an obvious solution. -- FPTI (talk) 06:33, 24 March 2024 (UTC)

The {{nop}} template needs to be on its own line. Once you've done that, then the problem will go away. However, it is most preferable to remove line breaks within paragraphs as leaving them in is known to cause problems with transclusion. Beeswaxcandle (talk) 07:17, 24 March 2024 (UTC)

Apologies, but I don't think that's it. Example page. This one has no { {nop}} but there's still a line break for that last line. @Mpaa? FPTI (talk) 07:59, 1 April 2024 (UTC)

@FPTI@Beeswaxcandle I have experienced the same issue before. What seems to happen is that there are extra carriage returns in the text, which are not visible. If you turn on "Generate paragraph (pilcrow) markers, ¶, in the left margin of the Page: namespace to indicate HTML paragraph tag starts." in Preferences-Gadgets they can be seen. I had to log out and log back in to activate the gadget. I don't have this gadget activated normally but it shows what the problem is. After proofreading text I usually run a tool that cleans-up the OCR text, which removes these in-paragraph line breaks Chrisguise (talk) 09:53, 1 April 2024 (UTC)

@FPTI I do not know what the problem is, but I am fine with it as it is transcluded correctly. As the problem is only in Page ns, it might be some glitch in ProofreadPage Extension. Mpaa (talk) 09:57, 1 April 2024 (UTC)

It is not specific of Page ns. In Page ns it happens only when in the footer there is some content inside a div block. The same can be reproduced in Main ns appending a div block to the last line, e.g. something like of course it was only a few seconds. I had leisure<div class="x">vv</div> Maybe it might be the parser that, when it finds the div block, insert a paragraph break at the beginning of the line ... who knows .... Mpaa (talk) 14:26, 1 April 2024 (UTC)

Indeed. This is p-wrapping and a rather dumb regex-based (essentially) parser. The parser thinks that all text has to be wrapped in a p tag, so as it parses the wikitext it is looking for various triggers for when to add an opening p tag, and when it needs to add a closing p tag. The parser sees Page: namespace pages as a single blob of wikitext, with the header and footer merely marked as noinclude sections. When there is a div (i.e. what {{c}} spits out) in the footer the parser notices, and since div elements are not valid inside p elements it decides it has to close the currently open p. To do that it backtracks and guesses at where the paragraph it just closed should start, and decides it's at the first line break character it comes to (i.e. the one between the last and penultimate line). In other words, whenever you have anything in the footer that isn't permitted inside a p element, the parser will put the last text line into its own paragraph hanging loose at the end of the page.

The even better news is that the shiny new parser (known as Parsoid) has been designed to be bugwards compatible with the old parser, so it will blithely reproduce this bug in exactly the same way as the old grotty parser. Oh joy!

But the moral of the story is the same as the advice given by the old-timers from the beginning: always remove hard line breaks inside paragraphs! Xover (talk) 12:42, 8 April 2024 (UTC)

Thank you! FPTI (talk) 07:21, 9 April 2024 (UTC)

Actually over the time I tend to preserve new lines as printed. It makes Validation much easier. The page break is just a cosmetic issue in Page ns with no relevance when transcluded. Mpaa (talk) 16:45, 9 April 2024 (UTC)

Hello, can you tell me what tool do you use for cleaning the OCR? The same issue is happening in every page to me. HendrikWBK (talk) 11:29, 8 April 2024 (UTC)

@HendrikWBK: For unwrapping hard-wrapped lines I use a custom user script. You can add mw.loader.load("//en.wikisource.org/w/index.php?title=User:Xover/unwrap.js&action=raw&ctype=text/javascript"); // Backlink: [[User:Xover/unwrap.js]] to your common.js to try it out. It adds a link in the left sidebar (in Vector 2010) or to the tools menu (in Vector 2022) labelled "↲ Remove hard line breaks" that does what it says on the tin. This was a hacky little thing I threw together for my own use, so no warranties. The source is in User:Xover/unwrap.js if you want to check what it does. Xover (talk) 12:55, 8 April 2024 (UTC)

Thank you, the issue is fixed. It also adds a link in the left bar in MonoBook HendrikWBK (talk) 13:18, 8 April 2024 (UTC)

How to create a placeholder page?

Hello, I'm from Wikisource Indonesia. I'm courious, for {{missing pages}} it says, "Placeholder should be inserted....". If the proofread has been done, how to create a placeholder page? Thanks. Mnam23 (talk) 01:12, 25 March 2024 (UTC)

Two steps are generally required: 1. The actual insertion of placeholder images into the scan file and then reuploading to Commons / Wikisource. 2. The movement of the pages to reflect the updated source file. The first depends on the file format, for example djvus are typically easy while PDFs are trickier. Help:DjVu_files#Inserting_a_new_pages_(e.g._a_placeholder) is an example of how to do that. The movement of large numbers of pages can be automated by requesting a bot / admin to bulk move as not to lose history. For help you can ask in the Wikisource:Scan_Lab. MarkLSteadman (talk) 01:21, 25 March 2024 (UTC)

Just making sure, if the placeholder page is already inserted, the template should stay on the Index page, just changing the parameter placeholder=yes, right? Mnam23 (talk) 07:59, 26 March 2024 (UTC)

Copyright question

Does this thesis (https://doi.org/10.7907/KW0Z-FQ64 / https://thesis.library.caltech.edu/10468/) meet the copyright requirements to be added? Nobody (talk) 12:17, 25 March 2024 (UTC)

Just to note, I was unable to access either of the sites linked, so for anyone else who had this problem, here's a working version of the Caltech link, and the PDF file of the 1951 thesis. The thesis is "Design and Calibration of a New Apparatus to Measure the Specific Electronic Charge" (1951) by George Clement Dacey (1921–2010).

My personal opinion is that this is in the public domain in the US, since it does not contain a copyright notice and it was published before 1977. I think academic papers generally count as published, but I'm not 100% sure. @TE(æ)A,ea.: What do you think? SnowyCinema (talk) 12:45, 25 March 2024 (UTC)

It's also Q119716034 for some additional info. On The Caltech page, it says, "Thesis Availability: Public (worldwide access)", which I don't believe means the copyright status. It also says "Default Usage Policy: No commercial reproduction, distribution, display or performance rights in this work are provided." Which sounds more like a copyright status, but I'm not sure. Nobody (talk) 13:45, 25 March 2024 (UTC)

• Nobody, SnowyCinema: We had a lengthy discussion about this in the past, see here. The result of that discussion, as stated, was that there was no precedent, but that the thesis in that case was not copyrighted. I do not see how the decision is not precedent, as the arguments in that discussion were general and not relating to that thesis in particular. My opinion, and the sources of that opinion, are stated in more detail in that discussion. In sum, the publication is voluntary, and it is “general” because anyone can access the copies which are available in the university library’s collection. Because there was a general publication, and there was no copyright notice, it is in the public domain. TE(æ)A,ea. (talk) 17:36, 26 March 2024 (UTC)

  Thanks for the explanation TE(æ)A,ea., then I'll go figure out how to add it. Nobody (talk) 18:31, 26 March 2024 (UTC)

  I created this, but I'm pretty sure I'm missing something and I can't figure out what. Nobody (talk) 19:32, 26 March 2024 (UTC)

  I fixed the quoting which was why it wasn't rendering. MarkLSteadman (talk) 20:36, 26 March 2024 (UTC)

Help with index page

Still very new to Wikisource, so sorry if my question seems dumb. After creating NOAA Storm Events Database – 2023 Matador tornado, I tried following the Index directions to create Index:NOAA Storm Events Database – 2023 Matador tornado, but the “Index” tab still doesn’t seem to show up on the text source. I’ve been working with another editor to add works of NOAA (U.S. government) (Category:PD-USGov-NOAA), and I’ve been struggling with figuring out how to do the Index pages with the few texts we have up. Can someone give some Index page assistance for the Matador tornado’s text as well as with the couple of other pages in that category. I’m not sure what I’m doing wrong exact. Thanks. WeatherWriter (talk) 16:11, 26 March 2024 (UTC)

An index works with a file. It is mostly a handy way to organize pages of that file.

The source for this appears to be a website. There is no point having an index without a file.

You can put a {{textinfo}} on the talk page and put in "source" instead. Alien333 (what I did — why I did it wrong) 17:07, 26 March 2024 (UTC)

Page:I will repay.djvu/285

Could someone please validate this page? Mpaa (talk) 15:24, 1 April 2024 (UTC)

Done SnowyCinema (talk) 15:51, 1 April 2024 (UTC)

Formatting assistance on Statistics of April 3-4, 1974 Tornadoes

Can someone assist with formatting Statistics of April 3-4, 1974 Tornadoes like it is on the government website? It also need a quick proofread. Thanks! WeatherWriter (talk) 16:07, 1 April 2024 (UTC)

@WeatherWriter Since it's a PDF (as opposed to an HTML webpage), it's best to upload it to Commons and use the Index: namespace. I'll upload it to commons on the understanding that it is a U.S. federal government work. Cremastra (talk) 16:16, 1 April 2024 (UTC)

...and here's your index page. Cremastra (talk) 16:19, 1 April 2024 (UTC)

font-feature-setting:'hist'

I am experimenting with using CSS for long-s instead of {{ls}}—essentially treating it as a glyph of s rather than as the separate character ſ. I've set up the CSS at Index:1644 Anabaptist Confession of Faith.djvu/styles.css but it doesn't seem to work (loading Page:1644 Anabaptist Confession of Faith.djvu/4 in Chrome on Windows, anyway).

Normally I would assume that it's not working because of some limitation in MediaWiki. However, I have used the exact same method for {{insular}}, and it seems to work fine there, so I am stumped. —Beleg Âlt ^BT (talk) 18:03, 3 April 2024 (UTC)

@Beleg Tâl: Fonts are hard. Xover (talk) 15:16, 8 April 2024 (UTC)

Ha, thanks—so it was just that the Junicode documentation was wrong, I guess :D —Beleg Tâl (talk) 19:50, 8 April 2024 (UTC)

DjVu file with blanked page

This is a bit of an odd case and I have no idea how to fix it. Page 155 (153 as numbered in the book) of File:The Salticidae (Spiders) of Panama.djvu appears to be blank. However, in the actual book it has text and in the file there is a text layer on that page that has the correct text correctly laid out. But for some reason the image for that page doesn't show the text. I was able to track down the physical book and scan the page in question, which is now at File:The Salticidae (Spiders) of Panama page 153.jpg. Is there any way to either integrate that file into the Index or repair the faulty DjVu file with it (preferably without losing the existing text later)? I have not been able to find any other scan of the book other than the one at the Biodiversity Heritage Library, which is the source for our scan. Nosferattus (talk) 22:08, 3 April 2024 (UTC)

@Nosferattus: Done. Another scan is available at Internet Archive identifier: bulletinofmuseum97harv. This type of help is usually posted there: Wikisource:Scan Lab. --M-le-mot-dit (talk) 11:01, 4 April 2024 (UTC)

@Nosferattus: pages 44 and 267 were also blank. Done --M-le-mot-dit (talk) 12:34, 4 April 2024 (UTC)

@M-le-mot-dit: Thank you!! Nosferattus (talk) 15:18, 4 April 2024 (UTC)

Validation/Feedback Request

I've been working on Ginzburg's Legends of the Jews as my first Wikisource project. (And yes, I understand that it's a massive, probably foolhardy endeavor for a first project. But here I am.)

I've just finished with the first chapter of volume 1 and the corresponding endnotes in volume 5.

I'd really appreciate one or more experienced editors looking over what I've done so far and giving me constructive feedback. (And it seems reasonable to validate what I've done along the way.)

Is my error rate acceptable for a "proofread" text? Am I using the {{Authority reference}} template correctly? Am I inadvertently making more work for myself or others down the line? Heck, is there anything I'm doing straight-up wrong? Any feedback, positive or negative, is much appreciated. If I'm going to invest the time and effort to complete this project, I want it to be good, not just good enough. And I'd like to hew as best I can to Wikisource best-practices.

A few notes on what I've already done:

• The endnotes are chock-full of abbreviations, and I found that preserving the distinction between word spaces and sentence spaces there improved readability a fair bit. I've kept the sentence spaces to 0.5 em, so hopefully that won't bother ardent single-spacers too much.
  • I have not done the same in the main text, as it didn't seem necessary. But if that consistency is important, I can certainly do the wider spaces in the main text as well.
• There is a fair bit of German, Hebrew, Latin, and Greek in the endnotes. I've studied the first three languages formally and have confidence in my ability to edit/proofread the snippets of those languages. Hopefully, relatively few errors have slipped through. I am completely self-taught in Greek, however, and would certainly appreciate someone who has formally studied Ancient Greek to scrutinize those bits.
• Is it normal for endnotes to take quite a bit more effort than the main text?

Thank you for any help/feedback you can offer! - Dave314159 (talk) 19:39, 4 April 2024 (UTC)

A few things (though I haven't been around for that long and am not that experienced) :

• I saw while looking at a random page that you used {{SIC}} for an outdated spelling (marvellous). It is not for that, but only for typos. Outdated spelling and other things that seem wrong but intentional should be kept as they are.
• Section titles should not be using ='s and the like, because they make formatting as it is made on-wiki and that was not in the original text. For example, on Page:Ginzburg - The Legends of the Jews - Volume 1.djvu/49, it should only be centered and sc'd, as ='s put in in bold and that was not in the scan.
• Keeping formatting of titles includes line breaks and all, for pages like Page:Ginzburg - The Legends of the Jews - Volume 1.djvu/26.
• Rather than raw wikitable formatting, you have {{TOC row r}} to take care of the titles in TOCs (the formatting you did also did not display after the second |+).
• A maximum width is sometimes put in TOCs with |width=, although it is in no way an obligation, to make it more easy on large screens (It can become hard navigating a max-width ToC when the line number is far to the right). Example taken with random page : Tom Swift Among the Diamond Makers

Apart from that, you're doing well, and you've already learned most important things. Keep going ! — Alien333 (what I did & why I did it wrong) 20:25, 4 April 2024 (UTC)

Oh, and : there's no problem starting with a large work, I did too, and anyway there are no constraints on time or on the quantity. Every page helps! — Alien333 (what I did & why I did it wrong) 20:27, 4 April 2024 (UTC)

>I strongly recommend against using templates for TOCs. [No I don't. It's the dot-leaders that are actually bad. Table wikimarkup over TOC templates is just a weak general recommendation. But I'm an idiot that keeps dashing off messages when I don't have time to actually check what I'm writing and end up saying dumb stuff. --Xover (talk) 22:12, 4 April 2024 (UTC)] I generally recommend table wikimarkup over TOC templates. None of the ones we have are technically sound, and using raw wikimarkup for table gives you both more flexibility and more robust results. The main downside is the learning curve, but when you figure it out it can be reused across all works. But if you insist on using ToC templates, at least stay away from the ones that try to fake dot leaders. They're oh so tempting, but they are also oh so broken and will create problems.

Also, width is set on transclusion with dynamic layouts ("Layout 2" is a common constrained-width layout). Setting the width of the table directly is a bad practice and should be avoided, unless there is a really pressing need for it. Xover (talk) 20:52, 4 April 2024 (UTC)

Well, so much for me. Could you just tell me, for the sake of curiosity, how the dot-leaders are broken? Maybe it should be put on the TOC templates page. — Alien333 (what I did & why I did it wrong) 06:13, 5 April 2024 (UTC)

Web standards do not support dot-leaders natively (there's a proposal that's been floating around for ages, but no forward motion). That means we have to fake them using other mechanisms, and all those mechanisms end up being directly contrary to how the standards are supposed to work. The result is that the implementations we have are very ugly, hard to support, have many problems even when they seemingly work, and are very prone to break when things around them change or they are used in a different context.

For example, since there is no way to generate a dynamical-length line of dots one implementation spits out something like a hundred period characters and spaces and uses styling tricks to hide the overflow. That breaks on very wide screens (add more dots and spaces, and everyone pays the cost on every page load). The hiding uses a white background color, which breaks in dark mode and in ePub exports (can somewhat be worked around with ever more special-case styling). Hacking around web standards also leads to incredibly complex markup, which combines with stuff like the 100+ dot characters, and leads to those implementations outputting huge amounts of data that we pay for every single time those features are used. I posted a particularly egregious example in WS:S#Orley Farm Contents+Illustrations Lists.

Note that my harping on about this is in the vein of advocating that these templates be deprecated. They aren't actually deprecated, so nobody is going to chide you if you do use them and this all is strictly speaking just one contributor's opinion. But I intend to keep bringing this up every chance I get in the hope that the community will eventually get tired enough of it to deprecate them just to make me shut up already. Xover (talk) 09:25, 5 April 2024 (UTC)

I feel a but stupid asking this and there is probably an obvious answer, but how does the table markup you gave on that page (<tr> <td style="text-align:right;">I.</td> <td style="font-variant:small-caps;">—the commencement of the great orley farm case</td> <td style="text-align:right;">1 </td></tr> ) do dot-leaders? To me it seems it only does the alignment. Or is it intentional, are you saying we should just omit dot leaders? — Alien333 (what I did & why I did it wrong) 10:29, 5 April 2024 (UTC)

The dots are drawn first, over the whole area; maybe the whole page. I know this because I tried to use it in the {{AuxTOC}} and changed the background color to Transparent, which exposed them. And then, the table elements have a background color to hide those dots.

The complicated templates, those using {{TOC begin}} are not as "bad" as the easier to use like {{Dotted TOC line}} and kin. The latter make a whole separate and different table for each entry (row). There is a category here, filled with indexes that use those (truly, much much much easier to use) templates where several of the pages just simply will not draw due to the heavy requirements upon the computers here. Unfortunately, my links to that discussion and category are elsewhere, so you will just have to take my word for it. They are worse than uncrunched pngs for processing time and *terrible* for small dedicated devices (like ereaders and maybe phones).

Being an avid and devout lover of the dotted tocs, I have been trying (and succeeding) to avoid them for Table of Contents use, but, the occasional small table found within works -- well, I indulge, feeling guilty like eating French Silk Pie for breakfast (which is technically scrambled eggs). But really, don't use the simple templates ever. And if you do -- Inductiveload has a script/tool which will convert the simple ones into complicated ones. My link for that is somewhere else also -- perhaps Mr. IDL will show up and drop it here.

The advice about manually making the tables is very good and the sooner started to learn the sooner learned. TOCs, while many are simple, several have a fineness and uniqueness of character which will improve anybody's skill level.--RaboKarbakian (talk) 11:01, 5 April 2024 (UTC)

(I'd never heard of {{dotted TOC line}} before this discussion)

And then what about the {{TOC row}}'s? They are less problematic, but how problematic are they? I have been using more or less only them since coming here.

Is there a guide about tables? I know how html tables work, but what else is there to learn? — Alien333 (what I did & why I did it wrong) 12:04, 5 April 2024 (UTC)

The best guidance we have right now is slightly camouflaged inside Help:Page styles. The most flexible, powerful, and robust way we have of doing tables right now is table wikimarkup combined with formatting applied through per-work page styles (the "Styles" tab on Index: pages; the CSS there is automatically loaded on all associated pages in the Page: namespace and in mainspace when transcluded using PRP). We need to make that approach more user friendly and reusable (ready-to-use snippets that can be copied), and create better documentation, but apart from the learning curve I heartily recommend it.

And compared to general HTML tables we have some unique problems stemming from the fact that we don't write HTML directly; we write wikimarkup that gets parsed and rendered into HTML by MediaWiki, and which is presented inside the skin and site chrome, etc. Compared to your typical CMS we also do far more advanced formatting than, say, a journalist banging out a news story or whatever. And then there is the added complication for Wikisource that we have to split these already twice-abstracted tables across wikipages in the Page: namespace and make them work together when transcluded together. Put together this means tables are one of the most difficult areas for contributors to deal with (which is why the lure of TOC templates is so great: it seems obvious that there must be an easier way to do this). Xover (talk) 12:18, 5 April 2024 (UTC)

To come back to the point, how does CSS do dot-leaders? It's not mentioned on Help:Page styles, and they even appear to be voluntarily left out, as two of the three examples have dot leaders and they are not taken into account. — Alien333 (what I did & why I did it wrong) 12:27, 5 April 2024 (UTC)

@Alien333: Oh, I'm sorry, I misunderstood. I am saying to simply not try to do dot-leaders, using any method, until web standards and web browsers actually support them natively. Everything else I write above is about tables and TOCs in general. Xover (talk) 13:13, 5 April 2024 (UTC)

The example omits the style sheet applied and other stuff. It's just meant to illustrate that the output from the templates is completely unreasonable. Xover (talk) 12:06, 5 April 2024 (UTC)

@Dave314159 It seems the responses above are drifting a little off topic, when it comes to the original question, which I will do my best to stick to. That said, so it is on record, I favor TOC begin, TOC row etc. While I have avoided validating anything for the moment, accuracy wise, the proofreading is good, and a few tips follow.

If you are doing anything with either strange formatting, or strange references, I strongly recommend transcluding the work as you go. In your case, I am not sure the endnotes are working, except those endnotes that you have specifically set the |transclude= parameter for. Because the endnotes are in a different volume, you may be forced to always use |transclude=, and may have to add this to every endnote thus far... That said, I am by no means an expert in endnotes. My main 'experiences' were with The History of Witchcraft and Demonology, which ended up working out eventually, endnote wise, but is far from finished, even with help. But yes, endnotes take an annoying amount of time. Other than that, if you need help with transcluding, ask away, although you seem to have a reasonable grasp of things so far.

Also, your headings do not seem to conform to wikisource styles, as far as I am aware. For example, I believe ==={{sc|The First Things Created}}=== should just be {{c|{{sc|The First Things Created}}}}, and similarly {{c|I<br>{{uc|The Creation of the World}}}} instead of == I: {{uc|The Creation of the World}} ==. Note that I removed the colon ":", because it isn't there in the first place, but thought I should finish this response before doing anything else to the text.

I also believe that manually setting sentence spaces is against wikisource styles (as in, do not force a double space at the end of a sentence, even if the original text does). As you can see in the example for the wsp template, it is for poetry and the like. To save you the trouble, a bot request can probably remove all of these, when the time comes.

I haven't formally (or informally) studied ancient Greek, so can't really help there (or with Hebrew), but otherwise, good luck with the project, and happy proofreading.

Regards,

TeysaKarlov (talk) 03:52, 7 April 2024 (UTC)

Good point about the manual spacing. I was also unsure about it. We in general do not preserve variable spaces; but in my quick scan it looked like they were here used to separate a headword from the rest of the paragraph. It is possible that this is an exception to the general rule. On the other hand, several of the cases did not appear to correspond with such use (extra-wide spaces at seemingly-random places within a paragraph?). But I didn't have time to look closer into it so I can't offer anything specific. Xover (talk) 07:19, 7 April 2024 (UTC)

double {{NOP}}?

Hi, please see my question at Template talk:Nop. Thanks, Hamaryns (talk) 19:29, 7 April 2024 (UTC)

You can place two empty lines ahead of the {{nop}}. We also have the {{dhr}} template to accomplish this. --EncycloPetey (talk) 19:33, 7 April 2024 (UTC)

Page moves, etc.

Over time I've made a number of requests for moves in support of fixing scans with missing pages, etc. These used to be dealt with promptly but more recently the response has been quite slow or they are still waiting (people are doubtless busy). I came across User:Inductiveload/Scripts/Page shifter.py recently. If someone can explain to me how to run this script where it is, or how to incorporate it and run it from my .js (if that's what's required), I'll happily do the fixes myself. Thanks, Chrisguise (talk) 13:47, 12 April 2024 (UTC)

@Chrisguise: If you have to ask I generally don't recommend you try to run this yourself. The script you link is a pywikibot script, and requires the technical chops to operate 1) in a *nix command-line environment, and 2) a big complex bot framework. It's not something you run on-wiki or in your browser, and it isn't really an interactive tool. Page moves due to updated source files in an existing index are especially challenging because there are so many factors you have to take into account to avoid messing stuff up.

Page moves and a few related tasks have indeed slowed to a relative crawl lately. Inductiveload isn't active any more, and I am too busy IRL to be able to pick up the slack (and usually my head is too fried to take on anything complicated), and we used to take care of the bulk of these. If you have any such tasks that are especially bad in blocking your progress then please feel free to try bugging me on my talk page and I'll try to prioritise them.

PS. If you want to make it require fewer brain cycles to run a page move request like that, specifying the necessary moves in the way the software expects (vs. what's logical for a human being) can help. The moves are specified as "page range to be moved" (123-345) and "offset" (+4, or -3, or...). And the destination page cannot exist, so when it's not a single unified shift you'll need to give these in batches with, typically, the last pages in the first batch: that way you make room for the later page moves. This way of thinking about it is really non-intuitive for humans, but it's what the computer requires, and it's often what takes the most time and effort when doing bulk page moves. Xover (talk) 14:17, 12 April 2024 (UTC)

Thanks for the response. I was clearly led astray by the 'Anyone can run this script' comment on User:Inductiveload/Requests/Move pages or indexes; it sounds as if 'anyone (with a computer science degree) can run this script' would be nearer the mark. Chrisguise (talk) 14:41, 12 April 2024 (UTC)

Yeah, it's a bit more that than plain "anyone". Don't get me wrong, it's not rocket science, but the "computer geek" factor is pretty high. Xover (talk) 14:50, 12 April 2024 (UTC)

Index page not displaying any pages

I recently created this index page - https://en.wikisource.org/wiki/Index:Methods_of_Operating_the_Comptometer_(1895).djvu - which is just giving me an Error: Invalid interval rather than displaying any pages. The djvu file itself looks fine - https://commons.wikimedia.org/wiki/File:Methods_of_Operating_the_Comptometer_(1895).djvu

Any clues on what I should do to get the index page working? Qq1122qq (talk) 14:00, 13 April 2024 (UTC)

As always, posting about seems to have fixed the problem :). Looks like I was having the same problem as many of the people in an earlier discussion. In the same way as discussed there, I tried purging everything possible multiple times, and after about half an hour of nothing happening the pages suddenly appeared! Qq1122qq (talk) 14:05, 13 April 2024 (UTC)

Had you also purged the file on Commons ? (For the sake of understanding if it actually fixes it) — Alien333 (what I did & why I did it wrong) 16:00, 13 April 2024 (UTC)

Yes - I purged and hard purged (not sure of the difference) everything I could, and crossed my fingers. I imagine there's some very slow running process buried somewhere which only runs intermittently. I've never had this issue with .PDF files so I wonder if it's a .DJVU only issue? Qq1122qq (talk) 18:42, 13 April 2024 (UTC)

I don't think so, since Chrisguise reported that he had mostly had that problem with PDF's.

But had you purged it on commons, specifically? asking because there there is no easily accessible "purge" button like here, needs to be done through a gadget or some other things, and you could have missed it. Sorry for insisting, but it looked like we finally had a solution, and I want to be sure before abandoning it. — Alien333 (what I did & why I did it wrong) 08:31, 14 April 2024 (UTC)

I purged on Commons, then purged in WS, and the page fixed itself. This has also fixed 3 more projects I've created in the last few days.

I was given the magic incantation to purge a file on Commons via someone helpful on Discord - if you want for example to purge File:Methods_of_Operating_the_Comptometer_(1895).djvu

then go to the URL https://commons.wikimedia.org/wiki/index.php?title=File:Methods_of_Operating_the_Comptometer_(1895).djvu&action=purge

and it will give you the option to purge the cache. Qq1122qq (talk) 23:03, 17 April 2024 (UTC)

@Qq1122qq: If you go to the Gadgets section of your Preferences, down under the heading "Interface", you'll find a dedicated "Purge" Gadget that does just this for you (and which exists due to this kind of problem). I see the description talks about a purge "tab", but that's just a holdover from when Monobook was the default skin. It really appears in either the sidebar or the Tools menu, depending on which skin you're using. Xover (talk) 05:10, 18 April 2024 (UTC)

(side note: we're still talking in the "old discussion") — Alien333 (what I did & why I did it wrong) 18:32, 13 April 2024 (UTC)

Sorry about that - I find the threaded wiki-style comment pages like this one very hard to parse so I had no idea it was still a live discussion. Qq1122qq (talk) 18:43, 13 April 2024 (UTC)

No problem, and we are having a discussion about simplifying the structure at WS:S#Simplify_Scriptorium_page_structure, that ironically appears to have been lost in the flow too. — Alien333 (what I did & why I did it wrong) 09:20, 14 April 2024 (UTC)

Help with getting clickable pages for Index:The Intense Mississippi Tornadoes of March 24, 2023

There is about 40-ish pages that I still need to upload for the document, but I can’t get the clickable pages to appear on the Index page and I keep seeing “Error: No such file” when I try to fix that. Can someone get the 40-pages red linked down there? WeatherWriter (talk) 16:07, 17 April 2024 (UTC)

@WeatherWriter: Why are you uploading this as individual image files? Proofread Page is designed to work with multi-page media formats like PDF and DjVu. Xover (talk) 16:28, 17 April 2024 (UTC)

Because it isn’t a PDF document, but rather a StoryMap. NOAA is weird and doesn’t like to create standard PDF-style documents. WeatherWriter (talk) 16:48, 17 April 2024 (UTC)

@WeatherWriter: If you have the images and can throw them up on Google Drive or something I can probably make you a DjVu of them. Xover (talk) 18:56, 17 April 2024 (UTC)

Invalid interval error on creation of Index:Yiddish Tales.djvu

Can someone please help to correct this linking error? I am unfamiliar with it. It is much appreciated. — ineuw (talk) 16:43, 19 April 2024 (UTC)

With my usual attentiveness, I noticed that others posted the same issue. I will wait for the solution. — ineuw (talk) 16:48, 19 April 2024 (UTC)

@Ineuw: It's an ongoing flakiness in MediaWiki and the integration between Commons and other projects. This file should be fixed now through black magic and dread incantations to the technology deities (or something to that effect). Xover (talk) 17:21, 19 April 2024 (UTC)

It displays correctly for me after a hard purge. —Justin (koavf)❤T☮C☺M☯ 17:24, 19 April 2024 (UTC)