UESPWiki talk:Style Guide

Related Discussions
Archived discussions about the Style Guide
Archived discussions about Content Policy
Discussion subpages
NPC Layout
Place Layout
Quest Layout
Page Archives
Archive 1: Oct 2005–Feb 2007

Any discussion of the styles to be used on the site should be done here.

New Sections

I've added to new sections to the style guide, namely Accurate and Verifiable and Unofficial Mods, prompted by multiple discussions on these topics over the last year or so. I've primarily tried to document the consensus from existing discussions and/or the existing practice. However, it's hard to be sure that my synopsis accurately reflects everyone's opinions. And there are a few details that might be unexpected, as documented in the following subsections. Feedback is welcome; until the text has been tweaked to everyone's satisfaction, I've added "proposed" notices to the new text to (hopefully) let readers know that the text has not been finalized. --Nephele^Talk 00:15, 15 January 2008 (EST)

Accurate and Verifiable

These additions have primarily been prompted by several discussions about CS data vs lore data (e.g., Oblivion Talk:Dark Brotherhood#Members Section, User talk:Obliv4PS3#Dark Brotherhood Factions). However, in assembling this information I realized that CS data is not actually considered to be an infallible "gold standard." There are actually several instances where CS data is not correct. Therefore I ended up stating that the most reliable source of data is the in-game console, rather than the CS. The CS is used as a convenient shortcut to obtain the information, but when the CS and the console differ, the console has to date been given precedence. I believe emphasizing that in-game data is ultimately treated as the most authoritative information also addresses the concerns of editors who claim that CS data is not relevant to gameplay. The wiki has not chosen external (CS) data in preference to gameplay data; rather the wiki has chosen one set of gameplay data (verifiable statistics) over another (lore-based information).

The slight de-emphasis of CS data is not meant to discourage its continued widespread use. The CS (or other tools that read the .esm and .esp files) is still the easiest way to extract all of the important information for the site. But I think it's worth occasionally remembering that there are a few limitations to the CS. (N.B., I'm also starting a related discussion at Morrowind talk:Enchant#Enchant points about another instance where CS data is perhaps not the best choice). --Nephele^Talk 00:15, 15 January 2008 (EST)

Unofficial Mods

This section is primarily a very brief synopsis of discussions at UESPWiki:Community Portal/Mod Info in Articles. I didn't want to get into details on the general style guide. However, I thought that a basic statement was necessary. Also, based on the recent example of Daggerfall:AndyFall, it seemed that a clarification regarding the older games would be useful. --Nephele^Talk 00:15, 15 January 2008 (EST)

Perspective

Again, the intent of this section is not to change existing practices. The main reason for adding it is to explain that the perspective used on UESP differs from some other prominent wikis (Wookieepedia for example) where articles are written from the perspective of someone living "in universe" [1]. We have generally adopted a more "out of universe" perspective in our articles, and this has led to confusion with some new editors.

However, I then realized that our Lore articles actually have generally adopted an "in universe" perspective. I thought that highlighting that distinction would perhaps help to refine the purpose of the Tamriel namespace, and provide one answer to frequent questions such as "what's the difference between the Tamriel article and the game article." If the community agrees with this emphasis, there are perhaps tweaks to Tamriel articles that would be appropriate. For example, on Lore:Fighters Guild, the game-specific sections would be kept as would links to the game-specific articles. However, those sections would be reworded to not use "game perspective" keywords such as "quest" or the "player". The sentence "The questline has the player cleaning up the guild and destroying the competition, the dubious Blackwood Company." would be reworded to something more like "The guild faced competition from a dangerous new threat, the Blackwood Company. However, in 3E433 the new guildmaster eliminated the threat by proving that the Blackwood Company was engaging in illegal practices, such as the use of hist sap." Also, these changes wouldn't need to be implemented right away; rather these would just be guidelines to keep in mind when revising Tamriel articles in future.

Reactions? --Nephele^Talk 16:20, 18 January 2008 (EST)

No problems at all with the first two. That seems a good explanation of what we've been doing recently. The Perspective shift is also a good idea. I've tended to write Tamriel articles from that point of view in any case as it always seemed to be the truly encyclopaedia-like part of the site. Apart from anything else, this will avoid irritating shifts in the articles themselves; "The player" or "You" could mean two different things on the same page if it mentioned, say, Arena and Oblivion. The main problem I foresee is that a number of Tamriel articles are transcluded into game pages; care is going to have to be taken to ensure that changing the Tamriel pages doesn't adversely affect the game ones. –Rpeh^{•T•C•E•} 11:44, 19 January 2008 (EST)

(update) I was just wondering about an edit made here. This new perspective idea hadn't been approved so I didn't edit for tone but the thought occurred that a new Cleanup-type template will be needed here. I'm not sure whether it should be the existing Cleanup template or a version of Tone or a whole new thing. Thought I should mention it though. –Rpeh^{•T•C•E•} 18:15, 22 January 2008 (EST)

Quotes

Can I suggest a new guideline on quotes. There's a lot of different styles, but the one we seem to be using most often (at least, in my impression) is the newer style where quotes are treated identically to parentheses and punctuation is grouped accordingly...in other words:

This is a "sample". (period belongs with sentence, not quote, so goes outside)

This is a "sample." (traditional style where punctuation is always inside the quotes)

but

"This is a sample." (whole sentence inside, so punctuation is inside)

Obviously it's hardly a big concern either way, as long as it's reasonably consistent throughout a given page, but I figure if we put a guideline in place, then it's at least a little more likely to be consistent across the site. Any comments from the peanut gallery? :Þ --Robin Hood (Talk • E-mail • Contribs) 14:06, 28 April 2008 (EDT)

Call me a traditionalist, but I much prefer the "old" way, where the punctuation is always inside the quotes. The other way makes sense to me logically, but it just looks...wrong. I always assumed the frequency of punctuation appearing outside of quotes was due to the fact that most people have no idea how to use punctuation correctly ;). But if both ways are technically correct, I suppose I'm open to change. –Eshe^talk 14:16, 28 April 2008 (EDT)

Traditionalist! (Sorry, you asked. :Þ) I'm more of a proponent of the new way, but that's probably because I'm a programmer and unbalanced begin & end punctuation drives me up the wall! I'm usually more of a traditionalist, myself, in almost all other grammar/spelling issues...just not this one. --Robin Hood (Talk • E-mail • Contribs) 14:27, 28 April 2008 (EDT)

By the way, if anybody wants to read more on the confusion that is quotes & punctuation, wikipedia has a pretty good description of where the styles originate and where they're currently in use: Wikipedia on Quotes & Punctuation. — Unsigned comment by RobinHood70 (talk • contribs)

I've tended to do the programmer thing too and put exactly what is said or written in the quotation marks. Thus, with your initial two examples I'd use the first if there was no full stop (or period if you prefer) in the original and the second if one was present. That obviously leads to an inconsistent look, but it is at least consistent in terms of what is to be found in the game, which is probably the more important factor. –Rpeh^{•T•C•E•} 06:45, 29 April 2008 (EDT)

I'm with Rpeh. The quotation marks should only contain what is being quoted. Any adjacent punctuation that is for grammatical purposes, rather than being part of the quotation, should be outside the quotation marks. --Gaebrial 09:05, 29 April 2008 (EDT)

While the signature was my goof <blush>, I had actually deliberately outdented my previous point as sort of a side-note. It would look odd to outdent it at this point, so I guess I'll leave it there. :) Let's see if I can remember to sign this time... --Robin Hood (Talk • E-mail • Contribs) 11:58, 29 April 2008 (EDT) (Yes!)

(Outdent) I'm another traditionalist. I find that "This." simply looks more naturlal to the eye than "this". Tha gap between the end of the word and the period is what really annoys me, but like RobinHood already said, the matter is hardly an important one, and probably won't even be noticed by the majority of viewers. - Game Lord^{Talk|Contribs} 12:03, 29 April 2008 (EDT)

I think if this discussion proves anything, it's that we're never going to get a standard. I'm going to stick with the in-game quotes but it's simply not practical to enforce that: checking everything that appears in quotes against the CS is a bit over the top. –Rpeh^{•T•C•E•} 12:31, 29 April 2008 (EDT)

To change everything would be a nightmare, of course, but if we decide on something (majority vote?) and put a recommendation in place, at least future edits can all follow the same standard. Also, Sam324 seems like he might be interested in helping out on this sort of thing, judging by recent edits. --Robin Hood (Talk • E-mail • Contribs) 12:43, 29 April 2008 (EDT)

Consensus may be tricky to achieve. If you want a wider discussion you ought to bring it up on the Community Portal. –Rpeh^{•T•C•E•} 12:49, 29 April 2008 (EDT)

I don't think it's important enough to start a site-wide sweep for inconsistent use and fix all of it to use a single system, but it's one of those things where if I'm changing something else on the page I might slip it in on the same edit. I definitely think the "logical quotes" method makes more sense all around, and would probably be the worldwide standard if it were for some technical issues with old printing presses that necessitated the rule change in the first place. I think the other method is just obsolete in today's world of digital text and inkjet/laser printers. Most technical publications (and this site is a technical publication, being an encyclopedic reference) conform to the logical quotes standard, and only a few hard-line traditionalists still cling to the old method (which isn't even the original rule - technically logical quotes came first, and they only changed it to accommodate printing presses). --TheRealLurlock ^Talk 14:55, 1 May 2008 (EDT)

