UESPWiki:Community Portal/Archive 36

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.

2nd Person or 3rd Person

In the style guide we have a section that specifically discourages 1st person, but we leave it up to the writer to decide between 2nd and 3rd person. I feel like we should be more consistent with this. My preference would be to use 2nd person most of the time, at least on quest and place walkthroughs. Otherwise we're repeatedly referring to the player as "the player", and then getting into the awkward condition of choosing a gender-specific pronoun, or having to write "he or she" (or other incorrect or awkward formations such as "he/she", "one", "they", etc.) all the time. Keeping everything with simply "you" removes any such issues, and makes the article much more friendly and readable. Using 3rd person to refer to the reader just comes off as overly formal and stilted, in addition to the issues of uncertain gender. This wouldn't apply to Lore pages. And of course when we're referring to people other than the player, such as on NPC pages, 3rd person is entirely appropriate. I'm also not proposing a site-wide sweep to make all pages conform to this form, but if you're editing a page written in 3rd person for some other reason, feel free to change it to 2nd at the same time. And we'd add a section to the Style Guide supporting this. Any suggestions/objections? TheRealLurlock (talk) 15:03, 18 February 2013 (GMT)

Pretty much the only articles that should be in third person are NPC pages and lore. While I prefer third person when writing, second person is just better for most content. Third person really only works when we aren't trying to be a game guide and when we need to be more encyclopedic or biographical. In fact, we should change the style guide to reflect this. Third person is appropriate in Lore (always) and is alright on NPC articles, but shouldn't be used for basically anything else. On that note, are there any place or quest articles that are currently written in third person? --AKB ^{Talk Cont Mail} 15:33, 18 February 2013 (GMT)

Plenty. You see a lot of:

"If the player looks to the left upon entering the room, they will see a pull chain in front of them that will open the gate so they can proceed into the next area"

Sometimes it's even worse:

"If the player looks to the left upon entering the room, the player will see a pull chain in front of the player that will open the gate so the player can proceed into the next area"

Or:

"If the player looks to the left upon entering the room, he or she will see a pull chain in front of him or her that will open the gate so he or she can proceed into the next area"

None of which is as clean and concise as simply:

"If you look to the left upon entering the room, you'll see a pull chain in front of you that will open the gate so you can proceed into the next area"

I exaggerate of course, but you see formations like this all the time. I want to fix them, but currently there's nothing in the Style Guide stating that this is wrong. I'd like to add a line saying that: "The player should always be referred to in the 2nd person (e.g. "you") in gameplay articles. 3rd person should only be used when talking about people other than the player." I would make an exception in places like spell pages. We use "the caster" frequently in such situations, mainly to reflect the fact that other people besides the player can cast spells. Not sure how to work that into official policy, but it seems logical. TheRealLurlock (talk) 16:42, 18 February 2013 (GMT)

