UESPWiki:Community Portal/Archive 11

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

Table Formats

As part of the never-ending efforts to create a more uniform site appearance, I'd like to propose some changes to the CSS classes used to control format layouts. We currently have two different classes that are widely used on the site, wikitable and greylapse. (Technically, there are two more classes: prettytable is identical to wikitable, and graylapse is identical to greylapse). Although there are slight differences between the classes, the names of the classes don't reflect what the differences really are, and more often than not one is chosen over the other based on individual editor's habits rather than based on actual differences between the table layouts.

What I think would be useful would be to first establish what really is preferred for a "standard" table layout on the site, and establish a single class to be used for that layout (perhaps wikitable, mainly just because that name is frequently used in the wikipedia documentation). Then figure out what alternative types of table layouts are frequently needed and set up CSS code for those layouts, with layout names that make the layout's purpose a bit more obvious.

For those who can read CSS, the current definition of the tables can all be found at Mediawiki:Common.css. Or else some examples that all of us will find more intelligible:

Wikitable

HeaderA	HeaderB
First	Second
Third	Fourth Two Lines, one really long

* This table shows the header colour for the original wikitable format that was in effect when this discussion was started. The actual header colour has since been changed to match that used for the greylapse tables.

Greylapse

HeaderA	HeaderB
First	Second
Third	Fourth Two Lines, one really long

The most apparent differences are:

The background color of the header boxes is different
Padding around the cells is somewhat larger in wikitable, as are the external margins around the table
Greylapse by default has valign=top set in every row
The headers are centered for wikitable, left-aligned for greylapse

For those wondering about the name, "grey" in greylapse I believe refers to the fact that the table borders are grey (a feature common to both table layouts), and "lapse" refers to the fact that borders collapse (again, common to both layouts). So I don't think the "greylapse" name is particularly helpful in identifying what is useful or different about the layout.

I think it would be good to make an overall decision about what should be standard for some of the basic parameters. Two such parameters that differ between these two layouts are the background color for header boxes and the amount of padding to use in tables. I'd consider those to be parameters that should be fairly standard no matter how the table is being used, and therefore should be applied to all tables defined in the CSS files. Personally, I think I prefer the header background colour from greylapse but the extra padding from wikitable, although I really don't have a strong opinion either way.

Other parameters, such as valign=top and alignment of headers probably depend more upon the purpose of the table. In those cases, it seems like it would make sense to decide which alignments are desirable in the generic case. And then figure out whether there are certain combinations that are frequently needed in other tables, and therefore should have CSS names. Here I'd vote for the wikitable layout as the standard. But I haven't looked into what other types of layouts we probably need (or are already using in various ways).

Any feedback? Anyone who's willing to dig up examples of tables that need special treatment (ones that rely on one or the other of these layouts right now; or, ones that are using ugly amounts of manual overrides that could be achieved more elegantly using CSS; or, ones that look ugly right now and need to be reworked)? --Nephele^Talk 01:38, 14 November 2007 (EST)

Personally, I would like to have the wikitable layout with greylapse color as standard. It's just a matter of personal taste, and I may prefer other formats on specific situations. One format that I think is quite common is to have all the table content centered. Also quite common is to center the whole table in the page. Another common style is to have the first column left-alinged and the rest centered. In any case, I think we should just create a few base formats from which other more complicated ones can be built upon, and not fall into the mistake of have a style for every different table we need. --DrPhoton 03:33, 14 November 2007 (EST)

Yes, I agree that we don't want to try to come up with CSS tables to cover every single situation. I was mainly thinking that I know there are cases where greylapse has been used instead of wikitable because of some of the formatting details (valign=top, for example), and wanted to provide better support for that. Probably the options in the CSS tables should focus on some of the formatting aspects that are much easier to do in CSS... valign=top or other commands applied to every row being a good example. But there are also some formatting options that can't be done more easily in CSS (first column left-aligned and the rest centered might be an example of that). --Nephele^Talk 13:46, 14 November 2007 (EST)

