UESPWiki:Community Portal/Archive 34

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

FormID Case Consistency

Do we, or should we have some consistent standard for the formatting of FormIDs? They're hex values, and thus may contain the letters A-F. We've been somewhat inconsistent with the case of these letters. On most Oblivion pages, the letters appear as capitals, while on most Skyrim pages, they are lower-case. And there are exceptions in both namespaces. I feel like we should choose one or the other and stick with it. Also, the "xx" that appears before FormIDs from mods is sometimes listed as "0x", which is the prefix for hex numbers in C-like programming languages, but really has no meaning in terms of the games. Typing "0x" before a FormID when entering console commands will not work, so we shouldn't be implying that it will. (It might be worth finding some way to make it clear what those x's really mean - so we don't get edits from people saying "Hey, I know the real ID for these items!" and replacing them with the IDs from their game, which being dependent on mod load-order are likely to be wrong for other users. It's happened numerous times.) I'd nominate a bot for the job of making them consistent - shouldn't be too hard to distinguish FormIDs from other content, given that they're usually contained within {{ID|}} tags, and are clearly 8-digit numbers in hex, always starting with "00", "xx", or the aforementioned incorrect "0x". Just need to determine which is better. The games aren't case-sensitive, so it doesn't really matter. Just would be nice to be consistent. TheRealLurlock (talk) 04:29, 20 October 2012 (GMT)

From what I've seen on the Skyrim namespace, the NPC and Place Summary templates tend to use capital letters while the item pages are the ones which are more inconsistent. Also, Alfwyn recently created the Skyrim:Form ID page which does explain the 'xx' in those codes. That's what's been linked to in all the related tables now, and that's what I use to explain when reverting those types of changes. — ABCface^◥ 04:33, 20 October 2012 (GMT)

Since I've mostly been editing item pages, I guess that's why I've seen it so much. In that case, I'd suggest going all-caps, because it only means changing a small number of item pages, rather than going lower-case, which would require changing hundreds of NPC and place pages. Also, with the small font it can be hard to distinguish a and e - a problem I ran into numerous times making all those icons. TheRealLurlock (talk) 12:50, 20 October 2012 (GMT)

I've started to remove "0x" on sight, it isn't encountered that often anyway. As for the case, mainly NPC/creature and book pages use uppercase, other content usually added by hand uses mainly lowercase, but there are of course exceptions. Personally I'd prefer lowercase form IDs, I find them easier to read, and they can just be copy-pasted from CSList. It isn't just a small number of item pages using lower-case IDs ([1] [2] [3]). When changing the IDs with a bot, the number of pages doesn't matter that much, but more how easily the set of pages is identified. Anyway, it would be good to hear more opinions before making the change in one direction or the other. --Alfwyn (talk) 13:04, 22 October 2012 (GMT)

I prefer lower case as well, as that's how the game displays IDs in the console when you click on an object. --Xyzzy ^Talk 13:49, 22 October 2012 (GMT)

Although I looove decapitalising a lot of things—I'm like the unofficial Queen of Decaps on this wiki xD—I prefer the IDs to be capitalised. To me, it simply looks way better, and TRL brought up a valid point too: it improves readability. However, I understand that game data presents these IDs in lowercase, but the "copy-pasting argument" is not really strong IMO; we shouldn't be lazy to capitalise a few letters. ~ Psylocke 14:02, 22 October 2012 (GMT)

(edit conflict) Since I play on Xbox, the IDs don't mean a whole lot to me outside of patrolling and making sure they're correct. But, if we are giving opinions on what we prefer, I actually find lowercase easier to read-- it's easier to distinguish letters from numbers faster. And of course it's faster to copy/paste from CSList when the need arises. I wouldn't be opposed to uppercase, but I do prefer lowercase. — ABCface^◥ 14:06, 22 October 2012 (GMT)

Distinguishing letters from numbers isn't really needed though. Since the letters ABCDEF don't look anything like numbers the 0123456789, there's not much chance of confusion. (I'd understand if there were I's or O's involved, but hex doesn't go past F.) The problem is that at small fonts, a and e are nearly indistinguishable, and c isn't great either. Either will work in the console, so it's just a matter of making them easily readable on the site, which capitals do much better. TheRealLurlock (talk) 13:14, 23 October 2012 (GMT)

Weird, because for me, 00012b8e is more easily readable than 00012B8E. For me, a and e are distinguishable; however, B and 8 are nearly impossible to distinguish (B8). I know I've mixed up the two many times, and that's just when I'm editing the wiki. As Alphabetface said, lowercase letters at least tell you which are numbers and which are letters, so you don't mistype the ID and then wonder why it isn't working. • JA^T 14:32, 23 October 2012 (GMT)

(←) Like Jak, I find B and 8 hard to distinguish (B8), and I also find D and 0 at that size hard when they're mixed in (0D). It's not a major issue, but I do find the lowercase IDs easier for this reason. — ABCface^◥ 15:51, 23 October 2012 (GMT)

I don't have any terribly strong feelings on the matter other than it should be consistent across all pages and namespaces if possible. About all I'll add to this discussion is that it's fairly trivial for the bot to change all those that are in actual {{ID}} tags without converting things that it shouldn't. The ones that are in templates could also be converted if desired, but rather than update a stupidly large number of pages, we may want to just convert those in the template itself (e.g., {{uc/lc:{{{ID}}}}}), which would also inherently correct any future mis-cased entries. – Robin Hood↝talk 22:52, 24 October 2012 (GMT)

Careful - There are cases where the {{ID}} template is used for things other than FormIDs, just as a quick and easy way of making things smaller fonts. (One frequent example is on Morrowind pages, where the item IDs are used, since there were no FormIDs in that game.) So don't just go converting everything using the template to upper- or lower- case. One thing that I thought made sense was on the page recently linked on your talk page: here. Wikipedia apparently agrees with me on using capitals for hex values. Although they're also using a font which has descending numerals, which I think is also a very good idea - it immediately makes hex numbers much easier to read, eliminating both the a/e problem I was having and the B/8 and D/0 issues others mentioned. I don't know what fancy .css is necessary to get those fancy book-style numbers, but I think it would aid a good deal in readability. TheRealLurlock (talk) 03:36, 25 October 2012 (GMT)

Way ahead of you. It'll need testing, but I've got the concept for the Regular Expression in my head, basically just looking for appropriate sequences of numbers and letters. I also grabbed the entire list of the template's parameters earlier, so it's easy to see how it's being used and make sure I'm not capturing anything I shouldn't be. There may be a few that it'll be easier to change by-hand rather than program for, but the bot should be able to do the bulk of them without any problems. As far as the fancy CSS, the template's set up in such a way that we could easily make the change either to the template itself or to MediaWiki:Common.css, so that shouldn't be a problem. The only thing I'm not sure is if that font is a custom font (like our dragon font) or a standard one, but I can look more into that if we decide that's the route we want to go. – Robin Hood↝talk 04:44, 25 October 2012 (GMT)

Pretty sure it's a standard font - unlike us, Wikipedia isn't likely to depend on its users downloading custom fonts. The one they're using is called "Georgia", though at a quick glance through my own font list (mostly the Windows 7 standards, can't speak for Mac or Linux), I see a few others with strong descenders - just not sure which are most common (many of the ones with descenders seem to be fonts designed for Hebrew or Arabic, oddly). I think Georgia is pretty standard though. Can everyone see this: 0123456789ABCDEF? TheRealLurlock (talk) 11:57, 25 October 2012 (GMT)

Yup, that looks fine to me, though I'm also a Windows user (Windows 8 as of an hour ago), so that's not much of a surprise. For anybody wanting to get an idea of what the IDs would look like if we changed the font face, simply add the following line to your common.css or monobook.css page.

.idref { font-family:Georgia; }

Looking at it as is, I'm thinking we might want to apply the font but leave the font size as normal in some of the templates, but for the ones that're underneath item names, that size should be fine. – Robin Hood↝talk 17:29, 25 October 2012 (GMT)

I like it, but I'll wait and see what others think about it. This font face definitely looks better with all-caps though. I find that the lower-case 'b' can now be potentially misread as a '6'. They're easily distinguishable if you see them side-by-side, but seeing a 'b' by itself could cause confusion. The capital 'B' is sufficiently different from '8' that I don't see a problem with that. And the 'D' and '0' are now completely distinct, so that problem is gone. TheRealLurlock (talk) 02:19, 26 October 2012 (GMT)

(←) I checked it out earlier and I like it as well. It definitely resolves the problem I had with distinguishing the numbers from letters in an ID quickly. I also agree with TRL that using uppercase letters in the IDs would be better if we decide to use this font for numbers in the IDs-- it looks far better. I do have a question though. The example that RH set up by adding that code to the css page only affected IDs which actually use the ID template, as far as I could tell. If we were to apply this site-wide, would it be implemented for IDs in the other places where IDs are listed as well? (I'm thinking of the IDs in the {{NPC Summary}} and {{Effects Summary}} templates in particular, though I'm sure there are other applicable templates and pages too.) I know this was just an example, so that's why I'm looking for some clarification. — ABCface^◥ 03:12, 26 October 2012 (GMT)

Right now, things like the NPC Summary are actually using their own method of generating the ID that doesn't match with the ID template itself. My suggestion would be that we make the necessary CSS changes to MediaWiki:Common.css (the above line and maybe the font-size currently in the template depending if they're all small or not), which would make it possible to have a universal format for IDs without having to actually call the ID template unnecessarily. At that point, any templates that have IDs on them could be altered to use <span class="idref">ID</span> (ID) rather than whatever they're currently using. – Robin Hood↝talk 04:21, 26 October 2012 (GMT)

Okay, that makes sense. Also, we'll need to keep in mind that some pages don't currently use any template at all, such as Skyrim:Generic Magic Apparel, which uses manually formatted tables. I can't think of any other pages off-hand, but I'm sure they're out there. — ABCface^◥ 04:29, 26 October 2012 (GMT)

Actually, that page confirms what I thought but hadn't gotten around to confirming yet: some IDs are full-size while others are small. I'd suggest that we have two classes in the CSS file then, one for each. That way, if we dislike the size or something, one quick change gets everything universally (at least once we apply the ID template or CSS style to everything). – Robin Hood↝talk 05:12, 26 October 2012 (GMT)

