UESPWiki:Community Portal

The UESPWiki – Your source for The Elder Scrolls since 1995
Jump to: navigation, search

This is the main discussion forum used for community-wide discussions about UESP's operations, policies, design, and improvement.

All members of the community are welcome to contribute to this page. Please sign and date your post by typing ~~~~ or clicking the signature icon in the edit toolbar. If you would like to start a new inquiry, please place it at the bottom of the page with a two-tier (==) heading.

Before starting a discussion here, please review the list of other community pages below, as your question or suggestion may be more appropriate on another page.

Other pages for community-wide or general questions include:

Specific requests can be made on these pages:

  • Bot Requests — This page can be used to request that one of the wiki's bots take on a task.
  • Image Requests — You can request specific images for articles here.
  • Creation Kit Information Requests — You can request specific Creation Kit information for articles here.
  • New Page Requests — You can request a new page here if you were prevented from creating the page yourself.
  • Purge Requests — If you are having problems viewing an article on UESP, the page may need to be purged. New purge requests can be made here.

In addition, past discussions from the Community Portal can be found at:

  • CP Archives — Lists all of the past discussions from the Community Portal page, including major discussions and chronlogical archives.
Active Discussions

Many discussions of community-wide interest are held on pages other than the community portal. Discussions about specific policies belong on the policy talk pages, for example. The following table lists other discussions that are currently in progress on other talk pages. If you start a discussion on another talk page, please add it to this list. If a discussion listed here has been inactive (i.e., no comments of any type in at least a week), please remove it from the list.

Location Date started Topic Listed here by

Daggerfall game systems cleanup[edit]

The existing Daggerfall pages contain many legends, assumptions, unimplemented features from the manual/Chronicles having accumulated over the years. I believe that should be amended.

  • Attributes governing skills: was never implemented and should be removed from the skill pages.
  • (to be continued)

Do we have a consensus? KShrimp (talk) 01:51, 4 August 2018 (UTC)

The third sentence on the Attributes page explains that they have no effect on skills in-game. I don't think the content should be removed, and listing governed attributes in the table makes more sense than moving them all to a large note. Instead, I think all of the skills pages should be amended to say, "<Skill>'s governing attribute is <Attribute>, but this has no in-game effect." They currently don't have the part after the comma. —Dillonn241 (talk) 09:52, 4 August 2018 (UTC)
Dillonn is correct, we don't delete information simply because it doesn't work or have any effect in the game, we document and explain it. Silence is GoldenBreak the Silence 17:13, 4 August 2018 (UTC)

ESO NPCs and the "affliction" parameter[edit]

Recently, with the help of Ilaro and RobinHood, we've added an affliction parameter to the Online NPC Summary. This is intended to be used for undead NPCs (vampires, zombies, mummies) and those afflicted by curses/diseases (werewolves, Soul-Shriven/Mindshriven, Flu Victim, probably other types I haven't considered yet). What this does is:

  • Allows for consistency with those types of NPCs, so we don't have (for example) some vampires marked as creatures, some where the race is marked as "Vampire", and some where it's only mentioned in the text
  • Adds them to two categories, Online-Afflicted NPCs, and one specific to their 'type' (see above), so if somebody is trying to complete Undead Slayer, for example, that information is easier to find

Eventually, I'll probably make 'hub pages' like I already did for Vampire, but the first step is getting all the NPCs listed consistently and easily findable, which is what this parameter does.--FioFioFio (talk) 13:02, 7 August 2018 (UTC)

So as I'm going through and cleaning up some creature categories, I came across the Hollow. They're reanimated stone constructs, marked as creatures. But the note on that page refers to Fiend Statues- a different type of reanimated stone constructs, this time marked as NPCs. If anybody has input on whether to call them both creatures, or both NPCs, I'd appreciate it. This kind of inconsistency annoys me, but so does having humanoid NPCs listed as creatures. EDIT: My confusion came because they were listed on a page of Undead Creatures, but looking at the individual pages, they're all NPCs. Problem solved.--FioFioFio (talk) 13:36, 7 August 2018 (UTC)
One more thing I should probably mention as part of this. Draugr and Skeletons have been considered "technical races", as far as ESO documentation here is concerned, for a while now. So I've been making a point to make sure other humanoid undead types are counted as NPCs, not creatures. This include Zombies (and Ra-Netu), Mummies, and Bloodfiends (being a type of vampire). This is following the general idea of "if it's humanoid and you can play as it (via skin/polymorph/personality)", it's an NPC. --FioFioFio (talk) 13:56, 7 August 2018 (UTC)
This is an excellent change and a big step towards documenting the nuances of ESO's various weird and wonderful NPC types. Certainly an improvement from manually adding categories like we were doing previously! —Legoless (talk) 22:32, 8 August 2018 (UTC)
I agree, it's an excellent change and it solves a lot of problems that have been addressed in this discussion. The hub pages are important, we just need to keep separate pages and the necessary disambigs for generic NPCs like enemies that are simply named "Zombie" in-game. Also, I think Spirits should be added to the types of afflictions. --Holomay (talk) 09:54, 9 August 2018 (UTC)
Thanks for the support, guys! And @Holomay, I agree with making Spirit an affliction type, and about disambigs between the hub page and the generic NPCs (just need to double-check whether there are generic NPCs just named Zombie or Mummy). --FioFioFio (talk) 14:55, 9 August 2018 (UTC)
While in principle I agree with this change, I can't help but notice that the use of the term "Affliction" makes being a spirit into an affliction, which is disputable; "reanimated statue" an "affliction", which is also dubitable, and these are both sorted into the Afflicted NPC categories. Since the usage is so wide, "affliction" may not be the best term due to its labeling of any condition as an affliction. Perhaps a term such as "Condition" or something similar would reduce this seeming disparity? Fullertontalk﴿ 19:20, 9 August 2018 (UTC)

() That's a good point, tbh. This has expanded beyond the original scope I had considered, and is encompassing more types than I expected. I'd still like to have one over-arching category for all of them (which can be split into smaller categories, eg Undead, Cursed, Diseased, then broken down by type). Perhaps "Atypical NPCs" or "NPCs with Special Conditions"? --FioFioFio (talk) 19:35, 9 August 2018 (UTC)

I'd be inclined to support "NPCs with Special Conditions" and a change in the display parameter of "Affliction" to "Condition". Fullertontalk﴿ 20:39, 9 August 2018 (UTC)
Vampire rights advocates would probably object to their status being referred to as merely a "condition"...not that they'd like "affliction" any better, mind you. :) But seriously, what about just "special" as a parameter name? The suggested category name is probably good, though. Robin Hood  (talk) 20:51, 9 August 2018 (UTC)
Well, I believe that Verandis Ravenwatch disagrees with the first point, to raise a pointless triviality. Changing the parameter name to "special" wouldn't change the display name, which doesn't resolve the issue of Anka-Ra, Hollow, Spirits, and the like being displayed as "Afflicted" when this could be considered an inapplicable term. Fullertontalk﴿ 21:35, 9 August 2018 (UTC)
condition for the parameter, and "NPCs with special conditions" works for me. I'll make the changes later tonight if there's no objections. --FioFioFio (talk) 22:05, 9 August 2018 (UTC)

Oblivion and Skyrim dialogue documentation[edit]

I am not really sure how to begin this topic. I am not a Skyrim/Oblivion editor, so I can not say that what I'll propose is something I would do myself. Still, I think it is too important to ignore. So to get to the point, in my opinion it is quite strange that the Oblivion and Skyrim namespaces are excluding all player dialogue on NPC pages. I understand that the idea is to get some kind of flow in the article so it is easier to read as 'story'. However, I believe a wiki should document the game and should make it as easy as possible to find this information for users.

Two examples:

  • Knight-Paladin Gelebor: The amount of information is really good, however if I want to search for a specific string of dialogue from a quest or an answer to a specific in-game question, I need to sift through all this dialogue without any anchors I can hold on to. Compare the page with its (yes I said it) wikia counterpart where it is much easier to find specific dialogue.
  • Heimskr: This one was actually the reason to start this topic. I tried to find his speech about Talos, but there is no header or any other anchor to easily read it.

There are two reasons I think we should include player dialogue: 1. It is much easier to read and find information and 2. (maybe even more important than the first one) we should not exclude in-game information. As wiki, we should be as complete as possible concerning in-game info. --Ilaro (talk) 19:51, 22 August 2018 (UTC)

I definitely think player dialogue is important to document. I think maybe the reason it isn't present on our wiki articles is due to the relative lack of player dialogue in Oblivion, which presumably affected the goals of the OBNPCRP and in turn the standards used for Skyrim. That said, we have examples of player dialogue being documented for those games, for example Oblivion:Kathutet. I don't really see any reason to exclude player dialogue, other than the monumental effort involved in retroactively adding it to otherwise-complete articles. —Legoless (talk) 19:59, 22 August 2018 (UTC)
(edit conflict) I agree with you and would also like to add that, at least for me, large paragraphs that switch between italics and normal text every other sentence are practically unreadable, and definitely unskimmable. So I agree with you. I think it would be better to paraphrase in the opening sections, and have the full dialogue listed out (including player dialogue) lower down on the page, much like we do in ESO-space currently. I'm not saying do away with the prose/story descriptions, but even actual novels don't format quotations and characters speaking like that. It's a terrible way to format it.--FioFioFio (talk) 20:04, 22 August 2018 (UTC)
This discussion is long overdue. Omitting player dialogue is a particularly egregious discussion that ultimately only hampers our documentation. Often, to find player dialogue, editors will have to peruse CSList or the Wikia, which is an oversight permitted by the wiki's permissiveness for the total disregard of full documentation. Ultimately, further completing documentation can only be a good thing. As Fio says, the unnested, unformatted paragraphs with interspersed dialogue is particularly difficult to parse, and so I am in full favour of conversion to full documentation. I'd like to add the caveat that while I'd be willing to help out, I am by no means the right person to spearhead a task like this. Fullertontalk﴿ 20:46, 22 August 2018 (UTC)
This is a terrible terrible idea. Yes in some select cases, and even then only in a few of the sentences "spoken" by the player, there is some interesting dialogue/ideas/whatever, but in the very vast majority it is useless junk merely there for the sake of better immersion for the player themselves (i.e. sentences as opposed to Morrowinds single-word topics in order to get information). Anyone complaining about the layout of the current completed NPC pages is complaining about having to actually read an article, where instead they want the information [edited because spoon-fed is an "insult"] presented to them in a way that they don't need to put any effort into reading through ugly bullet points and over-emphasis on every other line in order to be able to distinguish who says what and where with no insight or connections made that are actually there to improve a readers understanding of an NPC. The utter travesty that is the "acceptable" format for ESO NPC dialogue should not be imposed on any other article or gamespace simply because you are used to that and have no intention of making those articles less of a data-dump and actually an article about the subject.
There is simply no need to document player dialogue, it is a means to an end and basically never contains knowledge that the player has only learned through other means already, be that a quest, a book/note, or something previously said by an NPC. There is also no place for that dialogue on an NPCs page, because it isn't relevant to that NPC. Prose writing already covers it by telling you what dialogue option you need to select in order to get the following response (e.g. If you ask soandso about this, they will respond by saying this).
When picking examples of pages you have a problem with, it is best to use pages that are otherwise considered complete (otherwise it is far too easy to pick holes with your arguments). Knight-Paladin Gelebor is not complete, that second paragraph for one needs to be split at least twice, so it is no wonder you would see that as a wall of text because that is exactly what it is. I don't know why you are using a search for Heimskr's Talos speech in an argument about player dialogue, because his speech is not activated by, nor has any involvement by the player. The only real reason I can think you might want to search by player-dialogue is you are on a quest, but in that case any dialogue options and their results will be a part of a quest page's walkthrough. Considering all that, I consider SR:Delphine to be a perfect example of how an NPC page should look (I always use it as my example because it has just about everything you might come across with an NPC). Using bullet points instead of prose would make any of these pages more than double in length, because each dialogue line is separated by a player's line, and the paragraphs are subsequently split. Delphine has scenes with other NPCs, quips, combat dialogue (including ones unique to certain quests), optional dialogue trees (eg one question leads to two but only one can be asked), monologues, short answers, and long answers (and it even has quite a bit of player dialogue). I don't believe anyone who says that a page like that would be better off looking like ON:Razum-dar, for example.
PS, there is quite a lot of the game that we do not document. For place pages we don't document static objects (rocks, internal doors, etc). For creature pages we don't document behavior or movements outside of basic hostility. For NPCs we don't document or describe a persons looks (for Skyrim we know which eyes, hair, and scars people have). We don't document furniture, weather, kill cams, sounds (not music), trees/scenery. There is a serious and massive difference between documenting everything and everything we know about the games. Silence is GoldenBreak the Silence 22:00, 22 August 2018 (UTC)
By mentioning ESOspace NPC pages such as Razum-Dar, you conflate two separate issues. These pages are cliff faces of text not because of dialogue formatting, but because 1. the entirety of their quest-related events are stored on the pages; and 2. because quests in ESO are entirely player-driven and so there is little in the way of NPC-driven events to record on a quest page. Skyrim's system is far removed from this; NPCs have independent motion and a full range of activity, which makes the argument about ESOspace NPC pages a difference between games rather than a reason to condemn the decision to document player dialogue. Fullertontalk﴿ 22:26, 22 August 2018 (UTC)
I don't see the benefit in documenting player dialogue word-for-word since a vast majority of it is completely useless. A prose paragraph such as those seen on the example of Delphine is much nicer to read than the text-dump of broken dialogue found on many ESO NPC pages like Razum-dar. Also to note that whatever is decided here, the Style Guide will need to be updated to match, and then adhered to rather than ignored. --Enodoc (talk) 23:48, 22 August 2018 (UTC)
Honestly, I'm looking at both of those examples, and the easiest-to-scan parts of the Delphine article are the ones that break from prose. Prose does seem appropriate for unprompted lines of dialogue mixed with actions, e.g. the gap between two sections of non-prose dialogue in SR:Delphine#Bleak Falls Barrow. (In fact, that's how I've already been doing such lines when documenting ESO quests.) However, long mixtures of prose and dialogue are messy and visually unappealing. I definitely think the ESO style is more legible, and I think it'll be even better for Skyrim given the differences Fullerton has pointed out.
I would also like to point out that I find Silencer's arguments just bizarre, frankly. Player dialogue is absolutely relevant to NPCs because it's the thing they're responding to — it's the other half of the conversations they're having. Including it would be no less valid than including dialogue from Farengar, Esbern, and Ulfric on Delphine's page when documenting conversations she has with those characters. Silencer may not personally find the player dialogue interesting, but that has no bearing on whether it's pertinent to the NPCs that respond to it. DavidJCobb (talk) 00:44, 23 August 2018 (UTC)

