UESPWiki:Community Portal/Archive 56

This is an archive of past UESPWiki:Community Portal discussions. Do not edit the contents of this page, except for maintenance such as updating links.

Namespace for Call to Arms/etc?

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 ^{(talk • contribs)} 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 ^{(talk • contribs)} 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

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)

CSS

This sheet has been tested in Chrome (78.0.3904.108), Firefox (71.0), IE (11.535.18392.0) and Edge (44.18362.449.0). It should also work in most versions of Safari (though I can't test this), it works with iOS Safari (13.0) - this shows as using the same CSS selector as Safari on Mac. A live example is set up on the Dev wiki.

/* Gallery alterations - for mode=packed */
/* changes for all browsers */
ul.mw-gallery-packed img { height:200px !important; width:auto !important; }
ul.mw-gallery-packed>li.gallerybox { text-align: center !important; }

/* changes to browsers supporting min-content (this is the basis of text wrapping) */
@supports (-webkit-font-smoothing:antialiased) { ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox>div { width:min-content !important; } }
_:-moz-handler-crashed, :root ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox>div { width:min-content !important; }
@supports (-moz-appearance:none) and (list-style-type:disclosure-open) { ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox>div { width:min-content !important; } }

/* changes to browsers no supporting min-content (text under images will never wrap) */
_:-ms-lang(x), _:-webkit-full-screen, ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox>div { width:auto !important; }
_:-ms-lang(x), _:-webkit-full-screen, ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox div.thumb  { margin:auto !important; }
_:-ms-lang(x), _:-webkit-full-screen, div.gallerytext { max-width: 355px ; margin: auto; } 

@media screen and (min-width:0\0) and (min-resolution:+72dpi), \0screen\,screen\9 { ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox>div { width:auto !important; } }
@media screen and (min-width:0\0) and (min-resolution:+72dpi), \0screen\,screen\9 { ul.mw-gallery-packed>li.gallerybox, ul.mw-gallery-packed>li.gallerybox div.thumb { margin:auto !important; } }
@media screen and (min-width:0\0) and (min-resolution:+72dpi), \0screen\,screen\9 { div.gallerytext { max-width: 355px ; margin: auto; } } 
/* End of: Gallery alterations - for mode=packed */

The sheet above provides the functionality as above for <gallery mode=packed>, it is browser targeted, as Edge/IE don't support the function width=min-content.

The current copy is at the top of here.

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:

CSS

:Example 1:

ul.mw-gallery-packed>li.gallerybox { text-align: center !important; }

Example 2:

ul.gallery.mw-gallery-packed { background-color: transparent !important; border: 0px solid transparent !important; }
ul.mw-gallery-packed>li.gallerybox { text-align: center !important; }

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

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 {
    background-color:#FDF5E6;
    border:1px solid lightgrey;
    padding:4px;
    display:inline-block;
}

ul.gallery.mw-gallery-packed {
    background-color:#FDF5E6;
    border:1px solid lightgrey;
    display:inline-block;
    text-align:left;
}

--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 { 
    text-align:center;
}

ul.gallery.mw-gallery-packed {
    text-align:left;
}

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

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

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 7^th, 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

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)

Update

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

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.

Conclusion:

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

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

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: Solstheim^DB, Myrwatch^CC, Alinor 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 Alinor I think would be fine, but the current approach (which is something like Anvil) 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.

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

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

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

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:

• Give Skyrim:Switch a {{Mod Header}} using
• Create a template similar to {{ESO SS}}: {{Nintendo Switch}}
• Change Skyrim:Master Sword from a redirect to a proper Unique Weapon, which will use the Mod Header icon like the other dlc/cc
• Add the Champion's Tunic and Hylian Shield to Skyrim:Specialty Gear using {{Nintendo Switch}}
• Change Skyrim:Powers#amiibo to use {{Nintendo Switch}}
• Add a note to Skyrim:Unobtainable_Items#Torturer's_Hood that it can be obtained and equipped in the Switch release

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 () for Switch-specific notes, similar to how we use {{Pc22}} () 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

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

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

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

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 144.217.80.80 (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

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

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

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

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}}.

• Traditional
• 
• 

• Packed
• 
• 

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

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)

Examples:

mode=packed heights=200px (current)

• 

  Imperial Guard in Stros M'kai

• 

  Imperial Guard

• 

  Imperial Legion Rider

• 

  Imperial Watch Captain

• 

  General Tullius

• 

  Legion Fort Commander

• 

  Dunmer Legate circa 4E 201

• 

  Legion Captain

• 

  Prefect Calo

• 

  Deathshead Legion barracks, Gnisis

• 

  Castle Dour, headquarters of the Legion in Skyrim circa 4E 201

• 

  Imperial Recruiter

• 

  Imperial siege engine

• 

  Imperial Guard Centurions

• 

  Second Legion soldiers

• 

  Imperial army marching from the Imperial City

• 

  Legionnaires preparing to capture Windhelm

• 

  One of the many variants of legion armor

• 

  Cyrodilic Empire Imperial Warhorse, used by the Imperial Legion Cavalry

• 

  An Imperial War Mastiff, used commonly by the Second Legion

• 

  Morrowind concept art