Moving the icons from their own column to below the name is something I've been doing in the process of adding icons to item pages. I'm not sure if we want to do that in this case, since it would make those tables much larger vertically. I do feel like it would be nice to have consistency regarding ID formatting. Another place that still uses full-sized IDs are the NPC pages for Oblivion and Skyrim. (Morrowind uses smaller text, but then they're not hex-values) TheRealLurlock (talk) 11:56, 26 October 2012 (GMT)

(←) I still find lower case form IDs much easier too read than upper case ones. Maybe if "a" and "e" are hard to distinguish (not for me), we could do something about that. I see that IDs are currently changed silently [1] to uppercase - is it considered concensus now? --Alfwyn (talk) 12:47, 29 October 2012 (GMT)

I noticed that as well and wondered about the change- it seemed odd considering this is currently being discussed. I think using the Georgia font for numbers is a great way to go, and uppercase is fine if we do so. But if we don't change to that font for numbers, then I don't think we should start changing anything until we establish some sort of consensus. I still prefer lowercase if the numbers are the same font as the letters. — ABCface^◥ 14:47, 29 October 2012 (GMT)

It seemed like there was agreement, though I guess it is contingent on changing the font for IDs. I'll stop changing them for now, and leave that work for the bots if we do decide to change them. But that font does make a huge difference. Georgia with all-caps is far superior to our default font either with lower- or upper-case. My order of preference goes: default lower-case, Georgia lower-case, default all-caps, <huge gap>, Georgia all-caps. There are other fonts with descending letters I like even better, but they're less likely to be on every computer, whereas Georgia is pretty much standard. (Notably it's the only one that's included by default on both Windows and Mac OS.[2]) TheRealLurlock (talk) 01:19, 31 October 2012 (GMT)

Subsequent to Jak's reverted post, I had a look at the ID template, and I think I've come up with a solution that should work in all cases. It looks for anything within the {{ID}} text that looks like a Form ID and puts it in Georgian and in all caps, except for leading xx's (see Skyrim:Spells, for example). Please let me know if you spot any incorrect conversions and I'll figure out if the current solution can be changed to work around it, or if we need to go with another approach.

And, like Jak before me, I too have now discovered an issue with the template: the function I was using is limited to 10 uses per page by default; every other ID template on the page simply vanished altogether! For now, I've reverted the template changes. I'll do some more investigation tomorrow and see if this is a setting we want to change or if it would hit the servers too hard and we need to come up with some other plan. If the latter, I'm thinking of introducing a new template altogether: one for small text and one for actual, honest-to-goodness Form IDs. – Robin Hood↝talk 07:48, 9 December 2012 (GMT)

Hm, it did behave weird, in that it did convert to uppercase the xx too on Skyrim:Keys, but did not uppercase anything at all on Skyrim:Armor. --Alfwyn (talk) 16:42, 9 December 2012 (GMT)

FormID Case Consistency Edit Break 1

(←) The more I think about it, the more I think we're better off creating a new template and having that template strictly do the font changes, not the upper-casing. The bot can easily convert existing IDs to the new template, or add it into the existing text if it's not a straight change, and it can convert to upper-case as it goes. After that, it's a relatively simple matter of editors remembering to use upper-case, or fixing it if they find one that's not (and there again, the bot could easily do an on-demand case-verification scan like it does for unprotected pages and the namespace templates). It's a lot less work on the servers than trying to parse text from within a template. – Robin Hood↝talk 20:57, 9 December 2012 (GMT)

Do we really need a new template, if we change only the font for it? I guess displaying other IDs like editor IDs in Georgia would do. --Alfwyn (talk) 11:42, 10 December 2012 (GMT)

The only problem I see is where we use the ID template for things that are not IDs. While it was intended just to be used for IDs, I've seen a lot of cases where it was used just because somebody wanted small text, like for a footnote under a table or something. Also, for Morrowind pages, the ID is not a hex-value but actual words, I'm not sure if it matters there, but we should keep that in mind. (Don't think we have IDs at all for Arena or Daggerfall or the smaller games.) TheRealLurlock (talk) 13:05, 10 December 2012 (GMT)

Yeah, as TRL said, the ID template is used for small text all over the place. It's probably because we tell people to do this in our Quick Editing Guide which we link to in our standard welcome message for new users. I wouldn't be opposed to a new template for formIDs. — ABCface^◥ 22:59, 10 December 2012 (GMT)

That was the reasoning behind the suggestion for me as well. – Robin Hood↝talk 23:07, 10 December 2012 (GMT)

Can we come up with another good and short name? I would find it just a bit confusing to use a template ID for general small text and another one for actual IDs. So maybe change the template for the other uses instead of the ID uses. Wikipedia has Template:small for generall small text. But I frankly have no idea how common those other uses are compared to actual ID uses. --Alfwyn (talk) 23:18, 10 December 2012 (GMT)

Well, {{small|Some Text}} is not all that much less typing than <small>Some Text</small>, especially when you consider that the <small></small> tags can be added with a single mouse-click, since I added them to the Wiki markup template last week. (This exact issue was part of my motivation for doing so, although I was also adding a few others by request.) I could see using "ST" for "Small Text" or something, though that's still 7 characters you'd have to type, as opposed to 1 mouse-click. I'm just not sure how many people actually use those Wiki markup features to be honest. TheRealLurlock (talk) 02:06, 11 December 2012 (GMT)

(←) In the long term, the two advantages I can see to having a {{small}} template are that the size could be made a fixed percentage of the original size—where I believe both <small> and CSS font-sizing are browser-dependent—and the size/style of that text could be controlled independently of having a CSS small entry. Unless someone can think of something I'm not, those are exceedingly minor advantages, and probably not worth creating a template for in their own right. In the short term, however, it might make sense to create a template for the simple reason that if we're going to do any global replacements, once we replace things with a <small> tag, it becomes significantly more difficult to track down anything we may have incorrectly replaced. We'd want to be 100% sure, therefore, of what we want to do with potentially special cases like the Morrowind IDs. – Robin Hood↝talk 20:08, 13 December 2012 (GMT)

I was bored and came up with a template that would automatically format any FormIDs. It looks like this:

{{User:Jak Atackka/Sandbox8|Possible IDs: (001200ab) (001200ac) (001234ad) (001234ae) (001234af) (001234b0) (001234b1) (000034b2) (xx00123a) (xx00123b)}}

{{User:Jak Atackka/Sandbox8|Possible IDs: (001200ab) (001200ac) (001234ad) (001234ae) (001234af) (001234b0) (001234b1) (000034b2) (xx00123a) (xx00123b)}}

Unfortunately, this doesn't work with the {{hover}} template, and won't without a substantial amount of work. The template itself is insanely complicated as it is. Unless we plan to extend the abilities of {{#rreplace}} to allow it to be used more than ten times per page, then I agree that we'll have to create separate templates. Once the templates are set up, we should task HotnBOThered to replace these automatically. • JA^T 22:34, 14 December 2012 (GMT)

I think we're probably better off just using a simple template like <span class="idref">{{{1|}}}</span> rather than going with something more complex. The bot can figure out what's a Form ID and upper-case them correctly, then it's just a matter of keeping them that way, which shouldn't be all that difficult. Even if we want to have the template be a little more complex to deal with capitalizing things correctly itself, it makes sense to me to have one template call per ID rather than having the template itself try to handle multiples. As a general rule, the less parsing a template does, the better. – Robin Hood↝talk 00:00, 15 December 2012 (GMT)

Dragonborn Namespace

Just wanted to make sure we're working on implementing a new namespace for the Dragonborn expansion. The trailer confirms that it will be an expansion, just like Bloodmoon before it, so we should have a new namespace for consistency. Relevant past discussions I could find are here and here.

Also, I wanted to suggest we simplify the sidebar in the same way as Oblivion. That is, have a link to the "DB" namespace under Skyrim, then link to Skyrim:Official Plug-ins instead of listing Dawnguard and Hearthfire separately. Minor Edits^{Threats•Evidence} 19:06, 5 November 2012 (GMT)

When we have more information and can absolutely confirm a new namespace is warranted, yes, I'm sure everything could be put into place quite quickly :). ⇠eshe^talk 19:09, 5 November 2012 (GMT)

Well, I think we're already there; we know it will added a significant, separate landmass just like SI, TR, and BM. It would make no sense to deny a DB namespace. Precedent for the Shivering Isles does suggest that we should wait until the actual expansion is released, but it seems abundantly clear it will be warranted come Dec. 4.

Anyways, while I'm at it, can we hold off on various "featured in" notes related to Dragonborn, such as the one currently found on Lore:Solstheim? If we're creating a new namespace, we'll just have to fix those links anyways. Also, the proper format consistent with other pages would be to say that "Solstheim was featured in" blah blah blah, and it doesn't feel right to speak about an expansion in the past tense before it is even released. And as I said in the edit summary here, I think it's best we keep this stuff off the lore pages, at the very least, until the expansion is released. Minor Edits^{Threats•Evidence} 19:20, 5 November 2012 (GMT)

I agree about the Lore stuff, for sure, but I personally think we need to know a bit more about the size of the landmass that's being added before we're 100% sure we need a namespace for it (I mean, it seems likely we will, but still). The only other thing I would add is that I think DR might make a better abbreviation than DB—I think "DB" is "Dark Brotherhood" for most people, and that would just get confusing :P. ⇠eshe^talk 19:25, 5 November 2012 (GMT)

Concerning the subscript which will be needed in any case, our options are, DR, DA, DG, DO, DN, and DB. {{DR}} is taken for Deletion Review, and {{DG}} is Dawnguard. DB is shorthand for Dark Brotherhood and has been for ages, and would only serve to confuse people if used. This leaves us with a choice between DA, DO, and DN, none of which appeal to me, but, if forced, then I'd plump for DN. Silence is Golden^{Break the Silence} 19:32, 5 November 2012 (GMT)

We could also change the usage of DR for Deletion Review, since it's so rarely used anyway. ⇠eshe^talk 19:34, 5 November 2012 (GMT)

I will fight to the death for DB! I mean, we named Bloodmoon "BM". BM, for god's sake. We could've gone with BL or BN, but we decided to give it the same initials as "bowel movement" (much to the delight, I'm sure, of that expansion's critics). I say we stick to our guns at this point, and DB is the most logical abbreviation. And, I say this with complete and utter sincerity, the Brotherhood can [censored] and [censored] until their mothers [censored] all over their [censored]. They don't have a incontestable claim on DB. I'm sure most people are going to have to adapt to the idea of DB standing for Dragonborn on forums and what-not anyways, because the great masses out there who are going to want to abbreviate "Dragonborn" don't have a standard-setting Community Portal to guide them. I suspect they'll flock to using DB, and so should we. Then again, maybe there will be some indirect guidance from Bethesda in the game files. Maybe there already is in patch 1.8? Minor Edits^{Threats•Evidence} 19:50, 5 November 2012 (GMT)

(←) (edit conflict) I would side with DB. Aside from IRC short hand, I haven't seen DB in much use for the Dark Brotherhood, so I would only see the 10 regular editors having to get used to the change, which is NBD. ES^{(talk•email)} 19:54, 5 November 2012 (GMT)

On the lore notes: the lore guidelines were actually modified to allow these kind of notes prior to Dawnguard's release per a discussion on the CP. Not sure we should be going back on that policy. —Legoless (talk) 20:19, 5 November 2012 (GMT)

BOO! But I've made my bed, now I have to spend a drunken stupor in it. Minor Edits^{Threats•Evidence} 20:30, 5 November 2012 (GMT)

Personally, I'm not a fan of DB based on Dark Brotherhood usage, but it follows what we've done for everything else that's got two "words" in it (Blood Moon, Dawn Guard, Dagger Fall, Dawn Star, Red Guard, Shadow Key, etcetcetc), so I fully support it. It would be completely consistent with what we've done so far. Vely^►t►e 20:43, 5 November 2012 (GMT)

I too support using DB. In my mind, an official expansion takes precedence over an arbitrary acronym used to more conveniently refer to the Dark Brotherhood.

Also, to add to Vely's list of abbreviations that follow site conventions, there's Battle Spire, Storm Hold, Shivering Isles, Hearth Fire (we use HF as a superscript), and even Morro Wind and Sky Rim. Although I understand the concern, site conventions make just as much sense, and we might as well follow them. • JA^T 20:58, 5 November 2012 (GMT)

One more vote for DB, just because it will likely be used outside of UESP in the larger ES community. (Although I wouldn't necessarily recommend using clues from the game files. If we did that, Shivering Isles would be using "SE".) As it is, only three of our abbreviations have ever followed any other convention than splitting the two-part names. AR for Arena, TR for Tribunal, and OB for Oblivion, and only because there's no good way to split those. (AN? TB? TN? OL? OV? None of those really work.) Also notable that Arena and Oblivion both begin with a vowel, so that second letter really is the beginning of the next syllable, so it works. (Boy, you'd think we were IUPAC and somebody just discovered a new element or something.) TheRealLurlock (talk) 03:02, 6 November 2012 (GMT)

I vote DB for Dragonborn. Anything else is simply over-thinking it. Choose DB and accommodate everything else around that decision. CapnZapp (talk) 09:32, 6 November 2012 (GMT)

(←) As for the sidebar change mentioned in the first post, I don't think Dawnguard should be handled differently from Dragonborn. Dawnguard was a big expansion, there is no reason to believe Dragonborn will be bigger. In my opinion the decision about the namespace should be based on how closely it integrates to existing content (will we have several new quests involving old locations, will several new map-markers added to the old map, will several old NPCs be modified, ...). The decision about the sidebar should be based on importance, not some technicality whether we use a separate namespace. --Alfwyn (talk) 13:34, 6 November 2012 (GMT)

I can see the issue with listing Dragonborn, Dawnguard, and Hearthfire (or Official Plugins) on the sidebar, because Oblivion and Morrowind both have only two subsections, and it would look weird for Skyrim to have 3. I use my own collapsible sidebar, so it doesn't affect me either way, but if I were an anonymous user, I would say to hell with the balance, just list Dragonborn, Dawnguard, and Official Plugins on the sidebar. People are still coming here for Dawnguard information, and it's still the largest DLC released as of yet, so it still deserves its own spot on the sidebar. Hearthfire, on the other hand, is definitely small enough to be merged with "Official Plugins". Alfwyn is right, even if Dragonborn is being called an "expansion", it may not be significantly bigger than Dawnguard. Of course, we won't know this until it is released. Right now, I only tentatively support Dragonborn receiving its own namespace, but I'll feel more strongly on the issue when Bethesda releases another video that gives us a better idea of what to expect.

On a side note, we should consider renaming "Official Plugins". Concerns have been expressed that the name is potentially confusing, and something more obvious (like Official DLC) might help the users of our site navigate more easily. • JA^T 16:27, 6 November 2012 (GMT)

Just on the namespace thing, if hearthfire has its own namespace then surely DragonBorn should have one too. I mean, hearthfire basically just adds 3 houses and a few ingredients! DragonBorn adds a new area (surely bigger than the areas added for Dawnguard), new enemies, weapons, armour, spears and possibly dragon mounts. It may be too early to say it is the biggest DLC so far but it it probably going to be at least twice the size of Hearthfire or Dawnguard. RIM (talk) 16:44, 6 November 2012 (GMT)

What's the difference in the name, Jak? You'd need a terrible grasp of English, and a lack of common sense, IMO, to not make the connection. Besides, every page has been named "Official Plugins" for ages, and I did a scan of the site, and I can find no instance of anyone complaining or bringing up some kind of confusion over it, aside from your proposals to rename them all. ES^{(talk•email)} 17:16, 6 November 2012 (GMT)

"Plug-ins" sounds like an outdated term, in my opinion. "DLC" and "add-ons" seem to be what Bethesda have taken to calling them. I'd agree with changing the Skyrim page name, but Oblivion and Morrowind seem alright as is. —Legoless (talk) 17:28, 6 November 2012 (GMT)

Why just one, though? For consistency's sake, shouldn't it be all or none? ES^{(talk•email)} 17:33, 6 November 2012 (GMT)

(←) Because Beth consistently refers to MW and OB stuff as plug-ins, but to Skyrim stuff as DLC. Using the most common term for each will avoid the few cases of confusion that would pop up. Some may not instantly make the connection, especially if they started playing with SR. Vely^►t►e 17:40, 6 November 2012 (GMT)

It could be argued that Oblivion's page would be more correctly named "DLC", but the free Morrowind downloads have always been called plug-ins and I suspect that that's where the standard came from. —Legoless (talk) 17:47, 6 November 2012 (GMT)

(edit conflict × 4) RIM: Hearthfire doesn't have its own namespace. We aren't that hopeless ;). We did consider giving Dawnguard its own namespace, but we decided against that, and in hindsight, we made the right decision.

Snowmane: Jeez, that was pretty aggressive, and was phrased very much like a personal attack. Yes, every page thus far has used the phrase "Official Plugins". However, the whole point of community discussions is to create, remove, and change existing policies. This isn't even a policy - it's just a pattern that we've always used. We can change it if we decide it's for the best - that's what makes the wiki a wiki. Besides, the page could be moved and a redirect easily left there, so logistically it isn't a problem. As for people bringing up concerns about it, Vely explicitly stated that the term "Official Plugins" can be misleading during our previous discussion on the subject. And by the looks of it, we aren't the only ones.

I really only brought up changing the name as a passing thought, because we're already discussing changes to the sidebar, and this particular proposal was lost in the sea of arguing in our previous discussion. If the wiki decides to keep the name Official Plugins, that's okay. I just wanted to bring it up and have people think about it. • JA^T 17:52, 6 November 2012 (GMT)

I suppose it's probably meant for a separate topic, but "Official DLC" (or "Official Add-ons," I guess) does seem more in line with what Bethesda and Steam and other folks are using. Anything that makes things more clear seems like a good idea to me. ⇠eshe^talk 18:21, 6 November 2012 (GMT)

I agree that the term "plug-ins" is outdated, and assumed it was started because of the free Morrowind downloads, as Legoless brought up already. And once again, Jak wasn't the only one to ever bring this up. Not only did I bring it up here when the Skyrim page was originally created, Jak pointed out Vely's comments on it above, and as seen on many edits on articles and talk pages (here's one example from another regular user), people use the term DLC much more frequently. At the very least, a redirect for the name "Skyrim:Official DLC" would be helpful.

As for the namespace issue, it's a good idea to be prepared for it if we need to (such as coming up with the abbreviation, which seems to have been done already) but I think it's still too early to decide. There really isn't a strong enough indication that this will be much larger than Dawnguard yet. We need to know more before making that decision. — ABCface^◥ 18:30, 6 November 2012 (GMT)

(edit conflict) I like the term "Plug-ins", though I suppose DLC would work just as well. I'm ambivalent on that terminology, and I'm sure you all can agree on which one is most appropriate. But here's my summation on the other issues present here: I specifically define "expansions" to be plug-ins/DLC which add a significant, generally insulated chunk of landmass to the game, while general plug-ins/DLC like Hearthfire mainly just alter the existing world. I dislike "add-ons" as it could reasonably be used to refer to either type, thus clouding the dichotomy I believe we should continue practicing.

It's only expansions which deserve their own namespace, and thus, their own link in the sidebar. While it's unfortunate to diminish the standing of some of the more substantial DLC like Knights of the Nine and Dawnguard by not linking to them specifically, I feel it's necessary to avoid cluttering the list. It's sometimes hard to make the determination beforehand, and Dawnguard is an example of that. Ultimately, it added little more than a fort, a castle, a couple caves, and the Forgotten Vale, but these bits and pieces of new territory were not on par in terms of size or importance with the territories added by the Tribunal, Bloodmoon, or Shivering Isles expansions. We decided to wait to make the determination on whether DG should have its own namespace, and ultimately decided no. Both choices were smart and prudent.

This situation, however, is substantially different. Given the information which can be extracted from in the trailer (i.e., DB is adding Solstheim and at least one Daedric realm) and our unique familiarity with the territory (this is, after all, basically Bloodmoon 2.0), I think logic dictates that we can safely, reasonably conclude that DB qualifies as an expansion, and therefore, there's little practical reason to wait a month before launching the new namespace, and substantial reason to part with precedent and launch it early. We certainly can wait, and it's no big deal if we do.

However, there are some small advantages to starting the new namespace early, and some small disadvantages to waiting, mainly due to opportunity cost: our time contributing to the wiki now is relatively less valuable than our time will be after the expansion is released, as there will be much more to do after Dec. 4. While some may point out that we can make articles in sandboxes and launch them at the time of release, that much activity all at one time would put great stress on the site, and we want it to be functioning as good as it can in the days immediately following DB's release. So whatever we can reasonably get done beforehand should be done. There's also the matter of link maintenance: for example, links to Skyrim:Dragonborn are already proliferating, in some small part due to a recent lore policy change. I don't know about you all, but I don't want to have to waste any time on Dec. 4 changing these to Dragonborn:Dragonborn. There will be loads of more important stuff to do then.

So, in summary, ambivalent on DLC/plug-in terminology (but "add-on" makes me sad in pants), specifically defined expansions deserve a namespace and sidebar link, DB qualifies as one such expansion, there's little point in waiting to launch namespace, and some benefits to doing it early, but don't mistake my long-winded comment for zealous advocacy of one or the other; I'm good either way. Minor Edits^{Threats•Evidence} 18:57, 6 November 2012 (GMT)

Both Dawnguard and Dragonborn cost 1600 MS points. From that we can conclude that the "size" will be about the same - we have not much other data in that respect at the moment. Dawnguard did add two big external maps, the Forgotten Vale and Soul Cairn. I can't see why we should label Dawnguard as "DLC" and Dragonborn as "expansion" - they are exactly on the same footing. So in my eyes, giving Dragonborn it's own namespace, but not Dawnguard would look a bit random and inconsistent - so better only do that if there are really convincing arguments for it, not because of some trailer and guesses.

Bethesda refers to Dragonborn as "add-on" [3] both in the blog and at the end of the trailer. Dawnguard stuff is named DCL1 in the game files, Dragonborn stuff DLC2 - again no real difference here. --Alfwyn (talk) 19:29, 6 November 2012 (GMT)

Price and size are criteria that can change with time, inflation, and technology. A DLC's relationship to the vanilla game is a constant, relatively reliable polestar for determining whether a new namespace is warranted. And, as Lurlock noted above, using Bethesda's terminology is not always the most logical thing for us to do here. Minor Edits^{Threats•Evidence} 19:40, 6 November 2012 (GMT)

Well, I don't see a difference in DLC relationship to the vanilla game when looking at Dawnguard and Dragonborn. I don't know where the notion comes from that they play in different leagues. Whether there is a clear separation of content can't be judged right now, we will see that when it is released. Solstheim did feel vast and substantial back in Bloodmoon, but looking at our map, it is tiny compared to Skyrim. There was some change of in-game scale - all of Vvardenfell is only half the size of Skyrim. --Alfwyn (talk) 20:04, 6 November 2012 (GMT)

Just FYI, that map isn't an accurate representation of the gameworld sizes. Morrowind, Oblivion and Skyrim are all roughly the same size. Solstheim as it appeared in Bloodmoon can be compared here. —Legoless (talk) 20:25, 6 November 2012 (GMT)

Dragonborn Namespace: Edit Break 1

Just to chime in, I don't think price matters. It's possible that DG will be required to play DB, which would make it unnecessary to make DB cost more, or Beth could just decide that, with so much DLC planned, they aren't worried much about making it cost more. Vely^►t►e 20:51, 6 November 2012 (GMT)

I would just like to throw in my ten cents on the side of the "bigger than DG" crowd. My reasons are as follows. First: Bloodmoon is an expansion, and DB takes place in the same area, so it's probably an expansion. Building on that, multiple large locations have been confirmed or hinted at. There is an entire Telvanni settlement, complete with a tower. We have Raven Rock as well, and even Castle Karstaag. Also early in the trailer (20-25 seconds or so) a Nord village (Skaal Village perhaps?) is shown, and then a shot is taken from the sea which shows a large land mass: Solstheim. All of these, in addition to the dungeons which will surely be there. In addition, Dawnguard did not include enough large content areas to warrant new map markers. Dragonborn has five.

Next point, cost really doesn't matter a bit. Dawnguard is $20 and it is not a third the size of Skyrim, regardless of cost. In addition, I don't think that Bethesda could really just keep ramping up cost proportionately to size, if they did, we would see $50 DLC. I think that $20 seems to be a cap.

I also would like to say that I would tend to agree that a namespace should be set up early, so that we can add skeleton pages for major things early on. So to basically sum up my points: I support making a namespace for DB due to the size that it will have, and lack of convincing evidence that it won't be an expansion-sized DLC. --HalfStache 22:07, 6 August 2012 (UTC) 03:40, 7 November 2012 (GMT)

To me it is bleedingly obvious Dragonborn will be considered a full-blown expansion whereas Dawnguard is simply more content. The key is: are there new territories, new vast areas, landscapes? Adding a tower here, a vampire castle there does not make an expansion. Adding a substantial island with lots of new ground to explore does.

(I have always marveled at those who look at DLCs for what I consider trivial baubles: spear-wielding, dragon-riding, ice-armor... this is minor people! What I want out of expansions is new ground to explore and enjoy. Making Skyrim bigger, as in actually physically more of the mountains, rivers, forests, and ice sheets. Obviously, with the same density of quests, NPCs, monsters etc. To me there simply is no comparison between Dawnguard and Dragonborn. Dawnguard might contain more than Hearthfire, but both are relatively minor add-ons, whereas Dragonborn finally promises to add more... Skyrim... to Skyrim! :-)

TL;DR: DB:Dragonborn needs its own namespace. Not making the change right away only means you live in denial. Thank you. CapnZapp (talk) 08:09, 7 November 2012 (GMT)

I also just want to say that the price being the same doesn't mean that DG and DB are the same size in terms of area and content. One of the main criticisms of DG was that it was very overpriced for its size. RIM (talk) 13:56, 7 November 2012 (GMT)

Yes, it does seem there's a good chance we'll need a new namespace, but we simply can't know yet, and there's really not much point to jumping on a new namespace when we know so little. We can still set up stubs as needed until we know more and move them later (this takes literally a couple of seconds, and updating links takes only a minute or two anyway, especially if we get bots involved). We know basically nothing; it's too early to decide this just yet. ⇠eshe^talk 15:54, 7 November 2012 (GMT)

Why? Minor Edits^{Threats•Evidence} 16:34, 9 November 2012 (GMT)

I set up the {{DB}} template for future use. I also think it will need a new namespace, though at this time there is no new information, beyond a few screenshots. Silence is Golden^{Break the Silence} 20:25, 16 November 2012 (GMT)

Seems like it will have two new landmasses (Solstheim and Apocrypha), or at least a substantial dungeon-type area. A new namespace is beginning to seem even more viable to me. —Legoless (talk) 20:52, 16 November 2012 (GMT)

Dragonborn Namespace 2

Yes, I'll admit I made an edit break in a short thread section, but moving forward, this is important, and a decision ought to be come to, so for simplicity's sake, I broke away to a new line.

We are two days away from the release of Dragonborn, and we really need to make a decision on whether or not a namespace is created, and ideally, if we do make one, I want to see it created tomorrow sometime, so that we have it ready in time. Consensus from previous sections already appear to lean towards its creation it seems.

I am in favor of the creation of a new namespace for Dragonborn. I would like to use an argument Nephele made against a Knights namespace, in order to justify the creation of a namespace. To quote a specific line:

"KotN has not introduced any new places or people with the same names as existing Oblivion places, which would require disambiguation. On the other hand, KotN has made some minor changes to existing places, for example, Underpall Cave. In these cases, creating a separate KotN namespace would lead to confusion: should there be an Underpall Cave page in both the Oblivion and KotN namespaces, just to add that one change was made to the place?"

We have undenialable proof that two large landmasses are introduced to the game (Solstheim and Apocrypha), where most of the content will undoubtedly take place at. Since this information is unlikely to reasonably be integrated into existing SR articles, like Dawnguard's locations and tweaks to various pre-existing locations, or Underpall Cave in the Knights example, there is no organizational benefit to mixing in loads of content into the base game that would require refitting the space to hold this content.

While I am generally against using leaked information as a source, this close to release, I'd like to consider the information somewhat credible, and there is information suggesting a large (30-ish hours I hear) main quest, new abilities, weapons, etc, that strongly lean in favor of the "expansion" title, and an organizational split from the main Skyrim space that Dawnguard and Hearthfire didn't require.

Once again, I strongly recommend the immediate creation of this namespace, so that we can organize what we have into it before the release and the anon editing storm. The Unofficial Elder Scrolls Pages are the best of the best, and we need to be on top of things to ensure that our namespace is filled up quickly, efficiently, and to the high quality that UESP strives for in content. We were a disorganized mess when Dawnguard came out, and I definitely don't want that repeated, especially on such a large scale addition to the site.

If anyone has anything to contribute, come forward, because we need a consensus and something to happen, and it needs to happen fast. ES^{(talk•email)} 07:42, 2 December 2012 (GMT)

We definitely need a Dragonborn namespace. Everything about the expansion that is known suggests that it will be large enough to justify one. Yes, we can't know absolutely if it would be necessary, but there is just so much more that suggests we would need one than we won't (I can't find any real evidence contradicting the fact that it will be the biggest expansion yet). Most users seemed to had thought right away we would need this, and yet we didn't move forward with the implementation of this namespace. Honestly, how many times have we been burned by ignoring our instincts so far? Too many times. By waiting until after the fact to begin basic setup of the namespace, we're just asking for a disaster. Regardless of what you think, lets consider something we seem to only be hinting at right now; which one requires more work?

If we make the namespace now we'll be missing out on a pretty major opportunity to get some groundwork done right away. We'll also see an increase in editing from people adding Dragonborn content. Creating a namespace during this period and moving pages to it will simply be a nightmare. As such, there are several clear problems with waiting to see if we'll absolutely need it. However, if we make one now, there will be less issues as we can simply wait and see if we'll ultimately need it or not. We can focus on organizing and adding content during the period immediately after its release, and once things calm down we could come back and discuss if we need to merge Dragonborn with Skyrim or not. As Daveh said when asked on his talk page, there is no harm in making it sooner rather than later.

As consensus is leaning towards supporting this action and it needs to be done now rather then later, and Daveh is currently active at the moment, I'm going to ask Daveh to make the change. Arguing otherwise at this point with what we know would be like questioning whether or not Bloodmoon or Shivering Isles needed their own namespaces. If you still think otherwise, feel free to contradict me there or here. --AKB ^{Talk Cont Mail} 14:15, 2 December 2012 (GMT)

(edit conflict) Everything points to this being an expansion, with most of the action taking place away from Skyrim. There will, undoubtedly, be some crossover of information, but the vast majority will be separate. To use the same argument for waiting, why can't we make the namespace, and if it turns out to be unneeded, we just reverse the decision, there will be confusion either way, so lets just make it and regret it later if that be the case. Due to some unexplained reason, Bethesda have not bothered releasing any more trailers, or any other substantial information. The only information released (leaked) was a few days ago by a beta tester, which pointed to a large amount of animals, weapons, 44 locations, only one of which is in Skyrim, 5 types of craftable armour, and 5 new dragon shouts. In case you didn't figure it out, I'm in favour of a namespace. Silence is Golden^{Break the Silence} 14:25, 2 December 2012 (GMT)

I’ve been thinking about this as well, and let’s just create the namespace. The moving job will be the same regardless of what we do, so better safe than sorry. --Krusty (talk) 15:10, 2 December 2012 (GMT)

I agree. Giving the large amount of area, weapons, abilities, and realms, this is nothing but an expansion that deserves its own namespace. Tribunal is an expansion and has a namespace, and it adds the area around one city. Dragonborn deserves one as well.--Br3admax (talk) 15:43, 2 December 2012 (GMT)

I also agree. I was holding off on making a decision until Bethesda released more information, but they've been completely silent since they released the first video, so I guess we have to decide now. By what little information we have, it's obvious that we need to make a separate namespace for it. • JA^T 18:11, 2 December 2012 (GMT)

I think the ayes have it. Minor Edits^{Threats•Evidence} 19:31, 2 December 2012 (GMT)

Update -- I've added the Dragonborn (DB) namespace as requested. -- Daveh (talk) 22:27, 2 December 2012 (GMT)

I've just added it to MediaWiki:Uespnamespacelist as well, so from a technical standpoint, we should be good to go for all you Dragonborn types.

Unfortunately, it's unlikely that I'll be able to create all the necessary Dragonborn quest and NPC pages at this point, nor do I have access to the Xbox data in any event, so in all likelihood, Dragonborn content will need to be added by hand, like we did for Hearthfire. Hopefully, by the time it comes out on the PC, I'll be ready to add/modify the relevant pages. – Robin Hood↝talk 22:45, 2 December 2012 (GMT)

Since Dave gave it its own namespace, now, can know call it an expansion around the wiki? Currently, it is still called am "offical plug-in" on the Dragonborn page. While this name is techinically correct, all of the other expansions(i.e. Tribunal, Bloodmoon, and the Shivering Isles) are called expansions on their corresponding pages and related material.--Br3admax (talk) 23:21, 2 December 2012 (GMT)

Makes sense to me. Minor Edits^{Threats•Evidence} 23:23, 2 December 2012 (GMT)

Some of that is official terminology - Tribunal and Bloodmoon were called "expansions" by Bethesda, not just by us. Of course you couldn't call them "DLC"s in those days because the term wasn't invented yet, and they weren't downloadable anyhow. I think the same is true of Shivering Isles, though it's at least available as DLC now. But I'm fine with calling it an "expansion". I mean, technically anything that adds new content could be called an "expansion" by definition, but we're not going to be that broad. TheRealLurlock (talk) 01:55, 3 December 2012 (GMT)

The Elder Scrolls Wiki/Wikia: When our content finds its way there

Is there an established way of handling material that appears to have been copied from us without attribution by them? I found one good chunk of verbatim text a few days ago and put a note on their copyright talk page asking them to take care of it or attribute to us. An admin replied immediately and wiped out the content. Then I realized that the same editor there who had apparently done this, apparently did so for a fairly long string of pages. It was some time ago, and it seems that since then, there has a good effort over there at educating their editors not to do it.

I started writing to the same admin to point out the further instances, but thought I'd check here first. I was just going to write a friendly and positive note to the same admin, or maybe to the editor himself, who is a patroller, and quite active there, asking them to check it out. Any better or different idea? --JR (talk) 15:43, 23 November 2012 (GMT)

Nah, just asking them like you are is fine. Whenever issues have been brought up to my attention by others, I'd just ask in their IRC channel or post a message on one of the admin's talk pages. I love how polite and professional they are about it :) ES^{(talk•email)} 15:58, 23 November 2012 (GMT)

Thanks. --JR (talk) 16:43, 23 November 2012 (GMT)

Regarding this:

What if I compose a chunk of text regarding a certain Elder Scrolls subject and enter it on both sites? Then there'd be identical text in both places and yet, who can be upset over this? CapnZapp (talk) 19:13, 8 December 2012 (GMT)

We would probably want to replace the submitted text. It looks bad for both sites to have identical content. Is there any situation where this would happen? —Legoless (talk) 19:17, 8 December 2012 (GMT)

When one and the same editor writes up a single chunk of text and enters it on both sites? (Sorry for essentially repeating myself but I don't understand what about my hypothetical scenario you found unclear?) CapnZapp (talk) 20:28, 8 December 2012 (GMT)

If it's simply hypothetical, then I can't offer much of a response. If you have specific examples, I'm sure it could be worked out on a case-by-case basis. Regardless, it shouldn't really be an issue. —Legoless (talk) 20:34, 8 December 2012 (GMT)

Right, Legoless. Don't feel forced to reply, especially if you don't have anything to say ;) CapnZapp (talk) 14:17, 9 December 2012 (GMT)

(←) Anybody else? Would you actively discourage an editor (like me) from crafting a bit of text if my intention was to submit it to both wiki(a)s? Isn't that to put infighting above the expansion of the wiki? (A sincere non-trolling question!) Regards CapnZapp (talk) 14:17, 9 December 2012 (GMT)

In principle I would discourage it. First you'd need to make it known that you are the same person, then make it clear that you are the one posting it on both sites. This isn't infighting as we are rival wikis, with different standards and formats, so it is unlikely to be exactly the same text. Also while they may accept the text if it is properly attributes, we have a more strict, unwritten, policy on copyright violation - removal on sight. The question arises as to why you would wish to contribute to two different rival sites, you may wish to make both better in small quantities, but wouldn't it be better to concentrate on one, to make it wholly comprehensive, and not to make the two sites "identical," thus nullifying the reason for there being rival sites. Silence is Golden^{Break the Silence} 14:40, 9 December 2012 (GMT)

"This isn't infighting as we are rival wikis" LOL ;) At least an honest reply. I'm faintly surprised how up front y'all are with not accepting any content that has been "tainted" by your rival, but not upset by it. At least now I know! Happy days CapnZapp (talk) 16:06, 9 December 2012 (GMT)

We generally maintain good relations with them, and both wikis try to remove or attribute content where the other one is the source. There are several users who edit regularly at both wikis, and a few like myself who are primarily on one, but contribute to the other if they see something that really needs changed. In the end, content does tend to find its way from one to the other at times, but as a rule, we both like to differentiate ourselves from the other, so it's not really a surprise that even if something starts as identical content, it'll get changed soon enough. – Robin Hood↝talk 20:29, 9 December 2012 (GMT)

Dragonborn for Editors

Like with the other expansions I'm offering to purchase the Dragonborn expansion for active admins and editors of the UESP. Just e-mail me the request. For the XBox version I believe the best way is for me to give you an Amazon gift card you can use to buy the points with (unless someone knows a better way). When the PC version is out the best way is for you to give me your Steam name and I'll gift it to you directly.

If you are unsure whether or not you qualify for getting the expansion feel free to ask...the worst I can say is no and you'll never get if you don't ask. -- Daveh (talk) 13:56, 2 December 2012 (GMT)

Wiki Markup

Just a small suggestion: shouldn't [[Dragonborn:|]] be added to the markup table below the save page and show preview buttons, since it's going to be one of the most used markups in the next few weeks. Oh, and since I'm already on this topic, I suggest adding <code></code> as well; I really hate typing that out :P (especially for console commands and form IDs). So yea.. that's about it. Not really sure who is able to make such changes. An admin probably? ~ Psylocke 04:38, 4 December 2012 (GMT)

I just checked and the patrollers can't get to it currently, so it'll have to be a full admin. To save someone the time, the page is at: MediaWiki:Edittools. – Robin Hood↝talk 09:41, 4 December 2012 (GMT)

I took care of it, along with a few others. Was tricky to fool it into allowing me to add <nowiki></nowiki> tags, because they kept cancelling themselves out. But we got 'em now. TheRealLurlock (talk) 12:07, 4 December 2012 (GMT)

Hearthfire Minables on Skyrim Map

Just to let everyone know, for the Hearthfire expansion, the clay deposits (map) and stone quarries (map) have now been added to the Skyrim map. – Robin Hood↝talk 00:15, 5 December 2012 (GMT)

Hmm, I was just trying to also add the locations of the houses you can build on there - it's always bugged me that they were missing, but I can't seem to figure out how to edit it. I can edit the MW, OB, and SI maps just fine, but not the SR one. Am I missing something? TheRealLurlock (talk) 03:01, 5 December 2012 (GMT)

No, it's broken currently. I did it by updating the database directly. I've peeked at a few things here and there, but not enough to know what's wrong yet. I was going to go over Hearthfire and Dawnguard tomorrow and see if there's anything else that should be added. It's relatively straight-forward now that I have database access. – Robin Hood↝talk 03:10, 5 December 2012 (GMT)

(←) Where exactly would you discuss the (awesome) map? I would like to voice my opinion to keep DLCs separate, but realize here's not the proper place. Thx CapnZapp (talk) 16:09, 9 December 2012 (GMT)

Well, either here on the community board or on UESPWiki talk:Skyrim Map Design. --Alfwyn (talk) 16:13, 9 December 2012 (GMT)

Would it be possible to add a superscript "DG" or "HF" to the labels on the map in order to distinguish them? It would also be useful for searching for specifically mod-added content. (For example, if I wanted to see Clay Deposits and Stone Quarries together on the same map, I can't, since there's no "OR" feature in the search, but if they both had a "HF" in the name, I could search that instead.) Or if the superscript isn't possible, we could just put it in parentheses. TheRealLurlock (talk) 13:22, 10 December 2012 (GMT)

I don't know if superscripting would be possible or not, and I didn't want to break anything, so I just added "(HF)" to the end of the name for the clay deposits and stone quarries. – Robin Hood↝talk 21:24, 10 December 2012 (GMT)

That works. Are those currently the only mod-added items on the map? I looked around to see if any DG locations were there, but didn't recognize any. At some point, we should add all those, but it's apparently on you until we can figure out why other people can't edit the map. TheRealLurlock (talk) 03:19, 11 December 2012 (GMT)

I certainly haven't added anything besides the HF mineables, so I think we're okay. Also, Dave fixed the map editor the other day, so we can add the other stuff now through normal methods. I'll do the other DG, HF, and DB stuff by-hand right now (assuming all goes well, anyway). Should I also add the location where the Space Core lands from the Portal 2 mod? – Robin Hood↝talk 04:36, 11 December 2012 (GMT)

(←) Okay, I've added most of the Hearthfire and Dawnguard map markers. I can't figure out how Forgotten Vale is getting added to the Skyrim map, though. If any of the CK people out there can figure it out, please let me know! It might be scripted or something, I didn't look into it all that deeply. Rather than fudge it, I've left that off the map for the time being. There don't appear to be any map markers added by Dragonborn unless they're doing whatever Forgotten Vale is doing. – Robin Hood↝talk 07:00, 11 December 2012 (GMT)

I missed a few in Dragonborn. I'll be adding them either tonight or tomorrow. – Robin Hood↝talk 09:22, 11 December 2012 (GMT)

How did we get the actual map images for this? We'll probably need to do that again, since several of the new areas are outside the original map. (Volkihar Castle, for example, probably Forgotten Vale as well. And I didn't see the Dawnguard castle there either, but maybe I missed it.) Obviously Solshteim is off the map, but we'll need to wait until the PC version comes out for that probably? TheRealLurlock (talk) 13:05, 11 December 2012 (GMT)

Skyrim map images are from the Construction Kit export I did. Still haven't found a way to get colour maps. -- Daveh (talk) 13:20, 11 December 2012 (GMT)

Okay, so it is possible to get superscripts to show up in the labels. Check out the area I did around Lakeview Manor. I was concerned at first because the changed clay deposits and stone quarries were not showing up on the map. I then realized this was a limitation, that the map can only display 50 markers at a time in a search, and by editing those, I moved them to the end of the list. This occurs even if the first 50 are all outside of your current view. (Try looking for Iron Ore Veins and you'll see how much of a problem this can be.) TheRealLurlock (talk) 14:35, 11 December 2012 (GMT)

Regarding the Forgotten Vale, the map marker is xx0088e0 (20253/5161), it's just in the Forgotten Vale worldspace. This has an offset of (-50/17) cells, or (-204800/69632). Adding those, places the marker in the right region. Not sure if the world map scale of 0.5 for the Forgotten Valley has an impact on the coordinates inside, that would need comparing with the ingame world map. --Alfwyn (talk) 14:43, 11 December 2012 (GMT)

Yeah, though for Forgotten Vale, you'd also want to include several locations which don't have map markers - the shrines, the cathedral, numerous caves, the paragon portals, etc. What confused me in the FV was that the compass doesn't seem to be pointing the right direction when you're there. It felt like it was off by 90 degrees. I'd walk what appeared to be north, and the map marker would move to the east instead. (Or was it west? I forget.) Not sure how that will complicate things... TheRealLurlock (talk) 14:58, 11 December 2012 (GMT)

(←) For the superscripts: it's good to know that they're doable, but it's considered really horrendous design to add HTML to a database field if you don't know with certainty that it'll always be rendered as HTML and that nothing's going to actually think the name is "Stone Quarry ^HF". In the case of Lakeview Manor itself, for example, the mapname parameter in the place summary would also have to be updated to "Lakeview Manor ^HF", and I'm not sure if the Place Summary/Map Link templates would've handled that very well. You're welcome to try, if you want, but personally, I think it's a solution that has the potential to cause a lot of issues, so for now, I've reverted the changes. Dave's already mentioned here that he'll be working on better handling of DLC content in the new year, so I think it's best just to live with parentheses for the time being.

Thanks for figuring out the Forgotten Vale, Alfwyn. I wasn't considering that worldspaces can overlap...that'll be something to look into and see if there are other places that do that that we need to be concerned with. I agree that if we can figure out the appropriate scaling, adding other important locations to the map is a good idea. – Robin Hood↝talk 21:01, 11 December 2012 (GMT)

I think it would work if you replace all the < and > with < and >. (Edit post to see the difference - I think I've finally found something that even <nowiki></nowiki> can't do.) It's not pretty, but it would only be needed a few places, and might be templatable. TheRealLurlock (talk) 12:58, 12 December 2012 (GMT)

Dragonborn Quest Update

TLDR: Bot's updating Dragonborn quests in a few minutes. Have a look at the new Quest Objectives section and tell me what you think.

I know I told a bunch of you it'd be a while before the bot was up to doing the heavy lifting for Dragonborn, but the other day, I realized that despite being in the middle of a massive code revamp for processing the Skyrim data files, I could actually get things up and running as they stand now, though I still have a lot of work to be done. So, after two days of working on it, I now have the quest info ready to go. (For those familiar with SR's data files, I've basically got all the records and fields processed into a database, but only a few record types are actually being processed beyond that into meaningful, human-readable tables. It's that second level of parsing, along with figuring out how to integrate it into existing pages, that's taking most of my time.)

I expect there'll be a similar timeframe to get anything else up and running, but that's just a guess based on the quests. Some of the other stuff may be a lot easier. Over the next little while, I'll be going over NepheleBot and RoBoT's contributions around 11-11-11 to see what all they did and figure out how much of it I can do. NPCs and factions will likely be doable fairly easily, and items might be doable as well. I'm less sure about the latter simply because there's potentially a lot of stuff to go on a whole whack of different pages and I'll really have to look at it and figure out what goes where and if a computer can figure that all out. Places are likely to be the hardest, possibly not doable in the short run, so I'll leave that for last in the hopes that the people who're adding things based on CK data will tell me that it's all done and there's no need to worry about it right now. ;)

As far as the quests go, you'll notice I've added a "Quest Objectives" section as distinct from the "Quest Stages" section. That's because that's how Skyrim does things, and our previous attempts at linking the two were based on early misunderstandings (i.e., before the CK came out). Now that we know they're distinct, I've made the quest pages reflect that. Hopefully, that'll give us the ability to make both the stages and objectives sections more meaningful. Once we've played around with it in Dragonborn figured out if it makes sense to do that and worked out any kinks, I'll apply the same changes to all of Skyrim space as well. This makes for a substantially smaller "Quest Stages" section—I just hid anything that didn't have a log entry or a finishes/fails quest flag and listed it in the "missing" section. I was also fairly conservative in terms of what quests the bot updates/creates. If a quest has no journal entries and no objectives, it didn't get added, leaving 57 in total. It may also create pages that'll later need to be changed to disambigs, but for any existing disambigs, it'll update/create a "... (quest)" page instead.

If anybody notices any issues, whether it's missing quests, quests that shouldn't be displayed, incorrect info, or whatever else, please let me know! – Robin Hood↝talk 03:39, 7 December 2012 (GMT)

This is awesome, I think the extra 'Quest Objectives' section will be really useful. :)

Uh, one question though-- do we really need the |mod=Dragonborn parameter which makes the pages say "Added by plug-in: Dragonborn" on all the quests? They're all in the Dragonborn namespace, and we didn't do that for SI (based off of only two random SI quests I clicked on). — ABCface^◥ 03:51, 7 December 2012 (GMT)

I saw that in the parameters list and just sort of assumed it should be added. Especially given that it's in its own space, I suppose it makes sense to leave it off. I can have the bot remove them quickly enough if we're all agreed on that. – Robin Hood↝talk 04:03, 7 December 2012 (GMT)

Also, there were a few minor issues with the edits. I think ABCface and I got them all, but if anybody's got time, they could use a another set of eyes, just to be sure we fixed all the problems. – Robin Hood↝talk 05:11, 7 December 2012 (GMT)

Yea.. about the |mod= params, which adds "Added by plug-in: Dragonborn", I think they should be removed. Including those in DB namespace is like including Mod Headers; they're kinda redundant since it has its own namespace. ~ Psylocke 07:36, 7 December 2012 (GMT)

A minor point, I don't think quest footers are useful when there are no prev/next quests, they don't add any information. --Alfwyn (talk) 12:03, 7 December 2012 (GMT)

Another thing, I'm removing the Cleanup-srqrp headers. There is no point in a cleanup project when the pages aren't even written and it adds a very big distracting header. We haven't even started the project for Dawnguard. --Alfwyn (talk) 12:50, 7 December 2012 (GMT)

(←) I agree with Alfwyn's points about the cleanup project tags and the quest footer (the footer should only be on the DB main questline for now, until things get more organized, and probably not on many of them that it's on in the long run at all). — ABCface^◥ 15:29, 7 December 2012 (GMT)

Okay, I'll run a quick bot task to remove the headers and the mod parameter if they're not already gone. Oh and the footer I couldn't readily tell what was linked and what wasn't. The editor id gives us some clue, but without the game, I couldn't really be sure. I figured it was easier to remove the footer if it wasn't necessary than to create one if it was. – Robin Hood↝talk 19:49, 7 December 2012 (GMT)

(←) Just a quick update on the original topic of Dragonborn updates: NPCs turned out to be insanely more complex than I'd imagined, and while I've got all the basic data, there are still a lot of things I have to account for (like the base NPC templates, and which NPCs to actually upload). We're looking at at least a few more days before I can upload any kind of NPC data, but they are coming...eventually. – Robin Hood↝talk 08:12, 19 December 2012 (GMT)

Image Caption Standards

I've been meaning to bring this up for a while now: what is everyone's stance on full stops at the end of image captions (the description underneath a thumbnail)? I know it's done on Wikipedia, but I always try to avoid it and remove any I see. Obviously, full stops should be allowed when quoting a sentence or in the middle of the description, but I'd be against adding them at the end of one. Has there been any previous discussions about this? If not, can it be agreed to include/exclude them? The lack of consistency offends my OCD, especially within a single article. —Legoless (talk) 16:35, 8 December 2012 (GMT)

Not sure of previous formal discussions, but this was informally discussed on my talk page. Common practice seems to be excluding the full stops. According to what was discussed: our image captions are usually short descriptions which aren't complete sentences, and full stops are omitted (e.g., Delphine training with a recruit ) . Full stops are usually only used when the caption is an NPC's dialogue within quotation marks (e.g., "You're that visitor, been pokin' around." ) .

So yea... bottom line is: no full stops at the end of image captions unless it's a quote. AFAIK, this is what the patrollers have been practising anyway. ~ Psylocke 16:59, 8 December 2012 (GMT)

Based on that discussion, I've added this to Help:Images. Unless anyone has an objection, removing full stops on sight should become the norm. —Legoless (talk) 17:11, 8 December 2012 (GMT)

Just an innocent question regarding "I know it's done on Wikipedia, but I always try to avoid it and remove any I see". First, why not do it like Wikipedia does it? From my perspective, being different from the largest wiki is a clear disadvantage. Second, why do you avoid it? (Personal preference, specific grammar schooling, etc)? I honestly have no agenda or opinion of my own here, just curious why somebody would want to fight standard practice (where standard = wikipedia)? CapnZapp (talk) 14:13, 9 December 2012 (GMT)

I'm unaware if it's actually a policy on Wikipedia, but I've seen both methods used. As for why I choose to avoid full stops, I've always left them out of captions/lists, but I can't direct you to any kind of grammar rule. It's not "standard practice" to include the full stops, and it's also not the first time we've gone against Wikipedia's style guide. As far as I'm concerned, this is just a case of choosing one method and sticking to it. —Legoless (talk) 15:09, 9 December 2012 (GMT)

Just to add on to that: we don't follow wikipedia's policies to the letter; we just use it as a guideline. In fact, we differ a lot compared to wikipedia. For example, we employ Namespaces to categorise our articles, and we also capitalise headers in articles. So, in other words, this "no full stops for captions" thing is just one of the many instances we differ from wikipedia. ~ Psylocke 15:33, 9 December 2012 (GMT)

Ok thx CapnZapp (talk) 16:07, 9 December 2012 (GMT)

(←) I have moved my comment from here to the Help:Images talk page, because of it's enormous (I call it "prolific") length, and because, as below, Legoless did not intent to raise a topic that would turn into a big deal. As Legoless stated above, he was mostly interested in consistency, and not invested in which way it went.

I prefer placing concluding punctuation at the end of every sentence, including those in captions. This is a widely-held grammar convention, not simply a Wikipedia policy. I don't want to revert Legoless's solution, but prefer to try to reach concensus. Please contribute either below, or at Help_talk:Images#Captions_and_Concluding_Punctuation. My original content was posted at 21:26 in several posts due to errors returned by the server. The two following comments were in response to my lengthy treatment of the topic. --JR (talk) 22:58, 9 December 2012 (GMT)

Excuse the edit conflict, but I really wasn't anticipating this level of heated objection to the proposal. By all means, if my unfounded grammar beliefs are wrong, change them. I wasn't aware if Wikipedia even had standards for image captions (which was arguably naive). If this warrants further discussion, feel free to revert the above policy change. I didn't think it would be such a big deal, or so complex an issue. —Legoless (talk) 21:47, 9 December 2012 (GMT)

Well, that is a rather lengthy response. I do see the logic in Legoless' (and many other users') thinking, though. The majority of image captions are fragments, or incomplete sentences. Why would we punctuate them as complete sentences, then? One possible image caption would be "Eating a sandwich". It is a fragment, with no subject, implied or given. If my 7th grade English serves me, it's a verb phrase; it's not even a complete clause. This is a very common occurrence on the website, where we have simple prepositional phrases as captions. Why? You simply don't need any more to describe the image. Any more words are excessive, superfluous, and unnecessary (redundancy much?), because they do nothing to add to the meaning of the sentence. There is very limited space for image captions to begin with, and it's silly to write a 1 and 1/4-line long caption (which looks very ugly) when you could convey the exact same information in just half a line.

Judging by how this has been the unofficial site policy for years, and that so far we've never had any difficulty with it, I don't see how making this official would be a problem. This rule isn't exclusionary in the least - if you wish to write a complete sentence, whether for aesthetic reasons or because it would be beneficial and convey more information, then that's just fine. Similarly, quoted text would keep its punctuation, because our website uses logical quotation, in which the original punctuation is preserved. I don't feel very strongly one way or another, though - I'm just outlining what I believe to be the opposing argument. • JA^T 22:15, 9 December 2012 (GMT)

Jak: No one is suggesting punctuation after sentence fragments in captions. The question is whether a full sentence, or a full sentence + more, should have end punctuation in captions. --JR (talk) 23:03, 9 December 2012 (GMT)

Now I feel rather stupid. Ignore me. • JA^T 06:57, 10 December 2012 (GMT)

Nah, my fault. I (obviously) have beliefs about what is generally regarded as correct, but I'll gladly support any consensus. I just don't want a policy change without a discussion and a bit more clarity. I'm reverting Legoless's edit to the image help page per his most recent comment, above, and my discussion with him on IRC. Maybe an unofficial and temporary moratorium could be observed (with a bias toward not reverting/"correcting" caption punctuation issues) while some people who may have input are very focused on DB. Others may want some time to think about whether they have a preference. If no one else does it, I might try to initiate a (concise!) list of options, including what I understand to be proposed above. After getting some feedback, from others, I'm for "slowing down" but moving ahead to see if we can get a consensus of any kind. Maybe I'll move the whole discussion to the Help:Images talk page, and mark it above as an active discussion, unless someone thinks it should stay here and live or die as it will. --JR (talk) 08:15, 10 December 2012 (GMT)

(←) I'm not sure whether to continue this here or here, but since there's more of a discussion here, I guess this works. My input has already been mentioned above via the linked discussion on Psylocke's talk page, but I guess I should formally add it to this discussion as well. I agree with JR on the simple point that full sentences should always include punctuation. This is a pretty basic grammar rule to me, and something I prefer to stick to at all times if possible. Clearly, when quotes from dialogue or books which include punctuation are used as captions, the punctuation should be kept in place, and I don't think that's at issue here. But when it comes to removing punctuation from image captions regardless of whether it's a full sentence or not, I am very much against this. What I prefer to do (and have done, in several instances) when I see a full sentence as an image caption (which isn't a quote from dialogue or a book), is to change it into a fragment and remove the punctuation (if it's there). For example, instead of an image caption such as "ABCface eats some letters." I would change it to "ABCface eating some letters" (and here's two real examples). This is not a suggestion for what we should do everywhere, but rather an example of what I tend to do myself (and have for a while, long before this discussion came up).

As for establishing an official policy, I can't tell for sure what the consensus is, but I am strongly against removing punctuation from full sentences in image captions (or anywhere else I can think of). To sum up my opinions on the matter... Fragments should not have punctuation in image captions. Full sentences should have punctuation everywhere they're used. My personal preference is that image captions are not full sentences, unless using a direct quote. — ABCface^◥ 05:46, 18 December 2012 (GMT)

Watchlist Oddness

A number of people are getting blank pages returned when viewing their watchlist. This seems like it may be browser-dependent, as Chrome seems to be unaffected. In the limited experimentation I've done, hard refreshes seem to work on Firefox, but not on IE. I was, however, able to get at a watchlist by requesting that the page be purged (though re-accessing my watchlist the normal way afterwards causes the same blank page). This link will get you the purged watchlist. This is probably some kind of server-side cache issue, but at the moment, I think Dave's the only one who knows the likely cause and cure. :) – Robin Hood↝talk 05:46, 10 December 2012 (GMT)

I was one of those people for whom the watchlist wasn't working, no matter what I did, including purging. It finally came back on its own a few days ago, but the Random Page is still coming up blank. I'm on Firefox because I hate Internet Explorer and my computer runs REALLY slow on Chrome. So... I have no idea what's wrong... x( --Vulpa 14:48, 14 December 2012 (GMT)

There is definitely something wrong with the Random page for a number of people (strangely not everyone) and my attempts at fixing it just get me more confused about why it is broken. I think the easiest fix is going to be to just tell Squid to explicitly not cache Special:Random and see if that does anything. Will try to play with it more tonight. -- Daveh (talk) 15:39, 14 December 2012 (GMT)

Just in case this helps: I tried it both logged in and not on Google Chrome, and no-go. The same blank page (with correct URL displayed in the search bar) appeared both times. Either it just hates me, or... I dunno. :P --Vulpa 16:07, 14 December 2012 (GMT)

I've stopped Random from being cached on Squid and it seems to work, although it may also be due to accidentally restarting Squid instead of just reloading (which is why there was a lag spike just now). If you see the same issue on other pages let me know. -- Daveh (talk) 23:50, 14 December 2012 (GMT)

Woohoo! It works! Thanks! *Ahem.* Anyway, I was going to say that my watchlist did it again, but only briefly and roughly an hour ago, so I think it's fixed.  :D --Vulpa 00:07, 15 December 2012 (GMT)

Yup, looks good to me too in a quick test. – Robin Hood↝talk 00:11, 15 December 2012 (GMT)

Namespace Shortcuts

Alfwyn recently asked me if it made sense to have the bot keep expanding templates like {{DB}} to their wikified equivalent. The bot's been doing it for the simple reason that that's the way it's always been done. The original thinking, I believe, was that on pages with dozens or even hundreds of these template calls, they could really slow down the rendering of the page, and that's true. As Alfwyn pointed out, however, and I completely agree, "{{DB}}" is much more readable than "^{[[Dragonborn:Dragonborn|Dragonborn]]}".

For the namespace shortcuts that are links to pages, like {{DB|Items}}→Items, I think we should convert those without question. With the simple ones like {{DB}}→^DB, however, we need to decide when to convert them and when not to. On pages like Alchemy Effects, for instance (using SI as an example, since DB is still under development), there would be nearly 140 calls to the template on that page if we were still using it, which is rather a lot. The only good solutions I can think of are:

• only convert above a certain cutoff point, say, more than 10 namespace tags on a page;
• don't convert {{DB}} since it's undergoing heavy development right now and people care more about readability than fast page rendering, but allow the bot to do all the others.

Or we could have some combination of the two, or something else entirely. I'm open to suggestions. So, does anybody have any other thoughts on whether we should convert these, and under what circumstances? – Robin Hood↝talk 22:24, 11 December 2012 (GMT)

For the most part I agree with what you've proposed. Replacing {{DB}} with <sup>[[Dragonborn:Dragonborn|DB]]</sup> everywhere is not very productive, except in extreme cases, such as Oblivion:Alchemy Effects. Having a conversion cutoff of 10 sounds good. However, every instance of the template being used to create a link (such as {{DB|Items}}) should be replaced with links. • JA^T 01:05, 12 December 2012 (GMT)

Are the namespace templates especially expensive? Because we have pages using {{LE}} and {{ID}} really often. Furthermore, those template expansions are cached by the software, so I don't think fast rendering is really a concern or that the difference will be noticeable. --Alfwyn (talk) 11:36, 12 December 2012 (GMT)

That's what I'm wondering. I know back in the day, years ago when these templates were first created, there were concerns that they would be too expensive to be used hundreds of times per page. But the wiki software has improved a lot since then, and I'm not sure if that's still the case. I do think the templates should be kept as simple as possible to avoid unnecessary computation. As a matter of fact, the secondary use of these templates, the {{DB|Items}} form, is no longer necessary, since you can just do [[DB:Items]] instead, something we were not able to do before. If we do a sweep and convert all instances using that form into straight links, and then remove that functionality entirely, the computational impact on the pages where it's used in the {{DB}} form should be minimal. (I'm also not sure the parentheses option is really all that necessary. I feel like those should be consistent - either always use parentheses or never use them. Adding code complexity to the template specifically to make the template usage inconsistent seems a bit backward-headed to me.) TheRealLurlock (talk) 12:50, 12 December 2012 (GMT)

I've actually wondered whether we should even worry about it myself, but never looked into it until now. So, just looking at the plain template, as it's currently written, a single usage generated a preprocessor node count (a measure of the complexity of rendering the page) of 22. Bumping that up to 1500 calls, we had a PNC of 1801, which is slightly less than the current Skyrim Main Page. Now, I don't know how good of an estimate the PNC is for overall rendering time and impact and such, but I would expect it to be related, and 1801 is not a large figure by any stretch. So plain calls seem to be something that's so inexpensive as to be negligible, and I would support the idea of not having the bot make those replacements at all in future.

If desired, I could also revert those changes, perhaps on an "as-touched" basis—in other words, don't change it unless something else is changing on the page as well. This could easily be implemented within the link conversion, or with a little more work, I could even implement it globally, so any bot task that makes other changes would also revert any plain namespace shortcuts. Maybe even just limit it to only fixing DB and SR themselves and leaving all others as too old to even worry about changing back?

Going with TRL's point, I'm also going to suggest that I have the bot start using the short-name replacements for links (i.e., [[DB:Link]] rather than [[Dragonborn:Link]]) just to give people the idea that they can use those now rather than the template. I wouldn't mind removing the additional functionality from the shortcut links altogether, but I think we should give that some time, just to let people get used to the idea.

And finally, on the subject of parentheses, that was a request by Alphabetface, and I assumed it was for a specific reason. Apparently, others have also tried to insert parentheses in various ways on some pages, so if it's just a question of a format preference, then I'd say let's have the discussion, pick one way or the other, and by all means, remove the parameter. – Robin Hood↝talk 18:04, 12 December 2012 (GMT)

(←) I'm not opposed to getting rid of the parentheses altogether if they're that much of a hassle. We only started using them after Dawnguard was released, and it was simply because it looks better visually in certain situations. If the parentheses aren't worth the trouble, removing them altogether wouldn't be an issue. — ABCface^◥ 21:09, 12 December 2012 (GMT)

It's not a hassle, just a question of consistency. If there are times that they're better-looking, then we should certainly keep them, just as long as we're not mixing and matching between similar pages. Are there any examples you can think of where the parentheses are clearly an improvement to the format? – Robin Hood↝talk 21:58, 12 December 2012 (GMT)

I used the parentheses when it's a prefix like on Skyrim:Loading_Screens#Vampire-Related, but without if it is used after a term like in Skyrim:Bloodcursed Elven Arrow. --Alfwyn (talk) 12:53, 14 December 2012 (GMT)

Is that the only page that uses them as prefixes? I can't think of any other place we do that, and I wonder if there's a better way to show that. TheRealLurlock (talk) 13:23, 14 December 2012 (GMT)

The prefix example is a good one of when it looks better in parentheses. As for other examples, I prefer using the parentheses after a {{Quest Link}} because it's consistent with the (radiant) suffix we have on many quests using that template. I also find that on certain pages where there are many linked entries in the first column of a table, it improves readability to have the parentheses on those which are marked with a namespace shortcut tag. This isn't an issue for tables like the one where the Bloodcursed Elven Arrow is documented, since none of those entries are linked. But for long tables which have linked entries for the whole first column, having the parentheses on the DLC-specific entries makes it easier to spot them quickly, and easier to read. This last example may be more of a personal preference type of thing, but as for the prefix and quest link examples, the reasons are more objective. — ABCface^◥ 05:47, 18 December 2012 (GMT)

Class(es)/Occupation Again ... or Still

I think Ghorza gra-Bagol's NPC page (as it stands at the very moment!) represents an excellent resolution of the problem with describing an NPC's class and occupation. Having the introductory sentence describe her as a blacksmith (occupation/merchant) and linking to the "common" or "ordinary" meaning of the term as such, while providing the "technical" class in the infobox, and the "class details" also in the infobox.

I'm not sure about the terminology from a game mechanics perspective, (is her "technical" class really "blacksmith", or is her technical class actually the "more detailed" class?

Considering the lengthy discussion of the issue a while ago, which to my knowledge was not completely resolved, is this pretty much a model page? Should there also be a note explaining the difference? If so, I think it should be listed as such, or at/near the bottom of the page, not mentioned early in the description. Could the Skyrim:Classes page include a short explanation of the distinction in the overview? --JR (talk) 10:17, 14 December 2012 (GMT)

Technically there is only one class per NPC. In that case the class has an editor ID of TrainerSmithingJourneyman and that's what is displayed in the CK for the NPC. If one looks specifically at the class record in the CK, one finds a full name for it, "Blacksmith" in this case. Personally I'm not convinced about the usefulness of the extra "class details" infobox entry, making the class link in the infobox [[Skyrim:TrainerSmithingJourneyman|Blacksmith]] would be both terse and accurate. A link to [[Skyrim:Blacksmith (class)|]] on the other hand is next to worthless, it just links to a collection of classes sharing the name "Blacksmith". Having an extra "class details" field shows more readily information like training or in the case of warriors which weapons they prefer. But that information is redundant, since we list training and notable skills separately anyway. --Alfwyn (talk) 12:49, 14 December 2012 (GMT)

About moving the class to the notes like here, please no. This is generic to every NPC. Every NPC has a class as detailed in the infobox and that class has an effect on skills, health, magicka, stamina, training and probably bleedout default and voice points. Generic information (that might change as we find out more) should not be duplicated on a slew of pages. --Alfwyn (talk) 15:10, 14 December 2012 (GMT)

I tend like your suggestion ([[Skyrim:TrainerSmithingJourneyman|Blacksmith]]) for the infobox, or even [[Skyrim:TrainerSmithingJourneyman|TrainerSmithingJourneyman]], even recognizing the disadvantage of the latter. At least it would help those who don't know understand that the two areas (introductory description and summarybox) may link to different kinds of information. The idea could be that the infobox contains the "true"/"technical" class of the NPC, and links to stats that more detail-minded or sophisticated players might be interested in, while the narrative text links to the "practical" (someone will justifiably challenge me on all of those terms) information, when such exists and when the two differ. I think the related issues remain to be clearly settled, though there was quite a bit of discussion and at least the appearance of several people agreeing on something like the note that was placed on the page you reference. I just think that some people act on such with an understanding that a consensus has been reached, when in fact it has not. Maybe there should be a general note on all NPC pages succinctly explaining that the class field in the infobox links to "the technical class to which the character belongs, while information in the character's introductory text may lead to a different type of information" would be good. I don't know. I hope it gets revisited and someone puts it all together into a coherent set of options for us to choose from as a community. I've seen this work well for complex issues in the past (a sort of "Chinese menu" of "guideline package A, B ... N), and then a discussion and vote once all the options that enjoy some support are enumerated. It can be some work, and I'm wanting to drive such processes as best I can without wanting to hijack them or to display such an appearance. Right now, I'm going to see what I can contribute to getting a comprehensive capitalization policy in place, and then punctuation in image/graphic captions, which is more than enough FOR JR and OF JR! --JR (talk) 09:01, 17 December 2012 (GMT)