Myself, I generally default to wikitable, but there are cases where I've switched to greylapse for a few specific reasons. First, having the text top-aligned can be an advantage if you're going to be using Linkable Entries in the the table. An example would be the Morrowind:Leveled Lists page. When I had it as wikitable before, a link would bring you to a list, but half the list would be scrolled off the top of the page and you'd have to scroll it back down to see it all. By having the titles with the linkable entries top-aligned, you now see the whole list when you link to an item on this page. The other place I've been using greylapse is on Quest Stages sections on the Morrowind quest pages. My main reason for this was that it conserves space, allowing you to see the whole table at once except in the most extreme cases. When space isn't a premium, I generally go for wikitable instead. I wouldn't mind changing them to be more similar (there's no reason for the header colors to be different, I think). But eliminating one in favor of the other seems to be a bit hasty to me.

Alternatively, we could change them so that they're even more different, in order to make them less redundant. Maybe make greylapse have slightly smaller text or even thinner margins/padding, to further give it the advantage of fitting in tighter spaces (since that's what it's generally used for). Maybe make wikitable entries all centered by default instead of just the headers? (maybe not). Maybe a third class that's right-aligned by default would be useful for things like item-pages where you want the weight, damage, defense, etc. values to all be on the right side so the digits line up. Now a lot of this alignment stuff was made much easier by my Template:AL template, but I can still see an advantage to having classes that do this by default. A name-change for the classes to make them more accurately descriptive isn't out of the question either. (Keep the old names as duplicates, just so we don't have to change every table on the site, of course.) --TheRealLurlock ^Talk 15:25, 14 November 2007 (EST)

OK, I've started to experiment with how to implement things. I'll give things a couple more days before starting to make global changes to how the existing tables work. But here's what I'd suggest:

Change all tables on the site to class=wikitable (doesn't have to be done overnight, but that would be the long-term goal)
For tables that need other formatting options, add extra class options. So to get a table similar to the existing greylapse, you could use class="wikitable compress vtop". This allows editors to mix and match the options instead of forcing various options to always be combined. The options I've created so far:
- compress: reduces the padding in the table
- vtop: sets valign=top for all rows and cells
- firstleft: the first column of the table is left-aligned, the rest are centered. (Note: this one uses a somewhat obscure CSS pseudoclass known as "first-child". According to my CSS book, this feature is not recognized by IE6, so IE6 users will just see a center-aligned table. I've confirmed however that it does work in firefox and IE7. Also, this feature can only be used to make the first-column different from the others; no way to make column #4 special, for example).
Other options that have been suggested above can IMO be just as easily implemented as individual cases without the need to add hard-wired CSS code
- To center the whole table, use align=center
- To change overall text-alignment, use "style=text-align:center" or "style=text-align:left" (or use the Al template)

If nobody speaks up in a couple days I'll change the default header background on wikitables to be the #efefef colour currently used by greylapse tables. Other than that, I'd say it's just a question of finding some willing volunteers to gradually go through the site and start phasing out all the old table classes (hint: do a search on "greylapse" or "graylapse" to find them). --Nephele^Talk 13:15, 19 November 2007 (EST)

I believe that the Greylapse COLOURS are much better, as they the wiki a more unique feel. However, I believe that the padding and centereed heading on the Wkitables should be implemented on the Greylapse tables. If I knew how to work table scripting, I would change them myself! (HMSVictory 12:06, 20 November 2007 (EST))

Eh...Wouldn't it be easier to just change the colour of the wikitable header rather than the wikitable options on the greylapse? I've already started on making greylapse tables to wikitable ones. (Can't say I'm sure I have done it right, though.) Vesna 23:44, 20 November 2007 (EST)

A few reactions so far - The new tables do work for the most part. Some things I'd like to see changed though on the compressed tables. (In descending order of how important the are to me.)

The captions are too high. Greylapse captions are very close to the table, but wikitable compressed are much higher. This spoils the association with the chart when several tables are used at once (as is the case with the Quest Stages on several pages).
Header text is center-aligned by default, while Greylapse was left-aligned. Maybe I'm just not used to it, but I think the effect it has on Quest Stages tables is not a good one. See: Morrowind:Find Fedris Tharen, compared to any quest page that hasn't been changed over yet. When the table is just two columns, and the first is very narrow, it helps to have both column titles next to eachother, which you get from a left-align, but not from centered.
The header could stand to be a bit less compressed. Right now it's about the same height as a regular row, while in Greylapse it was a bit taller. I do get that the point is to be more compressed, but these look a little TOO compressed, maybe.
Now that I look at it, I agree with HMSVictory about the title colors from Greylapse. Call me resistant to change, but I prefered the old color scheme to the wikitable one in some cases.

I'm also not thrilled about the names for the new classes - they're longer, and have spaces in them, which requires you to use quotes, something that was previously only needed for sortable tables. Not sure what to do about that, especially since people have already started changing these en masse - a step which I feel may have been a bit premature before getting community approval of the new classes. (Also a job which presumably could be handled by a bot later on, but whatever.) Anyhow, I'll stop being a curmudgeon for now and see what other people have to say about this. --TheRealLurlock ^Talk 00:29, 21 November 2007 (EST)

Replying to Lurlock's points:

Captions look the same to me (I'm using IE7). See: Morrowind:Find Fedris Tharen and Morrowind:An Admiring Sponsor. If you were referring to the tables above, those have no captions, and the spacing you see is the margin of each of the tables.
I personally prefer centered headings, but if left-aligned headers are necessary, that can be done with "style=text-align:left". Maybe, the class definitions can be tweaked such that it's not necessary to include it on every cell, but just on the row.
I agree that headers can be a bit higher.
Greylapse color is in general better for me, but in some cases it can be a bit too dark, especially when you have several title cells together. I would also provide a boackground color between that of the Greylapse and the page background (wikitable has too much pink for me).
Regarding the names, I don't think there's much we can do about the spaces, as the styles are built upon different classes, that are put together in that way. Having a different class for each combination would not be flexible/practical.

I would also sugggest, as Lurlock, to stop any mass changeover until the classes and the way forward have been settled. --DrPhoton 03:45, 21 November 2007 (EST)

General clarification: my plan since the early stages of this discussion has been to change the wikitable background header colours over over to the graylapse colours. This was based on the discussion here, and that's what I stated two days ago in my last update to this discussion. The only reason I had held off on making that change was because I wanted to give everyone a couple more days to chime in with feedback on the decision. However, based on the feedback that came in over the last couple days it seemed to me that (a) everyone wanted the darker (greylapse) colours for the headers (b) not making the change was leading to general confusion with everyone seeming to think that the wikitable header colours were being kept. Therefore, I just went ahead and changed the wikitable header colours. Sorry, DrPhoton, but I was working on this change as you made your last comment, and therefore I'd already made it before seeing your request for a moratorium on further changes.

Overall with the changes, my impression was that everyone was in agreement with making changes to the table formats, which is why I started implementing the changes. And it still seems to me that everyone is in agreement with basic idea here, which is to standardize to a more uniform general table appearance and then have some variants for special cases. There are specific details with the CSS settings needing to be tweaked and I'm sure more tweaks will continue to be needed. However, the advantage of doing this with CSS is that it just needs to be done once in the CSS file and will apply everywhere, so I don't see why concerns about further tweaks mean that the entire project needs to be put on hold.

The only larger scale issue that appears to have been brought up is the names being used for the new classes. I apologize for making a unilateral decision about the CSS names. I thought that the most important issue here was the ultimate appearance of the pages to readers, and that there wouldn't be any reason for preferences in terms of whether the classes happened to be named "compress" or "compact" or whatever other class name someone might come up with. Therefore I didn't realize that it would be necessary to go through a step of proposing the exact names to be used for the tables and waiting for community consensus on what, to me, seemed like a minor coding detail. And I did not choose class names that contain spaces. Rather, I chose to set up several different classes that can be combined in whatever way editors feel appropriate to obtain the desired format. There is no class named "wikitable compress". Rather there is a "wikitable" class and a "compress" class. "compress" can be used by itself if someone wants, or it could be combined with any other class ("hiddentable compress", "prettytable compress", "greylapse compress", etc.); it exists independently of the wikitable class. In my opinion, setting up the classes this way provides the most flexibility for editors.

As for specific formatting issues:

Header spacing. I made a mistake in the original vertical spacing for the compress class; I meant to make the vertical spacing identical to greylapse but determining what that spacing is in greylapse is far from trivial. The vertical spacing has now been fixed. DrPhoton: it's likely that by the time you looked at the examples, the spacing had already been fixed.
Caption margins: I have adjusted the caption margins, both on wikitable and on compress. While I was there, I also changed the captions to be bold-face by default. Overall, I would like to find ways to make table captions look more "caption-like". Right now I never use them because I think they look, frankly, ugly (they just look like out-of-place standard text, and do not in any way stand out as being a "title").
Header alignment. Changing one header to be left-aligned instead of center-aligned is something that I think is more appropriately done on individual tables as needed. Unless you want to have a "queststage" table format, for example, that is set up to do all the formatting tweaks that apply to all quest stage tables. But I don't think that left-aligned headers are something that should be packaged in with other formatting options, such as "compress" or "vtop" because it doesn't seem like there's any reason in general why those options should always go together.

I'm willing to delay any further changes to the tables. Again, sorry DrPhoton for making more changes this evening, but I made them before seeing your request. And given that some of the changes I made were to fix mistakes and others to fix obvious widespread confusion, I'm reluctant to just revert them all now. But it would be helpful for me to get a bit more guidance on what exactly I've done that was not in agreement with the community consensus. Also, I'm not clear how exactly people would like to proceed if tinkering with the layout is not acceptable: I doubt that we can come to a consensus without actually seeing the changes in action (and I'll be the first to admit that I am very likely to make mistakes when implementing any suggestions, so it's not too realistic to expect that the changes can be made all at once and never be tweaked again). --Nephele^Talk 04:39, 21 November 2007 (EST)

I wasn't referring to your changes to the stylesheet (those can be undone with just one edit if need be), but to changes that have already been done to article pages, where "greylapse" has been changed over to "wikitable compress". In my opinion, we should refrrain ourselves from such changes until this discussion is sttled, or otherwise we may have to undo/redo a lot of edits to several different pages. --DrPhoton 08:33, 21 November 2007 (EST)

Ouch. As one of the two or so people that's aimed at, I honestly thought there was a consensus. Until a few hours ago there wasn't a dissenting voice on this page. Anyway, in the light of more recent discussions I've stopped. I'm going to post in more detail on this later on, but for now I've already spent enough company time on the site today! --Rpeh^{•T•C•E•} 08:51, 21 November 2007 (EST)

In Vensa's defense, I'd just like to say that she started changing articles because I asked her to. And if I'd had any suspicion that were wasn't consensus, I never would have asked Vesna to start making the edits. I sincerely thought that starting to change pages over to use the wikitable format was the least controversial part of any of this.

And I'm still somewhat confused as to what still needs to be decided about changing the articles. Yes, we all seem to want a standard format with wikitable as the basic standard format. Yes, we all think that variants are needed in some cases. I don't really see it as realistic to put up a list of every table on the site here on the community portal and vote on the desired format of each individual table. So it's going to come down to an editor or two going through and making judgment calls on a page by page basis and deciding which parameters to used for each table. Sorry for being somewhat obtuse here, but I'm still having a hard time understanding what needs to happen next. --Nephele^Talk 13:04, 21 November 2007 (EST)

(outdent) Okay, having thought about this for a while I'm not accepting that anybody has violated consensus. Nephele's post of 19 November clearly stated her intention to update the tables "if nobody speaks up in a couple of days" and also called for volunteers to start making the changes. Both things have happened since. Suddenly the implication is that consensus has been ignored and that the whole project should be shelved.

I think the project is long overdue and should go ahead at once. The site is a mish-mash of styles; not only are there the two main table styles but very often people have added their own improvements with non-standard cell padding, spacing and so on. That's not aimed at anybody incidentally - I've been at least as guilty as anybody else. Switching to a few, standard table forms will make the site look much more consistent; even professional!

As for the specific criticisms there have been on here, I'd say the names of the classes are ideal. It is much better to have descriptive names where possible; only people who looked at the CSS file will have been aware what "greylapse" meant but "compress" and "vtop" are a lot clearer. Yes, quotes are required except when using the base "wikitable" class, but then for 100% correct HTML they should be used anyway. I really don't want to see a lot of obscure codes like "wc" or "wv" for class names - we're not trying to win an obfuscation contest here.

Changes like this can only be tested by going and doing them. It's possible to edit your own copies of the style files but then only you get to see the changes. There's such a wide range of pages using tables that making the changes for real is the only way for everybody to see how everything will be affected. And to be honest, given all the browser variations out there, if we look at variant after variant until we all agree on the exact number of pixels that should pad out a table header, we'll die of old age before everybody is 100% happy

I don't see that there's anything wrong that a few tweaks can't fix. Let's get Nephele to do those and then get on with harmonizing the site. --Rpeh^{•T•C•E•} 14:42, 21 November 2007 (EST)

Before we get over our heads, I'd like to clarify a few things that may not have been clear. I only asked to call off the changeover of the tables because I felt that there were a few issues raised by Lurlock that needed to be addressed before a massive overhaul. I never accused anybody of breaching consensus and I don't believe anybody have done so. I also don't think this project should be scrapped, as it is quite necessary.

To go forward with the table changes let's all agree on the current table classes: wikitable, compress, vtop, and firstleft. I understand Nephele and Rpeh agree with these. I also agree. If Lurlock is also happy with them, then let's go on changing the tables. The classes can be fine tuned later on the style sheet, or we can even add new classes if we need. --DrPhoton 03:56, 22 November 2007 (EST)

Well, (after over a week) I'm okay for the most part - one other change I might suggest though - it seems to me that vtop is an option that will be used more often than not, especially if there are Linkable Entries in the first column, as a large percentage of tables have. I'd say that should be the default, and maybe have a vmid for any others. Or maybe just make the first column default to top align, and have a firstmid to center them? Not sure, just I know that there's far more reason to justify top-aligned text (due to linkable entries) than there is to justify center-aligned. --TheRealLurlock ^Talk 17:03, 3 December 2007 (EST)

I'll assume the lack of response to Lurlock's vtop suggestion means nobody has any objections ;)

To really be useful, I'm inclined to say that the default vertical alignment for all tables, not just wikitable-class tables, should be vtop. There are many places where invisible tables (no borders) are being used to layout information. For example, all the tables at Morrowind:People are embedded in an additional set of tables that position everything on the page. In all of those cases, we really want vtop-type alignment, and I know I've had to go in and add vtop (or previously valign=top) tags to countless tables to fix the alignment. Changing the default vertical alignment for every table on the site is a fairly substantial change, and it's hard to be sure whether there are tables that will be affected for the worse. But trying to scan through pages and survey what's being done so far, I think the vtop option will probably have no effect in many places (i.e., tables where the rows are only one line high will not be altered by a change in the vertical alignment), and will probably be an improvement in more than a few places. If we're going to make such a change it's probably best to do it sooner rather than later, and in particular so that any problem cases can be fixed as editors go through and fix up the table formats based on these updates.

So I'm going to go ahead and change the default alignment to be vtop. I'll add a vmid option, but I'll also leave the vtop option in the css files just in case. I'm not sure about the firstmid idea though (and wouldn't it be firsttop anyway?): I tend to find having different vertical alignment as you scan across a row of cells confusing, and I can't think of any examples right now where we would want to use it. But if as we proceed someone finds cases where that would be a useful option, it can always be added at that point. --Nephele^Talk 16:14, 21 December 2007 (EST)

Book Formatting

One idea that has bounced around at various times is to have a different, more "book-like" appearance for the various books collected on the site. I've done some experimenting this evening and found out that it would actually be fairly straightforward to implement some different CSS formatting commands specifically for books. An example of what might be possible is shown at Lore:King (you will probably need to do a hard refresh (Ctrl-F5) to see the new format). What has been done so far includes:

Indented paragraphs, without any extra vertical spacing between paragraphs: more similar to a printed book.
A serif font (instead of the standard sans-serif font used elsewhere): make the book text stand out more clearly as different (would also help to allow the actual text of the book to stand out more clearly from any notes or other additions).
A larger font: similar reasons to the serif font choice.
Margins on the left and right side of the text: again, differentiate book from standard text.

One of the key parts of this idea is to have indented paragraphs. Note that there are a fair number of books (in particular books imported from the old site) that already have indented paragraphs, for example Lore:A History of Daggerfall. However, the way it's being implemented right now is, well, somewhat ugly ;) The indents are being manually added using a series of   tags. This is very prone to errors and difficult to maintain.

What I'm proposing instead is to have a centrally defined format. If we want to later tweak some aspect of the format, all that's required is for an admin to change the CSS settings in a single place. Once implemented, all books will be consistent in appearance. The easiest way to implement this new format would be to add it to the Book Summary template used on every book page. Some additional details would be:

On pages with |Note=Yes, the book format would be skipped by default.
The Template:Book Footer template would turn off the book formatting.
A new template would be created ([[Template:Non Book]]?) which could be used to turn off the book formatting for any other sections of the page (i.e., for introductory editorial notes, etc.)

For those interested in the technical details, this would be implemented by adding a <div class=book> tag at the end of the Book Summary template. This would be an unpaired HTML tag and therefore would apply to the rest of the page. On most book pages the templates will not actually add a closing </div> tag. But the wiki software is good enough to notice that problem, and automatically adds the </div> after the end of page content, so as far as I can tell the HTML code ends up being fully legitimate and we shouldn't get complaints from any browsers.

If everyone else likes the idea, turning on the book format for all the pages on the site will be trivial. Some followup editing will be needed, however:

Some books are using <br> tags to create paragraphs. This new format relies upon paragraphs really being paragraphs (using the HTML <p> tag). The wiki automatically creates HTML paragraphs... but only when the paragraphs are separated by a blank link. Bottom line: <br> tags need to be eliminated from all book pages.
Introductory (or other comments) on pages will need to be enclosed in the new Non_Book template
  indents will need to be deleted.

Some of these tasks are ones that already need to be done (i.e., the existing task about UESPWiki:Task List/Books Needing Formatting), so this proposal isn't really adding a ton of new work. And the book pages will still be functional if the followup doesn't get done right away; they just won't be completely taking advantage of the new format yet.

Thoughts, feedback? --Nephele^Talk 02:13, 19 November 2007 (EST)

It looks great and will definitely make the books easier to format. As an extra bonus point, this would be a good opportunity to do some wikification of books too if people are already editing them. --Rpeh^{•T•C•E•} 02:39, 19 November 2007 (EST)

The example certainly looks very good. --Mankar Camoran^{•T•C•E•} 09:09, 19 November 2007 (EST)

Update: turns out it won't be so simple :| I'm hitting the same problem Lurlock was facing with the familytree templates: the wiki software is setup to invisibly close all html tags on a per-template level, rather than at a per-page level. So if I enter <div class=book> directly onto a page, it works, because it doesn't try to close the tag until the end of the page. If I put the same code into a template it forces the </div> tag to be invisibly placed at the end of the template, i.e., before the page contents even start.

It's behaviour that can be altered based on wiki settings, specifically using a $wgUseTidy parameter. On Wikipedia, the settings don't force html tags to be closed on a per-template level. Whether they would still be closed on a per-page level, I'm not sure. From what I can figure out at pages like this, we probably have $wgUseTidy=False right now, which means that the wiki's builtin functions try to do html cleanup on a per-template basis, and therefore don't do a great job. With $wgUseTidy=True it seems that a more complex program, Tidy, is used to do the html cleanup, and that program is called at a per-page level rather than a per-template level.

Given that we now have two applications that need $wgUseTidy to be set to true, I think it might be worth looking into getting that change made. --Nephele^Talk 17:55, 3 December 2007 (EST)

Resuscitation time! Tidy has been installed; the div code has been added to the Book Summary template; all of the book pages now have book formatting. However, there is a lot of tweaking that is going to be needed. In particular, pages with introductory notes need to be modified so that the note is not book-formatted. My thought is that only the text that is quoted verbatim from the game should be book-formatted; any additional information on the page should in standard wiki format, helping readers to more easily distinguish wiki information from the original information. So far I've set up Biography of Queen Barenziah as an example (including all of the individual volumes). For comparison, The Real Barenziah has not been done.

It took me a few tries to get the code to all interact properly, in particular for a complex case such the Barenziah example, e.g., a multi-volume book included in multiple games. But I've now worked it out so that only the Tamriel versions of the books should need updating. If everyone is happy with the way the examples look, then I can put together the details of what needs to be done to get the rest of the books tweaked.

Oh, and one more detail. I originally was thinking of turning off book formatting on notes, e.g. book summaries where |Note=yes. Now I'm leaning towards using it everywhere, in keeping with the idea of using book formatting to differentiate text that has been copied directly from the game. --Nephele^Talk 02:15, 24 February 2008 (EST)

User Page Warnings

A discussion of when and how warnings should be added to and removed from user and/or user talk pages. Much of the discussion is focussed on the warning on Aristeo's user page.

Because of its length (11 printed pages at this time), this discussion has been moved to Community_Portal/User_Page_Warnings. --Wrye 15:29, 2 December 2007 (EST)

Tamriel:Factions

I've been looking around Lore:Factions and I've noticed how terrible these pages are. Most of the Daggerfall factions are ok, but the Major factions, i.e. the Thieves Guild was made by a Daggerfall person. The description that appears on the top of the page and on the Lore:Factions_T page is fine, but the information inside is terribly incomplete, and also written from the perspective of a Daggerfall person. The Lore:Factions_T's page on the Tribunal Temple is fine, but it is too big of an article to not have its own page. It should have a description (the first paragraph works fine) and a link to the Tribunal Temple Tamriel page.

Basicly, what I'm saying is that I need help going through and fixing the major factions. I want all of the factions to have:

A description in the "Tamriel:Factions" page
A link to the factions Main Article, or if the Main Article would just be the description, then no link. (Some Daggerfall factions do not have a large amount of info to be written.)
The Main Article should include the description of the faction, along with a description of their role in the different elder scroll games.
More people working on them. These pages are orphans.

--Timmeh ^Talk 11:47, 1 December 2007 (EST)

I just did a revamp of the Lore:Fighters Guild article (following your cleanup of all the details, thanks!) to a layout that I think works better overall and is more consistent how I've tried to set up some other Tamriel pages. If you'd like to use that as a template/example for other pages, I think it provides the types of features you're looking for:

The main faction page, e.g., Lore:Fighters Guild is now directly transcluded anywhere else that a Fighters Guild description is needed (the previous buried /Desc page is obsolete; no need for new editors to dig around and find an otherwise unused page to edit the content).
The transcluded content contains only the basic description, but then automatically adds a link to the main article.
The main article contains links to all game-specific articles.

To get everything to work requires a few tricks with <noinclude>...</noinclude> and <includeonly>...</includeonly> tags, but I think even with the tags it's less obscure for most editors than alternatives such as a Tamriel:Factions/Fighters_Guild/Desc subpage and a template just to transclude that subpage. --Nephele^Talk 14:07, 1 December 2007 (EST)

{{Tamriel Factions Trail}} doesn't work correctly. You have the letter link as "Tamriel:Tamriel#Factions_(letter)" when it should be "Tamriel:Factions_(lettter)". --Timmeh ^Talk 14:59, 1 December 2007 (EST)

Nevermind, I fixed it. --Timmeh ^Talk 15:04, 1 December 2007 (EST)

Nice catch :) Looks like I've been making that mistake for a few weeks, now, too (on the other Tamriel trails...)! * Nephele sneaks off to fix all her mistakes * --Nephele^Talk 15:12, 1 December 2007 (EST)

Problem, many of the the templates that Uniblab used to do most of the Tamriel:Factions pages are rather annoying. Most haven't been made for Oblivion and Morrowind. I am really hesitant to just delete these peoples' work, but I think they are too game specific and rather annoying. Any suggestions? If not, I'd prefer that all of the templates for them be deleted, as I can't get any more information out of them. --Timmeh ^Talk 22:46, 2 December 2007 (EST)

Category:Faction_Data_Pages These are all of the pages that are used for infomation for the Tamriel: Factions Pages that I think need to be deleted. Why you may ask? For one, the Tamriel section is supposed to be an encyclopedia of information about the Tamriel Region. It is not supposed to be game-specific. Tables are not the way to have an enlightening article about a faction (almost all of the pages shown are tables, with the exclusion of the Faction Descriptions, and ones made for Morrowind info and Oblivion info). Faction Politics is a good idea, but the tables give too game specific descriptions. If one wants to know the allies and enemies of a guild in a certain game, then they should look in the game's namespace. The "Faction Training List", only is applicable to Daggerfall. In both Morrowind and Oblivion, non-faction npc's offer training, whereas in Daggerfall, you had to go to a guild to get training. Whether you were in the guild didn't matter. Of course, this is WAY too game specific. All the information is on the correct faction page under the Daggerfall namespace. The "faction benefits list" is almost only applicable to Daggerfall. In Morrowind, only a couple of benefits weren't available till a higher level. In Oblivion, the only benefits I can remember are being able to get into the arcane university and Guildmaster Benefits. "Required Skills" aren't in Oblivion. In Morrowind and Daggerfall, they are important, but not to the Tamriel namespaced pages, as they are too game specific.

I hope that cleared up any thing. If you wish to help, view the Lore:Fighters Guild to see what I want in the Tamriel:Factions pages. --Timmeh ^Talk 19:38, 3 December 2007 (EST)

Generic Place Summary Template

I've created a new template called Place Summary basically to allow a standard way of specifying location codes, regions etc for the minor locations of the games such as stores and houses. So far I've only put it on two pages: Divine Elegance and The Wastrel's Purse because I'm not sure everyone's going to go for the idea or will like the way I've done it and I wanted to get some feedback.

My reasons for using a separate template instead of adapting the Oblivion Places Summary are a) that there's no reason this shouldn't work for other games too, and b) The Ob one is complex enough without the various tweaks I needed to add here.

