From Wikisource
Jump to navigation Jump to search
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help. Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 348 active users here.




Create a 'small-poem' class[edit]

A number of works on Wikisource utilise a nested combination of {{block center}} and {{smaller block}} wrapped around a POEM tag.

(to give one example) Page:A_biographical_dictionary_of_eminent_Scotsmen,_vol_8.djvu/249

My proposal is that instead of making templates calls, the relevant (static) CSS code should be made a "__smallpoem" class, which could be imported via TemplateStyles or globally.

There are also many instances of nested /s /e pairs of the aforementioned templates. The second part of this proposal is a {{smallpoem/s}} consisting of a single opening DIV tag classed using the aformentioned "__smallpoem" style class. {{smallpoem/e}} would be a closing <DIV>

1 template call of 2, and in some instances just a POEM tag needed. More efficient? Thoughts? ShakespeareFan00 (talk) 10:14, 12 July 2019 (UTC)

My initial thought is that this proposal is merely an example of this, so I am hesitant to support it. Current solutions work well, and the template call maximum rarely gets hit by centered small poems. Does this really benefit anyone in any meaningful way? —Beleg Tâl (talk) 15:22, 12 July 2019 (UTC)
Also I really dislike the POEM extension (partially because it replaces the </p><p> that ought to exist between stanzas with a <br /><br />) so that might factor into my feelings on the matter. —Beleg Tâl (talk) 15:24, 12 July 2019 (UTC)
Symbol oppose vote.svg Oppose Not supported. There is no practical definition of what a small poem is. We can define the extremes (one line vs an epic spread across multiple volumes), but we cannot point to a particular length and say "there is the boundary point." Beeswaxcandle (talk) 20:00, 12 July 2019 (UTC)
Small as in terms of {{smaller}} formatting, not in terms of length, but your oppose is noted. ShakespeareFan00 (talk) 20:33, 12 July 2019 (UTC)

A minor Charinsert modification suggested[edit]

I suggest to modify our MediaWiki:Gadget-charinsert-core.js by moving the 'User' row to be the first row, (which is the default row). I modified a copy in my user space CharInsert|HERE, and it works fine.

The reason being is that the browser cookies no longer store the user's preferred selection to be the default row. If there is a replacement mechanism, it's not working. I must re-select the 'User' row on every page being edited. This being the 23rd row, it defies logic. Ineuw (talk) 18:08, 14 July 2019 (UTC)

Tentative Symbol support vote.svg Support though it would be better to have it remember selection per user (I use "insert" far more often than "user") —Beleg Tâl (talk) 15:20, 15 July 2019 (UTC)
@Ineuw: MediaWiki:Gadget-charinsert-core.js uses the API, which is a wrapper around HTML5 Web Storage. This works similarly, but not identically, to traditional cookies. The biggest difference in this case is that there is no good way to inspect what's in this storage in any of the big browsers that I've found (though I might be able to cook you up a custom script to inspect the charinsert cookie if you want it for debugging).
However, I just checked using the custom charinsert list from your vector.js and it seems to work just fine in the latest Safari, Chrome, Firefox, and Vivaldi. Is it possible that you've jacked up a security setting anywhere at some point? You don't have some kind of extra-paranoid antivirus running?
In any case, I don't have any strong opinion on the proposed change beyond it seemingly being prompted by what looks like a local issue; and that it will mean everyone without a preference set (including all non-logged-in users) will be presented with an empty list and a drop down labelled "User". I use charinsert so rarely that I don't really have a good grasp of the needs of those who do. -- Xover (talk) 15:36, 15 July 2019 (UTC)
@Xover: Thanks for the offer but I am really satisfied using the modified script of my namespace. The problem was that the new wrapper worked for awhile, but stopped working before the current wmf software update. Most likely because of the prior update.
So, this solution is only good for those who are logged in and mostly use the "User" row. PS: I scanned for viruses an hour ago, but will re-boot and do a boot time scan as well. Ineuw (talk) 01:15, 16 July 2019 (UTC)

New speedy deletion criterion for person-based categories[edit]

Following on from a discussion at WS:PD#Speedy deletion of author based categories.

It is long established and in the main uncontroversial that English Wikisource does not use person-based categories (of the type "Works by John Smith", "Poetry by John Smith", etc.). Some previous discussions can be found at: 1, 2, and 3 (and the two following threads). However, absent a speedy deletion criterium specifically for these, admins have to rely on the provision for precedent-based deletions. In practice this means such categories must be brought to WS:PD to be rubber stamped, wait at least two weeks (because inertia and habit), and then hopefully someone will remember to process them. Eventually.

I therefore propose that we extend the deletion policy with a new G8 criterion as follows:

  • Person-based categories—Categories where the defining characteristic is person-based. This includes, but is not limited to, author-based categories like "Works by author name".

All deletions (modulo CU type concerns) are subject to community challenge in any case, and are clearly visible in the deletion log, so there is no particular benefit to the bureaucracy where there exists no significant uncertainty or controversy. --Xover (talk) 14:32, 15 July 2019 (UTC)

Symbol support vote.svg Support, but I'd note that there is an exception discussed in link #2: namely, American presidential documents categorized by president. This is due to the fact that the administration of the executive branch is tied to who is the president at the time. There was no consensus as to the scope of this exception: what kinds of presidential documents it applies to, or whether other governments may have the same treatment, etc. —Beleg Tâl (talk) 14:42, 15 July 2019 (UTC)

Bot approval requests[edit]

Repairs (and moves)[edit]

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

Biography and family record of Lorenzo Snow[edit]

This is from an unknown source, but there seem to be two sets of scans on Wikisource -

Can someone decide on ONE set of scans, match and split (and eventually ditch the unsourced version), so I am not wasting my time, doing Lint-removal on stuff that will eventually be replaced? Thanks.? ShakespeareFan00 (talk) 10:19, 18 June 2019 (UTC)

Index:Biography and Family Record of Lorenzo Snow monochrome.djvu has more progress. Discuss with the proofreaders and come to a consensus? —Beleg Tâl (talk) 14:46, 15 July 2019 (UTC)

Scans which need page images integrating into the djvu/pdf etc.[edit]

I some time ago created a template which categorised a small number of works into a category here Category:Scans with pages to be integrated into source file. These works are those currently marked as needing a Source file repair, but where scans of missing pages have been added subsequently at the end of the page list. Currently the category contains 3 entries, and it would be nice if at some later date, those technically able were able to repair the files and Index pages concerned. ShakespeareFan00 (talk) 09:40, 28 June 2019 (UTC)

Also in relation to Category:Index_-_File_to_fix , I seem to have also made some 'reason' templates to supplement the categorisation of Index: pages into that status/category. ShakespeareFan00 (talk) 09:42, 28 June 2019 (UTC)

Index:The Discovery of a World in the Moone, 1638.djvu[edit]

Pages at rear of work need re-aligning as the source file was updated. ShakespeareFan00 (talk) 19:04, 2 July 2019 (UTC)

If you ask for help, please have the courtesy give time to people to fix stuff before jumping back on it. Very confusing otherwise. Or if you are in a hurry, just fix it then.— Mpaa (talk) 23:21, 2 July 2019 (UTC)
I had waited... The bot hadn't apparently moved the last few pages, so I did them manually. Next time I should perhaps have left it longer? ShakespeareFan00 (talk) 00:07, 3 July 2019 (UTC)

Index:The librarians of Harvard College 1667-1877.djvu[edit]

In the course of checking the page list, this turned out to be a entire volume of a periodical of which the current title of the Index is only a single issue. I think the file and Index should be retitled and the relevant pages relocated? ShakespeareFan00 (talk) 09:09, 14 July 2019 (UTC)

Other discussions[edit]

Talk pages consultation: Phase 2[edit]

"icon depicting two speech Bubbles"

The Wikimedia Foundation is currently conducting a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

Phase 1 of the consultation is over – thank you to everyone who participated! – and we've published the Phase 1 report. The report summarizes what people have said and what we've learned, proposes a direction for the project, and asks specific questions to explore in Phase 2.

Very briefly, the proposed direction is that wikitext talk pages should be improved, and not replaced. We propose building a new design on top of talk pages that changes the page's default appearance, and offers key tools like replying, indenting and signing posts. To keep consistency with existing tools, the new design will be a default experience that existing users can opt out of. We also propose building features that experienced contributors want, including the ability to watchlist a single discussion, and the ability to move, archive and search for threads. Building these features may require some loss of flexibility, or small-to-medium changes in wikitext conventions. The goal is to only make changes that directly enable functionality that users really want.

You can see more information and discussion about the proposed direction in the Phase 1 report, including the results of new user tests and some of the quotations from Phase 1 discussions that led to this proposal.

Now it's time to start Phase 2!

We have six questions to discuss in Phase 2, asking for reactions to the proposed direction, and pros and cons for specific changes that we could make.

You can help by hosting a discussion at your wiki. Here's what to do:

  1. First, sign up your group here.
  2. Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group.
  3. Then start the conversation with the six questions listed in the Questions for Phase 2 section of the report.
  4. When the conversation is concluded, the host should write a summary of the discussion on the Phase 2 community discussion summaries page, and report what you learned from your group. Please include links if the discussion is available to the public.

You can read more about the overall process on If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you. DannyH (WMF) (talk) 17:49, 17 May 2019 (UTC)

Discussion of Phase 2[edit]

Please proceed to discuss the following points:

1. What do you think of the proposed product direction?

Context: The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.

Question: What do you think of this product direction?

I think this is the only reasonable solution. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
This will only be feasible it if results in valid and correct list markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 18 May 2019 (UTC)
The way this proposal is phrased makes me think this will be implemented only on Talk pages, not all pages used for discussion. If this is the case (and I can't tell) then the proposal will have little impact on this project, since en.WS uses the Talk pages very little and prefers a few centralized discussion pages. --EncycloPetey (talk) 14:09, 18 May 2019 (UTC)
2. Marking separate discussions

Context: People want to watch individual sections on the talk page. They want better notifications, archiving, and search. To do any of this, we may need to create a more structured definition of what counts as a single discussion. This may mean making changes to the wikitext conventions on a talk page. For example, we may create a new way that discussion headings look in wikitext, or a new link that you need to use to create, rename or split a thread.

Question: What are the advantages and disadvantages of that approach?

The best way to accomplish this currently is to have a page for each discussion, and transclude all the discussion pages onto a single main page. Commons does this with deletion proposals for example, and Wikidata does this for property creation proposals. On Wikisource we use this approach for transcluding works, but not for discussions. I think that this would be a good approach for accomplishing this particular goal, but it would have to be streamlined. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
3. Helping newcomers find the talk pages

Context: Newcomers have difficulty finding talk pages. During user tests, only one person out of ten found the Discussion tab. Most testers looked for a Discussion tab on the opposite side of the page, where all of the other tabs and links are. Many people also expected to see links to discussions about specific sections in the article. We may want to move the link to the talk page to the opposite side of the article page. We might add discussion functionality connected to individual sections.

Question: What are the advantages and disadvantages of making the connection between article content and discussions more visible?

Improving the ability of newcomers to find the right location for a discussion is always a good thing. Experienced editors will get used to such a change (or a gadget or preference can allow them to disable the change for themselves personally). However, having discussions for every single section of content would only add to our problem of having way too many talk locations, and doesn't really make sense on Wikisource anyway. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
yeah, i’m finding new editors don’t know what a talk page is, where to find it, how to use it, or why bother. they do not respond to wikilove, or pings. the new generation of editors will edit only at meetups, and then collaborate on etherpad, or twitter, or telegram, never a talk page. it is all become "dark forest", might have to promote talk page interaction as fun, or moderated, in order to get some functional discussion on talk pages. Slowking4SvG's revenge 21:26, 27 May 2019 (UTC)
4. Where to show discussion tools

Context: Currently, many wikis have community discussion spaces in the project namespace (Wikisource or Wikipedia:), rather than in a talk namespace (Wikisource talk or Wikipedia talk:). The project namespace is often used for village pumps/cafés, noticeboards, and some workflows, such as Articles for deletion. The system will need to know where discussions happen, so that it can display the new tools in those discussions, and not display them on other pages. There are several potential ways to do this. One of them is to move all discussions to a talk namespace.

Question: What are the advantages and disadvantages of doing that?

I have no opinion on this —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
need to streamline tools and talk templates, so they do not break talk pages as being too large. the custom templates will need a re-code to transclude if linked to. Slowking4SvG's revenge 21:15, 27 May 2019 (UTC)
5. History tradeoffs

Context: Sometimes, you need to see the history of the entire page. Other times, it would be more helpful to see the history of only a single discussion thread. It would be ideal if we could provide both, but we're not sure how to do that.

Question: What are the advantages and disadvantages of having a complete page history or a specific thread history?

In some places (like the Scriptorium or WS:PD) the history of a single discussion is more important than the full page history, but it's necessary to also see the full page history in order to deal with (for example) vandals who modify the whole page. — This problem could be dealt with by having each discussion on its own subpage, transcluded onto the main page, and then implementing some sort of "include subpages" functionality in page history? —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
thanks are for a single talk diff. veterans use diffs for history, to reduce the confusion of who said what when. confusion in many conversations is widespread. Slowking4SvG's revenge 21:15, 27 May 2019 (UTC)
6. Metadata location

Context: Some wikis place templates at the top of article talk pages. These may show instructions, warnings, or FAQs. They may hold page quality information, link to relevant WikiProjects, or identify past activities. Many new users are confused by finding non-discussion material at the top of an article talk page. It would be helpful to move some or all of that content somewhere else on the page, or under a different tab.

Question: What are the advantages and disadvantages of that approach? Which templates are crucial for the proper use of a discussion page, and which could be moved somewhere else?

On Wikisource, this would only be {{TextInfo}} for content pages. We also list sources for biographical info on Author talk pages, and style guides on Index talk pages, but we generally structure these as discussions anyway. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)
A separate tab would be good (I have already suggested this for Wikidata), provided that relevant content may be transclued to the top of the talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 18 May 2019 (UTC)
Wikisource uses Talk pages only seldom for any discussion; we use them to store significant source information instead. A separate tab for discussion would be of little to no value.
Is this really a Wikimedia-wide problem, or is this just a problem on the Wikipedias? Perhaps only the Wikipedias need a separate tab/namespace for their pages. The other projects I work on don't have this issue. --EncycloPetey (talk) 14:11, 18 May 2019 (UTC)
It's not "just" the Wikipedias, but it is only some wikis, and the English Wikipedia is the biggest example.
One way of doing this might let us move the wikitext codes for categories out of the page, too. Imagine if Category:1887 works was attached to a page as its own property (like, e.g., the page title already is) and didn't have to be specified via category or template.
I would really appreciate it if one of you would summarize Wikisource's general views on these questions at the page linked in the message below. Whatamidoing (WMF) (talk) 05:01, 2 July 2019 (UTC)

Consultation is over[edit]


First of all, thank you for hosting that conversation on your wiki. We really value the work you've done!

The consultation is now over. We have received a lot of feedback, that require a lot of work and time to be summarize. We have decided to postpone communities summaries' due date to Monday June 24.

A page has been created to host communities summaries. Please add yours there.

If you have any question, please contact me.

On behalf of the Talk pages consultation team, Trizek (WMF) (talk) 08:57, 17 June 2019 (UTC)


Two questions re: [1]:

  • Since when are we prohibited from including links to PDFs of sources?
  • Since when are admins allowed to use their admin tools in content disputes in which they are involved?

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 18 May 2019 (UTC)