Personally I think placing redundant notes unto all articles is a bad idea. I know we do that for the quests, but even there to me it feels more like garbage at the end of the page I just get used to. We could put a similar (but probably more lengthy) "small print" paragraph after each NPC page. There isn't just the class to explain, but a lot of other things too (what does the race do, what is the meaning of a displayed skill like alchemy (probably none), what are the implications of race detail child, and so on). What we should do instead is put a link to a page with an explanation under words like "class" or "skills" if needed. Or more radically, we could put one help link at the top of the infobox, linking to an explanation of all the fields. --Alfwyn (talk) 14:01, 17 December 2012 (GMT)

NPC intro image description

Just a small suggestion I'd like to bring up, since there are no guidelines on this: how about centering and bolding the name in an npc intro image? Descriptions for FIs already seem to do this, and I've picked up bolding the name during Oblivion a while back like in the actual text. I know that there are intro images out there describing the actions of the NPC in detail - personally I think those type of images are preferred as 4:3 additions, but that's another matter - so centering might not be too good there. I've just done it here. Let me know what you think ~ Dwarfmp (talk) 02:43, 18 December 2012 (GMT)

I actually like the idea of bolding the NPC's name in their intro image caption on their page, and think this is a good idea. For intro images which have captions that are simply "NPC Name", the bolding looks fine. I also think it looks good to have the NPC name bolded in some of the longer descriptions, such as Oblivion:Laralthir. However, I don't really like the idea of centering the captions on NPC intro images for the reason Dwarfmp mentioned- it doesn't work too well when the caption describes the actions in more detail, such as in the link I just mentioned.

