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

Namespace for Call to Arms/etc?[edit]

We got some more info on Call to Arms today, and I noticed that this is the page we currently have for it, which is not in any particular namespace right now. Similarly, Skyrim Very Special Edition also doesn't have a particular namespace, and Skyrim Pinball is in the General space. I also intend to make a page for merchandise, including pages for Skyrim Monopoly and Risk. Should all of this go under the General space? Should there perhaps be a new "Tabletop" space for Call to Arms and the board games? I figured I'd bring this up first so that once I make the pages it'll save some work not having to move them. ~ Alarra (talkcontribs) 21:46, 23 December 2019 (GMT)

I imagine future documentation of Call to Arms will be fairly expansive. Even just keeping track of the miniatures and rulesets alone would require a couple subpages. Seems logical to create a namespace for it. —Legoless (talk) 22:31, 23 December 2019 (GMT)
Anything that applies to Call to Arms should also apply to Pinball and Skyrim VSE. They are standalone games that will just get more and more subpages the more they are expanded. Not sure if the best course of action is to make a namespace for everything, although there no real limit to the amount of namespaces on the wiki (we have at least space for 400+), so the question is more about their necessity. Merchandise usually just need one page to cover their content, but it might be a good idea to have namespace there as the list of items will grow considerably in the years. --Ilaro (talk) 00:52, 24 December 2019 (GMT)
While there's a theoretical limit to the number of namespaces, it's high enough that that should definitely not be a concern. I expect our sun will have gone nova before Bethesda reaches that number of games. ;) Robin Hood  (talk) 05:44, 24 December 2019 (GMT)
Namespaces for everyone! -- SarthesArai Talk 10:41, 24 December 2019 (GMT)
Disagree with Pinball having its own namespace, Call to Arms should but a skin for a pinball game doesn't need its own namespace Imperialbattlespire (talk) 11:51, 24 December 2019 (GMT)
That raises the question: for what reason should a game get a namespace? The amount of (sub)pages that are created for it or the importance of the game? If it's the former, then Pinball has more reason for its own namespace than VSE or Call to Arms right now and it definitely can be expanded even more (How to Get Started, Controls, Credits, and probably more articles are still missing). Why do we add a namespace? Mostly to easily navigate through pages and patrol their edits, so it doesn't really matter how important a game is as long as it has a certain amount of subpages. --Ilaro (talk) 12:26, 24 December 2019 (GMT)

() I would suggest namespaces for Merchandise, Pinball, and Call to Arms. Maybe VSE. That one is small enough that I can appreciate the "maybe too small for a namespace" suggestion. Still, our current policy is "any new game" if it'll take "more than a handful of pages", and is done specifically to handle when the same page names will be used in different contexts (such as Magic, Enemies, etc). As said in previous discussions on this topic, the only thing lost is a tiny bit of Robin Hood's time on the filters page. We gain organizational consistency and enhanced searching and patrolling tools!

Make the change. It's the right choice! --Lost in Hyrule (talk) 22:04, 24 December 2019 (GMT)

Easiest comparison I think is ObMob. If ObMob gets a namespace separate from Oblivion, then Pinball and VSE get separate namespaces from Skyrim too. As Lego said, Call to Arms needs pages for rulesets and such, so I think having its own namespace makes sense. The only ones I'm not sure about are Monopoly and Risk, as I'm not sure how much there is to write about them and how they relate to the others. If not much, they could probably go on General:Merchandise rather than in their own namespace. Pinball meanwhile probably needs to come out of General anyway, as I don't think it fits with the purpose of that namespace. --Enodoc (talk) 11:29, 25 December 2019 (GMT)
I agree. If those games had a substantial amount to document including duplicate topic names, there may be a reason for it. If they can be described on a single page, then Merchandise would suffice. Note on Pinball, I was going to put it in Main like VSE currently is, but do not have permission to do so. Thus, I put it in General for the time being. --Lost in Hyrule (talk) 16:08, 25 December 2019 (GMT)
I guess the question is how much I should document about those games. I assume that putting down, like, all the text of the cards and such would be too much (which is why for instance we omit the cookbook recipes unless the publisher publicly shared them)? ~ Alarra (talkcontribs) 01:46, 29 December 2019 (GMT)
The interesting bit from my point of view is how these games differ from their standard counterparts from a gameplay aspect. Which Rules are changed, are there any additional rules or variations that change how the game plays. Monopoly variants for example often have identically formatted boards, with different names/art, but may contain different rules. It should probably go without saying, but should probably be stated on the article somewhere, that all of the place/charecter names have been changed for Skyrim (for example) ones. Kiz(email - talk) 01:50, 29 December 2019 (GMT)
Not a fan of a gamespace just for call to arms but a namespace/gamespace for board games overall could work very well, similar to the BK:Books namespace. Also not sure what the whole debate around merchandise documentation is because TES Wiki beats out uesp by a LONG shot, their articles catalog and archive a lot of important information that uesp has literally nowhere. The Rim of the Sky (talk) 20:03, 29 December 2019 (GMT)

() So you are saying because the wikia has a better documentation now, we shouldn't even attempt to document it ourselves? While a board game like Skyrim Monopoly will likely be done justice with a single page, Call to Arms won't, and there's a chance there'll be another board game in the future. As there is no downside to making new namespaces for games with enough information to document, I don't see why we shouldn't make use of this extremely useful feature. -- SarthesArai Talk 14:36, 30 December 2019 (GMT)

Not what I'm saying, Wikia's documentation is just a good example of how much ground should be covered and if anything we should take a page out of their book. I support a namespace for call to arms but we might as well have it cover all board games, otherwise we could end up with Monopoly:Skyrim Monopoly or something, even putting monopoly in General wouldn't make much sense if we had a Boardgame namespace. Same as the novels, we don't have Lord of Souls or Kyne's Challenge namespaces, they're all in Books. The Rim of the Sky (talk) 19:20, 30 December 2019 (GMT)
That's because you can't document a novel more comprehensively without starting to copy sections. Having a single Boardgames namespace would still lead to the same issues we are hoping to avoid. We would have Quests (Call to Arms), in addition to any other games that may end up having quests. Based on current info, Call to Arms would match the general criteria we have for a gamespace. Monopoly probably does not. Thus, a Merchandise, or similar, namespace will be used for all the small stuff like Monopoly and Risk. Maybe we need to wait til release to be certain on CtA, but it's looking like full namespace. --Lost in Hyrule (talk) 19:57, 30 December 2019 (GMT)

Change Gallery Default Size[edit]

Indirectly following on from a really old Gallery discussion, we have finally found out how to change the default <gallery> thumbnail size. The current default is 120x120px, and it has been brought up many times before that this small size is one of the major detriments of the gallery, and why it is often not used (with raw thumbs or templates like {{Multiple Images}} being used instead). Therefore I would like to propose that we change the gallery default to 200x200px.

Following on from this we can look into whether we want to change the default style to either of the modes from that previous discussion as well. --Enodoc (talk) 00:59, 29 December 2019 (GMT)

As another option to changing the default style, we can modify an existing style using CSS. Options with this are endless of course, and the current best solution i've found is browser dependant on how it displays. It currently only shows when the <gallery> tag is formatted like <gallery mode=packed>.
Example images: Chrome/Firefox Example and IE/Edge Example.
For Chrome/Firefox the current script sets image height to 200px and allows image width to be automatically adjusted depending on the image aspect ratio, it also justifies the text centerally under each image.
For IE/ Edge the current script sets image height to 200px and allows image width to be automatically adjusted depending on the image aspect ratio, centralizes the image over the text but the text does not wrap over regardless of length. Text now wraps at a pre-determined width, currently set to 350px (which is the width of a 200px tall 16:9 image, this would need to be adjusted for a different image height)
Padding/spacing could be adjust to suite if we go down this route. We could also change the script target to all galleries instead, or update the relevant preferences for the <gallery> tag as well. There may be a way to limit the text length to a certain length, but I need to put this down for now (if anyone has any ideas on how to make that change please feel free!). Kiz(email - talk) 03:16, 29 December 2019 (GMT)
Sounds great, I support this. --Ilaro (talk) 09:26, 29 December 2019 (GMT)
Looks much better than the current gallery, fully support this Imperialbattlespire 10:46, 29 December 2019 (GMT)
It does look much cleaner, I say go for it.--Talyyn (talk) 13:36, 29 December 2019 (GMT)
I dislike the way it removes the grid-like aspect the current galleries have. -- SarthesArai Talk 17:19, 29 December 2019 (GMT)
Biggest problem with the current grid is all the unnecessary whitespace, since the grid frames are square and most of the images are not. That would be the main draw towards either nolines or packed, as they drastically cut down the unused space. But I would like to focus on the default thumbnail sizes first, before moving on to the gallery display style. --Enodoc (talk) 17:44, 29 December 2019 (GMT)
Yes, my CSS was in response to your comment on changing the style. I think a change to 200px defaults is a good idea to get changed as a first step. Kiz(email - talk) 17:49, 29 December 2019 (GMT)
Quite literally any change to galleries will be better than what we have now. I've experimented with some other formatting possibilites and they all look far, far better than what UESP uses as a default. The Rim of the Sky (talk) 20:03, 29 December 2019 (GMT)

() Updates made to the CSS and working in my first post to avoid keep reposting the script. New Example images: Chrome/Firefox Example and IE/Edge Example. The Chrome/Firefox section functions the same, the IE/Edge section now forces text wrapping at a preset width (this will need to be configured based upon the chosen image height). Kiz(email - talk) 06:35, 31 December 2019 (GMT)
More update! So, CSS is not the best solution for the image size change, the spacing issue between images (the irregularity/randomness) is caused by the adjustment of height via CSS. This should be changed via the .php setting unless we want a size change for different gallery types. If I apply the other changes without the height modification this is the outcome: Example 1 Or this: Example 2 Both those in Chrome/Firefox. In IE/Edge the results are identical: IE/Edge Example. The CSS is:

With that, a new gallery size of 200px (height) set in the .php settings would give nice even spacing like this. Kiz(email - talk) 13:03, 31 December 2019 (GMT)

200px does look good/standardised and I think example 2 looks the best/cleanest. Imperialbattlespire (talk) 20:29, 7 January 2020 (GMT)
yes please. also I really hate whitespace and its something that needed to be looked into. Zebendal (talk) 20:39, 7 January 2020 (GMT)

() Given that there have been no comments in opposition to the size change, I am happy to call that a pass to that half of the discussion. --Enodoc (talk) 20:11, 16 January 2020 (GMT)

This change has been put in place, so galleries will now appear much larger. I haven't made any changes to the style yet, pending the outcome of that discussion (below). Robin Hood  (talk) 20:32, 16 January 2020 (GMT)

Edit Break: Gallery Modes and Style[edit]

The other discussion about gallery style can continue here. --Enodoc (talk) 20:11, 16 January 2020 (GMT)

