Wikisource talk:WikiProject 1911 Encyclopædia Britannica/Style Manual

From Wikisource
Jump to navigation Jump to search

Formatting difficulties[edit]

Having proofread and validated several dozen pages in Page space, I have a few questions I'd like to get discussed and then included in the style manual if we can reach agreement. These comments particularly apply to the process leading from an OCR'd initial creation to a validated page. I've made subsections to help with commenting. DavidBrooks (talk) 01:03, 29 December 2014 (UTC)


I’ve been consistent in changing the ASCII apostrophe ' to right-quote ’ (not ’), except of course in the odd cases where it’s actually a left-quote or a (rare) breathing marker. Unicode, surprisingly to my mind, accepts that apostrophe and right-quote are the same character although they are semantically distinct. Does anyone have a problem with requiring the proper quotes in the Style Manual? It is a little extra effort, but there are several ways of getting a single right-quote, including selecting ‘’ from the palette and deleting the ’.

The general policy is to use straight quote marks rather than curly ones. See WS:MOS. Beeswaxcandle (talk) 09:47, 29 December 2014 (UTC)
Understood, although the recent discussion also says that specialists in a particular work can agree on something else (for EB1911, that would be PBS, Bob Burkhardt, and Slowking4 - not that I've brought it up with them yet). I think the issues with data entry are overblown, as there are several ways of entering the character, although the toolbar palette does require deleting the superfluous open-quote. Finally, can we distinguish apostrophe from single quotes? Since this style manual specifically calls out “curly doubles” for quotations instead of ``...'', and OCR usually gets those right, can we match the occasional embedded quotation and specify curly singles for them, as in: Smith writes, “Jones says ‘yes’.”?unsigned comment by DavidBrooks (talk) 18:06, 29 December 2014 (UTC).
David Brooks does bring up a point, that there is inconsistency between this project's EB1911 MOS which advises use of curly apostrophes, vs. general WS:MOS which advocates straight quotes. Probably the former should be amended: straight quotes seems the obvious pragmatic choice, given that in Wikipedia (which uses straight quotes), numerous articles have been created, and will probably continue to be create as copy-and-paste jobs straight from wikisource. --Kiyoweap (talk) 09:37, 28 January 2015 (UTC)
I think the days of copy-pasting into Wikipedia are over: there was a strenuous effort some years ago and the main focus is expanding the citation templates such as adding title parameters to parameterless {{EB1911}} instances. Anyway, we do have a lot of inconsistency now in Page space and Article space; in my most recent Page verifications I have been using the straight quote because of the general WS:MOS and also because it's a little less effort. But I haven't fixed the many proofread pages in Page space that have the curly apostrophe. I honestly don't much care, except to note that we do consistently use curly “double quotes”, primarily I think because that's what the OCR generates. DavidBrooks (talk) 21:00, 30 January 2015 (UTC)
I do not think that we should use straight double quotes for the reasons given before. We can easily have a bot run over the whole encyclopaedia at a later date converting them without any checking needed. If we go the other way then it would be much more difficult. So I am against changing the local MOS. As for single quotes, unlike the DNB this encyclopaedia does not seem to use them much for quotations (if at all), sp I am favour of using simple standard ascii single quote ' in place of other types of single quotes usage like apostrophes. -- PBS (talk) 20:53, 1 October 2017 (UTC)

en dash in ranges[edit]

As in Wikipedia, the dash in date ranges (1911–2014) should be an en-dash; I hope that's agreed. OCR originally delivers the basic ASCII hyphen, which should be changed. I understand the consensus is to represent it literally and not as 1911–2014 or 1911&2013;2014 (how confusing is that?). The problem now is that it's hard to distinguish visually, and impossible in the editor, so the proofreader and validator can't tell easily if their predecessor got it right. So we have to take the extra time to do a possibly null edit and see if it shows up as a change. Just an observation; I'm not proposing changing the guidance. Am I missing something?

em dash spacing[edit]

I'm not clear whether the long dash in article texts should be surrounded by a hair-space (e.g. with {{}}, as we have been putting in page headings. I've been using {{—}} as a matter of routine, although I really can't see the difference—but it is useful as a marker that, again, distinguishes it from hyphen in the editor. Spacing does seem pretty tight in the printed original. Is there a formal rule about spacing the dashes?

We're in the middle of discussing the deprecation of {{}} at WS:DEL#Template:—. It looks likely to go. At the main Style Manual there is guidance which says not to use space around an em-dash. Beeswaxcandle (talk) 09:45, 29 December 2014 (UTC)


As discussed above, EB1911 Greek uses polytonic diacritics. Although the Greek toolbar palette provides all of them, I've been wrapping them in the {{Polytonic}} template as well simply because it produces a more authentic-looking script (on Windows, at any rate). The template on Wikipedia (but not Wikisource) is deprecated but its suggested replacement, {{lang|gr} does not make the font change. I don't know the history here, but I've put it in the Style Manual as a "some editors" (i.e. me) suggestion. Should it be stronger?

Please continue to use either the {{Polytonic}} or its derivate {{Greek}} templates for Greek text. It looks better and the diacritics show up better in that set of fonts than in the basic font. Beeswaxcandle (talk) 09:50, 29 December 2014 (UTC)
Use the {{Polytonic}} template, this ensure diacritics with serifs display correctly (i.e. as shown in EB1911); the {{Greek}} template may or may not show them correctly depending on which fonts you have installed on your computer. See Template_talk:Greek. DivermanAU (talk) 20:58, 5 July 2017 (UTC)

2 issues: bold punctuation after title? Spaces around quotation marks?[edit]

I have two questions regarding to punctuation, that aren't explicitly mentioned on the Style Manual.

  • 1. The original text appears to set the punctuation marks (if present usually a comma or period) immediately after the title in bold, but this doesn't seem to be consistently used in Wikisource: see 1911 Encyclopædia Britannica/Annealing, Hardening and Tempering and 1911 Encyclopædia Britannica/Annecy for presence and absence of bold punctuation. Unless there is consensus or justification otherwise, I think any bold punctuation in the title should be bolded on Wikisource, and indeed, the example on the Style Manual supports this:
ABDERA, an ancient seaport town on the south coast of Spain, ...
  • 2. I'm not sure how widespread this is, or if it's peculiar to certain articles, but several article's I've proofed have leading quotation marks separated by a space: thus " The sky is blue," said Smith. The closing quotation marks seem to sometimes, but not always, lack the space, and this may have something to do with the presence of punctuation. I've found myself closing the spaces (which can also be incorrectly generated from the OCR), but is there style guidance on this?
No 1: good catch; you are probably right. I have always closed the bolding after the title itself: it matches the text in the previous ### Title ### line. Re no 2 - printed EB's typographical convention leaves a lot of whitespace after open-quote and before close-quote. Usually the OCR returns open as `` (two separate backticks) followed by a space. It usually returns the close-quote with no space. But it does vary, probably dependent on how much the whitespace is stretched by right-justification. Personally I prefer to modernize the look by removing the spaces. But check out Wikisource talk:WikiProject 1911 Encyclopædia Britannica#Typographical changes in Page space (there are too many talk pages pertaining to this topic running in parallel!) for an unresolved discussion on that. You may have seen one of the pages that Diverman worked on. DavidBrooks (talk) 22:48, 12 March 2015 (UTC)

Fractions with straight line[edit]

I have added how to handle fractions into the MOS those with a slash are fairly easy to do. However none of the alternative options for handling fractions with a straight bar seem to be very similar looking to the fractions used in EB1911. The major problem is that EB1911 uses a font that places numbers like 7 and the % symbol below the line of the usual text. AFAICT if the standard templates are used then, depending on the font used, it could affect the format of lines pushing them further apart eg 1{{sfrac|2|3}} 12/3. This affects the line spacing which could make the text look as if a new paragraph had been started depending on the coincidence of a start of a sentence. So the template I have created uses a smaller font and pushes the characters slightly higher 1{{EB1911 tfrac|2|3}} 12/3. I am not wedded to the size of the font of the relative positioning of the bar. Both can be adjusted either temporary see the (documentation in the link {{EB1911 tfrac}})) and/or permanently (the template code is not complicated), so perhaps someone would like to play around with the numbers and if they think the can improve on the look discuss it here. -- PBS (talk) 20:45, 1 October 2017 (UTC)