() I'm with DavidJCobb on this one in that I think there's a place for both, depending what you want to accomplish. A straight-forward dialogue section is good for what it is—and if we include one, I think it should be a section of its own as opposed to part of anything else—but it would certainly also be appropriate to highlight closely related dialogue in prose in some cases, along with any linkages (like inter-NPC relations or foreshadowing of quest events) that a player might miss if they're not paying attention. Robin Hood  (talk) 01:47, 23 August 2018 (UTC)

I'm in retirement, but still find myself poking in every now and then. I happened to notice this. Heh...
Given that I spent 5 years of my life, give or take, writing NPC articles in the Oblivion and Skyrim format, I cannot come close to providing an unbiased opinion on this. Or even logical arguments. So I guess I won't! Quite frankly, the Oblivion style NPC pages are what caught my interest in this site. They mixed comprehensive, encyclopedic writing style with more of a narrative style that tells a whole story that brings the characters to life. Compared to other sources of information for these games, I found this to be much more interesting and unique. They would always take the ingenious approach of bring up all the common dialogue up to further set up the background about the character that the schedule already did. And then the rumors! They would put in all these rumors about the characters to further set up the background about them. And the nice thing about listing the rumors out in a narrative format instead of the ESO text dump style, is it let it be pointed out who specifically would be saying these things about the person, maybe even go into a bit of background about that person. It just builds up the story even more.
And then, assuming the character is involved in a quest or something, we get into the fun part. The area of discussion for this topic more or less, since non quest related dialogue tends to lack player options. So the narrative style continues to work magic here. Now there's all this player dialogue and conversations with other NPC's going on. This helps to break up the prose perfectly, because we can insert the conversations in when they happen and maybe insert some exact lines of player dialogue here and there to break up the paragraphs. I think we always point to Dragonborn:Neloth as being a really good example of that. It is a really good article (even has the pretty star). The nice thing about the prose is that if the player dialogue is longer and maybe somewhat interesting, the prose can still capture it. I know that when I worked on Skyrim pages where this happens more often (most player dialogue in Oblivion is very mundane), I would always try to paraphrase the player dialogue exactly. This allows the player dialogue to be captured to an extent without breaking up the narrative and filling the article up with "ugly bullet points and over-emphasis on every other line" as a wise man once said. It must also be mentioned, but prose also can be used to further capture the emotion of the character in that moment as they say these lines. A text dump has to purely rely on the syntax and punctuation that is present in the dialogue, which sometimes doesn't match well with the actual voice acting.
It really depends on where we want to go with these articles, because NPC pages are kind of strange in what the target audience for them would be. If we want to just really cleanly present what's said when, then that ESO text dump style would be great. Just flip through it once, find the line I need, and boom. Done. Never gotta look at it again, and definitely no point reading all that other junk. Nah. The Oblivion prose approach sacrifices the ability to be quick reference material to bring the NPC to life in a completely different way. Where as when the reader plays the game through the eyes of your character, these NPC articles allow you to see the NPC through their own eyes and how they're seen in the eyes of the people they interact with. I think this is a better approach for NPC articles, because I think the target audience for these pages is someone who really liked a character and wants to relive their experiences with them and learn everything they can about them. I don't think a schedule, inventory, and text dump would appeal as much to this reader as a narrative would.
And I think really, a super subjective, inconsistent, grey area approach probably works well with this. There are many times when that ESO approach could be introduced here and there to an Oblivion or Skyrim page to capture interesting player dialogue and break up text. Sometimes those articles stay in prose longer than they should. It's really what's best for the article. If there's a bit too much prose and background and rumors, maybe I'll do some of that ESO stuff. If there's just a lot of linear dialogue between the player and NPC and the player options aren't interesting at all, I'll try to put some good prose in, mention the background and the emotion of the NPC/the way they are saying this dialogue. I can just paraphrase the player dialogue and it still gets in there anyways. Not as easy to locate, but, eh, it's no big deal. And I'm sure there's better ways to present the prose than switching from normal text to italics to normal text to italics every five seconds (though is it really that bad? I dunno.). That can be talked about endlessly; it's really not too important at the end of the day.
It was a big disappointment to me personally when I saw the ESO pages take the approach in dialogue that they did. I had no interest in the game, but looked forward to reading through some of the NPC pages for those that shared relationships with some of the characters from the games I did play. The one for the Motierre Dark Brotherhood chick in the game is one I remember trying to read through. I ended up reading it all, but it just didn't feel the same. There wasn't nearly as much of a story there, just a somewhat disjointed selection of dialogue (the narrative format is really good at doing some recap if the character hasn't been around for a few quests in the storyline or not all the events in the storyline are captured within the context of the player and that character's conversations). And this is no discredit to the editor who wrote the page, who easily put in just as much work and was just as brilliant as any of the editors who worked on the Oblivion and Skyrim NPC pages.
I'm well aware that the above isn't really a valuable addition to this conversation. My intention was to purely capture the way I feel about the NPC articles in those namespaces and the magic I felt in them that drew me to this site and made me want to create those myself. To provide a logical argument, an easy one I can think of is can you justify such a change for what the benefit would be? Do you realize how much time it would take to re-write all the Oblivion and Skyrim pages in this style? And what would the end benefit really be? A subjectively better dialogue format does not seem like a good enough benefit to justify the amount of work in my opinion. Unless things have changed in the past few months, there's a ton that still needs to be done in these two namespaces than mess around with completed pages, many of which are featured articles. Oh yeah, look at the featured articles sometimes. You'll notice a lot of them are for Oblivion and Skyrim NPC articles. Don't see many Morrowind NPC articles. Don't see many... oops! There I go with the opinionated stuff again.
Looking at the amount of time it took me to type all this nonsense out, I don't think I'll be following this conversation further. My free time is limited these days, and it's stuff like this that I'm trying to avoid! But, given my editing patterns in my time here, I felt I had to weigh in on this. I just unfortunately couldn't do it in a more useful way. I mean no harm or offence to anyone in this response; our ESO editors are the best and are important in keeping UESP alive for many years to come. This ghost from the past just wanted to express his opinion as being a lowly reader these days. And he will be very sad if he wants to do another read through of Amusei some day in the future, and finds a comprehensive, easy to navigate dialogue listing instead of a beautifully penned (typed) article. Forfeit (talk) 02:54, 23 August 2018 (UTC)
I agree with the sentiment of Ilaro's proposal. I have always found the dialogue nesting of the Guild Wars 2 Wiki to be very useful in understanding everything an NPC can say in given situations. Here is a decent example of some archived text: https://wiki.guildwars2.com/wiki/Braham/dialogue
To the two that have opposed this suggestion, you have essentially argued that you prefer a format where information is more difficult to find. I think the opposite goal is desirable for a wiki: ease of use combined with completeness, which aligns with our style guide.
One thing that I think is also worth considering here is whether all dialogue belongs on an NPC's page, or if quest specific dialogue should instead be moved to the Quest's page. GW2 tends to do it the latter way, though I think it's difficult to make a hard, consistent line between the two. I do think the Neloth and Amusei pages should be trimmed and transplanted substantially, having just read them both. --Lost in Hyrule (talk) 04:13, 23 August 2018 (UTC)

() I support the proposal to include player dialogue, though I'm not sure how practical a conversion will be. I think those opposed bring up a good point, however, in that prose can make the page more approachable as a story. Therefore, I think the best approach may be a series of summaries followed by the actual dialogue in a Showhide template. Note that I only mean this for direct conversations. NPC conversations, greetings, farewells, and other dialogue like that should probably go in tables or lists if it's not already.

For example, part of Delphine's page has this wall of text:

Once below, Delphine will make her way to the table in the center and lean over in front of a Map of Dragon Burials. She begins, "The Greybeards seem to think you're the Dragonborn. I hope they're right." She will express her distrust for the Greybeards if you tell her that they are right about you: "I hope so. But you'll forgive me if I don't assume that something's true just because the Greybeards say so. I just handed you the Horn of Jurgen Windcaller. Does that make me Dragonborn, too?" You can ask her if she was the one who took the horn, to which she will reply, "Surprised? I guess I'm getting pretty good at my harmless innkeeper act." If you insist that you're to meet someone here, she will say "I hope you're just playing dumb. I'm the one who left the note in Ustengrav."

Here's what I think it should look like:

Once below, Delphine will make her way to the table in the center and lean over in front of a Map of Dragon Burials. She begins, "The Greybeards seem to think you're the Dragonborn. I hope they're right." Her responses to your questions indicate that she does not trust the Greybeards and that she was in fact the person who took the horn and left the note in Ustengrav.

With this method, a few problems are solved: (1) player dialogue is documented completely and the branches are preserved, (2) walls of text back and forth between introductory phrases and long dialogue lines in italics are avoided, and (3) dialogue does not clutter the page and the page can be read fairly quickly as a story. —Dillonn241 (talk) 05:01, 23 August 2018 (UTC)

