UESPWiki:Community Portal/Templates

This page has been retired. New template discussions should be brought up on the relevant template talk page, or in the main Community Portal if multiple templates are involved.

This is the Template discussion forum used for community-wide discussions about UESP's templates. It has been created as a place to discuss the technical aspects of template design and usage without cluttering up the main Community Portal page with issues that most users would have little or no interest in. It can be used to discuss broad categories of templates, or to draw attention to a discussion on a specific template's talk page.

Color TemplatesEdit

I just changed {{Oblivion School Color}} only to come to the realization that it was no longer being used anywhere and had been replaced by templates such as {{ALT}} and {{CON}}. This brings up two questions:

1. Do we want to do all other templates (like {{Race Color}}) in a similar fashion?
2. Should we keep the existing pages, even if they're not in use currently, in the event that they're needed? CSS classes may not cover all possible future uses.

‒ Robin Hood↝Talk 04:49, 10 March 2010 (UTC)

I think it makes sense to delete Oblivion School Color. The profusion of color templates is a little embarrassing (not just {{ALT}}} and {{CON}} but {{ALT-header}} and {{CON-header}}) but I think we're stuck with them. The alternative would be to have a bot make thousands of changes with no clear benefit. Unless you can come up with a brilliant solution that makes it worthwhile :) rpeh •T•C•E• 08:24, 10 March 2010 (UTC)

Well, the header templates could readily be combined into one (with a parameter for the school, then grab the first three letters for the class), though there's no pressing reason to do so that I can think of. It probably makes even less sense to do that with the basic school colour templates. Ultimately, though, I think the various spell tables could (and should?) be replaced with a template along the lines of the Parameters template, where the template would look something like:

{{Spell List
|!|Alteration||
|Defend|Apprentice|43|[[Oblivion:Shield|Shield]] 15% for 30sec on Self <-- or using an {{OB Spell Effect}} like the MW one
|...
}}

The template itself would be a relatively straight-forward extension of the Parameters template, now that I think of it. I'll run HnB tomorrow to see if we're using those templates elsewhere.

What about Q1? Should we convert the Race Color and Race Color FC templates to classes as well? I haven't really looked into how they're used, but it's possible if we make them classes that they could be combined to include both background and font colour in one. I haven't looked at most of the others yet (React Color, Specialization Color, etc.), but I'd guess there's stuff there as well.

I still think the existing color templates could come in handy, since they return the HTML colour number which is more widely usable than a class, but then again, why keep something we don't need. Maybe the best solution is to keep a short description of deleted templates somewhere in case we need them again, then delete them so they don't get used accidentally. I dunno, maybe I'm over-complicating things...I do that sometimes. :) ‒ Robin Hood↝Talk 09:16, 10 March 2010 (UTC)

For consistency, I suppose we should change the standard templates to use classes. I wonder how many places use the colours without using a template? rpeh •T•C•E• 05:30, 11 March 2010 (UTC)

Interesting Category IssueEdit

Back in October, I brought up the issue that {{NewLine}} wasn't showing up in Category:Protected Templates. On a hunch, I added a blank line before the {{/Doc}} like there is in {{Linkable Entry}} (which I used as a base of comparison since the category showed up properly there). Much to my surprise, it worked! The odd thing here is that "Protected Templates" was displayed at the bottom of the NewLine page both before and after the change. It's not like this was a case of line wrapping corrupting a table or anything, clearly the wiki had some idea that that was the category to be used for that page. In any event, I thought I'd mentioned it here as a "gotcha" for template designers to watch out for. ‒ Robin Hood↝Talk 22:08, 10 March 2010 (UTC)

It's not the newline, it's a job queue issue. I had similar issues with some of the templates Joram created if the documentation was created after the main template. For some reason, the job queue doesn't realise that it needs to update the categories on the template. If you had just null-saved NewLine, it would probably have picked up the category. Or had you already tried that? rpeh •T•C•E• 05:28, 11 March 2010 (UTC)

I think I tried that back in October, but I certainly didn't try it today, so I can't claim certainty on that. It occurred to me that it might be the re-save that had triggered it, but I didn't think it was worth playing around with a template that's used on about a million pages. :) But you have a point, I've seen similar behaviour with other pages that have nested transclusions as well, so perhaps that's all it was. So the next question then is: how do you create the chicken and the egg simultaneously? ;) I think the best approach for new or substantially-revised templates may have to be to save the docs without examples, save the template, then save the docs with examples...or just save the template twice. I wonder if 1.15 or 1.16 fix this issue? I'll slog through the list at some point and see if anything stands out. ‒ Robin Hood↝Talk 06:47, 11 March 2010 (UTC)

I've tended to save the template first (with a redlink for the doc page), then the docs. The queue seems intelligent enough to realise it needs to fix the redlink, but if you then add a category to the doc page, it doesn't push it to the template. For new templates, it's easy enough to check because I do a (roughly) daily check on the maintenance pages that picks up missing categories. For new cats that aren't being applied correctly, it's a bit more tricky though. rpeh •T•C•E• 07:20, 11 March 2010 (UTC)

I just tried that with {{Old Link}} and it made no difference. Old Link didn't show up under Link Templates until I did a null edit. ‒ Robin Hood↝Talk 04:02, 12 March 2010 (UTC)

Journal EntriesEdit

I just tweaked the Journal Entries template in my sandboxes, and I'd like feedback on whether there's a better way of doing this, if we should go with what I've got, or leave it as is. For the sake of discussion, compare the journal entry table at Oblivion:Whodunit?#Journal Entries and in my sandbox.

The advantages of my version are that it produces a single table, thus allowing columns to properly size based on content rather than forcing them to fixed width (which can still misalign in exceptional cases, like if there were a stage of 10000000), and that there's no thick double-line at the beginning of the secondary header (caused by the end of one table and beginning of the next). The disadvantage is that the secondary header must be specified entirely manually, which may have a higher tendency towards typos and would need to be manually reformatted should we ever change the header style. A workaround for that might be to create another subtemplate that could be used behind the scenes for the primary header and manually specified for secondary headers, i.e. |!|{{Journal Entries/Header|id=Dark08Whodunit}}| (with the title defaulting to the page name in this instance). Thoughts? ‒ Robin Hood↝Talk 00:37, 21 March 2010 (UTC)

Wow. I'm rather impressed. I had thought that things would look much better that way but I didn't think there was a realistic way of doing it. Now I see your solution, I'm a bit embarrassed I didn't think of it myself! I assume it works okay on extreme examples like this? If so, I'd say "go for it!" rpeh •T•C•E• 01:33, 21 March 2010 (UTC)

I'm actually playing Oblivion instead of game-testing or modding, so I'll be brief (for a change): Have another look at my sandbox. ‒ Robin Hood↝Talk 04:45, 21 March 2010 (UTC)

I find it a bit unnecessary. The current system right now works just fine, and for once in my life, I think we should go with the simpler version. The '!'s are exceptionally confusing as it is common table syntax. I think the |header=no portion is adequate enough. Plus, that's an extra 700 edits that, when it boils down, aren't needed. Elliot 07:55, 21 March 2010 (UTC)

The !'s were chosen because they resemble common table syntax...they are, after all, creating header rows. It's also how I've done it in the {{Parameters}} template, so it's consistent. The syntax could be anything at all, though, even something stupidly verbose like |Please insert another header here|Quest (ID)|. Also, it wouldn't be 700 edits, since only those currently using the header parameter would need to be edited, which is 46 pages. From an appearance standpoint, the header=no parameter works well enough, though the double-line is a bit distracting, but the other thing to consider is the rendering standpoint. One table will be smaller and render faster than multiple tables (though even with rpeh's extreme example, I'll admit that the difference would be very small). ‒ Robin Hood↝Talk 08:58, 21 March 2010 (UTC)

I don't think it would be good to use it, since when I looked at it, it was confusing. Plus, it pulls the id from the #save. It just seems a bit unnecessary to over-complicate something that really isn't messed up. Elliot 20:09, 21 March 2010 (UTC)

<- It occurred to me after I shut off last night that the sub-template could readily use parameters 2 and 3 to create the header, instead of just 2 like I've designed it now, so there'd be no need for the manual entry at all (any more so than it is now, that is). Maybe something like this (just off the top of my head...I haven't looked at the actual code): {{#if:{{{2|}}}|{{{2}}}|{{{id|{{PAGENAME}}}}}}}. ‒ Robin Hood↝Talk 22:21, 21 March 2010 (UTC)

ifexist / ifexistxEdit

I'd swear that the {{#ifexist}} function used to not add the tested page to wanted pages, but in any case, at this point in time, it definitely does: If a page checks a target using #ifexists:, then that page will appear in the Special:WhatLinksHere list for the target page. I'm guessing they made that choice so that if a redlink page is later created, there's some way for the original page to update itself, although I'm not even sure that's the case....

IMO, it's just annoying to have wanted pages filled up with pages that we really don't want just because ifexist forced them to appear. Such as Morrowind:Jerall_Mountains, because Lore:Blades includes a Lore Link to Jerall Mountains, which is then transcluded into Morrowind:Blades. So I just added an {{#ifexistx}} function to MetaTemplate. It uses the exact same code as the standard function (down to the expensiveFunctionCount), except it does not force the page to create a whatlinkshere entry. I set up a quick test of it at Template:Sandbox (equivalent to Template:Lore Link) which is being used on Oblivion:Sandbox. And voila: a link to Lore:Orc_Names that doesn't make a pointless bookkeeping entry for Oblivion:Orc_Names. The main problem is that until I hear from Daveh, we can't do much other than test the function, because it's only available on content1/2.

So do we want to use ifexistx instead of ifexist? And while I'm at it, do we really want the expensiveFunctionCount? --Nephele^Talk 17:53, 2 June 2010 (UTC)

It definitely, definitely didn't used to add such wanted pages, otherwise the {{Lore Link}} template would have been a total waste of time. It got changed after the last major MW upgrade and caused (part of) the explosion in Wanted Pages. If there is any way you can fix it, I will have your babies be very grateful.

I tried a couple of ways of hacking this problem (either here or here - probably both, but I can't tell any more). Nx made some comments on the talk page of one of them to the effect that this could cause problems if a pseudo-wanted page was created afterwards. To use your example, if MW:Jerall Mountains was created, the MW:Blades article would still link to Lore:Jerall Mountains because MediaWiki wouldn't know to update the link. My attitude here is that the number of ratio of wanted-links-that-we-will-never-want to wanted-links-that-we-do-and-which-are-caused-by-this-problem is about 100:1 so it's better to fix the main problem. Just thought I'd mention it though. rpeh •T•C•E• 18:23, 2 June 2010 (UTC)

Yeah, what Nx mentioned is what I was guessing at above about pages not knowing to update themselves. But at the moment I'm having a hard time even figuring out whether that logic is true (I'm jumping back and forth between a half-dozen different things, so I'm a bit too distracted to be sure I'm thinking it through properly). Nevertheless, the problem would be fixed as soon as someone edited Lore:Blades or MW:Blades. Or if we were really worried about this happening on a few rare pages, we could just make a dummy edit to Lore Link once every few months. So perhaps we want to limit the number of places where we use existx -- maybe create a special Category for templates that use existx -- so that we can do whatever periodic maintenance seems necessary. --Nephele^Talk 18:39, 2 June 2010 (UTC)

A category would be a good idea. I can only think of a couple of other templates that would need this anyway, with the other fixes you've added. {{Morrowind Town Table}} and {{PageLetterMenu}} are definitely causing wanted links, and there are others like {{Morrowind Merc Notes}} that have got hacks in place to stop it.

I had been gearing up for another pass through the templates to tweak some stuff, and I know RobinHood70 was too. I'm going to hold off for a bit until things settle down a bit. rpeh •T•C•E• 19:07, 2 June 2010 (UTC)

I love the idea of having existx available, and whenever I go through the templates for Round 2, I would keep my eyes out for places we might want to use it. Actually, a good approach might be to use it in {{Lore Link}} and then see what Wanted Pages are left and if it's a template that's causing them, but either way, it would be a good thing to have.

Oh and thanks for tracking down those discussions, rpeh. I remembered Nx was involved, but little else beyond that and probably would have had the devil's own time finding them again. Actually, I remembered one specific discussion directed at me specifically, which can be found here (and incidentally clarifies that it was Exist, not Exists, though you've obviously already figured that out). ‒ Robin Hood↝Talk 01:51, 4 June 2010 (UTC), Edit: 02:00, 4 June 2010 (UTC)

I've done the switch on {{Lore Link}}, {{PageLetterMenu}} and {{Morrowind Town Table}}. The first two were causing most of the problems but MTT had been creating four Wanted Pages that had been bugging me for ages. I've also set up Category:Templates Using Ifexistx to keep track of them.

Before the change, we had 439 Wanted Pages. After the template changes, plus a few edits to clean up some stuff, we now have 233. 147 of those are from Daggerfall and have been around for ages. 41 are from Lore and might just get created at some point. The rest is an assortment of low-priority pages from other namespaces. rpeh •T•C•E• 10:22, 6 June 2010 (UTC)

Excellent! Glad to hear it's working out well. I'll add it to the Round 2 "to do" list to look for other templates that it would be useful on. That'll give us plenty of time to see if there are any issues with it before it gets put into too many templates. ‒ Robin Hood↝Talk 13:30, 6 June 2010 (UTC)

Editing AllowedEdit

I started putting together an Editing Allowed template, that users can put on userpages if they want to give permission for other editors to modify the page. So far I've just done the minimum, so it's not really ready for the community as a whole to use. The thought is that when used on a page it will display two things on the page:

1. An icon at the top of the page, in particular so that patrollers can quickly check the status of the page. For now I just used of some of the existing padlock .pngs, but I'm not sure whether they're the best choice. Even if we do want to use padlocks, we probably want some extra colours (e.g., green for Editing Allowed="all"). But I'd like to find out whether there are any other ideas for what type of icon to use.
2. A notice-box summarizing what type of editing is allowed. I'm thinking some users might prefer to have the notice-box somewhere out-of-the-way (like the very bottom of the page), which is part of the reason for having an icon appear at the top of the page.

Anyway, I just wanted to post this info here in case anyone is curious what I was up to with that template. Any help finishing off the template would be very welcome :) --Nephele^Talk 05:58, 8 June 2010 (UTC)

I might just take a stab at this, if that's okay. As you may have seen, I am expending quite a bit of effort in my own userspace lately, creating background information pages for a TES fan fiction series that I plan to write. I'd be happy to give other UESPWikians permission to edit my pages, and I think this would be a handy template to achieve that. I have copied the contents of Editing Allowed into my Sandbox Pa, and I will work on it there. I have set up an example usage page in my Sandbox Veh, which uses a {{#define:}} to shorten the path, making it easier to read the examples (I hope). – Daric↝talk 13:49, 24 January 2013 (GMT)

I think I have got this all working properly now, in my Sandbox Pa. I also have some Working Examples available to check the results of each parameter. I haven't migrated it back to the Template: namespace yet, and I'd appreciate some feedback before I do, being that this is my first template editing exercise for the Template: namespace. Thanks in advance. – Daric↝talk 07:49, 25 January 2013 (GMT)

I gave it a quick once-over, and it looks pretty good. I'm not sure if we need categories, as it's not likely to be a template that's in wide use at any given time, but they're certainly not hurting anything, and who knows, maybe they'll help lead people to users who want other editors to look at their pages. Oh, and for your next steps, you can scratch off Nephele, as she hasn't been on in about half a year. :) – Robin Hood  ^(talk) 09:11, 25 January 2013 (GMT)

Thanks for that RH. I have migrated the files to the Template: namespace now, and it all seems to be working okay. I have added the {{Editing Allowed}} talk page to my watchlist. I went ahead and created the categories. I think I was creating them while you were making the comment above. :) – Daric↝talk 09:36, 25 January 2013 (GMT)

Pre autosizingEdit

It only occurred to me after I added the new "autosize" parameter to {{Pre}}, but should I change that to respond to width=auto instead (and only for cases where scroll isn't specified)? Currently, the width parameter is only allowed for scrolling, and autosize doesn't work well with scrolling, so it might make sense and be more user-friendly to allow the template to basically fake the functionality that CSS doesn't allow. It might make the template coding a touch more complex, though...I'd have to examine it in more detail to be sure. Thoughts? ‒ Robin Hood↝talk 20:36, 26 July 2010 (UTC)

To be honest, the only person using this template is you so I don't see it as a big deal. rpeh •T•C•E• 21:39, 26 July 2010 (UTC)

At a glance, it looks like you're right, which surprises me given the versatility of the template compared to plain <pre> tags. ‒ Robin Hood↝talk 23:50, 26 July 2010 (UTC)

The template is more versatile, true... but the number of situations in which that versatility is required is very small. It's one of a number of templates where although I know something exists, it's more trouble to use the template than not to use the template. Another example is that "discussion moved" template. I'm aware that it exists, but it's more trouble to find out what casing and parameters it uses than to just link to the source/dest myself. When I've created (or edited) a template, it's usually been because I've found a genuine need for it while editing pages. This seems to be a case of a template being created because it might be useful. Sorry - but that's the way I see it. rpeh •T•C•E• 00:08, 27 July 2010 (UTC)

I can't disagree with you on the "discussion moved" template. In that case, I use it only because it ensures a standardized message. I even gave the parameters names because I could never remember the order...only now I can't remember the names, either! :) I guess {{Pre}}'s biggest use is in the template documentation and a few other such places, which, as you point out, means it's mostly me at the moment, though I find the ability to properly indent multi-line pre tags useful as well when replying to things.

For anybody else following the discussion, I've gone ahead and changed it to use width=auto. ‒ Robin Hood↝talk 00:18, 27 July 2010 (UTC)

Cleaning CleanspaceEdit

Like <nowiki> and other similar tags, <cleanspace> leaves single-character invisible "junk" in the output. As you may have noticed from my recent experiments, I've been working on a way of leaving the output "clean", so to speak, and have managed to find one way, but it's really ugly: {{#sub:<cleanspace>...</cleanspace>|1}}.

I don't expect there to be many, but during Round 2 of my template editing, I'll look for any templates where it's highly desirable for the output to be truly "clean"—for example, templates whose output may be parsed by other templates—and make the changes accordingly, but I thought I'd post this here a) as a record of what I'm doing, since the code seems kinda stupid on the surface, and b) to see if anybody has a better way of cleaning cleanspace. I tried <noinclude> tags around it, but as I expected, that just caused cleanspace not to get parsed at all on calling pages. We need some kind of <includeandignore> tag here (though if we could do that, cleanspace itself could be made to function that way and then we wouldn't need it). :) ‒ Robin Hood↝talk 18:44, 5 August 2010 (UTC)