Thanks PBS, that's a much better representation of the EB1911 fractions, the standard sfrac wasn't quite right. I've started using your template already. I've now compared the print version with your new template, a couple of possible improvements: make the fraction size a little more to match the print version (maybe 65% rather than 60%, otherwise the denominator can appear to touch the horizontal bar); and maybe make the font weight thicker for the fractions (otherwise the fractions numbers look thin). Looking at the print version (e.g. Page:EB1911 - Volume 07.djvu/801 Dalry article) the fractions appear to be the same weight as the standard numerals, although they are obviously smaller. As a comparison, the first fraction following has your standard EB1911 tfrac settings, the second has 65% font-size and the third has 65% and bolded fractions (just by using three quotes either side of the template): 231/4 231/4 231/4. Maybe a font-weight of 500 or 600 (normal=400, bold=700) would be more accurate, but I believe it depends on whether the font handles that. I believe that 65% size will show a gap under the bar, and bold fractions are better than normal weight. Other's thoughts? DivermanAU (talk) 05:43, 10 January 2018 (UTC)
I have only just read this DivermanAU. If you think it looks better with 65% then if you have not already done so then please alter the template to default to that (and reflect the alteration in the documentation). -- 09:35, 7 July 2018 (UTC)

Many link in an article[edit]

Some of the pages I see are full of links either external sources such as Wikipedia, or to other EB1911 articles. See for example the article "Ethiopia".

I think we should introduce wording into this MOS discouraging over-linking.

Linking should be restricted to places in the article where the authors have referred to another article either by using "Napoleon I. (q.v.)" or by the use of small caps as in "dealt with under Peninsular War", or inside brackets "(see ...)".

There are occasionally internal links to other section within an article, an example of which occurs in the article Napoleonic Campaigns "(see (Naval operations below)"