My reason for doing it at all is that I often find myself needing things like console codes for obscure places when going to investigate something and I'd like to have them to hand on the site. A template means these can be added easily and consistently.

So. Feedback? —Rpeh^{•T•C•E•} 11:37, 5 January 2008 (EST)

Only one comment - why not just call it "Place Summary"? That way it's similar to NPC Summary, Book Summary, etc. The word "Generic" just means more typing, and it's not really necessary to distinguish it from anything else. It could easily be used for all places, not just "generic" ones. (Excepting cities/towns, which already have a dedicated template.) --TheRealLurlock ^Talk 12:07, 5 January 2008 (EST)

That was what I was originally going to call it but I thought it would be better making clear that it's for everything - as opposed to the game-specific ones. Looking at it again now, I'd be tempted to agree with you though. Anything else anybody? —Rpeh^{•T•C•E•} 12:54, 5 January 2008 (EST)

Looks good to me. We've been needing something like this for the various store pages that have been created. I'd vote for just "Place Summary" instead of "Generic Place Summary," not that it's a major issue ;) While on minor details, I also wonder whether "Inn" or some other distinctive category should be used for places with beds instead of just "Store" ... although I can also see that differentiating types of stores could get overly complicated. It's also not something that affects the template, just how it's used ;) --Nephele^Talk 03:37, 6 January 2008 (EST)

