For other curious HNers, what differentiates [0] them from Project Gutenberg [1] is the improved typography/styling and the full usage of modern reader techniques. Think of it like, etext != ebook.
So why don’t they contribute these things back to Project Gutenberg? Particularly the typography ones like curly quotes and proper dashes, as those are almost always corrections where the overly-ASCII Gutenberg source doesn’t match the original.
Like PG, our editions are blends of other editions, along with our own updates. Often our edition winds up looking nothing like the PG edition, for example when we combine volumes, extract footnotes into endnotes, remove pagination, and so on.
So submitting back to PG would be more like replacing a PG edition, instead of updating it; and I doubt the original PG submitter would like it if their hard work was simply replaced by someone else who thought their version was an improvement.
Our volunteers do sometimes submit typos they find back to PG. We don't require that, so some producers do, and others don't.
Yeah, I was just looking through A Christmas Carol and observed a handful of editorial changes in the commits <https://github.com/standardebooks/charles-dickens_a-christma...> (bran-new → brand-new, frouzy → frowzy, and “Lowercase some gratuitously uppercased words”). Frouzy → frowzy I’m mildly in favour of. Ditching bran-new definitely loses character (he omitted the d on purpose!). One or two of the lowercased words were mildly strange capitalised (e.g. Idol was inconsistent with the previous paragraph); but the lowercasing of many introduces broad stylistic inconsistency, and direct local inconsistency sometimes; and most of the capitalisations were not gratuitous. In fact, more than a few were clearly to be pronounced, as a form of emphasis (e.g. Poor, One, Us); and some were distinctly proper nouns in the context, the removal of which increases the parse difficulty (e.g. One¹, /(Cold )?(Roast|Boiled)/); and some reflect customs still common or even preferred in their domains (e.g. Act, Angelic, Apostles, Star). I just reckon that commit should be reverted, because from my perspective it’s mostly actively bad, and the rest subjective. I’m curious what your reaction is to my opinion here.
But yes, I see that you’re practising some editorial oversight and not aiming to faithfully represent the original in all regards, which I gather is more generally Project Gutenberg’s goal; and this would obviously contraindicate upstreaming.
On the other hand, when it comes to more stylistic matters, I tend to wish Project Gutenberg had more consistency. There’s too much gratuitous variation in presentation and ridiculous 256-colour backgrounds. It’s often too obvious much of it is the work of a group of individuals rather than a coherent effort.
I’m curious about the footnote-to-endnote thing, because I’m not sure how the various formats in question handle them all, but in print endnotes are almost always just awful. If anything, I’d be expecting to replace endnotes with footnotes. (Me, I’m partial to sidenotes.)
—⁂—
¹ Hickory dickory dock, three mice ran up the clock; the clock struck one, and has been charged with assault and battery.
Yeah, any edition of a book that's "updating" modern English loses me, including messing with capitalization. Not interested. I love the formatting on Standard Ebooks, but they're no use to me if they're "updating" language, aside from things like repairing typesetting and formatting lost or mangled in PG editions.
Agree on notes in print, side notes (on very-wide editions) are best, then foot, then end of chapter endnotes. Full end-of-work endnotes are awful. Maybe they're better in ebooks, than footnotes, though? E-readers' poor UX for not-even-that-advanced features of books is part of why I barely use them, and practically never for any work that'd have notes of any sort.
As someone who regularly compares different scans of old books, I counter: for centuries it’s already been common practice for publishers to update spellings, recapitalize, and even make more drastic changes. You just never noticed because print books don’t have a public commit log.
In the case of Standard Ebooks, “sound‐alike” changes are allowed (so spelling and capitalization changes are allowed when they make sense). Censorship, and even innocuous grammatical changes, are not. Despite generally appreciating old works in their own context, I find the tradeoff in readability for such a widespread practice to be worth it given how minor SE’s alterations are.
Sometimes capitalisation matters are close to purely stylistic, but other times they really are part of the content, guiding pronunciation or emphasis, so that lowercasing them harms the work. What is your opinion of my assessment in the above comment of some of the specific changes in <https://github.com/standardebooks/charles-dickens_a-christma...>?
I haven’t looked into your example, but certainly it can be true that lowercasing can be harmful. It goes without saying, I think, that the SE policy is only to lowercase words when doing so doesn’t harm.
When I see erroneous changes in SE books, I argue to revert, and have generally been successful. In my experience it’s drama‐free, like fixing any other typo.
The problem is when irregular spelling is intended to capture a vernacular. It does a disservice to everyone, erasing the author's intent with homogenized language.
If the spelling is intended to be vernacular, the SE policy is not to change the spelling. I (a mere reader) have successfully reverted dialectal spellings in SE several times.
Editorial commits are all marked as such and contain no non-editorial changes. The tools for compiling ebook files are available at https://github.com/standardebooks/tools, so creating your own versions with only the work you're interested in is straightforward (and can be at least partially automated).
In addition to what Alex has said, as an SE contributor I do try to submit errata to Project Gutenberg where I can find the time and energy. Part of the problem, though, is that PG's errata process (https://www.gutenberg.org/help/errata.html) is quite cumbersome since you have to write an email to their errata team with each individual error. That's a real hassle to try to keep track of and submit. Ideally, if PG had something like a pull request system, I would just be able to find those errors in their code and submit the changes directly, but unfortunately they don't have that, so far as I am aware.
That is one major advantage SE has, I think, which is that we do allow people to make pull requests against any of our ebook repositories and any PRs that get merged are automatically deployed to the site. This makes it much, much easier for tech-savvy people to submit proofreading corrections!
> Part of the problem, though, is that PG's errata process (https://www.gutenberg.org/help/errata.html) is quite cumbersome since you have to write an email to their errata team with each individual error. That's a real hassle to try to keep track of and submit. Ideally, if PG had something like a pull request system, I would just be able to[...]
On the other side of the coin, Standard Ebooks's heavy endorsement/buy-in of GitHub-based workflows are offputting to broader audiences. (It's pretty offputting to me, and I'm not even non-technical; I just recognize it as a sort of Conway's Law + Law of the Hammer sort of thing, and it chafes.) I.e., for others what you describe is far less than "ideal".
Typos can be reported by email on SE too. Git is only required when you’re publishing a new book. My observation from watching the mailing list is that emailed typos are fixed quickly. (I always fix typos using pull requests, and those are acted on quickly too.)
You don't have to use Github if you don't want to, but you do have to use Git. We've had more than a few producers successfuly produce ebooks without using GitHub or Google Groups.
> We've had more than a few producers successfuly produce ebooks without using GitHub or Google Groups.
Can you share or document how? https://standardebooks.org/contribute suggests that "Technically inclined readers can produce ebooks themselves" but doesn't provide any point of entry to do so other than a link to the GitHub org, and "No technical experience is necessary. Contact the mailing list if you want to help." just links to the Google Group.
[0] https://standardebooks.org/about/what-makes-standard-ebooks-...
[1] https://www.gutenberg.org