Wikisource talk:Style guide

Disambiguation guidelines

I propose the following guidelines for disambiguation pages.

Disambiguation pages
A disambiguation page is a page listing multiple works of the same name (example: The Raven).

1. Page titles should be the ambiguous title being disambiguated.
2. The {{header}} template is standardised: the title is the ambiguous title; the section name is "(disambiguation)"; the notes contain the template {{disambig}}.
3. Disambiguated works are listed in bulleted form as such:

   * '''[[The Raven (Poe)|The Raven]]'''—A poem by [[Author:Edgar Allan Poe|Edgar Allan Poe]]

4. Disambiguated work titles: see 'Page titles'.

// [admin] Pathoschild (^talk/_map) 20:33, 18 June 2006 (UTC)

Sounds good to me. Although, what is the difference between number 3 and number 4?—Zhaladshar ^(Talk) 01:44, 19 June 2006 (UTC)

Sounds good to me, too; I believe the difference is the formatting of the actual titles of the works, such as The Raven (Poe) and The Raven (Someone Else). My only thought was that perhaps we could change the colour of the header on the disambiguation page, to make it clear that this isn't a work... however, it's not really necessary. Jude (talk,contribs,email) 01:51, 19 June 2006 (UTC)

Number 3 covers the formatting of each line on the disambiguating page, whereas number 4 covers the disambiguated page titles themselves. // [admin] Pathoschild (^talk/_map) 16:42, 19 June 2006 (UTC)

It says with no links except the titles. However I think a link to the author's pages could be useful. Yann 20:15, 15 May 2008 (UTC)

Naming policy

I don't understand the naming policy—why would we want The scarlet letter and not The Scarlet Letter? Or The pilgrim's progress, The gambler, Pride and prejudice, etc. Why not use simple rules like capitalize all words except articles and 2-4 letter prepositions? It seems that that is the de facto policy; perhaps this page should be updated? --Spangineer^wp (háblame) 18:57, 19 July 2006 (UTC)

The naming convention is for titles with no original capitalisation, intended to correct problematic titles like "Presidential Radio Address Of 17 May 2006" or "NEWSPAPER ARTICLE ON THE WAR OF 1812". For most words, the phrase "unless an original capitalisation is consistently used" overrides the previous statement. For example, if "Pride and Prejudice" is the most common capitalisation, that one should be used instead. Think of it as a default capitalisation for works with no original capitalisation.

Regardless, this section will soon be replaced by a global naming policy that will be more in-depth. // [admin] Pathoschild (^talk/_map) 19:14, 19 July 2006 (UTC)

Thanks for the response. Has the work on the more detailed naming policy already begun? --Spangineer^wp (háblame) 19:24, 19 July 2006 (UTC)

It's on my short-term to-do list; I intend to begin once I finish TemplateScript. It should be ready for proposal in a week or two. // [admin] Pathoschild (^talk/_map) 19:38, 19 July 2006 (UTC)

OK, let's make a proposal. I suggest replacing:

Sentence form (most words lowercase) is preferred, unless an original capitalisation is consistently used. Normal exceptions, such as proper nouns, apply.

with

