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)

Apostrophe[edit]

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). I am in 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)

Polytonic[edit]

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)

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)
Default font-size is now 63%. Documentation also edited. Just needed to be that little bit bigger to avoid the denominator touching the bar at some zoom levels. DivermanAU (talk) 05:29, 14 August 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)
I understand now about the implications of copying text with small-caps and getting lower case b.c. I'd like to propose a solution to approximate the size and weight of the B.C. text as shown in EB1911 and still use capital letters. I've created a new template called {{smb}} (smaller text and bolded). For comparison this is using small caps (and lower case): 56 b.c. ; this is using the new {{smb}} (with upper case text) 56 B.C. @Billinghurst: @PBS: @Library Guy:
  • smb/uc: A.D. and B.C.
    • copy paste: A.D. and B.C. YesYDivermanAU (talk) 03:10, 22 July 2018 (UTC)
I can't agree with this. No matter how hard I look at A.D. and B.C. in the EB1911 sources, I can't see that boldface will represent them fairly. DavidBrooks (talk) 23:44, 30 July 2018 (UTC)
I agree that the boldface with {{smb|A.D.}} is not ideal; it's a shame there isn't a reliable way to adjust the boldness level. So although a.d. ({{sc|a.d.}} is the right size and font weight but doesn't text copy as capitals; A.D. ({{smb|A.D.}}) is the right size, copies as capitals, but looks a bit bold; is A.D. ({{smaller|A.D.}}) the consensus choice (although a little large and the font looks a bit thin, it does copy as capitals)? DivermanAU (talk) 05:08, 14 August 2018 (UTC)

Lets stick with what the style manual recommends ({{smaller|A.D.}}). As User:Slowking4 points out we can always have a bot run over the code and change it if there is a consensus to do so some time in the future. -- PBS (talk) 06:30, 27 September 2018 (UTC)

Image names[edit]

Currently there is nothing in the style manual on Image/File names. Is there any guidance anywhere? If there is is it appropriate? Also if there is more than one image on a page how should such Images/Files be differentiated? -- PBS (talk) 19:05, 13 September 2018 (UTC)

Wikisource:Image guidelines#Image naming gives some guidance. -- PBS (talk) 19:28, 13 September 2018 (UTC)
IMO there is no need to be consistent with image names for Wikisource works, and the specific aspects of any image can lend themselves toward different naming schemes in different situations. Commons guidelines essentially advise us that names should be descriptive and accurate, and there is lots of room within that guideline. For instance, if Britannica has an excellent drawing of a tiger, that might be useful on dozens or hundreds of pages across different Wikimedia projects, it might be best to simply call it "File:tiger.png". If I'm uploading a whole collection of images from a work, I'll generally try to give them descriptive names that identify the source, as I did here. I think it's OK to use names like "Brittanica (1911) volume 23 page 96.png", and sometimes it's most convenient to do that when dealing with a huge set of files, many of which will never be very useful elsewhere; so (again in my opinion) it's fine to use an algorithmic approach in such cases, but if you have the time, I'd say it's better to use names that describe the contents of the image. Hope this helps... -Pete (talk) 20:41, 13 September 2018 (UTC)
Pete, the trouble I see with using descriptive names like "File:tiger.png" is how is an editor of this project going to find the file on commons? It seems to me that a consistent name such as "1911 Encyclopaedia Britannica volume 23 page 96 [a..z].[extention]" would help editors find the page. -- PBS (talk) 18:21, 14 September 2018 (UTC)
The article 1911 Encyclopædia Britannica/Colour use [[File:EB1911 Colour - Fig. 1.jpg]] and EB1911 Colour - Fig. 2.jpg etc. and were added by user:DivermanAU. Is this the usual way that you name images and have you run into any problems using this naming convention? -- PBS (talk) 22:01, 15 September 2018 (UTC)
I haven't run into issues with naming - I usually name them "EB1911 article - Fig x.jpg" as you see from above (and sometime extra info if they have a caption in the original) — this enough to make the name unique. I also use the Categories e.g. "Category:Images from the 1911 Encyclopædia Britannica, volume 6" [1] to help find images. DivermanAU (talk) 22:27, 15 September 2018 (UTC)

PBS: Sorry, I lost track of this discussion. When I'm working on something like this, I try to both upload the files to Commons, and add them to the relevant pages here. That way, nobody in the future needs to worry about finding them; they're already included as part of the pages here. And again, I think this approach is more in line with Commons policy, at least when it comes to images that will have significant other uses. -Pete (talk) 02:01, 27 September 2018 (UTC)