1) The goal of the wiki should be to make knowledge about the game accessible to people. Large paragraphs where sentences alternate between italics and regular are not accessible. It's not very readable. It's bad formatting and bad design. Read about readability. And grasping at straws to insult people for wanting to be able to read and find the information they want has no place in this conversation.
2) I think people just saw the words "ESO NPC pages" in my first post and skipped over everything else. I'm not saying do away with the prose entirely! I think Delphine is an excellent page, and I think ESO NPCs could do a lot more in the prose description department. But- and this is the point I was trying to make- the full dialogue transcripts should be there too. And when dialogue is worked into the prose, you need to be careful about the formatting. I like Dillon's suggestion above. You get the prose, the context, and you get the full dialogue.
3) Delphine may be a good page, but one good page does not disprove the existence of this problem. Let's take a look at another NPC page, General Tullius. It's pretty good, well-formatted, until you get to the Joining the Legion section. You have Tullius's coversation with Rikke nicely laid out, and then boom. Giant paragraph. And just for fun, let's remove his dialogue and see what prose is left behind:
I only see a couple of lines there were using prose instead of the player dialogue actually gives you any additional information.
4) So really, I'm going to say it again: I'm not saying do away with prose descriptions completely. They can be and are well done- we have plenty of examples of that. But there are also plenty of examples where it is poorly done, poorly formatted, and doesn't add anything that the player dialogue wouldn't. I am fully in support of a more hybrid method, just maybe with more of an emphasis on full transcripts than is currently done.--FioFioFio (talk) 13:03, 23 August 2018 (UTC)
I'll repeat roughly what I said on Discord. There is nothing to say we cant use both styles. When I wrote the Dragonborn:Neloth and Skyrim:Lord Harkon pages I heavily relied on the dialogue tree structure, because its well structured, easily scan-able and good for when you're citing dialogue in lore articles. But there is plenty of prose in those pages too. Both work well together. Readability massively important as Fio said, so that is why I'm a big proponent of using multiple headings, tables, different colored backgrounds, etc on the aforementioned pages to help with that.
Nobody on the wiki is wholesale removing player dialogue lines, so I'm not really sure why this is even a topic. This discussion is not overdue because we are already doing what is being proposed - and no one has had a problem with that. Just keep adding all dialogue as we have been doing.
When one of the main characters like Sai Sahan has a full page up, I'm certain it will be somewhat similar in format and structure to one of the FA Skyrim NPC pages. The Online:Razum-dar page might look long, but that's because the entire page needs some attention to make it better and not just a dialogue dump. --Jimeee (talk) 13:18, 23 August 2018 (UTC)
Correct me if I'm wrong, but Ilaro's original point was about adding player dialogue to pages, because it's generally lacking in SR/OB-space, not about anything having been removed. Just to clarify.--FioFioFio (talk) 13:39, 23 August 2018 (UTC)
I would only support adding player dialogue to old Oblivion and Skyrim pages if its done well, as in the case of Delphine, Neloth etc - not a mass text dump of dialogue like Razum-Dar. But lets be honest - no one is going to go back to old Oblivion and Skyrim pages and revamping them any time soon. ESO pages are the priority IMO. --Jimeee (talk) 13:59, 23 August 2018 (UTC)
Unfortunately for anyone who thinks otherwise, this conversation is about applying at least partial ESO "standards" to previous namespaces. The people who are editing ESO have clearly chosen a different approach to NPCs, which is different to the approach that multiple projects have taken towards NPCs in Oblivion and Skyrim, and one of the major points of those projects is to treat NPCs as people and not objects, which prose does and the (for want of a proper term) ESO approach does not.
The major difference between the two is that ESO NPCs rarely have any involvement in quests beyond standing still and talking. I would hazard a guess that 100% of the dialogue on ON:Lilatha is spoken without her moving between sentences. A fair bit of the prose in OB and SR is describing the movements, and then there is the different emotional states between lines. That cannot be replaced by the player dialogue. It is bland, it is emotionless, and it doesn't tell you where or how an NPC said something. A lot of dialogue is said without activation, just by being nearby and under certain circumstances, none of which can be described if it isn't there.
Another point that seems to be being misrepresented is that information will be removed, there is no way it cannot be if you switch (even partially) from prose to using player dialogue. You cannot preserve the information found in the prose if you remove it. Adding the player dialogue adds a different set of documented information. Removing "some" of the prose is still removing that information. As you can see from the examples above, the proposal is doubling the length, at a minimum, and these big pages are extremely long already.
I find it insulting that people criticize "prose-italics-prose-italics" and want to replace it with "bold-italics-bold-italics" (and on separate lines), yet they don't see that it is actually considered worse to have that amount of emphasized writing next to each other by every professional writer (nor that it is basically swapping one "unreadable" style for another. That article about readability is irrelevant, because it completely ignores the situation where you have certain information that you need to convey and can't alter how that is presented (or in simple terms, we have huge amounts of dialogue that always needs to be italicized). No normal wordy website (wikipedia, news, etc) that has a need for readability has as much dialogue to include, nor would it have a formatting constriction on top of that. Most would be restricted to some short quips or quotes, in part because the advice on "readability" includes only using short quotes and not long paragraphs of quoted dialogue.
Before anyone starts, Razum-dar was used as an example because it was the first I found that could be compared in length with Delphine, and Lilatha above is a proposed featured article, therefore considered "to be of the highest quality and should be held up as an example for other articles". I'm going to call out this statement: "one good page does not disprove the existence of this problem". You are aware that the topic was opened by using "one bad page to prove the existence of a problem", as well as an example of a "problem" that is completely irrelevant to the topic. If the bad page was brought up to the standard of the good page there wouldn't be an actual problem, just a theoretical one about choosing to include all player-dialogue. There also seems to be a complete and utter disregard for the fact that the pages those "opposed" to this are highlighting actually include a whole lot of player-dialogue. We are not opposed to player-dialogue per se, we are opposed to using the format seen on ESO pages as the standard for OB and SR, when those pages are already of a better standard, readability, and at a much higher level of completion. Player dialogue is comparable to using images and tables and such, used appropriately it can help break up walls of text, but at a basic level, it is not necessary or needed in order to fully document an NPC. Silence is GoldenBreak the Silence 19:23, 23 August 2018 (UTC)
Whether "in retirement" or not, Forfeit has summed up the way I feel we should approach dialogue in a much better way than I ever could. One problem I have with recording all player dialogue and NPC dialogue together in the "ESO style" (if we're calling it that) is that it ends up like a transcript, not an encyclopedic article about the character. The encyclopedic page style that we strive for and are known for is much more presentable in a prose narrative, as Forfeit said. I have a vehement dislike of the transcript style overall primarily due to it coming way too close to my personal interpretation of the red line – if everything is a direct transcript from the game, there is no longer a need to buy the game, and nothing hits that faster than transcribed text. Prosifying and paraphrasing dialogue falls under illustrative and transformative fair use in such a way that I believe transcription does not (and I am always surprised that sites such as this get permission to transcribe in-game and companion texts to the degree that we have done, particularly when they also sell them directly). Player dialogue, particularly when not directly relevant to documentation of the character (in terms of them being a character in a world, not an interactive object), is something for the player to experience themselves as part of gameplay, not on a website. --Enodoc (talk) 20:47, 23 August 2018 (UTC)
Permission is a non-factor here, considering both the explicit and implicit permission we get from the copyright holders to host this material. I would say a majority of the content on the wiki pushes the limits of transformative fair use. The understanding we have is that if the developers object to our hosting of certain material, we will take it down. Muddying the waters of this discussion with tangential copyright law debates is not productive. If you feel that dialogue is "something for the player to experience themselves as part of gameplay", that's a personal preference.
I have to concur with Jimeee's point above: we are already doing what is being proposed. There is no barrier to documenting player dialogue (as I tried to illustrate above with Oblivion:Kathutet), so if editors want to go ahead and document it I do not see the issue. —Legoless (talk) 21:18, 23 August 2018 (UTC)
Personal preferences aside, the relevance (or non-relevance) of player dialogue to the documentation of a character and their development is an important point to consider. Documentation of a character has not previously required extensive transcriptions of the player dialogue side of those interactions, and I see no real reason for that to change; the stuff that is necessary for further analysis of the character is included, and the rest of it isn't. I wonder though if we are gravitating towards this style for ESO specifically due to the lack of a CSList-style database with this all in – for the previous three games, a pretty full dialogue transcript for a character is only one search away, but that's not the case for ESO. ESO documentation on the wiki may have gone the way it has because we have been trying to compensate for the lack of that secondary database; ESOlog is great, but is not (and cannot be) on the same level as CSList. --Enodoc (talk) 22:00, 23 August 2018 (UTC)
I don't think the situation is all that different between ESO and the other games. You can search dialogue in CSList, but it's a blind keyword search: you can search by dialogue content or editor ID, and what you find won't be shown in context or in order. That's basically the same thing you get from downloading ESO's lang file, cracking it open, and pressing Ctrl + F. Unless there's something in CSList that I've missed, if you wanted to do something like listing out every line a character is capable of saying, you'd need the Creation Kit, and then you'd still only see the raw dialogue out of context. For ESO and the main-series games alike, the wiki's transcripts are the best option for reviewing character dialogue. DavidJCobb (talk) 04:28, 24 August 2018 (UTC)

() There are a lot of good replies and counter-arguments here and I'd like to address as many as possible.

First and foremost, I'd like to remove the weird conception that this proposal would completely remove all prose style on NPC pages. I'm not against that. SK and OB npcs do many things in-between dialogues, so those kind of things would still stay. For example, looking at Delphine's (excellent) page, shows me that a lot of the prose are either descriptions of Delphine's behavior, or are instead of the player dialogue. To be honest, I believe even this page would improve if the latter one would be changed into the real player dialogue instead of prose.

To take some steps back, I am mostly surprised that it wasn't questioned who will change/fix it (because other games are a much higher priority right now). I do not have the illusion that even if this idea will be accepted (and I see quite a bit of controversy) that all these pages will magically change into the new style. However, the idea is mostly that new pages can use this style without being reverted or get incomplete tags. In the end, this would be a gradual and probably quite long project (I mean, one of the most prominent Skyrim NPCs is even nowadays still a stub: Arngeir, there are just so many other things that everyone can or wants to work on).

If this all is compared with ESO NPCs, there are quite some things to consider. For one, NPCs are much more static than their previous counterparts, but more importantly, ESO is a beast of a game. There is much much more information to process than any previous ES game. This results in many content dumps without considering lay-out/details, because a page preferably has bad lay-out with a lot of content, than a good lay-out and no content. It just takes a lot of time to add prose and other details for ESO pages. (+there is no CSlist or Creation Kit to look up any information you want. If you miss something, you need to somehow redo everything manually.) However, as tib showed with Earl Leythen, it can be done almost as well as Delphine's page. There are still some lay-out issues and maybe needs some more info in-between dialogues, but that page is still a work in progress.

Concerning me previous statement of "content is more important than layout" does not mean we shouldn't consider the lay-out the moment we'll work on it. Spoonfeeding information to users was mentioned before as if it was something bad. I would go the complete opposite way. Spoonfeed as much as possible, because a wiki is to provide information as accurate and easy as possible. People come here to find information. The longer it takes to find it, the quicker they'll try to find it somewhere else. Walkthroughs and dialogue sections are there to lead a person through the quest or find specific strings of info, and it should contain the editors interpretation as little as possible.

This comes to the notion of "documenting everything". In case of Legends and ESO I would say: yes! It is possible that those games will be inaccessible in the future. In case of the other games I would almost say yes too. Documenting static objects already go a long way in adding maps of dungeons/places, just like documenting the looks of a person (you don't have to describe something to document it). However, documenting meshes of rocks or placement of furniture are no high priority and will open up a completely different problem:

While there are many things we could document that would violate fair use, I don't think it is a concern here at all. We are by far not the only one documenting player dialogue and Bethesda doesn't seem to care in those cases either. While I can see why, I don't think we should leave things "for the player to experience themselves". In my opinion, questlines should also be experienced by the players themselves, but we still document walkthroughs as thoroughly as possible, including suggestions on how to complete dungeons.

In the end, I can't make people to prefer one style over another. A wiki works on consensus, so if there are enough people that dislike or disagree with it, I will make no fuss about it. I have the best of the wiki in mind and I sincerely think these suggestions could improve it, even if they are perceived as bad. I also believe I can be swayed by good arguments against my proposals, so I am more than willing to listen to them even when they are presented in a nice way (How else am I going to improve my ideas? I do not claim to have thought about everything). --Ilaro (talk) 14:35, 24 August 2018 (UTC)

Edit Break: Dialogue[edit]

I felt like chirping in with a few thoughts of my own because my watchlist is exploding with novellas. While I'm not completely opposed to the idea of documenting all NPC dialogue as a fan of thouroughnes, we do need to be careful with how much we put into articles and what it's about, in my opinion.
Using a proposed Featured Article as an example, while there's nothing wrong with documenting dialogue like this, I feel like while the style guide prefers content over accessibility at the end of the day, it does say there should be a healthy balace. After all, the UESP needs to be accessible to the average reader, or who will want to visit us? Big dialogue trees, when used correctly, can be very informative, but for games like Skyrim or Oblivion, which are being proposed for this type of content, we can expect to lose navigability when we start including every player spoken option we can find, which would invariably include some random like like Belethor's "if I had a sister, I'd sell her in a second" crap. If we can healthily incorporate and improve accessibility for quest or critical dialogues to the character (Heimskr's Talos speech can be considered important to his character, for instance) in a clean and navigable way, we should go for it. If we're including content for the sake of content, eventually there's a tipping point in my opinion where there is such a thing as too much information. As was said above, in MMOs, the dialogue is almost exclusively related to quests, at least in my week and a half of ESO experience, so we don't have much per character to incorpotate, but for major singleplayer characters, we can easily triple page lengths.
My other concern is who's going to do all of this stuff? We have a lot of backlogged Projects as it is that aren't getting attention, especially if they were created after the fact like MWOP for instance, and there's not much interest in the current community to do them. Skyrim was such a big release that it's still relevant to a lot of people, but older games like Oblivion are falling off the radar for most gamers now being over a decade old and replaced by newer titles including an upcoming TES VI, which immediately will pull away almost every editor dedicated to any existing projects since we'll have to work on controlling quality as information and new users flood in. I'm concerned about whether as a project or an informal discussion to eventuall do it, will it ever be done in a consistent and satisfying way once we agree on what can be considered useful and what an agreeable style for incorporating content is? Besides, while "all articles should be informative, it also goes on to say that information only important to the author or to other editors shouldn't be included in the articles. As I said, we need to worry about what's actually usable to the average user who wants quick information that's readily accessible and not lost in large text trees. -damon  talkcontribs 15:23, 24 August 2018 (UTC)
I wouldn't worry about a lack of people interested in making these kind of edits. Wikis are an eternal work in progress, and some wikiprojects sit idle for years before being taken up again by interested editors (e.g. SSCP which is currently very active despite the age of the games). —Legoless (talk) 17:26, 24 August 2018 (UTC)

Dungeon Boss Mechanics proposal[edit]

Simply put, I think every location page we have for group dungeons and trials should include include a boss mechanics section for each boss. Yes, this seems odd and your first reaction is to think that such info belongs on the boss page under "Skills and Abilities", not the location page. Bear with me.

Boss mechanics (especially Veteran) are a prominent feature in dungeons, tricky to learn and for first time players not always clear. Users may naturally come to our Dungeon location page first if they are having trouble with a boss, but there with will only find basic info about enemies, rewards etc. They may click on a boss in hope of getting more info, but the boss page sometimes also basic (however some do have decent notes about their mechanics). Users might need to do that for every boss as they progress though the dungeon and all this clicking back and forth isn't a great experience.

My proposal is to centralize the mechanics info on the location page so it serves as a dungeon guide of sorts. We keep all the info as we have now, but have a new section labeled "Boss Mechanics" (which I have found is the term most in the community use). Then a new header for each boss, with a short, extremely objective description of this bosses mechanics and how it can be overcome. Info about strategies or optimal classes etc wont be included of course. Also, not every single boss will need to be listed if they have no unique mechanics.

This is good for a few reasons. I think it will encourage editors and regular visitors to fill in missing boss mechanics lacking on the site if they see them all listed on one page. Also, users don't need to keep clicking back and forth or have multiple tabs open - all they need to clear this dungeon is on one page.

Anecdotal, but since I started playing, my first port of call on a tricky boss has been reddit or youtube to learn boss mechanics (I still don't knew exactly what triggers Z'Maja's insta-wipe!) - partly because I knew we don't really list boss mechanics in an easily findable format - and I'm sure that's the case for many. What's worse is when grouped with randoms who don't understand the boss mechanics and trying to explain it to them in the chat. It would be great and so much easier to just tell these people to "google uesp Crypt of Hearts II" (instead of "google uesp Ruzozuzalpamaz") and know that they can learn the entire dungeon mechanics from one page. I think this might help change that. --Jimeee (talk) 09:16, 31 August 2018 (UTC)

We include walkthroughs on dungeon pages in other namespaces so I always figured this was something we were going to get around to doing eventually. It's definitely an excellent idea to try to make our ESO dungeon pages the go-to place for mechanics guides. Seems like a non-controversial proposal to me. —Legoless (talk) 12:21, 31 August 2018 (UTC)
That's what I figured. Instead of detailed walkthrough prose about the dungeon itself (as seen on older namespaces), I believe the value of Group Dungeon pages are the details of the boss battles themselves, which is why a separate section for them might work better. Given Wolfhunter has just released and people will no doubt be looking for guidance on the mechanic-heavy bosses, I think I'll try a prototype on those dungeon pages. --Jimeee (talk) 15:28, 31 August 2018 (UTC)
We should probably really have both (dungeon walkthrough and boss mechanics). Anyone searching for the boss specifically may expect to find it on the boss page too, so I would suggest putting it on the boss page and then transcluding to the dungeon page. --Enodoc (talk) 17:21, 31 August 2018 (UTC)
I agree too. Group Dungeons in particular don't have much else in them anyway. I also think Enodoc is right, if people are struggling with one boss in particular they will likely search for that boss by name. I don't think this is needed for bosses that are easy for the average player, but a few lines on their weakness or strengths would be what other games would include on the dungeons, with a more detailed analysis on their personal page. Each boss page should be expected to have details on any unique mechanics, and even details on shared ones. Silence is GoldenBreak the Silence 20:56, 31 August 2018 (UTC)
Agreed. Listing the mechanics on the boss's page and transcluding it to the dungeon page seems like a good practice. --Xyzzy Talk 13:20, 1 September 2018 (UTC)

Replacing Userboxes on User Pages[edit]

Sometimes users copy the code for a userbox template instead of using it directly. It's not a big deal, but this ends up creating more work when things need to be changed and can result in broken userboxes. It also sometimes leaves the user out of the userbox categories (subcategories of Category:Users).

There's no policy I know of that makes it okay to replace a use of {{Userbox}} with the templated userbox on someone else's user page, but I think this should be allowed so long as the appearance is unchanged or negligibly different. In some cases, the text may differ, but most userboxes (all of them should support it eventually) allow for the text to be changed with a text parameter. The same goes for colors. —Dillonn241 (talk) 15:32, 8 September 2018 (UTC)

Full disclosure: Dillon and I have already discussed this on Discord and I suggested he make a post about it, so we can make it a formal policy. Obviously, I support this idea, as having copy-paste userboxes really just makes more work all around. While there are times when customizations might be necessary that the userbox can't natively support, these times are rare in my experience, and in those few cases, we can certainly leave the user's page untouched. In any instance where a userbox can be used to duplicate the copy-pasted code, though, I feel it should be changed unless the user raises an objection (e.g., intent to modify it later on). Robin Hood  (talk) 15:39, 8 September 2018 (UTC)
If the appearance is unchanged and the user doesn't object, I don't see an issue. —Legoless (talk) 15:49, 8 September 2018 (UTC)
I don't understand how copying working code can result in the code breaking at some point in the future because someone changes the template, the two things are mutually exclusive. There is also a huge difference between someone copying the code from a userbox's template page and using the Userbox template to code their own version of a userbox that has a generic existing template, and these two things should not be conflated with each other. I don't believe there should be a policy on "this", as user-pages should be left alone as much as possible. You should never arbitrarily change a manually written userbox using the {{Userbox}} template for a generic templated one.
There is no issue with replacing the copied code for the template, as it is always a mistake. It is usually easily spotted as a mistake by the inclusion of the template category, so you can tell instantly that the user has misread the instructions on how to add the template to their page. If it isn't a maintenance edit (which fixing templates are) a user page should be left alone, however, should you feel the need to change a user's page for a non-maintenance edit you need to post to their talk page to explain what you have done, because you can easily offend someone by mucking about with their attempts at personalisation.
There are many reasons why someone might prefer to use a manually written template, one of which is to keep themselves out of the categories, another of which is the wording. For example, any of the game templates state "This user is knowledgeable about..." and adds you to the category "Users Knowledgeable about..." but a user might just want to state that they have played the game, not claim to be knowledgeable about it. Conversely, I can claim to be fairly knowledgeable about Morrowind, Arena, and Daggerfall, but I only use the userboxes to show which games I have played, and someone looking at my userboxes (if I had a Morrowind box) would assume I had played the game to be knowledgeable about it. Silence is GoldenBreak the Silence 18:51, 8 September 2018 (UTC)
Perhaps this can be limited to cases where the user has copied the category as well. I've come across several of these and they are primarily what I intended to replace. As a side note, there is a {{User Owns}} template that doesn't add any categories, but I understand your point there. —Dillonn241 (talk) 19:00, 8 September 2018 (UTC)
My understanding was that this was strictly about copy-pasted userboxes and those where it's a copy-paste with customizations that the userbox already handles properly which, perhaps, the editor didn't realize it could do. The example of only changing text and nothing else (i.e., retaining categories) is exactly the sort of thing I believe we mean. If someone copies the code without the category, then that becomes a substantive change and should not be replaced with the original userbox. (Although, that said, it shouldn't be hard to add a "nocat" parameter to userboxes, like we do with so many other things.)
As for how userboxes break as a result of copied code, consider the case of updating an image in a userbox. Let's say someone uploads a new high-resolution version of the image, where the original was "userbox-sized" and thus never had a size specifier attached to it. The person that copied the code might now have a 1000x1000 pixel image on their page instead of a 40x40 pixel image. The original userbox would be edited to adjust the size and fix it globally, but the copying user's page is now broken, and has to be fixed manually. If the only thing they had actually changed about the userbox was the text, then the original userbox with a text= would have worked fine, and would have been fixed by the centralized change. The copied userbox code just plain breaks. Robin Hood  (talk) 20:16, 8 September 2018 (UTC)

Tense Templates[edit]

Just so everyone's aware, Dillon came up with a new, generic design for a {{Tense}} template (still needs documentation as of this posting). This will replace the old Tense template, now at {{TenseOld}}, as well as the {{MWTense}} and {{OBTense}} templates. The reason for the change is that the old Tense template didn't work like the other two, and only handled a limited set of words which weren't always the words we wanted. Take, for example, "can", which might change to "could" or "could have" or "could've". Plus, anything that fell outside those defined words would simply spit out whatever word was provided unchanged. These differences led to a lot of misuse of the Tense template, and the fact that it was a limited word set led to some words being used that the template didn't actually handle. The namespace-specific versions were more versatile, but when needed in more than one namespace, they led to template calls like {{MWTense|is|{{OBTense|is|was}}}}, which is not tremendously intuitive. In short, it was a freakin' mess! About the only advantage to the older templates was that when they did use the actual words you were looking for, they were a bit shorter and less repetitive.

The new template is simple and works on a similar principle to {{Nst}} and {{Lore Link}}: {{Tense|present tense|past tense|NS=1}}, where NS is whichever namespace(s) you need, like |MW=1|OB=1, for example.

I've converted all of the Tense and OBTense calls already. By the time I actually post this, the bot will have gone through and converted the MWTense ones that are simple tense changes. The others will need a human to look at them, but most, if not all, should probably be converted to Nst. I'll look at those after lunch. In theory, all Tense calls could be handled with Nst calls (e.g., {{Nst|was|OB=is|SR=is}}), but Tense avoids having to retype the same word(s) multiple times, so I think it's probably a good idea to keep it as a separate thing.

Just wanted to make sure everyone knew about the change, since it's a bit different from how things have been done so far and affects three different templates. Barring any objections, I'll delete all three of the older templates in a few days. Robin Hood  (talk) 19:32, 11 September 2018 (UTC)

No objections, but I would or would have supported a move to Nst use only, if only for user-end simplicity. That said, a specific template should save a user from trying to figure out all the specific versions needed for each namespace. Silence is GoldenBreak the Silence 20:19, 11 September 2018 (UTC)
That's always an option in the future, and with all three templates harmonized into one, it'll be a lot easier to do if we want to go that route. Robin Hood  (talk) 20:20, 11 September 2018 (UTC)

Move Creation Club stuff to own namespace or into TESVMod: namespace[edit]

This side stuff of mods should be in a separate namespace, perhaps CreationClub:, shortcut CC: (we're already using that in CC note form), to keep it separate from the rest of the Skyrim material.

Another idea would be to move it all to the TESVMod: namespace, in a subcategory thereof, and without a CC: shortcut (what is now Skyrim:Creation Club would be TESVMod:Creation Club, and the main article for that subcat). That might actually be cleaner. Treat it the same way we treat Tamriel Rebuilt (TES3Mod:Tamriel Rebuilt) in relation to Morrowind, and so on.

This stuff isn't comparable to the official Dawnguard, Hearthfires, and Dragonborn add-ons:

  • It has nothing to do with Skyrim ("Oldrim"), not even Skyrim Legendary Editon – only Skyrim Special Edition, which is not really the same game in some senses.
  • It's random third-party fanfic content – not canonical, just approved for sale. It's not really any different from mods being sold via Steam Workshop.
  • It really is just mods. There's nothing special about them; everything they do has equivalents done in other mods on Nexus, etc., that are free.

It's misleading, unhelpful, even frustrating to have this stuff in the Skyrim: namespace as if it's an integral part of the game. Most of the notes pertaining to CC stuff should probably be removed from the main articles, or at best shunted into bottom notes, which clearly mark them as SSE-only notes.
— Darklocq  ¢ 22:32, 19 September 2018 (UTC)

No, no, and no. This was already decided about a year ago, when an official Bethesda employee confirmed that Creation Club is official content, as official as Dawnguard or Dragonborn. It's comparable to the official plugins for Morrowind and downloads for Oblivion.
To answer your three points:
  • Skyrim Special Edition is documented within Skyrim's namespace and is by no means a new game. All it does is overhaul the graphics, move the engine to 64-bit, and a few other things.
  • Co-developed by Bethesda so not third-party. It is in fact canon if you consider official content to be canon, which is the definition UESP uses.
  • Dawnguard, Hearthfire, and Dragonborn are "mods" too; the fact that third-party mods have done the same thing is irrelevant.
I agree that this is a bit awkward since Creation Club uses Dragonborn assets, which are all in a separate namespace. However, that's a problem with the Dragonborn namespace. The plugins and downloads for the previous games are both documented in their parent namespace. Not to mention that all of the existing Creation Club content exists within the Skyrim namespace already and moving it would be a daunting task for no gain. —Dillonn241 (talk) 22:57, 19 September 2018 (UTC)
Still not a good reason to not shunt this stuff out of the main game namespace, since trying to use it with actual Skyrim, not Skyrim SE, won't work and is liable to CTD you. We have namespaces for a reason (several reasons, actually). DG, HF, and DB are not mods in the definition we use here. They're official expansions. Yes, they "modify" the original game, and some pendantic definition of mod could be used to classify them thus, but it's not at all what we mean by "mod" here, and I'm pretty sure you know that. The CC stuff was created by individual, non-Bethesda modders like Elianora (maybe there are some exceptions; I did not pore over every single one of them). The fact that they've being given a stamp of approval to be sold doesn't make them part of Skyrim proper. They do not work in Skyrim proper, at all. Only in SSE. — Darklocq  ¢ 23:04, 19 September 2018 (UTC)
Oppose per current consensus and per all three points raised by Dillon. The above proposal displays a serious lack of knowledge in relation to SSE and Creation Club, particularly as regards Bethesda's approach to same. Claiming that Creations are "fanfic mods" made by "non-Bethesda modders" and that SRspace is for "Skyrim proper" shows a complete failure to consider the subject matter of this proposal, a failure which should really be considered terminal for this discussion. Elianora is a Bethesda employee. "Skyrim proper" isn't even being sold on Steam anymore unless you know the store page URL, while SSE/CC are receiving continuous developer support. There are just too many holes in this proposal for me to even outline them all in brief. —Legoless (talk) 23:26, 19 September 2018 (UTC)
I agree with the others. CC is just too small and too diverse to really make sense as its own namespace. While I too find it annoying sometimes to see things that don't apply to me, Creation info should all be marked as being specific to a given Creation, so it should be obvious at a glance what's what. Splitting it out would only produce a bunch of stupendously small pages and add to site upkeep. Conceptually, it would be like splitting all the small OB and MW add-ons out. It doesn't make any more sense to do so here than it did there. (And you just know that at some point, someone's going to argue for each CC to have its own namespace, which would make things even worse.)
The fact that Creations only apply to SSE is irrelevant to me (particularly the argument about attempting to use Creations in Oldrim, which is not a supported configuration). We're not about to split Oldrim and SSE into two namespaces, since they're 99.999% identical, so how is it any more beneficial to split out CC? All the same problems occur, since the original pages still have to have links to CC pages where relevant, only now you've added work to everything by putting some stuff in a new namespace and requiring cross-links between them. Robin Hood  (talk) 01:21, 20 September 2018 (UTC)
This split would fly in the space of existing namespace logic, and if we were to reconsider namespace policy, I honestly think the other direction makes a lot more sense. For your primary points, there isn't a major difference between the different versions of Skyrim, It is canonical content, and while it is basically a mod it has the air of official content thanks to Bethesda's involvement. --AKB Talk Cont Mail 06:15, 20 September 2018 (UTC)
Oppose: Per most other comments here, this would only serve to fragment and disorganise our content covering Skyrim. Quite frankly, I feel this policy would actually hurt the wiki more than help it. — J. J. Fullerton talk﴿ 07:51, 20 September 2018 (UTC)
Very well. I'll buy the reasoning that it wouldn't be helpful in the end and too much of a fragmentation. I remain skeptical about several of the other arguments, especially given the debate way above about redefining the canon level of various resources. But I also know when to concede when an idea is consistently opposed. — Darklocq  ¢ 02:59, 3 October 2018 (UTC)

Move Dawnguard stuff to own namespace[edit]

It's weirdly inconsistent with all other major DLCs/expansions that Dawnguard doesn't have it's own namespace; it should be Dawnguard:, shortcut DG:, to go along with all the other DLC namespaces (Dragonborn:, Tribunal:, Shivering:, etc., etc.). It's really not user-helpful to have this one be so different, and require guessing at names like Skyrim:Dawnguard Quests, etc. Just do it the same way as Bloodmoon and the like. — Darklocq  ¢ 22:54, 19 September 2018 (UTC)

You have to realize how much work is actually involved in this task. Bots can help but a lot of things, especially with templates, need to be reworked. If we're going to be changing existing namespaces, then we should be merging Dragonborn into Skyrim instead. The reason Dawnguard doesn't get its own namespace is the same as Knights of the Nine: most of its changes are to the mainland. Dragonborn got a namespace like Shivering Isles because nearly all of its content is separate.
I think there are much more important projects to be working on than splitting and merging namespaces for a seven year old game. Almost all of the content exists already and has existed without much issue. —Dillonn241 (talk) 23:07, 19 September 2018 (UTC)
Counterproposal: merge Dragonborn namespace into Skyrim namespace. That is the only inconsistency here. —Legoless (talk) 23:27, 19 September 2018 (UTC)
But then wouldn't that mean we should also merge the Shivering namespace into Oblivion, and the Tribunal and Bloodmoon namespaces into Morrowind? What's good for the goose is good for the gander. Croaker (talk) 00:51, 20 September 2018 (UTC)
The original discussion of having Dawnguard as a separate namespace came to the conclusion that it was too small to warrant its own namespace (though as I recall, there were a lot of opinions on both sides), while the parallel discussion for Dragonborn decided it was large enough. I'm not 100% sure, but I think at the time, we didn't know that those would be the only two major add-ons. Personally, I think that the two are close enough in size that whatever we do, they should really both have been treated the same. (And let's not forget Hearthfire...if we split DG out, then we're bound to have someone asking why HF is left in SR space.)
That said, splitting Dawnguard out would be insanely difficult at this point and would leave Skyrim space all but broken on a large number of pages, requiring a lot of human intervention. Merging Dragonborn in, while conceptually similar, might be marginally easier from a bot perspective, and would likely produce a bit less breakage due to the fact that SR space already exists. It would still leave a lot of pages needing human intervention afterwards, not to mention that there would probably have to be adjustments to a number of templates, but I think it probably wouldn't be quite as bad as going the other way around and splitting DG out. Of course, as Croaker mentioned, then we're stuck with the question of whether to do the same for OB and MW.
In the end, I think we should probably just leave things as they are, even if we might have come to a different conclusion if we'd known then what we know now. If consensus goes differently, though, I'll of course get the bot to do what it can, but as a wiki, we have to expect that there would be a lot for us humans to do even after it's done. Robin Hood  (talk) 01:06, 20 September 2018 (UTC)
I would be happier with merging the namespaces together then with further division. However, I would honestly prefer no action to be taken without a commitment of completely revisiting our current views on namespaces. The current rules were basically "Adds significant content that is primarily divided from the main game", and right now our namespace guidelines make sense, but I do think it'd make even more sense to just cut back entirely. A discussion to revisit our namespace policies wouldn't be entirely out of the realm of reasonable, especially right now in between major installments. If we're going to do it, let's do it all the way. --AKB Talk Cont Mail 06:21, 20 September 2018 (UTC)
I am in support of all suggestions for namespace mergers; I agree that having fragmented namespaces like "Shivering", "Tribunal", "Dragonborn" only serves to make navigation more difficult and fragments documentation for no discernable reason. Often, quests or NPCs found in multiple areas that cross DLC boundaries are split in documentation due to the arbitrary distinction of "This gets a namespace". I think our current namespace policy is restrictive and prohibitively complex; mergers, to me, make the most sense as far as policies go. — J. J. Fullerton talk﴿ 07:51, 20 September 2018 (UTC)
Oppose --- While I generally prefer having content segmented by DLC, this is not a priority at all - ESO is. Its a big project and unless someone can show me hard data that the current situation is having an adverse affect on the readership I have to oppose. The cost of doing a complete split or merge outweighs the benefit tenfold. --Jimeee (talk) 09:03, 20 September 2018 (UTC)

() Dawnguard's existence in it's parent game's namespace is entirely in line with precedent and what we've always done. Tribunal, Bloodmoon, Shivering Isles, and Dragonborn all add new worldmasses with their own weather, items, models, unique assets, and so on in a way that's distinctly separate from the "base" world and content. Dawnguard is a DLC that is, by comparison, similar to Knights of the Nine, which is part of the parent "Oblivion" namespace. It adds a handful of unique locations, NPCs, and new items, and it has a couple of new models for static objects, but outside of a few unique locations, it exists entirely within the "base" world of its parent game and doesn't add content on the same scale as the other larger DLC. That's why I support its integration into the Skyrim namespace, but also as RH70 said, this isn't something to easily decide on six years later. Everything about the content is created and documented for being in the base namespace and at this point we're looking at wasted effort to attempt to separate it out from the base namespace when consensus (which admittedly can change even in this discussion with a good argument) has long ago decided it shouldn't have its own space. -damon  talkcontribs 19:08, 20 September 2018 (UTC)

(edit conflict) I agree with the counterproposal of merging Dragonborn into Skyrim. The original reasons for a separate namespace for Dragonborn included significant, separate content; while Dragonborn content remains significant, it has become way too integrated to still be considered separate. That's also why additional namespaces shouldn't be created; the gameplay is way too integrated for such separation. (Conversely, Shivering, Bloodmoon and Tribunal remain as the only official "expansion packs"; expansion packs that were portrayed and presented almost as completely separate games. There's also no need to apply anything decided for Dragonborn to games that are no longer supported.) --Enodoc (talk) 19:14, 20 September 2018 (UTC)
Enodoc is correct, the integration of Dragonborn into the basegame is even greater now that we have, for example, multiple staff enchanters, and quests taking place partly in Skyrim and partly on Solstheim (e.g. this one). SSE considers Dragonborn along with the other two DLCs to be basegame, making our inconsistent use of namespaces far more apparent and difficult to work with. My counterproposal really has nothing to do with Shivering Isles or the Morrowind expansions; as Enodoc points out, the aforementioned are actually true "expansion packs" and are all handled identically in terms of namespace, unlike Skyrim DLCs where Dragonborn is the odd one out.
The initial decision to split Dragonborn off into its own namespace was decided prior to release, with the assumption that it would be Skyrim's first expansion. Instead it was a DLC with similar scope to Dawnguard, albeit far more self-contained within a single worldspace rather than divided across three worldspaces. I think in light of SSE's co-opting of Dragonborn into the basegame and utilisation of Solstheim for the purposes of Creation Club, DBspace now makes even less sense than it did to begin with. Take a look at Dragonborn:Food compared to Skyrim:Food and tell me why the former should not be integrated into Skyrim namespace. —Legoless (talk) 20:54, 20 September 2018 (UTC)
This is just insane. These decisions can only be taken near the point of release, preferably before, as the work involved in doing anything at this point is counter-productive to a stable community. The only way this would be acceptable would be if the task was universally accepted, with at least 50 people fully-committed to fixing all the things you want to break, as well as all the pages mentioning the namespace. I fully oppose any plan that isn't "leave things as they are". This argument is purely based on a philosophical opposition to Dawnguard not being treated exactly the same as Dragonborn, even though they aren't. Go and read the discussions at the time and you will see exactly why DG did not get a namespace and DB did. The reasons are logical, sound, valid, and consistent with previous games. There is no reason that the two should be treated the same. Don't touch the old namespaces because its too much work to change them now, but like some comments above, stopping the practice for future games would be an idea. The practice of namespaces for "large" DLC will always lead to cases where comparable DLC are treated differently. Silence is GoldenBreak the Silence 21:04, 21 September 2018 (UTC)
I've never been particularly happy with the separate DB namespace, as I can't count how many times I tried to navigate to SR:Whatever only to realize it's at DB:Whatever, but I really don't see this as any kind of priority for the wiki. I don't have any real concept of how much could be done by bot versus how much would require human effort, but I would support integrating DB into SR only if it's not significantly disruptive to the wiki's users. As for splitting out DG into a separate namespace, I see zero upside and plenty of downside to this. Firm "No" vote from me. --Xyzzy Talk 06:08, 22 September 2018 (UTC)
I've the exact same sentiment as Xyzzy in this matter. --Ilaro (talk) 09:24, 22 September 2018 (UTC)
To address Silencer's point about the reasons why DB got a namespace - while those reasons were indeed "logical, sound, valid, and consistent" at the time, those reasons no longer hold, as the integration of content with Special Edition has caused numerous inconsistencies in documentation, so much so that Dragonborn having its own namespace is now illogical and much less valid than it was at the time. --Enodoc (talk) 20:01, 24 September 2018 (UTC)

() To be fair, I have no experience with SSE, so I can't say for certain how integrated everything is, but the fact of the matter is that Silencer and the people opposed to the idea are right. We're looking at a lot of tasks, a lot of manpower needed, and more maintence work than anyone should have to bother doing. If we knew what we were going to have to do early on, it wouldn't be too far on to change course, but we have namespaces that have been set up as such for half of a decade. We also need to keep in mind that in addition to the ever-expanding Online and Legends namespaces, we also have an upcoming Blades and a teased-at Elder Scrolls VI. We have a lot of issues that are far more pressing than integrating one fully fleshed out namespace into another. I am 100% in agreement with Silencer, there is no way I'll support any change to the Skyrim and Dragonborn namespaces (or older ones for that matter) that isn't "keep the status quo", though we can consider this issue for future titles when the time comes. -damon  talkcontribs 17:56, 25 September 2018 (UTC)

Collected response:
  • Both of these back-to-back namespace threads (with largely unrelated rationales) have been predicated on UESP being really gung-ho about namespaces. That seems to have been the case when most of the Tribunal and Bloodmoon content was developed. Seemingly less so now.
  • "Counterproposal: merge Dragonborn namespace into Skyrim namespace". Works for me. While the namespaces help editors in arranging and managing content, and help readers to not confuse, say, ESO and Morrowind topics with the same name, they're actually a hindrance for end users and for editors when the content in question is for the same particular base game (Morrowind, or Oblivion, or Skyrim). The average user has no idea whether a particular NPC or item came from one of their installed DLCs or not, and even editors are apt to forget. It ends up vastly complicating things on the back-end side for no actual gain. And this site is unusually redirect-averse, to a really remarkable level. The search feature we force users to rely on isn't so helpful, generally returning results that pertain to every game and every DLC for every game. The combination of these factors makes namespaces not very user-friendly within a particular "gamespace".
  • On the other side: "if we split DG out, then we're bound to have someone asking why HF is left in SR space". And the answer is very simple, the same one as for all the minor Oblivion and Morrowind add-ons (Aside: Morrowind:Plugins is arguably misnamed, since we call them "expansions" in the case of Bloodmoon and Tribunal and "add-ons" in the case of all the little ones; and what's up with "Oblivion:Downloads"? Are we being this inconsistent just out of perversity? >;-). Hearthfire simply doesn't add enough content to bother with a namespace (note how unanimously and strongly this very same argument was presented above against a Creation Club NS split. If anyone's going to make a "good for goose and gander" argument, it is obviously this one, since the discussions are contemporaneous, not separated by years and held by long-departed people). This "insufficient content" argument doesn't really apply (within UESP's namespacing logic, to date) to Dawnguard and Dragonborn, which are very substantive, somewhere within the range of the other major expansions (Tribunal, Bloodmoon, and Shivering Isles). Dawnguard's total resources are only a tad bit smaller than Dragonborn's, and it arguably has a much more marked impact on the game (the Soltheim stuff feels extremely optional, and once you leave the place, in mid-quest or not, it's easy to just forget and never bother to go back). Still, I'd rather see all Skyrim's DLCs merged into Skyrim: namespace.
  • Speaking of ganders and geese: the argument above that no reader interests are affected [enough that we care] by integrated CC content directly into the namspace as long as CC things are labeled CC applies equally strongly to integration of DG and DB content, too. There is no real difference. It's all [asserted to be] fully canonical content with users neither aware nor caring which file the thing/NPC/place came from, and not helpful to the overall project to split up.
  • "this is not a priority at all - ESO is". Speak for yourself. ESO is not a priority at all for anyone not interested in that game (can't run it, or don't like MMOs, or haven't gotten to it yet, or don't like the lore-breaking changes, or don't like the feel of it like some don't like the Star Wars prequels, or ...). Almost all work on the content of this site is done by volunteers, based on their own interest level. You don't get to set priority for other editors or the community as a whole. Whether UESP's management feels ESO has priority, and it surely does for them, as will an eventual (hopefully) Skyrim single-player sequel, that has nothing whatsoever to do with namespacing logic.
  • The major DLCs with namespaces "all add new worldmasses ..." doesn't actually appear to have been the central rationale at all. I don't see a single other person here agreeing with that reasoning, and Dawnguard does in fact add one. You cannot get to Fort Dawnguard overland despite the confusing map marker, and must go through Dayspring Canyon which is a worldspace teleporter just like the one that gets you to Solstheim. All those in favor of the counter-proposal are ignoring this "separate worldspace" reasoning, so even if it had some part in the years-ago discussions it appears to be moot now.
  • "Dragonborn having its own namespace is now illogical and much less valid than it was at the time." I wasn't even aware of SE's integration causing UESP issues, but find this argument in favor of the "merge in DB" counter-proposal even more compelling.
  • "I would support integrating DB into SR only if it's not significantly disruptive to the wiki's users". Redirects "are cheap" and exist for a reason, even if we don't keep some them around forever. The "this site hates redirects" stuff has to be given a much-need rest when it gets in the way of practical matters. Don't let the tail wag the durzog.
  • "But it's hard" (in arguing either way) is an excuse that would prevent all work on anything non-trivial, on any project of any kind (and also relates to the bike-shed effect, i.e. wallow in trivia and in disputation to avoid working on difficult things). An old wiki maxim applies here: Wikipedia:WP:There is no deadline (and it probably goes back to MeatballWiki). Forgetting or ignoring this has a lot to with the unusual level of "resist change just because it's change" stuff that goes on at this wiki (far more so than on any other publicly editable wiki I've ever participated in).
— Darklocq  ¢ 04:00, 3 October 2018 (UTC)

Asides: DLC terminology, and redirects[edit]

Just to ensure we don't leave the asides hanging for another time - the Plugins/Downloads discussion can be found over here (and you commented on it at the time), and I don't know where the idea that this site hates redirects comes from, as we have nearly 30,000. We have so many redirects that we could probably do with turning some of them into full articles. --Enodoc (talk) 18:43, 3 October 2018 (UTC)

Going over the plugins/download/addons/DLCs debate, it's clear that no consensus emerged from it. There were few participants, they each laid out their view on the matter, and nothing appears to have changed – neither toward more consistency for an internal nomenclature across the board, nor toward less consistency, to exactly follow Bethesda's varying per-game marketing terminology. We're still using a kind of random mish-mash. As I said in the earlier thread, using redirects is one way to resolve this, so if you were reading articles for one game where "DLC" (or "Expansions" or whatever) was used, you can get to the corresponding article for DLCs in the previous or next game in the TES series using the same term, even if that's not the real article title.

On redirects in general: How many redirs there are, as a raw number, is a moot point floating in a vacuum; it's devoid of context and cannot be related to how many redirs there should be for maximum reader utility. Compared to other wikis, this one is definitely redirect-averse, and studiously avoids many redirects that are standard practice at other wikis. (More accurately: certain insistent editors and admins of this wiki are unusually redirect-averse, the wiki itself not being sentient. ;-) If you attempt to create one that does not correspond to exact game wording (e.g. British versus American spelling) – and even if it does correspond, to something like the plural or an adjective when the article is at the singular or a noun – someone will flag it for deletion, no matter how helpful it may be to readers. The excuse is always that readers should use the search feature, which is a poor excuse since the wiki's search engine returns scatter-shot results that are often more hindrance than help.

I don't disagree that various redirects (usually to sections) are good candidates for full articles, but that's an unrelated matter. That issue has nothing to do with number of redirects and which ones are reader-useful, but is a matter of whether content is being developed enough and in the right directions. The fact that content development level and reader ability to find the content they seek can occasionally both come up in consideration of redirects and what to do with them is purely incidental. (Analogy: If your restaurant offers 17 varieties of pizza, and three of these pizzas have so much stuff on them they're difficult to cook without either scorching the bottom or leaving the cheese partly unmelted, that has nothing to do with whether you have too many or too few kinds of pizza on your menu, or whether they are appealing to customers, and is only about certain recipes' practicality.)
— Darklocq  ¢ 01:21, 23 October 2018 (UTC)

New UESP Contractor[edit]

I am very happy to announce that I am going to begin assisting with UESP starting next month as an independent contractor. While I've been working on UESP projects for almost the last eight years, I've never been able to give it my full attention or effort. As I got involved with more tasks of constantly increasing complexities, my time became increasingly constrained, and I've had to set aside projects I've desperately wanted to see done. With those limitations in mind, my focus shifted from wiki content production to the social side. I believed it was the most valuable use of my time to help maintain and build up our community through an increasing presence on social media. And I think that was the right choice. We've become a bit more involved with the TES community than we have been in any years past, with more sneak peaks, more exclusives, and more recognition than we've gotten before, and that's thanks to us coming together as a community to push UESP into the forefront where it belongs.

With that said, the work on the social media side has become a bit more complex. We need more regular content, more complex content, and more clever content to keep moving forward. And with those ever rising requirements, the time in a day becomes increasingly small. Thinking up good and interesting content to post or share isn't easy, especially on a daily basis. Now that I shall be operating as an independent contractor, I will be available for a considerably longer period of time than before, alleviating most of these issues.

While my work will primarily still be on the social media side, I hope to dip back into wiki editing again since I will have better availability. I'm also not "locking" everyone out of social media, just because I will be doing it on the regular. Anyone interested in the social side of the site is still welcome to assist!

Again, I'm very happy to announce this. I've been a huge fan of the UESP for longer than I've been an editor, and I am excited to finally be able to give the UESP my full attention! --AKB Talk Cont Mail 10:09, 26 September 2018 (UTC)

Congratulations to AKB! —Legoless (talk) 11:35, 26 September 2018 (UTC)
Indeed! Congrats AKB! Well done! Timeoin (talk) 19:54, 27 September 2018 (UTC)
That's wonderful, congrats and hugs to AKB! Tib (talk) 20:00, 27 September 2018 (UTC)

() A few things I'd like to note . I've been very pleased with the work AKB has done on the social media side of the site and being able to hire him full time means he can devote his full effort to the project and hopefully see more dividends for the site as a whole down the road. This also makes AKB the first full-time UESP employee (besides me). Note that his "rank" and work priorities haven't changed. The UESP has been a community run site for a long time and I don't want to promote anything that might hint that "an official UESP employee" outranks a volunteer. Being full time just means he can devote more time to the site in regular increments as opposed to the here-and-there nature of a volunteer hobby.

Note that while we currently can't afford any more part or full time employees please let me know if that is something that you're interested in. Site revenue from ads is "irregular" but in the coming years if the site does well (ex: ES6) there hopefully may be more opportunities available. -- Daveh (talk) 23:52, 27 September 2018 (UTC)

Looking forward to seeing AKB on the wiki more! Glad you were able to take this opportunity, AKB. —Dillonn241 (talk) 11:35, 29 September 2018 (UTC)

New MediaWiki 1.24 Features[edit]

For those of you who haven't already read it on the Administrator Noticeboard, we've now updated the wiki to version 1.24 (give or take a few issues). There are a few new things that this allows. Here are the major ones that people might be interested in:

  • The Preferences menus have been updated. At the very least, search preferences have now been moved to the search page itself, where there's a checkbox that lets you use your current search preferences as the default. I'm uncertain what else was added, but there are a few things I don't think were there before, so you may want to take a minute and review everything. (Note: this explains why our customized versions of both of those caused problems during the upgrade, but also probably means they'll need a significant rewrite to get them working again.)
  • Category pages can now be moved—no more copying and pasting when we change a category name.
  • {{!}} is now a built-in magic word, which will improve the performance of pages (mostly templates) that use it. This means we no longer need the old template for it. The wiki is working on updating the What Links Here for the old template, but I imagine it'll be a little while before our job queue is clear again. Once we can confirm that the template is completely unused, it can be deleted.
  • On the off chance that anyone's still using IE version 7 or below, it's no longer fully supported.
  • Administrators now have access to an automated Merge History page. Robin Hood  (talk) 07:30, 29 September 2018 (UTC)
Thanks for the overview of the changes. Once all the problems with UespCustomCode are worked out, it will be a nice improvement for both editors and readers. —Dillonn241 (talk) 11:35, 29 September 2018 (UTC)

Reverting MediaWiki Thumbnail Change[edit]

I think the default image size for thumbnails should be changed back to how it was in 1.23, or at least made a bit smaller. The size now is 300px and the old size was 180px. 200px would be a good compromise, or possibly 250px. The main problem is a lot of pages weren't designed with this size in mind and may have layout issues. Some people have also pointed out on Discord that it's unusually large. —Dillonn241 (talk) 04:43, 5 October 2018 (UTC)

the compromise sounds good. if the old image size was too small then slightly making it bigger at 200px is decent. I had no issue with the old size Zebendal (talk) 05:02, 5 October 2018 (UTC)
Since someone's likely to ask at some point, looking at the various user preferences for thumbnail size in our own database, 300px is the most popular by a significant margin. However, there's a significant issue with deriving any statistics from that. Namely, at some point, MediaWiki stopped saving values if they matched the default value. Well over 90% of users who've had 10+ edits had the default value selected or have never changed their preferences at all. For them, we have no way of telling whether they actually wanted the old setting of 180px, if they just didn't care, didn't realize they could change it, or if they've set their size to 300px at some point since the upgrade to 1.24. That last group is going to be vanishingly small, I imagine, so it seems that a very large percentage of people were happy enough with 180px. Given that, and the preponderance of cell phones these days, I think 180px makes sense, but it's very easy to change to anything else, so consensus rules, as always.
As for layout issues, most of those shouldn't be a problem. I've had my thumbnail size set to 300px for years, so chances are, I'd have noticed anything significantly problematic, at least for images that are in templates. One-off cases in spaces I don't edit are another issue, but those will be a rarity, I imagine. Robin Hood  (talk) 05:20, 5 October 2018 (UTC)
I don't feel to largely either way, but would prefer the setting returned to what it was if there isn't a good reason to keep 300px. --AKB Talk Cont Mail 05:24, 5 October 2018 (UTC)
I'm one of the ones that didn't know you could change your preference. I've mostly been away from looking at the wiki, but I just recently looked at some pages and to me the images went to a seemingly gigantic size. I'm used to what it was before, but 200px sounds like it might be a good compromise. Enderkingdev (talk) 05:29, 5 October 2018 (UTC)
I'm in favor of 180 (or smaller than 300). My screen size is 1366 which is still the most common size, though it is being replaced by 1920 (30% of the market to 20%). I assume the 300 pixel is slanted towards the 1920 resolution. Some quick maths says that 180 pixels on a 1366 screen is 13%, 200px is 14% and 300px is 22%. 180px on a 1920 screen is 9% and 300 is 15%. I think what this says is that people want the image around 15%, so either 180 or 200 is good for smaller screens, but 300 is as significant an enlargement on 1366 as 180 is too small on a 1920 (420px is equivalent percentage on a 1920 screen). Silence is GoldenBreak the Silence 18:32, 5 October 2018 (UTC)
+1 for reversion to 180px, the new size has messed up formatting site-wide. —Legoless (talk) 22:04, 5 October 2018 (UTC)
I'm in favor of 200px. Nice round number. 300 is distractingly large. --FioFioFio (talk) 22:06, 5 October 2018 (UTC)
200px sounds good to me. Anything smaller and you begin to lose detail, particularly in the darker screenshots. --Enodoc (talk) 22:17, 6 October 2018 (UTC)

() I vote for a 200px thumbnail, as well, and we should also update our {{Multiple Images}}s and Galleries - so that pages like Lore:Dwemer Animunculi don't look inconsistent. -- SarthesArai Talk 10:43, 14 October 2018 (UTC)

It looks like 200px is winning, followed closely by 180px, so I'll go ahead and set it to 200px...as soon as I remind myself how :Þ. If that's still too big, you can always set it to 180px manually (and create an account if you need to). Robin Hood  (talk) 21:48, 14 October 2018 (UTC)

Book Information Proposal[edit]

This is an idea I've had for a while that I believe would be a great help to some readers. It involves the lore book pages (see Lore:Library). There are many books, especially long series like King Edward or confusing books like Vivec's sermons, that could use a summary. There are also many books that could use some more explanation of the differences between game appearances and space for a full notes section to explain inconsistencies, etc. This is handled rather poorly right now with the lorenote parameter.

The proposal is to modify the {{Lore Book}} template to display an "Information" link if a certain subpage exists. This takes you to Lore:<Book Name>/Information, with a format similar to what I have in my sandbox. Read the notes in brackets for some more details on it.

This subpage is entirely optional, partly to make the idea practical, but also because a lot of books in lorespace don't need a summary (a great example, although it probably doesn't belong in lorespace to begin with). If someone wants to write a summary for a book they can create this subpage and the template automatically links it. Subpages should only be created for books that are expected to have a summary. The notes and differences can be moved from the lorenote if a subpage exists.

If implemented, I think the goal should be to add summaries for some of the longer series and more confusing books first, as I said above. Many readers don't have the time/patience to read/understand these and a summary is a great way for them to still find out what important events happen. For long books, I have a list of those. Confusing books is more subjective, but I'm sure everyone would agree on Vivec's sermons and perhaps Mankar Camoran's commentaries. —Dillonn241 (talk) 11:26, 5 October 2018 (UTC)

Support: This is a good idea. After working on book pages for years, there have been may times I wanted to expand or note some meta-info about the book, but there just wasn't a good way to support it. I think a sub-page this will help with that. Also, I think a "More Information" link would be more descriptive than just "Information". --Jimeee (talk) 11:38, 5 October 2018 (UTC)
Comment: Yeah, for anyone else reading, note that all the specific formatting and wording can easily be changed. I'm not attached to a certain format. —Dillonn241 (talk) 11:41, 5 October 2018 (UTC)
Support: A good idea. --AKB Talk Cont Mail 11:46, 5 October 2018 (UTC)
Comment: I need a proper example. Book pages are not the proper place to be making summations or notes of length, they are meant to be just a copy of the book. The summary section already exists under which you can make significant statements with a few words. Important information is already taken and added to other lore pages, and I would definitely oppose it if you need to use information from other sources to "make sense" of some of the things in books, because that is duplication the lore pages, again. Silence is GoldenBreak the Silence 18:38, 5 October 2018 (UTC)
Comment: The sandbox is a proper example, if you take out the comments in brackets (and in this case the notes section as well). The only thing external to this is a link in the Lore Book infobox, possibly in the same style as (lore page) seen on pages like Oblivion:Vilverin. The specifics of that aren't important.
The purpose of this is not to draw any conclusions about the text, none at all. Nor to bring in any additional material. The summary is supposed to serve as a replacement for the text in an easy to understand and short paragraph format. Just like any book summary you might find on Wikipedia. It may be a good idea as well to list the major characters for longer works, but that's not part of the current proposal. —Dillonn241 (talk) 01:25, 6 October 2018 (UTC)
Comment: Sorry, don't know how I missed the sandbox line. If I've read it right (this time) the suggestion is that the summary is on a separate page with just a link to it in the infobox. This I can support as long the summary sticks to being a summation of the content, and not delve into "drawing conclusions" or finding any "hidden meanings" that English teachers love to ask their students to find. There is no need to call it anything other than what it is, simply "Summary" in the box would be enough. Concerning the template coding, I don't see why the gamespace versions can't also link it, and in that case there is no need to duplicate the summary, just link the lore version summary. Consider this a support for now. Silence is GoldenBreak the Silence 18:58, 6 October 2018 (UTC)

Morrowind mainpage issue[edit]

Entering Morrowind:Morrowind I get "Sorry! This site is experiencing technical difficulties. [...] (Cannot contact the database server)". I first noticed that yesterday(8.10.18). Is it just me? Is someone aware and about to fix that? FeXoR (talk) 12:09, 9 October 2018 (UTC)

It's most likely an error related to the recent update. A temporary fix is to hit CTRL+F5, which will load the page. You can also replace the "en" in the URL with "content1" or "content3", which will also fix it until the updating is done. Hope this helps :) --AKB Talk Cont Mail 12:47, 9 October 2018 (UTC)
This definitely helped ;) ("en" -> "content1" worked, Strg-F5 didn't work for me). Good to know that it's a temporary issue. Thanks and have a nice day FeXoR (talk) 19:22, 9 October 2018 (UTC)

Tech issues[edit]

Someone is having tech issues. The issuer of your SSL certificate is unknown and "Sorry! This site is experiencing technical difficulties." appears every now and then when I browse. — Unsigned comment by 185.220.102.4 (talk) at 13:39 on 9 October 2018 (UTC)

Please see above. --AKB Talk Cont Mail 13:39, 9 October 2018 (UTC)

Nubering of Redoran and Hlaalu crafting motifs[edit]

It seems like the numbering of the Redoran and Hlaalu crafting motifs have somehow gotten confused on UESP. I just found out as there is an anon user who has halfway tried to correct it, but seems to not have had the skills. (It is partially reverted by others too.) I certainly do not have the skills to move around the pages, and I guess there might be some bot work here too, to get all links right. —MortenOSlash (talk) 17:02, 15 October 2018 (UTC)

The log has both of them listed as number 51 and 52. Motif 52 shows Hlaalu under the book type, while Redoran is under npcLoot and mineditem. Motif 51 is the opposite. The moving isn't hard as they don't share the same full name. Silence is GoldenBreak the Silence 20:54, 15 October 2018 (UTC)
Anyway, we are still the other way round from the game. UESP Crafting Motif 51: Redoran whaile the game has Crafting Motif 51: Hlaalu, and the other way round with Motif 52. —MortenOSlash (talk) 22:41, 1 November 2018 (UTC)
There isn't anything to stop the moves, you won't be moving any pages on top of another, which would be complicated. Silence is GoldenBreak the Silence 18:51, 2 November 2018 (UTC)
Now I got it. When the motifs are listed as inventory items, then it is 51 Hlaalu and 52 Redoran, but when they are learned and listed under Crafting Motifs in the Quest Journal, it is opposite around. So one of the numberings are a bug, but which? —MortenOSlash (talk) 17:00, 14 November 2018 (UTC)
The numbers in the eidetic memory should be the default or "correct" number, and redirects then made for the numbering found in the inventory. Silence is GoldenBreak the Silence 19:18, 14 November 2018 (UTC)

Proposal: New ESO NPC reaction names[edit]

Some time ago, I'm not sure when, NPCs labelled as friendly ceased to display their health values here. I feel this is an improbity, as it pervents seeing the health values of NPCs whose health values are actually relevant. Quest-Related NPCs, such as Lyris Titanborn or Abnur Tharn, Sai Sahan or others all assist you in combat and their health values are relevant, as are the goblins in Fungal Grotto. Some friendly NPCs must be kept alive, such as the Star-Gazers and to conceal their health is a disservice. Peripherally, if UESP's ESO NPC Reaction documentation were to change, I believe Bards should also be expanded to their own category—what I would call "Justice Friendly". Failing these, I would argue that health values for friendly NPCs are returned to visibility. My proposal is as follows:

  • Friendly NPCs who cannot die: Followers, health values displayed (e.g. Lyris)
  • Friendly NPCs who can die: Allies, health value displayed (e.g. Star-Gazer Priest)
  • Bards: Justice Friendly, health value not displayed (e.g. Auditory Stimulator)

Please provide feedback below. — J. J. Fullerton talk﴿ 02:39, 19 October 2018 (UTC)

Oblivion Plugins[edit]

I really don't want to bring this up again, but I do think there's been a mistake here. It was decided a while back to reverse the use of the term "add-on" for Morrowind and Oblivion, and the supposedly correct terms were Plugin for Morrowind and Download for Oblivion. I've gone ahead and standardized Morrowind to the extent that's possible using search. However, there are far more instances for Oblivion, not of "add-on" but of "plugin" or "plug-in" (around 300).

As far as I can tell, the archived website uses the term "download" exactly once, which is for the Oblivion Downloads page. It doesn't suggest this is the term for the content; there are many uses of the term plugin and plug-in, with the hyphen there as inconsistently as the wiki. There are also a few uses of DLC, but only in the form DLC1, DLC2, etc. similar to how Skyrim sometimes calls Dawnguard DLC1 for example. Unfortunately, I've already made quite a few edits based on the consensus and all instances of "add-on" are now "download". Additionally, the term Download leads to some confusing sentences when you're trying to say "download the download". Overall, the term just feels wrong and I felt that with every edit trying to standardize it.

So my solution here is to forget about "download" and just use "plugin" for Oblivion to be both consistent and accurate. Morrowind is standardized, Oblivion still has the majority of its pages using "plugin", and Skyrim/ESO are already fairly consistent in their terminology. It would only take around 100 edits to fix compared to the previously mentioned 300. —Dillonn241 (talk) 04:19, 29 October 2018 (UTC)

For what its worth, Xbox has them all as "Add-ons". However, this is standard for xbox additions of any sort, be they expansions (such as Shivering Isles), DLC (such as Knights of the Nine), plug-ins (Mehrunes Razor etc), or purchasable content such as Horse Armor. Knowing which ones are which may help distinguish here. (Horse Armor is a trivial update. Shivering Isles is a game into itself just about.) Timeoin (talk) 09:59, 29 October 2018 (UTC)
The point of this change was to be accurate. There being "many uses of the term plugin and plug-in" in Oblivion space is not valid justification to use an inaccurate term. That said, there really isn't very much consistency when it comes to Oblivion DLC. The old obliviondownloads.com website unhelpfully uses both "plug-in" and "add-on" in short succession. As long as we stick to an accurate term, I'm not particularly opposed to changing this again. —Legoless (talk) 13:33, 29 October 2018 (UTC)
The decision to make it "Downloads" was primarily based on the name of the content menu as it appears in-game; the website using the same name at least once was a convenient corroborative. Let me know if I need to post the in-game screenshot as proof. In terms of writing a sentence, "download the content" would probably be best, but "DLC" and "plug-in" would work as well since they are also in use on the website. I don't remember seeing "plugin" (without the hyphen) used in connection with Oblivion content. --Enodoc (talk) 19:34, 29 October 2018 (UTC)
I stand corrected on this, after searching through videos of Xbox let's plays. It seems the Downloads menu entry only appears on consoles under the Options menu. Still, in-game is a better source than any website. Just to note, it does use the term "downloaded content" in the same menu, so for cases where we'd have to say "download the plugin", it shouldn't be "download the download" but "download the content". —Dillonn241 (talk) 03:15, 30 October 2018 (UTC)
Downloads also appears in the content for PC, as follows: # This file is used by Oblivion to keep track of your downloaded content.
# Please do not modify this file.
DLCShiveringIsles.esp
Knights.esp
Timeoin (talk) 04:07, 30 October 2018 (UTC)
For another source - the Official Prima Guide calls it Downloadable Content, so I think Downloads is fine for the name of the page, and any permutation or abbreviation of downloadable content would work for everywhere else. --Enodoc (talk) 19:25, 30 October 2018 (UTC)
So "download the DLC"? —Legoless (talk) 21:15, 30 October 2018 (UTC)

() I don't feel too strongly in any direction. I will say, however, I feel this is too focused on semantics when as we can clearly see, a lot of these terms were used interchangeably. --AKB Talk Cont Mail 21:30, 30 October 2018 (UTC)

ESO Reference Calculations[edit]

Whenever the bot updates the various ESO item sets and skills, it uses a reference set of figures for standardized calculations, so you can readily see if damage, healed amount, etc. have gone up or down notably since the last update. These figures were established I think back around Patch 11 or so, and it occurred to me to wonder if what I was using still made the most sense. Here's what the bot is currently using: Health = 8744; Magicka/Stamina = 7958; Damage = 1037.

When I asked on Discord, Dave suggested that maybe the following numbers might make more sense: Health = 16k; Magicka/Stamina = 30k; Damage = 3000. He also added the following comments: Debatable what is "normal" but those might give you more reasonable/typical values. Could go Damage = 2500. Weapon Damage is easier to get above 3000 than Spell Damage. I'm not currently separating weapon and spell damage in my formulae, but I think that would be doable with a little work, if we really decide we want it (I make no promises, though...my design is currently a lot simpler than Dave's).

So, do we want to change the reference numbers for the next bot run, and if so, what to? Apart from possibly splitting Weapon and Spell damage, it's a very easy change to make and would take effect across the board in the next bot run. The disadvantage is that there'd really be no way to tell if something had increased or decreased since the previous patch, but the advantage is that from now on, we'd be using numbers that might make more sense to people as a reference and I suspect would a bit rounder, at least in some cases. Thoughts? Robin Hood  (talk) 20:59, 7 November 2018 (UTC)

With no further comments on this, I've updated to use Dave's numbers, so there will be much higher apparent damage and such for this set of updates, after which, it should stabilize again. Robin Hood  (talk) 23:09, 10 November 2018 (UTC)

New Province Mod Namespaces[edit]

I want to eventually fully document (by 2180) the three mods Tamriel Rebuilt, Skyrim: Home of the Nords, and Province: Cyrodiil, as well as any other project within Project Tamriel's scope. The first pseudo-namespace exists and is rather large, but has fallen behind since map 3. The other two pages didn't even exist until a few minutes ago. It's a daunting task but I can't do anything for the other two until the pseudo-namespaces for them are created, presumably with NS_ID set to SHOTN3 and PC3.

The main reason I want to work on all three simultaneously is because they share assets, and therefore items, creatures, etc. I thought about the idea of moving all the assets in TR's namespace to a new Tamriel Data namespace, but I doubt it's worth it. Tamriel Rebuilt can act as the default namespace for items that aren't intended for a specific project and items for a specific project can go in that project's namespace. —Dillonn241 (talk) 12:17, 8 November 2018 (UTC)

Yeah that sounds like a good idea. Make sure you add yourself to the Modspace Project too! We have a ribbon and everything. How many pages are we talking about that would be considered part of Tamriel Data rather than one of the province mods separately? If they're part of the Tamriel Data file rather than the TR file, it may make more sense for them to be under Tamriel Data, but I'm happy to leave the final decision on that to you.
When it comes to creating new pseudospaces, I don't think the ID is really that important, since as far as I can remember, it doesn't really do anything. PC3 sounds good; SHOTN may be enough without the 3 as it's quite long already. What we do need for each new pseudospace though is all of the following:

# NS_BASE ; NS_ID ; NS_PARENT ; NS_NAME ; NS_MAINPAGE ; NS_CATEGORY ; NS_TRAIL

and an important part of that is deciding on the base category and trail. In this instance, whether Project Tamriel is included as part of the trail or not may need to be considered.
--Enodoc (talk) 20:16, 8 November 2018 (UTC)
From what I know so far, I'm against putting Project Tamriel in the trail. That would be similar to adding Aldmeri Dominion to any trail containing Grahtwood, or The Elder Scrolls to any trail containing Skyrim. The mods are standalone and just happen to be part of this bigger project that shares assets.
I'm fine with either SHOTN or SHOTN3, but said the latter because the existing modspaces seem to imply that they all end with the number of the associated game. In the unlikely case there is a mod for Skyrim with initials SHOTN, then we wouldn't run into a problem. A mod with initials PC for another game is much more likely of course, so perhaps this standard can just be applied to 2-3 character initials. NS_ID matters because that's what we use for files.
Hard to say on number of pages, but I'm betting the number of shared items (starting with T_) is in the thousands. Certainly enough to warrant another pseudospace, though it could be a lot of work for little gain moving all the existing items, books, etc. to Tamriel Data/. A bot job nonetheless if I can list everything that needs moving. The advantage is that this is overall more correct than throwing them all under the TR name, and removes any need to think about where to put an item. If anyone else agrees with four pseudospaces here, I propose a Tamriel Data space with initials TD3. Enodoc was saying on Discord that Beyond Skyrim shared assets will be added under Beyond Skyrim/ instead of say Beyond Skyrim: Cyrodiil/, which is consistent with this idea.
In summary:
  • Tamriel Rebuilt (TR3) - already exists
  • Skyrim: Home of the Nords (SHOTN)
  • Province: Cyrodiil (PC3)
  • Tamriel Data (TD3)
Dillonn241 (talk) 08:01, 9 November 2018 (UTC)
I went ahead and made these pseudospaces since I highly doubt anyone except Enodoc really cares how this is going to work. Now to do a whole lot of moving and adding content. —Dillonn241 (talk) 05:00, 10 November 2018 (UTC)

DEFAULTSORT Update[edit]

Those of you who have been around for a while might remember a time (2009 to early 2013) when pages just got sorted to where you'd expect most of the time without having to constantly specify {{DEFAULTSORT:whatever}} all over the place. Thanks to a bit of prodding from Dillon, I've now re-implemented this feature. Pages now automatically have a DEFAULTSORT of {{SORTABLECORENAME}}. This means that in categories, pages now sort by their subpagename, if applicable, with the words "A", "An", and "The" moved to the end. For example, Stirk/The Secret of Vassa now has a sortkey of "Secret of Vassa, The" by default, and automatically gets grouped under "S" in Category:Tes4Mod-Stirk-Quests.

This should mean a lot less need to specify DEFAULTSORT either manually or in templates. Robin Hood  (talk) 06:01, 10 November 2018 (UTC)

Thank you! One less thing to think about when creating new pages, and one less thing to confuse newer editors. Not to mention that the list of pages with a defaultsort property should (I hope) be reduced to those pages that are actually handling special cases. —Dillonn241 (talk) 06:08, 10 November 2018 (UTC)