The BHL link is not a link to a PDF, it is a link to a database that also has a PDF. This information and link is stored on the data item for the work at Wikidata. There is no reason to duplicate the information here; Wikisource is not a link farm.
You have been resisting advice on Author pages since you arrived here, and have declined repeatdly to discuss the issue each time it was brought to your attention. You instead chose to communicate only through repeatedly reverting. This is a basis for blocking an editor, but I chose instead to merely protect the page. --EncycloPetey (talk) 19:16, 18 May 2019 (UTC)
perhaps this link [2] or this [3] is "allowable" ? but do not see the point of reverting links rather than uploading to commons and replacing. do you really want to say "see how restrained i am, i did not block you?" Slowking4SvG's revenge 10:45, 20 May 2019 (UTC)
Direct link to an external PDF is better than a link to a page at Wikidata with the link to external PDF (as many people are not familiar with WD). The form of the link introduced at [4] was not very good, much better is the form of external links e. g. at Author:Max Stirner, but this can be solved in a better way than a simple revert. Locking the page as a mean of forcing one's own version in a content dispute is generally harmful. If necessary (which was not our case) it should always be done by an independent admin.
As for the "basis for blocking an editor": I can see there 2 reverts by User:Pigsonthewing and 3 reverts by User:EncycloPetey. Wikisource policy regarding this issue is described at Wikisource:Blocking policy#Excessive reverts. --Jan Kameníček (talk) 12:38, 20 May 2019 (UTC)
Direct link, yes, to a scanned file, but not to a database where the reader must then follow additional links to reach the scan. The BHL link is a link to a database, not to a PDF. So any objection to a Wikidata link would apply equally to a BHL link. The Wikidata link has the advantage of providing all the links, whereas BHL is only BHL, and the user must still follow additional links to reach the scan, and the user must be familiar with BHL to do so. The preference is to upload a file to Commons and host a copy here.
External scan links on an Author are always a temporary thing or a secondary level. The goal of Wikisource is to host works in the Mainspace. The Author pages are a secondary tier of content to support the Mainspace, and external links are temporary links to sources of content, in preparation for hosting that content here. We have in the past allowed links to Google scans or to Internet Archive scans using {{Ext scan link}}, but not links to databases such as BHL, or adding DOI links, or other database identifiers (which should be hosted at Wikidata), for this is a misuse of what the Author pages have always been intended to do.
Andy Mabbett has been abusing external linking on Author pages, such as at Author:Alexander Reid Urquhart and Author:Marcus Ward Lyon (1875-1942), with excessive external linking to multiple databases. This isn't linking to a scan; it is adding multiple remote database identifiedrs for a single work to an Author page on Wikisource, instead of placing them on the work's data item at Wikidata, which is where the data belongs.
See further the Help:Author pages and Wikisource:Style Guide, which explain what the Author page is intended for: listing the works and linking to the main page of the work. Neither page recommends the addition of external linking as a function of the Author pages. You can see my attempt to discuss this issue, but no discussion was forthcoming. This is not the first time I have gotten no reply when starting a discussion; you can see that most of the previous discussions which I started (missing images, house style, ...) received no replies either. Disputes cannot be resolved through discussion when one party habitually refuses to discuss.
In this situation, the problem should now be resolved as I have uploaded the desired work to Commons and set up a transcription Index. No external links to the work are now required. --EncycloPetey (talk) 13:46, 20 May 2019 (UTC)
@EncycloPetey:I agree with many points you have mentioned, though with several buts.
You are absolutely right that it was a link to a database and not to the scan. However, the scan was just one click farther, so the contributor might have been asked to replace the link for a more accurate one instead of removing it and following with an edit war.
You are also right that external links are just temporary. I understand that their main purpose is to show contributors where the work is available to be added to Wikisource.
I was reacting only to this specific case, I know nothing about other Andy Mabbetts contributions.
It is true that the mentioned help pages do not say anything about external links in Author pages. However, current practice is different and external links showing where the work can be obtained to be added here are frequently used and nobody seems to be removing unless they are substituted at least by a downloaded scan. IMO, they can be useful, although the scan or even the proofread work instead of the link are much better.
Your final solution by uploading the work to Commons is perfect. --Jan Kameníček (talk) 17:24, 20 May 2019 (UTC)
"You have been resisting advice on Author pages..." I note that this allegation is made without any supporting diffs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 20 May 2019 (UTC)
Do you deny the allegation, or simply question its delivery for the purpose of wiki-lawyering? If I thought the diffs would result in a change in your editing practices, I would trawl through for them. But up to this point, you have failed to respond to discussion (see your Talk page), or have hedged, or have turned to ad hominem (again, see your own Talk page). This being the case, there seems little point in providing the diffs, as I cannot believe it will improve your editing. --EncycloPetey (talk) 16:36, 20 May 2019 (UTC)
Diffs, please. And I'm happy to respond to discussions: you have yet to initiate one on my talk page; mostly posting instructions. As for wiki-lawyering, having been caught with your fingers in the admin-tool-abuse cookie jar, it is you and you alone who is doing that; and resorting to ad hominem.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 20 May 2019 (UTC)
You didn't answer my question. --EncycloPetey (talk) 17:10, 20 May 2019 (UTC)
i’m sad that you are engaging in this way. you very well know PotW is stubborn; why then are you edit warring, and locking pages? this is how admins act over on commons, i expected better here. we should be modeling good behavior and showing deep link or wikisource link, not reverting a general list link, these can be added to a work list. we need some admin faciltators; is that a style of leadership you are prepared to try? Slowking4SvG's revenge 18:31, 20 May 2019 (UTC)
I tried offering alternatives, but was unacknowledged. I demonstrated setting up an Index page for transcription, which is the Wikisource goal. --EncycloPetey (talk) 19:36, 20 May 2019 (UTC)
why don’t you offer an alternative to locking an author page? what is the justification for a one month admin lock on an author page? do you want only admins to edit this site? Slowking4SvG's revenge 17:18, 24 May 2019 (UTC)
I did offer alternatives. Twice. And I initiated dialog on the issue, to which the response was being told to go away and reverts. Also, the page was locked for only 14 days, not a month, which I had hoped would be sufficient time for a dialog to begin on the issue of database linking, which was the crux of the disagreement. Perhaps unsurprisingly, that dialog has still not happened, except for the replies by Jan.Kamenicek above. Did you have any comment to offer on that issue?
In any event, Wikisource:Protection policy advises the protection of pages which become host to an edit war "until the users resolve their dispute through discussion". At this point, Andy Mabbett has not participated in the discussion of the issue, and has refused to do so. --EncycloPetey (talk) 20:59, 25 May 2019 (UTC)
i’m sorry, i do not find that response adequate. i do not see a "issue of database linking" consensus standard of practice. you should expect more "non-participation" when you roll out the lock tools to stop discussion. should your standard of practice become the norm here, i would reconsider my participation. Slowking4SvG's revenge 23:38, 25 May 2019 (UTC)
How can there be consensus if you will not discuss it, and Andy will not discuss it? I have initiated discussion several times. The issue is also one of the two points upon which this very thread was started, yet only Jan.Kamenicek and I have discussed that issue. --EncycloPetey (talk) 23:47, 25 May 2019 (UTC)
I note that diffs have still not been provided. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:14, 22 May 2019 (UTC)
I note that diffs have still not been provided. I also note that this review is still open. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 25 May 2019 (UTC)
I find it ironic that an editor is demanding diffs in a thread he started by making unsubstantiated accusations. If you believe some Wikisource policy has been violated, then please identify it. Otherwise, please apologize. --EncycloPetey (talk) 23:02, 25 May 2019 (UTC)
i find it ironic to critique the participation of an editor, while denying participation. Slowking4SvG's revenge 23:46, 25 May 2019 (UTC)


Since diffs have been requested…

On 18 May Andy added a new work to Author:Lyman Belding in this series of edits: 1, 2, 3. In addition to listing the work itself the edits add a DOI using {{DOI}} and a bare URL to A few minutes later EncycloPetey, presumably while patrolling the recent changes feed, removes the links with the edit summary BHL and DOI links belong on Wikidata item for the work, not on the Author page. Four minutes later they open a thread on Andy's talk page explaining their reasoning and suggesting alternate methods to achieve the apparent goal. 16 minutes later Andy reverts EncycloPetey's change to Author:Lyman Belding with the edit summary BHL provide a PDF of the full work. EncycloPetey then reverts and instead adds a {{wikidata edition}} as they had previously suggested on Andy's talk page. Two minutes later Andy reverts with the summary restore link to page containing PDF of full work. EncycloPetey now reverts and protects the page, and posts the addendum Wikisource is not a link farm. Please use Wikidata for metadata links. on Andy's talk page. At this point—22 minutes and 2 reverts after they received the first message on their talk page, but just 2 minutes after the author page was protected—Andy responds on their talk page with Work on improving your tone; and assume good faith.. EncycloPetey responds with Feel free to follow your own advice.. One minute later Andy opens this thread questioning EncycloPetey's conduct, and then replies on their talk page with Don't post here again until you have sufficiently addressed the above.. Four minutes later EncycloPetey responds to this thread explaining their reasoning and their complaint with Andy's actions.

At no point during these edits do I see any attempt by Andy to discuss this issue or the related actions, despite EncycloPetey's attempt to start such a discussion on their talk page. The two replies on their talk page are not responsive to the issue raised, and this thread is a complaint regarding EncycloPetey's conduct rather than addressing the actual issue in disagreement.

The full list of diffs (all times in UTC):

I'll also note that EncycloPetey has previously attempted to discuss, assist, and facilitate on Andy's talk page with no apparent response. --Xover (talk) 08:00, 26 May 2019 (UTC)

The accusation for which diffs were requested was "You have been resisting advice on Author pages since you arrived here". Which of your collection of diffs do you suppose supports that allegation?
One of my earlier questions was "Since when are admins allowed to use their admin tools in content disputes in which they are involved?". What's your answer to that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 26 May 2019 (UTC)
Your first question is a matter of moving the goalposts. You started this thread over two questions, and both have been answered satisfactorily. Yes, your second question has already received a reply above. You asked: "Since when are admins allowed.." and the answer is that it has never been disallowed. You were challenged to present policy that says otherwise, or to apologize for your unsupported accusations of misconduct. You have not responded to that reply, but have simply stated the original question again. It is not clear yet whether you are dodging the issue or begging the question. --EncycloPetey (talk) 23:36, 27 May 2019 (UTC)
My second question has indeed received a reply above; Jan wrote Locking the page as a mean of forcing one's own version in a content dispute is generally harmful. If necessary (which was not our case) it should always be done by an independent admin. However, in this case, I was - quite clearly - asking Xover for their response. And still no diffs to support your allegaton... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 28 May 2019 (UTC)
So you are now accepting a person's opinion as if it were true and policy, without supporting evidence? Will people's post facto opinions be the deciding factor for you, rather than Wikisource policy? And will you accept these opinions without supporting evidence or diffs? If so, then why are you asking for diffs? --EncycloPetey (talk) 01:11, 29 May 2019 (UTC)

Pictogram voting comment.svg Comment

  1. This argument has elements of two people trying to defend their actions and such will always be combative. Could we focus on a discussion on what we need for Wikisource, and the readers. This is in terms of information available, and readable pages, and something that is maintainable. I reckon that you two will agree on a lot, so let us tease apart where we disagree.
  2. Administrators operate on the consensus of the community. It has been my intended practice (though probably imperfect) that where I am getting into a reasoned dispute, that I look to bring the matter to the community. Difficult at times, though useful for broader opinion.
  3. I would like to think that we can resolve our disputes with less (no?) vitriol if we are focusing on what is the best output for users and editors. — billinghurst sDrewth 21:44, 30 May 2019 (UTC)
i agree. i regret i do not see any sign either of these editors will drop the stick long enough to come to a consensus about a way forward. (you very well could have a guideline about deeplinks on author pages) what then is the community going to do about community health? trouts all around does not seem to work. and rest assured this lack of civility will fester, if we do not deal with it. Slowking4SvG's revenge 17:05, 31 May 2019 (UTC)

Ongoing issues[edit]

EncycloPetey is now removing (and has done so three times, so far: [5], [6], [7]; each time with the edit summary "cleanup") publisher details which I have included in a list of works at Author:Frederick W. Lanchester, a page I recently created.

I note that publisher details are often included in author pages without drama, for example: Author:Henry Eliot Howard; Author:Brooks Adams; Author:Choudhary Rahmat Ali.

I note also that diffs supporting the accusation he made about, above, me have still not been provided, nor has that accusation been withdrawn. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 9 June 2019 (UTC)

The fact that other pages have not been cleaned up is not a valid reason for preventing the cleaning up of pages. Metadata belongs at Wikidata, or can be placed in the header of a work's Mainspace page. It should not be stored on Author pages. Note that comparing data for books with data for journal articles is not an equivalent comparison; journal articles require data that books do not. --EncycloPetey (talk) 14:25, 9 June 2019 (UTC)
Removing anything but the title, which many others including myself have deliberately and purposefully added. Where and when was that decided, or are you just announcing that this is "better" now? CYGNIS INSIGNIS 19:37, 9 June 2019 (UTC)
See Help:Author pages#Works by the author. --Jan Kameníček (talk) 20:01, 9 June 2019 (UTC)
Hi Jan, thanks I suppose, but note I am not new here. The page provides a helpful suggestion, not a consensus of unilateral decision to define what goes there: are we seeing different things? Nevertheless, that is a help page that has been edited with a view, in my view, to retroactively applying a consensus of one as if that were policy anywhere else but in a users head; the history shows that one's admins view is contested by another. These are the pages I should be watching after a decade of sporadic contributions. CYGNIS INSIGNIS 20:40, 9 June 2019 (UTC)
@Cygnis insignis: Misrepresenting the issue does not help. --EncycloPetey (talk) 20:37, 9 June 2019 (UTC)
Is that not what is happening, then I apologise. CYGNIS INSIGNIS 20:40, 9 June 2019 (UTC)
@EncycloPetey: user complained that publisher info was removed, that it what I see in the history and current page. CYGNIS INSIGNIS 21:10, 9 June 2019 (UTC)
[edit conflict] You may not have noticed two relevant points in the issue: (1) The metadata was added to the page as part of a copy-paste of information at Wikipedia. No attempt was made to reformat the data for Wikisource by the original contributor at that time; it was just copy-paste. (2) One of my alterations was to select a much higher quality scan at IA in place of the one copy-pasted from WP. The original link was to a low-quality Google scan from which all the images had been stripped. Part of my cleanup was to link to a much higher quality scan made from the Univ. of California collections, and which included the missing images. I noted this in my edit summaries, but had my selection reverted [8] [9] to the low-quality scan missing its images.
Only the edition-specific information of publisher and city of publication for four books were removed; and a higher-quality scan was selected. Some publication information, such as "Limited ed. of 640 copies", was left in place, as a kind of explanation to the reader as to why no scan was linked and also might be difficult to locate. Where it is relevant, information specific to particular editions can be included, such as in the header notes of a work to clarify the source, or on a versions page where it is necessary to distinguish between editions, but in most cases edition-specific metadata is clutter on an Author page.
The primary function of the Author page is to direct the reader to works by the Author that are hosted on Wikisource, as well as to works about the Author. Metadata specific to editions is not data about the Author, and belongs on the work's Mainspace page (in the header notes) or on Wikidata in the data item for that edition. --EncycloPetey (talk) 21:17, 9 June 2019 (UTC)
"Misrepresenting the issue does not help", says EncycloPetey, then goes on to do just that. He claims "Part of my cleanup was to link to a much higher quality scan... but had my selection reverted... to the low-quality scan...", but neglects to show the diff where, after reverting his removal of publisher data, I reinstated the link to the better scan: [10] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 June 2019 (UTC)
He also says "[publisher metadata] belongs on the work's Mainspace page (in the header notes) or on Wikidata in the data item for that edition", neglecting to mention that, for the works in question, neither of those things yet exist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:27, 9 June 2019 (UTC)
That is because it is bluff, you are a newb here aren't you :) EP is not the king, I am. CYGNIS INSIGNIS 22:32, 9 June 2019 (UTC)
Ja, this is the point I came to make, and forgot to note when told I was misrepresenting what I could see Andy was doing. I also have an allergy to that sort of thing. CYGNIS INSIGNIS 22:21, 9 June 2019 (UTC)
@Pigsonthewing: please don't thank me, I'm not especially sympathetic and not aware why I would value that response. Its worth noting my last interaction with this user: I responded to a request to help with ids of some birds at commons, the requests for rotation were met with reverts and notification at a notice board (to the astonishment of myself and others). Petey makes exceptional contributions that I read and value, which I think it also worth repeating. CYGNIS INSIGNIS 21:06, 9 June 2019 (UTC)
I wasn't thanking you for any perceived sympathy, but for making a cogent point. I'm not sure how your baseless umbrage-taking over a commons issue is relevant here, but I recall that maintaining the original orientation of the images in question was already being discussed at Common's Village Pump (not a "noticeboard"), starting at 11:30 am on 11 May, well before you proposed rotating them, at around 9pm that day. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 June 2019 (UTC)
Not much patience for tire kicking mate, not when a user has over a decade of wiki contributions and comes to this library making noise. Maybe your request at wikipedia should have noted rotation was unwelcome, or you could have hit on the solution of non-rotated versions, instead of insisting that that anyone reading that authors handwritten personal notes sideways and birdies with their legs in the air. CYGNIS INSIGNIS 22:18, 9 June 2019 (UTC)
I've no idea to which "request at wikipedia" you refer, but on Commons, my edit summaries referred you directly to the discussion on Village Pump, where the matter - including the possiblty of hosting rotated duplicates - was already under discussion, as your own comment there confirms. This is still not relevant to Wikisource, and if you wish to persue it I invite you to pick a more suitable venue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 9 June 2019 (UTC)
The bird project, if I recall correctly. Don't be insubordinate. CYGNIS INSIGNIS 22:35, 9 June 2019 (UTC)

