Please do not post any new comments on this page. This is a discussion archive first created in , although the comments contained were likely posted before and after this date. See current discussion or the archives index.
This book was published in 1843 at a time when the first of his letters was not yet found anywhere.
It seems that the missing first letter was found by 1905 and was published in two volumes containing all five letters. These books are named "Letters of Cortes" I don't know what to do with the first one. Personally, I think that it should be deleted.
Wikisource can accommodate multiple editions of a work. The 1843 could stay, but it would certainly be lower priority if the later edition is the same, just with the extra letter. --EncycloPetey (talk) 04:17, 31 December 2018 (UTC)
Incidentally, I would go further and assert that every edition should be on Wikisource; it's just that given limited resources, only the "best" edition may be a realistic goal. --Xover (talk) 18:42, 1 January 2019 (UTC)
Agatha Christie
The Agatha books are " copyrighted in the USA till 2019 " . I do not live in the U.S , and 2019 has arrived ; Then why are the links not there ? 182.66.156.16510:45, 1 January 2019 (UTC)
Because they are not out of copyright outside the US, Christie died in 1976, by current copyright rules, her work will not leave copyright until 2047 at the earliest, (irrespective of the situation in the US). ShakespeareFan00 (talk) 11:11, 1 January 2019 (UTC)
Addendum: Links and texts do not magically appear because of a date change. For a text to be available on Wikisource, a volunteer has to proofread a copy of the text and add it to Wikisource. That process requires someone to volunteer to do the work, and then time to accomplish the task. --EncycloPetey (talk) 15:55, 1 January 2019 (UTC)
Linking people mentioned in TOC pages - when not in Author: entries here?
I'm looking at the TOC of a work that includes stories, poems, and illustrations. Handling the 'authors' is straightforward when near all have Author: entries at WS. Handling the 'illustrators' is rather more of a problem, as only one was an author. (Leighton having an author entry is strange to me).
Why would you link to Author pages in the ToC? That would mean making external links from the ToC of a work, which the user will expect to be links internal to the work. The Author pages can be linked from the header pages of the individual items; there is no reason to link the authors from the ToC. A Table of Contents should link to parts of the work, not to external targets. --EncycloPetey (talk) 04:19, 31 December 2018 (UTC)
Introducing a rule implying external links from a work are deprecated constitutes a statement of policy neither supported nor forbidden by our current policy. I am not saying EncycloPetey is "wrong" here but this is a guideline I would generally approve… yet in specific cases ignore as unrealistically restrictive. The matter needs further discussion and subsequent detailed changes to policy. 114.73.65.23406:01, 31 December 2018 (UTC)
@EncycloPetey: You are quite correct. I am still a little concerned that because Wikisource:Wikilinks links to WS:MOS but not the reverse; and the general similarity of the introductory language can lead to ambiguous interpretations. There is a fundamental conflict remaining between "transcription purism" and the risk of lost opportunity for the proof-reader who is closest to the work noting matters of later confusion (an author wring in 1898 referring the the "Prince"…could be referring to Machiavelli's work, their local royalty, current British royalty or a frivolous exaggeration but with a very high degree of certainty almost none of the possibilities listed in w:Prince (disambiguation) (or vastly worse q:Q225225!)… and it seems a shame to miss the chance of offering a clarification. This issue is intractable, yet it seems the community is happy to permit mechanical extraction of wikidata linkage into Author pages. Sad. 114.73.65.23400:48, 2 January 2019 (UTC)
@Shenme: the relevant documentation is Wikisource:Wikilinks and Wikisource:Annotations. EncycloPetey's recommendations are worth considering, but are not mandatory; links to pages in Author namespace are not considered annotations and can be freely added to the text at the proofreader's discretion. Links to Wikipedia are considered annotations, however, and should follow the annotation guidelines. However, Author pages for illustrators such as Author:Frederic Leighton are totally acceptable, and pages can also be created in Portal namespace for individuals who have never created any content that can be hosted on Wikisource, but for whom relevant related content exists. —Beleg Tâl (talk) 13:20, 31 December 2018 (UTC)
In most situations, I would agree. Linking to Author pages from within a text, especially from footnotes or appendices, or from places where that author's works are being referenced, is a fine thing. But in linking Author pages from the Table of Contents, you are violating a user's expectations. One would normally expect links from the Table of Contents to link to parts of the work itself. --EncycloPetey (talk) 15:59, 31 December 2018 (UTC)
It would reassure me to know that you had looked at the two example pages. Certainly the chapters/articles have links from TOC to in-work individual items. This is as expected. Someone previously had linked the authors' names in the first page. I found this useful. When seeing Leighton's name unlinked in the second page I wanted the same ability to ask "who is this somewhat familiar name? Oh, that guy."
There is minimalism - what are the fewest, absolutely required things to enable reading. Anything else done is an additional benefit to some portion of 'users', or readers. A reader has some expectations against the required minimums. A reader will not be harmed by exceeding the minimums.
As an example, the work in question has a mix of articles from several authors. After A Defence of Cosmetics, I'll be glad to avoid any further works by that author. A quicker link from the TOC obviates having to go the article first, and the author link there, only to back out twice over.
This is a wiki. Wikis were to break conventions/restrictions enforced by physical media, yes? I fail to see the astonishment, much less harm, in linking attributions found in the TOC. Shenme (talk) 19:15, 31 December 2018 (UTC)
I had looked at the two example pages, yes.
Exceeding the minimums can harm the reader when the excess violates expectations. And, no, wikis do not exist solely to break conventions.
The purpose of a Table of Contents is to inform the reader of the contents of that work. When the items in the ToC are linked, the expectation is that there is content in that work to which the link will take the reader. When a link in the Contents links to something other than Contents, that is a violation of expectation.
I see there being two issues here. 1) Linking to authors/illustrators from a TOC; and 2) How to link to authors/illustrators who don't currently have a page here.
For the first, I agree with EP that TOC links that go outside of the work should be kept to a minimum. Those links belong where they appear in the text—usually, at the beginning of the subwork (remembering that they should appear in the header on the transclusion, so may not be needed in the Page: namespace).
In the template Helpme, it's given that after helping, I need to insert {{tlf|helpme}}. I would like to know where the source code of that page is present.Adithyak1997 (talk) 06:08, 3 January 2019 (UTC)
@Adithyak1997: All templates' source can be found at [[Template:Template name]] so the source code for the tlf template is at Template:tlf. However, I'm uncertain why Template:helpme recommends using it: it appears to simply be intending to remove the transclusion, presumably to remove it from the category that is automatically added. Simply removing the helpme template will have the same effect, and leaving behind the wikicode "{{helpme}}" seems rather pointless. Maybe it would be better to have a answered=yes parameter for this? --Xover (talk) 09:00, 3 January 2019 (UTC)
It's a suggestion for if you want to indicate that the Helpme template had been used, but no longer need help. {{tlf}} is just one way to do this; you could use {{tl|helpme}} or {{tlf|helpme}} or <nowiki>{{helpme}}</nowiki> or I had a [[Template:Helpme]] notice here but I don't need help any more thanks — I don't think we need to add another method with a parameter. —Beleg Tâl (talk) 13:22, 3 January 2019 (UTC)
Indentation options
At this page over at the Portuguese Wikisource, I am wondering the best way to indent text without having an available template. I would like indentation to resemble the original. They do not yet have block center over there (nor do they have Gap), so right alignment would be too drastic. I am opting (for now) not to use the poem tag in hopes that I'll get the ball rolling at some point there to add a block center template that behaves like ours here (and spans more than one page). Any suggestions welcome. Londonjackbooks (talk) 16:20, 3 January 2019 (UTC)
I would create a template, but in the absence of that I would probably use raw html to emulate {{gap}} <span style="display:inline-block; width:12em;"></span> or to emulate {{center block}} <div style="position:relative; margin-right:auto; margin-left:auto;"></div> —Beleg Tâl (talk) 16:34, 3 January 2019 (UTC)
You can easily copy it over to ptws yourself (just drop the <noinclude>{{documentation}}</noinclude> if ptws lacks {{documentation}}; it doesn't affect functionality). {{center block}} is more complex, but still eminently copy and paste'able. --Xover (talk) 17:43, 3 January 2019 (UTC)
@Xover: I am wincing over "easily" ;) I am technically nearly illiterate. But I have to ask... I always use {{block center}} vice center block... What are the main differences in the templates (in layman's terms)? Thanks Londonjackbooks (talk) 17:59, 3 January 2019 (UTC)
P.S. Here's the more honest answer: I can probably figure out how to transfer the template over. I did so some years ago with a template from WS to WB with lots of help and instruction which I have since forgotten, but looking at the history now does not help me much. In the years that have passed, I may have become somewhat lazier in the brain; or at least I may lack the motivation I had then. I would require explicit instruction once again, and if anyone is willing to instruct me with much patience, I may be up to giving it a shot :) Londonjackbooks (talk) 18:13, 3 January 2019 (UTC)
AFAIK the difference is: {{block center}} uses table styles for backwards compatibility, whereas {{center block}} uses block styles per modern web design best practices. It should look the same most of the time but it might display differently if you are playing with margins, indents, or other scenarios. —Beleg Tâl (talk) 18:45, 3 January 2019 (UTC)
@Beleg Tâl: No, I don't believe it can span several pages, and there are other differences I was told made it not a desirable option. I'll have to look for the discussion. Here is a mention: "bloco centro is <div> block based while block center is table based (different HTML structure is used)." [1]Londonjackbooks (talk) 20:08, 3 January 2019 (UTC)
@Londonjackbooks: On {{block center}} vs. {{center block}} I'm not much help. They purport to do the same thing, but the former claims to do it in a technically better way. How that shakes out in practice I don't know. As for copying, I'll use {{gap}} as an example:
Go to Template:gap (the page you're actually referring to when you use {{gap}}).
Hit "Edit" (or, for protected templates, "View source").
Select all the text in the text field and copy it.
Open pt:Predefinição:gap (or replace "gap" with a suitable name in Portugese. "lacuna" perhaps?).
Hit the "Edite esta página" link.
Paste the copied template code into the text field.
Hit the "Pubicar página" button.
Use {{gap}} (or {{lacuna}} or {{hiato}} or whatever you used in #4 above).
The short version: copy the template code from Template:template name in English on enWS to Predefinição:template name in Portugese on ptWS. Use with {{template name in Portugese}}.
This works for all simple templates. Some templates use other templates, or require combinations of templates, or do funny things with namespaces, etc. which make them work poorly or not at all when copying like this. But most simple formatting templates should be doable.
@Xover: Thank you. I will take a look at the instructions above in more detail tomorrow. In addition, it is also desirable to retain the template's history when bringing it to another sister project. Someone linked the history for me [somehow] the time I copied a template from WS to WB. Londonjackbooks (talk) 20:20, 3 January 2019 (UTC)
An edit summary ala "Copied from s:Template:gap." is sufficient for attribution requirements. To actually preserve edit hiistory you need to get an administrator to import, not copy, the template over. It's done using Special:Import by someone who has the "transwiki-import" permission; and import from enWS must be enabled on ptWS (which it isn't currently, I don't think). You'll need to point a friendly admin there at the documentation at m:Import to set it up. (a pain to initially set up, but it makes future imports much easier). --Xover (talk) 20:31, 3 January 2019 (UTC)
A newbie's questions: headers and footers in Wikisource pages
I am an experienced w:Wikipedia:WikiGnome. My favourite WikiProject (w:WP:DPL) has gone from cut down the jungle (before my time) through drain the swamp (about when I joined) to (now) trim the grass. I have started to look for useful WikiGnomish things to do in Wikisource.
I am about halfway through turning a hundred-plus bot-scanned pages like Page:Gedichte Hesse 1919.djvu/99 from gibberish into German. The transcription is easy, and I think I'm beginning to get the hang of Wikisource-specific templates like {{c}}, the {{larger}} family, {{gap}} and {{dhr}}.
My questions are these. Should the published page number be part of the transcribed text or be placed elsewhere? Should the language be included somewhere? Is there anything else I should know before going back to the top of this group and starting to mark the pages as proofread?
(Hermann Hesse won the Nobel Prize for Literature for his prose, most definitely not for his poetry. It's dreadful stuff. Still, that book is out of copyright and has been uploaded; so, we might as well get it right.)
Hermann Hesse died in 1968; works that are PD-US but not PD-70 are accepted at the Multilingual Wikisource for Wikisources like the German Wikisource that only accept works that are PD-70.--Prosfilaes (talk) 03:14, 9 January 2019 (UTC)
@Narky Blert: The page numbers, as artefacts of the physical medium of a book, as well as the running title/author/otherstuff that's repeated at the top or bottom of every page in the book should be placed in the header and footer text fields. They are also strictly speaking optional, but I think the general de facto consensus behaviour is to transcribe these bits as well. The header/footer text fields will be displayed on each page in the Page: namespace, but are wrapped in <noinclude> and won't be displayed when the pages are transcluded together into the overall work's page in mainspace. Or put another way, in the Page: namespace the focus is somewhat stronger in the direction of preserving the characteristics of the original, while in mainspace the focus is somewhat stronger in the direction of producing a new edition that takes advantage of the modern medium. As an example, page numbers are mostly irrelevant in a web edition; and to the degree they're needed they are generated automatically by software based on the information in the Index: page for the work.
As for the language, as EncycloPetey says, works primarily in German should be transcribed at German Wikisource. Language tagging for the main language is thus not necessary: all works on English Wikisource are presumably in English. However, runs of non-English text in the work should generally be tagged with an appropriate {{lang}} template (for the usual reasons). Practice here seems to be variable, with some guidance and practice running to only tagging those specific instances where the non-English text requires a different font or other special display, but I recommend tagging all such instances for the same reasons they do so over at enwp.
Finally, Wikisource has, by nature, an infinite amount of gnoming type work. Quite apart from the bazillion and one started but never finished transcription projects, there are a great many works that have been transcribed (Proofread) but never Validated. Attacking either of these backlogs would be immensely valuable. There are also a lot of works that are in the public domain and have scans available but where nobody has got around to uploading and transcribing them yet. Organizing work around these, somewhat like EncycloPetey has done for Portal:The Yale Shakespeare (think of Portals as roughly analogous/similar to WikiProjects on enwp) would also be of great value.
I'm a relatively new enwp-expat here myself, so if there're any issues that you think might be a translation issue between the two projects you should feel free to ping me. Not that I can claim any particular expertise on either project, but I've banged my head into at least some of the difference and might be able to point you in the right direction. Or, of course, the village pumps on enWS are a lot lower traffic and more useful than the enwp ones so you probably shouldn't hesitate to ask for any information or assistance you need here. --Xover (talk) 09:00, 8 January 2019 (UTC)
@Xover:. Thanks! (I'm getting up to speed by editing in areas where I can do some good and little damage. I thought it might make a refreshing change faithfully to reproduce the typos in original texts rather than to fix typos introduced by WP editors.)
How do I open the header and footer text fields for editing? On opening a page for editing, I can see the header field for a second or so, but then it disappears.
@Narky Blert: The disappearing headers and footers is (probably) a result of task T209939, which should get rolled back in the deploy scheduled for 7–8 January (ish). I haven't tested myself, but someone said this happens only if you have the horizontal layout enabled in the preferences, so toggling that may be a workaround. It is apparently also just WebKit (Safari) and Chromium (Chrome, etc.) that are affected, so Firefox, IE, or Opera may also work. Personally I've been digging around in Web Inspector to turn off a font-size:13px rule that applies to those text fields and without which the height becomes juuuust big enough to edit. In any case, it'll hopefully disappear in the next couple of days. --Xover (talk) 20:52, 8 January 2019 (UTC)
@Xover: Ah yes, 'what could possibly go wrong?' I've seen similar at WP with complex Templates and with Wikidata imports.
I can't see the header box for editing in any of PaleMoon, WaterFox, Chrome (which I dislike) or IE (which I wouldn't use if you paid me).
Not all works on the English Wikisource are in English (en). They can also be in Scots (sco), Middle English (enm) or Old English (ang), and I suspect various English creoles could also find a home here.--Prosfilaes (talk) 04:36, 9 January 2019 (UTC)
TOCstyle can't cope with inlined styles on page numbering...
Anyone can proofread it. Wikisource is run by volunteers who donate their time freely. Anyone can volunteer to proofread the text. --EncycloPetey (talk) 05:28, 12 January 2019 (UTC)
Validation is also done on a volunteer basis. My time right now is divided between a literary criticism of Virgil's poetry and a 1918 edition of Macbeth. But given the popularity of Agatha Christie's works, it is quite likely that someone will notice your work and begin validation before too long. --EncycloPetey (talk) 05:45, 12 January 2019 (UTC)
@EncycloPetey:Do you know any Christie enthusiasists in WS ? If so , then inform then about my work . —unsigned comment by005X (talk) .
Adding layouts and "proposed layouts"
Hi all. I occasionally contribute to en-wikisource and da-wikisource which is considerably smaller (~2800 mainspace pages). I've noticed that while da-ws has 3 different layouts (the view modes available under "Display Options" in the sidebar) for displaying texts, en-ws has a fourth one as well as one called "proposed layout". What does one have to do to add more layout types as well as the "Proposed Layout", and how does the latter work exactly? I've tried finding information at mw:Extension:Proofread Page, but so far I've come up short. Thanks in advance, --InsaneHacker (💬) 10:58, 12 January 2019 (UTC)
Strictly the layout scheme has nothing whatsoever to do with ProofreadPage apart from the coincidence both schemes were originally the invention of User:ThomasV. I expect the documentation you are looking for might be Help:Layout, particularly sections starting at "How to write dynamic layouts" and below? 114.74.213.15814:56, 12 January 2019 (UTC)
It helps with how to set up the actual CSS-coding, but I'm still at a loss on what one needs to do to the wiki config files to make new layouts appear for all users. --InsaneHacker (💬) 14:16, 14 January 2019 (UTC)
Would have used {{TOCstyle}} but there isn't an option to set a lead-prefix for the chapter numbering, nor a way to get the page numbering to left align instead.. A suggestion on how to format this would be welcomed, or updates to TOCstyle
ShakespeareFan00 (talk) 01:10, 14 January 2019 (UTC)
Apropos of nothing, I bought and read this new in my teens (a reprint/new edition obviously). Suddenly realising that the book was actually written over a century ago makes me feel old! --Xover (talk) 07:04, 14 January 2019 (UTC)
Sure. But most texts here don't register as "New when I was a teenager" in my subjective model of the world. :) --Xover (talk) 17:44, 14 January 2019 (UTC)
I'm raising this in case (A) section headings are being changed while proofreading, without checking 'What links here', as seemed to have happened December last year [3]; (B) Odd encyclopedia entries with two commas like 'Masham, Abigail, Lady' are producing unclear page titles. --Cedders (talk) 11:13, 15 January 2019 (UTC)
Hi Cedders, it was just a case of me forgetting to check for changed section tags when copying the proofed text from Gutenberg. Normally I specifically search for "section begin" when displaying the differences to check for altered tags, but must have forgotten in this case. I don't believe its anything to do with having two commas in the page title. DivermanAU (talk) 11:38, 15 January 2019 (UTC)
This file and others are showing something that someone with the right tools could presumably write a script to resolve.
Namely that the whilst all the scans are present, the OCR text associated with them is apparently offset by a page meaning the OCR text and scan pages do not concur.
Ideally the DJVU files should be rebuilt carefully, as these OCR discrepancies may have resulted from "third-party" page removal in tools that are not necessarily as fully aware of the 'text-layer' capabilities of the djvu format as would be desirable.
Whilst I had been marking these for "Source file needs repairing", On review "Source needs OCR text layer" seems more appropriate.
New version of djvu uploaded. It is a bug in IAUpload tool, open in phabricator (I have proposed a fix but maintainer is not fixing it, so I worked out my own script).— Mpaa (talk) 23:13, 15 January 2019 (UTC)
Care to look into other works in the "Source File needs to be repaired" and "Text Layer needed" cateogries? I think MANY files could be rescued quite easily. ShakespeareFan00 (talk) 23:50, 15 January 2019 (UTC)
What are you talking about? It seems like there is no problem from the 502nd to 503rd pages of the scan (aligning to pages 482 and 483 of the text). —Justin (koavf)❤T☮C☺M☯03:16, 18 January 2019 (UTC)
It took me a while to understand also. You mean the saved text of each page is off by one page. I was looking for a missing page. Maybe an admin can do something about it. Jpez (talk) 06:12, 18 January 2019 (UTC)
Adding pages to existing scanned book (Once A Week Volume II)
Hi — what should I do if I am looking through a scanned-and-indexed book and notice that some pages are missing? Would it be possible, if I have to insert two pages after scan number 140, to number them 140a and 140b? Levana Taylor (talk) 21:37, 17 January 2019 (UTC)
It is correct to raise the issue here. Please post the Index page, which page number and where to find the missing pages. Page numbering will be taken care accordingly. Someone will fix it.— Mpaa (talk) 22:05, 17 January 2019 (UTC)
Thanks. The problematic book is Once a Week, Series 1, Volume II Dec 1859 to June 1860. I haven't finished looking through it all yet, but the problems I so-far found are: two pages missing after scan no. 140 [it is pages 128 and 129 of the book that are missing]; scan no. 462 cannot OCR; from scan 218 onward existing OCR'd texts are not matched with the correct page image. As for a source for a scan, there is Google Books. Levana Taylor (talk) 22:19, 17 January 2019 (UTC)
And there are plenty of other problems. The scan of 208 is in the right place, it is correctly followed by 209, but then we wrongly have 208 again, 209 again, and then 210 and so on as it should be. Then, where 225 ought to be, we have an image of 227 (but the same image is also in its correct place). Then, 228 and 229 are missing. 258 is followed by 261 then 260 then 261 again then 262 and 263, then we skip to 266, 267, 266 again, 267 again, then 268 onward are correct until 276 is followed by 279, 278, 281, 282, 281 again, 282 again. 283 and onward are OK, until 420 and 421 are missing and 422 & 423 appear twice. 502 and 503 are missing. Then later pages 512 and 513 appear twice. 602 and 603 are missing.
Let me summarize all that by naming ranges that have problems, starting and ending each range with pages that are correct. 207-210 ; 224-230 ; 258-268 ; 276-283 ; 419-424 ; 501-504 ; 511-514 ; 601-604.
You are right, rats, well, now I know which browser not to use. The different browser I tried did load the pages without skipping or repeating them.
I still think 579 and 453 need to be replaced, though. After that, all that remains is getting the texts back with the images they belong to. Thanks for your help! Levana Taylor (talk) 13:31, 18 January 2019 (UTC)
Here is a guide to where the OCR'd text of various pages has ended up:
From page 128 to 206, the text is two pages before the image. Y
From page 209 to 225, the text is four pages before the image. Y
From page 226 to 227, the text is two pages before the image. Y
From page 230 to 243, the text is four pages before the image. Y
From page 246 to 281, the text is six pages before the image. Y
From page 282 to 299, the text is four pages before the image. Y
From page 306 to 325, the text is six pages before the image. Y
The text of page 340 is four pages before. Y
The text of page 350 is four pages before. Y
From page 406 to 423, the text is six pages before the image. Y
From page 424 to 428, the text is four pages before the image. Y
From page 452 to 456, the text is four pages before the image. Y
From page 506 to 515, the text is four pages before the image. Y
From page 606 to 622, the text is four pages before the image. Y
Pages 619 to 622 are incorrectly marked "without text."
Thank you very much! I have checked the repaired areas, they are OK. I have removed the repair templates and the temporary page nubmers ... Levana Taylor (talk) 05:47, 19 January 2019 (UTC)
Update on 1860 Once a Week: pages for special work
I'm making good progress in putting together this magazine volume, Once a Week Vol II, into a properly constructed form that will then only need proofreading. However, I've seen some pages that have formatting that I don't know how to do: tables, and images that are more complicated than mere full-width insertion (I can and do handle poems, though). I've marked all pages that are complicated as "problematic" in case anyone wants to look at them. Levana Taylor (talk) 14:10, 20 January 2019 (UTC)
references with symbols
Is there a template that allows us to follow the style of the original document by indicating references with * † ‡ instead of numbers? Levana Taylor (talk) 17:22, 21 January 2019 (UTC)
The "house" style here is to convert them all to numbers—see Help:Footnotes and endnotes. This is because when the text is transcluded the list of references goes to the end rather than displaying at each page. If we to use symbols, then there would multiple references with the same marker and the reader would not know which one applied in a particular case. Beeswaxcandle (talk) 17:29, 21 January 2019 (UTC)
Yep, that makes sense. But I thought maybe someone had programmed a template that would apply to the whole article and display the reference list with custom symbols instead of numbers. Levana Taylor (talk) 17:46, 21 January 2019 (UTC)
That wouldn't solve the problem of multiply repeated symbols. There are more than a few limitations of physical printing-by-page that simply do not transfer well to electronic format. --EncycloPetey (talk) 17:48, 21 January 2019 (UTC)
Why would repeating symbols be a problem? the current system counts up the number of <ref> in the article and displays them in order as 1, 2, 3. Why couldn't it display them as * † ‡? Levana Taylor (talk) 17:59, 21 January 2019 (UTC)
Imagine you have a text with 59 references across 100 pages. Each reference in the original is either * † or ‡. By numbering the footnotes, they can be numbered 1 through 59. If using symbols, there aren't 59 footnote symbols, so you would get two dozen * and a dozen † and a handful of ‡, all on the same page, and it would not be clear which * refers to which footnote. —Beleg Tâl (talk) 18:19, 21 January 2019 (UTC)
I know, it wouldn't be useful for anything but a short piece with not more than 5 references (the number of traditional symbols — though you then go to **, ††, etc.). I will stop beating a dead horse now :-) Levana Taylor (talk) 19:07, 21 January 2019 (UTC)
Was looking at this.. Text is good, but the 'diagrams' seem clipped in the scans? Anyone good with SVG to be able to make 'repairable' versions? ShakespeareFan00 (talk) 00:31, 22 January 2019 (UTC)
Broken links to machine-translated text on an external site
What should we do about On some controversies regarding origin and nationality of Nezami Ganjavi? The Russian text has been released under a free licence, and a page has also been created here at ENWS, but only the abstract, keywords and contents page are in English. The bulk of the document is in the form of external links to Google Translate which are now broken. Even if the links could be fixed, it seems odd for Wikisource to be directing users to machine-translated text and for something to be "on" ENWS when it's actually on an external site. The research looks interesting, but if almost all of it is in Russian and not English, does it belong on English Wikisource? MartinPoulter (talk) 21:12, 22 January 2019 (UTC)
I fixed the file (that was wrong), but I think there is more to it. In djview text is aligned with pages but not in Index/Page. I think this is similar to what hapened with an EB199x Volume. Something goes wrong with how text is loaded, but we were not able to explain it (at least so I recall).— Mpaa (talk) 21:04, 24 January 2019 (UTC)
Can you help me make this page] look a little prettier? I've got two tables of contents positioned next to each other, using "float." I think they would look better with more space between them (that is, in a narrow window they would) and/or maybe a line between --how would I do that? Any other proposals for layout? Levana Taylor (talk) 04:01, 24 January 2019 (UTC)
I'd merge the two lists, maybe something like this:
I still think parallel columns are preferable, but when you said "combine", I said, "Of course! I can put both lists in one table, and that'll give lots of formatting possibilities." The result was this, which I really like. Thanks for shaking my mind loose! Levana Taylor (talk) 17:35, 24 January 2019 (UTC)
It includes the following footnote added by a wiki editor: "EDITOR'S COMMENT (FEB. 2015): The date in 1815 given by the original text is wrong and should be the 8th of August."
They may be right about the date being wrong, but my understanding was that we digitise what's there, not correct it when it's wrong. Seems to me like we'd be adding a lot of footnotes to a 100-year-old encyclopedia if we did that. Should this footnote be removed? Chuntuk (talk) 01:07, 26 January 2019 (UTC)
@Chuntuk: you are quite correct. I have replaced the footnote with an HTML comment. You can also use {{SIC}} if desired, but I don't think that's desirable here since this is not a typo —Beleg Tâl (talk) 01:34, 26 January 2019 (UTC)
I would usually move comments like that to the talk page for the article. However, the claim is completely unsupported by any reference at all, which really makes it worthless as an emendation. --EncycloPetey (talk) 01:37, 26 January 2019 (UTC)
Parenthetical can't necessarily appear in a pagelist tag on an Index page..
However, the work-around (until the script is repaired), would be to amend the Index pages containing parenthesised page numbering inside a pagelist.
So:-
Does anyone have a script which could at the very least identify ALL affected Index pages?
Could an appropriate edit-filter be implemented to check for this when an attempt is made to save an Index page?
Although it may also be possible to have an automated script 'repair' many of the affected Index pages, I'm not sure it would be able to do this reliably in some contexts.
ShakespeareFan00 (talk) 10:01, 28 January 2019 (UTC)
@Billinghurst: Per your closure of those tickets, you stated was this solely a local issue thus here would be the "appropriate" place for further discussions. One of the relevant documentation pages has been updated already. If you would like to outline work-arounds and solutions below, it would be appreciated.
I can’t parse the regex in the above comment to see where exactly the problem lies, but it seems to be producing some false positives. For example, the first item in the “list of Index pages to repair” is Index:United States Statutes at Large Volume 12.djvu, but that page does not use parentheses in any of its <pagelist> calls. Is it possible that the regex is flagging all pages that (1) call <pagelist> and (2) have a parenthesis anywhere on the page, whether or not it is part of the <pagelist> call? Because that would substantially overstate the number of pages that need to be repaired. Tarmstro9919:30, 28 January 2019 (UTC)
Yes, the regexp isn't perfect. If you want to generate a better regexp, feel free, the current regexp was \<pagelist((.)*)\=((.)*)\(((.)*)\/\> . Thanks.. I estimate about 200 Index pages may be affected, The search generates 500 or so results and many false positives :( ShakespeareFan00 (talk) 21:28, 28 January 2019 (UTC)
vertically-centered asterisk?
I have been pretty successful so far in finding templates that reproduce the special typographic features used in the 1860 magazine I'm entering, but one I can't find is a largeish asterisk vertically-centered in the line. Levana Taylor (talk) 08:59, 27 January 2019 (UTC)
Fullwidth characters are not really for use in English texts; they're designed for use with Eastern Asian scripts that are inherently monospaced, and when Latin characters are stuck in, they are either halfwidth or fullwidth. EncycloPetey's solution is probably best.--Prosfilaes (talk) 03:28, 28 January 2019 (UTC)
OK, then that particular asterisk is not the right one. The main problem with the regular asterisk is that it's too small. Here is a comparison of the original with {{larger}} asterisks—quite good. And Once a Week (magazine)/Series 1/Volume 2/Where is the other?, various uses of enlarged ordinary asterisks in a story. Not bad, as long as I tweak the formatting enough. The pre-made templates are all wrong. Levana Taylor (talk) 05:00, 28 January 2019 (UTC)
It looks to me like the original publication was simply using a font in which the asterisk * is larger than most fonts. For example this page has an unusually large but otherwise unremarkable asterisk for the note in the bottom left. It's not a different character, just a different font. For this reason, an ordinary * would be the best character to use here. —Beleg Tâl (talk) 23:29, 28 January 2019 (UTC)
Thanks. I'm sorry about asking such trivial questions. I haven't even tried the difficult things like tables yet.
Box formatting
Another question. Is there a help page explaining how to position text inside a box with a border? The documentation for Template:Frame doesn't explain how to change border properties or which other templates you can use inside it for positioning the text, and it looks like Template:Float box doesn't allow for anything very elaborate inside the box (I could be wrong). Levana Taylor (talk) 00:33, 29 January 2019 (UTC)
I tried that on page 288 but something is wrong: why the big white space at the top? Also the text isn't quite horizontally-centered in the box and I couldn't figure out how to add some padding at the left. Levana Taylor (talk) 04:16, 30 January 2019 (UTC)
@Levana Taylor: -- That is ok, px or em, whatever you like. But to note that curly quotes are against the house style. Also, the page should not be set to proofread status without the image. Hrishikes (talk) 05:48, 30 January 2019 (UTC)
Page Numbering anomaly part 3
Acts of the Constituent Assembly and Dominion Legislature of India 1949/Act1 This numbers from 4 because on the index page the last defined page in the previous page list was "3" (rather than 10 which would the DJVU page index), but does it say this is in the documentation? How am I expected to KNOW this is the expected behaviour by intuition or telepathy?
I was testing what happens with multiple page-lists on a single Index page.. The behaviour is not unexpected, but not seemingly clearly documented.
ShakespeareFan00 (talk) 21:22, 30 January 2019 (UTC)
A deleted draft
After a disagreement on the language of a text, where we seemed to be reaching an understanding, I was going to move the text to my sandbox for then moving to the multilingual Wikisource. The text was marked with a template indicating the percieved language issue (part of the book is in English, and a larger part than I initially realised in a constructed language), but it didn't indicate any particular timeframe, or that the text would neccessarely be deleted (moving to a user subpage, as a draft, would otherwise be a possible option), if I remember correctly. I was also going to ask for second opinions, and normal disputed contributions are normally not deleted that fast in the Wikimedia projects I've been active in, so when going for dinner, I didn't expect much to happen this very same day, at least.
The communication from the editor has indicated that 1) he didn't make much effort checking his statements in the discussion on beforehand 2) he didn't make much effort in understanding what me as another editor wrote, which made the communication frustrating. The discussion can be found at my discussion page.
And then the same editor deleted the whole page.
I would be very happy about undeletion and moving to my sandbox or a subpage of the sandbox. Then I could use the edits I did to it. Undeleting, moving with history to user:flinga/sandbox/alteutonish, 1915 would have been excellent, but I would be grateful for any constructive help.
You were told repeatedly the work couldn't be hosted here because it was not in English. After 40 minutes of back and forth trying to get you to understand this, you finally agreed that only the introduction was in English. Then you say you suddenly went offline the moment you were told it would be deleted. How inconvenient. It seems that you are only here to cause trouble and disrupt the community. You still have access to the scan; it has a DjVu file with a text layer. Use that text layer on multilingual Wikisource. The English Wikisource does not host works written in artificially constructed languages. --EncycloPetey (talk) 21:30, 27 January 2019 (UTC)
Both of you: Thank you very much! It is greatly appreciated.
EncycloPetey: I appreciate this last help very much. I have to say I don't really understand what's been our problem. I understand that you feel personally attacked in the last messages, but from my viewpoint 1) I was here to contribute 2) I never did or say anything bad or strange 3) I found your dialogue lacking in terms to reach an understanding, and a cooperative outcome - I found a tone in it that I really don't understand the reason for. I've also contributed to Wikimedia projects for well over a decade without big issues or ever being blocked. I did agree on your point in my (next to) last message, then I went for my break, and I can't see what's neccessarely strange with that - in other words, I didn't see your reply before dinner, and I only tried contributing with a text, which is after all the point of this project, isn't it?
The initial topic of our disagreement was whether the book was in English at all or not, and to what extent. From my viewpoint, that's what we were straightening out, we partially disagreed, and as editors we are normally equals, so I disagree with both the premise and the content of "was being repeadetly told".
I do think giving feedback on this is important for this project.
Assuming that EncycloPetey got the impression early on that my intention was to cause trouble here, which I only realised long after this discussion, I have apologized for any harm potentially caused by my actions, and for essentially making a too big thing out of it. That apology is also directed to anyone else here who might possibly have been affected. Flinga (talk) 03:03, 2 February 2019 (UTC)
No pages numbers displayed ...
I cannot figure out why the page numbers are not displaying on the later parts of the transclusion here: Provincial_Geographies_of_India/Volume_4, given that I've implemented the workarounds about removing certain characters
There doesn't seem to be a consistency as to where the page numbering script fails, other than it does not seem to like certain non alphanumeric characters in a defined string to be displayed as a page number.
It would be appreciated if those with technical ability, (rather than continuing to suggest work-arounds) documented what page number formats (and charcters) are accepted by the page numbering script because I am getting tired of tracking down technical minutiae, which don't seem to behave consistently.
ShakespeareFan00 (talk) 16:07, 30 January 2019 (UTC)
@ShakespeareFan00: The PageNumbers script rather uncritically stuffs the page number value in a HTML ID attribute, so the safe rules (HTML 4 rules) for what you can put in there is something like: A–Z, a–z, 0–9, hyphen (-), underscore (_), colon (:), and period (.). And the first character must be A–Z or a–z.
As of HTML 5 the rules for ID attributes are much laxer (no space characters, must be at least one character, must be unique in the page), but once you exceed the above list you start running into what are special characters in JavaScript, HTML, URLs, and MediaWiki. Some will work, but more by happy accident than design.
This state of affairs is partly due to MediaWiki:PageNumbers.js being effectively a personal half-experimental project of GOIII's (as far as I've been able to tell, but I wasn't around at the time) that was never fully polished or architected, and partially due to the limitations of what such a script can do without being made a part of MediaWiki proper. For example, some of the limitation stems from needing to use the page numbers as identifiers, and it would be… not trivial… for such a script to generate non-pagenumber derived unique identifiers that retain a connection with a page number that is otherwise used only for display. --Xover (talk) 07:03, 31 January 2019 (UTC)
Thank you.. That explains the failure of "("")" bracketed numbers, "'" would conflict with string terminators used in CSS. I am still not sure as to why a terminating period, caused issues though, but will remove those anyway as it's helps solve the problem. Are you willing to look into this in more depth, so there is a definitive list of characters that shouldn't be present, so that the relevant help documentation can be updated?ShakespeareFan00 (talk) 10:47, 31 January 2019 (UTC)
Well, I'll certainly be happy to help however I can, but there's no actual code that can be parsed to discover the set. The only real way to find the answer is to try various characters and seeing what fails. And we have several different layers of technology interacting here (WikiMarkup and the MediaWiki parser, the ProofreadPage extension, HTML, and JavaScript. It's not impossible CSS is also involved due to selectors for the relevant identifiers. --Xover (talk) 11:10, 31 January 2019 (UTC)
@ShakespeareFan00: discovered that File:Portland, Oregon, its History and Builders volume 1.djvu lacks an image of page 449. I found an alternate scan of the book, extracted the page, inserted it into the DJVU file, removed a neighboring blank page to preserve pagination, and re-uploaded it. But the page previews are not updating. This is true both on Commons and here on Wikisource (but Commons has updated one of the pages, but not the other; Wikisource has updated neither.) I tried refreshing and purging all involved pages, with no effect. It's been more than 24 hours, so I'm not confident it will "fix itself." Does anybody know what's happening, or what to do about it?
Hmm, I think I must have looked at the wrong pages before. I have checked several times since posting the above comment (now struck), and the problem persists. -Pete (talk) 20:31, 4 February 2019 (UTC)
I noticed, however, that on Commons when I try to purge the file page, I get an error message that says "purge failed" (without further explanation). I don't know why that purge fails, but perhaps it's related to this problem. -Pete (talk) 20:39, 4 February 2019 (UTC)
@EncycloPetey: would you mind taking a look at this one? I saw your comment on WS:Scriptorium on (what I thought was) a similar case; but this one is a DJVU, not a PDF. How can I get the Wikisource interface to display the page images properly? It still (now a couple weeks later) seems to be displaying pages from the previous, deleted file. -Pete (talk) 20:38, 7 February 2019 (UTC)
My best guess is that a cache purge is needed at Commons to made the change show through. I've tried several things at the Wikisource end, including an edit to the Index page, and several forms of purges and cache clearing. Looking at the page itself from the file while at Commons shows the correct image, and using the OCR generates the correct text; it is only the display through the Proofread Page extension that seems to be at fault. So, unless there is a subtle error in the structure of the DjVu file itself, I suspect it will take a purge at Commons or time for the correction to trickle to Wikisource, or else there is a (new?) problem in the Proofread Page extension. --EncycloPetey (talk) 20:48, 7 February 2019 (UTC)
Thanks. I've added a phabricator ticket (see top of this section). I have a screenshot in phabricator of the failed purge, something I haven't seen before -- so I agree, that seems like the most likely cause. -Pete (talk) 21:54, 7 February 2019 (UTC)
I have imported Criminal Law of the People's Republic of China from the website of the Chinese National People's Congress. However, I am not sure whether the text fulfills the requirement of English Wikisource. Would any more experienced users proofread the text, as I am not familiar with the formata of English Wikisource, thank you.廣九直通車 (talk) 07:34, 6 February 2019 (UTC)
Tools for building transclusion pages?
I'm going through the painstaking process of creating a page for each of the many short chapters of The Souvenir of Western Women. It occurs to me that maybe there are tools or scripts that assist in this stuff -- any suggestions out there? -Pete (talk) 21:15, 2 February 2019 (UTC)
Not to my knowledge. I keep three tabs open: the work's table of contents, the page being transcluded, the page being created. Paste the contents of previous chapter page into new chapter page. Update next/section/previous based on TOC in first tab; update pages being transcluded based on info from second tab; copy whole thing to clipboard, save, click the red link to next chapter and paste content, repeat. It's the most efficient process I've got. —Beleg Tâl (talk) 02:13, 3 February 2019 (UTC)
Or you can create a text file with all the needed information for each chapter (e.g.title, prev, next, start, end, section, etc) and we can set up a script to generate pages. If the format of the file is standardized, it could become a library script to be used e.g. for Bot requests.— Mpaa (talk) 09:50, 3 February 2019 (UTC)
That is a great idea—I am about to add another volume of a magazine with several hundred articles, and I would like to be able to submit a text file for you to run through a script (I don't know how to use scripts myself). The data that would be useful for magazine articles are: title, section, contributor, previous, next, index, from, to, fromsection, tosection, defaultsort, category. Title and index are the same for every article. One category would be sufficient. Levana Taylor (talk) 18:56, 3 February 2019 (UTC)
Beleg Tâl, that's more or less the process I've been using. But I agree, an something like Mpaa describes would be ideal, especially for works like this with many chapters. I'd be happy to try creating a text file for the remaining portion of this work, if you want to give it a try. I should be able to do that tomorrow. Thanks! -Pete (talk) 22:19, 3 February 2019 (UTC)
OK @Mpaa: I have created a text file here: User:Peteforsyth/Souvenir I don't know the best format for you, but I think all the information you need is in there. Please let me know if you need me to make changes. A few comments:
I started where the bulk of the redlinks begin. There are, however, already some blue links interspersed among the remaining redlinks. If a page already exists, maybe the script could just ignore that line in the text document and move on to the next. (Ideal would be to check, and add in fields for "previous" and "next" if they are missing. But that's probably hard to code, and not so hard to fix manually.)
I have no idea what the most convenient delimiter is, so I put three percent symbols between the chapter title and the page number. I figure it should be easy to search-and-replace if there's a more suitable symbol.
The page numbers are offset by eight from the DJVU file. (E.g., page 200 in the original book is the 208th page in the DJVU file.)
I removed author names, since there is much inconsistency in how they are presented. I don't mind going through and adding "contributor=" items to the headers after the pages are created.
There will be a number of cases in which one page contains parts of two chapters. I have no problem fixing those manually.
I would suggest including "year=1905" in each page.
Please let me know if this is sufficient, or if you need me to do anything else. Feel free to edit the page in my user space, if that's the easiest way to communicate what format works best for you. -Pete (talk) 23:27, 4 February 2019 (UTC)
@Mpaa: I realized it's better to include the known contributors so I updated the text file. It now includes the name of the contributor at the end of the line, in the cases where it is known. Please let me know if you have questions. -Pete (talk) 19:46, 5 February 2019 (UTC)
I copied a sample of how it should be to your page. Better tab separated. Order of columns is irrelevant, keep for now the header row as is. Pages in 'djvu' values are better (both from/to). I tried to extrapolate the end page but it is wrong, please review it, there are also sections to be added (see the few pages I have created as MpaaBot, there are errors).
This is just a small script, long way to make it up to a standard bot ... but it will do for this work.— Mpaa (talk) 21:25, 5 February 2019 (UTC)
To add sections, add two columns (fromsection/tosection) with corresponding names of sections as applicable.— Mpaa (talk) 22:03, 5 February 2019 (UTC)
Thank you @Mpaa: that all makes sense. I've now updated the text doc, it's accurate with both page numbers and section numbers. -Pete (talk) 23:47, 6 February 2019 (UTC)
p.s. In some cases the section markers do not yet exist in the pages, but I'll be going through to make sure they are included. -Pete (talk) 23:49, 6 February 2019 (UTC)
That all worked great. Thanks @Mpaa:! And thank you @Victuallers: for all your proofreading work too! I just added it to the "new texts" page and will tweet it out too :) -Pete (talk) 22:28, 8 February 2019 (UTC)
Auxiliary TOC for Once a Week
I have several questions, but will start with the basics. I would like to use the template {{Auxiliary Table of Contents}} to add a table of contents to volumes of Once a Week magazine, because the volumes don't have a TOC, only a subject index (quite a different thing: for instance, in Volume II the article titled "The European Difficulty" is in the index as "Pope Pius IX"). I have here created part of a contents page for Volume III to show what it might look like, with the auxiliary table of contents above the transcluded index. Before I go on with more of this I would like your thoughts on whether this is a reasonable thing to do.
Some notes on the stylistic choices I made for the TOC: It is divided into numbers not just for usefulness and readability, but also because the book is so divided: In small print at the bottom of the first page of every number is "Vol. XNo. Y," and the date is at the top of every page. As for how the entries are formatted, Title. By Author . . . . .Illustrated by Illustrator., that is directly taken from how the magazine displayed their contents in their advertisements. (I can't simply copy over the advertisment, though, because that isn't quite a TOC either.)
OK, I will take the lack of comments to mean that no one has an objection to my implementing this table of contents, and will move on to the actual help question I wanted to ask.
How should I format the lines in the TOC, given that {{Dotted TOC line}} doesn't work inside of {{Auxiliary Table of Contents}}? (And neither do other potentially useful templates like {{block right}} and {{hi}}.) Is there some other combination of templates I could be using? Ideally, the "Illustrated by" column should be a separate column at the right, left-aligned within itself, and with a caption at the top; it's coincidental that the "comment" field of Auxiliary Table of Contents provides a caption for it. And of course the main column should have a line of dots of the correct length and should wrap with a hanging indent. I could do all that by building a table by hand but that would be a bad idea because it would make the page much too hard to edit. The point of templates is to keep complicated stuff under the hood. Levana Taylor (talk) 17:00, 9 February 2019 (UTC)
Actually Songs of the Slav demonstrates that Dotted TOC line breaks Auxilary TOC: notice that the box is only around the first item in the contents, and the content item title creates a white space inside the box Levana Taylor (talk) 18:35, 9 February 2019 (UTC)
@Levana Taylor: Actually, the auxilliary TOC contains only the first item on purpose, the rest is the real table of contents. But you are right about the white space, although this issue is hardly visible (at least on my monitor) and I would not notice, hadn't you told me. --Jan Kameníček (talk) 19:21, 9 February 2019 (UTC)
OK, I see what you were doing adding the preface there. This is what it looks like with more than one line: not too good! there are two problems to fix. The background color of Aux TOC needs to be set to white to match the bgcolor of the lines, and it doesn't have that option (nor do the lines have the option of changing the color to green). Also, I don't know why the left margin of the Dotted lines is different from the undotted ones. (BTW, feel free to edit that TOC experiments page if you have better ideas!) Levana Taylor (talk) 19:57, 9 February 2019 (UTC)
As for the chapter-width, it seems that the inconsitency is caused by different default values of both templates: it is 2.5em in TOC line and 3.5em in Dotted TOC line. I do not know whether it is a mistake or whether it is set differently on purpose. --Jan Kameníček (talk) 22:33, 9 February 2019 (UTC)
I'm seeing an unusual problem with this , namely that in some of the scans, what should be an n is transposed for a u, and vice versa in the images generated from the DJVU file. Whilst I can in context find many of these, I would like an explanation as to why this is occurring, as it's not exactly convenient to have to proofread against 2 sets of scans ShakespeareFan00 (talk) 21:31, 8 February 2019 (UTC)
Can you give a specific example? From time to time I have noticed scans where what should clearly be an "n" looks like a "u" (and vice versa). For some of these works, I have obtained a hard copy of the same edition, and found that the original does not have this issue. My guess is that the dual process of scanning and compression loses some of the visual distinction in 19th century fonts between the two letters. --EncycloPetey (talk) 21:35, 8 February 2019 (UTC)
The problem is likely a reflection of the tiny font size in which the page was printed. I notice the same sort of issues with footnotes and other tiny print. --EncycloPetey (talk) 21:55, 8 February 2019 (UTC)
Ad as I said, if DJVU can't provide RELIABLE scan images, maybe it's time to use a more reliable format... PDF isn't ideal because of other issues, and there is no current support for using a TAR/TGZ/ZIP archive of JP2 scans in an easily index way at present, ( and of course using direct scans mean no text layer currently) (sigh :( )ShakespeareFan00 (talk) 22:16, 8 February 2019 (UTC)
DjVu has a feature where the pages can be lossly compressed, which means that images of letters are replaced with images of other letters that are close enough. This can cause this type of problem if that feature is turned on.--Prosfilaes (talk) 15:14, 9 February 2019 (UTC)
They both use floated blocks, and as far as I can tell they behave entirely consistently with the standard behaviour of floated blocks, which is that the first one goes up against the margin, and any subsequent ones next to it on the inside. You'd have to use fancy positioning in the template to move it from there to the other side of any intervening floated content. —Beleg Tâl (talk) 02:44, 11 February 2019 (UTC)
That answers the first concern, what it doesn't answer is why IDENTICAL markup is rendering in one instance and NOT in another, Perhaps someone else can take a look at the respective markup, and get Mediawiki to give CONSISTENT renderings , rather than forcing me to play hunt the obscurity every single time I actually want to improve something.... (rage noise) ShakespeareFan00 (talk)
It is also well-known that not everything will display well in both the Page: namespace with its narrow pagewidth and the mainspace with a much wider pagewidth. Don't look for solutions for nice display in the Page: namespace if the transcluded text is behaving nicely in the mainspace. The transclusion is the only thing that counts in the end. Beeswaxcandle (talk) 03:12, 11 February 2019 (UTC)
There is another glitch with the margin-note saying "not-in the original" in that it's currently not positioning correctly. It should be right over on the left, not indented as currently. As I said , it would be nice if someone actually overhualed these templates "properly" so that they will play nicely together, instead of creating frustration for contributors. (sigh) 03:27, 11 February 2019 (UTC)
Well lets see User:ShakespeareFan00/Ruffhead - and the drop cap works, but the note-positioning behaviour doesn't. I'm fed up having to play "guess the stable combination" based on templates, namespace, and phase of the moon, &c. Consistency and repeatability are not unreasonable things to expect from a platform like Wikisource... (sigh) 03:36, 11 February 2019 (UTC)
They should look identical, barring the page header lines, I am puzzled as to why the firstletter behaviour isn't being applied consistently. Maybe a it's a browser issue, which one are you using? ShakespeareFan00 (talk) 13:41, 11 February 2019 (UTC)
They both look the same to me in both Firefox and Chrome on Windows 10, with or without your .sanity rules in my common.css page. —Beleg Tâl (talk) 16:13, 11 February 2019 (UTC)
It also helps if there's a strightforward way to put experimental CSS so everyone can use it (as opposed to a personal common.css) ... TemplateStyles being one possibility, but at present it's not possible to use Userspace CSS files in a templatestyles src field, for various reasonsShakespeareFan00 (talk) 13:43, 11 February 2019 (UTC)
I've updated it with a working solution: wrap all of the margin notes into a single {{float left}}. This means that when the browser places the dropinitial beside the previous floated block, it places it next to the column of notes as a whole, rather than beside the final floated note in the series. —Beleg Tâl (talk) 17:16, 11 February 2019 (UTC)
I had some experimental CSS I wanted to test and demonstrate more widely.. Is there a way of using TemplateStyles to link experimental CSS from a User space page into a Page: Wikipedia: or Main namespace page? Or are there limitations on what can appear and where?
ShakespeareFan00 (talk) 13:45, 11 February 2019 (UTC)
If this message is red, then the answer is yes. You might need an admin to change the content model of the linked CSS file from "CSS" to "Sanitized CSS". I'm not sure if this requires elevated permissions. —Beleg Tâl (talk) 15:26, 11 February 2019 (UTC)
BTW be prudent with this. If you have an experimental CSS rule you want to try out, you should put it in your sandbox and link people to it. If it applies to a particular work, you can create a work-specific template and clearly identify it as an attempt to improve that specific work - noting this both on the template documentation, and within the Index talk page. If you start putting user CSS where people don't expect it, and you forget to remove it afterwards, other editors will not take that kindly. —Beleg Tâl (talk) 15:33, 11 February 2019 (UTC)
Use a selector to implement ::firstletter behaviour, with a view towards the CSS4? style dropcaps styling, (which would make the currrent dropinital approach less of an issue once browsers support the functionality concerned.) ShakespeareFan00 (talk) 16:10, 11 February 2019 (UTC)
Yes That was it EXACTLY. Now if that could be tested with some exactign test cases... there might be a replacement for the current {{di}} template. The next problem would be how to handle things like drop initals where a normal sized quote preceeds... hmmm... And thanks for the hint ShakespeareFan00 (talk) 16:29, 11 February 2019 (UTC)
@ShakespeareFan00: FYI, implementing drop initials using ::firstletter should result in exactly the same problems that {{di}} has currently, because you still need to float the element in order to have the second line appear beside it rather than below. Given that a solution to this particular issue has been found, I'd suggest saving yourself the headache until the dropinitial feature in CSS is fully implemented across browsers. —Beleg Tâl (talk) 21:31, 11 February 2019 (UTC)
This has overlapping sidenotes, which I made an attempt to resolve by adding an optional 'clear:' in the relevant templates {{Outside}} and {{Outside2}} to try and get the sidenotes to auto wrap (the way {{MarginNote}}'s do.,
This has overlapping sidenotes, which I made an attempt to resolve by adding an optional 'clear:' in the relevant templates {{Outside}} and {{Outside2}} to try and get the sidenotes to auto wrap (the way {{MarginNote}}'s do.,
sounds of insane laughter... It's ALWAYS a misplaced bracket., anyway I've solved the overlapping sidenotes issue that's been an annoyance for over a decade, with one simple clear: in the Sidenotes code. :) (more insane laughter...) ShakespeareFan00 (talk) 15:51, 11 February 2019 (UTC)
OK, it's time to think laterally. Why does it have to be sidenotes? Just because in print the decision was made to print the references as sidenotes, why do we have to when presenting the text? After all, putting them there makes the work less accessible to some of our readers. Some possibilities (with thanks to the Braille community):
Regular footnotes collected at the end of the piece of legislation;
Regular footnotes collected at the end of the print-page representation (least acceptable here);
Regular footnotes collected at the end of each section/subsection/subsubsection/paragraph—whichever makes the most sense for the piece of legislation; or
Inline notes marked off in some distinguishable way (e.g. [], {}).
An explanation of the variation from print should be placed in the Notes field of the header in the Mainspace: transclusion.
I do prefer sidenotes, they look much better and work exactly the way the original author intended. Sidenotes are used for a different purpose than footnotes–they should help the reader find the place in the text where a particular topic is dealt with (while footnotes provide extra information and thus can be placed at the end). What is more, footnotes always disturb the readers forcing them to leave the text and go downwards and then return back, which is OK from time to time, but it is not very comfortable at the beginning of every paragraph. (It is possible that some browsers may have problems with sidenotes, but it is a problem of the particular browser, not ours. It is the browser that needs to be improved. I believe that programmers of browsers should serve the needs of internet users, not vice versa, i.e. internet users adapting their behaviour to make the situation easier for browser programmers). --Jan Kameníček (talk) 19:33, 11 February 2019 (UTC)
If the marginal notes were topic-based, then I would not be recommending changing them to footnotes. However, in this particular situation the notes are not topics, but are providing extra information. The print conventions of the period were to use marginal notes rather than footnotes. In this case there are a lot of notes that need to be attached to each paragraph. As a result when done as sidenotes there are frequent overlaps in the wider mainspace: windows. If we want to continue to allow our pages to be viewed at multiple widths on multiple devices, we need a way to manage the overlaps. Thus my series of suggestions to avoid sidenotes for the references. Beeswaxcandle (talk) 20:06, 11 February 2019 (UTC)
@Beeswaxcandle: As far as I see there is e. g. a part mentioning appointed commissioners, next to which there is a sidenote saying "Commissioners appointed". There is a part saying "...the first Meeting of the said Commissioners shall be held on..." which is accompanied by a side note "First meeting". And so on... They are typical sidenotes attracting the reader to the topic, not notes adding extra information. --Jan Kameníček (talk) 21:25, 11 February 2019 (UTC)
Well my preference is to keep the "subect-titles" as sidenotes (per more recent legislation, if not modern ones ), I'm open minded in respect of what are in effect cross referencing
The wrong page in
De Vinne, Invention of Printing (1876).djvu/554
the citation is right,
Johnson J.Typographia, or the Printers' Instructor, including an Account of the Origin of Printing. 24mo. 2 vols. London, 1824.
but the wikilink is wrong. There doesn't seem to have a page for John Johnson (1777-1848) (see [5]) - the page is for John Johnson Jr. Editor of the Johns Hopkins University Studies in Historical and Political Science
I've attempted MANY times this morning, to get the sidenote to have closer behaviour in the two respective versions... Something was more seriously clearly broken in the relevant template because parameterising ONE component should not have caused the template to cease rendering utterly.
It also doesnt't help that someone else seems to have assumed line-height is supported for SPAN ed content, MDN and W3Schools seem to say otherwise, meaning that the parameter concerned is effectively processed but may not have a visual effect. (sigh) ShakespeareFan00 (talk) 14:32, 13 February 2019 (UTC)
A.D 686 Cures an earl's wife
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.
A.D 686 Cures an earl's wife
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.
@ShakespeareFan00: Deep breaths :) Yes, it appears to be primarily that line-height is a block-element parameter being used on an inline element. Should you maybe use display:inline-block;? —Beleg Tâl (talk) 16:22, 13 February 2019 (UTC)
PS since sidenotes look different depending on Layout, perhaps some of these changes should be done in Layout.css rather than in the template. —Beleg Tâl (talk) 16:22, 13 February 2019 (UTC)
And whilst the layout options seem to function outside Mainspace. (the option for previewing them doesn't appear), which is not an acceptable long term approach... I'll revert back my changes for now, as this clearly isn't going to work unless someone does some much more fundamental rethinking (Sigh) :( ShakespeareFan00 (talk) 16:54, 13 February 2019 (UTC)
It might not actually be possible... If the sidenote is positioned absolutely, it can't be dynamically affected by the position of other sidenotes. However, if the sidenote is positioned relatively, it can only be placed within its parent, and not in its parent's margin... I think this is a place where CSS may have failed us. —Beleg Tâl (talk) 22:29, 13 February 2019 (UTC)
Can you come up with an alternate approach then, like converting them to footnotes instead? 22:33, 13 February 2019 (UTC)
Converting to footnotes is a viable solution. Honestly I would just use sidenotes and let them overlap, and then we can resurrect this discussion when future versions of CSS are released that might give us more options. —Beleg Tâl (talk) 21:06, 15 February 2019 (UTC)
Thanks. I did the former, and I'm happy with that. I read the LST page, but I'm not sure I understand what you're getting at with that one. I'm curious, if you're inclined to elaborate. -Pete (talk) 15:16, 17 February 2019 (UTC)
And others... Can someone else possibly with AWB, assisst in the repair of various tables over multiple pages? I am cleaning up LOT's of pages, but I am about to burn out doing it manually. ShakespeareFan00 (talk) 23:29, 15 February 2019 (UTC)
The other cause of a fostered content warning appears to be:
Header
{| <table style>
Body
{{nop}}
|-
|content
...
As there is no row defined at the point at which the {{nop}} occurs there is content outside the table structure which causes the 'fostered' content warning. Using
<!-- -->
|-
|content
...
instead resolves the error in some situations, but the longer term fix would be for the parser ( and wiki-markup) to explicitly recognise it is inside a table and handle the SOL context for the |- correctly, or by providing an unambiguous continuation syntax. There is a unresolved Phabricator ticket concerning this.
ShakespeareFan00 (talk) 10:33, 17 February 2019 (UTC)
Either I can waste time running around playing hunt the random whitespace rule, or someone can actually care, and get the parser fixed so it has ONE CONSISTENT and REPEATABLE behaviour for how to handle continued tables. This has been unresolved for some time, which doesn't inspire confidence in the platform used for Wikisource.
ShakespeareFan00 (talk) 10:45, 17 February 2019 (UTC)
? - there is a consistent and repeatable solution, which you are very familiar with - use {{nop}} to separate table syntax from other content so that they don't collapse into each other —Beleg Tâl (talk) 11:55, 17 February 2019 (UTC)
That was what WAS being used on that page... It was STILL generating a "fostered content" warning, apparently due to the <section /> tag, and also possibly due to the reasons I mentioned in the thread above. ShakespeareFan00 (talk) 14:35, 17 February 2019 (UTC)
What I am saying is that I shouldn't have to remember where {{nop}} (or {{nopt}} or <!-- --> works and where it doesn't. There should be ONE syntax that works in all instances and interactions, without me as a contributor having to guess/test on every single instance. It doesen't help that Wikisource is STILL apparently trying to do multipage tables with a syntax designed for single continuous pages. This isn't the first time I've mentioned this, and the sooner certain people overcome their resistance to actually fixing the real problem and provide a working syntax that doesn't depend on template or comment 'work-arounds' the better. ShakespeareFan00 (talk) 16:22, 17 February 2019 (UTC)
I don't know what a "fostered content warning" is, but I have yet to see a scenario where {{nop}} failed to work as expected. As far as I know {{nop}} is the one syntax that works in all instances--that's kind of the point of it —Beleg Tâl (talk) 20:04, 17 February 2019 (UTC)
What fosteref content is , where there is content appearing that doesn't fit with what media wiki thinks the expected table structure is.
{|
Run of text
|-
|Start of row.
|}
Would generate a warning because after the {| the parser is expecting to see either a | or |-. {{nop}} generates a <p></p> which can only appear within a <td> or <th> tag. Mediawiki in an attempt to clean up the output moves the content to the parent container (I.E Outside the table.). Using a <!-- --> instead to effect the line break does not insert content that shouldn't be there as whitespace between a <table> and a <tr> is acceptable..
In some instance the {{nop}} works because it's appended to the end of the row generated in the header portion...
{|
|-
!header1!!header2{{nop}}
|-
|Data 1|| Data 2
|}
Is what's the parser effectively thinks it's seeing.
Where the header only contains an opening {|
What's actually seen is seemingly
{|{{nop}}
|-
|Data 1||Data 2
|}
which breaks the intended stucture as the parser isn't expecting to see a <p></p> immediately after a <table>.
Because figuring these interactions out is tiresome, the proposal was a cleaner method of indicating the ditching of the initial <table>...<tbody> header code, that puts the table generation ENTIRELY within the body text of a page, which is one less set of handling rules to deal with and should be the repeatable and consistent approach desired.
ShakespeareFan00 (talk) 20:50, 17 February 2019 (UTC)
In respect of the proposal, what the parser would see is something like
<!-- first page -->
{| nofooter=true
|+caption
|-
! Header 1 !! Header 2
|-
|Data 1|| Data 2
|}
<!-- next page -->
{| noheader=true
|-ribbon=true <!-- I.E. Supress display of next row when transcluded. -->
! Header 1 !! Header 2
|-
|Data 1|| Data 2
|}
on transclusion, which is all within HTML5 structuring rules with no need for <p></p> or other insertions outside of <tr><th> etc.. and entirely linear.
Fixing this for good at parser level avoids the complications and is easier to debug. Spotting a missing noheader/nofooter in the table syntax is easier, then figuring out the absence of various line-feeds and template combinations.ShakespeareFan00 (talk) 21:01, 17 February 2019 (UTC)
Next step would be figuring out how to more precisely define how to handle no-footer/no-header rules work in templates which are transcluded to pages which are transcluded to mainspace., but these could be more tightly and rigidly defined than the current approaches.
I formatted the verse play The secret that can't be kept by copying verbatim the formatting of the Yale 1918 "Macbeth". This works fine except that I would like to add one additional improvement: I would like to confine the entire text column to a width of 32em so that when the screen is wide the right-floated elements are not ridiculously far from the left-aligned elements. In principle, I would do this by placing everything in a block. But I don't understand how to make this work correctly when dealing with multiple transcluded pages. The Yale "Macbeth" uses some tricks I don't understand, involving sections and a dummy header, in order to carry over {{dent}} from page to page. I copied this but don't know how to adapt it to carry over the block also. Levana Taylor (talk) 02:07, 20 February 2019 (UTC)
When formatting articles such as St. Anne's Lake, Transylvania, I use {{float right}} to append the signature to the end of the article text. This article also has footnotes, so for the sake of readability there should be a blank line between the signature and the rule above the footnotes: The problem is that
doesn't always produce the desired result because of the way that the float interacts with the elements below it. If I understand correctly, this problem is what the "clear" parameter is used for; but where should I put the "clear"? Levana Taylor (talk) 22:20, 20 February 2019 (UTC)
Hi I've added noninclude tags to the rule on the proofread page. This will make the rule viewable there but won't transclude it to the main namespace. Then I added a blank line and then a rule plus the reference tag to the main namespace which gave the blank line you were asking for. Using the reference tag you can place footnotes wherever you want in the main namespace, whereas if you don't use it they get automatically placed right under the text. Jpez (talk) 05:44, 21 February 2019 (UTC)
Can someone take [6], which is a copy of The Merchant of Venice (1923) and generate a DjVu file and upload it to Commons? It seems IA have not generated a proper DjVu file for this work. The file is needed as part of Portal:The Yale Shakespeare, a current project that is actively generating scan-backed editions of Shakespeare's plays.
Sure, but why have a needless diifference between the filename and the title? The "The" never hurt nobody! :) --Xover (talk) 05:15, 21 February 2019 (UTC)
Not true. Including "The" in the filename creates lots of extra work for any derivative files that have to be sorted alphabetically. Modern library databases routinely drop "an", "an", and "the" from the front of titles for this reason. Some of the other titles have been shortened as well, such as "King Lear (1917) Yale.djvu" instead of "The Chronicle History of the Life and Death of King Lear and His Three Daughters (1917) Yale.djvu" --EncycloPetey (talk) 20:58, 23 February 2019 (UTC)
What Is the best way to suppress the paragraph-space between two pieces of text that are one above the other? (Not using "float" because I want to position them exactly.) The poem tag is one; are there others? --Levana Taylor (talk) 20:00, 23 February 2019 (UTC)
See the letter in this story. I have the signature positioned by means of <br/> and {{gap}}, but I would rather right-align it; {{right}} would cause a paragraph break between the signature and the line above. Levana Taylor (talk) 20:42, 23 February 2019 (UTC)
I've used {{float right}}, although for letters in the middle of text, I might use a {{block center}} with fixed width to help set it off from the body text. Short letters like this suffer from the switch to electronic format by virtue of no longer being constrained to a column of fixed width. --EncycloPetey (talk) 20:54, 23 February 2019 (UTC)
It's failing for me too. I'm not quite sure why, but it is using a jQuery ajax call rather than the API, so I'd like to make this change to the gadget code to fix the issue. SamWilson01:17, 25 February 2019 (UTC)
When you have a poem with some extremely long lines, it'd be good to allow for wrapping by specifying a hanging indent. But if you add {{hi}} to the start of the poem, it assumes that successive lines of the poem separated by a single line break are the same paragraph and indents every line after the first one. Solution? Levana Taylor (talk) 19:00, 24 February 2019 (UTC)
So what you want to happen is, rather than:
And there, in middle of the path, a leper did appear;
In a deep slough the leper lay; to help would none come near,
Though earnestly he thence did cry, "For God our Saviour's sake,
From out this fearful jeopardy a Christian brother take."
— you would prefer something along the lines of:
And there, in middle of the path, a leper did appear;
In a deep slough the leper lay; to help would none come near,
Though earnestly he thence did cry, "For God our Saviour's sake,
From out this fearful jeopardy a Christian brother take."
If you don't want a hanging indent, then don't use hanging indent; use a div.
And there, in middle of the path, a leper did appear;
In a deep slough the leper lay; to help would none come near,
Though earnestly he thence did cry, "For God our Saviour's sake,
From out this fearful jeopardy a Christian brother take."
If I understand it right, what Levana Taylor wants to achieve is something like this:
And there, in middle of the path, a leper did appear;
In a deep slough the leper lay; to help would none come near,
Though earnestly he thence did cry, "For God our Saviour's sake,
From out this fearful jeopardy a Christian brother take."
The solution I have used is not very good and I would be also grateful for being shown some better. The one suggested at the top looks quite complicated to me. --Jan Kameníček (talk) 21:44, 24 February 2019 (UTC)
If the problem is the wrapping of lines, and getting them to wrap in specific places, then that is not usually replicated in Wikisource. The place where a line wraps is fundamentally a function of the page width in the publication. But at this point we're speculating, because we don't know for certain what is being attempted. --EncycloPetey (talk) 22:18, 24 February 2019 (UTC)
I am not sure if we understand each other. The problem as I see it is in making the high indent inside the <poem></poem> tags. (I wrapped the poem in {{block left}} only to make sure that the high indent is visible.) If you watch a poem with long lines on a large monitor, then there is usually enough space and no need to indent it. But when you watch it on a narrow display, part of the verse often gets to another line and needs to be indented similarly, as it is indented in books with narrow pages. The same problem can also appear in the Page namespace, where the right half of the screen is dedicated to the scan and thus the remaining space is much narrower.
The indenting of a single wrapped line within a paragraph is not really supported in HTML/CSS. I strongly recommend that you not try to replicate it, but rather that you allow it to wrap without indenting which is the default wrap behaviour for digital documents. —Beleg Tâl (talk) 00:12, 25 February 2019 (UTC)
@Beleg Tâl: The problem with poems is that you need to distinguish visually a new verse from a verse which has just overflown to another line because of its length. The indent is not only the solution used in printed books, it is probably the only really suitable solution. --Jan Kameníček (talk) 10:12, 25 February 2019 (UTC)
Hmm.
This is a poem.
It is really rather good.
I wrote it myself.
The only trouble is: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
it has a really long line.
This solution helps with one particular extremely long line, but it seems too complicated to be used regularly throughout the whole long poems or even anthologies of poems. As I have pointed above, even moderately long lines need to be indented when vied on small displays. For example the Page:An Anthology of Modern Bohemian Poetry.pdf/45 is a real mess on my small monitor, but the suggested solution means that every single line has to be indented in this complicated way separately. It would be great if some simple template wrapping the whole poem could solve it. Jan Kameníček (talk) 10:05, 25 February 2019 (UTC)
Here is what I approximately see on my small monitor in the narrow window in the Page namespace (to achieve it, I limited the width of the block here):
Hidden springs were playing music and my day its song thereto was chanting,
On the melancholy shores.
The grief of bygone life, from whence I came was wafted to me from the fragrance,
And from the converse of the trees and from the heavy drone of insects o'er the waters,
And there lay whole centuries, betwixt my hands, that blossoms plucked, and them
Betwixt my countenance and a mystic world,
That in a thousand questioning glances in my spirit mutely gazed.
However, a new unindented line usually means a new verse, continuing overflown verse needs to be indented, otherwise the poem is difficult to read. Here is what I should see ideally:
Hidden springs were playing music and my day its song thereto was chanting,
On the melancholy shores.
The grief of bygone life, from whence I came was wafted to me from the fragrance,
And from the converse of the trees and from the heavy drone of insects o'er the waters,
And there lay whole centuries, betwixt my hands, that blossoms plucked, and them
Betwixt my countenance and a mystic world,
That in a thousand questioning glances in my spirit mutely gazed.
Is there a better way to achieve it throughout the whole poem or even series of poems?
BTW: Here I used an example when the width of the space for the poem is limited by the page namespace layout, but sometimes it can be limited in the main namespace too, for example by using the template {{Bilingual}}, which divides the screen into two halves. --Jan Kameníček (talk) 10:30, 25 February 2019 (UTC)
@Jan.Kamenicek: Your problem is a separate case, and as Beleg Tâl said above, there is really no good way to achieve that. It's possible of course, but it would probably entail something like wrapping the entire poem in a template with each line a separate parameter, and then doing a lot of moderately complicated and fragile styling. It's not something I would recommend pursuing unless the need was great. --Xover (talk) 17:40, 25 February 2019 (UTC)
@Xover: I do not think it is a separate case, the problem also arises always when you try to read any poem with average-long lines e. g. on a small mobile. It turns into a mess where it is very difficult to find out where a verse ends and a new one begins. --Jan Kameníček (talk) 17:53, 25 February 2019 (UTC)
@Jan.Kamenicek: I agree that it is a problem. What I'm saying is that it is a different problem, and, due to the limitations of HTML/CSS that Beleg Tâl mentioned above, it cannot use the same same solution. Any solution that I can see to the problem you're talking about would be complicated and fragile. Sorry. --Xover (talk) 18:08, 25 February 2019 (UTC)
There is an experimental CSS property text-indent:each-line. When this or an equivalent is published, it will be easy to add this to existing and new poems. —Beleg Tâl (talk) 18:32, 25 February 2019 (UTC)
If you use Xover's solution on any line longer than 35 em (30 em to really be on the safe side) it takes care of any ordinary, rather than narrow, screen width. But I agree with Jan Kameníček that this doesn't address the real problem. Let's hope for improved CSS soon! Levana Taylor (talk) 19:49, 25 February 2019 (UTC)
Contents page numbers don't match the actual page numbers
I am proofreading Index:The Coronado expedition, 1540-1542.djvu where the some page numbers of the Contents and all of the Illustrations page numbers are incorrect and have no relation to the actual page number and there is no pattern to the offset.
I am asking what is the company policy on what to display? The printed page number, or the actual page number?— Ineuw talk13:01, 9 March 2019 (UTC)
I would just display the number as printed without marking it. On the whole there is no need for links to page numbers as our links are to chapters or sections of a work. If there is a real need to link to a page within a section, then use deep-linking to the appropriate anchor—either the derived one to the page number from the pagelist or a user-created {{anchor}}. Beeswaxcandle (talk) 18:16, 9 March 2019 (UTC)
Thanks to all for the advice. @Beeswaxcandle: I know that it's not necessary to create links from the contents to the page namespace, and I wasn't going to do it, but the images' djvu numbers are all over the place and without access to the pages they are very difficult to find and verify. — Ineuw talk18:59, 9 March 2019 (UTC)
images not accompanying text in magazines
Some magazines may publish an image that does not accompany a story or article, like "The Fair Jacobite" on page 249 of Once a Week vol. VI. What is the Wikisource policy about including these when entering a magazine article-by-article? It does have a caption, at least, or there'd be nothing English-language about it. Levana Taylor (talk) 22:03, 10 March 2019 (UTC)
In the magazine the picture is placed between two articles. So I would put it into a separate subpage between the two subpages with those articles. --Jan Kameníček (talk) 22:59, 10 March 2019 (UTC)
It's part of the magazine. We store English language magazines, including their images, captions or no captions. Jan's probably right; just stick it on its own subpage.--Prosfilaes (talk) 04:44, 11 March 2019 (UTC)
Because this is a rare occurrence, there isn't a set policy for what to do in this case. Putting it on its own subpage is one option. I personally would probably put it at the end of the section preceding it. It's really up to the discretion of the editors who are proofreading the work, whatever makes the most sense within the context of the work as a whole. If there are likely to be more such instances, you should make a note on the index talk page to inform other editors what the convention is if they run into the same question. —Beleg Tâl (talk) 15:01, 11 March 2019 (UTC)
There aren't going to be any more in the issues of OAW I'm working in, but in the later years of the magazine they frequently had a "pull-out" artwork in the issue, and they weren't the only ones to do this. Levana Taylor (talk) 16:01, 11 March 2019 (UTC)
missing greek
Hi,
I've just finished proofreading Munera pulveris by John Ruskin. Just a heads up to whoever can fix Greek, there's 15 pages with only a few words or short phrases per page of missing greek for it to be fully proofread. And transcluded? Cheers, Zoeannl (talk) 10:01, 10 March 2019 (UTC)
On the author page for Abraham Cooper, who has two images in Wikidata, including the image here isn't working properly. But William Wordsworth, who also has two images, is correct. How was this achieved? I don't see anything on Wordsworth's page selecting an image. Levana Taylor (talk) 20:34, 12 March 2019 (UTC)
Look at Wordsworth's Wikidata item, in the image section. Look at the little arrows by the top left of each picture. You can see that one image is ranked higher than the other, but this is not the case for Cooper. Try setting the rank of one of his pictures higher.
Yes, it should be controlled at this end ... I would want the "Old" image here on Wikisource because it corresponds to the time of writing of that article, but perhaps someone else using Wikidata for a different purpose would have a reason for wanting the "Young" image as their default. Levana Taylor (talk) 21:31, 12 March 2019 (UTC)
I think it will make no harm when I start proofreading, and if the pages don't match after the files are replaced later, they can be moved. But it would be great if somebody were able to get a better copy. --Jan Kameníček (talk) 19:51, 17 March 2019 (UTC)
Done but the quality isn't the best. Also there is no ocr but you can use the ocr button for that. I'll see if I can create a better copy when I have the time. Jpez (talk) 05:13, 18 March 2019 (UTC)
This page was previously deleted on 16 September 2012 by George Orwell III who unfortunately does not seem to be around atm. Is it good to create and proofread? Cheers, Zoeannl (talk) 09:36, 17 March 2019 (UTC)
But the seal is in the public domain copyright-wise, and we won't have any copyright problems using it. There's no reason to not use an image that's already on Commons.--Prosfilaes (talk) 07:43, 21 March 2019 (UTC)
Further to this: regardless of the copyright issues (which there are none), the fact that the government agency themselves placed the seal on this document means that we are not violating any regulations by reproducing the seal when we reproduce the document. —Beleg Tâl (talk) 12:25, 21 March 2019 (UTC)
Actually, that makes a ton of sense in retrospect. I had wanted to be on the safe side with this, but I am glad my to confirm these concerns were unfounded. –MJL‐Talk‐☖03:53, 23 March 2019 (UTC)
Header, main window and footer temporary resizing issue
I reported this bug and wondered if anyone else has this problem. Would other editors check this and please reply here indicating the OS and the browser used? Thanks in advance.— Ineuw talk03:45, 25 March 2019 (UTC)
Issue is resolved. There was a code line in the common.css causing all of the above problems. Thanks again. — Ineuw talk21:21, 25 March 2019 (UTC)
top caption with FIS?
On this page {{FIS}} allows me to insert the floor plan the way it should be, except that as far as I can tell it doesn't allow for the caption at the top. Can the top caption be added using FIS, or is there another way to get the floor plan right? Levana Taylor (talk) 03:24, 28 March 2019 (UTC)
Problem with that: the "capalign" parameter of {{img float}} aligns both the top and bottom captions the same, whereas in this case the text above should be centered and the text below should be left or justified. Can some HTML expert suggest a way to get the correct result "by hand" instead? (replicating what img float does, but with separate alignments for top and bottom captions)? Likewise I want to put the bottom caption in smaller font than the top one, which means specifying different line heights. Levana Taylor (talk) 14:18, 28 March 2019 (UTC)
Jesus and Satan meeting
Some where in Ellen Whites writings, there is a reference when Jesus meet Satan some where in space and Satan wanted to return and Jesus turned and cried, where is that found? —Preceding unsigned comment added by 12.246.210.62 (talk)
It seems the text layer is either missing or incomplete. I used the WS OCR button to generate text, but this method has several issues, including (1) text rife with scannos, and (b) curly quotes instead of straight.
It may be worth looking for a better scan of the novel instead of proceeding with this particular file.
Also, we already have the 1st (UK) edition, and the 2nd (UK) edition of 1850 is considered the authoritative one. So, is the 1848 US edition worth having? --EncycloPetey (talk) 13:31, 28 March 2019 (UTC)
It must be your browser, it's working fine with Firefox (Mac) and Safari (Mac only). The only thing not working with me is the header - which says - wuraaaxnc acres-rs. 5 --kathleen wright5 (talk) 14:03, 28 March 2019 (UTC)
I would say so. It's a poor scan, with a bad text layer, for an unimportant edition, of a work for which we already have the 1st edition. The 2nd UK edition of 1850 would be valuable, but an early US edition of this novel is more a literary footnote. --EncycloPetey (talk) 14:20, 29 March 2019 (UTC)
The name of the main namespace page does not link to the Table of Contents entry
Can someone please look at these pages and tell me why a link is not made? The text in the Table of Contents was copied from the main namespace page title.
I copy-pasted the link from the address bar that uses underscores instead of spaces, and it's linking now. I have no idea why it didn't work before though. Jpez (talk) 12:51, 30 March 2019 (UTC)
Set this problem aside in the past few hours, But I think it's best to delete all main namespace pages cascading from the two roots, and then delete the root pages. — Ineuw talk21:44, 30 March 2019 (UTC)
@Jan.Kamenicek: Five pages of Contents are not too long. First, it helps if the pages appearing in the Contents list exist. There is an error somewhere in the list of contents. If you look at the end of transclusion on the index page, there appears three page numbers outside of the Contents structure. — Ineuw talk16:43, 30 March 2019 (UTC)
@Ineuw:I looked at it again, but there are only existing and proofread pages transcluded. When I try to remove some of the the pages transcluded in the beginning and look at the preview, the pages in the end are transcluded without any problem. That is why I guess the problem is with the length of the pages (maybe they contain too many complicated templates...).--Jan Kameníček (talk) 16:52, 30 March 2019 (UTC)
@Jan.Kamenicek: Tried to find the problem by pasting all five pages into this sandbox. Please look at it if anything is missing. Unfortunately, I never used this template. Isn't there supposed to be end of list template?— Ineuw talk17:17, 30 March 2019 (UTC)
@Ineuw:It is interesting that direct pasting resulted in more content being displayed in your sandbox, but still the last rows do not work. The documentation to the template {{Dotted TOC line}} does not say anything about ending the list. Anyway, when the list is shorter, it works well, see, e. g. this experiment, when it is longer, transclusion of the last pages stops working. --Jan Kameníček (talk) 19:15, 30 March 2019 (UTC)
@Jan.Kamenicek: You're definitely running into the post-expand include size limit (~2MB). II'm guessing the main culprit to be {{Dotted TOC line}}. Every single invocation of this template will spit out ~10k characters (and assuming all of them are stored as 8 bits, one byte, that's 10kB), meaning you can have a maximum of 200 of these before hitting the limit provided there are no other templates or content involved. Your pages break down like this (post-expand include size in bytes):
My immediate advice would be to drop {{Dotted TOC line}}. I'm all for reproducing works visually as close as possible, but this particular template looks downright pathological: the sheer amount of markup it spits out for each single line is just astounding. For a long(ish) ToC it's never going to work reliably and will have a measurable impact on readers' systems (download time, performance). Case in point, replacing it with {{TOC line}} on Ineuw's sandbox reduces its post-expand include size from 2,097,152 bytes (capped by the limit) to 252,726 bytes. That is, something on the order of 90% of it comes from {{Dotted TOC line}}. --Xover (talk) 20:47, 30 March 2019 (UTC)
I was afraid the problem is something of this kind... It is quite bad if the dots have to be left out. The reason is not only the effort to reproduce the original, but dots really make such long lists much easier to read :-( --Jan Kameníček (talk) 21:36, 30 March 2019 (UTC)
I also see a number of redlinks in those pages that appear to need correcting, such as links to ".../Chapter 3/Chapter 5" in the text --EncycloPetey (talk) 22:02, 1 April 2019 (UTC)
It also looks as though the line returns, at least in the left column, are deliberate. It may be easier to match the columns if you replicate these line returns instead of having the text wrap. --EncycloPetey (talk) 00:59, 15 April 2019 (UTC)
Drop initials are incompatible with other formatting...
See: - Page:Ruffhead - The Statutes at Large - vol 2.djvu/94. Can someone take a sledgehammer to the relevant templates and MAKE them interact in a SANE manner please, there having been considerable efforts made to make the templates used here not screw up the layout?.
If this isn't fixed I will consider nominating the ENTIRE cl-act-p based family for deletion, on the basis that they just seem to be too incompatible, It is not as if they are widely used. ShakespeareFan00 (talk) 09:43, 16 April 2019 (UTC)
These templates rely on floating elements. If you familiarize yourself with float positioning you should be able to figure these out. In this case, {{cl-act-p}} depends on {{margin block}} which by default clears floats to the left. This forces each cl-act-p block to appear below other cl-act-p blocks, or any other floated blocks that precede it. The dropinitial is also floated, and is not cleared, so it will be positioned beside the floated block immediately before it - which is the very last cl-act-p block. You can get around this by putting all the cl-act-p blocks inside a container block. The dropinitial will then be positioned next to the top of the container block (which is now the immediately preceding floated block) instead of next to the top of the very last cl-act-p block. —Beleg Tâl (talk) 13:01, 16 April 2019 (UTC)
Right so dropintial is (currently) incompatible with cl-act-p, Perhaps at some indeterminate future date it will be possible for Wikisource to have templates that do not have obscure interactions issues, until then it seems an overly complicated and otherwise uncessary workaround is needed. What a shame :( ShakespeareFan00 (talk) 16:36, 16 April 2019 (UTC)
Perhaps YOU are able to provide a "compatible" drop-initial template that doesn't rely on a contributor knowing precise CSS details and the minutiae of obscure Mediawiki/HTML/CSS interactions? Thanks. ShakespeareFan00 (talk) 17:03, 16 April 2019 (UTC)
lol nope. Templates are just shortcuts for CSS. If you want to format a text with complicated floating blocks of text, it's up to you to understand how complicated floating blocks of text works. Dropinitial needs no further changes to work the vast majority of the time; if you want a version of dropinitial that accounts for the behaviour of whatever cl-act-thingy is, then that's on you. —Beleg Tâl (talk) 17:26, 16 April 2019 (UTC)
Whilst that may be so, there wasn't anything in the documentation for {{di}} or {{intial}} that mentions this issue in any detail. Once again I am supposed to KNOW apparently by intution or telepathy, various miniutiiae of CSS/HTML/Mediawiki markup interactions. This is NOT conducive to positive long term contributions. ShakespeareFan00 (talk) 18:18, 16 April 2019 (UTC)
The documentation for {{di}} explicitly says "This template simply generates a left-floated span (w/style display: block;) containing content with the proper CSS styles applied to it." Floated elements are well documented on MDN, W3Schools, and many many other websites. No intuition or telepathy required. —Beleg Tâl (talk) 20:57, 16 April 2019 (UTC)
The incompatibility of {{di}} with other "floating" templates is NOT howver documented. It seems I'm wasting my time trying to get anywhere with this issue (sigh).ShakespeareFan00 (talk) 21:12, 16 April 2019 (UTC)
See also Page:Test_page#Testing_/s_/e_version_(5d)_with_inline_at_start,_layout_specified_and_a_drop_initial_(I_said_let's_have_some_insanse_test_case!) , The 2 sidenotes/titles should be level with the dropinitial, but that seems to currently be outside the limitations of Mediawiki/CSS/HTML to handle in a SANE and CONSISTENT manner. As I said perhaps SOMONE ELSE can come up with an approach that means that the SAME concerns and arguments do not occur again and again EVERY SIX MONTHS until someone finally gets around to ACTUALLY providing the functionality needed, instead of stalling by saying it's down to me. Either work out a fix the templates or put it in the documentation, that DI and other templates can't be used alongside other 'floated' elements. ShakespeareFan00 (talk) 21:25, 16 April 2019 (UTC)
From some further analysis it seems that what I am trying to do in terms of interactions is NOT currently feasible, due to CSS/HTML limitations. Hopefully when the CSS Text spec, properly supports true drop initials (and browsers do as well) this can be revisted. In the meantime the work around seems to be use a right-hand position for the sidetitles universally. ShakespeareFan00 (talk) 09:39, 17 April 2019 (UTC)
OK, anyone here good with LUA code?
Page:Ruffhead_-_The_Statutes_at_Large_-_vol_6.djvu/775, a template used on this page was recently updated. I can't figure out WHY the change should have caused something that worked previously to suddenly start generating BAD markup. Can someone else here please provide an explanation, and a repair, so that the templates behave in the SANE and DOCUMENTED way they are supposed to. Thanks. ShakespeareFan00 (talk) 10:49, 16 April 2019 (UTC)
I don't see anything wrong with the linked page. What are you talking about? Which template? What update? Where is the bad markup? —Beleg Tâl (talk) 13:06, 16 April 2019 (UTC)
Page 8 and Page 9 of The Lucknow Album are currently proofread as two separate tables, which is causing misalignment on transclusion. I have tried formatting as page-spanning table, but for some reason it is not working on transclusion. Can someone make a fresh attempt please? Hrishikes (talk) 08:06, 20 April 2019 (UTC)
Done, looks like it was because page 8 and page 9 were transcluded separately with two separate <pages /> calls. —Beleg Tâl (talk) 11:38, 20 April 2019 (UTC)
I marked this page "validated," but in retrospect my approach is pretty kludgey. Could somebody with a better understanding of how to handle curly braces in tables offer an alternative?
have more spacing between them than ordinary lines do, despite there being no extra line spacing or paragraph breaks applied in the source.
Also, I'm not quite sure how to achieve the indenting style from the original text, as you can see on the same page, when a line runs over, it's a hanging indent, but the second line is right-aligned, but then slightly indented from the right margin. -- I, Podius (talk) 18:11, 25 April 2019 (UTC)
@I, Podius:{{center}}, {{left}}, and {{right}} all wrap their argument in a HTML <div>…</div>, which is a block element like <p>…</p>, and so will always have the same vertical whitespace properties. Your best bet is probably to leave the text as such left-aligned but use {{gap}} to indent the relevant lines a suitable amount. I wouldn't worry about that final word on the last line. It doesn't appear to be deliberately wrapped for artistic reasons: it's just wrapped due to the space constraints of physical books. The weird alignment is just to mark such a wrapping point. Just unwrap these lines and you won't need to worry about trying to reproduce it. --Xover (talk) 18:36, 25 April 2019 (UTC)
@Xover: Ah, I see! What annoying behaviour. That's good to know. I wasn't sure how closely I should try to match the original formatting, so that's helpful; I'll just add a standard hanging indent for when the text wraps, in that case. Thank you! I, Podius (talk) 03:29, 26 April 2019 (UTC)
See also Wikisource:Scriptorium#blocks of text w/o blank lines between paragraphs. I have tried the method there, of removing automatic paragraph margins by surrounding every paragraph with {{p|m0}}</p>, and it works fine. Two clarifications: 1. {{p|m0}}</p> should be placed inside all <div> templates such as {{right}} 2. You can specify spacing before and after a block of no-paragraph-break text by using {{dhr}} Levana Taylor (talk) 19:48, 25 April 2019 (UTC)
@Levana Taylor: Very helpful, thank you! It took me a while to figure out how to get it working because I didn't realise I needed to add {{p|m0}}</p> to the preceding and following paragraphs, as well. But now it all looks right. Cheers! I, Podius (talk) 03:29, 26 April 2019 (UTC)
I would like to proofread the play R.U.R. (Rossum's Universal Robots) by Karel Čapek (the one which introduced the word "robot" for the first time). Unfortunately, the copy at Hathitrust is not very good, e. g. instead of the four sketches of the stage at the end of the book there are only two repeated twice, and some inscriptions in the sketches are illegible. I have found a much better copy at the archive.org, but it seems it can be only borrowed for some reason, although it should have been out of copyright already. Is there any way how to get the book from the archive.org? --Jan Kameníček (talk) 18:40, 28 April 2019 (UTC)
That was one of my first scans, and the worse for it. It is available on archive.org, but it's not really usable directly. However, Google Books had a better copy of the same edition I scanned, so I uploaded it to File:R U R Rossum s Universal Robots.pdf. It does not have the sketches of the stage, instead having photos of the action, and I'm not sure it's the exact same play text, but there it is.
BTW, we should probably move the Paul Selver books from Commons, since he died in 1970, leaving his translations under copyright in his home nation.--Prosfilaes (talk) 09:14, 29 April 2019 (UTC)
All these linked publications are published in the USA; does that not make USA the source country for this work? —Beleg Tâl (talk) 11:19, 29 April 2019 (UTC)
Thanks very much! I will start working on it soon :-)
As for the Commons, their rules seem too complicated to me, so I am really not sure whether the movement is necessary or not. However, the R.U.R. was published directly in the U. S., so I guess it could have been uploaded to Commons. However, I do not care very much if it is uploaded here or there. --Jan Kameníček (talk) 11:43, 29 April 2019 (UTC)
Now I looked at it in more detail and found out that the editions are not the same, comparing e. g. the descriptions of scenes, which are much longer and more detailed in the version published by Samuel French than the description in the uploaded version published by Doubleday (besides the missing sketches). So it would be great if it were possible to get the Samuel French version somewhere too, I would be happy to proofread both of them. --Jan Kameníček (talk) 12:06, 29 April 2019 (UTC)
Thanks, although it seems that the djvu file has lost the OCR layer. Besides that I have to confess I prefer pdf files as they can be also easily viewed outside the proofreading extension directly in a web browser, while djvu files require to download some additional software (I have it but other people who may also want to see the file usually don't). But I thank you for trying to help! --Jan Kameníček (talk) 07:53, 30 April 2019 (UTC)
I've deleted the duplicate pages from the above, but are still showing. I also deleted them from the Index namespace. What have I done wrong? --kathleen wright5 (talk) 02:01, 6 May 2019 (UTC)
@Kathleen.wright5: The underlying PDF at Commons contains 6 pages, which is what ProofreadPage will show in the Index: for it. You may wish to consider whether duplicated pages are a significant (i.e. worth preserving) feature of the original edition, or whether it is incidental or an error introduced during digitisation. In any case, you can just mark them as not needing proofreading in the pagelist if that is indeed the case. --Xover (talk) 06:19, 6 May 2019 (UTC)
After spending two days wrestling with the formatting of an article on cryptography, I have got it all solved, except for one point. On this page, in the paragraph below the cryptic message, one line has a brace under it, and I could not find a way to insert that. Luckily, though, it might not be necessary to include this brace at all, because it isn't part of the text proper, but rather a proof notation indicating "Obviously some error here - query what is intended" which didn't get corrected before the final printing. (This isn't the only muddled sentence in the article either; a pity there wasn't another round of proofreading before press-time.) Thoughts? Levana Taylor (talk) 22:53, 8 May 2019 (UTC)
@Levana Taylor: Absent other examples it is hard to generalise, but in this instance it appears the brace might be marking the repeated "b" (which seems an obvious error, indeed) specifically. If that is the case you might use {{SIC}} to mark that letter. If other instances truly mark a line or sentence fragment of indeterminate length I'm not sure there is any sensible way to replicate those particular markings. If the latter situation obtains it may be best to simply not try to reproduce these at all. --Xover (talk) 04:22, 9 May 2019 (UTC)
Could I have some ideas for dealing with these Notes. For example: this page. Some Letters have multiple Notes referenced, from different pages. Cheers Zoeannl (talk) 06:57, 12 May 2019 (UTC)
The answer partly depends on how the transclusion will happen. Is each letter going to be transcluded separately? Or is it going to be a single section with all the letters together? Beeswaxcandle (talk) 07:14, 12 May 2019 (UTC)
I don't know. There are no descriptive titles, just Letter # so I don't know if there is any advantage to transcluding separately? Hence, looking for ideas... Cheers, Zoeannl (talk) 21:43, 12 May 2019 (UTC)
Multiple columns across pages
I have a current project which includes a list of names several pages long. Each page is laid out in two columns and the entries are in alphabetical order (of surname) so for example one one page column 1 goes from John Freneau to John Hammel and column 2 continues from John Hibon to James Le Mome and the next page from Isaac Le Doux to Gentien Maret and Paul Maigne to John Picquet.
I started adding these using tables but then it occurred to me that once the pages are linked into a view of the full chapter the entries will be out of sequence as John Hammel from Page 1 col 1 will be followed directly by Isaac le Doux from page 2 col 1.
It looks as though the {{Div col}} template would solve the ordering problem when the pages are combined but the formatting options seem limited. The entries are quite widely spaced, are justified rather than right aligned, there is a large default line space, and the original uses a dividing rule between the columns.
I have been able to use an HTML <div style='column-count:2; column-rule: 1px solid black;'> to give me the rule but so far have not found a way to tighten up the text layout within the columns.
See the 'table' formatting here and the '{{Div col}}' version here
The standard solution here is to not use columns at all—or rather do it all in a single column. We are aiming to make the text available, not reproduce what the publisher had to do to keep the number of pages down. Beeswaxcandle (talk) 08:08, 16 May 2019 (UTC)
Thank you both. I have opted for the single column solution and have also used the <poem> tags from the pages that Jan linked to so tighten up the formatting. The only niggle there is that it seems they can't be used in the page headers/footers. The section (currently unfinished) is here. GreyHead (talk) 12:41, 16 May 2019 (UTC)
@Beeswaxcandle:: As you can see in the linked page above, the multicol template is used only in the noinclude sections, so the text is divided into the columns only in the page namespace, while there is just a single column in the main namespace.
@GreyHead: Yes, the <poem> tag cannot be put into the header or footer and has to be repeated in the beginning and end of every page. Another option (though not very comfortable one for long lists) is to use <br /> at the end of each line. Do you need any help with the unfinished part? --Jan Kameníček (talk) 13:46, 16 May 2019 (UTC)
@Jan.Kamenicek: Thanks for the offer, I'm fine thank you, it's a lot faster now using the <poem> tags and, all being well, I will finish this section over the weekend. GreyHead (talk) 13:20, 17 May 2019 (UTC)
page numbers in main namespace
Can anyone please help/explain what is happening here. For instance With axe and rope in the New Zealand Alps/Chapter VIII. The pages up to 86 are given to the left (in different layouts), but after the first image there are no longer page numbers visible. This is also the case in other chapters. What do we do wrong? Help appreciated, --Dick Bos (talk) 11:04, 17 May 2019 (UTC)
I'm looking to develop a new way of publishing translations of historical music theory sources. Could Wikipedia do this? Would another platform be better?
(1) The entire translation should be freely accessible and easily searchable online.
(2) All users can comment on specific passages, identify typos, and suggest changes, and this revision history is archivable and viewable
(3) A very high volume of foreign language and English text can be viewed in parallel format, with links to images of the original source (or just searchable images of original file on one side)
(4) Notation examples and audio files are integrated within the parallel text.
(5) Two systems of footnotes (original and editorial) are possible.
(6) Integrated bibliographical citations are possible.
Wikipedia would not publish translations, but Wikisource can under certain circumstances. See Wikisource:Translations, specifically the section on "Wikisource original translations". There would need to be a scan-backed copy of the original text at the appropriate language Wikisource (e.g. the Italian Wikisource for a text written originally in Italian.) Then, a translation can be created here based on that original.
Parallel texts are generated dynamically, rather than hosted as a single work. To create a text that is simultaneously in two different languages, you would need to work at the multilingual Wikisource instead. --EncycloPetey (talk) 16:37, 18 May 2019 (UTC)
Wikiversity would publish an original translation or even an original book, Derekremes. If it meets Wikisource's guideline, tho, it's probably better here; Wikiversity is for more general teaching and research resources. HLHJ (talk) 01:56, 20 May 2019 (UTC)
@Jan.Kamenicek: The copy from NWU hosted on HathiTrust is a Google scan, which means Google Books will probably be missing the same pages (it's the same scan). However, HathiTrust also has a ditto scan from a copy at UC which is not missing these pages. As best I can tell, both copies are the same edition. --Xover (talk) 09:15, 26 May 2019 (UTC)
@Xover: Good point! I did not notice it because Hathitrust usually links from an edition's catalogue record to all copies they have, but this time they have separate catalogue records for each copy for some reason. Anyway, I have uploaded the other version now. Thank you very much! --Jan Kameníček (talk) 10:04, 26 May 2019 (UTC)
They rely on the bibliographic records provided by the original institution, and those are in general pretty poor. Almost every time I visit Hathi I find some kind of quirk like that. Thus I wouldn't recommend trusting automatic links through author etc. fields blindly. Always look for title matches or your own search on the author name. --Xover (talk) 10:13, 26 May 2019 (UTC)
About create pages
Hello! Respected team, i m okay bhargav, i have some questions that which platform we make my wiki info..page past time auto delet my pages and after i don't try agqin so, what can i make page on wiki platforms and if yes , please give me a permission for make my own pages and help me for create pages please and if your answer not, so what is reason for that, also you cqn check my name find on google this name (okay Bhargav) so, i want to page for my information so, please help me. Thank you —unsigned comment byOk bhargav (talk) .
@Ok bhargav: On this website (Wikisource) you can add published, freely licensed, English-language written works. You cannot create a page for self-promotion. I have put some information on your talk page, which should answer your questions. I will try to answer any other questions you might have. —Beleg Tâl (talk) 18:29, 28 May 2019 (UTC)
Need for an Administrator
Hello - this is a new editor here. Can an administrator help me with my user-page? Multiple times I have tried to create it, but it keeps blocking my action, because the filter thinks that I am a spam-bot. I don't know where else to find help! Thanks in advance! Orlando the Cat (talk) 04:26, 30 May 2019 (UTC)
I've created it; that might let you edit it easier. If not, it would help if you could be very explicit about what error messages you're getting.--Prosfilaes (talk) 05:15, 30 May 2019 (UTC)
How to activate the OCR bot?
Every once in a while, when attempting to use OCR gadget, I get the following message: ws_ocr_daemon robot is not running..
Is this a daily maintenance routine at a particular time of the day?
I also come accross this quite often (for example just now) and it is very unpleasant as it slows down my contributions. Is there anything that could be done to improve the OCR bot's performance? --Jan Kameníček (talk) 07:35, 30 May 2019 (UTC)
Just a comment by Phe copied from the phabricator: "...the service was down and not running, those downtime are not related to 'too much request' but there was probably something broken in the past few days in the cluster or one of the numerous downtime for a planned maintenance..." [11]. --Jan Kameníček (talk) 23:02, 30 May 2019 (UTC)
Google's OCR scan is not nearly as good as Phe's. Phe's OCR interprets emdashes {{—}} correctly, recreates paragraph breaks and replaces all accented characters with and "é-acute". This last feature is a mixed blessing, even if it's incorrect 50% of the time. At least it identifies where lower case accented characters are missing. Ineuw (talk) 16:11, 1 June 2019 (UTC)
Unfortunately, it is not running again, and this frequent inaccesibility makes it much less useful. Therefore I am trying to get used to the Google gadget, whose main advantage is that it works --Jan Kameníček (talk) 17:11, 1 June 2019 (UTC)
Can someone decide on ONE date format on the quoted letters and document that style choice , so I can be consistent in applying it? Thanks.ShakespeareFan00 (talk) 18:35, 6 June 2019 (UTC)
Would you mind providing links to these quoted letters that you want advice regarding? I don't see any indication on the Index page of what you are referring to. —Beleg Tâl (talk) 18:44, 6 June 2019 (UTC)
Also, if you are proofreading this text, why don't you decide on one yourself? Are the dates really weird or something? —Beleg Tâl (talk) 19:23, 6 June 2019 (UTC)
I also failed to find anything problematic. One of the pages contains the date "July 30th, 1893." and the other March 7th, 1905. Can you please be more specific what sort of special tag you see there and where? --Jan Kameníček (talk) 21:08, 6 June 2019 (UTC)
I guess the date does look even smaller than the smaller quoted text on that particular page. Is it like that in every instance? (If not, there is no need to standardize.) If you nest smaller tags, the date will be really tiny; I'd recommend to use {{fine}} (or similar) instead so that it remains legible. However, the difference in font size is so subtle that I do not think it is necessary to reproduce it, so you can pick whichever convention you prefer, and post your decision at Index talk:The Naturalisation of the Supernatural.pdf —Beleg Tâl (talk) 21:13, 6 June 2019 (UTC)
Regarding Wikisource:WikiProject 1911 Encyclopædia Britannica
Are the comments and notes at the bottom of any given article modern? Or were they from the original article? It would seem they are modern. —unsigned comment by144.230.82.246 (talk) .
It would help answer your question if you could be a little more specific -- can you link to a specific page, or quote some of the text you're referring to? If the "note" is a statement about its copyright/public domain status, that is probably modern, and intentionally so. -Pete (talk) 19:20, 17 June 2019 (UTC)
Thank you, Beleg Tâl. I'm trying to figure out the best method for adding entire copyleft fulltext academic articles to Wikisource. I have an application for this, discussed on the Wikiproject Medicine group (the group is currently supplying Internet-in-a-box wiki subsets to off-the-net medical facilities). Is there a good way to link such a fulltext to the Wikidata metadata? Presumably you'd want to display that metadata here somehow, but hotlinking might be better. Is there an extant example I could look at to figure out how to do this? HLHJ (talk) 22:20, 1 June 2019 (UTC)
Thank you very much, Beleg Tâl, that's just what I wanted. I have looked through it and am looking at the tools credited in its edit history. I also uploaded another rather random non-medical article, but now I look at it more closely, I'm not sure the source (a journal which seems to be a research group's own publication) is reliable... I'll come back to this. HLHJ (talk) 04:10, 21 June 2019 (UTC)
Fixing problematic code (alignment in captions)
I've been informed that a number of my edits have introduced an HTML problem of some kind. (I'm no HTML expert, so I don't fully understand what it's about.) I'll put an example below. Can anybody suggest a better way to code such captions? I'd like to continue to use {{FI}} template if possible.
Copyright, Kiser Bros., Portland, Ore.
MOUNT JEFFERSON, FROM HOOVER'S BUTTE
"We can plainly see Mount Jefferson" (page 46)
This applies to most of the images in Letters From an Oregon Ranch and a number of other works as well. Of course, it would also be good to reduce the amount of space between the image and the caption...maybe a solution could address that as well? -Pete (talk) 19:26, 18 June 2019 (UTC)
@Peteforsyth: Some comments if I may? The caption parameter of {{FI}} always tries to enclose its content in an HTML paragraph (<p>) tag which regretably is somewhat at odds with use of {{right}} as that template in turn uses a division (<div>) tag to do its magic. This is one of the relatively few verboten HTML constructs which may be the origin of the original complaint…and also indirectly explains the gap betwixt image and caption you mentioned! (Oh and {{c}} adds yet another <div>… but by now the damage has already been done and cue parable spilt milk &c.)
May I humbly propose something like:
{{FI
|file=Letters from an Oregon Ranch p. 8.png
|width=90%
|cstyle=max-width:500px
|talign=right
|tstyle=margin:0
|caption={{sm|Copyright, Kiser Bros., Portland, Ore.}}</p>
{{p|ac|m0}}MOUNT JEFFERSON, FROM HOOVER'S BUTTE<br/>
"We can plainly see Mount Jefferson" (page 46)}}
which displays as:
Copyright, Kiser Bros., Portland, Ore.
MOUNT JEFFERSON, FROM HOOVER'S BUTTE
"We can plainly see Mount Jefferson" (page 46)
Now for a little explanation (as I have cheated a little bit!) talign=right is used solely to align the "Copyright" line and its effect ends at the </p> fragment. tstyle=margin:0 is used to eliminate padding around and within the caption (everybody forgets that paragraphs always add typically around 7px margin-top and margin-bottom!) Finally {{p|ac|m0}} adds a new paragraph with center aligning and margins (re)suppressed to hold the main part of the caption; i.e. "MOUNT JEFFERSON &c.
Many thanks, this helps me understand the problem and I think it's a good solution. In an ideal world, I tink there would be a little more space between the (c) notice and the actual caption (and/or a little less space between the caption's two lines). Maybe if I study the template you introduced I can find a way to accomplish this; but I wouldn't say it's mission-critical. Much appreciated! -Pete (talk) 19:12, 19 June 2019 (UTC)
Also, just out of curiosity -- won't this "cheat" introduce an extraneous closing paragraph tag? I assume that's simply ignored, and therefore not a problem -- but curious if I'm interpreting the code correctly. -Pete (talk) 19:13, 19 June 2019 (UTC)
Yes it does create another issues with mismatched tags, the REAL solution would be to fix {{img float}} so it can handle the block level elements correctly, but given past experience I don't see that happening certain contributors are aggressively dissuaded from "too clever by half" solution , as opposed to actual repairs to the underlying templates. ShakespeareFan00 (talk) 19:24, 19 June 2019 (UTC)
@Peteforsyth: Regarding the line spacing in the caption issue; is this more to your liking?
{{FI
|file=Letters from an Oregon Ranch p. 8.png
|width=90%
|cstyle=max-width:500px
|talign=right
|tstyle=margin:0
|caption={{sm|Copyright, Kiser Bros., Portland, Ore.}}</p>
{{p|class=imgCaption|ac}}MOUNT JEFFERSON, FROM HOOVER'S BUTTE<br/>
"We can plainly see Mount Jefferson" (page 46)}}
which displays as:
Copyright, Kiser Bros., Portland, Ore.
MOUNT JEFFERSON, FROM HOOVER'S BUTTE
"We can plainly see Mount Jefferson" (page 46)
I dropped the m0 as I misunderstood your requirement—which reintroduces that 7px inter-paragraph margin I referred to before. As for the concern about extraneous closing paragraph tags the balance between opening and closing tags is maintained thus:
<p> is generated internally by {{FI}} just after image and in front of caption—furthermore this is the paragraph which conveys the talign and tstyle information into HTML, and is closed by…
</p> this explicitly coded tag ends the Copyright line fragment and also ends right-alignment…
A second <p> is generated by {{p}} (Also a side note here: I added class=imgCaption as I missed the (slight) issue of {{FI}} marking the caption block with this particular class name and thought I might as well make the two paragraphs as similar as possible in this respect.)
</p> is generated internally by {{FI}} to close off the caption block. This is the cheat in that {{FI}} "thinks" it is encapsulating a single parargraph's text and in fact here it has been handed two. This is not an issue because {{FI}} furthermore encloses the whole image+caption entity within a <div> block and thus the whole mess hangs together!
@ShakespeareFan00: I hope the above exposition allays your concerns. {{FI}} is a surprisingly flexible and robust template and if anything ought to act as a model for modifications to other templates such as {{img float}}… However the two templates do not satisfy the same purposes at all and are not generically interchangeable. {{FI}} is superior for situations where a (possibly variable size) image+caption stands alone either within a page or floats off to one side. {{img float}} lends itself better to text winding around a captioned image of fixed dimensions. Not at all the same animals!
Thanks very much, this is all very helpful -- both to the immediate task at hand, and also giving me a nice lesson in the underlying issues. I'll start implementing this shortly! -Pete (talk) 07:25, 21 June 2019 (UTC)
{{hi/s}}<span style="display:inline-block; text-indent: 0;">{{ditto|Here is a STABLE way of doing this.}}</span>{{hi/e}} —Beleg Tâl (talk) 03:53, 22 June 2019 (UTC)
I just edited the page for John Donne's epigram "Hero and Leander" - it was incorrectly spelled as "Hero and Leader." I changed the title in the page entry, but "Hero and Leader" is still appearing, and a corrected link goes to the Marlow poem instead of the Donne epigram. Can anyone tell me how to fix this (or do I just need to wait for the change to percolate through)
The approach I am using here works, but adding {{p}} tags for each entry would be inefficient. @Xover: is this an approach where a TemplateStyles approach to redefine the P handling for each block of entries could be implemented for this index? It's mostly a simple margin collapse, and combination of that with the CSS style in the dent. It would be nice to be able to customise the indentation and paragraph break spacing behaviour, but I'm not sure TemplateStyles was advanced enough to handle paramatised generation of CSS per called block yet.
ShakespeareFan00 (talk) 08:51, 22 June 2019 (UTC)
@ShakespeareFan00: Provided I understand correctly what you mean, this sounds like it could be reasonably solved by using <pclass="no-vertical-space">…</p> and a per-work stylesheet that removed the margins. That is, in the page markup you use a template that tags it as a particular class name, and then write custom CSS that styles all instances of that class however you want. Provided each paragraph is styled the same, you would not need actually parametrized CSS for this.For practical reasons we would probably want to require some kind of prefix on the CSS class name (to avoid collisions), or some magic in MW (ProofreadPage and TemplateStyles) that takes care of the scoping. At small volume, for simple cases, and CSS that is used in a single work, this is not likely to be an actual problem; but worth keeping in mind. --Xover (talk) 09:13, 22 June 2019 (UTC)
Yes but I'd like to avoid having to type the P class=foo stuff individually for each paragraph, Ideally what I'd like is {{p-collapse/s}} and {{p-collapse/e}} I can apply over an entire block, which is at most 4 calls per page as opposed to a considerable number of {{p}} calls. ShakespeareFan00 (talk) 09:18, 22 June 2019 (UTC)
Probably doable by using <divclass="no-vertical-space">…</div> around all the paragraphs and then using a stylesheet that applies the style to div.no-vertical-space>p. But since the actual paragraphs are then generated by Mediawiki there is some fragility here that may or may not be a problem in practice. --Xover (talk) 10:24, 22 June 2019 (UTC)
Also- [13] Why is the bottom entry mis-aligned, I was using the /s /e variants to accommodate the split layout?
It seems that at the end of the page it fails to wrap the end paragraph. This is a LONG-standing issue that no-one seems to have wanted to tackle prviosuly. Using {{nop}} in the footer did not change the behaviour. I've also asked at least TWICE for the whitespace behaviour to be PROPERLY DOCUMENTED so I'm not playing hunt the "pedantic minutiae" MANY, MANY, TIMES. ShakespeareFan00 (talk) 11:16, 22 June 2019 (UTC)
What needs to happen in the CSS style, is that the margin behaviour for the top margin/padding reverts to normal for the first entry in a collapsed block (i.e the first entry of the B block) ,and conversely needs to revert to normal for the bottom margin in the final paragraph of a block (i.e the end of the paragrpah representing the last entry of the block of A entries.) I had a possible approach commented in the style sheet, but wasn't sure how to cancel a previously defined style back to the normal/default inherited values. ShakespeareFan00 (talk) 14:03, 22 June 2019 (UTC)
You should be able to do that by simply adding a margin to the div itself. I've done that: take a look and see if that does it? --Xover (talk) 14:20, 22 June 2019 (UTC)
Thanks, Also added some rules for the first and last P elements, hope it doesn't add additional space, I an re-comment them if needed. Seems to work so far.
Text Indentation handling
@Xover: Relating to Page:The Prince (translated by William K. Marriott).djvu/313
Currently I am using {{dent/s}}, {{dent/e}} to set up the text indent, however here there is a slight issue with this, given that the start of the page is a continuation of the previous entry and so as such doesn't need the indent. The slight discrepancy can be worked with for now, but in time it would be nice to be able to have an expanded {{dent/c}} that gives a more accurate behaviour (My current attempt doesn't actually work properly yet). ShakespeareFan00 (talk) 14:40, 22 June 2019 (UTC)
The templates make it kinda hard to see, but all of them are really just spitting out HTML div elements with some associated CSS. Most of the /e templates spit out a plain </div>. Which means what you're really doing here isn't some special Mediawiki syntax: it's just various shortcuts for inserting HTML code. And as such, anything you want treated specially needs to be marked up specially.I can't immediately think of any way to make {{dent/s}} automatically correct for being in the Page: namespace and set an indentation that is correct relative to whatever you had it set to on the previous page (and the pages may even be stored out of order). But simply wrapping the special bit in a separate {{dent/s}}, ending it when the special bit is done, and then adding the regular dent for the rest of the page is relatively cheap. --Xover (talk) 15:17, 22 June 2019 (UTC)
Good thinking in regard to the modified wrapping, but it would have caused problems for the nesting of HTML tags. For now I've just taken out the indentation entirely, and until {{dent}} or another template can be repaired to work correctly over multiple paragraphs and inside other "classed" DIV's without resetting stuff. ShakespeareFan00 (talk) 16:14, 23 June 2019 (UTC)
The style is defined as DIV -> P but where the dent is put in it would be DIV-> DIV -> P, I'm not sure there's a way in CSS to say DIV -> (any number of sub levels) -> P Sigh :( ShakespeareFan00 (talk) 16:30, 23 June 2019 (UTC)
Index:The Life of the Spider.djvuCurrently this uses {{RunningHeader-centered}} in the header and footer of a number of pages.. The code given could be easily replaced with a much simple {{center}} given that the single element present is in the center location, but to do it for all pages manually would be time consuming. Is there someone here that can make the appropriate change with a script, AWB or bot rapidly? ShakespeareFan00 (talk) 09:08, 22 June 2019 (UTC)
@ShakespeareFan00: Are you familiar with the AWB software? If you're using Windows, it's a great option for stuff like this. I think it's pretty straightforward to figure out, but I'm happy to answer questions if needed. -Pete (talk) 19:25, 22 June 2019 (UTC)
@Ineuw: You are quite correct. I did not word it well but meant only after the entire set of transcluded pages is (at least) at proofread standard — if the main-space problem remains then is the time to start seriously bug-hunting. I missed the fact Appendix A (and thus the table, too) ended on page 524! 114.78.66.8204:44, 24 June 2019 (UTC)
Understood what you said about the set. Instead, there are a lot of small tables within the section.Ineuw (talk) 08:13, 24 June 2019 (UTC)
Can someone come up with a way to convert the Munsell colors back to RGB for the table cell backgrounds?
I tried using a convertor/picker here [14] but the colors picked bear little resemblance to those in the (faded) chart.
You could also just open the scan image in Paint or GIMP or something, and use the colour picker tool to identify an approximate colour to use. —Beleg Tâl (talk) 13:06, 24 June 2019 (UTC)
Due to a 'misunderstanding' I'm not editing on Wikipedia right now, otherwise I would have asked an appropriate project there already. Nothing to stop another contributor from doing so though. ShakespeareFan00 (talk) 13:42, 24 June 2019 (UTC)
A number of the subpages for this translation are giving rise to "fostered content" , which typically means a table has been misformatted somewhow.
Can an experienced contributor take a look and provide a generalised fix that could be applied across all the pages?
However, the SCORE extension generates a DIV block wrapping the formatted score output. Per HTML structuring conventions, you can't put a DIV inside a SPAN.
Can someone advis on how this might be repaired, or do I need to raise a Phabircator ticket like I did for a related issue with the POEM tag?
ShakespeareFan00 (talk) 13:41, 24 June 2019 (UTC)
Whilst the conventional rule is a normal SPAN may not wrap a normal DIV that is not quite what is happening here. Strictly a SPAN modified via display attribute into an inline-block is attempting to wrap a block DIV element which appears to be permissible in some browser renderings. I pose the question (as I do not know myself) if this is a legal (if rather borderline) construct. Any expert opinions? 114.78.66.8210:25, 25 June 2019 (UTC)
Prior to my subsequent updates, the 'sidetitles' overlapped the main body text, in the portion that represented the original Act. This was determined to be due to it using a version of {{cl-act-t}} which was subsequently edited considerably. Replacing it with {{cl-act-h}} and cleaning up the excessive DIV based formatting in that section solved the issue. The rest of the text could be 'standardised' though.
Thanks, it would be nice if the pages tag had a a noblanks option so the page concerned didn't need to be listed individualy in this use case.ShakespeareFan00 (talk) 13:23, 26 June 2019 (UTC)
No it doesn't. They take up zero vertical space when they are empty, but they are still transcluded. Comes in handy sometimes, for example when transcluding pages that use {{iwpage}} to pull content from another wikisource, but which have no local content that needs proofreading —Beleg Tâl (talk) 15:35, 26 June 2019 (UTC)
[SOLVED] A database error bug in Save a Gadget setting - already reported
Unchecked the Easy LST option which generated a database query error on Save. Could someone verify it? Ineuw (talk) 19:33, 26 June 2019 (UTC)
I just checked and can't reproduce. If there is a deployment underway currently then it was probably something transient related to that. --Xover (talk) 20:53, 26 June 2019 (UTC)
Uploaded this file only to find an identical file already validated in pdf format. The difference is that my upload (.djvu) came from Internet Archive, and the .pdf came from Google books. Downloaded the .pdf and replaced the Google claim with a blank page.
I would like to delete the .djvu version. Unless I am mistaken, deleting the index page does not delete the pages. How can I go about removing the pages as well? Ineuw (talk) 06:40, 30 June 2019 (UTC)
@Ineuw: So far as I know there is no special magic involved: both the index and the pages are just wiki pages that happen to be in the Index: and Page: namespaces, and are deleted just like every other wiki page. But to avoid the tedium you will probably want to enable the MassDelete tool at the bottom of the Gadgets section of your Preferences so that you can use Special:MassDelete to do them all in one batch (temporary bot flag is probably a good idea too). --Xover (talk) 06:59, 30 June 2019 (UTC)
As in converting the PDF to DJVU? I think I like the general quality of the PDF more as well. (although, MediaWiki seems to be returning images of lower-quality than what I can see in PDF.js or pdfimages.) Suzukaze-c (talk) 21:30, 1 July 2019 (UTC)
Eh, using the DJVU file format doesn't cause MediaWiki to ruin the image resolution (??????), so I took the time to assemble a new DJVU. 🤷 Suzukaze-c (talk) 04:51, 2 July 2019 (UTC)
where the vertical alignment option is moved to a table class to apply it universally doesn't.
WHY? Is Mediawiki being pedantic about where it expects to see things, as with SO many other issues, making it much more complicated than it needs to be? (sigh)
The reason for creating {{table class}} was so I did NOT need to use a multiple {{ts|vtp}} calls. But if it's not going to work properly... as evidenced here - Page:Miscellaneous Babylonian Inscriptions.djvu/79 then why should I bother trying to make things less costly in terms of parser calls etc....
The answer as to why is simple. Look at the table of parameters in the documentation for {{ts}}. "vtp" has a "no" for table, but a "yes" for row and cell. The solution is therefore logical, and I leave it to the reader to derive. Beeswaxcandle (talk) 08:17, 4 July 2019 (UTC)
This says there are misnested SMALL tags, but despite going over the alleged mistaken sequences MANY times, I can't find the mistake, Can someone please indicate precisely WHERE and WHY the relevant passages are misnested? because right next to them are nearly identical consturctionswhich DO NOT CAUSE the Linter tool to identify them as a mistake. I am getting extremely tired of running around playing hunt the minutiae, because certain tools don't provide enough SPECIFIC infrmation to actually repair a page.ShakespeareFan00 (talk) 13:44, 5 July 2019 (UTC)
My advice: don't even bother. That work is a garbage copydump and contains way more problems than linter mistakes. Don't waste your time playing whack-a-mole with a text that should be replaced wholesale instead. —Beleg Tâl (talk) 16:26, 5 July 2019 (UTC)
I did manage to repair it after a LOT of search and replace. However, as you say a properly scan-backed version would be much much better. ShakespeareFan00 (talk) 17:15, 5 July 2019 (UTC)
I have a theory about what might have gone wrong in respect of the SMALL misnesting though, see the "Pathological HTML test case" example, in my Userspace sandbox, Not that it's something LintError would directly tell you to look for :( ShakespeareFan00 (talk) 17:16, 5 July 2019 (UTC)
This for SOME reason stopped working correctly, when an update was made to the underlying module, I reverted the changes to the module, but I suspect they were made in good faith. What broke it and why?
Is there a reason why the pages tag doesn't have a layout=foo.css option?
I was looking at the markup here Equitation/Chapter 28 which does a custom layout, which to me (given that it's being applied to the whole work would be better suited as being a 'layout') or a stylesheet.
You'd probably have to ask the devs for why the proofreadpage extension is the way it is. There is also a CSS field in the Index page form which as far as I can tell does nothing at all. Using a template to apply styles to a work as a whole is a clever workaround. I don't think layouts are the right tool for this type of effort. —Beleg Tâl (talk) 22:43, 5 July 2019 (UTC)
The CSS field is supposed to apply that style in the Page namespace, iirc. But, no, it seems, essentially useless in practice. The idea in task T226275 though, might make the style effectively configurable from the Index: page. Or it might make sense to add the |layout= parameter you suggest here.The page numbers / dynamic layout stuff is a great idea, but it's not really "finished". The layouts are hardcoded inside a javascript that is unconditionally loaded from common.js. I'm trying (off and on; I keep hitting dead ends) to figure out some way to first turn it into a Gadget—so that it can be temporarily disabled by anyone working on a new version of it—and then to clean it up and refactor it. One of the first tasks in that would be to move the actual layouts out of the javascript and into separate .css files that are actually editable by anyone that knows CSS. At that point we might start running into conflicts between the dynamic layouts and a hypothetical custom style provided by ProofreadPage, but that should be manageable if define what gets used for which thing well. It's entirely possible such changes to ProofreadPage will make the local dynamic layouts mostly obsolete. --Xover (talk) 08:48, 6 July 2019 (UTC)
This apparently has a badly formed header. Can someone with the time and expertise please figure out why the header template is seemingly unable to cope with SIMPLE italics in a title, causing it throw lint errors?
I think the header template needs a complete rebuild anyway, given that a VERY large number of LintErrors I have had to fix recently are ultimately caused by very specfic minutiae of how whitespace and pairs of markup tags are dealt with. As I've said REPEATEDLY it is unreasonable to expect contributors to know these precise miniutiae every single time they might want to use a template. Is the header template sufficiently complicated that it can't actullay be made to work consistently from a contributors perspective, or converted to a Module that is better able to cope with the more unusual things contributors supply as parameters to it?
I don't see any problems in the header, though the title and section field are swapped. I don't expect contributors to know or care about lint errors either (I don't care about them myself). If the devs want us to care about lint errors, they can make tools to prevent lint errors from being introduced in the first place. — I do, however, think it would be worth revisiting the header template, aligning it with modern responsive web design principles, integrating it more heavily with Wikidata, and so forth. I do acknowledge that it would be extremely hard to preserve backwards compatibility if this were done, and backwards compatibility is extremely important given the number of "hacks" that are in place currently to get the desired display in the current structure. —Beleg Tâl (talk) 23:32, 6 July 2019 (UTC)
I care instead and I think it should be enforced and become an habit. I spent quite a lot of effort in cleaning up the backlog. "lintHint" is very quick and quite helpful (most of the times ... and except that in Page ns, page or page-preview behave differently). Immediate clean-up is N times more efficient than cleaning up afterwards. And most of the times issues are wrong nesting of tags, due to misuse of div-based vs. span-based templates. — Mpaa (talk) 20:31, 8 July 2019 (UTC)
I would only support enforcing it if the Wikisource interface were to automatically by default check every edit for lint errors and clearly display exactly what needs to be fixed, in terms any noob editor can understand. Otherwise it is completely unreasonable to expect anyone to do this. Wikisource is a steep enough learning curve already. —Beleg Tâl (talk) 20:52, 8 July 2019 (UTC)
Without making too complex, I think it would be enough to make the gadget mandatory and add a sentence at the bottom of the page in Preview mode to ask (or suggest, as there might be some hard cases to figure out, i.e. it is not mandatory but encouraged) to run it. Errors are quite well explained at mw:Help:Extension:Linter, which could also be added near the message. IMO, it is reasonable to ask at least experienced editors to chip in to maintain the work as clean as possible. Not being visible does not mean we should ignore it.— Mpaa (talk) 22:27, 8 July 2019 (UTC)
Perhaps someone with sharper eyes can figure out EXACTLY where something is misnested? (because neither LintErrrors or the LintHint script could identify precisely WHICH template call in a overly complex nested set of templates was ACTUALLY responsible). ShakespeareFan00 (talk) 18:21, 7 July 2019 (UTC)
This was an unclosed small-caps template. For future reference, an easy way to fault-find these issues, even on very large pages, is:
Copy-paste the content to a sandbox page (optional, but allows you to save "checkpoints")
Run the LintHint tool from the edited page, it should show the same errors
Remove self-contained (i.e. don't break templates) chunks of text one at a time, checking LintHint each time.
When an error disappears, the culprit was in the last block removed.
Ctrl-Z to remind yourself what the block was. If the block was very large and the error is still not obvious, subdivide the block and do it again. Saving the sandbox at this point can be helpful, as you use "Show changes" to see the diff.
This uses sidenotes, but the formatting to do them correctly and the appropriate layouts is never directly loaded because it forms part of the page numbering script used when transcluding pages with a <pages> tag. Can someone come up with a way to use them directly? or provided an alternative format for use here? {{pline}} might be what was intended. ShakespeareFan00 (talk) 09:11, 8 July 2019 (UTC)
I did a quick test, and it doesn't look right. (sigh). Rhetorical: When will the contributors with technical expertise on this project actually get around to ACTUALLY fixing the many problems I've REPEATEDLY mentioned in terms of getting core things like sidenotes, like badly nested templates &c. &c. ShakespeareFan00 (talk) 16:13, 8 July 2019 (UTC)
The image isn't actually centered despite the stylesheet saying to do the margins automatically. Suggestions before I start sending carefully worded emails with choice comments to certain contributors? ShakespeareFan00 (talk) 15:54, 8 July 2019 (UTC)
The {{img float}} template is for floating images, which are put into spans so they can be inserted without breaking paragraphs. This template has never been intended or worked really well for centred images for that reason (centring a span doesn't mean an awful lot, you have to set text-align:centre on the container, not the span). In fact, when I wrote it way back in 2010, I didn't give it a centre option. The documentation of the template suggests two alternatives, one of which is not to use a template at all, because the "raw" File: method already has a centre argument. Alternatively, specifically for centred images, {{FreedImg}} has "smarter" behaviour for resizing, etc, but there are a few quirks there too (like an automatic 94% font size). Inductiveload—talk/contribs16:18, 8 July 2019 (UTC)
The first suggested approach in the documentation DOES NOT WORK and it would be helpful if at some point it was in fact removed.ShakespeareFan00 (talk) 16:27, 8 July 2019 (UTC)
{{Img center}} is the start of an experimental image centering template, It still uses DIV's though, so can't yet be used to solve issues elsewhere, If you want to improve it feel free, currently it just passes through a File syntax option, but removes one of the borders. Needs much improvement. (sigh) ShakespeareFan00 (talk) 19:12, 8 July 2019 (UTC)
{{FI}} is not necessarily inline, which means it can't be embedded inside a SPAN or P based template, or inside a P created by transclusion, Imgcenter is yet another attempt to work around this limitations (sigh) Sometimes I wish there were more people willing to fix these problems in the backend instead.ShakespeareFan00 (talk) 22:02, 8 July 2019 (UTC)
Anyway : Category:Images using center float, That's about 1100 images using a center imgfloat, which DOES NOT WORK, Perhaps you would be willing to get started on finding a CONSISTENTLY behaving LONG-TERM fix, so as with so many other issues, the same concerns do not have to be raised REPEATEDLY here, with no credible approach emerging. I am increasingly fed up, with being told to use various work-arounds that are potentially unstable or building up future problems. Unfortunately to really resolve issues and concern like 'inlined images' would need someone to hold down a developer until they actually respond to concerns like this instead of developing even more controversial bits of wizard gadgetry for a prestige project like Wikipedia. rant rant &c.
On a related note - {{FIS}} doesn't work properly either as evidenced here -A_history_of_the_gunpowder_plot/Chapter_1 when I tried it. Unless someone comes up with a credible fix by the end of the week, I will consider just disabling or removing both templates, because they just DO NOT WORK correctly anymore.ShakespeareFan00 (talk) 22:35, 8 July 2019 (UTC)
According to the documentation for {{FIS}}, for centred images, you must ensure the width + margin-left + margin-right sums to 100%. You did not do this, so the span's cleared width is only the width of the image + padding + margins. As it is a span, it is embedded in the overall container, of course it doesn't "claim" more block-wise space. The example on the page uses percentages: 30% + 35% + 35% = 100%. You used px, so it's impossible get 100% width with hardcoded values (as 100% could be any number of px). You could do it with CSS calc() function, if it is acceptable WRT browser support (Chrome 26, Firefox 16, IE 9, Safari 7). This works for me:
I'd appreciate input as to the acceptability of this, is there a minimum browser version targeted? Perhaps some e-readers wouldn't appreciate it? Do we care? If so, it could be useful to allow the template to apply a default margin-left/-right of calc((100% - imgWidth) / 2), as this avoids the template caller having to do this.
I do not think issuing an ultimatum threatening to disable/remove a template used by something like 16000 pages is constructive. Moreover, these templates have (relatively complete) documentation, even if they clearly have some issues. If you have beef with the docs, might I also suggest that theydosaythatcharitybeginsathome? Inductiveload—talk/contribs07:26, 9 July 2019 (UTC)
And thank you taking the time to respond with the above suggestion regarding calc. I would agree with the auto option for the margin handling as it does exactly what was intended. [[15]] looks EXACTLY as intended now. ShakespeareFan00 (talk) 08:11, 9 July 2019 (UTC)
Glad it's working.
Be careful with the word "auto": in CSS it has a different meaning, which doesn't really make sense for inline elements (even with display:inline-block). The current {{FIS}} does actually use auto for margin-left and -right. This doesn't work as it does with {{FI}} because it produces this:
This only works for width=100% because there is no space on the floated line for anything else. As soon as width is less than 100%, you'll find the cSpan1 span only has whatever width you give it and no margins. This allows other elements on the floated line, or the embedding container, to creep up next to the image.
It seems in some instances Mediawiki or other Wikisourced templates may already be using CSS3 type features.. Examine the HTML generated for the poem in [[16]] for example? ShakespeareFan00 (talk) 14:07, 9 July 2019 (UTC)
Enough is enough: WHERE is the mistake? i.e where the's flipped formatting?
According to the LintErrors page there's a flipped over DIV SPAN combination SOMEWHERE in a transcluded page for this Nicholas_Nickleby/Chapter_24, however, I've run ALL the relevant pages through the Lint hint script INDIVIDUALLY and it did NOT find a concern on ANY of the transcluded pages. So can someone PLEASE indicate EXACTLY WHERE LintErrors is deciding to be pedantic before I send a very strongly worded e-mail to the maintainers of the Linter tool about it's increasingly frustratingly INACCURATE false-detections ? ShakespeareFan00 (talk) 23:38, 8 July 2019 (UTC)
<divstyle="display:table; position:relative; margin:0 auto; width:auto;"><spanstyle="font-size: 83%;"><divclass="poem"><p>Sing, God of Love, and tell me in what dearth <br/>
Thrice-gifted <spanstyle="font-variant:small-caps">Snevellicci</span> came on earth, <br/>
To thrill us with her smile, her tear, her eye, <br/>
Sing, God of Love, and tell me quickly why.
</p></div></span></div>
Thank you, I'm very suprised that when I checked that page, the checker script didn't find it initially. Is this something that a localised script could check for and repair automatically, as the repair looks straightforward. @Mpaa:. ShakespeareFan00 (talk) 07:58, 9 July 2019 (UTC)
I don't know about an automated repair tool, as wikitext is notoriously tricky to parse, but finding lint failures in some unknown subpage is easy with Pywikibot:
This won't find lint errors that manifest only when the pages are transcluded together, but it would presumably have found this one. Hope it helps, Inductiveload—talk/contribs10:49, 9 July 2019 (UTC)
Thanks, I am not in the best position to ask, but would you also be willing to mention the pywikibot angle in the phab ticket at https://phabricator.wikimedia.org/T226400 ? If this check could be an additional "check transcluded pages" button available from Special:LintErrors it would be a rather useful addition. ShakespeareFan00 (talk) 14:05, 9 July 2019 (UTC)
They are also very quickly spotted if you use certain fonts as the edit-box font. (I use Bedstead (which is based on a teletext font precisely because it's very easy to spot obviously different things like ligatures. ShakespeareFan00 (talk) 15:19, 9 July 2019 (UTC)
Hi people! Is ok to use these books by Santos-Dumont on their respective language Wikisources (English, French and German)? All the archives are from before 1920s and I remember to saw the French one on the fr.Wikisource sometime ago but I couldn't find now. Thanks, Erick Soares3 (talk) 15:23, 9 July 2019 (UTC)
@Erick Soares3: All works published anywhere in the world before 1924 are in the public domain in the US (95 years after publication). In Brazil, the term of protection is 70 years after the death of the author (pma. 70). Works by Santos-Dumont thus entered the public domain in Brazil in 2003. That means the scans can be hosted on Commons, and the English language works can be transcribed on English Wikisource. I am not familiar with the policies on frWS and deWS, but I would be very surprised if they were stricter than Commons. They may however have other restrictions (taking into account the jurisdiction of the transcriber, say) that affect the issue, so the only way to be sure is to ask on their respective Scriptoriums. --Xover (talk) 16:10, 9 July 2019 (UTC)
@Nizolan: Thanks! The German version was translated by Ludwig Holthof that I can't find any biographical information, but seeing that his works date from late 19th early 20th century I think that is easy to assume that are PD. Erick Soares3 (talk) 17:49, 10 July 2019 (UTC)
I'm not entirely convinced calling lots of float rights is the best approach? Is there a way to combine the functionality here into a single template or indeed a stylesheet that could be universally applied per page? This works, so hardly a priority. ShakespeareFan00 (talk) 22:50, 9 July 2019 (UTC)
The postulate titles are floated right, so {{float right}} is exactly the best possible approach. You could use {{rbstagedir}} to apply the other formatting along with the floats if desired. However, if by "single template" you are thinking of creating some sort of {{eeusc-header-fl-r}} type monstrosity, please don't. It can do no better than the current solution, and it will be vastly more difficult to maintain. As for stylesheets, this should be accomplished by modifying {{float right}} rather than creating an alternative template whose only difference is that it uses classes instead of inline styles. —Beleg Tâl (talk) 12:19, 10 July 2019 (UTC)
(Aside) Float-right is SPAN based, which may be the reason a number of misnesting errors are being identified in other works. Block based content should not use a float-right in it's current form. Not sure how in some instances this would be fixed without having to do some pusedo-P hacks, to allow a DIV based float, but hiding the paragraph breaks, which I am very unwilling to do for maintenance reasons. —unsigned comment byShakespeareFan00 (talk) .
I didn't notice it is span based. We should create a separate template for block elements (maybe modify {{block right}}?). In the case of the Elements however, the floated content is inline so {{float right}} is fine. —Beleg Tâl (talk) 14:38, 10 July 2019 (UTC)
There's also the issue of precisely where Mediawiki decides to "tidy", or end paragraphs which seems to be a dark art to decipher at times. this is despite REPEATED requests for someone to actually sit down and FORMALLY document what it's SUPPOSED to do.ShakespeareFan00 (talk) 16:14, 10 July 2019 (UTC)
CharInsert no longer displays the User defined row
Every page opened for editing I must re-select the "User" defined row of characters. I tried working with the "Special characters" built into the Toolbar, but this lacks ligatures among other things. Is there anything can be done to fix the Charinsert.Ineuw (talk) 08:13, 10 July 2019 (UTC)
@Beeswaxcandle: Are you saying that your "User" Charinsert selection shows up automatically when you open a page for edit? Also, please clarify "no toolbar (since they stole it), and FF 67)". To emulate your setup I witched everything to Monobook (from Vectra).
Logged out from WS and deleted the en.wikisource cookie from FF 67.0.4.
Logged back, and in the Page namespace I edited a page.
Set Charinsert to "User", and saved the edited page.
In preferences, editing tab, I have "Enable the editing toolbar" off. I loathe this one and manage without it. The only thing I can't do is initiate OCR of a page. Beeswaxcandle (talk) 05:54, 11 July 2019 (UTC)
Can Poem not appear inside a REF tag?
Because I can't find another reason why King_Solomon's_Mines/Chapter_XVI should be giving a DIV SPAN swap warning. Yet sometimes in other works this behaviour works, and sometimes it doesn't (Sigh!)
Examining one of the poem based references : here :
<olclass="references"><liid="cite_note-1"><spanclass="mw-cite-backlink"><ahref="#cite_ref-1"aria-label="Jump up"title="Jump up">↑</a></span><spanclass="reference-text"><divclass="poem"><p><spanstyle="float:left; text-align:right; margin-left:-moz-calc(0em - 3em); margin-left:calc(0em - 3em); width:3em;">"</span>Now haste ye, my handmaidens, haste and see<br>
How he sits there and glowers with his head on his knee."
</p></div></span></li></ol>
Which is very obviously malformed HTML. You clearly can't put a DIV in a SPAN. As this is the behaviour of Extension:Cite itself, this isn't going to be a problem that can be solved easily, given that for it to work, what Extension: Cite actually generates will need updating. Extension:Cite however is a fairly core template... (worried look). I'm also suprised no-one noticed this previously. ShakespeareFan00 (talk) 16:44, 10 July 2019 (UTC)
Looks like it has been noticed previously, (phab:T49544 "<references/> list item must not wrap the text in <span>"), but some kind of server error is preventing me from seeing the content of that ticket. —Beleg Tâl (talk) 16:56, 10 July 2019 (UTC)
I hope by "do something drastic" you mean "create lots of tickets at Phabricator" because that would very likely be the best solution for parser-level issues like this. —Beleg Tâl (talk) 16:59, 10 July 2019 (UTC)
I am not using HTML but have no problem creating tables and poems within <ref></ref> tags with our templates.Ineuw (talk) 20:32, 10 July 2019 (UTC)
You're missing the point a little bit. The Cite extension will absolutely allow you to create tables and poems within ref tags, but every time you do this the Cite extension will generate malformed HTML regardless of what markup you use. —Beleg Tâl (talk) 21:01, 10 July 2019 (UTC)
If you've used ref tags, you've used the Cite extension. The Cite extension is what provides us with the ref tag, the references tag, and probably a couple of other things. —Beleg Tâl (talk) 23:18, 10 July 2019 (UTC)
China Review scans from HKU
HKU has uploaded scans of the articles from the 25 volumes of The China Review (1872–1901), all of which should be PD. Unfortunately they only include the articles and not the frontmatter and other non-article pages of the journal volumes/numbers (notably there's no scan of the ToC). Are these OK to upload article by article? The alternatives aren't much: IA has a couple of issues of CR but not more than that; HathiTrust seem to have scans of the whole thing but their nutty copyright policy—they view anything after 1879 as copyrighted by default and allow only pdfs of individual pages to be accessed, and from the US only—makes it technically difficult to transfer them. —Nizolan (talk) 18:57, 10 July 2019 (UTC)
HathiTrust only treats everything after 1879 as copyrighted because you're outside the US; as a general rule, everything before 1924 is free on HathiTrust. Their agreement with Google means you can't download the whole PDF of Google-scanned files (most of them), but they don't make any serious effort to stop people for downloading them page by page. I can do it for any work you need.--Prosfilaes (talk) 07:16, 11 July 2019 (UTC)
@Prosfilaes: I figured, my complaint was more that, afaik, there's nowhere in the world that has a "publication + 140 years" law so it's a pointlessly overrestrictive policy on their part. The articles I'm interested in at the moment are pre-1879 so I should be able to get the volumes from Google for now, but I might take you up on the offer in the future, thanks. —Nizolan (talk) 12:37, 11 July 2019 (UTC)
In 2010, the earliest known work under copyright in the UK was from 1859. In 2011, it was from 1865.[17] So if one wants to be absolutely correct about life+70 law, publication + 151 years is necessary. For a major author, Author:Bertrand Russell's first work will be 145 years old when his works leave copyright in life+70 countries. Restricting, but not pointlessly overrestrictive.--Prosfilaes (talk) 22:52, 11 July 2019 (UTC)
Sometimes Mediawiki makes me want to scream...
Page:The_Church,_by_John_Huss.pdf/353, A misnesting glitch is PURELY down to whitespace handling such as occurs at the end of a page between the text and the footer. And this means what should be a paired opening and closing SPAN {{hin/s}} (in the body) and {{hin/e}} (in the footer), are incorrectly tidied up, making what was supposed to be an intended template USELESS in one of it's intended use cases, and causing unecessary Linter warnings Or am I not seeing an obvious repair?
ShakespeareFan00 (talk) 21:38, 10 July 2019 (UTC)
If the transcluded output renders correctly, I would not consider the template useless. Does MediaWiki always generate lint errors if a span is split this way? If so, this is a bug and the devs have to fix it, because open/close span templates are not going anywhere. —Beleg Tâl (talk) 23:31, 10 July 2019 (UTC)
I'm not sure it transcludes nicely, and I couldn't see any obvious errors in the direct HTML view in the browser. I think Linter MIGHT be misdetecting this very specfic use case... ShakespeareFan00 (talk) 00:30, 11 July 2019 (UTC)
Page edit problems
The Page header appears below the textbox on top of the footer see display.
Also, the OCR button (activated in Gadgets) is frozen, although the "Site: General utilities needed by the templates and portals of this wiki project." is active.Ineuw (talk) 21:32, 10 July 2019 (UTC)
I tested these in both Windows 10 and Linux Mint 19.1 in Firefox 68 and the latest stable Vivaldi.Ineuw (talk) 21:32, 10 July 2019 (UTC)
Works for me, Windows 10 v1903, Firefox 68 and latest stable Vivaldi. I assume you've tested it while logged out? —Beleg Tâl (talk) 23:38, 10 July 2019 (UTC)
@Beleg Tâl: My software is identical to yours but again the same, . . . the OCR stopped working and the header position is again at the bottom. When logged out, the page layout is fixed, but cannot test the OCR (but I am sure it's good). Cleared all cookies. Logged in and after two pages the problem returned. I am convinced that it is the software, because as I said earlier it is the same in Vivaldi as well. Any ideas? Ineuw (talk) 07:37, 11 July 2019 (UTC)
@Ineuw: Do you have any messages in the Javascript Console? Have you tried blanking your user scripts to check whether something in there is affecting this? There was a new Mediawiki release deployed yesterday. I don't see anything obviously related, but in the interaction between changes to Mediawiki and custom user CSS and JS there is a lot of potential for stuff to break. --Xover (talk) 11:11, 11 July 2019 (UTC)
@Xover:, That's the one thing I forgot, because I use it very rarely. Thanks for the reminder. As for my custom scripts, I will remove and re-install them one by one.Ineuw (talk) 20:01, 11 July 2019 (UTC)
┌─────────────────────────────────┘ @Xover: Tracked down the source of the error. It is the pathoschild family of scripts. Emptied vector.js and .css, Then restored the .css and everything was fine. Then, one by one, I added the scripts until the errors popped up. This was when I added the first script pointing to pathoschild tools on wmflabs in the vector.js
A maximum of 6 errors (below) showed up when opened a Page for editing. Otherwise, 3-4 various "Content Security Policy" errors everywhere always, with numerous warnings about outdated load.php issues. Should I file a bug report?Ineuw (talk) 02:54, 12 July 2019 (UTC)
Content Security Policy: The page’s settings observed the loading of a resource at https://tools-static.wmflabs.org/meta/scripts/pathoschild.templatescript.js (“script-src”). A CSP report is being sent.
Content Security Policy: The page’s settings observed the loading of a resource at https://tools-static.wmflabs.org/meta/scripts/pathoschild.templatescript.js (“script-src”). A CSP report is being sent.
Content Security Policy: The page’s settings observed the loading of a resource at https://tools-static.wmflabs.org/meta/scripts/pathoschild.util.js (“script-src”). A CSP report is being sent.
Content Security Policy: The page’s settings observed the loading of a resource at https://tools-static.wmflabs.org/meta/scripts/pathoschild.regexeditor.js (“script-src”). A CSP report is being sent.
ReferenceError: hookEvent is not defined index.php:390:1
Content Security Policy: The page’s settings observed the loading of a resource at blob:https://en.wikisource.org/df413324-e851-40c8-abc0-28ebe15755c9 (“script-src”). A CSP report is being sent.
@Ineuw: Hmm. The CSP messages can be ignored: they're output for everything hosted on wmflabs.org and it's just reporting.The remaining message, though, is a genuine symptom of an error somewhere. .hookEvent() is a function for attaching multiple event handlers at once that was provided by the old "wikibits.js" library that has been slowly being phased out since before the introduction of ResourceLoader. .hookEvent() in particular, was deprecated in MediaWiki 1.17 (released in 2011) and removed in MediaWiki 1.29 (released in 2016). It seems unlikely that the new MediaWiki version deployed on Wednesday (1.34/wmf.13) would have made any change that affected that one way or another. I also copied your vector.js and failed to reproduce both the header positioning issue and the error message in the console, so the browser would seem to be one factor playing into it. I tested in Safari and Firefox, and neither had the header positioning issue; but Firefox did point to some potential issues in your personal copy of the nop-inserter script (don't we have a Gadget for that now?).I don't think we have the source of the problem pinpointed enough to make a good bug report yet, so I'll keep poking around to see if I can find anything else useful. You might want to try tacking &debug=1 onto the end of the URL on a page where you see the problem: it tells MediaWiki to send you each javascript separately instead of bundled together through ResourceLoader, so error messages in the console will give you a better chance of tracking down exactly which line in which script is triggering the error. --Xover (talk) 07:18, 12 July 2019 (UTC)
Your help and advice is much appreciated. My copy of the nop-inserter.js highlights the page navigation arrow in green (for a few seconds) to indicate success. The general nop-inserter in Gadgets flashes a message. Both of these options exist in the public Gadget but the community preference was for the message and I was used to the colour highlight. PS. will post the results of &debug=1.Ineuw (talk) 07:33, 12 July 2019 (UTC)
Documentation markers for charcter(SPAN) vs paragraph(block) based templates..?
I'd like these to categorise the parent template they are on into an appropriate category, but not the Doc page they appear in?
@ShakespeareFan00: You might try putting your templates on the /doc page but inside <onlyinclude>{{div-based-template}}</onlyinclude>. The /doc page is transcluded onto the parent template page, but wrapped inside <noinclude>…</noinclude>. The net result ought to be that the template has no effect on the /doc page (onlyinclude); spits out its contents (i.e. the category) on the parent template page; but won't affect whatever other page where the parent template gets transcluded (noinclude). However, this will affect both the category and the visual output, so it might be better then to simply add the category to the doc page directly. --Xover (talk) 11:05, 11 July 2019 (UTC)
@ShakespeareFan00:I know that this is an old post but we were discussing the {{FIS}} template further on, perhaps you want to look at the change I made in the page mentioned above.
I am having an issue in which the OCR button on the toolbar isn't working. I encountered this when I was proofreading Index:A History of Wood-Engraving.djvu. For some reason, it worked fine for the first few pages with text, but after that, it simply refused to generate a text layer for the other pages despite the words being clearly readable. Is there a fix for this? DraconicDark (talk) 14:32, 11 July 2019 (UTC)
[CC: Ineuw] @DraconicDark: I just checked in Safari and the old OCR button is non-functional there too. Checking the javascript console it is throwing an error:
[Error] Error: Syntax error, unrecognized expression: An error occurred during ocr processing: /tmp/52004_20706/page_0011.tif
error (load.php:20:880)
select (load.php:37:233)
find (load.php:41:184)
init (load.php:142:753)
jQuery (load.php:2:505)
hocr_callback (Script Element 1:594:825)
fire (load.php:45:980)
fireWith (load.php:47:174)
done (load.php:126:628)
(anonymous function) (load.php:130)
This indicates a server-side problem: the phetools hOCR tool is returning an error message and the local javascript here that is calling it is choking on the error.The Google Vision-based OCR tool that you can enable in your preferences ("Development (in beta)" section) seems too work though, and is a decent workaround. --Xover (talk) 15:35, 11 July 2019 (UTC)
Rant part 5 (Scoring points...)
Page:How to Write Music.djvu/21
Here a {{float box}} is used to wrap the scoring elements, which would work if the Score tag provided span-based output. It currently provides a DIV based output (not unexpectedly) which means that in this page malformed HTML get's generated. I'm starting to wonder if many of the common floats and shoulders Wikisource contributors use, should really instead be local classes in the core Mediawiki styling for the site, like certain of the table classes I've authored recently.ShakespeareFan00 (talk) 18:51, 11 July 2019 (UTC)
@ShakespeareFan00:, Try {{FI}} instead of {{FIS}}? Remove the "S" from FIS and try it again. FI was written first, but it could not float, So, FIS was created with <span></span> instead of <div></div>.Ineuw (talk) 20:11, 11 July 2019 (UTC)
I've checked, in the equivalent documentation for {{FI}} which I suspect is the same documentation as {{FIS}} although written previously, the score example works without generating the warning. Next question would be how to put a simple score (typically a short extract) inline (which might need yet another Phabricator ticket...) There's an open ticket on Phabricator about converting lillypond to MusicXML but any kind of support for doing that is still in the very early stages of development..ShakespeareFan00 (talk) 20:18, 11 July 2019 (UTC)
For that you'll need to identify a text which has a short extract inline, such that this feature would be necessary for proofreading that text correctly. —Beleg Tâl (talk) 20:48, 11 July 2019 (UTC)
[[File:PD-icon.svg|12px|alt=|link=]] This article incorporates text from a publication now in the [[w:public domain|public domain]]: <spanclass="citation encyclopaedia"><div></div><pid="DNBfooterInitials"style="clear:both; text-align:right;">[[Author:Patrick Weston Joyce|P. W. J.]]</p> (1885). [http://en.wikisource.org/wiki/Beranger,_Gabriel_(DNB00) "Beranger, Gabriel (DNB00)"]. In [[Author:Leslie Stephen|Stephen, Leslie]]. ''[[Dictionary of National Biography]]'' <b>04</b>. London: Smith, Elder & Co. p. 322.</span><spantitle="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikisource.org%3ASpecial%3AExpandTemplates&rft.atitle=Beranger%2C+Gabriel+%28DNB00%29&rft.au=%3Cdiv%3E%3C%2Fdiv%3E%3Cp+id%3D%22DNBfooterInitials%22+style%3D%22clear%3Aboth%3B+text-align%3Aright%3B%22%3EP.+W.+J.%3C%2Fp%3E&rft.aulast=%3Cdiv%3E%3C%2Fdiv%3E%3Cp+id%3D%22DNBfooterInitials%22+style%3D%22clear%3Aboth%3B+text-align%3Aright%3B%22%3EP.+W.+J.%3C%2Fp%3E&rft.btitle=Dictionary+of+National+Biography&rft.date=1885&rft.genre=bookitem&rft.pages=322&rft.place=London&rft.pub=Smith%2C+Elder+%26+Co&rft.volume=04&rft_id=http%3A%2F%2Fen.wikisource.org%2Fwiki%2FBeranger%2C_Gabriel_%28DNB00%29&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook"class="Z3988"><spanstyle="display:none;"> </span></span>
Create a template named Template:SF00, copy and correct the original template's error. Then, use it as a test template on pages which are linked to the original. If the test template works well everywhere, then open a discussion in the Proposals section of the Scriptorium. Ineuw (talk) 01:20, 12 July 2019 (UTC)
And it's that the DNB author initials {{DNB PWJ}} aren't a PURE span, they have code that generates the DIV. Is there an alternative template that should have been used?ShakespeareFan00 (talk) 15:22, 13 July 2019 (UTC)
The float left item should be centered, I thought setting a style would do this, but text-align seems to be inapplicable to spans? ShakespeareFan00 (talk) 11:40, 12 July 2019 (UTC)
Also note to other contributors, typically style= when supplied to a template doesn't have wrapping quotes like it would when being supplied directly to an HTML tag..ShakespeareFan00 (talk) 11:55, 12 July 2019 (UTC)
Rant Part 8 ( A Table of concerns...)
I cannot seem to find a way to generate this row without a warning about fostered content or the resultant transclusion being incorrect.
As we other issues, I've REPEATEDLY said the way to PROPERLY solve this is to have a table syntax that supports proper continuations, but despite raising concerns there's been no further action taken on finding a STABLE long term solution. (sigh) ShakespeareFan00 (talk) 14:32, 13 July 2019 (UTC)
@ShakespeareFan00: Instead of complaining, ask for help, or take the initiative to read the history of the template. Template:Markup/row was originally imported from WP. So I replaced our version with the latest WP copy. At first glance, they look the same. Please try it because I don't know what it is for.Ineuw (talk) 01:09, 14 July 2019 (UTC)
Despite there being no whitespace (other than line feeds, Mediawiki seems unable to handle multiline content that's supplied to a SPAN based template in a clean way... Collapsing the whitespace made the error go away, but the parser should be much more robust than that? I thought I'd ask here if there is another less drastic way of doing this as opposed to collapsing ALL whitespace because Linter (if not the parser) seems to throw a fit, if it doesn't see exactly what it expects... ShakespeareFan00 (talk) 15:55, 13 July 2019 (UTC)
In the Page edit mode the sidebar TemplateScript/proofreading.js link in the "gear" icon (on right of the 'Page tools' title) is broken. Can someone fix this link and check if the contents of that page are still relevant? Ineuw (talk) 20:36, 13 July 2019 (UTC)
Rant part 10 ( Something that really SHOULDN'T have worked.)
I'm head-scratching... Something I did here worked... And it shouldn't have, as I understood the layout model concerned :(
Perhaps another very experienced contributor can review what's going on here so I know why it worked when it did not previously? It would be nice to generalise this down a bit so it can be used elsewhere. I have a nasty feeling it's not stable though :( ShakespeareFan00 (talk) 23:02, 13 July 2019 (UTC)ShakespeareFan00 (talk) 23:12, 13 July 2019 (UTC)
Why do you think this should not have worked? This is exactly the solution I suggested to you the last two times you asked for help making it work, and it worked both those times. I also updated Template:Dropinitial#Technical notes with this suggestion last time you brought it up. —Beleg Tâl (talk) 11:01, 14 July 2019 (UTC)
Thanks, The tweak in this particular instance was to adjust the margins by the width, and to use the DIV based version of float-left, which I did not know existed.
And I said it wasn't stable, but looking at User:ShakespeareFan00/sandbox ( fourth heading) , thanks to some template logic I wrote a while back, I've got the shift when it's transcluded. Next step would be the logic in a template like {{lrpaged}} to read the page number in mainspace and then I don't have to worry about left or right anymore. :)
This was leaking a SPAN, I've re done the logic in a sandbox and would appreciate someone else reviewing the code and the testcases before it's hopefully swapped in? ShakespeareFan00 (talk) 16:24, 14 July 2019 (UTC)
@ShakespeareFan00: I took a look and found even your improved version needlessly complicated. I took a stab at simplifying while guaranteeing valid output, and as best I can tell it works as intended now. If you agree then feel free to update the live template. --Xover (talk) 08:30, 15 July 2019 (UTC)
In the original the wraping lang in the span is only applied if parameter en is supplied. In your version it was supplied regardless, which is not the original logic as I understand it. Resolved this in the sandbox and swapped it in. ShakespeareFan00 (talk) 08:50, 15 July 2019 (UTC)
Here each line of the quote is precceded by a ` to mark each line of the quote.
My thought was that this could be styled to insert this with a CSS rule, but no such selector for the start of line exists.
Also some discussions on the #css IRC channel at freenode indicated that it could not currently be done in purely CSS, however
a contributor there suggested a Javascript method might work. Would such an approach be feasible, or for simplicity do we just drop this archaic formatting? ShakespeareFan00 (talk) 20:21, 14 July 2019 (UTC)
I'm going to say that this is not something we reasonably can reproduce, nor something we should reproduce. Granted it sometimes obliges us to find an alternate formatting to convey the same information, but that's not usually been a big problem in my experience. We have all the usual typographic conventions at our disposal, including things like indentation and margins. The important factors are that it is clear and understandable for our readers, and that it reproduces the meaning of the original formatting (not its mere visual instantiation). --Xover (talk) 07:14, 15 July 2019 (UTC)
The "traditional" solution to this situation is to enclose the quoted section within <blockquote></blockquote> tags. Granted, the representation looks nothing like the running-left-quotes and maybe never will but at least the semantic structure is captured and for now that has always been regarded as "good enough." 114.78.171.14407:38, 15 July 2019 (UTC)
Not only is not something we can "reasonably" reproduce, it's not something we should reproduce. Typesetters of printed works that use the device know what the line length will be on every page of their book and can insert the appropriate slug as required. Given we are reproducing works in a non-printed medium for multiple devices that use many different line lengths, the benefit of doing the work to make it behave is minimal (particularly as the situation where a quoted section goes across page breaks will be particularly messy to deal with in Javascript). The nearest equivalent in modern typography is to block indent the text and place a grey bar on the left margin. The suggestion of the IP to use blockquote tags is pretty close and there is a family of templates ({{quote}}) that allow for such that go over pages. I would expect each paragraph within the blockquote to begin with a quote mark and the final paragraph to terminate with one (as per long-established practice) even though they are set off. Beeswaxcandle (talk) 09:32, 15 July 2019 (UTC)
Hi all. I am just starting out using AWB on US Statutes at Large Vol. 33, Parts 1 and 2. I've successfully done some very simple search/replace of obsolete template calls, but now - no doubt preparing to trip for the first time over my new and exciting AWB shoelaces, I am being more ambitious! I would love to be able to insert the necessary elements for USStatHeader in the several hundred pages of these two documents. My problem is my ignorance of regex - I thought I could search for <noinclude>*</noinclude> to replace it with my USStatHeader string, but no dice. It then occurred to me that I need a text-layer means of differentiating between header and footer, anyway, which my initial approach would have failed to achieve. Is what I am trying to do possible? If there are any AWB wizards out there, if it's possible to use a search/replace control file whereby for a given page file name, it pastes the next (perfectly formed) line of wikitext from the input file into the header, that would be AWESOME. Thanks, and apologies if this is all an achingly basic question. CharlesSpencer (talk) 11:52, 16 July 2019 (UTC)
An empty header generally takes the form <noinclude><pagequality level="0" user="Beleg Tâl" /></noinclude>. I generally find it helpful to use https://regexr.com/ to build and test regexes that I will use in AWB. The CSVLoader plugin should be able to handle your search/replace control file requirement; see w:Wikipedia:CSVLoader/Find and replace for details. —Beleg Tâl (talk) 12:16, 16 July 2019 (UTC)
I found the answer... {{*}} embarrassed to admit I asked the question over a year ago. And had forgotten the answer. Klarm768 (talk) 10:57, 19 July 2019 (UTC)
Surprised by the structure of a URL and a blue link leading nowhere—is there something wrong?
Both pages said:
Wikisource does not have a text with this exact name
Also on Wikisource, clicking the link on the page of The Chaos/De Chaos resulted in the same message in a language from the Netherlands (nl), I trhink. So I opened https://nl.wikipedia.org/wiki/The_Chaos and a search for "Ruize" returned no instances. Google Translate could not translate that term. I don't edit on Wikisource much at all, so I was surprised by the structure of the URL and by a blue link that leads nowhere. There may be absolutely no issue here, but in case there is... Hey! Here's what I found odd!
All I can do is post here and probably not come back due to real-life limitations. I edit en.WP (including technical documentation), en.WT, en.C and occasionally other languages and projects. I mention my WM CV so you can maybe garner from this what an experienced editor might find odd on WS, but I did not check for an existing WS for WP editors page, like the one on WT. There's my data dump! Thanks in advance, Geekdiva (talk) 15:12, 19 July 2019 (UTC)
The book nl:Ruize-rijmen has not yet been added to Dutch Wikisource, which is why it says (in Dutch) that this work does not exist.
The poem Ruize-rijmen/De Chaos is written in English, which is why this particular page is on English Wikisource instead of Dutch Wikisource.
The book nl:Ruize-rijmen is not in English, so the rest of the book should not be added to English Wikisource. This is why it says "Wikisource does not have a text with this exact name" when you go to en:Ruize-rijmen.
Finally, and this is the real issue: wikilinks that point to other wikis (including Dutch Wikisource) are always blue, even if the page does not exist on the other wiki. Links to nl:Ruize-rijmen are essentially redlinks, but they appear blue because nl:Ruize-rijmen is on a different wikisource.
And here I've found another problem, namely Template:Sn-year/sandbox that it seems to be next to impossible to actually emulate what the page numbering script is creating (in respect of dynamic layouts to fake the structure sufficiently to allow for testing of layouts in other than mainspace from a direct transclusion.
It would of course be nice if for once, someone actually sat down (independently of content work) and implemented a PROPER and FULLY DOCUMENTED explanation of what certain core Wikisource functionality ACTUALLY does, so that templates like {{sn-year}} and {{Fake layout}} can be implemented in a logical, consistent and reproducible way, and be used for thier intended purpose, but given the time available to a volunteer project like this, I don't see that happening with any priority. Instead there are various work-arounds, hacks and 'too clever by half' approaches, that aren't stable (including some I've written). This is NOT an approach sustainable in the long-term, in terms of maintainability.ShakespeareFan00 (talk) 23:26, 19 July 2019 (UTC)
In OAW vol 1 page 36 and OAW vol 8 page 433, lilypond is generating scores that are much wider than the rest of the layout: this magazine looks best if fixed-width elements are no wider than 600px, preferably 500px. Page 433 could be improved by breaking the score into three lines; is there a way to do that? The same could be done on page 36, or the lines could be horizontally compressed (there is no reason the notes have to be spaced out that much). Levana Taylor (talk) 23:44, 21 July 2019 (UTC)
@Levana Taylor: Poking around like a bull in a china shop, but I did take a stab. Maybe some further tweaking will get you the result you're after? As best I can tell there is no way to make the Score extension generate images of a given web-ish dimension, much less dynamically size them relative to the browser or web page. It is possible something can be achieved by wrapping the score tags in a template that imposes some sizing: it'd be hacky and inconvenient, but might actually work. If this is an issue you run into often then feel free to give me a ping and I'll look into it. --Xover (talk) 21:57, 22 July 2019 (UTC)
When I read the Lilypond manual and didn't see any way of forcing the lines to break, I thought I must have overlooked it, but if you didn't find it either, it must not be there. Your method of globally reducing the size of the output works, though. It forces the user to choose between long lines or else tiny font size for the lyrics. I think the best compromise is "line-width = 130\mm #(layout-set-staff-size 13" which fits inside 600px (although 120/12 fits into 500px, it's ridiculously tiny). Thanks! Levana Taylor (talk) 01:08, 23 July 2019 (UTC)
@Slugger O'Toole: Step one is to upload it to Commons. I'll do that now for you. Step two is to make an index. Step three is to start transcribing. (Easier said than done.) Have you read Help:Adding texts yet? Do you have questions about that guide? —Justin (koavf)❤T☮C☺M☯00:29, 23 July 2019 (UTC)
Thanks, Justin. I had not read that help page. I was looking at what I presume to be an older page and was a bit daunted. I have created the index page. I guess the next step is to proofread. Seems like it will take some time. I'd appreciate the help, if you're inclined to give it. If not, thanks for getting me this far! --Slugger O'Toole (talk) 02:55, 23 July 2019 (UTC)
@Slugger O'Toole: It seems that the original OCR layer is quite bad and unfortunately our OCR button has stopped working for some reason a short time ago. So I recommend you to enable Google OCR button in your Preferences/Gadgets. --Jan Kameníček (talk) 07:36, 23 July 2019 (UTC)
Page numbering to the left with {{page break}} or {{pagebreak2}} is NOT compatible with {{block center}}.It would be NICE if someone eventually sat down and rewrote certain templates so that they have reliably predictable behavior regardless of where they are ACTUALLY used.
I am generally not happy taking out templates others have placed, but as I trust your technical expertise, I'll mention your above comment if someone queries my removal of 'incompatible' templates. ShakespeareFan00 (talk) 09:05, 21 July 2019 (UTC)
You and others, have previously suggested that before making certain types of changes, that I SHOULD consult more. If I don't ask about concerns when I can't find an obvious solution, then what do you suggest? You seem to be saying you would prefer a more neutral 'technical' request, in comparison to the percived venting that's sometimes happened. ShakespeareFan00 (talk) 09:30, 21 July 2019 (UTC)
In respect of the actual concern with the template "incompatibility" https://petscan.wmflabs.org/?psid=10179664 which is about 170 pages to check (most of which do not need any changes so possibly more like about 40-50 pages that need updating), any volunteers? ( the temporary solution is to convert |left to |hide.). A longer term re-design of the templates mentioned would be appreciated,
A technical question arises, how does the PageNumber.js script get to get the page numbering to the side of the page consistently (I am wondering if it's a very specfic form of classing or style? Because if there was a way to arbitrarily call that code directly from mainspace, Could it be utilised by setting the relevant class and idents in {{Page break}} to get the desirable behaviour (of consistently left hand aligned page numbers)? I've not as far as I know had issues with block centered content and page numbers (generated) from a transcluded work vs trying to do it directly in Mainspace with {{page break}} As you are more familiar with the scripting code concerned, would it be possible to implement a way of calling it arbitrarily? ShakespeareFan00 (talk) 12:21, 21 July 2019 (UTC)
In PageNumber.js, all page numbers are listed before any of the text content, and each page number is manually positioned by the algorithm based on the calculated location of the transcluded content within the browser window. —Beleg Tâl (talk) 17:21, 21 July 2019 (UTC)
And is there any reason why that approach could not be used directly in mainspace? using Page break or Page break 2 to insert markers read by an algorithm? ShakespeareFan00 (talk) 14:00, 24 July 2019 (UTC)
I don't think it makes sense to use {{page break}} to simulate PageNumber.js on non-scan-backed works, and I would support removing all instances where it is used in this way. —Beleg Tâl (talk) 17:21, 21 July 2019 (UTC)
@Erick Soares3: I took a stab at the ToC: here and here. Note in particular that I changed from roman to arabic numerals in the chapter subpage names. Looking quickly at the "List of images" it looks like the same approach would work there. There are, of course, also other ways to go about it, so please do not feel obliged to keep my changes if you prefer a different approach. --Xover (talk) 21:23, 22 July 2019 (UTC)
@Xover: Thanks! But I saw that something went wrong between page 11 and 12 (see My Airships). Have any idea? I will see what to do in the "List of images" - I'm still learning all that part of Wiki code. Erick Soares3 (talk) 21:34, 22 July 2019 (UTC)
@Erick Soares3: My apologies. It was that darn magic mystical {{nop}} that needs to be inserted in oftentimes seemingly random places. When we combine multiple separate pages, each containing wiki markup, into a single page with transclusion, it is always tricky getting the whitespace right for the markup where whitespace matters. For example inside a table, the "|-" that starts a new table row needs to start on a new line, but the transclusion removes the preceding newline because most of the time that page break occurs "within a sentence". The "magic nop" template forces a new line there, which makes it work. This is about the fiddliest and arcane bits of wiki syntax you will have to care about. --Xover (talk) 22:05, 22 July 2019 (UTC)
I uploaded vol. 31 of Poet Lore from HathiTrust, but then I found out that some pages were missing. HathiTrust has one more copy, which has other problems (missing index pages), but it has got the pages that are missing in the uploaded file, i. e. pages no. 328–329 and 371–374. Could someone who has got the needed software extract these pages from the other copy and add them to the uploaded file?
@Jan.Kamenicek: I don't have tools for working with PDF, but I can probably generate a new composite DjVu file for you. It'd also get a completely new text layer which I cannot guarantee is as good or better than the existing one. In my limited experience it's as good or better than the alternatives but this will depend strongly on the work in question as well as a bit on individual preference. But if those caveats are acceptable to you I can take a stab at it. --Xover (talk) 11:38, 23 July 2019 (UTC)
@Xover:I do not insist on PDF, I prefer it mostly because it is usually easier to handle for me. So if you make a DJVU composite, it will help. Thanks very much! --Jan Kameníček (talk) 11:50, 23 July 2019 (UTC)
@Jan.Kamenicek: Done: File:Poet Lore, volume 31, 1920.djvu. Please check that I didn't mess up anything with the page doctoring.I would also be very interested in your impressions of the OCR quality. Both overall; if there are specific features that are handled better or worse than expected; and whether there are particular pages where it does unexpectedly well or falls down completely. The OCR here is performed using different software than IA and that used in both the OCR button and the Google OCR button, and OCR results are to a certain degree dependent on the preprocessing of the page images (which is obviously different here), so I'm interested in such feedback to get a sense of how well my tools are doing compared to the alternatives (and it may be that there is further pre- and post-processing I can do to improve the results).No need to make a study of it, but if you happen to notice anything while working on it I'd appreciate a note on my talk page. --Xover (talk) 15:45, 24 July 2019 (UTC)
I tried using my alternate account and it was the same. Unfortunately, an unregistered user has no access to the OCR button.Ineuw (talk) 04:23, 20 July 2019 (UTC)
Emptied the vector.js and .css files and repeated the OCR action . The result is the same as with the files installed. — Ineuw (talk) 06:09, 20 July 2019 (UTC)
@Ineuw, @Jan.Kamenicek: See #OCR button not working above. This is a server-side issue with Phe's OCR tools: the javascript gadget that implements the OCR button here calls a service on the toolserver that in turn attemps to perform OCR on the page requested, and that service is choking on something in certain DjVu files and returning an error message to the javascript gadget here. Since the gadget here doesn't specifically handle that error it just gets logged in the web browser's "Javascript Console" and the script just terminates (which looks like "nothing happened" to the user).The quickest workaround is to just enable the Google OCR gadget in your preferences and use that. If it produces results that are unusable (it usually does at least almost as well as the old OCR gadget in my experience) it's also possible we can regenerate the whole DjVu file with a text layer generated by Tesseract 4 (Phe's tool uses Tesseract 3, and Google's uses the Google Vision API). It depends entirely on the work, how many pages are affected, whether original scan images are available, and so forth, whether it's worth doing the not-overwhelming but not-quite-trivial amount of work involved. For this particular work it doesn't seem obvious that regenerating the DjVu would produce any better results than the existing OCR text layer, but if you would like to test the results I'd be happy to try it. --Xover (talk) 09:04, 20 July 2019 (UTC)
I am not experiencing the problem with a .djvu, but with a .pdf file. It has got an OCR layer, which is unfortunately quite bad, and so are the results with the Google gadget :-( I hope the OCR button will be repaired soon... --Jan Kameníček (talk) 16:40, 20 July 2019 (UTC)
I just checked and it's the same error, so whatever the issue is it affects both DjVu and PDF files. --Xover (talk) 18:37, 20 July 2019 (UTC)
┌─────────────────────────────────┘
@Xover: Thanks again for your kind help. Unfortunately, Phe's Github activity and his activity on French WS, ceased two-three years ago. I don't know what is Phabricator's policy in such a case, so I will post the question in their community forum. Also noticed a bug report about the .pdf scanner. task T224355 — Ineuw (talk) 20:24, 20 July 2019 (UTC)
The OCR gadget is an inseparable part of my work with the proofread extension and I am really surprised that its maintenance depends on one particular person... That is not good. --Jan Kameníček (talk) 06:55, 22 July 2019 (UTC)
Just tested it again, and it now doesn't work for me as well. Wish I could track down the version of 04:35, 25 July 2019 (UTC). — Ineuw (talk) 18:37, 25 July 2019 (UTC)
Adding to Wikisource
Hi there,
I made a translation into English from German of the poem "Wandere!" by Heinrich Heine. A user Huon (administrator of Wikipedia) suggested I contacted the Wikisource to inquire if I possibly should have this translation added to the Wikisource. That is why I am writing. I visited "Wandere!" page ( https://en.wikisource.org/wiki/Wandere! ) on Wikisource but I am not quite sure how to do all this (adding the text, should it be just a translation or the original poem in German too, etc.). The poem itself and the translation of it is currently on English Wikipedia Heinrich Heine page ( https://en.wikipedia.org/wiki/Heinrich_Heine ) under the heading "Wandere!".Sergeismart (talk) 16:13, 23 July 2019 (UTC)
@Sergeismart: Danke, we do welcome translations, as long as you agree to freely license them. In the {{header}} template that begins the work, include yourself under the translator field and make sure to add the appropriate copyright tag at the bottom. It may be something like this: {{translation licence | original = {{PD-old}} | translation = {{CC-BY-SA-3.0}}}}. See {{translation license}} for more on that. Then, add a link to it to Author:Christian Johann Heinrich Heine and it seems like you're all set. I look forward to it being added here. —Justin (koavf)❤T☮C☺M☯18:26, 23 July 2019 (UTC)
Hey, Justin (koavf), will you check it out here - https://en.wikisource.org/wiki/Wandere! - if I did more or less fine (I mean if all spaces are filled correctly, etc.). And by the way I will appreciate your thoughts on the translation itself (if you have a spare second to read through it). Thanks.
Ja, meine Duetsche nichte ist gut but I'll take a look. Odd about the translation notes below, because we definitely do have locally-hosted translations that are not in that namespace and that use the standard header template. —Justin (koavf)❤T☮C☺M☯21:53, 23 July 2019 (UTC)
I just added " Category:Wikisource translations " at the bottom of an edit, couldn't do it through adding "Translation header" in the beginning of an edit (for some reason it didn't go through, it went very well though with just a "header" template). Hope now it is more or less fine. Enormous thanks for your help.
@Beleg Tâl: I was looking at other works in the translation namespace and it seems to me that the prevailing custom is to use the translated (English) name of the work in the name of the page after "Translation:" --Jan Kameníček (talk) 21:44, 23 July 2019 (UTC)
Hey, Beleg Tâl, I greatly appreciate it! No need to add myself as an author of a translation into the "translation license", right? Just asking cause User:koavf told me previously to include myself in the "translator" field. Thanks again.
Sergeismart (talk) 21:51, 23 July 2019 (UTC)
@Sergeismart: Two more things: (1) The author's name is not part of the poem text, and so should not be included in the poem or translation. The original certainly doesn't have it there. (2) There is no reason to italicize the entire poem or its translation. The original is not italicized. --EncycloPetey (talk) 18:25, 25 July 2019 (UTC)
Section Labels and known problems
I have started publishing pages, but not transcluding any of them yet. I see in Help:Transclusion that "Use of letters and numbers is usually a recommendation, and other extended characters may cause some issues when transcluding." Section Labels published so far contain the following characters: underscore, hyphen, colon, ampersand, and period (_ - : & .) I am hoping that someone has used these without problems. Or that someone can attest to having used other non-alpha, non-numeric characters with impunity?
I need to decide whether I should I start over and republish all the pages done so far. I have over 25000 Section Labels yet to be inserted. ¯\_(ツ)_/¯ Klarm768 (talk) 21:07, 20 July 2019 (UTC)
In my humble opinion, just use a character and a number, and without space. In this manner, enclosing it in quotes is superfluous. In my scheme of things I use the following syntax. For the ending section "E" = End and "289" equals djvu page number and "B" = Begin of next section. Do not use page numbers, they can be either missing or duplicated. Djvu numbers are always unique.
<section begin=E289 />
<section end=E289 />
and for the second
<section begin=B289 />
<section end=E289 />
I have not found that to be a useful process for biographical works as you have to track too many things, and too many possibilities for mistakes and omissions. I have found it significantly more helpful to use a section name that matches the article name (subpage) and for the article to match the identifying component. You will see that approach in many of our biographical works (though noting that in have been involved in most).
This also enables a quick and easy transclusion process, as I have two sidebar scripts that insert things like
which means that if you have a ToC to work from then you are just inserting page numbers (first example where it spread over multiple pages), or one page number, when the article is contained within a page. Noting that this method as it can have spaces means you need to wrap the section name within quotes in the Page: ns.— billinghurstsDrewth 00:55, 21 July 2019 (UTC)
Thank you both for your thoughts... although I'm a bit uncertain whether I rightly untangle the comments. I have revised 689 section labels to contain two "words"... entirely alpha-numerics. I do not understand whether there is additional advantage to truncating to a single "word" but I want to understand before resuming.
The work (Imperial Dictionary of Universal Biography) is a three volume set comprising 3940 page images. The 3672 pages-to-publish I have assigned into 25,740 sections, using a spreadsheet. There are 256 "signatures." Within my personal dissection I assign these "signatories" to 240 "identities" or "Contributors." This work has no de facto ToC. My sequencing spreadsheet is as close as probably ever will exist. I presume it is not eligible to be published with the IDUB, but it might have a usefulness in transclusion. I do not grasp the reference to "sidebar scripts," but I like the idea of facilitating transclusion. My background is not in computers. My mental-model is a mail-merge involving a "namespace template letter" into which fields are assigned and populated from each row of the spreadsheet to create templates to paste for transclusion. I'm sure that there are sophisticated methods but I work with the tools I have. Klarm768 (talk) 21:21, 21 July 2019 (UTC)
@Ineuw: I'm not sure what the word "project" means in your question's context. If there is an "official" Wikisource project regarding "Imperial Dictionary of Universal Biography" I do not know of its existence. As far as I know, billinghurst has created a few pages at the beginning of Volume 1 such as "List of Contributors" and other preparatory pages. Otherwise, as far as I know, I am the only person who has ever transcluded any portion. That occurred due to quest to track down as-complete-as-possible-works of James Frederick Ferrier. I choose to pursue the entire work. My reasons are personally motivated... but available on request.
Whether nobody else would choose to make it a project is not my concern. As far as a Wikisource IDUB project... which, if there were one, would have to mean I am deemed unwelcome/uninvited. I have spent many hundreds of hours getting the entire text in fair-copy-MS-Word... getting every entry & article sequenced and titled... getting the contributors disambiguated to considerable degree (actually one of the most confusing aspects). I would prefer to have a Wikisource-pilot steering my trireme... so many Scyllas and Charybdises. (Perhaps the only one who attempted the role got in trouble because of my errors... choices made before I ever discovered that Ferrier contributed to IDUB.) Besides... helping me with a project of 5,845,911 word-count is not Wikisource priority. In a year or two I hope to have IDUB in fair-copy-Wikisource and transcluded. The Wikisourse Mysteries are reserved for the initiates. Klarm768 (talk) 21:17, 23 July 2019 (UTC)
For what it's worth, there is one page of IDUB with 38 Sections on a single page. There are hundreds of redirects & biographies with fewer syllables than the subject's name. Klarm768 (talk) 21:24, 23 July 2019 (UTC)
@Ineuw: I'm not sure what the phrase "user:billinghurst's method" means in your context. I have already gone back and converted all Section Labels to a single 'word' of alpha-numerics. The numeric portion is based on the image# & and the alpha portion reflects/preserves the sort order of the Sections. Is that the "method?" I scrolled through the "user:billinghurst" site but found nothing I could otherwise apply myself. I have previously transcluded articles from pages with multiple sections on a page. Does that mean I used the method" at that time? Or is the "method" something new in the past 18 months?
BTW, I do appreciate your taking time to respond. Hopefully I will eventually have more comprehension and fewer confusions. Klarm768 (talk) 15:22, 24 July 2019 (UTC)
@Billinghurst: Thank you for your input. As I'm sure you are aware, Imperial Dictionary of Universal Biography has no ToC of its own. Is it conceivable that my Section-sequenced spreadsheet could be adapted (eventually) to generate the "records" to populate transclusion data. The Indexed Images are PDF rather than DJVU. Despite repeated attempts, I could not upload the entire Volume 3 in one piece, so I settled for making it into Volume 3a & 3b. Have I compromised automating the transclusion process? Klarm768 (talk) 20:14, 24 July 2019 (UTC)
@Klarm768: None of that changes my commentary about the preferred means to label sections with the resulting (subpage) article name. With regard to
the name list that you have, if you dump it somewhere as a text list, one name per line, I will convert it into a linked list for you, that is an easy task. The change that we make is to make it overt that OUR table of contents is not part of the publication, it is our generation. Men-at-the-Bar, Alumni Oxonienses, etc. are all in that boat.
DjVu vs PDF, again no issue, beyond DjVu has some advantages for our work
reupload as a split file, again no issue, the transclusion will care not, and as I suggested about ignoring volumes for your presentation, it makes no difference.
┌─────────────────────────────────┘ @Klarm768: Some additional comments.
If your material is in spreadsheet format it can easily be used to create a ToC. You can create a ToC in the main namespace, as it was done in PSM. I don't think that its against the rules of WS if one adds relevant material, which does not exist in the original. The rule is not to change the original itself when proofreading.
In reference to section tags, you should familiarize yourself with billinghurst's method of sectioning the text. I think that the second option is the simpler. If help is needed, just ask.
If the text is in MS Word format, there are people who use it for editing, spell checking, and then copying and pasting as plain text.
@Billinghurst:@Ineuw: If it would be prudent to perform a test batch on an IDUB subset I could make X-Y-Z available soon. When inductiveload helped with a ToC for Institutes of Metaphysics we used pastebin.com and I exported a delimited text file. I presume I still can use that when the time comes. The columns (fields) in my spread sheet are entitled thus:
Volume# | Image# | Page# | Entry-Sequence per page | ABC | Contributor# | Contributor's Text-Signature | * | Title of Entry | word count | Disambiguation/Clarification | SectionLabel (which is built from Image#&Sequence)
I can arrange or reorder to your specifications. Yes, I have "Word Counts" on 25,740 sections and assorted clarification errata which I hoped to insert into the "notes" area at transclusion. Contributor# is my creation, an assigned number signifying the sequence in which a contributor-signature is first observed in IDUB. Then if a new signature is discovered which is defensibly thought to be the same contributor I assign that signature to the existing Contributor#. I try to include the reasoning behind that assignment in the Disambiguation/Clarification field. The * field is for IDUB biography titles whose names are preceded by * signifying the subject was thought to be alive. This indicator is nowhere explained on any page of IDUB but is findable in the IDUB advertisements in other books.
I have a whole other spreadsheet upon which I have researched all the contributor Signatures and IDUB "Lists of Contributors" and wherein I pursue the disambiguation process. I don't know if that can be found useful, but it exists. Klarm768 (talk) 11:29, 25 July 2019 (UTC)
Just go ahead and do a test page or two according to your plan. A Wikisource test page is = 1,000 words in the Scriptorium. — Ineuw (talk) 18:32, 25 July 2019 (UTC)
Hmm. This is odd. The OCR text showing in the Page: namespace here is pretty poor; but when I look at the original PDF and DjVu files at IA the OCR text looks just fine. I can even copy from the PDF into a text editor and get much better quality than what appears online here. So I uploaded copies of both files locally here (PDF, DjVu) and checked the same page in both. This is the result:
PDF
OF DEDHAM, MASSACHUSETTS
7
Jno BuUard, Robt. Grossman, Hen Wilson, Jno N[ewton], Edw. Colver. Hen. Smith, Nath Colborne, Nath. Aldus, Hen Phillips, Sam^
Morse,
Dan Morse, Jno. Morse, Jos. Kingsbury, Jno. Dwite, Lamb.
Kemp, Edw. Richards, Tho. Leader, Geo. Bearstowe,
G[enery], Edw.
Jonath. Fairbanks,
Jno Frarey,
Eli.
Mich Powell, Mich Metcalfe
juno'^,
Jno Metcalfe,
Lusher, R[obt] Hinsdell, Pet. Woodward, Jno Guyle,
Rich. Evered, Robt. Gowinge, &ce.
The
said Inhabitants, taking into Consideration the great necesitie
some means for the education of the youth in o^ s'd
Towne, did with an unanimous consent declare by voate their willingness to promote that worke, promising to put too their hands to provide
maintenance for a Free Schoole in our said Towne. And farther did
resolve and consent, testifying it by voate, to rayse the summe of
Twenty pounds p annu, towards the maintaining of a Schoole M^ to
keep a free Schoole in our s'd Town.
of providing
And
and consent to betrust the s'd 2(d£ per annu
Towne, formerly set apart for publique use, into
the hand of Feofees to be presently chosen by themselves, to imploy the
sd 20;^, and the land afors'd, to be improved for the use of the said
Schoole that as the profits shall arise from the said land, every man
may be proportionably abated of his some of the s'd 20£ aforesaid,
&
also did resolve
certain lands in o^
:
freely to be given to the use aforesaid.
have power
land
:
make
to
And
y* y® said
Feofees shall
a Rate for the necesary charg of improving the s'd
they giving account thereof to the Towne, or to those
whom
they
John Hunting, E^^"^, Eliazer Lusher, Francis ChickerJohn Dwight & Michael Powell, are chosen Feofees and betrusted
should depute.
inge,
in the behalf of the school as afore said.
The school thus
was designed
established, to be
managed by Feoffees,
to continue seven years, as will appear in the
following record relating to the training ground
1644. 4^
12°^*^.
:
Granted to the Feofees for the free schoole
in
Ded-
ham for the use of the s'd schoole a parcel of the Training ground
much as shall be set out to them by the Towne, which said p'cel
so
is
granted from this present day unto the last day of the eighth month
which shall be in the year 1650.
Hen. Phillips deputed to set out the
Hen. Chickering,
s'd parcell of
Eli.
Lusher
Land above
said.
&
DjVu
OF DEDHAM, MASSACHUSETTS
7
Jno BuUard, Robt. Grossman, Hen Wilson, Jno N[ewton], Edw. Col-
ver. Hen. Smith, Nath Colborne, Nath. Aldus, Hen Phillips, Sam^
Morse, Dan Morse, Jno. Morse, Jos. Kingsbury, Jno. Dwite, Lamb.
G[enery], Edw. Kemp, Edw. Richards, Tho. Leader, Geo. Bearstowe,
Jonath. Fairbanks, Mich Powell, Mich Metcalfe juno'^, Jno Metcalfe,
Jno Frarey, Eli. Lusher, R[obt] Hinsdell, Pet. Woodward, Jno Guyle,
Rich. Evered, Robt. Gowinge, &ce.
The said Inhabitants, taking into Consideration the great necesitie
of providing some means for the education of the youth in o^ s'd
Towne, did with an unanimous consent declare by voate their willing-
ness to promote that worke, promising to put too their hands to provide
maintenance for a Free Schoole in our said Towne. And farther did
resolve and consent, testifying it by voate, to rayse the summe of
Twenty pounds p annu, towards the maintaining of a Schoole M^ to
keep a free Schoole in our s'd Town.
And also did resolve and consent to betrust the s'd 2(d£ per annu
& certain lands in o^ Towne, formerly set apart for publique use, into
the hand of Feofees to be presently chosen by themselves, to imploy the
sd 20;^, and the land afors'd, to be improved for the use of the said
Schoole : that as the profits shall arise from the said land, every man
may be proportionably abated of his some of the s'd 20£ aforesaid,
freely to be given to the use aforesaid. And y* y® said Feofees shall
have power to make a Rate for the necesary charg of improving the s'd
land : they giving account thereof to the Towne, or to those whom they
should depute. John Hunting, E^^"^, Eliazer Lusher, Francis Chicker-
inge, John Dwight & Michael Powell, are chosen Feofees and betrusted
in the behalf of the school as afore said.
The school thus established, to be managed by Feoffees,
was designed to continue seven years, as will appear in the
following record relating to the training ground :
1644. 4^ 12°^*^. Granted to the Feofees for the free schoole in Ded-
ham for the use of the s'd schoole a parcel of the Training ground so
much as shall be set out to them by the Towne, which said p'cel is
granted from this present day unto the last day of the eighth month
which shall be in the year 1650. Hen. Chickering, Eli. Lusher &
Hen. Phillips deputed to set out the s'd parcell of Land above said.
OCR button
OF DEDHAM, MASSACHUSETTS 7
Jno Bullard, Robt. Crossman, Hen Wilson, Jno N[ewton], Edw. Col-
ver, Hen. Smith, Nath Colborne, Nath. Aldus, Hen Phillips, Sam’
Morse, Dan Morse, Jno. Morse, Jos. Kingsbury, Jno. Dwite, Lamb.
G[enery], Edw. Kemp, Edw. Richards, Tho. Leader, Geo. Bearstowe,
Jonath. Fairbanks, Mich Powell, Mich Metcalfe juno", Jno Metcalfe,
Jno Frarey, Eli. Lusher, R[obt] Hinsdell, Pet. Woodward, Jno Guyle,
-Rich. Evered, Robt. Gowinge, &ce. ~
The said Inhabitants, taking into Consideration the great necesitie
of providing some means for the education of the youth in o' s’d
Towne, did with an unanimous consent declare by voate their willing-
ness to promote that worke, promising to put too their hands to provide
maintenance for a Free Schoole in our said Towne. And farther did
resolve and consent, testifying it by voate, to rayse the summe of
Twenty pounds p annu. towards the maintaining of a Schoole MT" to
keep a free Schoole in our s’d Town.
And also did resolve and consent to betrust the s’d 20£ per annu
& certain lands in o° Towne, formerly set apart for publique use, into
the hand of Feofees to be presently chosen by themselves, to imploy the
sd 204, and the land afors’d, to be improved for the use of the said
Schoole: that as the profits shall arise from the said land, every man
; may be proportionably abated of his some of the s’d 20£ aforesaid,
freely to be given to the use aforesaid. And y* y® said Feofees shall
have power to make a Rate for the necesary charg of improving the s’d
land: they giving account thereof to the Towne, or to those whom they
should depute. John Hunting, E’", Eliazer Lusher, Francis Chicker-
inge, John Dwight & Michael Powell, are chosen Feofees and betrusted
in the behalf of the school as afore said.
The school thus established, to be managed by Feoffees,
was designed to continue seven years, as will appear in the
following record relating to the training ground :
1644, 44 12™°, Granted to the Feofees for the free schoole in Ded-
ham for the use of the s’d schoole a parcel of the Training ground so
much as shall be set out to them by the Towne, which said p’cel is
granted from this present day unto the last day of the eighth month
which shall be in the year 1650. Hen. Chickering, Eli. Lusher &
Hen, Phillips deputed to set out the s’d parcell of Land above said.
�
Google OCR
OF DEDHAM, MASSACHUSETTS
7
Jno Bullard, Robt. Crossman, Hen Wilson, Jno N[ewton], Edw. Col-
ver, Hen. Smith, Nath Colborne, Nath. Aldus, Hen Phillips, Sam1
Morse, Dan Morse, Jno. Morse, Jos. Kingsbury, Jno. Dwite, Lamb.
G[enery], Edw. Kemp, Edw. Richards, Tho. Leader, Geo. Bearstowe,
Jonath. Fairbanks, Mich Powell, Mich Metcalfe juno", Jno Metcalfe,
Jno Frarey, Eli. Lusher, R[obt] Hinsdell, Pet. Woodward, Jno Guyle,
Rich. Evered, Robt. Gowinge, &ce.
The said Inhabitants, taking into Consideration the great necesitie
of providing
Towne, did with an unanimous consent declare by voate their willing-
ness to promote that worke, promising to put too their hands to provide
maintenance for a Free Schoole in our said Towne
some means for the education of the youth in oF s'd
And farther did
resolve and consent, testifying it by voate, to rayse the summe of
Twenty pounds p annu. towards the maintaining of a Schoole Mr to
keep
a free Schoole in our s'd Town.
And also did resolve and consent to betrust the s'd 20£ per annu
& certain lands in or Towne, formerly
the hand of Feofees to be presently chosen by themselves, to imploy the
sd 20, and the land afors'd, to be improved for the use of the said
Schoole: that as the profits shall arise from the said land, every man
may be proportionably abated of his some of the s'd 20 aforesaid,
freely to be given to the use aforesaid.
have power to make a Rate for the necesary charg of improving the s'd
land: they giving
should depute. John Hunting, Eldr, Eliazer Lusher, Francis Chicker-
inge, John Dwight & Michael Powell,
in the behalf of the sch0ol as afore said.
set apart for publique use, into
And yt ye said Feofees shall
or to those whom they
account thereof to the Towne,
are chosen Feofees and betrusted
The school thus established, to be managed by Feoffees,
designed to continue seven
following record relating to the training ground:
will appear in the
was
years,
as
1644. 4d 12mo, Granted to the Feofees for the free schoole in Ded-
ham for the use of the s'd schoole a parcel of the Training ground
much as shall be set out to them by
SO
e Towne, which said p'cel is
granted from this present day unto the last day of the eighth month
which shall be in the year 1650.
Hen. Chickering, Eli. Lusher &
Hen. Phillips deputed to set out the s'd parcell of Land above said.
The immediate conclusion is that the best result comes from the OCR button, followed by the DjVu, followed by Google OCR, and with the PDF dead last. But since the text looks fine in the PDF locally, this means the problem must actually be the function that extracts the text from the PDF on-wiki!
I haven't done systematic testing of pages in this work or across works, but the results above are quite suggestive. For one it means we should very strongly prefer the DjVu to the PDF as a source. It also justifies the reliance on the OCR button for those who routinely use that. And it raises the question of what the difference is between the OCR button and the OCR at Internet Archive. The OCR button uses Tesseract, but IA uses a commercial product if I'm not mistaken. It would be interesting to compare the text produced by the OCR button with that produced by the latest Tesseract directly to see if the results are comparable. --Xover (talk) 11:06, 23 July 2019 (UTC)
Hm, that is very interesting, thanks for sharing this info. As for better OCR with DJVUs than with PDFs: besides various problems with DJVU format (common browsers cannot read it), e. g. HathiTrust does not offer scans in DJVU, only in PDF :-/ Many contributors are able to download a PDF and upload it to Commons, but they are not always able to convert it to DJVU prior uploading. So the best solution is not to stop using PDFs, but to make Wikimedia projects environment friendlier towards them. --Jan Kameníček (talk) 11:21, 23 July 2019 (UTC)
I meant, when you have both DjVu and PDF available, you should always prefer the DjVu. Creating a new DjVu when one is not already available is a fiddly, obscure, and highly technical task: I've created my own tooling that makes it somewhat bearable, but it's not something I would suggest anybody else tries to do unless they are otherwise undaunted by such work. --Xover (talk) 11:31, 23 July 2019 (UTC)
@Xover: I understand that DJVU is shown better in the Page namespace. Does it applie also to DJVU converted from PDF? I personally would expect that any further processing deteriorates the text, so it is really strange if it improves after the conversion. --Jan Kameníček (talk) 11:43, 23 July 2019 (UTC)
@Jan.Kamenicek: Sorry, I missed this question. There is nothing inherently lossy about converting between PDF and DjVu where the text layer is concerned. We're converting structured data from one format to another, not doing OCR on an existing OCR text or stacking lossy compression algorithms. If the extraction from PDF in Mediawiki gives poorer results than the extraction of the exact same text from a DjVu, then any process that moves the text layer as is to a DjVu should give better results. But, of course, if you use the same method that Mediawiki uses (which gives bad results from good data) and puts that into the DjVu, then the conversion will give equally bad results (or maybe even worse results).But I'm not familiar with the way PDF stores text layers internally or the existing tooling for extracting it. It is entirely possible that actually doing this in practice is too complicated to be realistic. So at least for now, my approach will be to generate a new DjVu, with a new OCR text layer, from original page images, when this issue crops up. And I'd be happy to help out anyone who doesn't have the tooling available to do it themselves. Just with no promises on turnaround time: it's a somewhat fiddly multi-step process where each step takes a significant amount of processing time. --Xover (talk) 09:59, 28 July 2019 (UTC)
Tables of Contents
In the past I have mostly relied on {{Dotted TOC line}} when building tables of contents, and in many cases that works fine.
I've seen others use a table-based approach, rather than a template on each line. I don't see anything under help:Table of Contents or WS:Table of Contents, and I'm wondering if somebody could help me learn this other system.
That page uses {{TOCstyle}}, you can read the documentation on its template page to get up to speed. I personally would use {{TOC row 1-dot-1}} and its related templates, which are also documented on their own template pages. —Beleg Tâl (talk) 12:46, 28 July 2019 (UTC)
@ShakespeareFan00: (and CC Inductiveload) There is documentation for TemplateStyles itself at mw:Help:TemplateStyles. It's not much used here yet because until very recently there were serious bugs in MediaWiki when it was used, and that broke stuff here on enWS. Those have now been fixed so as a general rule TemplateStyles should be safe to use.However, note that the intended use for mw:Extension:TemplateStyles is in actual templates, and use elsewhere is not necessarily a good idea. Even if it does not create any other technical issues, I am uncertain we would want a work, like The Lusiads (tr. Burton), in mainspace to have an associated custom stylesheet over in the Template: namespace (i.e. Template:Os Lusiadas (Burton, 1880)/errata.css). Until some kind of practiice and guidelines is figured out for this use case I would recommend using it only very sparingly and only when the benefits are significant (avoiding a large number of {{ts}} calls might be one such case).The method does look like a very useful one with many potential benefits for the Wikisources though. Perhaps it would be worthwhile to poke Tpt and Anomie and see if something tailor-made for Wikisource could be made based on ProofreadPage and TemplateStyles? There is that "CSS" field in the Index: that only kinda sorta does work sometimes maybe. Perhaps it would make sense to have per-work custom CSS in a subpage of that work's Index:, and use the "CSS" field on the work's index to load it?Whether or not we would want to actually allow per-work CSS is a different matter, and one that would need discussion on the Scriptorium to determine. I imagine the benefits might be obvious for larger works like the DNB, but more controversial for most smaller individual works. --Xover (talk) 16:23, 21 June 2019 (UTC)
@Tpt:@Anomie: , Let's start the discussion.. I know with some works I did that I was using a LOT of {{ts}} calls, when some form of advanced per work classing would be more appropriate, assuming it was possible..
@Anomie: - Thanks, but I think Index: pages generate their own edit form, which would need to be DISABLED if whats being seen is in fact the per work styles.. 13:44, 22 June 2019 (UTC)
Note that any transcluded styles for Page: 's would also need to be made in such a way that the CSS concerned could also be used in Main namespace, but I'm not sure how you would be able to write CSS that was transclusion aware.. ShakespeareFan00 (talk) 16:28, 21 June 2019 (UTC)
(Aside) It would be nice in time (i.e when anyone cares to implement it) if {{ts}} was re-written slightly, so that adding new codes to it and other templates like {{tf/s}} {{span}} {{p}} etc. could be done WITHOUT having to add new clauses to the MASSIVE switch statements inside them. ShakespeareFan00 (talk) 16:45, 21 June 2019 (UTC)
If necessary, you should be able to use body.ns-0 as part of a selector to apply only on main-namespace pages, and similarly body.ns-104 as part of a selector to apply only on Page-namespace pages. Anomie (talk) 13:39, 22 June 2019 (UTC)
Thanks
In terms of name-mangling if needed, could you do something like __indexpage_id__localclassname?
In terms of what's required to use this right now:
If it's acceptable to put the CSS styles in the Template namespace, nothing needs to be done right now.
If it's preferred to put per-work styles in the Index: namespace (which I think is probably a good idea) then any of these will suffice:
Set $wgTemplateStylesNamespaces so that Index namespace CSS pages get the Sanitised-CSS content model by default (IMO, this is best), or
Permit non-administrators to change page content models (to work around the lack of default). This can be either by a change of config, or a resolution of phabricator:T85847.
Put them in the Template: namespace and move them later when one of the above is done.
In terms of nice-to haves, a resolution of phabricator:T226275 would allow the <pages/> tag to pull in a style that every page of a work uses. But this can be worked around for now by manually placing the shared <templatestyles/> tag before the <pages/> tag and adding to the auto-header in the index page. THis would be easy to bot out later, and harmless if left in place.
Just finished validating my first Wikisource text, The Life of the Spider (with some help from Xover above). One thing I'm not sure about is linking to the book index from the Wikisource page. The book index isn't listed in the table of contents, so it isn't linked to from the Wikisource page, and thus isn't included in exported versions. Is there a way to fix that (aside from just transcluding the book index directly into the Wikisource page)? Kaldari (talk) 15:06, 29 July 2019 (UTC)
I think I would have gone with treating it as a chapter (its own subpage) and used the previous/next links in the header to link it in. And if the original table of contents is insufficient for some reason, {{AuxTOC}} is usually used to supply the want. But I don't think I've run across this specific issue previously so you may want to hold off and see if anybody else has a better or more definiitive answer. --Xover (talk) 16:55, 29 July 2019 (UTC)
Yep, I'd just stick an {{AuxTOC}} at the start/end (as appropriate) of the real TOC. For example, The Amazing Emperor Heliogabalus has a Preface that isn't listed in the real TOC. Its quite common for front matter and indexes. It could probably do with a note somewhere if this is actually good practice. Inductiveload—talk/contribs17:27, 29 July 2019 (UTC)
Thanks for the suggestions! I tried the {{AuxTOC}} template, but I didn't like that it created a separate TOC in the export that wasn't part of the original book. Instead I ended up just adding a hidden link to the Index from the existing TOC (Page:The Life of the Spider.djvu/10) which actually worked perfectly. Kaldari (talk) 02:00, 30 July 2019 (UTC)
The pages tag is supposed to add a Back and forward link?
It was my understanding that header=1 added forward and back buttons:- but here it's use here
Where is the mistake so I don't have to run around playing hunt the quirk again, when trying to rely on what has and hasn't been purged in the backend yet? ShakespeareFan00 (talk) 17:12, 2 August 2019 (UTC)
For anyone trying to use this, the way it works is that when you add |header= to the <pages/> tag, ProofreadPage automatically inserts a {{header}} template with automatically generated variables for |previous= and |next=. To find the right previous and next chapter it uses the work's Index: page as a table of contents: every link to mainspace (i.e. ignoring links to Author: and Portal: pages) is assumed to be a chapter link, except the first link which is assumed to be the link in the title field to the work's main page. This last point was what tripped up ShakespeareFan00 here: in the Index: page the work's title wasn't linked, so ProofreadPage instead ignored the link to the first chapter. Thus the previous link on chapter 2 didn't get filled in (but subsequent chapters' previous links did). --Xover (talk) 18:11, 2 August 2019 (UTC)
How should I add incomplete indexes to Author pages?
Hello! I've recently upload scans of Nutcracker and Mouse-king by E. T. A. Hoffmann to commons and i've uploaded a Index to wikisource. I'm going to start transcription soon, but I would like some help. Can I add a link to the index on the authors page and if I can, how do I do that? If I can't add a link to authors page, where on Wikisource can I ask for help and/or boost the index's popularity? Pago95 (talk) 18:39, 4 August 2019 (UTC)
In my experience, you can choose one of three ways:
If the work has been partially transcluded, place {{incomplete}} on the transcluded work page, and do not link to the Index page from the Author page.
If there are a lot of works listed on the Author page and it looks too cluttered when you use {{small scan link}}, or if you want to distinguish between works that have scans and works which were added but do not yet have scans, you can use {{scan}}; see Author:William Schwenck Gilbert for example.
1) How can I add a speech transcription entry to Wikisource without first uploading a file to the Commons? I understand from the Beginners Help how to create a Wikisource entry from a Commons upload, but what if I haven't done one? ETA: I realize now there is no requirement to have a Commons upload.
2) If I have a link to video or audio of the actual speech, but the link is not to the Commons, what is the format to include this link in the Wikisource entry? For example, this https://en.wikisource.org/wiki/Presidential_Weekly_Address_-_14_January_2017 is a transcription of an Obama Weekly address which can be viewed at Youtube. I think the entry would benefit from a link to the video, am I wrong and such external links are to be avoided?
I MUST create an author page for a "James Orton." He is not the same one who populates the existing "Author:James Orton" identified as an American Naturalist. ALL the background ID available on my "James Orton" reads as follows:
James Orton, Dublin, Author of "The Enthusiast," "The Three Palaces," &c., &c.
My Jame Orton contributed 4 brief biographies to the "Imperial Dictionary of Universal Biography." Both authors wrote in the mid to late 19th century. I have found a few references in periodicals but have not been able to add a middle initial or vital statistics. What is the recommended remedy?Klarm768 (talk) 17:05, 7 August 2019 (UTC)
Have you used Wikidata at all? One good first step would be to ensure that each has a thorough Wikidata entry. The naturalist has an entry: wikidata:Q6140665 It would be good to start another for the other Orton.
More specifically, it's my impression that English Wikisource policy is generally to use the most complete name of the author, as opposed to the name by which they are best known. So if there is a known middle name for either, that's the most straightforward way to distinguish them. If not, Help:Disambiguation#Authors says we should use birth and death years to distinguish. -Pete (talk) 17:30, 7 August 2019 (UTC)
I can see a James Orton in Ireland in the 1850s, and early 1860s. James Orton married Julia Colthurst in 1853, he was of St. Margaret's Bay, Kent. (Dover?) Wife died 1857 (seems to be childbirth), and daughter 7 months later, at 7mo. This gent is Bray, Wicklow (selling up 1862). Directories and newspapers shows James Orton an inspector of branches (People's Provident Assurance Society) in Dublin and Bray in 1858. [Baptism of John Nicholas Colthurst Orton in Westminster in 1854, so this is a UK & Ireland search. JNCO cited as actor in census. Death of same, also called Charles Overton, 1898]
Thank you to all who have pitched in... particularly @Beleg Tâl:. I was going to need further help implementing BT's advice, but it appears BT has performed what was proposed. I wish I could say that understand what BT proposed and appears to have done. Perhaps then I could do the remainder myself. Wikidata is mysterious to me. HOWEVER I have 3 remaining disambiguate+create problem authors. Should I create a new Scriptorum Section for each or continue this one? Klarm768 (talk) 14:35, 8 August 2019 (UTC)
That's really all there is. A wikidata item for the new author will need to be created, but you can ask someone else to do it for you, or you can look at d:Wikidata:Tours to learn how to do it yourself. —Beleg Tâl (talk) 14:42, 8 August 2019 (UTC)
Thanks. I've now started the Wikidata Tours. A number of the IDUB contributors are not published elsewhere, no dates of birth/death are provided, often possess rather common names, are distinguishable by their profession/city/academic&heraldic_credentials. Overall I am proud of my detective work on 230+ discoverable contributors. BUT My last three provide least of any distinguishable facts, their Author:names are already in use. My numerously-configured Google searches are not adequate. More successful search methods are not mine. The dates of contribution-composition are not provided so floruit date could be 1854-1876.
I can provide a titles of their contributions and/or the full content of contributions. The TOTAL contributor data points are these:
Possibly useful: Frederick M. White contributions (numbering about 370) are mostly biographies of Spanish historical and then-living contemporary figures. Klarm768 (talk) 16:23, 8 August 2019 (UTC)
Thanks for your help... BUT I failed to include parentheses and I created Author:James Anderson 1804-1863. So now I need advice on how to remedy that.
I find 9 contributions by Barr. Most of them are ecclesiastics; but not of any particular denomination, nation, or doctrinal theme that I recognize. I observe that not only Barr's but many of the signatures fall in a segment of the alphabet. I have surmised that they were contracted for a "duration" (sub-editor switches were numerous). The original IDUB was created from A-to-Z. This might explain why all of Barr's biographies start with G, H, I, J, or L. At least one of the less august contributors was employed while a University student. Perhaps contributions ceased with graduation or acquiring a better job elsewhere. Klarm768 (talk) 20:35, 8 August 2019 (UTC)
I happen to possess a physical copy of the 1863 Edition and could confirm that Barr's contributions are there. His originals were probably first printed 1856-1860. I know of no digital version of 1863 Edition. Klarm768 (talk) 21:48, 8 August 2019 (UTC)
I'd like to move this book from Commons over to Wikisource. I've created a few books before from Commons to Wikisource but I don't know what to name this one. This is what I named it on Commons "File:Navaho Legends.djvu" But maybe I was supposed to name it "Memoirs of the American Folk-Lore Society V". This one in Wikisource is from the same series.
Index:Memoirs of the American Folk-Lore Society XVII.djvu
Should I have named the original file, on Commons, Memoirs of the American Folk-Lore Society V ?
And then there's this also, already on Wikisource, with a red link for Navaho Legends: Memoirs of the American Folklore Society
Please help with advice or please go ahead someone and do it because I have no idea how to proceed and I would like to start reading and working on the Navaho Legends. Also note that same book is available on books.google except there is an image that doesn't show on the book in Commons AND images are in books.google are in color. Thank you much.--The Eloquent Peasant (talk) 00:24, 9 August 2019 (UTC)
Sorry for answering my own question. I've requested the file in commons be moved to: File:Memoirs of the American Folk-Lore Society V.djvu so then I can create the index file here. I think this is the correct thing to do. Thanks! The Eloquent Peasant (talk) 02:03, 9 August 2019 (UTC)
Ultimately the name of the file doesn't really matter, but it's preferred (especially on Commons) if files in a series have consistent naming. Since the other files in this series have the format "Memoirs of the American Folk-Lore Society #.djvu", I think you were right to rename the file. —Beleg Tâl (talk) 14:53, 9 August 2019 (UTC)
On this page, about the middle of the right column, there is an odd character: a rho with a wavy line above it. This squiggle is intended to reproduce a manuscript mark and looks to have been added to the type plate freehand. How should it be reproduced digitally? Levana Taylor (talk) 01:44, 8 August 2019 (UTC)
Nonono don't use Latin letters to transcribe Greek! The correct character is Rho + combining tilde: ΧΡ̃Ο ΧΡ̃Ο or Χ{{subst:cdm|Ρ|303}}Ο—Beleg Tâl (talk) 10:36, 8 August 2019 (UTC)
I agree with Beleg Tâl. An alternate method (as if you need more!) could be: <math>\Chi\tilde{\Rho}\Omicron</math> which renders as: . Incidentally in case you are wondering the sequence in Greek is usually translated as Christo (as in Jesus)… 114.78.171.14411:44, 8 August 2019 (UTC)
Cool, thanks for the math code. I had actually tried the combining tilde and noticed that it’s not suitable for capital letters because of rendering on the letter instead of above. But ‘math> can do so much. Levana Taylor (talk) 15:13, 8 August 2019 (UTC)
The combining tilde renders above the letter. Your system may not work right, but it works right on this system (a generic Windows 10 system), and hopefully the percentage of system that have problems with it will just decrease over time. The math code is less well supported and I'm pretty sure it won't work with screen readers, whereas I'm pretty sure that ΧΡ̃Ο will at least get spelled out.--Prosfilaes (talk) 01:10, 9 August 2019 (UTC)
Of the two browsers on my laptop, Microsoft Edge renders the combining tilde correctly and Firefox doesn’t. Can some other people try out Safari, Chrome, and mobile browsers? Levana Taylor (talk) 23:55, 9 August 2019 (UTC)
It's going to depend a lot on more things than just the browser. Edge and Chrome on Windows 10, and Chrome on my Android system all display it correctly.--Prosfilaes (talk) 07:47, 10 August 2019 (UTC)
OK, I should stop worrying then. Somehow I hit the one browser setup (Firefox + whatever addons on Windows 1) that wasn’t working correctly. Probably won't happen for anybody else. Levana Taylor (talk) 08:02, 10 August 2019 (UTC)
Problems with specific transclusion
Despite my repeated attempts, I have been unable to properly transclude this work, do to a number of incorrect line breaks added by the <pages /> command. Is there any way to fix this, other than to either fully correct the file, or to give all of the pages as templates (i. e., {{Page:}})? TE(æ)A,ea. (talk) 15:11, 9 August 2019 (UTC).
That’s the problem; the poems are transcluding as intended. It is the unnecessary page breaks inside of a paragraph that are the problem. “[A]nd that no State could/either…” should be in one paragraph, not two (here). I’ve used (perhaps broken) <pages index="Marmor Norfolciense.djvu" include=25-55,64-65,56-63,82,66-78 />; that shows the correct “page” range. TE(æ)A,ea. (talk) 17:35, 9 August 2019 (UTC).
Since the paragraph that starts on page 55 is continued on page 64, I think that this include method is the only way to preserve that flow within the pages tag. —Beleg Tâl (talk) 18:26, 9 August 2019 (UTC)
That is what is currently being used; however, it is not working. With the “include” parameter, regardless of given order, it proceeds in numerical order. This causes problems, as the scan is not in numerical order. TE(æ)A,ea. (talk) 23:26, 9 August 2019 (UTC).
I see what you mean. I think I have an idea of how we could make it work, but honestly I think it would be better to just fix the scan. —Beleg Tâl (talk) 01:30, 11 August 2019 (UTC)
I'd like to have the Index:Memoirs of the American Folk-Lore Society V.djvu removed- it came from archives and is missing tons of images.
A better version of the same is on books.google and it's not missing images. --The Eloquent Peasant (talk) 03:56, 11 August 2019 (UTC)
It is slightly complicated as you want to upload a .pdf file, while the current one is .djvu. I personally would upload the pdf version to Commons independently of the original djvu, and then started a new index page. (The old one can be deleted then).
To get the book to Commons you need first to download it from Google Books to your computer, and then you can upload it to Commons using their UploadWizard. Unfortunately I cannot do it for you, as Google Books limit the access to many publications of theirs (including this one) in my country. If you need any other help, just ask. --Jan Kameníček (talk) 07:15, 11 August 2019 (UTC)
I did it! Thanks! 1) I downloaded the Google version (with images). 2) I converted it to djvu format. 3) I uploaded it over the old version (without images). Now I'll fix the pagelist. Thank you.The Eloquent Peasant (talk) 12:36, 11 August 2019 (UTC)
A scanned file has got two wrongly ordered pages (no. 111 and 112). Having checked it with a different copy I found out that the original book has the pages correct and so it is only a fault of this particular scanned file. Unfortunately, the other copy has many other flaws, and so it is not possible to replace it. Could somebody skilled with djvu files fix it and reorder the two pages, please? --Jan Kameníček (talk) 18:30, 12 August 2019 (UTC)
Perfect, thanks. Now I'll just have to wait until the index pages get updated as clearing the cash has not helped, but I guess it is only a matter of time. --Jan Kameníček (talk) 06:59, 13 August 2019 (UTC)
Help with botched page move
In the midst of some discussion about book titles (see here if you want the background), I moved Vol 1 History of Mexico by H H Bancroft to History of Mexico (Bancroft)/Volume 1. I expected to see a checkbox that would have permitted simultaneously moving all the sub-pages (the chapters) as well, but I didn't see that option. I foolishly forged ahead, hoping that the checkbox I remembered was on the next screen in the process; but of course, it wasn't.
(1) Where did I go wrong, and (2) (more importantly) Is somebody able to move the sub-pages to clean up my mess?
The answer to (1) is actually somewhat important, because there are 3 other volumes in this series that will need similar treatment.
Please note, in this case the works have existed for some time, so it's important to preserve redirects rather than deleting the original page names. -Pete (talk) 06:03, 13 August 2019 (UTC)
You didn't go wrong, you just don't have the ability to do it because you're not an admin. Let me know on my talk page the exact names of origin and target that you want the other volumes moved to. Beeswaxcandle (talk) 06:53, 13 August 2019 (UTC)
Ah, of course. I guess I'm remembering from other wikis where I'm an admin. I just didn't realize that checkbox was an admin thing. Thanks for doing that, and yes, I'm happy to dig through and fix any remaining idiosyncracies. -Pete (talk) 07:48, 13 August 2019 (UTC)
My custom edit toolbar gone again...
...which I could live with if I could possibly bring the Insert/Wiki markup, etc. toolbar from the bottom of my editing space to the top. Is this possible? Thanks, Londonjackbooks (talk) 04:11, 14 August 2019 (UTC)
please include athorisms of G.C. Lichtenberg
G.C. Lichtenberg was Germany's first professor of physics who had laid the theoretical groundwork for the Xerox machine by the mid-eighteenth century. Severely hunchbacked , he nevertheless became one the great aphorists of the age, recording his thoughts and observations - such as "Everyone is a genius once a year. A real genius has his original ideas closer together." - in a series of alphabetical "waste books"(he'd reached volume "l" by the time he died in 1799). Can you include the waste books, please ? Thank you! —Preceding unsigned comment added by 80.41.196.51 (talk)
The only available book seems to be Lichtenberg's Reflections. I have uploaded it for you and created the index page, so if you want, you can start transcribing. I have also proofread two pages as an example, see e. g. Page:The reflections of Lichtenberg.djvu/28. If you need some advice during the work, just ask, somebody will always help you. Happy editting! --Jan Kameníček (talk) 15:41, 14 August 2019 (UTC)
IwPageSection generates badly formatted HTML...
<spanclass="iwpage"title="fr|Ruffhead - The Statutes at Large, 1763.djvu/206|viscount"id="fr:Ruffhead_-_The_Statutes_at_Large,_1763.djvu/206:viscount"><divclass="mw-parser-output"><divclass="pagetext"><divclass="mw-parser-output"><p><br>
rienreceudesdettesleRoi&qeriensneprendretzparquoileRoiperdeouparquoidroituresoitdesturbeouladetteleRoidelaeeqeloiaumentfreezretourner&loiaumentsuirelesbrefsleRoiavostrefen&avostrepoair&qevousneprendretznulballifenvostreserviceporqivousnevoletzrespoundreetqevousswreezvozballifsfaireautielsermentcomeaeuxapentetquenulbriefnereceivretz,parvousneparlesvozsouzsealdesJusticesforsqeeneyreouautresjusticesassignetzenmeismelacounteouJusticedeNeugate&qevousmettretzvozballifsdeplusloiauxdupais&qenulballifneministreqiadesteodlautreviscounteretendretzenvostreservice.
<spanclass="iwpage lang-en"title="en|Ruffhead - The Statutes at Large, 1763.djvu/206|p160-n1"id="en:Ruffhead_-_The_Statutes_at_Large,_1763.djvu/206:p160-n1"lang="en"></span></p><!-- NewPP limit reportParsed by mw1290Cached time: 20190816083951Cache expiry: 2592000Dynamic content: falseComplications: [vary‐revision]CPU time usage: 0.008 secondsReal time usage: 0.011 secondsPreprocessor visited node count: 34/1000000Preprocessor generated node count: 0/1500000Post‐expand include size: 1917/2097152 bytesTemplate argument size: 176/2097152 bytesHighest expansion depth: 4/40Expensive parser function count: 0/500Unstrip recursion depth: 0/20Unstrip post‐expand size: 0/5000000 bytesNumber of Wikibase entities loaded: 0/400--><!--Transclusion expansion time report (%,ms,calls,template)100.00% 7.960 1 Modèle:Lst100.00% 7.960 1 -total 25.16% 2.003 1 Modèle:IwpageSection--></div></div></div></span>
This is malformed as a DIV cannot be inside a SPAN. LintErrors doesn't detect this,(and currently there is no visible impact as far as I can tell) but as I expressed previously on a different issue trying to shorehorn everything into a SPAN is leading to longer term issues. It's time certain contributors with the expertise, took another look at this.
ShakespeareFan00 (talk) 08:47, 16 August 2019 (UTC)
I agree that this does not look like a good place to use <span>…</span>. By its nature it will regularly and quite appropriately contain block elements, and this will lead to all sorts of weirdness and undesirable behaviour. My initial thought is that this should be changed to <divclass="iwpage-section">…</div>, and site CSS changed to treat that wrapper as .iwpage-section{display:inline}. No guarantee this will not break anything that relies on the old quirks, but I would be inclined to argue that those instances are in principle broken to begin with. --Xover (talk) 10:11, 16 August 2019 (UTC)
I was saying eslewhere, that the iw templates and {{Page}} could ideally be a module, to centralise the core behaviour and provide options to overcome some of the current limitations, like in some instances the desirability of getting the semi-'raw' markup back, so that a local wiki could reprocess it slightly (However as templates are widely divergent on other wikiks, that proabably too risky.).ShakespeareFan00 (talk) 10:16, 16 August 2019 (UTC)
The templates don't do much that's worth modularising; they just spit out a span or div with the provided params concatenated into the title or id attributes. The actual work happens in JS at MediaWiki:InterWikiTransclusion.js (globally loaded from MediaWiki:Common.js), which is a three year old copy of mul:MediaWiki:InterWikiTransclusion.js (I don't think the intervening changes are particularly relevant to this discussion). The templates expose the provided parameters as html attributes (id/title) which the javascript then picks up, and then requests the relevant content from the remote wiki using the MediaWiki API, and finally inserts it inside the span or div generated by the template here. In other words, the only bit worthwhile centralising is the javascript, and that is already centralised (it's just insufficiently maintained, but that's a separate matter).A central repository for templates and Gadgets that are available across projects is on a long-term wishlist at the WMF, but nothing much is being done with it that I am aware of. The problems are not primarily technical: separate projects have separate goals and practices, making sharing code often be challenging. --Xover (talk) 10:53, 16 August 2019 (UTC)
There is no scanned page, ProofreadPage simply has a default view for a non-existing page. Things are being displayed as expected, it is your actions that are not expected or within scope. Keep within scope, and things will work fine. — billinghurstsDrewth13:20, 16 August 2019 (UTC)
As I indicated, this IS working as designed. What would be useful is the ability to transcribe different portions of a complex layout to different sub-pages, but using the same scanned image (an example would be a newspaper scan with many individual articles, in each 'frame' of the print layout ). This would not necessarily be the same as using sections. If this isn't currently supported fair enough, but it's a limitation.
We are working in the Page: namespace, why should we be bothering with intricate complexity for no valid purpose. Our purpose is the presentation in the main namespace in a clean and as simply as reasonable possible. Why do we even have the discussion about some fancy? You keep trying to make things more difficult and convoluted than is necessary. — billinghurstsDrewth14:52, 17 August 2019 (UTC)
It's an interesting idea. Unfortunately, I don't think the devs would implement it; it would require a lot of work to implement and would not be used very much at all. I've seen the devs shut down ideas that are better than this and easier to implement. —Beleg Tâl (talk) 21:38, 16 August 2019 (UTC)
And sometimes, my seeming unreasonableness, comes from the fact that I do actually "care" (as you do.), I'm just more likely to bluntly express the frustrations I have about quirks and limitations, because there is seemingly (as you mentioned previously) not necessarily the community expertise for someone to sit down and take a closer look at the responsible code. In many instances Wikisource IS pushing the limits of what Mediawiki and wikitext was originally designed to do, and the flexibility offered means that slightly less experienced contributors (myself included) are only to able to create combinationally complex templates, that a more considered approach wouldn't have. If I seem to be complaining a lot, it's not because I like complaining, it's out of frustration at encountering the same concerns and temporarily lacking the recall of what had been suggested or decided on as a reasonable solution previously. Given this I am wondering if I should stop contributing, as I seem to unable at times to express 'technical' concerns without ranting, or the ability to reason if previous solutions, (even some I had suggested) would be applicable.ShakespeareFan00 (talk) 16:46, 16 August 2019 (UTC)
There seem to be three different approaches being used to the Subject and chapter headings across this work. Before I continue I'd like to ask someone to consider writing a style guide for this, so I'm not necessarily going to have to go back over stuff that was previously validated. ShakespeareFan00 (talk) 14:41, 17 August 2019 (UTC)
How to on footnotes that overflow on Narrative of the Proceedings of Pedrarias Davila
Well. Here it definitely feels like the blind leading the blind. Which is better, before or after? I proofread the pages leaving the footnote overflow formatted the way it had been done before my time. Newer user changed the footnote overflowing wikimarkup and I don't think it works. Sometimes the page on the finished product shows a broken sentence. I let the user know that I thought he should undue his footnote formatting changes. This is an example of the page:
[[18]] Please guide us or tell us where to go for guidance. Thanks. --The Eloquent Peasant (talk) 16:31, 17 August 2019 (UTC)
I left a couple of newlines preceding the footnotes, which interfered with the transclusion. Sorry about that. I've now removed them. Feel free to revert my changes if they've somehow made things worse. 8582e (talk) 16:42, 17 August 2019 (UTC)
I have fixed one ref, now it should work fine. Imo the best solution is to use <ref name="xy"> text </ref> on the page where the reference starts and <ref follow="xy"> text </ref> on the following page. I have never met any other solution. --Jan Kameníček (talk) 17:00, 17 August 2019 (UTC)
Then the second suggestion works: <ref>{{page|The seven great hymns of the mediaeval church - 1902.djvu/66|section=note01}}</ref>. The {{page}} template defers to LST's #section parser function, so it's independent of the pages tag. Regardless, the current state is not actually "broken" per se, since it does transclude correctly (edit: kinda, it has linter errors) (and the original work doesn't have the note on that page anyway). Inductiveload—talk/contribs11:30, 16 August 2019 (UTC)
The LintHint script is however claiming for [[19]] is there's a DIV SPAN swap sowmewhere though. but I can't see it visually in the output, so hardly a priority. ShakespeareFan00 (talk) 12:02, 16 August 2019 (UTC)
That would be because there is the following construction for each ref:
Comment Not sure why we are going around this roundabout yet again. It will never work successfully, and it is completely known that it will be problematic within wikis. So please stop the incessant complaining; it is getting beyond a joke.
I think this is just phab:T49544 rearing its ugly head again. We should definitely not start removing block content from references just because the references algorithm hasn't been updated to accommodate them yet. In this case the current construction works exactly as intended. —Beleg Tâl (talk) 21:35, 16 August 2019 (UTC)
┌─────────────────────────────────┘ Why make this so ludicrously complicated? To use the existing symbolism:
{{sup|1}}
## note01 ##
"Le {{ls}}urnom de Bernard &c. &c.
####
with:
<reffollow="note01">
"Le {{ls}}urnom de Bernard &c. &c.
</ref>
Now was that so hard? No need for nested extension invocations at all!
Oh and don't forget to rinse and repeat for each case. 114.78.66.8223:07, 16 August 2019 (UTC)
Or, you could leave it alone since it's already validated and working as intended. I probably would have used this method if I had known about it when I proofread that work, but the method in place currently is fine. —Beleg Tâl (talk) 23:17, 16 August 2019 (UTC)
@Beleg Tâl: You speak as the person who tweaked the page twice (out of nine edits) subsequent to validating the thing. Even if what you were attempting unsuccessfully to do actually worked it would be wrong and result in a large amount of footnote content which should not appear in Page: space. So, umm—no. Do it right instead.
Recall I have no real dog in this fight so do not care if you persist in being stubborn, foolish or foolishly stubborn. 114.78.66.8201:19, 17 August 2019 (UTC)
Foolish, would be breaking or unnecessarily uglifying something. And it's definitely not stubborn to not want to change something the only issue with is a small linter concern (which as I said above was hardly a priority.) Your solution when tested did not render in the expected way in respect of the Notes Pages itself. Namely I ended up with a a list of superscripted numbers followed by a list of the notes broken out of the formatting. (There may have been numerous reasons why that formatting was being retained.) Did you try sandboxing the approach you suggested above? User:Billinghurst's suggested template was a much cleaner approach, and a more sensible solution to this. Yes I can agree with doing it right, provided that it IS actually the right way, something many of my own "too clever by half" approaches to certain layout issues have eventually floundered on.ShakespeareFan00 (talk) 20:07, 17 August 2019 (UTC)
I have solved the references on The seven great hymns of the mediaeval church/The Celestial Country using {{authority reference}}, which is basically a wrapper around the solution using #ref and #section tags with a bit of namespace-sensitive code on top. I did modify the template slightly for flexibility in cases like this when the reference text is not a single section on a singe Page. I didn't do so to break the validated text, but more because I wanted to ensure that the {{authority reference}} approach would, in fact, work. Indeed, it was previously not quite possible with that template as-was, and it now is. I have also overhauled its documentation. Inductiveload—talk/contribs13:14, 19 August 2019 (UTC)
I have uploaded a new version, without first pages. Text layer should be aligned now. Please corsscheck pagelist.Mpaa (talk) 19:24, 18 August 2019 (UTC)
This page Short_Titles_Act_1896/First_Schedule/1838 uses the deprecated {{Page}} template because it builds up a table where the sectional boundaries do not align with the page boundaries in the scan.
Is there an equivalent {{pages}} template or module that would do the same thing with a single template call or invocation which is equivalent to if it weren't for the table would be a straightforward <pages> tag (which according to it's documentation cannot currently be used in this way)? ShakespeareFan00 (talk) 08:48, 18 August 2019 (UTC)
If this is the correct way to build these pages, fair enough, but concerns were raised about overly convoluted solutions recently. (I'd already started on trying to subst down the templates used in Page: namespace on this so that it was simpler to understand. ShakespeareFan00 (talk) 08:48, 18 August 2019 (UTC)
I'm sure there's a better way to do this directly from the scan. I'd probably do it by placing the table headers in Page space within <includeonly> tags. Then you can use the standard <pages> transclusion without difficulty. —Beleg Tâl (talk) 13:27, 18 August 2019 (UTC)
If the <pages> tag had an 'embeded' variant then I would certainly prefer to use it directly. Multiple <includeonly> tags. seems to me to be the wrong way to go, in terms of simplicity. Maybe the whole structure needs a rethink. ... ShakespeareFan00 (talk) 14:37, 18 August 2019 (UTC)
HTH - Given that the only reason this was sectionalised in the first place, was because it blew out the transclusion limits, I wondered if it was the repeated/nested template calls doing that, having removed one layer of complexity, I rewrote a lot of the repeated calls as part of TemplateStyles stylesheet (which when this work was first done wasn't possible), and the resultant removal of a number of {{ts}} calls meant that the transclusion limits were not being hit nearly as rapidly. Unless I hit the limit for building a table, it may be possible to remove the need for the sectioning altogether and have the table as one LARGE page again :) .ShakespeareFan00 (talk) 07:11, 19 August 2019 (UTC)
While I think using TemplateStyles for table formatting is a good idea, I do not think it's a good idea to pile work-specific CSS into a generic stylesheet like Template:Table class/tableclasses.css. This stylesheet should contain only the most generic classes that are applicable across all works, as it will be loaded/embedded for every page that transcludes {{ts}}. Any work-, scan- or table-specific formatting should go into a dedicated stylesheet. There are very very few classes that truly belong at the global scope. In fact, there's an argument to say there should be no global styles, because, assuming we do use TemplateStyles, they are easy to implement on a per-work/-scan/-table basis, and having a core set of classes globally is fragile: if the central CSS is changed, the changes will propagate to tens of thousands of pages and breakage (subtle or not) might go undetected for a very long time, by which time going back would possibly break pages made in the meantime. Unpicking which pages are and are not affected would be frustrating at best. With CSS only at the work level or lower, the effects are siloed into their own scopes and are easy to search for and adjust. Inductiveload—talk/contribs08:26, 19 August 2019 (UTC)
I do see you concern about the short-titles stuff being highly specific so separated it out. There are some other rules in it that could probably be reworked into more tightly specfied layouts as well , hmm.. ShakespeareFan00 (talk)
Cool, __ntrans probably needs to move out as well.
I'm also not convinced the single-rule classes like "__bb" are necessary. You still need to put "{{tc|__bb}}" on every single element, instead of {{ts|bb}} or style="border-bottom:1px solid black;", so it's not saving typing, and it's going to end up with loads of tiny classes in the global CSS scope. CSS is really good at applying multiple styles (e.g. "__boxc") or applying styles to many specific subelements (e.g. "__col"). But having tons of rules which are essentially just aliases for individual styles seems odd. Especially when you are repeating for table, tr and td.
If you find yourself repeating {{ts}} calls a lot, then it might be time for a work- or table-specific CSS. But only hoist to global scope if you are sure that 1) the style applies to enough works to merit it and 2) the style is well-defined enough that people won't need to tweak in future, as tweaking global CSS is risky.
Perhaps "__t_" might be a better prefix too, where "__" denotes global and "t_" denotes "table CSS". Otherwise, you could get silent collisions in future if, say, some image formatting CSS used "__foo". Making sure they're siloed into "__t_foo" and "__i_foo" pre-empts that problem. It might not happen, but if it does, it'll be frustrating. Perhaps a defined prefix for "work-specific CSS" should be defined too. At Template:Os Lusiadas (Burton, 1880)/errata.css, I used the schema "_oslus", where "_" denotes "work specific" and "oslus" denotes that particular work (which only has to be unique in each context it might be transcluded and is more for documentation ans searching than necessity).
On the subject of searching, a handy way to find pages using a certain class is like this: insource:/__boxc/. Underscores are "greyspace", so they're otherwise tricky to search for. Inductiveload—talk/contribs10:06, 19 August 2019 (UTC)
That was partly a deliberate design decison :) .
Section break to follow up with some CSS questions..
Of course you can. Otherwise TemplateStyles would only allow a single template per page to use it. And then you'd have to pile everything that could possibly be needed on each Wiki into a monstrous CSS file. Which would be called...common.css! Inductiveload—talk/contribs10:47, 19 August 2019 (UTC)
Sorry to be hard of understanding but can you do this:?
You can't do that because that would try to import the content at Template:genericstyles.css tablestyles.css minutiae.css (and pages can have spaces in the title, so you can't naively split on spaces). You also can't repeat the src attribute, as XML doesn't allow that. If you actually wanted to do this, you'd just add multiple calls:
And, yes, you can put this in a template and it will work. Try it out.
As I said in the earlier section, a workable solution, until phabricator:T226275 is done, might be to put CSS common to a work in the "header" of the work in Page namespace, and then also transclude it in mainspace manually. If ProofreadPage gains the ability to implicitly include one or more CSS sheets, the <templatestyles/> calls in mainspace and Page namespace will be pretty easy to clear up, and won't break anything in the meantime. Inductiveload—talk/contribs15:18, 19 August 2019 (UTC)
You may be correct about the "small" classes, but the thinking here (experimentally) was that {{table style/parse}} is a massive switch statement. It's not easy to add new short codes (the same data/logic combination occurs with {{tf/s}} (in the absence of {{div}} {{heading}} {{span}}. By moving the 'style' data OUT of the template logic, it's easier to maintain that logic or protect it, isn't it?ShakespeareFan00 (talk) 10:36, 19 August 2019 (UTC)
Why is that difficult? It's just adding a line like this:
-->|w15=width:15%<!--
Why is that harder than adding this to the CSS?
table .__w15 {
width: 15%;
};
But this begs the question: why is "width:15%" useful to have as a global style class anyway?
I think {{ts}} has gotten a bit out of hand with too many styles being added for niche cases, but it dates from a time years before TemplateStyles was even conceived, when doing everything per-cell is extremely verbose and tedious, and it seemed useful at the time. The worst excesses of {{ts}} can probably be replaced with much more concise CSS targeted to the table, the work or, (very, very, carefully) globally. Any shorthands that then aren't globally useful can be trimmed from {{table style/parse}}. But they aren't especially harmful, because they're not polluting any scope outside the internal switch of {{ts}}. The worst case is that template evaluates slowly, but I don't think even a big switch like that does.
{{ts}} is purely a shorthand template. It could be subst'd quite happily. You can't do that with CSS classes that pull the data in from another document. There's no semantic difference between "{{tc|__bb}}" and "{{ts|bb}}". Both rely on a mapping from a shorthand to real CSS, and both have to be applied per-cell (or per-row). The technical difference is that one is spraying hundreds of CSS rules into the global CSS scope, and {{ts}} is not.
Why not just <div {{ts|ba}}></div>? Since one rarely has hundreds of tiny divs like you do table cells, I question the need for such shorthand anyway. And if you do find yourself needing hundreds of styling calls for divs, dedicated templates and/or TemplateStyles might be a better choice? There's no need to totally eschew HTML, IMO. Inductiveload—talk/contribs13:06, 19 August 2019 (UTC)
I've experimentally updated the first of the Acts in this to use a format more like that used on legislation.gov.uk, and in the process remove the sidenotes in favour of a simpler approach.
Before continuing , I'd like a consensus that this would be a reasonable method for proceeding, and an agreement as to the use of x.0, x. or x.1 to set anchors for singular numbered sections. (They can't use anchors of the form x directly, because those are the anchors the Page numbering script uses.) ShakespeareFan00 (talk) 11:54, 18 August 2019 (UTC)
What I was proposing was 1.0, 2.0 , &c. for sections numbered 1., 2. &c. but 1.1, 2.1, &c. for those that lead directly into a sub section i.e those 1.—(1), 2.—(1) &c. in the original, (with obvious addtions for further sub-levels). Does that meet with approval, because I was wanting this to apply across a number of works. As you I should use what makes sense (and document it I suppose). ShakespeareFan00 (talk) 07:46, 19 August 2019 (UTC)
You'd need to set up a whole dictionary so that it can recognise if a word is made of two other words but is not itself a compound word. I think that's beyond what AWB can do. It's certainly beyond what I can do. —Beleg Tâl (talk) 16:24, 19 August 2019 (UTC)
If the example is truly representative, removing the ts stuff from the table body should be mostly trivial for somebody with a batch edit tool with regex support. Replacing the heading block with {{statute table/titles/header}} is less so, depending on the capabilities of the tool and how much variability there is in that block across pages. --Xover (talk) 18:15, 19 August 2019 (UTC)
Feel free to reason that as I created an overly complex layout, I should do my own cleanup, but if anyone wanted some tedious, mind-numbingly repetitive "cleanup" tasks to just get on with:-
Unique old style Spanish characters used by Mexican conquistadors
I am working on text which has a lot of words written in the unique Spanish used by the conquistadors in Mexico. There are two characters which I cannot find anywhere.
They are "r" and "q" with a tilde(~) or a macron (¯). The characters in our Charinsert are not the ones, and they don't seem to be coded in BabelMap codepoints either. Any suggestions? — Ineuw (talk) 01:12, 19 August 2019 (UTC)
If there is no precomposed Unicode character, then you'll need to use combining diacritic marks. You can most easily do this using {{cdm}}. Thus: r + combining tilde is {{cdm|r|303}} = r͏̃ and q + combining macron is {{cdm|q|304}} = q͏̃. —Beleg Tâl (talk) 01:30, 19 August 2019 (UTC)
This is a beautiful solution, much thanks. I searched for these characters in Babelmap, but r͏̃ and q͏̃ or r͏̄ and q͏̄ are not available precomposed. — Ineuw (talk) 11:16, 22 August 2019 (UTC)
On many pages of the original, the Italics text uses a typeset where the letter "u" looks like a "v". An example is in the first line of the 2nd paragraph. Historia Eclesiastica de Nvestros Tiempos where Nuestros is the word but appears as Nvestros. What should I use in these cases? — Ineuw (talk) 02:39, 25 August 2019 (UTC)
How can I download the source texts of a particular document placed on the Wikisource project?
All documents and books placed on Wikisource have their own source texts in the special Wikimedia mark-up language (I don't know the name of this language, but all Wikimedia projects keep their contents in it, e.g. Wikipedia articles are written in this mark-up language). These sources are the base for all Wikimedia documents, and texts in other formats like html, epub, mobi, pdf and so on, as far as I know, are obtained by converting these sources to the required format.
Is there a way to download these source texts for some particular document as a single text file, a bundle of text files or as an archive file (in zip, rar, tgz or any other popular archive format)? I could fetch these sources manually, but in the Wikisource project a practice is adopted that each page of a document or a fiction book has its own source file with marked up text. In my case the book is large enough and has about 300 pages, so downloading each page manually would require a full day to make the job (as each page source would need to be fetched individually). Is it possible to automatize the task and fetch the files immediately for once without copy-pasting each file by hand?
All the wikis have (had?) a book-making functionality where you can build your own list to be made into a PDF book. See Special:Book though at this time it is undergoing a rebuild.
Use the download function that shows on each work (and the subpages of a work) using the links in the sidebar
Another option, if you really want just the raw wikitext: you can substitute all of the pages onto a single page, and then copy the content from that page.
Pictures In Rhyme moved to Pictures in Rhyme and I really messed it up
I'm so sorry. I really messed this up.
I thought I could move the .djvu file and now I see I made a big mess.
I already also requested images for the book found in Commons be moved from Pictures In Rhyme to Pictures in Rhyme. Index:Pictures in Rhyme.djvu
It had been validated in April but the title of the book was wrong and it caused the main Index page to have red links so I thought it would be easy to fix. That is why I moved it. Is there anyway I can fix this? --The Eloquent Peasant (talk) 19:01, 26 August 2019 (UTC) and contrite
I've moved it back. The name of an Index must match that of the File. The orthography of the Index name does not need to match that of the Mainspace title. The redlinks in the right column of this Index are because they are relative links and are linking to non-existent subpages of the Index. If the links are working in the Mainspace, then there is nothing to do. There is also no need to move the Commons images, doing so will create more work, as we will then have to change the name of every image in the Page namespace. Beeswaxcandle (talk) 19:24, 26 August 2019 (UTC)
@The Eloquent Peasant: It was me who made there the relative links some time ago, as I consider them better than absolute links, despite some of their disadvantages (however, I know some other people prefer absolute links in cases like this one).
Advantage:They work independently of the name of the work. As a result, they do not have to be adjusted e. g. when a work is later moved to a new name for some reason. From time to time I see a work moved to a new name where it was forbidden to adjust the absolute links, which stopped working. This does not happen with relative links.
Disadvantage:They do not work if the page is transcluded outside the main namespace, for example into the Index namespace. They are also more difficult for beginners.
If the red links in the Index page bother you, I can change them into absolute links. – e. g. {{namespace link|''Sisera''|Sisera|..}} would be replaced by [[Pictures in Rhyme/Sisera|''Sisera'']] --Jan Kameníček (talk) 22:50, 26 August 2019 (UTC)
That would be awesome Jan. Did you see the absolute destruction I made with such an idiot move trying to fix those red links? I'm so embarrased. Yes, if you wouldn't mind @Jan.Kamenicek: that would be awesome.--The Eloquent Peasant (talk) 22:53, 26 August 2019 (UTC)
The technical details are that (currently) mediawiki style lists, followed immediately by a <li> tag won't format correctly, as the parser tides up, by placing the end </ul> before the nominal last item, given directly as HTML ShakespeareFan00 (talk) 09:16, 28 August 2019 (UTC)
┌──────┘ Comment that is expected behaviour of lists, you cannot mix wikistyle and li html style. Why you wouldn't just use an asterisk, and try to continue on the next page with something like <noinclude>:</noinclude>text text text * more text text text
It is what we do with continuing ordered lists using # — billinghurstsDrewth12:41, 28 August 2019 (UTC)
Yep, and that was my commentary re ordered lists been doing that in DNB for ages, and that is style matter, not blending of bullet markers. — billinghurstsDrewth13:24, 28 August 2019 (UTC)
Access to individual items on a page?
In one collection I am working on, four related poems are followed by a series of nine notes thereon. To keep these notes intact I have put the four poems onto a single page. Is there any way of addressing the individual poems through labelling, for instance? Although direct access is not essential, there are index entries, and each of these individual poems will need a versions page.
Esme Shepherd (talk) 11:01, 31 August 2019 (UTC)
Thank you but I'm not sure I know how to address an anchor within a Wikisource page. The page will be something like: The Siege of Valencia/Songs of the Cid, which is made up of Index pages from 253 to 271. This comprises: Poem1, pages 253-255; Poem2, pages 256-259; Poem3, pages 260-265; Poem4, pages 266-267, 268 is blank, and Notes to all four poems, pages 269-271. I don't think it practicable to separate the poems with their individual notes, all I'm wanting is to reach the correct place within The Siege of Valencia/Songs of the Cid from each Versions page, that is from Versions of Poem3, for example one is pointed to page 260 after which one can if desired scroll down to find the notes thereto. Do I address it as The Siege of Valencia/Songs of the Cid {{anchor}}?
Esme Shepherd (talk) 18:17, 31 August 2019 (UTC)
Anchors are what's needed, but you don't need to explicitly create them as page numbers are automatically anchors under transclusion. The links will be to the print page numbers. So, The Siege of Valencia/Songs of the Cid#249 for the first poem. The other group of automatic anchors are headings, so if you have used a heading template (rather than a simple formatting one) then The Siege of Valencia/Songs of the Cid#The Cid's Departure into Exile. Beeswaxcandle (talk) 18:37, 31 August 2019 (UTC)
Thank you for your excellent explanation. I knew I had seen some kind of anchor somewhere but couldn't remember where! Now I know how they work. Esme Shepherd (talk) 12:21, 1 September 2019 (UTC)
From the move log: -
"08:42, 1 September 2019 ShakespeareFan00 talk contribs moved page Template:Data square/style.css to Template:Table class/datasq.css without leaving a redirect (This is a table class)"
It looks as though Template:…/….css files can only be moved without a redirect. I know nothing more. Suggest that you pop over to mw: and read about the matter. — billinghurstsDrewth22:39, 1 September 2019 (UTC)
@Prosfilaes: Awesome! How can I incorporate these pages into the existing scan/work? Especially since the wikisource numbering will all have to change...
It will be necessary to either (a) edit the existing DJVU to insert the missing pages, or (b) replace the DJVU with the one that Prosfilaes found. (Option (b) is only possible if the better scan is exactly like the current scan except that it isn't missing pages. If you can't do (a), you can check the documentation at Help:DjVu files, or ask someone at WS:S#Repairs (and moves) to do it for you.) After that, you can update the Index page, and ask at WS:Bot requests for someone to shift all the completed pages to the new locations. —Beleg Tâl (talk) 20:21, 31 August 2019 (UTC)
It's weird - the HathiTrust scan is seemingly only the first half of the IA book, but the page numbering and the very typesetting of the pages in common are exactly the same. But there's 300 pages "missing" from the end of the HathiTrust scan. So I've figured out how to do (b) and now have an updated DjVu file with the two pages inserted into it. I'm a little unsure exactly how to do the "updating the Index page" part though.
Also, I've noticed that pages 72 and 73 got scanned twice; I can remove the extras while I'm doing this—should I? —Dcsohl (talk) 02:39, 1 September 2019 (UTC)
@Dcsohl: Yes, artefacts of the scanning process or that otherwise occur after publication should be corrected: swapped pages, missing pages, extra pages, bad scan quality. The idea is to represent what was actually published as faithfully as is reasonable (with a caveat for certain forms of artefacts of the printing process where we prioritise the author's text over what's a result of the printer's needs). Anywhere where the modern scanning process has caused deviations from the actual published work it will generally be desirable to fix it.The Index: page contains, among other things, a mapping between the logical page numbers (what you see printed in the book) and the physical page numbers of the digital file. When the digital file changes the mapping must be updated to match. So "updating the Index page" means changing this mapping to reflect the changes: book-page 73 is now on the scan-page where the duplicate book-page 72 was, and so on. --Xover (talk) 08:12, 1 September 2019 (UTC)
@Xover: Excellent, that's what I thought, but I did want to be sure. I have another question about this work, though, and that is that the *text* from the missing pages is actually present in the completed work, but there's no source for it. (You'll notice that page 81 on that page is extra-long, but if you click on it to edit page 81 it only has page 81's text.) I'd like to preserve the existing text if possible, to merely proofread/validate it rather than start from the beginning with those pages. Is this possible, before I update the DjVu? —Dcsohl (talk) 13:18, 1 September 2019 (UTC)
@Dcsohl: Text in pages in the Page: namespace are not affected by the contents of the DjVu file: we just make the text from the DjVu available as a starting point when you first start editing a page that doesn't exist yet. Once a page in the Page: namespace is first saved, it is the wikitext and not the DjVu text layer everything relates to.But the text you see on the transcluded work is actually not from the individual pages: it has been inserted directly in the mainspace page. Nothing there will be deleted or overwritten by changes to the DjVu file; and it can be easily copied and pasted where you want it. --Xover (talk) 13:51, 1 September 2019 (UTC)
┌──────────────────────────┘ I think I pulled it off—the index is updated, the pages have been shifted, the two chapters (here and here) affected by the shift have their transclusions updated, I've done a first pass on the formerly missing pages, and things look good to me, but I certainly could use a second set of eyes to do a quick double-check... —Dcsohl (talk) 04:39, 2 September 2019 (UTC)
The dots do not begin after the word "Introduction"; they begin at the very beginning of the line and are covered up by the word "Introduction". It looks like there is a dot right at the end of the word "Introduction" that is covered up, which is why the next dot does not appear until after the space of an additional gap. I have added a line in your sandbox with the word "Intruductio"; you will see that the dots are in the same locations as the line above it, but the "n" is not covering up the previous dot. —Beleg Tâl (talk) 12:55, 1 September 2019 (UTC)
@Beleg Tâl: I am afraid I see something different from you so it must be a browser issue. I am using Chrome and the first two lines are OK, but the following three (including the one of yours) have about 5 cm long gap behind the word "Introduction", after which the dots finally start. Now I have tried to open it in Firefox instead of Chrome, and there it works well, with the dots beginning almost immediately behind the word "Introduction". I have no idea, why the word "Introduction" covers the dots up to the distance of 5 cm behind the end of the word in Chrome. --Jan Kameníček (talk) 14:07, 1 September 2019 (UTC)
I see the dots and the gap before them on the `spaces=3` and `spaces=6` line. It's an interesting bit of CSS trickery, this template is... the row of dots is always right around 300 characters long, with the appropriate number of spaces between each dot as provided in the parameter. So with one space there are 150 dots but with three spaces there are only 75 dots, etc. The row of dots is right-aligned, and the left part is chopped off wherever it runs into some other element (namely the chapter title for the row).
It looks to me like in the chosen font (Arial), a space is much narrower than a period, so with higher space-counts, the line of dots simply doesn't extend as wide as it should, or as it would if you didn't use so much space. The template should probably be modified--my preference would be to use a monospaced font just for the row of dots, but I don't know how it would affect other works already using the template. Alternatively, wider rows could be specified, or have the character count (default 300) be flexible. —Dcsohl (talk) 04:38, 2 September 2019 (UTC)
There are 3 items in the account books of the first five years of Once a Week where a payment was made to an Edward Smith for a contribution. Nothing is known about the writers of these pieces, and the writings are a diverse lot - a travel article, a comic story, and a poem. I don't think it’s safe to assume that they were all written by the same person, but neither do I know that they weren’t. How should I handle creating an author page for Edward Smith? Levana Taylor (talk) 15:59, 1 September 2019 (UTC)
It is one of those issues that has plagued us for years with one-off writers of something, and the amount of trouble we undertake. 1) Do we even bother? Instead override, and make it a black link; 2) Do we individually list, and have three disconnected emtpy (valueless?) pages. Or do we just collect them somewhere in a vague clumping fashion. Is there value in an author: ns page with listings? One could say less likely as it will tell us nothing about the author. With such a common name, I bet that no-one will ever know.
So my answer is based around how will it be managed at Wikidata, and my thoughts are that we would not use "author", and instead use "author name string" (P2093) on the articles. That being the case, let us not put in author: ns and I suggest maybe Portal:Edward Smith or maybe Portal:Edward Smith (eponymous), and we can build around that. *If* we ever did determine that the person was the one person and identifiable, then we move the page to Author: ns and spruce it up.
I certainly have been doing black links for some of the vaguely-known contributors, in which case I write something like this in the notes field: "The magazine’s account books record a payment for this article to one E. West. Nothing is known about this writer." I just struggle to decide which unknown authors get this treatment and which get a page. At one end of the spectrum Michael Terry, writer of travel despatches from Italy, should definitely get a page because he’s distinctive and it seems like he may be identified at some point. At the other end of the spectrum, I totally give up on one-off contributors with names like "E. West" and "J. Wilson." But there are many in the middle. The Portal option introduces a new possibility I hadn't thought about. Can you show me an example of a portal being used as a placeholder page for a writer? Levana Taylor (talk) 23:33, 1 September 2019 (UTC)
We have corporate authors and publishers in portal namespace, (Category:Publishing companies) and more recently where I have identified multiple biographical works about people, I have started building portal pages to hold those (category:People in portal namespace) and I would think that they would have records of their authorship that we would host.. We have been wider-ranging in the scope and approach of Portal: pages, whereas Author: pages have been tied to a model. — billinghurstsDrewth04:27, 2 September 2019 (UTC)
In my opinion, we should create Author pages for these authors unless they really are ephemeral. For example, here are some reasons why an author is worth creating a page for:
We know at least their name and works they authored (as is the case with John Wright)
There exists some scholarly research into their identity (as is the case with F. B. P.)
I personally don't think we should use Portal space for this, unless we believe Edward Smith is a group of people using a single pseudonym (like Eando Binder). However, it should be okay to place it in Author space while noting that there is a possibility that the individual may be a conflation of several individuals -- as is done at Author:John the Evangelist and other pages. —Beleg Tâl (talk) 04:02, 2 September 2019 (UTC)
The problem with author ns is that someone will create an author page for it citing it as one person, not with any uncertainty, and I don't see that it is the right way to go. We already have corporate author pages in portal: ns, so for poorly defined authority it seems better to distinguish. I see your cited page as being different circumstance. — billinghurstsDrewth04:20, 2 September 2019 (UTC)
Not sure what point you are making? Those pages don't fit the criteria that was broached in the subject. There is no evidence for or against that the Edward Smith is one or multiple people, which is why I am suggesting handling it this way. Alternatively we are having three Edward Smith pages with no ready means to distinguish them. — billinghurstsDrewth12:55, 2 September 2019 (UTC)
Just like Author:John the Evangelist, we do not know whether the author in question is one or three individuals. Just like R. Maitland, we have no information about the author except the name and the work itself. Author:Pearl Poet is both of these: we do not know whether the Pearl Poet is one person or several people, and we know nothing about them. Just like all of the above, the page belongs in Author space and not in Portal space. —Beleg Tâl (talk) 13:01, 2 September 2019 (UTC)
People in portal namespace
I do like the concept of Category:People in portal namespace that billinghurst has mentioned above. I would just like to ask, what is supposed to happen if it is found out that a person, who has a portal page, wrote some works and these are added to Wikisource, and consequently also author page for the person is created. Should both the portal and author page exist parallelly? If so, which of them should be connected to the person's Wikidata page? Or should the portal page be deleted (redirected)? Or should the author page be created by moving the portal page into the author namespace? --Jan Kameníček (talk) 15:56, 2 September 2019 (UTC)
If an individual in Portal space is discovered to have authored works, the page is then moved from Portal to Author space. Similarly if an individual in Author space is discovered to have no extant works, the page is moved from Author to Portal space. —Beleg Tâl (talk) 17:45, 2 September 2019 (UTC)
Comment Further categorisation still needs to be resolved, as we have always done straight categorisation of people as the authors and their occupations, origin, etc. It has always been problematic, and left for another day. Similarly our categorisation of biographical works again with the conflict. I know that the EB1911 project looked at a hierarchical naming approach, though it is still internal to the work, rather than universal to the site. — billinghurstsDrewth23:06, 2 September 2019 (UTC)
Unlike DjVu or PDF, the JPG index pages do not generate the index automatically, and must be manually inserted. I do not know of a specific example I can point you to, but I do know it can be done and there are such Index pages on Wikisource. --EncycloPetey (talk) 21:18, 6 September 2019 (UTC)
In the past, when I have used the OCR button on (e.g.) Page:Eleanor Gamble - The Applicability of Weber's Law to Smell.pdf/6, the "Page Body" field becomes temporarily greyed out and inaccessible while the script rearranges text on the page and then it eventually snaps to and lets me interact with the text again, reinserting a cursor. Now, it stays stuck in that greyed out step. Is anyone else experiencing this? I am using Firefox and just (re-)installed uMatrix but I told that (and all my other extensions) to allow media from other domains (mediawiki.org, wikimedia.org, wmflabs.org)... any guesses as to what's happening here or how to fix it? —Justin (koavf)❤T☮C☺M☯17:06, 7 September 2019 (UTC)
@Koavf: See this thread in the archives. It's a problem with the OCR tool that we appear to be dependent on Phe too fix, and they have not yet been able to do anything about it. --Xover (talk) 18:39, 7 September 2019 (UTC)
That's why I have four OCR buttons on my edit toolbar: Tesseract 3 (the default here), Tesseract 4, Google Drive, Google Cloud Vision. Google Cloud Vision OCR is available as a gadget here. The other two can be put into interested users' common.js. Hrishikes (talk) 02:29, 8 September 2019 (UTC)
@Koavf: -- Not like that. Copy it from my common.js. But Google Drive OCR is better; it is faster and also removes the line breaks. You can copy it from my global.js. -- Hrishikes (talk) 03:46, 8 September 2019 (UTC)
@Hrishikes: Thanks very much for the tips too! I am just trying them. The Tesseract OCR has good results, but it is extremely slow. However it is much better to have it now than to wait until the default OCR button is repaired. Did I understand it right that there are two different Google gadgets (Google Drive and Google Cloud Vision)? Some time ago I enabled the Google OCR gadget in my preferences, but it gives quite poor results. Now I have copied something to my commons.js from your page, hoping to try the other Google gadget, but as a result I have got two identical Google buttons giving identical results. How can I get the other one? --Jan Kameníček (talk) 15:42, 8 September 2019 (UTC)
@Jan.Kamenicek: -- My common.js has Google Cloud Vision. You had already got it as a gadget, so the two are identical. You can get the Google Drive OCR from my global.js at Meta (it is called indic ocr by the developer). Hrishikes (talk) 16:07, 8 September 2019 (UTC)
Unfortunately none of these is good with 2-column pages. There are lots and lots of 2-column scans out there, so maybe someone sometime will write a variant of one of these gadgets that is specific for that situation. Levana Taylor (talk) 16:58, 8 September 2019 (UTC)
Yep, I go down to the local university to use ABBYY fairly often. I’m slightly amazed you bought a copy, since it’s so expensive. The ABBYY output that IA provides isn’t too bad, but they didn’t check every page to make sure that columns were being recognized correctly and maybe 1 out of 30 is wrong; plus they didn’t retain italics and suchlike formatting in the output they give. There are other problems, but it’s still probably the best OCR you can find on the web for old texts. Levana Taylor (talk) 17:26, 8 September 2019 (UTC)
From time to time there are some wishlists where WM contributors can express what they need to develop. What about asking for a new OCR gadget that would cover the needs of Wikisource contributors? --Jan Kameníček (talk) 17:52, 8 September 2019 (UTC)
@Levana Taylor: You wouldn't happen to be able to provide me with an example of a "bad" OCR of a two column page and then a "good" OCR result? Ideally of the same page, but that's not very important. --Xover (talk) 02:41, 9 September 2019 (UTC)
@Xover: You ask, you get. Here is Page 38 of Volume 3 of Once a Week run through all 4 gadgets: all 4 of them failed to notice that it was two columns. At the bottom, IA’s FineReader text, which did get it right. Levana Taylor (talk) 04:32, 9 September 2019 (UTC)
@Levana Taylor: Ah, thank you. That is most elucidating. I grabbed that page preview from Commons and ran it through Tesseract 4.1 locally, and added its output (modulo some post-processing for stuff like turning \n into actual newlines) to your samples page. I don't have older versions of Tesseract available for testing so I can't say whether the difference is due to improvements in 4.1 or there are other factors at play. --Xover (talk) 05:13, 9 September 2019 (UTC)
For those who maintain these kinds of tools, this is a promising Web interface. Not sure if the authors of that tool are interested in collaborating but we could reach out to them. —Justin (koavf)❤T☮C☺M☯17:09, 9 September 2019 (UTC)
I've read this and every other post concerning the OCR problem (I reported the bug), and want to thank everyone for the comments and links. Being in a bind, I tried all suggestions but the results are very disheartening and want to voice my opinions for whatever they are worth.
Of all the OCR software I tried, Phe's is the fastest and has the best reproduction of texts I am working on. (A lot of Spanish mixed in the English text).
It is fast and clean. It recognizes mdashes and the "é", character, but not the other accented characters. But, character replacements are consistent. Seeing "4" in the Spanish the text, means an "à" consistently.
I have no idea why would anyone use a web service to OCR a page.
I tried Project Naphta, but it only works in Chrome based browsers, but not Firefox.
Indic-OCR has no instructions. Do they want a single image or a complete book uploaded? Tried a single .jpg image from the Commons and their software crashed with error 505, alerting me that their server is either too busy or it's down.
Locally, when I copied [[s:mul:User:Putnik/TesseractOCR.js]] script to my user namespace, it didn't work. But embedding the link in the Common.js pointing his namespace's copy works. It produces the same quality as Phe's, but very very slow. It took a 1 minute and 40 seconds to OCR THIS PAGE. So, it clearly needs more work.
Also tried the Google OCR from Gadgets but it produces poor results.
So, Phe's OCR script must be fixed. It works for me in the current volume, but not in the other 3 volumes of the series. The problem was found but not fixed, and if it works intermittently, perhaps comparing the function when working successfully, and not, can lead to the solution. Proofreading ~2400 pages of text heavily infused with Spanish, without a good working OCR is ridiculous. The software issue cannot be a great problem because it works in some but not in other volumes. I would have to try check out older .djvu uploads as they relate to the wmf software versions. The wmf software changed and improved over time and Phe hasn't been around for over a year. — Ineuw (talk) 10:01, 14 September 2019 (UTC)
Proofread.js changes and Index files' installation dates.
A random comparison of Index:djvu files' installation dates with the working copy of the OCR gadget, indicates that the problem occurred after March 2019, at which time the Gadget still worked. From what I understand, OCR is part of Proofreading script, but both scripts are continually updated, and the last OCR edit was in January 2019. I was hoping to narrow down the time frame of changes by matching Index file installations and testing the functionality. This is the only thing I can contribute. — Ineuw (talk) 23:58, 14 September 2019 (UTC)
Index form script
I am seeing Bengali script in index form entries of these three indices: 1, 2, 3. Not sure if it is related to my browser/preferences only. Can anyone please check? Hrishikes (talk) 17:53, 8 September 2019 (UTC)
@Hrishikes: I, too, am seeing the incorrect script on certain index titles but in each of your samples only on certain revisions. I am not even logged-in. No other Index: page I have examined (so far - I haven't tried all that many!) seem similarly affected. 114.78.171.14421:38, 8 September 2019 (UTC)
Very strange. Editing the page fixes it. Purging the page fixes it. It's not being done by the javascript that enhances Index:-page editing, nor the one that preloads data from Commons. I think this may be in Mediawiki somewhere, but I don't have any bright ideas as to where or how. It might be worth opening a ticked on it, but since a purge clears it it's unlikely to get a whole lot of effort put into it. --Xover (talk) 02:36, 9 September 2019 (UTC)
(ec.) Declare the positional parameter {{center|1 = all your text}} as its display it was saying that it was missing. Generally happens when there is an equals sign appearing in the other output which it interprets as a named parameter, which then means that the required parameter {{{1}}} is seen as missing. — billinghurstsDrewth23:59, 15 September 2019 (UTC)
I'm having trouble here using a hanging indent with the leader box template and I'm not sure what template I'm supposed to use for the columns with a border between them. Abyssal (talk) 18:54, 16 September 2019 (UTC)
@Abyssal: You can handle the indent like this: {{dotted TOC line||{{em}}cinnabarinus|136}}. The best thing to do is ignore the columns with the border between them and instead create it as one single column. —Beleg Tâl (talk) 19:08, 16 September 2019 (UTC)
In this article for OAW, I had to restrict the text to a fixed width of 500px because of the image that wraps around the text. There are other articles that do the same thing. If I’m setting a fixed width for some articles, should I be consistent throughout the magazine and do it for all of them? If so, what’s the most wiki-friendly way to do so? (I know about default layouts & I don’t think they’re the solution because they alter other things besides just width) Levana Taylor (talk) 19:39, 19 September 2019 (UTC)
@Levana Taylor: I am afraid even then it does not work perfectly. In my case the various paragraphs overlap (maybe due to font-size being a little larger than yours—I do not know for sure?) Perhaps reworking the {{overfloat image}} invocation into something a little more flexible—I am thinking perhaps {{img float|polygon=}} with all the paragraphs rejoined into a continuous text flow wrapping around the image…? 114.78.171.14401:23, 22 September 2019 (UTC)
Thanks for the tip about using the polygon parameter. I haven’t ever done that before and will have to wait till Monday to be able to create an edited version of the image; so if you want to have a try, be my guest. Levana Taylor (talk) 03:51, 22 September 2019 (UTC)
@Levana Taylor: I gave it a go, not being entirely familiar with polygon outlines myself. Then I found Firefox has a point-and-click edit interface for this stuff anyway! Is the result acceptable for you? I was fairly harsh in removing some of your clever effects (I particularly liked text-align-last:justify and was rather sorry to realise it could be dispensed with!) to make the blocks join and attempted to force HTML to do the text flow itself. If I have overdone this please amend further! 114.78.171.14409:43, 22 September 2019 (UTC)
Looks great! I just adjusted the margins around the upper text block.
Pleasingly, this page also looks good if the window width is increased beyond 500 px so that the text flows to the right of the top of the image. That means there’s no maximum with for the text. There’s merely a problem with the image being cut off if the window width is less than 500px, but no reason to force the text to be as wide as the image, so no minimum text width.
The same situation should prevail in almost all pages: The text width does not have to be fixed globally to accommodate certain fixed-width elements, like the image-positioning tables on page 2.43, the certificate on page 7.702, or the side-by-side letter and transcription on page 8. 63. I just put them inside a 500px box and let them be cut off if the window is too narrow, while the rest of the text on the page can be wider or narrower than them. Levana Taylor (talk) 12:49, 22 September 2019 (UTC)
Problem solved (for now, at least) -- see above. However, I would still like to hear if any one has arguments in favor of setting global widths (minimum, maximum, or fixed) -- the arguments against are obvious, in that flexibility of text is one of the great advantages of a digital format. Levana Taylor (talk) 12:49, 22 September 2019 (UTC)
If I may throw in a final 2¢ worth: although the experiment has been going on for a long time now—born as it was prior to mediawiki user adjustable <img> CSS—consider {{FreedImg}} as an example of exploring the possibility of flexible-sized images… Now if polygon support were to be migrated into that template… and judicious application of CSS max-width: applied to the image… It should not be beyond possibility to construct a page such that it would balance (whatever that meant) image and text up to a certain (fixed) limit (say when the image is at its crispest; i.e. native resolution) and beyond that on ever-larger displays rewrap the text component dynamically around the best-possible image…
Come to think of it {{FI|imgstyle=}}… the hooks are already in place if somebody wants to give it a trial? The CSS would not be pretty though! 114.78.171.14405:55, 23 September 2019 (UTC)
"Living authors"
Currently, when an author’s dates in Wikidata are "floruit," that is, properties Work period (start) and Work period (end), they are automatically added to the category "Living authors" here. Is there a way to suppress that? Levana Taylor (talk) 19:45, 25 September 2019 (UTC)
A little calculation: if someone died this year at age 100 and had their first work published at age 18, their first publication would have been in 1937. In round numbers, if someone’s "Work period (start)" is 1935 or earlier, they can’t possibly be alive. Levana Taylor (talk) 19:55, 25 September 2019 (UTC)
My view was either:
2019-70-70 = 1879 (so 1880 to be really sure.) So if an author was born or working before 1880 they are highly unlikely to be alive now.
1996-70 = 1926 - 70 = 1856 so anything published prior to the 1850's is almost certain not to have a living author ( or be in copyright still) (1996 due to URAA) ShakespeareFan00 (talk) 20:14, 25 September 2019 (UTC)
That is the calculation for "PD-old", yes -- if an author published before about 1850, they can't have lived past 1924, so, except for posthumous works, everything they wrote must be public domain automatically. That’s different from whether an author can be classified as a Living Author: there, what matters is whether they can have lived past 2019, not whether they can have lived past 1924. Levana Taylor (talk) 20:45, 25 September 2019 (UTC)
OK, so the problem is related to the also unresolved issue of "Work period (start)" and "Work period (end)" not yet being integrated into the software -- they will eventually be displayed as "fl. start-end" and at that time the living authors problem will also be solved. thanks for the pointer. Levana Taylor (talk) 20:37, 25 September 2019 (UTC)
Yes, I keep trying to find time to get this fixed, but the couple of times I've done so it's not been quick. Oh, and the test-items I was using have since been improved so I had to find more (you can see lots of the test cases are now failing, because there items have since been changed). SamWilson00:44, 26 September 2019 (UTC)
Carrying forward a block center within a split footnote
I have split footnotes with restricted text widths but at the moment these texts do not run continuously. That on the second page begins on a new line. I have tried using block centre/s and block center/e but I have probably got it wrong because this does not eliminate the problem.
For example, at present, I have:
First page:
Body:
<ref follow="p53">{{c|Note 22.<br>''The Bowl of Liberty''—}}
{{block center/s|max-width=500px}}
One of the ceremonies by which the battle of Platæa was annually commemorated was, to crown with wine a</ref>
Footer:
{{block center/e}}
Next page:
Header:
{{block center/s|max-width=500px}}
Body:
<ref follow="p53">
cup called the ''Bowl of Liberty'', which was afterwards poured forth in libation.{{block center/e}}</ref>
These particular pages are:The Siege of Valencia.pdf/68 and 69. There are several other instances within the notes here, e.g. pages 62 and 63, 63 and 64 etc. Esme Shepherd (talk) 21:51, 27 September 2019 (UTC)
Comment As coding is nested, the coding starts and should finish in the ref, not outside of the ref. So ideally what should be occurring with the code is something like
<refname="p53">
{{block center/s|max-width=500px}} All the sections of text on first page<noinclude>{{block center/e}}</noinclude></ref>
which starts and finishes though does not transclude the close, then have on the subsequent page(s)
<reffollow="p53"><noinclude>{{block center/s|max-width=500px}}</noinclude>all your subsequent sections of text follow ... {{block center/e}}
</ref>
which has though does not transclude the open, yet has the close. And yes, it does make the coding a little more complex, — billinghurstsDrewth 23:35, 27 September 2019 (UTC)
I knew I was overlapping templates, which seemed wrong. I see the problem has been cured by omitting the block center/e in the footer of the first page, although the text on the second page looks wrong because it is inset. However, the end result now is perfect, so I have followed suit with all the other splits and published the result in Wikisource. All these references begin on earlier pages within the poem text. Esme Shepherd (talk) 11:40, 29 September 2019 (UTC)
PERMISSION REGARDING USE OF TEXT
Sir
I wish to make a request for using "The Bishop's Candlesticks' by Norman McKinnel for educational purposes. Kindly guide me through the procedure.
Most of our text here is public domain in the US, with a few freely licensed pieces. [The Bishop's Candlesticks] is a British work published in 1908 by an author who died in 1932; I don't believe it's under copyright anywhere in the world and therefore is free to do with as you wish. None of us can give you more permission than that, and this is not legal advice.--Prosfilaes (talk) 10:39, 28 September 2019 (UTC)
If you utilise the epub download link on the left hand sidebar, I believe that you will find that the appropriate credits will be part of the download ("About this digital edition" which is the last page). — billinghurstsDrewth11:20, 29 September 2019 (UTC)
A few problems with an old scan and request for best practices
I’m not sure what you mean by "generate" an SVG image. Adobe Illustrator is one of the major programs to work with SVG (I go down to my local university to use their Adobe software). You can save an existing image as SVG, or, if you want to recreate it with clean lines, add a new layer, set it to semi-transparent so you see the old image, trace over the lines with Illustrator’s line-drawing tools, make the layer non-transparent, then save just that layer as SVG. Levana Taylor (talk) 20:17, 29 September 2019 (UTC)
@Levana Taylor: Sorry, I meant a program that can easily generate SVG graphs from data. I looked for a few online and tried LibreOffice Calc but they seem a little cumbersome. Is there a program (like a spreadsheet program) that can take input data like a table and generate an SVG graph easily? —Justin (koavf)❤T☮C☺M☯20:37, 29 September 2019 (UTC)
Finding a program to output data in exactly that form is unlikely. And even if you did find it, it would probably take more programming to set it up just so that doing it by hand in Inkscape (which is a very, very good free vector graphics program).
If you are willing to essentially write a program to output from data, rather than just do it as graphics, you probably want Octave (or MATLAB), Matplotlib (Python) or TikZ (LaTeX). But it won't be trivial to make this image with any of them. Inductiveload—talk/contribs10:33, 30 September 2019 (UTC)
There are some tables that cross over pages and this is one of those times where print considerations of pagination don't really make sense for digital. E.g. see the text that splits across Page:Eleanor Gamble - The Applicability of Weber's Law to Smell.pdf/55 and Page:Eleanor Gamble - The Applicability of Weber's Law to Smell.pdf/56. On paper, it makes more sense to have the running text broken up with the tables but digitally with one long scroll, it's very jarring. How should I fix this? Should I have a way of inserting divs from different pages in different orders?
I have several moderately complicated tables (e.g.) Page:Eleanor Gamble - The Applicability of Weber's Law to Smell.pdf/49 and I have noticed two problems: one is that the little empty rows that I have at the top are too thick, can someone tell me how to make these rows slimmer and I have several lines broken up by cross-cutting rows. Between the CSS, HTML, and MediaWiki, I'm not sure on how to fix this. Additionally, these tables are not centered.
I have modified the table in this diff. Basically, overall table borders can be done right after {|, rather than on a per-cell basis. "margin:auto" is the secret sauce to centring a table on the page. Inductiveload—talk/contribs20:28, 29 September 2019 (UTC)
(1) It took me some pondering and looking, but now I see why you're looking to generate SVGs: you want to recreate charts like the one reproduced here, based on the original data. Correct? I would imagine it's possible to do so with a program like LibreOffice, but I'm not certain how. (I've successfully produced PNGs from spreadsheets, but not SVGs.) Regardless, I agree that this seems like an ideal way to approach these images (though others may disagree, preferring photographic preservation of the original image). -Pete (talk) 22:20, 29 September 2019 (UTC)
(2) I think it's fine to combine stuff originally presented on two pages into one thing. It's commonly done with images that span pages, for instance, with the map at the beginning of this Wikisource page. I would take a similar approach.
(3) (nothing to add here)
(4) My take: Explain any such decisions in the "notes" field of the header (or perhaps in a template on the work's talk page). The key question is, "what's the source document?" If the source document is a printed book, rather than a scan of a printed book, I think it's fine to reassemble the digital file to better reflect the original book. But it should be explained somewhere a critical reader is likely to see it. -Pete (talk) 22:25, 29 September 2019 (UTC)
@Peteforsyth: That's exactly correct: I want to recreate these data which are perfectly suited for SVG rather than raster graphics. We should not prioritize photographic reproduction of non-photographic images, just like how we don't prioritize a perfectly "typographic" reproduction but a reproduction of the textual content including what it semantically means, not just how it looks. That's to say nothing of how much more accessible SVG is than raster graphics. I monkeyed around in LibreOffice a little bit but couldn't reproduce what I wanted easily. I may need to go back to that. Do you have any feedback for my other issues above or bandwidth to validate any pages? —Justin (koavf)❤T☮C☺M☯22:28, 29 September 2019 (UTC)
Yeah, I think we're in agreement on the best approach. Wish I knew better how to generate the charts in SVG, but I don't. I validated the page associated with that chart, and I'll see if I can do a few more. I'll try to watch this discussion too -- they're good questions, I'm curious what others have to say. -Pete (talk) 22:33, 29 September 2019 (UTC)
@Inductiveload: This is excellent. I've tried using Inkscape (and GIMP and Photoshop and Illustrator) before and it's just confusing to me but I guess I need to learn to make SVG some way other than by hand or via spreadsheet programs. This is very helpful--I'll try making the other two graphs. —Justin (koavf)❤T☮C☺M☯17:22, 30 September 2019 (UTC)
@Levana Taylor: I am uncertain as to the technical reason for this problem occurring but it has some association with mixing Index: space references. You will note the first page is being drawn via Index:Once a Week Volume V.djvu and the latter two (which register no errors here) via Index:Once a Week Dec 1860 to June 61.pdf. You might investigate if an equivalent effect may be achieved which draws all pages via a single index (still using multiple <pages>s should be O.K.)
Alternately, one solution which works (but will like draw criticism!) would be to substitute line 11:
<pagesindex="Once a Week Volume V.djvu"include=4/>
Should a work here be linked to its work item on Wikidata, an item specifically for the Wikisource edition, or the item for the edition which was scanned? Levana Taylor (talk) 15:49, 1 October 2019 (UTC)
I think the edition which was scanned, and the Wikisource edition transcribed from that scan, can be considered to be the same edition. The work itself (as distinct from any edition of that work) is a separate item, linked to the edition-item using has edition and edition or translation of, and linked to the Wikisource {{versions}} or {{translations}} page. —Beleg Tâl (talk) 16:14, 1 October 2019 (UTC)
Where an edition exists, or should exist, then we have an edition item, and wikidata item, so typically we are talking classical literary works (fiction or non-fiction) and we produce VERSIONS page that will generally link to the WD item about the work (and usually the WP article). However, for court cases which we reproduce the court judgment / output are only synonymous to be one version/edition, so those I link directly to the WD item about the case, and fudge the element of the judgment being a separate component.
Then we come to entries and articles that are part of larger literary works and probably either never going to be more than one edition, or evolve through various editions, eg. Crockford Clerical Directory; Who's Who; etc. which don't fit into the model of WD very well, and no-one has a particular interest. With those I just try to maintain a uniform approach, and if someone dislikes what I do, they can bot-remedy it. — billinghurstsDrewth22:04, 8 October 2019 (UTC)
frequently makes reference to paragraph numbers (including those in other chapters).
I think it'd be cool and useful if I could format these references as hyperlinks, which would make navigation nicer...but how can I do it? Couldn't make much sense of the links and subpage documentation for this purpose. --Contrapunctus-1 (talk) 11:04, 8 October 2019 (UTC)
I would suggest that you not strive to format the anchor text as a URL. Firstly, it would indicate to users that they can click on it to link to something else, rather than that they can link to it as an anchor. Secondly, if the text is not formatted as a URL in the source material, then it is not good to make it one in the transcription (unless it's listed as acceptable usage by WS:ANN or WS:Links). —Beleg Tâl (talk) 13:13, 9 October 2019 (UTC)
Fully concur. Anchors are passive, wherever used. If there is a crossreference to add, you know that you have created anchors, and you know that you can easily code for them with wikilinks (as expressed above). — billinghurstsDrewth13:49, 9 October 2019 (UTC)
I went through W:ANN and WS:Links. Some way to copy the URL of an anchor seems to generally be considered useful (e.g. see the headings here or here, which have a link button on mouseover). In the original text, each paragraph is numbered, and I was merely proposing to format the numbers as links - fairly unobtrusive, and it doesn't seem all that different from references. I don't see it as changing the content, but making better use of the facilities afforded to us by the medium of the Web, so better ways to refer to the work are visible to users.
What is the copyright status of works by authors whose death dates are unknown, and whose works were published in the mid-19th century? Is it Wikisource policy to act as if they died between 1919 and 1948 and use PD-70, that is, use an assumed minimum time since death? I don’t know what lawyers in Spain and Mexico would argue as to whether an author about whom nothing is known but their name is to be treated as anonymous, but I take it Wikisource would prefer to play it safe and use a generously-assumed date of death rather than the anonymity rule of going by publication date. Levana Taylor (talk) 08:05, 9 October 2019 (UTC)
When Commons discussed this a while back they landed on publication + 120 years as a reasonable assumption (though some argued for much more) based on some guidance from the US Copyright office. It seems a reasonable rule of thumb for us to adopt: while some authors will have lived for more than 50 years (50+70=120) after publishing something, in most instances that will not be the case.On anonymous works I'm not sure we have a well-established standard for what the threshold is: it is entirely possible that in a legal sense a book that includes an author's name is anonymous when that author name cannot with any certainty be linked to any real world person (for example, if we cannot even determine whether the given author's name is a real name or a pseudonym). I haven't really looked into this, but I'm pretty sure the relevant laws tend to talk about knowing the identity of the physical or legal person and not about whether or not there is some text that looks like a name on the title page as published. On the other hand, if we're pretty sure that the name is a real person but we just don't know anything about them, then that would argue against treating it as anonymous. --Xover (talk) 08:23, 9 October 2019 (UTC)
Of the 1860s authors I’m dealing with, I know the death dates of about 350, and six of those are between 1920 and 1926 (thus, PD-80). That's different from publication+120. Still, if the committee of people who are smarter than me thinks that I can call 1860s publications with unknown author dates PD-old, that’s good enough for me. Levana Taylor (talk) 09:01, 9 October 2019 (UTC)
We only concern ourselves with US copyright, and other countries we tell them that they cannot have a copy. With our criteria of pre-1923 the inclusion the date of death is usually only pertinent for whether we host the scan at Commons or here. That said, I usually try to hunt down authors and get dates, which is why I watch new author creations, and churn away at the author maintenance categories. — billinghurstsDrewth09:48, 9 October 2019 (UTC)
Yeah, that’s perfectly satisfactory for WS, just use {{PD-1923}}. It does leave me puzzled as to how to deal with making a corresponding wikidata item; it seems like there are no exactly suitable items defined yet for the "license" and "copyright determination method" properties. It's a question to ask over there, but honestly, I hardly expect answers any more from questions asked at WD -- there seem to be remarkably few people participating. Levana Taylor (talk) 11:05, 9 October 2019 (UTC)
Is it possible for publications to have an incorrect ISBN number? How would it be possible to track down such a book get the correct number? It seems that the publisher printed the wrong ISBN number. — Ineuw (talk) 21:20, 8 October 2019 (UTC)
@Ineuw: It's not incredibly uncommon, especially with smaller publishers. A common mistake is not properly converting 10 digit ISBN to a 13 digit one, or vice versa, which gives you the wrong check digit. Try searching for the book on WorldCat by name or title, or using only the middle part of the ISBN. Giving us what book details you have might also help. Jarnsax (talk) 21:37, 8 October 2019 (UTC)
@Kaldari: The text layer in the original DjVu was offset (presumably a messup at IA). This can be fixed by dumping the hidden text of each page with djvutxt—which will generate sexpressions to recreate a hidden text page with all structure intact—and then reimporting it at the correct pages using djvused. However, as I didn't have a script for that particular operation set up I've instead regenerated it from the source .jp2 files (at full resolution and with new OCR) and uploaded the new version. If the old OCR was better I can look into preserving that instead, but in my experience that's generally not been the case. While I was at it I also rotated the two foldout pages (pp. 293–294) that were printed in landscape format, mainly because Tesseract does not handle rotated text very well (I think it thought they were in Cyrillic or something). If you would like them in the original configuration they can be rotated back. Please let me know if there are any issues. --Xover (talk) 07:42, 9 October 2019 (UTC)
The updated version is, hopefully, correct. The original had every page's text layer shifted by -1 (text layer one page earlier than the actual page). The problem was in the original DjVu from IA, and not just a symptom of the MW bug triggered by some DjVu files that looks similar (offset OCR pages). --Xover (talk) 05:53, 11 October 2019 (UTC)
I hope this is not too bothering a task for anybody!
I am correct in supposing that all works published pre-1924 without a copyright renewal after that date can certainly be hosted on Wikisource, can they not?
I'm asking because I'd like to import W.B. Yeats' pre-1924 plays from Project Gutenberg, and, as I annoyingly don't know its copyright status, I don't want to painstakingly re-format the whole text, only to find that all (say) thirty-something pages have to go.
Can I ask how to find records of copyright renewals also, so for the future I don't have to bother anybody or worry myself unnecessarily? Thanks in advance, Orlando the Cat (talk) 05:24, 10 October 2019 (UTC)
@Orlando the Cat: Copyright, sadly, is not straightforward, so you'll rarely get a single blanket answer.The closest thing we have is the pre-1924 rule of thumb: works published anywhere in the world before 1924 are in the public domain in the US due to expiration of any publication+95 years copyright term.Works hosted on Wikisource must at a minimum be in the public domain in the US; but works hosted on Commons must also be in the public domain in their country of origin. In the case of Yeats, a lot of his output will have been first published in the UK. The copyright term in the UK is 70 years post mortem auctoris ("after the author's death", abbreviated pma), and so the UK copyright for Yeats' works will have expired in 1939 + 70 = 2009.Pre-1924 works are not subject to renewal (they will have expired regardless) in the US. In the UK the terms have always been of fixed lengths not subject to renewals. I thus don't think there are any relevant renewal checks for Yeats' pre-1924 works.However, works first published in the UK whose copyright had not yet expired there on 1 January 1996 will have had their US copyright restored by the URAA. Since the US copyright term is 95 years from publication, this means any of Yeats' works that were first published in the UK after 1924 are still protected by copyright in the US even if they have since expired in the UK. Such works cannot be hosted neither here nor at Commons.But, of course, there are exceptions to the exceptions (told you copyright was tricky). The URAA restored US copyright after the fact, in 1996, for foreign works whose US copyright had expired due to failure to observe US formalities (notice, registration, renewal). But foreign works that were also published in the US within 30 days of the publication in their home country are, for US copyright purposes, considered to have been first published in the US. They are thus subject to ordinary US copyright rules, including the historical requirements for copyright notice, registration, and renewal; and, crucially, they are not affected by the URAA copyright restoration in 1996. That means that any of Yeats' work that was either actually first published in the US, or was first published elsewhere but published in the US within 30 days, can potentially have expired if it failed to print a copyright notice, failed to register the copyright, or failed to renew it. For works that fall into this category we will have to do detective work in copyright records to determine status. But it is often worthwhile to do so as a surprising number of works have failed to observe one or more of these renewals.However, all that being said, please do not import anything from Project Gutenberg, ever. Gutenberg have a rather lax attitude to reproducing their sources, and will often conflate multiple editions without even bothering to document where the text comes from. And all new projects here really should be scan-backed now. If you want to add Yeats' works then please start by identifying good printed editions of the works, finding and uploading scans of these, setting up transcription projects for them, and then proofreading from these. Gutenberg etexts are plenty well enough hosted and mirrored on Project Gutenberg; we can and should do better than just be another mirror for them. If you need help please feel free to ask. Nothing in the process is actually very advanced, but it is a bit complicated before you've done it a few times. --Xover (talk) 06:57, 10 October 2019 (UTC)
@Xover: Thank you for your speedy, detailed and useful reply!I've had a nagging suspicion that Project Gutenberg wasn't the best place to find reliable sources of texts (the playscripts are such a complex mess), and I only began checking the website once I joined Wikisource; I shall keep your advice doubly in mind. I believe, however, judging from the debates on Wikisource talk:Proofread of the Month, that the Internet Archive is the next-best place to find texts - am I correct?It's a shame Yeats' plays are so difficult to find, otherwise I'd have tried to upload scans of them long ago; this is one of my motivations that I've been wanting to put them online, on a trusted place. I'll have a quick look through existing Indexes, in case there are ones I missed.I suppose I may have to give up my project, if things get too complex, but that's alright - something else will appear which will catch my attention.Thanks again, Orlando the Cat (talk) 07:58, 10 October 2019 (UTC)
@Orlando the Cat: I took a quick look and found a good scan of Yeats' own 1922 edition of his Irish plays at the Internet Archive (Internet Archive identifier: playsinprosevers00yeatuoft). I've uploaded that on Commons as File:Plays in Prose and Verse (1922).djvu. I've also set up a basic transcription project for it Index:Plays in Prose and Verse (1922).djvu. Based on my own experience these are the biggest hurdles to getting started with such efforts. The next step is to proofread the pages of the book one by one, and when that is done, we transclude it into mainspace (sort of as if it were a template) using the <pages …> tag. For a work like this we would typically transclude the front matter onto Plays in Prose and Verse, and each play into subpages like those linked in the table of contents (i.e. Plays in Prose and Verse/Cathleen ni Holihan, Plays in Prose and Verse/The Pot of Broth, etc.). Since these are plays rather than chapters, we would also typically create redirects or entries on versions pages for the play title: Cathleen ni Holihan → Plays in Prose and Verse/Cathleen ni Holihan. Practice varies a bit for when to transclude, but I'd suggest transcluding each "chapter" (play) as and when it is done to start. I'll try to watch your progress and help out when needed; or you should feel free to ask for help here if you get stuck. Proofreading the pages is the big job here; everything else there's usually someone available to help out with. --Xover (talk) 14:11, 10 October 2019 (UTC)
Using Wiki source material for commercial purposes
Dear Wiki source help,
I've got a question concerning the commercial use of Wiki source material. I would like to make a graphic novel based on the text of Alice in Wonderland. My question is whether I can use the text from the novel found on the wiki source page and then publish it for commercial purposes?
Best regards,
Charles
Hi Charles. The texts listed at Alice's Adventures in Wonderland should all be in the public domain worldwide. Wikisource generally does not assert any additional copyright in the texts we host since they are mere transcriptions of the original (other terms apply for other parts of the website, but they are generally on the free side; do be aware of that though).To the degree any independent copyright exists those parts are dual-licensed (you can pick either license depending your preference or needs) under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY-SA) and the GNU Free Documentation License (GFDL). The choice is up to you (and your lawyers), but I would usually assume CC BY-SA to be the easiest to work with. The "BY" bit refers to a requirement to attribute the source (i.e. the Wikisource contributors, typically by a link to the page here you got it from), and the "SA" bit refers to a requirement to publish derivative works under the same license.But as I said, you generally do not need a license to use the text of Alice in Wonderland as the text itself is in the public domain since its copyright has expired. We would always appreciate acknowledgement of the work our contributors have performed, of course, but that is as a mere courtesy. --Xover (talk) 09:48, 11 October 2019 (UTC)
Hi Xover,
Thank you for your reply and I'll def. refer to Wiki source and its volunteers when the text is done. Btw. I just realized something Alice in Wonderland is an English text. However, is the same true when it comes to an American text from the same period and the author died around the same time?
To be clear: I'm not a lawyer, and this ain't legal advice. Ultimately you'll have to consult a real lawyer to get those determinations!That being said, Wikisource strives for all its texts to be freely and safely reusable, including for commercial purposes, and to that end expends quite a lot of energy on copyright determinations when potential issues are raised (we do not pre-vet contributed texts). When we do there are some rules of thumb regarding copyright we have found useful. The most applicable one based on your question is that anything published anywhere in the world before 1924 will be in the public domain in the US due to its term of copyright protection having expired (generally 95 years after publication). That guideline is derived from US copyright law, and Wikisource as such requires only that a work is freely licensed or in the public domain in the US (where the servers are hosted). For your purposes you may also need to care about the country in which the work was first published, and the copyright regime in the jurisdiction in which you yourself are located. If you intend to commercially publish a derivative work internationally, your publishing partner may have additional requirements. As a rule of thumb, most (but not all!) jurisdictions have copyright terms that expire 70 years after the death of the author (vs. 95 years after publication in the US). Depending on the work in question and the jurisdictions involved the answer to that question will vary. --Xover (talk) 11:23, 11 October 2019 (UTC)
Bishop of Hereford: John or Thomas?
It seems that the bishop John Tresnant, author of The Process of John Tresnant, Bishop of Hereford... is the same person as John Trevenant mentioned by various sources. He calls himself John too in the mentioned text. What confuses me is that Wikipedia and other more sources call him for some reason Thomas Trevenant, while I did not find any source mentioning both names and confirming clearly that John Trevenant had also another name Thomas or vice versa. May I ask for help what the real name of the person is? Is it possible that the sources who call him Thomas are wrong? --Jan Kameníček (talk) 20:32, 11 October 2019 (UTC)
What a great puzzle! So far I've found that Henry Wright Phillott refers to him as John in chapter 10 of Hereford[21], but as Thomas in chapter 11 of the same work. So you're not the first person to be stymied by this :) —Beleg Tâl (talk) 03:55, 12 October 2019 (UTC)
As it seems that he called himself John, so I called his author page John Trevenant, but it would still be useful to find out whether the Thomas version is another name of him or a later mistake, copied by various sources since. --Jan Kameníček (talk) 18:32, 12 October 2019 (UTC)
Thank you very much. It really seems that some confusion happened later and modern sources including Wikipedia keep copying it one from another... --Jan Kameníček (talk) 11:39, 13 October 2019 (UTC)
I agree. In fact, I have been unable to find any mention of "Thomas" that predates the 1888 work by Phillott that I linked above, so my current hypothesis is that Phillott himself is the cause of the confusion. The mistake proliferated widely, however; even appearing in "Ancient Diocese of Hereford," in Catholic Encyclopedia, (ed.) by Charles G. Herbermann and others, New York: The Encyclopaedia Press (1913) —Beleg Tâl (talk) 14:10, 13 October 2019 (UTC)
Note that the enwp article is now at w:John Trevenant. According to Ealdgyth (courtesy ping) who created it (and a lot of the other enwp articles for bishops of that era), the "Thomas" in the article was a mistake (possibly even a cut&paste error). The source cited in the article (Fryde, et al.) uses "John". --Xover (talk) 14:53, 13 October 2019 (UTC)
In Once a Week, some poems are printed with quotation marks floated, others without, and there seems to be no rhyme or reason as to which (different typesetter working that week, maybe?) So far, following Encylopetey's advice, I’ve been entering them following whichever practice it is in the magazine. But Billinghurst's remarks about us not being beholden to old printers got me to think that I ought to standardize; after all, all other formatting is being standardized throughout the WS edition of this magazine. Agree? And I think people will be telling me I ought to never use them -- after all they’re fiddly (especially since I’m using curly quotes) and I suppose, depending on how it’s done, it’s possible some browsers might not render {{fqm}} correctly. I have a preference for using them, but not a strong one. Levana Taylor (talk) 05:17, 17 October 2019 (UTC)
As someone who used to do text layout for a living, I find punctuation that isn't hung very ugly and so I have a strong preference for floating initial quotation marks (where the line doesn't start part-way in). Doing so gives a strong visual line on the left of the poem and adds to the professionalism of the look. Thus, I recommend that, where possible, you hang the quotation marks. {{Fqm}} was designed for this purpose, particularly when used with {{block center}} and <br /> on line ends. Beeswaxcandle (talk) 07:27, 17 October 2019 (UTC)
I would generally follow what is in the work, though omissions and discontinuity on a page can be problematic. I wouldn't object to a consistent approach. For DNB we convert the book listings from a streaming list to an <li> list as it greatly improves readability. We are not pressed for space as the publisher of DNB clearly wasn't wishing for white space. — billinghurstsDrewth11:34, 17 October 2019 (UTC)
Hilfe beim Veröffentlichen mit WikiCommons und WikiSource
Hallo liebe Wikipedianer,
in meinem Besitz befindet sich ein kleines Notizbuch von meinem Ur-Ur-Urrgroßvater, das ich gerne veröffentlichen möchte.
Von den Seiten des Notizbuchs habe ich Scans erstellt und diese bereits bei WikiCommons veröffentlicht (siehe Georg Heinrich Hoffmann, Waterloo)
In mühevoller Arbeit habe ich zusammen mit meinem Bruder die Currentschrift von 1815 transkribiert, der Text liegt nun als Word-Datei vor.
Nun möchte ich gerne die Originalhandschrift (Scans) mit der Transkription verbinden. Wie gehe ich dabei vor? Eine kleine Bedienungsanleitung wäre toll.
DANKE! —unsigned comment byDitero (talk) .
I have uploaded File:The Bohemian Review, vol2, 1918.djvu to Commons. Unfortunately, when I was converting the file from .pdf to .djvu, two pages got blanked for some reason. I tried to convert it several times using two different online converters, but the result was always the same. So I extracted only these two pages and tried to convert them separately, but they got blank again. May I ask somebody to replace the two blank pages with [22] (behind page no. 80) and with [23] (behind page no. 92), I am unable to convert these into .djvu.
I recently found the full text of Entick v Carrington ([1765] EWHC J98 (KB)) (decided at 1765) on [24], but I am not so sure about how to import the verdict, provided that I am not really professional in these case laws. Can anyone inform me how to do this? Many thanks.廣九直通車 (talk) 02:55, 5 October 2019 (UTC)
@廣九直通車: It is pretty much going to be a copy and paste of the text, then some formatting, with appropriate references and sourcing. There isn't a lot we can do that is different. Then it is the curatorial aspects outside of main namespace. Listing on portal pages, wikidata item, possibly links from enWP, NO author page in this situation. There are plenty of examples below category:case law, especially from US, to use as comparisons. — billinghurstsDrewth22:16, 8 October 2019 (UTC)
Now I have imported the text at Entick v Carrington, would anyone proofread the text? Also, I cannot find the cases and legislation at the source page. Can anyone explain how I can find such information? Many thanks.廣九直通車 (talk) 12:20, 19 October 2019 (UTC)
@Crocojim18: Start with Help:Table and then buzz again with questions. In short, we open the table in the first page, then subsequent pages it is opened in the header (not in the body), and we don't close the table in the body until the last page of the table (we close it in the footer). There are some formatting tricks that we need to undertake due to how mediawiki behaves. — billinghurstsDrewth16:10, 24 October 2019 (UTC)
What's the normal procedure for handling advertising pages, for example Page:Amazing Stories Volume 01 Number 02.djvu/3? Are we actually supposed to transcribe and transclude them? Is it OK to leave them out and just mark them as "Without text"? And if you do that, can you still mark the work as fully Validated? The only documentation I found related to this is Wikisource:What Wikisource includes#Advertising, which just says that "Advertisements that are part of a larger publication are acceptable." Kaldari (talk) 21:57, 16 October 2019 (UTC)
Totally OK to leave them out and not transclude them. I think there is a a guideline somewhere that spells this out, but I'm having trouble finding it too. Look to Popular Science for examples. -Pete (talk) 22:02, 16 October 2019 (UTC)
Also, is it necessary to transclude half-title pages AND title pages, or can you just transclude the title page and omit the half-title? Kaldari (talk) 00:03, 17 October 2019 (UTC)
Sorry, I was going from memory and I must have been mistaken. I've seen a number of texts where advertisements were not transcribed. The guidance I remember receiving is that the ads are not generally considered part of the text itself, they're merely an artifact of the way it was published. But I'm not sure if that applies to FT status or not. I will try to poke around and find a good example, unless somebody more knowledgeable stops by :) -Pete (talk) 00:46, 17 October 2019 (UTC)
In the magazine I’m working on, I’ve been leaving out the small-type snippets (one or two sentences) at the bottom of the last page of some issues that say "a new serial will begin next issue…" or the like. I don’t even know where I’d transclude that. It’s not part of the last article in the issue, and it just seems ridiculous to create an entire transcluded page for such a thing. Levana Taylor (talk) 01:31, 17 October 2019 (UTC)
Levana, if transcribing that sort of work, you could just wrap the extraneous text in <noinclude> if it should be excluded from transclusion. Alternatively stick them in the footer of the work if able. We are in control here, not slavishly beholden to a printer from 100 years ago. Someone can look at the scans if they want those bits. — billinghurstsDrewth04:01, 17 October 2019 (UTC)
Yes, that is my thought exactly, and I have been doing exactly as you say -- putting that stuff in the footer. It is not part of the substantial content of the magazine. Levana Taylor (talk) 05:06, 17 October 2019 (UTC)
[A tangentially-related aside:] I enjoyed reading and transcribing The Souvenir of Western Women, which had a ton of really interesting stories and photos. But I was frustrated that it was difficult to distinguish ads from editorial in a few places. It was gratifying to find that a contemporaneous review of the book in the Oregon Historical Quarterly faulted the book for exactly that reason! -Pete (talk) 01:35, 17 October 2019 (UTC)
Comment The advertising material, front matter, and end matter (collective) is not considered part of the work of the author, though we do consider it part of the published edition. So we rate the proofread & validated status based on the work of the author. So no requirement for any person to do the advertising to publish a complete work. However when we look at the scan, and its rate of transclusion, we will say 1) Fully, 2) Not advertising, 3) Not/unchecked. It was later done this way so where someone did proofread the advertising, we can reproduce it as required, as it does have good social interest, plus it often has valuable information about authors and their works. Some explanatory text at Category:Fully transcluded — billinghurstsDrewth04:03, 17 October 2019 (UTC)
@Kaldari: Two ways that I can read the question, so I will answer both
Proofreading status is just a status of what we do to a page, if you don't wish to proofread it, then don't. Some have blanked the pages where they don't wish to work with those page, especially with serials where the advertisements are pretty general. We haven't argued or changed their assigned status, and it probably reflects where advertisements are interspersed through the work as well as front and back. I cannot say that I have seen a disagreement between parties on such a decision.
Transclusion status of category:not transcluded is used to indicate that a page is not transcluded into a work, and that can be applied to a proofread or validated page. With these there can be differing approach on whether it can go into a work or not, but it is mostly shrug and move on.
If you think that a page should be specifically excluded, I would suggest categorising in body as "not transcluded" and if potentially controversial, drop a note on the related Index: talk page of why. [Note that we categorise in the body so we can see if pages to be excluded end up being transcluded. Over the years I would have removed 50-100 and non-controversial in that aspect]. For the work in question, I don't know as I would need to see what else has been decided for similar pages. Marking as problematic and moving on would be my choice. I would never transcribe it, nor bother with it. If there was considered value, then I would be sticking the image in as "front matter". If someone bothered to transcribe, then bless their little cotton socks, what diligence. — billinghurstsDrewth20:33, 17 October 2019 (UTC)
Comment In response to @Peteforsyth:'s question about FT: because advertising material is not part of the work of the author, validation and transclusion are not required for giving a text featured status. Beeswaxcandle (talk) 07:30, 17 October 2019 (UTC)
To come back to Kaldari's original question about documentation -- while the advice of veteran users here is sensible and consistent with what I've heard in the past, I'm not seeing any links to guidelines or policies. My own search of [[Wikisource:]] and [[Help:]] namespaces was no more fruitful than Kaldari's. Do such policies and guidelines not exist? If not, any advice about how to go about creating them? -Pete (talk) 17:38, 17 October 2019 (UTC)
“
Wikisource does not collect advertisements concerning any type of work that are not publications themselves. This includes information about works that have just recently been published, or are protected by copyright, or even those that are in the public domain. Advertisements can take on a number of forms, but the most common ones are written comments or external links.
Note: Advertisements that are part of a larger publication are acceptable.
Philosophically we focus on the works. In ancient times we outright said don't worry about the advertising, and even in some early works the advertising was zapped from the scans. Though some proofread it and wished to do the advertising, so then who are we to say that it is wrong, and we allowed for it. So then it becomes how to present the advertising once it has been proofread, hence why we have front and end matter as generic catchalls.
To also remember that some of the book catalogues are generic and would have been reproduced hundreds of times in a year at the backs of books, so we simply leave it at user discretion.
Is this documented beyond this forum's archive … no idea. It hardly ever comes up as a question, though there may be some light commentary in user talk: ns. If you think that it needs to be, then find the right spot, and suggest some text. — billinghurstsDrewth 20:49, 17 October 2019 (UTC)
Since yesterday, when I'm not proofreading Yeats or "The Coxon Fund", I've been inspecting various Charles Dickens scans; I came across the scans for Our Mutual Friend (original link: Index:Dickens - Our Mutual Friend, ed. Lang, 1897, vol.1.djvu), and seeing how they were in the "Works of Charles Dickens" series (of which 5, Pickwick to Nicholas Nickelby, have been correctly titled (e.g. "Works of Charles Dickens, ed. Lang - Vol. 1" and so on, as opposed to Pickwick, ed. Lang, Volume 1/2 and so on)), I stupidly moved it to "Index:Works of Charles Dickens, ed. Lang - Volume 23.djvu", before I realized that: 1., the file is not moved along with the index; 2., the file itself cannot be moved; and 3., my edit refuses to completely undo.
Is there anybody skilled enough here who can remedy this situation? Thanks in advance!
(Once/if the catastrophe is fixed, I'll just stick to Yeats, "Coxon Fund" and perhaps PotM, so nothing in a similar vein can happen...!)
Problem solved; in a flash of inspiration I redirected the new index back to the original title. Many apologies if I have caused a great deal of trouble for people in those two agitated hours! Orlando the Cat (talk) 05:48, 30 October 2019 (UTC)
@Orlando the Cat: Don't worry about it! This stuff is not at all intuitive and we've all been there. There is also very little you can do wrong that cannot be undone relatively easily. But as a general rule of thumb, renaming pages in File: or Index: namespaces is typically not worth it. So long as no (or very few) pages in Page: have been created it can be done when there is good reason, but it is always a pain and rarely worth the effort: any File:/Index: can be transcluded to a sensible name in mainspace which is what our readers will see.Oh, and don't let a little snafu scare you off from experimenting and trying to do good things. No harm was done and this is how we learn (and there're such a lot of odd nooks and crannies to learn on Wikisource). --Xover (talk) 06:47, 30 October 2019 (UTC)
Navigation arrows are not displayed in Vector skin
With the Vector skin, the "Previous", "Next" and "Up" navigation arrows are not displayed. But a narrow space of their location still shows. It's possible to navigate by clicking on the space. — Ineuw (talk) 07:46, 31 October 2019 (UTC)
This nasty problem shows up in other language Wikisources as well! Has there been an update or so, that caused this change? --Dick Bos (talk) 08:54, 31 October 2019 (UTC)
If I understand the patch correctly it amounts to a change in CSS attributes only. How can this be highlighted such that it is not removed in the next round of improvements? Is there some kind of central go/no-go test case set which may need an update for ProofreadPage? 114.78.66.8204:15, 1 November 2019 (UTC)
In particular, single column tables. What is the correct syntax?
The page I am currently working on is 'Felicia Hemans in Death's Doings.pdf/1'
My syntax is clearly wrong because although it looks to be centred in preview, this is not how it turns out when transcluded, in 'Death's Doings 1827'. Here it is not properly centred.
I thought I might find the solution in previous work, but I notice that although most of these index columns were previously centred when I created them, they are so no longer.
If I had the correct foolproof syntax, I could put all of these right. Can you help me please?
Esme Shepherd (talk) 16:06, 31 October 2019 (UTC)
p s: Perhaps I don't need wikitable at all. This seems to work:--
Thank you. I originally copied from another file and I have no idea which that was now. All those percentages seem to be very variable and now I can put them all straight. One question though - is there any control for width other than adding some padding to the text with 'gap'?
Esme Shepherd (talk) 22:59, 31 October 2019 (UTC)
@Esme Shepherd:Comment We tend not to push absolute sizes, and if we can leave fluid, that is our preference. As we are coding for such a width range of screens: wide screens, to mobile phones, so we have tended to use the left margin as an anchor if we truly need an anchor, then have the right margin to be its own relative positioning. This means is as free as we can go.
The scan that we're using for the 1907 edition of Alice's Adventures in Wonderland (with illustrations by Charles Robinson) is missing 2 pages, which were likely removed from the original book before it was scanned. Efforts to locate another scan of the book have been fruitless. However, we do have a copy of the color plate that was found on Flickr (File:Alice's Adventures in Wonderland - Carroll, Robinson - S205 - The whole pack rose up in the air.jpg), and the missing text is known (and saved in an HTML comment [25]). In order to complete the transcription, it seems the best course of action would be to add 2 blank pages to the DjVu file (after page 203 (or 173 according to the book pagination)) that could be used to hold the missing text and color plate, so that they could be transcluded into the main namespace. It would be best if the blank pages were totally white (not yellow like an actual page), to make it clear that they are only placeholders for the missing pages. Kaldari (talk) 17:20, 30 October 2019 (UTC)
I have the tooling to do this, but I'm not sure when I'll be able to get it done (might not be until next week some time). But we'll also need someone to shift the existing pages to compensate for the inserted ones, and I don't have the tooling for that. Since this work is complete and transcluded, once I upload the modified version the mainspace work will be broken until the pages are shifted, so that needs to be coordinated. --Xover (talk) 07:57, 31 October 2019 (UTC)
@Xover: I've recreated the two missing pages from images found on Flickr and Scribd. These should be inserted to become pages 204 and 205 of the new DjVu file. Kaldari (talk) 00:37, 6 November 2019 (UTC)
Hello, I am transcribing Ghalib's divan and am wondering how best to represent the text in type. I am having trouble getting the line breaks for the poetry to be consistent. Line breaks in this type of poetic text (ghazal) are traditionally represented horizontally across the page with a caesura in the middle, rather than vertically down the page in English texts.
For example,
The text should not display like this:
اٴے شہنشاہِ آسماں اور رنگ
اٴے جہاندارِ آفتاب آ ثار
It should display like this:
اٴے شہنشاہِ آسماں اور رنگ /اٴے جہاندارِ آفتاب آ ثار
In Index:Atalanta - Vol. 2.djvu, for example on p. 21, I'm getting an error in my browser's Javascript console that "TypeError: success is not a function. (In 'success()', 'success' is an instance of Object)" (triggered inside ProofreadPage's image zooming code) and the OCR text layer in the DjVu doesn't get loaded into the edit field. On other works I've tested I do not observe this.
Latest Firefox on Windows 10. Not sure how to access the Javascript console, but I do have the problems I think you're describing -- OCR is not loaded (and I take it there is OCR in the original), and I can't zoom on the page image. -Pete (talk) 20:06, 17 October 2019 (UTC)
I ran into this again on a different file too, so I've filed a bug on it in Phabricator. @Tpt: I had trouble tracing this backwards so if someone actually familiar with that code could take a look it would help get us closer to whatever is the root cause here. Based on the code in ext.proofreadpage.page.edit.js I really don't see how success can end up as anything but undefined or function. --Xover (talk) 11:03, 10 November 2019 (UTC)
Update: it looks like tpt and samwilson just checked in a fix for this javascript error (unknown if that's sufficient / the root cause for the missing text layer) so that should disappear with the next Mediawiki deployment (happens every two-ish weeks I think; look for version "1.35.0-wmf.8" in the Tech News posted at WS:S). --Xover (talk) 14:31, 14 November 2019 (UTC)
Seeking advice for making better DJVU files
I created a DJVU file for an issue of The New Northwest. Here is its index page (which links to the file): Index:The New Northwest, October 27, 1871.djvu As you can see, the file has a bit depth of two (black and white, no shades of grey). It's readable, but not very pretty.
@Peteforsyth: You want to use JPEG as the intermediate format: DjVuLibre supports JPEG directly, it's just JPEG 2000 (.jp2) it doesn't handle. Convert the files using GraphicsMagick using gm mogrify -format jpeg '*.jp2' (you may need to adjust the commandline syntax for operating system differences). Then use c44 page-1.jpg page-1.djvu to turn it into a DjVu, and djvm -i wholework.djvu page-1.djvu (and … page-2.djvu, … page-3.djvu, etc.) to add each page to a multipage DjVu file.Or you can ask me to do them and I'll get you DjVus with an OCR text layer generated with Tesseract (which may or may not be of sufficient quality to be worthwhile). I've got some custom tooling for this that is… not user friendly, let's put it that way… which converts Tesseract's hOCR output into DjVuLibre's sexpr format and adds it to the DjVu. I've generated a new DjVu using this method and uploaded it over File:The New Northwest, October 27, 1871.djvu so you can take a look.PS. The mechanical process of scanning and assembling a DjVu does not create a new independent copyright (this is Bridgeman Art Library v. Corel Corp., aka. the "sweat of the brow doctrine"), so there are no rights for you to release under CC0. Commons uses the {{PD-scan}} wrapper template to indicate this. Instead, the file should be tagged with the licensing that applies for the original work, which I am guessing is public domain in the US due to pre-1924 publication? If so, I would suggest using {{PD-scan|PD-old-70-expired}} (which also asserts it is public domain in pma. 70 countries) or {{PD-scan|PD-US-expired|country=US}} (which only asserts it is PD in the US; the |country=US bit is to suppress the warning that Commons requires works to be PD in both the US and the country of origin, since it doesn't apply when works are first published in the US). For works published more than 120 years ago Commons accepts an assumption that the author(s) died more than 70 years ago and that pma. 70 copyrights have thus expired now, in the absence of specific evidence of the author(s)'s vital dates, so this work can be safely tagged with the former too. --Xover (talk) 04:30, 18 November 2019 (UTC)
Why not use PGM as the intermediate format? It won't work if you're trying to use cjb2, but c44 will take pgm or jpeg, and there's no reason not to use the lossless format as input.--Prosfilaes (talk) 20:12, 18 November 2019 (UTC)
Ah, thank you both -- very helpful. I appreciate your offer to make these for me, @Xover:, but I'm also trying to learn myself -- so I may do a few more small files like this just to get the hang of it.
Glad to know that PBM, PGM, and JPG files work in DJVU, but JP2 and PNGs don't. I've updated the Help: page linked above to state this.
You're quite right about copyright, stupid mistake. I can only guess that with all the "work" I had to do to produce the files, I momentarily felt that it must add up to something significant :) (Either that, or I just clicked the wrong box.) I've corrected the tag.
Hmm, even though my file is more than twice the size of Xover's, it is pretty much illegibly blurry. I'll revert the file...maybe I need to manually specify a higher resolution when creating the PGM? -Pete (talk) 03:34, 19 November 2019 (UTC)
On second thought -- neither file is truly legible. Open to suggestions about how to improve this. I tried with the setting "-dpi 300" which should be plenty, but it produced a file of exactly the same size (which I imagine is more or less identical -- I need to get a DJVU viewer for this computer to be sure.) -Pete (talk) 00:21, 20 November 2019 (UTC)
Perhaps someone can suggest a way of doing this that is less template intensive? I was previously told to use {{ditto}} by other contributors here. Would sectionalising it by inital letter be a possible solution? ShakespeareFan00 (talk) 10:26, 6 December 2019 (UTC)
We have been through this over and over and over. These templates were set up as experimental and they stopped being developed. They are complex table of contents templates, and they are being used here for an extensively long index. View the source and tell me that what is being delivered is okay. How many concatenated tables is reasonable? KISS. What are the expectations here? — billinghurstsDrewth00:13, 7 December 2019 (UTC)
Let me just reemphasise and amplify what billinghurst says: {{TOCstyle}} and friends ({{dtpl}} in particular) that try to make dotted TOCs simply should not be used! They emit such massive amounts of markup that you will run into trouble on any non-trivial work. {{ditto}} is far more reasonable, but it will also exacerbate the problem when there are a lot of invocations of it (which will often be the case on such pages).Use simple tables for tables of contents, and rethink your approach if even that starts to get complicated (if you start having to style each cell of the table, say). For indexes and such you shouldn't even be looking at table markup if some other approach will do (perhaps just a line of text followed by a right-floated page number?).Tables of contents and indexes are one area where you should definitely be looking to simplify as much as possible, even at the cost of fidelity to the original, because they run into this technical limitation, are too complicated and time-consuming to reproduce exactly, and become impossible to troubleshoot or modify later.As for this particular work, I think just dropping the "D" model (the dots) will help. I would also suggest switching completely to a plain table because it will make the pages less complex to edit. Use a {{gap}} for the indented rows instead of that |row165style=padding-left: 1em| stuff. The uses of {{ditto}} are probably fine. Use {{sc}} or {{ts|sc}} for the small-caps. --Xover (talk) 09:26, 7 December 2019 (UTC)
May be the case of less worse, but never certain that the use is better. What are you seeing as the benefit? Slavishly trying to replicate a page? — billinghurstsDrewth12:39, 7 December 2019 (UTC)
Benefits I see are: 1) Modern style of TOC does not go well together with the rest of the work which is usually a replicated old book including its old style and layout; 2) dots leading from the chapter name to the page number help me to get the number right. --Jan Kameníček (talk) 16:01, 7 December 2019 (UTC)
Restyling it using simple tables, would either involve a LOT of inline CSS, or use of {{ts}}, which would again potentially hit the limits previously encountered. I will consider sectionalising it.ShakespeareFan00 (talk) 14:49, 7 December 2019 (UTC)
Hmmm.. I'm considering walking away from this. Perhaps someone else can come up with and comprehensively document a single approach that doesn't overrun the limits, so that I am not running around changing thing back and forth, and we end up having the exact same discussions continually because no-one (apparently) has the time or expertise to maintain templates or modules that are more complex than simple parameter substitution...
Generally you should be able to define the first page, as if 12=6 then 7=1. Those are the page numbers, they don't magically start at somewhere like 6. — billinghurstsDrewth10:44, 1 December 2019 (UTC)
Created in an attempt to reduce template calls, but Mediawiki moans about it being the wrong content model, or refuses to invoke the style as intended.
Can someone review this or suggest a better approach? I wrote this and the templates which utilise it, so I didn't have to write a number of {{smallcaps}} calls for what seemed to be a predictable format.
The example is a straightforward description list, representing a side title, and 2 paragraphs... When I wrote a near identical example in a JS fiddle to test out the concept, it worked without concerns. When I attempt to implement the same code in the Sandbox (and sandbox.css) it doesn't.
The example was a MINIMAL test case, to see if the approach could be made to work. What the stylesheet should be doing is converting the layout so that the first DT item is to the side, with the first DD item next to it.. The next DD item would then be left aligned with the first.
This was an attempt to come up with a way of paritally replacing {{numbered div}} with something that I thought Mediawiki would actually be able to cope with. It seems that I was mistaken in assuming it could do this.
Position change of the Charinsert bar and one other question.
The Charinsert bar reverted to below the textbox and I always had it above, between the .djvu and the textbox. Is it possible to reset it from my vector.js?
When in edit mode, the .djvu text image is very large. Is there a script with which I can modify the default page size? — Ineuw (talk) 01:04, 12 December 2019 (UTC)
Hello. Apologies if I am using this space for a non-wiki topic, but I was wondering if anyone knew the answer to this question: In Portuguese, a person "catches" a flower (apanhar) rather than picks one... My question is, what other languages might use a similar translation? to catch a flower? Is it used in French? Greek? Spanish? I ask because Florence Earle Coates uses the term "catch flowers" in her poem In a College Settlement, and I don't believe it is generally used in English, is it? Thanks for any insight, Londonjackbooks (talk) 04:33, 16 December 2019 (UTC)
Not in French, Occitan, Spanish, Catalan, or Italian. I do wonder where the Portuguese idiom came from—it must be fairly new if not shared with other Romance languages. Levana Taylor (talk) 21:57, 16 December 2019 (UTC)
Well, en.wikt has "collect, gather" as the first listed meaning of the Portuguese expression apanhar, the second one is "grab, pick up" and only the third listed meaning is "to field (intercept or catch)". Collins en-pt dictionary also has several meanings, although in a different order: 1. to catch, 2. to pick up, 3. to get, 4. to pick, 5. to grab. So I would say that we have here something very common: one verb simply has several meanings, which are quite related (and "catch" is only one of many). What is more, en.wikt claims that the Portuguese verb apanhar was borrowed from Spanish apañar, which means 1. to fix, 2. to pick up, to grab with the hand, 3. to get by, to manage. So I guess that the meaning "to catch" developed from "to pick up" or "to grab", not vice versa. Therefore it seems to me that translating or explaining "apanhar flores" as "catch flowers" is just an example of choosing the wrong meaning. --Jan Kameníček (talk) 23:46, 16 December 2019 (UTC)
True, this would be a good Wiktionary question. But I "know" this place (WS) better ;) My Portuguese language teacher, who is Portuguese, stated specifically that the sense of picking flowers is to "catch" them (apanhar). A Spanish friend also said the same thing about "apañar" with regard to flowers last night. Perhaps the sense that your eye catches them first, where they, in essence, pick you before you pick them? You catch sight of them? You are caught up in/by them? Something that it does to you and not vice versa. When you catch a cold, it gets you. I was mainly curious because of Florence Earle Coates' use of the phrase "where you can catch flowers" (written in English, and not a translation) in the poem linked to above. That is specific, in my opinion. She almost seems to be using the idea in a "foreign" sense. I believe Coates was familiar with the French language, but I am unsure of any others... Thanks for any insight :) Londonjackbooks (talk) 04:25, 17 December 2019 (UTC)
When creating a namespace, it permissible to insert external links (e.g. a wikipedia reference when creating a wikisource biographical page)? If so, is there a recommended method?Klarm768 (talk) 11:58, 18 December 2019 (UTC)
If you are talking about creating author pages, there is no need to include a reference, they are simply list pages. If you have supplementary information outside of the works written by the author, or works written about the author, then we put that information on to the respective author_talk: page. — billinghurstsDrewth12:45, 18 December 2019 (UTC)
Thank you. As I understand your reply, it would be inappropriate to insert links in "Notes" or elsewhere. But if I understand also, the information I am harvesting would never become available to a reader unless the biography is signed and its author is discoverable and the reader bothers to consult the author_talk: page where may be encountered several hundred biographical links for disambiguation/clarification related to that author. For example: IDUB biography entitled "Alftekin" is unsigned, has no author page, no author_talk page. More than simple search was necessary to discover these links: https://referenceworks.brillonline.com/entries/encyclopaedia-of-islam-3/alptekin-COM_23754?s.num=265&s.start=260 and https://en.wikipedia.org/wiki/Alptakin%7CAlptakin. I wish that Wikisource accommodated making these available while encountering the biography. Klarm768 (talk) 15:21, 18 December 2019 (UTC)
Additionally, all of these articles also have Wikidata entries with P180 (main subject) properties set, so perhaps that could be harvested by the header template?
WRT extra resources you turn up, while you could probably just dump them on the article talk page, it would be better, IMO, to add them to a "central" location, since it's unlikely people will consult the IDUB articles's talk page when looking for sources. In your particular case, an Encyclopedia of Islam link is already a citation on Wikipedia, perhaps yours would fit there too?
Thanks, Inductiveload. Perhaps Transoxania is recruiting you. I claim no thorough vetting of the links that I harvest... MANY are not found in wikipedia. Frequently I harvest wikidata, worldcat, BNF, etc. Originally I was trying to disambiguate biographic-subject-names. Now I try to find existent links on all subjects. Spellings, dates, "facts" are often disparate but could be relevant to the right person. Some biographies are "duplicates" due to different spellings or surnames. Some are mergers of identities which should have been disambiguated. My best label might be "Quick & Dirty Clues." I am fantasizing a field for TOC transclusion {°¿°}. Klarm768 (talk) 21:42, 18 December 2019 (UTC)
Comment We would not place external links from main namespace articles to biographical material on the web; that is not the purpose of reproducing a work. We may consider external links from Portal: or Author: namespaces, though there is elements of depends on what we are linking to. Wikipedia is the encyclopaedic article, and would have those external links. The Wikidata item for the person would be the place to have all relevant/pertinent links to biographical material.
With relation to other links within our headers: Related_author links to author page(s) here, and generally when it is difficult to put a wikilink into the lead part of the article. The sister links come through {{plain sister}} and predominantly added at Wikidata as a single repository of links to an item. —unsigned comment byBillinghurst (talk) 11:33, 22 December 2019.
My impression is that wikisource biographical-objects are not necessarily discoverable from wikidata. Presuming that the IDUB titles are eventually transcluded, perhaps a process can be proposed 1) to deposit my harvested links, 2) to assign the task to vet/discover acceptable links, and to create/edit wikidata entries. Klarm768 (talk) 17:14, 22 December 2019 (UTC)
While I applaud your desire for the highest standards, I would recommend that you just nominate it already. The work is already in a pretty good shape, and if any problems are identified, you will have an opportunity to fix them. BethNaught (talk) 10:17, 23 December 2019 (UTC)
Long-term users who have been granted "patrolled" status do not deal with this; everybody else does. (I'm not endorsing this state of affairs, just reporting it ;) The way to get it addressed is for an administrator to give your account "autopatrolled" status. In my (limited) experience, admins here seem rather conservative about granting it. (You could request that at WS:ADMIN.) If my endorsement means anything, I'm happy to offer it...I've found this user helpful, inquisitive, and engaged, and clearly an asset to the project. -Pete (talk) 22:33, 23 December 2019 (UTC)
I must be missing something. So far as I know, whether an edit is patrolled or not affects only whether it shows up in some special "recent changes" feeds, and does not in any way limit what you can do. Who has informed [you] that my edits are unpatrolled and in what circumstances? So far as I've noticed, Wikisource does not actually use the patrolled status for anything but what Mediawiki provides by default (unlike, e.g., enwp where every edit should ideally be patrolled). --Xover (talk) 23:23, 23 December 2019 (UTC)
Xover is right that "whether an edit is patrolled or not... does not limit in any way what you can do". (Confusingly, en.wp's "patrolling" is New Page Patrolling, which is a customised subset of Mediawiki's normal patrolling system that WS uses.)
What you should do is just not worry about it. It's just a way of helping recent changes patrollers prioritise which edits to check. Once you have a track record of demonstrating competent editing and understanding of how WS works, some admin will get bored of having to check your edits and just make you autopatrolled :) BethNaught (talk) 23:30, 23 December 2019 (UTC)
Thatoneweirdwikier, like the students in the Wikipedia course I taught, was surely "informed" by obnoxious messages in the software -- not by obnoxious users. It's not unusual for new users to be put off by messages that seem to suggest they are less than welcome. What is unusual is for one to decide to stick it out, and point it out on a page like this. I suggest we not lecture them as to whether or not they should worry about it...but, do as you see fit, of course. -Pete (talk) 05:10, 24 December 2019 (UTC)
Disabled Vector.js, css, and all gadgets, removed all cookies and data. I am using Firefox 71.0 and the latest Vivaldi. When I log in, the header ends up on the bottom of the edit textbox in both browsers. This is in Windows. I will test this in Linux as well. User:Ineuw
The new features of coloured tags and templates further break the proofread page, freeze the cursor and mouse pointer. Is there a way to disable this? — Ineuw (talk) 02:38, 29 December 2019 (UTC)
@Ineuw: Specifically, there should be a button just to the left of the "Advanced" menu, and to the right the OCR buttons, with an icon that is supposed to resemble a higlighter pen or magic marker (). It toggles whether syntax highlighting is active or not (but it sometimes doesn't take effect until the next time the editor is loaded). Also, you haven't somehow managed to turn on the "Visual editing" or "New wikitext mode" in the "Beta features" section of the Preferences? The latter in particular may superficially resemble the old wikieditor, but is actually the VisualEditor impersonating a traditional text editor. Both of them are known to be broken in various ways in combination with ProofreadPage. --Xover (talk) 11:16, 29 December 2019 (UTC)
@Billinghurst, @Xover:Thanks. The syntax highlighter is the cause of the problem header/footer problem. I didn't know that this existed because I only use the Proofread tools. Also, none of the beta features are activated. Thanks again. — Ineuw (talk) 14:28, 29 December 2019 (UTC)
Done -- Hrishikes (talk) 07:31, 18 January 2019 (UTC)
Comment Not sure why we are going around this roundabout yet again. It will never work successfully, and it is completely known that it will be problematic within wikis. So please stop the incessant complaining; it is getting beyond a joke.
I think I pulled it off—the index is updated, the pages have been shifted, the two chapters (here and here) affected by the shift have their transclusions updated, I've done a first pass on the formerly missing pages, and things look good to me, but I certainly could use a second set of eyes to do a quick double-check... —Dcsohl (talk) 04:39, 2 September 2019 (UTC)
Comment Further categorisation still needs to be resolved, as we have always done straight categorisation of people as the authors and their occupations, origin, etc. It has always been problematic, and left for another day. Similarly our categorisation of biographical works again with the conflict. I know that the EB1911 project looked at a hierarchical naming approach, though it is still internal to the work, rather than universal to the site. — billinghurst sDrewth 23:06, 2 September 2019 (UTC)
). It toggles whether syntax highlighting is active or not (but it sometimes doesn't take effect until the next time the editor is loaded). Also, you haven't somehow managed to turn on the "Visual editing" or "New wikitext mode" in the "Beta features" section of the Preferences? The latter in particular may superficially resemble the old wikieditor, but is actually the VisualEditor impersonating a traditional text editor. Both of them are known to be broken in various ways in combination with ProofreadPage. --Xover (talk) 11:16, 29 December 2019 (UTC)