Again as I stated in the above discussion, I feel like example 2 of Kiz's work looks the best for the gallery, really does a good job of removing wasted space and making the images clearer Imperialbattlespire (talk) 20:49, 16 January 2020 (GMT)
So, now that the gallery size tag is changed that removes the largest issue. So example images: Standard (Example), Modified (Example). We can have a mixture of the two, or just switch the default gallery tag to use . Personally I prefer my modified version, but would be for changing the default tag to use over keeping our current gallery version. Kiz(email - talk) 02:48, 17 January 2020 (GMT)
Your modified version does look much better, and feels more intergrated into the page Imperialbattlespire (talk) 08:23, 17 January 2020 (GMT)
I think we could get quite close to the modified version if we reverted the changes made to packed a few years ago to force it to look more like {{Multiple Images}}. If we nix this bit in Common.css, what happens?
ul.gallery.mw-gallery-packed {
    border:1px solid lightgrey;

ul.gallery.mw-gallery-packed {
    border:1px solid lightgrey;
--Enodoc (talk) 00:11, 18 January 2020 (GMT)
So, if we nix all that code (ignoring most of it was duplicated of itself), we get: (Example 1). The only thing I don't like about that, is the images are centered as well as the text.
Or, we can go with this: (Example 2). This aligns the images to the left, and the text centrally under each image. The CSS mentioned about is remove and the following added:
ul.mw-gallery-packed>li.gallerybox { 

ul.gallery.mw-gallery-packed {
Edit: The most current version (Example 2 of this post) is set up for viewing on the dev wiki. Kiz(email - talk) 08:48, 19 January 2020 (GMT)

() Unless anybody wants to weigh in on this that hasn't, I feel this perhaps isn't as supported as the Discord conversation showed. For those interested, i've got a version like it that works upto 150px images (code below).

ul.mw-gallery-traditional img { height:150px !important; width:auto !important; }
li.gallerybox { text-align:center !important; width:min-content !important; }
li.gallerybox div, li.gallerybox div.thumb div { width:auto !important; }
li.gallerybox div.thumb div { width:auto !important;  margin: auto !important; border:none !important; }

If we want to change the gallery mode, thats a simple change that can be implemented. If anybody wants to use the code above and has any issues - ping me on Discord and i'll get it sorted. Kiz(email - talk) 01:53, 14 March 2020 (GMT)

Flora Images[edit]

In the aspect ratio discussion above, the problem of consistency has been mentioned several times, and I think some of the concerns haven't been addressed properly now the new policy has been implemented. I'd like to limit the topic to one of the examples Jeancey has mentioned, the Flora images, so that the discussion doesn't stray too far. This is the status quo: The image standard policy lists Flora images under 4:3/16:9/16:10 which previously was just 4:3. Morrowind, Oblivion, Skyrim and all other Flora Categories meet the 4:3 standard while in ESO Flora images there's a mixture of 1:1, 4:3 and a few 16:9 images. What are we going to do about this discrepancy? While other types of pages can highly benefit from a mixture of images in various aspect ratios, I don't think that it's a good idea for list-like pages like, for example, Flora B. Also, in contrast to many place images, Flora images would not benefit from the wideness of 16:9 or 16:10 - there will be exceptions and they should be allowed, of course, but in general I think the best choice for Flora images and pages is to keep 4:3 as a preferred ratio even for ESO and upcoming games. This could easily be added after "Flora images should feature the plant in as much detail as possible." in the list of image standards. --Holomay (talk) 18:12, 12 January 2020 (GMT)

Honestly, I prefer 1:1 for the Flora images personally. But I think at this stage, sticking with 4:3 makes the most sense. I definitely can't see the rationale for 16:9 Flora images that I can Place images. Kiz(email - talk) 20:48, 12 January 2020 (GMT)
The lack of consistency here is caused by ESO. We should continue with 4:3 for flora. —Legoless (talk) 16:06, 19 January 2020 (GMT)

Dragonborn/Skyrim Namespace Merge[edit]

I'd be willing to merge the Dragonborn pages into the Skyrim pages alone if no one else is willing to do it. I have a ridiculous amount of time on my hands, and there are less than 1,000 pages in the Dragonborn namespace. If anyone who works on maps has any input, I'd be willing to make the changes necessary to ensure Dragonborn locations link to their SR namespace pages. MolagBallet (talk) 01:45, 26 January 2020 (GMT)

Per the previous discussion, I am strongly in support of this. With SSE, Dragonborn became part of the base game, and the separate namespace becomes ever more unsustainable as more Creation Club content is released using Dragonborn items and places. The main opposition in the past was based mainly on the large amount of work involved, but if we have editors willing to take on and plan the merge project I don't see any reason not to do this. Speaking of a plan, the following actions will need to be taken:
  • Add |mapbase=Dragonborn param to the {{Place Summary}} on every moved place page.
  • Have a bot identify the pages that will need to be merged, e.g. Skyrim:Spells#Dragonborn and Skyrim:Spells. The initial merge can be a simple copypaste job, adding the Dragonborn contents to the bottom of the respective pages (see e.g. Skyrim:Achievements). However, human intervention will then be needed to merge the lists, which is where the bulk of the work lies.
  • Take account of fringe cases such as Skyrim:Skull (Dragonborn).
  • Fix categories.
I also don't think it would be a bad idea to maintain the Dragonborn namespace for redirect purposes, given the age of the pages and the high likelihood of external links. —Legoless (talk) 01:54, 26 January 2020 (GMT)
I agree with the idea of keeping the namespace for redirect/archival purposes. MolagBallet (talk) 01:58, 26 January 2020 (GMT)
(edit conflict) I believe most pages can be moved with bot, which also gives the advantage of changing all links to the correct new namespace. The only real need for human interference is most likely for pages that will conflict or need to be merged with the Skyrim version (like Skyrim:Keys and Skyrim:Keys). NPCs, locations, and other individual pages seem like they can be moved over without conflict. Map links on the other hand are a bit tricky, but I believe Alfwyn (link dug up by Legoless) already found a solution here. Then if everything is moved over all links on the site with Dragonborn and DB need to be changed to Skyrim.
If you'd like to take up the task to sort out the pages with possible conflicts (which I'm sure a list is possible to generate), then I'm in full support of this. I don't think there is even the need to do any of the other pages manually. --Ilaro (talk) 01:59, 26 January 2020 (GMT)
I think this is a good idea, and would be willing to help with the page merging that is required. I would think RH would be able to generate a list of pages in each namespace that we could cross-reference. Leaving all the old redirects behind, at least for some time, seems like a good idea since they've been around for ~7 years. A bot run for the bulk of the page moves, and for the mass-link updates that will need to follow. Kiz(email - talk) 02:04, 26 January 2020 (GMT)
I am in full support of this move and will help in anyway that I can.Zebendal (talk) 03:03, 26 January 2020 (GMT)
While I was previously of two minds about a merger, with SSE merging the game into a single cohesive entity, and several of the new Creations having some content set in Solstheim, I don't think it makes sense to have DB as a separate namespace at this point. I didn't realize that DB space was less than 1000 pages. That makes this that much easier of a project. As mentioned in the Discord chat about this, I think it might be a good idea to have some kind of project page, or something along those lines, so we can be sure we're all agreed on what to do for special cases like merging content pages, when one namespace has a redirect and the other has content, when both spaces have redirects, how to handle disambiguation pages (and links that target them), as well as what to do with talk pages, categories, image names, and anything else that people think of that we haven't come up with yet. Robin Hood  (talk) 04:44, 26 January 2020 (GMT)
Per the previous discussion, I also agree with the merge. As I said last time, the original reasons for a separate namespace for Dragonborn included significant, separate content, and while Dragonborn content remains significant, it has become way too integrated to still be considered separate. The reasons behind giving it its own namespace have been voided by the inconsistencies caused by that separation when documenting Creation Club content. For anyone who's worried about the number of things this will break, setting up a Project for this would help alleviate that, and if a trial run is done first on dev.uesp.net we'll have a better idea of what gets broken without affecting the main wiki. --Enodoc (talk) 15:04, 26 January 2020 (GMT)

() I agree with the project page, to itemize exactly what each step in the process and whether it will be by bot, editor, or by bot with a maintenance category (so a editor can review the changes, or properly merge pages where there are both DB and SR pages). A trial run on Dev to see exactly what breaks is also a good idea, likely suspects including templates and categories. A couple more to add to Legoless initial list.

  • Mass-move images from File:DB- to File:SR- and accosiated categories.
  • Mass-update links by bot as well from Dragonborn: to Skyrim: (and aliases). Although, changing DB/Dragonborn to an alias of SR/Skyrim could also be an option.

Before testing on Dev could really be practical, that will want updating to a more current version of the wiki. The current image is from November 7th, 2019. Kiz(email - talk) 16:07, 27 January 2020 (GMT)

It seems that consensus has been reached but just to add an example onto reasons for the merge, Creation Club complicates linking between Skyrim and Dragonborn in a big way. I initially created Skyrim:Skaal Villager and Skyrim:Ancient Ice in the Dragonborn namespace, but there were so many broken links that I had to move them into the Skyrim namespace.
I also heavily support keeping DB articles as redirects after the move rather than outright deleting them. The Rim of the Sky (talk) 02:33, 2 February 2020 (GMT)
I've created a preliminary project page at Dragonborn Merge Project, based on this discussion. I'll probably be updating it again later today or maybe tomorrow, once I review both this discussion and the Discord discussion. In the meantime, everyone should feel free to update themselves with any additional issues or anything I've missed. Robin Hood  (talk) 05:35, 2 February 2020 (GMT)
I've just sat and reviewed the discussion from Discord, and can't see any points raised that aren't addressed on the project page. I've already been through the project page myself and added one in that I felt was missing. If anyone else interested in this can also do likewise, or raise them here to say we've not thought that situation through, as well as add there names to the project to give a general idea of how many editors we're likely to be looking at. Once we're reviewed any specific templates I think the trial run on Dev (after an update) is worth doing to see what, if any, that we've missed. Kiz(email - talk) 16:29, 2 February 2020 (GMT)

() Update: Bot testing has begun on the Dev wiki as of yesterday, the first section (file moves) appears to have run with no issues. The content and talk move will be run in the next couple of days or so. We'll be testing the template editing on Dev as well, to ensure we can have a smooth roll out on the live wiki once required. Pending this content and talk move going okay, we'll then set a date and time for the run(s) to start at some point towards the end of this week, with the goal being to carry the merge out during low edit times when possible with minimal interruptions to editing. The current plan calls for the following namespaces to be locked for all users whilst the bot is run: 134, 135, 146, and 147 (Skyrim, Skyrim_talk, Dragonborn and Dragonborn_talk respectively). This is so that HoodBot doesn't have to deal with e/c resolution on top of everything else as well as reducing the likelihood of anything moving/changing during the run, edit notices will be in place in effected namespaces during this time.
If anyone can think of anything not covered/handled on the project page, please comment below so we can make changes before doing the test runs. Kiz(email - talk) 22:06, 16 February 2020 (GMT)

In theory, the jobs to migrate Dragonborn over to Skyrim are now complete and working beautifully! It looks like there will be very little for humans to do. I'd appreciate it if people who are interested could please have a look at the development server and see if there's anything terribly amiss before we run this on the live servers.
There are a few known issues: first, some of the merge job went awry and left extraneous #Dragonborn links on the development server. This is now fixed in the job itself, but I saw no reason to spend time creating yet another job to fix a few broken links on a test server. Also, sometimes, data saved by our various templates has not been successfully refreshed. Typically, that just requires a purge, though you may have to purge a few different pages (e.g., for an achievement, you'll likely have to purge the page/redirect with the achievement data and any page where it's not displayed correctly). Also, some images on the development server are missing/out-of-date. That's nothing related to the merge itself, just a question of cutting down on unnecessary copying.
Things not done yet on dev: pages that we'd tagged as needing human intervention have largely not been touched apart from link updates and the like. I didn't see much point in doing this on dev only to have to redo it on the live servers (and, in any event, some things will probably need discussion or someone who's better at organizing information than I am). Also, while most templates are working properly, some have not yet been adjusted, particularly where they involved pages that are waiting for human intervention. Lastly, as discussed on the project page, there's been no effort to migrate/integrate the various Category:Dragonborn- categories as yet. Many of those can probably be done as a small page-move job of their own once we're working on the live server.
Apart from those things, I believe everything else should be okay, so if you see anything that's not quite right, please mention it, either here or on Discord. (If posting on Discord, please @ me to be sure I don't miss it.) I'd rather be told about something I already know about than not be told about something I've overlooked! Robin Hood  (talk) 21:46, 20 February 2020 (GMT)
Just to give people an idea, here's what's left on dev: Merge Results. This same report will be available after the live job, and can be generated by the bot in a few seconds, so it'll be a good way to keep an eye on what's done and what still needs to be done. Robin Hood  (talk) 02:18, 21 February 2020 (GMT)

Bot Run[edit]

The bot will be updating Dragonborn, Skyrim, and related pages for roughly the next four to five hours quite some time (edited because live servers seem to be taking a lot longer than the development server did). This will occur in three back-to-back phases, during which you can expect some degree of link and template breaks:

  • Move all files beginning with DB-. No redirects will be left behind for these by default, though people are welcome to create any that might be needed in the future.
  • Merge all Dragonborn pages that have the same name as Skyrim pages (with the exception of Achievements, Dragonborn, and Sandbox).
  • Move all remaining pages not accounted for above. Redirects will be created for all of these, to limit breaking links, both internally and externally.

At each stage, links will be adjusted based on what has moved, so there may be multiple updates to the same page. If there are any questions or comments, please do so below. Robin Hood  (talk) 18:06, 21 February 2020 (GMT)

The bot run is now complete, and both Skyrim and Dragonborn spaces are unlocked once again. Robin Hood  (talk) 03:51, 22 February 2020 (GMT)
A preliminary report that highlights things that may still need human intervention can be found here. Some of the items listed may be false hits due to the fact that the wiki is still updating things like which of the moved pages are in what categories, and what links to the new/old pages. Items will likely disappear quickly as the job queue catches up and as humans take care of the most pressing issues. Feel free to ask me to update the report at any time; it takes only a few seconds.
Also, as people start to look at the various pages, new bot jobs will likely pop up over the next few days. I intend to make myself available as much as possible for this sort of thing, so please don't hesitate to ask if you see any sorts of page moves, link/template call updates, or anything else like that that a bot would likely be good at (e.g., relinking the Dragonborn main page, once we figure out what we're doing there). Robin Hood  (talk) 04:59, 22 February 2020 (GMT)
Can the bot find out which pages actually use {{DB}} to link to a page, that is use a parameter other than "par"? Those pages would break changing that template to something simpler like {{DG}} and {{HF}}, which would be the easiest way to make it link to Skyrim:Dragonborn for the parameterless use. And probably we want those templates to behave the same anyway. --Alfwyn (talk) 01:07, 23 February 2020 (GMT)
I guess for consistency with DG and HF, all Dragonborn books and notes should get a |mod=[[Skyrim:Dragonborn|Dragonborn]] parameter added to their infobox. And DB map places should get |ns_map=DB changed to |ns_map=Dragonborn so the maplink shows locally on the page too. --Alfwyn (talk) 11:36, 23 February 2020 (GMT)
There are no pages that use DB to link to a page. The only ones that use the par parameter are: Erik the Slayer, Hide and Seek, Onmund, Ores and Ingots, Reaver, Thieves Guild, Trainers, Werewolf, and the template's own doc page. If we want to change DB to work the same as the others, that would be easy enough.
The Dragonborn books and notes are done, per our discussion on Discord, and the Place Summary templates have been updated. Did I miss anything? Robin Hood  (talk) 08:54, 24 February 2020 (GMT)


An update on general progress, we have 0 pages that require merging into their Skyrim equivalents after being "moved-by-append" by the Bot. And 0 pages that are one of the following: Redirects in DB with a page in SR, Redirects in SR with a page in DB or a redirect in both namespaces that still want figuring out by an editor and removing from the relevant category.

After those are all complete, the next job is checking for any links still on-wiki that are [[Dragonborn: or [[DB: and repointing those to their now corrected locations. As well as re-categorizing everything as applicable and moving the categories to be Skyrim-Dragonborn- instead of Dragonborn-.

If anybody finds anything that is broken/not working as expected, or that we've missed, please either comment below or ping me (@Kiz) on Discord. Thanks! Kiz(email - talk) 05:06, 1 March 2020 (GMT)

Large Gifs[edit]

I've been creating some high-quality gifs for Blades:Emotes. An example can be seen here with the intention of using it in a thumbnail at 200px in place of those "Missing Image"s. There were some snags with using that example gif that made me aware of certain pros and cons regarding the specifications of these images. I'd like to share the dilemma inductively, beginning with where I started.

Initial Design:

Firstly, the framerate is nearly unchangeable. The example gif is 25 frames per second, specifically a 40 millisecond frame delay. This is intentional, as the gif format itself is limited to multiples of 10 milliseconds. That means that the only reasonable gif framerates are 33⅓, 25, 20, 16⅔, 12.5, 10, 8⅓, and 6⅔ fps. Because of the capture software, the source video is limited to common framerates (60, 50, 48, 30, 25, 24), the only candidate due to the 10ms restriction being 25. However, with frame disposal, there would be room for clever tricks, like recording in 60fps but deleting ⅔ of the frames in-between to end up at a final 20fps. I stuck with 25 for simplicity.

The gif dimensions have a lot more room for change, as the image is around 1090x1090px before downscaling. I chose 500x500px arbitrarily as a good midpoint between large file size and loss of detail.

The Problems:

The largest issue with this idea in general is accommodating users with poor internet connection. The technicalities of internet behind-the-scenes are not my forte, but it seems like 15 or so of those images on the one page wouldn't be awful if they were all similarly sized like the example gif. It also seems that, unlike normal images, the website doesn't create scaled-down previews of gifs. So the user has to load the full gif, no matter what size it's set to on the page.

Additionally, the example gif file has the following warning: "Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated." This makes use in a thumbnail impossible at the current dimensions. Someone explained to me that the functionality of being able to visit the file page to view larger previews holds some importance to UESP. I do not know where the threshold for this restriction is, but by going too small, it may function on the Emotes page but lose value as a preview for a more detailed image.


The example image could be used as-is by just using it as a raw image rather than a thumbnail. However, these are some pretty complicated and fundamental issues, so I figured I would post here to see the consensus on how this should be handled. I'm currently sitting on a couple of 25fps source videos that have yet to be made into gifs. Besides that 25fps and the 10ms rule, I have full control over the specifications of the output gif. If it is required, I can use a ⅓ or ⅔ frame disposal to result in 12.5 or 8⅓ fps, though I fear it wouldn't look very smooth and may lose purpose as an example of what to expect in-game. What file sizes, dimensions, and framerates are appropriate? Please correct me if I am misinformed on anything as well.

-- Dcsg (talk) 03:32, 3 February 2020 (GMT)

Might be better to utilise a more net-friendly format for uses such as this (e.g. .webm files). At present, a still frame similar to what is used on ESO:Emotes would be the safest option for a list page. —Legoless (talk) 19:09, 3 February 2020 (GMT)
(edit conflict) So, a couple of technical babble explanations. MediaWiki implements GIFs interestingly as far as I can tell, this means conversely to what you might expect larger GIFs actually work more of the time than smaller GIFs. MediaWiki's in-built (adjustable) default limit for playing GIFs in thumbs is 12.5 MP, your GIF in comparison calculates out at a somewhat larger 57 MP. But the implementation of the |thumb| tag changes as your resolution does, as you increase the resolution of the thumbnail image from 200px to 250px as far as MediaWiki is concerned, its not actually a thumbnail anymore.
For reference, this specifically is the change I am talking about: 250px image - working and 200px image - not working
The difference is in where MediaWiki pulls the image from, the working example loses the /thumb/ flag in its srcset= 2x field. Which is the marker, as far as I can find, that identifies an image from a thumbnail.
With that technobable out the way, one more concern for a page like Blades:Emotes. I don't know *how* badly page time load will be affect specifically. But you could easily be looking at ~7MB per image even for a scale down thumbnail, which would mean an image bandwidth load of around ~100MB for that page.
So, on to some more testing, it gets worse. The wiki will happily play the GIF at either 220px or 300px on its own, any other height value causes intermittent issues where the GIF will load frozen and not start. More bizzarely if you have the fullsize image on the page, even hidden, any size from 220px to 400px will reliably load.
Ultimately, we have a couple of choices (in theory, some of these would want coding, templating and testing first) -
  1. We can force the images to be mathematically between 220px and 400px, overriding the user preference on a sliding scale.
  2. We can set one value for everyone that we know works.
  3. Investigate a solution as mentioned by Legoless above.
If there is a good reason that we need to get GIFs working better than this, we can explore solutions in extension/custom javascript, the first option above would be a very hacky way of doing it. Kiz(email - talk) 19:24, 3 February 2020 (GMT)
So, having let this one rest overnight, the .webm doesn't seem to have worked. The on-wiki transcode is still attempting to process the file, with no success. In the meantime, DCSG has upload several new GIFs in a different size and frame rate. These new files work correctly in thumbnails from 120px up to 300px, as they fall short of the 12.5 MP limit (for reference these are 10.5 MP). I personally think these are fine, my only additional point would be to try getting a 400x400 version to work. This would mean an increase to a value like 19 MP $wgMaxAnimatedGifArea (the longest current emote is 114 frames, which calculates out as 18.24 MP), this would want testing first before rollout. Kiz(email - talk) 19:09, 4 February 2020 (GMT)

Duplicate Icons[edit]

This is just a public request. You know who you are. Please do not delete duplicate icons. They are so small that they do not take up much room and harm nothing by existing. And even if you feel you MUST do so in the name of cleanup (which is totally unnecessary), please replace them with redirects. The amount of extra time it takes to search the dozens of icon categories for icons which may have completely unrelated names is seriously annoying. Having an icon available under multiple different names makes it much easier to find when you need them. By simply deleting them, you are make more work for yourself and for everyone else who needs to use them later. — TheRealLurlock (talk) 23:30, 29 February 2020 (GMT)

Simply put, No. Unnecessary redirects are by definition unnecessary. I prefer not to look through hundreds of absolutely useless icons in a category simply because you are too bothered to search by the original file name which goes on every icon page now. File redirects still show up in those categories, making it incredibly difficult to find one specific icon you need, if you feel the insane urge to search visually instead of using the search bar. Further more, having four or five different names for the same icon on the same page can significantly confuse new editors, since they have no idea which one is the right one, and may not use any icon at all because they think they are somehow different. I don't see why spending time and effort creating and maintaining redirects so every single item, skill and achievement can have their own redirect in their name. There are tens of thousands of skills, items and achievements in ESO, with more added every patch. It is simply unfeasible and idiotic to create redirects for them all, and creating redirects for a handful is both confusing and inconsistent.
Furthermore, publicly calling someone out is exactly the wrong way to behave, especially since your opinion is not the only one that matters in a situation. I have been working with MANY other editors to try and consolidate the icons into a searchable and condensed form, so I would appreciate it if you didn't try and undo the months of work we have been doing. Jeancey (talk) 00:41, 1 March 2020 (GMT)
The tone of this subject seems completely unnecessary you know who you are.
On the actual topic, I agree with Jeancey on this - I can't see a reason why we need duplicate icons, we have a special page which serves the purpose of highlighting them so we can remove them. Uploading duplicate copies of icons for editor ease is completely unnecessary. Why must we have six copies of the same icon? Why can it not be named File:ON-icon-skill-Keen_Eye.png, is that not a descriptive enough title that we could reasonably expect editors to find? Kiz(email - talk) 01:07, 1 March 2020 (GMT)
A bit related, I often know the name of an image in the game files. Is there a good way to find out under which name it is already uploaded on the wiki? Of course I could try to upload it and if I get a duplicate warning just use that, but there has to be something better. Update: And of course there is. For many icons the game file name is documented on the image page and advanced search in the File:-namespace (excluded in normal search) will find it then. --Alfwyn (talk) 23:12, 1 March 2020 (GMT)
I remember the reasoning behind duplicate icons was that if one use changed its icon but another didn't, it would be easy to replace just that use. That purpose remains conceptually valid if, for example, they decide to change the icon for Rugged into one thing and the icon for Tough into something else. With only one copy of an icon, you have to edit every instance for that one changed usage. Also the game file name is only passingly useful if it doesn't include the entire filepath, otherwise nobody knows where to look for the icon anyway. --Enodoc (talk) 18:29, 3 March 2020 (GMT)
The filename is more to verify that you are getting the correct icon and whether it is already uploaded. Presumably if you are uploading icons at all, you know where to look for the file path, since you already have the icon. You wouldn't just have the file name and then go tracking down the icons. Also, for that purpose to remain conceptually valid, as you state, we would need hundreds of thousands of duplicate icons uploaded, which is simply unfeasible and fairly labor intensive work for little to no gain... If they change an icon like that we'd just change it to the new icon manually, and that is how we have always done it and it has worked fine so far... Jeancey (talk) 19:24, 3 March 2020 (GMT)

Marking DLC/add-ons[edit]

I just stopped Dcsg via talkpage message, trying to make it more uniform how we mark the DLC something is from. Depending on game and context there are currently at least four ways: SolstheimDB, MyrwatchCC, AlinorSummerset and writing it out "The Adabal-a (Knights of the Nine)". My personal concern was replacing infobox lines like "Elder Scrolls Online (Thieves Guild)" with "Elder Scrolls Online(DLC)". This is more consistent with how we do it at other places (and with Skyrim CC), but takes away the immediatly visual information from which DLC the book (in this case) actually is. Having different ways to mark the DLC depending on context and game is no problem for me, even if that means we are not consistent across the board. On the other hand I can understand the desire to have a more uniform layout for things. We had a bit of discussion on discord about it, without immediate result. I bring it up here now to find out how other editors think about it. --Alfwyn (talk) 00:31, 24 March 2020 (GMT)

In Lorespace I think writing it out in full like Elder Scrolls Online (Thieves Guild) makes most sense. In Gamespace something more like AlinorSummerset I think would be fine, but the current approach (which is something like AnvilCrown Store) needs reviewing, and I am planning to create a new template that covers off all the DLCs in icon format. --Enodoc (talk) 21:53, 24 March 2020 (GMT)

Separate CC contents from Skyrim "base game" contents in the same page.[edit]

I would like them to be separated in the same page. Here is an example of this: https://en.uesp.net/wiki/Skyrim:Artifacts . I think this will increase the readability of articles as I myself was quite confused when I viewed the page before. --Lywzc (talk) 14:05, 24 March 2020 (GMT)

I would oppose this change, ultimately they are all Bethesda releases. If we were to move towards seperating CC out, I would not want us to treat CC any different when placed in lists/tables than Dawnguard, Dragonborn and Hearthfire, which would mean seperating all of those out as well. Kiz(email - talk) 18:05, 24 March 2020 (GMT)
Since the release of Legendary Edition and Special Edition, we can say that Skyrim, Hearthfire, Dawnguard and Dragonborn have merged into a single entity, hence the merge in wiki. However the same can not be said for CC contents. They require separate purchasing and there are many who do not own any of them. I can not say majority since I do not have any statistics but I can say the vast majority do not own all of them. For them CC mixed with non-CC contents is certainly confusing to some extent which we should avoid in a wiki. So CC certainly is not quite the same as the three large DLCs. Besides I am not saying to create a new page for them although I am also not against such idea. --Lywzc (talk) 18:27, 24 March 2020 (GMT)
Every item has a symbol and an 'Added By' entry to explain where they came from. Somebody could come to the page who only has base game Skyrim, no DLCs. The clear categorization already listed on the items I believe are sufficient to remove any confusion for this person. It would be nice if they were all in a sortable table, though. --Lost in Hyrule (talk) 19:24, 24 March 2020 (GMT)
Talking about the vast majority. Also the symbol is too inconspicuous. I certainly did not notice that symbol the first time. It was because I know such thing did not exist in Skyrim+3DLCs that I was able to notice the symbol. If you are going to distinguish them by symbols at least make those symbols more noticeable like putting it before the large bold name. But again consider the majority. --Lywzc (talk) 19:42, 24 March 2020 (GMT)
I would consider the Icon indicitive of what they are, the only reason I would consider it less obvious is due to the variety of image heights because of how images are normally defined (by width) and are actually defined, if at all, on the main mod page. The reason the icon is after the text, and not before, is because the Icon functionality was never actually used on the Skyrim page. If you look at the Oblivion page you can see how this would look. I would be in favour of some standardization in the image heights used accross the Mod icons in this template, but that doesn't appear to be a trivial change after a few minutes of tinkering. Kiz(email - talk) 20:05, 24 March 2020 (GMT)
Back to the original topic, per this and this discussion, we can see clearly that 3 DLCs are considered part of the base game now. Most newer mods in Oldrim now also requires 3 DLCs to work or receive support. Which means Skyrim+3DLCs can not be separated. But such argument can not be applied to CC. As I have mentioned, they require separate purchasing and do not apply to many if not most players/users. Your argument that CC is the same as 3 DLCs is without regards to reality. So CC contents are not only could be separated, but should be separated. Maybe in the future when Bethesda released some Special GOTY Edition including them all and most players have jumped onto that can we fully merge them. --Lywzc (talk) 01:08, 25 March 2020 (GMT)
Your argument about mods requiring DLCs isn't related to the discussion at hand. To you, the three DLCs being lumped together is a no-brainer, but many people still play Oldrim without DLC and some with only a one or two of the DLC. The only difference between the DLC and CC is the release of Legendary/Special Edition, the amount of time between release, and popularity, none of which hold any bearing to UESP. No user should see something on the wiki and expect to find it in their game when it isn't, but also no user should expect to see something on a page about the game when it isn't. The best way to do this, in my opinion, is to keep everything related to a Game in one namespace, and everything the user with the minimum amount of content wouldn't see should be clearly marked. If the issue is about how the current marking isn't adequate, then that's a different discussion. Dcsg (talk) 23:46, 26 March 2020 (GMT)

Mod File Format Tables[edit]

I realize this won't be of much interest to a lot of people, but since I've recently started wikifying Dave's Morrowind file format and creating pages for it on the wiki, I thought I'd take the opportunity to maybe re-think some things we haven't done terribly well with those pages in the past, at least in my opinion. I'm really not great at page layout, so I thought I'd bring it to the community, if anyone has any input. For now, the changes would only be applied to the Morrowind space, but we can also apply them to other namespaces in the future as time permits (or possibly with some bot assistance, though with the complexity of the tables, a lot of these changes will be beyond it).

  • Change the word "Subrecord" to "Field". Within a record, units of data are most often referred to as fields, not subrecords. Also, as we've seen on the existing pages, that word leads to multiple variants like "Sub-Record" and "SubRecord". "Field" can pretty much only be written one way.
  • Remove the "Name" column. It's a completely arbitrary name, made up by whoever comes along—it has no relationship to anything in the game whatsoever. What little one might get from the name is eclipsed by the more descriptive information in the "Info" column. Some pages have already gone ahead and removed this field, though not many that I spotted.
  • Remove the "Version" or "V" column in the few pages that have it, and move that information into the "Info" column. That'll allow more descriptive information, including what's meant by "version"...we're using at least two different things that I've found (game version and internal record version).
  • As Alfwyn mentioned the other day on Discord, standardize nomenclature to be unambiguous. Data types go by many different names in many different programming languages, sometimes leaving words like "short", "long", and "float" meaning different things to different people. I've already started doing this, but I want to convert everything to naming that includes the size of the value within it (e.g., uint8/uint16/uint32, float32/float64).
  • Re-think structures. We've got a complete mishmash of styles throughout the tables, including but not limited to: a new section in the table (see Effect near the bottom of the table), row-by-row with an intro and fields indented below it (see DATA), row-by-row with no intro/indentation (see DATA), and as individual lines in the "Info" column (see ENIT). And that's just looking at the ones that are in tables...there are several that aren't. Part of the problem here is that it's hard to represent this kind of information in a table, particularly if the structures become nested (i.e., a spell, which has multiple effects, and each effect has its own data that needs to be stored). For added fun, some sub-structures have individual names for each field (as in the spell page's Effects section), while other structures don't (as in most of the other examples I linked).
Probably the format on the spell page will be the most useful for structures where fields have their own names, but then there's the question of structures that just have data lumped into the same field. Those would probably be more readable and easier to manage if we use the unindented row-by-row format, which seems to be what's been done for many of the Skyrim pages. There's still the issue of nested structures if we go that route, but I don't think that's very common for the all-in-one fields. I suppose that in the rare case where that occurs, we could separate them out like the spell effects and just drop the names. I'm open to suggestions here, cuz I'm not terribly happy with anything I've tried.

Does anyone have any ideas on any of this? Or perhaps any other things I haven't mentioned here? Robin Hood  (talk) 10:27, 25 March 2020 (GMT)

I mostly agree with the points you raised. The name is nice to explain some of the 4-letter fieldnames (EDID -> EditorID), but that can be as well stated in the Info column and sounds less official there. But I much prefer structures done in a single table cell like in TES5:NPC_, it's easier to read and manage I find. --Alfwyn (talk) 14:54, 25 March 2020 (GMT)

New Namespace for Official Products[edit]

Summary of recent Namespace discussions. We largely agreed that Call to Arms gets a namespace, and that is moving forward. There is moderate support for Pinball to get a namespace, which I still support. Hopefully as I flesh out those pages, more will be forthcoming! Skyrim Very Special Edition (VSE) is very small, and not too many support it getting a namespace. We also discussed a Merchandise namespace, to cover things like plushies, coins, Monopoly, and so forth.

Thinking about that, I have an alternative proposition. There are a variety of 'official' TES things that we would do well to document. General space could be used for it, but I think we should make a separate category. "Other Products" (but please suggest better names if you have them) would encompass all the TES stuff in one category, rather than having it sitting beside Developer pages, cancelled games, fan products, and so on. It would contain shirts and plush animals sold in the online stores, physical Collector's Editions, special coins given away at events, boardgame tie ins like Monopoly and Risk, and the very small games such as VSE and Smolder Scrolls. (It could even contain Pinball if it had to, but please don't do that to me.)

Proposal: Create an 'Other Products' namespace for all the official 'stuff' that doesn't get a namespace of its own. Name recommendations also welcome. --Lost in Hyrule (talk) 18:25, 2 April 2020 (GMT)

Easiest comparison I think is ObMob. If ObMob gets a namespace separate from Oblivion, then Pinball and VSE get separate namespaces from Skyrim too. […] Pinball meanwhile probably needs to come out of General anyway, as I don't think it fits with the purpose of that namespace. --Enodoc (talk) 11:29, 25 December 2019 (GMT)
I stand by this comment. Meanwhile I think you have given examples of sufficient merchandises that General:Merchandise no longer seems viable, so I would be happy with a Merchandise: namespace for any official non-game product. --Enodoc (talk) 18:35, 2 April 2020 (GMT)
I agree with Enodoc's comment. Having a Merchandise: namespace is a good option. If we put all official non-game products in the General: namespace, it would get cluttered up pretty fast. Werewolfvampire (talk) 20:54, 2 April 2020 (GMT)
Like last time, I fully agree with a pinball, VSE, and Merchandise namespace. --Ilaro (talk) 08:55, 4 April 2020 (GMT)
I agree with the pinball and VSE namespaces. Would Smolder Scrolls be in the Merchandise Namespace, too? -- SarthesArai Talk 13:05, 4 April 2020 (GMT)
I think Smolder Scrolls can go to Online. That was where I originally suggested putting it, as it lives on the ESO website. --Enodoc (talk) 13:18, 4 April 2020 (GMT)
I accept these points, as well. I think the purpose of General is for meta information surrounding TES as a whole. Thus, official TES stuff should find other homes on UESP. The intent behind this proposal was more to make sure small games did not get thrown into General. A point to consider, though: is it a possibility that something could be released that isn't Merchandise, does not directly tie to an existing game, and does not warrant a namespace itself? Say, if Smolder Scrolls used characters from multiple games and was on the main TES site.
I may be too concerned about 'future-proofing' here. If Merchandise is expanded to cover tiny side games, I know we avoid any being put into General going forward. If we keep the spirit of "even small games get Namepsaces", though, then I need not worry about that. --Lost in Hyrule (talk) 21:04, 4 April 2020 (GMT)
There is no issue with using mainspace for topics which don't fit into Merchandise or General, e.g. Eye of Argonia and TES Travels/Concept Art. —Legoless (talk) 00:06, 5 April 2020 (GMT)
Agreed on using Mainspace for anything that isn't Merchandise. We could put Smolder there, for example. --Enodoc (talk) 14:15, 5 April 2020 (GMT)

() The consensus here is a bit murky, but I think I'm seeing support for Pinball, VSE, and Merchandise. Does that work well enough? Keep in mind that it's somewhat easier to split out a namespace later on, if we need it. Creating and then merging later leaves the unused namespace around forever. Also, for VSE, do we want to spell it out or is that too long? Robin Hood  (talk) 20:33, 23 April 2020 (GMT)

With no further comments, I think this does seem to be the consensus. My proposal at the start of this was not accepted. Merchandise will be created to house physical products, Pinball and VSE for their respective, smaller games. Smolder Scrolls will either be Main or Online, as either is justifiable. I believe 'VSE' is sufficient for the namespace, or perhaps 'SkyrimVSE'. --Lost in Hyrule (talk) 18:44, 5 May 2020 (GMT)
Okay, the new namespaces exist. I used Merchandise, Pinball, and SkyrimVSE with a shortcut of just VSE. This makes it slightly easier to manage on the off chance that there's something like OblivionVSE in the future and we need to get rid of the VSE shortcut. For the templaters, I haven't added any info to the Uespnamespacelist yet, as I wasn't sure if it would actually be needed or useful, and even if it is, we need to figure out what the main page will be for each space and all that stuff. By all means, feel free to add it or ping me to do so. Robin Hood  (talk) 21:01, 5 May 2020 (GMT)

Skyrim Switch Integration[edit]

I think that the few things that are unique in the Nintendo Switch release of Skyrim should be on their respective pages, treated similarly to DLC or Creation Club. The list of unique features are quite small, so this wouldn't create any shocking difference to the affected pages. The following would be my course of action:

I believe this is important for the sake of completeness for the relevant pages. Let me know if you have any opinions one which way or the other. --Dcsg (talk) 07:02, 4 April 2020 (GMT)

This sounds sensible and small project that will increase the quality of the wiki. --Ilaro (talk) 08:55, 4 April 2020 (GMT)
Makes sense to me! --Enodoc (talk) 13:22, 4 April 2020 (GMT)
You make good points and have a plan, I say go for it. --Talyyn (talk) 13:43, 4 April 2020 (GMT)
For consistency's sake, we should be using the {{Ns22}} template (Nintendo Switch) for Switch-specific notes, similar to how we use {{Pc22}} (PC) etc. I think this icon is preferable to the proposed .svg but perhaps I'm in the minority here. —Legoless (talk) 00:03, 5 April 2020 (GMT)
Seems like a good idea to me, on all counts. I do prefer the icon Legoless suggested. --Lost in Hyrule (talk) 00:20, 5 April 2020 (GMT)
I've done everything I set out to do and a little more. I quickly realized that handling not-Elder Scrolls information could be tricky and deceitful to the user, so I came up with {{Crossover}} as a warning and applied it everywhere it was needed, and also for some Fall of the Space Core stuff. I also used {{ns22}} on the Torturer's Hood, gave the amiibo power its own page, and moved things from the main Skyrim:Switch page to their respective pages.--Dcsg (talk) 00:52, 5 April 2020 (GMT)
Good idea Dcsg, 100% agree with that crossover banner. Imperialbattlespire (talk) 18:21, 5 April 2020 (GMT)

() I love the banner. Perfect way to phrase that. Jeancey (talk) 03:37, 6 April 2020 (GMT)

Adding -event- Image Category/Category:Online-Event Images[edit]

Currently in the Online namespace when dealing with images about in-game Events (particularly from the official site), the filenames either go into -misc- or -prerelease- without rhyme or reason. I suggest that a new image category -event- should be used, it would be more accurate and clear out the Category:Online-Miscellaneous Images and Category:Online-Pre release Images. It could also fold in user-generated images of events (such as the first Heart's Day).

It would take abit of image renaming and redirecting, but I can work on it.--Talyyn (talk) 05:14, 7 April 2020 (GMT)

This makes total sense - I would just go ahead and make the category as there is no reason not to have one. In fact, many of the images in Category:Online-Pre release Images need re-categorized. We, myself included, have just gotten a little bit lazy over the years and began to use that category to dump everything from the ESO site. --Jimeee (talk) 09:20, 7 April 2020 (GMT)
Well I went ahead and changed most of them, now it is the case of chasing down the links on other pages, so the redirects can safely be removed.--Talyyn (talk) 12:18, 7 April 2020 (GMT)

NPC Dialogue[edit]

Hi! I've noticed the ESO style of dialogue bleeding over into some of the other namespaces (Skyrim and Morrowind). My concern isn't with Morrowind as there was inconsistency (and room for improvement) in dialogue presentation there before this. I see Skyrim articles that had complete dialogue in the prose format being changed into this style. Was consensus reached that this is now the preferred style? Skyrim:Keerava is an example if you look through the edit history. The most recent discussion I could find regarding this seemed to still be a mixed bag of opinions on the style. I'm not opposed to seeing this style in the Skyrim namespaces for new articles or articles that are still missing dialogue, but I think it's a different story to be changing complete articles by our old(?) standards into this subjectively better format. While some may say the dialogue is easier to find now and the article is better because of that and it also does a good job at documenting player dialogue, I can argue that this new version introduces a lot of white space and odd indenting. I could also tell you that it lacks the narrative flow of the old style by having each line of dialogue on a separate line, which in turn hurts the overall readability for someone who is reading the article start to finish.

In particular, I think the forcing in of the existing prose into the ESO style is creating a "worst of both worlds" type of scenario. You don't have the advantage of the good narrative flow of the prose because it's jumping from line to line for every single piece of dialogue. This causes it to read like a list instead of a book. You don't have the advantage of cleanly listed dialogue like the pure ESO style because of the prose narrations being mixed in. Rumors would also need to be fit in too, further bogging down the ESO style. I think this showcases the ESO style's overall weakness at documenting context, even when a hybrid style is used, which is why the FA in that namespace still used some pure prose and none of this hybrid stuff.

I've wrote far too much on this before so I'll try to keep this short, but here's my opinion on dialogue and I think it coincides well with the approach of the modern holy grail, Skyrim:Neloth:

  • "Loose" dialogue without player options works great with prose and rather poorly in the ESO style. Prose commentary turns it into an interesting paragraph while the ESO style creates a list that doesn't document context or NPC emotion. For characters with so little dialogue where a dialogue section isn't needed, the prose can be used to transition from their schedule details into the dialogue to provide interesting narration and great flow. The ESO style is easier to find, I guess, but I think ctrl + F makes that benefit marginal.
  • Player dialogue that is a linear path of player options is the gray area that both styles can have an advantage in. Prose works better here, in my opinion, if the player dialogue is boring and good commentary can be provided instead (as an aside, this is why I think the ESO style would be terrible for Oblivion). Prose is also better if context or NPC emotions needs to be documented, such as if someone got killed or a building exploded between two of the player dialogue options or the character went from whispering to screaming. ESO style works better if the player dialogue is lengthy and interesting and there's no context worth documenting.
  • When player dialogue branches off into multiple paths, the ESO style will be a lot cleaner than prose, which can get very convoluted here to keep up with dialogue conditions and branching. Depending how complicated it is, a well constructed table will be much better than both though. Prose can still have its merits for documenting context and emotion.

Ultimately, this is an entirely subjective item to discuss. As has been mentioned by many in the past, a mix of the styles works best. To close, as this is already way too long, I think a clear consensus for changing existing articles should be established before wiki resources are spent on subjective improvements. I'm well aware that I'm on the wrong side of the majority here and am probably seen as a problem child old man due to my inactive status but yet posting another long piece on this (which is a fair opinion), but looking at the opposition in the last discussion, I fail to see why these edits are being made. No offense to any of the editors making these edits either; I appreciate your work and do think some of the changes, particularly with the branching dialogue, were beneficial. Forfeit (talk) 02:04, 6 May 2020 (GMT)

I would agree with you that prose that already exists should remain. ESO style dialogue should absolutely NOT be used for Morrowind, as there is a completely different style of dialogue there. There aren't dialogue trees, but dialogue options, that you can click at any point that you meet the requirements, so the sort of branching dialogue choice style of ESO does not fit there. The dialogue should be presented simply with the dialogue option and the resulting dialogue from selecting it, nothing more. Skyrim should be discussed, but if the dialogue already exists I don't think we should change it. Personally I think the single player games should be primarily prose style, but I lost that battle a long time ago. Jeancey (talk) 17:32, 6 May 2020 (GMT)
Throwing my view in here, I dislike the overuse of prose in the Skyrim namespace, half the time it seems like there's more words on talking about the dialogue than the dialogue itself, I also belive the "wall of text" format that a lot of Skyrim pages has needs to be fixed (An example of this is Ysolda where the dialogue is just all shoved together as one giant block of text rather than being split up into dialogue and quest related dialogue.), keep the prose sure, but spaces are needed between dialogue/just because dialogue is "boring" doesn't mean we need to start writing a whole novel of prose about it. Also what Morrowind NPC page are you referring to? Imperialbattlespire (talk) 19:54, 6 May 2020 (GMT)
As far as Morrowind, it would be something like Bloodmoon:Korst Wind-Eye as one example. That's added a third main dialogue format I've seen used in that namespace (disregarding characters with only one unique line of dialogue, which is mostly done in single-sentence prose). There's the original style as seen on Morrowind:Lorbumol gro-Aglakh and what I call the Hargrimm style as seen on Morrowind:Bolvyn Venim. The original style lumps all dialogue together where as the Hargrimm style uses the same approach but breaks it into the separate quests and will on the rare occasion add some prose. I've never liked how Lorbumol came out and I think it would benefit from taking the Hargrimm or Korst approach. I agree that Morrowind should probably be a separate discussion though.
As far as prose being wordy, that's part of the point in my opinion. An NPC page should bring the character to life, rather than simply documenting their schedule, inventory, dialogue, and rumors. All the commentary helps to do so. All the rumors and prose on the (divisive) FA Skyrim:Thonar Silver-Blood (and really any other article Krusty wrote) helped to create a masterpiece that I don't think simply listing out dialogue could ever accomplish. Prose can get overly wordy when it's paraphrasing player dialogue and I think that's where other styles could be beneficial depending on the scenario and what will best tell the story while still documenting everything. Ysolda looks good to me, even great actually! The paragraph before the speech check table is the only place I see the need to potentially break up the text (when discussing the multiple options you can respond with). Most of the other player dialogue is very boring and I don't see the need to break the narrative flow of the prose to list it out. I do agree that the quest dialogue could be sectioned out, as that would be standard procedure in that namespace anyway for characters involved in multiple quests. Forfeit (talk) 00:01, 7 May 2020 (GMT)
I would say rewriting prose in older namespaces is a low priority, and any changes would need to bear in mind the goals of OBNPCRP. However, in principle I don't have an issue with more player dialogue being recorded in those namespaces, in whatever format is preferred. As Jeancey said, Morrowind has its own system of dialogue and that namespace needs to maintain its own specific formatting because of this. —Legoless (talk) 00:44, 7 May 2020 (GMT)
The real issue how the dialogue from Skyrim and older Elder Scrolls namespaces bleed into the rest of the contentm, making it hard to find specific dialogue within an ocean of text. I even prefer using that OTHER wiki for getting dialogue information because no effort was made to seperate the dialogue with a simple. ==dialogue== I hope when TES 6 comes out we do not commit such an atrocity again.Zebendal (talk) 01:59, 7 May 2020 (GMT)
I can agree that some Oblivion articles could benefit from a Quest-related Events section. Something like Oblivion:Rythe Lythandas comes to mind. The reason they look the way they do is because that's what the (ancient) style guide instructs one to write.
Where I would disagree with this is something like Oblivion:Adanrel and most Oblivion NPCs where there are only two lines of dialogue. I see no reason to disrupt the overall flow of the page to section off two lines of dialogue. I like the typical Skyrim approach of having non-quest related dialogue in the main body, as the schedule can compliment it quite well. The schedule, general dialogue, and general rumors is then used to set up and lead into the quest events. Skyrim:Ainethach would be an example of this layout, though it is not necessarily well-written. Something like what Skyrim:Deekus was just turned into (why are these edits still being made with an active discussion taking place?) looks odd with that one line of general dialogue and then a sub-section for the quest dialogue. It also deleted the rumors, making a complete page now incomplete by our standards. Forfeit (talk) 02:51, 7 May 2020 (GMT)
I wrote the dialogue for Bloodmoon:Korst Wind-Eye and I see no issue with it, considering none of the Bloodmoon dialogue was even wrote down beforehand, also I heavily disagree that we're meant to "bring life to NPCs", considering half the Skyrim pages seem to lack even basic dialogue, I really don't get the priority people seem to have regarding prose, also player dialogue should be included on Skyrims pages, I have no idea why people think its acceptable to just not include it because it seems "boring", this is a wiki, its about documentation, when we're missing half the information because there's a weird opposition to including PC dialogue and instead replacing it with prose, I agree with Zeb, and I know a lot of other people use the Wikia in regards to Skyrim dialogue. Also the massive wall of text not being split up and merged with what clothes the NPC wears, etc is just awful, it should at minimum be under ==Dialogue== Imperialbattlespire (talk) 14:28, 7 May 2020 (GMT)
I don't edit in Skyrim gamespace but I found when adding/formatting conversations (not character to npc dialogue) which appear in ESO that context to lines should added when possible (I use <blah> to denote actions), for example in the Circus of Cheerful Slaughter, the actor Queen Ayrenn gives a speech. If it is just left to the spoken lines, you wouldn't realize that she starts zapping her Mages Guild audience with lightning bolts midway. Especially when you have characters with many appearances and lots of dialogue, context and readability is very important, otherwise in the case of the former you just have a dump of conversations with little idea how each connect within a particular quest. Personally if a character only has one or two lines of dialogue, I don't mind that it isn't seperated under a dialogue heading but when more than that, giving the text its own space is prudent. Each approach does have its own strengths and weaknesses--Talyyn (talk) 21:33, 7 May 2020 (GMT)

() Content >>>>>>> Style, so I agree that focus should be getting any dialogue on the pages even if it's all bullet points in random order. But this discussion is (mostly) about changing completed articles. If you don't think we should be bringing NPCs to life, that would be the very reason why you don't see the priority regarding prose.

I think our main competitive edge over that advertisement infestation has been our lore section and then our NPC pages as a distant second (our overall comprehensive nature being the how and why we are better). I'm not too familiar with that place as I don't desire to give them traffic, so I could be wrong. Our NPC pages were a much different (and I would argue better) product than what that site is selling. By perhaps sacrificing a tiny amount of ease of use, they tell a story and bring the character to life instead of listing information in a cold, clinical fashion. Outside of UESP Lore namespace editors, I have my doubts that a majority of our readers come to an NPC page to find one line of dialogue. And if they are, ctrl + f should get the job done. They're reading that article because they like that character. They want to relive their experiences with them and learn more about them. Bringing the character to life seems like a good way to satisfy that customer. Ultimately, moving away from prose makes our product much more similar to theirs and we lose our niche in that market.

I definitely saw a shift occurring shortly before I became inactive, but I am quite shocked by the complete change in philosophy in the community nowadays on this topic. NPC pages were historically one of our most featured types of articles once the OBNPCRP rolled out, and now all I see is hatred for the style those articles championed. I see what Jeancey meant by battles being lost. I know the past is meaningless in Wiki Land, but doesn't it seem odd to be changing articles that use a format similar to multiple FAs in that same namespace to something completely different? It's one thing if just new sectioning and player dialogue was being added, but Skyrim:Gulum-Ei looks completely different now than how it used to, not even factoring in the deletion of all the rumors. It's previous format was much closer to the FAs of that namespace.

Prose is usually written so that the player dialogue is still documented. The boring player dialogue is simply documented in a more interesting fashion that doesn't break the article's flow rather than having bold text on its own line that says, "What are you doing?"

Since it's nearby, on that Skyrim:Ainethach page to give two examples:

  • You can ask him if he is in charge here, which will have him further elaborate on the issues he faces as a landowner: player dialogue is Are you in charge here?
  • During The Heart of Dibella, if you tell him that you are looking for a young girl that lives around here, he will reply by directing you to Enmon: player dialogue is I'm looking for a young girl who lives around here.

It's not in bold font, but the player dialogue is there. It should be written so that the wording is exact ideally (aside from first/second person changes), but I'm not losing sleep over that (and it's a pretty quick fix if someone is bothered by it). Where I would lose sleep is if context, rumors, and emotion were not documented on the page. This is a wiki, it's about documentation, and by not documenting these items on an article, the article would remain incomplete. Forfeit (talk) 03:21, 8 May 2020 (GMT)

I submit to the group the new Ysolda appearance when compared to the old. I think this shows, similar to the intent of the edits that are the root of the discussion, that there is room for improvement in prose heavy articles. However, I think it also shows where prose is still useful and should be retained. All these edits were in line with current best practices in this namespace based on existing FAs, so I felt they were safe to make despite the existing conversation. Oh, the images might make it look terrible now, but that's got nothing to due with what we're talking about here and more to do with Forfeit's greatest editing weakness.
I added sectioning for the quest dialogue (whether general dialogue should be down there too is splitting hairs really and not a big deal to me, my reasoning against this is provided previously) and "documented" more player dialogue. I went with the Neloth style for that, but more hairs to split on how to indent it that I'm not worried about. The loose dialogue was retained in prose instead of breaking it all apart and having the context line for the dialogue on a separate line than the dialogue. The single path player dialogue was also kept in prose as I felt the existing prose paraphrased it well and did not see the need to break the flow of the article. Beyond the fact that this helps with the flow of the article, it also is more reminiscent with how books write dialogue (they aren't always jumping to a new line, particularly when they are setting up the dialogue). Similar to when a reader sees a hyperlink, every time you jump to a new line it introduces a subconscious pause in the reader's mind. Thus, you have to be careful when you introduce these.
I don't have much more to add to this discussion, but I thought I would provide an illustration on an article that was pointed out as being problematic. Do with it as you please. Forfeit (talk) 21:22, 9 May 2020 (GMT)
Hello all, I realize I am a few days late after most of this discussion happened but I hope I can still add my own two cents. As others have mentioned, I have noted previous discussions about making Skyrim NPC pages more like ESO pages. Admittedly, I'm very biased as I have written a lot of these Skyrim NPC articles but in my view taking out the prose is a giant step in the wrong direction. This might be a lengthy post so I'll try to organize my thoughts as coherently as possible.
First, I find the extended and drawn out nature of the page to actually be less readable. The Barknar page that has been discussed before felt more readable and concise before the formatting was changed. I also find the drawn out nature of these kinds of pages to just look a bit clunky and odd at times as well. In Keerava, for example, there is an uncomfortable amount of blank space throughout that article. Most of the right side of the article is blank and every single line of dialogue is given its own line. During the Taking Care of Business section, the dialogue after telling her "I'm finished wasting my time talking to you." is presented on two separate lines even though each line is barely a third of the page.
Second, as others have brought up, these articles are not just dialogue dumps. There is a greater narrative value reflected with the prose. Now, to be fair, I have not played ESO so I don't have a full grasp of the purpose of that game. However, it strikes me that it has different goals and values. More focus on social aspects, multiplayer, that sort of thing instead of single player experiences. Yet, for me, the central feature of the main Elder Scrolls games are the experience of playing and creating single player narratives. NPC pages in the Skyrim namespace should reflect that.
To sum up these points, my overall view is that these formatting changes are not good and that pages like Barknar and Keerava should be reverted back to their original style. However, I'd like to leave a few more closing thoughts.
I feel that perhaps a larger problem then this style disagreement is a lack of collaborative nature to make NPC pages better, instead just favoring more blunt approaches. I think in these discussions there have been a lot of valid criticisms by people who are more favorable to the ESO style of prose heavy pages that weren't very readable. Yet, I don't think these isolated problems with prose mean that prose is bad. My two favorite articles on this site are Cicero and Delphine and when each was initially finished by their main authors, Krusty and Psyclocke respectively, they looked much different than they do now. That's because each was nominated for a featured article and faced a lot of constructive criticism. Some of the criticism of these articles was similar to very valid criticisms of certain prose articles now, that there were too many giant blocks of texts, that they were hard to read at certain points, etc. However, people worked together to make the articles feature worthy. Delphine used more tables and player dialogue to make it more readable. Cicero used nifty journal quotes to both make it more readable and enhance the narrative effects of the page.
I think a silver lining of this discussion showed that this can still happen. Ysolda looks much better now in my opinion due to collaborative work of multiple editors here presenting criticisms and working to fix it. Yet, more often it seems that the two schools of thought on this formatting issue make edits independently of each without much discussion. I have admittedly been inactive on the wiki for the last couple of years but since returning on a semi-active manner I started by de-stubbing Beem-Ja. The version I wrote was a very standard style for a NPC page. Additionally, this is the style endorsed in the style guide, as the NPC style guide cites two pages, Legate Rikke and Delphine, that use this style. Looking back on previous discussions about this, there does not seem to ever have been clear consensus about changing this kind of style. However, this page was changed to something that does not reflect the style guide without any discussion. I personally think the changes decreased the quality of the page, but I especially think these kinds of changes should not have been made without community consensus.
Overall, I think we all need to be on the same page. I have made my views clear about which side I prefer but I would rather have either side become established consensus instead of continuing to lack one. Maroonroar (talk) 20:58, 14 May 2020 (GMT)

ESO DLC[edit]

Uses of template {{Crown Store}} with a parameter specifying a DLC were changed by a bot run to use {{ESO DLC}} instead, and that is the way DLC specific things should be marked in the future. The Crown Store template can still be used without parameters for marking and linking to the Crown Store unspecifically. Since I was a bit involved in changing those templates, I guess I should let people know about the change in usage. There are now distinguishing icons and the links to the DLC content under the icons actually work now. --Alfwyn (talk) 19:45, 13 May 2020 (GMT)

Do you want to use this on Lore:Library in replacement of what I began to do with A and B books a while ago? If it's acceptable, this solves every problem with those edits. --Dcsg (talk) 18:16, 23 May 2020 (UTC)
Better to have plain text on the lore book pages, I think. That way it will remain consistent with how we treat the DLCs from other games. —⁠Legoless (talk) 19:11, 23 May 2020 (UTC)
I would say directly spelling it out e.g. ONExtra=(Elsweyr) is best for books. --Enodoc (talk) 14:14, 25 May 2020 (UTC)

Tor exit nodes banned[edit]

Yesterday I tried to edit a page but found that all tor exit nodes had been blocked. I appreciate your efforts in keeping this wiki free of vandalism, but blocking all exit nodes also affect legitimate tor users. Would you be willing to try some captcha instead? — Unsigned comment by (talk) at 02:10 on 14 May 2020‎ ‎

TOR Nodes are only blocked from editing anonymously, they can still create accounts and edit from existing accounts. We do have users that edit from TOR/Proxies with no issues, so I can’t see a need to discontinue such practice. Kiz (email - talk) 04:44, 14 May 2020 (GMT)

Skyrim NPC dialogue[edit]

I feel like there is a big issue in regards to our documentation of Skyrim's dialogue, with people seeming to think that because the player dialogue is "boring" it shouldn't be wrote down, which in my view, goes against the point of a wiki, since it's not up to us to decide whats boring, just to document it so users can easily access it. In particular, a lot of the prose on NPC pages just basically repeats what the player dialogue says, but isn't the player dialogue, a little bit of prose like, "When spoken to after X" or "When spoken to in X", makes sense since it gives context to the dialogue being after an event/quest or only being said in a location.

I would happily go through the NPCs of Skyrim to change this, and add missing dialogue on a lot of NPCs. I know there are others who would do so too. I bring this up because as of late I have noticed quite a few people in the community stating that they use the other wiki instead of the UESP due to the lack of dialogue on Skyrim's NPC pages, the missing player dialogue, and the horrible format of dialogue being in the main body as a giant wall of text instead of being under a header of Dialogue or Quest-Related Events, I personally think the ESO and Blades method of writing out dialogue is the best example of a good mix of minor prose and actually have player dialogue alongside the NPC dialogue. Just because "its always been like that" doesn't mean it looks good or that the rest of the community enjoys it, and as stated before, talking to other members of the community on the discord and other UESP members, I know I am not the only one who feels this way.

I propose that dialogue gets moved out of the main introductory body on all NPC pages, so that it is not a wall of text, and that player dialogue should take precedence over prose. Imperialbattlespire (talk) 16:42, 5 June 2020 (UTC)

I agree with moving the bulk of dialogue out of the body of articles on NPC pages, quest pages can suffer from this "wall of text-ism" as well in some cases. I think a small amount of prose dialogue can however still be used for effect without being overwhelming like some of our current pages, and wouldn't want to see prose style quotations to be removed from gamespace in the entirety, but used far more sparingly. Kiz (email - talk) 16:45, 5 June 2020 (UTC)
I agree with all of the above. We can use prose to add context, but showing all of the dialogue otherwise uninterrupted is clean and efficient for readers. If it makes it easier for our community to get their information, I'm on board. MolagBallet (talk) 18:37, 5 June 2020 (UTC)
I believe we always come back to the same "perfect example" of SR:Neloth, which has an ideal balance of prose for context and player dialogue for detail. If other pages followed that setup I see no problems. There should never be a giant wall of text in the lead - the only time I think dialogue belongs in the lead is when there aren't any quest-related events to put it under, such as when they're just a generic vendor like Endarie, where creating a separate heading would give you a whitespace void instead. --Enodoc (talk) 18:39, 5 June 2020 (UTC)
Skyrim's dialogue is formatted atrocious enough that I would rather look at an article on the competing TES-related wiki than read through UESP's page. The dialogue shouldnt bleed through the main body, whoever decided this was a good idea needs to rethink this. On the topic of prose, i dont think it should be a primary goal we should look for, but it should be something that should be used sometimes to make a page better. As a reader, i'd mostly want to see what a person actually said.Zebendal (talk) 21:07, 5 June 2020 (UTC)
I respect that the active community and I are on completely different wavelengths in regards to this so I'm going to stay away. Where we are on the same wavelength, if I had to guess, is that I don't want to write another long post and you don't want to read another long post!
I've re-evaluated this and will continue to side with 11 FAs (in the Skyrim namespace alone). I personally think this new style is harder to read and creates new documentation gaps. It's unfortunate too as the harder it tries to deal with the documentation gaps, the more readability suffers and vice versa. I also think it must be mentioned that the player dialogue is often already there except paraphrased to second person, so this is more of a style issue than a content issue as is being potentially implied (we'll agree to disagree that flipping I's to you's is a content deficiency).
One thing I will humbly ask though is that rumors (what other characters say about the NPC) continue to be included on these pages as they are updated. I have seen these getting removed. As Legoless mentioned in the last discussion, any style updates still need to make sure to meet the goals of the OBNPCRP in terms of content. It's effectively our style guide for NPCs, and I can't imagine that this won't bleed over into Oblivion/Shivering eventually. The documentation of the character remains incomplete without those, much for the same reasons given for including exact player dialogue. I disagree with the repetition argument for excluding these. Good luck, and thanks everyone for trying to improve the reader experience! Forfeit (talk) 03:37, 8 June 2020 (UTC)

Category:Online-Pre release Images Cleanup[edit]

Imperialbattlespire and I have been doing some clean up of the Category:Online-Pre release Images. The biggest thing was moving all the images of Crown Store items to Category:Online-Crown Store Images. Now renaming and updating links will be some work but with future Crown Store images uploads, could you refrain from using -pre release- as a category and use -crown store- instead.

We have also created other categories for trailer images and renders which don't really belong in Event or Pre-Release.--Talyyn (talk) 16:48, 10 June 2020 (UTC)

Page Title vs. Search Engine Optimization[edit]

There's been some talk on Discord about possibly altering our page titles in the hopes that they would improve search rankings of pages like Lore:Daedra where the primary search term is mixed in with a namespace name. The thinking is that this may appear to SEO logic like it's a single word, "Lore:Daedra", rather than two words, "Lore" and "Daedra". The proposal is to alter the display title to read Lore: Daedra with a space. As you can see, this wouldn't bother copy-paste linking in any way, though it would likely lead to a sharp increase in the number of links on the wiki with spaces in them. To be clear, though, companies keep their SEO logic highly confidential to avoid malicious manipulation, so we have no way to know for sure if this would actually have the effect we want, at least not immediately.

I looked into how feasible it would be to make this the default for the entire site and I can't find any direct way to do it without altering the MediaWiki programming. We can, however, get there in a more roundabout fashion for the vast majority of the pages we'd want to do this on by adding a {{DISPLAYTITLE}} to both {{Trail}} and {{Trail2}}. The one minor problem with this approach is that it would invalidate any existing DISPLAYTITLE if it occurred before the Trail call (or whatever other template might be involved), so we'd have to fix the template/DISPLAYTITLE order on any affected pages. I suspect that would be a very small number of pages, but don't quote me on that!

Along with this, there's also a suggestion to change the primary name for Online space to ESO, both for user-friendliness and SEO optimization. Very few people search for "online daedra" or think of the game they're playing/page they're reading as being "Online". This should pose no problem at all from a technical standpoint, so it's really just a question of how people feel about "Online:Daedra" vs. "ESO:Daedra" displaying as the page title. (Again, from a linking standpoint, the name and/or spacing make no difference at all, since ESO is already defined as an alias for Online.)

Does anyone have any thoughts on either of these suggestions? Robin Hood  (talk) 16:16, 15 June 2020 (UTC)

I think this is a fantastic idea. When I started editing UESP it seemed very unnatural to me that pages displayed as "Lore:Daedra" without a space, so I definitely think adding a space would help with user friendliness. I'm also a big fan of moving over to using ESO; the game's name is not Online and never has been, and I really don't think the term "online" is conducive to good SEO. —⁠Legoless (talk) 16:27, 15 June 2020 (UTC)
You're absolutely correct about Google SEO algorithms. There is no way to know if space will make any difference at this point. That said, the algorithms sophisticated enough to know when and when not to take spaces into account. For this reason I highly doubt a space will make any difference, although I'd love to be wrong. If its for the sake of readability... then i'm not too sure. Is there evidence the current format is less unreadable?
Search the term "Daedra" or "Deadra elder scrolls" and we are page 1 rank 3. Search the term "Deadra lore" and we are page one rank 1. Page ranking is much more than the page title - although having a solid h1 title is absolutely important, among many other things.
In regards to changing to "ESO". Again, there is no evidence this would help SEO. The algorithms sophisticated enough to know "Online" is synonymous with "ESO" when mixed with another term. For example, search "eso mounts" on Google. We appear on page 1 rank 3, desipte the fact the Mounts literally has no mention of the term "ESO". Only "online. The only reason I would change it to "ESO" is because that is what the community now calls it without question, so its more user-friendly.--Jimeee (talk) 16:58, 15 June 2020 (UTC)
If we switch to ESO, I would think that for user friendliness switching extant links from Online/ON to ESO. To complete as well, we’d need to redefine (or add as an acceptable shortcut) ESO to any ns_base parameters. Kiz (email - talk) 16:59, 15 June 2020 (UTC)
Links could be done in the same fashion as converting underscores to spaces—in other words, if and when someone feels like doing it during another edit. I don't see a need to replace them en masse, since it would literally change nothing beyond the text itself. In most cases, ns_base=ESO will already work, so that could be done the same way. I'm pretty sure the swap of namespaces would make absolutely no difference there. We would have to take a look at some of our templates, though, like {{Nst}}. At least as things stand now, that expects "ON" and nothing but. Similarly, {{ON}} itself should probably become a redirect to {{ESO}}. MetaTemplate is mostly separate from our actual namespaces, though, so that can all be done afterwards, I think. For now, it could retain its "ON" setting and we'll change it over to "ESO" when we're ready. Robin Hood  (talk) 17:20, 15 June 2020 (UTC)
I believe the reason why ON was chosen was to adhere to our two-letter shortening for images and such. I don't seen an issue continuing that method. I personally think ESO:Mounts looks silly, and likely Lore: Daedra will look silly, but that may be down to what I'm used to rather than actual silliness. Since ESO already works, I don't really see a need to make a massive change of all existing links to ON. We really haven't had much of an issue with people messing up the namespace part of the link (typically if it's messed up, it just isn't there, which wouldn't affect Online vs ESO). I'm with Jimeee, I don't think ESO vs Online has an affect on ESO. Jeancey (talk) 17:38, 15 June 2020 (UTC)
For the page titles, I'd be happy to remove the namespaces completely; we don't show links as Lore:Daedra or Lore: Daedra, we show links as Daedra, and I think that is therefore the most logical for the page title as well. On a related note, if we did this, it then wouldn't matter whether we used Online or ESO, because it wouldn't show except in the page tab. --Enodoc (talk) 18:51, 15 June 2020 (UTC)

() There are two issues with removing the namespace altogether, albeit minor ones. The first is that it makes copy-paste linking available only from the URL, which is a bit trickier than highlighting the entire title. The second is that in order to eliminate the namespace from the title, we have to remove DISPLAYTITLE restrictions altogether, which then allows for silliness like CP getting displayed as "The Page People Talk On A Lot" or some such thing. I don't think that's that big of a deal, since people would just revert that kind of change, but it's one more thing we'd have to keep our eyes on. Robin Hood  (talk) 20:32, 15 June 2020 (UTC)

We may also get a rise of people linking to the wrong namespace, since instead of seeing what namespace they or the page they want to link to are in, it all just displays as "Daedra". We might get lots of confused folks. I really don't see an issue with displaying the namespace. Very few people are confused with it's presence. We're established enough that most readers understand namespaces, and those that haven't seen them before can understand that Skyrim:Daedra is going to be about daedra in skyrim and that Oblivion:Daedra is about Daedra in Oblivion, they aren't really that likely to be confused as to what the page is about. Having a page just say Daedra, they might get confused about what game it is referring to, since there are relatively few other places the namespace is mentioned and they are MUCH smaller. Jeancey (talk) 20:57, 15 June 2020 (UTC)
I don't think hiding namespace entirely is a good idea. Per Jeancey, it will lead to confusion if we have 6+ pages all titled "Daedra". —⁠Legoless (talk) 21:44, 15 June 2020 (UTC)
Yeah I get that. That doesn't mean we can't (or shouldn't anyway) improve inter-linking between same titles in different namespaces. And the namespace is already in the Trail and the Article tab, which is right next to the page title. I imagine DISPLAYTITLE can't take markup, because otherwise I'd suggest something like Lore: Daedra, where the namespace is there but smaller. --Enodoc (talk) 23:10, 15 June 2020 (UTC)
Turns out the size thing does work, so that's my suggestion. Add a space, but also make the namespace name itself smaller. --Enodoc (talk) 00:24, 16 June 2020 (UTC)

Gallery Mode and Image Ratio[edit]

Continuing from the discussion earlier in the year, we had considered changing the default gallery mode from traditional to packed to better display non-square images. In quick summary, packed is a responsive design and sets images within the gallery by height, not width. We would also remove the current formatting that was implemented to packed so that it mirrored the design of {{Multiple Images}}.


As an extension to this, we could also consider allowing completely non-standard aspect ratios solely in galleries, because in packed mode, they wouldn't look out-of-whack with everything else. Things like File:ON-place-Karthwatch.jpg (right) would then have a place to go.

These two things (the gallery mode and the aspect ratio in galleries) need to be taken as separate proposals but there is merit in considering them together. --Enodoc (talk) 19:20, 23 June 2020 (UTC)

Support this packed format fully, gets rid of the awful white space, and with the new standards of allowing 16:9 and 16:10, it makes even more sense as they have a lot of white space with the "traditional style".Imperialbattlespire (talk) 18:15, 24 June 2020 (UTC)
I support changing the gallery mode, but I do NOT support allowing literally any aspect ratio to be used. I think we should still restrict it to the allowed aspect ratios. Jeancey (talk) 18:25, 24 June 2020 (UTC)
I also support the new packed format. It looks clean and neat while displaying a larger number of image aspect ratios better than the previous. I do not support allowing any aspect ratio to be used in galleries. We should consider putting guidelines for gallery images on Image Standards to avoid confusion and provide clear documentation on what is allowed. I do think that allowing one or two modern resolution and aspect ratio combinations only for galleries might be worth discussion. Ultrawide screens are becoming more prevalent and can provide some panoramic type images similar to the one Enodoc linked above. These screens run at 3440x1440 and use a 21:9 aspect ratio. Thuraya Salaris (talk) 21:22, 24 June 2020 (UTC)
Either I didn't implement it correctly, but adding adding a description to images in the gallery in the first case puts the text below, not in the white area, which I thought would happen, and in the second case it was nicely included in the frame. So especially with this being the case, I'd agree the packed version just looks better. ~ Dwarfmp (talk) 00:12, 25 June 2020 (UTC)
Regarding aspect ratios, which I'm noting just because I find in interesting, Bruma has had a non-standard aspect image as its primary image for nine years, which is also a Featured Image. At what point does a nice-looking image render itself exempt from the guidelines? --Enodoc (talk) 18:43, 25 June 2020 (UTC)
To be honest, I've always found that image super small and hard to figure out on the page... Jeancey (talk) 20:51, 25 June 2020 (UTC)
I think the answer to that has to be: Only when an image that does meet the guidelines is unable to fully capture the subject. If a subjective opinion of "it looks good keep it" is allowed to rule then there is no point in any image standards at all. Thuraya Salaris (talk) 00:17, 26 June 2020 (UTC)
In fairness, a lot of Oblivion articles are left wanting for images. OB:Market District didn't have a single screenshot until two days ago. I don't think an Oblivion article lacking a standard image for 9 years is a good thing; those panoramic shots are cool but there's nothing preventing us from taking a new one (and maybe adding the panoramics to one of these newfangled galleries). —⁠Legoless (talk) 08:15, 26 June 2020 (UTC)

() Replying in response to the Packed Gallery style. I agree, can we start using it?--Talyyn (talk) 10:33, 26 June 2020 (UTC)

I agree with Jeancey, support the gallery, don't support the aspect ratio change. Kiz (email - talk) 19:26, 26 June 2020 (UTC)
Galleries have now been updated to default to mode=packed. Pages containing galleries may require a purge or hard refresh to get them to update properly. Robin Hood  (talk) 17:59, 4 July 2020 (UTC)
Any way to shrink the images back to the previous size on specific pages? General:Wallpapers in particular is looking a bit destroyed after this change, would be better off with smaller thumbnails. —⁠Legoless (talk) 23:16, 5 July 2020 (UTC)
There are several different mode options. The previous default was "traditional", so you can use <gallery mode=traditional> to go back to that style. There's also mode=nolines, which is very similar to packed mode, but much smaller. There are still more options than that, though...see Mediawiki's page for more details. Robin Hood  (talk) 23:33, 5 July 2020 (UTC)
I believe nolines has a consistent width, as opposed to packed which has a consistent height. If that is preferred, we can change the default to nolines instead. We can also change the default heights separately from the default widths; the default is currently 200x200, but we could have 200x180 for example if that would be preferred. --Enodoc (talk) 20:02, 6 July 2020 (UTC)

Edit Break[edit]

It appears that the changes have exposed the packed mode's "feature" of being responsive and selecting "optimal sizes" rather than being strict to the heights it's been given, resulting in a bit of a mish-mash of image sizes in larger galleries as it tries to make rows a similar length to each other. There are two solutions I can think of for this which don't involve reverting the change outright. These are not mutually exclusive and we could pick one, both, or neither.

  • Change the default mode to nolines instead. This has fixed widths instead of fixed heights, and these are strict. This loses the intended approach of reducing the spacing, but keeps the removal of the white background box.
  • Change the default height to 180px. This keeps the intention of the same height being the core purpose of the change to packed, while potentially reducing the overall negative impact of its "responsiveness".

A third option would be to try and address what we've got with css, which I haven't looked into. --Enodoc (talk) 19:27, 12 July 2020 (UTC)

I'd like to see Option #2 (180px) tried first. Option #3 (CSS) can be messy with resizing images sometimes, though we could certainly give it a go, but that wouldn't be the optimal solution. If we're going back to fixed widths rather than heights I think we're losing the main advantage of switching from traditional in the first place. Kiz (email - talk) 01:09, 13 July 2020 (UTC)
I'm having a huge issue when using the desktop site on my phone; whenever I scroll, the page readjusts the galleries, and everything after that jumps up and down... (also applies to category pages with images) -- SarthesArai Talk 15:09, 14 July 2020 (UTC)
--Enodoc (talk) 16:07, 14 July 2020 (UTC)

Graph Extension now available for use[edit]

With the new wikimedia version, we have access to the Graph Extension (write up pending). It's this extension from MediaWiki. It uses Vega, a format that uses JSON and HTML to visualize all kinds of different graphs. This post is mostly a heads-up that if people want, it is now available to use. At the moment, Dcsg and I are working hard to get graphs templated on the wiki and some results can already be found here and here. Many more great things are possible if we can get them to work, but it needs a bit of technical knowledge before we can truly do the crazy stuff. It can get really awesome with all kinds of interactive modules as seen in some of the demos here and here, but that is all far in the future as of now.

Please let us know if you're interested in using it, have feedback, questions, or if you're familiar with JSON and can help is out. --Ilaro (talk) 17:59, 24 June 2020 (UTC)

I also made the template {{Graph}} to store one-off graphs so that they don't clog up the page they're used on. - Dcsg (talk) 23:16, 26 June 2020 (UTC)

Effect Syntax Conventions[edit]

I have been creating {{Effect Text}} as a template very similar to {{Effect Link}} where it instead displays the syntax of the effect, like how it would appear in-game.

Example (Blades namespace): {{Effect Text|Restore Health|m=80}}Restore Health +80 Health. Note that there is an option to display it simply as raw text for any relevant applications.

I made it with Blades in mind, but I figured that what I was doing was generic enough to design it to allow for use in other namespaces. However, I realized that it would soon be problematic with the current variable-naming conventions suggested by {{Effect Summary}}. Simply M and D (for magnitude and duration respectively) are not unique enough to use #replace without erroneous replacements. For example, #replaceing "+M Magicka" would replace both M's, despite only the first M corresponding to the effect magnitude. Skyrim follows a different convention, using things like <mag> and <dur>. This is a better, more unique way of indicating the variables in an effect that would work flawlessly with {{Effect Text}}. This brings me to the following options:

  • Replace all instances of M, D, etc. with <M>, <D>, etc.
This is the simplest option. It would allow the template to work by #replaceing different search terms depending on the namespace. If desired, {{Effect Summary}} could be tweaked to #replace any <M>s, <D>s, etc. back into M's, D's, etc., therefore allowing this change to be entirely internal.
  • Replace all instances of M, D, etc. with <mag>, <dur>, etc.
Similar to the above option, but would allow for more clarification and a single site-wide convention. Similarly, this change could be done to only appear internally.
  • Replace all instances of M, D, <mag>, <dur>, etc. with <magnitude>, <duration>, etc.
This option is similar to the one above, except the explicit spelling would prevent any confusions that M/mag might mean magicka or that D might mean damage or any misunderstanding of that sort. This change can also be done to look identical as far as the user can tell.
  • Only use {{Effect Text}} for Blades, inputting the syntax parameters of Blades effects with whatever variable naming convention that is appropriate.
This option only changes the handful of Blades effect articles that are currently created. If there is no benefit to allowing use of {{Effect Text}} on other namespaces, then this option could have some validity, though I would argue that the standardization across the namespaces would be beneficial in its own right.

Each option has its benefits in regards to standardization, clarification, and use with {{Effect Text}}. The downsides could include making creating new effect articles slightly more tedious and departing from the conventions used from each game's actual code, the latter of which can be solved with the aforementioned tweak to {{Effect Summary}}. Please let me know how you feel about this suggested change and which option you may prefer. --Dcsg (talk) 21:20, 14 July 2020 (UTC)

I'm all for standardization and consistency. I think the clearest option should be used, which means just writing the full <magnitude> and <duration>. We don't have to type it out every time anyway, as the templates will still just call the parameters "m" or "d". --Ilaro (talk) 13:43, 15 July 2020 (UTC)
I agree with Ilaro's choice and reasoning. It hadn't occurred to me when we were first tossing around ideas that this method still allows us to replace effect text on a per-namespace basis if some later consensus decides that's preferable. At the moment, though, I think consistency across the site is the better choice, as opposed to matching something as arcane (to most readers) as the precise effect syntax the CS/CK uses. Robin Hood  (talk) 08:42, 18 July 2020 (UTC)

Concerning Skyrim armor, Specialty Gear and Unique Armor[edit]

I'm putting this here cause I think it deserves some attention and is a bit of a general thing. I'm having a problem with the state these pages (Skyrim:Specialty Gear and Skyrim:Unique Armor), are in and what the definition of them are. The Specialty Gear seems to list some incomplete faction item lists, and also unobtainable items already listed on that page. Not to mention the page split suggestion from as early as 2012.

Then there's the individual and supposed unique faction armor pages (come on...) that I think should be on one page as a list, considering they are part of a set. The Shrouded Armor in particular isn't even unique according to those standards, as you get them through a quest, while pieces are also found at the Dawnstar Sanctuary. In fact, by those standards, the Worn Shrouded Armor pieces are unique, yet they're just put on the specialty gear page. Let's be honest, considering faction armor as unique simply because the player has a different set for gameplay reasons is silly. I'd much rather see these in a list with total stats just like regular armor, even just for comparison.

Which brings me to another point concerning all armor pieces. I think it's important to mention in some way (as part of a table perhaps) any material keyword attached to armor (and weapons) in general, cause it tells you the information you need for the matching set perks and the smithing perks. ~ Dwarfmp (talk) 00:46, 26 July 2020 (UTC)

Linking to Older Images[edit]

Hi folks!

Is there a way to add a gallery link to an older image that's been replaced by a new one? One of my favorite images has been superseded by a newer image and I'd like to link to the older one in my Favorite Images gallery. I tried putting the archive link into the gallery but that doesn't seem to work. Any help would be appreciated, thanks! — Wolfborn(Howl) 20:11, 22 August 2020 (UTC)

You can't use older images in galleries or by image links, at least not as far as I know, but what you can do is download the older image and then re-upload it as a user image (with a name like User-<Username>-<Description>.ext). Robin Hood  (talk) 23:23, 22 August 2020 (UTC)
That solution had occurred to me, but I thought I would check if it were possible to use the existing image before uploading it again. Guess that's what I'll have to do, though. Thanks for the help! — Wolfborn(Howl) 23:36, 22 August 2020 (UTC)

Modspace Maintenance[edit]

I've found that some of the trails in the various modspaces tend to be lacking in both function and design. Design-wise, I believe that a trail should lead you to less specific / more "encompassing" pages. Why, then, does the first link in a default {{trail}} on a modspace page lead to the base game when said page makes no link or mention of the modspace. For this reason, it should almost definitely link to just the Mods page. However, having the base game in the trail is very functional for cross-referencing and more. I propose that all of the modspaces use the form [[Mods|Mods]] / [[Base Game:Base Game|Base Game]]: [[GameMod:Main Page|GameMod]]. I think that this is the most true to what a trail is supposed to do.

Additionally, the modspaces are supposed to be the home for mods and technical information, but there are some pages like Daggerfall:Hacking Guide (and all its subpages) and Category:Battlespire-Hacking Guide whose contents have not been moved over. I think that they should be moved, as that is where one should come to expect that kind of information.

While I'm on the subject, is there any reason a link to the game's relevant modspace isn't in the See Also of the base game's main page?

Finally, naming conventions for modspace-related files. It seems to be all over the place, with things just being named whatever. Are there good reasons why they don't follow an image-like naming convention with at least NSID- preceding the name of the file?

If any of what I've suggested comes to pass, things should definitely be leaving redirects, as much of it is quite old and there may be other websites that link to the pages or bookmarks people created for them. However, I think that everything I suggested would help to concretely define what the modspaces are and solidify them as a fleshed-out, valid place on the UESP. — Unsigned comment by Dcsg (talkcontribs) at 18:39 on 10 September 2020 (UTC)

Those namespaces are new so those pages you mentioned were just missed when everything else was moved over. It's no issue to move them, just be sure to keep the redirect around since those pages are very old and could be linked externally. —⁠Legoless (talk) 18:48, 10 September 2020 (UTC)
Agreed on most fronts, moving older stuff over to the modspaces should help with consistency across the wiki, and linking to the modspaces from gamespace main pages should help with visibility. I hadn't noticed the trail issue until just now, but your suggestion sounds like a good one. As for establishing a naming convention, I don't know what you mean by NSID- in particular. Thal-J (talk) 19:05, 10 September 2020 (UTC)
Like how a shadowkey image always starts with File:SK-. So, in this case, I'm asking if non-image modspace files should start with something like TOther-. -Dcsg (talk) 19:08, 10 September 2020 (UTC)
(edit conflict × 3) Modspaces are already linked from the main page of the gamespace for everything that had a modspace prior to the creation of the newer ones, and all but ESO are a direct transclusion of the modspace main page. TesOtherMod and Tes1/2Mod are a just bit behind on that front, probably because they're newer and nobody got around to those yet; we just need to decide how to do something similar for TesOtherMod in a way that works for that namespace.
I always thought that the modspace names, while functional, aren't particularly "nice" either, so I'd say we could even remove the name of the modspace from the trail completely. Linking the modspace main page itself doesn't really have a functional purpose, as all modspaces are immediately divided into Mods and Modding, which are more useful as root pages for navigation, and both Mods and the gamespace main pages have the transclusion, so I think Mods / Game would work quite well by itself.
The Modspace isn't linked in See Also of course because for the most part it's already linked somewhere else. Arena and the spin-offs are the only exception, again probably just because those are the newest modspaces.
Image naming convention should indeed be that it matches the NS_ID on MediaWiki:Uespnamespacelist, so wherever that isn't currently the case is likely just wrong.
Also please consider joining the Modspace Project, as these are some great ideas! --Enodoc (talk) 19:11, 10 September 2020 (UTC)

Notability for Lore Articles - Creating Guidelines[edit]

After some discussion, it has been noticed that the UESP Wiki doesn't have a set of guidelines involving notability in relation to lore articles. Across the entire game series, we literally have thousands of characters. While at best all of them should have some sort of page in their own gamespace, it is another matter when creating a lore page.

What do we consider notable enough to merit a lore page, a section on the People pages or just a nominal mention on a related lore page? I am aware that there has been arguments/discussions about this previously but a set of guidelines should be made so in the future when the question of notability comes up, we have something to point to.

In my opinion, there is a certain degree of context involved. For example, if I had to consider notability on broad terms such as Notable [Race Name], I would have to consider both the game series as a whole and how consquential that character was to history. For Khajiit, Rid-Thar-ri'Datta influenced the Khajiit on a cultural and religious level which is still felt to the present day. Of course if we held every character to those standards, then the list of notable characters would be vanishingly small. And so I guess notability should also be looked at through the lens of the game(s) they appear in. Do they matter in the grand scheme of things? In-universe, would they be considered notable?

Of course they are opinions and can change, but a discussion on these matters should be started and hopefully some guidelines be drafted.--Talyyn (talk) 08:42, 14 September 2020 (UTC)

We do actually have notability guidelines. Lore:People, Lore:Flora, and Lore:Artifacts all have information about what qualifies to be there. If additional guidelines or clarifications are needed, it should be a simple enough process to start a talk page discussion on the relevant page (e.g. defining place notability on Lore talk:Places, which currently has no info on this). I agree that context is important and I feel like any guidelines need to be discussed in context, rather than as an overall broad discussion which is likely to miss out on some of the finer details. —⁠Legoless (talk) 09:12, 14 September 2020 (UTC)
"Historical relevance" was always the general unwritten rule - I agree with Talyyn that it would be good to codify what this means in certain places a bit more specifically. Lore:Books is another one that doesn't necessarily have clear guidelines. --Enodoc (talk) 19:17, 15 September 2020 (UTC)
Lore:Books is way behind on ESO. There are so many lore-relevant books in that namespace that need a lore transclusion. The general rule for Lore:Books has been anything that isn't an irrelevant personal note. —⁠Legoless (talk) 16:32, 20 September 2020 (UTC)
Looks like we may need to come to a decision more quickly here. I would propose that book that doesn't add anything NEW to lore should also be excluded. Specifically, books that are essentially descriptions of quest directions, such as the Litany of Blood, which is just a list of NPC locations for an achievement, doesn't really need to be in lore. Whereas a personal note written by a king might be good to include. I also think that we shouldn't make the guidelines overly broad under the thinking that "Well, it can't hurt". I don't see how adding pages that will never be linked to as references and will never be touched again (aside from template changes) helps the lorespace out. I do believe this should remain a manual process, perhaps we could have a new project to assist with adding books to lore. Adding thousands of useless notes to lore with a bot job is needless and significantly increases the noise and work when templates need to be updated. Jeancey (talk) 19:29, 24 September 2020 (UTC)
Turns out that the guidelines for Lore:Books are actually at Lore:Library. I agree with most of those as it clearly quantifies books with authors and books that look like books. The one I have an issue with is "relevance", as it relies on interpretation of the "goal of lorespace" (which is to be "an encyclopedia of accurate and verifiable information in The Elder Scrolls universe"), and is therefore not quantifiable. If a guideline is not quantifiable, it is impossible to follow it consistently, which leads to an inconsistent experience for our users.
Therefore I'm going to suggest that the only way to codify the Library guidelines in a consistent way is to remove the possibility for personal interpretation of "relevance", and we should instead either default to the preceding guideline of not including any journals, notes or letters at all, or decide what "relevant" actually means in real terms so that it can be spelled out. The guidelines already allow for citing journals etc from other namespaces, so citability is not a valid condition for relevance. --Enodoc (talk) 00:13, 25 September 2020 (UTC)

() Excluding journals etc. is arbitrary and not a useful parameter here. There is very little reason for us to be citing other namespaces—clearly if a text is being cited it belongs in lorespace. Our definition of "relevance" to date has been very lax (see this discussion) and I see absolutely zero benefit in tightening these restrictions. It would be far more useful to transclude too many ESO texts from lorespace than too few; that is the approach we have been taking for many years in other namespaces.

With so many ESO books absent from lorespace, it would be far easier to run a bot job on transclusions and worry about deletions at a later date if there really is a pressing need to reconsider this policy. Personally I don't see the value in forbidding such transclusions, but this debate should not be holding up the improvement of ESO book pages. —⁠Legoless (talk) 01:05, 25 September 2020 (UTC)

I primarily agree with Legoless. There appears to be a misunderstanding of that guideline that needs clarification here. That guideline is saying a document with an author, excluding journals, notes, and letters, is almost always going to be a good addition to the lore library. It is NOT saying that journals, notes, and letters should never be included. In fact the guidelines very clearly list several journal that are included to make that point clear. I also don't believe there is any possibility of any guideline(s) that could do a better job of explaining what is relevant or not than what we currently have. More importantly, looking for a perfect guideline that covers any case is just not how any of our guidelines work. Guidelines and policies are meant to ease process, not be some perfect and rigid code. --AKB Talk Cont Mail 01:15, 25 September 2020 (UTC)

Page Title vs. SEO, Follow-up[edit]

Enodoc just reminded me of this conversation back in June. While there were definitely different opinions on the various aspects, there seemed to be overall support for altering the display title (making the namespace smaller and adding a space) and for swapping "ESO" in as the primary namespace name instead of "Online". So, I've gone ahead and made those changes.

For the time being, this will lead to a bit of a hodgepodge because not all pages actually have {{Trail}} or {{Trail2}} templates on them, so some titles won't be affected at all (e.g., most of the main pages and those outside of gamespace). Also, the ESO/Online swap leads to the oddity that is ESO:Online. All these can be addressed with time, but for now, I'm not aiming to address them immediately. Instead, I want to see how people feel now that the preliminary changes are in place. These are all easy-come, easy-go, so if we decide we don't like certain aspects or whatever, we can easily change anything that needs it.

So, how do people feel about the changes? Robin Hood(talk) 22:24, 18 September 2020 (UTC)

The change from Online to ESO seems to have been made without much impact and is having a massive impact on the site, as all of the categories in Online space are broken and many templates as well. In addition, this change was made following a relatively minor discussion several months ago where this change is not a primary focus. I think we should revert the changes and hold a bigger discussion considering the impact it's having, and the implications of such a change would have (moving tens of thousands of images and categories is something that shouldn't be taken lightly). The original discussion didn't fully support this anyway, so I don't think this change is something that should have happened in the first place. Jeancey (talk) 23:04, 18 September 2020 (UTC)
I like the changes in general, although I think the ESO change broke more things than were anticipated. I would however be interested in opinions of the visual change, which was the primary aim, as the technical stuff can be fixed one way or the other over time. --Enodoc (talk) 23:11, 18 September 2020 (UTC)
(edit conflict) I followed what I thought the consensus had been, but if I misread consensus, I apologize. I honestly don't recall who brought up the change back in June...you'd have to trace through the old Discord chats...but since it had been suggested repeatedly over the years and I thought it had consensus, I went ahead with it. The change does seem to have had a wider impact than I expected, though, so for now, I've reverted to Online as the primary name. ESO: links will continue to work, of course, as they always have. I do think this is worth some consideration, as virtually everyone thinks of it as ESO, not Online, but clearly, it will take a bit more planning and template adjustments than I'd realized. Robin Hood(talk) 23:15, 18 September 2020 (UTC)
While it is my personal opinion, I just don't think the size change of the namespace name looks good. It makes me think something broke with the page, if anything. --AKB Talk Cont Mail 23:21, 18 September 2020 (UTC)
Just a quick technical note on the impact of the ESO/Online change for future reference: manually changing the NS_ID entry for ESO/Online to "ON" would have eliminated most, if not all, of the issues we saw. It's something we can try on Dev if people are strongly in favour of the Online-to-ESO change. The template issues could then have waited indefinitely and we could have had a broader discussion of whether to change files, templates, etc. Robin Hood(talk) 23:34, 18 September 2020 (UTC)

() The change from ON to ESO was a good one and should be restored. Trying the NS_ID fix on a test server first sounds like a good idea before we go live with it. RH is correct, this change has been brought up several times over the years since the creation of the Online namespace in 2012. It has been clear since launch in 2014 that "ESO" has become the official shorthand name for this game; nobody who is looking for ESO info is going to be googling "Online". In line with the other SEO change and also in the interest of good naming practices, I support the change.

Regarding the new spacing for article names, I think it's a good change but I agree with AKB that the smaller fontsize looks a bit strange. —⁠Legoless (talk) 16:22, 20 September 2020 (UTC)

Agree with Legoless on the ON vs ESO issue. Also agree with Legoless and AKB that the new namespace font size looks weird. Having a mix of font sizes in the page title just doesn't look right to me. — Wolfborn(Howl) 04:02, 21 September 2020 (UTC)
@ Legoless when you said "nobody who is looking for ESO info is going to be googling "Online". In line with the other SEO change" Its a myth that "Online" is affecting SEO and its easily disproven. As I said last time, Google's algorithms are sophisticated enough to know "Online" is synonymous with "ESO" when mixed with another term. Hence, this change won't affect SEO whatsoever. The only reason I would change it to "ESO" is that's what the community now calls it without question, so its more user-friendly. But if it breaks a million things, I'd not bother. Also, mix of font sizes looks terrible
There are other reasons why newer ESO sites are appearing higher in google and being used and linked to by the community (such as Alcast's ESOsets, ESO Fashion, etc), and it's not because of SEO. --Jimeee (talk) 08:39, 21 September 2020 (UTC)
Sorry Jimeee, that's easily disproven. If you look up "online sets" and "eso sets" in incognito, you will get very different results. The fact of the matter is that nobody is using the former to search for ESO set info. Obviously the best thing to do would be to type "sets uesp", but this is still a good change to avoid user confusion. —⁠Legoless (talk) 10:15, 21 September 2020 (UTC)
Edit: I think we may be talking at cross-purposes here. The reason for the change isn't because UESP doesn't show up when you google e.g. "eso sets", but rather about making our page names actually reflect the correct terminology rather than depending on Google and readers to make that connection. —⁠Legoless (talk) 10:28, 21 September 2020 (UTC)
Since nobody seems to like the mixed sizes (myself included), I've gone ahead and removed that change. The space in the title remains for now, since I don't see any huge outcry about that. As far as Online vs. ESO, I do think it's something we should be looking at changing for exactly the reasons Legoless mentions. Google may have learned to associate Online with ESO, but nobody outside of UESP does. Even with Google, I imagine that's a learned behaviour, and it can obviously still be fooled as Legoless points out. There are also other search engines which may or may not be making the association. While there seems to be some disagreement about whether it's necessary, I think it's probably a good idea to at least look at changing Online to ESO, so we're talking in concrete terms rather than hypothetical. To that end, I'll start playing around on Dev when I have the chance, so at least we'll know for sure that we won't break 100 templates right out of the gate. ;) Robin Hood(talk) 15:50, 21 September 2020 (UTC)
@ Lego re: If you look up "online sets" and "eso sets" in incognito, you will get very different results. - yes, and this proves my point about SEO exactly - on the results page for "eso sets", the Online:Sets page appears on page 1, despite that page not having the term "ESO" anywhere in it. This means likely search terms (using ESO) from regular people currently point to uesp. I still agree though that we should switch to ESO as the namespace as its the agreed community term (provided it wont break templates) - and that itself should be reason enough. --Jimeee (talk) 16:13, 21 September 2020 (UTC)
(edit conflict) I just made the basic changes on Dev, and most things continued to work as expected. There was some template breakage, not unexpectedly, but most or all of these could easily be adjusted beforehand to work with either Online or ESO, so there would be little, if any, disruption during the changeover. (For the templaters, we're mostly looking at things that use NAMESPACE, NS_BASE, NS_NAME, or NS_PARENT in #if and #switch statements.)
After that, if we went for a full changeover, there would need to be mass template updates and category/file moves. This would be comparable to the Drangoborn/Skyrim merge in a lot of ways, so there would be some disruption during the initial large-scale bot changes, but that would fix most things by the time it was done and then there'd probably be some manual changes or additional bot jobs to fix any remaining issues. Online space is much larger than Dragonborn was, so it's hard to give a good estimate of how long all that would take, but I imagine the bulk of it would be done within a day or so, then follow-up would be as we spot things. Robin Hood(talk) 16:44, 21 September 2020 (UTC)

() Personally, I think we should just modify things so that Online and ON continue to be used for the categories and templates. ON fits with our two character prefix usage (which is why it was chosen over ESO originally), and anyone who is that focused into file naming will understand. In terms of categories.... Online just looks nicer, as a Single capital and lowercase everything else, aethetically fits with Skyrim and Morrowind and all the other namespaces. ESO doesn't fit with that aesthetic and I think this will cause pretty much all categories to seem "weird" or "off" for the namespace.

Plus there's the added benefit of not having to mass move tens of thousands of pages.... Jeancey (talk) 18:22, 21 September 2020 (UTC)

UESP's entry into #TamrielTogether Contest[edit]

Zenimax's recent contest involves a guild crafting a poster or short video that celebrates or promotes a guild. The grand prize is all guildies of two guild that wins recieving a unique mount and furnishing that has the guild's crest, memorilizing the guild with exclusive collectibles. UESP is a well know name within the Elder Scrolls community, and has created an ingame community in eso, as well as one that spans multiple TES games, it would be the perfect contest for UESP to enter. Plus, UESP would finally become canon in-universe. For more information, read on here in the Guild Contest section. https://www.elderscrollsonline.com/en-us/news/post/58841 Zebendal (talk) 14:43, 29 September 2020 (UTC)

It'll be two entries, to be clear. Unless you are suggesting we ignore the EU guild, or ignore the NA guild. I would also like to point out that a significant number of people involved in the in-game guilds aren't on the wiki, as they are part of the greater UESP community. It might be good to reach out to them in-game to see if something is already being planned. Jeancey (talk) 17:32, 29 September 2020 (UTC)
Could do a merged entry for all 3 guilds. —⁠Legoless (talk) 07:17, 1 October 2020 (UTC)
We can probably ask ZOS to see if they are considering counting a guild that spans across multiple platforms as one entry so no UESP guild is left out, because it is probably too ambitious if we do one entry for each of the three. If we do enter under one guild, we should consider what guild crest we go with, because if we win that will represent our guild in-universe. I feel as if the guild crest that PC EU chose is the most fitting, as it has colors that are iconic to the wiki's design, plus Julianos is a more widely accepted deity than Hermaous Mora.Zebendal (talk) 08:17, 1 October 2020 (UTC)
Just a note, ZOS hasn't released any of the rules or regulations yet for this contest, so we won't know the answers to these questions until that happens. Likely it will cover what guilds should do that span multiple servers as there are many other guilds in the same boat. - Pylawn (talk) 20:19, 1 October 2020 (UTC)
ZOS has just released the rules here for the guild contest here. https://www.elderscrollsonline.com/en-us/news/post/58891 Some clarifications listed in here https://forums.elderscrollsonline.com/en/discussion/549253/official-discussion-thread-for-promote-your-guild-win-custom-collectibles are
  • Only the platform/server of the submitter will be eligible for prizes. We, unfortunately, cannot give the prizes to sister guilds on different servers or platforms.
  • No plain screenshots should be submitted. It should ultimately look like a poster, but if you use elements of a screenshot in your design that is okay.
  • Only the submitter needs to be in an eligible country. The guild members do not.
So by the looks of it, if UESP enters, only that specific server will get the reward. NA is the most active and biggest apparently, so it should probably do something to benefit the most amount of people, but that would probably have to be discussed with Baratron who is the guild leader.Zebendal (talk) 20:31, 15 October 2020 (UTC)
If anyone wants to submit a poster or video for PC-EU they can contact me. —⁠Legoless (talk) 23:54, 15 October 2020 (UTC)

Assimilation Lab Wiki Integration[edit]

The Assimilation Lab, which currently hosts a few TES fan wikis, has asked us to take over the hosting of their wiki content - Dave has agreed in principle, and the content has begun to be transferred into some temporary holding wikis on the UESP domain. The task for us as editors now is to have a look at the content on those holding wikis and see where it would fit best, and to get it into a ready state there so it can then be moved across to the main wiki.

There are currently three wikis ready to be looked at:

  • TESCOSI - This one will probably require checking over for duplicate information, and then integrating into Tes4Mod; it may be worth keeping a page called "Tes4Mod:TESCOSI" just so we can direct users of the old site to the new location of that content.
  • Morrowind Modding Wiki - This one will also mostly require checking over for duplicate information, and then integrating into Tes3Mod; again, a page called "Tes3Mod:Morrowind Modding Wiki" may help field users of the old site to the new pages.
  • Better Cities - This one is the biggest, and will require a bit of a structure review, but otherwise it should be relatively simple to get this all transferred to Tes4Mod:Better Cities/. The images are a separate consideration, but we will try to work something out whereby we then don't have to reupload all ~2,000 of them.

There are a couple more that need a bit of TLC first to rescue the viable content from a mess of 10,000+ spambot edits.

--Enodoc (talk) 19:14, 14 October 2020 (UTC)

These two have now been cleaned of spam (thanks Dave!), and are also ready to look at:
  • Order of the Dragon - This one is smaller than Better Cities but otherwise I think the approach will be the same. We'll need to decide whether or not it requires a subspace.
  • Oscuro's Oblivion Overhaul - Again, I think this one can easily be merged into Tes4Mod and we just need to decide whether it needs a subspace.
--Enodoc (talk) 18:57, 15 October 2020 (UTC)
how come we don't have a wiki just for all mods (like mods.uesp.net) the TesXMod: system is so messy and looks confusing with default search settings The Rim of the Sky (talk) 22:53, 15 October 2020 (UTC)
I think a completely separate wiki for mods would also be confusing, as then you'd not get any search results at all if you searched here, but there may be other ways we can improve how Modspaces work without taking all the content and putting it somewhere else. If the problem is specifically TesXMod as a system, maybe we should change that system? I mentioned further up how I always thought that the modspace names (while functional) aren't particularly "nice", and I'm always open to suggestions for how modspaces can be improved! --Enodoc (talk) 18:24, 16 October 2020 (UTC)
Fair enough I think a subwiki would be better (like https://tes-mods.fandom.com/wiki/The_Elder_Scrolls_Mods_Wiki) but there's definitely other room for improvement in different ways, will have to figure out what that could be The Rim of the Sky (talk) 22:37, 16 October 2020 (UTC)
What in particular do you think people find messy/confusing about TesXMod? There's a few things we could do, but I'm not sure if they would be better or worse:
  • Put everything under a single Mods: namespace rather than separate namespaces for each game, but then you lose what game it's for and any other associations that come from parent namespaces
  • Give big mods like Beyond Skyrim their own namespace, so instead of Tes5Mod:Beyond Skyrim: Cyrodiil/Bruma, you'd have something like Tes5Mod/Beyond Skyrim: Cyrodiil/Bruma
  • Change the name of TesXMod to something a bit nicer to look at, e.g. instead of Tes4Mod:Better Cities you could have Mods/Oblivion:Better Cities, but that's a longer title than what's there now
Any other suggestions of course are welcome! --Enodoc (talk) 00:08, 18 October 2020 (UTC)

() Aside from the images, which should be arriving on Monday, and some tidying up, this is now done.

Enodoc (talk) 01:01, 5 December 2020 (UTC)


Yesterday I had a discussion with a number of UESP users regarding the main page, its style, how easy it is to navigate, etc. The first part of this process is the logo, currently, it is the sword to the right

Current image

This design is quite outdated, screams the 90s and has very little to do with the UESP or the Elder Scrolls in general. I've brought this up with Dave and he has said he is down for changing this logo, the first step in this process is for the community to come up with ideas and mockups for what the new logo could be.

Zebendal had the idea of having the swords Dustfang and Dawnfang as a set of logos, one for dark mode and one for light mode as it would still have a sword but would be tes related and recognizable.

SR-item-Dawnfang & Duskfang.jpg

SageofIce had the idea of using an elder scroll as that is the title of the series and so is quite iconic, it also fits into the "scholarly" nature that the UESP has with its parchment background for example.

SR-concept-Elder Scroll.jpg

A couple of users on the Discord have brought up the point that it could perhaps be the Imperial Dragon and Diamond as the Empire has been a big part of every TES game, mainstream, and the side games.

If anyone has any discussions or wants to attempt their hand at creating something, please do contribute here. Imperialbattlespire (talk) 14:24, 31 October 2020 (UTC)

Dawnfang is not a good option, we should not be using a copyrighted game model for our logos. If there's a need to replace the current graphic, we should make something original. —⁠Legoless (talk) 14:25, 31 October 2020 (UTC)
I don't think we should be making a new logo at all - if we want to replace the sword on the main page with something else, we should just up-rez this one:
--Enodoc (talk) 14:57, 31 October 2020 (UTC)
I like the idea of an Elder Scroll for our banner logo, we already have an Oblivion-style Elder Scroll parchment as our main logo, so it would make sense in my opinion to have both be an Elder Scroll. That being said I do really like the Zeb's idea of having a Dawn/Duskfang-like sword logo which has a gem that changes colour depending on the site theme mode. As for who would make these new logos, my suggestions would be either MadameTortilla or LadyN, both have proven themselves when it comes to design. Thal-J (talk) 15:01, 31 October 2020 (UTC)
I like the idea of having Dawnfang/Duskfang as the logo. It can work for both default and dark mode, and it keeps the use of a sword that we have been using.Zebendal (talk) 15:55, 31 October 2020 (UTC)
The suggested replacements aren't great ideas for the reasons Legoless stated. --AKB Talk Cont Mail 17:03, 31 October 2020 (UTC)

() I'd love to replace that sword with something more modern. However, I agree that it should be something original and not a (possible) copyrighted item. Maybe we could ask Bethesda for use, but I don't think they will give a definite answer. I think the best option is to just remake the current logo with a more modern style and sword. --Ilaro (talk) 19:49, 31 October 2020 (UTC)

The other wiki just straight up uses the Skyrim logo, so I don't think that using a sword from the game would be too bad. We could ask.Zebendal (talk) 20:25, 31 October 2020 (UTC)
UESP 25th Anniversary Finished Coin.jpg
Duskfang is a bad idea for reasons stated. It's overthinking it. If the logo really bothers people, the logo used on the UESP coin is already well designed and is more consistent with the UESP's existing branding compared to some sword. --Jimeee (talk) 12:55, 1 November 2020 (UTC)
As a long-time gamer I like the retro look of the current image, and it's placement next to the "...since 1995" link is very fitting IMO. If we're going to change it, I think incorporating an original image of an Elder Scroll would be most appropriate. --Xyzzy Talk 16:37, 2 November 2020 (UTC)
An elder scroll of our own design seems fine.Zebendal (talk) 17:20, 2 November 2020 (UTC)

Splitting Out Major Mods To Separate Namespaces[edit]

Enodoc touched on this in the Assimilation Lab Wiki Integration, but we need to come to a decision on whether we want to give the larger mod spaces their own separate namespace. There are any number of advantages to this, such as shorter names, easier template handling, and so forth. However, there's also one major drawback: we'd need to do a mass move of all those pages! The bot could certainly handle most of that, and it wouldn't be anywhere near as problematic as merging Dragonborn namespace was, but it'd still be a large project, probably with at least some human intervention required.

This has become a bit more of an issue right now, since one "small" change suggested by Dcsg is making us realize that our templates are horribly inconsistent for some categories (e.g., Category:Shivering-Places but Category:Shivering Isles Places with Non-Standard Images) which really need to be brought into line with one another. This, in turn, cascaded to needing to decide what to do with mod spaces, before we go rearranging the affected categories.

So, should we give large mods like Tamriel Rebuilt, Stirk, Beyond Skyrim, etc., their own namespaces? Robin Hood(talk) 23:21, 3 November 2020 (UTC)

I'm going to say yes, but not using the format I suggested before; if part of the aim here is to make the namespaces shorter and more readable, Tes5Mod/Beyond Skyrim: is no better than Tes5Mod:Beyond Skyrim/. So I would suggest for every mod that gets its own namespace, it drops the "modspace prefix" completely. So Beyond Skyrim's namespace would just be Beyond Skyrim:.
I think at this point we may as well look into the names of the other modspaces as well for readability - so I would also suggest renaming TesXMod: to [Game] Mod: (or [Game] Mods:); Tes5Mod: would become Skyrim Mod(s), for example. (This is instead of the suggestion I made before, Mods/Skyrim:, primarily again for readability.)
This will also better help to vet which mods get their own namespaces; at the moment, the subpage format is generally used as the default even if they aren't actually set up properly as pseudospaces – Midas Magic being one example.
Enodoc (talk) 23:55, 3 November 2020 (UTC)
I can get behind some of what Enodoc suggested. If namespace mods are going to drop indication of from which game they come, then at least keep the trails the same so that it is very clear what they are. Also, a minor thing, but between Mod and Mods, I prefer Mod since "Mods" sounds like it should have more to do with the actual modifications themselves when the namespace should be about all things technical. -Dcsg (talk) 00:17, 4 November 2020 (UTC)
The main issue with dropping the game entirely is that it can be unclear to many users what game the page needs to be based on. If it just says "Tamriel Rebuilt" how does a new user know that edits should be made with Morrowind gamespace guidelines in mind, and not Skyrim's? This is especially important for mods that have been supported now for years, as to would be easy for someone to just assume that new edits are in the style of the newest game (or, more likely, they look at recently edited pages and use formatting of those namespaces). I think we should retain the game the mod is for in some way in the namespace title. I personally don't think making the names shorter is actually a concern we need to prioritize. Jeancey (talk) 00:49, 4 November 2020 (UTC)
There may be common gamespace practices, but I don't think there are any actual guidelines for specific gamespaces? The Style Guide is namespace-agnostic, and the Modspace Guidelines specifically link to the Style Guide generally (although we can also update those). Anyone who's editing a mod page would presumably know what game it's for, and as Dcsg said, we'd definitely want to keep the game name in the Trail anyway.
On that note though, if we don't go for shorter as the primary concern, we should still go for readability, so we'd need some alternative suggestions to just "Tamriel Rebuilt" with that in mind. Something I would be interested in finding out is whether a colon can be used within a namespace name, as that would open up some more options. --Enodoc (talk) 12:37, 4 November 2020 (UTC)
No, colons can't be used. The parser matches on the first colon and checks if it's an interwiki or namespace, and if nothing matches, it decides the whole name is a page in main space. Robin Hood(talk) 17:00, 4 November 2020 (UTC)
By guidelines I mean general practices, but also what templates to use. You shouldn't use Online templates for anything but online, shouldn't place and people setups are wildly different between morrowind and the newer namespaces. Jeancey (talk) 18:47, 4 November 2020 (UTC)

() Personally, I don't think the namespace being in the name is terribly necessary, because I think most of the time, people who are actually editing a game-related page know what game the page belongs to. That said, though, a lot of the mod spaces do have the name in them already, so maybe there's some benefit to including the name for consistency. (Note, however, that "Skyrim - Home of the Nords" would be confusing, given that it's a Morrowind mod.) For now, I've just lopped off the existing "Mod" namespace and adjusted the names with colons in them so that they're useable as namespaces. That leaves us with the following:

Current Name New Name
Tes1Mod Arena Mod
Tes2Mod Daggerfall Mod
Tes2Mod:Daggerfall Unity Daggerfall Unity
Tes3Mod Morrowind Mod
Tes3Mod:Morrowind Rebirth Morrowind Rebirth
Tes3Mod:Province: Cyrodiil Province - Cyrodiil
Tes3Mod:Skyrim: Home of the Nords Skyrim - Home of the Nords
Tes3Mod:Tamriel Data Tamriel Data
Tes3Mod:Tamriel Rebuilt Tamriel Rebuilt
Tes4Mod Oblivion Mod
Tes4Mod:Better Cities Better Cities
Tes4Mod:Stirk Stirk
Tes5Mod Skyrim Mod
Tes5Mod:Beyond Skyrim Beyond Skyrim
Tes5Mod:Beyond Skyrim: BSAssets Beyond Skyrim - BSAssets
Tes5Mod:Beyond Skyrim: Cyrodiil Beyond Skyrim - Cyrodiil
TesOtherMod Other Mod

How do people feel about those as namespace names? (Note: per Jeancey's point, I've included all namespaces that we might want to move in the above list...they don't necessarily actually all need to be moved. Smaller mods may be perfectly fine where they are.) Robin Hood(talk) 02:54, 11 November 2020 (UTC)

We have to be careful too, since Tamriel Rebuilt is significantly intertwined with Tamriel Data (as is Stirk I believe). Does Beyond Skyrim need 3 namespaces? why can't it just have one? And the only other question I would have would be is, are Daggerfall Unity and Morrowind Rebirth large enough to get their own namespaces? Morrowind Rebirth only has like 30 pages, 17 of which are books. Daggerfall Unity has even fewer, like 21 pages. And there isn't going to be much more content in the TES2Mod namespace besides Daggerfall Unity, so that can probably stay put. Jeancey (talk) 03:01, 11 November 2020 (UTC)
Brief comment saying I like everything Jeancey suggested. The different installments of Beyond Skyrim can use Mod Headers if necessary, like ESO DLC. Regardless, I feel like the dashed namespace would feel cumbersome in practice, so I think there should just be a space with no dash. Don't want to instigate the opening of yet another can of worms, but I think the ESO modspace should be named in the same way as the ESO space. Right now that looks like both "Online", but if that one of them ever changes, then both should change. -Dcsg (talk) 06:41, 11 November 2020 (UTC)
That all looks good to me, and I agree that Beyond Skyrim only needs one namespace. We can keep the BS: Cyrodiil pseudospace as well – just set it up with a colon instead of a slash, so that they're proper pages instead of subpages. Colons in the name after the namespace should be fine. I don't want to end up with an inconsistent setup, so if there are some we decide don't need a namespace, then I would argue they don't need a pseudospace either, and those pages should be moved up to the root level of the relevant modspace.
The way Tamriel Rebuilt, Province Cyrodiil, and SHotN link in with Tamriel Data could potentially be alleviated if Tamriel Data itself stays put in Morrowind Mod (with its pages promoted), as long as those new namespaces have Morrowind Mod as their parent. Something to consider as well is whether we could combine Province Cyrodiil and SHotN into one namespace (Project Tamriel) - that would also alleviate the naming issue for SHotN.
Morrowind Rebirth is supposedly a total overhaul, so regardless of the number of pages it has now, I think it has the potential to get quite large. Daggerfall Unity on the other hand is an engine, and so probably won't. I'm uncertain about "Other Mod", and personally would prefer "TES Mod" (or just "Mod") so that it could also function as a root namespace for mods and modding.
So here's my update to the suggestions:
Current Name New Name
Tes1Mod Arena Mod
Tes2Mod Daggerfall Mod
Tes2Mod:Daggerfall Unity Daggerfall Mod (promoted)
Tes3Mod Morrowind Mod
Tes3Mod:Morrowind Rebirth Morrowind Rebirth
Tes3Mod:Province: Cyrodiil Project Tamriel
Tes3Mod:Skyrim: Home of the Nords Project Tamriel
Tes3Mod:Tamriel Data Morrowind Mod (promoted)
Tes3Mod:Tamriel Rebuilt Tamriel Rebuilt
Tes4Mod Oblivion Mod
Tes4Mod:Better Cities Better Cities
Tes4Mod:Stirk Stirk
Tes5Mod Skyrim Mod
Tes5Mod:Beyond Skyrim Beyond Skyrim
Tes5Mod:Beyond Skyrim: BSAssets Beyond Skyrim (promoted)
Tes5Mod:Beyond Skyrim: Cyrodiil Beyond Skyrim: Cyrodiil (pseudo)
TesOtherMod Mod
Enodoc (talk) 18:42, 12 November 2020 (UTC)
I think we can PLAN for Morrowind Rebirth once it's bigger, but I think creating the namespace now is just asking for a tiny namespace that never gets updated. There doesn't seem to be much activity in the namespace (seems like major additions happened in July and September). I think we should hold off right now, until it's clear that there will be a major expansion of the namespace. I don't think there's a need to make any changes immediately if the namespaces are small or aren't being worked on (Stirk, as well, I would suggest could remain where it is, as it is essentially 100% complete, though I'm not 100% opposed to giving it its own). Jeancey (talk) 18:57, 12 November 2020 (UTC)
My point was that nothing should remain exactly where it is – if it doesn't get its own namespace, the pages should be promoted so we have no subpages acting as full pages. So where that doesn't work, that's an indication that a namespace is needed. Stirk and Morrowind Rebirth could probably go either way.
Regarding Online Mod vs ESO Mod, I agree with the premise of keeping it consistent, but equally I'd rather only move the mod pages once, so it could just as easily remain at ESO and wait for the other one to catch up. --Enodoc (talk) 19:31, 12 November 2020 (UTC)
So, under your plan, Enodoc, using Daggerfall Unity as an example, the main page would be at [[Daggerfall Mod:Daggerfall Unity]], but all child pages would bump up to the root level? That presents some possible issues. The first is potential naming conflicts in the future. If two small mods both wanted a "Creatures" page, they'd have to be disambiguated, which ends up being little better than subpages (although only a few pages would probably need disambiguated). The second, potentially larger issue is that the current pseudo-namespaces in Uespnamespacelist would no longer work for those, I suspect, since those are all expecting a parent/subpage setup. We could get rid of them entirely, but that would then require reworking any templates that are using the pseudo-namespaces for things like display names, category names, etc. I think, if we're going to move the mods around, we're better off either assigning all the mods that currently have Uespnamespacelist entries to their own namespaces or accepting that we're going to have some with dedicated namespaces and others that are still following the subpage style. Robin Hood(talk) 03:03, 15 November 2020 (UTC)
"So, under your plan, Enodoc, using Daggerfall Unity as an example, the main page would be at [[Daggerfall Mod:Daggerfall Unity]], but all child pages would bump up to the root level?"
Yep! Creatures pages etc should follow the same setup as DLC pages, like Dawnguard Creatures - DLCs don't get pseudospaces based on subpages, and there's no reason to treat mods any differently. Anything left over in Uespnamespacelist that doesn't get its own namespace should be removed - we'd have to rework templates and categories anyway if they were given their own namespaces, so the overall work should be about the same.
I would suggest though that we don't make any actual changes until after the Assimilation Lab Wiki Integration is finished, as those temporary wikis were set up based on the current namespaces, and the Export/Import would probably work best if they still exist? --Enodoc (talk) 13:38, 15 November 2020 (UTC)

Edit Break (Splitting Major Mods)[edit]

() The Assimilation Lab stuff is done, so this can continue I think. --Enodoc (talk) 17:29, 13 December 2020 (UTC)

I'm just starting to look into this and I really don't see things working out well when it comes to moving mods out of their current subpage style. Using Daggerfall Unity as an example, even just looking at page names, we'd end up having to manually go through the list and rename a lot of things in order to disambiguate (like "Installing" or "Mods", which would be inappropriate as DFU-specific titles at root level). And if we ever do want to give DFU its own full namespace, then we run into the issue in reverse of having all kinds of pages like "Installing Daggerfall Unity" that then have redundant titles for their namespace and have to be renamed back.
And that's leaving aside issues like templates. For example, {{Bullet Link|Settings|<settings description>}}, which works just fine for DFU currently, would need to be converted to a full link style ({{Bullet Link|[[Tes2Mod:Daggerfall Unity Settings|Settings]]|<settings description>}}) if we moved it to root space. Same thing goes for all kinds of other templates that produce trails, categories, etc., all of which would end up needing some kind of manual overriding to get them to work right afterwards when they're working just fine as they are now (e.g., in Skyrim spaces, {{Trail|Quests}} points to Skyrim:Quests, {{NPC Summary|Person}} categorizes NPCs into Category:Skyrim-People, and so on). If we put mods in the root space of <whatever game> Mod space, we'd constantly be overriding template behaviour to get to the desired place. So, if DFU actually had people, the NPC Summary would, by default, want to put those people in Tes2Mod-People, where it should probably actually be putting them into Daggerfall Unity-People. In a lot of cases, this would actually mean having to add that option to a bunch of templates that don't currently allow it. This would add a lot of work that otherwise wouldn't be needed with mods staying in a subpage format and just adding them to Uespnamespacelist as needed. And if a mod later does develop its own namespace, a lot of the work is just a simple matter of changing the entry in Uespnamespacelist to match.
It's a different scenario for DLC because there, the trails/categories/templates should generally still point to the appropriate space most of the time (e.g., {{Trail|Quests}} should still point to Skyrim:Quests, {{NPC Summary|Person}} should still categorize the character into Skyrim-People, etc.). So unless there's some compelling argument to put everything at the root level that would trump all the effort involved, I don't think that's going to work out very well at all. Robin Hood(talk) 01:43, 17 December 2020 (UTC)
Okay, so to recap, taking all the above into account, this is what I'm seeing for namespace changes:
Current Name New Name
Tes1Mod Arena Mod
Tes2Mod Daggerfall Mod
Tes2Mod:Daggerfall Unity Daggerfall Mod:Unity/
Tes3Mod Morrowind Mod
Tes3Mod:Morrowind Rebirth Morrowind Rebirth
Tes3Mod:Province: Cyrodiil Project Tamriel:Cyrodiil/
Tes3Mod:Skyrim: Home of the Nords Project Tamriel:Skyrim/
Tes3Mod:Tamriel Data Tamriel Data
Tes3Mod:Tamriel Rebuilt Tamriel Rebuilt
Tes4Mod Oblivion Mod
Tes4Mod:Better Cities Better Cities
Tes4Mod:Stirk Stirk
Tes5Mod Skyrim Mod
Tes5Mod:Beyond Skyrim Beyond Skyrim
Tes5Mod:Beyond Skyrim: BSAssets Beyond Skyrim
Tes5Mod:Beyond Skyrim: Cyrodiil Beyond Skyrim:Cyrodiil/
TesOtherMod Mod
Tamriel Data might be justified in having its own namespace given the number of pages it has (just over 3000), but it's no problem to leave it as a pseudo-namespace. Does anyone have any thoughts on that?
BSAssets is still being promoted, since there are literally only 3 pages at root level apart from that and Cyrodiil, so keeping BS and BSAssets as separate namespaces or pseudo-namespaces makes no sense at this point. If that becomes a concern later on, we can split them out then.
My plan is that when moving pages from a pseudo-space to a full namespace, those will be done without leaving redirects. Does that present any concerns for anyone? It's no problem for me to tell the bot to leave redirects during the move, but I don't see a point in cluttering mod spaces with redirects for every last pseudo-space page that previously existed unless there's a good reason to do so. Maybe just for the main pseudo-space pages? There are few enough of those that I would suggest we just add them by hand afterwards if they're wanted, cuz otherwise it's a separate bot job just for those half-dozen or so pages.
Along with this, Dcsg had requested that the NS_NAME values for two namespaces be changed: "Online" to "ESO" and "Pinball" to "Skyrim Pinball". In theory, NS_NAME is meant to be a descriptive name for display purposes only (i.e., in message boxes, page descriptions and the like), so it should've been a fairly trivial change that probably nobody would've been concerned about, but the reality is that a number of our templates are using it for categories. So, as part of this project, those templates will be brought into line with everything else, with their categories being moved to Category:NS_CATEGORY-whatever (e.g., Category:Incomplete Skyrim Pages will move to Category:Skyrim-Incomplete Pages). And of course, I'll leave redirects for those moves, since many of them are long-standing categories that may be linked to externally.
If anyone has any concerns/corrections/suggestions about any of this, now's the time to speak, cuz I'll be testing the waters on Dev over the next few days, then if that goes well, I'll start getting to work on the live servers. Robin Hood(talk) 19:30, 17 December 2020 (UTC)
TesOtherMod turning into just "Mod" has been a little overlooked here, I think. Are there plans to use it as a root namespace? If not, I think a user searching Mod:Main Page and only seeing things that are specifically miscellaneous would be very confusing. My opinion is that it should stay "other" adjacent, but if there is real intent to make it a root in addition to the home for miscellany then there is an argument for renaming it "Mod". --Dcsg (talk) 20:28, 17 December 2020 (UTC)
I don't have any particular opinion on what it should be used for, but if we make it a generalized space, we could use it to house articles on common concepts between games (or at least some of them) like Form IDs, Editor IDs, the various data types found in mod/save/archive files, and that sort of thing. Right now, these are all split off by namespace, which is equally valid since there are variations between spaces that don't necessarily apply elsewhere, but they could be made generic to avoid having to synchronize information between them if we wanted to. If we did, then a generalized Mod space would make more sense to do that in. Robin Hood(talk) 23:00, 17 December 2020 (UTC)
I will acquiesce to Daggerfall Unity staying as a subpage set, but I would like to insist on taking Beyond Skyrim: Cyrodiil out of subpages. Beyond Skyrim: Cyrodiil/<NAME> is a significantly less-favourable option than either Beyond Skyrim: Cyrodiil: <NAME> (per the suggestion) or just Beyond Skyrim: <NAME>. (I will have a closer look at Tamriel Data and see what makes most sense there...).
The specific note about templates - Bullet Link, Trail, Category definitions, etc. - is conditional on the relevant thing being defined in uespnamespacelist, not on it being defined through a subpage (as far as I can tell). And from that, I take it that we could define uespnamespacelist entries as required, based on theoretically any prefix, not just ones that involve a slash (hence Beyond Skyrim: Cyrodiil: being the suggestion there).
Generally agreed on the categories, but that's inconsistent already - DLC quests are already directly overridden by direct calls to {{Trail}} putting them in the Root-DLC-Quests category instead of the Root-Quests category (Lost to the Ages being a direct example), and DLC NPCs are in Root-NPCs by the Trail as well as manually added to Root-DLC-NPCs. I think the ideal solution for mods that don't have their own namespaces would be for pages to be categorised in <Modspace>-<Topic>, <Modspace>-<Mod> and <Modspace>-<Mod>-<Topic> (so for example, Tes5Mod-Quests, Tes5Mod-SWIFT, and Tes5Mod-SWIFT-Quests).
And yes, turning TesOtherMod into Mod so it can be used as a non-specific root namespace was indeed the idea. Mods would become the Mod:Main Page. Enodoc (talk) 15:53, 18 December 2020 (UTC)
UespCustomCode is based on a page either being in a namespace of its own or on it being a subpage. All of the code is designed around that idea for the simple reason that MediaWiki itself is designed around that idea. We can't just use any arbitrary prefix and call it a pseudo-namespace. Moving Cyrodiil into Beyond Skyrim space itself is certainly an option, but Uespnamespacelist entries must be unique namespaces/pages, so you have to drop the concept of Cyrodiil altogether and flatten everything into Beyond Skyrim namespace (as already suggested for BSAssets). That leads to the issue of page name conflicts and what to do with those. The two options would be to merge them into a single page and let users deal with properly integrating the information (a la Dragonborn) or renaming them (which includes either straight renaming or adding disambiguators).
As far as categories go, I think once we get everything using NS_CATEGORY instead of NS_NAME, and do the page moves, a lot of the manual categories will simply fall into line as part of that process. We'll have to see what happens there, but I'm not anticipating huge issues on that front...certainly nothing that couldn't be dealt with by a follow-up job or two, if needed. Robin Hood(talk) 18:12, 18 December 2020 (UTC)

() Also keep in mind that Tamriel Data is pretty integrated with the Tamriel Rebuilt pages. We might need to make sure that stuff like the book template on Tamriel Rebuilt pages still links correctly to Tamriel Data. Jeancey (talk) 18:37, 18 December 2020 (UTC)

Just in case anyone's using it, I'm starting the changes on dev and expect there will be a number of breakages to mod-related stuff as a result, since I'm taking everything step-by-step there rather than having a ready-to-go process that all gets done at once. Seeing as it's dev, I don't expect this will bother anyone, but I know sometimes people use it to test something, so I thought I'd mention it. Robin Hood(talk) 19:17, 18 December 2020 (UTC)
Ah damn I didn't realise CustomCode was built specifically on Namespaces and Subpages. Readability would argue then that we should flatten the whole thing, with critical index pages like T5:Beyond Skyrim: Cyrodiil/Quests going to Beyond Skyrim: Cyrodiil Quests, and specific article pages like T5:Beyond Skyrim: Cyrodiil/Count Desilus Carvain going to Beyond Skyrim: Count Desilus Carvain.
For Tamriel Data, we could probably do the same thing, and disambiguate if that ever becomes necessary. In order to be read properly by Tamriel Rebuilt and Project Tamriel in templates and links, surely flattening is the only solution, unless it gets its own namespace that is added as the parent of the other two. I am hesitant to suggest Tamriel Data getting its own namespace primarily because it adds no content of its own; you can't play "Tamriel Data" as a standalone mod, it's an asset repository for use by other mods. --Enodoc (talk) 19:36, 18 December 2020 (UTC)
Okay, so after some confusing back and forth on Tamriel Rebuilt/Project Tamriel, I think we've got that figured out now. That leaves BS as sort of an odd man out now, though. Despite my reservations about flattening BS space into a monolithic whole, that's basically what we're doing for TR3/PT3 at this point, so maybe it makes sense to do it for all of them. My main reservation about this is that we're essentially foregoing most of the functionality that UespCustomCode was designed to provide us, so a lot of the template automation around categories and file names will fail or need to be overridden. As long as those working on the project understand that flattening everything into one space will likely entail a lot of manual work after the bot job is done, it makes no difference to me personally. I'm just concerned that if people don't like the end result, we might end up doing a second move to essentially undo the first one, which would get messy. Can I get a final decision on that, please? Robin Hood(talk) 00:56, 20 December 2020 (UTC)
Further discussion led to an understanding of the drawbacks of getting rid of pseudospaces, so we ended up wrapping back around to using them, but significantly shortened (examples). While we didn't discuss it, I took the liberty of shortening Daggerfall Unity as well. Sorry for all the back-and-forth here, but I really think this is the best plan. Getting rid of pseudospaces altogether just presents too many issues that we can't easily deal with, and the shorter names make things work well. Robin Hood(talk) 03:51, 20 December 2020 (UTC)
If the feeling is that pseudospaces would still need to exist within the separate namespaces, I see no real benefit to having separate namespaces at all, as the pseudospaces would continue to work perfectly fine where they already are. Consistency is most important, and wherever pseudospaces exist, there is inconsistency between the mods in those pseudospaces, and the ones that do not have pseudospaces. The intention behind this suggestion originally was to move anything with its own pseudospace into a separate namespace so that inconsistency was averted. (And also to make the page names shorter and tidier, primarily without slashes and colons.)
Regarding the categories and trails argument for keeping pseudospaces, that doesn't hold when you consider the mods that don't qualify for pseudospaces (which is the majority of them, like SWIFT and The Forgotten City) - those categories and trails have to be added manually at the moment anyway. The only way to resolve that (which is something we need to do) is to update how the trails and categories are defined within the summary boxes and headers so that the mod= is included within those definitions. --Enodoc (talk) 16:33, 20 December 2020 (UTC)
There's something else besides consistency that's important which is ease of use, which you touch on in your post. Both namespaces and pseudospaces interact with UespCustomCode to give us that ease of use by providing a hierarchy to structure the information while each subspace in the hierarchy retains most of the benefits of being a namespace. Our entire set of templates has been built up over the last ten years or so to use UespCustomCode and MetaTemplate extensively. If we want to completely get rid of pseudospaces, then we lose that hierarchichal structure, and we need to either redesign every last template not to rely on the pseudospace features or we give everything its own full namespace so that it can. I don't see either as desirable.
SWIFT and The Forgotten City are indeed both in the same namespace right now...and they're also largely redlinks. The ease-of-use issues haven't had much of a chance to show up yet. But even looking at the pages that do exist, we're overriding a lot of the built-in functionality. Why do people have to spend time doing so? And how are they even supposed to know it's necessary in the first place? If we added SWIFT and TFC to the pseudospaces list, none of that would be necessary...the magic we've built into the templates already would just plain work.
Flattening multiple mods into the same space also creates confusion and need for disambiguation when there probably shouldn't be any. If I come across a random NPC in Mod space, I don't know just by looking at the title what mod that belongs to, and if someone's forgotten to tag which mod it belongs to, it becomes even more of a challenge to figure out.
While there's a lot to be said for adding mod functionality to templates which really don't do much with it right now (like NPC Summary, which only displays the mod name and that's it), I don't see that as an appropriate solution in this case. SWIFT and TFC are not both mods of Skyrim Mod, they're mods of Skyrim itself, but that's a foregone conclusion in Skyrim Mod space, so why should every last thing be forced to use a mod-like structure there? What's more, if we someday decide that they really should have their own full namespace, then moving it there is simplicity itself: take everything in the pseudospace, move it all to the new namespace, update all the links, and you're done. If it's a bunch of pages scattered around a given Mod space with other mods alongside it, it becomes nightmarish to figure out which pages belong to that particular mod and which don't, you have to worry about disambigs for other mods, extracting information that's been put onto common pages, etc. Your mod space has essentially become a bin of pages with tags on them rather than a proper filing cabinet that has an inherent structure. It doesn't matter how well you organize those tags, that bin is still going to be chaotic to work with. And if you want to move those pages to a separate namespace of their own (which SWIFT and TFC would probably qualify for if fully expanded), you have to change a lot more things when they become namespaces of their own...namely all those kludgey overrides that were put in place to make things work when it wasn't in a pseudospace.
Pseudospaces under a full-fledged namespace give projects structure. Project Tamriel stuff is all kept in the same place, for instance, while each sub-space gets all the benefits of being in a namespace of its own. Yes, the names are a bit more of a nuisance to work with, but templates like TR3 and the magic already built into most of our main Summary templates, combined with well thought out names, make that largely trivial to work with. Honestly, I think the length of the existing names has been our biggest hurdle in the past, not the fact that they're in pseudospaces. Robin Hood(talk) 20:21, 20 December 2020 (UTC)
Hi all, I must admit most of the more technical aspects of this debate are lost on me but I thought I'd add my tuppence given I'm quite active in the Beyond Skyrim namespace. First thought is that each BS project is quite distinct from the other: different teams are working on say Cyrodiil, Iliac Bay and Atmora. So while I have sympathy for Enodoc's "what's the point?" argument, I think it makes sense for there to be sub/pseudo spaces within Beyond Skyrim. The glue that binds them all together is BSAssets, so I support that being promoted to just "Beyond Skyrim".
Second thought is just a plea from someone doing content editing to make sure we're giving due weight to ease/functionality as well as to consistency/categories/templates. By that I mean that the solution we settle on ideally minimises the amount of manual adjustments or overrides to templates etc that someone would need to do when adding content. I don't have enough template or dev knowledge to weigh up the proposals against both criteria, so just wanted to flag that to those of you who will be able to judge across both areas.
Before I leave you to it, an option I wanted to throw out there is instead of colons we could have: "Beyond Skyrim (Cyrodiil):"? Don't know if having brackets would cause any template issues though. --SerCenKing (talk) 12:33, 21 December 2020 (UTC)

() Enodoc's primary concern has been consistency, so after talking it out on Discord, we've actually decided that the best option all around is to put pseudospaces to even greater use and be consistent that way. So, once we're done with this project, we'll create pseudospaces for SWIFT, TFC, and anything else that needs it. Those will be easier (I think), since we're leaving things in place and only adjusting any templates and removing overrides that are no longer necessary.

As to the idea of using "Beyond Skyrim (Cyrodiil)" as the full root namespace, I think that's doable, though I'm not 100% sure about parentheses in namespace names. That would effectively make "Beyond Skyrim" and "Beyond Skyrim (Cyrodiil)" two different namespaces (much like the proposed Tamriel Rebuilt vs. Tamriel Data). That's really not a whole lot different from a parent/pseudospace, but it's conceptually different. There's also some slight technical differences, but I don't think they're anything to worry about.

Everyone: Now that we've agreed on the base/pseudospace structure, do the above choices of namespace still make sense? I'm quite content with them as they are in the table, but particularly for the Morrowind-related spaces, it could make sense to leave things the same way they are now and just change the namespace name to Morrowind Mod. It makes very little difference to me, the bot, or the wiki at large; it's just a question of what works best for those working in those spaces. Robin Hood(talk) 19:43, 21 December 2020 (UTC)

Trying to figure this out has been very messy with as many facets as there are. I've created UESPWiki:Modspace Project/Namespace Overhaul as a place to organize the confirmed outcomes and courses of action. On its talk page, I have separated different points of discussion as separate sections. Please create any new sections that still need discussing, making them as specific as possible. Also feel free to update the main page with whatever may not be covered yet. -Dcsg (talk) 20:27, 21 December 2020 (UTC)
Thanks both. For ease and clarity, could you please post (either here or on the project page Dcsg helpfully set up) the final version of the table above? Just so we're all clear where we've landed.
On a slightly unrelated note, the {{BSA|}} and {{BS5C|}} templates seem to have broken (although rather haphazardly from what I can tell). Assume this will be rectified once all the relevant moves/changes are done? --SerCenKing (talk) 17:05, 23 December 2020 (UTC)
For the BSA and BS5C templates, I made some changes to the underlying PHP code on the server, and I suspect I must've introduced a bug somewhere that's causing the breakage, because the template itself looks fine. I'll take a closer look at it after breakfast. Hopefully, later today, it should just magically start working again. (Edit: fixed now. A simple case of a misplaced parenthesis causing NS_ID checks to fail.) Robin Hood(talk) 19:09, 23 December 2020 (UTC)

Edit Break 2 (Splitting Major Mods)[edit]

I'm just getting started on this now. Because of the differences between the development servers and our real servers, my plan is to do one last test run of the bot before doing the real moves, so there won't be any major activity right away, but assuming that all goes well, the real moves will probably start within the next hour or maybe even sooner. There will likely be a lot of breakage until the bot is done; I'll update this topic at that time. Robin Hood(talk) 21:33, 7 January 2021 (UTC)

I noticed that "ESOMod" was first renamed to "ESO Mod" (per the above discussion and the project page) and then renamed a second time to "Online Mod". From what I can see this was done on the basis of a Discord discussion, but maybe I'm missing something. To my mind this is a move in the total opposite direction and is a change for the worse in terms of accuracy; this new name is far less descriptive than the initial "ESOMod" or the proposed (and agreed?) "ESO Mod". I would strongly suggest a revert of this second rename. —⁠Legoless (talk) 05:01, 8 January 2021 (UTC)
Discussion topic related to this project have been here. -Dcsg (talk) 06:44, 8 January 2021 (UTC)
I don't see anything on that page regarding this change to "Online Mod". This new name is non-descriptive; the game is not called Online and the namespace is not about "online mods". I am opposed in principle to this last-minute change being effected without any on-wiki discussion or indeed any real consensus. —⁠Legoless (talk) 14:47, 8 January 2021 (UTC)
Just using this thread to flag some of teething issues I come across:
  • The {{Book Normal|}} template appears to be struggling on Beyond Skyrim: Cyrodiil/Notes and Beyond Skyrim: Cyrodiil/Books. It seems to only be picking up a random smattering of values. Tried purging but no luck. Assume this is just something about the changes making their way through the system?
  • The BSAssets pages use the {{BSA|}} template a lot and it's currently broken (e.g. red links here). We just need to change it so it points to Beyond Skyrim: rather than to Beyond Skyrim: BSAssets/.
  • While we're at it, would it make sense to change {{BSA|}} into {{BS|}} given we've collapsed BSAssets into just Beyond Skyrim?
  • Similarly, do we want to change {{BS5C|}} to just {{BSC|}}? I assume the "5" is a nod to TR3 and TR4 but there aren't any Beyond Skyrim mods for previous games, so feels redundant and is a bit longer to type. Appreciate this might be more faffy and involve a fair bit of bot work though (as we'd need to change image names too), so not necessary.
--SerCenKing (talk) 18:10, 8 January 2021 (UTC)
The game isn't called "Online" either. It's there for consistency and for ease of templating. If it's becoming ESO, then the gamesace should be ESO. Gamespace and Modspace come as a package and should have any changes reflected upon both namespaces. -Dcsg (talk) 18:35, 8 January 2021 (UTC)
@SerCenKing If you want to jump into our discord, I can help you through some of these. Most of the issues come down to the Job Queue. So many changes were made, that the wiki has a backlog of updates it is working through. Templates rely on those changes, and thus are slower to update when they are saving/loading values. As the job queue goes does, the changes will happen quicker. Jeancey (talk) 18:55, 8 January 2021 (UTC)
Yeah the ESO Mod vs Online Mod is a consistency thing which I agree with in principle but not in practice. ESO Mod was suggested with the consideration that, when the issues of the things that broke in the previous attempt were addressed and resolved, that change would be reimplemented and finalised. The overall concerns were primarily about what the change broke, not that it was a bad change overall, so I had always assumed it was a given to be reapplied when the broken stuff was accounted for. If we need that ESO vs Online discussion again though, that's a separate thing but I will still support it --Enodoc (talk) 19:25, 8 January 2021 (UTC)
This isn't an issue of consistency because the two issues are not tied. This is a change which has been made to the name of an existing namespace, without consensus. —⁠Legoless (talk) 20:46, 8 January 2021 (UTC)

() I haven't looked into Book Normal yet (see next para), but BSA to BS is out because BS is already Battlespire. BS5 is the current initialism and I think just moving the template to that name would fix all the issues. BS5C to BSC is also doable if we want, and would just mean updating Uespnamespacelist along with renaming the template. My apologies for changing ESO Mod to Online Mod, but I thought it was something we'd wanted and forgotten to document. I think consistency between the main and mod space is preferable, but I don't work in those namespaces, so I'll leave you guys to figure out.

Edit: The Book Normal thing is just a question of waiting for the job queue to catch up and possibly null-editing or mass-purging any pages that don't get refreshed properly. Robin Hood(talk) 20:57, 8 January 2021 (UTC)

Ah bloody Battlespire! Ok, in that case agree BS5 is most sensible, let's go with that. As you say, hopefully that will also fix the BSA template currently returning BSA:XYZ rather than Beyond Skyrim:XYZ.
By the same logic as above let's keep BS5C too for Cyrodiil. Also thanks both for the Job Queue explanation - I was clearly too impatient! --SerCenKing (talk) 21:23, 8 January 2021 (UTC)
Moving BSA to BS5 does indeed appear to have fixed the issues, although you may need to purge the page to see blue links instead of red. Robin Hood(talk) 22:52, 8 January 2021 (UTC)

AI Upscaling[edit]

A considerable number of older images on the sites cannot be improved in any meaningful way because of the low quality of the source files. However, AI upscaling is a growing option to enhance old images, as well as render games in real time. In fact, a lot of future images that are used on the site could very well use Deep Learning Super Sampling to increase the quality of lower resolutions (see here). With that said, it might be worth deliberately taking advantage of this to start improving some of our older images now. One notable example of this is these two images:


MW-birthsign-Apprentice (AI Upscaled).jpg

One is the highest quality version of that image taken directly from the game files of Morrowind, and the other is that image upscaled by an AI. While there's a few errors, I would say that they are overall minor, and the software I used for this was fairly flexible and allowed me to correct it fairly heavily. Additionally, AI upscaling is definitely going to be getting better with time, so future results will hopefully be even better. That's not to say we should replace existing base-quality images with these, but I do believe we should take advantage of this to provide our users with improved versions where you can actually make out the details more easily. --AKB Talk Cont Mail 14:58, 1 December 2020 (UTC)

I don't see why not. Can we AI upscale UESP's scroll background texture? looks a bit low res now on higher end pcs.Zebendal (talk) 16:32, 1 December 2020 (UTC)
Fully support this, will be great for lore pages in this instance. Makes sense to take advantage of new technologies to provide a better experience for users. Imperialbattlespire (talk) 16:36, 1 December 2020 (UTC)
I think it's a great idea when handled properly. The most obvious being to never overwrite the original image. But I also think that any image that is an edit of another (not just with ai upscaling) should link to its base image in the summary. For those unfamiliar, you can link to an image without displaying the image by putting a : before the file's name. (i.e. [[:File:MW-birthsign-Apprentice.jpg]]) There is then the use of such images, which I think should be sparing. An image should only be upscaled when no good alternative exists, the image would noticably benefit from it, and that the final result is better than the original, maintaining the same feel/intention of the original. I also argue that, beyond just creating the images sparingly, they should be used sparingly, not allowing the upscale to overshadow the original in terms of significance. What this looks like in my mind is that the rule of thumb would be that originals are used in their gamespace, and upscales are used in the lorespace. However, each scenario would have to be considered case-by-case. -Dcsg (talk) 18:18, 1 December 2020 (UTC)
I would be a little wary of embracing this sort of enhancement wholesale, but Dcsg's suggestions sound good to me—particularly with regards to maintaining the originals. —⁠Legoless (talk) 19:23, 1 December 2020 (UTC)
I'm also a bit hesitant, but I'm not entirely against it. My main concern is that UESP has always prioritized the original in-game experience, to the point where even pics with minor mod items in them have been re-taken sometimes. Dcsg really hit the nail on the head, I think...there may well be times when upscaling an image would be beneficial for the site, and I'm certainly not going to object in those cases, but original content should always be preferred, especially in gamespace. Robin Hood(talk) 19:47, 6 December 2020 (UTC)

Proposal to Update Site Background[edit]

The site background has been looking a bit pixelated on higher definition screens to me. I've tried to create a solution to address this. You can see how it would look in comparison on the dev wiki. This is intended to keep the basic feel of the current background, while also not being overly pixelated on higher resolutions. The version there was just to test it, a virtually identical but more lightweight version that has already been created would be used if we did adopt it on the wiki. --AKB Talk Cont Mail 18:15, 6 December 2020 (UTC)

I'm all for the upscaled version, although if we can find a free "naturally" hi-res parchment texture, that might be something to look into as well, since it's even less likely to show pixelation or other artifacting. Just in a quick Google, it would seem that the main issue with that suggestion is finding something that tiles well. So, if someone finds something, great, but the upscale of the existing one may be our best and easiest option. Robin Hood(talk) 19:52, 6 December 2020 (UTC)
I think the one on dev looks bad; it lacks texture and looks mostly solid unless you scroll down to the bottom. Also, any image can be turned tileable pretty easily. I know on gimp, it can be done with Filter -> Map -> Tile Seamless.... -Dcsg (talk) 20:36, 6 December 2020 (UTC)
Hello, I am a fan of changing the parchment of the background to a higher resolution one, but the one on the dev wiki is not an improvement and lacks any texture. If needed, hire someone to create a new parchment texture that can replace the old one, as the new one should be faithful to the old one.Zebendal (talk) 20:47, 6 December 2020 (UTC)
We can definitely consider any option that won't radically change the look of the site as it is now, looks alright tiled, and is free to use. If anyone has any options, feel free to provide them. --AKB Talk Cont Mail 20:49, 6 December 2020 (UTC)
A paid solution is probably not a good idea, unless the community is okay accepting the result beforehand. --AKB Talk Cont Mail 20:57, 6 December 2020 (UTC)
Can you do thee thing DCSG suggested and show us how it looks?Zebendal (talk) 20:59, 6 December 2020 (UTC)

() Update: A new candidate has been put on display on Dev wiki. Please check it out, a hard refresh may be required. Honestly it looks so good in my opinion that we should definitely go with it. --AKB Talk Cont Mail 01:06, 7 December 2020 (UTC)

If needed, we can try looking for a free background on the Creative Commons website. We can edit the color schemes ourselves to look closer to the website color. So just a few ideas.Zebendal (talk) 02:50, 7 December 2020 (UTC)
Heres a background suggestion that isn't too high quality, this one. I edited it to be tile seamless via gimp and made the color scheme closer to the website.Zebendal (talk) 03:31, 7 December 2020 (UTC)
Edit: Heres another one I did after eliminating some of the dark spots, it might look good on the website. — Unsigned comment by Zebendal (talkcontribs) at 04:06 on 7 December 2020 (UTC)
I really like the one Zebendal made, it tiles really nicely. -Dcsg (talk) 04:09, 7 December 2020 (UTC)
That one can't be an option, we would have to credit the original creator on every single page. I prefer to stick to the traditional UESP background, updated to be less pixelated, instead of changing it to something else entirely and having to credit someone on every page of the site for it. --AKB Talk Cont Mail 14:17, 7 December 2020 (UTC)
This is the same issue as the suggestion that we use Dawnfang in place on the dagger on the main page. Let's be clear here: if we're making branding or design changes to the website, the copyright needs to lie with UESP. —⁠Legoless (talk) 14:26, 7 December 2020 (UTC)
What's currently on dev looks like a blurry upscaling of the current background, so I don't see the benefit. If there's a problem with the current texture then we need a new texture, not to make the current texture bigger and thereby less detailed as a result. --Enodoc (talk) 19:35, 7 December 2020 (UTC)

() I also see the new version as a step down from the current version. I understand the desire to improve the background, but the current suggestion just isn't an improvement. I think we should delve deeper into this, rather than choosing a worse option just to make a change. It has also been noted that the issue with the current background is more prevalent on 4k monitors, but if it makes it better for 4k and actively worse for non-4k, that I would suggest that's not a good tradeoff, given the number of people who would be using each resolution. Jeancey (talk) 19:55, 7 December 2020 (UTC)

It's probably best to get someone to create a new background then, maybe hire an artist to create a background faithful to the original for us?Zebendal (talk) 01:50, 8 December 2020 (UTC)
I am curious if any thought has been given to hire an artist to create a new HD background true to the original?Zebendal (talk) 22:25, 7 January 2021 (UTC)

Gamespace Main Pages[edit]

I'd like to gauge opinions on a topic that came out of the Namespace Overhaul and related discussions -that being the inconsistency between main pages of Gamespaces and other namespaces - i.e., Skyrim:Skyrim and Oblivion:Oblivion vs. Lore:Main Page and General:Main Page.

If we moved the gamespace main pages to :Main Page as well, that would allow for pages like Skyrim:Skyrim and Oblivion:Oblivion to be about the in-game entities (like Oblivion:Cyrodiil and Morrowind:Vvardenfell), rather than an index page.

Thoughts? --Enodoc (talk) 22:42, 31 December 2020 (UTC)

While it's a bit odd from a technical viewpoint since they aren't in their own namespaces, I would prefer having these main pages/portals in Mainspace. For example, Skyrim:Skyrim becomes simply Skyrim.
General:Main Page -> General
Redguard:Redguard -> Redguard
Tamriel Rebuilt:Tamriel Rebuilt -> Tamriel Rebuilt
Project Tamriel:Skyrim/Skyrim: Home of the Nords -> Skyrim: Home of the Nords
This is a lot nicer looking to the end user and makes the very common link to the game portal much cleaner [[Skyrim:Skyrim|Skyrim]] becomes [[Skyrim]]. —Dillonn241 (talk) 23:03, 31 December 2020 (UTC)
As I mentioned in Discord, a lot of the current main page content would break if moved to Main space as is. Most of the templates would need to have |ns_base=<namespace> added to them, which is a lot of clutter. (Edit: Enodoc pointed out on Discord that this would likely be less "cluttery" than I was thinking, since ns_base can be inherited in most of our templates.) While I think it's a good idea to have Main space pages like Skyrim be redirects (or disambiguations) to Skyrim:Skyrim or Skyrim:Main Page (which we're already doing for most things), I think it would add a lot of extra work to maintaining the main pages if we moved them to Main space, and the only real benefit to doing so would be to have a page that has Skyrim as its title instead of Skyrim:Skyrim or Skyrim:Main Page.
That said, I do agree with the initial proposal that Skyrim:Main Page sounds a lot more natural than Skyrim:Skyrim for a landing page, and would allow Skyrim:Skyrim to let us document the province somewhere other than Lore space. It would require a lot of edits by the bot to update existing links, but probably not as much as it appears, as a lot of the references will be from trails or the various {{NS}}-related templates, which can all be changed with a very simple edit to Uespnamespacelist (and probably a dummy edit or recursive purge to those templates). Robin Hood(talk) 23:45, 31 December 2020 (UTC)
Since there hasn't been any further discussion on this, and I've been waiting on a decision before going ahead with the mod space renaming, around mid-afternoon (Eastern) tomorrow, I'll go ahead with the renaming, moving all the mod-space main pages to "Main Page" in whatever namespace/pseudospace is appropriate. In no way is this intended to be a final decision on this issue, but I don't want to hold up the entire project for the sake of a few pages. If we decide we want all main pages to be something else later on, it's relatively trivial to move them again. Robin Hood(talk) 02:55, 7 January 2021 (UTC)
I think we should keep the existing gamespace main page names as-is. They seem fine to me and make logical sense. No need for consistency in every instance, especially when we would end up with page names like "OBMobile:Main Page" that wouldn't be particularly clear about their subject matter. —⁠Legoless (talk) 22:14, 7 January 2021 (UTC)
I would prefer for expansion spaces to be merged with their gamespace, ex: tribunal and bloodmoon into morrowind space. — Unsigned comment by Zebendal (talkcontribs) at 22:24 on 7 January 2021 (UTC)
OBMobile is a strange one anyway considering "Oblivion Mobile" is not the name of that game. It's called TES Travels: Oblivion. But either way, maybe we should be changing that namespace to "Oblivion Mobile" in full (or something more accurate), then Oblivion Mobile:Main Page makes as much sense as the rest of the suggestions. We could even consider merging Travels into one Travels namespace, but merging namespaces is not the topic of this discussion. --Enodoc (talk) 23:40, 7 January 2021 (UTC)
According to the developers it's actually called "The Elder Scrolls IV: Oblivion for mobile" but we tend to gloss over these technicalities for the sake of readability. There's nothing stopping us from making a "Skyrim:Skyrim (place)" page if desired. Also I think merging different games into a single Travels namespace would be highly destructive, for the record. —⁠Legoless (talk) 00:12, 8 January 2021 (UTC)
Edit: In fact, turns out Skyrim:Skyrim (place) already exists as a redirect since 2013. This would appear to me to alleviate the concern that was the subject of the initial proposal. —⁠Legoless (talk) 00:17, 8 January 2021 (UTC)

IG and OOG Sources[edit]

I'd like to propose that we handle IG and OOG content in a similar way to how the Star Wars wiki (https://starwars.fandom.com/wiki/Main_Page) does it with "Canon" and "Legends".

Have a normal copy of a lore page with just in-game references, then also have a link that links to a copy that also includes UOL references/topics with a disclaimer. This would allow for those who disagree with UOL to not have to view it, and those that want to see it could then see it. This should satisfy both sides of this constant debate. Imperialbattlespire (talk) 09:59, 25 January 2021 (UTC)

Oppose; the two are not comparable. We have userspace for fanfiction and we allow UOL sources to be used in lorespace when clearly marked. Having two versions of the same article, one with rampant use of unofficial sources and one with valuable information stripped away, will lead to a duplication of effort and two low quality pages. To me, this proposal would represent a very serious split due to a failure to compromise, when we should instead be looking to produce a single, consensus-based article. —⁠Legoless (talk) 10:54, 25 January 2021 (UTC)
I agree with Legoless. This "solution" would simply create more problems than it would solve. Editors would have to ensure that changes were made to both versions of the page, it would be confusing to readers not well-versed in the subject, and it would inevitably lead to debates over which version of the page is the "correct" one. — Wolfborn(Howl) 11:07, 25 January 2021 (UTC)
Oppose, per what Lego said. --Jimeee (talk) 17:04, 25 January 2021 (UTC)

Defining what is and what isn't original research a lot better.[edit]

Its hard to tell what is or isn't, not everyone has the brain iqs to understand what it exactly is or isn't. The concern I have is its not defined with clear examples of what is or isn't Original research. Or what types of examples could be exceptions or anything. What I see as original research others do not, and what I don't consider to be original research others see as being that. It makes it hard to tell and I'm sure that I'm not the only one that has had this issu.. I'm hoping what can be done is a guide for the does in don'ts, So like a Tutorial of what you can and cannot do. This will also allow me to know how to spot original research and try and help fix it if I'm able, and I'm sure others would love to have a guide as well so they can avoid it and maybe do the same.TheVampKnight (talk) 03:38, 26 January 2021 (UTC)

The current guidelines already define what "original research" means and how to go about bringing up something you feel should be an exception.
"Even if a series of statements can logically be put together to reach a conclusion, that conclusion does not belong on UESP unless it has already been stated elsewhere (in valid source material).
A core goal of the UESP wiki is to summarize what's already known, like any encyclopedia, rather than to come up with new information.
Exceptions to this rule may be possible, but those exceptions need to be discussed on the talk page beforehand."
Seeing occasional OR on the wiki that's been vetted isn't an inconsistency, it's an example of going through the process. If you think there's an obvious logical throughline a page isn't utilizing, ask on the talk page. If you can get some consensus, then you can put it on the page freely. Otherwise, OR will tend to always lead to an edit war. - Jacksol (talk) 03:47, 26 January 2021 (UTC)
The problem is the original research policy is so widely misconstrued that just about any statement that isn't a baseball bat to the face of exposition can be deemed "original research" under the current guidelines. I've seen far too many cases where valid info is called by some as unreliable to the point where its basically McCarthyism. The policy should probably just be done away with and rewritten from the ground up because too many editors use it as a way to avoid having info they simply don't like put onto a page, its a policy that is exploited far too often and is barely cited anymore in the correct context. The Rim of the Sky (talk) 04:08, 26 January 2021 (UTC)
That's a fair point. I'll be honest and say I was partially basing my response off of already knowing exactly why this was being posted thanks to discord. In general, though, you're right. Having examples for what does and doesn't constitute original research would be pretty nice and would limit the removal of perfectly valid assumptions (and would have also made merging Naahfalaar a lot easier than it was). Jacksol (talk) 04:12, 26 January 2021 (UTC)
Maybe rather than redefining original research, we need to redefine how it's used. The baseline is essentially "no unsourced inferences", so if we follow the guidelines to first have a discussion, any inferences can be footnoted with a direct link to the discussion, which would explain for everyone else how that inference has been reached. --Enodoc (talk) 09:47, 26 January 2021 (UTC)

Different Stance needed for Documentation of Creation Club Lore Errors[edit]

Let's not make this a thread to argue about Creation Club's canonicity. That was already addressed by Cartogriffi, the Community Content Manager at Bethesda Game Studios.

I am not an official arbiter of Bethesda lore, but I hope you don’t mind if I chime in. Creations are official releases, but it’s also understandable that a site like UESP or the Imperial Library would take CC with a grain of salt. We do consider lore implications when reviewing proposals, particularly something trying to heavily enmesh itself into the world. Connections to the world are great, but we also want to avoid anything being too impactful. That is, we want things to fit into the game world, but we’re also not looking to greatly expand the lore of the game. With historic items, like artifacts, simply existing can have implications for the lore. Although artifacts in Tamriel do have a habit of disappearing and re-materializing in other places. I believe this was even noted in the description of Chrysamere in Daggerfall.

Now that said, I do want us to acknowledge thaat Creation Club screws up some times, and we should take a note on when NOT to document, or rather, taking a note of the obvious contridictions.

Divine Crusader[edit]

Pelinal Whitestrake’s relics have a mechanic added to them by the gods. You see this in action in Oblivion when you raise in infamy. An evil act will cause the message

“Beware! The gods have taken note of your crimes! Do not continue down this path or you will be unfit to wield the Crusader's Relics."

Another act will strip you of your ability to use the relics, and give you the message

"Your crimes have made you unfit to wield the Crusader's Relics. Walk the Pilgrim's Way to repent of your sins and once again seek the favor of the gods."

In the Divine Crusader creation, we see bandits wearing the crusader relics, throwing that mechanic out the window. Cartogriffi has made a statement saying, acknowledging that the Creation didn’t retcon it, it was just a mistake.

"We are aware that in Oblivion, the crusader relics would be unequipped if you committed sufficient crimes. While they function differently in TES V, they are still divine relics. The bandits wearing them are not intended to be proper recipients of this equipment.. "

The wiki handeled this well, in that it mentions the fact that the bandits had them, but not the obvious mistake of them being worn.

Spell Knight Armor[edit]

The Beldama Wyrd is the focus of this Creation, but they seem to have been confused with the Glenmoril Wyrd. The Beldama Wyrd are known worshippers of Jephre, Not Hircine like the Glenmoril Wyrd.

Jephre is important to the Beldama because they trace their origins to him, and believe they are descendants to the Ehlnofey. Jephre represents the first of the Earth Bones, which represents the Laws of Nature. Among these laws was His Naming, which gave the formless beings of Nirn their shape during the Dawn Era.

Prior to its (Accidental?) removal from ESO's live server during the Delve revamps, A book explored Hircine as the anti-thesis to Jephre’s order of established forms, and describes Lycanthropy as a means to reject the tyranny of the established shape. One ancient Khajiiti tale even credits the formless beings prior to being given shape by Jephre as being Hircine’s children.

The creation has an npc of the coven named Beldama Ward Mother, which is a Hagraven, creatures of decay which are known to be into dark magic and cruel against nature, which is definitely not Jephre's domain. The creation also tells of the Beldama coven doing the Briarheart ritual on a victim. The Briarheart ritual is something that involves communing with Hircine, not Jephre. Aside from texts that support Hircine's involvement with the Briarheart ritual, a quest in ESO deals with a Reachmen trying to earn the right of the Briarheart from Hircine himself.

Lastly, the Glenmoril Wyrd already have established relations with the Reachfolk, though it varies depending on which branch within the Glenmoril Wyrd covens we are talking about. So it makes sense for a branch of them to be associated with the Forsworn like the creation portrays Wyrds do. Theres also the issue of proximity. The Beldama Wyrd in both Daggerfall and ESO are located in close proximity to the city of Daggerfall. It makes more sense for the Glenmoril to make it to the Reach, as they are already spread throughout Tamriel.

Whoever pitched the idea to make the creation clearly just assumed that all Wyrds were into the same thing, not knowing that the Beldama have seperate beliefs from the Glenmoril.

Arms of Chaos[edit]

The Creation centers around trying to create artifacts that mimic the Staff of Chaos power. This book made a mistake.

“Master Ellane said the Staff of Chaos was crafted by Loreth, and passed on through the generations until it was stolen by Jagar Tharn, before being shattered into pieces by the Eternal Champion.”

In Arena, we see this is not the case. It was Jagar Tharn that was the one that broke the staff into pieces, and the Eternal Champion had to recover the pieces individually. The reason why Jagar Tharn shattered the staff was because, as Ria Silamane says,

"He knew that the Staff of Chaos was nigh indestructible, having been made from the essence of the Land itself. But in that he found the key. As the land is split, so did he shatter the Staff into eight perfectly formed pieces. These he scattered across the realm."

Now if the staff being shattered by the Eternal Champion is intended to be in the context of after the story, there is a line that may support this, but UESP notes that it is missing from the 1.06 version of Arena (and possibly other versions), and we can only speculate that it is either a bug or intentionally removed because it contradicts Ria’s earlier claims that the staff was indestructible.

“This is the Jewel of Fire, and the crucible of Tharn's life force. It is also the thing in which Tharn has suffused all of the energy of the Staff. If you can touch the Staff to this Jewel, the release of that combined energy may be enough to destroy the Staff of Chaos and open the gate between worlds. If you are successful, Tharn will no doubt be destroyed as well.“

This statement in Arena however specifies that it would be destroyed, not split, which is a difference Ria made in the first quote about Jagar Tharn having to resort to doing because it couldn’t be destroyed. Additionally, people have reported the Staff still being in their inventory after completing the Main Quest. So therefore, the Staff of Chaos wasn't destroyed or split at the end of the Main Quest, so the book can only be accurate if you make the assumption that the Hero split the Staff themselves after the events of Arena. The book can be an example of an in-universe mistake though, but ...

"The original Staff of Chaos, or Balac-thurm, was a relic of untold power, shattered into pieces and lost to time. In the years since, mages have sought to recreate its magic, traveling to worlds beyond the realms of mortal men. Follow the path of the mages as you obtain an ancient ring and restore the artifacts of chaos, including two new staves and an enchanted amulet!"

As you can see, the official marketing for it suggests otherwise. — Unsigned comment by Zebendal (talkcontribs) at 23:42 on 28 January 2021 (UTC)

I don't really get why any of this should be treated different than other continuity errors/ambiguous statements between games? Also, within 200 years a lot can change. The Beldama Wyrd could have make deals with other Deadric Princes in the meantime, or they strayed off their path, or got tricked, or they just forgot their original worship, or they were absorbed by another Wyrd while keeping their name, etc etc. The wiki is to document info and not to judge what exactly are errors. Note the differences on the page in the note section if you feel like the changes are significant. --Ilaro (talk) 14:44, 29 January 2021 (UTC)

Documentation of Morrowind non-relevant NPCs[edit]

I'd like to propose that people be allowed to convert NPCs that have been deemed "non-relevant" into actual pages if they're willing to put the work in to do so. There is no detrimental value to this being done as more info/documentation and an image for these NPCs is beneficial to those interested in that NPC. There has been plenty of times where I've searched for NPCs in Morrowind and the UESP hasn't popped up on Google because the name only exists on a list somewhere.

If the ESO namespace can achieve what it has so far regarding the 1000s of NPCs it has, I don't see how it's a lot of work to do this as due to the nature of these NPCs, it's actually a lot faster to make the pages compared to NPCs with unique dialogue, quests, etc, as they only need a screenshot taken and info from the CS regarding what they wear, carry and can cast, as the data values for everything else are already on the redirects. Imperialbattlespire (talk) 05:36, 29 January 2021 (UTC)

I support this proposal. Enacting it will make these NPCs much more searchable and will only be an addition, as it won't necessitate the destruxion of the current list format. And, of course, as Imperialbattlespire says, this will bring the Morrowind space more in line with namespaces of more modern games like ESO's. — J. J. Fullerton talk﴿ 05:38, 29 January 2021 (UTC)
There's absolutely no good reason to restrict anyone from doing this. It was a mistake 20 years ago, and one we don't have to keep making. --AKB Talk Cont Mail 05:43, 29 January 2021 (UTC)
100% this needs to be done, its very important to have every npc listed even if they are thought not important. Its been a huge pet peeve as a user not having any pages for these npcs. Even if they are not important to some they are very important for another user and all of them should be listed and have pages, made so we know what they look like and where they are. A prime example of pages needed is every vampire with a unique name its been a huge pet peeve not having that or any dialogue they might say. There have been cases where an npc isn't listed that has something important to say or is an important part of something I need to look up that I'd have to go to Fandom to even find and even then I can't find it at times but othertimes I get what I need from there. Generic or not, its important that these npcs get added in. Being a user myself and from that prospective I'd expect every named npc to have a respective page for them. TheVampKnight (talk) 05:45, 29 January 2021 (UTC)
I don't see an urgent need for this to be done, but I also don't see a reason why we should continue to prevent people from creating pages as they see fit. What I don't want to see is a mass bot job to make them all stubs, and then no one doing anything else for most of the NPCs. They should each remain non-relevant until someone decides to turn that particular page into a full page, as ImpBat did with the page that sparked this discussion. Jeancey (talk) 06:08, 29 January 2021 (UTC)
I can help with taking the screenshots, but I cannot help with the templates as I have trouble with them. Assuming this passes, make sure you all make a custom Nighteye spell of 65-100 points to use as morrowind is a naturally dark game and you will need it so the images don't come out too dark.Zebendal (talk) 06:30, 29 January 2021 (UTC)
I support this motion. We already have all of their stats; all we need to do is get their inventory, etc. -MolagBallet (talk) 19:36, 29 January 2021 (UTC)

() Just as a note, this discussion hasn't been closed yet, so I'll be rolling back any additional changes regarding this topic until this discussion is officially closed. Jeancey (talk) 02:29, 31 January 2021 (UTC)

Don't worry, we are patient. You only delay the inevitable. I have plenty of NPC images ready that I plan to upload as soon as this discussion is declared settled. Why are you against this? That other wiki has us beat on this part. As AKB said, this was a mistake made 20 years ago. Zebendal (talk) 02:40, 31 January 2021 (UTC)
My comment is unrelated to the eventual outcome of this proposal. This is entirely a process issue, and nothing to do with the specific proposal. On this wiki, we wait until discussions finish before implementing the proposals, not before. Jeancey (talk) 02:46, 31 January 2021 (UTC)
I don't have an issue with non-relevant NPC pages being created if someone wants to put the work in. —⁠Legoless (talk) 02:54, 31 January 2021 (UTC)
I have to say that I fundamentally disagree with Jeancey about not making the stub pages. If we're all in agreement that this is something that should have been done 20 years ago, as AKB said, then we should have the bot create the individuals pages. A stub page is infinitely more effective than just passively letting people make the page if they want to, as it literally shows that the information is missing to any potential editors. I don't see any reason we wouldn't do this aside from not trusting Morrowind fanatics enough to eventually finish filling in the pages, in which case I just need to point out, have you met Morrowind fanatics? Jacksol (talk) 03:06, 31 January 2021 (UTC)
Morroboomers are indeed pretty fanatical. Any missing information they would be willing to fill out as they have a huge passion for the game.Zebendal (talk) 03:08, 31 January 2021 (UTC)
While I have no objection to a bot job, I'm not sure I see much point to running one, either. You can literally just remove the redirect and rename the Non-Relevant template to NPC Summary, and you've just done everything the bot would do. Sure, the bot could add a Stub to the page as well, but then you'd just be trading Morrowind-Non Relevant NPCs for a new Morrowind-Stubs-NPCs or the slightly broader Morrowind-Stubs. No real benefit there. In the meantime, however, you will have lost any information on the location page, like info about the location itself, as well as the comment beside the one-liner for the NPC.
I didn't read through the whole discussion on Discord, cuz it was...large...and I'm not having a good day today, but I did notice a call for snowballing the discussion so people can get to work on the pages. If there are no objections, I'm willing to make that call, since the conversion to templates is the only real point of debate here, and despite my comments above, I don't particularly see that as a major issue, either way. Robin Hood(talk) 04:21, 31 January 2021 (UTC)

() Okay, in the absence of any objections, I'm gonna go ahead and call this snowballed in favour of changing non-relevant NPCs to regular ones as time permits. There's still some discussion of whether a bot (Dillon's bot, in this case) should be involved, but whether or not that happens shouldn't affect the overall decision of changing them over. Robin Hood(talk) 20:02, 31 January 2021 (UTC)

I don't know how to work with templates that much, so a bot creating the pages and filling them would be awesome. I have been uploading NPC screenshots. Zebendal (talk) 03:28, 4 February 2021 (UTC)
There currently isn't support for using a bot. All the pages already exist, there is no page creation for NPCs. Jeancey (talk) 18:52, 4 February 2021 (UTC)

Arena Artifact Dialogue[edit]

Currently, all artifact citations for Arena boil down to "Events of Arena", which is a pretty bad citation and is something that we should avoid all together. We have the Artifact Quests page, but it is pretty bare. I was wonder if either we should just link to the similar page on Imperial Library https://www.imperial-library.info/content/artifact-dialog , or if someone with authority here could ask someone from the Imperial Library itself like Lady N or Benefactor for permission to host the dialogue here with a note that the dialogue was originally archived there. Wouldn't help to try since we have a friendly relationship with them, and this could benefit both wikis and help spread obscure arena dialogue more.Zebendal (talk) 09:08, 6 February 2021 (UTC)

We should just try to get them from the game instead of hosting them from another website. There is a lot of dialogue from Arena that's still not documented on the wiki. --Ilaro (talk) 18:46, 6 February 2021 (UTC)
This dialogue is not difficult to datamine, it's stored in plain text in the Arena directory. We should copypaste it somewhere as most of that info is missing from the wiki. —⁠Legoless (talk) 21:47, 6 February 2021 (UTC)
I have no idea how to datamine, so you all would have to handle that on your own. Zebendal (talk) 02:39, 7 February 2021 (UTC)

On Quotes and Quote Boxes[edit]

The use of centered/text-aligned quotes and quote boxes at the top of a section has long since irked me. The placement of a quote before even setting up the premise of the article, like this particularly egregious double quote on Lore:Wild Hunt, strikes me as incredibly unencyclopedic. The content that is being shifted down will likely be the MOST important on the entire page/section. Not only do quote boxes like these overshadow the critical information, they often don't serve to further the user's understanding of the subject in any capacity.

Take, for instance, the quote on Lore:Lysandus, the very first thing the user will read. Is it really more important that the user know that the ghost of Lysandus once uttered "vengeance" than the fact that Lysandus was the king of Daggerfall? It's not just the beginnings of articles, it's a problem for sections too. Quotes like the one in the "History" section of Lore:Khajiit suffer from the same problem. Before a user can learn about khajiiti history, they must first read a lengthy quote that only establishes that "there is khajiiti history", a conclusion that the user already came to upon seeing the existence of a section labeled "History".

This is not to say that quotes are unsightly and inherently detrimental to wiki articles. I think that quote boxes that are used in the exact same manner as image thumbnails are a great way to spice up the visual appeal of a page and make it more fun.

Just like images, I think quotes need to be seen as decoration and treated as such. For instance, I think that the use of quotes on Lore:Warp in the West is great; it compensates for the lack of images. It does seem like this philosophy is built into the default CSS of the quote box template, but it is frequently being overwritten via its style parameter in ill-advised situations. The quote box on Dawnstar:Dawnstar is, in my opinion, one of the few examples where forcing a quote box to occupy the full width seems appropriate.

My suggestion is to outlaw positioning a quote "before" the first word of a page or section, except for extreme circumstances. This ensures that the informative content is given priority and reinforces the decoration-mindedness that I believe is necessary for handling quotes. -Dcsg (talk) 01:32, 12 February 2021 (UTC)

I completely agree, and have tried to make use of quote boxes only where they fit, and when they're relevant. An oversaturation of quote boxes, just like with images, can make a page unsightly. -MolagBallet (talk) 02:24, 12 February 2021 (UTC)
I addressed the issue with Wild Hunt page and made it look better while I was doing it and even added an image at the top and used one quote that was most fitting for it. The others I just got rid of. The way it was, before I edited it looked so terribly bad it was not even funny, so I fixed the issue with that page. Quote boxes are fine but, not in the way it was done on the Wild Hunt page as that was just plain cringe.TheVampKnight (talk) 02:26, 12 February 2021 (UTC)
I definitely agree that that was an improvement to the page, but the argument I made about prioritization still stands even after those changes. -Dcsg (talk) 02:44, 12 February 2021 (UTC)
My initial opinion was they are trashy, but people are fond of them in general so I wasn't going to oppose them unless they were truly bad ("Meme Quotes" like the poor quality one that was added to the top of Lore:Svargrim). That said, the way Lore:Warp in the West uses them is actually great. Using a quote when we are short on images is a great way to keep the page content dense while also being visually pleasing. I support a new guideline being adopted. --AKB Talk Cont Mail 03:13, 12 February 2021 (UTC)
I think quotes can be nice to have on a page sometimes, but per the Svargrim edit I don't think every lore page benefits from one or needs to have one. —⁠Legoless (talk) 09:07, 12 February 2021 (UTC)
I disagree with a complete ban on top quotes. Take the quote on Nahfahlaar's page for example, "While my brothers were slain or locked away, I have been free. I know when to fight, when to fly, when to look for allies. And so I stand before you, nikrent. Unbroken." It tells a lot about his character and how he differs from his brothers.- Zebendal (talk) 22:55, 12 February 2021 (UTC)
A reader who doesn't know anything about the topic of the article would glean FAR less information from a cryptic quote than the first actual, encyclopedic sentence "Nahfahlaar (also known as Nafaalilargus, sometimes spelled Nafalilargus or N'falilaargas) was a red dragon who often allied with mortals for his own protection." The philosophy on the UESP of prioritizing content over style has existed since 2006. Objectively, there is no such quote that will ever give more context in an encyclopedic manner than the authors of this wiki are capable of. Hence, it ought to be treated as style, and as style, should take a backseat to content. -Dcsg (talk) 23:16, 12 February 2021 (UTC)
I disagree with the removal of relevant, well placed top page quotes and I disagree with prejudice the retroactive application of this to older articles regardless of the decision made.Dcking20 (talk) 23:39, 12 February 2021 (UTC)
Regardless of the conclusion we come to, there's no avoiding a "retroactive application" of this concept to older articles. If a policy is put in place for something, everything under the namespace it applies to is affected. This isn't suggesting that we ban the use of relevant quotes. Well-placed quotes aren't going anywhere, ill-fitting and ugly top page quotes are. Bottom line is if something is ugly, useless or ill-fitting, then it's ugly/useless/ill-fitting. -MolagBallet (talk) 00:21, 13 February 2021 (UTC)
I provided a very non open ended disapproval for the proposal. What about my comment warranted you playing the “that’s not how this works” card followed by giving your very subjective rundown of opinions on the nature of these top page quotes like those opinions could somehow be projected onto myself? I’m not interested in games, I’m only interested in giving my word of dissatisfaction on the record. Also why did you speak of these top page quotes “going away” in a factual manner like it’s already said and done and this isn’t a one day old discussion with about equal parts agreement, equal parts dissent, and equal parts in between???Dcking20 (talk) 02:20, 13 February 2021 (UTC)
I agree with the removal of quotes at the top of the page before any other information in the article and similarly at the top of particular sections within the page as per the example of the Khajiit history section. While I can only speak for myself, whenever I read an article that has such a quote at the very top I automatically skip over because I want to read the information on the page. Trying to think of this from a new user's perspective, I cannot imagine that such top page quotes are particularly useful without further context that they would obtain later in the article. Especially if it's a meme quote like what was on Svargrim or what is on Lysandus' page. I do like the example of the Warp in the West page and I agree that it is a great usage of quotes to style them in similar placement to that of images.
To be clear, while I agree with the removal of quotes being removed from the top position of pages I do not mean that quotes don't have a place. Were such a guideline laid out after this discussion I would say that pages with top quotes only need such quotes to be moved around on the page to allow for a more pleasing format. Once again, similar how the Warp in the West page handles them. Enderkingdev (talk) 03:22, 13 February 2021 (UTC)
I wasn't going to wade in on this discussion, but tonight I came across another example of what people like Dcsg, Enderkingdev, and others are talking about. I went to this article to find out who this character is, only to find a completely meaningless quote at the top of the article: meaningless because without knowing the context, the only thing it does is leave you wondering what the hell it means. It did nothing for me but get in the way of the information I wanted to know and detracted from the article. I agree with many here that quotes can add to an article when used judiciously and wisely, but too many articles seem to have a quote at the top for no other reason than to have a quote at the top. If we're going to put quotes in articles, let's make sure they're relevant, informative, and located where they complement the information and enhance the quality of the article rather than just throwing a quote at the top of every page for the sake of having a quote at the top of every page. — Wolfborn(Howl) 08:50, 13 February 2021 (UTC)
I don't think there needs to be a policy as it will hinder the communities efforts to make the Uesp look and feel better. If there is a problem like there was clearly with the way the Wild Hunt page quotes were handled, that is where editors should work to address the issue. Like I did with the Wild Hunt page when I saw there was an issue. That way we can continue working on improving the Uesp. If there is stupid and not very fitting quotes those can be changed or removed by editors when its spotted by them. TheVampKnight (talk) 12:12, 13 February 2021 (UTC)
I agree with the idea of generally removing top-of-page quotes and relocating them to somewhere more useful on the same page. "Top-of-section" quotes are less of an issue for style but equally as likely to be unnecessary. --Enodoc (talk) 15:39, 13 February 2021 (UTC)

() I don't see the big issue with having quotes at the top of pages, it's the same as all wikis I've seen in my experience, I just think its a case by case basis, I think https://en.uesp.net/wiki/Lore:Four-Score_War is a good example of a top quote working very well, maybe a quote section could be implemented into the character template or something? Imperialbattlespire (talk) 10:23, 14 February 2021 (UTC)

I think these quotes started here exactly because other (game)wikis do it. But just because others do it, doesn't mean we should too. I'm with Dcsg that they are usually not very informative and we should strife to always get the most important/concise info at the top of the page. Quotes can then take a backseat to provide a more rounded page where images are absent. --Ilaro (talk) 11:24, 14 February 2021 (UTC)
I think it is a mistake to be removing quote boxes entirely, as we would be removing an (imo) important avenue to display what in-universe characters think on certain subjects or characters. A good example of this is on the https://en.uesp.net/wiki/Lore:Ja%27darri page, the first thing a user sees is an analysis of her character by Nahfahlaar. You also have more lore-discoverability, as the curious user would wonder "who's Nahfahlaar?" and go to his page to find out more about him. As a user, you instantly get to know her character, in a way that "Ja'darri was an ancient Khajiiti hero" never could. If you removed that quote from the top of the page, and just used it as a cite for elsewhere on the page, it would just be dull and would make the page less interesting. Quotes displayed prominently like this allow the user to get a better picture of an event, or a character from the in-universe perspective, more than just normal wiki prose could.
I also disagree with the mindset "just because other wikis do it doesn't mean we should", because this is the same mindset that kept us in the past with things such as image resolutions and aspect ratios. Sometimes it is useful to analyse what other wiki's are doing and adapt (keyword being adapt, not necessarily take verbatim) that to our purposes.
That being said, there is room for improvement here, I would argue that instead of removing quotes, the policy on quotes on pages should be that they are relevant to the article and help explain the context for a new user. This means that we don't have meme quotes "The grey host is my true ally!" because they will become dated and meaningless several years down the line, and also doesn't actually tell you anything about the subject itself. Additionally, we should perhaps prefer quotes by other characters, instead of ones from the subject themselves, as they tend to be more informative, like the Ja'Darri example. Thal-J (talk) 15:08, 14 February 2021 (UTC)
Removing quotes of any sort is a silly idea, its really just a matter of making sure the quotes are good rather than poorly chosen. The Rim of the Sky (talk) 22:26, 14 February 2021 (UTC)
I think you misinterpret my quote Thal-J. I agree that we can and even should look at what other wikis do and adapt from that. However, my point was that just because other wikis do it, doesn't mean their policies are necessarily good ideas for our wiki. And not sure why you're saying that that mindset is holding us back, as me being one of the people with that mindset and also always been a proponent for better resolutions of images, better dialogue formatting for older namespaces, etc since the start. Every policy change should have merit on its own regardless of what other wikis are doing. --Ilaro (talk) 15:32, 15 February 2021 (UTC)
Ilaro, its not about adopting other wiki policies, its if quotes are appropriate. In this thread we have seen some great examples and some bad ones. Its down to how they are used.
Its not entirely true that these quotes started here exactly because other (game)wikis do it... I started using these rounded boxed quotes back in 2014 when I joined - we used basic italic quotes back then. However its true that the style is partially inspired by the article quote boxes I made when I was at wikia - but that's not the same as adopting other wiki policies - its adopting good ideas. I think the first page it was used on was Lore:Tyranny of the Sun. They became more common after that and eventually Robin created a template for it. --Jimeee (talk) 16:15, 15 February 2021 (UTC)
Actually, the original post which started this whole discussion wasn't about whether quotes are appropriate, it was about the placement of quotes in articles.
From what I can see reading through this discussion, pretty much everyone who's posted here agrees that using quotes in articles is fine, yet this discussion seems to have become focused on whether quotes themselves are acceptable. Given that there seems to be a consensus on that point, perhaps we can all agree that using quotes in articles is fine, stop focusing on that issue, and re-focus this discussion on the original question of where the quotes in articles should be placed. Should banner quotes be allowed at the top of articles / sections, or should they be placed less obtrusively, off to the side the way images are used? Hopefully this capsule summary will help to move this discussion back on track. — Wolfborn(Howl) 23:06, 15 February 2021 (UTC)

() I also feel like quotes at the top of articles are just completely unnecessary and often are detrimental to the flow of the article. As have previously been stated, I just skip over them entirely, and given they are without context, I don't see how they are beneficial in any way at the top of the article. There MAY be one or two where there is an exception to this, but I doubt it... It just isn't really a good place for these quotes, and just serves to distract from the article itself. Jeancey (talk) 18:18, 16 February 2021 (UTC)

A suggestion not to cover, the worst lore bloopers from the Creation Club Content on lore pages.[edit]

We have been talking about this of how bad it is with the whole Beldama Wyrd stuff the third party people did with that one Creation Club. Which doesn't make much sense given their lore and history. What I suggest we do is take it from a Grain of Salt. The Dev did state that Uesp or Imperial Library may take them as a grain of salt. That is what I think we should actually do with the creation club content. Most Creation club lore is fine, even Umbra can be explained because Daedra reform after death and each of the Daedric Artifacts could possibly be reformed as well. Even the Beldama Wyrd stuff could be explained but after reading some of the positions on it. I do think we need to vet this type of thing. For actual mistakes and not cover those mistakes. Anyone else feel we should do this? So the suggestion is to cover all the Creation Club stuff in the Skyrim section but not cover all of its lore if its breaks with the main theme of that lore on the respective lore pages.TheVampKnight (talk) 02:31, 23 February 2021 (UTC)

This is a really bad plan. As much as I dislike certain things from it, we can't say some aspects from Creation Club should be documented and not others, that's an extremely slippery slope that can only end up poorly. Jacksol (talk) 03:18, 23 February 2021 (UTC)
I feel that UESP's goal is to document the lore, not decide it. So, if Spell Knight Armor or whatever other CC creates discrepancies, then we should document those discrepancies. Ideally, that would be within the body of the Lore text itself, but if need be, it could be separated out into its own section, labelled "Discrepancies" or "Lore Conflicts" or whatever else, then mention there what the issues are. Robin Hood(talk) 04:44, 23 February 2021 (UTC)
Well I'm really of the opinion we should still document all of it, but I made this suggestion because, going by the devs statement, Uesp and Imperial libaray may take it as a Grain of Salt. So we could securitize the worst aspects of it and mistakes made and I don't think we need to cover those mistakes in the lore. I'm fine with what outcome comes from this discussion really. It would be preferable to me if we still keep that stuff in the lore page. I do agree with Robinhood. We could add in the discrepancies thing or warning and mention exactly why it conflicts. So I would personally prefer the lore conflicts mention and header as that would be the better solutionTheVampKnight (talk) 05:40, 23 February 2021 (UTC)
Right now, I worded the Beldama Wyrd page to say "Sometime in the Fourth Era, the Beldama seemingly abandoned Jephre, and instead took up traditions associated with Hircine, who is an antithesis to much of what Jephre represents." Thought that was neutral enough. Sucks that creation club authors confused the Beldama Wyrd with the Glenmoril Wyrd, shows that they don't take their time researching for their additions which can have negative lore implications. Zebendal (talk) 05:46, 23 February 2021 (UTC)

() About the Hircine Beldama thing, there's two things that should be kept in mind: the first is that wyrds are not monolithic entities. The Glenmoril Wyrd, supposedly dedicated to Hircine, also had covens that worshiped Molag Bal, Namira, or Mehrunes Dagon. And the Glenmoril covens who do worship Hircine do not share the same dogma about him, which translates to different attitudes wrt. the Reachmen and lycanthropy. So if there's this variety of faith in the Glenmoril Wyrd, why would the other Wyrds be entirely unanimous in their religious beliefs? Why couldn't there be a Beldama Coven that has come to essentially do a 180° turn compared to the mainline?

I suspect the author went with the Beldama mostly because the Glenmoril have been a tad overused already (Bloodmoon, Oblivion, Skyrim, Dragonborn) to the point that the others were at a risk of getting entirely forgotten. --Gez (talk) 11:42, 23 February 2021 (UTC)

At the end of the day this is a simple matter. This is official content in the games and should be documented. We should cover it in the most encyclopedic way, which may mean noting contradixions. There is little else to discuss on this matter. — J. J. Fullerton talk﴿ 05:15, 25 February 2021 (UTC)
I agree 100% with Jacksol, RH and Fullerton. CC content is released as official Bethesda content. There's no reason to treat it any differently than any other official content which Bethesda releases for the ES series of games. — Wolfborn(Howl) 05:40, 25 February 2021 (UTC)
I already voiced my opinion on a similar topic from a couple of weeks ago and I reiterate that I also disagree with this proposal. --Ilaro (talk) 08:39, 25 February 2021 (UTC)
This proposal aims to exclude documentation of certain sources based on nothing more than personal distaste for lore inconsistencies. It should be clear that this runs counter to the wiki as an encyclopaedic project aimed at neutral documentation. I concur with Fullerton that there is little to discuss here; to me the existing standard seems absolutely fundamental. —⁠Legoless (talk) 11:50, 25 February 2021 (UTC)

Proposal to remove autopatrolled status from patrollers[edit]

This is something I've been meaning to raise for a while. UESP grants patrollerships on the qualification of whether one can patrol others' edits, and not of whether one's own edits are patrollable. Using myself as an example, I was raised to patrollership despite extremely valid concerns over the standard to which I held mine own edits. This and other examples of the process by which patrollers are nominated and raised to the role suggest to me that it should be separated from being autpatrolled. I note this might require a spate of nominations of current patrollers to being autopatrolled, which may necessitate a review of all current autopatrolled users. That besides, I believe this to be a necessary step given how we as a wiki select patrollers. — J. J. Fullerton talk﴿ 05:15, 25 February 2021 (UTC)

I see no harm in doing this. -Dcsg (talk) 05:55, 25 February 2021 (UTC)
No. I see active harm in doing this. This would result in about a 10,000 % increase in unpatrolled edits, and make it significantly harder to find and patrol the edits that really need patrolling. If someone has concerns as a patroller that mean they shouldn't have their edits patrolled, then they shouldn't be a patroller.
What I'm gathering from this is that perhaps Fullerton needs to have the patroller role removed. An inherent aspect of being a patroller is the trust and qualification that their OWN edits are good enough to not need to be patrolled. If they can't be trusted with their own edits, then they shouldn't be patrolling anyone else's. End of story. Jeancey (talk) 06:14, 25 February 2021 (UTC)
While I think Jeancey's comment to Fullerton was uncalled for, as he already got his patrollership removed, I do agree with the gist of his statement. Patrollers are expected to get the autopatroller role and thus should be rejected if they are expected to not adhere to those standards. --Ilaro (talk) 08:43, 25 February 2021 (UTC)
I agree with Jeancey and Ilaro on this. The very job of patroller is about being accurate enough that your edits don't need to be patrolled and, in fact, that you're able to help correct other editors' mistakes. If you're not able to do the first part reliably, then by definition, you shouldn't be a patroller. Yes, conceivably we might catch a few mistakes by having patrollers' edits cross-patrolled, but these are supposed to be infrequent enough that it's better to focus on other things. As Jeancey said, not having patrollers' edits auto-patrolled would enormously magnify the workload for vanishingly little benefit.
Also, as I mentioned in Discord, I don't believe patrollers not being auto-patrolled is a common scenario, so I wouldn't necessarily trust it to work 100% reliably in MediaWiki to begin with, but there's the added concern of how that might interact with some of our customizations like Userpatroller. Robin Hood(talk) 08:56, 25 February 2021 (UTC)
This suggestion makes no sense to me. I would not trust someone to patrol another's edits if their own could not be autopatrolled; it's the bare minimum required for the role. —⁠Legoless (talk) 09:29, 25 February 2021 (UTC)
After reading and seeing what it is by other people's descriptions of it. I see no reason to remove the Auto Patrol feature. Its a good quality to be very good at something and doing editing extremely well. If its a good thing, and makes quality of life easier why do away with it? I can fix stuff if I see it if its blatantly obvious but I can't fix grammar as I'm not the best with it and I wouldn't be patroller material I feel at least not right now or anytime soon. But those that do have those qualities and make the cut should have the tools they need to make it easier to do their jobs, and why take that away from them? TheVampKnight (talk) 09:51, 25 February 2021 (UTC)
This is about separating Patrollership from Autopatrollership, not removing patrolling altogether. From what it sounds, ideally nothing perceivable would even change, as (almost?) all patrollers would be granted autopatrol rights, so no aforementioned 10,000% increase in red exclamation points. I think what Fullerton is trying to bring to light is that having a keen eye for others' edits is a different muscle than having good edits yourself, and that one does not necessarily have both fully trained at once. I think there is validity to what Fullerton is saying, but lacking in displaying how such a change is needed. -Dcsg (talk) 17:39, 25 February 2021 (UTC)

() I hadn't picked up on that specific point in the OP, but even so, I really don't see the point of separating them. I don't agree that patrolling your own edits and others are different muscles, to use your wording. An edit is an edit is an edit, to my mind. If you can't be trusted to check your own edits, you can't be trusted to check others' and vice versa. And for the rare time that you do want someone else to look over your edit, we all know that we can just ask one another. Separating the two would just be an exercise in redundancy, as I suspect all current patrollers would be deemed to get both, while nobody new would be added with only one or the other. I can't ever see myself voting someone into patroller if their own edits couldn't be trusted, and I think from what I'm seeing here and in Discord, most others feel the same. Robin Hood(talk) 18:05, 25 February 2021 (UTC)

This is an incredibly silly idea for the many aforementioned reasons people have given. You made mistakes and lost your role already, don't make it harder for the rest of us and let it go. The patrol status of edits isn't as big a deal as always made out to be as anyone can doublecheck any edit and see flaws if they wanted to. The Rim of the Sky (talk) 21:55, 25 February 2021 (UTC)
I'll note despite the comments on mine own patrollership that I'm not proposing this for mine own convenience; indeed, this proposal cannot affect me by its nature.
In every field of writing, editors are separated from the writers. Journalists submit their pieces to editors and subeditors to be proofread and checked; novel writers submit to editors or editing agencies. The simple fact of the matter is that being good at writing or being good at wiki-editing is not the same skillset as being able to proofread and very that someone else's wiki page edit meets stringent and high standards. They're completely different skills, and we shouldn't be treating them as such. — J. J. Fullerton talk﴿ 01:50, 28 February 2021 (UTC)
Well the thing about this Fullerton, there are some areas I do agree with you on. I've seen Admin edits that don't match actual sourcing's, or have pure speculation in certain lore pages. While I do agree that Patrollers and Admins do have to have their work checked as they are not above mistakes or bending their own rules because they are in charge of everything. That does not mean we need to take away AutoPatrol. Don't need to be a patroller or admin to correct a mistake a admin or a patroller makes as it really isn't needed to make their jobs a lot harder. As the Uesp is all a community effort and that is what we do here. TheVampKnight (talk) 02:16, 28 February 2021 (UTC)

Proposal for the inclusion of dialogue on quest pages[edit]

Currently, our standard is to document quest dialogue on NPC pages and entirely remove it from quest pages. A common argument for this is that dialogue will obscure the quest walkthrough, clogging up the page with irrelevant detail. However, the resultant paraphrasing of dialogue is arguably worse, including irrelevant detail that doesn't even reflect the game. However, these pages are not walkthroughs. The walkthroughs are sections on these pages which document quests, which is our goal as a wiki. The exclusion of dialogue is a failure to document. I'm proposing, therefore, a compromise. A third section on quest pages entitled "Full events" or similar, including NPC events and dialogue that change as the quest progresses. I'm not saying that all quests must be changed now to meet this new ideal; I merely propose that this becomes our new goal with quest documentation.

This would help users of the wiki massively. While us editors know full well that we can load up Online:Razum-dar after the requisite loading time, skip to the relevant quest, and read the dialogue, new users of UESP simply see the dialogue of the quest isn't on the page, and if they don't give up then they give up when they have to keep a half-dozen pages open to see the full events of the quest—especially if some are as lengthy and dense as Online:Razum-dar. This, quite frankly, is user-unfriendly and should change. We're doing an active disservice to readers hoping to catch up on quest dialogue by forcing them to keep dozens of pages at a time open, and it makes it harder to find dialogue on a common subject from several different NPCs despite quests being a very funxional method of separating by topic. Removing dialogue for the sake of removing dialogue makes it harder to follow the walkthrough if one isn't actively playing through a quest; without dialogue to anchor, it's almost impossible for a casual user to double back and see what just happened in a quest or, worse yet, what happened in a quest they played some time ago.

I'm also investigating the possibility that this proposal could involve saving dialogue and pulling it via #lst, thereby preventing duplication of information and automating NPC pages. DCSG has agreed to work on a mockup for this, and he'll soon have it ready as an example.

In the end, the aesthetics of having a dialogue-free quest page should be a minor concern next to the manifold benefits of including it. I'm not asking anybody as an individual to change all their own work to meet the new ideal. I'm not asking anybody to change all of the pages affected by this; I'm merely suggesting a new ideal model for quest pages. — J. J. Fullerton talk﴿ 01:48, 28 February 2021 (UTC)

This is something we desperately need. Whole-heartedly support. Correct on every level.
Omn (talk) 01:50, 28 February 2021 (UTC)
Agree with this proposal, I don't see an issue with including it as a section on its own, that way people who don't want to see it all and just want to see a quick walkthrough can do so, but those who do want all dialogue, etc can scroll down and see it, it'll mostly just be a copy paste job from existing NPC pages anyways, so not like its a massive job for those who want to do it. Imperialbattlespire (talk) 01:53, 28 February 2021 (UTC)
Heyo folks, Bryn here. I've discussed this topic with Fullerton a number of times in the past, so he told me he was formally making this proposal, and here I am to offer my support, not as an editor but as a regular user of the UESP. I check dialogue pretty constantly, in special for ESO, and it really is a hassle to be required to keep a number of tabs open and have to cycle through them repeatedly to get the information I want (and also keep running into repeated bits of dialogue shared between characters, thus making the argument about duplicating information pretty insidious). By keeping all the relevant dialogue on the relevant quest it would not only be easier to get this type of information, but, in my opinion, would also make actually writing the walkthrough and sequence of events much more objective and easier on the editors, by not having to write summaries of the exchanges that often tend to be biased in their interpretations.
On various occasions I had to turn to the TES Wikia to get bits of dialogue that I just couldn't find on the UESP because of this kind of policy.
Be it on a section of its own, or in collapsable tables in the body of the walkthrough, the inclusion of dialogue in the relevant quest pages would only benefit these articles and the experience of every user in the site. 02:10, 28 February 2021 (UTC)
Our current set up is definitely fairly user unfriendly in terms of dialogue. In fact one of the most common complaints I get from non-UESP affiliated peers is that our ESO quest pages are severely lacking in many cases, this change would be a great way to bolster them. It’s fairly obvious we need to make changes with how we handle dialogue. Thankfully, from what it seems like, we would definitely have enough users willing to put in the work to make this change, I see no reason not to test it out. Naga007 (talk) 02:13, 28 February 2021 (UTC)
Great idea. Support. Dcking20 (talk) 02:21, 28 February 2021 (UTC)
Amazing suggestion, I wanted to bring this up before. I dislike having to open other tabs to look at associated dialogue. Would make "Events of Quest" citations better.Zebendal (talk) 02:25, 28 February 2021 (UTC)
The issue that I've been having is with two things, one not every bit of npc dialogue on the npcs page but can be found on the respective quest page. Another is npcs involved in quests not being able to be found on respective quest pages in terms of links. Like if I want to find an npcs dialogue from an Eso quest page, or want to look up a note or something with some type of lore stuff from that quest you have to go around to find all those npcs. I can't find it the important npcs or lore stuffs that easily. So what I suggest we do is keep Npc dialogue off quest pages and then link to the pages of all the npcs involved in said quest and even side characters, as well as all lore source material like books or notes. As that for sure has been an issue at least for me. A perfect example of this is this quest https://en.uesp.net/wiki/Online:Chasing_Shadows this has an npc that I wanted to look up but what the npc page does not the quest page itself have his journal so people can find it, which was important to me because I had to look up something the other day and I couldn't find the journal and had to go find it the hard way. So that is the problem I've had is important stuff that I need to look up can't be found as easily. TheVampKnight (talk) 02:31, 28 February 2021 (UTC)

() I agree with this as an editor and a user. I have completed aforementioned mockup, which can be seen on Online:Sandbox. It's not perfect, since it's using something that had elements of a walkthrough, but hopefully you can see how it would fit if those two subjects were split on a quest article. -Dcsg (talk) 03:05, 28 February 2021 (UTC)

Vamp makes a very good point. In the current system, in order to gather all the dialogue from a specific quest, you have to go to each character involved with the quest, sift through their potential mountainous piles of dialogue in order to find what you’re looking for, and then once you’ve done that for each character, you have to piece together the sequence of dialogue yourself. From a user standpoint, that’s incredibly inefficient, tiresome, and inconvenient. As a wiki, our primary goal is to document, our secondary goal is to make the information accessible. With how we handle ESO quest dialogue in the current system, it is adequately documented; however, it is subpar in how it is readily accessed. A solution of some kind feels warranted. Naga007 (talk) 03:28, 28 February 2021 (UTC)
I just use Control F, and that wasn't what I was referring too, what I was referring to is the Skyrim stuff with the Dialogue not being all there on the Npc pages where I can find the dialogue. Then I was mentioning talking about the quest pages don't list all the related npcs in Eso Quests with a link to their respective pages on the Quest pages themselves, and it doesn't list any of the unique journals or notes written by certain npcs that can be found in those quests. Finding Dialogue isn't an issue with Ctrl F, what is a problem is finding the respective npc names or even books they may have that have important lore sourcing. What I care about is if the Npcs have all the dialogue they said on the respective game pages as well as any books or lore stuffs they written, in a place where I can find the links to those. Just by looking at the respective quests or npcs. To make it much easier to find stuff, so when I'm having a conversation then I can just look it up easier. Instead of having to go out of the way just to find something. TheVampKnight (talk) 05:43, 28 February 2021 (UTC)
I would like to point out the actual current standard states that dialogue SHOULD be on the quest page.
Dialogue. Key quest-related dialogue should be quoted as part of the walkthrough. In particular, if there is information from an in-game dialogue that would otherwise need to be paraphrased as part of the walkthrough, it is generally preferable to quote the dialogue instead of paraphrasing it. However, the walkthrough should not attempt to include every piece of dialogue that you hear during the quest.
So those people who think that dialogue is somehow banned completely from quest pages, that's not really accurate at the moment. Jeancey (talk) 05:59, 28 February 2021 (UTC)
Yeah Jeancey. I've not worked on many ESO quest pages, but for Dragonborn DLC I added tons on dialogue to quest pages no problem. There are definitely ESO quest pages with dialogue that exist (Online:Soul Shriven in Coldharbour, Online:Partners_in_Crime). Where did this idea come from that dialogue is banned from quest pages? --Jimeee (talk) 10:32, 28 February 2021 (UTC)
I believe that originated because, especially in ESO, it happened sometimes that only a big dialogue dump was added and nothing else which got some pushback. Anyway, yes I like this idea. Dcsg's plan to use #lst seems great to me, even when it raises the difficulty a little bit higher. I think we can easily lower that bar a bit by templating it. {{Section Begins|Queen Ayrenn}} (or whatever we want to name it, we can decide anything we want for easier implementation) looks a lot cleaner and easier to use than <section begin="Queen Ayrenn"/>.— Unsigned comment by Ilaro (talkcontribs) at 02:46 on February 28, 2021‎
The template for the sections may be a bit much, but I suppose there would be no harm in having it. What I did envision being templated would be the Quest-Related Events section of an NPC, where it would look something like {{Quest Events|Quest1|Quest2|etc...}} and it would automatically form all of the sections and use #lst for you. -Dcsg (talk) 17:31, 28 February 2021 (UTC)
I think a section for dialogue that's separate from the walkthrough is a good idea that addresses everyone's concerns - the walkthrough itself isn't overloaded, while the dialogue is still included. Perhaps "Dialogue Transcript" would be a reasonable name for the section? --Enodoc (talk) 20:26, 6 March 2021 (UTC)

Splitting up References and the issues that are associated with it, along with should we be doing this?[edit]

While the idea is good, because if a page has so many references it maybe good to split them off. I've noticed its very buggy, and doesn't always work to take you to the reference. Another big issue is Editors convivence. The new overhaul had information that, also is Orcish History lore, so I used that as part of the expansion or overhaul work on the Orc page. When I did that the issue I had, was I had to go through all those citations to fix them, to make it so it didn't error. Now I'm not saying we should do away from the idea, but it needs to be coded in a way. So that editors can transfer information to another page, when needed without having to go through all the references without causing such errors.TheVampKnight (talk) 10:51, 3 March 2021 (UTC)

I think the 2 main issues people have highlighted is the buggyness and also that reference sections might give undue prominence to certain types of sources. But going past all that - I need to ask the primary question of "What problem does this solve?". And if it does solve a problem, the next question is do we have evidence of this being a problem for enough people for it to warrant a solution. Its easy to fall into the trap of using what we as editors find problematic, and then believing that the wider UESP readership also have this problem, when they possible don't. Our personal annoyances shouldn't really be a basis for a design change that can effect the wider readership.
I suspect this change is an effort to organise the 100+ refs on articles into some order - So I ask if having an organised reference section is truly helpful to readers? I can only give my own experience (which of course is in no way representative of an average UESP reader), but I have never felt giant lists of refs needed to be broken down, either here or on wikipedia. To me, ref sections are not really sections that I would use to browse sources in the same way I would Lore:Library. I'm interested to hear other's opinions on why we should have this change - but at the same time we need to recognise that we editors are so far removed from the average UESP reader that our opinions on what they would like to see are possibly not as relevant as we think. Not without evidence. --Jimeee (talk) 15:36, 3 March 2021 (UTC)
I'd like to encourage discussion on the subject. Please do criticise the experiment. I have only separated the references on two pages: Lore:Molag Bal and Lore:Breton. Implementation on Lore:Molag Bal was done on a whim after one user said "wow that's a lot of references, it's kind of impressive", and another user said "reference groups are a thing if you ever feel like they should be separated". So I decided to see how it looked. The only reason Lore:Breton got the treatment is because somebody suggested it once while the project was still on my sandbox after they liked the ref groups on Lore:Molag Bal, and I implemented it for the sake of testing. Personally, I like organizing things, but I can see why people might consider the grouped citations unsightly or unnecessary. I have no qualms with eliminating the excess reference groups if people abhor them. -MolagBallet (talk) 19:28, 3 March 2021 (UTC)