Capitalisation for titled works using title case: all words capitalised except short (< 5 letters) articles, prepositions, and conjunctions (except when the first or last word); but if the title is consistently capitalised in a different format, use that instead. For originally untitled works (e.g. Bin Laden's letter to Mullah Mohammed Omar), use sentence case: all words uncapitalised (except the first word), with the normal exception for proper nouns.

--Pharos 10:36, 14 February 2008 (UTC)

 Support per discussion currently at the Scriptorium —Beleg Tâl (talk) 19:07, 17 February 2016 (UTC)

 Comment Perhaps you may want to use this as a guide. Londonjackbooks (talk) 20:42, 17 February 2016 (UTC)

wow, that's a lot more detailed than I would have intended to propose, but I like it. I'd be willing to incorporate the whole thing, with appropriate modifications (such as "except when the source scan indicates otherwise") —Beleg Tâl (talk) 21:09, 17 February 2016 (UTC)

I do not want to steer you wrong as proposals of guideline/policy changes are new to me, and I do not necessarily know how the process begins,—but I would develop an outline for what you intend to propose (on this page initially—perhaps create a new section), and place notice of it at the Scriptorium to alert other contributors that discussion on the subject is sought. A more serious and in-depth forum would be Wikisource:Requests for comment, but I would seek further opinion on whether, at this stage, that would be an appropriate forum. Feedback/input from other contributors is what is desired at this point, correct? and not a voting process? Londonjackbooks (talk) 23:34, 17 February 2016 (UTC)

We already have the discussion happening at the Scriptorium, and this discussion here; I'm pretty sure these are the appropriate places for seeking feedback and input. Right now what I intent to propose is that we follow the suggestion of Pharos above. If you or any of the other WS editors thinks a different approach is preferable, I'm amenable to that. —Beleg Tâl (talk) 14:12, 18 February 2016 (UTC)

 Support per discussion currently at Wikisource:Scriptorium. --Neo-Jay (talk) 20:55, 17 February 2016 (UTC)

Text formatting

What kind of formatting is generally permissible? For example, what about converting "--" to "—" and making ellipsis spacing consistent? --Spangineer^wp (háblame) 22:21, 28 September 2006 (UTC)

Personally, I always change -- to an em dash ((using {{--}} or '—' (it's so much easier to type an em dash on a mac!)), and insert elipses etc. But I don't know if it's generally how people work. There doesn't seem to be any overt policy on typography (although maybe one is emerging?). But, I'm nearly two years late with this reply, so I guess you've figured something out by now... :-) — Sam Wilson ( Talk • Contribs ) … 07:56, 8 September 2008 (UTC)

I deprecated it, and I'm about to change it to a null effect. {{—}} may have some escape function, or a shortcut for the character. cygnis insignis 06:24, 23 September 2010 (UTC)

I disagree with deprecating this; see Template talk:—. —Spangineer^wp (háblame) 13:40, 23 September 2010 (UTC)

Naming and translated works

Do we want names for translated works under (1) original title in foreign language, (2) direct translation of title in foreign language, (3) whatever some old PD translation was originally published under, or (4) whatever is considered the "common" name in English, i.e. the Wikipedia naming standard. Personally I would suggest (4), but either way I think we do need some standard here.--Pharos 04:17, 8 June 2007 (UTC)

Long 's' (ſ)

Is there a final policy on the use of long 's's (unicode character 017F: 'ſ', 'ſ')? Some works (e.g. Elegie I) keep it, but there seems to be a lack of consensus (see Wikisource:Scriptorium#Typography_queries). Would it be useful to create a template (say, {{Long s}}) to be used for every instance of a long s, so that it could be easily changed to a short 's'? Is there a way of changing how the template operates on a per-work basis? That might be useful, although if a site-wide policy were to be decided upon it would be unnecessary. —Sam Wilson ^{contrib's | talk} 02:21, 18 February 2008 (UTC)

Just to tidy up here, and in case anyone's missed it elsewhere: please use the long 's' template (either {{Long s}} or {{ls}}; they're the same) for transcribing these characters. The template is currently set to display the long 's' on Page namespace pages, and a modern 's' on Main namespace pages; this makes for easier reading and source fidelity. There is not yet a way to change the output on a per-work basis. — Sam Wilson ( Talk • Contribs ) … 07:51, 8 September 2008 (UTC)

Why should it display a modern 's' in the main namespace? We should match the original orthography; if necessary, we can add an explanatory footnote or header description. —{admin} Pathoschild 08:16:50, 08 September 2008 (UTC)

Actually that's just what I thought at first, too. But now I quite like the idea, especially as it's so easy to change at any point—ideally, I'd like to see some way of changing it on the fly, per-page as it were. Certainly, reading modern Ss is easier than long Ss (although after a page or so the become pretty invisible). User:Jayvdb added the code to display differently in the main namespace, by the way; maybe he can add some extra explanation.

I'm not sure about being completely true to the original orthography, though: we don't, for example, use st ligatures (do we?), or match fonts; isn't this in the same league? Hmm, maybe I'm being contradictory there: I do want to keep the long Ss, after all… so I don't know.  :-)

— Sam Wilson ( Talk • Contribs ) … 09:41, 8 September 2008 (UTC)

Check out {{custom substitution}}. It is a general template that will allow us to easily let users select, based on monobook.css commands, whether they see ſ or s. Long-s is not the only thing that can use this, I made {{eszett}} too which works on the same principle. Inductiveload (talk) 02:51, 8 March 2010 (UTC)

FYI, this was killing Google searches and has been removed.--Doug.^{(talk • contribs)} 16:01, 28 July 2011 (UTC)

lefttext & prose CSS classes

As far as I can see, it doesn't matter which of these classes is used when one is formatting a page that contains {{Page}}s: they both provide a left margin that the [page] link sits in. So it's just up to the editor? Or are there other differences between these two that I'm not aware of? And are there any other similar classes that it would be useful to mention in the Style guide?

Personally, I prefer the prose class, with the adition of font-family:serif (like this paragraph), because it's actually almost possible to sit down and read a lengthy text on-screen, or so I find. I would support some guideline that encourages editors to use somesuch formatting, if anyone else is into it…

— Sam Wilson ( Talk • Contribs ) … 08:07, 8 September 2008 (UTC)

Personally, I find sans serif fonts (especially nice wide ones like Verdana) easier to read on-screen than serif fonts. Printed on paper, though, I prefer serif fonts. Angr 11:08, 12 September 2008 (UTC)

Neither of these classes wrap, both justify the text to create a flush margin. This imposes a width and makes it more difficult to read. Cygnis insignis (talk) 17:57, 25 January 2010 (UTC)

So we shouldn't use them? I don't particularly mind, but I think that if the Style Guide mentions these classes, then it is rather endorsing their use. Should we remove that bit? — Sam Wilson ( Talk • Contribs ) … 01:36, 28 January 2010 (UTC)

I prefer serifs, but I am not willing to override other user's preferences or risk interfering with accessibility. AFAIK the prose class was introduced because people didn't like the way short poems appeared on the page, they have a point but also the option to change that their individual preferences. Changing the size of a window is trivial, imposing a preference is not. Left-text emulates an original, analogue format that is constrained by the size of the physical page, not very well because it forces an indent and a line break. Printers used a format that gets as much print on the page as possible, economics being a key factor, the single spacing and lack of empty lines are not present when the text is digitised. Justified text was created by craftsman, it is quite difficult to a satisfactory result, attempts by digital applications to do this vary from crappy to, more recently, barely okay. High-end applications do a better job, but there is a legitimate view that ragged right margins improve the legibility. As with the millions of articles at the other place, none at all would be best, but it's introduction was required for technical reasons. The class 'indented-page' has been widely deployed, the only difference is a small left margin that keeps the trancluded content clear of the link to the Page: namespace. Yes, we should remove that bit. Cygnis insignis (talk) 03:29, 28 January 2010 (UTC)

NOTE that these classes are now redundant with the change to the underlying layout that is deployed in left hand side links. — billinghurst sDrewth 11:55, 4 November 2010 (UTC)

Author naming convention

Following on from the discussion about {{Initials}} on template's talk page and WS:S, it would seem that we have a policy to have full names, not partials (first/last) or initials. I would think that if we have the preference for full names then we should be specifically stating that, rather than leaving it for contributors to discover for themselves at a point in time. If this page is to be kept simpler, then maybe we could add that direction to {{Author}}. -- billinghurst (talk) 10:24, 28 December 2008 (UTC)

Modification to # Special characters ...

An edit was made that suggested that the paragraph be modified to ...

1. Special characters, such as accents, ligatures[, and punctuation marks], should be used wherever they appear in the original document, if reasonably easy to accomplish. This can be achieved using a special character menu shown below the editing form, or using typography templates. Optionally, templates such as {{long s}} (ſ) may help avoid confusion between special and alphabetical characters.

• support update — billinghurst sDrewth 12:18, 5 June 2010 (UTC)
• I reverted the change, though I don't necessarily oppose it. The contributor wants to make curly quotes policy, quite a different path to the extensive discussion over the equally questionable use of long-s. WP:MOS recommends against, whether there is good cause or simple bloody-mindedness behind the policy there, I'm pretty sure it is better to focus on more productive matters. If the case is strong for curly quotes, we should probably change all of them, the arguments concerning digital doc, the web, and particularly searches sway me to say no change at this stage. Cygnis insignis (talk) 12:58, 5 June 2010 (UTC)

  I couldn't give a toss about curly quotes, though if someone wishes to do them, good luck to them. For me they fall outside reasonably easy, however, there is a whole lot of punctuation that I wish to see, no more --, where we can have —; and other punctuation which falls under this category. The remaining text doesn't particularly cover punctuation. — billinghurst sDrewth 16:15, 5 June 2010 (UTC)

My earlier changes got a welcome copyedit, but I think my version of Formatting (4.) is more firmly positioned - it grasps the key concept and makes for a practical guideline when deciding what to retain. I agree that emdashes should be used, until convinced otherwise, transcriptions that do that sort of substitution also use allcaps for italic :P Cygnis insignis (talk) 18:47, 5 June 2010 (UTC)

Personally, I prefer spaced en-dashes to unspaced em-dashes, but if we do use unspaced em-dashes, we should at least put zero-width spaces (&#8203;) on either side so that there can be line breaks where they occur. Angr 11:53, 26 June 2010 (UTC)

I use a keystroke modifier on -, but there is {{—}} being deployed with a different idea. I would need to see an example to appreciate the zero-width behaviour. I am concerned that this affects our quirky search engine, hyphens and dashes seems to be another thing that fouls matches on very close search patterns. Am I wrong in thinking that adopting a convention would would eventually help with that problem. Cygnis insignis (talk) 13:27, 26 June 2010 (UTC)

Disambiguation Guidline redux

Further to an initial conversation with Cygnis insignis (User talk:Cygnis insignis#Anthony Panizzi and his ilk), I think that the Disambiguation Guideline needs a little clarification. At present the guideline refers to works with the same title. This has been interpreted as including articles referring to the same person/place/subject. E.g. Anthony Panizzi or Anazarbus. These articles are already disambiguated by the publications containing the articles, so don't need a disambiguation page for the topic. Cygnis insignis correctly points out that the articles will be found via the usual search mechanism and the addition of a dab page with {{tl:similar}} on the separate articles adds extra layers of navigation that are not required. I suggest the addition of another point.

6. Articles about the same topic do not require a disambiguation page.

Note I've deliberately used "do not require" to allow for the odd occasion when there will be a need. Beeswaxcandle (talk) 06:55, 19 March 2011 (UTC)

I disagree, as I find that linking similar articles by some means is useful, though happy to explore other solutions to achieve this if disambiguation pages are that problematic. I hardly find them difficult and most have quick link potential (templates) for most biographical texts. Would that also means that {{versions}} are just as redundant, maybe even more so? If we also follow that example then we would also stop doing redirects from a base name to a work within a collection as the rationale is that they can find it via a search. Also, it would be useful if it could be indicated why it is a problem, the above bit doesn't clarify that issue.

For John Smith, we do or we don't have a disambiguation page? One John Smith? Two, three or four John Smiths? Three or four encyclopaedias/dictionaries (quick mind dump of some of the bio material EB1911/CE/DNB/Aus Bio/Irish Bio/Alumni Oxon/Alumni Cantab/Men at the Bar/Men of the Time/PSM/Indian Bio/...). Maybe sixteen entries, so a search result is not going to help. If we have an Australian bio for John Smith, it is just going to be Title/Smith, John, similarly for the Irish work Title2/Smith, John. Same person? Different? Is it easier to go to a disambiguation page, or to visit each biography? Then have the example where a poem is about the person, against the biographical data. We wouldn't disambiguate in your example. So part of the conundrum is when do we know that they are different John Smiths? Different works about John Smith? How, where, when do we start disambiguating? To me it is easiest to start when we have two articles. One could say that this is more than disambiguaton, that this is also about navigation aids, and making it easier to find things on site. It is also useful if one of the John Smith's is an author as we can then link over to show that there is more.

Now where there is an author page, and we only have works about the author, then I generally haven't been doing separate disambiguation pages (well not recently), as we can let the Author page stand as the disambiguation/link page, and each should link back to the author page.

Extending that thought line both Cygnis and myself both wish to see a better solution than Template:Similar though not yet arrived at on a solution, and my recent commentary has been that it may be something for consideration in {{header}} (via {{plain sister}}) navigation box. Billinghurst (talk) 11:22, 21 March 2011 (UTC)

We make a page for ambiguous titles because the software doesn't allow allow a title to be used twice. We make a page for multiple editions because an author may refer to another author's text without specifying the edition (or "version") and we should not decide which the reader should see. We want the most comprehensive, cross-referenced, hypertext subject index ever devised, we have it! eg. w:John Smith. Note also that we link to sources from that place, it is appropriate for users to do that, the objects we accession do not need to link elsewhere, the value in this is often very low or none—the user has arrived at the desired page, it is the end of the path. That path is worth worth creating it is notable, and should be noted elsewhere; wikisource is improved, "made useful", by linking to it... TO wikisource. Arriving at a wikisource page is deliberate, they either want that text or they took the wrong path; they need to go back and try a different path. Linking every other possible path is not appropriate: 'disambiguating' the sections within a title, especially reference works, without an author's reference, is insane. The real-politick of our situation is that editors are addicted to making things 'light-up', operating on more or less flimsy premises, they get their fix at wikipedia until someone says "No!", there is a drama, they get censored, then come here to create duplicate or maverick schemes. We are not editors here, what we 'know' about other texts is utterly irrelevant. CYGNIS INSIGNIS 14:19, 21 March 2011 (UTC)

Biographical articles are just articles written at a point time where each author had access to different material, different connotations, and their own biases. When writing an article one refers to multiple articles, which is expected for WP biographical articles. So to me, it does not seem inappropriate to link to related articles that provide a perspective, and often a perspective sometimes contemporaneous, sometimes retrospective. Linking them or listing them on a page is collating, not judging them. Then to think that WP is going to be fully comprehensive of any listing at WS does seem to reflect that it is an encyclopaedia, which pretty much means filtered, abridged, rather than exhaustive; something always has to go. Similarly, research is proved wrong, proved right, contradicted, etc. so by linking to one book alone is always going to end their journey, not expand their journey. Curators and librarians are the joiners of knowledge allowing it to be accessed from different perspectives, and making it available for a wider view, so I cannot accept a one-dimensional view that our readers only come for that page or that work. Some may, very true, but I would say that some/many do not.

We all have our opinions, we can disagree with each others, they are still our opinions, and that makes them right for us. It would be nice if there wasn't the rhetoric; hyperbola; judgemental statements that may indicate your use or your approach; it is not a singularity there is no one correct approach. If something is missing then add to it

Users will always have their own experience on their own terms in line with why they came here; I won't try to double guess or to limit. I don't have the expectation that everyone will search, or want to search, some will want to browse, to wander, to find new paths, new knowledge. As an editor it is my job to get the text right to the work as expected by the author; as a lay-curator (and in the absence of professionals) it is one of the tasks to at least make the site easier to navigate, to open up contents to be explored. Where we get the "mavericks" et al, I try to approach things with an open mind even when my gut says no no no, and see what experience they want to have, and work with it and adapt and promote the good bits, and try to discard other bits; evolution is just inevitable. Billinghurst (talk) 15:45, 21 March 2011 (UTC)

smart quotes vs straight quotes and other punctuation

I see that the style guide was changed to say that we should use only straight quotes with this edit. However, I see no discussion and the reasons at Wikipedia referenced here are not particularly convincing. In fact, the changes were modified shortly there after with this edit but were reverted without discussion, merely an edit summary that the changes were an "impractical solution". How are these different from the problems of any other unicode characters? At the very least, actively changing smart quotes to straight quotes seems a waste of time while proofreading. On many of our sister projects there is no concern with using «double angle quotation marks» which are at least as problematic for display and for search engines.

I also don't understand what the basis is for the added language about dashes etc here, what is wrong with using &mdash; for —, for example, or &#x2010; for ‐  ? It seems much more likely that we'd get hyphens (‐) and minuses (‒) instead of the common hyphen-minus (-) if we didn't try to prohibit this and not everyone has a button or some other way to produce the actual characters handy all the time.--Doug.^{(talk • contribs)} 19:30, 25 October 2011 (UTC)

• My comment sat her for nearly two months without comment so I have removed the section. If we think we really need rules on these two matters, I suggest they should be limited to:
  1. Quotes: quotes should be consistent throughout a work, either straight or curly, if curly quotes are used then curly apostrophes should also be used (a curly apostrophe is the same character as a curly right single quote)
  2. Hypens/Dashes: Hyphens and dashes are not interchangeable. Hyphens should be consistent throughout a work and a hyphen-minus should be used unless another form of hyphen is determined in advance.
• --Doug.^{(talk • contribs)} 05:59, 22 December 2011 (UTC)

I have undone your edit; a general discussion without a proposal is just that, your removal does not seem to make the guide better. It is our preference, and become what has been reflecting the practice, which is exactly what a guide should be. A guide is not a hard set of rules, and should allow variance if there is a justification for that variance. The most important thing should that a work should be uniform in its approach. The problem has previously been where the style guide has been autocratically imposed as a rigid set of rules. Looking to what you are trying to address it seems more about hard guidance (rule/shall) and soft guidance (preference/should). I agree with your statements about ... — ... &mdash; ... &#x2010; ... {{--}} for its reasoning and their use is not wrong, that said, simplicity and for proofreading sometimes an — is easier to check for its existence. — billinghurst sDrewth 11:26, 22 December 2011 (UTC)

Do you disagree regarding smart quotes? I use them as does Inductiveload, I know. Not sure about others. I have never seen any discussion that this is our preference and I don't think we should be telling people they should use straight quotes when there is no such preference. The only thing it materially affects is a quoted search. How about the language I have posted above? Possibly with more detail regarding dashes.--Doug.^{(talk • contribs)} 11:53, 22 December 2011 (UTC)

Also regarding ellipsis, I commonly see you using … instead of . . . so I don't think entering actual characters is a practice or preference at all.

I have removed the link to the non-existent rationale for straight quotes. the Wikipedia Style Guide is of no relevance and contains no rationale.--Doug.^{(talk • contribs)} 12:00, 22 December 2011 (UTC)

• How about this for a complete proposal:

1. Punctuation:
   • Remove extra spaces around punctuation, eg. colons, semicolons, periods (full stops), parentheses or commas, as well as incremental spacing found within justified text.
   • Quotes should be consistent throughout a work, either straight or curly, if curly quotes are used then curly apostrophes should also be used (a curly apostrophe is the same character as a curly right single quote).
   • Hyphens/Dashes: Hyphens and dashes are not interchangeable.
     • Hyphens should be consistent throughout a work and a hyphen-minus (-) (U+002D) should be used unless another form of hyphen is determined in advance for the entire work.
     • Dashes should be an em dash (—) (U+2014) or an en dash (–) (U+2013) should be used. For greater length dashes templates or html/css should be used depending on the application.

• I have left the first line, though I don't see why we would object to the use of archaic spacing which was not always merely part of justified text (colons often were placed evenly spaced between words even when it made justification harder). I have left out the section on ellipses intentionally, they are very difficult to space to the original and this is frequently pointless.--Doug.^{(talk • contribs)} 12:18, 22 December 2011 (UTC)
• Additionally, on the spacing point, I don't see any usefulness in removing one of the two spaces normally following a period/full stop. I type them by habit, myself, and would never go back and remove them. It is actually a flaw in our systems that these second spaces get sucked up and one we should be trying to find a way to overcome.--Doug.^{(talk • contribs)} 12:23, 22 December 2011 (UTC)

It still seems to me that the principle is not clear and we are looking to impose rules. The words are vital, continuity through a work is needed, there is some formatting that we have modernised though if an older form exists within a work, then see previous two points. The reality for why we have the guidance that we do is 1) ease of proofreading, and people don't all do curly quotes, 2) OCR generally keeps it simple, and we should be looking to that as a good principle, 3) more rules, and slavish adherence to a 17th or 18th or 19th century model which changed is pretty pointless, we don't want to make it harder for contributors. Definitely about two spaces between sentences, we obviously learnt from the same style guide for typing on an old-fashioned typewriter prior to word-processing justification. Our guidance about not doing pointless editing should stand. — billinghurst sDrewth 13:04, 22 December 2011 (UTC)

I continue to not follow. I don't think "we are looking to impose rules" at all; except maybe with respect to dashes and hyphens because anyone who uses a hyphen-minus for a dash will likely get a talk page full of explanation and if they don't fix it, it will be fixed for them. Quotes and using characters instead of codes for dashes or ellipses are just not rule things, the rule is "keep it consistent", not "do it such and such a way unless there's a good reason". We shouldn't require a "justification for [a] variance". The person who sets up the work sets the style and might just decide to follow another way because he or she likes it better, it's easier and they won't do it at all otherwise, or whatever. You seem to like &hellip; and, apparently, straight quotes. I prefer curly quotes and will rarely bother to figure out which dash is which on the tools below but will instead type &#2014 or &mdash;. If I edit a work that you have set up, I'll use straight quotes but you may still have to go back and "fix" my dashes if you don't like the codes. If you edit Index:The International Jew - Volume 1.djvu (or 2 or 3 or 4), you will either use curly quotes or your edits will be changed. Anyone who tries to say it's wrong is likely to be simply ignored. Inductiveload and I had no justification for making the quotes curly except that it's very easy to do and we're setting up the work, and most importantly, we both want it that way.

User preference should be king. I suggest we should consider the de.ws way (one of the few places I'd suggest this) which is actually pro-preference in this arena. They have a strict style guide which they will aggressively enforce (e.g. all dashes are transcribed as en-dashes), but they also have a firm rule that the person who sets up a work can make all sorts of deviations from the style guide by declaring the variations on the index page (e.g. em-dashes will be transcribed as em-dashes). It is of course only this latter part that I wish to import ;-). --Doug.^{(talk • contribs)} 13:47, 22 December 2011 (UTC)

• I agree with the primary goal being that of consistency within a work, and with the details of how that is achieved being up to the editors of that work. I see the Style Guide as being just that, a guide for when I'm not sure of what to do and don't have a personal or precedential preference (ooh, such alliteration ;-) ) and mostly I just do what I think is correct. Let people do what they want; we can always fix things up later — far more important that people feel able to contribute! — Sam Wilson ( Talk • Contribs ) … 05:22, 23 December 2011 (UTC)

A few points/thoughts:

• I've never bothered to change the standard browser font on this laptop and so I can't see the difference between "curly" quotes and "straight" quotes. This means that, because I can't type curly quotes directly I don't bother. If I was always editing on a Mac then I might consider it. Additionally, I use Hesperian's cleanup script which changes all curly quotes to straight ones. I suspect that the average reader/user of Wikisource won't even know that they can change the standard browser font and therefore they won't be able to see the difference either—so what's the point of distinguishing them?
• Have worked in typography in the past I am much more concerned about em-dashes and en-dashes being correct. If the wrong one is used (or incorrectly spaced) then it slows my reading down as my wetware tries to make sense of what it is seeing. For me an em-dash should never be spaced and thus I never use {{—}}. It doesn't help that the default font here doesn't have a character for the thin spaces and so I see a couple of ugly little boxes on either side.
• Yes, there are times when colons and semicolons are spaced as words. This is mostly in liturgical works to assist with pointing the chant. However, in all other circumstances I think the space before is an artefact of the typesetting process and I find it ugly.
• With respect to double spaces after a full-stop: fortunately the software collapses these to a single space (although Hesperian's cleanup script does this anyway). One enterprising editor has come up with a way around the automatic collapsing, but the resultant proliferation of templates makes the works harder to read and use. Try Bulletin of the Torrey Botanical Club/V23/Drink Plants of the North American Indians for an example. The templating of paragraphs with each sentence being a field makes searches across sentences impossible. But the long spaces are there.

I'm sure that there are things that I've missed or misunderstood, but in the end I'm with Billinghurst on the simple fact that we're trying to make the words/texts available in a useful searchable format and the minutiae of the "pretties" must be at the service of that rather than the other way around. Beeswaxcandle (talk) 07:43, 23 December 2011 (UTC)

Amen to SW and BWC, and really I don't think that we are away from where Doug is.

The reason we have a guide is also as many works are shared, we need to be able to explain generally how our works are being edited, so people hopefully come along edit one page grossly different from the remainder of a work, or to move them away from a standard. As more prolific editors we intuitively do such things, however, for the casual editor, they will/may like to be guided.

Where we have probably been poor in documenting and enforcing is where a specific work varies from the style (for whatever reason). We need to be much better at annotating the Index/Index talk pages where a work deviates from the norm; such would be on Index a note that says see the talk page for specific editing styles for the work in question. — billinghurst sDrewth 08:00, 23 December 2011 (UTC)

+1 for each work explaining its deviations from the style guide. (Not that I've ever gotten around to doing so!) This is what PGDP do, and it seems to help there. — Sam Wilson ( Talk • Contribs ) … 23:41, 23 December 2011 (UTC)

I agree with Billinghurst, BWS and SW. I really don't see the punctuation as problematic in most cases. If I am doing my own work (or a work that doesn't seem to have some special formatting preferences) then I will, using a script:

• Use straight quotes (and change curly quotes in OCR to straight). Most (non-WS-regular) people are barely aware they are a distinct glyphs (some may never even notice the difference due to font issues), and wouldn't know where to find them. The reason I used them in TIJ was not a personal preference, but rather because Doug, as the primary contributor, wished to keep them. I don't mind keeping them where they are already standard, but I wouldn't say I prefer them.
• Remove spaces before colons, semicolons, exclamation marks, question marks, etc., unless obviously part of some "special" formatting such as maths or music. I find this to be ugly and hard to visually parse, and to me it's just one of those 100-year-old typographic affectations that aren't part of our mission.
• Collapse multiple spaces to one space. Since it's collapsed anyway, and I mainly consider a double space after a full-stop to be from the era of typewritten monospaced text, I don't find them at all important. Trying to get consistency would be a huge struggle, as it would be easy to miss one, or for a helpful editor who hasn't read some notice hidden away somewhere to not put them in. The reason they are collapsed is because "normal" HTML collapses whitespace, and you need special formatting wrappers to preserve it.
• Remove spaces around an em-dash. I don't recall ever seeing a scan a page with spaces around the dashes. I don't use {{—}}, just the — character. I understand that HTML codes might be easier for some to enter and, being equivalent in the end result, I don't find them offensive. {{--}} is fine too, and can be substituted at will.

The priority for me is that the "default" formatting is easy to do. I find the above to be the simplest and most consistent method. Adding spaces in certain places or using characters that no everyone even realises are distinct glyphs is just inviting fragmentation. Perhaps someone who really cares would fix the deviations, but it would suck up a huge amount of time from an experienced editor. I say, keep it simple, and in the general case, use the method that an uninformed new editor can get right on the first go. There is enough to learn around here without weird rules for where the colons go.

If a work does have a good reason to deviate, then the style should be very clearly stated on the talk page, and any mistaken edits should be gently corrected. Having your first edits criticised because of a misplaced space or a wrong quote would, I imagine, be very dispiriting to a new editor. Inductiveload—talk/contribs 10:56, 24 December 2011 (UTC)

OK, sorry for giving you part of the blame IL for the curly quotes on TIJ ;-). In any case, I agree with most of the above I guess, the point of clear agreement is that we should be documenting the deviations. I think the the index page is the place to do it as that's sort of the "control page" for the work.

I do not advocate the use of templates for dashes ever, though I don't strongly object to it if the extra space isn't added in. I sometimes use the html simply because I can't find the right one, though since I normally edit from a mac, that's a sign of supreme laziness.

I do disagree on the spacing, but as I noted above, I do not advocate templating in the spaces, I advocate a change to the mediawiki software as there is no good reason to collapse the double space after a period and doing so is one of the big reasons web content is harder to read in my opinion.

The rules were added by Cyg, who is either on long term break or retired, but he used the style guide as a set of rules to enforce not a point of departure. Apparently that era in en.ws is over and we can note our deviations as we will. I'll start with noting the TIJ deviations. ;-)--Doug.^{(talk • contribs)} 12:23, 30 December 2011 (UTC)

If you want the edit window to have the em-dash character (rather than HTML code) in it, but don't want to type anything other than ASCII characters yourself, just subst the template in. If you type {{subst:--}}, no one will ever know you didn't just enter the em dash directly. Angr 23:30, 30 December 2011 (UTC)

Dashes / hyphens and date ranges in titles

Another editor has noted that for a time, links to a Wikisource article from an article at Wikipedia were broken because a script (w:User:GregU/dashes.js) had changed the hyphen in the wikilink to an endash. The link to the Wikisource article was broken because there wasn't a redirect at Turner, William (1714–1794) (DNB00) to Turner, William (1714-1794) (DNB00). As you can see there is now a redirect.

Reading between the lines at Wikipedia's MOS:DASH and MOS:ENDASH suggests that the title of an article that contains a date range should use an endash instead of a hyphen. This further suggests that visible date ranges in links to Wikisource articles should contain endashes even if the actual title's date range contains a hyphen.

[[Turner, William (1714-1794) (DNB00)]] → Turner, William (1714-1794) (DNB00)

The Wikisource style guide doesn't seem to address hyphens, dashes, and date ranges. Is it addressed elsewhere and I just haven't found it? If not, what is the correct way of expressing a date range in an article title on Wikisource?

—Trappist the monk (talk) 19:45, 7 October 2013 (UTC)

I like the idea of using proper dashes in titles. (And not having user scripts that mess with perfectly good URLs! ;-) But that's a separate issue.) And no, I don't think it's in the style guide explicitly at the moment, so maybe it'd be good to add it. — Sam Wilson ( Talk • Contribs ) … 06:32, 8 October 2013 (UTC)

The DNB project made a decision for that project to standardise and use hyphens, and that was a simple way to have them as it is on the keyboard, and many just scanned that way (KISS). At the same time, we do encourage redirects as many are done with ndashes. Can I say what an idiotic bot approval. <sigh> A rule? If you want one, use a hyphen, and feel welcome to put in a redirect. That is what we have been using for author disambiguation pages. — billinghurst sDrewth 10:07, 9 October 2013 (UTC)

Thanks for that. The specific reference to hyphens in date range disambiguators is here though it doesn't make mention of the why. No matter, the issue is with Wikipedia's MOS and cite DNB.

—Trappist the monk (talk) 12:18, 9 October 2013 (UTC)

The discussion will be at Wikisource talk:WikiProject DNB or its archives. I will have a look at the template at the other place, and box ears if necessary. — billinghurst sDrewth 13:25, 9 October 2013 (UTC)

I have left a note on the script asking for fixes. Their MOSDAB reflects to internal page names and does not say break external links, so we can more state that the script is wrong in its actions. — billinghurst sDrewth 13:34, 9 October 2013 (UTC)

Further

Consensus and proper formatting It seems like there is a kind of consensus that ndashes are proper English for date ranges rather than hyphens? —Justin (koavf)❤T☮C☺M☯ 04:34, 20 July 2014 (UTC)

Replicate the work is the internal requirement, so it is not exclusively en dashes. Consistency through a work is the requirement, and generally people have preferred en dashes. For works and author page titles we have used hyphens, not en dashes, though redirects are generally done to cover the mix. — billinghurst sDrewth

@Billinghurst: But why use hyphens when ndashes are appropriate (other than possibly preserving original orthography)? As you pointed out, redirects fix this problem, so there is never a need for the incorrect format of Author:John Smith (1982-2014), since it can redirect to the proper Author:John Smith (1982–2014). —Justin (koavf)❤T☮C☺M☯ 00:10, 24 July 2014 (UTC)

Because creating and maintaining an entire army of redirects for something because it was arbitrarily decided to be "correct" for titles is a ridiculous waste of time and resources. When people are typing something in, the endash is not on the keyboard and requires extra effort to produce. It makes far more sense on Wikisource to eliminate all that extra unnecessary work for both users and editors by deciding that a regular dash is "correct" for titles. --EncycloPetey (talk) 02:17, 24 July 2014 (UTC)

Indentation

Again, not that I have a dog in this fight, but Beeswaxcandle's recent edit inserting

Paragraph spacing. Between paragraphs there should be a single blank line (obtained by using two line returns) and the first line of each paragraph is not indented. If sections of a text unit are separated by wider paragraph breaks, then use a double blank line (obtained by using three line returns).

seems in all respects a mistake given that it forgets the necessary caveats and in all its helpful formats was already covered by

Page layout should mimic the original page layout within limits, but avoid unnecessary complexity that makes the text difficult to edit or read. A Wikisource page does not usually correspond directly to a printed page, but rather to an article, chapter, or section.

There is no call for or general consensus on nixing indentation in all cases, as implied by the new wording; similarly, afaik, there's no general consensus that three lines is the mandatory cut off when making larger text divisions. — LlywelynII 16:28, 27 August 2014 (UTC)

Actually, there is general consensus here on this point. There has been general consensus for years. If you disagree, you are free to try to change peoples' minds, but to deny the existence of consensus is unhelpful. Hesperian 00:44, 28 August 2014 (UTC)

... and because there is a general consensus, and you were highlighting that it was not explicit, the addition was made to make it explicit. The convention was around when I joined in 2007, and I remember a general conversation about that and similar conventions then or 2008 in WS:S. If you check the archives for those pages I am sure that you will find it. — billinghurst sDrewth 02:11, 28 August 2014 (UTC)

Also, as I have mentioned on your talk page, if you want indented paragraphs, then that can be set for works to display that way for you within Special:MyPage/common.css. One of the things that we are trying to achieve is to not overly enforce formatting, and to allow people's viewing preference to come into play. So our font-size changes are proportional, rather than set; our right width is unset; font-face is left to the browser of the user; use of width is limited, etc.— billinghurst sDrewth 02:33, 28 August 2014 (UTC)

Italics and quotes in bibliographies

The Chicago Manual of Style says: "When quoted in text or listed in a bibliography, titles of books, journals, plays, and other freestanding works are italicized; titles of articles, chapters, and other shorter works are set in roman and enclosed in quotation marks." That is the convention that is mostly but not universally used at WS (viz. Author: pages) but I cannot see that it is specifically referenced anywhere, or have I missed it? Moondyne (talk) 00:55, 15 October 2014 (UTC)

Help:Author pages implies through its examples that the titles of works should be italicized, but I don't think I've ever seen an explicit statement advocating any particular style. --EncycloPetey (talk) 02:21, 15 October 2014 (UTC)

Thanks. Use of quotes for poems, shorter works and articles within a work was my main point. Moondyne (talk) 02:33, 15 October 2014 (UTC)

Curly/straight quotes

I'd like to revisit this. Hope it's okay that I'm starting a new thread instead of necro'ing the old one... as a newcomer here, it seems strange to me that so much work is being put into matching the original typography and layout, except where the quote characters are concerned. The straight quotes thing is the main reason I don't don't download ePubs from here. Can it be at least made optional to encode texts with proper quote marks (and apostrophes as well)? Or maybe use the <q> tag so that people can define their preference in their stylesheet?--Chowbok (talk) 18:41, 11 December 2014 (UTC)

It's not set in stone that one shouldn’t use curly quotes. Their usage should be consistent within works, but if people want to use them I think they generally do. I agree that they often look better; they are, however, a bit of a pain to enter! :) (The SpecialChars.js gadget is pretty cool, but one still must re-type each character.) — Sam Wilson ( Talk • Contribs ) … 23:16, 11 December 2014 (UTC)

Well, I've tried to use them and been reverted twice and scolded once, so I don't think that's the case...--Chowbok (talk) 23:27, 11 December 2014 (UTC)

Is "so much" work really being put in when double spacing and justification or lack thereof are not respected? (See pages of Index:US Senate Report on CIA Detention Interrogation Program.pdf.) Ekips39 (talk) 23:44, 11 December 2014 (UTC)

@Chowbok: Hm, yes it seems that I might be mistaken as to the level to which curly quotes are accepted. But there was a work not long ago that specifically requested that contributors use 'em; I can't for the life of me find it now though, sorry.

@Ekips39: I'm not really sure what you're saying? That curly quotes are less work than straight ones? I think double spacing and paragraph justification are things best 'normalised', just as we normalise font size or page margins (they can be changed by custom stylesheets anyway). Quotes are different. — Sam Wilson ( Talk • Contribs ) … 01:09, 12 December 2014 (UTC)

Curly quotes create technical problems and should be avoided. --EncycloPetey (talk) 02:15, 12 December 2014 (UTC)

Can you elaborate? What kind of technical problems? --Chowbok (talk) 03:46, 12 December 2014 (UTC)

Well, for one, the don't render universally in browsers. The last time I used the University of California library computers (not so long ago), anything with curly quotes rendered as little boxes instead. Also, when I've seen them used here, they're frequently done incorrectly. Add to that the fact that they require extra work to insert, and there's really a weight of reasons not to use them, and "I think they look pretty" as the only positive reason. I know that you think we try to preserve the typography, but there are myriad ways in which we do not do that, and deliberately so; there are many details in which an on-line medium such as Wikisource cannot and should not try to reproduce 19th century book typography. Curly quotes is but one of the items on that list. --EncycloPetey (talk) 06:57, 12 December 2014 (UTC)

I don't know how long ago you went to that library or what browsers they were using, but I say unequivocally that every browser in use today supports them. I defy anyone to show me one that doesn't. The "extra work" argument doesn't hold weight either, if I'm willing to do the extra work. I'm not saying to require them, just to allow them. Finally, left and right quotes aren't some quaint outdated convention but the standard in use in all printed matter to this day. None of your reasons hold water.--Chowbok (talk) 07:07, 12 December 2014 (UTC)

You are incorrect. Now, perhaps every most recent update of every browser supports them, but most schools and universities lack both the money and manpower to update browsers or operating systems, even in the US. So, you are simply flat-out wrong about this. --EncycloPetey (talk) 14:57, 12 December 2014 (UTC)

{{Citation needed}}. I don't think policy should be based on your gut feeling of what's supported, especially when it'd be so easy to verify one way or the other.--Chowbok (talk) 18:32, 12 December 2014 (UTC)

And just to be extra sure, I just loaded one of our pages in IE 5 under Windows 98, which is 15 years old. The layout is completely garbled, which means nobody could use Wikisource with it anyway--but the quote marks display perfectly. So I'm afraid you're simply incorrect.Chowbok (talk) 18:44, 12 December 2014 (UTC)

Actually, you're both right. Browsers whether old or modern use the fonts that are available on the particular computer. Websites don't dictate a particular font, rather a font family and if the font that the browser is using has the curly quote glyphs it will display them. If it doesn't, it will display the "dummy" character. This adds another reason for our default norm of straight quotation marks, we cannot assume that every reader of the works we host will have UTF-8 fonts in the various styles (serif, san-serif, display, gothic, etc.) that have all five of the curly quotation marks (incl. the separate glyph for apostrophes). Beeswaxcandle (talk) 19:06, 12 December 2014 (UTC)

This was a default Windows 98 install. No custom fonts were added. I can't believe that there's a single font in use today that doesn't have curly quotes. Again, if you have examples, I'll correct myself. But IMO we're chasing phantoms here.Chowbok (talk) 19:24, 12 December 2014 (UTC)

I was replying to Chowbok's statement that "so much work is being put into matching the original typography and layout, except where the quote characters are concerned" and pointing out that no effort was being made to match spacing and justification, and as such I didn't see how that argument led to the conclusion that we should allow for curly quotes. Curly quotes are definitely more work than straight ones unless your autocorrect makes them curly. I don't have an opinion on what we should do in relation to any of these points. Ekips39 (talk) 06:36, 12 December 2014 (UTC)

Ah, yes I see! Sorry, I should've read more carefully. You're right in what you say. I'm going to stick to straight quotes... :) — Sam Wilson ( Talk • Contribs ) … 06:48, 12 December 2014 (UTC)

• This is a Style Guide that indicates a group of norms that the community has agreed on over the 11 years we have been in existance. If there is doubt about to proceed in a situation, it is something we can point to as a standardised way of doing things. It is not intended to be a rigid set of rules that will never be deviated from. If, for a particular work, there is a good reason to deviate from the agreed norm, then we do that with appropriate documentation on the Index talk page. The most important thing is consistency within a work—whether that be the single page of the Treaty of Waitangi or the entire 70 volumes of the DNB.

  With respect to the straight vs curly quotation marks issue, the agreed norm is to use straight marks. The underlying reason for this is the inability to type curly quotes directly from a standard keyboard in a Windows OS, but they can be typed in any of the Apple OS. Without the guideline in the Style Guide we would then risk having a mixture of curly and straight quotation marks in a work. That said, if the editors who join together on a particular work decide between them to use curly quotation marks, then that is allowed and is the norm for that work. "Fly-by" editors should not go against the consensus for that work. Beeswaxcandle (talk) 08:10, 12 December 2014 (UTC)

  • Sounds to me then, that with the projects I initiated and that I'm doing all the proofreading on, I should get to determine the style. Am I reading you correctly?--Chowbok (talk) 18:32, 12 December 2014 (UTC)

    In a nutshell - yes. As long as you make note of the intended styling you wish to practice throughout the work at the outset, there is no real reason not to follow your lead. At the same time, fair warning - such "deviations" may one day in the very future of supposed development result in any number of "issues" not apparent in today's build (e.g. reinsertion of proofread text back into source files or xml generation of embedded text layers and the like might not account for UTF-8 and/or the use of such rich text like punctuation for example).

    I'll worry about such nuances when they happen (thhffftt... not likely imho). If such miracles do take place one day, please note; a bot will come through and "undo" what is needed at that point anyway. -- George Orwell III (talk) 03:13, 13 December 2014 (UTC)

    The style guide is not absolute, and allows for some variation. That said, there needs to be good reason to deviate, and it is not whim. There are good reasons that the community has arrived at the style guide, and some things are not particularly negotiable in a standard work. The reason that the style guide is not absolute is that certain works are formatted particularly as a look by the author, so to disregard that is inappropriate when rerendering an author's work. If parts of the work reproduction are simply typographic, then the requirement is not there to retain them. So in answer to the original question, no, I don't think that it is time to revisit that component of the guide. — billinghurst sDrewth 11:33, 13 December 2014 (UTC)

The main argument against curly quotes seems to be that they're difficult or annoying to enter. But Wikisource is different than other projects in that once the text is accurate to the material, there isn't any need to alter the text again. It's even mentioned in Wikisource:Featured texts that once a work reaches featured status, "the work should be locked to protect its integrity". So if someone wants to go to the trouble of using curly quotes to match the source material, why is that a problem when the text is unlikely to be modified again?

The reason I bring this up is because I noticed someone being admonished (User talk:RaboKarbakian) for using them in a work they started (Index:Pilgrims Progress-1896.djvu) by using this style guide as justification. I've been using curly quotes also for works I've started (and other works that were already using them) because I assumed this was just a general guideline that didn't need to be strictly followed as some of the other comments here suggest that it's up to the person who started the work. I'm guessing I just flew under the radar. But what's funny is that there are featured texts that are using curly quotes and apostrophes ([1] [2] [3] [4]). And even the Main Page has been using a curly apostrophe since 2011. So either this style guide needs to be changed, or shouldn't be strictly enforced against other users, or existing text should be fixed to match the style guide. Right?

Another point mentioned was that old browsers and operating system fonts don't support curly quotes, though that comment was 4 years ago and it was never mentioned which operating system they were using. But old browsers are always falling out of support because of changing standards (does anyone know if MediaWiki has a list of old browsers they support). And if there are still browsers that have trouble with curly quotes, then what other Unicode characters do they have trouble with? Should we avoid those also? But I'm guessing it's not a serious problem because they're being used already in various places like the Wikimedia Foundation home page and the Terms of Use that's linked to whenever you contribute to this site and the main page and featured texts that I mentioned before. --Riley AJ (talk) 05:17, 23 December 2018 (UTC)

Re: "The main argument against curly quotes seems to be that they're difficult or annoying to enter", no that's an underlying reason (per text above). We've been through this issue many, many times in many, many places. If you wish to rebutt the previous lines of argument, you'll need to comb through multiple namespaces over the past 6 years at least.

Re: RaboKarbakian: It is more than just using curly quotes in his case. If you wish to discuss his admonishment, I suggest a separate thread in a different venue as it is more complex than simple straight vs. curly quotes as most people would understand the issue.

Re: Featured texts. If you look at the dates when those texts attained Featured status, most are from 2007–2008, which is a very long time ago in wiki-terms. Standards for FT have changed.

If you do wish to revisit the issue of quote style, the Scriptorium is the proper venue these days. Adding new text to a four-year old discussion is less likely to gain notice from the community, and this would need a full-community discussion in a prominent place. --EncycloPetey (talk) 05:36, 23 December 2018 (UTC)

Title pages/color?

for Pages such as this one, which is black text on a red hardcover book, should there be a red box surrounding the text? I know that wikisource is meant to match the books style wherever possible, but this doesn't seem to have been addressed anywhere in the style guide. if the color is set to dark red, then the page is much too hard to read.--Legofan94 (talk) 15:29, 20 January 2016 (UTC)

My two cents: I don't usually transclude book covers unless they are adorned with interesting/notable illustrations, in which case I transclude the actual image of the cover as opposed to replicating it (that is, if a quality image is available). Since this particular work doesn't contain a suitable title page to serve as front matter in the Main, I would merely transcribe the text in black and not worry about color. Londonjackbooks (talk) 16:25, 20 January 2016 (UTC)

I agree. When there is some particular illustration or artwork associated with the cover, or some significant design element, then that is work reproducing. But simple text on a solid color cover is usually not worth the effort. --EncycloPetey (talk) 03:18, 21 January 2016 (UTC)

Linking "q.v." references

I have seen in Encyclopaedia Britannica and a few other sources text saying something like "Isaac (q.v.)" in the article on Abraham. Would it be appropriate to add a link to the topic indicated (in this case, the article on Isaac at the word Isaac) in such cases? John Carter (talk) 18:41, 16 June 2016 (UTC)

Definitely. These are EB's internal links, and we should be hyperlinking them for user convenience. I also think they are the only internal hyperlinks we should be adding. However, this view has been contentious; see previous discussion here and here. Hesperian 00:37, 17 June 2016 (UTC)

Formatting of editorial comments

How should the following page be formatted. A scanned label covers some text and I want to point this out to the reader.

https://wikisource.org/wiki/Page:The_Supreme_Court_of_Judicature_Act_1873_and_1875.djvu/2

(Talpedia (talk) 00:01, 13 October 2016 (UTC))

Wikisource continues to discuss issue such as this. The page that summarizes current thoughts and approaches is Help:Annotating, but it may not provide a completely satisfactory solution for this particular situation. --EncycloPetey (talk) 00:36, 13 October 2016 (UTC)

If you do not what it says, you can use {{illegible}}, if you do know what it says, then type it in, and use an html comment to quote your source. html comment = <!-- comment here --> — billinghurst sDrewth 01:32, 13 October 2016 (UTC)

Page titles — reverted edit

I have reverted the edit that said that "title case" is preferred, as I do not believe that there is that consensus from the community. The common accepted form, as I understand librarians use at this time, is the sentence case. Personally I am agnostic on the matter and believe we can state that both ways are acceptable, as in the end it matters not, and I much prefer correctly worded titles, rather than those manufactured on a whim. — billinghurst sDrewth 15:02, 23 July 2017 (UTC)

My change was based on common usage; sentence case for titles is extremely rare and frequently results in argument and controversy. —Beleg Tâl (talk) 11:58, 24 July 2017 (UTC)

Commons usage is common usage, and if it is happening that way then it is okay. If it is resulting in argument or controversy it is then a matter of saying that title cases or sentence case are both acceptable, and if one exists and you want the other, then create a redirect for the missing type.

I feel that text with specific meaning that has been in place for greater than 10 years is worthy of discussing rather than unilateral change. — billinghurst sDrewth 14:28, 24 July 2017 (UTC)

@Beleg Tâl: Although my own preference is for title case, that is because most of the works I've done are books or plays and have short titles. But there are times where I have done other sorts of works, such as poems or journal articles, and for those sorts of works sentence case makes more sense. So, although you might perceive a trend towards title case, is that not a reflection of the kinds of works most often being completed recently? If we had more poetry and more journal articles, we might see a bias in the other direction. And even for some older books, with excessively long titles, sentence case makes the better choice. So I agree with billinghurst that both sorts of titles are in use and both are acceptable. --EncycloPetey (talk) 15:58, 24 July 2017 (UTC)

Fwiw, of course we should use title case for the titles of works. It's right there in the title. Fine to link from sentence case. — LlywelynII 19:20, 5 March 2019 (UTC)

Titles of compiled works

I suggest a change in Wikisource:Style guide#Page titles, number 2, second bullet, as follows: When a work is a collection (e.g. poetry) or a compiled work (e.g. a journal or almanac), then the subpages are works in their own right, and the original title of the work should be used in the subpage title.

The reason for the change was discussed at my talk page. --Jan Kameníček (talk) 08:48, 27 September 2018 (UTC)

hws/hwe

The page states "If there is a dash at the end of a page (or at the beginning of a page) in the Page namespace, an undesired space is added to the right (or left) of the dash after transclusion. The only currently available solution is to use templates hyphenated word start (and hyphenated word end at the beginning of the following page) or linkable phrase start (and linkable phrase end at the beginning of the following page) as a workaround." but the page for hws says that it's no longer necessary. Should this be changed? Pelirojopajaro (talk) 06:15, 25 April 2019 (UTC)

Yes, and no. There are still situations where it's required, but using it doesn't hurt anything. --EncycloPetey (talk) 13:32, 25 April 2019 (UTC)

What needs to be changed are the statements that "an undesired space is added" and that it is "the only available solution", which are no longer true. --Jan Kameníček (talk) 14:08, 25 April 2019 (UTC)

Title pages & responsive design

I'm not aware of any specific guideline for transcribing and formatting title pages. For what I see, the common practice is to mimic the layout of the printed page as close as possible. In my opinion a more thoughtful approach would be needed:

• Font sizes should be proportionally scaled with reference to the body font size. Indeed, mimicing the font sizes as seen in the preview of the scanned page is superficial, because the dimension of the preview is generally quite different from the dimension of the physical page, which is most often unknown, and also because the e-book will be displayed on screens that could be quite smaller than the physical page. For these reasons and also for the sake of uniformity, it is required to set the font size of the body to the default font size of Wikisource. It clearly follows that other font sizes should be proportionally scaled with reference to the body font size.
• Non-semantic line breaks shouldn't be transcribed, because they can cause a mess on small viewports and, indeed, they aren't semantic.
• Very large vertical spacings should be transcribed as "normally sized" vertical spacings, because otherwise they degrade the layout on small viewports (see figure) and because their size isn't semantic.

Very large vertical spacings

"Normally sized" vertical spacings

Title page of Reflections on War and Death rendered on Books for iPhone

What do you think about it? —Esponenziale (talk) 17:49, 1 May 2019 (UTC)

This lies outside the current scope of the Style Guide, which consists of the broadest points in style. What you are proposing sounds like the start of an essay or recommendation of "best practices" for a very specific subset of what we do - the title page or the first visible page of a transcribed text. Note: The title page is not always the first page visible to a reader. For some works it is the cover, an image (cove or frontispiece), and the title page may be the second, third, or even fourth item visible to a reader. There is a lot of latitude given to editors in the set-up of the works they transcribe. --EncycloPetey (talk) 18:15, 1 May 2019 (UTC)

I agree in giving the maximum leeway to editors, but I also find that best practices are very helpful. Smartphones have revolutionised web fruition and web design. Currently they accounts for 19% of visits to Wikisource main page (pageview analytics). It is possible that most editors are not fully aware of this. —Esponenziale (talk) 21:54, 1 May 2019 (UTC)

"Smartphone" and "mobile web" are not the same thing. The statistics show mobile web access of the main page. --EncycloPetey (talk) 22:26, 1 May 2019 (UTC)

A comment (if you will permit) from the floor: Only a complete idiot designs for an evolving target (especially a target where one does not know where it will be in (say) ten years time!) If one constrains one's title pages on the basis of what the best technology of today can handle… one takes upon oneself the risk that one may look quite antiquated in a year's time; let alone quite silly for the subsequent nine years… and beyond?

The question one ought to be asking is: does one wish to remain faithful to a deathless publication versus trendy for a month or so? 114.73.168.91 02:47, 2 May 2019 (UTC)

Removal of non-semantic line breaks is already part of our process, and I agree that it should be part of our style guidelines. Regarding a "best practice for title pages", perhaps this can be accomplished by fleshing out Help:Front matter and making it more integrated with the rest of our guidelines? —Beleg Tâl (talk) 12:58, 2 May 2019 (UTC)

Are you suggesting we put information on the Help pages or expand our Style Guide? Nothing in the Help namespace is part of the style guide, but is simply "collected wisdom". --EncycloPetey (talk) 15:05, 2 May 2019 (UTC)

I am suggesting we put the line breaks item in the style guide, and that we put the "best practices" essay you suggested along with the other two original proposals in the Help pages. —Beleg Tâl (talk) 16:37, 2 May 2019 (UTC)

How would you word the line breaks item so that it precludes poetry, drama, and other forms where semantics is not the only reason for a line break? And how would we apply this principle to title pages where there is a very definite layout, including graphical elements? How would you apply this principle to Connie Morgan with the Mounted, or An Essay on Virgil's Æneid, or Hymns for the Coronation of His Majesty King Edward VII, where there are not only nonsemantic line breaks in the title, but changes in font size and font face as well? More challenging still, how would we handle The Present State of Peru with only nonsemantic line breaks? I don't see how we can implement such a principle as part of the Style Guide. --EncycloPetey (talk) 17:00, 2 May 2019 (UTC)

That's not what I meant. I clearly misunderstood the original suggestion. I understood "not semantic" as meaning "not-deliberate" - that is to say, line wraps that are artifacts of the display/medium rather than the decision of the author or publisher. In general, we all consider things like this to be unacceptable, yet there is no mention of this convention in the style guide at all, and some new editors mistakenly preserve them. That is what I think should be added to the style guide. With regard to title pages in particular, have a look at Page:An account of a savage girl.djvu/7 and Page:LostApocryphaOfTheOldTestamentMRJames.djvu/7; you will see which lines are preserved and which ones were removed as not-deliberate. —Beleg Tâl (talk) 18:36, 2 May 2019 (UTC)

I agree, this is what I originally meant as well.. —Esponenziale (talk) 18:45, 2 May 2019 (UTC)

I apologize for my lack of clarity: semantic is used by web developers, possibly with too much flexibility, to identify the elements of the layout that have "some meaning" and therefore can be considered part of the content. These are lists, paragraph, titles, some breaks (not every one), etc. —Esponenziale (talk) 19:34, 2 May 2019 (UTC)

I disagree as I think that line breaks at title pages are always deliberate. Publishers carefully decide on the size of font, letter-spacing, word-spacing and so on to achieve exactly the layout they want. Wrapping the title at the above mentioned Page:LostApocryphaOfTheOldTestamentMRJames.djvu/7 is imo completely wrong. Notice that the publisher not only broke the line of the title, but also slightly adjusted the word-spacing so that the lines were justified. Wrapping the lines destroys this layout and the result looks awful. --Jan Kameníček (talk) 18:53, 2 May 2019 (UTC)

What I do agree with is wrapping the lines in poems as shown above. --Jan Kameníček (talk) 18:58, 2 May 2019 (UTC)

"Semantic" and "nonsemantic" have so many meanings, and are so broadly defined terms in terms of coding alone, that it would require a lengthy essay simply to explain one person's concept of what falls within and what falls outside of the scope of the term. Nothing so broadly defined could be placed into the Style Guide, but an essay offering advice on best practices and offering opinions could be written. There will be at least as many exceptions as there will be applications. --EncycloPetey (talk) 19:46, 2 May 2019 (UTC).

Yes line breaks in the titles and also vertical spacings have been deliberately chosen by the publisher, which had to choose how to fit the contents in a page of a given fixed size. Unfortunately, when a screen is smaller than the original page these type of features can't be replicated, unless the page as a whole is scaled proportionally to the viewport (that is, if we copy the entire page as an image), but then the text often turn out to be unreadable. Since these features have no meaning or artistic value, neglecting them is a very low price to pay to have in turn an adaptation that is highly faithful to the original and perfectly readable independently of the device one's using.—Esponenziale (talk) 22:51, 2 May 2019 (UTC)

But judgments about "meaning" and "artistic value" are highly subjective. And there is still the question of how much this is worth bothering about. How many people will read Moby-Dick on an iPhone? What about works where we make the title page fit the little screen, but the work itself won't do so because poetical lines wrap? All we have right now is information about Main Page views, which is not enough to shape policy, as far as I'm concerned. --EncycloPetey (talk) 00:24, 3 May 2019 (UTC)

Even if we wrapped some of the lines of title pages (those assumed by somebody not to be "deliberate"), others would still stay unwrapped and so the problem of small devices stays unsolved anyway. I do not think it is contributors of Wikisource who should bother about it, it is the task for programmers to give different choices of view to desktop and mobile users and to prepare e.g. some templates displaying line breaks differently on different devices. We should not adapt our behaviour to imperfect software, it is the software that should be adapted. --Jan Kameníček (talk) 06:31, 3 May 2019 (UTC)

Please back this argument up for a moment. The ProofreadPage extension as utilised by WikiSource encourages verified faithful transcriptions may be made page-by-page. And the easiest means of verifying the proofreading of another transcriber is if the page layout is also as close as reasonable to the layout exhibited by the published composition of the original scanned page.

So far so good. Then when the results of these efforts is transcluded back into a work one can be fairly assured the resulting text will reflect that intended by the original author (publication errata notwithstanding.) In some respects it is an unintended consequence of the process that at this point the publisher's formatting is also incorporated as what is really wanted is the textual content alone.

Unfortunately it is only at or beyond this stage that semantic transformation is appropriate but by this point in the process the typical WikiSourcer feels they have done enough and the work lies dormant after finally being tagged as "Done."

And then somebody comes along wanting to read the verified work on a mobile device; or a Kindle; or via any number of browsers (any Lynx users still out there?); or whatever… and finds to their frustration that the output does not look just perfect on an untested, arbitrary platform. This is above and beyond the scope of any wiki-anything Style Guide. It is surely an issue for the browser to handle HTML-to-screen rendering; or the various Download as PDF/EPUB/MOBI adaptor applications to perform reasonable translations. I fear this matter is better couched in terms for use in Phabricator reports to improve the above utilities, rather than mangling vertical whitespace in a hopeless attempt to appease the unforgiving mobile-browser gods…

The Style Guide should be limited to giving guidelines compatible with producing sufficiently simple HTML amenable to rendering on as many desktop and mobile browsers as possible, and also with the Download utility family. Anything more is not going to stand the test of time as the consuming platforms of the coming decade will have characteristics we cannot currently even anticipate. That is the nature of innovation. 114.73.168.91 10:15, 3 May 2019 (UTC)

The problem of separating content and presentation is not new: it has been extensively dealt with in close relation to responsive web design. I guess that here we've been reenacting the process. To solve the problem of the screen size, the presentation should change depending on the screen size, but the content should remain the same, independently of the screen size. HTML5 specification clarifies that HTML code should represent all the content, including all semantic layout features, while the CSS code should take care of all the presentation.

Indeed, the HTML5 specification says that "<br> elements must be used only for line breaks that are actually part of the content, as in poems or addresses." (HTML 5.3: 4.5.29. The br element), which safely means that any break in our titles is just presentation stuff that shouldn't be represented with <br>.

So: any semantic layout feature should be preserved in our transcriptions for sure, what about presentation features? I think that they should be preserved as much as possible, and they shouldn't be preserved if they end up disrupting the layout on a notable number of devices. Therefore we should discard "presentational" line breaks, because CSS3 doesn't allow to set breaks depending on the viewport width, and leaving them there ends up disrupting the layout on small screens. Large vertical spacings as well can't be conveniently sized as function of the vertical space available and therefore should be discarded as well.

How many devices are we talking about? E-book readers are often smaller than the pages of the original books and, in any case, they're most often used with bigger font sizes than the original works (which cause an identical problem for the layout).

Better statistics about Wikisource usage from mobile can be found in the topview analysis (if you don't see the last column, that is "% Mobile", try to enlarge or shrink the window... Yeah talking about responsive design...). —Esponenziale (talk) 21:31, 3 May 2019 (UTC)

Template naming convenitions.. And Table Class sub-pages...

Proposal:

"

Templates should be given an unambiguous name as to their intended function.

If there are different versions of a template to accommodate span based, block based and split versions, then these should be named {{foo}}, {{foo block}}, {{foo block/s}} {{foo block/e}} (for the opening and closing pair respectively), should the opening tag require a different formatting on proceeding pages then Template:Foo block/c should be used.

If different versions of a template exist to accommodate left-hand or right hand versions then the pairing Template:Foo left, Template:Foo right should be used for the base name. ( foo/l and foo/r have also been used.)"

Proposal: (Could be on the documentation for {{ Table class}} if not suitable for here)

" Sub pages of {{table class}} should ideally use a descriptive name for generic stylesheets likely to see wider use.

• Where a table class relates to a specfic table, then the page name should be the PAGEID of the Page: where the first part of the table occurs.

• CSS "class" names should be unique with an entire Index: (or likely range of transcluded pages.).
  • For generic stylesheets an appropriate name prefixed with 2 underscores (example "__foo") should be used.
  • For specfic stylesheets (likely to be used for a single specfic table) should use the numeric pageid of the Page: in which the table starts, prefixed by two underscores.

" ShakespeareFan00 (talk) 20:16, 10 May 2020 (UTC)

Chapters

I came across some public domain book translations. How do I format the Table of Contents and the individual chapters? 2603:7000:D03A:5895:A978:F848:5AD2:920A 14:01, 5 November 2023 (UTC)

The best start is to download the scans of the translated books to Commons and then to create the index page enabling to proofread the individual pages. For details see Help:Proofreading. After all the pages are proofread, we transclude the whole work to the main namespace. We usually try to format all the pages in ways resembling the originals. As for the table of contents, there are several ways how to do it, one of them is using templates {{TOC begin}} and {{TOC end}}, with various TOC row templates between them, see the documentation of the mentioned templates. You will always find help in any phase of the process when needed, just do not hesitate and ask e. g. at Wikisource:Scriptorium/Help. --Jan Kameníček (talk) 16:27, 5 November 2023 (UTC)

Chapter names

Greetings! I'm working on The Cloud of Unknowing whose chapters are named First Chapter: Of four degrees of Christian men's living; and of the course of his calling that this book was made unto, Second Chapter: A short stirring to meekness, and to the work of this book, etc. The style guide is at best ambiguous and at worst contradictory about how to handle such chapter names. It says:

Works that have chapters/sections should be numbered, not named (eg. use [[/Chapter 1/]] and not [[/The Dog Returns/]]). The section name should reflect those in the original work (Chapter 2, Act 2, et cetera). Subpage titles such as [[/Preface/]] and [[/Appendix/]] are fine though.

It's clear that the first chapter's subpage should not be named Of four degrees of Christian men's living; and of the course of his calling that this book was made unto. But should I keep the names First Chapter and Second Chapter, following the guideline to reflect the original work, or convert them to Chapter 1 and Chapter 2, following the guideline to emphasize the numbering? Furthermore, if the preference is to emphasize numbers, does that also mean that chapters with Roman numerals such as Chapter I and Chapter II should be converted to Chapter 1 and Chapter 2 in the page names? —Remember the dot ^(talk) 15:02, 21 July 2024 (UTC)

The point is that, if the work is divided into chapters, use chapters; into acts, then use acts; likewise sections, books, or whatever unit. Notice that none of the examples advocate for numbering with words. And yes, Arabic numerals are preferred over Roman for page names. --EncycloPetey (talk) 16:50, 21 July 2024 (UTC)

That's fine by me, it just needs to be made more clear because it's not obvious to newcomers. Would you please update the style guide to say that ordinal numbers and Roman numerals are to be replaced with Arabic numerals in subpage names? —Remember the dot ^(talk) 18:30, 21 July 2024 (UTC)

Such an update to the Style Guide would require a community discussion and consensus, as this is one of our two core documents. --EncycloPetey (talk) 02:41, 22 July 2024 (UTC)

This is already covered in the linked Help:Subpages in the section in the Style Guide. Beeswaxcandle (talk) 03:00, 22 July 2024 (UTC)

Thanks for pointing that out. Help:Subpages#Chapters and sections does cover Roman numerals. However, the phrase "when such a numbering scheme exists in the original work" could easily be taken to mean that the policy only applies to works that originally used plain Arabic or Roman numerals, not ordinal numbers or numbers as words, which are not mentioned. Could we add a few words to that page to clarify?

Alternatively, if there is no consensus to write such a rule down on a policy or guideline page that can be shared with newbies, maybe we shouldn't be treating it as policy. In my case, I contributed to Wikisource quite a bit in the 2000's, and it's a bit jarring to be told that practices that were previously fine are no longer acceptable. The new policies aren't bad, it would just save a lot of confusion if there were better documentation of the current expectations and better communication of where to find that documentation. —Remember the dot ^(talk) 03:11, 23 July 2024 (UTC)

I do agree with this, and as such I have posted a proposal at WS:S#Slight modification of WS:MOS regarding chapter numbering —Beleg Tâl (talk) 13:42, 23 July 2024 (UTC)

What is the status of the style guide?

Over on Wikisource:Scriptorium, I recently requested permission to use a bot to help mass-change ſ to {{ls}} in one 1706 book. I was met with a bunch of arguments about whether I should be swapping ſ to {{ls}} in the first place. I was baffled by this, since Wikisource:Style guide/Orthography#Phonetically equivalent archaic letter form which explicitly says to use {{ls}}.

So is the Style Guide, like... actual site rules? If it is, then I think many people on this site need to be reminded of that. If it's not, then it needs maybe a header at the top or something, saying, "This isn't actually a rule or guide, don't take it at face value," so that new users know what the deal is. If this is an issue about {{ls}} specifically, and not the style guide as a whole, then maybe the bit about that needs rewriting? Eievie (talk) 00:33, 14 November 2024 (UTC)

The hat note at the top of the Style Guide best expresses what it is. It is a a set of norms to be followed. If there is a cogent reason to break the norms on a particular work, then that's okay—but that reason needs to be documented (on the Index Talk: page). Beeswaxcandle (talk) 05:46, 14 November 2024 (UTC)

It should be also noted that besides the written norms we also follow the so called "common practice". So before making any really extensive and widespread changes which influence hundreds or more Wikisource pages it is usually good to ask about it e.g. at Scriptorium. --Jan Kameníček (talk) 10:40, 14 November 2024 (UTC)

In the Scriptorium conversation, someone said, "the issue of {{ls}} versus ſ, it is a quite contentious issue in the enWS community. It would be better not to fuel that flame." What I'm hearing here is that it would be appropriate to push back against that? To say something along the lines of, "If ſ-vs-{{ls}} really is as contentious as claimed, this should be taken up with the style guide, rather than with me. If there's a reason this specific work should be an exception, that's ok, but ignoring the style guide as a matter of course is not."? Eievie (talk) 21:34, 14 November 2024 (UTC)

It is a general problem in Wikisource, that the community is quite small and so it is difficult to find people who would be willing to update various policies and written rules whenever needed, and so it has been established that not only written rules but also the common practice is taken very seriously. Yes, I admit that this is confusing for new editors.

As for the long s, I personally do support using {{ls}} but at the same time I know there has always been some opposition. It has been added to Wikisource:Style guide/Orthography ages ago (in 2011) and I did not find any relevant community discussion that would actually approve it. The last discussion on this topic that I found took place in 2021 when some contributor suggested bot replacements but the request was not approved by community consensus. Having this discussion result, no major replacements should be done until we reach a different result. If you wish, you can start such a discussion. --Jan Kameníček (talk) 22:23, 14 November 2024 (UTC)