UESPWiki:Administrator Noticeboard/Archives/More Site Suggestions

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

More Site Suggestions

Sorry for the number of these "big idea" posts recently -- I think this should be the last set of new ideas (at least for a few months). However, during my immersion in the site's PHP code over the last couple of weeks, I've discovered a couple of other configuration changes that could be useful for the site:

• Better default category sorting
  • In a nutshell, it should be possible to remove the DEFAULTSORT tags from all of our trail templates.
  • To do this, I'd tweak the php code so that the default (used if no other category sort tag is provided) is no longer {{FULLPAGENAME}} (e.g., "Oblivion:Anga") but is something more appropriate for the majority of our pages, such as {{CORENAME}} {{SORTABLECORENAME}} (introduced above, e.g., "Anga").
  • The immediate effect on the site would be negligible, since we never use the default sort tag right now. However, we should be able to simplify our templates, fix problems with templates providing conflicting sort categories, and we should be able to use DEFAULTSORT tags the way that was intended: only use them on those articles that need special treatment.
  • This was also discussed above, but since it was buried under a lot of technical details there, I figured I'd put it somewhere more visible
• "Fixing" the Tamriel namespace
  • In a nutshell, make it so that any external links/bookmarks to old Tamriel articles will permanently work -- without us having to keep around the actual old Tamriel articles.
  • Specifically, what can be done is specify in the site configuration files that "Tamriel" is a namespace alias for "Lore". It's the same way that on Wikipedia "WP" can be used universally as an alias for "Wikipedia"; the result is somewhat like a super-redirect that works for the entire namespace. (Also, "Tamriel_talk" would become an alias for "Lore_talk".) I've tested how this works, and it is completely transparent: whether you type in a URL for a page, type in a link to a page, or use the search function, you always end up at the corresponding Lore page. Furthermore, when you end up at the Lore page, it always calls itself a Lore page (even the URL is fixed, i.e., there's a HTML-level redirect that happens, too, if necessary). I tested this on my test wiki, using the exact same namespace configuration as UESP. However, any skeptics can easily experiment on Wikipedia and see how WP works there.
  • Simultaneously, I'd suggest that in our wiki settings, NS=100 is renamed to Tamold and NS=101 is renamed to Tamold_talk. In other words, that we instantaneously transform all of our existing "Tamriel" articles into "Tamold" articles (this is not a bot-type move, but rather a single universal change made to the wiki's lookup tables). I think this would make it much less confusing trying to clean up the old articles. In case anyone is curious, without this renaming, the old Tamriel articles would still be accessible -- "real" Tamriel articles apparently take priority over the Tamriel->Lore alias. But I would be very very uncomfortable trying to delete all of those old Tamriel redirects if there's any chance that a Tamriel link is actually leading to a real Lore article (for example, if you don't refresh the to-be-deleted category, then actual Lore pages would effectively be listed in the to-be-deleted category).
  • Unfortunately I didn't realize this option existed back before we did the Tamriel->Lore move ;) It probably would have made nearly all the bot work unnecessary. But hopefully better late than never!
  • I think we could safely do this change right now; we would still wait until August to actually delete the Tamold articles, just because that's what we said we'd do. The other option would be to wait until August to introduce the alias, i.e., not make any changes until the currently established date. However, I don't see how waiting helps any readers -- why spend a few months telling readers they have to update their bookmarks if in fact they won't really have to in the end?
  • This is also an option to keep in mind for the Review and General namespaces -- we don't actually have to physically keep the namespaces, even if we want existing external links to those articles to work forever.

If these suggestions are acceptable to everyone, I could add these changes into the code that Daveh is about to install. --Nephele^Talk 20:07, 25 March 2009 (EDT)

That all sounds good to me, although RoBoT is a bit miffed that the work he did wasn't necessary! The sort order fix is also good - although with {{SORTABLECORENAME}} rather than {{CORENAME}} - unless that's what you mean by exceptions. –Rpeh^{•T•C•E•} 04:13, 26 March 2009 (EDT)

Yes, I meant to say SORTABLECORENAME ;) --Nephele^Talk 10:05, 26 March 2009 (EDT)