For those who are concerned with consistency, there are many MW and OB pages out there that already have the NPC name bolded in captions, so while the SR namespace generally doesn't follow this practice, we haven't been consistent site-wide anyway. If we do want to move towards getting some consistency site-wide, I'd be in favor of bolding the NPC name in their intro image caption, but not centering. — ABCface^◥ 03:33, 18 December 2012 (GMT)

Ditto. • JA^T 03:36, 18 December 2012 (GMT)

Bolding the name in the caption seems like a great idea. The bot could probably do the brunt of the work, if desired...just look for any text in the imgdesc parameter that's the same as the page name and then bold it. While we wouldn't want to center everything, we could only center those where the name is the sole text of the description. I kind of like that idea, but I could go either way because it does mean that those specific pages will be different from all other NPC pages. If we do decide to center, we probably shouldn't use the center tag since it's deprecated (and not even included in HTML5 at all). I think MediaWiki actually includes support for it outside the HTML standard, but I don't know if that's intended to be a permanent addition or not. Probably best to just import Wikipedia's Center template and use that if we're going to center anything. – Robin Hood↝talk 05:57, 18 December 2012 (GMT)

I actually don't like the idea at all. The bolded text just doesn't look good in my opinion, not to mention the fact that the caption just seems redundant, given how it's a page designed JUST for the NPC who's name is written as the article title. Snowmane^{(talk•email)} 07:36, 18 December 2012 (GMT)