mode=nolines widths=200px

• 

  Imperial Guard in Stros M'kai

• 

  Imperial Guard

• 

  Imperial Legion Rider

• 

  Imperial Watch Captain

• 

  General Tullius

• 

  Legion Fort Commander

• 

  Dunmer Legate circa 4E 201

• 

  Legion Captain

• 

  Prefect Calo

• 

  Deathshead Legion barracks, Gnisis

• 

  Castle Dour, headquarters of the Legion in Skyrim circa 4E 201

• 

  Imperial Recruiter

• 

  Imperial siege engine

• 

  Imperial Guard Centurions

• 

  Second Legion soldiers

• 

  Imperial army marching from the Imperial City

• 

  Legionnaires preparing to capture Windhelm

• 

  One of the many variants of legion armor

• 

  Cyrodilic Empire Imperial Warhorse, used by the Imperial Legion Cavalry

• 

  An Imperial War Mastiff, used commonly by the Second Legion

• 

  Morrowind concept art

mode=packed heights=180px

• 

  Imperial Guard in Stros M'kai

• 

  Imperial Guard

• 

  Imperial Legion Rider

• 

  Imperial Watch Captain

• 

  General Tullius

• 

  Legion Fort Commander

• 

  Dunmer Legate circa 4E 201

• 

  Legion Captain

• 

  Prefect Calo

• 

  Deathshead Legion barracks, Gnisis

• 

  Castle Dour, headquarters of the Legion in Skyrim circa 4E 201

• 

  Imperial Recruiter

• 

  Imperial siege engine

• 

  Imperial Guard Centurions

• 

  Second Legion soldiers

• 

  Imperial army marching from the Imperial City

• 

  Legionnaires preparing to capture Windhelm

• 

  One of the many variants of legion armor

• 

  Cyrodilic Empire Imperial Warhorse, used by the Imperial Legion Cavalry

• 

  An Imperial War Mastiff, used commonly by the Second Legion

• 

  Morrowind concept art

mode=packed heights=150px

• 

  Imperial Guard in Stros M'kai

• 

  Imperial Guard

• 

  Imperial Legion Rider

• 

  Imperial Watch Captain

• 

  General Tullius

• 

  Legion Fort Commander

• 

  Dunmer Legate circa 4E 201

• 

  Legion Captain

• 

  Prefect Calo

• 

  Deathshead Legion barracks, Gnisis

• 

  Castle Dour, headquarters of the Legion in Skyrim circa 4E 201

• 

  Imperial Recruiter

• 

  Imperial siege engine

• 

  Imperial Guard Centurions

• 

  Second Legion soldiers

• 

  Imperial army marching from the Imperial City

• 

  Legionnaires preparing to capture Windhelm

• 

  One of the many variants of legion armor

• 

  Cyrodilic Empire Imperial Warhorse, used by the Imperial Legion Cavalry

• 

  An Imperial War Mastiff, used commonly by the Second Legion

• 

  Morrowind concept art

mode=traditional widths=200px (original)

• 

  Imperial Guard in Stros M'kai

• 

  Imperial Guard

• 

  Imperial Legion Rider

• 

  Imperial Watch Captain

• 

  General Tullius

• 

  Legion Fort Commander

• 

  Dunmer Legate circa 4E 201

• 

  Legion Captain

• 

  Prefect Calo

• 

  Deathshead Legion barracks, Gnisis

• 

  Castle Dour, headquarters of the Legion in Skyrim circa 4E 201

• 

  Imperial Recruiter

• 

  Imperial siege engine

• 

  Imperial Guard Centurions

• 

  Second Legion soldiers

• 

  Imperial army marching from the Imperial City

• 

  Legionnaires preparing to capture Windhelm

• 

  One of the many variants of legion armor

• 

  Cyrodilic Empire Imperial Warhorse, used by the Imperial Legion Cavalry

• 

  An Imperial War Mastiff, used commonly by the Second Legion

• 

  Morrowind concept art

--Enodoc (talk) 16:07, 14 July 2020 (UTC)

Graph Extension now available for use

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

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}} →  +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

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

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

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 (talk • contribs) 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

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

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

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

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.

• TESCOSI can be found at Oblivion Mod:TESCOSI.
• MMW content is at Morrowind Mod:Morrowind Modding Wiki.
• Better Cities is at Tes4Mod:Better Cities/Main Page.
• Order of the Dragon can be found at Oblivion Mod:Order of the Dragon.
• Oscuro's is at Oblivion Mod:Oscuro's Oblivion Overhaul.
• The Quest Lists are at Morrowind Mod:The Morrowind Quest List, Oblivion Mod:The Oblivion Quest List and Skyrim Mod:The Skyrim Quest List.
• The Oblivion Quest Mod wiki is at Oblivion Mod:Oblivion Quest Mod Wiki.

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

Main page layout - Part 1 - The logo

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.

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.

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)

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

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
ESOMod	ESO Mod
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)
ESOMod	ESO Mod
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)

(←) 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/
ESOMod	ESO Mod
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)

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

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:

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

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 (talk • contribs) 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

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 (talk • contribs) 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)

Prev: Archive 55

Up: Community Portal

Next: Archive 57