I have just added to an author page this markup: * {{DNB link|Logan, William Edmond}}, which renders as:

in particular: London: Smith, Elder, & Co., (1885–1900) in 63 vols, which seems to be at odds with the claim that "Metadata belongs [only] at Wikidata..."; and the reverts linked above, especially as (unlike in those examples) the target Wikisource page and Wikidata item each already exist. Perhaps our widely-used DNB template needs "cleaning up"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 14 June 2019 (UTC)

No, it doesn't. CYGNIS INSIGNIS 19:37, 14 June 2019 (UTC)?
Right. So can the publisher details be restored to the works on Author:Frederick W. Lanchester? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 14 June 2019 (UTC)
Of course, Mr. Mabbett, because it was obviously well intentioned and not vandalism, but restoring this example is arguably not allowed if EP says otherwise. Attempts to alter that situation, tacitly endorsed in the documentation, were resisted. The inaction of others in formulations of a verifiable consensus is a concern, but in the absence of that any action is fraught with unintentional consequences. And you, of course, recognise all this without me restating it, and there are few good options when being accused of vandalism. Your sincerely, CYGNIS INSIGNIS 17:10, 15 June 2019 (UTC)
"arguably not allowed if EP says otherwise" go on, then, let's hear the arguments for that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:57, 15 June 2019 (UTC)
I think you have heard them, such as they are, others find them unpersuasive. Would you like me to ping those I am aware of who have expressed views on this? @Xover: is currently holding the talking stick, by disputing the changes made to the only relevant page, but there are others who hold clearer views on where authority lies in relation to 'established' and sysop access users. CYGNIS INSIGNIS 20:31, 15 June 2019 (UTC)
My apologies Cygnis insignis, your ping did not generate a notification for me for some reason and my available on-wiki time has been consumed elsewhere the last few days. I'm afraid I do not know what you mean by "… currently holding the talking stick, by disputing the changes made to the only relevant page." I attempted to participate in one policy-related discussion, but as you characterised my contribution there as "… rude af in your assumptions and aspersions, also discouraging to any solution." I opted to step away. If there is some other issue for which my input is holding up progress I am not aware of it. --Xover (talk) 06:52, 17 June 2019 (UTC)
"If there is some other issue..." Well, you haven't answered the questions I asked you on 26 May. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:53, 18 June 2019 (UTC)
@Pigsonthewing: Personally, I don't think it makes sense to mention publishers when listing an author's works. It's a list of works, not a list of publications. For example, it wouldn't make sense to list the 50+ editions of On the Origin of Species at Author:Charles Robert Darwin. Instead, we link from his author page to a list of the editions: On the Origin of Species. That is where the publisher information belongs (and on the index pages, e.g. On the Origin of Species (1859)). At the author level, we don't deal with specific editions or specific publications of a work, we're just dealing with the works themselves, i.e. the intellectual creations of the authors. Of course, we typically link to specific editions from the author page (especially when only one edition has been published), but that is just giving an example of the work. It doesn't represent the work definitively, as other editions may be published in the future. We also shouldn't list the publisher at the author level because it can be misleading, implying that the work was only published once by a single publisher (which often isn't true). FWIW, Wikidata seems to sometimes, but rarely, acknowledge a separation between works and editions, e.g. wikidata:Q20124. Kaldari (talk) 14:32, 2 July 2019 (UTC)
That's a reasonable viewpoint, though others clearly disagree with you; and "published once by a single publisher" apparently applies in at least one of the cases at hand. But this is discussion of abusive admin behaviour, not styles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 2 July 2019 (UTC)

Sidenote mess[edit]

Does anyone have any tips for how to deal with this sort of thing? My current solution looks OK in Page: but it'll probably play havoc with dynamic layouts, and my sense is that as currently set up {{sidenote}} is mostly intended for the more usual section-heading sidenotes than for side-references like this. —Nizolan (talk) 19:03, 12 June 2019 (UTC)

After seeing that it also breaks the page on mobile I had the thought that it might be better to just convert all of the textual references to standard footnotes and leave only the page numbering as sidenotes, per the "page layout" advice at WS:MOS. —Nizolan (talk) 21:55, 12 June 2019 (UTC)
that is the way side footnotes appear. it is a roadblock for works with side footnotes. there has been some discussion at other transcription projects, about transcribing without the side footnotes (as adding little value), but there has not been a consensus to adopt that style. Slowking4SvG's revenge 11:36, 16 June 2019 (UTC)
@Slowking4: In this particular case the sidenotes are important, because the work is a medieval Bible commentary and the sidenotes point to the particular Bible verses, as well as allusions to other works. Unfortunately when there are about 50 of them on one page there's no way to present them as sidenotes without breaking things, so I think changing them into an ordinary <ref> group is the only way to go if we want to retain them in this specific instance. (My example attempt is here.) I'm not opposed to ignoring them in some cases though. —Nizolan (talk) 19:50, 25 June 2019 (UTC)
that is a good compromise, go for it. (sometimes i think our verisimilitude of marginalia gets in the way). Slowking4SvG's revenge 02:16, 26 June 2019 (UTC)
If you are using {{Outside L}} , {{Outside LR}} etc. you can use the experimental clearfix=yes parameter, this should work on transclusion, but doesn't quite work in page namespace yet. It was written as a style so could be tweaked for mobile if needed.
(Aside:) {{fine block}} is DIV based, the sidenote template families are SPAN, you can't put a DIV in a SPAN per HTML document structuring conventions, so you might want to rethink the formatting. ShakespeareFan00 (talk) 08:09, 26 June 2019 (UTC)

Marking authors as dead[edit]

Using petscan, we can do a search for PD-1923 living authors, turning up 650 pages. If they published a work at the age of 20 in 1923, that would make them 115; w:List of the oldest living people gives us the complete list of four known people that old. It might be possible if they were a little younger, but if they published in 1918 at 15, or 1913 at 10, they're in the same group, and many of the people in that list published works in the 19th century. Besides simple correctness, there's also errors and questionable entries there.

Unfortunately, putting ? in the deathyear spot doesn't seem to take authors out of Category:Living author, and is not encouraged with wikidata. Is there any way to take clearly dead authors out of this category?--Prosfilaes (talk) 20:03, 14 June 2019 (UTC)

I expect that if you add a death year to Wikidata (including "unknown value") it will have the desired effect. Birth year before currentyear-110 also works. —Beleg Tâl (talk) 23:30, 14 June 2019 (UTC)
Yes, filling death year to Wikidata works. However, there are still some unsolved issues, e.g. when only work period start and work period end are filled at Wikidata. So, e. g. Author:Mansur II is still categorized as living. --Jan Kameníček (talk) 19:39, 15 June 2019 (UTC)
I fixed that one, thus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:32, 15 June 2019 (UTC)
Thanks for solving this one, but I am afraid making up some "latest date" of death individually at every page is not a solution. Some general solution would be much better. E. g. the author template could react to "work period end" in a similar way as it does to "death date". --Jan Kameníček (talk) 20:54, 15 June 2019 (UTC)
I'm not suggesting "making up" anything; I'm suggesting the value be estimated from the available facts. Changing the template here, far from being a "general solution", does not help other users of Wikidata's data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 15 June 2019 (UTC)

I understand what you mean. However, coincidental individual estimation of every single person with unknown date is imo not a good idea. If we do not want to appear cases like Mansur II before you individually fixed it, we should modify our author template, which would result in immediate correction of all existing and also future author pages ot this kind.

This does not mean that Wikidata cannot be edited as well, but are we sure they want it this way?

  • They distribute data to more wikiprojects than to Wikisource and even outside Wikimedia projects. I am not sure if you made your estimation based on some Wikidata consensus. If not, we may have a discussion here and decide that a person is most probably dead e. g. after work period end + 90, but for consistency reasons we should not insert Wikisource conception to Wikidata until we know that this is widely acceptable for them (and not e. g. +100). I failed to find any discussion of this kind at Wikidata.
  • Wikidata definitely have better tools how to add +90, +100 or whatever to the work period end to show that the person has most probably died, than relying on individual and coincidental manual edits which may (unlike automatic addition) insert numerical mistakes or add different numbers than has been decided. --Jan Kameníček (talk) 22:03, 15 June 2019 (UTC)
Nobody's suggesting automatically entering last work+X death dates on Wikidata, as far as I can tell. WD does specifically have tools to add estimates, such as the qualifier Andy used, or the "sourcing circumstances" qualifier which can take the value possibly (among others). Those are there, to my understanding, precisely so that they can be used in cases like this. If there aren't death dates available on other Wikimedia projects then case-by-case manual editing seems like the only solution to me, and certainly the only reliable one. —Nizolan (talk) 23:46, 15 June 2019 (UTC)
OK, but the main problem is that manual editing is too coincidental, while modifying the author template solves it much better and forever. Andy edited Mansur II at Wikidata only because I mentioned this author here. Others stay unsolved and even more other unsolved authors are to appear in the future. This does not mean that people cannot edit Wikidata at the same time. --Jan Kameníček (talk) 09:00, 16 June 2019 (UTC)
"modifying the author template solves it much better and forever" for some value of "it". What you're describing is simply a local hack, which would leave the two projects containing divergent data, instead of in sync with each other. That's neither better, nor sustainable in the long-term. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:12, 18 June 2019 (UTC)
"Are we sure they want it this way?" Yes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:12, 18 June 2019 (UTC)

Files in Category:Extracts from Mueller Report[edit]

As per Commons:Deletion requests/Files in Category:Extracts from Mueller Report, these images should be moved to here:

I am unaware of any easy way of doing this, so any assistance for this matter is greatly appreciated. -Einstein95 (talk) 09:03, 16 June 2019 (UTC)

these were kept as de minimus. c:Commons:Deletion requests/File:Report On The Investigation Into Russian Interference In The 2016 Presidential Election.pdf they can transfer them, if they choose to.
we also lack a consensus for "fair use" here; see also Wikisource:Scriptorium/Archives/2016-10#Exemption_Doctrine_Policy_(EDP), and Wikisource:Scriptorium/Archives/2014-05#Dealing_with_non-free_images_in_transcriptions_of_freely_licensed_works Slowking4SvG's revenge 11:32, 16 June 2019 (UTC)
Lovely. -Einstein95 (talk) 13:16, 16 June 2019 (UTC)
yeah, i was proven wrong about that deletion close, but not about the consensus. as we see, they will continue to nominate until they get the result they want. Slowking4SvG's revenge 15:44, 16 June 2019 (UTC)
Fair use is explicitly prohibited on Wikisource. With no consensus to amend the policy, fair use remains unacceptable here. —Beleg Tâl (talk) 13:52, 16 June 2019 (UTC)
It is correctly stated there that "reproducing whole works is not fair use" and because we reproduce whole works, it is quite logical that fair use is not allowed here. However, imo we could accept some exceptions for works which are in public domain but contain minor parts (e. g. a couple of photographs), which are not. Of course a clear consensus about it would be needed. --Jan Kameníček (talk) 15:39, 16 June 2019 (UTC)
so, you are still prepared to veto a reasonable compromise, despite the harm it would cause the dissimination of knowledge? Slowking4SvG's revenge 15:41, 16 June 2019 (UTC)
Beleg Tâl is not attempting to "veto a reasonable compromise", just pointing out that, as it currently stands, that compromise is not permissible per policy. Pppery (talk) 16:30, 18 June 2019 (UTC)
on the contrary, when a proposal is on the table, and the comments are "IANAL" and "fair use not allowed", that is stonewalling and vetoing, not collaborating. rest assured commons and wikisource will get a black eye if these pages get deleted. [11] Slowking4SvG's revenge 20:18, 19 June 2019 (UTC)


Seeing lint errors all over the place, Is there a scan of this, so the import can be replaced? ShakespeareFan00 (talk) 09:57, 18 June 2019 (UTC)

There are scans available at IA but transcription work so far has been at Ante-Nicene Christian Library instead—basically "Library" is the original UK edition, "Fathers" is a later pirated American edition with a different structure. The imports of Ante-Nicene Fathers and Nicene Fathers seem to have quite a lot of errors in general. —Nizolan (talk) 23:59, 18 June 2019 (UTC)
The ANCL is one of my on-going projects. As I create each work in the ANCL, I am repointing any links to ANF to the proofread ANCL version. Once that's done, I'm then collapsing the ANF work down from lots of tiny pages to a single page. Because these are separately published editions with ANF having additional apparatus and commentary, they do both need to be kept. The import of ANF was via a bot and, as far as I can tell, there was minimal human proofreading or checking of layout etc. Hopefully, the collapsed works don't have the errors you are pointing at. Beeswaxcandle (talk) 07:01, 19 June 2019 (UTC)
Ante-Nicene Fathers/Volume III/Anti-Marcion/Against Praxeas/I is somewhere where a mainspace version of the OCR clean-up script would help. ShakespeareFan00 (talk) 09:17, 19 June 2019 (UTC)

Author mispelt[edit]

Author:Robert Beverly is misspelt and should be Author:Robert Beverley or as the wikipedia article, Author:Robert Beverly Jr. Could this be redirected, please? Cheers, Zoeannl (talk) 10:43, 18 June 2019 (UTC)

Yes check.svg Done -Einstein95 (talk) 11:56, 18 June 2019 (UTC)

Image only material out of scope?[edit]

Material that has no text is out of scope isn't it?

Page:Meeting in the Oval Office between Nixonand President Mobutu Sese Seku of Zaire - NARA - 194548.tif ShakespeareFan00 (talk) 15:23, 18 June 2019 (UTC)

  • Yes, that clearly is redundant to the commons image. Kges1901 (talk) 16:15, 18 June 2019 (UTC)
I've deleted it as out of scope. —Beleg Tâl (talk) 02:05, 19 June 2019 (UTC)

Page:February 1916 QST.djvu/21[edit]

LintErrors is being pedantic, It says there is a "fostered content" - There isn't, the sole issue seems to be an LST style section tag marking the portion that is the end of the table. It's a shame that despite the fact that I have mentioned issues like this REPEATEDLY, there is no-one seemingly able to finally resolve this once and for all by actually fixing LintErrors and the backend so contributors like me don't have to run=around playing "hunt the pendatic interaction minutiae'. Table syntax also needs updating so it can ACTUALLY be done neatly across multiple pages, rather than having to use the various "bodge" and "kludge" approaches currently needed. When I also say this needs to be fixed, I am seemingly ignored (sigh) ShakespeareFan00 (talk) 23:15, 18 June 2019 (UTC)

NYPL on renewals[edit]

NYPL has a blog on the state of copyright renewals, and their work to wrangle a database [12] -- Slowking4SvG's revenge 15:57, 19 June 2019 (UTC)

The Prince (Marriott)[edit]

What to do about seemingly abandoned transcriptions of non-scan backed efforts?

An agressive removal campaign would seem rash, but I am sorely tempted to do this for some works like this that have too much 'junk' from an interdetminate third party source (which isn't given.)

ShakespeareFan00 (talk) 19:32, 19 June 2019 (UTC)

here you go Slowking4SvG's revenge 19:43, 19 June 2019 (UTC)
Thanks, but for various reasons, it would need someone else to set up the index here, I am not editing at Commons until 2021 owing to a "misunderstanding". ShakespeareFan00 (talk) 20:29, 19 June 2019 (UTC)
ok, if by aggressive removal campaign, you mean getting others to upload to commons and do indexes here, i agree. we decreased non-scan backed by 1958 pages last year.[13] you realize that if you delete them, then all progress would be lost? Slowking4SvG's revenge 21:05, 19 June 2019 (UTC)
See File:The Prince (translated by William K. Marriott).djvu.--Prosfilaes (talk) 21:44, 19 June 2019 (UTC)

i see we have Wikisource:Requested_texts#Works_exist_at_Wikisource_—_candidates_for_addition_of_pagescans. if you put work w/o scans, we can bury you in indexes. Slowking4SvG's revenge 01:22, 20 June 2019 (UTC)
I would love to see more scanless works buried in indexes. —Beleg Tâl (talk) 03:15, 20 June 2019 (UTC)
(Smile) Always ways to create more work for the unpaid minions hard-working contributors , LOL ShakespeareFan00 (talk) 08:10, 20 June 2019 (UTC)

Authorship concerns[edit]

And I've found an anomaly - The Prince (Marriott)/Introduction credits Herbert Butterfield, the problem is that according to w:Herbert Butterfield he would have only been 8 in 1908, assuming the introduction is from the 1908 edition, (and in 1925 (the date reprint would still have been doing his MA, Not implausible for an MA student to write a book introduction though.) , hmmm. Who actually wrote the introduction and when? ShakespeareFan00 (talk) 23:54, 19 June 2019 (UTC)
@MartinPoulter:, Time to ask an expert. ShakespeareFan00 (talk) 00:14, 20 June 2019 (UTC)

Author:Niccolò Machiavelli also claims the introduction is by Butterfield, however I've only found him mentioned on post-war editions, NOT on the 1908 original ( or reprints.) So did someone when building the Author page and the works, essentially misread the bibliographic data? ShakespeareFan00 (talk) 17:53, 20 June 2019 (UTC)

Okay someone really needs to sort things out - The Annotated Prince has a potential misattribution as well, in that it claims the translation is Marriots, but The_Annotated_Prince/Chapter_I Claims to be the Thomson translation, which is DIFFERENT translation entirely (which is also not scan backed.)

Any experienced contributors here want to make things UNAMBIGUOUS before I have a screaming fit and re-instate the deletion for ALL the editions currently on Wikisource, So we can start again with a KNOWN "clean" and scan backed edition.. ShakespeareFan00 (talk) 18:03, 20 June 2019 (UTC)
Also A description of the methods adopted by the Duke Valentino when murdering Vitellozzo Vitelli, Oliverotto da Fermo, the Signor Pagolo, and the Duke di Gravina Orsini Credited as Marriot, but based on the lack of clarity noted above, I've marked it as unsourced. ShakespeareFan00 (talk) 18:08, 20 June 2019 (UTC)
i suspect that "introduction by Butterfield" is a later edition, given the lack of credit on the scan we have. i would adjust the guttenberg to reflect the front matter we have. hard to prove without some bibliography from subject matter expert. Slowking4SvG's revenge 01:54, 21 June 2019 (UTC)
That's why I put in a request to User:MartinPoulter, who has access to relevant library sources ShakespeareFan00 (talk) 08:04, 21 June 2019 (UTC)
The edition scanned is in parts post 1920, given a comment in an editorial by series editor Author:Ernest_Rhys (d. 1946) Page:The_Prince_(translated_by_William_K._Marriott).djvu/322)ShakespeareFan00 (talk) 08:18, 21 June 2019 (UTC)

Template Name collision...[edit]


This wronlgy assumes that {{P}} is the same as it was on Wikipedia at the time the documentation was imported, which it isn't, {{P}} locally is a different template used for marking up paragraph styles, which means this documentation page breaks. Can someone experienced resolve this issuse, perhaps by importing the updated {{Q}} and {{q}} from Wikipedia and updating this documentation appropriately? ShakespeareFan00 (talk) 21:53, 19 June 2019 (UTC)

@ShakespeareFan00: Yes check.svg Done I've imported {{wikidata entity link}} from enwp and redirected {{q}} to it. Note that {{Q}} and {{q}} are the same template (the first letter is case insensitive in MediaWiki, even when linking or invoking templates). {{wikidata entity link}} handles both entities (William Shakespeare (Q692)) and properties (given name (P735)) so there is no need for separate Q/P templates. Let me know if there are other issues. --Xover (talk) 05:32, 20 June 2019 (UTC)

Committee to Defend the United States Constitution v. Moon[edit]

Should I just inline the footnotes without leaving the [FN] style markers? ShakespeareFan00 (talk) 01:07, 20 June 2019 (UTC)

In my opinion: yes. —Beleg Tâl (talk) 03:12, 20 June 2019 (UTC)
Thanks, Can you look over my recent Lint removal efforts like this ? ShakespeareFan00 (talk) 08:28, 20 June 2019 (UTC)
No, I don't care about this lint stuff —Beleg Tâl (talk) 10:54, 20 June 2019 (UTC)

Oxon link template broken[edit]

There is something wrong with {{Oxon link}}... Levana Taylor (talk) 15:43, 20 June 2019 (UTC)

User:Billinghurst was working on it recently; perhaps they can help? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 20 June 2019 (UTC)
I haven't touched the cover template, or the underlying template in over a year. It looks to be working fine on the template/doc page, so can you please extrapolate on "something wrong" in terms of diffs, or explanation. — billinghurst sDrewth 21:27, 20 June 2019 (UTC)
First question usually is: are the instructions being followed? Two parameters {{Oxon link|name of article page|year of matriculation or B.A.}}billinghurst sDrewth 21:32, 20 June 2019 (UTC)
It works fine on author pages, so I don't know why the documentation page is displaying an expression error. Levana Taylor (talk) 23:13, 20 June 2019 (UTC)
It just needs a default value for the matric parameter; since it doesn't have a value on that page it reads #ifexpr: < 1715 expecting a number where "<" is and throws an "unexpected <" error. —Nizolan (talk) 23:28, 20 June 2019 (UTC)

Dynamic layout problems and proposed fixes[edit]

Coming across some problems with Layouts (see here). I've tested these with several different browsers. Firstly, the position of the header in Layout 3 seems to be off—I assume it is supposed to be above the sidenotes and not off the edge of the screen.

Sidenotes are also broken in Layout 4 (they overlap with the text) and Proposed Layout (they go past edge of screen).


  • Layout 3: headerContainer has the right width (21em to fit in the 23em margin of the layout) but should be at right: 0 not right: -23em which currently hides it off the edge of the screen.
  • Layout 4 sidenotes: I guess this was modelled on Layout 2 since they use the same numbers but the body in Layout 2 is 36em wide whereas Layout 4 has a fixed width of 540px. The style applies left: 37em; this should instead be measured from the right e.g. right: -17em (since the width of the box is 16em).
  • Proposed Layout sidenotes: The style applies right: -10em. This should be adjusted to e.g. right: -4em. —Nizolan (talk) 16:30, 20 June 2019 (UTC)

Wanted: User script for missing images[edit]

Where an image is missing, the template {{missing image}} renders with text like:

To use the entire page scan as a placeholder, edit this page and replace "{{missing image}}" with "{{raw image|The British Warblers A History with Problems of Their Lives - 5 of 9.djvu/6}}".

Is there (or could someone make) a user script that would, say, add a button to automatically make the suggested replacement? Maybe User:Samwilson, whose other scripts are fab, can help? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:21, 20 June 2019 (UTC)

Another non scan backed work[edit]

Copyright check is suggested as the work is after 1924, and this URAA may be aplicable. Keynes died in 1946 so it is PD in the UK (original publication location.)ShakespeareFan00 (talk) 19:47, 20 June 2019 (UTC)

You might be right; 1946 is one year too late for copyright to have expired in 1996. —Beleg Tâl (talk) 12:16, 21 June 2019 (UTC)
The UK went life+70 on 1996, apparently specifically timed to grab that extra 20 years from the URAA. --Prosfilaes (talk) 17:56, 21 June 2019 (UTC)

Biographical enquiry Author:Aaron Thompson[edit]

Anyone else got more information on this person, ( It's not the Basbeball player), but so far I've only been able to find an uncertain birth date around 1681.. ? ShakespeareFan00 (talk) 10:30, 21 June 2019 (UTC)

Fellow of Queen's College, Oxon; born 1681 or 1682; translated Monmouth's The British History into English —Beleg Tâl (talk) 10:46, 21 June 2019 (UTC)
Thence: Echard, Siân "Remembering Brutus: Aaron Thompson's British History of 1718", Arthurian Literature 30, 2013. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:58, 21 June 2019 (UTC)

Index:The Prince (translated by William K. Marriott).djvu text complete...[edit]

Text complete. If someone wants to assemble and figure out formatting for the notes and Index. ThanksShakespeareFan00 (talk) 13:44, 21 June 2019 (UTC)

I wonder which header style is preferred, if any: used here vs. automatic? (And, if the firs one is preferred, why the automatic is different?) Ankry (talk) 06:06, 27 June 2019 (UTC)

Bio query[edit]

Author:Gladys Thomas & Author:Mary F. Guillemard associated with the translation of Rostand's Cyrano de Bergerac ?ShakespeareFan00 (talk) 15:01, 21 June 2019 (UTC)

Think I've identified the second because there's only one Mary F. Guillemard in UK census records from the period: Mary Frances Guillemard, born Dublin 1856, apparently lived in Kent for most of her life, died 1930. Probably the same Mary Guillemard who wrote a jingoist poem, "Fill Up the Ranks", published in the UK Cambridge Magazine in 1914. I've got nothing for Gladys Thomas; the name's too non-specific to check government records. —Nizolan (talk) 20:33, 21 June 2019 (UTC)
Do we know that either or both were in the UK? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:05, 21 June 2019 (UTC)
"Gladys Thomas and Mary F. Guillemard, who we understand are London women..." hereNizolan (talk) 23:24, 21 June 2019 (UTC)
Thomas has a VIAF ID: 315182819 and Library of Congress ID: no2015031802. Guillemard is VIAF: 51467264; LoC: no2007059400. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 21 June 2019 (UTC)

Did page validation process changed?[edit]

Could and would someone enlighten me what process validated this page, but there is no validation history.Ineuw (talk) 22:03, 21 June 2019 (UTC)

@Ineuw: it was created as proofread (Special:Permalink/8825300) and validated in Special:Diff/8910736 - is that what you were looking for? --DannyS712 (talk) 22:16, 21 June 2019 (UTC)
Thank you, and yes (said he sheepishly) Ineuw (talk) 22:21, 21 June 2019 (UTC)
@Ineuw: no problem. I took a look at your user page, and see your an admin - any chance you can take a look at Wikisource:Administrators' noticeboard#Request for autopatrol? Its been sitting there for a couple days. See Index:Alabama v. North Carolina, 560 U.S. (2010) slip opinion.pdf and Index:Fisher v. University of Texas at Austin, 579 U.S. (2016) (slip opinion).pdf for my recent project. Thanks --DannyS712 (talk) 22:25, 21 June 2019 (UTC)
@Ineuw: Thanks, I just didn't want to be a burden with new pages - if there are any issues with my pages so far please let me know --DannyS712 (talk) 22:40, 21 June 2019 (UTC)
Glad to help. All I did was to increase the font size and the space above the title pages for better legibility, . . . . according to my ideas, which varies with every editor. The important part of editing is consistency in a project.
Also, page footnotes are converted into one unified endnote in the main namespace page. To keep them separate, one needs a separate main namespace page for each chapter or heading, and footnotes would still end up as a single endnote, but for the chapter. Ineuw (talk) 00:14, 22 June 2019 (UTC)
Okay, thanks --DannyS712 (talk) 00:16, 22 June 2019 (UTC)

Mathilde Leiris[edit]

Hello from the French language wikisource; we have worked on a book published in New Orleans in 1835. Does anyone (for instance in Louisiana) have bibliographical details about its translator, Mathilde Leiris in order to enrich her wikidata record ? Thanks a lot for your help. Hektor (talk) 11:35, 23 June 2019 (UTC)

Tech News: 2019-26[edit]

17:30, 24 June 2019 (UTC)

Use of HTML element IDs[edit]

I'm trying to clean up some warnings currently being issued by epubcheck for epubs generated by wsexport, and would like to make this change: Template_talk:License#Why_have_element_IDs? Sam Wilson 05:10, 25 June 2019 (UTC)

Symbol support vote.svg SupportBeleg Tâl (talk) 12:48, 25 June 2019 (UTC)
Yes check.svg Done And the epub test suite is improved another couple of points. :-) I'll keep digging through it (~45 to go). Sam Wilson 02:28, 26 June 2019 (UTC)

Biogaphical checks...[edit]

I made a table of the figures mentioned in the title page of a work here - Index talk:Memorials of Affairs of State in the Reigns of Queen Elizabeth and King James Volume One.pdf

but would appreciate a second view, before I create the red-linked author pages, to be sure I've identified the correct historical indviduals.

Additionally, the Cornwallis referenced in an earlier indvidual than the one English Wikisource has an Author page for, I was not sure how to do the disambig for this? ShakespeareFan00 (talk) 10:36, 26 June 2019 (UTC)

Reducing unlinked pages...[edit]

I've been attempting to resolve some of the lower hanging fruit here. I'm hitting the limits of research skill with more than a few of the remainin entries, and it would be appreciated if some more experienced contributors here would be able to link some of the Index: pages with "corporate" authors, to appropriate Author: or Portal: pages.

Thanks. ShakespeareFan00 (talk) 14:31, 26 June 2019 (UTC)

Templates that generate external links inside works (Template:Ussclinker)[edit]

I just came across {{Ussclinker}}. It appears to be intended for use in works that refer to US Supreme Court decisions, and generates output like this:

Note that the case number (726 and 103) is linked to an external website that is configurable, enwp being one option, but defaults to The link targets are themselves works that could, should, and sometimes already are hosted here on enWS. The template is transcluded on the order of 150–200 times.

Is this in keeping with our practices for linking inside works? Do we want to permit such external links (some of which are commercial, some directly antithetical to our mission, one domain has been usurped and now appears to serve ads for German credit cards or something)?

The other functionality of the template appears to be good and useful; but I am, personally, quite sceptical of the external links portion and would like the community's input on this. --Xover (talk) 14:46, 26 June 2019 (UTC)

And now that I look at it, there seems to be a whole suite of similar templates, many of whom link to external sites. They appear to have been cut&paste imported from enwp where their purpose is to be used for citations, where such external links would be not just ok but actively desirable, and not made specifically for enWS. Which may explain why they function the way they do. --Xover (talk) 16:48, 26 June 2019 (UTC)
Agree, we should definitely not make external links to non-Wikimedia projects from inside the works. Even links to Wikimedia projects like Wikipedia or Commons are controversial and should be used quite rarely. --Jan Kameníček (talk) 16:58, 26 June 2019 (UTC)
I can foresee cases where we should do that; for example, modern open-licence works where the text has URLs written inline. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:50, 28 June 2019 (UTC)
Sure, but that would be a set of pretty clearly delineated special cases, so I don't think we need to worry overmuch about that in this context. If it ever becomes an issue in practice we can have a general discussion about those at [[WS:Wikilinks]. --Xover (talk) 12:22, 28 June 2019 (UTC)

Pictogram voting comment.svg Comment @Xover: If the links are sitting on portal or author pages they are perfectly within scope. If they are sitting on main ns pages, if they are in the notes section, they would be acceptable, if they are sitting in the body of the work, then they are less acceptable per WS:wikilinksbillinghurst sDrewth 06:32, 28 June 2019 (UTC)

@Billinghurst: My apologies, I should have specified. Yes, they are indeed being used—and appear to be intended to be used—in the body of works. See e.g. Roe v. Wade. --Xover (talk) 07:36, 28 June 2019 (UTC)

Issues with Robert the Bruce and the struggle for Scottish independence[edit]


I have had a go at creating the Chapters for Robert the Bruce and the struggle for Scottish independence but have noticed a couple of issues that I am unable to resolve.

Issue 1. I created the Front Matter page listings, but I see that the Illustrations listings from page (25) display as if they were on page 26 with red links showing instead of the blue links from the actual page view.

Issue 2. In the Chapter Robert the Bruce and the struggle for Scottish independence/The Revolt of Robert de Brus the table crossing between pages 121 and 122 is not displaying correctly.

I'd appreciate if someone has time to help in correcting these issues.

Thanks Sp1nd01 (talk) 14:49, 26 June 2019 (UTC)

{{TOC link}} links to the page number parameter when displayed in Page: namespace and to the chapter name parameter when displayed in the Main namespace. Since you've specified (e.g.) {{TOC link|31|SILVER PENNY OF JOHN DE BALLIOL |1}}, this will link to Page:Robert the Bruce and the struggle for Scottish independence - 1909.djvu/31 in Page:, and Robert the Bruce and the struggle for Scottish independence/SILVER PENNY OF JOHN DE BALLIOL#1 in Main. The second parameter should be corrected to the name of the chapter under which the illustrations appear.
I have fixed the table. —Nizolan (talk) 14:55, 26 June 2019 (UTC)
Thanks so much for your help and fix.
I'd not come across the ToC links previously, I was simply copying what someone did in the Chapter listings for consistency. I'll correct all those ToC Links parameters to the name of the associated chapter. Sp1nd01 (talk) 15:25, 26 June 2019 (UTC)

Index:The Female-Impersonators 1922 book scan.djvu[edit]

The book gives a number of names for the Author, What name should be on the Author: page taking into account the appropriate sensitivities? ShakespeareFan00 (talk) 11:18, 27 June 2019 (UTC)

That would be ; I'd go with the English Wikipedia and use Jennie June. The Swedish and Wikidata use Earl Lind as the page name, but the Arabic goes for a transliteration of Jennie June.--Prosfilaes (talk) 21:24, 27 June 2019 (UTC)
Looking at Wikisource:Author names it seems that if the person uses multiple names/pseudonyms then the full name should be used. It is not specified there what exactly is meant by the full name, but the given examples show that it should be the original or "real" name of the person. If all three given names and pseudonyms are used to denote the person in bibliographical records, then Earl Lind should be the choice. What is more, bibliographical databases like LOC or VIAF prefer Earl Lind as well (both mentioning also the pseudonym Ralph Werther and only LOC mentioning also Jennie June). --Jan Kameníček (talk) 22:32, 27 June 2019 (UTC)
Full names are preferred over abbreviated names, but there is no consensus with regards to people with multiple names. I am inclined to go with Lind for the sole reason that it seems to be preferred by other bibliographical databases. —Beleg Tâl (talk) 00:10, 28 June 2019 (UTC)

Pictogram voting comment.svg Comment Personally I believe that all author pages belong at the real names. Trying to play chase the pseudonym and resolve that battle, especially where users wrote under their real name, and maybe under one or two pseudonyms, some equally famous. We have had this argument before and there is no perfect answer, and there are complex discussions around disambiguation, etc. In the end, their real name is their real name, it is usually the name by which the biographies are published, and it is the perfect thing to disambiguate to as a final result, and it is definitive. We have redirects, we have lookups, that will allow us to resolve those other matters. It is also much easier in which to give instruction of author pages at real names, fully expanded; create redirects for the alternatives. — billinghurst sDrewth 06:26, 28 June 2019 (UTC)

Pseudonymns are not the only use case; marital surnames, religious names, and (like this one) deliberate name changes are all common and both their old and new names can be considered their "real" names. —Beleg Tâl (talk) 14:38, 28 June 2019 (UTC)

Duplicate transclusions...[edit]

An Introduction to the Philosophy of Consciousness (Part 2) with Blackwood's Magazine/Volume 43/Issue 270/An Introduction to the Philosophy of Consciousness (Part 2).

Retain, Redirect, ignore? ShakespeareFan00 (talk) 15:14, 27 June 2019 (UTC)

Redirect the first to the second (for the volume structure) I think… —Nizolan (talk) 15:18, 27 June 2019 (UTC)
I would actually delete the former entirely; there should be a redirect for An Introduction to the Philosophy of Consciousness but I see no reason to have redirects for its subparts. —Beleg Tâl (talk) 17:04, 27 June 2019 (UTC)
Also, the work structure for Blackwood's Magazine is a disaster, I'll see if I can straighten it out when I have a chance —Beleg Tâl (talk) 17:06, 27 June 2019 (UTC)
Yes check.svg Done , redundant link speedily deleted; misplaced articles relocated; headers updated, all good now —Beleg Tâl (talk) 20:12, 27 June 2019 (UTC)

Placing replacement scans at the end of a work? Shouldn't they ultimately be integrated in the djvu?[edit]

Index:Miscellaneous Writings.djvu

In this work, the original scan contained some absent pages, which were provided as additional JPG's and appended at the end of the pagelist.

Prior to some concerns on the talk page for {{integrate pages}}, it was my understanding that previous practice here at English Wikisource had been to repair the djvu by inserting the respective JPEG's back into the Djvu file so that there was a complete file. (This has been done a few other works.)

A while back I'd created {{Integrate pages}} to mark the Index: pages I'd identified as having this issue, and a tracking category (which hopefully should remain empty most of the time.

Some concerns were expressed on the talk page for the template concerned (which I've downgraded to being a 'tracking category' insertion only), pending a wider request for views here.

ShakespeareFan00 (talk) 18:42, 27 June 2019 (UTC)

I agree that the pages should be integrated, though I think it would make more sense to post to #Repairs (and moves) above, rather than simply tagging them into a tracking category that no one but you is monitoring. —Beleg Tâl (talk) 20:16, 27 June 2019 (UTC)


Erm where is the header param for the pages tag documented?

Its used here: The Life of the Spider/The Garden Spiders: The Telegraph-Wire?

ShakespeareFan00 (talk) 14:44, 30 June 2019 (UTC)

@ShakespeareFan00: "Documentation" may be giving it more credit than it merits, but there's something at oldwikisource:Wikisource:ProofreadPage#Headers_and_Navigation. --Xover (talk) 15:31, 30 June 2019 (UTC)
notes at MediaWiki:Proofreadpage header templatebillinghurst sDrewth 02:43, 1 July 2019 (UTC)

Proofreading, OCR cleanup script...[edit]

Would it be possible for the relevant portion of this script to note ¬ as a line continuation marker and remove collapse text in which it appears appropriately? ShakespeareFan00 (talk) 11:46, 1 July 2019 (UTC)

Similar to what was done here ?

ShakespeareFan00 (talk) 11:50, 1 July 2019 (UTC)

I agree, I've had texts where that would be very useful. Maybe that character is frequently substituted for a hyphen by some common OCR algorithm? -Pete (talk) 02:04, 2 July 2019 (UTC)

Biographical Enquires (Railway Junction Diagrams on Commons).[edit]

A long shot but I thought I'd ask here, as the Wikisource community is typically good at finding really really obscure biogrpahical sources and details.

A while back someone uploaded a set of Railway Junction Diagrams to Commons (I'm not editing on Commons until 2021 currently.), but in doing some research at on something else, additional information arose due to

That base map seems to have been drawn by a John Airey (?-?) , ( who in some other sources is also credited with the the Junction diagrams.) with the engraving by (J & W Emslie)

A lot of use of Google later and I found:

  • Emslie, John Philip (1839-1913 )
  • Emslie, W.R (?-?) (Brother to above?)

here - being in "Benezit Dictionary of British Graphic Artists and Illustrators.", 2001, Oxford University Press.

I've not found any further details on W.R. Emslie, although context suggests by 1914, he and J.P had a company or partnership that did engravings.

I've also not yet found any dates for Airey in online sources.

If the 1914 diagrams (or any prior to 1923) can be more conclusively linked with Airey, and shown to be Public domain it would be very useful information for someone to add at Commons, (someone who might also be interested in uploading the map concerned). I seem to also recall that a later issue of the map (in 1948) (still in copyright, sadly) had an index of stations. ShakespeareFan00 (talk) 16:38, 1 July 2019 (UTC)

What is your question? What is it that you are wanting? — billinghurst sDrewth 23:27, 2 July 2019 (UTC)
If it is who is John Airey, looks to have been born in Stainton or Kendal, Westmorland c.1836, and looks to have died 1 Dec. 1924; buried 2 Dec 1924 (somewhat confirmed). Appears in census as clerk, or railway clerk, 1911 census says pensioner, clerk from RCH. Directories for London indicate that he appears to also have been running a map selling business from Euston station. — billinghurst sDrewth 00:00, 3 July 2019 (UTC)
Thanks , thats exactly the information I needed. ShakespeareFan00 (talk) 08:55, 3 July 2019 (UTC)

Tech News: 2019-27[edit]

21:23, 1 July 2019 (UTC)

Revisiting curly quotes[edit]

Per EncycloPetey's suggestion at the style guide talk page, I would like to have the community revisit the idea of allowing curly quotes. Personally, I hate curly quotes and think they are a pox on humanity, but considering how we go to such great lengths to make our source texts faithful to the originals, it does seem like a prominent inconsistency. I'll try to list a few of the advantages and disadvantages that have been discussed...

  • Can be more faithful to original text.
  • Consistent with Project Gutenberg (and probably the majority of commercial e-texts).
  • In some cases, may be easier to read, especially when multiple quote characters are in sequence.


  • Harder to enter.
  • Some browsers may not be able to render (according to EncycloPetey in 2015).
  • They are often used incorrectly.

As this would be an optional style, I wouldn't give much weight to it being difficult to enter. It's certainly easier that most of our TOCs. And given that it's been 5 years since this was last debated, I have serious doubts that there are still issues around rendering. That basically leaves the objection that they are often used incorrectly, which I would say is also true of all the different dash characters we allow (and even expect). Are there other disadvantages that I'm forgetting? I suppose one is that it would cause inconsistent styles across Wikisource. What are other folks' opinions and thoughts about this? Kaldari (talk) 01:41, 2 July 2019 (UTC)

Curly quotes are better typography and are recommended by Unicode. Some quotation styles are not compatible with straight quotes (like „German quotations“). Browsers that can't handle basic web standards like Unicode are going to have far more serious problems on Wikisource than being able to render curly quotes. It is ridiculous that curly quotes are against our MOS. —Beleg Tâl (talk) 01:48, 2 July 2019 (UTC)
Re: "more faithful to original text" No, this is a typography issue, and has nothing to do with faithfulness to a text. A text has curly quotes because of a printer's choices, not any choice made by the author. And just as we do not specify fonts, we shouldn't bother specifying specific styles of punctuation either. Re: "Consistent with Project Gutenberg" this is irrelevant, and is at odds with the previous claim that using curly quotes would be "faithful to original text". If we're worried about the original text, then why should we care what other sites are doing? And if we're worried about what other sites are doing, then we're not caring about the original text. I'd also point out that Project Gutenberg is in no way consistent about the style of quotes they use. Additional disadvantage: We will need an additional series of quotation template to handle situations currently done with templates like {{' "}} which provide for clarity of punctuation. --EncycloPetey (talk) 03:32, 2 July 2019 (UTC)
It seems like we often try pretty hard to match the typography in the source: Page:KJV 1769 Oxford Edition, vol. 1.djvu/10. Should this be discouraged, in your opinion? Kaldari (talk) 04:02, 2 July 2019 (UTC)
RE: "we often", no this was a single editor over-formatting that page. --EncycloPetey (talk) 17:22, 6 July 2019 (UTC)
  • Pictogram voting comment.svg Comment In the vast bulk of our works curly quotes are not required, and should not be encouraged, and their addition doesn't give value to the works, ie. disadvantages outweigh advantages, especially in true communal works. That said, we have always allowed some variation where there is a reasonable explanation of why a deviation from the style guide can be justified. We haven't been absolutionist about these matters, we just have a valid reasoning for setting a style guide, and generally asking people to follow it, and not deviate "just because", or "because I like them better". The test for a deviation has been an open conversation, and a semblance of consensus. — billinghurst sDrewth 05:32, 2 July 2019 (UTC)
In the vast majority of our works, neither casing, accents nor non-monospace fonts are required. We could go all old-school computer printout style, but given that we support Unicode and rich text, it seems reasonable that we write English as it is supposed to be written, with curly quotes. Their addition makes the text easier to read by adding additional cues as to the meaning of a quote, whether it is opening a quote or closing it. --Prosfilaes (talk) 07:14, 2 July 2019 (UTC)
I Would Çonsidér Accürate Reprǒductión Of Casing And Aççénts To Be Requĩred —Beleg Tâl (talk) 12:58, 2 July 2019 (UTC)
I THINK DECADES OF TELEGRAPHIC AND COMPUTER USE ESTABLISH THAT ACCURATE REPRODUCTION OF CASING IS NOT REQUIRED and a lack of accents in English has decades more of use with ASCII and normal keyboards.--Prosfilaes (talk) 09:32, 3 July 2019 (UTC)
I was considering opening up a discussion on this; it definitely is more faithful to the way English is published. Typographical norms should not be scorned for just being typographical norms.--Prosfilaes (talk) 07:14, 2 July 2019 (UTC)
  • Pictogram voting comment.svg Comment I wouldn't mind them being used but I wouldn't use them personally, because it's another pain for us proofreaders to worry about that isn't worth the hassle. I wouldn't discourage other users from using them though, neither would I mind if a user were to add them in to a work I've proofread and used straight quotes on. In my opinion it is a minor typography issue and I really wouln't care if they're used or not. Jpez (talk) 11:45, 2 July 2019 (UTC)
  • Pictogram voting comment.svg Comment The relevant current text of the Manual of Style reads:
"Use typewriter quotation marks (straight, not curly)."
I agree with what I think most above are saying, which I think would be most succinctly stated as follows:
"Any given work should be self-consistent in terms of the style of quotation marks and apostrophes used. That is, such marks should either all be curly, or all be straight, within any given work. If the initial transcriber of a work has chosen one style, the other style should not be adopted in that work unless a user intends to update the entire work to the new style choice."
I am very skeptical about this: "unless a user intends to update the entire work to the new style choice". Imagine occasional proofreaders doing small chunks of an encyclopedia. I doubt they will check what others have done and even more make it consistent. Pretty sure we will end up with mixed style except for committed users on single works.— Mpaa (talk) 23:30, 2 July 2019 (UTC)
@Mpaa: That's exactly the kind of thing I'm imagining (and have experienced). Here's how I imagine it working, with such a policy (perhaps worded a bit better) in place:
  • Me: Hi, I see you've validated about 5% of the pages of this work. That's awesome, thanks! I've proofread about 80% of them. I see that you have changed straight quotes to curly. Are you intending to go through the whole document and change them all to curly?
  1. Other editor: Yes, I plan to do that.
Me: Great! I look forward to seeing the final result.
  1. Other editor: No, I was just passing through, only interested in this one chapter of the book. I probably won't do more than a few more.
Me: Ah, I see. In that case, would you mind sticking with the convention I began with? (links to MOS) I'd rather stick with straight quotes than go to the trouble of updating all the pages.
In my view, that's a nice, easy way to resolve this "conflict" (which doesn't even need to be a conflict). Having a manual of style that guides us in this direction would, in my view, be a great advantage, and make it possible to quickly and easily arrive at an acceptable solution. -Pete (talk) 22:04, 3 July 2019 (UTC)
A satisfactory solution to an imaginary and likely situation, but that is not how it plays out in folk-lore. CYGNIS INSIGNIS 11:26, 6 July 2019 (UTC)
Hmm, I don't see anything relevant on that work's discussion pages, what am I missing? This is a type interaction I've seen work on many wikis over the years. I'm not sure where you'd anticipate it going off the rails...but, having a clearly articulated policy that sets the parameters is a necessary ingredient. -Pete (talk) 22:19, 6 July 2019 (UTC)
One practical concern is that various automated tools implement one style or the other, and may need to be rewritten or eschewed in order to comply with a change in the Manual of Style. -Pete (talk) 20:27, 2 July 2019 (UTC)
One of the reasons why I was doing this was because the OCR seems to spit out curly quotes, and I was tired of fixing them.
I’m guilty of using curly quotes in some works, where I am (or try to be) completely consistent throughout the whole work. That said, I normally only do it in novels (or this comment), where I’m planing on spending a fair bit of time sitting reading the thing — I think proper typography matters more then (and indeed, I’d say curly quotes, along with correctly-sized dashes and various other non-typewriter or -computer conventions are “proper”). For reference, non-prose, works, I think straight quotes are fine. (Maybe the distinction I’m getting at is between works with large amounts of dialog and those without?) I’ve seen people make the argument that they’re not required because we can make automatic replacements later, but that’s not really true: there are various situations in which it’s impossible to programmatically determine which type of quote character should be used. Anyway, I hope I’m not on the wrong side of common opinion here, but I do like to be able to use curly quotes on Wikisource. —Sam Wilson 11:33, 3 July 2019 (UTC)
I agree with this and Jpez's comment above. I don't see a good reason to forbid them categorically, and can see plausible use cases in novels and the like, even though I probably wouldn't use them myself (the projects I work on are generally academic and often require enough heavy lifting in Unicode without having to fiddle with quote marks). —Nizolan (talk) 14:30, 3 July 2019 (UTC)
On a personal level, I like curly quotes & find them easier to read. But from an editor's-usability standpoint it sure does make sense to convert everything to straight quotes, as the only way to avoid inconsistency. It is much easier to convert curly to straight than vice versa; I have a little application to straighten the quotes in all OCR output, but the reverse process would be no easy matter. I actually began entering Once a Week magazine with curly quotes but EncyloPetey pointed out the standards so I went through several hundred pages I'd entered and straightened the quotes. I am now up to 2000 pages and I am most emphatically not going to revisit all of them and curlify them .... We seem to be stuck with straight quotes as a legacy issue. There would have been ways to make entering curly quotes easier if they had been favored from the beginning; and the OCR output from the application that this site uses now gives us them automatically; but although I don't see a problem with allowing them in certain cases (there are, for a parallel example, a few texts displayed with long s's) a person would have to be urged to think carefully before they started down that route, because so much of the existing apparatus favors straight quotes that avoiding inconsistency would be difficult. Levana Taylor (talk) 23:08, 3 July 2019 (UTC)
It is much easier to convert curly to straight than vice versa is also an argument for curly quotes; transcribing text is all about recovering information from the images that can't be done automatically.
We should be stuck with nothing as legacy issues. If it's better we should make the change, and earlier is better. I'm not sure that much of the existing apparatus favors straight quotes, but this is a chance to change the existing apparatus.--Prosfilaes (talk) 01:07, 4 July 2019 (UTC)
Curly quotation marks are a legacy of printed blocks of text that required incremental spacing, denoting a beginning or end of a quotation if the squelching and stretching of the line made that ambiguous, and few of those legacies are transcribed here (often [or yet]). CYGNIS INSIGNIS 11:18, 6 July 2019 (UTC)
Quotation marks are a legacy of printing; inline quotation marks date no earlier than the 17th century. Printing pervades how we write English, and an attempt to abandon those legacies would produce something unusable or unwelcomed by most of our audience.--Prosfilaes (talk) 07:15, 7 July 2019 (UTC)
There is nothing difficult in writing curly quotes. On Macs and on all modern mobile devices they are easy to enter using the built-in keyboards. On Windows it's probably not built into the default keyboard, but that's what the Special characters button is for.
Old browsers are not a reason not to use modern technology. If they aren't upgraded today, they will be upgraded in a year or two.
A lot of websites that care about quality of presentation use curly quotes. Wikis in some languages have a gadget that converts straight quotes to elegant quotes automatically. Some sites where text can be edited do it as well, for example Quora, and Wikisource could do it (it must not be forced, though).
I actually find it surprising that there are people on English wiki sites who are against curly quotes, given that the English language has such a long typographic tradition of using rich punctuation, with quotes, dashes of various length, etc. --Amir E. Aharoni (talk) 05:47, 4 July 2019 (UTC)

(unindent) I have an idea; it'd take some programming, though. Suppose it was allowed to enter curly quotes, but the software would display them as straight quotes by default. That way, if only part of a text was entered curly, people would usually never notice because it'd all be displayed straight. However, there'd be a user-controlled setting allowing displaying curly quotes where they exist. Levana Taylor (talk) 02:12, 5 July 2019 (UTC)

I don't see the advantage. There's a lot of criticism of the "just add another user-controlled setting" idea in the UI world. It seems a lot better to offer tools to help make the changes and encourage not doing inconsistent changes.--Prosfilaes (talk) 03:46, 5 July 2019 (UTC)
I am also not sure it's a good idea to correct all curly quotes to typewriter quotes user-side by default. There are some cases in texts I've transcribed myself where curly quotes are necessary independently of the general guideline. An example of this is in transliterations of Semitic languages, where the distinct letters ayin and aleph (the half-rings ʿ and ʾ in modern scientific transcription) are often represented by curly apostrophes, ‘ and ’ respectively. In this case correcting these to typewriter quotes would remove necessary information. —Nizolan (talk) 11:51, 5 July 2019 (UTC)
Some additional advantages and disadvantages have been mentioned:
More Advantages:
  • Easier to convert from curly quotes to straight quotes than vice versa.
  • OCR tools already output curly quotes.
More Disadvantages:
  • Some new templates will be needed.
  • Some tools will need to be updated.
Let me know if I'm overlooking any. Kaldari (talk) 04:53, 6 July 2019 (UTC)
  • @EncycloPetey: I'm curious if any of the arguments above have led you to reconsider your opposition (as you seem to be the main opponent of the idea). Kaldari (talk) 04:54, 6 July 2019 (UTC)
    I may be more vocal, but that doesn't mean I'm the "main opponent", it merely means that my voice is stronger in this discussion. It is normal in the Wikisource community for long-time participants to sit back and read discussions without chiming in, so long as their opinion has been expressed by someone in the discussion. I have done this myself. No one in this discussion has explicitly voiced support or oppose, and it would be premature to interpret anyone's opinion when there has been no call for a vote. You've also biased your interpretation: where some editors have said "I don't care", you have interpreted that as "support", but it is not at all the same thing. This is a "community revisit", and not a vote to change policy. --EncycloPetey (talk) 17:32, 6 July 2019 (UTC)
    For the record, I explicitly Symbol support vote.svg Support changing the policy to allow curly quotes at the editor's discretion, and Symbol oppose vote.svg Oppose continuing to disallow curly quotes. However, this discussion didn't contain a proposal either way, so it doesn't matter until someone posts a proposal for !voting. —Beleg Tâl (talk) 23:19, 6 July 2019 (UTC)
  • I think Kaldari's summary is helpful, and I'm not sure why we're talking about whether this is a formal vote when nobody has claimed that it is. FWIW I have no objection to the characterization of my position. I like Jan's version below, making "straight" the default and only permitting “curly” where there's some evidence that curly will be used consistently throughout the work. In fact, that seems like a useful formalization of a principle I expect is already in use in some places, but not formally documented or endorsed. Which IMO is one of the best ways to develop policies on a wiki. -Pete (talk) 22:29, 6 July 2019 (UTC)
To make my position clear, I am very much in favor of allowing curly quotes on a case-by-case basis as long as the editor intends to make a good-faith effort to see they're used consistently (the guideline could be, "please don't add curly quotes to a work that's already partly straight quotes unless you're about to change the whole thing.") Though I worry about how to get it done, I think the problems are solvable, so yeah, in favor. Levana Taylor (talk) 03:20, 7 July 2019 (UTC)
@EncycloPetey: I wasn't trying to hold a vote, I was trying to see if maybe there was consensus for a change in the style guide, in which case, there would be no need for a vote. It is clear from your reply, however, that you are still against the idea, and maybe there are other silent voices that are as well. Also, please let me know whose opinion I have misinterpreted, and I will be happy to revise my statement above. Kaldari (talk) 14:43, 8 July 2019 (UTC)
And by "consensus", I meant actual consensus, not wiki-speak consensus. Kaldari (talk) 14:47, 8 July 2019 (UTC)

I have been following the discussion and thinking over the pros and cons and finally came to this opinion: The main disadvantage of allowing curly quotes is a danger of different attitudes of two or more people transcribing one work. For this reason I would explicitely allow curly quotes only if the contributor is able to ensure consistency of their usage throughout the whole work, typically when the contributor transcribes the whole work by himself/herself. When more people cooperate on transcription of a work, straight quotes should be recommended, unless they are all able to make an agreement about curly quotes (of course such agreement is practically impossible with such large works as Encyclopaedia Britannica). --Jan Kameníček (talk) 18:53, 6 July 2019 (UTC)

That's a nice thought, but even with the best will in the world, people start projects and don't finish them. The better thing is for the person who starts a project to document all their style choices on the talk page -- the note at the top of the index indicating that style guidelines exist is a great invention. Quote-style is no different from many other choices in that respect and can be handled the same way. If we shift to curly quotes and they become normal, then there will be no problem with expecting people who sign on late to a future project to use them. It's only the possibility of transitioning to curly quotes in projects that are already begun now that presents difficulties. Levana Taylor (talk) 21:03, 6 July 2019 (UTC)
A policy doesn't have to be perfect to be useful, sometimes "good enough" is good enough. I believe most Wikisource users would answer in good faith if asked, "do you intend to complete this project?" For myself, I think I'd answer "yes" for about half, "no" for about half. If a few projects end up with some inconsistencies because somebody intended to finish it but then got distracted or busy elsewhere, is that too high a price to pay if there are benefits elsewhere? -Pete (talk) 22:33, 6 July 2019 (UTC)
Both sides of this argument are starting to fall into the desperate position of trying to shore up numbers of supporters by appealing to the everybody who is reading this and not making their position clear must by inference be on my side of the argument. So for the sake of this alone I must delurk and declare that I am a closet supporter of the use of curly quotes for reasons I shall not go into here as they have already been adequately covered by others.
On the matter of automated tool use favouring straight quotes I have some sympathy. Creative laziness is always admirable but at heart it is just that: laziness. If some piece of scripted magic could perform reliable verification then why is everybody here at all? Proofreading still has an aspect of bespoke craft and we should take pride in our input.
As for perceived difficulty of entry of characters, aside from resort to UNICODE, there are the various pickers available both mediawiki supported and local. Nobody appears to have yet noted that native HTML such as the <q></q> construct works well under mediawiki, and all reputable browsers now handle the so-called HTML entity-forms: &ldquo; → “; &rdquo; → ” &lsquo; → ‘; &rsquo; → ’ Learn them; they are your friends! 22:56, 6 July 2019 (UTC)
Suggestion for implementation of quotes: there should be a gadget that finds all straight quotes on a page and converts them to curly while highlighting them so the editor can check the result for correctness (because it wouldn't be perfect). This would go a long way toward easing worries about inconsistency. Not only would it allow quicker, better conversion of works that have been begun using straight quotes, but if someone happens to notice stray straight quotes in a work that's mostly curly, they can rapidly find them all. Levana Taylor (talk) 03:20, 7 July 2019 (UTC)
Pictogram voting comment.svg Comment I agree with the spirit of @Levana Taylor's suggestion but point out the occasional real-world case of quotations crossing pages — commencing on one page and terminating on a later one — would completely reverse the sense of correct quotation mark appearance. Which makes implementation of such a gadget tortuously impractical — as the analysis must take place at the work/chapter level to enable sensible decision for the gadget to act on the component page level. Only the {{nop}}-inserter gadget attempts this at present and for a vastly simpler case. 03:43, 7 July 2019 (UTC)
I don't see the problem. Ending quotes are at the end of words, lines and paragraphs, and starting quotes are at the start of words, lines and paragraphs. Quotes never cross paragraphs in normal English style, so any tool should restart at a new paragraph. On proofed text, it's possible the tool will put the wrong quotes on the first paragraph, but it won't be a problem for the whole page.--Prosfilaes (talk) 07:02, 7 July 2019 (UTC)

Arbitrary break (curly quotes)[edit]

I have… questions… 🤔

  • Are we proposing to allow straight vs. non-straight quote mark style to be at the whim of the first contributor? Of any contributor that has a good-faith intent to update all previously proofread pages? Only when based on some set of criteria related to the work? What, if any, are the constraints on the choice?
  • Is the proposal for the benefit of proofreaders with a preference, or for our readers? That is, is our goal to achieve the best presentation for our readers, or to allow our proofreaders some flexibility or to express their own preference? What are we trying to achieve by making a change in this area?
  • At what level do we care about consistency? The work? The chapter? Individual entries in the DNB and similar? Across works within a series? How would we achieve such consistency in practice? How would we resolve conflicts in preference?
  • What kind of curly quotes (there are on the order of 30 of them) would be allowed, and how would the style be decided? Would the “Anglophone” style be allowed or preferred for a work by a « Francophone » or „Germanic“ author? How about for reproducing an official text of some kind (English translation of a law, say) where the originating country specifies (sometimes by law) a specific quote style?
  • How would we handle the issues currently dealt with by {{" '}}, {{' "}}, et al (there are 5 of them just for straight quotes; each extra style of quote would generate at least 5 more)? How do we detect and correct instances where accent marks are (accidentally) substituted for single quote marks? How about the inevitable Windows CP1252 character set issues?

I don't as yet have a firm opinion on the issue of curly quotes except that they do create a lot of complexity and that that complexity must be addressed if we are to adopt them. I do hold the opinion that good typography aids readability; that good typography creates visually appealing works, and that visual appeal is a desirable trait; that our goal should be the benefit of our readers over our own contributors; and that our readers are a diverse group with many different needs. I am also by inclination prone to prefer more diplomatic reproduction of works (I've driven certain community members to distraction by insisting on using {{lgst}})—which inclines me to want to reproduce a work's quotation style, and against any style that differs from the one use in the work (including substituting straight for curly)—but experience has taught me that there are good reasons to moderate that impulse (see, Billinghurst, I do listen and learn!).

And, ultimately my main concern is maintainability and manageability over the totality of the project, over a decade or two, and in the face of practical realities like the occasional conflict between contributors, the perennial slow changing of the guard (who now remembers why we made every decision shaping the project?), and the necessity of either automating or having the manpower for certain kinds of necessary cleanup or guidance for new contributors.

I like fancy quotes (and other typographic affordances), but they sound like they'd be really hard to do right. --Xover (talk) 07:18, 7 July 2019 (UTC)

Curly quotes should match the scanned text. That's simple.
We should deal with {{" '}} with fire, and then dump the ashes into a heart of a live volcano. I mean, if that's your bag, then whatever, but it seems weird about arguing for curly quotes against claims that the typography doesn't matter and that consistency is important, but have to deal with an idiosyncratic set of templates that surely have no consistency in use and tackle an issue of micro-typography that can and should be handled by modern text layout systems in web browsers; TrueType fonts have supported kerning pairs of characters for 25 years.
I would hope that modern systems won't dump CP1252 characters into the browser. We should have a bot checking the pages for inappropriate Unicode characters (Private Use, unmapped, etc.) and include 0080-009F in there.--Prosfilaes (talk) 07:56, 7 July 2019 (UTC)
I have not observed that the kerning issues with adjacent quote marks (or with "rn" and "m", for that matter) have been rendered moot by modern text layout systems. I have no particular affinity for those templates, but I do care about the issue they are attempting to solve. I also do not think making templates to deal with this issue that are consistent (what are the problems with the existing ones?) should be impossible. --Xover (talk) 08:06, 7 July 2019 (UTC)
Modern text layout systems are well-capable of dealing with kerning. If they don't, well, that's still stepping into their territory. There's no way of making such templates consistently used unless we make a big fuss about them, which I strongly object to. I haven't seen them in any thing I've used text I've worked on.--Prosfilaes (talk) 08:36, 7 July 2019 (UTC)
That they have advanced support for kerning (which they do, even on Linux) does not mean they can intuit the need for such automatically: we need to make use of such facilities for anything to happen. --Xover (talk) 08:52, 7 July 2019 (UTC)
In a TrueType font, there is a table listing pairs of characters and the space that needs to be added or removed between them. If "' needs extra space, then that table should list the amount of extra space it needs and the typesetting program should adjust the distance between the two glyphs appropriately. See w:Kerning.--Prosfilaes (talk) 12:31, 7 July 2019 (UTC)
Yes, that is indeed how the TrueType specification handles it; and OpenType has even more advanced features for this. However, so far as I know, no web browser on any operating system does this automatically, and the CSS features for explicitly enabling it are only partly supported (and would require some sort of markup on our side in any case). And even with that support it would require an OpenType font which has the appropriate kerning setting for these pairs, and that was available for us to use, which mythical beast may exist but I couldn't name one off the top of my head. I agree that it would be very nice if we didn't have to worry about this, but, again so far as I know, that is not actually the world we live in. If you know otherwise I'd be happy to get rid of those templates even if we only use straight quotes: they're nobody's idea of a perfect solution, they're just the best we've got available.--Xover (talk) 15:22, 7 July 2019 (UTC)
I have never used these templates; "'this'" or “‘this’” have always been completely adequate. If/when browser support for kerning becomes more common, then the appearance will be improved slightly, but in the meantime there is no need for manually padding the punctuation imho. —Beleg Tâl (talk) 20:11, 7 July 2019 (UTC)
I'd say pretty much this is the definition of a problem we don't have to deal with. We send "' down the line, and the other side renders it. If that rendering of a common pair of characters is unsatisfactory, the spirit of HTML and text transcription is that we don't know their fonts, their system. If systems don't do this automatically, and fonts don't set kerning for these pairs, then obviously it's not considered a big problem.--Prosfilaes (talk) 21:42, 7 July 2019 (UTC)
That's a fair stance (both of you). I don't agree with it—it goes to readability so a similar argument applies to this as to using typographers quote marks (or distinguishing between plain, en-, or em-dashes)—but it is absolutely an issue it is reasonable to consider falling within the limits of "good enough". Thus the question, above, of whether what we are trying to achieve in this discussion is flexibility for our contributors or a better reading experience for our readers. What the goal is affects the calculous of how much effort to put into stuff like getting typography and layout correct vs. getting it "good enough" (wherever you draw that line in general) and letting the users' browsers deal with it. --Xover (talk) 04:31, 8 July 2019 (UTC)
I think the difference is here that users' browsers can't add curly quotes properly; it is up to human intelligence to add them. On the other hand, we can't add space properly, given that we don't know what fonts are being used. In the long run, properly recording the characters that are there will help all usages of the text, where manually kerning characters will help only certain users, and make usages that don't reflect current web browsers more complex.--Prosfilaes (talk) 11:24, 8 July 2019 (UTC)
I use the {{" '}} group in my projects after seeing them in use elsewhere since it seems like a neat solution to the problem, and the templates can easily be made inoperative whenever browsers do get round to displaying them better. Given that I regularly have to add manual padding when typesetting documents in InDesign using professional typefaces I am somewhat sceptical about how effectively those TrueType and OpenType specifications are being used by fonts at the moment. As Xover said above fonts using the full scope of these settings properly are a bit of a mythical beast.
For the record, in Arial on Windows 10 and the current version of Chrome I can't distinguish "' from '" at all (or for that matter '''). In curly quotes, though, it seems much easier to distinguish “‘ and ‘“, so it's possible that the templates are simply unneeded in that case. —Nizolan (talk) 15:15, 8 July 2019 (UTC)
Back to topic of curly quotes, I checked the French, Italian, and German Wikisources and they all seem to use curly quotes by default. (It seems Spanish has their own style of quotation marks and doesn't use apostrophes.) Kaldari (talk) 14:35, 9 July 2019 (UTC)

Classed tables...[edit]

I recently created {{table class}} and {{table class/import}} and an associated stylesheet....

However, in order to avoid name conflicts, I'd like to know if there are formatting classes that are defined elsewhere, ( Most likely in Mediawiki namespace), so that I can make a note of those names and NOT use them when implementing future table-class styles..

The reason for needing a seperate {{table class/import}} is because it's not currently possible to have template styles directly within a table owing to mediawiki limitations.

I used the two templates here -

ShakespeareFan00 (talk) 00:43, 4 July 2019 (UTC)

Why not just use class= in the table itself? —Beleg Tâl (talk) 03:02, 4 July 2019 (UTC)
The {{table class/import}} template is needed so the tweaked styles are "visible" to subsequent class calls (And it could be genericised further), but I am prepared to consider that {{tc}} may not be needed after all, other than as a 'placeholder' for the Stylesheet that sits below it.
The intent was that additional short codes can be implemented as CSS classes in the stylesheet, rather than needing to add them as part of the massive switch statment in {{ts}}. Although {tl|ts}} could in term be converted to use classes, (the separation of the short codes from the template logic would be a good thing.)

My other reason for having a {{tc}} is as a shorthand, and so that {{table class/doc}} can eventually document the new styles implemented. If there's a better soloution, I am open-minded. ShakespeareFan00 (talk) 08:51, 4 July 2019 (UTC)

In my opinion, if we are creating a central library of class styles, we should put them in a normal place like MediaWiki:Gadget-Site.css or something, and document them there. If we are creating work-specific class styles, we should put them in a work-specific template for each work. I don't think a template is the right location for a central library. Maybe you can set up {{tc/i}} similar to {{authority/link}} as a base structure upon which work-specific templates can be built? —Beleg Tâl (talk) 12:31, 4 July 2019 (UTC)
Speaking of which, I think MediaWiki:Gadget-Site.css is the answer to your original question, namely where are most of the prefab formatting classes defined. —Beleg Tâl (talk) 12:32, 4 July 2019 (UTC)
And others..
In respect of generalised classes:
  • The more that can be put in a core stylesheet the better. PROVIDED it can still be cleanly updated, one of the issues with using numerous {{ts}} calls is that when something changes, a lot of calls have to be updated or the massive switch statment in {{table style/parse}} modified when a new code is desired. Using TC instead means, the call and the stylesheet change, but the template logic doesn't need to be.
  • What about documentation ?

ShakespeareFan00 (talk) 13:40, 4 July 2019 (UTC)

(Aside1) - in MediaWiki:Gadget-enws-tweaks.css ClearFix seems to be defined twice? Unless I am not seeing a minor difference? ShakespeareFan00 (talk) 13:40, 4 July 2019 (UTC)
(Aside2) - Is there are tracking category for which templates are using Templatestyles?
(Aside3) - I can adjust {{tc/i}}, I can genericise it, and add a tracking category? Would there be a better name to make it fully generic, so it can be used on ANY element as opposed to just tables?

ShakespeareFan00 (talk) 13:40, 4 July 2019 (UTC)

If the classes are defined centrally in MediaWiki namespace, no importer template is needed. If the classes are defined per work, it occurs to me that the TemplateStyles tag itself is fully generic and can be used on any element. In either case, neither {{table class}} nor {{table class/import}} is actually needed. As for documentation, maybe Help:Table is a good place to start? —Beleg Tâl (talk) 15:00, 4 July 2019 (UTC)
If you want to move the CSS classes I defined into an appropriate mediawiki location feel free, Provided the documentation is also reclocated. :) ShakespeareFan00 (talk) 16:04, 4 July 2019 (UTC)

Sidenotes... The cause of the problem?[edit]

In page namespace I sometimes have overlapping sidenotes, a known long term issue.

This seems to be due to the way the sidenotes are implemented here

The culprit being the "position: absolute." , and the sidenotes being 'span' based. An attempt was made to provide a badly concived fix here, Template:Right sidenote/sandbox.css but it was never fully implemented as I still don't think it would work properly..

Can some experienced review and come up with a solution?

ShakespeareFan00 (talk) 16:13, 4 July 2019 (UTC)

The 'fix' only partially works here -, ignore the issue with the Drop initial, as that's an insoluble problem at the moment. ShakespeareFan00 (talk) 17:18, 4 July 2019 (UTC)
I got rid of the drop initial; there is no drop initial in the scan. —Beleg Tâl (talk) 20:12, 4 July 2019 (UTC)
Another side issue seems to be that it isn't possible to get a consistent view of how something MIGHT be rendered, as the way it's currently implemented means Page:'s, Mainspace pages, and User space tests will all give different renderings due to CSS class interactions, as will previewing content when what SHOULD nominally be the same rendering isn't because of various class interactions. It would be nice (and I have said this REPEATEDLY) to have consistency. It seems this is too much to expect from a volunteer project, given the time people have available, and it's perhaps time to ask the WMF to hire some coders to find a long-term solution to issues like this. ShakespeareFan00 (talk) 18:52, 4 July 2019 (UTC)
There are downsides to all approaches.
  • Positioning the sidenote absolutely allows the note to align with the margin. However, absolutely placed elements do not interact with each other at all and therefore can overlap.
  • Positioning the sidenote relatively requires the creation of a "pretend" margin to place the sidenote in. This pretend margin is actually a block of text that is positioned where we would expect the margin to be. However, if the actual margins are too large or too small, the sidenote will not align properly (and might overflow the margin). Also it will interact with all other relatively positioned elements (such as dropinitials) which can require a good handle on CSS to be able to resolve.
  • Experimenting with rendering is only half the battle. Even if it is the same in all namespaces, what about other layouts? other themes? how about mobile? how about epubs and pdfs? We ideally want to be able to say "this is a sidenote" and then let the system place it in a location that is appropriate for the situation.
To sum up: robust sidenotes that work in all situations are a bit more complicated than CSS can really handle, and a bit of overlap here and there is probably the best compromise achievable without having a professional design something (maybe a new mediawiki extension?) —Beleg Tâl (talk) 20:12, 4 July 2019 (UTC)
Page:The_Laws_of_the_Stannaries_of_Cornwall.djvu/34 was something that would work consistently...but it's overkill..

ShakespeareFan00 (talk) 22:32, 4 July 2019 (UTC)

Wikisource:News (en): July 2019 Edition[edit]

Which Benjamin Bell?[edit]

Index:A Treatise on the Diseases of the Bones.djvu

This list's a Benjamain Bell as the authour, but the dates for the grandfather or grandson of that name ( both notable in the surgical field) don't fit in with the nominal publication date given. Is there a third Benjamin I've not found information on, or is this a new edition of an earlier published work (possibly with updates)? ShakespeareFan00 (talk) 08:13, 5 July 2019 (UTC)

It is dedicated to w:William Adam of Blair Adam styled Lord Chief Commissioner of the Jury Court, which post he held 1815–1839. The foreword is dated 1st October 1828. Which means it is unlikely to be the grandfather or a reprinting of one of his older works.
The grandson lived 1810–1883 according to the ODNB, was also a surgeon and wrote a biography of his grandfather. HathiTrust has the author as "fl. 1823-1828" on no obvious authority. If 1810 is correct, the grandson would have published this when 18, which seems improbable on its own. The foreword also refers to various professors etc. as peers, or at least without the deference one would expect from a 18 year old, no matter who his grandfather was. The author also claims in the foreword that they have been studying "osseus tissue" for several years. I therefore think we can effectively exclude the grandson too.
It seems unlikely that two brothers would both be named "Benjamin Bell", so it's unlikely to be an elder brother of the grandson. But given the subject matter and so forth, it does seem fairly likely to be a decendant of the grandfather. The most likely identity then is as a son of the grandfather, and father or uncle to the grandson. My call would be to label this as a new author that flourished ca. 1828, and is almost certainly a son of the grandfather, and most likely the father or uncle of the grandson.
Note that there is no relation to Charles Bell (of Bell's Palsy fame). These are separate families from the Edinburgh region who both produced famous surgeons and medical writers, and who clashed over appointments and the internal politics of the Royal Society of Edinburgh and the Edinburgh College of Surgeons. But Charles Bell had a practice in London, and the name Benjamin is inherited through several generations of the other family (the grandfather, the grandson, the great-grandson, and there's even a great-great-grandson called Benjamin Bell). --Xover (talk) 11:13, 5 July 2019 (UTC)

The author is credited as a "Fellow of the Royal College of Surgeons of Edinburgh, and London", so certainly not the 18 year old. three people called "Benjamin Bell" are listed at [20], but there is some ambiguity in the writing [my comments in square brackets; let's call the original Benjamin I].

His [Benjamin I] descendants were also to achieve distinction in surgery. His elder son George Bell (1777 - 1832) and his [whose?] son Benjamin Bell were both Fellows of the College and surgeons in Edinburgh. His [whose?] younger son Joseph was also a Fellow of the College and his [whose] son Benjamin Bell was President of the College form [sic] 1863 - 1865. His son, Joseph Bell, great-grandson of that first Benjamin Bell, also became President of the College and famously the model for the character of Sherlock Holmes.

This source lists Benjamin I as having three sons: George (1777-1832), Robert (1782-1861), William (1783-1849), all FRSE, but no Joseph and no Benjamin.

So, possibly;

  • Benjamin (1749–1806)
    • George (1777 - 1832)
      • Benjamin II
        • Joseph
        • Benjamin III
          • Joseph II (1837-1911)

But this would make Joseph II the great-great grandson. It seems the answer may lie in this paywalled paper [21]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 6 July 2019 (UTC)

The Christian's Secret of a Happy Life[edit]

Well the source given in the textinfo doesn't actually match the text given in terms of the first few pages, So where did it come from?

A properly sourced scan would be better.ShakespeareFan00 (talk) 11:12, 5 July 2019 (UTC)

If you read further on the talk page, or the metadata in the text itself, you can see that it was proofread against a physical copy of the 1952 edition. Some of the content (the foreword and backplate for example) are probably copyvio. I would support replacing it with the 1916 edition that they linked to. —Beleg Tâl (talk) 12:07, 5 July 2019 (UTC)
Which metadata? The one at because I am only seeing the IP's comments on the talk page here. Listed at WS:CV until someone can give an unambiguous answer. ShakespeareFan00 (talk) 17:28, 5 July 2019 (UTC)
I assume BT is talking about the frontmatter in the text itself, which says "COPYRIGHT MCMLII BY FLEMING H. REVELL COMPANY", i.e. it's © 1952 (this frontmatter including the foreword is not in the IA scan, which is from 1916). What the IP seems to have done is copied the OCR text from IA of the 1916 edition, and then "proofread" it from a copy they have of the 1952 edition. —Nizolan (talk) 18:01, 5 July 2019 (UTC)
Yes, that is the metadata that I was referring to —Beleg Tâl (talk) 22:12, 5 July 2019 (UTC)
And there are better scans than the Google ones at Internet Archive. ShakespeareFan00 (talk) 17:38, 5 July 2019 (UTC)
I just had a look on the Stanford database and the copyright was renewed so this does appear to be a copyvio. —Nizolan (talk) 15:14, 5 July 2019 (UTC)

Removing non-content pages from a scan?[edit]

A user recently requested assistance with a work that ended up necessitating recreating the DjVu file from the original .jp2 files. The scan was a Wellcombe-sponsored IA scan, so it was high quality and with much care and attention to detail. In particular, the work has many plates, and each plate is protected by a rice-paper cover page, which the scanners lovingly captured: 17, 18.

Such pages are not part of the page number sequence, but make it hard to create the pagelist; and they contain no text to proofread or illustration to reproduce.

I ended up including them in the generated DjVu to be conservative (and to reduce complexity and finish faster, since someone else was waiting for the result), but the more I think about it the less I like it. So… do we have any existing guidance on this? What are others' practice when this comes up (for those that do create DjVus from individual images)? Or simply have an opinion?

I think, absent guidance to the contrary, next time I would opt to remove such pages. --Xover (talk) 07:42, 7 July 2019 (UTC)

yeah, i would be less concerned about gray "without text" pages, which can be skipped in transclusion, than the works missing images. i agree, it is a drag, creating the index though. and jp2 is a problem; we need some support. images are a key differentiator in our system, and the fact most scans do it clumsily means we will have some cleanup to do. Slowking4Rama's revenge 20:27, 7 July 2019 (UTC)

Tech News: 2019-28[edit]

20:13, 8 July 2019 (UTC)

Proofread bar[edit]

Is there any template that can produce a colored bar based on the proofreading data of indices?! I want to use it inline. --Yousef (talk) 13:30, 9 July 2019 (UTC)

Not automatically as far as I know but there is {{PageStatus}}, used e.g. at Wikisource:WikiProject Chinese, which however needs to be updated manually. —Nizolan (talk) 14:22, 9 July 2019 (UTC)
yeah, for DNB it was done manually in a table Wikisource:WikiProject_DNB/Progress, but for 10th anniversary, there were charts generated from tables, Wikisource:Tenth Anniversary Contest/Summary. - Slowking4Rama's revenge 00:26, 10 July 2019 (UTC)

Linterror hunting...[edit]

Does anyone here have a way of producing a report that lists an Index and all the Page:s in it that have a specified Linter concern?ShakespeareFan00 (talk)

I've been doing A LOT of cleanup manually, and would like to focus efforts on improving entire works per session rather than random improvements on a page per page basis?

Thanks in advance...

Oh and I am about to have a 'burnout' so may need to take some time out soon...

ShakespeareFan00 (talk) 20:51, 12 July 2019 (UTC)

They already answered your question:Wikisource:Scriptorium/Help#Enough_is_enough:_WHERE_is_the_mistake?_i.e_where_the's_flipped_formatting?.— Mpaa (talk) 22:16, 12 July 2019 (UTC)

Message Box module..[edit]

Here Template:From_Commons is calling the Message box module, but Lint hint generated a warning about an interupted SPAN (i.e A paired "Missing end tag" and "Stripped tag" warning.) . My guess it that the Message Box module is thinking it's going to get a SPAN based text parameter, whereas here it's getting a Block based list. Can someone with the approriate Lua skills examine the module and indicate if this is indeed what has caused the concern here?

ShakespeareFan00 (talk) 13:27, 13 July 2019 (UTC)

Also Help:Beginner's guide to Index: files ShakespeareFan00 (talk) 13:32, 13 July 2019 (UTC)[edit]

Does anyone have a tool that will fetch the work (or all the images individually) from pages like:

please? (I've fetched that one manually, but that won't be feasible for larger works.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:35, 13 July 2019 (UTC)

It seems that the books in this online collection are stored in the form of sets of jpg images displayed using the BookReader script. The source code for BookReader is here. I have been hunting through Cornell's Digital Collections site and it really seems that they don't make their books available in any form except through BookReader, although you can purchase a POD copy(!) No doubt your best bet would be to e-mail them. Levana Taylor (talk) 21:14, 13 July 2019 (UTC)
They are stored as jpeg here:, etc. It should be possible to write a script to loop over and download the pages... MarkLSteadman (talk) 22:28, 13 July 2019 (UTC)

OCR gadget issue?[edit]

Is the OCR gadget failing for anyone else, or just me? It's not been working for ~24 hours - I've tried on different source documents more than once. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 13 July 2019 (UTC)

Seems it works OK to me. --Jan Kameníček (talk) 19:02, 13 July 2019 (UTC)
it’s working for me. there is also the google OCR gadget which sometime gives better results. (in beta at bottom) - Slowking4Rama's revenge 00:09, 14 July 2019 (UTC)
Thank you, both. It's still not working for me; the editing area just goes grey. This is quite recent, as it worked previously. I've added the Google OCR gadget, and while that works, it adds words in the wrong location; see, for example, the initial edit on Page:Notes of a journey across the Isthmus of Krà.pdf/8. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 14 July 2019 (UTC)
ok, for that work, i have the same problem. i suspect it is a problem with the text layer, and the open OCR software. maybe a ticket, but support is minimal. and yeah the OCR slices phrases. i.e. [27] Slowking4Rama's revenge 12:20, 15 July 2019 (UTC)
"open OCR software"? Are we at cross purposes? I gave an example of an issue caused by the Google OCR gadget. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 15 July 2019 (UTC)
you said the OCR did not work - that is the open version. you said you added the google OCR gadget. people have been know to cut paste their OCR from a google doc as well. Slowking4Rama's revenge 02:26, 16 July 2019 (UTC)

The Lint error stuff[edit]

If this is a tangible issue could we have it stated as such in policy/guidelines and advice written up on how to avoid it? I don't want to waste people's time by having them follow me around correcting the errors, but beyond some basic stuff like avoiding nesting a div in a span I don't have much of a clue about the best practices, and I imagine many other editors won't either. In some cases the fixes seem to be contradictory to the advice that is currently available: for example in diff I used that workaround specifically because the documentation at {{gap}} states that it should not be used to format indents. —Nizolan (talk) 12:18, 14 July 2019 (UTC)

It helps if the person fixing can understand your code. (bright red embarassed face) ShakespeareFan00 (talk) 14:26, 14 July 2019 (UTC)
@ShakespeareFan00: Basically in that specific case I had to add {{divify}} because otherwise it would add <p></p> tags and unwanted space, and divify had to be nested inside the margin template to work. (I know it's overcomplicated, iirc in later projects I switched to a {{block center|...|width=95%}} hack to get an indented rh.) But anyway, I just don't want to create unnecessary work for you + others, so at least a list of common mistakes might be useful. —Nizolan (talk) 14:40, 14 July 2019 (UTC)
We say not to use {{gap}} for indents because we don't preserve paragraph indents. In this case {{rh|{{smaller|VOL. II.}}|{{smaller|D D}}}} would have been more than sufficient. Since it's not a paragraph indent (and since it's not being transcluded anyway), using {{gap}} would be acceptable here if the exact positioning of the mark is important to you. —Beleg Tâl (talk) 15:46, 14 July 2019 (UTC)
@Beleg Tâl: That's fine for this specific case, but it doesn't clear up the need for guidance on general issues, and it's also different from the documentation at {{gap}} (which I've now changed to reflect what seems to be common usage). The latter says that all usage to "produce a formatting preference" is deprecated, and specifically gives the comparable example of using it in {{right}}. It seems that there are multiple conflicting expectations here, on top of the Lint guidelines which are not written down anywhere at WS afaict. —Nizolan (talk) 16:58, 14 July 2019 (UTC)
While I'm complaining about unwritten expectations, I also want to note that this isn't the only place where people seem to have different ideas of what house style constitutes at the formatting level. So far I have seen signature marks being added and removed by different editors, claiming to follow guideline in both cases. I've seen the same thing with the nesting of {{lang}} and italics. Unless I am missing somewhere where these things are laid out explicitly, it might be a good idea with these small nuts-and-bolts problems to either work out some general guidance which people can stick to, or, if they are a matter of editor preference, to say so explicitly. —Nizolan (talk) 17:03, 14 July 2019 (UTC)
it’s great you want to document norms, i would suggest expanding Help:Beginner's guide to Wikisource with maybe some consensus building on discussion there. and think about a welcome wagon / teahouse (this is a renowned head down place, where the adversive admins only show up once in a while) Slowking4Rama's revenge 13:17, 15 July 2019 (UTC)
IMHO there is no best practice, just the awareness that templates cannot be arbitrarily combined to obtain the desired effect as they might produce incorrect HTML. So, if someone gets an error, they should go and look at the template implementation and the HTML error and figure out a different solution. "Keep it simple" is a general valid rule, as well as keeping a right balance in trying to faithfully replicate the original. — Mpaa (talk) 19:57, 15 July 2019 (UTC)

Tech News: 2019-29[edit]

15:30, 15 July 2019 (UTC)

Palestine Order-in-Council[edit]

I'm asking if someone that has access to the Hebrew Wikisource, can do a check of this against the original there, as in the preamble notes there is a sentence that to me looks like it has letter missing in the translation here? ShakespeareFan00 (talk) 20:39, 17 July 2019 (UTC)

I can access the Hebrew Wikisource, but I can't read the Hebrew. Our text is checked against this version though, not against the Hebrew. Here is the requested passage:

הואיל ולמען תת תוקף להוראות סעיף 22 מספר הברית של חבר הלאומים הסכימו מעצמות ההסכמה הראשיות למסור לידי הממונה, שייבחר ע״י אותן מעצמות, את הנהלת ארץ ישראל שהייתה שייכת קודם לכן לממלכת תורכיה, בתוך אותם הגבולות אשר ייקבעו על ידן;

והואיל ומעצמות ההסכמה הראשיות הסכימו גם לכך שהממונה יהיה אחראי להגשמת ההצהרה שניתנה מלכתכילה ביום 2 בנובמבר, 1917 ע״י ממשלת הוד מלכותו ונתקבלה ע״י המעצמות הנ״ל, לטובת ייסוד בית לאומי בארץ ישראל לעם היהודי, בתנאי ברור שלא ייעשה כל דבר העלול לפגוע בזכויות האזרחיות והדתיות של העדות שאינן יהודיות, הקיימות בארץ ישראל, או בזכויותיהם ובמעמדם המדיני של היהודים בכל ארץ אחרת;

והואיל ומעצמות ההסכמה הראשיות בחרו בהוד מלכותו להיות הממונה על ארץ ישראל;

והואיל ויש להוד מלכותו סכמות וכח שיפוט בארץ ישראל בתוקף חוזה, שעבוד, מתנה, מנהג, הסכמה־שבשתיקה ובתוקף אמצעים חוקיים אחרים;

לפיכך נאות הוד מלכותו לצוות, בתוקף הסמכויות המסורות לו לתכלית זו בחוק השיפוט בארצות נכר, 1890, או בכל חוק אחר, ובעצת מועצתו הפרטית, ובזה מצווים לאמור:–

Beleg Tâl (talk) 01:20, 18 July 2019 (UTC)
Thanks, I don't read Hebrew either , but I'll see what Google Translate makes of it.
The sentence I actually had concerns is in small text below the above (noting an ammendment), and as of my enquiry read as follows on English Wikisource page:- "In Accordance with Articles 14 and 15 of the Law and Administration Ordinance every function formerly vested in the King of Britain or in the High Commissioner shall now be vested in the Cabinet of Israel and the term "Palestine (E"I)", whenever appearing in any law, shall no be read as "Israel".
The "no" should I think be read as "now"? The rest of the preamble matches up. I didn't want to change it without someone checking.ShakespeareFan00 (talk) 08:11, 18 July 2019 (UTC)
That paragraph does not appear in the source edition so it should be removed entirely. —Beleg Tâl (talk) 12:59, 18 July 2019 (UTC)

Isthmus of Krà[edit]

I've nearly completed work on Notes of a journey across the Isthmus of Krà. The original does not have a table of contents; would it be acceptable to add one, for the convenience of readers? If so, how should the fact that it is a new addition be indicated? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:52, 18 July 2019 (UTC)

there should be more help on this, but see also Template:Auxiliary Table of Contents -- Slowking4Rama's revenge 10:37, 18 July 2019 (UTC)
@Slowking4: Perfect, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 18 July 2019 (UTC)