Ah.. another image caption discussion. I kinda agree with ES. IMO, the bolding in image captions doesn't look appealing to me. True, the bolding and centering is fine if the caption is just the NPC name. However, bolding just doesn't look right like in the OB example given; specially formatting just part of the caption looks weird. And like RH said, if this is done, there will be inconsistencies with all other NPC pages. So, if we really want consistency, what I think could be done is to leave the captions just as they are now, and remove any instances of bolding in captions.

Also, since there is an increasing trend in discussions in the past few months that we usually defer to Wikipedia's style, let me just throw in WP's manual of style for captions if you guys want to create a guideline pertaining to formatting captions. ~ Psylocke 11:25, 18 December 2012 (GMT)

Bolding the name in image captions seems to be a bit random to me. Why do it, just to have it bold? There is no real need to emphasize the name there in my opinion. And there are currently guidelines to this at UESPWiki:Style_Guide#Bold, specifically "Avoid using bold formatting for general emphasis". --Alfwyn (talk) 13:46, 18 December 2012 (GMT)

(←) I don't particularly care for the centered + bold formatting, or even just some bold formatting. I don't really understand the point of centering and bolding some captions, but not others, and I don't think it looks as good as regular old plain formatting (although centered and bold looks fine for the FIs on the main page, so I'm okay with that I guess). In fact, while I'm at it, I don't really prefer just having the NPC's (or place's or item's or creature's) name as the caption; I personally think a brief description is much better, even something as basic as "Legate Rikke at Castle Dour." Just putting the name of the person or thing there seems redundant and a bit boring to me, like we're just putting it there to fill up space. ⇠eshe^talk 14:41, 18 December 2012 (GMT)