I'd like something like "In walkthroughs the player should always be referred to in the 2nd person (e.g. "you")"', leaving it open in other cases (so we don't need to define exceptions like spell pages). Adding something like this to the guideline will be helpful, since other wikis usually have a third-person only style guideline. --Alfwyn (talk) 16:56, 18 February 2013 (GMT)

Thanks for the examples. I completely agree that it looks atrocious. Alf's change seems like the best choice, so I'd throw my support for that alteration. --AKB ^{Talk Cont Mail} 17:09, 18 February 2013 (GMT)

There are places other than walkthroughs where 2nd person is appropriate though, e.g. Traps, Lycanthropy, etc. Any game-play related articles like that would fall in this category. Also, on NPC pages, when describing interactions between the NPC and the player, 2nd person can be used. How about "References to the player should always be in the 2nd person (e.g. "you"), except when such references could refer to other people in addition to the player." This covers all cases I can think of. TheRealLurlock (talk) 17:28, 18 February 2013 (GMT)

Yes, there are other places. But I think we should not overcomplicate the style guide and just leave those cases open. There are several cases where not using 2nd person is fine too.

• Skyrim:Dawnguard The player can choose to aid....
• Skyrim:Health [NPC health]...calculated differently than the player's health
• Skyrim:Classes In Skyrim, a class cannot be chosen by the Player Character...

Requiring all those cases to use 2nd person would not be good in my opinion. --Alfwyn (talk) 17:57, 18 February 2013 (GMT)

(←) I'm for some flexibility. If it comes to specifying guidelines, a flexibility's constraints can be defined as carefully as possible--I'm sure not perfectly--and added as such). However, I think the second person is always (?) better when it is a reasonable choice between second and third. "You" simply involves the reader more closely in text than does "the player" (in other contexts "the person" or "one"). I'd say it should be considered correct in quest walkthroughs. I don't think there are any walkthroughs that use only the third person presently. If we did, I suspect that most people who read it would experience what I'm calling "closeness" here (you couldn't blame it on the frequency of a pronoun's or noun's use: otherwise the same problem would pertain to "you" in many or most articles). It's distancing, ignoring the nature of the relationship (we want and usually have) between writers and readers.

For NPC pages, I can see a pull toward third-person as it often feels more "encyclopedia" and formal in tone. But I think we should depart from, say Wikipedia, on this, because we pretty much consider our audience to be players of the game, who use the wiki to enhance doing so. We don't want to see, on Wikipedia, "If you had been a member of Lincoln's cabinet, you would have engaged in many a heated debate." Of course! But if it was "the family and close friends of Barack Obama wiki", and I was his triracial step-brother, I'd rather read, under say, "Charisma", "If you accidentally run into the president in the middle of an important meeting, he is just as likely to interrupt the entire proceeding and say 'hello', as he would be to remain focused on the meeting and seek you out later."

On this wiki, if we agree that we are essentially talking to the player/user, then I think we have a familiarity, an intimacy even, a commonality, with our audience, and it feels more that way when we use "you." I'd be sort of for the logical quotations guideline: Once there's an edit from third-person to second-person, it should not be reverted (except when and where pretty much everyone would agree that the third-person makes more sense), at least not without a discussion. So no "If the steward appoints the player thane" -> "...appoints you thane." -> "...appoints the player thane." on an NPC or gameplay topic page such as a skill page. I suppose if there were some consensus coagulating around something like this, I'd be happy to try to work on some precise and concise language for consideration.

The "we don't need this made policy" idea is ok with me too, in this area, since it's clear what the most general feeling is from the above, because disagreements or potential edit wars can be handled as any other; but I'm generally pro-policization for the help it can give editors without needing to post questions, etc.

And, yes, fellow English-lovers, (not English lovers) "policization" may very well not be "a word", but I use it because I think it's good communication. ;p --JR (talk) 12:49, 22 February 2013 (GMT)

Color-coded Map Icons

So, I was experimenting a bit, and I wanted to see how this would go over. I created a set of color-coded map icons by Hold. (Using the color of that Hold's guard uniforms.) I've only done one set so far, because I wanted to see what people thought:

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

These would be most useful on the interactive Skyrim map, so you can see where the borders of the Holds are. But it could also be useful on the place pages. The template could even be set up to choose the correct colored version automatically, by adding the name of the Hold to the end of the file name (once all the files exist of course), so there'd be very little work changing them over. Any thoughts? I'm open to suggestions on changing the colors maybe. Winterhold and Hjaalmarch are kind of similar, though fortunately they don't share a border, so at least on the big map they wouldn't be confused. — TheRealLurlock (talk) 14:32, 5 March 2013 (GMT)

They're kinda neato, aren't they? My first reaction was "why?", but when I visualize all of the map icons being color-coded, I think it would add some zazz (not sure if that's a word) to the map. Thumbs up from me. --Xyzzy ^Talk 15:04, 5 March 2013 (GMT)

Just added Solstheim - interestingly, the Cave icon is one of only 3 (along with Fort and Nordic Ruin) that would be needed in all colors. All told, we'd need 205 icons to cover everything. I just went and checked for which icons are used in which Holds, so I can avoid wasting time creating icons that won't be used. Now, technical questions: To use these on the interactive map, I think they need to be uploaded manually by someone with serve access - don't think it can use images stored in the wiki. Also, for some of the Holds, there are disambig issues. From a templating perspecting, for Whiterun and Falkreath, would it be easier to have them named "Whiterun Hold" and "Falkreath Hold"? And for Winterhold, would "Winterhold (region)" be better? Or is this not required? For the Solstheim-colored variants, is it okay to keep the "SR-" prefix, rather than "DB-", as we have for the other Solstheim-only icons? — TheRealLurlock (talk) 17:24, 5 March 2013 (GMT)

Very nice, it will change from the bland all-white map markers. I suppose the colors are based on guards uniforms/town banners? Some of them aren't spot-on, but I'm being picky. Also, I wonder why you choose this color for Solstheim; I know no one truely rules on the island, so you can't just make them Redoran-colored, but is there a reason? — Unsigned comment by Elakyn (talk • contribs) at 19:19 on 5 March 2013‎

They would be nice for the interactive map, but I wouldn't like using unofficial icons on articles. —Legoless (talk) 19:56, 5 March 2013 (GMT)

Solstheim was a tricky call, but we used a color similar to this when including Bloodmoon content on Morrowind pages. See Morrowind:Spell Effects for example. Since we're in Solstheim again, it made sense to keep consistency on the site. I suppose I could try and get a sample of Bonemold armor, but it would look a lot like Whiterun yellow. Similarly, Redoran red would be very similar to Haafingar/Imperial red. (Also, I think Neloth would disapprove, as would the Skaal.)

The rest of them are sampled from the actual uniform graphics. There is of course a range on each uniform, as they use light and dark shading to simulate folds in the cloth. I tried to get a representative average, and in some cases I cranked up the saturation a little bit, because a lot of them just looked grey and indistinguishable, but the hue is straight out of the game.

As for the use of unofficial icons on article pages, we're already doing that in several places. The icons for "trainer" are similarly just tinted versions of an official icon. In fact, most of the service icons are being used in ways other than they were designed for. Heck, we're still using Oblivion icons on the creature pages. (The heart for health columns, etc.)

Incidentally, I wonder how exactly we're determining where the borders are? Some locations are obviously in one hold or another, but the borders don't seem to be clearly marked in the game. The only way you can usually tell is if you get caught committing a crime in a given location, and when you're out in the wild where everything is hostile to you, nothing you do is a crime. Unless you Calm somebody first, I guess. Did somebody go around Calming bandits and forsworn and then attacking them to see which hold gave them a bounty? Or is this info easily available in the CK somewhere? — TheRealLurlock (talk) 22:21, 5 March 2013 (GMT)

CSList is where I get which hold a particular location is in. The only place that this may not work would be Unmarked Locations, but they, by definition, wouldn't need a marker, unless someone decided to start marking them, then they would no longer be unmarked...I better stop before I pass out. --Xyzzy ^Talk 00:28, 6 March 2013 (GMT)

I was thinking we might use the Door icon: for locations without a map marker but which do have an interior cell. We can't just put it on all such pages, however, because the template automatically includes it in a category of discoverable locations if you add an icon. But there's probably a way around that which we can look into later. For other unmarked locations, I think we need to come up with another icon altogether. Currently we're using for those, but I think that's wrong, because there are legitimate locations which use the Landmark icon which do appear on the map, and it might be confusing to use the same icon for unmarked locations. I think something simple would be better, like just a little circle, maybe, similar to the Pog icons we use on some overlays. — TheRealLurlock (talk) 01:15, 6 March 2013 (GMT)

(←) Echoing a point made above, I can see this being useful on the Map itself, but I would be opposed to it being used on the pages. We HAVE icons to use for these pages already, whereas for health, magicka, stamina, there aren't really icons to use from the game, so we continue to use the old ones. I think that it would be inappropriate for us to use them on the main articles, and I'm not so sure it would even be aesthetically pleasing either. All in all, I am for using the icons on our map, but strongly against using them on the main pages. I think there needs to be many, many more opinions before we decide anything this major though. Jeancey (talk) 17:53, 6 March 2013 (GMT)

Well, the icons exist. Implementing them on the place pages would actually be as simple as one template change, which could be easily reverted. It would not, if I've done this correctly, require individual changes on every single page. (Only exception might be the Hold capitals might have to be done by hand.) By contrast, implementing them on the interactive map might actually require a bit of work, though I'd like to see that happen. (Somebody else will have to copy the files to the right part of the server to do that, however.) Anyhow, it's there if we want to use it. If not, I won't be too offended... *sniffles* — TheRealLurlock (talk) 02:52, 7 March 2013 (GMT)

It isn't really a question of ease of use. All you need to do is a template change, yes, but that template is used on thousands of pages, because updating place summary also updates it on every single page its on, including oblivion and morrowind namespaces, regardless of something having actually changed. Before ANYTHING happens, there needs to be a real consensus, we should wait at least until the most active of editors have had a chance to see this, and comment on it. It is much more than a "simple change" in terms of the number of pages the template is on. Jeancey (talk) 02:59, 7 March 2013 (GMT)

I think colored icons are a good idea. Realize that we've had to custom-make about half of the Skyrim icons, including all of the Skill-related ones and quite a few others. This wouldn't be the first time we've recolored existing icons for flavor either; look at {{Spells Sold}}. I like the icons, because they add a bit more color to the otherwise-monotone pages. I highly doubt any viewers will be confused by these changes, because every map icon in Skyrim is white, and they will catch on that they are just what we use. As for comments that we need new Health/Magicka/Stamina icons, if you have an idea, go for it! We haven't used any new icons because no one has made any. My only concern is if Daveh does indeed implement the changes below and color the map, the colored icons may not look so good, unless we make a set of brighter icons. • JA^T 03:31, 7 March 2013 (GMT)

It's true that all the earth-toned icons might blend in a colored map, and I doubt making them brighter will change that unless you make them like fluorescent-bright. As for the health, magicka and stamina icons, I checked numerous game sites and it's particulary uninspiring; health is almost universally represented as a heart (or a cross for modern/futurist universes) and magicka is either a flame or just about anything that looks sort of esoteric. As for stamina, flexed biceps and silhouettes running seem to make up the majority, with the occasional heart and/or set of lungs.

There's also the question of whether we should color-code those too -red, blue and green- or not. The ghost weapons found in Labyrinthian gave me an idea, but I'm not sure at all; it would be Blood for health, Soul for magicka and Heart for stamina, but obviously some people are gonna be confused. Also, how do you represent a soul? Some kind of wispy bluish flame?

Anyway, I think the main thing here is making a stamina icon. It looks odd to have a heart, a magical shield and then "Sta", like a kid who didn't get his dessert. Elakyn (talk) 06:51, 7 March 2013 (GMT)

There's another possibility here which is to keep the icons white, but give them a colored border instead of black. I thought about doing that initially, but I was concerned you wouldn't be able to tell the difference as easily. I'm open to suggestions on better color choices. I was trying as best as I could to represent the colors used in-game for guard uniforms, but they are admittedly kind of drab and might not stand out very well. I do agree that we need a Stamina icon, but that's a separate issue. — TheRealLurlock (talk) 12:55, 7 March 2013 (GMT)

What about the opposite? White border with colored insides. That way you can easily see it against the background, but it is still full the correct color. Would that work? Jeancey (talk) 16:27, 7 March 2013 (GMT)

Certainly doable, actually easier than making colored borders. (I can automate the process to turn borders white. Making borders color-coded is more labor-intensive.) Though it might look like they're now undiscovered locations, since that's what dark-on-light signifies in the game, but that's not too serious... — TheRealLurlock (talk) 13:40, 8 March 2013 (GMT)

(←) Here's a really quick redo of the Nordic Ruin set with white borders. I'm not 100% satisfied with how the edges came out, I'm going to see if I can improve on that. — TheRealLurlock (talk) 14:47, 8 March 2013 (GMT)

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

The concept of using hold guard colors is sound. My only concern is for readability - the colors for Hjaalmarch, Reach and Winterhold are varying shades of green that might seem too similar when looked at on the actual map. It's not too bad, as Winterhold is far from Hjaalmarch and the Reach, so it wont be as noticeable. Side by side they are pretty distinct, but map testing might be useful.

Also you could maybe take into consideration color blindness, are these all might appear grey to some folk.--Jimeee (talk) 17:24, 8 March 2013 (GMT)

(edit conflict) Huh. It's probably just my astigmatism, but I'm having trouble distinguishing the icons with white borders. Now I almost know the map by memory so it's not a problem to me but it might be to others. As for colorblind people, well, I admit that it's a problem but we can't do much about it; they're gonna see the map off-colored, but so is everything for them. I guess we could keep the black & white map and create a colored one separately for people who suffer such defects? Elakyn (talk) 18:47, 8 March 2013 (GMT)

I do think the colors are more easily distinguishable with the black border than with the white, but maybe that's because they're on a light background. I just put another set up against a middle-grey background, which is more like what you'll see on the map. I did the same for the black-bordered Cave icons back at the top of this discussion. That should give people a better idea of how these will look on the actual map. — TheRealLurlock (talk) 18:52, 8 March 2013 (GMT)

While I'm at it, here's another set, with the colors made a bit bolder. It sacrifices a little bit of faith to the original colors in favor of making them more easily distinguishable. I tried not to go super-flourescent on them, just crank the saturation up enough to where there'd be no confusion between any two colors. (Oh, and as for color-blind people - What can you do, really? We can't accommodate every possible handicap. There may be somebody reading this site on a text-only browser with an old amber-screen monitor. Maybe some people are completely blind (probably not playing video games much I'd imagine). Sorry, we simply can't take everything like that into account.) — TheRealLurlock (talk) 19:12, 8 March 2013 (GMT)

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

Haafingar The Pale Winterhold Solstheim Hjaalmarch Whiterun Eastmarch The Reach Falkreath The Rift

(←) Can I get some feedback on the new bolder icon colors? I want to know if I should go ahead and do the rest of them this way. Or maybe try the bolder colors with the original black border or what. If nobody says anything within a day, I'm going to just do the rest like the Fort images above. — TheRealLurlock (talk) 13:05, 9 March 2013 (GMT)

They're much easier to distinguish, that's for sure. However I did a quick try and if we put the icons on the map as it is now (that is, grey) even with white borders and the name right next to it the Falkreath icons are gonna be hard to spot. Or maybe it's just my eyes again, I don't know, someone with good eyes shoud try. Elakyn (talk) 13:19, 9 March 2013 (GMT)

How about now? I made it a little brighter. Can't go too pale or it looks just like The Pale. Cranking saturation doesn't really work either because it's supposed to be grey. (Actually, it turns out that in hue it's most similar to Whiterun. Crank the saturation way up and you get a yellowish color.) Of course, it may all be moot if Daveh's talk of getting colored maps (below) work out. (Not sure where you'd get the graphics for that, but I assume he has something planned). It also might be a feature you can choose, like Maps vs. Satellite view in Google maps. But I don't think there's much more I can do for Falkreath while still remaining at least slightly faithful to the original colors. — TheRealLurlock (talk) 13:50, 9 March 2013 (GMT)

I strongly prefer the brighter colors. With how small the icons will be, we need the contrast. They're good, in my opinion. Either white or black borders would work.

As for putting icons on pages, I don't mind either way, but on the capital city pages, the colored icons would clash. Vely^►t►e 16:12, 9 March 2013 (GMT)

If the map stays grey, the white border are preferable, if only for Falkreath - with black borders they're damn near invisible given how small the map icons are. As for the site, I'm not sure. The region is already mentioned in the table, icons for the Whiterun Hold will blend in, and the contrast between table and icons might not be pleasant to the eye depending of the color. Wouldn't colouring the table for all places be more practical, like it is for capital cities? Elakyn (talk) 16:37, 9 March 2013 (GMT)

It's less a matter of what they look like on the individual place pages and more of a useful hint that would appear on pages like Skyrim:Places where they're all together. They're listed alphabetically, so on that page you have no way of knowing what hold things are in without clicking each link individually. With color-coded icons, that information would be immediately available. — TheRealLurlock (talk) 18:23, 9 March 2013 (GMT)

(←) So, I went ahead and tried implementing this on the place pages. They should change over gradually over the next few hours. (You can speed up the process by purging pages, but that shouldn't be necessary.) I figure the only way we'll really know how it looks is to see how it looks. If we hate it, it's as simple as rolling back my last 2 edits to {{Place Summary}}. But let's see how it looks first. As for the interactive map, somebody with access to the server will need to figure out how to make these icons available there, and maybe they can figure out their proper hold automatically so as to prevent the real pain that would be editing all those individually. — TheRealLurlock (talk) 14:46, 11 March 2013 (GMT)

I think this is a good idea. Particularly for the lists and the map. (I'm indifferent about the place pages at the moment, but those that are appearing look OK to me.) Regarding the specific colours, if you're still considering their ease of viewing, did you consider the colours currently on the hold capital pages? These appear to be based on the banner and shield colours rather than the uniforms (Falkreath in this case is a shade of blue rather than grey). I also was thinking, for consistency, that the icons would be more easily identifiable if they matched the colour of the Hold capital. --Enodoc (talk) 15:46, 11 March 2013 (GMT)

Just to jump in very briefly on this, I think these could be neat for the map, but it would probably be better to leave the non-colored icons in place for wiki pages themselves. I don't think the guard uniform colors are universally recognizable enough for most users to realize what the colors mean, and we already list holds on the location pages anyway.

On a side note, I do have ideas for Skyrim health/magicka/stamina icons (and a few others as well for the charts, such as weight and value), and actually made a few as a test. I'll upload them sometime soon (in another section) so you guys can take a look. ⇠eshe^talk 17:42, 11 March 2013 (GMT)

(edit conflict) I strongly oppose using these icons on actual articles. They're unofficial and unnecessary. Place pages have a region parameter already. Icons are included on place summaries because they represent the place in-game, and adding colouring to them eliminates that purpose. The map is a different issue. —Legoless (talk) 17:44, 11 March 2013 (GMT)

(edit conflict) After looking at Skyrim:Places, I am not very keen on the white bordered icons. I too support using these on the official map, but I think it might look better with the thick black border of the standard icons, with the center colored to match the hold. The white border is more distinctive on a dark grey background, but once the Skyrim map is colored, they will have significantly lower contrast. As for using them on the wiki, I'm on the fence about that one. On the one hand, why use colored icons when the official icons are perfectly fine? On the other hand, our entire Skyrim namespace is rather blandly colored, and these will add some strongly needed color to our pages. First, I'd like to see them replaced with thick black border versions, and then I'll see whether or not I think they would look good on the wiki. • JA^T 17:54, 11 March 2013 (GMT)

Elakyn suggested that the page tables be colored like they are for the hold capitals. I think that would be a great idea, if we're looking for color. Vely^►t►e 17:58, 11 March 2013 (GMT)

I support coloring the map icons, as it will look ordered and consistent, but coloring the icons on the Skyrim:Places page just looks messy. I'm more neutral on using colored icons in the articles, but they look a bit odd as the only color on the page. --Xyzzy ^Talk 18:04, 11 March 2013 (GMT)

(←) Per Legoless, I am absolutely against using unofficial icons on the wiki articles. Really, I'm sorta on the fence about them being on the map as well, because they are unofficial. If BethSoft wants to provide us with black and white assets, then we have black and white assets to work with.

And, I do have one question I don't have an answer for: Where do these colors come from that we use to represent places on the wiki? Are they from any in-game source, or just random colors chosen by whoever set up the hold pages and the infobox? If these are real colors from the game, and not random colors chosen by whoever made the box, I'll be a little bit more lenient towards the map, but my stance on the wiki articles is the same. Snowmane➚^{(talk•email)} 18:13, 11 March 2013 (GMT)

(←) (edit conflict) Can people calm down please? It was a trial run. It's very simple to revert this back. I just wanted people to have a chance to see what it would look like before rushing to judgement. To address people's individual points:

• The icons are unofficial: Big deal. A lot of our icons are "unofficial. The whole site is unofficial. It's right there in the name. If using the tinted achievement icon is okay to represent "trainer", then this is no different.
• The icons are unnecessary: Nothing is "necessary", really. On the individual page it's less relevant, but having the icons colored on the place lists is very helpful and lets you know approximately where a location might be found without checking every page.
• White borders: Not my idea. I put them on because other people objected to the black borders, which I did first. The look can be changed if people would come up with a suggestion, but nobody said anything even when I asked for opinions, so I decided to "be bold" and try it out.
• Hold capitals already have colors: I wish somebody had said something about that sooner, though looking at them now I have some disagreements with the colors chosen for the capitals. Baby blue for Windhelm just seems wrong. The place is the capital of the Stormcloaks, and they use a much darker blue. The color we're using for Falkreath is more like what Windhelm should be, and matches the uniforms of the guards better.

Anyhow, as I see there's some rather strong objections, I'll go ahead and reverse the change, but people need to be a bit less vitriolic about this. I clearly stated it was a trial run when I did it, and even said that it would be easy to change back. It's not like it has some major impact that breaks the whole site. It's a minor aesthetic change. If you had such strong opinions about it, you should have spoken up when I asked for suggestions all of last week instead of jumping down my throat now. — TheRealLurlock (talk) 18:22, 11 March 2013 (GMT)

Personally I didn't have strong opinions either way until I saw the change put in place, which is why I decided to give my input, and I imagine the others that commented today had a similar experience. I'm not really opposed to color, to be honest, and I really like the shades you came up with for the icons. I think Elakyn and Vely might be on to something with the idea of coloring the tables instead. ⇠eshe^talk 18:27, 11 March 2013 (GMT)

I think the main issue was that the change was not communicated effectively. I suggested the white icons under the impression that they would be used only on the map, not on the wiki, and I support that, because the map tends to be darker and the white bordered icon might show up better. From rereading above, the majority of discussion revolved around the map, and it seems that most people support using it on the map, or are at least on the fence. This shouldn't be a both or neither situation. The change to the template came without any significant discussion about using it there at all. If you had changed the map icons to see what it would look like, I don't think anyone would have been opposed because we discussed that change. Jeancey (talk) 18:44, 11 March 2013 (GMT)

I'd like to try them on the map, but I can't because I don't have access to the server to upload the icons there. Also, Daveh is in the process of upgrading the map API, so any changes to it now might be a bad idea anyhow. Once the map upgrade is complete and somebody with server access gets those icons where they need to be, we can try it out there. I for one think consistency between the map and the wiki makes sense, and it'd be nice to use the icons in both places, provided we can come up with something that looks good in both. I think maybe going back to black borders, but making the colored part much lighter (though think less "florescent" and more "pastel") might work better. But I'd like to see more discussion on this, and a little less screaming please. You can't test this kind of thing without just doing it and seeing how it looks, and it's easily reverted. — TheRealLurlock (talk) 18:56, 11 March 2013 (GMT)

This isn't perfect, but I went into Photoshop and did a quick mockup of what icons with black borders would look like, both on the wiki and our currently-grey map:

Ignore the slight transparency issues with the borders of the icons on the grey; the actual icons would have a more solid border. I think this would look a lot better, personally. • JA^T 19:19, 11 March 2013 (GMT)

(edit conflict) I just want to say that I liked how the different coloured icons turned out on SR:Places, as, to me, it was much more useful for easy Hold differentiation that reading the associated text, and 30 icons that are all identical in one list seems a bit redundant (the icon in its monochrome form is at the top of the section anyway). I do however prefer the monochrome ones on the place pages themselves, as I think the colour there is unnecessary. Would it be technically possible to use the colours for the lists and the monochrome for the articles? --Enodoc (talk) 19:22, 11 March 2013 (GMT)

(←) I've made a colour comparison reference chart in my sandbox. Feel free to add anything to it. --Enodoc (talk) 20:41, 11 March 2013 (GMT)

Set	Haafingar	Hjaalmarch	The Pale	Winterhold	The Reach	Whiterun	Eastmarch	Falkreath	The Rift	Solstheim
Current Icon
Hold Capital
Banner
Shield Motif
Elakyn
Enodoc

The maps are where I'd like to see this change the most, but it's not something I can implement on my own, despite having server access. Now that I've looked into it a bit, there are two approaches that I can see, one would be expanding the list of icons (dramatically) to include coloured versions of each, as I suggested in Dave's topic; the other would involve using the "Region" field in the database, which is currently unused in Skyrim, except as a convenient behind-the-scenes way to flag Hearthfire icons. The second solution makes the most sense and would probably involve only minimal changes to the map code, but either way requires PHP programming, which is very likely going to be Dave's domain. The one thing I probably could do easily enough is to fill in that region from the associated wiki page, as Lurlock suggested, partly by bot, partly by hand. Before I do that, though, I'll wait to see if that's what Dave wants. – Robin Hood  ^(talk) 21:26, 11 March 2013 (GMT)

Yeah, so we now have FOUR sets of colors for the holds? Whew. I'm thinking something between my set and the hold capital colors should be used all around. Those capital colors are just all kinds of wrong to me - just way too bright and jolly, candy-like (except oddly The Reach - that one's really dark in all 4 sets.) The banner colors are better, but several of them are pretty similar, even more so than my first offering. The shield colors are way too dark - especially the one for The Pale. I mean, it's called "The Pale". That color is anything but. Eastmarch, Falkreath and the Rift are also nearly indistinguishable. Also, I think a better arrangement for comparison would be to have switch the rows and columns, like so:

City	Current Icon	Hold Capital	Banner	Shield Motif		Elakyn	Enodoc
Eastmarch
Falkreath
Haafingar
Hjaalmarch
Solstheim
The Pale
The Reach
The Rift
Whiterun
Winterhold

That way you can see how each set looks together more easily. — TheRealLurlock (talk) 22:00, 11 March 2013 (GMT)

Hey ho, fair enough. Yes, that does make comparison between sets easier. My aim was for comparison between the different versions of colours for each hold. The Banner and Shield colours are directly from the assets, and indeed they are not the best alone. Personally, I think something between yours and the banner colours would be best, and then we could change the hold capital ones to match. (I also assume the hold capital ones were originally derived from saturated versions of the shield colours.) --Enodoc (talk) 22:14, 11 March 2013 (GMT)

I like some of those, doing a bit of a montage (ms paint, nothing fancy) chosing TLR's colors for Haafingar, Hjaalmarch, The Rift, and The Reach, hold capital for Whiterun and Winterhold and shield for Falkreath. For Eastmarch and The Pale I chose TLR's colors and cranked saturation and luminosity a bit. And Solstheim, well I like this icy-blue but it looks a bit too much like some of the Stormcloaks colors. Overall, there's a good contrast between both the different holds and the grey of the map but that's just what I think. Elakyn (talk) 22:59, 11 March 2013 (GMT)

I've added your suggestion, plus one I was working on as well, to my comparison chart above. (I'm not sure how much you cranked your sat and lum, so I went for 20 each.) --Enodoc (talk) 23:56, 11 March 2013 (GMT)

Yay colors! I like Enodoc's line on the first chart, but the first column (current icon) on the second is also good; both of these color sets use shades that are around the same "intensity" (I know I'm using the wrong word here, but what I mean is that none of the colors stands out as being much lighter or much darker than the others, so they all look nice together) and they're pretty easy to distinguish from one another. Nice work, guys! ⇠eshe^talk 02:03, 12 March 2013 (GMT)

Just so you know, the two charts are using the exact same colors, just with rows+columns swapped. (Also mine is alphabetized, and I haven't added those two extra rows (columns in my case) yet). So the first column on my chart is identical to the first row on Enodoc's (and also happens to be the colors used in the currently uploaded set of icons.) If that's the colors people like, then that's great because they're already done. (Although I could change them all to use a black border instead of white and re-upload them yet again... I really should either figure out how to make a bot to do that, or find some way of uploading a whole set of images that doesn't require me to sit there doing them all one at a time...) — TheRealLurlock (talk) 02:46, 12 March 2013 (GMT)

Yeah, I did notice that—I meant the line labeled Enodoc, so the last line in the first chart. The ones in use are okay, but I like the colors on that line slightly better. To be specific, I like the purple for Falkreath and that the yellow for Whiterun actually looks yellow, plus it's much easier to distinguish between Falkreath and The Pale, etc. ⇠eshe^talk 19:50, 17 March 2013 (GMT)

(←) Just a quick comment for TRL; the capital colors are shades of colors I pulled from the guard colors. So, no, they are not all kinds of wrong. Elliot (talk) 20:38, 17 March 2013 (GMT)

Sidebar Reorganization - Revisited

Hello everyone! It's been a while since this was last discussed, but I've recently given it some thought, and I have a few ideas. For those that don't know, I wrote some code for a collapsible sidebar a while back; you can see what it looks like by doing the following:

1. Go to your Javascript page.
2. Add this on a new line: importScript('User:Jak_Atackka/sidebar.js'); If you haven't created this page, then go ahead and do so.
3. Save the page. You may have to "hard refresh". To do so, just hold down the Shift key while you click the Refresh button.

I've been using this for a long time now (as have a number of other users), and I can't imagine using the sidebar without it. It's been thoroughly debugged, and it works flawlessly on every browser I've tested, including mobile ones. However, I think it's time to move it out of my userspace and somewhere more official. There are a few options for this:

1. Move it under UESPWiki:Javascript. This is where all of the "official" Javascript applets are. This would have minimal impact.
2. Make it into a gadget. This would allow you to add it from your preferences page. This would have slightly more impact, as editors here will be more likely to stumble upon it.
3. Make it into an extension. This would implement it site-wide, for both anonymous users and editors, and would have maximum impact.

Last time this was discussed, there was strong approval from the users that tried the applet to implement it site-wide, but I want to see what everyone else thinks about this. One thing I should note is that this is Javascript only. It doesn't affect how the sidebar loads; rather, it changes the sidebar's appearance after it has loaded, which means that users with Javascript disabled will not be affected by this. • JA^T 17:05, 8 March 2013 (GMT)

Very nice...I had this on my own to-do list as well. I was also thinking about deeper collapsible menus for the main topics in each game but I think that better looked at separately. -- Daveh ^(talk) 21:10, 8 March 2013 (GMT)

(edit conflict) I would think it should go under Javascript. While it is a fancy toolbar, not everyone may find it desirable to have a fancy toolbar, so I am opposed to it being forced into use across the board. Gadgets, I know nothing of, and I won't speak of. Snowmane➚^{(talk•email)} 21:13, 8 March 2013 (GMT)

I would put it under Gadgets for the same reason Snowmane cited for making it Javascript. Snowmane: the only difference between JS and a Gadget (from the user's perspective, anyway) is how easy it is to enable/disable. A Gadget is just a check box in My Preferences whereas Javascript takes a moderate amount of knowledge to create the appropriate skin.js page. – Robin Hood  ^(talk) 22:32, 8 March 2013 (GMT)

I was running the Javascript sidebar until a few days ago, and had no problems with it. I only removed it because I just didn't want to have to click that one extra time to expand it. I think it would be more convenient for editors to use if it was a gadget. I had actually wanted to remove it a few days earlier, but couldn't remember the name of the page where it was loaded. Having it as a selectable gadget would be much simpler for those who want to use it. --Xyzzy ^Talk 00:03, 9 March 2013 (GMT)

I'm a user of your collapsible sidebar, and it is awesome. The only difference it would make to me, if it were made into a Gadget or Extension, is one less line of code in my monobook.js, which has many other modifications too. Would implementing it as a either of these options override the other changes in my own Javascript? – Daric↝talk 00:58, 10 March 2013 (GMT)

(←) RH: I meant, I knew that gadgets use the tick boxes, I meant, I don't know how easy it would be to implement it that way... Not that it matters, because whoever wants it bad enough as a gadget would find a way to make it work lol. I just wanted to clarify that I was speaking for ease of implementing it more widely. Snowmane➚^{(talk•email)} 01:11, 10 March 2013 (GMT)

It's been a while since I set one up on my test wiki, but as I recall, it's pretty simple...basically just a matter of copying the Javascript, then specifying what text to display in your preferences. – Robin Hood  ^(talk) 01:14, 10 March 2013 (GMT)

Daric: Well, it depends on how they interact. In general, though, anything on your personal monobook.js (or common.js) file takes priority over all other Javascript code. If, for example, you completely removed the sidebar in your monobook.js file, then it would be gone.

Snowmane: From what I've seen, it's fairly easy to do, and as RH said above, it mainly involves copy-pasting the code to a certain page, and then making a few other small changes.

So, is the general consensus here to make it a Gadget and make it available to logged-in users only? I personally would like this to be available to everyone, because it makes the whole sidebar much cleaner, is simple and intuitive, and allows us to list multiple significant DLC listed at once without worrying about the sidebar becoming longer than the actual article. The primary purpose of this is functionality, and it allows us to list all recent DLC (and, for that matter, all DLC) in such a way that doesn't crowd the sidebar. Although, it would also help to modernize our site some, without doing so obtrusively or in a way that's distracting. • JA^T 06:57, 10 March 2013 (GMT)

Would it be possible to put it up temporarily (a few days, a week, etc.) and add a poll somewhere asking whether users (anon or otherwise) like the new layout? Could link to it through a little question mark or phrase next to the word "sections" or as its own bullet beneath the games list, like how we have "What is this Ad?" to link to info about ads on the site. That way, we get feedback from the majority of users, not just the ones interested in the CP, which often doesn't include anons.

I'm in favor of implementing it site-wide, but if not, then a gadget would be nice. Vely^►t►e 22:15, 11 March 2013 (GMT)

It's very nice. I would have no objections to it being site-wide, but otherwise a gadget would be good. A slight niggle - the All Content link has disappeared, and that was the first thing I noticed. I think I see it in the code as being removed, so I'm sure it's intentional. What's the reasoning behind that? (I never use it anyway, just curious.) --Enodoc (talk) 22:55, 11 March 2013 (GMT)

(←) My one concern in this fancy sidebar is what kind of changes would be needed to override the thing if it was implemented site-wide? I spent many months using the fancy sidebar, being one of the first Jak showed it to, but I've since discontinued it in favor of my own list that was short, sweet, and to the point for what my needs on the wiki are. Maybe another user is the same as me, and they don't want the sidebar showing absolutely everything there is.

Is it going to be easy, if this thing were implemented across the board, for someone like me to manually override the fanciness of it in order to have a basic table? And, on top of that, is it going to be as easy as how it currently is to make such changes? As it stands, the navbar is rather navigable and customizable, and unless you specifically needed the extra features, I would rather not have that customization taken away for the fanciness of Jak's dropdown menu filled with every link the site links to. Looking at Jak's code, you'd need to have a clue what you're doing in order to make customizations to it, whereas with the current layout, it's rather easy to add or remove entries. I, personally, don't want a navbar hardwired to one set layout. I want the vast customization that the current layout provides to me, which is why a gadget for those who really want it seems more desirable to me. Jak's dropdown may look pretty, but if it's not easy to use, it's not going to be at all desirable to have, in my opinion.

I'm not saying his navbar is bad, mind you, although I might possibly sound harsh with my words, knowing how I am with words, I'm just explaining that the ability to customize it is what I find to be important. Snowmane➚^{(talk•email)} 23:10, 11 March 2013 (GMT)

Velyanthe: Exactly my thoughts. Ultimately, this isn't for our benefit - it's for the benefit of anonymous users. The only way to accurately gauge their reaction is to test this site-wide for a few weeks, and have some sort of comment submission form (like the "Report Ad" feature, except it could go to my email instead) to determine what they think.

Enodoc: Yes, I intentionally removed it, because in all honesty, it is irrelevant. We already link to all of the content from the sidebar; why have one other link?

Snowmane: The Modify Sidebar customization is fully compatible with this (or at least will be with only very minor modifications). This only alters the Skyrim, Oblivion, Morrowind, and Other Games menus, as well as removing "All Content". If this is implemented site-wide, then Modify Sidebar will be guaranteed to override this, and you'll be able to modify this as you please.

One thing we would have to decide is, which version do we use? This is technically two versions in one; you can see the other version by adding or removing the line linkGames = true; from your Javascript page; alternately, you can look below to see a (rough) representation of it. It's not very good, but it describes the difference well enough:

Difference Between Two Versions

I personally prefer the Alternate version, as it's more compact. The only difference is that with the Alternate version, you can only expand the menu by clicking on the arrow, whereas with the Default version, you can click on the unlinked word. • JA^T 23:36, 11 March 2013 (GMT)

Personally, I prefer the alternate, but I think most users will find it easier to use the default--there would be less confusion and it would be easier to handle, I think. No "Where'd the stuff go and why's there a triangle?", but rather "Where'd it all go? What if I click... aha!" Vely^►t►e 23:46, 11 March 2013 (GMT)

Okay, I tried making an extension, but it didn't work very well. I can, however, copy/paste it into the wiki's Common.js file, which has the same site-wide effect. I tested it on the dev wiki, and it works just fine, so all I need is the go-ahead to implement this site-wide for a short test period. I don't have a feedback method set up, so I guess I'll just keep an eye out for what people say. Note that anyone that is using my User:Jak Atackka/sidebar.js will have to disable it, or otherwise your sidebar will get all borked up. • JA^T 19:25, 17 March 2013 (GMT)

If you want a way to receive feedback, Jak, I have the Google Docs thing, so I can make simple feedback forms, if you like the idea and don't want to yourself, then I can share them with you. I assume, being a good personal friend, you wouldn't abuse the privilege of knowing my password if I PM'd you on Facebook? There are several ways you can do it, actually, but a brief survey of a few questions strikes me as a fairly simply thing to make, and we could have one in minutes at your desire. Or, you can download the things and run all this yourself. It's not a large download, but you don't have the best network, so everything is a pain for you. Just a helpful suggestion :P :) Snowmane➚^{(talk•email)} 20:39, 17 March 2013 (GMT)

Of course I would abuse that privilege :P. Jokes aside, though, I'm not sure that a feedback form is strictly necessary. Effectively, the entire website is a feedback form - if users have an issue with something, they bring it up on a talk page or change it themselves. What I really need, though, is more feedback from other users on this site. So far, five users have replied to this discussion, only one of which is an admin. I need the approval of more users, especially admins, before I test this out, because it is a significant change that strongly affects site navigation. If anyone is just joining this discussion, I'll be using the Default version, which is (roughly) displayed in the above ShowHide. • JA^T 22:31, 17 March 2013 (GMT)

(←) Those black, non-clickable links in my sidebar always bothered me. I've just implemented linkGames = true; and it looks much better aesthetically, IMHO. The triangles retain the functionality, but the clickable names make it look much better. My vote is for the alternate option, but I'm not an admin. Please let us know before you decide to make this change, as I don't want an "all borked up" sidebar, to use your eloquent terminology, Jak. – Daric↝talk 05:27, 18 March 2013 (GMT)

I thought I'd try out the Alternate, to join in the recent trend, and I also agree that it looks better. It restores consistency to the sidebar style that was lost by the black text. --Enodoc (talk) 18:33, 18 March 2013 (GMT)

I agree that the Alternate is much better; however, I'm concerned with whether or not people will know how to use it right off the bat. With the black text, it's very obvious that it's separate from the other entries, and I imagine that people will be like "Hm, I wonder what happens if I click here... aha!" With the Alternate, however, the only indication of how it works is the arrows, which not everyone will notice right away. However, if you feel that we'd be better off using the Alternate version (which I wouldn't mind), then we can do that. I'm still waiting on the approval of an admin; otherwise, I will implement this after waiting a week whether you like it or not :) • JA^T 18:58, 18 March 2013 (GMT)

If we had to implement this site-wide, I think the black text is ideal. Otherwise, there would be loads of people (like me, undoubtedly), who would click the blue "Morrowind" expecting it to drop as designed, only to be directed to MW:Morrowind. It's not so visibly pleasing, but on the other hand, it becomes easier to use with black drop down text. You've gotta take the good with the bad, and I'd take functionality over whether or not it's aesthetically pleasing. Snowmane➚^{(talk•email)} 19:18, 18 March 2013 (GMT)

Seems to me then that the logical answer would be to make the default one a site-wide change (joining Jak here in a call for more admin input first) and then let those who want the alternate to still be able to do so by adding linkGames = true; into their own Javascript page. – Daric↝talk 22:43, 18 March 2013 (GMT)

Speaking as an admin (since you keep asking), I'll just say that I've been using Jak's sidebar for months now and have had no problem with it. Mind you, this means that it will make no difference to me whether it's site-wide or not. And I'm honestly not sure whether an admin's opinion on this is any more valid than anyone else's. On the contrary, I probably don't use the site the same way as the average visitor, nor do most of the admins and other regular editors - which is to say most if not all of the people who have so far contributed to this discussion. But I don't really see any reason why not to just do it. The only other option I can think of is that we could potentially have both versions available as a choice in your user prefs, which would be a pretty fair compromise. Yes, you can always override whatever is there by editing your monobook.js page, but I don't think the average user should be expected to know how to do that, so a simple checkbox or drop-down list in the user prefs seems to be the best way to keep all options available. Assuming we can make that happen easily, of course. — TheRealLurlock (talk) 00:21, 19 March 2013 (GMT)

Sidebar Reorganization - Edit Break 1

UPDATE: Check out the new sidebar! I ended up implementing the default version, but I added a gadget that allows you to convert it to the alternate version - check your Preferences and you'll see it under "Gadgets". Anyone that's using User:Jak Atackka/sidebar.js will want to stop using it; if you're still using it, you can probably see why. Any feedback here is appreciated! • JA^T 02:18, 19 March 2013 (GMT)

My feedback: The links are dropdown menus, rather than the basic lists that I wanted, and, like I said, it's not desirable to me, personally. The only links on the thing that I haven't modified are the three Gamespaces that you've set to drop down, and I don't want them dropping down to show that mess of useless links. May you instruct me on how to revert it to showing just what I have it set to show? And, afterthought that's unrelated: How do I remove expansions from the sidebar? It doesn't work the same as removing a main game, it seems. Snowmane➚^{(talk•email)} 03:02, 19 March 2013 (GMT)

Well, the whole point of the sidebar was that it would contain every link that you could possibly need, yet is hidden if you don't want it. As for customizing it, ModifySidebar should work with it (if not now, it will soon). However, that really has to wait. I have 3 finals tomorrow that I have to study for, and right after that I'll be out of town for the rest of the week, so this will just have to wait. In the mean time, you can use the gadget that neatens it. This will at least give you an idea of what the anonymous users of our site have to use, and how we can improve their experience. After all, our readers come first. • JA^T 03:09, 19 March 2013 (GMT)

And on that note, ModifySidebar doesn't seem to work anymore. Please fix it when you can...I'm lost without my "toolbox" button! Alternately, perhaps after others have looked at it over the next day or so, we can revert the JS changes until you're back...unless I'm the only one having this issue. – Robin Hood  ^(talk) 04:11, 19 March 2013 (GMT)

Since it's Jak's project and wish to put his fancy drop menus on the site, I'd support reverting it to default until he's actually able to fix it properly, rather than have everyone hanging out to dry while he's off taking his exams. Snowmane➚^{(talk•email)} 04:30, 19 March 2013 (GMT)

ModifySidebar hasn't worked for me since the wiki's upgrade to 1.19 (or roughly since that point), so my sidebar code definitely isn't the culprit.

I just went on the dev wiki and tested it after disabling the collapsible sidebar, and confirmed that ModifySidebar is indeed broken. It appears that there is some sort of significant error that not all browsers catch, or at least not all the time. I tested it out for a bit, and I got it to remove one link one time, but even after hitting "Show preview" without touching the code, I couldn't replicate it. Something is definitely wrong with it; judging by the fact that it failed for me right around the 1.19 upgrade, I suspect that it's the culprit. I never touched it, so it's not me. • JA^T 04:50, 19 March 2013 (GMT)

(←) Well, until it's fixed, how about that revert for the time being until it could be given attention? Otherwise, there's gonna be a load of people who might have broken things while you're gone and unable to test and fix. Snowmane➚^{(talk•email)} 04:53, 19 March 2013 (GMT)

This custom sidebar has been actively used since last September, and in the past 8 months no bugs (major or minor) have been reported. I've tested it on multiple versions of all five major browsers, and even my iPhone, and it works flawlessly. ModifySidebar and this are two completely separate things, and at least according to my tests, ModifySidebar is completely broken, regardless of the sidebar. There's no real reason to disable the custom sidebar, unless there's a significant dislike of it, or it is causing significant problems. • JA^T 05:06, 19 March 2013 (GMT)

Jak: double-check how you're activating ModifySidebar. I remember there was something about that that made it function intermittently unless you did it just right. That's why I copied the ModifySidebar code into my JS instead of just calling it from the Javascript page. I can assure you that, with whatever changes I'd made to how it was activated, it was working fine alongside the custom sidebar up until today. Otherwise I wouldn't have complained about my missing toolbox. :) If it's not that, then load order may be an issue in some way. – Robin Hood  ^(talk) 05:12, 19 March 2013 (GMT)

Hm, strange. You're right, copying the ModifySidebar code fixes it, but I just tested your customizations on the dev wiki, and it works just fine. Very strange. Maybe you're having a caching issue?

It could possibly be that you are hiding "All Content" twice, both with the collapsible sidebar and with ModifySidebar, which is throwing an error (because it doesn't always hide them in the same order). Other than that, though, if you're still having errors, then go ahead and undo the site-wide change for further testing. • JA^T 05:21, 19 March 2013 (GMT)

I've been using both ModifySidebar and Jak's sidebar.js for some time now, under Firefox v18 and v19, and have not had any problems with them. Since the change to a site-wide drop-down sidebar, I had initial problems with the conflict with my monobook.js until I removed Jak's sidebar.js as instructed. I've also enabled the Gadget to provide the alternate version. It all seems to be working fine here, and my modifications using ModifySidebar are still in place and working fine. Just saying, my experience with the change has been positive over all, and I'm quite happy with things how they are. For me, the only difference has been one less line of code in my monobook.js, which I'm happy to revert temporarily if need be, to go back to using Jak's sidebar.js in the meantime if the site-wide situation needs fixing. – Daric↝talk 08:02, 19 March 2013 (GMT)

Did you guys both do hard refreshes? As you can see in my JS, I've reduced my changes to a simple clearing of the general section, then adding RC back in, and it still does nothing. I'll play around with it some more tomorrow...too late right now. – Robin Hood  ^(talk) 08:38, 19 March 2013 (GMT)

(←) Have you cleared up your sidebar issues, RobinHood70? If not, I'll be glad to try to investigate the cause of this problem. I assume that it might be a load order issue, which unfortunately I'm not sure how to counter. I'll ask Daveh what the wiki sets MediaWiki:Common.js and user .js browser cache times to, because it's possible caching is disabled for one or the other (it's the only other thing I can think of off the top of my head).

There have been some recent complaints about the sidebar, and I'm willing to fix them. One complaint I heard was that it's ugly, which I agree with. I originally decided to do it this way with the hopes that it would be a bit more obvious that they aren't normal links, but I'm considering switching it to the much better looking Alternate version. Another complaint was that the DLC is sorted rather arbitrarily; why, for instance, is Dragonborn listed under Skyrim, but the other DLC under "Official Plug-ins"? It's a valid complaint, and I wish I'd heard it sooner. That's why I've repeatedly asked for more input from the community. So far, about half a dozen people have contributed to this discussion, which is very bad because it gives us a very limited idea of what we need. It's hard to gauge usability when only one new person has tried it. However, it seems that nobody else is very interested in the sidebar, so I'll stop begging for more input on this, and just hope that what I do is agreeable.

Moving forward, there are a few possible changes that can be made:

• Replace the black, unlinked labels with links. It won't be as obvious that it's a drop-down menu, but it'll look much better.
• Remove the "Official Plug-ins" menu from Skyrim. The only minor DLC so far is Hearthfire, and it would just be stupid for it to have its own menu.
• Rename the "Official Plug-ins" menu from Oblivion. For Morrowind, that name makes sense, but for Oblivion, it doesn't. I'm leaning towards "Official DLC".

Discuss it, or don't discuss it. If there aren't any negative votes, then I'll implement all of these changes in a few days. • JA^T 08:20, 23 March 2013 (GMT)

As far as the grouping is concerned, what you have at present follows the namespace conventions for the wiki, as far as I understand them. I never did like like the way the UESP segregated major DLCs from minor DLCs, and I'm sure I have voiced that opinion elsewhere. But the important issue here is that it is consistent. I personally think it is consistently wrong, but I'm not going to ask you to change the whole namespace organization of the UESP wiki just so that the sidebar can become consistent with it. What you have presently, in the way of grouping, is logical, as far as the rest of the site is concerned. I don't think it needs changing unless you plan on changing the whole namespace organization of the UESP wiki as well. – Daric↝talk 12:02, 23 March 2013 (GMT)

Jak: I haven't been able to get it working, but I at least have a bit of an idea what's going on. You've done more research on jQuery and such than I have (which is to say, you've done some), so maybe you'll know. The problem seems to relate to the use of $() vs. addOnloadHook(). A while ago, I was told that the jQuery way ($()) was the way to do it, and I'm pretty sure addOnloadHook was deprecated. As I recall, addOnloadHook also caused a race condition, meaning some things would load correctly and others wouldn't. I don't remember the specifics off-hand, I just remember that JS add-ons would intermittently fail to load. Anyway, since your sidebar went into the site's code instead of being loaded by my own code, my entire common.js file fails, not just ModifySidebar. And it doesn't seem to be just me...addsince.js uses the jQuery method and that script fails too, both for me and one of my doppelgangers, unless I copy the entire script and change the $ to addOnloadHook. – Robin Hood  ^(talk) 21:06, 23 March 2013 (GMT)

A suggestion - could you replace the black with the blue, but keep the default click action being expand, with the link remaining in the sub-menu? That may make it look better but keep the functionality it currently has. I agree with the changes to the Skyrim and Oblivion menus. For reference purposes, all three Skyrim DLCs have been called "Add-Ons", coded as DLC1 (DG), BYoH (HF) and DLC2 (DB). There is no consistency within them, and no complete consistency between them and us, so I don't think the separate namespaces is a viable reason in this case for the menu to function differently. It helps with our organisation, but I don't think it means a lot to the readers as a whole. --Enodoc (talk) 23:06, 23 March 2013 (GMT)

Thanks for the feedback. I'll try to respond to you all.

Daric: We currently differentiate our DLC by the fairly good criteria of whether or not it introduces a significant, separate world space; anything that doesn't is considered minor DLC. Part of the justification for this is that if it consists of minor additions to the base game, having a separate namespace for it is infeasible. However, if we integrate the DLC with the main namespace, then we'll have significant chunks of information that are DLC-specific, and I for one hate reading a wiki on a game and learning all of this cool information, only to discover that it's DLC only. However, that's a conversation for another time.

Robin Hood: This gets weirder and weirder. Could this possibly be a browser issue? I'll definitely look into it. I may be able to replace the jQuery method with the old method, as they both are for our purposes practically identical.

Enodoc: That would be a good compromise, especially so because if people click on the link to go to Skyrim, it'll instead expand the whole menu.

One other thing I could do is move Knights of the Nine under the main Oblivion menu, next to Shivering Isles. I think Enodoc is right - our sidebar doesn't necessarily have to line up with our namespaces. The namespaces are primarily structural, whereas the sidebar is just for convenience. Personally, when I think of Oblivion DLC, the two that pop in my mind are SI and KotN, so I think it makes sense to move KotN up. • JA^T 07:25, 24 March 2013 (GMT)

so i was making a similar point on the talk page for dragonborn but i will also post it here, the sidebar for navigation is there for ease of use, so the most important factor in my mind is keeping it easy to use. making loads of changes some of which are a bit random makes it annoying to use. a lot of it is deciding when something gets its own bar which seems to be solely based on namespace. so you could change the bar to name the location instead of dlc or plug in so it says skyrim, skyrim and lists all the plug ins associated with the mainland and then skyrim, solstiem (sp?) and lists those games, i.e. dragonborn. and do the same with oblivion and morrowind which would get you the same setup but with more clear reasoning behind the order. the other point i would make for skyrim being as there are only 3 plug ins once you click the skyrim tab its far to assume that people would like to see all 3 listed there without additional links. i understand the 9 oblivion minor dlcs being cluttered but having a separate menu for plugins that arnt dragonborn to list the other 2 seems like a waste of time. i mostly really miss being able to logon to uesp and click heartfire right away to get to construction pages, now i have to go through so many levels i end up just typing it in the searchbar instead, negating the purpose of having a quick navigation page. my 2 cents--Lord.Baal (talk) 08:59, 24 March 2013 (GMT)

(←) Thanks for the reply, Jak, and yeah, for another time. In fact, I've had that discussion before, and I understand UESP's position, I just think it is wrong, personal preference and all that. Speaking of which, I am opposed to Enodoc's suggestion, on the grounds that, if you set the color of those "pseudolinks" (as I call them) from black to blue, to match the other links in the sidebar, you could be getting them out of step with those of us who have customized our browser's color scheme. What most of us see as blue links or purple visited links are actually A:link= and A:visited= variables which can be set in the browser's preferences. – Daric↝talk 09:19, 24 March 2013 (GMT)

My god, these sections get so large and unattractive, forgive me for not reading this rambling. Here's the deal: the alternate sidebar is still not correct because the only things that need to be dropdown are the Official Plugins, and the Other Games I suppose. And then, don't call the Skyrim DLC 'Official Plugins', stick to the official name, and especially don't separate Dragonborn from the other DLCs because that's complete bullcrap. Don't tell me how DB has it's own namespace and DG doesn't and that's why, because that's clearly a huge error that needs to be fixed, but let's leave that discussion for another section ~ Dwarfmp (talk) 10:53, 24 March 2013 (GMT)

I don’t think this should be a discussion about what looks good to us, it should be a discussion about what looks good for the players out there – the people that hits the site for information. The recently changed sidebar makes it even more difficult to navigate the site and find what you’re looking for (and we are notorious for being difficult to navigate in the first place), so it needs to be tweaked. I have absolutely no idea how, as I found the old sidebar to be the best solution. I’m also unsure why it had to be changed in the first place? Why not show that we have content for ALL games in existence instead of hiding old games like Redguard away like dirty secrets? Why hide the Dragonborn namespace? If it is because the sidebar gets too long, then I’m pretty convinced that people will figure out how to scroll the page down before they find the tons of hidden subsections we currently have. Like I said, I have no idea how to improve the old sidebar and I’m open for suggestions – but why fix what wasn’t broken? --Krusty (talk) 11:34, 24 March 2013 (GMT)

Firstly, I agree with moving KotN up to being under the main Oblivion entry. It is considered seperate to the other DLCs in the Official Guide as well. Perhaps, as Krusty says, it is better to avoid hiding everything for each section, and instead hide those entries which were not there before, namely the extended plug-in/DLC lists and TES Travels menu. Regarding the blue, as I mentioned before, would it be possible to code the js to read the defined A:link colour (whether that be blue or otherwise), to fix the problem of colour preferences mentioned by Daric? --Enodoc (talk) 15:58, 24 March 2013 (GMT)

i am loving what i am hearing right now, all good points, i would say the biggest being why fix what is not broken, did anyone complain about the old sidebar and having a few items showing under each game? the new style is definitely worse. i also wanted to comment that the guy who mentioned the namespace disputes about dawngaird and dragonborn is dead on, dawnguard could easily get its own namespace as it has a large number of new quests and quite a few new areas to explore. a poll of users would be nice to see what they prefer since so few ppl actually comment on it and i would love to see what a large sample of users think.--Lord.Baal (talk) 04:23, 25 March 2013 (GMT)

Sidebar Reorganization - Edit Break 2

The only part of the sidebar that seems to be under dispute here is the Sections group, which we cannot seem to edit, as regular users, through the use of ModifySidebar() in our monobook.js files. Is there any way that we could have access to the Sections group, so that we can set up the sidebar to our heart's content, the same way we can do for the Toolbox (p-tb), General (p-general) and Community (p-community) groups? – Daric↝talk 06:00, 25 March 2013 (GMT)

Okay, I implemented the suggested changes. I'm trying to figure out why ModifySidebar isn't working, because it makes absolutely no sense. It works perfectly on the dev wiki, but when the exact same code is used here, it seems to throw a syntax error. I'm still looking into it. In the mean time, though, you can try out the (IMO) improved sidebar - disable the gadget that alters this to see the full effect. I'm also preparing a much more in-depth response to the concerns brought up thus far, but right now I am completely exhausted from my out-of-town trip, and it'll be a few days before my mind clears enough for me to make a complete response. • JA^T 00:18, 27 March 2013 (GMT)

It's about time I've explained myself - why I made this, why I implemented this without full consensus, and what I plan to do about it. I'll put it in a Showhide, so as not to completely throw off the discussion.

My Thoughts

"Why?"

There have been quite a few discussions about modifying the sidebar, and some of them have gotten pretty heated. It basically boils down to two opposing, equally valid viewpoints. One is that the sidebar is meant for navigation and ease of use, and thus should have any links that users would find useful. The other is that the sidebar has to maintain structure, and frequently changing it isn't good for our users; also, overly long sidebars are bad. As a compromise, I created this. Combining the ease of use and number of links of the first option with the conciseness of the second option, it allows us to neatly display any useful link that we could possibly want, without worrying about the sidebar becoming polluted or messy.

"Does it actually make a difference?"

I'd say so. To look at the unaltered sidebar, just go to Special:Preferences. With the old sidebar, we were running into numerous pages where the sidebar was longer than the article itself, which is a very bad design (look at dailymail.co.uk to see what I mean. We don't have it that bad, but it shows why that's a bad design idea). In addition, every time a new DLC was announced, the site would devolve into a massive argument over what links should go and what links should stay, only to end in a thin, forced consensus in which the other 49% of the users were left unhappy. I decided that we needed a more permanent solution.

"What's with the Official Add-ons/Plugins? No one needs those."

Honestly, yes, they are rather useless. However, I figured that since I was making an all-inclusive solution, I could simply add those two collapsible menus and cover all of the bases with very little space impact. I've actually had to use those sub-menus a few times, so they are useful - just very rarely.

"Why are all of the other games under "Other Games" instead of being displayed?"

This was the one thing that I wasn't so keen about. However, in the end, I made a conscious decision to do so, for one reason only: It saves a lot of space, by replacing six entries with just one. All of the games are still there, and I didn't call them anything potentially demeaning like "Spinoff Games", but if you can think of a better term, you're welcome to suggest it.

"Why did you implement this site-wide without full consensus?"

I mostly did it because there was no other way. Having seen the way that these discussions have played out in the past, I know that consensus is never reached; the closest thing is a slight majority. The discussions either devolve into a shouting contest or simply stall, because no action has been taken, because consensus hasn't been reached, and so on. This creates a vicious cycle in which nothing gets done, so sometimes you have to step up and do something, in order to move the discussion along and to ultimately get something done. That's the reason why I did it without complete consensus; the reason why I did it in the first place is completely different. Vely suggested implementing it site-wide for a trial period, and I agreed to do it for two primary reasons - because it's the only way to see what it's like site-wide, and the only way to truly get community-wide feedback. This has been successful in that regard - users outside of this discussion began contributing ideas, many of which I ended up adopting.

I apologize for stepping out of line a bit by forcing a consensus and implementing it site-wide. I feel that it was justified, though, because the discussion would likely have not progressed without it, and it was the only way to get more than half a dozen people to share their thoughts on it. Now, having said that...

"What will you do now?"

The sidebar has undergone a two-week trial period, during which point it has received significant feedback from the community and has been modified in order to address the concerns that were brought up. There are only two loose ends left - renaming the "Official Add-ons" sub-menu under "Oblivion" (which is a discussion of site-wide concern), and resolving the last minor technical problems it has with ModifySidebar. Note that most of the technical issues have been fixed - the only thing still affected are the collapsible menus, and that can be worked around by using clear and rebuilding the sidebar, as Daric Gaersmith has done. However, those are minor concerns.

What really needs to be done now is deciding whether or not we keep the sidebar. I got the site-wide trial period that I wanted, so I will keep quiet and accept whatever decision the community makes. If it decides against using it site-wide, then I'll make it into a user Gadget, and not bring up site-wide adoption again. • JA^T 07:06, 3 April 2013 (GMT)

In light of other discussions here about namespaces, I have changed my former viewpoint that the consistency between the sidebar and the namespaces is paramount. I now don't see this as desirable at all, and that we should instead make the sidebar become completely independent of the underlying namespace infrastructure, and focus it entirely on making the site more navigable for our readers. There is no good reason, as others have pointed out, to reflect the underlying organizational decisions (that are only of interest to editors), and impose them on the average reader of the wiki through use of the sidebar.

Having gotten that off my chest, I'd also like to commend what Jak has done here. My decision to modify my own monobook.js is not meant in any way as a slight against Jak's sidebar modifications. In fact, I consulted with Jak about my changes, so that they might be used (as he has done above) as an example of what could be achieved if people really do not like the collapsible sidebar. I personally prefer the collapsible sidebar myself, but I do have reservations about the naming of the "Official Add-ons/Plugins" as Jak has mentioned above.

You may notice in my monobook.js that I have a set of ModifySidebar() entries for a "gaer" group to be added to my own sidebar. This currently doesn't work, we cannot add our own groups to the sidebar yet, as far as I know. I've also copied this to the developer website in the hope that we can somehow get this part working. — Daric✐ 09:54, 3 April 2013 (GMT)

I really like the new sidebar, even though some details bug me a little. First, the difference between collapsible and non-collapsible names isn't very obvious; the icons are the same color and just slightly different shape, it's doesn't scream "click me, I'm collapsible". Also, I guess we could make the game names a direct link instead, or would that cause too many people to accidentaly click the name instead of the arrow?

Second, while there is currently little in the way of small Add-ons for Skyrim, they do exist (does the texture pack even count?), and there is currently no direct link toward them. While the chances of having other small DLCs are thin, thanks to the evergrowing modding community, it's not impossible. Also, even though it's only my opinion, I think Hearthfire doesn't fit with DG and DB and would be better under an "Official DLCs" or whatever you want to call it.

Regarding that last point, I think we should keep consistency in the way we name Add-ons. If Bethesda wants to change their naming convention for each game, so be it, but do we really have to follow their example? Calling KotN or SI a "plug-in" is completely ridiculous, that kind of name only fits the 1 or 2 dollars Add-ons, and "DLC" only means that it's downloadable which, in Oblivion's case, is not always true. "Add-on" encompasses both smaller and bigger content, downloadable or not. I guess we could use "plug-in" when it comes to smaller ones, but we'd have to draw line regarding size and price. -- Elakyn (talk) 11:07, 3 April 2013 (GMT)

I'll leave the naming of the "extras" to the other discussions, but it would perhaps be better aesthetically to have them named the same on the sidebar. I agree that having the non-links the same color as the links on the sidebar is misleading, they should be different. On Hearthfire, it may be time to relegate it from the sidebar completely, Fall of the Space Core is the other official "thingie" so it would be the only one not there. There are plenty of other discussions about how to name them, so lets not start it here. While initially skeptical of what improvements could be made, I understood Jak's need for a site-wide test. I don't use that portion of the sidebar all that much, and when I do, it's usually just to get to the namespace quickly. Reducing the sidebar to a collapsible state allows us to push the older games back up into view. Also, with such small icons (the arrows), at least to me, its hard to distinguish them at a glance. Naming of sections seems to be an issue here, so perhaps we can split that off, and focus on whether we want the new style or not, I'm in favor of it. Silence is Golden^{Break the Silence} 19:28, 3 April 2013 (GMT)

I agree that the blue, link-colored labels are misleading, but ironically that's a good thing. Previously, the labels were black, and although it made it obvious that they were different, they were really, really ugly. By having them be link-colored, people will click on "Skyrim" thinking that it'll take them to Skyrim, but instead it expands the menu, making it instantly obvious what's going on. This actually tricks new users into learning how it works, while looking aesthetically pleasing at the same time. Having said that, though, if anyone has a suggestion for how to recolor it or otherwise make it obvious that it's a collapsible menu, you're free to suggest it. I could keep the labels link-colored and italicize them.

As for Skyrim DLC, I decided during the last change that since there are only 3 DLC, it made more sense just to have them all under "Skyrim" instead of under "Official Add-ons". However, once we start seeing the fourth and fifth Skyrim DLC (nor however many there are), we can re-add an "Official Add-ons" menu and add Hearthfire, Fall of the Space Core, and the Hi-Res Texture Pack to that menu. I could add that menu sooner if people would want that. However, we really need to come up with a consistent naming scheme for the DLC before I do that, and that's a whole other discussion. • JA^T 21:45, 3 April 2013 (GMT)

Dragonborn Peaks YT Video

Regarding the discussion on DB talk:Mortrag Peak, it was suggested that, in order to facilitate the climbing of the four mountains on Solstheim, the inclusion of a YouTube video may be beneficial. Jeancey suggested starting a topic here to see what people think about having an exception to the YouTube video restriction for this purpose. It would also serve as a visual guide to the text directions, particularly in the cases where it is not clear what features are being referred to in the text. --Enodoc (talk) 15:51, 11 March 2013 (GMT)

It doesn't seem necessary to me. It's just platforming. —Legoless (talk) 22:12, 11 March 2013 (GMT)

Platforming? Sorry, no idea what you mean, Legoless, unless you are referring to platform games, which I never play anyway, as I'm into RPG games like TES, not "platformers". Just dismissing this as a gamer skill that RPG players aren't known for, is not helpful, sorry. I've been trying to follow Enodoc's directions, but I'm going to have to rely on the YouTube link that was provided on the Talk Page, because I just cannot work it out without a visual representation. I'm pretty sure I'm not the only one that visits the UESP for help with completing tasks such as this, who is a visual learner rather than textual. A picture is worth a thousand words, and a video is worth ten thousand. – Daric↝talk 07:09, 15 March 2013 (GMT)

I'm going to chime in against using a youtube video here. If someone can't follow the text then the text needs changed, as has already happened after the original editor of the directions watched one video. The UESP is primarily a text based site, and one video has already been linked on the talk page for those who want one. A few visual aids wouldn't go amiss though, in the form of pictures, possibly one with the route marked on it (we already have those type of pictures linked from certain pages). Silence is Golden^{Break the Silence} 19:06, 15 March 2013 (GMT)

Perhaps an aerial view of the route with the route marked on it? Jeancey (talk) 19:37, 15 March 2013 (GMT)

Is there really just one route? Whenever I climb mountains, I usually just improvise it. If you know the tricks, you can usually find your way up just by doing it. Maybe just a link to Mountain Climbing would be sufficient. It feels like much more of an achievement if you find your own way up, and any kind of map or guide or video implies that there is only one valid route to the summit, which is generally not the case. — TheRealLurlock (talk) 19:45, 15 March 2013 (GMT)

So, having just investigated this myself, I found my way to the top of Moesring Mountain 4 times, and Mortrag Peak twice, using very different routes. (Wasn't intentional - the hardest part is climbing to the top and then not going too far and falling to your death. Frykte Peak and Hvitkald Peak I made it to the top and back down safely on the first try.) I used Arvak each time. I don't think it's necessary to have a horse on any of the peaks, but I used him on all but Hvitkald. (The faster speed of the horse might explain why I kept overshooting and falling off. Might be safer on foot, though much slower.) Anyhow, I'm not sure if watching any video or looking at an aerial map would have made that easier. The only thing I can think of that'd help would be distant shots of each peak from several different angles, so you know which mountains to climb (many generic mountains look promising, and you can waste a lot of time climbing the wrong peaks, since you can't tell you're on the right one until you're almost at the top), and obviously an overhead map (just showing the locations of the markers, not the route(s)), which may have to wait until we get an interactive map of Solstheim. — TheRealLurlock (talk) 20:45, 15 March 2013 (GMT)

(←) From what I understand of this discussion then, linking to someone else's video from a talk page, as Enodoc did, is okay, but we shouldn't have video content of our own on article pages. Is that the general consensus? If it is, I'm quite happy with that. I can't summon Arvak, by the way, as I already have two followers. – Daric↝talk 23:35, 15 March 2013 (GMT)

That wouldn't stop you. Arvak is a summoning spell, which is counted separately from your followers. I actually have THREE followers in addition to being able to summon Arvak (Serana, a normal follower, and the Steadfast Centurion Sphere). Arvak is limited by your summon cap - you can only have one, or two with the Twin Souls perk. Now if you've got a Thrall of some sort following you around, that would count against Arvak. But 2 normal NPC followers (I assume one of them is Serana) and even a creature follower won't stop you. — TheRealLurlock (talk) 04:51, 16 March 2013 (GMT)

Interesting, and I know we're straying off topic now, but I have the Twin Souls perk and my Conjuration skill is leveled to 100% yet I can not summon anything, not even a simple Familiar, while I have two normal followers, Serana and Borgakh. I tried saving first (for testing purposes), then I dismissed Borgakh, and all of a sudden I could summon again, including summoning Arvak. Feel free to move this discussion to a more appropriate place if you think it's necessary. – Daric↝talk 09:12, 16 March 2013 (GMT)

Morrowind Overhaul Project

So as many of you may know, I have been extremely interested in bring the morrowind namespace and those of its expansions up to par with the quality of the later games. To that end, I have drafted a Morrowind Overhaul Project (or MWOP) and I would like to get everyone's opinion on it. Have I missed anything (likely)? Did I make any mistakes? Is there anything else you think could, or should be added or changed? Thanks in advance guys. Just to note, the templates involved aren't done yet (I am going to start on them now), so if you have any ideas about that, feel free to let me know! Thanks! Here is a link to the project page in my sandbox! User:Jeancey/Ehnii. Thanks again! Jeancey (talk) 17:50, 14 March 2013 (GMT)

Just a bit more here, I have created three templates that will be placed on NPC, Place and Quest pages, respectively. If I could get your thoughts on those as well, that would be great. :) They currently have lots of red links because they aren't in the correct namespaces but eventually they will be named {{cleanup-mwop-npc}}, {{cleanup-mwop-quest}} and {{cleanup-mwop-place}}. Thanks again! Jeancey (talk) 18:50, 14 March 2013 (GMT)

I like this! I would surely join it! - Chez ^{talk • email} 05:58, 15 March 2013 (GMT)

Instead of making a whole new project, why not just resuscitate the already existing Morrowind Redesign Project? I'll hand over the reins if you want - until I get a replacement for my lost MW discs, there's not much I can do to help out. But it seems that having two projects with essentially the same goals is just redundant. — TheRealLurlock (talk) 12:34, 15 March 2013 (GMT)

That would make sense, sure, but there's no harm in updating the guidelines too. I haven't looked at the MRP in a while, but I would guess that some of our standards have changed a bit since then, and I bet there are some things we do with Skyrim pages that would really spruce up the Morrowind namespace too. I haven't had a chance to really comb through your guidelines yet, Jeancey, but I'll hopefully get to that today :). ⇠eshe^talk 13:28, 15 March 2013 (GMT)