Finally here are the standard use of links to author space (Author:) either in the name of the article or when the EB1911 articles has an initialled author or authors (there are examples in Napoleonic Campaigns where authors have written different sections, so the initials are not always at the bottom of articles.

I think only links that meet one of those criteria should be present in an article. Others thoughts? -- PBS (talk) 21:26, 1 October 2017 (UTC)

I agree with you PBS, only include links in the cases you mention. Sometimes I find one of those pages with over-linking and remove the excess links (see Page:EB1911 - Volume 09.djvu/877 — Ethiopia) where I used the converted Gutenberg text (its distracting otherwise). DivermanAU (talk) 04:33, 13 December 2017 (UTC)

Representing A.D. and B.C. should be small-caps[edit]

Currently the MoS states that "... abbreviations B.C. and A.D. use smaller capitals (for example, {{smaller|B.C.}})" but I do not believe that is correct. Take a look at the scan here Page:EB1911 - Volume 01.djvu/369 and see that the size of the small-caps in the image for the article link Africa, Roman in the first paragraph is the same size as a.d. and b.c. in paragraph 3. (Currently a bot has converted the smallcaps a.d. to smaller A.D. in the text.) Using the "smaller" template reduces the weight of the font and make it look skinny compared to the normal text, using small-caps maintains the normal font weight. The Gutenberg proofers used small-caps. @Billinghurst: @PBS: @Bellerophon5685: @DavidBrooks: @Library Guy: @Suslindisambiguator: @Slowking4: @DutchTreat:Other's thoughts? DivermanAU (talk) 21:59, 6 July 2018 (UTC)

for my part - when the scan comes up lower case, then i use "SC", and when upper case then i use "smaller". but if you want to want to drive a consensus, feel free to bot correct. Slowking4SvG's revenge 23:38, 6 July 2018 (UTC)
I always auto-converted (haven't worked on this for a while) to <code>{{sc|b.c.}}</code>. I thought this was the consensus, and it took some iterations to reach it. DavidBrooks (talk) 23:52, 6 July 2018 (UTC)
The problem is bigger that that. We need to manage a.m./p.m. where {{sc}} is the means.
Further it is not that simple an issue it is not just the visual output, it is all the outputs. B.C and A.D. are capitals and should be represented as those consistently in all text formats, whether a work size-adjusts or not. [They are not b.c. and a.d. which is the input required for small-caps]. We need an awareness of what occurs in copy and base of the text, text-readers, and the appearance in search results, and lower case output is wrong.
  • sc/lc: a.d. and b.c.
    • copy paste: a.d. and b.c. N
  • sc/uc: A.D. and B.C.
    • copy paste: A.D. and B.C. YesY
  • smaller: A.D. and B.C.
    • copy paste: A.D. and B.C.
  • fine: A.D. and B.C.
Where we have a.m/p.m. the use of small-caps is the right way to handle it
  • sc/lc: a.m. and p.m.
    • copy paste: a.m. and p.m. YesY
  • sc/uc: A.M. and P.M.
    • copy paste: A.M. and P.M. N
So arguing one case alone is not appropriate when we are needing to manage the more diverse solution. — billinghurst sDrewth 01:01, 7 July 2018 (UTC)
  • Pictogram voting comment.svg Comment Please also consider w:Small caps#Computer support for small caps in responses. — billinghurst sDrewth 01:01, 7 July 2018 (UTC)
  • Pictogram voting comment.svg Comment 2: {{smaller}} is our specific representation as determined by consensus to allow for consistent decrease.increase where nested. It maybe that the percentage for {{small-caps}} is not in alignment with that and needs to be globally adjusted if it is problematic in a work or two. I know that we didn't consider this aspect at the time of picking the % change of font-size. — billinghurst sDrewth 01:05, 7 July 2018 (UTC)
  • Pictogram voting comment.svg Comment Either {{sm|B.C.}} or {{sc|b.c.}} is fine with me; I prefer the first because I think it makes the source more readable. Using both representations in a single article is kind of tacky. I think getting the font-sizes exactly right is a poor emphasis. For example, the fine print sections are smaller in font-size and line-height than the usual body font-size. Showing which sections are fine print is important, but getting the font-size exactly right I don't think is so important. I think just using "smaller" font-size would be better than what we are doing now. We are just trying to get a good electronic representation of a printed document which communicates its essentials. Also, many aspects of a print representation are due to limitations of that medium (space, page size), which should be abandoned when moving to an electronic medium; and idioms like slapping down an image or table in the middle of a paragraph while they work OK in a print medium, look kind of awkward in an electronic medium where the formatting has to be more flexible, and the original paragraphing still needs to be communicated. Library Guy (talk) 15:21, 13 July 2018 (UTC)
As with the above discussion on Fractions, one has to be a little careful with this type of formatting problem as there are often can be typesetting differences between volumes. So what is a facsimile copy by Wikisource based on one volume may only be an approximation in another. This is the same for other things (eg (q.v.)) in different volumes. So for all these sorts a issues a number of volumes ought to be surveyed to see that there is probably one rule fits all. -- PBS (talk) 09:43, 7 July 2018 (UTC)