Daveh just added these changes -- the Tamriel/Tamold change is sitewide; the defaultsort change is only on content1 so far. Another new only-on-content1 feature is that our large categories have been fixed! Compare how the Oblivion NPCs category works on content1 and content2 when you're not logged in -- in particular that the "next 200" and "prev 200" links work on content1 but are useless on content2. --Nephele^Talk 00:44, 7 April 2009 (EDT)

I just noticed one thing while playing with the NS* magic words in the sandbox on content1. On UESPWiki pages, those new words return "Project". I know why, but I imagine that should be expanded into "UESPWiki"? –Rpeh^{•T•C•E•} 04:33, 7 April 2009 (EDT)

...and the subspaces don't seem to be working either ([1]). Should I just stop messing around until this all goes out? –Rpeh^{•T•C•E•} 04:45, 7 April 2009 (EDT)

Ugh, I introduced a typo when getting the main and main talk namespaces working, which effectively disabled the mod subspaces. I've fixed that, and I changed the namespace names to be the UESP-specific names instead of the canonical names, so that takes care of UESPWiki/Project and any other cases, if they exist. I also decided to finally get smarter about my testing, by creating some lists of test pages to run through before finalizing a set of edits, which should hopefully minimize stupid mistakes from now on. I've passed the code on to Daveh.

Also, UespCustomCode should be in pretty good shape, so it should be ready for serious testing. Although I can imagine that hitting these problems is frustrating, on the other hand, identifying them early is better -- especially given that it takes a bit of extra time to get any fixes posted. So I'd say test away -- as long as it isn't driving you crazy. --Nephele^Talk 12:09, 7 April 2009 (EDT)

It's not frustrating so much as uncertain. I keep wondering whether I've hit a bug or made a mistake. Just to check - it's only UespCustomCode at the moment, right? Not MetaTemplate? Am I right in thinking that needs the MediaWiki upgrade? That's the one I really want to play with! Also, shall we take this whole discussion to the talk page of one of the new extensions? –Rpeh^{•T•C•E•} 12:35, 7 April 2009 (EDT)

Yes, it's only UespCustomCode so far. So that's the NS functions, the #label and LABELNAME functions, and the CORENAME and SORTABLECORENAME functions. I've passed the code for MetaTemplate to Daveh, but he has not yet installed it. See UESPWiki talk:MetaTemplate for details about MediaWiki versions -- the short version of which is that it does not need an upgrade and in fact will not work with an upgrade (yet).

The best way to keep track of what's available is the Special:Version page -- or rather the content1 version of the page. The version of UespCustomCode that Daveh installed yesterday (with category fixes and search fixes) is version 0.4; the latest version with the new NS fixes is version 0.5. Even more importantly, down at the bottom of the version page is a list of all the tags and function hooks added by extensions. The one set of features that does not show up in that list is the full list of new variables (e.g., CORENAME, SORTABLECORENAME, LABELNAME -- although you can semi-infer that they've been added given that the sortable and label functions are listed); the NS variables show up because they can be used as functions (e.g., {{NS_NAME:Shivering}}) as well as variables (e.g., {{NS_NAME}}). --Nephele^Talk 14:06, 7 April 2009 (EDT)

I just tested and confirmed that the new default sorting is working -- it's just hard to find examples of pages where it is even being used right now, since the majority of our pages have a DEFAULTSORT tag or a manually-set key. Furthermore, updating a page's sort option is not trivial -- simply purging doesn't appear to work. Nevertheless, the dozen-odd redirects that I edited this morning are all being sorted correctly in the Redirects from Alternate Names category. One notable example is [[Tamold:The Wolf Queen, Book I/Description]]: it's being sorted under "Wolf Queen, Book I, The", whereas all of the other Wolf Queen books and subpages are being sorted under "Wolf Queen, v? ..." So it's clear that the default algorithm is taking effect, but also provides an example of a case where a manual sort key (or DEFAULTSORT tag) is preferable -- automatic algorithms can't figure out everything ;)