Intro images are supposed to show the NPC in full and completely focused. I specifically refrain from uploading images with people in the background (when you can recognize them or something similar). When it comes to activities, I don't upload images with the NPC farming for instance, when it doesn't show them that clearly. "Rikke at Castle Dour" wouldn't be bad, since the location makes a difference, but that's not always the case. Suppose we could say "Wilhelm in his inn", but I don't see much of a point, at least not in the image I uploaded. I think it's much better to upload another 4:3 image of him behind the counter. NPC pages, even for filler NPCs, usually get enough text to throw in another 4:3 image where there's actual activity. Intro images are title images, just like you would bolden and center a title. So I guess I think it's more like a ID card picture, if you get what I mean. If you can get a perfect shot of the NPC, shown very clearly, and have them at their house or having them sit in their favorite chair, that's a big bonus you should always try to go for, but it's not always possible to get that, and thus not always necessary ~ Dwarfmp (talk) 15:50, 18 December 2012 (GMT)

I'm ok with either way, or even both, but am personally inclined against bolding names in captions because the general standard is formatting captions like body text. I'd support bold type if the text was more like a headline over an image or an "image-in-infobox", like the infobox here. I'm open-minded because we italicize quoted matter for no reason than enough of us seem to like it and I haven't heard anyone complain or "argue" about it. I do prefer a policy, whether it be x, y, "x can be changed to y, but not y to x" (as is the case with our logical quotation policy), "changes from x to y or y to x should be made only for within-page consistency", or almost anything else, as long as it offers us some kind of anchor in the storm without unreasonably restricting us.