The main issue with that is that it would seem that the guidelines for this project were, unfortunately, extremely small. The only thing I can see that was done was fill out infoboxes and basic blurbs, finish quests, and create maps for every area. In order to bring this project up to snuff, I would have to rewrite the ENTIRE thing, which is the exact same as starting a new project. All of the things covered under the MRP were completed, and the MWOP would address completely different things. The guidelines I have written might not even be complete yet, and they are still many times longer and more detailed than the old project. I looked into reviving the old project, and it would seem that reviving might actually be more work than creating a new one. Because they are so widely different, it doesn't seem to make sense to completely overwrite another project with new things, negating the old one, when it was clearly completed successfully in terms of its guidelines. A new project allows for new guidelines, without interfering with the old one. I may have repeated myself there a bit, but I definitely thing that Morrowind deserves a new project, not the retooling of an old one. MWOP is basically the ONPCRP, SQRP, and the OPRP rolled into one. There are three separate templates, three whole sections of work that can be done. There just isn't any overlap with the old one, at all. Jeancey (talk) 14:20, 15 March 2013 (GMT)

(←) I have launched the project. If anyone has any comments on the project guidelines, questions, concerns, etc. please direct them either to the project talk page or my talk page. :) Jeancey (talk) 21:33, 12 April 2013 (GMT)