Okay - moved to "Place Summary". Thanks gang - I'll start using it now. —Rpeh^{•T•C•E•} 07:53, 6 January 2008 (EST)

So, how do you define a location like "The Feedbag" in the Imperial City? Not a store, but no beds either. I'd call it a tavern maybe, but then you're adding another type. For that matter, will there be articles for things like Guild Halls? You can buy things at most of them, but I'd hardly call them stores. Likewise for Temples. We could use a more general term, like "Business" (at least for stores, inns, and taverns). And to keep the terminology consistant, maybe change "House" to "Residence". (Also helps to qualify people who live in dwellings that can't really be called "houses".) --TheRealLurlock ^Talk 00:50, 10 January 2008 (EST)

The Feedbag is an Inn: before this template it was already in the Oblivion-Places-Inns category, used the Oblivion Places Inns trail and present on the Oblivion:Inns page. Similarly, I've used "Stable" for the stables because that's what they were already using. I've used "Settlement" on Applewatch because it has a settlement icon but "Residence" for in-town ones seems sensible. There's no reason why it can't use terms like "Guild Hall", "Chapel" where obvious and "Building" where not. –Rpeh^{•T•C•E•} 07:19, 11 January 2008 (EST)

Edit tools for wiki markup

I've been thinking about removing the namespace links from the "Wiki markup" section that appears below your Edit window. They're left over from before we had transparent namespaces, and for the most part they're not necessary any more. The vast majority of links on the site will be within the same namespace, in which case the [[]] is now all you need. (And the Ab button on the top of the Edit window does that just as well.) For those links that go to another namespace, the OB, SI, MW, TR, BM, and Template:|Tam templates (as well as the others for older games) pretty much handle those cases well enough. The only ones I'd consider leaving would be the UESPWiki and Category links. UESPWiki links are uncommon enough that a template isn't really necessary. Categories are in more cases than not automatically covered by Breadcrumb Trail or Infobox templates, and only rarely need to be entered manually. (I just created the Template:Cat|Cat template to easily link to a category without placing the page in that category.) Removing those 6 entries from the Edit tools would shrink the box by a line or two, and possibly make it less confusing for inexperienced editors. However, since this affects all editors on the site, I thought I'd open it up to a community vote to see if there were any serious objections to this proposal. So, discuss below. --TheRealLurlock ^Talk 14:38, 10 January 2008 (EST)