User HouseEdit

Would anybody be opposed to me prodding {{User Hlaalu}}, {{User Redoran}}, and {{User Telvanni}} (edit: and {{User Dagoth}}), replacing on users' pages with the appropriate {{User Rank}} userbox instead? My concern is the minor differences in wording and functionality: the wording would change from "user is a part of" to "user is in" (otherwise, the boxes are visually identical), and the user would also automatically be categorized into the appropriate house Category, providing we don't decide to remove them, where they would not have been previously. Normally, I'd just prod and wait to see if it was reverted, but in this case, there's a bit of extra effort involved, so I don't want to "be bold" this time around. – Robin Hood↝talk 23:43, 8 August 2010 (UTC); edit: 20:06, 10 August 2010 (UTC)

• Sounds like a good idea. --Michaeldsuarez ^{(Talk) (Deeds)} 23:50, 8 August 2010 (UTC)

Please. The sooner the better. rpeh •T•C•E• 00:07, 9 August 2010 (UTC)

Okay, I'll get started on this. – Robin Hood↝talk 19:26, 10 August 2010 (UTC)

Message TemplateEdit

While I'm thinking of it, I recently tweaked the {{Message}} template (which is just a wrapper for the {{Notice}} template) to provide site-wide standard colours. These can later be moved into the appropriate CSS file, but I figured for now, it gives a simple way to provide standardized colours that can readily be changed by anybody who feels they're not quite right. It's not a big priority, but eventually, I'll try to move all of our various site messages to use it so that if we ever decide to change the standard, we'll know that it's automatically done site-wide. – Robin Hood↝talk 22:56, 25 August 2010 (UTC)

Quest Header TemplateEdit

TAO recently changed the {{Quest Header}} template to move from "at" to "in", which sounds a lot better when you're referring to a city instead of a specific location. Unfortunately, that doesn't work out so well for quests like Breaking the Siege of Kvatch, where the meaning is changed. The three ways I can think of to address the problem all seem a little bit kludgy:

1. Add an "inat" parameter (or some other name that we all agree on) that defaults to whichever one makes sense in the most cases.
2. Add a "StartAt" parameter which would work along with the Start parameter so you could optionally specify either or both: "Giver (at StartAt) (in Start)".
3. Leave only the one parameter, but go back over all instances of them and add "at" or "in" to the Start parameter, appropriately.

In any case, unless someone's got a bright idea for how to decide which is which, that'd probably have to be done one-by-one, or perhaps by-hand offline, then let a bot do all the changes at once. Anybody else have any better ideas? – Robin Hood↝talk 15:00, 20 October 2010 (UTC)

Well I've created a temporary workaround - while we decide what to do you can replace {{Quest Header}} with {{User:TheAlbinoOrc/Template2}}. While it should probably be moved from userspace I'm reluctant to create a page that'll probably end up getting deleted just to do a temp fix. Also on a related note we could just adopt using two templates as our solution but it is a fairly clunky way to do it.--Ghurhak gro-Demril _{or TAO}^Yes? 15:22, 20 October 2010 (UTC)

No, please. Using a user template in live space is not a good idea.

RH's option 3 strikes me as the best option. There are several places where "at" didn't really work and "in" won't work either. Adding a parameter to specify one word seems like massive overkill as does introducing a new parameter. RoBoT could do this change almost immediately, but maybe this is a nice simple intro task for HnB?

Lastly, please let this be a lesson on the right and wrong ways to change a widely-used template. rpeh •T•C•E• 16:39, 20 October 2010 (UTC)

Yeah I knew that - I just wanted to say that there was an alternate version that could be moved if we needed to.--Ghurhak gro-Demril _{or TAO}^Yes? 18:57, 20 October 2010 (UTC)

I was thinking this might not be too difficult to do as a task for HnB. I've been avoiding any major programming lately because of CFS brain-fog issues, which always seem to be at their worst in late-summer and fall. But given that it's really just taking existing code and modifying it to alter one specific parameter, which is a very simple, logical next step in the design, I don't imagine it'll be that big of a challenge (he says now). – Robin Hood↝talk 19:11, 20 October 2010 (UTC)

Never mind any bot programming required, there are 906 Quest Headers that use a non-blank Start parameter. I can see a few shortcuts, but still, this may take a while. – Robin Hood↝talk 11:17, 21 October 2010 (UTC)

Okay, the code is written, and I'm letting it do a test run on what I've done so far, just to make sure there are no serious flaws in the logic. I'm also about 1/3 of the way done the list of changes it should make to the Start parameter. Would people prefer I publish the list of changes in a sandbox first? The sandbox list would look like this ...

Page Name	Old Text	New Text
Tes3Mod:Tamriel Rebuilt/Which Witch?	?	?
Morrowind:The Necromancer of Vas	[[{{NAMESPACE}}:Ald'ruhn|Ald'ruhn]]	in [[{{NAMESPACE}}:Ald'ruhn|Ald'ruhn]]
Oblivion:Anvil Recommendation	[[{{NAMESPACE}}:Anvil|Anvil]]	in [[{{NAMESPACE}}:Anvil|Anvil]]

... then people could make bulk changes to the list before the bot goes on its merry way. Otherwise, I can just let the bot run with the text I thought seemed right and we can change anything we don't like on a case-by-case basis afterwards. I'm being consistent for identical entries, and trying to make inconsistent entries consistent, but it's not always obvious what the best wording should be and I'm going through them pretty quickly, so I make no promises. – Robin Hood↝talk 19:55, 21 October 2010 (UTC)