{Discussion continued on UESPWiki:Community Portal/Archive 14#Quoting and Punctuation Format)

The Community Portal discussion ended in 2008, so I want to comment here at the talk page of the Style Guide to forestall any future attempts to revisit the issue (people who see a "this wiki uses American English" rule are apt to incorrectly assert that punctuation-always-inside-the-quote "is" a "rule" in "American" writing. The reversion of the style guide to logical quotation (LQ) – terminal punctuation goes outside, unless part of the original material being quoted – was a wise consensus choice. The rule (which is not actually arbitrary but principled – see below) reduces dispute and is helpful in a project of this sort. By this point, no one is unfamiliar with it; it's used at Wikipedia, the third to fifth (depending on metrics) most frequently used website in the world. Contrary to some beliefs, the style was not invented by "computer nerds", but dates to the nineteenth century as the first formalized quotation style, and arose in textual analysis and criticism (which is a large part of what a game encyclopedia is), philosophy, and linguistics for quotation and terminological precision purposes, inspired the increasingly forking British quotation styles, was originally common in the United States. It was later adopted by computer and other technical writers (starting in the US despite the general trend there away from LQ), for reasons of exact clarity about what is and is not part of a literal string like a code or command example.

Most importantly, LQ prevents ambiguity and quotation errors. UESPWiki is very careful about quoting game material exactly as given (typos and all), so the punctuation-inside-no-matter-what style some prefer would necessarily introduce errors in this regard, by forcing into the quotation various extraneous commas that belong to the quoting sentence not what is quoted. That would not be compatible with UESP's goals with regard to pinpoint game-quotation accuracy. As a form of writing about computer software, and the commands entailed in it, UESPWiki also best serves its readers with absolute clarity about literal strings like console commands, configuration file entries, and file names.

On dispute reduction: Some North Americans [I'm American, so this is criticism of my fellows not of the Other] are very jingoistic about "their" style. They've been encouraged to take this stand by excessively nationalistic style guides, the publishers of which profit by competing with others, trying to sound more authoritative, and encouraging irrational levels of "brand loyalty" by tying it to a false sense of patriotism, a "language as politics" manipulation technique that began with Noah Webster's efforts to sharply fork written American from British English in the first place. Such people are usually going by what their grammar school teacher told them – someone with a similar style guide indoctrination background plus an authoritarian role of insisting on rules that students must follow or have their grades lowered as punishment. Victims of this crude schooling consistently also believe, for the same miseducation reason, that a sentence cannot end in a preposition and that an infinitive cannot be split, which anyone from a more formal linguistics background knows is not actually true in English, but a Victorian-era prescriptive grammar fantasy based on trying to impose "perfect" Latin grammar on English. They're usually also unaware that various American technical publishers use LQ; Scientific Style and Format of the Council of Science Editors recommends it, and even the usually overly nationalistic Chicago Manual of Style does so for "computer writing", which a wiki about a computer game is twice over, as to both its medium and subject. (CMoS also notes LQ's use for linguistic glosses, textual analysis, and other technical writing, but denigrates the use in philosophy texts for unexplained reasons, probably ascribable to editorial conflicts between editions; it is not an error-free work). The punctuation-always-inside style is technically called typographical or typographers' quotation (TQ), and only mislabeled American, being also often preferred in British/Commonwealth fiction publishing. TQ arose to protect tiny, fragile quotation mark blocks in movable type printing by shielding them with larger character blocks, a rationale that no longer exists in digital printing. Meanwhile, there are over a dozen conflicting variants of quotation style in Commonwealth ("British") varieties of English, albeit closer to LQ in most cases than TQ is; the leading British style guide, New Hart's Rules, just throws up its hands about the matter. Because It is not possible to keep everyone happy all the time when it comes to quotation style, the only practical choice is LQ as an across-the-board rule, because it has a defensible practical rationale, and is not tied to any national dialect. Some object to LQ reflexively because of the name "logical quotation", and just need to get over it. It doesn't mean that all other quotation styles are deemed "illogical"; rather, it refers to the rationale of the style, following the logic of what pertains and does not pertain to the quoted material, rather than being based on aesthetic, nationalist, or tradition arguments.

A third rationale for sticking to LQ at UESPWiki is that it discourages coding errors in MediaWiki markup, which uses series of single straight quote/apostrophe characters to generate both italics and boldface:  According to ''Darkest Darkness,'' the Daedra ...  is a markup error (note where the comma is), and one that is only made by someone habitually ignoring or unaware of the LQ rule. This matters, because people making this error tend to spread it to other markup, e.g.  According to ''[[Morrowind:Darkest Darkness|Darkest Darkness,]]'' the Daedra ...  which looks even worse and makes even less sense.
— Darklocq ^☎ ¢ 10:37, 30 March 2017 (UTC)

Headers

Lately, there has been some minor conversation as to whether headers should be like Rules and regulations or Rules and Regulations. It isn't mentioned in the Style Guide, so I think something has to be added (especially since we are different than Wikipedia by capitalizing most words in the title). If no one opposes, I will add a quick sentence or two in the page. –Elliot ^talk 23:27, 8 December 2009 (UTC)

For in-game stuff, we always need to use the in-game casing. For other stuff, this is one of the very few issues where I can honestly say I don't mind either way :) –rpeh^{•T•C•E•} 23:48, 8 December 2009 (UTC)

I'm all for using "title case" in titles and have always disliked Wikipedia's stance on that, so as far as I'm concerned, you can go right ahead. —Robin Hood (Talk • E-mail • Contribs) 00:18, 9 December 2009 (UTC)

Actual PAGES!

In my opinion a HUGE category of items ex. Miscellaneous items isn't usefull. Yes we know a quill is worth nothing and weighs 0.1 BUT people want more in-depth descriptions. Such as locations of most quills etc. this should be done to further help users FIND the items. It is MY opinion on this although if others are different that's their opinion I was just thinking people migh want something like that.

Quills are very common - they are in hundreds of fixed places - plus random spots. You wouldn't need to search far to find one. And after that, what else could be said specifically about a quill? --Arch-Mage Matt ^{Did I Do That?} 05:29, 27 August 2010 (UTC)

Italicizing quotes

"This should be the standard method of quoting an NPC's dialogue."

"This should not be because it looks stupid."

I can't find any guidance for this issue in the style guide or elsewhere, but we can use our common sense and eyes here: italics are used for emphasis, and there's no point in italicizing the quotations, since they are not part of the game's dialogue or punctuation. Further, when the quotations are italicized, they bleed together with the last word of the sentence. As you can see above, it just looks bad, plain and simple (can you see? I don't know if different skins of the site use different fonts where this is not apparent). I think explicitly noting here that quotation marks around dialogue should not be italicized would make the wiki look a whole lot better. Minor Edits 22:59, 7 May 2011 (UTC)

I see no way to implement this policy, you can't have bots do it as it would be impossible to distinguish quotes from the rest of the article, and more importantly we have been doing it for so long it would be hard to change this habit as nearly every article with in-game dialogue on it already is like this, making it nigh impossible to have an editor do this. The best case scenario with this is that we have widely differing styles between articles that recently got more information and the older ones. I would prefer to follow the current style instead of bothering with this. --AKB ^{Talk Cont Mail} 23:05, 7 May 2011 (UTC)

(edit conflict × 2) I'm not too keen on the idea, mostly because I'm incredibly lazy. While it makes sense, I don't see the point in changing it. It looks pretty much the same to me, and would be a pain to change. Legoless 23:08, 7 May 2011 (UTC)

I think it's fair enough to have a "preferred style" - that's what Style Guides are for. Personally, I've used the second version purely because it seemed more natural while I was editing, but I'm certainly not wedded to it.

Getting a bot to change all existing pages would be tricky; having a user make them all would fill RecentChanges so quickly it would make your eyes bleed. If there's consensus for one format over another then it would be fair enough to allow the quote format to be changed as part of a larger edit, but I really wouldn't want to see somebody doing that kind of edit on its own. Having spent more time at Wikipedia lately, I get sick of seeing the edit summary "[made pointless changes] using AWB". rpeh •T•C•E• 23:18, 7 May 2011 (UTC)

Certainly; I'm no advocating a massive project, just one of those low-priority "while you're editing something else, if you think of it" sort of things. Minor Edits 23:22, 7 May 2011 (UTC)

I'll probably have a look to see if RoBoT could make the change, but I shudder at the number of pages that would be affected. It's probably much better as a background thing. rpeh •T•C•E• 00:02, 8 May 2011 (UTC)

I missed this discussion entirely, but posted my honest opinion here, after notifying AKBabout lack of Italics in his dialogue quotes. As far as I'm concerned, we keep doing what we have been doing for the past two years and stick with Italics. --Krusty 11:19, 28 May 2011 (UTC)

The style I use is for the inverted commas to be in 'normal' font and the actual dialogue in italics. I don't think it makes sense to make massive changes for such a small thing. I reckon the single policy we should have in this case is to have the same style throughout a page, to avoid confusion. --SerCenKing ^Talk 11:39, 28 May 2011 (UTC)

And that is what I think this discussion is actually about - and we had that discussion years ago and agreed to what you just said. Quotes should always be in italics, while the colons may differ. --Krusty 11:46, 28 May 2011 (UTC)

Policy on the capitalization of classes

Capitalized and uncapitalized seem to be used interchangably, is there a definitive policy on this?--Catmaniac66 07:18, 23 May 2011 (UTC)

We're changing them to uncapitalized as part of the OBNPCRP. rpeh •T•C•E• 07:44, 23 May 2011 (UTC)

Gotcha, so if I see it capitalized I dont need to worry about uncapitalizing it as this will be done as part of a larger edit to the page and would only clog it up, correct?--Catmaniac66 07:46, 23 May 2011 (UTC)

Yup. Although if you see a page that has largely been completed OBNPCRP-wise, then feel free. rpeh •T•C•E• 07:52, 23 May 2011 (UTC)

From what I see on the pages, I assume this applies to uncapitalized class names in the main text, but capitalized in the summary chart/box on the right hand of the page? Nikomis 13:21, 23 May 2011 (UTC)

Yes. rpeh •T•C•E• 15:03, 23 May 2011 (UTC)

Epicine They

In the UESPwiki writing style, is it preferred to use an epicine they or "he or she" when the gender is unknown or could be either male or female? For example, which of the following is preferred?

• When you speak with your spouse, he or she will offer you a home-cooked meal.

• When you speak with your spouse, they will offer you a home-cooked meal.

In general, most modern experts accept either. There are still a few "conservatives" who accept or prescribe the traditional use of the male pronoun in a generic way, but most or all authoritative modern style guides absolutely prohibit this as sexist language (style guides to scholarly writing such as the American Psychological Association Style Guide and the Modern Language Association). The most common advice is to first see if the issue can be avoided by rewording: In your example, we can do this easily: "Your spouse will offer you a home-cooked meal." If the dropped element of the sentence needs to stay, we need something like, "When spoken to, your spouse will offer you a home-cooked meal."

However, in many cases, this is not so easy to do, or results in a complicated, tangled sentence. In that case, "he or she" is considered by some to be better (more "technically correct"), but most will say that when this looks cumbersome or is repeated to many times (e.g., "Ask him or her if her or she will put his or her thing in his or her other thing"), then "they" or "their" is preferred. As I wrote above, however, many professional writers and experts consider the use of "they/their" a completely acceptable to resolve the issue. Jreynolds2 00:32, 28 December 2011 (UTC)

Revisiting one of the guidelines

I believe we need to revisit one of the guidelines, specifically the one about possessives for singular words ending in s:

"Possessives should use "'s" for singular words, even if the word already ends in an "s". This conforms to modern practice as recommended by the Chicago Manual of Style and similar works. Plural nouns ending in "s" add only an apostrophe to become possessive."

This is (honestly) outdated. Many, many, many organizations use the single apostrophe for words ending in s, especially names. More than that, however, is that the TES games overwhelmingly use the "s'" format over the "s's" format. Thus, I think we should revisit and change this guideline. Jeancey (talk) 18:18, 19 July 2013 (GMT)

I am in full support of this. Quite frankly, "Tullius' Armour" looks better than "Tullius's Armour". The extra 's' is silly. Also, Jeancey would eat me if I didn't agree. --Nocte|Chat|Look 18:21, 19 July 2013 (GMT)

I would support this as well. It just looks strange to me and Jeancey makes a good point that the "s" format is used a lot more in the games as opposed to the "s's". Forfeit (talk) 19:28, 19 July 2013 (GMT)

I don't see any issue with this. Obviously, when it comes to something copied directly from the game (such as dialogue or an item/place name, etc.) then we use the in-game spelling, but otherwise I think removing this point from the style guide altogether is acceptable. It was only added a few months ago anyway. — ABCface^◥ 04:33, 22 July 2013 (GMT)

It saddens me that this wasn't already the standard. Minor Edits^{Threats•Evidence} 06:58, 22 July 2013 (GMT)

I support this. • JA^T 07:52, 22 July 2013 (GMT)

Since I'm apparently the one who added that guideline (which surprises me), I thought I should chime in. It's not actually a rule I use, personally. I grew up with the s' style, but I recognize that sometimes grammatical rules change with time (take, for instance, the growing prevalence of logical quotation in North America, including us). So, my vote is for s', but I don't really mind either way. The reason I added it in the first place was that there was a discussion at the time, and most people seemed to support the s's style, so I went with it. Unfortunately, I can't seem to find that discussion anywhere, which leaves me really confused. It would be unusual for me to have an IRC discussion only, since I'm normally all about having on-wiki discussions before even minor policy changes, but I checked and don't see anything about it even there. <scratches head> If anyone finds it, please link to it! I seem to remember Eshe being the main supporter of the s's style, but I may be misremembering. – Robin Hood  ^(talk) 18:52, 22 July 2013 (GMT)

Italicizing perks

I've seen a few editors italicize perk names within articles (e.g. One-handed notes section) and I like the way this looks, but it has not been consistently done wiki-wide. Should we be doing this? --Xyzzy ^Talk 06:28, 17 December 2013 (GMT)

I may be wrong, but I believe this started with just a few on skill pages due to the rule "Italics can be used for proper names to clarify that the phrase is a proper name", because the names of some perks aren't entirely obvious that they're proper nouns. Then some people didn't realize this was why and started italicizing perks elsewhere because they had seen it somewhere already. I don't think there's any other legitimate reason to do so. — ABCface^◥ 13:21, 17 December 2013 (GMT)

"mobile" stylesheet not congruent

The "mobile" stylesheet is not similar to the main site, at least in respect to colors and wallpaper. Is there any reasoning behind this? For me, the mobile site stripping of these styles makes it very difficult (for me) to read, making my eyes tired very quickly. I primarily access the site from my mobile devices (tablet and phone) and because the colors are not the same, I end up using the main site, often using Firefox or Chrome "reader" function instead of the m.uesp mobile links. I realize that sentence is a run-on, but too tired to fix it. Is this the right place to post? I could not find a mobile site specific page...

1NUY4SH4 (talk) 11:13, 29 March 2014 (GMT)

It's to make it easier to load for mobile browsers, as well as easier to view without a ton of stuff taking up valuable mobile screen real estate. While I think everyone knows that a lot of people enjoy the look of the site, I believe it's better to just provide the content for mobile users. --AKB ^{Talk Cont Mail} 14:09, 29 March 2014 (GMT)

That explains the wallpaper, but not the color inconsistencies. Maybe, though, I am the only one who has an easier time reading the main css colors than the mobile css starkness. I do like how the mobile version is easier to browse. Thank you! 1NUY4SH4 (talk) 22:11, 30 March 2014 (GMT)

Speculation and uncertain facts

Moved to UESPWiki:Community Portal#Speculation and uncertain facts. —Legoless (talk) 15:36, 23 December 2014 (GMT)

Em dash and spaces between sentences

Would it be possible to add two more standards to the style guide?

Dashes: I've noticed that dash usage varies widely:
1. standard—one
2. standard — two
3. standard -- three

I believe the most efficient standard would be the first one; it saves space and looks the most professional.

Spaces: some pages have two spaces between each sentence, and some have one, and oftentimes the spacing varies within a single article. Would it be possible to implement a standard preferring one or the other? I personally prefer one space, but people might have sufficiently strong opinions that it would be a pain to standardize. —Lyra001 (talk) 13:32, 10 July 2015 (UTC)

I can't really answer anything when it comes to the dashes, but for the spacing, I'd say the overwhelming majority style is single space. It's been quite awhile since I've even seen double space on an article, so I'd say single space is the standard there. •WoahBro^►talk 14:06, 10 July 2015 (UTC)

For dashes, Wikipedia suggests using either an unspaced em dash or a spaced en dash. I've always preferred your first example, myself, and wouldn't mind making that a formal rule. As for spaces, the only difference is when you're editing. HTML only ever displays a single space, regardless of how many you actually have (except in unusual cases, like <pre> tags). By definition, the point is therefore moot, but there's nothing wrong with replacing all double spaces with singles if you're making another edit anyway. – Robin Hood  ^(talk) 14:34, 10 July 2015 (UTC)

Are there particular uses we are referring to? Because, for example, I agree that an em-dash should have no spaces when used in a sentence, but as a Brit, I would always used a spaced en-dash in such situations anyway. I also think that {{Place Link}} would look odd if the spaces were removed from around the em-dash there, but having an en-dash instead to reduce space could also be an option. The other thing to note is that whenever we are quoting in-game text, we should use the style as presented in-game, regardless of whether it fits with our style. On spaces, as RH says, it doesn't matter in terms of display, as it will always show only one space. For consistency, it may be good to remove double spacing in the edit window so as to not cause confusion. --Enodoc (talk) 22:04, 10 July 2015 (UTC)

Yeah, for example, the dashes on the Skyrim: Quest Information are spaced, but the same sort of format in the Skyrim: Race is replaced with colons. If dashes were standardized according to standard one, a corollary could be that a link to a page, followed by a brief summary, should be separated with a colon and not a dash. —Lyra001 (talk) 05:58, 11 July 2015 (UTC)

Question About First Person

Would the first person restriction also apply to lines that refer to the player directly? For example, "Once you are finished with (task), report to (NPC) for your reward." Raddok (talk) 19:43, 30 October 2015 (UTC)

First person is "Once I am finished...". "You" is second person, and preferred here. So your sentence would be just fine -- SarthesArai ^Talk 19:50, 30 October 2015 (UTC)

It appears my understanding of perspectives could use work. Thanks for that clarification. Raddok (talk) 21:51, 30 October 2015 (UTC)

Recent Additions

There have been a number of recent changes to the style guide that have been made, without discussion or consensus, which I do not agree with.

• Adding extraneous information on capitalization, which obscures the rest of the guideline and is already covered by Spelling.
• Replacement of the US standard "unspaced—em-dash" with the UK standard "spaced – en-dash", which contradicts the conclusion of the discussion right above this one.
• Stating there is a preference to use semantic HTML over wiki markup, in contradiction to the general wiki editing guideline which states preference of wiki markup or template use, when no preference has been approved by community discussion.
• Explaining why and how to section-link an article multiple times right after saying multi-linking is bad practice (if we don't want it to be done, we shouldn't be saying how or why to do it).

--Enodoc (talk) 10:26, 30 March 2017 (UTC)

I agree with your points; the additions are unnecessary and in many cases actively confusing as well. I would like to point out, though, that my personal preference is towards spaced em-dashes ("like — so") for pure readability, and I would be content to have this case be the exception to the US style standard. My reason is that at the quickest of glances I can't tell whether an unspaced dash is em or en. Probably doesn't affect anyone else, but ah well. —likelolwhat ^{talk lulzy to me} 10:40, 30 March 2017 (UTC)

Agreeing with Enodoc and likelolwhat as well. I'm also of the opinion that content changes to the Style Guide should be discussed and consensus reached before altering the document. The same as for any site-wide guidelines. Echo (talk) 12:59, 30 March 2017 (UTC)

To take the original points of the objection in the order given:

1. Because there's little activity and few active editors on the site, and volunteer editing time is very limited, it has proven more efficient to just get to work and deal with occasional objections or tweaks than to try to launch a new discussion about every alteration or addition. Meetings, including virtual ones, are usually a drain on, not enhancement to, productivity. I realize I'm comparatively new at this site, but I'm taking care not to impose my will, just observe general best practices, absorb this particular community's expectations, and identify and resolve reader- and editor-facing problems. I have a lot of general experience at that. Consensus on a wiki is mostly established by doing not asking, and by post hoc not prerequisite discussion. The wiki's own guidelines seem to suggest being bold and that particular editors are not more "vested" than others by having already contributed more/longer.
2. Capitalization: The spelling and capitalization material is effectively buried in another page which is hard to find (it's not even a subpage of the Style Guide). People will expect to find at least something about this in the Style Guide, and a sentence with an example explaining the key principle is the most efficient way to get the gist across.

   When a site has a central style guide then various other more detailed pages on specific style issues, the main style guide needs to summarize the key points from those other pages, or it fails in its purpose. Remember that most people will not read the style guide, fewer will read all of it, and even fewer will read detail pages that are linked off of it. It's a bare fact of Web usability that people do not "drill down" any further than they have to, and spend much less time on any page than we'd like or expect them to. Various usability studies by Nielsen Norman Group and others have proven this conclusively, since the late 1990s, and demonstrate that in an era of "click bait", the trend to distraction and short attention span has worsened in this medium since then. See also the more general concept "don't bury the lede" A document like this should always front-load the primary expectations. Also, it's not possible for the addition of a sentence to "obscure the rest of the guideline", which is long. Please don't engage in hyperbole, which is not helpful to consensus formation because it has a polarizing tendency.

3. Dashes: Either style – spaced en dash or unspaced em dash – is acceptable and understood universally in English for setting off a parenthetical—like I'm doing both ways in this sentence—and they are semantically equivalent. However, see works on actual typography generally (or Web typography, usability, and accessibility more narrowly), and you learn that they're not visually equivalent. For example, The Elements of Typographic Style by Robert Bringhurst, widely regarded as the "bible" of typography in general, for about 35 years and counting, specifically denigrates unspaced em dashes as a readability problem, even in physical print, and recommends spaced en dashes.

   There's a reason the spaced-en-dash style is common online: "foo—bar—baz" can be very difficult for many readers to distinguish from "foo-bar-baz", while "foo – bar – baz" never, ever presents that problem. Web typography is not predictable. As just one example: in the browser, OS, and font combo I'm using right now, boldface is almost undetectable on this site, monospace is a bit too tall, en dashes and hyphens are hard to distinguish, and I had to jack up the base font size a bit. If I switch to a different browser, none of these conditions are true, but there are different display issues.

   The fixed predictability of print does not apply online. In digital typography especially, unspaced em dashes are long known to be a readability problem, because the writer cannot depend on the reader having a font that clearly distinguishes between em and en dashes, or even hyphens, and many fonts do not, especially at smaller font sizes. (This is even true of some print typefaces, as the Chicago Manual of Style itself notes in the current edition's sec. 2.93, not written by Garner; the material on paper typography and proofreading pre-dates his involvement and goes back many editions.)

   Regardless what one's personal preferences are in print, and certainly regardless of any dubious nationalism-based arguments (see also old thread on quotation style above), there's a defensible predictable readability and parseability rationale for always using spaced en dashes in online writing, instead of unspaced em dashes, for this sort of construction. (Use of the en dash as a joiner as in Sapir–Whorf hypothesis, or range indicator as in 1993–2002, is never spaced, and it's never an em dash). As an aside, the unspacing of the em dash historically arose as an artifact of typewritten manuscripts, where the em dash was represented with -- (two hyphens), which results in a very wide pseudo-character that looks funny when spaced, like "this -- is excessive". None of this stuff relates to modern to online typography, or even current manuscript preparation with word processors. If you type that unspaced double-hyphen pseudo-em-dash in MS Word, OpenOffice, etc., it'll auto-convert to a real em dash, and if you use space-hyphen-space it'll auto-convert to a spaced en dash, further proof that both styles are universal, since this feature is not dependent on either the US English or British (or Australian, etc.) English dictionary and grammar add-ons being loaded.

   Also, what I added didn't "contradict" the previous discussion of dashes, in which the first editor asks, one editor says "I can't really answer", a single editor expressed a subjective preference, without a rationale, for unspaced em dashes, another editor agrees that en dashes shouldn't be spaced (no one disagrees with that) and repeats the same mistaken nationalistic argument for en versus em, and the closing comment observes pages using spaced en dashes, then makes unrelated comments about colons. I'm not contradicting any community consensus, I'm providing (in much greater detail now) a logical basis for the community to come to one at all.

4. The preference for using <em> and <strong> rather than <i> and <b>, respectively, to indicate semantic emphasis has nothing to do with wikis or this wiki in particular, but is part of the HTML standards from W3C and WHATWG. Wiki syntax like ''...'' is a just MediaWiki shorthand for producing <i>...</i>, nothing more.

   If the desire is simply to avoid using bare HTML in the wiki code, the obvious solution is to create templates for these. One can simply port over Template:Em and Template:Strong from en.Wikipedia.org. We use bare HTML (e.g. <br />) all the time anyway, so I can't see why this should be a priority. But I'm happy to do it on request; I wrote those WP templates in the first place, and I keep having to correct myself using {{em|...}} here out of habit, and switch to <em>...</em>.

5. I don't understand the last objection, about multi-linking. A) We don't say not to do it, we say to usually not do it. B) There is no "multiple times" going on there. C) There is one actual, certain rationale for multi-linking (namely, to specific sections in a long article, to get readers to the info they need), so D) we should say so rather than leave perusers of the Style Guide wondering and making up their own minds as to when to do it ("when I think it's really interesting", or whatever), nor E) wondering how to do it properly (coded for a specific section anchor) in the one kind of case where it might be useful.

PS: I collect style and grammar guides, so I can easily research any other style questions that arise. I'm already familiar with the material from years of work on wikipedia:en:Manual of Style, with which I don't subjectively agree on every point, just that the points appear to have consensus over there. I'm not trying to impose its preferences on UESP, though the consistency and conflict-resolution rationales for coming to some rule (even if it's a different one) on any given matter will often be identical. I agree with the opening comment in the early discussion that the present approach to dashes is just random chaos, with no particular style being consistently imposed. This gives the material a poor appearance for readers, as does the profusion of ALL-CAPS FOR EMPHASIS, which I've also been cleaning up and which is also already against the style guide. I get the sense we could easily spend more time arguing about what the style guide says or should say than in actually applying it to the live content, and I think that would be a mistake.

— Darklocq ^☎ ¢ 14:46, 30 March 2017 (UTC)

I disagree with all recent changes. Changes to the style guide should actually reflect our style, not change it. --AKB ^{Talk Cont Mail} 17:24, 30 March 2017 (UTC)

On what bases, specifically? I've addressed the original objections as to their substance. Was there something in particular you had in mind? The obvious problem is the actual style of the articles does not match the Style Guide at all, and flaws in its wording, which I resolved, are the principal reason. — Darklocq ^☎ ¢ 23:40, 3 April 2017 (UTC)

Any changes to the style guide that do not reflect usage are considered contentious and should go through a discussion period (however minimal in terms of time and contributors) before implementation. I have not gone through the changes, but any that go against practice should and will be reverted until a proper discussion agrees that such a move is desired. In theory our style reflects that which is found in the game itself, where for example unspaced emdashes prevail. Also wiki markup is desired over html, the very reason we have so many templates and an actual namespace for them is to reduce html usage which is not very easy to master, whereas template usage is.

Having now gone over it I found it impossible to separate any good from the bad, therefore I took the blunderbuss option and reverted them all. Pages like this need to be clear and concise, adding weighty reasoning to simple statements is not helpful, and any existing on the page should be reduced where possible. The style guide itself is not meant to be a comprehensive guide on how to edit, write, or code, nor is it based on the grammar rules of any particular actual language. It is to guide editors towards our style, what we prefer, what we do not want, and how we want our information presented. That means the reason many of these 'do's' and 'do not's' exist on the page is because they are or have been a prevalent problem, such as the quotation marks. They are not on the page because the community thinks like this, it is the non-community or new-to-community editors who make these 'mistakes' (and often they are not grammatical mistakes just trying to present information in a way which does not fit within our wiki). This leads to the emdash question, which again the prevailing attitude and therefore the style which the guide supports is the unspaced emdash. It does not matter a single jot what any other wiki is doing, or even what the prevailing attitude is amongst the highest literary minds (who so often disagree that is almost idiotic to use them as a guide), this is our style on our wiki. Another last reason that html is not desired is that it often falls out of use, there is a lot of old html on our pages that is no longer supported and therefore the page no longer looks like it was supposed to. Overlinking is linking to other pages, for example if you went to the Skyrim Jorrvaskr page and linked every iron sword mentioned, or to Lore Civil War and linked every mention of Skyrim. Lastly, I think, the reason the style is somewhat ambiguous in many areas is because it should be. It is not meant to prevent an editor from doing what they think is necessary for a page, merely guide them to a position where a 'finished' page in the editors eyes will have very few edits afterwards in order to make it fully consistent and without mistakes. Silence is Golden^{Break the Silence} 17:51, 30 March 2017 (UTC)

I hope you realize mass-reverting hours of careful work, for which detailed rationales have been provided (without refutation for the most part), just because you can't be bothered to sort the unobjectionable from the bits you have an issue with, is a strong discouragement to participation. I seem to be the most active MW editor at this point, fixing a lot of stuff, too. If, despite this wiki's pronouncements otherwise, one really has to be a member of a special in-crowd clique here to get anything done, there are other wikis I'll move on to. — Darklocq ^☎ ¢ 23:40, 3 April 2017 (UTC)

Others have largely addressed the various points brought up here, but to add to Silencer's points about HTML vs. wiki coding goes, the reason we use wiki code is because, well, this is a wiki! :) Using wiki code makes sure that any changes to HTML have little or no effect on formatting, as Silencer mentioned. If, for example, HTML decides to deprecate <i> in favour of <em> or vice versa, the underlying PHP code can be changed and everything that uses '' will continue to work, whereas anything using bare HTML will not. A couple of specific examples where this has already occured are <center> and <tt>, both of which are now deprecated. Since the wiki itself does nothing for these except pass them through to the browser, any browsers which stop supporting the HTML 4 standard at some point in the future will cause this formatting to break, or perhaps even be displayed as part of the text.

There are, obviously, cases where it's necessary, or at least preferred, to use bare HTML, such as <code> and <pre>, and it's often useful in embedded tables as well. In an ideal world, all of these would be converted to templates (and in fact, we do have {{Pre}} and {{Small}}, for example, which roughly replicate equivalent HTML commands), but this is often fairly redundant in cases of HTML code that's unlikely to be deprecated, and templates can sometimes even be a step backwards, since there are certain things like pipes and equals signs that need to be encoded when placed in template parameters, so it's a judgement call. On a side note, there's a term, "wikify", which describes changing HTML code to wiki code. It exists very much because of this reasoning.

Lastly, on a completely separate note, please don't post to old threads...in your case, one that was almost a decade old, now! This is called "necroposting", and is discouraged—usually to the point of being removed—unless the new post adds substantive new information to the discussion. Simply reiterating previous points, or posting "I agree" messages, no matter how detailed, really adds nothing to the discussion. Even expounding on previous points adds very little, particularly nine years after the fact. – Robin Hood  ^(talk) 20:47, 30 March 2017 (UTC)

I know what necroposting is and why it is generally avoided. I did add "substantive new information", in quantity. Few of the points I made had already been made in that discussion, in either of its locations. Every other article I go to demonstrates resistance against (or unawareness of) LQ, so I considered it worth the trouble to reinforce this site's use of LQ, lest skimmers of the Style Guide see just "use American English" before their eyes glaze over and they move on, likely assuming that means use typical American journalism quotation style (remember that quotation marks are covered in a different USEPWiki page they will probably never get to). This result is especially likely since they see typesetters' or "American" quotation style in our articles frequently already. Every time I do an editing spree here, I fix TQ/AQ several times in several articles.

On the HTML issue, as I said, the obvious solution is to use template wrappers for the HTML elements.
— Darklocq ^☎ ¢ 23:40, 3 April 2017 (UTC)

(←) I disagree that your post added anything substantial to a nine-year-old discussion. Discussions that old, especially on policy pages, are rarely read, and most of the points you brought up are covered in any discussion of LQ, like the one we link to in the article itself. You also talk about forestalling any future attempts to revisit the issue. If there haven't been any such attempts in nine years, it's not terribly likely that there will be any, and if there were, we would've dealt with them then. Now, having said that, you do add a number of good points, even if they are covered elsewhere, which is why your post wasn't removed (or at least that's why I didn't remove it—I can't speak for others).

Using template wrappers for something we have wiki code for is just silly. Yes, there's the whole semantic markup argument, but this isn't Wikipedia, and I don't think it's terribly necessary or even beneficial to get people to use specific HTML elements for specific purposes, except perhaps on some of the more technical pages that discuss things like file formats and the like. As a general rule, however, it just adds complexity to what many people already find daunting to learn, and it creates work for very little gain in day-to-day wiki usage.

As for logical quotation, I think most of the current batch of editors know to use it, and most of the newer pages do use it. (And heck, Wikipedia has had that policy pretty much since its inception, I think, and there are still plenty of pages there that get it wrong, so I think we're doing pretty good in the newer namespaces.) Older pages have not been updated, so it's not unexpected that on Morrowind pages and the like, you'll probably find a lot of non-LQ usages that need to be updated. And it's great that you're finding and fixing them! We very much appreciate it.

I don't want you to think we don't appreciate your efforts here, or that we haven't considered your points, or we're being cliquey, or whatever. There are reasons behind most of our existing policies, and we've already had discussions on them in a lot of cases, and when we haven't, it's because nobody really gave it a second thought. I think you got off on the wrong foot with a lot of people by introducing several changes, including policy changes, without any prior discussion. It's one thing to be bold when adding policies that reflect existing usage, but quite another when you start changing policies like the use of en- or em-dashes, or suggesting that HTML should be used in preference to wiki markup, when that's clearly not the way things are currently being done. If you want to propose policy changes, by all means, do so, but you should write each one as its own topic. Having a wall of text with five different policy discussions isn't conducive to discussion, which is probably why nobody's discussing your specific points. – Robin Hood  ^(talk) 06:01, 4 April 2017 (UTC)

A short example on capitalization sounds like a good idea, but it doesn't need to go into too much detail. I think other people have covered the reasons behind the other objections. You mentioned some articles which don't match the style guide as one of the bases for the changes; could you link a few, please? It may be that there are a few which either predate parts of the style guide or were created without it in mind, and it's probably easier to change those to match the guide than it is to change the guide to match the pages. As AKB said, the guide should reflect the style that exists, but if there are different existing styles, they need to be made consistent with each other first. --Enodoc (talk) 10:38, 4 April 2017 (UTC)

I must say I am disappointed that you (darklocq) would accuse me of laziness and reverting without reason; I thought I managed to give my reasons for reversion as well as discussing all of your points above without creating a wall of unreadable text. As many may have noted I do tend to wander when making long posts so I try to keep it simple when being controversial, so there is less room for misunderstanding. I am not an expert on any part of the English language, nor am I an expert on wiki-coding or html. I would, however, consider myself an expert on the UESP style of editing. I know the mass-reversion edit is disconcerting to the person it is done on, therefore it is discouraged but not banned on wikis. That is why I made it known what I did on the talk page, while attempting to address all your points. If any of the edits you made did not come under one of those points then you should say so, instead of trying to start a personal fight.

The style guide exists mainly for new users. Those more accustomed to wiki-editing and our site should not have to refer to the style guide as a reason for making an edit, as each edit should normally be able to stand on its own without a page to back it up. The Style Guide comes under the 'Guidelines' part of Policies and Guidelines (the Guide part of the page name might give it away), so no matter what you write here I could theoretically write a page with everything the opposite of what is written here and not be 'wrong' to do so. Despite that the guide is still meant to represent what is desired, and mass-changing things on the page without discussion is wrong. Any arguments about lack of activity or care are baseless, as every wikipedian loves an argument as changes (but mainly controversial changes) to Policies and Guidelines should, by policy, be done with consent, however meagre the participation.

"Policies and guidelines can be edited like any other Wikipedia page. It is not strictly necessary to discuss changes or to obtain written documentation of a consensus in advance. However, because policies and guidelines are sensitive and complex, users should take care over any edits, to be sure they are faithfully reflecting the community's view and to be sure that they are not accidentally introducing new sources of error or confusion."

"Because Wikipedia practice exists in the community through consensus, editing a policy/guideline/essay page does not in itself imply an immediate change to accepted practice. It is, naturally, bad practice to recommend a rejected practice on a policy or guideline page. To update best practices, you may change the practice directly (you are permitted to deviate from practice for the purposes of such change) and/or set about building widespread consensus for your change or implementation through discussion. When such a change is accepted, you can then edit the page to reflect the new situation."

I have often edited policies myself without prior discussion, but I strictly limit myself to alterations that are uncontroversial and update it to common practice. Any hint of a controversy, and sometimes even without out, and a discussion should be attempted. When you can point to that discussion for any changes you are making you are far far less likely to be reverted, but you should almost expect it and be ready to defend your changes on these pages. If this seems like I am repeating myself it is because I am. Silence is Golden^{Break the Silence} 11:28, 4 April 2017 (UTC)

[removed by poster]

 Dragon Guard (Talk) 23:22, 4.4.17

Hey, you asked me on what grounds I objected, so let me give you a point by point break down of what I disliked about your edits:

1. First, stating you believe you can ignore the community because "it's small and inactive" or is a "good ol' boys club" "or echo chamber" or it would "take months to get a reply" or whatever else you've said in the last few days does not exactly ENDEAR you to a community. I agree with being bold and editing, but when you are being bold and editing, you should remember "Note that all contributions to UESPWiki may be edited, altered, or removed by other contributors". I'm also going to say your claim of not imposing your will, following best practices, or absorbed this community's expectations. You edited a guideline to directly contradict what we do to match what you like, and considering over a half dozen members of the community have expressed pretty clear disagreement over your actions, your edits here did not reflect what the community wanted.

2. That's redundant.

3. I have trouble expressing how little I care about the opinion of The Elements of Typographic Style by Robert Bringhurst. But let me just say we use American styles wherever possible, after a quick Google search, Robert Bringhurst is Canadian. We also already established consensus against what you changed it to quite specifically.

4. Again, going specifically against the communities expectations and practices, you changed it to everything being HTML preferred. You're essentially proposing changes to just about every article on the site, instead of reflecting what the community actually does or want.

5. I'm sure some of your changes that would have probably been accepted, but by splitting these editions over sixteen different revisions, it's extremely hard to review the changes. --AKB ^{Talk Cont Mail} 03:22, 5 April 2017 (UTC)

I've left this entirely alone for a long time, to let stepped-on toes stop hurting (on both sides – it's difficult to express how frustrating it was to have many hours of painstaking work, over several days, nuked in a mass revert, though I accept SIG's explanation for why that route was taken).

Taking all your criticisms in stride, I'm curious what changes you thought would be likely to be accepted. I think by now my months of editing, including a lot of style guide "enforcement", to the letter, clearly indicates I'll do what the style guide says regardless what it says and am not here to impose my "preferences". The changes I made and suggested were for practical reasons, and I'd like to see some of them reinstated, after however much discussion is necessary to agree on at least some of them.
— Darklocq ^☎ ¢ 14:57, 13 August 2017 (UTC)

Possessives Revisited

Several topics up, it was agreed that possessives of words ending in s should use s' rather than s's. As a result of that discussion, the section on possessives was simply removed, where it probably should have been altered to state the consensus. So, is using s' still the consensus, and if so, does anyone object if I re-add that section with the appropriate changes? – Robin Hood  ^(talk) 05:48, 5 April 2017 (UTC)

I believe it should be s's, as in "Ross's Game Dungeon" as a random example. I don't think a word being possessive should change it's spelling. --AKB ^{Talk Cont Mail} 06:21, 5 April 2017 (UTC)

It seemed to me that ESO was changing the trend to s's, but a quick look through a couple of the categories shows s' to be prevalent, but not 100% (Bolelos's House, Milk Eyes's House, Multa's's Miscellany). I can't see any consensus on where the difference stems from, so perhaps we should just follow Bethesda and ZeniMax and use s' except where it's from the game. Silence is Golden^{Break the Silence} 11:26, 5 April 2017 (UTC)

Where the difference stems from (in the real world at a large; I dunno what's going on inside Zenimax): Style guides have been at war with each other over this matter for more than a century; there are about half a dozen different conflicting "rules" (based variously on appearance, pronunciation, consistency/clarity, tradition, even etymology), and some of them have changed over time. Americans over about 30-something have a tendency to write Jones', the glass', etc. Younger ones are bucking that old trend because it's often confusingly ambiguous, and because the The Chicago Manual of Style changed its recommendations in a recent-ish edition (maybe the 15th, at very least the 16th), and now prefers the less ambiguous Jones's and the glass's. The latter style has largely dominated outside the US, so this CMoS shift is a move toward commonality. It hasn't had a sweeping effect because the also-influential American journalism manual Associated Press Stylebook still advises Jones' – newswriting almost always opts for compression when possible, to save column and headline space.

On a wiki, I would normally side with Jones's for clarity and commonality (plus there is not desperation to compress in this medium). But on this site in particular, it probably makes sense to stick with Jones' because that's the style that predominates in the actual games. Perhaps the rule here could be to use the style that best matches the game in question, within articles about that game, if Zenimax's own house style has been shifting over time.
— Darklocq ^☎ ¢ 15:21, 13 August 2017 (UTC)

Italicised Game Names

• Using italics for titles of the games themselves helps distinguish the titles from places, etc. ("in Morrowind" clearly refers to the game in an out-of-universe way; "in Morrowind" refers to the land within the games).

I've removed this recent addition from the page, since it is not what we have historically done with the shortened game names. It has always been "Oblivion" or "The Elder Scrolls IV: Oblivion", but never "Oblivion". Of course, context matters and I'm not opposed to using italics in the manner described when distinction is needed (such as distinguishing Daggerfall from Daggerfall from Daggerfall). However, it seems to be a recent trend to add italics to all instances of a game name, regardless of context (see this old revision in Legends space).

I don't think this is necessary or desirable; italicised instances of "ESO" look absurd and incorrect. That said, we're now living in a world with two products called "Morrowind", so maybe it is time to make the full jump. Does anyone have any input on this? —Legoless (talk) 19:01, 20 June 2017 (UTC)

I think it's handy to italicize when it's an instance like Daggerfall, Morrowind, Skyrim etc. but agree that initialisms like ESO or TES seem odd when italicized. Maybe make an exception there? Echo (talk) 19:34, 20 June 2017 (UTC)

The way we have written our pages has largely resulted in not having to distinguish the terms as they are usually totally obvious. For instance in the Morrowind namespace Morrowind is not referred to when discussing locations, nor is Skyrim mentioned as an area on Skyrim pages. Even in Oblivion where it is unavoidable given the distinction sometimes needed between Oblivion and Cyrodiil, it is avoided. With ESO there is little mention of Morrowind the location because it isn't really a thing within the game, and to be honest I don't remember a single instance of mistaking a game mention for its namesake location, or vice versa, when reading pages. But I do think there is merit to changing all this, though ESO does look wrong (and perhaps because it is not the game name it can be exempt from such a rule), but I would prefer a hard and fast rule where all instances of the game name are italicised, as most italic rules say to apply it to names of works (books, films, games), including the wikipedia manual of style (wikipedia suggests italicising abbreviations though). However I am a very strong supporter of "knowing your subject" which thinks people should be able to distinguish between similarly named things (especially on a single-issue website) without having their hands held, and only provide dis-ambiguity where it is strictly necessary. Silence is Golden^{Break the Silence} 19:52, 20 June 2017 (UTC)

I'm glad this discussion came up. I was about to ask somewhere what to do about a number of edits made by a user yesterday that added italics to instances of "Arena" in city/town lore articles, like Lore:Wayrest. Croaker (talk) 20:03, 20 June 2017 (UTC)

I do prefer to italicize game names that aren't ESO. One of the main reasons I do this in the Legends space in particular is because a town could be in Skyrim without appearing in Skyrim. That's confusing, and an italicization of the game name definitely makes it far more legible. —Fullerton ﴾talk﴿ 02:55, 21 June 2017 (UTC)

This topic still hasn't been decided. I've had to question myself many times when italicizing game titles, and there's no guideline to follow. I support italicizing short names like Redguard and Oblivion, as well as full names such as The Elder Scrolls V: Skyrim. ESO and other acronyms don't need italics because they can only mean one thing. All the other short names, however, do have alternate meanings. It's also a matter of following proper English grammar. I think any style guide would agree that because these are large works like novels, they need to be italicized. —Dillonn241 (talk) 00:19, 3 August 2017 (UTC)

Agreed. We should italicize game names (long or short), but not abbreviations. --Enodoc (talk) 00:26, 3 August 2017 (UTC)

My stance is that the game titles should be italicized, without doubt. But, contrary to some of the posts above me, I believe that ESO should also be italicised. The Silencer pointed out above that the name of works should be italicized, and the developers themselves commonly refer to the game as ESO, and is also marketed as such as well. I believe that the argument for using the correct grammar/style outweighs the aesthetic approach which I see argued above, if ESO is synonymous to The Elder Scrolls Online, and is widely accepted and used by its creators and marketers, then it should also be italicized simply because it's a rule; it's the name of the work, and it's correct. KriHavok (talk) 02:15, 3 August 2017 (UTC)

What about "ESO Plus", or the various other situations in which it's used? The developers never italicise the abbreviation, and nor should we. Italics in this instance are a purely stylistic choice (this is the Style Guide, after all). Italicising short names for the purposes of clarification is one thing, but there is no context in which ESO would need to be distinguished like that. —Legoless (talk) 23:07, 3 August 2017 (UTC)

(←) In response to the above, ZOS regularly italicize ESO, as seen in numerous articles on the official website. Examples: "If your membership ends, you’ll still be able to play ESO" [2], "In addition, you can visit the Players Helping Players section in the official ESO forums to talk to the ESO community" [3], and "we talk to long-time fan Isriana about her unique ESO-themed artwork" [4]. If you use the search function on the official website, and search for "ESO", you will actually find plenty of articles that italicize ESO, because it's the name of the game. I believe they do not italicize "ESO Plus", because it is a two-word trademark (as seen in the first example I linked above, where it is displayed as ESO PLUS™), and in this case they denote it is trademarked by using initial capitals, after the use of the ™ symbol in the article title (but since ESO is an abbreviation, all letters of that are to be capitals anyway), and is why "Plus" is capitalized too. As if only one word of the two-word trademark were to be italicized, then it is not so obvious to the reader that both of the words constitute to one trademarked term. Furthermore, because ESO is already an italicized term in its own respect, this makes me also believe they didn't italicize both that and "Plus", to highlight how whilst "ESO Plus" is a trademarked term, ESO is one too. I did do my research into the italicization of trademarked terms to discover this information, and whilst common advice stresses the importance of consistency whilst remaining in the standard rules, admittedly, the nomenclature does get a bit confusing when it comes to using initial capitals, and italics, but ultimately this is how ZOS has chosen to display its terms, and I usually have a preference to sticking to how they convey their material to us, which is why I am in support of ESO to be italicized and as an extension to the ESO Plus topic that Legoless brought up, I believe that should be left as is ("ESO Plus" -- without italicization), for my aforementioned reasons. KriHavok (talk) 01:15, 8 August 2017 (UTC)

Grouped response to whole thread: I wrote the "Using italics for titles of the games themselves helps distinguish the titles from places, etc. ..." material in question. I support italicizing game names (and shortenings thereof), and strenuously disagree with "not having to distinguish the terms as they are usually totally obvious". I frequently encounter ambiguous wording here, though this may be more of a problem in articles on older games like Morrowind than it is for newer, attention-getting material on ESO. On this site, the use of the italics is often contextually necessary because most of the game (and expansion) names have game-world referents, often in the same paragraph or even the same sentence: Skyrim is a place, Tribunal is another name for Almsivi (and its temple, and its quest line), Helm of Tohan is an artifact, etc., etc.

While one can write tedious and sometimes contorted prose to get around the ambiguity (to make it "totally obvious"), it is much easier on editors and readers to just italicize the titles. That's why the italic titles convention arose to begin with in the real world. No one should have to write "the game Morrowind" or "Morrowind (the game)" (or have to redundantly link it again as Morrowind) to disambiguate here. The four-character, easily distinguishable italics way is clearly preferable for multiple reasons. Doing it consistently is preferable because, well, it's consistent and it eliminates a lure into productivity-wasting dispute over style trivia and rule interpretation.

The italics would not be used for The Elder Scrolls or TES, which is a franchise. This is consistent with gaming-press style, with Wikipedia (whose style we're not following in every detail, but which has influenced reader and editor expectations and our own style guide, which cites WP's MoS), and with real-world treatment of titles of creative works versus the "properties" under which they fall: "Thor: Ragnarok will be the next release in the Marvel Cinematic Universe." (Some house style apply italics when the whole franchise/series is named after a work in it, e.g. "the Star Wars films", "Star Trek fandom", but that doesn't apply here.) Italics are also not used for utility software, online services, and other non-"creative" digital work; it's Microsoft Word, Unbuntu, and Yandex, so it's Wrye Mash, OpenMW, and ESO Plus (which isn't a game but a membership service). One could insist for or against "ESO Plus", but it's trivia that only affects a tiny number of articles, and no readers will care. That said, what some other site does, like "ESO Online™" is really of no relevance or concern here; their house style is not ours.

Re: "Italicising short names for the purposes of clarification is one thing, but there is no context in which ESO would need to be distinguished" – It's an instruction-creep and consistency matter. It's preferable to have a simple "italicize the game titles, short or long" rule, than to have a complicated "italicize the game titles, except [insert various nit-picks that serve no actual purpose here]" set of rules, which is harder to remember and understand, and apt to produce frustration, disputes, and unnecessary cleanup work. Italicizing ESO is completely harmless, actually does serve a purpose (this is an acronym-dense "field", and it makes it clear to non-experts that a game is meant, not a patch project or modding tool or Console command or whatever), while avoiding "ESO" doesn't actually buy us anything. "Don't do X unless truly necessary" is a fine default in all-things-being-equal circumstances, but is a secondary consideration when "just do X consistently" produces fewer headaches. If we were taking a "truly necessary" approach to style, about a million text strings on this site would get decapitalized, since there are very few cases where our "game caps" are actually necessary for understanding. We would also lose the italicization of quotations, the sharp namespace separation, the finely nested categorization, italicization of in-game titles of works like Progress of Truth [not doing it for the game titles is inconsistent with that, too], and many other style and content arrangement choices that have been made at this wiki because consensus feels they aid clarity and usability.
— Darklocq ^☎ ¢ 16:43, 13 August 2017 (UTC)

I want to revise my position on this issue to only italicize full game titles and short titles when there is a real possibility of confusion. This is how most of the wiki already does it, and without a clear entry in the style guide we are going to end up with a lot of inconsistencies. Implementing italics on all instances of short names will require thousands of edits that cannot be done by a bot due to multiple uses of the words.

This is also a practical issue. If we italicize short names, there will be hundreds of possessives that must use something like nowiki tags to not also italicize the apostrophe. Page and category names are not italicized either and I don't think MediaWiki allows that. I propose that we add an entry under "Italics" clarifying this use of italics for game titles, as it is already the most common usage. —Dillonn241 (talk) 23:18, 11 November 2017 (UTC)

Edit Break 1

Nothing was ever decided for this topic, so I propose that we try to reach a consensus finally. And by that, I mean add an entry to the style guide. I don't actually care much which option is chosen; it's more important that we have a guideline that will keep the wiki consistent on this point. I do believe the majority of the wiki currently uses "italicize full titles only", which makes it the most practical choice. However, as others have pointed out, italicizing removes some ambiguities, specifically for place names (Daggerfall, Battlespire, Dawnstar, Stormhold, Morrowind, Shivering Isles, Skyrim, Summerset), faction names (Tribunal, Knights of the Nine, Dawnguard), and other TES things (Redguard, Shadowkey, Oblivion, Dragonborn).

From the responses above, it seems like almost everyone agrees on "italicize full titles and short titles" but there is some disagreement on ESO. I propose that for now, we stick with not italicizing ESO as it is closer to what we're currently doing. Then that issue can be decided in the future if necessary.

For making possessive forms of italicized words, I created a {{'}} template a while ago based on Wikipedia's. Use it in place of an apostrophe for an italicized word and it will prevent the apostrophe itself from being italicized. For example: Redguard's. Another option is to italicize the whole word but that implies that the title is "Redguard's" instead of "Redguard". The more important thing is that we decide whether to italicize in the first place, though. —Dillonn241 (talk) 00:20, 28 March 2018 (UTC)

Sounds good to me. Full titles, short titles, but not abbreviations. --Enodoc (talk) 16:23, 28 March 2018 (UTC)

I agree with Enodoc. It's rare that people italicize initialisms or abbreviations, but both long and short forms of titles should be italicized. – Robin Hood  ^(talk) 16:56, 28 March 2018 (UTC)

I agree. Italicize long or short game names, but not abbreviations. --Holomay (talk) 09:56, 30 March 2018 (UTC)

Another name that is italicized inconsistently is The Elder Scrolls. I like Darklocq's reasoning to not italicize it, especially since there is no way to confuse its use. Plus, the tagline at the top right of every page doesn't italicize it (it would be plain text if so). No one ever opposed this suggestion, so I can only assume no one cares and/or everyone agrees. Best to have some guideline here instead of nothing.

Based on the responses above and this extra detail, I think the new entry under "Italics" should say: "Game titles such as The Elder Scrolls V: Skyrim and Daggerfall should be italicized, but not abbreviations like ESO. Additionally, the series name The Elder Scrolls should not be italicized." It should probably be at the top, as it's more important than the other two. I'll add it in a few days (a week after the edit break) or someone else could, assuming there is no major opposition. —Dillonn241 (talk) 01:12, 2 April 2018 (UTC)

Bold Formatting Using Semicolons

I propose adding the following to the guidelines for bold formatting:

Do not use a semicolon (;) simply to bold a line without defining a value using a colon (:). This usage renders invalid HTML5 and creates issues with screen readers.

Semicolons are for defining a definition list, not for bold formatting. --Enodoc (talk) 08:17, 31 July 2017 (UTC)

I never knew that they had a specific usage! We've used them to bold terms all over the place on UESP, I think. We should definitely add that to the page, in my opinion, or the practice is likely to continue. – Robin Hood  ^(talk) 08:57, 31 July 2017 (UTC)

I have a habit of doing this, it is a very useful tool to replace pointless multiple lower-level headers using =. From some of the posts on the wikipedia page, and the linked bug report on wikimedia, it seems that screen readers have all sorts of problems with wikipedia markup, and that the use of a colon without a preceding semi-colon is just as bad as the other way around (in other words, every single talk page indentation is semantically wrong). It also appears that this problem has been known since 2006, and that html5 and screen readers have only exacerbated the problem by making it publicly visible. If something has been known and unable to be fixed for 11 years that has no other reasonable alternative I see no point in banning its use, however a precautionary line could be added to encourage other markups to be explored. Silence is Golden^{Break the Silence} 01:53, 4 August 2017 (UTC)

I have no real issue with using it for low-level headers. It's when it's used for bold formatting that I have reservations. --Enodoc (talk) 15:18, 5 August 2017 (UTC)

What exactly is the difference then. The complaints on wikipedia are about when a semi-colon is used without a colon to create a list, which is exactly what happens when using them as low-level headers. I have seen it used to bold an entire sentence maybe three times, and every time it was unnecessary to bold it at all. The most common usage would be in tables, which screen-readers seem to have trouble with even without the use of semi-colons, to which I would argue that it is pointless addressing one part of the whole problem when you wouldn't even notice an improvement. Silence is Golden^{Break the Silence} 16:15, 5 August 2017 (UTC)

It's a stylistic formatting difference. ''' is bold. ; is a list header. I don't think I've seen it used here as a low-level section header, only to specifically head a list, which is what it's designed for. (I'm not saying that it isn't used as a low-level section header, I just don't remember seeing it.) Any places where it makes an incorrectly-mixed list (like here) are on my long-term plan of things to correct. Closer to current relevance though is ESO dialogue, where it is often correctly (syntactically) followed by a colon line, but is incorrectly being used to bold-format something. Dialogue is supposed to be '''bold''' for the player and ''italic'' for the NPC, not ;List Header for the player. --Enodoc (talk) 16:44, 5 August 2017 (UTC)

(←) Strongly support adding this guideline line-item. Probably the no. 1 problem with MediaWiki, as used in the real world, is the mangled HTML it generates when people do "convenient" things like use ; as a shorthand for what they think it just boldface. Someone really needs to do a plugin for it that detects ; at the beginning of a line (which translates into the <dt> HTML element), checks for a following : (the <dd> element) and converts the dt semicolon line, in absence of a dd colon, into a span with CSS boldfacing. Until such time, the usage needs to be avoided. The majority of misuse of dt semicolons on this site (and many others) are actually cases that should be headings (h3 ===, h4 ====, whatever, depending on the extant heading structure of the page already), and all the rest should just be replaced with ''bold''. I encountered the dt semicolon element being abused on this wiki as a low-level section header at least twice yesterday, and abuse of the dd colon as an indent is also frequent. Yes, talk pages on MediaWiki installations have invalid HTML structure; that's no reason to spread the bad habit to the content of the real work, especially since it interferes with reuse of the content (e.g. parsing by tools; perhaps to make a pop-up help app, or whatever people might want to do with the content at this or whatever other wiki). I don't buy "it hasn't been fixed yet so we should give up" reasoning. Just use proper code and the not-fixed-yet problem doesn't affect our content in the first place. PS, to forestall any "but real headings make the ToC too long" objection: The ToC can be constrained to only show a limited number of nested levels of headings, so that's not a rationale for bad code. — Darklocq ^☎ ¢ 16:59, 13 August 2017 (UTC)

This discussion seems to have died and the proposal was not opposed, so I'll go ahead and add it to the page somewhere (probably under the "bold" section). --Enodoc (talk) 14:20, 3 January 2018 (UTC)

Italicizing game names (again)

Should we be italicizing the titles of games or not? Our style guide seems to imply that we should—"Italics should be used for the titles of books and lengthy works." I'm personally in favor of it, but I'm always hesitant to change them, since they're not italicized throughout like 99% of the wiki. Five years ago, it seems we reached a sort-of consensus to italicize (in most cases, at least), but then the discussion died. If we do decide to start capitalizing, it would presumably be a pretty big endeavor and would result in lots of inconsistency for a while, so maybe it's not worth it. (In theory, italicizing should help with clarity, but not if it's done intermittently.) Still, as a grammar obsessive, it bugs me. We should at least make a decision one way or another and add it to the style guide. —⁠Will ⁠• ⁠B ^[talk] 21:30, 15 April 2023 (UTC)

I asked about this on the Discord recently, italics are preferred and changing those you see that are incorrect is perfectly acceptable. As of late, I have been using the new Template:G, which is very useful for time-saving. Mindtrait0r (talk) 05:00, 17 April 2023 (UTC)

I found this discussion after seeing the use of this new {{g}} template on Lore:Ayleid Empire. Based on the previous discussion above, we have been italicising most game names aside from "ESO" as an acronym (although The Elder Scrolls Online is fine). The {{g}} template currently italicises ESO and I've started a discussion to potentially change this based on the outcome of the discussion here. Personally I'm still of the view that abbreviations should not be italicised. —⁠Legoless (talk) 08:56, 17 April 2023 (UTC)

I have no problem changing the template, as the creator of Template:G. This will make the DLC refs look like ESO: Blackwood. If that's fine, then no worries.

Alternatively, we could change the standart to something like Online: Blackwood, so the full thing is always italicised.

Anyways, I've changed the template to de-italicise the ESO abbreviation for now, as per the discussion from five years ago.--ErfXploded (talk) 11:15, 17 April 2023 (UTC)

I think the new look is great! Mindtrait0r (talk) 13:04, 17 April 2023 (UTC)

Two weeks late, but thanks for the quick change! I've just specified in the style guide that game titles should be italicized. Feel free to adjust the verbiage. —⁠Will ⁠• ⁠B ^[talk]

I left a couple italics-related thoughts on the G template talk page, but I guess this would be a better place for it, so I'll move it here:

• Shouldn't the colons be italicized as well? For example, Online: Blackwood, instead of Online: Blackwood? Pretty sure it's grammatically correct to do so even when the title is shortened like that.
• Relatedly, I'd actually endorse italicizing ESO, if for no other reason than italicizing abbreviations of titles is what's recommended by Wikipedia and—I'm pretty sure—the Chicago Manual of Style (though it's behind a paywall so I can't confirm). But would be fine either way.

One other thing—a couple people in the discussion five years ago suggested The Elder Scrolls does not need to be italicized since it's the name of a franchise, like the Marvel Cinematic Universe. But that doesn't apply in this case, since The Elder Scrolls is the actual title of the series and appears in the complete title of each game (e.g. The Elder Scrolls III: Morrowind). So I'm specifying that in the style guide, unless there are any objections. —⁠Will ⁠• ⁠B ^[talk] 16:06, 30 April 2023 (UTC)

I would say colons should be italicised, yes. I'm indifferent either way on whether ESO is italicised, but The Elder Scrolls definitely should be. The only thing I would say is that IIRC "Online" should never be used in isolation; it's either "The Elder Scrolls Online" in full, or "ESO" as an abbreviation, never "Online" by itself. --Enodoc (talk) 22:14, 2 May 2023 (UTC)

I've made the colons italicised where appropriate (everywhere but after "ESO"). --ErfXploded (talk) 22:26, 2 May 2023 (UTC)

Awesome, thanks! —⁠Will ⁠• ⁠B ^[talk] 01:46, 4 May 2023 (UTC)

Verb tense for "also appears" for locations in multiple games

For locations that appear in multiple games, it seems to be standard to put an "also appears" statement in the Notes section, for each game's version of the place page.

Should the verb tense in this statement (appears vs appeared) follow the real-life game release timeline, or the in-game calendar?

The current "Verb tense" section says that past tense is appropriate for "locations [...] which appeared in previous games", which I think implies it should follow the real-life game release timeline. For Morrowind, Oblivion, and Skyrim, this almost happened "automatically", because the in-game calendar went forward along with the real-life release dates. With ESO being set in the relatively distant past, compared to the three preceding games, it's less clear.

For example, if "Foo Cave" appears in both TES 3 Morrowind and ESO, then on the place page in the Morrowind namespace, should the article say:

• Foo Cave also appeared in ESO.

(In-game calendar timeline; Morrowind in 3E 427 and ESO in 2E 582.)

or

• Foo Cave also appears in ESO.

(Real-life game release timeline; Morrowind in 2002 and ESO in 2014.)

For places that appear in both Morrowind and ESO, some of the articles in the Morrowind namespace have it one way, and some have it the other, which is how I first noticed it.

Thanks! 73.185.239.90 06:58, 21 May 2023 (UTC)

I always thought it should be "appears" regardless of chronology. Otherwise, things get needlessly complicated when you have a location that appears in three (or more) games (such as Rielle). If you go by in-game chronology, for example, then the wording for the Oblivion entry would be "Rielle also appeared in ESO and also appears in Skyrim" (or some variation thereof), which is needlessly convoluted and clunky. A simple "Rielle also appears in ESO and Skyrim" is much cleaner and imparts the necessary information with a minimum of linguistic gymnastics and without creating confusion regarding in-game vs. real-life chronology. — Wolfborn^(Howl) 08:31, 21 May 2023 (UTC)

I use both. "Appears" is more appropriate for a live service game, while "appeared" is better for a game released in the past or no longer available. —⁠Legoless (talk) 09:29, 21 May 2023 (UTC)

If we're after consistency, "appears" is probably better. This treats the "in-universe" chronology of the games as seperate from the "real-world" chronology of the user, and matches the usage in more traditional forms of media eg when discussing Shakespeare's Henry IV you might say "Falstaff also apppears in The Merry Wives of Windsor" without worrying about which came first (Henry IV was written first but it's not clear whether it's set first and it seems somewhat academic from the perspective of 400+ years later).--Draugluin (talk) 03:55, 27 June 2023 (UTC)

Formatting of Time on Oblivion NPC Pages

This is a minor nitpick of mine that I can easily fix with a bot job, but I don't want to change it without some agreement.

On Oblivion NPC pages, the schedules write time as 1am, 2am, 3am, 1pm, 2pm, 3pm, etc. The game formats time in the Wait menu as 1 am, 2 am, 3 am, 1 pm, 2 pm, 3 pm, etc. with the space. Most style guides recommend lowercase with a space and two dots, but I think we can safely leave out the dots since we're matching how the game presents time. No space is definitely wrong.

I can't see any issues running the bot to fix this. It's a simple search and replace over the Oblivion namespace. —Dillonn241 (talk) 00:52, 12 February 2024 (UTC)

I prefer the current layout, i.e. 1pm. This was standardised as part of the OBNPCRP and is consistent across the namespace. Can't see the logic behind adding a space but not adding the dots, let's just keep the informal style. —⁠Legoless (talk) 01:07, 12 February 2024 (UTC)

There are many valid ways to format time. The rule as I understand it is to simply be consistent. I don't like the idea of having a format explicitly for Oblivion. Whatever format we use should be consistent throughout the entire site. Eve (talk) 07:06, 12 February 2024 (UTC)

Well, in my experience we consistently use the same style for News posts as well, or at least try to. —⁠Legoless (talk) 14:27, 12 February 2024 (UTC)

I, indeed, see no spaces or dots used there, yes. I do, however, see a mix of lowercase and caps. And just looking at this page, the automatic signatures for our posts do get a space in their timestamps (at least with local time zone display enabled). I'm also okay with enacting a change on just a subset of pages so long as it's understood that the intention is to eventually standardize times sitewide to the same format. I like it with a space and caps, personally. Eve (talk) 15:13, 12 February 2024 (UTC)

Capitalization

Hello, I am not native to the english language but it goes noticed that a lot of headers capitalize every first letter of a word, why is this? it looks somewhat tacky. TheSeldomConsitentEditor (talk) 22:46, 12 February 2024 (UTC)

This is a formatting practice called title case. We use it here for both page and section titles (books which don't follow the rule in-game are exceptions, such as the texts from ESO's map). The discussions regarding why exactly we use title case are long, long ago, but here are some I could find: (1) (2) (3)

The general reasoning seems to be that it looks more professional, which I agree with. MLA format, which is standard for papers regarding English and communications, uses title case for its titles, subheadings, and sources. APA format, which is standard for papers regarding social sciences, uses title case for its headings and title. Thurabian (or CMOS) format, which is standard for research write-ups and dissertations, uses title case for its titles and subheadings. These are the core three formats for professional papers. Hopefully this helps! Mindtrait0r (talk) 01:48, 13 February 2024 (UTC)

Wording of References

Apologies if this isn't the proper talk page to raise these questions. I have noticed two inconsistencies with the way games are cited. First, quests. I've seen this style of quest cite, Events of Quest Name in ESO, as well as this one, Quest Name quest in ESO. Second, expansions. I've seen Oblivion: Shivering Isles and Shivering Isles

In both of these cases I prefer the first. "Events of" is more descriptive to what exactly is being cited. It also matches with this common ref - Events of Game Title. I also prefer listing Oblivion before Shivering Isles. I have seen it argued that the expansion is never referred to in that way, but I don't think many of the others are, either. As far as a I know, there's no categorical difference between Shivering Isles and Orrery, they're both expansions, but we don't cite Orrery as its own title. Putting Oblivion before it is more descriptive, providing context that it is part of Oblivion. Someone who doesn't know that might look and see Shivering Isles as its own game. I've also found this official trailer which uses the Oblivion - Shivering Isles format. Mindtrait0r (talk) 16:17, 28 February 2024 (UTC)

It seems to me like the above two questions relate to my recent edits. I'll address why I've been making these changes.

Events of. For context, the "Events of [game]" references across lorespace are largely my fault. As part of the Shivering Isles Redesign Project, myself and other editors endeavoured to begin adding game-specific information to lorespace in 2011. Previously, the policy was to disallow lore articles for e.g. locations which had only appeared in one game and were therefore sufficiently documented in gamespace. See Lore:Cann for an early example of this style of citation being used. Over time, this practice spread across the namespace, and it was fairly harmless when all we were dealing with were small, single-player, easily verifiable games. However, since the advent of ESO, there has been major pushback against such general citations, and myself and many other editors have been working on removing all instances of "Events of", to be replaced by more specific references.

The changes you're talking about ("Events of Quest Name in Game" -> "Quest Name quest in Game"), to my mind, are in line with this. The "Events of" is a vestigial remnant of this ongoing cleanup effort, and seems to be the preferred style of certain prolific lore editors. All I'm doing by rewording the ref is finishing the job, by moving away entirely from unspecified "events" and citing the quests themselves. The wording that you prefer seems overly wordy to me, and sounds awkward sometimes when used with certain quest names.

Oblivion: Shivering Isles. To put it simply, this is not the title of the expansion. This formulation only appeared on the wiki recently with the creation of {{g}} and it is in no way official. Furthermore, usage of the template that caused this confusion has been discontinued. The full title of the expansion is The Elder Scrolls IV: Shivering Isles, as can be seen from the box art and from the title of The Elder Scrolls IV: Shivering Isles - Prima Official Game Guide. Oblivion does not and never has formed part of the title. If you want to mention Oblivion in the reference, it should say something like "X from the Shivering Isles expansion for Oblivion". Personally, I think just Shivering Isles will continue to suffice (until such time as ZeniMax pull a Morrowind on us).

—⁠Legoless (talk) 19:35, 28 February 2024 (UTC)

Just to throw my two cents out there, "Quest name quest in Game" was my idea of replacing the original "Events of" ones with something more straight to the point and bluntly understood. It's basically meant to say "this in this", which I thought was as direct as it could get with referencing something in-game. Sometimes I'll say "faction quest" or "daedric quest" just to be a bit more specific but even without that, I think its clear to the reader what is being referenced. It's also consistent with other refs like "Person/Place in Game" or "Loading screen in Game". As for the title thing, I mean if the product is called "Shivering Isles" and not "Oblivion: Shivering Isles" then we call it the former to be consistent. And besides, if the reader isn't sure if it's a separate game or not, they could just click the link and learn more. --Vincentius1 (talk) 23:05, 28 February 2024 (UTC)

I don't think we should settle on one or the other. My preference would be that if the information being referenced is in a specific quest, then cite that by name—the idea being that more specific is better. On the other hand, if it's something that covers a lot of related quests, then it could be "College of Winterhold questline in Skyrim", for example, and only if it covers multiple unrelated quests would we use "events of...". The problem I see with "events of" in something like ESO is that it covers sooooo much territory and makes it very hard to verify information. – Robin Hood ^(talk) 16:04, 29 February 2024 (UTC)