That would probably make it much less confusing for new editors, especially editors used to other wikis, most of which don't use namespaces the way we use them. I prefer to keep the links in the box, however, as I use them frequently. I rarely, if ever, use the namespace templates. --GuildKnight^Talk2me 22:25, 10 January 2008 (EST)

Well, I myself used those links relatively often, rather than the templates you just mentioned (it's easier to make a single click than to type a few letters ;). Therefore I would vote agains shrinking the Edittools table just for the sake of saving a few lines. --DrPhoton 03:28, 11 January 2008 (EST)

I agree. I always use the full name for a link rather than the template and often use the links in the edit box. Those templates seem plain unnecessary to me - they increase the load on the server for the sake of saving people a couple of key presses. –Rpeh^{•T•C•E•} 04:40, 11 January 2008 (EST)

UESPWiki ^β

UESPWiki:Community Portal/Archive 11

Table Formats

Book Formatting

User Page Warnings

Tamriel:Factions

Generic Place Summary Template

Edit tools for wiki markup

Sponsored Link WAH?!

UESPWiki β

UESPWiki:Community Portal/Archive 11

Table Formats

Book Formatting

User Page Warnings

Tamriel:Factions

Generic Place Summary Template

Edit tools for wiki markup

Sponsored Link WAH?!

UESPWiki ^β