Wikisource talk:Style guide

From Wikisource
Jump to: navigation, search
Style guide (talk page)

Disambiguation guidelines[edit]

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[edit]

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? --Spangineerwp (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? --Spangineerwp (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)

Text formatting[edit]

What kind of formatting is generally permissible? For example, what about converting "--" to "—" and making ellipsis spacing consistent? --Spangineerwp (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 ( TalkContribs ) … 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:—. —Spangineerwp (háblame) 13:40, 23 September 2010 (UTC)

Naming and translated works[edit]

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' (ſ)[edit]

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 ( TalkContribs ) … 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 ( TalkContribs ) … 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[edit]

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 ( TalkContribs ) … 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 ( TalkContribs ) … 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[edit]

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 ...[edit]

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[edit]

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[edit]

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 ( TalkContribs ) … 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 ( TalkContribs ) … 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. Inductiveloadtalk/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[edit]

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 ( TalkContribs ) … 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[edit]

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)TCM 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)TCM 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)