I also agree with Eshe (and Snowmane?) that a good caption serves something more or different than merely identifying the NPC by name, when the name is the title of the article page, the first word(s) in the article, and so on. But that may open another can of worms, since there is often (in myself included) an urge to get cute or funny, and that seldom works well because people's tastes for such vary so widely, and it's usually a departure from the encyclopedic. So something simple and pertinent or interesting that's (probably) encyclopedic in tone, like this one should probably be the norm if no particular brilliance strikes one of us. At least "Legate Rikke at Castle Dour" identifies the place as well as the person, but "Jarl Skald on his throne" is almost devoid of anything but the obvious. (Not to blame whoever placed it there, probably in a hurry).

As to the content of the image itself, I think we all agree that the priority is to identify the person clearly. The image page says "preferably performing some kind of action", but I think we can hold on to identifying them clearly (and, at least usually, from head to toe) as the defining standard. If the background accomplishes that and also conveys something of the character's essence, or also shows something interesting, I that that's usually better. I could see reasons to include other people in such an image; again, as long as the ability to identify the subject is not compromised. --JR (talk) 18:03, 18 December 2012 (GMT)

Why is it always different

Hey guys and players of skyrim. How come its different for the PLAYSTATION3 X_ BOX and the PC like its weird there's places in the PlayStation that there's not in of it Xbox sane with the others. I think it's not fair well im off to play more skyrim... bye. — Unsigned comment by Azula Moons Stormclook (talk • contribs) at 04:20 on 20 December 2012

Everywhere that's available on the Playstation and Xbox is available on the PC as well. The only thing is that due to agreements with Microsoft (I believe), the add-ons for Xbox are being released earlier than for Playstation and PC...but we'll get them eventually too! – Robin Hood↝talk 04:49, 20 December 2012 (GMT)

actually There is a dovakhinn house for Xbox . or PC that doesn't exist on playstation — Unsigned comment by Azula Moons Stormclook (talk • contribs) at 00:44 on 21 December 2012

This isn't the place to make complaints against the game, but will you elaborate on your observations, to give some clarity and help those who wish to help. Silence is Golden^{Break the Silence} 00:53, 21 December 2012 (GMT)

Skyrim Factions

This has been a topic that we've been avoiding for a while, but unfortunately, it needs to be done, and now's as good a time as any. The Skyrim Downloadable Content Dawnguard, Hearthfire, and Dragonborn have added a number of factions, but they aren't documented. Dawnguard has a couple of factions, and I don't think we've documented any Hearthfire factions at all. I started documenting some of the Dragonborn factions, but ran into a bit of a snag (read below) that needs to be resolved by the community.

The problem is two-fold. First, we need to document the new factions that have been added. There are few enough that it could be done by hand, but the issue is, where do we put them? For the smaller DLC, we can either integrate the DLC factions with Skyrim:Factions and use the {{Mod Header}} template to indicate that the faction is added by DLC, or we create a Skyrim:Dawnguard Factions page and list all of the added factions there. However, we also have to deal with DLC like Dragonborn, which has its own namespace, but shares some of its data with the base game. The way I see it, it really boils down to two options:

• We document all factions used by Dragonborn under Dragonborn:Factions
• We integrate all of the Dragonborn factions into the Skyrim namespace

We can also do a bit of half-and-half, where we only document the added factions in Dragonborn:Factions and have the rest of them redirect to the Skyrim faction page. If we integrate all of the factions into the Skyrim namespace, then we can either fully integrate it into Skyrim:Factions or give it a separate page, like Skyrim:Dragonborn Factions. The only problem with fully integrating it into Skyrim:Factions is that it is sorted by letter, and 99% of the added factions begin with "DLC2", which will make our Skyrim:Factions D article obscenely long. Note that when I say Dawnguard and Dragonborn, I'm simply using them as examples of small and large DLC, respectively. Any new DLC would be treated accordingly. I could go either way on this one.