(←) Okay, the (huge!) list of changes is posted in my sandbox. Please feel free to make any changes to the New Text column that you feel are necessary (I've already spotted one inconsistency while copying it). Unless there are unexpected objections to the plan, I'll probably convert it back to a text file and then run the bot early tomorrow morning when few people are on.

Okay, all done! There were 895 changed in the first batch where I expected 905 (was 906, but obviously wouldn't change User space). I tracked down why 10 were missing, which was 8 that we'd all somehow missed (despite my double-checking by sorting them) and 2 that didn't need changed. I reran the bot for just the 8 missed ones, so now we're done. I'll be making the changes to the Quest Header template shortly. Please let me know if there was anything critical that was missed or screwed up, but I think it's more likely to just be a question of poor wording choices and such, which can be changed as they're found. – Robin Hood↝talk 16:05, 23 October 2010 (UTC)

#listsavedEdit

This'll probably mostly be for rpeh, but just in case anybody else is curious, I'm posting it in a more general forum.

After rpeh and Brf talked about #listsaved at Template talk:NPC Data, and with Nephele's insistence that it worked fine, I decided to take another look at the whole #listsaved issue and figure out what was going on.

The main problem was that in Nephele's example, she was showing what could be done if we really wanted to, not what was currently doable. I've changed {{Place Summary}} and {{Place Link}}, as well as the MetaTemplate docs so that the example would actually work (although it would look a bit ugly as written). You can see an example in my sandbox, which is nearly identical to the current version of Ayleid Ruins. The only difference is that "The Old Way" gets sorted under "T" instead of "O". I'm not sure if that would be changeable or not, nor did I want to mess around too much. It would depend on when/how #listsaved sorts things.

Apart from that, there were a few documentation issues to fix, but the example for #listsaved now works correctly, and hopefully makes it a bit more clear how everything works. – Robin Hood↝talk 02:03, 14 December 2010 (UTC)

DragonFontEdit

There is a template for text in the DragonFont here. Currently it is used on only a two content pages (Skyrim:Bleak Falls Barrow (place) and Skyrim:Word Wall). More pages could benefit from text in the DragonFont, such as books that contain dragon text and the dragon shout pages. To make use of this font easier I propose:

• Change the font to the official font: File:SR-Dragon_script.zip. This because:

• It uses then the same letters for the characters as in the game. Useful for books as this one;
• The currently used font differs a little bit in layout;
• Contains all the characters.

• Make it a webfont (enough converters only to get the font in a web format), so people don't have to install the font before they can see it. An alternative is to change all characters to images.

I cannot do this myself, so I hope an admin agrees with me and performs this change.CoolGamer 16:40, 12 December 2011 (UTC)

The webfont is already in place, see User talk:Nephele#fonts for a few details. --Alfwyn 16:47, 12 December 2011 (UTC)

As Alfwyn said, all the admin-specific stuff has been done. One other change that needs to be made, however, in order to implement the revised fonts is to update the characters used for all of the two-character vowel combinations. The pre-release font used lower-case letters, whereas the official font uses numbers -- for example, "ahrk" was written as "BRK" in the pre-release font, but it's "4RK" in the official font. The need to make that switch is one reason why there's been an unofficial moratorium on more widespread use of the Dragonfont template. --Nephele^Talk 17:24, 12 December 2011 (UTC)

There are only 2 pages currently using the template with the old dragon font now. It isn't much work to update these pages.CoolGamer 17:32, 12 December 2011 (UTC)

Only one page (Skyrim:Bleak Falls Barrow (place)) still uses the old dragon font. I updated the text to be used with the new font on one of my pages: here. Is there anything else holding an update to the new font back? -CoolGamer 18:37, 14 December 2011 (UTC)

Trails and disambiguationEdit

The current {{Trail}} template doesn't work well together with disambiguated titles. There is a bit of discussion about it here. The problem with changing the existing template is, that it can be used in several ways:

• {{Trail|a|b}}
• {{Trail|a|[[b (c)|b]]}}
• {{Trail|a/b}}

Making a change to the template for disambiguated titles without breaking those uses will be non-trivial and it is used on too many pages to simply track down the cases that would break. Using the "nocat" parameter of the existing template becomes cumbersome fast, the trail part of one article became suddenly:
{{Trail|Quests|[[Skyrim:Thieves_Guild_(faction)|Thieves Guild]]|nocat=yes}}[[Category:Skyrim-Quests]][[Category:Skyrim-Quests-Thieves Guild (faction)]]

With Skyrim we have at least Skyrim:College of Winterhold (faction) and Skyrim:Thieves Guild (faction) where quests for those need special treatment. So my suggestion would be to simply use another template for those cases, a sandboxed version can be found at User:Alfwyn/Sandbox/Template:Trail2. This one gives the user the possibility to override the links and categories generated, if necessary. The line above would become:
{{Trail2|Quests|Thieves Guild|link2=Thieves Guild (faction)}}

This overrides the link for the second parameter. The current implementation defaults to generate categories of the form "Category:Skyrim-Quests-Thieves Guild" instead of "Category:Skyrim-Quests-Thieves Guild (faction)", which would be my preference for those categories. Further that implementation doesn't support file-system like trails like a/b/c.

Any suggestions/opinions on using that? --Alfwyn 18:16, 13 December 2011 (UTC)

Just spotted that we're using this page again, and saw Nephele's beautiful return of serve putting the ball in my court on this one :)

I haven't looked at this at all yet but I suspect a better solution will be to make the trail {{Trail|Quests|Thieves Guild (faction)}} and have the template use Neph's addons to strip the disambig part out.

I consider all of this to be more proof that Bethesda deliberately set out to cause trouble for us... rpeh •T•C•E• 00:34, 1 January 2012 (UTC)

Hm, it's already in use now at {{Trail2}}, but not in that widespread use that this couldn't be changed. We could probably change the #addtotrail part in Trail/Section to use something like [[{{#label:foo}}|foo]], but that would break the second usage in my list (don't know how often this is used however, since the doc says not to use it).

On the other hand, having the ability to override certain parts has the advantage, that we can set up trails like {{trail2|Quests|Daedric|link2=Daedric Quests}} without being forced to redirect Daedric to Daedric Quests (and be able to redirect it to Daedric weapons/armor instead).

--Alfwyn 01:07, 1 January 2012 (UTC)

In terms of disambig pages, I was thinking the inverse of what you were: [[foo|{{#label:foo}}]] (e.g., College of Winterhold), which wouldn't break any usage, I don't think, but wouldn't allow for usages like your Daedric Quests. Given that Trail2 is working pretty much as we'd want it, we could perhaps incorporate the #label into that and then just use that across the board. Is there anything that Trail2 doesn't handle? – Robin Hood↝talk 02:26, 1 January 2012 (UTC)

You are right, that's what I actually meant. It works as long as "foo" is a plain word and not a link. --Alfwyn 15:45, 1 January 2012 (UTC)

Good point, I wasn't thinking about what happens if it's already a link. My mistake. I think we can actually handle that case too, but that makes it more complicated, and with a template that's used on pretty much every content page on the wiki, I'd definitely rather avoid complicated. – Robin Hood↝talk 18:44, 1 January 2012 (UTC)

(←) O/D'ing because I fear we may be about to lose sight of what we're trying to do here. The history here is that we used to have about 50 trail templates - one for each section of the site (I don't think I'm exaggerating here). Nephele's additions to MediaWiki meant that these could almost all be changed to use one template. I created the /Section sub-template so that about half of the remaining cases could also be handled - we had a lot of Game|Something|A/B templates and wanted the page to be in both A and B categories. There aren't that many of these and I dare say that if there's a better solution it could be applied fairly easily.

I suppose now is the time to ask: Do we need the breadcrumb trails at all? Aren't we doing everything we need to do through categories? Is the continued use of trails causing more confusion than assistance? Personally, the only time I bother with a link at the top of the page is when I'm trying to get back to a parent page after viewing its child - I don't think I ever use the breadcrumb trail. Are we simply spending too much time on this? rpeh •T•C•E• 03:18, 1 January 2012 (UTC)

That's a very good point, rpeh. Like you, I never use them except to go to a parent page. If that's all anyone here is using them for, we may want to rethink the whole thing, though we may want to solicit opinions from the broader community before doing anything drastic like that. – Robin Hood↝talk 05:50, 1 January 2012 (UTC)

Personally, I use the breadcrumb trails all the time; I don't see how categories provide a replacement for the trails. --Nephele^Talk 06:32, 1 January 2012 (UTC)

I find that usually if I'm on, say, a Thieves Guild quest page I'm most likely to want to look at other Thieves Guild quests next, so the category system is ideal. If people find the trails helpful, though, I suppose we have to live with them. rpeh •T•C•E• 16:26, 1 January 2012 (UTC)

Strangely enough, I almost never use categories outside of template design and maintenance, but hey, given my affinity for templates, maybe that's not such a surprise. :)

I'm thinking it might be useful to run HotnBOThered to get a sense of which styles of parameters are in widespread use and see if we can narrow down the possible parameter styles that we're attempting to handle. Specifically, I'm thinking that if we use Trail2, we probably won't ever actually need to pass a link, so we could re-write those to use the Trail2 parameters. In a very quick check, even at reading one page per second, retrieving all uses was estimated to take 4 hours...and I'm not so sure we want to be burdening the wiki with one page per second for that long over and above the current load. If we want to get a sense of what we're dealing with, though, I can always run it at a page every two or three seconds and just leave my computer on overnight tonight. (I have some hardware maintenance planned for during the day today, so there's really no point in starting a run till I'm done that.) – Robin Hood↝talk 18:44, 1 January 2012 (UTC)

(←) HnB finished its run and came up with some interesting results. The {{Trail}} template appears directly (i.e., not counting Templates or other transclusions) on 3792 pages. We're currently using the link style of parameter only on Skyrim:Fortify Skill, presumably because any others have been converted to Trail2 already. Obviously, this one remaining instance would be easy to handle. For the "/" style trails, there are 385 pages using that style (I can provide a list if anyone wants), but if we want to stop handling that style, almost all of them could be converted to use the standard 3-parameter call instead of using the "/" format. Only seven Morrowind pages would require a fourth parameter in order to convert (Ennbjof's Nord Burial, Free Hides-His-Foot, Free the Slaves, Rabinna's Inner Beauty, The Drunken Bounty Hunter, The Runaway Slave, Tul's Escape). I don't know whether we want to try eliminating a category from those ones to bring it down to three, or build logic for four parameters into the template. Either way is easy enough, though. All the remaining pages use exclusively plain text, so would require no additional work. – Robin Hood↝talk 22:01, 2 January 2012 (UTC)

Clearable Flag for Skyrim PlacesEdit

In a recent edit, Elliot changed the "Clearable" flag in {{Place Summary/Skyrim}} to be hidden if the answer isn't "Yes". From the perspective of things like "Essential", that makes sense, because an essential character is the exception to the general rule, so it's notable. In the case of a location being clearable, though, from what I gather, a location being clearable or not is common either way, and players seem to think it's important (I don't have it yet, so I'm just going by what I've read while patrolling). Do we want to switch that back to always being displayed? – Robin Hood↝talk 23:51, 31 December 2011 (UTC)

It's important because not getting a "Cleared" flag on your map usually means you've missed something really important. The implication is that if you can't get a "Cleared" flag, it definitely needs mentioning. I agree with RH70 that this is a flag that should always be shown. It may be that we decide in the future that only "Yes" or "No" should be shown, but while we're working all this out it's easier to show everything and be damned. rpeh •T•C•E• 00:38, 1 January 2012 (UTC)

Following on that comment, would you say the same for the Dungeon flag? It seems to me that one's probably unimportant (perhaps for either a "Yes" or "No"), but at this point, we don't really know that. – Robin Hood↝talk 00:58, 1 January 2012 (UTC)

It's perhaps possible that they should work together: that for anything that is a dungeon, the clearable status always get shown. One of the issues going on here is that the same Place Summary template is being used for buildings in towns -- houses, stores, inns -- and having "Dungeon: No; Clearable: No" show up on those pages seems like a waste of space. I don't know offhand whether the "Dungeon" flag is a reliable way to differentiate between "friendly" buildings and lootable areas -- I don't even know what the game actually uses that flag for. --Nephele^Talk 01:36, 1 January 2012 (UTC)

Yes, the dungeon "flag" is a bit strange, many non-dungeons have it set (Lost Tongue Overlook, Mara's Eye Pond, ...) not sure if it is useful right now. For the clearable flag the desired behaviour would be perhaps to show Yes or No if set to that value, and nothing if not. --Alfwyn 01:44, 1 January 2012 (UTC)

Oops, yes - Nephele makes very good points. I was forgetting those times where the extra flags were showing up. rpeh •T•C•E• 01:52, 1 January 2012 (UTC)

To Neph's point on interaction between the two, notably there are pages like Arcwind Point or Anise's Cabin where one flag is set and the other is blank, so it's not a clear-cut interaction. I think Alfwyn's suggestion may be the best, or we could go for a case of if either is specified, show both, but if neither is, show nothing. – Robin Hood↝talk 02:08, 1 January 2012 (UTC)

(←) Having the summary list clearable as no has it's benefits, but like Nephele stated, using them for houses stores, palaces, etc. is an error that definitely needs to be addressed. Perhaps waiting until the CK comes out would be our best bet so we can figure out what they meant by dungeon. elliot (talk) 15:55, 1 January 2012 (UTC)

So, I went ahead and defined it for the places you would consider "clearable". I am pretty sure I got them all; however, I'm not sure it's the best way to do it. elliot (talk) 02:27, 8 January 2012 (UTC)

I want to point out that Klimmek's House does show up as cleared on the map. This might mean that more houses are 'clearable', and that we might want to reinstate the clearable parameter for houses. Klimmek's House is, however, the only exception I've found sofar. Wolok gro-Barok 18:10, 17 January 2012 (UTC)

I think we need to change clearable one more time. The current fix was a functional short-term fix, but it's reallly somewhat of a hack that's too difficult to maintain and has no flexibility. We need to instead have a simple parameter that is explicitly set to Yes or No, or else is left out on pages where we don't want anything displayed -- giving editors full control over what gets dsplayed.

Going through pages tonight I came across too many messed-up cases -- such as The Ratway Vaults and The Katariah where clearable needs to be displayed, but there's no way to do it (at least without changing the template and messing up other pages). Not to mention cases where editors try to set clearable=0 or clearable=no and do the exact opposite. I can get the bot to go through and change the parameter on all existing pages, at which point fixing the template will be trivial. Any thoughts? --Nephele^Talk 07:12, 18 March 2012 (UTC)

Agreed. It was a temporary fix until things were ironed out... but it kind of died after that. I think we need to come up with a list of what needs to be labeled as "not clearable". Perhaps another parameter can be created, but I think you would know more since you've seen the game data. elliot (talk) 07:23, 18 March 2012 (UTC)

Having seen the workarounds you tried to put in place, I'm all for something that'll simplify that! ;) – Robin Hood↝talk 07:26, 18 March 2012 (UTC)

For now, I'm just trying to get the bot to explicitly set clearable=Yes/No on all the pages where the clearable param is currently being shown. All of which is assuming that I know how to tell whether or not a place is clearable (and that a couple strange cases are just unreproducible glitches).

Beyond that, I think the Clearable line should be shown in the infobox on any places where people are likely to wonder whether or not it's clearable. Somewhat vague, but I think that's ultimately what matters. More specifically, I think any location that contains enemies probably needs to explicitly say whether or not it's clearable. We'll have a bit more freedom to make case-by-case judgement calls once the template updates are done. --Nephele^Talk 23:28, 18 March 2012 (UTC)

Quest Item DataEdit

Jak Atackka is experimenting with ways to handle the various quest item data. I'm a little rusty on what we might have in place, and I know all those familiar with it will be reading this page, so I'm cross-posting it here. It started as a discussion of Section Transclusion, but then morphed a bit as I clued into what he was trying to do. The original is at User_talk:Jak_Atackka#Section_Transclusion, though the CP post it started on might also be a relevant place to discuss this. Thanks! – Robin Hood↝talk 21:41, 10 January 2012 (UTC)

The discussion was moved to UESPWiki:Community_Portal/Quest_Item_Redirects. --Alfwyn 19:33, 15 January 2012 (UTC)

Skyrim and Faction TemplateEdit

With Skyrim there are a lot of faction names that cause a bit of trouble when it comes to linking to a page. Examples:

• Maul's faction, links to "Thieves Guild", a disambiguation page.
• Adrianne Avenicci's faction, links to "Whiterun", an article about a city
• Adrianne Avenicci's faction, links to "Warmaidens", a slight misspelling of Warmaiden's, creating a faction redirect here confuses people searching for the shop.

We could fix this by directly linking to the relevant Faction_x page (for Skyrim only), without going through a redirect. I sandboxed that approach here. It automatically produces links to titles like "Skyrim:Factions_W#Whiterun".

Another way would be to automatically link to pages of the form "Whiterun (faction)". We have already a few faction articles in that fashion, for the rest redirects could be created. Tried that here. --Alfwyn 19:32, 15 January 2012 (UTC)

Both ideas have merit. The "(faction)" page would be visually cleaner, but I think in the end, the Factions_x method is probably the best way to go (edited: see below). Rpeh's done more work on faction organization than I have, so I'm hoping he'll chime in here. In the meantime, of course, there's the long-hand method of using {{Faction|Factions_W#Whiterun|altname=Whiterun}} or {{Faction|Whiterun (faction)|altname=Whiterun}} if there's need. – Robin Hood↝talk 23:50, 15 January 2012 (UTC)

It occurred to me that the reason we're not just using the Factions_x style of linking is that we're loading rank data from the pages. Assuming we don't want to complicate the template further, we should probably continue with that model, in which case the "(faction)" style is the better way to go. If we want, we can pop an #ifexistx check in there before we load the data and if it doesn't exist, revert to trying the plain page name instead. – Robin Hood↝talk 01:43, 16 January 2012 (UTC)

Will there be any rank data to load for Skyrim? We don't have rank icons or ingame visible names for ranks, in other cases ranks seem to be dynamic. Some of the rank names don't look like we really want to display them on NPC pages (like "Freed - ready to follow player" for CWMission04PrisonerFreedFaction). So just documenting them on the faction pages might be enough. Directly linking to the Faction_x pages would have the advantage that it can be painlessly changed to another solution later on, since it doesn't require mass-creation of redirects. --Alfwyn 13:00, 16 January 2012 (UTC)

I looked around a bit, and we actually have sensible looking rank data stored at "Skyrim:Thieves' Guild" and "Skyrim:College of Winterhold". But I just tested it, the data will still be loaded with the first version, since there I'm not changing factionPage at all, just the generated link. --Alfwyn 19:05, 16 January 2012 (UTC)

At some point I will get RoBoT to fix the Faction template usage. At first glance something like getting the bot to check if a page exists and creating a (faction) redirect if it does (with exceptions for the Big ones) should work. The problem is time: I don't have enough of it. It's the problem with moving from boring jobs with free internet access to an interesting one that blocks UESP. :)

If someone else wants to take this on, I'd advise against complicating the template any more than it already is. It'll work as it is - it just needs care. Incidentally, the big factions all have ranks (the Companions is another one, for instance), but there aren't many others - if any. rpeh •T•C•E• 19:18, 16 January 2012 (UTC)

Thanks for the feedback. But simply changing the link for the template usage will not do, as the example Skyrim:Enthir shows, it confuses the category and the text displayed. That could of course be fixed by specifying the altname and catname parameters, but this will blow up the source of NPC pages considerably in some cases. The first variant of the change I'm proposing isn't really complicating the template much, it just adds another case into an already existing namespace switch. --Alfwyn 19:34, 16 January 2012 (UTC)

I would recommend just providing the altname and catname to bypass it. {{Faction|Fence (faction)|altname=Fence|catname=Fence}} works just fine. These can easily be adjusted as needed by using the categories. elliot (talk) 07:58, 20 January 2012 (UTC)

Sure, that is a reasonable fix for the individual case. I just don't think it is a good idea to systematically create those cases. I also don't see the value in creating a lot (about 1000) of redirects when we can link directly to the target - I don't think people will search the wiki for the faction names used in Skyrim often. It is probably not desirable to directly link to a regular article for the big factions too, as the distinction between "Thieves' Guild" and "Thieves Guild" will get lost.

Anyway, adjusting the template to link to "Faction_x#factioname" would work with most of the NPC pages as they are now and can be easily changed later on. The same is not true once a heap of redirects have been created. --Alfwyn 15:44, 20 January 2012 (UTC)

Well, I am against that for systematic reasons. The factions need to redirects because of categorization. Also, as I said, it is not good "for the individual case" because it can easily be done for all of them. I can do it. Simple. Easy. Plus, Nephele said she would create the redirects for the faction pages once I got all of the information on there. So, at the behest of two people who know factions and templates, I would recommend that we find the problematic cases and fix those. elliot (talk) 18:38, 20 January 2012 (UTC)

There was no plan to change the categories for NPC pages. The faction redirects for Oblivion don't have any interesting categories, so I don't see how we need the redirects for that. As for "at the behest of two people who know factions and templates", see Polling is not a substitute for discussion at wikipedia. I know that all those redirects can be created by a bot, I just haven't seen a good argument why they should be created so far. --Alfwyn 10:43, 23 January 2012 (UTC)

Having now looked at Alfwyn's proposed changes in more detail (inter-page diff), I think for the time being, altering the link is the way to go. As he says, it won't alter how we're handling anything else—the categories will stay the same, the page it wants to load rank data from will stay the same, etc.—it only affects what page we're linking to. As an interim solution until we can figure out how we're going to handle factions in the long run, I think this offers the best choice. And once we have (faction) pages created or whatever else we choose to do, it's as easy as just removing that line to revert to the previous behaviour. It may also have the advantage of encouraging those so inclined to actually document the factions, as right now, we're a little lacking. – Robin Hood↝talk 22:20, 23 January 2012 (UTC)

(←) The only comments I have related to this are basically an aside -- I don't think they're really related to the question of how to handle the Faction template on NPC pages. Nevertheless, since this discussion has apparently decided to throw out the wiki's entire redirect organizational structure, here goes.

Regardless of how the faction links are handled on the NPC pages, faction redirects are still needed. Countless numbers of pages on the site have been set up under the assumption that faction redirects would eventually be created. The only reason why those redirects had not been set up prior to today was because the target pages (pages such as SR:Factions C) did not exist. If there's one thing that's worse than a red link on a page, it's replacing that red link with a broken redirect. Otherwise, the bot has been ready and waiting to handle the task for a month now.

NPC infoboxes are far from the only place on the site where factions are linked. Links to factions exist on each faction category page (e.g., Category:Skyrim-Factions-BanditFaction). The factions are all cross-linked to each other, meaning at this moment there are countless red links on pages such as SR:Factions B). Factions are red-linked on pages such as SR:Warlock and SR:Dungeon Delving (Caves). Factions are far more important in Skyrim than in Oblivion -- controlling merchants, trainers, marriage, followers, quest-givers, etc. -- and therefore I'd expect as time goes on there will be even more reasons to mention factions on pages across the site, meaning even more reasons why links to factions will be created.

Besides links, redirects also exist to help readers find information. Today's burst of faction-related activity was triggered by an editor complaining about being unable to find faction-related information. Until redirects are set up, readers will continue to have problems finding the info. For example, searching for TownMorthalFaction right now is basically useless, so I can see why the category page ending up being edited. Even now that SR:Factions T exists, it's a dozen entries down on the search page.

Just because there are a handful of problematic cases where disambiguations may be needed doesn't mean that the entire system needs to be thrown out. Adding redirects for factions such as "TownMorthalFaction" is not going to mess up any other searches or promote typos in other links, and I don't know of any other efficient way to help readers find the page. Therefore, creating these redirects does not really seem comparable to questions such as whether to create redirects for plurals. --Nephele^Talk 01:11, 26 January 2012 (UTC)

I think only Alfwyn has suggested doing away with redirects entirely (except where required for disambiguation, of course). What I was proposing was only a temporary link to the Factions pages. I assumed that if faction redirects were created, that the interim coding would once again be removed. This is basically the same reasoning as you mentioned—link to a page that's likely to exist soon (and indeed, now they do thanks to you!) in favour of linking to a non-existent or broken redirect. If the bot is ready to create the appropriate pages, then that becomes a moot point and no changes to the template are required, at least not strictly for that reason.

Is there some merit, though, to creating all faction pages as "xxx (faction)"? Or do you foresee problems with that approach? – Robin Hood↝talk 03:02, 26 January 2012 (UTC)

I think adding "(faction)" to all faction redirects is more trouble than it's worth. There more than 1000 factions, and since the bot is set up to create redirects for both editor ID and name there will be about 1500 redirects. Maybe two dozen of those need to be disambiguated. Furthermore, a majority of the redirects already include "Faction" in the name (nearly all editor IDs include Faction, and maybe half of the names include Faction). "Wolf Faction (faction)" just seems unnecessarily redundant. --Nephele^Talk 04:04, 26 January 2012 (UTC)

I had a feeling that might be the case. Thanks for the feedback. :) – Robin Hood↝talk 04:31, 26 January 2012 (UTC)

Nephele made the right points in terms of why we need redirects. I still see no reason to change it, considering that the faction pages are essentially up (thanks again Nephele). elliot (talk) 05:23, 26 January 2012 (UTC)

(←) Creating the redirects would make finding faction information by name easier, that is a good point.

But I don't think many readers will search for faction names, they are not visible in the game. We often don't offer wiki-search support for other things just found in the game data too. The factions can be found, by going to Factions. In some sense factions have become more important with Skyrim, but they also got much more technical. For a player not looking at game data, they became less important. The player no longer has any (visible) ranks in the factions and can't even see which factions he joined.

Current redlinks: For Oblivion the faction links on faction_x pages (see Oblivion:Factions A) were done directly to the faction_x pages, the redlinks on the Skyrim faction pages were created semi-automated recently, and could probably changed without too much effort the same way (I'd do it if that is what we are wanting) . The redlinks on the category pages are created by {{Faction Category}}, which may need a bit of fine-tuning anyway (see Category:Skyrim-Factions-all friends in here). Linking to factions on regular articles will need addressing.

There are more than just a handful of problematic cases, where a faction name clashes with the name of an already existing page (Falmer, The Pale, Whiterun, Bounty Collector, Kyne's Peace, ...), searching for the faction name won't work in those cases anyway, directly linking will fail too. I don't want to change the wiki's general redirect structure, I just think that in this case cleanly separating faction names from article names somehow would be a good thing. --Alfwyn 13:04, 26 January 2012 (UTC)

I have been thinking quite a bit of this. I still think it more economical/desirable to change two templates, instead of creating 1500 redirects and fix up those uses where a name clash exists. But as it looks like everybody else is either indifferent or thinks those redirects are desirable, it will be better to create them instead of having those redlinks. I will just find me other things on the wiki to attend to. --Alfwyn 14:53, 27 January 2012 (UTC)

Pro's and con's aside - Neph, please continue what you were doing. We have tons of red links - and factions are incredibly useful when writing NPC pages and even if a few links will point to awkward places, the majority will point to the correct information. We can always discuss this later - right now, this must fall under the "let's get something on the pages"-category. I have never searched for a faction in my life, nor do I intend to - but it is silly to have everything done up until "C" and then just stop. Top priority, IMHO. --Krusty 21:35, 3 February 2012 (UTC)

Sorry about taking so long to get the bot restarted. I just haven't much UESP time lately. For now the bot has just restarted the original job -- which means all problematic faction names are just being skipped instead of doing any disambig-type names.

Which leads to another thought, getting back closer to the original discussion topic. Looking more closely at the factions, there are a few cases where the faction names are pretty useless, if not downright problematic (example: "Rank = which mission is in "slot" 1", edid CWFieldCOPotentialMission1Faction). There are other cases where multiple factions share the same name (example: "Can show up at battles in this hold", shared by multiple CWAllies<Hold>Faction edids). What I'm wondering about is whether we should switch to using the edid in any case where the faction name is problematic -- which could then include at least some of the disambig cases (in particular Warmaidens). The redirects at the standard name would still exist, but the faction lists on the NPC pages would use the edid, and the Factions_* pages would also use the edid as the primary name for listing/sorting. The NPC page changes can be done by bot (and the bot is probably going to have to take a pass at updating all the factions, any way). The Factions_* pages are also going to have be redone at some point to add in the member lists, so any reorg can be folded in at that point.

Not that I'm proposing making any such changes right now, but just a thought for what we could do as the next step of cleaning up the factions. --Nephele^Talk 19:44, 4 February 2012 (UTC)

I was thinking that switching to edids either as needed or all around was probably our best bet. I was wondering if maybe we wanted to change {{Faction}} to #load the faction name (altname) from the faction page, then display that if it's found. I believe that small change would allow a good deal of flexibility in terms of what we call the actual faction pages themselves. – Robin Hood↝talk 20:12, 4 February 2012 (UTC)

LetterPic templateEdit

This template isn't really relevant here but since it's been brought up, I would urge caution when using it. While it's probably true that any book using a fancy letter in Oblivion uses one in Skyrim, the reverse is certainly not true. I'd thought about using a template like this myself but didn't do it because of this reason, and because the obvious workarounds (like using something similar to trimlinks on {{Place Link}}) seem like too much hard work. I'd welcome other thoughts though. rpeh •T•C•E• 07:23, 16 January 2012 (UTC)

I'm off to bed, so I haven't played around with it at all, but I'm thinking of something like {{LetterPic|A|Oblivion=1|Skyrim=1}} as the call. Then you get template logic something along the lines of

{{#if:{{{ {{NAMESPACE}}| }}}
  |[[File:{{{1}}}.png]] (or switch logic like what's there now, or whatever)
  |{{{1}}}
}}

Not sure if that'll actually work, but it's worth a try. – Robin Hood↝talk 08:06, 16 January 2012 (UTC)

Yeah, I thought about adding some features like that to it. Also there are definitely some places where it should not be used, for example the Lore:Mythic Dawn Commentaries. In this case, the letters spell out a message on the margin which would be lost if the fancy letters weren't used, so they should be there even in Lore space. I also wasn't sure if we ever wanted to use Oblivion-style letters in Skyrim book pages or anything like that. Not having access to Skyrim to see these books, I don't know. But there are definitely places where this could be used, so I think it's useful to have it. I'm open to suggestions on what features it needs to be more useful in all cases. --TheRealLurlock ^Talk 13:34, 16 January 2012 (UTC)

That's one of the other workarounds that seemed like too much work :) The other problem is that almost every template use will need updating with every new game. rpeh •T•C•E• 19:04, 16 January 2012 (UTC)

What if we have Oblivion and Skyrim (and future games) default to 1, with Morrowind and anything else defaulting to 0. Then we only have to worry about the exceptions. – Robin Hood↝talk 22:12, 16 January 2012 (UTC)

Yeah, I'd assume default values, so as to avoid a need to change them later. Mind you, even if they did have to change with every game, it's hardly a big deal, since they only come out like every 4 years. And it's a change that could easily be done via bot on those rare occasions when it's needed. As for games other than Oblivion and Skyrim, no values are needed for those, since Oblivion was the first game which had fancy letters. So those would be the only ones you'd need flags for. Set them both to 1 by default and it would cover the vast majority of cases, and those uses would most likely not need to be changed in the future. --TheRealLurlock ^Talk 04:11, 17 January 2012 (UTC)

That's even more clunky. Different defaults and starting out with nearly as many exceptions as there are non-exceptions isn't nice. New games come out more often than that too, by our definition - Tribunal, Bloodmoon, Shivering - presumably we'll have another SR-related namespace before too long. rpeh •T•C•E• 05:49, 17 January 2012 (UTC)

(←) Not necessarily. I assume that the same book in the same game will always have the same style, regardless of whether it's in the original game or an add-on, so we can use {{NS_PARENT}}, meaning that we only need to worry about changes for each new game, not each new namespace. I think we can handle making changes once every 5 years or so. – Robin Hood↝talk 06:11, 17 January 2012 (UTC)

That's quite an assumption... rpeh •T•C•E• 06:43, 17 January 2012 (UTC)

Are there any books you're aware of where the add-on creates a whole new version of the book with or without fancy letters? I can't imagine Bethesda wasting their time on that, but even if that happens, the solution below will resolve that. – Robin Hood↝talk 08:06, 17 January 2012 (UTC)

We're getting off into technicalities here, so I've moved the discussion. I think I've thought of a workable, non-clunky way of doing this. As part of LetterPic, simply #inherit a UseFancy variable. Then when you trasnclude it into the relevant namespace, you can either pass UseFancy in the transclusion, or #define it on the page. I'll have to play with it tomorrow, but that seems like it should work, and it would require no updating or special efforts whatsoever whenever new games/add-ons come out. What's more, if it were necessary to use fancy letters in a base game, but not in an add-on version (or vice versa), that would be doable. – Robin Hood↝talk 06:47, 17 January 2012 (UTC)

That's what I meant with my initial "trimlinks" comment... rpeh •T•C•E• 19:02, 17 January 2012 (UTC)

There's no trimlinks involved here at all. As an example, I've mocked up the first paragraph of Brief History of the Empire, v 1:

• User:RobinHood70/He = Template:LetterPic
• User:RobinHood70/Vav = Lore:Brief History of the Empire v 1
• User:RobinHood70/Zain = Oblivion:Brief History of the Empire, v 1 (the ns_base is added in order to pretend like that's what it is, but wouldn't be necessary in the real thing)

In Lore space, all you have to do is use {{LetterPic|B}} as the first letter (as opposed to the kludgy #if statement that's in use in the real Lore space already!!!). In Morrowind space, there are no changes required. In Oblivion and Skyrim space, you just add a |usefancy=1 to the {{Lore:Brief History of the Empire v 1}}. I don't see how we can get it any simpler than that. It's then up to editors to add the parameter to those books that use fancy initial letters, which I would see as a fairly trivial edit if they're already adding LetterPic to the Lore articles anyway. And whenever ES6 comes out, there are no changes required to existing pages, you just need to use the |usefancy=1 on any new books that use the fancy letters. And again, if we want, we can probably provide different defaults in different spaces, but under this setup, I'd recommend not doing that, just to keep it straight-forward. – Robin Hood↝talk 20:48, 17 January 2012 (UTC)

I know that. That's why my original comment said "like using something similar to trimlinks on {{Place Link}}". That should have been clear enough. rpeh •T•C•E• 21:43, 17 January 2012 (UTC)

Sorry, but I'm still not understanding what you mean by using trimlinks with Place Link. Oh and what I didn't mention above, but I assume you also clued into, is that for those books like the Mythic Dawn Commentaries, where all known instances of the book use fancy letters, you can just #define:usefancy=1 on the Lore page itself and you're off to the races with no need to change any other pages.

The way I look at it, we have three choices: we can implement something ourselves to deal with the fancy letters; we can let users add whatever kludges they come up with leaving things ridiculously inconsistent; or we can revert every last fancy-letter change ever made from now until eternity. Personally, I think the first choice is the best option. – Robin Hood↝talk 22:00, 17 January 2012 (UTC)

I said like trimlinks. Like the way we use it on Place Link!!! In other words, inheriting it from the page where the template is used. Exactly what you just suggested. rpeh •T•C•E• 22:05, 17 January 2012 (UTC)

(←) While the words "similar to" and "like" were clear enough, the fact that you meant an inherited variable of some kind was not at all clear from your initial statement or subsequent statements until this one, primarily because without editing the Place Link template to find out that you meant something different (which was certainly not the first thing that came to mind), I assumed you were talking about #trimlinks, not a trimlinks parameter. Since #trimlinks could also conceivably make sense in this context (i.e., stripping a letter link down to just the letter), that to me was the natural assumption about what you were talking about. You never once mentioned inheritance or anything else to give it any other context. – Robin Hood↝talk 22:13, 17 January 2012 (UTC)

If I had meant #trimlinks, I'd have said #trimlinks. It was perfectly clear what I meant in the context of controlling the appearance of pages. At this point I can only assume you're being deliberately obtuse. Next time I'll just write the bloody template. rpeh •T•C•E• 22:20, 17 January 2012 (UTC)

(←) Back to the original topic: We will still have tons of custom ifeq/switches for adjusting links or slight text changes, but the template looks good to me and conversion should be painless on a per case basis. --Alfwyn 22:23, 17 January 2012 (UTC)

(edit conflict) Returning to the point at hand, I think the inheritance idea is about the best idea we've got, so unless you have objections, I'll make the appropriate modifications to LetterPic and we can start using it in the actual books as we come across them, getting rid of the kludges that have already been added to books like Brief History of the Empire. – Robin Hood↝talk 22:27, 17 January 2012 (UTC)

(edit conflict) We need to sort out how the template will work before using it because it'll affect how it will be used: will the namespace exclusions be on the Lore pages where the template is used or on the namespace pages which will be affected by it? Once we sort that out we can start using it. rpeh •T•C•E• 22:29, 17 January 2012 (UTC)

I think the inheritance idea is the most flexible option, as well as being the simplest to use in the end. In cases where we're defining usefancy right on the Lore page so that it's a universal change for all books, I would suggest we make it abundantly clear for new users by also adding an HTML comment, something like:

{{#define:usefancy|1}}<!-- remove this line if fancy lettering is only used in certain namespaces -->

Does that sound reasonable? – Robin Hood↝talk 22:35, 17 January 2012 (UTC)

One thing that occurred to me as well is that if we go back to the old suggestion of leaving all the decision-making on the Lore page itself, the LetterPic template could just inherit variables of each namespace name, meaning that you could #define what to do with each namespace at the top of the Lore page, then each LetterPic call after that once again reduces to {{LetterPic|A}}. It'd make for a heck of a lot of inherited variables, and we'd have to update the template for each add-on, but it would have the advantage that you'd only be changing a single page, and only in one location for the entire page, rather than every last call. Honestly, at this point, I think I'm agnostic...there are advantages and disadvantages to both methods, so whatever other people decide is what I'll code. :) – Robin Hood↝talk 23:27, 17 January 2012 (UTC)

I think it would be better to keep things separate. There aren't that many fancy letters on any page, so I wouldn't worry about making too many calls to LetterPic. rpeh •T•C•E• 06:04, 18 January 2012 (UTC)

I just put a modified version of the template in place which I think gives us the best general solution. That said, Alfwyn just pointed out a slight tweak in IRC that I think would make it that much better, but I don't have the time to play with it right now. I'll let him explain. :) – Robin Hood↝talk 22:00, 19 January 2012 (UTC)

The basic idea was, that we probably want in almost all cases no fancy letter in Lore and MW, and the appropriate one in OB and SR. So this case should be the easiest to use, with no additional defines or parameters specified anywhere. We would disable that automatism at the Lore page, if we want to use fancy letters only in some name spaces with a define. A slight modification of RH's version that does this can be found at User:Alfwyn/Sandbox/Template:LetterPic . --Alfwyn 22:58, 19 January 2012 (UTC)

Skyrim Merchant WealthEdit

One of the features of the NPC Summary template has some complications for Skyrim merchants. The "Gold" section which indicates how much money merchants have to barter with is designed to automatically add merchants to categories based on wealth. It does this by comparing the number to a set of values in the Wealth template. Problem is that if this value is not just a number (which is the case on most of them, due to the listing of Investor and Master Trader perks), no category is added. Now these notes are apparently optional (I guess that not all merchants can be invested in, and some don't receive extra money for Master Trader?) so on pages where they have no such notes, categories are then added. It might be worth modifying the Wealth template to support Skyrim better - making it possible to add one or both notes optionally, and modifying the values as far as what counts as "wealthy" etc. in Skyrim. A few other concerns are that the Thieves Guild fences seem to have a variable value (related to some quest or something, I assume?), and one particular merchant, Lucan Valerius, has a feature/glitch whereby investing gives much more than the usual amount, so exceptions would need to be made for these. As far as the values go, there's fortunately much less variation in Skyrim than in previous games. I've done a count and I think the categories can be broken down as:

• Destitute: 50 gold (10 members)
• Poor: 100 gold (32 members)
• Well Off: 400-500 gold (41 members)
• Rich: 750 gold (22 members)
• Wealthy: 1000 gold (16 members)
• Fences: 1000-4000 gold (7 members)

Lucan Valerius is the exception to all of this, because while he qualifies only as "Rich" (750), he can be made into the wealthiest merchant in the game by far once invested in. There are also no "Broke" merchants as there were in previous games. Finally, a Skyrim:Commerce page should probably be created at some point, as the "Gold" header in the template links to it. Any modification to this template would probably require changes to every one of the Skyrim merchant pages to support them, so I'd say it's a job for a bot. (Hopefully it should be possible to modify the template in such a way that it does not require updates to the Morrowind and Oblivion merchant pages as well.) --TheRealLurlock ^Talk 03:04, 23 January 2012 (UTC)

So, what I whipped up in User:Elliot/Sandbox/6 is currently working (check the NPC Summary variant at User:Elliot/Sandbox/14). I spot checked a bunch of different pages in multiple namespaces and nothing seemed to break (and the NPCs were added to the correct category as well). The way that Nephele ran her bot made all of the entries uniform, so, if we alter it this way, there shouldn't be a problem. elliot (talk) 05:42, 23 January 2012 (UTC)

I've made a few changes to the version in your sandbox - a slight difference in how you're splitting the original string, and a few changes to the error handling (huh tag). One problem I see right off-hand, though, is that not all fences have 1000-4000 for their gold (see Enthir and Niranye). – Robin Hood↝talk 00:23, 24 January 2012 (UTC)

Sweet, thanks for cleaning that up; it was definitely a little messy. I haven't familiarized myself with the string functions yet, so your fixes are a definite improvement. Now, regarding the two NPCs, I think they should be added as a fence separately, mainly because they are normal merchants as well. elliot (talk) 02:31, 24 January 2012 (UTC)

TBH, I've never been a fan of these rather arbitrary categories, and especially not of a system that places "Wealthy" above "Rich". Do we really need this on Skyrim too? rpeh •T•C•E• 06:54, 24 January 2012 (UTC)

In tables, I find the colour-coding can be helpful to make it that much easier to pick out wealthy merchants at a glance, but in the NPC Summaries, it really serves no purpose as far as I'm concerned, so I'm game to remove it there, at least for Skyrim. As I recall, Oblivion didn't really make any in-game distinctions either, so maybe there too. I don't really know Morrowind that well, but I think it served more of a purpose in that, didn't it?

If we do keep the colouring in the NPC Summary for Skyrim, though, we should probably separate the Investor and Master Trader perks as parameters to NPC Summary. Then we can get rid of the string parsing in the updated version of Wealth altogether. – Robin Hood↝talk 07:55, 24 January 2012 (UTC)

Actually, if anything, the distinctions are much more clear-cut in Skyrim than in previous games. The values I listed, 50, 100, 400, 500, 750, and 1000, are the only values out there - there's no in-between numbers like in previous games, so the division is far less arbitrary. (The only concession I made was to group 400 with 500 because there's only 3 of them.) The names could maybe be changed, but I couldn't think of any other good words that divide wealth into clearly defined zones like that. To me, "wealthy" does seem richer than just "rich", even if they are synonyms. I just figured "fabulously stinking wealthy" was just too long, and words like "affluent" or "opulent" too likely to confuse some of our readers. Maybe "loaded"? But that's kind of slangy, and may not get the point across. --TheRealLurlock ^Talk 14:01, 24 January 2012 (UTC)

(←) While it might be true that the categories are more relevant to Skyrim than earlier games, that's an argument for removing the template from those games rather than adding them to Skyrim. I'm normally a fan of categories but here the arbitrary divides make them largely pointless. Even in Skyrim, the way in which available funds for fences increase during your rise through the guild means that a necessary but irritating trip to the fence becomes a standard "go-to" trip to get rid of your unwanted goods. Having one single page in which merchants can be sorted by available funds seems far more useful to me, and given that it will include other essential information such as where they are to be found and any requirements to use their services, it's far more flexible than categories.

My vote is to remove the Wealth template from the NPC Summary entirely and kill the associated categories. rpeh •T•C•E• 18:49, 24 January 2012 (UTC)

I agree with rpeh. The Wealth template has no place within the NPC Summary for Skyrim, for the reasons stated above. This was significant within Morrowind (or so I've heard) but in Skyrim it's completely irrelevant. I also agree that a central page that lists the merchant's relative wealth is necessary. Skyrim:Merchants already exists, but that page needs to be consolidated into a single table or at least fewer tables. ?• JA^Talk 07:16, 25 January 2012 (UTC)

Reminding myself how this all worked in the various games, I'm seeing that this is entirely made up by us for all the games and it doesn't have any in-game meaning in any of them. Given that, I'm going to fully support the idea of scrapping the categories and the colourization on the NPC Summary. We can use {{NAMESPACE}}:Merchants for that sort of information instead. I'd also like to suggest that we add colour-coding to at least the Oblivion version of that, so that players can easily pick out the merchants who have high amounts of gold available. Perhaps we could simply re-purpose the Wealth template if it's not used anywhere besides the NPC Summary (I haven't checked), since templating it would ensure that the changes are all done correctly each time, and any future changes to what amounts get what colours are one-stop changes.

If we're all in agreement, I'll make that change, along with adding parameters for Investor and Master Trader (with temporary coding to check if gold has comments in Skyrim space...just until we can switch over to the new parameters). – Robin Hood↝talk 04:56, 26 January 2012 (UTC)

I just had an idea in the shower. Why not make the colour relate to the amount of money? Make the richest merchant's wealth appear in blue and the poorest in red, then scale the colours according to the values in between. We might need to hard-code max/min values for namespaces (or they could possibly be #loaded from somewhere) but that shouldn't be a problem. This would mean no more arbitrary colours and should let people see at a glance which merchants are richer than others. Thoughts? rpeh •T•C•E• 07:41, 26 January 2012 (UTC)

I didn't have much time to describe this idea this morning, so let me expand my earlier post a little.

The basic idea is that there would be a smooth transition from red to blue (or whatever colours we choose) as wealth increases. The poorest merchant in a game - possibly excluding oddities with zero gold - would be shown using one colour, the richest would be shown using the other, while a merchant in between would be shown in a mix of the two colours. The "rich" colour would be calculated as 255 * (ThisMerchant - Poorest)/(Richest-Poorest) and the "poor" colour would be that value subtracted from 255, although we might want to add another scaling factor if the colours we get aren't too different.

I'm not wedded to this idea: it just seemed like a good way to make the colours mean something instead of using random values.

I've added "gold" to the list of values being #saved on the NPC Summary template because it'll probably turn out useful whatever we do. rpeh •T•C•E• 18:46, 26 January 2012 (UTC)

I like the idea, though from previous experience doing this sort of thing manually, a linear formula might not produce enough colour contrast. I was using straight fade-to-white, though...cross-fading seems to produce somewhat better results. As an example, here are Oblivion's merchants in Cheydinhal using a red-blue cross-fade, given a potential range of values from 50 (most innkeepers) to 2000 (Aurelinwae et al):

Merchant Name Gold Borba gra-Uzgash 1000 Dervera Romalen 50 Eilonwy 800 M'raaj-Dar 400 Mach-Na 1200 Magra gro-Naybek 600 Mariana Ancharia 50 Tertia Viducia 1000 Dummy Entry 2000

Merchant Name Gold Borba gra-Uzgash 1000 Dervera Romalen 50 Eilonwy 800 M'raaj-Dar 400 Mach-Na 1200 Magra gro-Naybek 600 Mariana Ancharia 50 Tertia Viducia 1000 Dummy Entry 2000

What do people think? – Robin Hood↝talk 01:20, 27 January 2012 (UTC)

Hmm, while I am not a huge fan of the color coding system, RH, I think that {{#local:max|2000}} should be {{#local:max|1000}}. Everything else above 1000 should just be blue. I don't think it would be a good idea to stretch it out that far because most are only good until 1000 (at least in Skyrim). Having said that, I wouldn't be disappointed if the template was scratched all together. elliot (talk) 03:41, 27 January 2012 (UTC)

(←) The current template pretty much already does that. (The color spectrum is different, but the idea is the same - purple for broke, blue for destitute, all the way up to red for wealthy. The gradient is based on hue rather than a straight linear translation.) For Skyrim at least, and to a lesser extent for Oblivion, this is all we need, as there is fairly little variation in the amount of gold held by merchants in those games. Morrowind had more variation, but I don't see much need to make the color gradient more precise than it is. I concede that the categories may be somewhat arbitrary, and are possibly not needed. But the template could otherwise be used as is as far as the colors are concerned. --TheRealLurlock ^Talk 04:45, 27 January 2012 (UTC)

I didn't change the limits cuz I don't wanna play too much before getting other feedback, but it occurred to me that a red-green shift might produce nicer results in that it would generate something like a traffic light system. Not sure I'm thrilled with the results, but I've added that as a second table above. (And please don't look at the code I used to do that...it's seriously ugly! <g>) – Robin Hood↝talk 04:44, 27 January 2012 (UTC)

That looks pretty good, except that values towards the poor end are a bit similar (in both columns) - it may need tweaking a little to avoid that. Otherwise I still rather like the idea. rpeh •T•C•E• 05:51, 27 January 2012 (UTC)

Okay, the wealth colouring and categories have now been removed from the NPC Summary template. I think we were all in agreement that at the very least, the categories could go, so now we just need to come to agreement on colours. I don't see a need for colours in the NPC Summary template, but they can always be added back in if the discussion goes that way. The template can still be very useful on the various Merchants pages, though.

I've also added new parameters for Investments and Master Trader. The existing parameters will work fine, but converting to the new ones will ensure a standardized message. There are exactly 100 to be converted, which I would see us just converting over time, as the opportunity presents itself. If we want, we can always put a bot on it, but I don't think it's a priority given that what's there now will work fine. – Robin Hood↝talk 01:35, 29 January 2012 (UTC)

Calendar templateEdit

Just so all our templaters know, I just created a {{Calendar}} template, which creates calendars like the following:

Sun's Dusk
S	M	T	M	T	F	L
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

At the moment, it's a very generic template, with no game-specific logic or anything like that in it. I've replaced all the calendars on Lore:Calendar with the new template. If that's the only page on the wiki that uses calendars of any kind, we can change it a bit to be more specific to that page, but for now, I haven't done that under the assumption that we may have calendars elsewhere that I don't know about. – Robin Hood↝talk 05:08, 23 January 2012 (UTC)

Nice job on the template! My only qualm is with Midyear, 4E 201. How would it look if you changed the wide horizontal bars to just empty cells? ?• JA^Talk 05:52, 25 January 2012 (UTC)

Yeah, I was thinking of doing that or completely blanking the lines in the empty areas. Chrome seems to screw up on the blanking, though, at least the way I tried it, so showing empty cells is probably the best bet. A variation of that that I thought of is to do it like some calendars do where the lines are more greyed out for that area. That should be a simple change to just showing plain empty cells. I'll play with some time in the next couple of days and see what I can come up with. – Robin Hood↝talk 06:51, 25 January 2012 (UTC)

One option is to take the blank cells and set the background to transparent and the borders to 0, but I don't know how that would look. ?• JA^Talk 07:25, 25 January 2012 (UTC)

Unfortunately, blanking or fading the borders turned out to be more complex than I'd hoped, so I went for just displaying the remaining cells as normal ones. I've mostly got it working now, but for anybody who's been following my changes, you may have noticed that months that end at the end of the week are ignoring the addrow feature. I understand the problem, but I'm damned if I can find an easy solution. In the meantime, I think the Calendar page looks acceptable, even if not quite as desired, so I'll take it back to my sandbox until I can come up with something workable. – Robin Hood↝talk 01:39, 30 January 2012 (UTC)

I fixed the alignment problem by force-aligning all calendars to the tops of their cells. They're still missing a blank row, but at least this way they line up with the other calendars. (Technically I probably could have just added the alignment to those two which were off, but this is more complete and consistent.) --TheRealLurlock ^Talk 01:56, 30 January 2012 (UTC)

Thanks, TRL, hadn't thought of that...I was too preoccupied with the template issue. :) As it turned out, the problem wasn't what I thought it was, it was just a misplaced }}. Once I found that, everything was fine. The Calendar page looks as it should now. – Robin Hood↝talk 02:14, 30 January 2012 (UTC)

{{Morrowind Town Table}} vs. {{Morrowind Town Table Test}}Edit

Both of the above infobox tempates are being used on the wiki, however I'm pretty sure we only need one. {{Morrowind Town Table Test}} Is slightly different because it includes a bar on the top. Compare Morrowind:Balmora and Morrowind:Ald'ruhn. I think the code for MTTT should be used under Morrowind Town Table and all of the pages using the MTTT template should instead use MTT. I don't know if the two templates are there on purpose, or if that is a relic of somebody's testing. If it's just a relic, then I'll go ahead and change over the pages, but I need the go-ahead from you guys. ?• JA^Talk 23:38, 6 February 2012 (UTC)

I've just had a look, and the only other change I see besides adding the banner is that it doesn't display "(view map)" on Tribunal pages, which almost irrelevant since the original template is only used once on a Tribunal page (Mournhold) and the test one isn't used on any Tribunal pages. The only issue I see with the updated one is that it's not always used at the top of the page (Mournhold again, for example), which makes the banner look more than a little odd. I think we can resolve that, but I'd have to play around a bit and remember my CSS lore. I'm also not sure if the banner is necessarily appropriate on all pages that MTT is used on, but I'll let you check on that if you feel like it. That's easy enough to handle, though - we can put the banner inside a #if statement if we need to. – Robin Hood↝talk 02:41, 7 February 2012 (UTC)

All done. I went ahead and left the header-less pages header-less, since none of them seemed to need one. I marked MTTT for speedy deletion. ?• JA^Talk 06:02, 8 February 2012 (UTC)

Oh, good! I knew there was something I was supposed to follow up on today, but I got distracted. Thanks! – Robin Hood↝talk 06:45, 8 February 2012 (UTC)

Sure thing! Also, I went ahead and (somewhat) fixed up {{User EditsPerDay}}. Because displaying it as a decimal is inherently impossible on the wiki, it displays a generic "x edits in y days". Not quite as nice as I was hoping for, but it's good enough for now. ?• JA^Talk 06:55, 8 February 2012 (UTC)

That works. And then if you ever do figure a way around the problem, it can be changed readily. – Robin Hood↝talk 07:05, 8 February 2012 (UTC)

Skyrim BoxEdit

Hey, can anybody with IE9 (Internet Explorer 9) please check if these boxes are displaying correctly? Anybody reading Elliot's talk page knows that this has been a hellish battle. However, I think I finally got it right. Can you tell me if any of these tables don't look quite right?

This is a single line of text

This is the first line of text, and this is the second line

This one has a fixed width

Thanks for the help! ?• JA^Talk 02:07, 19 February 2012 (UTC)

Confirmed here too! :P – Robin Hood↝talk 02:21, 19 February 2012 (UTC)

Note TemplatesEdit

So, I went ahead and made {{intnote}} and {{note}}. They're slight alterations of Wikipedia's complicated note system (I made sure these were very simple). However, my reasoning for doing so is because the * and † type of references/notes doesn't really cut it. We expect better functionality within a top wiki, and I am sure our readers do too. It makes it a little more complicated, but it's nothing editors can't handle. The basic format is {{intnote|refidnote|note a}} and {{note|refidnote|a}}. You can see them in use here and here as opposed to what we had here and here. elliot (talk) 08:43, 27 February 2012 (UTC)

Excellent job! I'll start implementing these immediately. ?• JA^Talk 08:55, 27 February 2012 (UTC)

I just experimented with using them, and ending up tweaking the templates a bit. I prefer using symbols such as † for notes -- I think the problem with our existing notes isn't the choice of symbols, but the fact that they're not hyperlinked. The way the templates were originally written seemed to basically assume that you wanted to use letters instead of symbols for the notes. I took out some of those assumptions -- so now whatever is provided for the "visual display of the link" is what actually gets used. If you want brackets around the text, you should supply the brackets as part of the text; if you want a ^ before the note, you should supply that, too. --Nephele^Talk 21:04, 29 February 2012 (UTC)

Oh, that's fine. I was debating with the format of them and just figured letters were intuitive. But they look good now; I've no problems. elliot (talk) 05:12, 1 March 2012 (UTC)

Bug TemplateEdit

As designed, the {{Bug}} template has a vn paramter that's an opt-in parameter which categorizes the bug into the "Unconfirmed Bugs" category instead of the "Outstanding Bugs" category in the relevant namespace. In other words, you have to specify that verification is needed. Does anybody see any problems with deprecating this parameter in favour of a confirmed parameter (and perhaps a shorter alternate, like conf)? I think in most cases, we want the bug reports to default to unconfirmed, not to have to add a parameter which, in essence, confirms that it's unconfirmed. The one drawback is that any cases where the vn=1 was deliberately removed before will now default to unconfirmed and have to be re-edited by those who can confirm it. Thoughts? – Robin Hood↝talk 04:08, 13 March 2012 (UTC)

Good idea. ?• JA^Talk 04:40, 13 March 2012 (UTC)

(edit conflict) I'd be in favor of this - but you would have to fix those vn=1 tags first before I'd approve of any such change. Seems like something a bot could take care of, since you'd have to look at almost 1000 pages by my quick estimate (and potentially multiple uses per page in some cases). I'd say if you can make sure that the bot can make those changes reliably, then go for it. --TheRealLurlock ^Talk 04:45, 13 March 2012 (UTC)

The vn=1 would be ignored in favour of the confirmation, but yes, I had figured I'd probably have the bot remove the parameters globally, just to avoid the clutter of leaving unused parameters around. – Robin Hood↝talk 05:48, 13 March 2012 (UTC)

Hmm, it just occurs to me that wouldn't do what I thought. The real trick would be (and I don't even know if this is possible) to have the bot check the history to see if the tag ever had a "vn=1" param that was removed, and if so auto-confirm it. Some of these bugs are very difficult to test, and it seems like it'd be a shame to have to go back and re-confirm everything that has already been confirmed. As I said, almost 1000 (or maybe more counting multiples on a page) bugs would be a real pain to check by hand, especially if they've already been checked. --TheRealLurlock ^Talk 05:54, 13 March 2012 (UTC)

Why not just have the bot replace "vn=1" with "conf"? ?• JA^Talk 06:04, 13 March 2012 (UTC)

(←) Lurlock: yes, that would be the problem. Checking for that kind of edit in the page history would be nightmarish in terms of coding and stupidly resource-intensive on our servers, so it's not really feasible to do that.

Jak (or both, really): Conf would work opposite vn. Since people sometimes remove the vn=1 deliberately, but in many cases just don't know to add it in the first place, we have no way of knowing for certain whether it's been forgotten, deliberately removed, or deliberately not added in the first place due to multiple reports already on the talk page. This is why a confirmation parameter makes more sense to me, since you specifically have to add it rather than possibly just having forgotten to add the vn parameter. In essence, I think at the moment, the vn parameter has ended up being unreliable to the point of being useless. It's not fool-proof - if people see a confirmed tag in one, they might start adding it everywhere and generate the same problem in reverse, but hopefully Patrollers can keep on top of that much more easily, since most people won't know to add it (plus "confirmed" is probably more intuitively understood, where I think some people are adding vn=1 just because they don't know what it means). – Robin Hood↝talk 06:35, 13 March 2012 (UTC)

Duh, whoops. We could go with an incredibly complicated solution, or we could just say to hell with it and just be stuck with adding "conf" to each of the bugs. Another option is to look at the bug, and if any specific key word pops up such as "confirmed" or even "exists on system" then the bot would add "conf". ?• JA^Talk 07:01, 13 March 2012 (UTC)

That would be doable, though we'd have to think about what words would be good. Some people add "confirmed on <platform>" right in their first post, but really they're just reporting something that happened once. Another option is for me to generate a list of all those that don't have vn=1 on them before I start the bot stripping away the existing ones. I'm not sure that helps much over just removing the vn=1, though...either way, you essentially have to confirm the bug. – Robin Hood↝talk 07:33, 13 March 2012 (UTC)

Any further thoughts on this? My current thinking is Jak's "to hell with it" solution where we switch to conf and remove all the vn's, also asking the patrollers to make sure to check that conf parameters don't get added unless it's reported by multiple people on the talk page or the tag is added by a second person.

The other option is that we do away with confirmed/unconfirmed altogether, though I'm not sure if that's desirable. – Robin Hood↝talk 05:16, 16 March 2012 (UTC)

Okay, for now, I've just added the confirmed parameter. That leaves us with a three-tiered system at the moment, but perhaps that's not such a bad thing. The confirmed bugs will give Kivan/Arthmoor an idea of what should take priority for the USP, then maybe after they've released a version or two of that, we can remove all the vn parameters in favour of confirmed. Does that sound reasonable? – Robin Hood↝talk 07:27, 21 March 2012 (UTC)

Effects SummaryEdit

Neither enchsyntax nor alchsyntax show up on a page using {{Effects Summary}}, but syntax does appear. For example, Telekinesis Effect defines syntax and it appears. Paralyze defines alchsyntax and enchsyntax. Neither appear, but a handwritten description does. Huntsman's Prowess defines enchsyntax, but no description. As a result, the page does not describe the effect at all.

The source for {{Effects Summary}} suggests that these descriptions should be rendered via the #if statements near the end. They look similar to me. Is there a simple fix? --Pure 19:29, 27 April 2012 (UTC)

Fixed. It was a minor capitalization issue, but everything works now. • JA^Talk 19:56, 27 April 2012 (UTC)

Selective Inclusion TemplatesEdit

I'd like to create a template (or rather a pair of templates) that allow for selective inclusion based on a variable name. For example, say I have the page Underwater:Basketweaving, and I put on that page a bit that goes: {{include|Foo|Everything you ever wanted to know about Fooing a basket}} and elsewhere another bit that goes: {{include|Bar|Here are all the Bars where you can weave baskets}}, the page might look like:

Everything you ever wanted to know about Fooing a basket

...other stuff...

Here are all the Bars where you can weave baskets

But then on page Underwater:Foo, I could include the command {{includefrom|Underwater:Basketweaving|Foo}}, and it would place "Everything you ever wanted to know about Fooing a basket" on that page, and on Underwater:Bar, I could do {{includefrom|Underwater:Basketweaving|Bar}}, and I'd get "Here are all the Bars where you can weave baskets". I'm pretty sure this can be done by using #save commands in the "include" template and #load commands in "includefrom", but it's a bunch of moving parts, and I wonder if it's even worth the effort, or if there's already a better way of doing this. TheRealLurlock (talk) 14:29, 16 December 2012 (GMT)

Sounds useful. The name include could perhaps changed to something like export, since it doesn't really include something. We have the LabeledSectionTransclusion extension installed [1], which seems to do something like this. Do we use that anywhere, or is it currently unused? Because there is significant overlap with the #save/#load functionality there. --Alfwyn (talk) 15:43, 16 December 2012 (GMT)

Yeah, I chose the name "include" to be analogous to the <includeonly></includeonly> and <noinclude></noinclude> features we already have, which perform a similar task but are much more limited. I notice there was a previously deleted template by that name which had a completely different purpose. export and import could work too. The LabeledSectionTransclusion looks interesting, but it's kind of ugly to code, so I don't expect it'd get much use. Perhaps if its functionality were wrapped in a nice friendly template it might be better. One advantage it may have over #save/#load is it might avoid the problem where when the page with #save gets edited, it doesn't show up right away, and temporarily breaks pages where #load is used until the server caching or whatever is done, or you purge the page. Not sure if LabeledSectionTransclusion has the same problem though. TheRealLurlock (talk) 16:46, 16 December 2012 (GMT)

A nice thing about encapsulating that in a template would be, that we can change what it is based on at a later time without much problems. --Alfwyn (talk) 16:52, 16 December 2012 (GMT)

LabeledSectionTransclusion is something I've long wanted us to make better use of. I've used the simpler section transclusion feature in a few places, but not much. I don't think we're using the actual labeled transclusions anywhere. Unfortunately, it doesn't appear to work in templates. Unfortunately, I played around unsuccessfully for some time before noticing that it says that right on the LST doc page. – Robin Hood↝talk 20:43, 16 December 2012 (GMT)

Category SortingEdit

Before the server upgrade half a year before, an Uesp custom extension in the server code took care, that pages starting wit "A", "An" or "The" sorted correctly in categories. This code isn't called anymore since the upgrade. Subsequently on many pages DEFAULTSORT directives were added. This didn't help in all cases, because any categories defined in <cleanspace> tags recognize DEFAULTSORT only, if it is done before tag, and most templates define categories inside <cleanspace> tags.

Strategies to fix the category sorting I see are:

1. Add DEFAULTSORT to all pages needing it, change templates to define categories outside cleanspace tags.
   • Alternatively to changing templates, fix server code.
2. Add DEFAULTSORT to all pages needing it, before calling any templates.
3. Change templates to automatically take care of the common cases (A, An, The), add DEFAULTSORT to the remaining pages.
4. Fix server code to do the category sorting automatically for the common cases.

My personal take on the options is, I don't like option (1) at all, the resulting templates are harder to read and random spacing issues may crop up. Having looked quite a bit at the code, I don't think this issue will be easy to fix server side. I see up and downsides to the remaining three approaches.

Option (2) is pretty straightforward, but editing intensive. I tested option (3) on dev [1], it works like seen here (The Rat In The Pot). A couple of templates would need changing though. The fix for option (4) is much easier as far as I can see. But it has the downside that it may break with another update again, and there are only very few people that can fix it (as opposed to changes to templates or individual pages). So it may be good not to do much unnecessary customization server side, but that's to a large extend a strategy decision.

Thoughts? --Alfwyn (talk) 18:58, 16 January 2013 (GMT)

The only reason to use Option (1) is because a few of us have already gone through and added {{DEFAULTSORT}} to hundreds of pages, and it'd be easier at this point to modify the templates slightly than to go back and make hundreds more edits. • JA^T 19:04, 16 January 2013 (GMT)

I am perfectly willing to do all of the editing required for Option (2). Just say the word and I'll do it. There honestly isn't THAT many things left. Some Daggerfall quests, and some Oblivion locations. I think everything else has had DEFAULTSORT added to the top of the page. Jeancey (talk) 20:11, 16 January 2013 (GMT)

I'll look at this a little deeper later on, but my initial reaction is that both options 1 and 2 are less than ideal because it's too easy to accidentally break pattern and not notice. Of course, the flip side to that is that they allow us to break pattern easily if we actually want to. Option 3 might be a good choice, though if more than one template needs to be changed, I consider that a drawback, even if probably a necessary one. Which ones would need changing, anyway? I'm guessing Trail...what else? Finally, I like Option 4 because even if very few people can change the server code, it puts a small amount of code in a single place where it can be updated as needed. The drawback, as you point out, is that we need to adapt to any future MW re-writes, but those tend to be infrequent, so at least for me, I don't consider that to be a significant enough drawback to rule out that approach. Having a few site-specific customizations that add a lot of power to the site as a whole has always been one of our strengths in my mind, even if the potential for breakage also creates a point of weakness. – Robin Hood  ^(talk) 20:47, 16 January 2013 (GMT)

Option 3 would probably need changing the book template too, many cases of "the" there. I don't think that doing the change in the trail template is a good idea, used by too much, and it is not guaranteed that it is included before any category definitions. I guess I'll at least try to implement option 4 on dev. On the customizations, yes a few site-specific customizations that add a lot of power is a good thing. A lot of customizations that add little things and break unnoticed not so much. My particular concern with that tweak is, that it is obscure and it can be easily enough replaced by more obvious stuff. It did break, and nobody noticed it. Of course that breaking didn't hurt much, but then why bothering tweaking it? --Alfwyn (talk) 11:52, 17 January 2013 (GMT)

You know, for the templates that are affected, we can always add a |defaultsort= parameter, that within the template defines {{DEFAULTSORT}} before it defines the category or calls other templates, such as {{Trail}}. This has the added benefit that the variable will always be within the template, and not simply floating around in a random place on the page. Templates that would be affected by this change include {{Place Summary}}, {{Quest Header}}, and {{Book Summary}}. We can then go back and fix the affected pages. • JA^T 15:13, 17 January 2013 (GMT)

Project param for wipsandboxEdit

I see that there is a hard-coded link to the Morrowind Redesign project within the {{wipsandbox}} template at present. It would be great if we could recycle this template for other such projects, and I was wondering if we could add a project parameter to it without too much hassle, instead of the existing check against the namespace? – Daric↝talk 10:38, 11 February 2013 (GMT)

Great idea! I've made the change. Templaters: for now, I've kept it simple. Do we want to change it to a #load value from the project page instead? – Robin Hood  ^(talk) 03:43, 12 February 2013 (GMT)

Text parsing helpEdit

I'd like to create a template or templates similar to {{Autolink}} that will parse a two-word name and use only the first or last part of it. E.g., if given the code {{Firstname|John Smith}}, it'll produce a link that looks like [[John Smith|John]]. A similar one would be created for Lastname. Basically, it should use the entire text as the link, but use everything before (or after in the case of Lastname) the first space character as what's displayed for the link. (Also, like Autolink, if an already-formatted link is provided it should do nothing.) Is this even possible? I could swear I've seen cases where we do simple parsing tasks like this elsewhere, but I can't find any. In case anyone is wondering, it's for the proposal I made on Lore:Names. I've already implemented it for Altmer Names, but some of the other races are going to be much harder without something like the template I just described. I'd also be creating new versions of {{LinkList}} to use these new templates, but that seems easier to do. Though it's possible that doing the parsing there instead of in the link itself might work better. Any help? — TheRealLurlock (talk) 14:43, 21 February 2013 (GMT)

Something like [[{{{1}}}|{{#explode:{{{1}}}| |0}}]] will do that, but it doesn't take care of the namespace prefix. --Alfwyn (talk) 15:08, 21 February 2013 (GMT)

The namespace part is easy. Autolink already does that, I'll just be modifying it to make the new templates. #explode, eh? That should probably be documented on either UESPWiki:MetaTemplate or Help:Magic Words (or both). Are there any other fancy-schmancy features like that which aren't listed on these pages? Or is there somewhere else where they are listed? — TheRealLurlock (talk) 19:49, 21 February 2013 (GMT)

Works perfectly: {{NameList}} and {{SurnameList}}. Only problem might be names with more than 2 words - I'd like to have all but the first word be used in SurnameList, rather than just the second word, as that seems to be the most common scenario. Possible with this function? — TheRealLurlock (talk) 19:58, 21 February 2013 (GMT)

Explode is part of the StringFunctions extension, the docu is linked from Special:Version (docu). The only thing I can come up with for selecting all but the first word is slightly more complicated: {{#explode:{{{1}}}|{{#explode:{{{1}}}}} |1}} - that is select the first word (space and first being the defaults), then use that (plus space) as delimiter for the outer explode. --Alfwyn (talk) 20:39, 21 February 2013 (GMT)

Actually, I found a sneaky and much easier solution. If you use a _ instead of a space, it won't break the word there, and the link works either way. Nifty. Unfortunately, that doesn't let you group multiple words in the display text (or it does, but the _ is visible.) Using a & nbsp; or formatting the link in long-hand solves this issue. (Incidentally, does anyone know of a way to type & nbsp; and actually have those 6 characters display on the page and not just a space? No combination of nowiki tags seems to allow for this. I added a space after the & to get around it, but it's not ideal.) — TheRealLurlock (talk) 22:59, 21 February 2013 (GMT)

Oh, I like the _ solution. And &amp;nbsp; displays as &nbsp; .--Alfwyn (talk) 10:39, 22 February 2013 (GMT)

Userspace in a boxEdit

	Title Text
	Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla interdum bibendum erat non euismod. Phasellus dapibus rhoncus nisi, sed pulvinar turpis venenatis vitae. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Ut pretium, nisi ac egestas malesuada, ante tellus gravida mauris, et aliquet eros tortor sed augue. Ut dictum tempus massa viverra euismod. Suspendisse eleifend vestibulum bibendum. Suspendisse erat leo, pretium vel lobortis sit amet, tincidunt et tortor.

Now that several other people have started using, in their own userspace page (see, for example ^[1][2][3][4]), the box that I copied from Rpeh, I was wondering if it would be a good idea to create a copy of it in the Template namespace? There are already at least those four copies of it that I know of in userspace, plus the one by Rpeh. Perhaps to prevent more copies being made of the code, there should be a single copy available in the Template namespace. I'm happy to make a Template-space copy of it myself, and to document it, if it is deemed necessary. – Daric↝talk 02:04, 27 February 2013 (GMT)

It's not necessary; if it's easy to use and possible to make it a template, feel free. Userspace templates are for fun, and since it's in use, it won't hurt. There's fewer people using some of the userboxes we've made. Vely^►t►e 02:12, 27 February 2013 (GMT)

Autolink QuestionEdit

Okay, so I'm trying to make a template to do these more easily. See {{FamilyList}}. It depends on {{Autolink}} to catch any exceptions to the pattern, such as NPCs in other namespaces. However, Autolink doesn't seem to like it if there's 2 variables in the link name. See what happens:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13

Everything works fine, except for the extraneous "_Andrano" tacked onto the ends of the Tribunal and Bloodmoon links. What am I missing here? Is there some way to force Autolink to treat two variables as one word? — TheRealLurlock (talk) 15:55, 27 February 2013 (GMT)

In a word: blech! Autolink is doing what it's supposed to. It's just that in this case, what gets passed to Autolink is: "[[Tribunal:Galsa Andrano|8]]_Andrano", which it dutifully displays. The only way around it that I can see is to completely re-write the template, essentially duplicating the Autolink functionality with a few customizations within the /Entry template (or perhaps a second sub-template). Anyone else see a better way? – Robin Hood  ^(talk) 04:11, 28 February 2013 (GMT)

Hmm - yeah, I see it now. The trick is it has to add the surname ONLY if the param isn't a link. I think it might be possible to rig something up with a #if and #pos and not add the surname if it finds a '[' in the param. Might try something like that in the morning unless you come up with something better before that. I mean, it's already done now, the hard way. But that whole section of the page is pretty hard to read if you look at the page source. A nice convenient list-template like {{NameList}} and {{SurnameList}} that I made before would make things much cleaner.

I also couldn't find a way to make FamilyList use the recursive method that the others use. It would have to store some sort of int counter variable and increment it for each link. Not sure how easy that is in wiki-template code. Possibly not worth the effort. I instead duplicated the code to be able to handle the current worst-case scenario, making the first 2 names required to simplify things (If you had only 1, you'd simply link it, so template note needed). I think the way I arranged the #if's, it'll early-out at the first param it doesn't find, so it's not processing all 15 entries every time if there's only 3 of them. — TheRealLurlock (talk) 04:49, 28 February 2013 (GMT)

It works! Give my creation... LIFE!!! — TheRealLurlock (talk) 14:00, 28 February 2013 (GMT)

Similar to what I'd been thinking of, good work. With the additional check in the /Entry template, do we still need the {{Autolink}}? Or can that just be switched to a straight link, now? – Robin Hood  ^(talk) 20:46, 28 February 2013 (GMT)

I guess it could be a straight link. One limitation of mine is that it only looks for '[', not '{'. So those Hovers that Jeancey put on some of them had to be left out of the FamilyList template. (Fortunately, I designed it such that you could immediately follow it with additional entries and have it appear seamless.) One other annoyance I ran into - I was planning to #define:ns_base separately for each section so that it doesn't have to be redeclared with every use of the template. Unfortunately, it doesn't seem possible to #define a variable more than once on the same page, so the Oblivion and Skyrim sections still have to declare ns_base every time. Obviously, it makes the most sense to have that default to Morrowind, since there's an order of magnitude more of them than the two more recent games combined. Still, it'd be nice to save a little redundancy by being able to redefine the variable for each section. Only way I can think of doing it would be having every section on its own sub-page and then transcluding them all, but that seems needlessly complex... — TheRealLurlock (talk) 21:21, 28 February 2013 (GMT)

Try #local instead. Not sure if that works, but it's worth a try. #define only works if the variable isn't already defined, so the first #define defines it, rendering the rest meaningless. – Robin Hood  ^(talk) 21:26, 28 February 2013 (GMT)

Indeed it does! My mind is still thinking in C, where you can always re-#define a variable when needed. Or even #undef it if you don't want it anymore, though I'm not sure if that one exists in wiki. #local solves the problem though. — TheRealLurlock (talk) 21:59, 28 February 2013 (GMT)

(←) Yup, Nephele gave us an #unset command as well. :) As I recall, there are a few issues with undefining unnamed parameters, but apart from that, it works well. – Robin Hood  ^(talk) 22:07, 28 February 2013 (GMT)

Yeah, though it's still twice as much code as #local, so that's clearly the best one to use in this case. I've now changed all the Names pages over to use FamilyList (where applicable). The only other one that might benefit from it is the Orc Names, but then I'd have to make a similar alteration as I made to {{SurnameList}} to handle the "gra-"/"gro-" prefix, and it's just not worth it. Incidentally, is there any risk that this computation-heavy template-trickery might cause slow-downs on these pages or the server in general? I did these to make the code on the pages easier to read and edit (and smaller to load), but I hope it won't cause any kind of problems with performance. Not that I expect these are very high-traffic pages of course, so it probably doesn't matter much. — TheRealLurlock (talk) 22:31, 28 February 2013 (GMT)

It's always hard to judge these sorts of things. The two main things I look at are the numbers in the "NewPP limit report" (seen by viewing the page source), and just plain refreshing/purging and seeing how long those take. The numbers do look a bit high, but they're on part with some of our other pages, like the Ingredients List pages. – Robin Hood  ^(talk) 22:45, 28 February 2013 (GMT)

(←) Okay, new problem. I added the ability to start at a number other than 1, using the #expr: to add a starting value to the number. You can see it in use with House Dagoth on the Dunmer Names page. It works and all, but the only problem is it now inserts a space after the number, thus before the comma. Is this a bug with the #expr: function itself? Is there any way to make that not happen? — TheRealLurlock (talk) 16:53, 4 March 2013 (GMT)

Ah, good catch RH. So it wasn't my change that broke it after all (for once), it was Jeancey adding the category to the sub-template, which must have happened while I was in the middle of editing that section (it did take a while). Not sure if removing the <cleanspace> tags made any difference, but I guess they're not really needed there. — TheRealLurlock (talk) 01:42, 5 March 2013 (GMT)

That was actually what I was supposed to post. I got sidetracked and forgot to actually post. :) – Robin Hood  ^(talk) 02:08, 5 March 2013 (GMT)

New Parser FunctionEdit

Hey templatey types! Just thought I'd let you know I've added a new parser function to MetaTemplate, #explodeargs, which works very similar to #splitargs. In light of recent changes, I suspect the reason for it will be fairly obvious:

{{#explodeargs:00123456, xx123456, xx789abc|,|ID|1|separator=', '}} → 00123456, xx123456, xx789abc.

That's obviously an incomplete implementation, but you get the idea. I'll probably build a second multi-ID template so we can use this version on things like NPC Summaries, where dealing with multiple RefIDs and BaseIDs—especially with the header being formatted differently from the body—is a real nuisance any other way. This way, we can pass refid=00123456 or refid=00123456, xx123456, xx789abc and the single parameter can then be passed around, inherited, dealt with differently in different templates/sub-templates, etc. It's possible that all our existing {{IDs}} calls will end up moving to use this instead, but for now, we'll have both and we can figure out where we're going with them both over the next little while. For now, though, I've been at this way too long, and I'm off to play Skyrim for an hour before bed. Template building can wait till tomorrow. :) – Robin Hood  ^(talk) 08:44, 24 December 2013 (GMT)

Multi-Column Layout of ReferencesEdit

This is a followup of stuff discussed on UESPWiki_talk:Lore#Explanatory_notes. But since it got a bit technical and some references are used outside of Lore too, I continue here. The idea is to have the list of references found at the bottom of articles lay out in multiple columns, like it is done on Wikipedia. References are usually a long list of short entries, so multiple columns make sense.

Currently a scheme is in test on the dev server (example, may need a force reload) that by default changes the layout of references to multiple columns based on browser-width. This is done by css in Mediaiki:Common.css .

Now the default may not be optimal in all cases. Template:References is a simplified version of Wikipedia:Template:Reflist (the original code made too many assumptions about other templates and specific style in place) to change the layout. I think in most cases this will be to change it just back to traditional one-column layout. On Wikipedia it is used to more or less randomly setting the column width to either 25em or 30em, I think we should avoid over-tweaking.

Anyway, not sure about the name. I used "References" because it's the name of the tag it replaces, but using WP's name would have its advantages too, the usage is in large parts compatible.

A small issue with multiple column layout is text beginning in one column and continuing in the next. There is some style in place to prevent it, but it may be ignored - the situation will get better as browsers support the standard more. Testing showed it works with Chrome and really new versions of Firefox.

The scheme in test makes the use of the template optional. Another possibility would be to replace all <reference/> tags in use by a template, but personally I don't see a need for that. --Alfwyn (talk) 12:35, 6 February 2014 (GMT)

As long as it's readily override-able when we need to, I'm not picky on which method we use. As for naming, I'd support Reflist, just to keep it the same as Wikipedia since, as you say, the functionality is basically the same, so I think the naming should follow suit. We agree about not replacing all <reference> tags. The more flexible the solution, the better, which includes using <reference> tags on their own. – Robin Hood  ^(talk) 21:41, 6 February 2014 (GMT)

Implemented it as {{Reflist}} now and changed MediaWiki:Common.css accordingly. --Alfwyn (talk) 14:01, 15 February 2014 (GMT)

Online AchievementsEdit

Currently for Skyrim all achievement data is duplicated. It is once listed on Skyrim:Achievements and once as #saved data on the redirect for the achievement. I think storing data on redirects should be avoided - it's a really obfuscated way to store data.

Anyway, the data is stored, so that different pages for which the achievement is relevant can display the data about it. So another method would be to store all data on the achievement page. I tried that on dev at Online:Achievements and load the data at Sandbox. The two relevant templates are ONAdef to define and display the data on the Achievement page and ONAuse to display the data on a relevant page.

Apart from the general scheme, there are two things: What should the name of the templates be? And for some reason things stop to work for "Alik'r Desert Skyshards" and I have no idea why. Other names are ok, but not this one (and it's not the apostrophe (alone) causing the problems). --Alfwyn (talk) 20:21, 3 March 2014 (GMT)

It's because #save and #load don't work with values greater than 20 characters. I'm pretty sure it #saves the truncated variable, requiring you to #load it with the same truncation, but I may be mistaken. Typically I manually truncate the #save and #load values to 20 characters to prevent any compatibility issues. • JA^T 20:48, 3 March 2014 (GMT)

Thanks. Then hoping the first 20 characters will be unique it is, I guess. --Alfwyn (talk) 20:56, 3 March 2014 (GMT)

(←) This scheme (defining data on Achievement page, load from there) won't really work, if we are going to split the Achievement page. And with already 608 of them to start with, this is likely to happen. An alternative would be, to define the data at the redirect targets (#load checks the redirect as well as the target) if we don't want just to try to load the values from all the split pages. --Alfwyn (talk) 15:25, 4 March 2014 (GMT)

We've been having a discussion on irc about this, but I think that displaying or formatting the achievements like we did in skyrim is silly and counter-productive. Each achievement should be displayed on the page where you get that achievement. Most of the achievements have several specific criteria, which wasn't the case in skyrim. Displaying the achievements as we did in skyrim would cause a significant loss of information on the pages in question, forcing a user to go through a link in order to discover what the criteria of the actual achievement is, which is completely and utterly baffling to me as why we would do that.

The criteria themselves are part of the game data, as is the description. I do not see a good reason why we wouldn't display game data for achievements. I just don't understand it. Alfwyn and Silencer have been trying to explain to me the reason why we should send people through a link in order for them to learn the criteria of the achievement from the page they were on, but all I really understood was that they disliked tables, and thus they didn't want to display the achievement info since that would require a table. I may have misunderstood, but that was how I understood the argument. Could someone try and explain why we shouldn't display the criteria on the pages in question? I have created two possible layouts for achievements that I think would make sense, which can be seen here. Feel free to comment on that, or respond to the points I have laid out above, or both. I'm not trying to be antagonistic, I'm just super confused. Jeancey (talk) 18:24, 5 March 2014 (GMT)

The difference in opinion as I see it, is not so much what data to display, but how to display it. I think, if it can be done as text, it should be text, and not a box layout as default. Those tend to look cluttered if there are several of them on a page.

My starting assumption on how to do things is just to do it like it was done in Skyrim. If not, it will need explanation why not. ESO seems to categorize achievements, we hadn't that in Skyrim. Do we have an example how the ESO criteria for achievements are presented in-game? Looking at ESOhead, several of them seem to be trivial (often just repeating the description), others tend to be longish lists. --Alfwyn (talk) 19:27, 5 March 2014 (GMT)