We could perhaps start gradually removing the sort tags from trails. I'd suggest, however, just focusing on cases where the sort tags are currently causing problems (I recall a case a month back where there was a problem on a tamriel rebuilt page, perhaps the TR trail and the quest trail conflicting, but I can't remember where for sure). It's likely that a lot of our trail templates are going to be merged/made redundant/deleted when we start updating templates, so all of the template-based sort tags should automatically get cleaned up as part of the general revamping. --Nephele^Talk 12:33, 8 April 2009 (EDT)

I can't remember either, but I'm pretty sure you're right and it was the quest and TR trail. I've removed the DEFAULTSORT from the Tamriel Rebuilt trail, but I didn't want to touch the site-wide templates without further discussion. I'm going to suggest that we take all the DEFAULTSORT tags off templates, wait until the job queue settles down, and then check the results. Otherwise, I imagine we'll find several places where pages are being affected by multiple defaults, which will be confusing.

It looks like there are about 150 templates using DEFAULTSORT, so that's going to be quite a bit of work. –Rpeh^{•T•C•E•} 03:07, 10 April 2009 (EDT)

One side effect of the recent change to Tamriel Rebuilt Trail is that old categories such as Category:Tes3Mod-Tamriel Rebuilt-Weapons are no longer used since now the relevant pages instead want Tes3Mod-Tamriel Rebuilt-Items-Weapons... --Gez 11:39, 10 April 2009 (EDT)

Hmm. That's how I think it should be done, but I've changed it back to the old way for now. –Rpeh^{•T•C•E•} 12:22, 10 April 2009 (EDT)

(outdent) You're going to hate me for this, but I have a new suggestion. Some kind of randomize function would be very useful for the "Did you Know?" section of the main page, and may be useful in one or two other places. At the moment, DYK items get added and removed at the whim of editors but they're still all true. If we had a "pick x items from this list" function, they could all be kept and re-used. Something like {{#pickfrom:2|Item 1|Item 2|Item 3|Item 4|Item 5|Item 6}}, which would pick two items from the parameter list.

On a usefulness scale, I know that's right down the bottom, but it has always annoyed me to see perfectly good "did you know"s disappearing without trace. –Rpeh^{•T•C•E•} 14:28, 12 April 2009 (EDT)

Done... at least in my version of MetaTemplate ;) I've added how it could possibly work at User:Nephele/Sandbox/2#Did You Know. The complicationsfeatures I added are:

• A seed parameter can be used to provide the random function seed. In my example, I'm setting the seed to the current week -- so Did You Know will look the same for everyone on the site, but will change once per week. Reducing the randomness means that if someone posts a comment like "I think that last Did You Know entry is wrong", we have some chance of knowing which entry is actually being discussed. It also means if a reader notices a couple of interesting entries in the DYK list, follows one of the links, then comes back to the main page, the other entries that caught his/her eye are still there.
• The 500 strangeness is so that if you view the Main Page/Did You Know page you are able to see all the DYK entries; the random 5 entries are only shown on the Main Page. Also, if the pickfrom number is larger than the number of entries in the list, the list is not randomized -- I felt it would make more sense when viewing the full list to have it always be in order.
• I kept the first four DYK entries out of the pickfrom, as an example of how we might want to treat any new additions to the list. I'd say if new DYKs are added, we want them to appear right away. Once they're "old news", then we can move them down into the pickfrom list. I considered whether to somehow work guaranteed entries into the pickfrom code, but it seemed like more trouble than it was worth.
• The separator text is inserted between each of the entries. Since wiki trims whitespace in parser functions, the line breaks all get stripped out. '\n' is the default value for separator, so that option doesn't really need to be specified in this case, but I made it possible to change the separator in case it's necessary for any other applications. Plus, the separator text recognizes C-style escape sequences.

Does it look like that would do the trick? --Nephele^Talk 02:56, 13 April 2009 (EDT)

Fantastic! That looks perfect. I wasn't expecting you to do it that fast... or even do it at all. My sink still needs unblocking, incidentally ;-) –Rpeh^{•T•C•E•} 03:28, 13 April 2009 (EDT)