UESPWiki:Community Portal

The UESPWiki – Your source for The Elder Scrolls since 1995
UESPWiki(Redirected from UESPWiki:CP)
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 {
    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[edit]

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

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

Dragonborn/Skyrim Namespace Merge[edit]

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

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

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

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

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

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

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

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

Bot Run[edit]

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

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

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

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

Update[edit]

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

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

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

Large Gifs[edit]

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

Initial Design:

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

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

The Problems:

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

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

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[edit]

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

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

Marking DLC/add-ons[edit]

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

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

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

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

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

Mod File Format Tables[edit]

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

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

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

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

New Namespace for Official Products[edit]

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

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

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

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

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

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

Skyrim Switch Integration[edit]

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

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

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

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

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

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

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

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

NPC Dialogue[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ESO DLC[edit]

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

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

Tor exit nodes banned[edit]

Yesterday I tried to edit a page but found that all tor exit nodes had been blocked. I appreciate your efforts in keeping this wiki free of vandalism, but blocking all exit nodes also affect legitimate tor users. Would you be willing to try some captcha instead? — Unsigned comment by 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[edit]

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

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

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

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

Category:Online-Pre release Images Cleanup[edit]

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

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

Page Title vs. Search Engine Optimization[edit]

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

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

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

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

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

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

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

Gallery Mode and Image Ratio[edit]

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

ON-place-Karthwatch.jpg

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

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

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

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

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

Edit Break[edit]

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

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

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

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

Graph Extension now available for use[edit]

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

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

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

Effect Syntax Conventions[edit]

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

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

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

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

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

I'm all for standardization and consistency. I think the clearest option should be used, which means just writing the full <magnitude> and <duration>. We don't have to type it out every time anyway, as the templates will still just call the parameters "m" or "d". --Ilaro (talk) 13:43, 15 July 2020 (UTC)