Doom Wiki:RFC/Style guideline proposal

I would like us to have a simple list of common style issues, apart from Doom Wiki:Policies and guidelines or Doom Wiki:FAQ, in which some of the information is deeply buried under a mountain of text that nobody will more than likely ever read.

Some propositions

 * Usage of Template:Wp needs to be documented as preferred over bare use of the wikipedia: interwiki. This can, in certain articles, save entire kilobytes of wiki text as well as a significant amount of RSI pain to users like myself (I would also like to note that being forced to constantly correct this causes similar pain).
 * Usage of Template:C needs to be documented as mandatory versus usage of or  in contexts other than extended multiline blocks of code.
 * Titles of games that are not primary subject matter should always be italicized. This is already stated, and similarly buried in the above mentioned documents.
 * Inline simple quotations should generally not be italicized except where it is called for, for some specific stylistic issue.
 * Capitalization standards need to be reiterated. We do not capitalize links to normal articles (ie., one does not discuss the topic of Wikis).
 * Punctuation around quotations should follow American English standards (since that's what we do with everything else so far). Periods and commas go inside the closing quote, even if not part of the original quotation. Question marks and exclamation points are the opposite.
 * Usage of inline hyperlinks as citations (like this ) is obsolete. Usage of Extension:Cite should be mandatory.
 * Citations should prefer an MLA, APA, or similar standards body's format. Author, title, publication, date of publication, date of access, and if available or applicable, page number(s) should be given for literary sources. Bare naked hyperlinks are not suitable citations due to the habit of things to.
 * Basic use of wiki links needs to be outlined in simple terms:
 * Standard plurals can be formed by appending the pluralization outside the wiki link; there is no need to repeat the entire link text. Most newbie editors get this wrong.
 * There is never any need for underscores in wiki links, not even interwiki links. They should be avoided.

Discussion
Feel free to comment or suggest changes/additions here.

What will be the stance on. I read some arguments against it but I can barely remember them now. It definitely needs some CSS but it is much better than this. --Kyano (talk) 10:30, 19 July 2015 (CDT)


 * It may be going away when we upgrade next time. The extension has been taken over by a bunch of people with a totally different view on how syntax highlighting should be done who have changed the backing library it uses and the formatting of its output completely and I simply don't feel like keeping up with this kind of crap. --Quasar (talk) 11:02, 16 August 2015 (CDT)

I'd amend the bit about plural to be about regular plurals. mancubusi, since we're going with this, isn't going to work better than mancubi. I'd also amend that underscores instead of spaces are never needed in wiki links, because there are things which use underscores as part of the name (codepointer names, source file names, some nicknames, etc.). Finally, I personally hate putting closing punctuation inside of a quote when it does not belong to it. --Gez (talk) 11:53, 19 July 2015 (CDT)


 * So which style are we to follow then? Whichever the current editor prefers? Seems haphazard but I'm not going to put a big argument forward either since it's minor. I tend to "correct" things to the American style while editing articles however. --Quasar (talk) 12:08, 19 July 2015 (CDT)

''Usage of inline hyperlinks as citations (like this [1]) is obsolete. Usage of Extension:Cite should be mandatory.'' "Should"? Should a guideline use words like that one? :-) --Kyano (talk) 13:17, 19 July 2015 (CDT)


 * These are suggestions for new style guidelines, not the actual wording that would be used if they were agreed to. --Quasar (talk) 13:31, 19 July 2015 (CDT)


 * Cool. Then I want to suggest to use more definite words :-) --Kyano (talk) 13:54, 19 July 2015 (CDT)

No objections to the details (and I admire the idealistic viewpoint that all of our articles could actually look like this). Two general thoughts:


 * Tiny stubs, or pages clearly in flux, should be exempt until they stabilize. Style is usually the first thing to get munged by a major revision.
 * Required formatting will be a barrier to editing. IMO that should be reserved for the highest quality levels, as with Wikipedia's FA/GA system.  (FWIW, given my own track record in reviewing.)    Ryan W (talk) 17:02, 19 July 2015 (CDT)


 * We ultimately can't require anything since we're not putting in advanced filters. However, use of our standard templates and basic extensions needs to be explained and advanced to users as being highly desirable and in accordance with existing consensus about how the site should work and be designed. That's the main point. Though having bots that rove around and fix these kinds of things would be a worthy project as well. Saving myself from refactoring any more wikipedia: links alone would be worth the effort. --Quasar (talk) 13:38, 20 July 2015 (CDT)


 * That's one way to require it. Another way is how we require not vandalizing, or not adding random speculation: explain, then warn, then block.  The latter could be implemented immediately so I thought you might mean that.


 * If this becomes an approved guideline, I'd be glad to help with items that can be flagged using a dump. The catch is that RL prevents me from being continuously online (as you've noticed), so if all new edits must be cleaned up within hours, then a bot might be needed.    Ryan W (talk) 18:47, 20 July 2015 (CDT)


 * I'm not looking to ban or censure users, only at least have a simple list of guidelines I can post to their user page to look at. I can say to do that with the FAQ or P&G, but if their problem is only style-related, and they're not violating copyright or don't have questions about whether or not to create an article about weapons that look like faces, then those articles both have a lot of irrelevant material to sift through. --Quasar (talk) 19:06, 20 July 2015 (CDT)


 * Yeah, I definitely see the point now. Style guidelines once had their own page, of course, and it was my idea to merge.  Didn't imagine we'd get regular contributors for whom formatting was the most burdensome issue!    Ryan W (talk) 19:29, 20 July 2015 (CDT)

I have an idea which would encourage use of these things without having to constantly refer people to policy guidelines. We are able to arbitrarily extend our edit bar for articles with buttons that could do anything from adding the code and wp templates to pre-inserting a ready-to-use prettytable. I have a basic list made up of buttons I'd like to add but I left it at work and so I'll put it here on Monday. --Quasar (talk) 10:51, 16 August 2015 (CDT)

List of some buttons for consideration: --Quasar (talk) 17:29, 17 August 2015 (CDT)
 * c
 * wp
 * cite web
 * FileInfo
 * youtube
 * prettytable
 * prettySortable
 * Create right-aligned thumbnail
 * Add gallery tags
 * ref tag
 * references
 * Add a category
 * Make a redirect
 * A timeline by year link (probably via a template which I've meant to make for a while)


 * As long as we don't go WYSIWYG/WYDSIHBTCI interface, it should be fine. I guess it'll require javascript to work? --Gez (talk) 07:08, 21 August 2015 (CDT)


 * AFAIK, all the editor buttons need JS. These will need a small addition to Common.css which consists of boilerplate code. --Quasar (talk) 07:51, 21 August 2015 (CDT)


 * The edit buttons are now in place. Open to comments if anybody has any. --Quasar (talk) 11:07, 21 August 2015 (CDT)


 * Don't know if re-opening this is frowned upon, but since Ryan pointed me here... ;) In the past week I've been fixing a lot of Wayback links using Archived link, and a button for that would come in handy so I don't have to copypaste it from somewhere local. Could it be added? Thanks. --Xymph (talk) 13:26, 11 February 2016 (CST)


 * Seems prudent given the amount of work entailed. --Quasar (talk) 16:48, 11 February 2016 (CST)


 * So the button might be added to the editor bar some day soonish? --Xymph (talk) 03:32, 16 February 2016 (CST)


 * Will see if I can get it deployed tomorrow. --Quasar (talk) 03:59, 16 February 2016 (CST)


 * NB: This is done, finally. --Quasar (talk) 16:50, 7 November 2016 (CST)