Voice Types

Okay, the long-delayed NPC Voice Types project is off to the races. It's currently running at a much higher rate of speed than previously due to a discussion Jak had with Dave some time back where they agreed that our bots didn't really need to follow Wikipedia's standards. As usual, please let me know if the bot's screwing anything up (very quickly) or if the new-found speed appears to be creating a lag. Due to the large volume, I won't be monitoring it closely, so post to the bot's talk page if you need to make it stop.

Also note that due to my current database setup, I have to do each mod separately, so you will actually see several bot runs before it's done. Skyrim will be tonight's; I'll do the others over the next day or two. – Robin Hood  ^(talk) 04:34, 20 March 2013 (GMT)

Before anybody bugs me about it, yes, I am aware of this little oversight. The bot actually handles multiple edits to the same page correctly...except I forgot to account for section links from redirects. I'll fix it for the various mod runs, though they're less likely to run into the problem in any event. – Robin Hood  ^(talk) 05:44, 20 March 2013 (GMT)

Should we list the names of the actors when known? I know I added a few to Voice Actors earlier, because I actually met her at a convention, and she had some of them listed on a poster. (And apparently she did a lot more than the ones she listed.) I'm not sure if we know which actors go with which voice types in all cases, but for the ones we do, we should make that info available somewhere. Either add a link to the category on the Voice Actors page, or add a link to the row in the Voice Actors page to the category pages, or both maybe. Not sure if we should mention it in the NPC articles themselves, though I think we do for some of the major characters. (Mostly only those with unique voices not used by any other NPCs.) — TheRealLurlock (talk) 12:40, 20 March 2013 (GMT)

If you mean add the name of the voice actor to the NPC pages, that would be silly. We only do that for unique voices (as in used for one NPC). The voice type names as they're added to the NPC pages can be added to the Voice Actor page if it hasn't been done already ~ Dwarfmp (talk) 16:50, 24 March 2013 (GMT)

No, not on each and every NPC page, but maybe the category ones? A note, like "NPCs with the MaleNordCommander voice type are voiced by Paul Ganus" or something along those lines. Elakyn (talk) 17:12, 24 March 2013 (GMT)

Wiki_Fi

Hey there. I've been working on a little side project that I thought you guys might be interested in. It was originally intended for the Team Fortress and Portal Wiki but I've extended it to more wikis since. I wanted to know if you guys were interested in getting included :) It requires no work on your part at all, just your blessing to collate the information from the wiki API for display. What do you think? Moussekateer (talk) 19:33, 20 March 2013 (GMT)

Sounds alright to me, how about everyone else? Vely^►t►e 21:59, 21 March 2013 (GMT)

I like graphs... --Xyzzy ^Talk 04:08, 22 March 2013 (GMT)

Image Category Needed

Hey guys. Silencer reminded me that I had an abandoned project sitting in one of HnB's sandboxes to clean up our User Images file names. That's all done now, with one file remaining that's proposed for deletion and one that I just have no clue what to do with. Fivetenets.jpg started out as a User image, but now it's used on Lore:Dark Brotherhood as well. I don't know our image categories very well, nor am I even 100% sure if that comes from Skyrim or one of the other games. Can someone savvy have a peek at it and figure out what to do with it to get it out of User Images? Thanks! – Robin Hood  ^(talk) 06:17, 23 March 2013 (GMT)

It looks like a slightly altered version of File:SR-place-Dawnstar_Sanctuary_Tenets.jpg. --Xyzzy ^Talk 06:44, 23 March 2013 (GMT)

I'm wondering if it might be a direct export of the texture file. That would account for its clean appearance. – Robin Hood  ^(talk) 07:46, 23 March 2013 (GMT)

Gemstone Geodes

I've begun a discussion here about whether the redirect from Skyrim:Geode_Vein to Skyrim:Blackreach should now be severed, being that Dragonborn has introduced another type of Geode Vein now. As the page itself is currently redirected, I'm concerned that people won't be able to see the discussion either, that's why I have posted a link to it here. – Daric↝talk 12:37, 23 March 2013 (GMT)

