UESPWiki:Community Portal

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

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

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

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

Other pages for community-wide or general questions include:

Specific requests can be made on these pages:

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

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

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

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

Location Date started Topic Listed here by

Namespace for Call to Arms/etc?[edit]

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

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

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

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

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

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

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

Change Gallery Default Size[edit]

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

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

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

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

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

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

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

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

Edit Break: Gallery Modes and Style[edit]

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

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

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

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

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

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

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

Flora Images[edit]

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

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

Dragonborn/Skyrim Namespace Merge[edit]

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

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

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

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

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

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

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

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

Bot Run[edit]

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

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

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

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


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

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

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

Large Gifs[edit]

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

Initial Design:

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

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

The Problems:

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

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


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

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

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

Duplicate Icons[edit]

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

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

Marking DLC/add-ons[edit]

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

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

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

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

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

Mod File Format Tables[edit]

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

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

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

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