Second, we need to improve existing documentation. I'm not sure about our existing rules for listing them on NPC page. A good example is Skyrim:Alvor. Some of the factions are listed under their full names (such as "Alvor Services"), and others are listed as their editorIDs. Some of these, such as TownRiverwoodFaction, have no full name, but others, such as CrimeFactionWhiterun, do have full names. Which do we prefer? On the one hand, listing factions by their full name often makes them much more readable (WIGenericCrimeFaction is a bit vague; Crime Faction so crimes against created actors are registered is much more helpful). On the other hand, the only people that would actually need the faction information most likely only need the editorID, plus there are many factions that simply don't have a full name. Also, unlike Oblivion, NPCs are often a member of many factions; it isn't unusual to be part of 6 factions. We can simply create our own human-readable full names, if we feel so inclined. We can also simply keep to the current standard, which is basically to use the full name whenever possible, and only use the editorID when the full name is misleading. Either way, this ought to be properly discussed. Our documentation is also incomplete; it doesn't list the members of each faction. This is bot work, so whenever one of our bot operators is free they can take on this task. One potential issue with this is that it will potentially make the faction pages much longer, such as Skyrim:Factions D, and we'll have to somehow break them up.

This isn't a very high-priority project, but it does need to be discussed, so we can clean up our existing section and lay down the groundwork for future DLC. • JA^T 10:15, 27 December 2012 (GMT)

The rules for factions used so far look to me: All the static factions with rank >-1 are documented. The full name is used if the faction has one, else the editor ID. Several factions are an exception to this rule for one reason or another (CrimeFactionWhiterun because it would clash with "Whiterun", CWPotentialAllyFaction, because the full name would start with a number).

I think we should document new faction in the Dragonborn namespace and point to the Skyrim pages for the old ones. We did that for other stuff like items too. Breaking up the pages in some way is probably a good idea, the diffs for Skyrim:Factions D are already crashing my browser and it's length make it generally hard to handle.

There is much that would need to be done and researched for factions:

• Currently most pages list a downright wrong dispositon boost value.
• The only flag listed right now is HiddenFromPC, but this flag seems to have absolutely no ingame relevance.
• Looking at the CK, there is a ton of information associated to a faction, we will need to decide what and how to document it.
• Static faction information may not be sufficient, what do we do about dynamically added factions? Dynamic stuff is probably important for finding out potential quest givers or who will take over services from dead NPCs.

A problem with factions is, it is a ton of information which is hard to edit by hand, but several points would need individual care (for example links to Draugr Faction just link to the first one, not the correct one, but without that faction relation info is nonsense). And ideally there would be individual descriptions of what the impact of a faction is. I'm not really sure we need to document faction members though, unless we can provide more information than the category already does.

A more heretic question: Do we need to document the factions the way we do? What exactly makes it useful information for the average reader that it warrants a position in the infobox? Most of the uses for factions are really technical and even more than a year after the games release we didn't document what they do for almost all cases. But without that, it's just a bunch of meaningless data with cryptic names. As a note, we don't document equally important technical information like keywords for items and places. Just because documenting factions that way for previous games was useful, doesn't mean it is for Skyrim.

But yeah, I too think there is really a need for discussion. --Alfwyn (talk) 15:17, 27 December 2012 (GMT)

It's funny you should bring this up now because I'm finally at the point in the NPC information that I've got all the data I need in a database, and it's just a matter of putting it into the actual NPC Summary template and formatting it correctly. This, of course, includes figuring out what factions to document and how, which'll probably be later today or tomorrow.

So, first off, I believe that if we're going to document them, Dragonborn factions should be put in Dragonborn space. We might even take that a step further and ignore the "DLC2" when alphabetizing them in Dragonborn space, so for example, "DLC2HunterFaction" could be put on Skyrim:Factions H. To your point, it's not 99% of DB factions that start with "DLC2", it's 100%, so I think ignoring that part just makes sense.

I agree with Alfwyn's assessment of "the rules", though I've only given them a brief glance at this point, so my understanding may be incomplete. Whether we're correct or not, though, I have to wonder whether it makes sense to document only some of the factions rather than all of them or none of them. Granted, many of those with Rank = -1 are there for technical reasons only, but what makes it more important to document SkyrimJewelerFaction for Adara, but not SkyrimMerchantFaction? As for the names, I think Alfwyn's correct, that we've used friendly names in most instances, and only gone to EditorIDs when there was no friendly name or the friendly name was ambiguous. Some of those names are insanely long, however, and I wonder if we may not want to just go with the EditorIDs or, as Alfwyn suggests, get rid of them altogether for Skyrim. They're just not as informative as they were in previous games in many cases.

To Alfwyn's point, something like Keywords play almost a pivotal role now for just about everything: creatures, items, locations, spells, and a whole lot more. Heck, even though I'm not adding them to the NPC Summary at this point, I had to use them just to figure out what was an NPC or a creature, and they'll also come in again when I have to mark whether the actor is undead, a ghost, a child, and whatever other special types we're documenting.

Lastly, in working on the NPCs, I ended up having to process far more information than I realized at first. At the moment, I've only got the FormID, EditorID, flags, and friendly names of factions, but now that the framework is in place, it won't take much more work to get the rest of the information. So whatever we decide on, it should be a relatively minor task to put the bot on it. Probably only a day or two at most once I've finished with the NPCs, unless of course I'm hopelessly naïve, as I was for NPCs. :) I don't think I am, though...factions look to be moderately straightforward. – Robin Hood  (talk) 21:34, 27 December 2012 (GMT)

Dragonborn NPCs

At long last, the bot is about to start updating our Dragonborn NPCs. First off, I'd like to publicly thank Alfwyn for all his help in figuring out what should be done, what shouldn't, and what we'll probably want to rework in the future. As far as the updating itself, there are a number of points I feel I should note, just so people know what to expect, namely:

• NPCs: To get picked up by the bot, an NPC must actually appear in a cell somewhere (i.e., it has a RefId), and must be one of the NPC races (or be Miraak's custom race...darned special cases). It will not add any that are created through more roundabout ways, like a few quests do. It can, however, be told to add those manually, so if you find special NPCs like this that you want the bot to create/update, just give me the Base ID or Editor ID, and I can have the bot do a special run for them. (It's easy to check these in the CK: it'll pick up those with a Count of 1 or more, but not those where the Count is 0 and the Users is 1 or more.)
• Location: I have no idea how to tell if something's a city, village, house, store, whatever. For now, if a location of some kind hasn't already been entered, the bot will spit out an unlinked location, and it'll be up to editors to link it and/or change the parameter name from loc= to whatever else might be appropriate. Given all the work Alfwyn and others have been doing on the NPC Summaries, though, I expect these cases will be few and far between.
• Steward: Not sure how to tell this, so this one's completely up to editors to add.
• Marriage: While I could pick this up in theory, there are so many complications that go into who you can actually marry, it didn't seem worth it...the data would just be too unreliable.
• Merchant info like what they sell, gold amounts, and availability: Not something I'm getting from the game data at this point, so again, up to editors to add.
• Leveled lists: Unlike NepheleBot, my bot isn't yet sophisticated enough to go through these and figure out what values are common and which ones vary. The bot will report any NPCs where it was unable to resolve the data, and then spit out its "best guess" NPC Summary to its Results page. Again, it'll be up to those with access to the CK to go through and figure out what should be done in each case, and the bot'll report what specifically needs checking. There are only about a dozen such cases, as I recall. I'll try to go through them myself, but if you beat me to it, or you know for a fact that they've already been checked fully, please let me know and save me the extra work. :)
• Leveling info: Even though the game data doesn't always do so itself, the bot will be taking level considerations into account for things like health, magicka, and stamina, and changing the formulae in a few cases to reflect that. For example, for Miraak, his maximum level is 150. However, since his level is always the PC's level × 1.1, and the PC can only make it to level 81, you'll never get to 150. The ranges will therefore be updated to reflect only those values that're actually possible in-game. In addition, ranges will be added to all leveled NPCs to make them consistent. (Previously, we weren't doing so if the NPC had no level limits.)
• Factions: The bot will try to use "friendly" faction names where possible, but if they're longer than 40 characters or the friendly name isn't unique, it'll fall back to showing the editor id instead. The 40-character limit was put in place because you get some insanely long faction names that tend to overwhelm our "summary" box at times, like "Once the player gives the cow to the giant they are both permamently added to this faction". If even 40 characters is allowing too much through, that can be easily changed for next time, or we can re-run if necessary. Also, it's probably going to needlessly re-order some factions; having it keep the existing order would've been more work than it was worth.
• Multiples: The bot will spit out one NPC Summary for each RefID that an actor has. It requires human judgement to figure out what's redundant, what can be combined into a single summary, and what should be left as separate summaries.

As usual, if you see the bot doing something massively wrong, post to its talk page and it'll stop. If you spot any minor issues not mentioned above that aren't worth stopping the bot for, please let me know on my talk page so I can improve the code for a Hearthfire run (not that there'll be much to do for Hearthfire, since it's mostly about building homes and making all that crap you used to throw out the most valuable commodities in the game), and any future add-ons. – Robin Hood  (talk) 23:43, 31 December 2012 (GMT)

For those who're following along, there were a few minor issues during the first couple of attempts, resulting in having to restart. Then one of my attempted fixes failed spectacularly and I had to revert a large number of pages. As a result, I stopped trying to poke at it and went back into testing mode. The issues of the original, and most of those that people have corrected so far have now been addressed, though one or two changes will have to be re-made after the bot clobbers them again. It's probably best to hold off fixing things till we're sure the bot has made it all the way through it's run, just on the off chance that I have to run it yet again...I'm hoping not to have to, though, I think I've gotten all the game-breaking changes now. The bot'll begin its run again shortly, though I'll be running it a bit more slowly this time, just to give me that much more reaction time should anything go wrong. – Robin Hood  (talk) 02:32, 1 January 2013 (GMT)

That run went much more like what I'd originally envisioned! ;) The bot's done now, so feel free to make any changes you see needing to be made. I've been following along behind the bot and will be making several myself, but if you beat me to them, that just means I get to hop into the shower that much sooner. :P – Robin Hood  (talk) 03:06, 1 January 2013 (GMT)

Bugs for DLC

Just in case anybody's wondering what the bot's up to, one of the patch developers has asked for a way to distinguish Dawnguard and Hearthfire bugs from normal Skyrim bugs. While you can usually tell this based on the {{Mod Header}} on the page, there are almost certainly going to be times when that won't be correct, or where DLC bugs are on non-DLC pages. Those we'll have to add manually as we find them.

This also opens the door to the possibility of creating categories for add-ons and separating them out from Skyrim in the various Bugs categories. Does anyone see any particular arguments for or against doing so? (This is also why it's adding the dlc parameter redundantly in cases where the fix parameter makes it obvious...easier both for templates and bots to check one thing consistently than two totally different things.) – Robin Hood  ^(talk) 04:17, 6 January 2013 (GMT)

I am entirely for this. The bug categories are extremely useful, and giving them the ability to be separated by DLC is even more useful. If we use this parameter, we can possible remove the {{DG}} and {{HF}} at the beginning of each bug and add these tags through the template itself. • JA^T 04:31, 6 January 2013 (GMT)

It would be useful to me. I will make fewer mistakes (in answering questions or writing content) the more aware I am of which things are associated with DLC. I'm impaired in that dept. --JR (talk) 04:37, 6 January 2013 (GMT)

IMDb Interwiki Links

Our IMDB interwiki links (as used on Voice Actors and a few other pages) have either become broken or been broken for a while. It's possible that this occurs only for users with an account at IMDB, it's unclear. In any event, I've looked at Wikipedia's solution, and where they used to have a single interwiki link for IMDb, they now have four. I'm trusting their judgement on this, and have copied those same interwiki links to our database, though I believe we're currently only using links to actors. Here are examples of each.

Page Type	Link to Use	Example
Actors	[[IMDbName:0000197|Jack Nicholson]]	Jack Nicholson
Titles (movies, shows, etc.)	[[IMDbTitle:0094721|Beetlejuice]]	Beetlejuice
Company	[[IMDbCompany:0005073|Universal Pictures]]	Universal Pictures
Character	[[IMDbCharacter:0002425|Austin Powers]]	Austin Powers

Don't blame me for the specific examples, they're stolen almost verbatim from Wikipedia. I'll be changing our Voice Actors page and the few others that show up in the search. I don't believe the bot can help out significantly here, since I'm not sure if the search function is finding the existing interwiki links reliably. (It might be, but I'm skeptical...if it is, there are so few, it's not worth doing a bot job for it anyway.) Long story short, it'll be up to us to change any others ourselves. I'll remove the existing IMDB interwiki link in a moment, which should help us spot any remaining ones, since they'll become red links. – Robin Hood  ^(talk) 22:29, 7 January 2013 (GMT)

Prev: Archive 33

Up: Community Portal

Next: Archive 35