I also brought this up here, but nobody replied at all. I think it's just because of the work that'd be required to document the locations of all gem geodes. (Geode Veins are easier, since they're pretty much all in one location.) — TheRealLurlock (talk) 13:52, 23 March 2013 (GMT)

Thanks TRL. Looks like a job for a Gaersmith then. I'm on it. I've made a start, collecting web resources into my Sandbox 'Or'. The content for the Geode Vein page itself will be built, from the gathered resources, in my Sandbox 'Un'. Both my Sandboxes 'Or' and 'Un' are open to collaboration for anyone who wants to help out. This will be my first major page building exercise in article space, so I'd like as much input and feedback as possible. I'll be following the style of Skyrim:Mining for this page, as it seems to be the closest match. – Daric↝talk 23:54, 23 March 2013 (GMT)

I was chatting with Dwarfmp last night in IRC about this, and he raised an objection to having both main game and DLC content on the same page. I just thought I better get that clarified before I go any further with this, as my intention is to keep information about the Soul Gem Geodes of Blackreach and the Gemstone Geodes of Solstheim together on the Geode Vein page. Comments anyone? – Daric↝talk 21:17, 24 March 2013 (GMT)

I do not think they should be put together. I dont really understand what 'Geode' means (Im sure what im thinking of is wrong! o.o) but other than the word 'Geode' they have nothing in common. Adding a section on the Blackreach page should be fine. I do think Amethyst Geode, Emerald Geode, Ruby Geode and Sapphire Geode could all be made into a redirect to keep them together on one page. Maybe call the page Mining? Then it could include Stalhrim and Heart Stones aswell. — Kimi the Elf ^{(talk | contribs)} 21:40, 24 March 2013 (GMT)

I'm not in favor of separating everything, I think a "DB" next to the name is enough to distinguish all the creatures/items/places/etc... But I guess we could make as Kimi said, a Dragonborn mining page with redirects and description of the "new" geode veins and keep the Blackreach ones on a separate page. Now should we make an entire page, or put them with Blackreach or soul gems? Elakyn (talk) 22:00, 24 March 2013 (GMT)

Even if they was in the same namespace I would have said to seperate them because they have nothing in common. For the soul gem ones I doubt there is enough to write about them to have their own page. Redirecting to Blackreach or Soul Gems and having the information there should be fine. I would probably go with Blackreach as thats the only location and they give more than just soul gems. — Kimi the Elf ^{(talk | contribs)} 22:07, 24 March 2013 (GMT)

I'd agree - grouping Geode Veins with Gem Geodes is loony. They have nothing in common. It'd be like "Red Mountain Flower" on the same page with "Redwater Den" because they both have the word "Red" in the name. Now if we were putting ALL mineable items on one page, that would make some sense (though it might be a tad long). But there's no particular reason to group Blackreach Geode Veins with Gem Geodes other than that. (For the record, a geode is usually a hollow rock with a crystal formation inside.) — TheRealLurlock (talk) 01:54, 25 March 2013 (GMT)

Some good news. I've found all the Gem Geodes in the wildness :) The page has been updated. Shall we remove the incomplete templete now? Dreamshadow (talk) 08:36, 29 March 2013 (GMT)

(←) Thanks everyone, great feedback (well, apart from Kimi's "geodude", that is, hehe). As TRL said, a geode is a place where crystals form inside a rock. We mine metal ores (iron, corundum, etc) and soul gems in the game the same way as we now mine gemstones, stalhrim, and heartstones. All it takes is a pickaxe (or, in the case of stalhrim, an ancient nordic pickaxe). The Soul Gem geode veins of Blackreach have more in common with the new Gemstone Geodes, than they do with any other place where you can "swing a pickaxe". They both encompass the concept, as TRL mentioned, of yielding crystals rather than ores. For the sake of argument, Stalhrim is neither an "ore" nor a "geode", as it is enchanted ice, whereas heartstones, well, I'm not even going to go there!

If it is agreed that these should all go together on the Skyrim:Mining page, I'm happy with that. If a new Dragonborn:Mining page needs to be created for gemstone geodes, stalhrim, and heartstones, that's fine too. But I'm surprised that no-one else here can see the similarity between the Blackreach geodes and the new genstone geodes. It is not just a shared common word, as TRL implies above, it is a scientific concept, as TRL linked to above. – Daric↝talk 03:21, 25 March 2013 (GMT)

I was reading what you wrote in This Sandbox, but I feel that is way to complicated. I have no idea what I just read, and im not sure its really relevant to the game... I think it would be better to focus more on where you can mine, what you get from mining and what you can do with it. — Kimi the Elf ^{(talk | contribs)} 07:02, 25 March 2013 (GMT)

Most of the description reads as complete speculation, an issue which I've brought up here. —Legoless (talk) 15:56, 25 March 2013 (GMT)

Yeah, you can't use real-world science to try and come up with explanations for things in a game. So much of ES follows its own rules that trying to think like a real-world geologist is just silly. Rubies appear next to Emeralds because that's where the developers put them. Unless there's' an in-game source corroborating any of that info, it's just guesswork, which doesn't fit on this site. As for the similarities between Geode Veins and gem geodes, again, the only thing really in common between these is that they have the word "geode" in them and produce items that are crystalline in nature. But in terms of gameplay, the gem geodes have far more in common with standard ore veins than with Geode Veins, because gems can be used for crafting items, while soul gems cannot. (Enchanting being a completely different process from Smithing.) Plus, you can also randomly find the same gems by mining most regular ore veins, but not from Geode Veins. Whether an object is crystalline in nature or not is basically irrelevant to the player. Moon Sugar is technically a crystal, as are Fire/Frost/Void Salt and Salt Piles. But we don't treat those any differently from other ingredients. — TheRealLurlock (talk) 16:12, 25 March 2013 (GMT)

Okay, I surrender. I'll just stick to fan-fiction writing from now on. — Daric✐ 01:24, 26 March 2013 (GMT)

Social Media Pages & Content

Hello everyone - your favorite s'wit is back. (Or least favorite; I won't judge.) I've been helping Dave with the site's new social media pages and wanted to see if anyone wanted to contribute anything. I've been doing a "Screenshot of the Week" category that would be easy for anyone who likes to take screenshots (in any game) but isn't necessarily interested in having them be Featured Images (or who has a beloved screenshot that didn't make it as a Featured Image). If you could send them my way it'd be most appreciated.

Alternatively, and as well, you're welcome to use it as an outlet to share things. We already share featured articles and images from the wiki; if you ever wanted to go into blog updates or anything of that sort, it's an option. Maybe even sharing random "Did you knows" with links to articles would be entertaining. In any case, just wanted to put that out there and remind everyone that it's something open to the community and sharing all of the great content on UESP, wherever it is. Feel free to e-mail me or swing by my talk page for any ideas, suggestions, or what not. Thanks for all the hard work! --Avron the S'wit (talk) 17:33, 29 March 2013 (GMT)

I have several ideas, mainly for a Q&A place for everything Elder Scrolls. no idea how to get people to ask us questions though :P I'll talk to you about it more later, I'm in class right now :P Jeancey (talk) 18:26, 29 March 2013 (GMT)

In my experience it's harder to get content than to provide it (point of proof just being this CP section here). It's easier to simply provide things that reflect UESP as a community, I should think. --Avron the S'wit (talk) 13:32, 30 March 2013 (GMT)

Dawnguard vs Dragonborn

I'm sure it's been discussed before and it was all looking right back then, but I think we all know now that the current situation is all wrong. I've been holding off on bringing this up because it's not going to be an easy matter, but I'm just gonna go ahead and get this off my chest. To put it clear and simple: officially, Dawnguard and Dragonborn are of equal status and importance as DLC. As of now though, Dragonborn has its own namespace while Dawnguard doesn't, and that is just wrong.

There are two ways to fix this:

• Remove Dragonborn's namespace and intergrate it like Dawnguard is integrated.
• Give Dawnguard its own namespace.

I would say the second course is the good course. That's pretty much all that needs to be said. ~ Dwarfmp (talk) 22:37, 29 March 2013 (GMT)

Aren't namespaces used for ease of organisation? Dragonborn needs the split, whereas Dawnguard is far better off being integrated. I don't see the need to change. —Legoless (talk) 22:50, 29 March 2013 (GMT)

Ignoring the contestable point of them being equal, that still ignores the fact that the content that Dawnguard adds neatly works with Skyrim as it is. Dragonborn is almost entirely split off and it makes more sense to keep Skyrim and Dragonborn at arm's length to another. There really isn't any benefit in not having Dragonborn split off, while Dawnguard's content is a better fit with the content that it actually changes. --AKB ^{Talk Cont Mail} 23:04, 29 March 2013 (GMT)

I know this has been discussed at length previously, as Dwarfmp said, both here and in IRC, but there are still voices that need to be heard, I believe. The "silent majority" of people who consult the UESP but aren't "Editors" should have a say on this, I reckon. Let's put up a poll on the front page of the wiki, and gather some feedback. — Daric✐ 23:23, 29 March 2013 (GMT)

Is the average site user going to notice or care which add-ons have their own namespace? As long as they can click on the appropriate links to get the info they want, I don't think that where we arbitrarily differentiate between minor and major add-ons, and hence which ones get their own namespace, affects the average site visitor at all. If I am correct in this assessment, then the debate about which add-ons to split off into their own namespace and which ones to incorporate into Skyrim becomes just a matter of ease of integration, with a bit of personal preference thrown in.

Can someone please explain to me, and by extension anybody else who doesn't understand this, why ALL Skyrim content, including add-ons, can't just be included in the Skyrim namespace? Is there some aspect of this that I'm not aware of? It seems like this has become a serious point of contention, so I would like to understand why separate namespaces for large expansions/add-ons/whatever are necessary. --Xyzzy ^Talk 23:38, 29 March 2013 (GMT)

So far, we have been incredibly consistent in how we make our namespaces. Main games get their own. Any DLC that adds significant landmass where 90+% of the content in that DLC takes place also get their own namespaces. Bam. Done. Already consistent. This definition works for every single DLC that has been released, for every game. Bloodmoon, new landmass, All quests take place there. Same with Tribunal, same with Shivering. KotN, the content is spread across all of Cyrodiil, not in a single new landmass, thus, no namespace. Dawnguard, content is spread across all of skyrim, not in a single new landmass, thus, no namespace. Dragonborn, new landmass, majority (except one or two) quests take place on the new landmass, thus, it gets its own namespace.

I don't understand why people can't seem to see the difference between Dawnguard and Dragonborn, and the similarities between them and KotN and Shivering. It is very clear to me why the namespaces exist, and why they are split the way they are. I just don't see any logical reason why they should be different.... Jeancey (talk) 23:51, 29 March 2013 (GMT)

I don't think it's about consistency. Would anyone really make the difference if Tribunal and Bloodmoon were merged with Morrowind? It's the same thing here. Yes, there is a lot of new stuff added by Dragonborn and it's obviously different from Dawnguard. But claiming "we did this before, let's do it again" won't convince many people. Anyway, this is the Easter Egg debate all over again, it won't change anything. Elakyn (talk) 23:56, 29 March 2013 (GMT)

(←) (edit conflict) Jeancey, the status quo does not have to remain so, if there is a significant body of the community who disagree with it. According to the Consensus guidelines, "any issue can be reopened for discussion, even if a consensus was previously reached, if an editor feels that there is a need". That same page also suggests avoiding (wherever possible) turning a discussion into a vote, but "some decisions based purely on stylistic preference may not be amenable to a compromise solution". This issue of DLC priority is about "stylistic preference", and in my view a vote should be taken. — Daric✐ 00:03, 30 March 2013 (GMT)

+1 for no need to revisit this. I think the distinction between plug-ins and expansions, as discussed during the creation of the DB namespace, is a sound working practice. Dawnguard is effectively a plug-in which significantly altered the vanilla game world, while Dragonborn expanded upon the game world. I don't see anything inconsistent in our treatment of DLC under this analysis. Minor Edits^{Threats•Evidence} 00:07, 30 March 2013 (GMT)

(edit conflict) The difference is, the namespaces are there for ease of finding things. Giving EVERYTHING its own namespace creates ridiculous amounts of namespaces and isn't useful, just as giving nothing its own namespace puts so much stuff in the main namespace that it because cluttered (not an entirely accurate analogy, but you get my point). Let me ask you this. If I ask, where is Arkngthamz located? You can accurate describe that by saying it is located in skyrim. If I ask, where is Raven Rock located? You cannot accurately describe that as being in skyrim, because it isn't. All but 1 of the locations added by Dragonborn are not IN skyrim, thus it is justifiable to create its own namespace, since all of its content occurs in a specific area unique to Dragonborn. With Bloodmoon and tribunal, they occur at a location that cannot be described as Vvardenfell, which is where the rest of the game takes place, just as shivering takes place away from Cyrodiil. It just doesn't make sense to put them all in the main namespaces, when they occur in completely different locals. Jeancey (talk) 00:08, 30 March 2013 (GMT)

Daric: Also, I thought this WAS revisiting it... We are giving our opinions. I am trying to explain why the way that it is works, and works well. Jeancey (talk) 00:09, 30 March 2013 (GMT)

(edit conflict) Isn't that why we have disambiguation pages? Or the Lore section of the wiki? — Daric✐ 00:13, 30 March 2013 (GMT)

I'm not sure what you mean? This has nothing to do with disambiguation. It is about organization. Jeancey (talk) 00:16, 30 March 2013 (GMT)

There is no "silent majority". We get complaints all of the time over the smallest details. If users actually didn't like our way of organizing with the namespaces, we'd of heard about it much more frequently than we do. As for the suggestion of a public poll, I just have to disagree with that. There is no necessity to call attention from all visitors to this non-consequential thing. We don't ask for global input when it comes to sorting our categories or building templates for navigation, why would we treat namespaces differently? The average user isn't affected by our namespaces, at all. In fact, this has never been more true since our search engine automatically adds on namespaces to searches now. So, from the standpoint of the average user to the site, they have no reason to care. --AKB ^{Talk Cont Mail} 00:17, 30 March 2013 (GMT)

(←) For me, one of the biggest reasons to use different namespaces for some DLC is the amount of overlap in terms of content. Hearthfire, for example, would be ridiculous to have as a separate namespace because it adds very little in terms of quests, places, creatures, etc. Dragonborn, on the other hand, adds a ton of new quests, places, creatures, etc., most of which are unique to Solstheim and don't appear in Skyrim at all. If we put all of the DLC info onto the Skyrim versions of those pages, the result would be overwhelming, to the point of detracting from the site for those who don't have the relevant DLC. If we create separate pages for them, as we have for Dawnguard, how it that different from creating a namespace, really?

Dawnguard lies somewhere between Hearthfire and Dragonborn in terms of what it adds to the game, so for me, it's hard to say if creating a namespace or separate pages in Skyrim space would be better. The way we've structured the main Dawnguard page looks suspiciously similar to how we've structured the main Skyrim page and the main Dragonborn page, and it's very noticeable that we've had to use page names like Dawnguard Quests, Dawnguard Creatures, Dawnguard Items, etc. just to disambiguate them which, as I said earlier, is effectively the same as creating a namespace for it anyway. That would argue for putting Dawnguard in its own real namespace. On the other hand, while Dawnguard adds quite a bit in these areas, it's not comparable to Dragonborn. It really only adds a couple of quest lines, and some relatively small areas, when you get right down to it, which is an argument against creating a whole new namespace.

In the end, I'm neither for nor against the change from an organizational perspective, though from the perspective of changing everything over, it's likely to be a fair bit of work. HnB could probably do most of it if we go that route, but there's probably still going to be a lot of things that'll need human attention and decision-making as well. – Robin Hood  ^(talk) 00:37, 30 March 2013 (GMT)

The view that "landmass" and "location on the map" should determine whether or not a DLC gets its own namespace or not seems very arbitrary to me. For instance, the full game Oblivion was located both in Cyrodiil and in Oblivion, but we don't separate the game into separate namespaces just because of where the game takes place, so why should we do so for the DLC/add-ons/plugins, whatever you want to call them? — Daric✐ 00:45, 30 March 2013 (GMT)

I'm having trouble seeing that argument as anything but grasping at straws. The difference is that in Oblivion, Cyrodiil and Oblivion were a package deal. You got both by buying the game. That is not true with the DLC and expansions, which are notably separate from the original game. It's not that it takes place in a separate place, or that it's large in size. It's that it takes place in a separate location while being a large expansion to original content. This has already been explained, and surely you could understand the difference between Dagon's Plane of Oblivion and Cyrodiil being in the same namespace (they came in the same package), and the separation with the Shivering Isles.

There are always going to be arbitrary lines drawn when it comes to organization. That's a fact that must be accepted. By turning Dawnguard into a namespace, you're just making another arbitrary line with an even less solid explanation for it. Because now, why wouldn't we give Hearthfire its own namespace? Or what about the tiny additions to Morrowind? By arguing for the inclusion of Dawnguard, you are just creating a more obvious dissonance over what does and doesn't get a namespace. --AKB ^{Talk Cont Mail} 01:10, 30 March 2013 (GMT)

For those thinking about a poll or questioning the merits of our namespace system: it occurred to me that the site survey had a lot to say on the matter and didn't happen all that long ago. Peruse it if you haven't already. As I said on that talk page, I think most problems understanding the site structure could be solved with a short and sweet explanation on the Main Page. Since a lot of people requested some changes to the Main Page, we could kill two birds with one stone. Minor Edits^{Threats•Evidence} 01:17, 30 March 2013 (GMT)

I wouldn't actually mind having Dragonborn integrated into the Skyrim namespace, but splitting Dawnguard seems like a really bad idea. Look at what it does to Skyrim:Vampire. —Legoless (talk) 01:24, 30 March 2013 (GMT)

(edit conflict × 3) Daric, of course it's arbitrary. Why? Because we have to make that decision ourselves. If we went by another suggested criteria of following what Bethesda calls an expansion, then we'd have a separate namespace for Bitter Coast Sounds. We don't just differentiate it based on whether or not it's a separate landmass. We separate it based on three things: size, how much of an impact it has on the base game, and how well it stands independently. These are fairly logical criteria. If all the mod does is add a handful of items to the base game, then it would best be integrated with the main gamespace. If, however, it adds a huge number of items, many quests, a large landmass, a whole slew of things that aren't connected to the main "Skyrim" at all, then it gets it's own namespace. This is for organizational reasons, primarily for the reader's benefit. If we separate everything into namespaces, then everything will be disconnected from each other. It's a bad thing to have one namespace with 99% of its links to another namespace - it completely defeats the purpose of them. Dawnguard is a good example. It adds significantly to leveled lists throughout the game, from skeletons to dragons. Listing this information in separate articles would be silly, because the new info is only relevant to the old info, and duplicating 10,000+ word articles just for the sake of having a different namespace is stupid.

I will post what I said when we last discussed this:

As more of a general observation, Shivering Isles deserved it's own namespace because it had both a huge new landscape as well items that were completely independent of the main world items, including Amber and Madness Ore armor just to name a few. The locations and items that the add-on Dawnguard adds are just that, add-ons. With the exception of the Soul Cairn, all new locations are just integrated into the mainland. Castle Volkihar is due north of Northwatch Keep and due west of Solitude, but it's still easily within the bounds of the world. Castle Dawnguard is the same. Places like Dimhollow Cavern, Forebears' Holdout, and Redwater Den are all on the mainland. The two new dragon types, Revered and Legendary, are integrated into the existing leveled list for dragons. Dragonbone weapons are also integrated into the existing lists. Fletching is hardly a standalone skill - it's integrated into the existing Smithing options. Just about everything that's added with Dawnguard is added into the vanilla game, similar to Knights of the Nine, rather than acting as a standalone expansion, like Shivering Isles. If I may be so candid, there's a reason that the 1.6 update changed it from "Loading Downloadable Content" to "Loading Add-Ons".

Having reached the end of Dawnguard, I haven't changed my conclusion. Dragonborn, however, is very much like the Shivering Isles. It has a large, self-contained landmass, with dozens of new NPCs and quests, hundreds of new items, new skills and abilities, and with the exception of a single small link, is completely separate from the mainland. You can spent tens of hours exploring Solstheim without setting foot in Skyrim. You can completely forgo Skyrim equipment and arm yourself with DB-specific equipment. You can spend in-game months just doing quests in Dragonborn. When it comes down to it, Dragonborn is like the Shivering Isles, and Dawnguard is just a big Knight of the Nine.

Dragonborn truly is a self-contained experience, and it should be a self-contained reading experience as well. Dragonborn has its own namespace, and Dawnguard doesn't. That's the way it should remain. • JA^T 01:50, 30 March 2013 (GMT)

Dawnguard vs Dragonborn - Edit Break 1

Legoless: Your comment "Look at what it does to Skyrim:Vampire" was already addressed by my comment above, about disambiguation pages. I just happened to have preempted your argument, and my answer was therefore read out of context. I am, after all, in the GMT+12 timezone, I come from the future. Hehe.

As for the site survey that took place back in November 2012, how many new users, myself included, didn't even know that this was happening back then? I only registered an account on UESP in December 2012. Prior to that I was part of the "silent majority" of people who consult the UESP without having a registered account as an editor, and believe me, I always thought the namespace conventions here were weird, long before I registered as an Editor. — Daric✐ 03:00, 30 March 2013 (GMT)

Disambiguation pages are for two different things with the same name. Splitting up leveled lists and repeating data would be a mess. The vampire page would be split, with the same data but different races on different pages, and the notes about DG changes to vampire data would be a pain to figure out, as DG alters the vanilla vampire. Vely^►t►e 03:36, 30 March 2013 (GMT)

Why is it that everyone seems to think expansions are based upon landmass? Dawnguard's size is very comparable to that of Dragonborn's, the difference is negligible. You're telling me if Hearthfire had houses built on a new small island, it would get a namespace of its own? Come on people, this is a ridiculous argument. I haven't been there myself, but I hear the Soulcairn is really big, similarly adding a huge amount of new landmass. If the addition is small, you don't have to create a new page, you can just link to the original Skyrim page if it's really few new content. Both DLC add an equal amount of content, and as RobinHood70 said, they all pretty much have their own page already ~ Dwarfmp (talk) 13:05, 30 March 2013 (GMT)

Dwarfmp: It isn't about landmasses, it's about the separation. Returning to the example of Skyrim:Vampire: Dawnguard heavily modifies the vanilla vampires, and trying to move that information to a separate page would be stupid. It makes similar changes to Falmer enemy lists and dungeons. Skyrim:Lycanthropy would also require an inane split due to the information of the perks. Dawnguard is far too integrated into the base game to make a split possible. With Dragonborn, this isn't the case at all. You can count the changes it makes to the base world on one hand: a boat, cultists, the Ebony Warrior, a new armour type, and a remote landmark. It's just not practical to split Dawnguard or Hearthfire.

Daric: What do disambiguation pages have to do with it? —Legoless (talk) 13:19, 30 March 2013 (GMT)

Why would it be stupid? If I didn't have Dawnguard and wasn't planning to get it, I wouldn't want its data mucking up the Vampire page ~ Dwarfmp (talk) 13:28, 30 March 2013 (GMT)

Eshe did a nice job of clearly distinguishing Dawnguard data from vanilla data. Take a look at the tables. —Legoless (talk) 13:40, 30 March 2013 (GMT)

(←) I actually voted for a Dawnguard namespace in the CP discussion about it, but I think the biggest determining factor is how separate the data is. Dawnguard makes vast changes to Skyrim, it's enemies, dialogue, and places its content alongside and with the vanilla game. Dragonborn on the other hand places 99% of its content on Solstheim, away from Skyrim. It does make changes to leveled lists and such, but only to add its new enemy types to the existing ones, and to prevent some of them happening on Solstheim. In short Dawnguard changes Skyrim (and adds to it of course), while Dragonborn only adds to Skyrim.
If we compare them to Oblivion, Dawnguard is extremely similar in what it does to the Knights of the Nine, while Dragonborn is very similar to Shivering Isles. If any changes have to be made, I would far rather Dragonborn was moved to the Skyrim namespace that Dawnguard was extracted, of course, at this point I'm against either move. What is really needed are some guidelines on what DLCs/Add-ons/Expansions we would consider making a namespace. To me it starts with content, it has to add a significant amount of data to qualify, then it should be separation (i.e. does it make vast changes to the game, or just add to it), thirdly, it should add significant landmass where the vast majority of the content takes place. Dawnguard fails on the last two to me. It does add significant landmass, in the Soul Cairn and the Forbidden Legend, but the majority of its quests take place in Skyrim (and Skyrim locations altered by Dawnguard). Silence is Golden^{Break the Silence} 15:05, 30 March 2013 (GMT)

The fact that one DLC deserves a namespace over another is incredibly biased, and I can't contribute to a wiki that's biased on its structure alone already. Disregarding facts because it's easier to do so is not what I want to stand for ~ Dwarfmp (talk) 16:47, 30 March 2013 (GMT)

Namespaces, as I see them, are entirely for ease, and I think that is their underlying purpose. I think the relevance to disambiguation mentioned by Daric, or at least, how I see it, is that namespaces are just disambiguation at the highest level. The issue we have here comes when such disambiguation is unecessary, and the system potentially causes more harm than good. The system we currently seem to use, as described above, is based on the integration/separation of the content of an add-on, and, by extension, the integration/separation of our information, and not whether the amount of content is comparable. I think this is the bias Dwarfmp is referring to (please correct me if I'm wrong).

For consistency, since DG and DB seem to be considered equal by Bethesda (they are referred to as DLC1 and DLC2 in the files, whereas HF is called BYoH), perhaps we should also consider them equal. The integration issue is, however, the biggest issue I see with this. The DG:Vampire page and the SR:Vampire page would obviously explain only that which is relevant to each, but DG info without the SR base info may not make sense, since some of the DG stuff requires the SR stuff. Equally, extra creature variants (dragons, chaurus, falmer, etc) added by DG would not make sense without their SR base. How easily could the SR base info be transcluded into DG articles? Particularly considering the extended lists, separation and transclusion into a new namespace could become difficult. Continuing on the lines of integration, what would we do with place articles (SR:Hall of the Vigilant, SR:Ruins of Bthalft, SR:Arcwind Point) that are only minorly changed by DG, but still changed all the same? Most of the rest are probably viably separable or directly moveable, either by pulling out the DG stuff or by virtue of the Dawnguard:Places-style naming that we use already.

This is how I see it working if we decide to give DG its own namespace. Whether we actually need to or not, I am generally indifferent. For consistency and equality, I think we should; but for integration and separation, I think we shouldn't. --Enodoc (talk) 18:56, 30 March 2013 (GMT)

All I'm saying is that by giving Dragonborn a namespace and not Dawnguard, it's as if we admit that Dragonborn is in fact "bigger and better" or "more of an expansion" than Dawnguard. To my understanding, KOTN doesn't have a namespace because it was a big "plug-in" (I'm not even sure what to call these things anymore) but in all rights still not considered an expansion as Shivering Isles was, it was the mother of all smaller "plug-ins". I'm not saying we HAVE to separate the Dawnguard data from the vampire page, links to the page and keeping the DG data there may just work as well. Of course people are going to tell me "but then we separate DG data from other DG data, so what's the use of a namespace". It's just the idea behind it, that one DLC is an expansion and another is not, they are equal in their own rights ~ Dwarfmp (talk) 19:12, 30 March 2013 (GMT)

If I recall correctly, Shivering is also referred to the in the game data as a plug-in. All of the DLC for Oblivion was. It is the EXACT same situation with KotN and Shivering as it is with DG and DB. DB *is* bigger and more of an expansion than DG is. It has more quests, more area to explore, and a more coherent story. The reason that they refer to them differently from HF is that HF was made pretty much in its entirety by three devs with some time on their hands as a fun thing to do. Beth liked it so much, they spruced it up and released it, but it was the brainchild of some devs in their spare time, as opposed to the DG and DB, which were planned out. DB is bigger in every aspect, thus, it gets its own namespace. I don't understand why some of you don't think it is bigger than DG, because it very clearly is... Jeancey (talk) 20:41, 30 March 2013 (GMT)

This has nothing to do with us thinking one is more of an expansion than the other. It's about how easy it is to document. We clearly state they are both expansions or whatever you want to call them. We're not treating Dawnguard's content differently for any reason but because it is easier to document its pages when they're in the same namespace as Skyrim. Dawnguard's content is entirely tied up with the rest of Skyrim. Dragonborn, on the other hand, has a tenuous connection to the rest of the content in the Skyrim namespace. The same is true for the rest of our expansions with namespaces. SI barely changes anything existing in Cyrodiil (Sheogorath's shrine quest and adds a single island), Tribunal adds somewhere around three new NPCs to Vvardenfell, and Bloodmoon adds a boat and an annoying topic that plagues all of the inhabitants of the island. So all of those expansions do very little with the rest of the game's existing content, and it would clutter up our existing articles about games by adding a bunch of content that is barely relevant to everything else on the article.

Honestly, I'm not sure why this is such a big deal. Namespaces literally only exist for organizational purposes. It is easier to organize our content if some of it is split off from the rest. That's the defining idea behind it. It's why we don't group together different games under the same namespace. Splitting them up for individual games is just an extension of that idea. If it improves navigation if we split up the games, surely it helps if the game's content is split up where it can be? So the real questions are, is information related to Skyrim easier to find if we keep Dragonborn split off or if we split off Dawnguard's content? The answers to me are yes and no, respectively. Dragonborn is easily split off, while with Dawnguard every other link or article will go back to the Skyrim namespace. While Dragonborn is currently fine, Dawnguard's split off from Skyrim would make navigation a nightmare for those trying to read up on Dawnguard. We'll either have a ton of redundant articles, or articles that are arbitrarily in one namespace or the other. --AKB ^{Talk Cont Mail} 20:56, 30 March 2013 (GMT)

SI was implemented in the Oblivion.esm file, while the plug-ins were esp files completely on their own. When I see one DLC has a namespace and another has not, I'm going to draw the conclusion one DLC is bigger over another. Bethesda distributes them as equal, as they are both priced equally. Where are you going to draw the line? What requirements must DLC have to be more than just a "plug-in"? Shivering Isles is the first and only major expansion for Oblivion., note how that is the first line on the SI main page. SI is not put on the plug-ins page, while KOTN is. Are you going to change the Dawnguard page claiming it's some sort of "lesser" DLC like Hearthfire? Pretty much tells readers they should buy Dragonborn over Dawnguard because you'll get more out of Dragonborn for the same amount of money. When I look up to purchase KOTN and SI from the official site, I see that SI is no less than 3 times worth more than KOTN.

AKB, you say that namespace is only used to make things easier for us, and doesn't make a difference in meaning at all. But that's not the impression I get. The infoboxes are different, the whole main page is handled differently. As a reader, the site tells me one is better than the other. I get why it's been implemented differently, but it still feels very biased to me, and maybe many more people ~ Dwarfmp (talk) 21:11, 30 March 2013 (GMT)

Dwarf, we have stated the requirements. I think that silencer stated them fairly well. It adds significant new content, Significant new land mass, and the vast majority of that new content takes place on the new landmass, not in the landmass of the base game. Every single DLC currently follows this guideline. Those are the requirements. You seem to think there are two types of DLC, big ones and small ones. This isn't the case at all. There are many types of DLC, some are large, some are small, and some are somewhere inbetween. DB is nearly 40% larger than DG, its a simple fact. DB and DG both add significant content to the game, but DB also adds significant landmass, and the new content appears almost entirely on that landmass, whereas DG's content is spread around the existing skyrim landmass. Those ARE the requirements we currently use. Simple as that. Jeancey (talk) 21:20, 30 March 2013 (GMT)

(←) Nowhere is it stated what the "requirements" are. If Bethesda says they're equal, then we should not treat one differently than the other, or we should at least clearly show they're supposed to be of equal value. Right now it's completely biased, and that's against Bethesda's view on it ~ Dwarfmp (talk) 21:28, 30 March 2013 (GMT)

Namespaces aren't official. This has nothing to do with how Bethesda treats them. The requirements that have been stated are the ones that currently seem to be followed. This discussion needs to be based around that. Just stating that "they aren't equal" and "split the namespace" isn't helpful at all. If we are going to split or combine namespaces, we need to come up with distinct and specific namespaces requirements that we should follow. Otherwise, I will propose splitting EVERY dlc into its own namespace, and because there weren't guidelines set down, we will have to do so because we were making arbitrary distinctions based on little more than personal opinion. I think that the Mehrunes' Razor plugin was quite large, and I have spent many hours with the Dunbarrow Pirates, why aren't they full namespaces, its not fair. Unless we come up with specific guidelines, this will have been a useless conversation. Silencer stated fairly well some requirements that would accurately describe how we have currently been splitting namespaces. Could you come up with some requirements that we could use for your point of view? One that would only add DG as a namespace, and no other DLC from any other game? These requirements much accurately describe the namespace policy for the entire site, not just Skyrim. Jeancey (talk) 21:38, 30 March 2013 (GMT)

This isn't personal opinion, this is Bethesda's "opinion", and therefore fact. It needs to be made clear at least, that both are considered equal. Maybe we need a new infobox for Skyrim DLC. The descriptions need a re-writing, and since we're on it, we need to know what the official names are, DLC/Plug-In/Add-On/Expansion/... ~ Dwarfmp (talk) 21:43, 30 March 2013 (GMT)

No, this is a personal opinion. Namespaces are only for us, and therefore WE must decide how they work. The official term for Skyrim is DLC. HF, DG, and DB are all referred to by Bethesda as DLC. Using your logic, HF needs its own namespace. All of the Morrowind extras were referred to as Add-Ons. All of them. All the Oblivion ones were Plug-ins. Bethesda makes no distinction between them, the only distinction is ones that WE have imposed. This is our site, our wiki, not Bethesda's. We must decide how to split the namespaces. We have a system that works, and it works well. If you think that it should be changed, I think that everyone would be willing to hear it, but there needs to be a specific change. How would you write the namespace policy in order to add DG as its own namespace? What requirements would you use? Jeancey (talk) 21:47, 30 March 2013 (GMT)

How about we add a clarification to UESPWiki:Namespaces? Dwarf, would that satisfy your concern if we clarified in that page's intro something like "The UESP namespaces are created for organizational convenience, and do not reflect the opinion of Bethesda."? Minor Edits^{Threats•Evidence} 21:53, 30 March 2013 (GMT)

Dawnguard vs Dragonborn - Edit Break 2

The fact that Dawnguard and Dragonborn are both DLCs of equal worth, according to Bethesda, is indisputable. Readers of the UESP wiki will therefore expect them to be treated as such. If the underlying mechanisms that we use to organize the wiki do not reflect that fact, for some organizational reason that only matters to Editors of the wiki, then it behoves us to obfuscate that distinction in some way, I believe. This is where the sidebar comes in to play. If we truly cannot represent the two DLCs as of equal merit, the way Bethesda do, in the underlying mechanics of the wiki (namespaces) then we owe it to the readers of the wiki to make it appear as if we do, by making them equal in all other respects, such as on the sidebar and in other page navigation devices. — Daric✐ 22:13, 30 March 2013 (GMT)

I'm not sure how you have changed your sidebar, but I have the base sidebar, and there is no distinction between DB and DG. It lists skyrim, then it lists the DLC in order of release. That's it. They appear the exact same. I'm not sure what the issue is here? Jeancey (talk) 22:19, 30 March 2013 (GMT)

Before I changed my sidebar in my monobook.js, Dragonborn was definitely treated the same as it is in the namespaces, as a special case, bigger and better than Dawnguard. As per the discussion above, and Jak's sandbox...

Difference Between Two Versions

Since then, I have modified my own sidebar to make things look equal, the way Dwarfmp has been advocating in this present discussion. They're all called "DLC", and the larger DLC's, such as SI, KoTN, DG, and DB, are treated as equals, with everything else listed under "Other DLC" for each major game. Apart from the fact that my sidebar now doesn't collapse, it looks fine to me. — Daric✐ 22:52, 30 March 2013 (GMT)

But that's not how it appears right now. Right now, everything is treated equally. Dawnguard, Hearthfire and dragonborn all appear under the dropdown menu thing for skyrim. The old style was modified before it became official. That's why I'm sort of confused at what the issue is? Or has your issue been sneakily fixed without your knowledge? Jeancey (talk) 22:57, 30 March 2013 (GMT)

(edit conflict) For reference (no opinion is inferred by this post), and I think someone was asking, currently at www.elderscrolls.com, all Morrowind ones from Bitter Coast Sounds and Master Index to Tribunal and Bloodmoon are called Expansions [1]. TR and BM are considerably more prominent, however. All Oblivion ones, from Horse Armor and Spell Tomes to KotN and ShIsles, are called DLC [2]. KotN and SI are equally prominant, and more so than the other eight. All Skyrim ones are called Add-ons [3], amd all three are listed equally. --Enodoc (talk) 22:56, 30 March 2013 (GMT)

Ah, I was getting my terminology mixed up, but my point still stands, they were listed equally by Bethesda, and they all used the same terms. Jeancey (talk) 23:02, 30 March 2013 (GMT)

(←) You're right Jeancey, it looks like Jak has sneakily changed the placement of the DLCs in the sidebar, but I wouldn't have noticed that because I have already overridden the default sidebar. However, having taken a look just now at the site's sidebar without my own modifications, I see that the naming of the "extras" groups is still inconsistent, being "Official Add-ons" for Oblivion, and "Official Plug-Ins" for Morrowind. As per Enodoc's comment above, I think I'll keep my modified sidebar in place until that is fixed too. — Daric✐ 23:16, 30 March 2013 (GMT)

Okay, I don't want to add fuel to the fire but I think some people here should learn to let go. The reasons for the separate namespaces are clear and concise and, while I think separating absolutely everything is overkill (thinking about Weapons/Armor/Unique Items in particular), the truth is that it does make things easier to document and it avoids confusion; a tiny DB next to the name is not exactly what I'd call noticeable. As it was stated above, the new search engine isn't limited to a single namespace and allows you to find anything you want without problem. The truth is that virtually no one cares; the goal of UESP is ease of use, and it's easy to use. The people who come here aren't idiots who are completely lost because we use different namespaces; they're knowledgeable about the game, they know that Dawnguard, Hearthfire and Dragonborn are Skyrim extensions.

As for Dawnguard, I'd agree with a separate namespace. In the end, nearly all quests added take place in new locations, the fact that some of them are in mainland Skyrim seems irrelevant to me. I really don't think comparing it to KotN is fair, considering that it added only 8 places, two creatures (more like one and a half), one questline with no side-quests and only 32 NPCs. By comparison, Dawnguard is huge. Shivering Isles on the other hand, added as much if not more than Dragonborn. However, we obviously don't need to split pages like Vampire/Vampirism/Lycanthropy, and places that were modified can simply stay as they are, with a description mentionning the potential changes. But again, in the end, it doesn't matter to anyone but us few, the average user wll not be affected by such changes. Elakyn (talk) 00:19, 31 March 2013 (GMT)

Before this goes any further, I need to point out I've talked about it with Jeancey and some other people in the IRC shortly after my last post. Some interesting facts were raised, like KOTN having been the same cost as SI initially, etc. The point is, the discussion has led me to be confused, because apparently KOTN IS officially an expansion like SI, but I've always based the info off of this wiki, because I trusted everything to be correct here, but I was wrong. The name "plug-in" has apparently never been used, and is definitely not the proper name for Oblivion official mods. What I want, is simply the truth, clarity. Apparently Dawnguard IS a good deal smaller than Dragonborn, and I guess we can safely blame Bethesda for selling it as an equal DLC. Apparently, we need to come up with guidelines for what a namespace is, and what DLC/expansion deserves it, because apparently my view on it was wrong as well. I still think we need to change the infoboxes, and change the term "official plug-in", there has to be a good official term used everywhere. Btw Elakyn, you shouldn't underestimate people's stupidity... ~ Dwarfmp (talk) 00:45, 31 March 2013 (GMT)

Bethesda is inconsistent, thus we must come up with our own guidelines. Changing the infoboxes so that every main page for a DLC or game is the same would seem like an appropriate way to indicate that they are, in fact, the same. Having guidelines for namespaces also would be for the best, and I think we should stick to whatever guidelines we come up with. Separating the namespaces is based on the ease of use for us, thus it must be based on how easy it is to do that. As was pointed out, if Dawnguard was split, the majority of the links on those pages would be to skyrim pages, which defeats the purpose of having it in another namespace. I think the discussion now should focus around specific guidelines for namespaces as a whole, rather than for this specific DLC. One set of guidelines has already been proposed. Elakyn, since you seem to be of the opinion that Dawnguard should be a namespace, could you come up with some guidelines that would apply to all games and DLCs that would achieves this? Jeancey (talk) 01:06, 31 March 2013 (GMT)

Okay, so let's start a conversation at UESPWiki talk:Namespaces and work out some guidelines to add to that page. Minor Edits^{Threats•Evidence} 01:06, 31 March 2013 (GMT)

Data upgrade of DLCs

I've pointed this problem out in the talk page of Skyrim:Ingredients, sadly nobody replied at all. It seems that the numbers of ingredients samples are out-dated. Obviously, they didn't take any DLCs into count. Maybe some upgrade is needed. It would be much more convenient. Dreamshadow (talk) 13:32, 30 March 2013 (GMT)

I agree. Not quite sure how that would be implemented, to ensure that it was separate info for those who don't have it, but at the same time still included, but probably would involve additional counts of the ingredient with the {{DG}}-style templates. -Enodoc (talk) 11:26, 3 April 2013 (GMT)

As a matter of fact, I won't pay much attention to the total numbers. However, locations with multiple samples added by DG or DB must be added as soon as possible. It's hard to have them done effectively without the help of CK. That's why I mentioned it here instead of getting them done by myself. Dreamshadow (talk) 11:57, 3 April 2013 (GMT)

We don't list all locations anyway, we only list around 10 possible locations for each ingredient. For most, if not all, the only thing that will change is the total numbers. — Kimi the Elf ^{(talk | contribs)} 12:33, 3 April 2013 (GMT)

I see, thers is no need to list every location with detailed numbers. However, for some ingredients, multiple samples appeared in DB or DG locations. For example, Kagrumez contains 10+ samples of Dwarven Oil, much more than any other locations listed in the original page. These cases should be mentioned anyway. Dreamshadow (talk) 12:48, 3 April 2013 (GMT)

Bolding in captions and text

Yes I'm back to complain. I've brought up a similar subject a few months back (see here). Now, I haven't exactly started bolding all over the place even though I'd want to, I don't see why the mass "fixing", aka removing, the bolding in the Oblivion namespace is justified without any sort of consensus reached. The origin of the bolding was in a fact link in the description linking to the page itself, causing boldness. Now don't ask me why this was so in most cases (who knows, a good reason forgotten), but I grew accustomed, heck, I knew nothing else before since it had always been like that. And it simply looks better too if you ask me. Now here comes Skyrim, most articles still composed by what I expect to be anons and complete lack of experience with the wiki. Newcomers think it's supposed to look like that. And here we are now ~ Dwarfmp (talk) 02:51, 3 April 2013 (GMT)

Personal opinion. Bolding of the house and the name in the photo caption looks ridiculous... I think it makes articles seem less professional and sloppy. I don't like it and I don't think it should be there. That is my personal opinion. It makes no sense to have a link to the current page in the image caption. Absolutely zero sense. Jeancey (talk) 02:59, 3 April 2013 (GMT)

And I think a lack of it looks unprofessional. Though I wouldn't say the house name needs bolding, that's true. I don't know why there were links, but supposedly so images and captions could be easily copied to another page. But that's not the point. And it isn't just those boldings, it's also bolding of dialogue topics in Oblivion, which makes for easier tracking, and makes perfect sense ~ Dwarfmp (talk) 03:09, 3 April 2013 (GMT)

Oh, I was only talking about the bolding in image captions and house names. It's like saying, THIS is the npc we are talking about... when there is only one NPC in the image, and you are on that's npc's page. It is like saying, "Hey reader, you are so stupid that we have to bold this name for you, just in case you didn't understand that you are on this page, and the image is of the NPC". It's insulting, personally. Jeancey (talk) 03:15, 3 April 2013 (GMT)

I have to agree with Dwarfmp.When I first came to the site and saw the bolding of names in image captions, I thought that it made it obvious who you are referencing. If I was, say, merely researching the games I would have no idea what the character looks like and so I could believe that an entirely different NPC than the one the page is on. That is my own opinion on this matter. -- Ad Intellige Mecum loqui 03:21, 3 April 2013 (GMT)

Dominus, not sure if you're being snarky or not, but if you are, please don't; it's unkind and unclear. If not, then sorry for thinking you may be; I can't tell.

As for my input, bolding doesn't really do anything for character names in image captions, just looks a bit odd. As for topics being bolded, that makes a lot of sense to me. "When she talks about Anvil" clarifies that I have to click on "Anvil" in conversation to get that result and not "rumors" or "daily life", etc. because those could also be about Anvil. It also gives a bit of variation to the occasional walls of text. Vely^►t►e 03:35, 3 April 2013 (GMT)

It was not my intent to come off as snarky and so I apologize for that. I was merely trying to give my opinion that I support bolding the names.-- Ad Intellige Mecum loqui 03:39, 3 April 2013 (GMT)

(←) My apologies then. Vely^►t►e 03:42, 3 April 2013 (GMT)

Before anyone undertakes a standardization project like this entailing a huge amount of edits, the considerate thing to do is garner a consensus to determine that your course of action is something the community wants. On this general topic, I'm apathetic. I don't think the bolding serves much point. Nor do I think it's detrimental in descriptions where it appears. But if someone does it, I don't see how it hurts. In my opinion, there's no reason to go make a ton of edits to ensure uniformity on such an inconsequential matter. While I might be missing some big debate(s), it seems to me that the long history of bolding in descriptions on many pages supports the conclusion that very few people are put off by this different practice. I'm a fan of standardizing things on the wiki, but not of big editing campaigns to make changes which don't actually make the page any better. It's something of a paradox. Minor Edits^{Threats•Evidence} 04:15, 3 April 2013 (GMT)

I would just like to point out, that only a small number of oblivion pages actually bold the names, along with one or two morrowind ones. The vast majority of pages on the wiki do NOT bold the names in the image captions. We do not have a long history of it. There would be many many more to change to make them all bold than to make them all non-bold. Jeancey (talk) 04:57, 3 April 2013 (GMT)

By "long history", I only meant that the pages which are bolded have apparently been that way for a very long time. Countless people have viewed these pages, some must have noticed the difference, but it doesn't seem like there's been action against it. In other words, it's not something people seem to care much about one way or the other. Minor Edits^{Threats•Evidence} 05:18, 3 April 2013 (GMT)

Forgive me for my interruption. I just wonder is there anyone noticed my question above. I've been waiting for several days. I think that is more important than such "minor" problems. As a common user, I just care I can find any useful information here. I would pay little attention to these formats. Dreamshadow (talk) 09:09, 3 April 2013 (GMT)

Does anyone have a link to an example of each case for reference? Thanks. --Enodoc (talk) 11:20, 3 April 2013 (GMT)

Here is an example of one of the few NPC pages with the NPC's name bolded in the first image caption; here is one of many where it is not.

For what it's worth, I don't really care what's done on other sites or what was or was not done with consensus; I'd just like to see consistency. When you're on a page with a caption formatted one way and click over to a page that has it another way, it gives them impression that our editors don't know what they're doing. This may not be a showstopper issue, but uniformity conveys a certain level of professionalism that, frankly, I think we ought to strive for. If we cared enough about captions to make sure they don't have end punctuation, we can give a few minutes to care enough about this.

Anyway, I would be in favor of not having bolded names in image captions, for a few reasons:

1. The extra formatting doesn't seem necessary. The NPC's name is on the title of the page and the heading of the infobox, and is already bolded in the first line of text. The bolding in the caption draws the eye to something the reader really already knows.
2. I think it would look odd to format the name in one image, but not the rest (for pages with many images).
3. The vast majority of NPC pages (across all namespaces) do not have the NPC's name bolded in the first image caption. This to me not only illustrates historical preference for no bolding, but also indicates it would be vastly easier to achieve consistency by removing the bold from captions that have them rather than adding them to the hundreds and hundreds that do not.

⇠eshe^talk 15:13, 3 April 2013 (GMT)

I'd agree with this, though I think it's kind of a huge waste of time for people to go through every page and remove bolding from image captions. There's so many other things that need real attention that it doesn't make sense to put this much effort into such a trivial formatting issue. If anything, maybe we can get a bot to go through and remove caption boldings. Just doesn't seem like it's worth the amount of work it would take for humans to do it all. There's plenty of other more important things people could be doing right now than wasting hours on this. — TheRealLurlock (talk) 15:52, 3 April 2013 (GMT)

That would be true if it were going to take hours ;). I think there's honestly only a handful of pages that have that formatting. If we decided to go ahead and remove the bolding, people could just do it as they come across it (or we could sic Helena on them!). It doesn't strike me at all as a "we must decide and then resolve the issue immediately" situation, but people clearly have opinions one way or the other, so...might as well talk it out while we're thinking about it. ⇠eshe^talk 15:57, 3 April 2013 (GMT)

(←) Sorry, it's been a busy day doing bot stuff on two different sites, and I'm only just now catching up on the huge amount of discussion that's shown up on AN and CP in the last 24 hours. To address Lurlock's point, if the decision is to remove it, then yes, a bot could very easily take care of removing the bolding, whether it's genuine bolding or the bolding introduced by self-linking, as in Eshe's example. Alternatively, if we want to put a user on it just to be doubly sure, the bot's already set up to generate lists of templates and their parameters, so it would be literally only a few clicks (and a whole lot of time waiting for it to finish) to generate a list of NPC Summaries with imgdesc's that contain the page name and either ''' or [[. – Robin Hood  ^(talk) 05:11, 4 April 2013 (GMT)

It seems like most people are agreed when this was last discussed that the bolding should go. RH, would you be willing to go ahead and generate that list whenever you have a free moment? As many people have said, this isn't an urgent issue, but we might as well get some harmony on our pages as long as it's a quick and easy task. ⇠eshe^talk 17:20, 22 April 2013 (GMT)

Okay, the list is in User:RobinHood70/Zain. I can do it tomorrow if no one else is chomping at the bit. :) If you are, see my notes there. – Robin Hood  ^(talk) 05:19, 23 April 2013 (GMT)

I put the bot on this earlier today, so these should all be done now. There were a few special cases, which I handled by hand afterwards. If anybody spots any more, please let me know so that I can investigate. – Robin Hood  ^(talk) 23:23, 23 April 2013 (GMT)

Awesome! I'll take a quick look through the list later today, just to double-check. Thanks for taking care of that, RH! ⇠eshe^talk 14:28, 24 April 2013 (GMT)

Everything looks good. Lots of redundant links hanging around in the captions, but I zapped them as I went. Thanks again! ⇠eshe^talk 18:19, 24 April 2013 (GMT)

New Project Proposal

Woooweee! This is just like anticipating those speeches you absolutely dreaded in high school! Anyways, I'm posting here today to propose a new project scheme -- mainly for the Oblivion namespace. I've already spoken to several people (off the top of my head... Krusty, Eshe, etc) about my plans coinciding this -- I have even already started briefly in one of my sandboxes here trying to gather the basic information needed about each article. Anyways -- the project I'm here to propose is the Oblivion Houses Redesign Project!

Basically all the details I tried to explain on that page about what I hope to do with this project, but to sum it up here for you guys -- I want to create individual article pages of each individual house that is listed within the game itself. I am copying the examples set by the Skyrim namespace as it already has pages like this (example: Amren's House). Also there is the unmentionable fact that the Oblivion NPC Redesign Project has already listed most of the house contents already -- just on the wrong pages in my opinion. Why would you list a house and ALL it's contents on an NPCs page? Sure -- the NPC may live there afterall, but merely the location of where that NPC lives and also perhaps the schedule in which they can be found there should be listed in my honest opinion.

Anyways I'm not going to bore you guys with insane ramblings from me when I tried my best to summarize up the proposition I have when most (if not all of the meaning behind this project) is already listed on the page I previously linked... oh wait, there I did it again! :) -Helenaannevalentine^(talk) 22:32, 4 April 2013 (GMT)

I'm going to ask the same thing that I was asked. There is already an Oblivion Places Redesign Project. Can't this be just added to the existing project? Why does it have to be a brand new project? Jeancey (talk) 22:35, 4 April 2013 (GMT)

The Oblivion Places Redesign Project, like Krusty just said in the IRC, is solely for dungeons and caves - which requires and has different standards with the guidelines and layouts, which is the main reason as to why I'm proposing this project also -- because this one also requires new articles along with any redirects, etc, to be made rather than solely improving on pre-existing articles. -Helenaannevalentine^(talk) 22:42, 4 April 2013 (GMT)

This seems like a good idea, we can include more house details and even add a map of the interior. It should make some long pages shorter, which goes hand in hand with what seems to me its only bad side: it would shorten already short NPC articles ~ Dwarfmp (talk) 01:13, 5 April 2013 (GMT)

I'm just going to say that I always thought this was a good idea. I remember looking at the "House Contents" section of the OBNPCRP for the first time and going, "Huh. Why's it all shoved into one page, you really don't get into much about the house." Well, now we can change that. Full support. --Vulpa 01:19, 5 April 2013 (GMT)

(edit conflict) Yes, on the downside it would shorten the NPC pages, but the pages themselves are meant to be solely about the NPC themselves and their inventory, schedule, etc -- not half of their pages consisting only of their house contents. To me, that's a bit pointless in itself, and justifies even more reason to go ahead with this project. Plus as you said, we could take interior images and really snazz up the new articles :) On another note, glad to have you onboard Vulpa! -helenaanne  ^{talk ♥} 01:22, 5 April 2013 (GMT)

I have to admit it's a good idea. However, may I have you take a look at this page, HERE. So much work and so limited resources. I won't argue the importance of this project. Maybe we should pay more attention to Skyrim and Dragonborn-related pages at this moment. From my point of view, a "Skyrim/Dradonborn Maintenance Project" would be more urgent ;) Let me guess, most readers are visiting SR and DB pages, these maintenance-need pages. Anyway, I don't think it's wise to spare more resources for other pages. At least, for now. Dreamshadow (talk) 02:51, 5 April 2013 (GMT)

Hi there Dreamshadow! It's nice of you to add your opinion to the disucssion - you provide a valid point -- most pages that seemed to be visited nowadays are from the Skyrim namespace and Dragonborn namespace, etc -- but we can't solely focus on them just alone. We must continue to provide care and maintenance with the older namespaces -- hence why this project has been brought up here. Plus, most of the Skyrim and Dragonborn articles are already being focused on by most editors and contributors lately so there isn't as much of an urgency to have a project for those articles seeing as those articles themselves aren't being neglected. -helenaanne  ^{talk ♥} 03:00, 5 April 2013 (GMT)

Going off of that, some of our editors don't have Skyrim or Dragonborn and are looking for things to do, or are more interested in Oblivion, etc. We have a redesign project for Skyrim already, and Dragonborn is too new for a redesign project to happen--it's still being written. Projects basically exist just to say "this needs to be done, and this is the way it should be done; help out if you want to." If people like Oblivion houses, they'll work on Oblivion houses. If people like Arena, they'll work on Arena. And if people like Dragonborn, they'll work on Dragonborn. It's just something to be done; our "limited resources" who are interested in this project probably won't be taking their attention away from elsewhere on the wiki to work on this. Plus, older pages still need to be maintained and in good condition.

As for the topic, OBHP sounds good to me. I never liked how houses were split from NPCs in Skyrim but not other games. Vely^►t►e 03:11, 5 April 2013 (GMT)

My apologies then. Thanks for your reminder. I don't mean that we should pay no attention to older pages. If we can handle the balance between different pages. I'm always happy to see more and more detailed pages~ If possible, I'm for this project. Dreamshadow (talk) 03:21, 5 April 2013 (GMT)

I also think this is a good idea. Let’s just make it a consensus and start creating house pages for all OB houses - hopefully, RobinHood70 can work some wonders with that bot of his? --Krusty (talk) 05:03, 14 April 2013 (GMT)

Just as an aside, while I didn't include this in my project yet above, I fully intend to do the same thing for most (if not all) of the houses in Morrowind. The only thing I am hesitant about is that there are quite a few one room shacks that probably don't deserve a page, but the multistory house in the cities probably do. Jeancey (talk) 05:34, 14 April 2013 (GMT)

(←) I'm not set up to read Oblivion data, just Skyrim, but I can use CSList provided that all the information we need is in there. What, exactly, are we thinking we'd want? Just the Place Summary data? Not sure how much of that I can get from CSList, but I'll poke around tomorrow and see what I can figure out. – Robin Hood  ^(talk) 06:41, 14 April 2013 (GMT)

Terminology (again)

The name of the Skyrim player character. I brought this up around the time of release, because I was concerned about how unprofessional it would appear and how potentially confusing to readers it could be if the lore section used two or more terms to refer to the same person. After objection to Last Dragonborn, it seemed we settled on Dovahkiin. But that "consensus" was never really adhered to. And now, almost a year and half later, we have a roughly even split between the use of these two terms in the lore pages. Now it seems like there might be more objection to using "Dovahkiin" than "Last Dragonborn". I'm not advocating for dozens of frivolous edits to change it to one or the other without some other substantive reason to edit, and I really don't care about the ultimate choice, but it would be really nice if we could all be in agreement moving forward, because this is ridiculous. And if it matters to anyone, we have a bit more material to consider now then we did back then, as Miraak explicitly refers to the PC as the Last Dragonborn. Minor Edits^{Threats•Evidence} 02:34, 5 April 2013 (GMT)

I still think that in at least on any Skyrim pages, the player should always simply be referred to as "you". Removes ambiguity, and keeps the style of gameplay related articles in the 2nd person. The only time where this should even be an issue is on Lore pages where we have to refer to the player in the 3rd person. In those cases, my vote is for "Dohvahkiin". I still think it's a bit weird to refer to somebody as the "last" anything when we have no guarantees there will never be another. Miraak does say "last", but keep in mind, he's an egotistical maniac who believes himself to be immortal and is planning to kill you in a few minutes when he says that. Not sure his word should be presented as gospel. — TheRealLurlock (talk) 11:43, 5 April 2013 (GMT)

Personally, I think the "Last Dragonborn" seems more like a title. Esbern and various NPC's call you "Dragonborn". Arngeir and various Dragons call you "Dovahkiin". I prefer "Dovahkiin" as it's clearer - especially in the lore articles - who we are referring to. --Jimeee (talk) 12:09, 5 April 2013 (GMT)

The issue I see is in ambiguity. "Dragonborn" and "Dovahkiin" apply to an unknown number of people, while the prophetic "Last Dragonborn" is unique, like Nerevarine. If there is no ambiguity – and in this case, there usually isn't – Dovahkiin is suitable, but if clarity is required, Last Dragonborn should provide that (and possibly in some other cases, for example their first mention in the timeline 4E 201). The interesting thing about "Dovahkiin", which is my preferred option on the whole, is that you require someone knowledgeable about the dragon language to bestow it. Anyone who knows their history can recognise a "Dragonborn", but only those who have met the Greybeards or a dragon can reasonably be called "Dovahkiin". --Enodoc (talk) 12:43, 5 April 2013 (GMT)

I disagree that the word "Dovahkiin" applies to an unknown number of people, there is nothing in the lore that supports that. Even Tiber (who could shout) was never called "Dovahkiin", but was called a "Dragonborn". Our "Dovahkiin" is unique as he can absorb dragon souls, sometihng that no other mortal Dragonborn hero (that we know of) has been able to do. --Jimeee (talk) 13:09, 5 April 2013 (GMT)

Wait. I was going to stay out of this but now I'm confused: I thought that the player was recognized in game as "dragonborn" the moment he/she absorbed his/her first soul. I clearly recall the player and some guards defeating a dragon (Mirmulnir?) outside Whiterun. It was when the player stood next to the dragon and absorbed its power that the guards starting calling him/her "dragonborn". Now, we've established that dragonborn are recognized for exactly that--absorbing the souls of dragons. As for "dovahkiin", we say right here that dovahkiin and dragonborn are one and the same. The dragonborn is a term given to the player (and other past heroes) by mortal man. Dovahkiin is the exact same thing, just said in the dragon tongue. So now, dragonborn and dovahkiin BOTH apply to the player, and of heroes past that went around killing dragons for kicks and sucking up their power. But... "Last Dragonborn". That is far more unique. There's only one, and that's the player. As noted by Minor Edits, Miraak said so himself, and he's been around long enough to know. Even Esbern said something along the lines of "you're the first in centuries, and probably the last" (if you want I can probably go find the quote-- I just heard it). In a nutshell, I think "Last (Final?) Dragonborn" would be the most accurate (and then, throughout an article, just "the Dragonborn") title for the player. --Vulpa 13:22, 5 April 2013 (GMT)

I support "the Last Dragonborn" for Lore pages and Dragonborn pages to an extent, but it's unnecessary for Skyrim ones. It avoids confusion, even though there are very few known Dragonborns in history, Miraak is actually the only one who could cause some confusion on the topic. Of course, it's still a pretty generic title; every Dragonborn was the last at some point. It doesn't sound as unique as "Nerevarine" or "Champion of Cyrodiil", but it's the most distinctive title we can give him/her. -- Elakyn (talk) 16:03, 5 April 2013 (GMT)

@ Vulpa - The guards starting calling him/her "dragonborn" because of the old tales of Nords who could do the same as mentioned in the Book of the Dragonborn.

Dragonborn individuals are certainly not JUST recognized for absorbing the souls of dragons. Although Dragonborn and Dovahkiin are technically the same word and both apply to the player, there is a slight nuance between the "types" of Dragonborn. Alessia, despite being Dragonborn, could not absorb dragon souls (if you believe MK). We don't know if Reman or Tiber could either. I doubt all the heirs of the Septim bloodline could either, if we go by the Book of the Dragonborn. In this way we can create the distinction with Dragonborn and Dovahkiin. Like I said, "Last Dragonborn" is too much like a title, which is why I support that our hero is Dovahkiin. --Jimeee (talk) 16:59, 5 April 2013 (GMT)

(←) The "Last Dragonborn" is not a term introduced by Miraak, it was used in promotional material and in-game (vanilla) before Dragonborn DLC was known. Miraak himself is titled the "First Dragonborn". Just to cover it, Delphine calls Martin Septim Dragonborn, "For the last two hundred years, since the last Dragonborn emperor..." so we see that Dragonborn applies to more than Miraak and "you". The term Last Dragonborn comes from the prophecy, which ends with "The World-Eater wakes, and the Wheel turns upon the Last Dragonborn." This is the prophecy which you are a part of, to me it is explicitly calling "you" the "Last Dragonborn". It doesn't matter if more appear later, which would mean you weren't the "last", but you are still the "Last". It is a title given to you alone. Lastly, on dragonborn, Miraak does not call you the last, he addresses you as Last, "And so the First Dragonborn meets the Last Dragonborn at the summit of Apocrypha." The use of caps when addressing you shows that this is your title, not your position as last in the line. The problem with Dovahkiin, is that is is almost never used outside direct dialogue (or indirect in your presence), where addressing you informally by the more simple Dragonborn would be fine as it clearly is referring to you. The only usage I see is in Songs of Skyrim, where it is used in a songified version of the prophecy. Because Dovahkiin translates simply to Dragonborn, which can refer to more than one person, and a title has been clearly identified for the player (Last Dragonborn), I think we should move to using that title. Silence is Golden^{Break the Silence} 16:51, 5 April 2013 (GMT)

Also, see this page ~ Dwarfmp (talk) 18:27, 5 April 2013 (GMT)

Yeah, I linked to that above. For those of you keeping score at home, we're now tied 3-3. Minor Edits^{Threats•Evidence} 20:01, 5 April 2013 (GMT)

I'm going to throw in my support of the use of "Last Dragonborn" without reading any of the above discussion. This issue has already been dragged out far too much, and there's plenty of support behind the player character being Last. —Legoless (talk) 20:17, 5 April 2013 (GMT)

As am I. "Last Dragonborn" seems to be the only term that we're certain refers to the player character in Skyrim. I agree with Elakyn, though, that this term should primarily be used in lorespace. It's a proper title, as Jimeee said, which is perfectly appropriate for lorespace; in gamespace, though, "you" would be best. • JA^T 02:50, 6 April 2013 (GMT)

Okay, then, that sounds fine to me. "Last Dragonborn" is how Bethesda refers to the player character, and we should just take their word for it at this point. While "Last Dragonborn" has the potential to mislead, "Dovahkiin" is actively misleading, so it's hardly a decent alternative. Unless someone wants to filibuster for "Dovahkiin", I think we're done here. Thanks for your time, everyone. Minor Edits^{Threats•Evidence} 04:11, 6 April 2013 (GMT)

Oh oops, I didn't realize you already had linked to that discussion, I did not get the impression people read it from the posts here previously, my apologies ~ Dwarfmp (talk) 12:38, 6 April 2013 (GMT)

(←) So, are we free to change "Dovahkiin" to "Last Dragonborn" wherever we find it in Lore, or are we taking it on a case-by-case basis? Might be a good job for a bot if we are changing it wholesale. --Xyzzy ^Talk 16:32, 6 April 2013 (GMT)

I don't think having it automated would be a good idea. It might be used in the correct context on some articles (e.g. Lore:Dragon Language). I say change it where you see it. —Legoless (talk) 16:34, 6 April 2013 (GMT)

I agree. This is definitely a case where humans are preferable to bots. Otherwise, you're probably going to see changes that end up like this: "The Last Dragonborn, also called The Last Dragonborn...." :) – Robin Hood  ^(talk) 18:28, 6 April 2013 (GMT)

Skyrim Main page link to People instead of NPCs - revisited

The Skyrim NPCs page is just about impossible to find without searching for it directly, and that has been made more difficult since the wiki upgrade. I think the main Skyrim page should link to the NPC page instead of the People page. The NPC page already contains a link to the People page, and I would consider named People to be a subset of NPCs. Thoughts? --Xyzzy ^Talk 04:37, 20 September 2012 (GMT)

I would support this change. • JA^T 04:49, 20 September 2012 (GMT)

(←) I'm bringing this up again, including the response I got last time, since it never got resolved when I first brought it up last year. I would like a little more consensus before changing the Skyrim main page. --Xyzzy ^Talk 20:24, 5 April 2013 (GMT)

Currently, the namespaces MW, OB and SR seem to function in the same way with regards to this; People is linked from the main page, and NPCs is linked by some obscure link from within the People page. I agree that People acts as a subset of NPCs, as the trail on SR:People reflects this. I think there should be consistency across the namespaces, though. --Enodoc (talk) 20:34, 5 April 2013 (GMT)

Both are equally desired imo. I've updated the pages to have the NPC link first, with named people as a sub-bullet. Silence is Golden^{Break the Silence} 20:58, 5 April 2013 (GMT)

That works. --Xyzzy ^Talk 21:02, 5 April 2013 (GMT)

How about DB? I'd like to speak for our Reavers and Werebears. It's hard to visit them directly now. Dreamshadow (talk) 23:27, 5 April 2013 (GMT)

I overlooked Shivering and Dragonborn, they have also been changed now. Silence is Golden^{Break the Silence} 23:40, 5 April 2013 (GMT)

Skyrim:Statistics page?

Would there be any objection if I created a statistics page for Skyrim in the same vein as Oblivion:Statistics. I would sandbox it first. Just an idea for a future project. --Jimeee (talk) 23:59, 6 April 2013 (GMT)

I see and uphold no objections towards the creation of such a page, as long as the article is sandboxed and presented upon completion there is no real harm in having such a page when similarly the Oblivion namespace has one. The only concern would be with the possibilities of more additional add-on content with Skyrim and having to possibly update the page. -helenaanne  ^{talk ♥} 00:14, 7 April 2013 (GMT)

Fine by me, go for it. Vely^►t►e 00:21, 7 April 2013 (GMT)

Only problem with Skyrim statistics is that quite a few of them do not have any clear maximum. E.g. Because of the Radiant system, you can clear the same dungeon more than once, so there's no way to say what the maximum number of dungeons cleared is. It's the same reason it's hard to do a 100% completion page for Skyrim. But with that understanding, feel free. Just make sure to note that most of them can never really be completed. — TheRealLurlock (talk) 12:32, 7 April 2013 (GMT)

Daedric Font

Would we be able to have a Daedric Font template made like the {{DragonFont}} template? We do currently have a {{DaedricFont}} template but this one only works if you already have the font installed. There is also the {{Daedric}} template but this apparently causes some sort of technical strain for the wiki and needs to be used on sub pages linked to by the {{DaedricNotice}} template? — Kimi the Elf ^{(talk | contribs)} 03:43, 7 April 2013 (GMT)

It could be done via MediaWiki:Common.css like the Dragon Font:

/* Add webfont support for Dragon Font */
@font-face {
    font-family: 'DragonscriptRegular';
    src: url('/w/extensions/DragonFont/dragon_script.eot');
    src: url('/w/extensions/DragonFont/dragon_script.eot?#iefix') format('embedded-opentype'),
         url('/w/extensions/DragonFont/dragon_script.woff') format('woff'),
         url('/w/extensions/DragonFont/dragon_script.ttf') format('truetype'),
         url('/w/extensions/DragonFont/dragon_script.svg#DragonscriptRegular') format('svg');
    font-weight: normal;
    font-style: normal;
    font-variant: normal;
}

Should be easy enough I'd presume. Elliot (talk) 03:59, 7 April 2013 (GMT)

The biggest trick would probably just be getting the font into the various formats. Anybody have format converters for the various types listed? I've never even heard of .eot and .woff, personally. – Robin Hood  ^(talk) 04:51, 7 April 2013 (GMT)

Sorry for interruption. Just another minor problem. May I have anyone take a look at these two font files, here and here. It seems that there is something wrong with the zip files. Dreamshadow (talk) 07:21, 7 April 2013 (GMT)

They both appear fine to me. – Robin Hood  ^(talk) 08:12, 7 April 2013 (GMT)

Well, if you say so. Never mind. Maybe just some problems with my Internet connections, I guess. Dreamshadow (talk) 10:33, 7 April 2013 (GMT)

Ref ID N/A

Just something else I've been meaning to bring up. The NPCs that are spawned, and not present when you start a game, don't have a Ref ID. This makes their infobox have an empty space, obviously, and to me it looks as if the ID just hasn't been filled in yet. I think it's better to have it filled with 'N/A', so as to make the readers sure it hasn't been skipped. Now the only bad thing about it is that the Ref ID shows up under their name on top of the infobox, leaving a (N/A) there in such cases, but I feel that's not really a problem.

Anyway, I did fill that in on two NPC pages, but one of them has been removed again, so I'll just ask it here and see what's up ~ Dwarfmp (talk) 11:04, 7 April 2013 (GMT)

I brought this up somewhere over a year ago, possibly on Nephele's talk page after she reverted me when I added a refID with "ff" in it. I don't think a decision was ever reached. I think back then I suggested using "n/a" or removing it from the template for those NPCs. Using n/a seems like the best solution, unless someone else comes up with a better one. --Xyzzy ^Talk 20:09, 7 April 2013 (GMT)

I'd personally prefer "N/A" (capitalized), but yes, I support this proposal. • JA^T 20:45, 7 April 2013 (GMT)

How about "Randomly generated" or something similar, since "not applicable" is not technically true? --Xyzzy ^Talk 20:52, 7 April 2013 (GMT)

In that case 'Radiant' would be consistent with the rest of the NPC data that is random for some (race, gender, etc). Silence is Golden^{Break the Silence} 20:57, 7 April 2013 (GMT)

As long as it is genuinely radiant, I don't mind using "Radiant" either. I'm not sure if there are any situations where it isn't radiant, though. • JA^T 00:30, 8 April 2013 (GMT)

I'm pretty certain there are cases where NPC refs are generated (NOT randomly) during gameplay which are NOT part of the Radiant system. "Radiant" has a specific meaning in the Skyrim engine. It is not just a synonym for "randomly generated". So while this might get the point across, it would be technically inaccurate. I think "N/A" is probably the best to use, since it covers all cases. — TheRealLurlock (talk) 00:44, 8 April 2013 (GMT)

(←) I'm all for this, though I have less of an opinion as to the specifics of what we put in there. If there's a need to distinguish between truly radiant and those that are generated in some other fashion, then a human will have to make the change. If we go that route, there's a list in User:RobinHood70/Het of everything that would need looked at. If we just want to fill them all in with "N/A" (or whatever), it's a relatively simple bot job. The only question would be what to do with non-blank values that probably should be treated as though they were (specifically: "00000000", " ", "{{huh}}", "dynamic", "N/A", and "varying"), or if the bot should only fill in blank entries. – Robin Hood  ^(talk) 01:36, 8 April 2013 (GMT)

In cases where there is no unique RefID, I think "N/A" is best. The only reason I removed one is because it's not something we've done in the past anywhere from what I've seen. I am completely against using "00000000" (which I know was something rphe's bot did in the past) as it's incorrect information, and could possibly lead to confusion for people who aren't familiar enough with IDs to realize it means there isn't one. "N/A" is widely-used and understood, and is accurate enough to cover most (all?) cases which do not have unique RefIDs. — ABCface^◥ 16:14, 12 April 2013 (GMT)

What is wrong with leaving it blank? If you leave it blank, it doesn't even display in the table. What is wrong with that? I would also like to echo ABC's comment about 0000000... I have very much opposed to using that. Jeancey (talk) 18:06, 12 April 2013 (GMT)

So I looked into it. Currently {{NPC Summary}} displays the refid even when blank, but {{Creature Summary}} does not. This is what I was thinking of when I said it didn't display. How would everyone feel about using that style in NPC Summary? Compare it to this, a creature summary with a refid. Jeancey (talk) 18:17, 12 April 2013 (GMT)

I can agree with that, as it doesn't propose there might be a refid, because the "title" is gone. Silence is Golden^{Break the Silence} 18:20, 12 April 2013 (GMT)

Sounds like a good solution. If it doesn't exist, leave it blank. If it's radiant or random, state as such. I think if we leave it blank, and it can be randomly or radiantly generated, then we risk editors changing it to the random/radiant ID that they have seen. --Xyzzy ^Talk 18:45, 12 April 2013 (GMT)

I don't like the two empty cells. To me, that looks like something's gone wrong. When there's no RefID, I'd rather see the BaseID cell span the entire row (like Location, a few above it on the Giant page), even though that would effectively move it out of its customary location. While it would probably confuse people at first, now that I'm thinking along those lines, it might not be a bad idea to swap the order of the BaseID and RefID so that the one that's always going to exist is on the left, then the one that may or may not exist is on the right. I have no firm preference as to whether we go with RefID = N/A or just have the BaseID span the row, though. – Robin Hood  ^(talk) 19:10, 12 April 2013 (GMT)

Whatever decision we come to, we may want to explain it on the Form ID page. If we decide to leave it blank, then Dwarfmp's concern that some users may simply think that the ID hasn't been filled in yet can be addressed. And if we decide to fill in "N/A" or some other entry, then, not only is it clear that the information is complete, but we can have somewhere to explain that some RefIDs are dynamic, some are radiant, etc. That page already explains a little bit about Ref IDs, so we may as well explain more there about why there may not be a specific RefID listed on a given page. — ABCface^◥ 14:33, 13 April 2013 (GMT)

(←) I've changed the RefID and BaseID fields to display "N/A" for the time being, though re-reading, I realize that that wasn't really a consensus for that. So, questions:

1. Do we want "N/A" displayed or do we want complete blanking, like in the Creature Summary. I'm really not a fan of Creature Summary-style blanking, personally, but if that's what everyone else wants, it's easy to make the template do that.
2. If we go for "N/A", is doing it via the template the best solution or should we add "N/A" manually to all the blank refids? If we do it via the template, then any new game will also display "N/A" by default until a bot fills in the correct information. Doing it manually avoids that potential problem, but then we need to make sure any future entries are consistently using "N/A".

Whatever the case, I'll be fixing all of the other irregularities (mentioned in my previous outdented post) shortly. For those that are following the related discussion on my talk page, the plan for now will be to leave blanks blank, and leave "N/A" as "N/A" so that if we opt for N/A as our final solution, I'm not blanking it tonight only to have the bot revert it tomorrow). – Robin Hood  ^(talk) 01:54, 17 June 2013 (GMT)

Dialogue, Dialogues or Conversations

I'm working on add unique dialogues to SR:people pages in recent days. I've noticed some conflicts about the standard layout and I'm a little confused. In order to seek the final unification, I brought it up here. As you know, a NPC's unique dialogue may be just some single sentences, may be a short conversation with other NPCs. At this moment, I have the following concerns:

• 1.Subtitle: Dialogue, Dialogues or Conversations, which one should we use. e.g. Conversations here and Dialogue here(most popular cases)
• 2.Summary: For a short conversation, a summary is needed? e.g. here and here
• 3.Table: Is it necessary to use a table? e.g. here and here, and Alphabetface's opinion is here.
  

After all, the final unification is needed. Dreamshadow (talk) 05:09, 11 April 2013 (GMT)

Dialogue should be used. In this instance, dialogues is incorrect, grammatically (I'm fairly sure. I can't find the form in online dictionaries). Jeancey (talk) 05:13, 11 April 2013 (GMT)

I see. Shall we change the "Conversations" on some pages into "Dialogue"? What's more, how about other problems I submit, any ideas? Dreamshadow (talk) 12:10, 12 April 2013 (GMT)

I agree that "Dialogue" is the best header title. As for the short bits of conversation that are included with the main section of an NPCs article, I think that leaving them in that section is fine for now. If we are going to create a "Dialogue" section, then any dialogue should probably go there, unlike Bryling's page. As Krusty stated on ABCFace's talk page, a table is probably most appropriate for random dialogue. All of this is mostly a matter of personal taste. Consistency across articles is good, but not necessarily a hard-and-fast rule. --Xyzzy ^Talk 14:04, 12 April 2013 (GMT)

Very well~ I've got the idea and I like it very much. Thanks~ Dreamshadow (talk) 14:25, 12 April 2013 (GMT)

To be super-pedantic, the term "dialogue" technically means a conversation between 2 (and exactly 2) people. Compare to "monologue", which is just one person talking. So technically, any conversation involving 3 or more people is not technically "dialogue". But honestly, nobody uses that strict a definition anymore, so whatever. — TheRealLurlock (talk) 19:48, 12 April 2013 (GMT)

That's incorrect actually TRL:

noun 1. conversation between two or more persons.

It isn't JUST two people. Jeancey (talk) 19:56, 12 April 2013 (GMT)

(←) My preference would be to not have a separate section at all if it were avoidable. It messes with the normal flow we used with the ONPCRP. Introduction, schedule, inventory, spells, dialogue, rumors. Rumors about the NPC traditionally go last, but with dialogue split between two sections rumors are thrown into the second. Of course, NPCs and the player character used to have considerably less dialogue, so I kind of understand it even if it subconsciously annoys me every time I see it. If the conversations with other NPCs are going to be split off, I prefer it to be labeled under "Dialogue". --AKB ^{Talk Cont Mail} 21:03, 12 April 2013 (GMT)

Jeancey: Depends on how originalist you make your definition. The "Di-" prefix means "two". In the original use of the term, and I'm talking ancient Greek theater here, it specifically meant "two". Obviously, that is not consistent with modern usage at all, just a curiosity. — TheRealLurlock (talk) 23:51, 12 April 2013 (GMT)

Actually, no, the prefix is "dia-" meaning "through" (c.f. Wiktionary entry, etymology). – Robin Hood  ^(talk) 01:24, 13 April 2013 (GMT)

• 1.Subtitle: I would not mind using Dialogue or Conversations, however its a good idea to choose only one for consistency and Dialogue seems the most popular.
• 2.Summary: The summary is a good idea. Some of the conversations only take place at certain times or at certain places.
• 3.Table: Your two examples are completely different. I do not think most people including Anoriath needs a table, however for Danica_Pure-Spring her random dialogue is easier to list in a table.

Just my opinion. — Kimi the Elf ^{(talk | contribs)} 01:33, 13 April 2013 (GMT)

Thanks everyone, your ideas are quite valuable. From my point of view, Kimi's opinion would be the final answers. As for AKB's ideas, they are also reasonable. However, I'm not familiar with OB and I don't have a clear view about dialogue in OB. In Skyrim, NPCs would have four different kinds of unique dialogue and we may treat them in different ways.

• 1.Quest-related dialogue, they should be recorded in "Quest-related events". Some featured articles are great samples. e.g. Legate Rikke
• 2.Greetings, when you talk some NPCs or wander near them, they may have some unique dialogue. It would be nice if they can be included in the first paragraph. Otherwise, they may need a single section. e.g.single section and included
• 3.Conversations, some NPCs may talk to each other randomly or in some scripted cases. In this case, a single "Dialogue" section will be needed. If possible, a summary would be welcome. e.g.a summary and scripted conversations
• 4.Unique topics, players may choose a unique topic and talk to them and they have scripted replies. It should be included in the first paragraph. e.g.a good sample

By the way, I think Danica Pure-Spring is really a special case. It would be hard to track every dialogue without the help of CK. Hopefully, they are rare cases. That's all, any other ideas? Dreamshadow (talk) 04:22, 13 April 2013 (GMT)

I disagree with that method of organization. Greetings shouldn't be in the first paragraph. There is enough to summarize about an NPC already in the first paragraph without adding in lengthy quotes. A good example of decent organization brought on by the ONPCRP would be Janus Hassildor. Really, the only issue with Skyrim is the extreme increase in the number of NPCs who talk to each other instead of the player character, making organization slightly harder. However, that still doesn't mean we can't essentially do it the way we were for Oblivion NPCs. --AKB ^{Talk Cont Mail} 19:00, 13 April 2013 (GMT)

(←) If the NPC page is anywhere near decent, you won't have a "Dialogue" header of the sort ~ Dwarfmp (talk) 22:47, 13 April 2013 (GMT)

I still stand by my opinion that the table on Anoriath’s page is wrong. Tables should only be used when several different dialogue options can result in some kind of conversation (e.g. Danica). In any case, Dwarfmp is right - to build an NPC page, dialogue can occur everywhere, preferably without headers – so it may be a good idea to just start with the static conversations as they more often than not warrant their own header (example). I hope that made sense, otherwise maybe my response on this page is more understandable. As for the headers themselves (Conversations, Dialogue), it’s merely a question about what you think is right with the NPC at hand – like Dwarfmp said, if the page is “complete”, headers sometimes are not even relevant. --Krusty (talk) 04:47, 14 April 2013 (GMT)

Agreed, I can help remove these tables. My concern is that sometimes it's really hard to include every unique dialogue in the additional paragraphs, such as some less important NPCs or NPCs with large quentities of dialogue and conversations, such as this one(less improtant) and this one(too many scripts). At this monent, a single section would make them clearer and more convenient. Dreamshadow (talk) 05:41, 14 April 2013 (GMT)

The first one is easily changed so that the dialogue is in the main body of the article. See this edit. Not the best way, but it's so easily done to remove the secondary section.

The second one would be improved if the split off dialogue in the Conversations section was moved to areas that covered times in which she would have such conversations. It really doesn't make them any more clear as currently it provides no additional commentary explaining when those conversations will happen, with it just being a list of dialogue. As of right now, that Conversations section on that second article looks a lot more like how we usually list dialogue in sandboxes before we finish up an article for launch than proper content. So while it may be more convenient for some users who just want the dialogue, it's not better or simpler for anyone else who wouldn't have much of a clue what triggers those lines. --AKB ^{Talk Cont Mail} 13:04, 14 April 2013 (GMT)

To be frank, I don't like the first edit very much. It looks a bit messy. More statement would make them better and clearer. As I mentioned above, a summary would be nice before we list some conversations. Dreamshadow (talk) 13:30, 14 April 2013 (GMT)

(←) For the first one, adding more explanations before each line is still very easily done. The point I was trying to make was that it took me less than a minute to do it that way to get it to match the existing standard for completed NPCs. Either way, it's still better than just listing them without any kind of explanation in a separate section. It doesn't look like a completed article when you do it that way. With Sern there was literally no explanation for anything he said, so how would a reader even know what those lines meant or even who said them with your version? While the second case with Verona is tolerable in my opinion as it would be rather bulky to add into the main article either way, the first one just doesn't work.

As for the second one, you can provide more explanation, with it in its appropriate place. Just by dropping the conversation into a section of the main body where she would have that discussion would make it utterly more clear even if you didn't add any further explanation. If she has them all at any time, it still isn't that hard to incorporate it into the main body of the article by simply saying she'll have this conversation with X about Y. But as I said above, that's more of a matter of personal preference than what is right or wrong. I completely agree with you that we should summarize a conversation before we put it on an article, but that's just basic logic. Of course we're going to explain why, when, and where an NPC will say something. That's just how you write NPC articles. If you find any situation where this isn't the case, I'd consider the article to be missing content. With the case of Varona, I'd say it was at the very least missing any explanation for who she was having the conversation with and why. --AKB ^{Talk Cont Mail} 13:58, 14 April 2013 (GMT)

Yeah, more explanations would be better. I'm not willing to list raw dialogue there without any explanations either. After all, I'm still too naive to make them completed. Sometimes, I'm not quite confident of my English. However, I'll try my best to make them look better. Dreamshadow (talk) 14:45, 14 April 2013 (GMT)

For the record, I did the same thing when I started. I had a tendency to split things up into its own sections (see this edit). As I learned after some help, this just wasn't the right way to do it. It looks better when they're organized in the preferred manner. You have no reason to feel bad, as learning how to do it the right way can be hard, especially when that way hasn't been enforced with the latest game as much as it should. I'd suggest giving the NPC Layout Guide a look if you haven't already Not only does this help our readers by making it easy to jump from one part on a specific attribute of the character to the next as you'd eventually learn the article layout, but it also looks much better. I've been using the Oblivion NPCs as an example of how this should be done as those are without a shadow of a doubt the best NPC pages on the site, and any editor should try to emulate their style for Skyrim when possible. The issue really lies with the fact that we went into Skyrim without a project like the ONPCRP to help guide article development. Not anyone's fault, it would just had helped avoid issues like vastly different styles on different articles. --AKB ^{Talk Cont Mail} 15:09, 14 April 2013 (GMT)

Spamwich

I have an idea! Of course, I know just slightly more than nothing about such things like if this is possible or not, but... New accounts such as ' LailaoetwcdshtkDriggins ' or ' DorathyaezqkcwmqxZannino ': we all know that they have no intention of helping the site. So. What if we limit account creation to, say, less than 20 characters? That's no problem for anyone who means well (give me one example of a real contributor to this site with a username longer than that), and might stop this rather unimaginative string of bots. --Vulpa 16:41, 14 April 2013 (GMT)

Dominus Arbitrationis. I'm sure there are more. Jeancey (talk) 16:48, 14 April 2013 (GMT)

User:Mudcrabs-More-Fearsome-Than-You (31), and pushing it is MethodicMockingbird (19), Helenaannevalentine (19), and Alpha Kenny Buddy (17). Silence is Golden^{Break the Silence} 16:50, 14 April 2013 (GMT)

His Grace, Jon Targaryen, the first of his name, King of the Andals, of the Rhoynar, and of the First Men. He who is the Prince That Was Promised, and Azor Ahai reborn (167) has a couple of valid edits, but he's still a non-bot. However, I would not protest to a limit on the account creation, despite preexisting accounts. But there is also the kitten captcha which could be implemented, though I don't know what's happening on that end. If that gets put into place, then I think name limit won't be necessary.

My one concern would be that spam accounts would get smart and chop down their names in order to make accounts, ending up taking some possible names and making account creation difficult for new users. Vely^►t►e 17:01, 14 April 2013 (GMT)

I was just going to add that this would only affect accounts already made (like, Dominus and Mudcrabs wouldn't be made to shorten). And new accounts who actually plan on making valid edits surely wouldn't mind having shorter names (after all, they haven't made a "name" for themself with it yet, it's not changing much). I realize that you've all scrounged up some examples against me, but really, it's a pretty rare thing to have a username longer than 20 (or like 23) characters. However, if the new captcha makes this irrelevant I suppose I withdraw. :P --Vulpa 17:08, 14 April 2013 (GMT)

I think the Title Blacklist extension could be made to check user name lengths using a clever Regex, but if not, it should be fairly trivial to create an extension that would do it. Either way, it would have no effect on existing accounts at all. I'm not sure it gets us all that far, though. For simplicity's sake, I've limited my searches to November 2011 forward. This ensures that we're looking at moderately recent trends. Let's also assume that those trends will be, at least roughly, reflective of future trends. Yes, Skyrim was created during that time (which is why I chose it), but hey, ESO's on its way, so I think it's fair to assume that it's a good example of what account creation patterns will be like.

Anyway, since roughly the time of Skyrim's release, we've had 27,874 user accounts created. Of those, only 2337 (8.4%) have had names longer than 20 characters—2280 (8.2% of the base) of whom have never made an edit. For the 57 out of 27,874 new users (0.2%) who have made edits—and keep in mind that some of those are legitimate, but some are spammers/vandals—I'd certainly be willing to say, "sorry, you'll just have to figure out a shorter name." There's also the possibility of a pre-existing user creating an account with a longer name for any users who feel a desperate need. I believe all staff have that right (I think it comes with the title blacklist override). But the question remains, is eliminating 8.2% of spammers worth writing an extension for, and inconveniencing a small number of users who wanted a long name?

On the flip side, if we do write a custom extension, as opposed to using the Title Blacklist, it becomes easier to add other filters that may again only capture a small number of the total (e.g., excessively long e-mail addresses at time of registration), but those small numbers may begin to add up to something significant. – Robin Hood  ^(talk) 18:32, 14 April 2013 (GMT)

I do think names of 20 chars are not unreasonable. That Jon Targaryen guy up there on the other hand, is WAY too long, and I'd have no problem with not allowing names of that length, even for legit users. (I think that username adds up to more characters than the sum total of all his contributions.) I'm just not sure where a reasonable place to draw the line would be. Too short and you disallow a lot of perfectly reasonable names. Too long and you might as well not even bother. Unfortunately, as far as spam prevention, I doubt this would be very effective, as currently most of the spam that actually gets past the filters uses much shorter names, too short to even consider blocking based on name alone. Those long names may be spam bots, but so far they've almost never successfully posted any spam, so blocking their creation wouldn't really do all that much that the filters aren't already handling fairly well. — TheRealLurlock (talk) 20:43, 14 April 2013 (GMT)

Admitting that such limitation was put into place, wouldn't spammers just make bots that generate shorter names? I don't really see the issue being resolved here - not that it affects me in any way. -- Elakyn (talk) 21:06, 14 April 2013 (GMT)

(←) They probably would. The problem with fighting spam is that it's a never-ending battle. They change tactics, we adapt; we change tactics, they adapt. It's just a question of how effective any given measure is and how long it will continue to be effective. – Robin Hood  ^(talk) 21:10, 14 April 2013 (GMT)

Just piping in to say that TheRealLurlock is absolutely right. The vast majority of spammers use shorter usernames, so it would not be a very effective spam prevention tool. Also realize with the stated statistics that many users create an account and then don't use it, forget their password and make a new one, or even forget that they have an account and make a new one (I've done this myself a few times, actually). And RobinHood70, I also agree that the fight against spam is a never-ending battle. Implementing the Asirra extension would do wonders on the account creation end of it, and the filters are doing a solid job of keeping out the actual spam. These two in conjunction should practically eliminate spam from reaching our site.

As for whether or not we should implement this, I'm on the fence, but I'm leaning towards opposing it. The benefits and tradeoffs would be slim, and although it would only affect a handful of users, I'm not keen on restricting freedoms like that. We have quite a few prominent users with long nicks, and odds are we'll have more in the future. • JA^T 22:01, 14 April 2013 (GMT)

Prev: Archive 35

Up: Community Portal

Next: Archive 37