Difference between revisions of "Talk:Main Page"

Revision as of 04:38, 21 October 2011 (view source) Xola (Talk | contribs) (→‎Connection down discussion: new section) ← Older edit		Revision as of 20:28, 21 October 2011 (view source) Rehevkor (Talk | contribs) (→‎Connection down discussion) Newer edit →
Line 354:		Line 354:
	See here: [[Status#Discussion]] --[[User:Xola|Xola]] 09:38, 21 October 2011 (UTC)		See here: [[Status#Discussion]] --[[User:Xola|Xola]] 09:38, 21 October 2011 (UTC)
		+
		+	:Please don't [http://discworld.imaginary-realities.com/w/index.php?title=Talk:Main_Page&curid=104&diff=32700&oldid=32642&rcid=35046 redirect this page] again. '''<FONT COLOR="red">Я</FONT>ehevkor''' <big>[[User talk:Rehevkor|<FONT COLOR="black">✉</FONT>]]</big> 01:28, 22 October 2011 (UTC)

---

Revision as of 20:28, 21 October 2011

	Old content for this page has been archived, and can be found at the following locations.
	Main Page/Archive 1 Main Page/Archive 2 Main Page/Archive 3 Main Page/Archive 4 Main Page/Archive 5 Main Page/Archive 6

Registered user spam

Some spambots register themselves and modify Idlechasing. This is probably because http://www.idlechasers.com/wiki/index.php/Main_Page now redirects there.

I protected it so only administrators can edit it. If this remains the only target for this spam, that I recall was the kind present on the idlechasers wiki, then they should tire of failing at some point.

Any changes can be placed in the talk page and will be put soon.

Or I guess we could just include another "real" page that's editable. Yeah that sounds nice. --Frazyl 21:55, 1 June 2011 (UTC)

Ok after a false start I moved Idlechasing to Idlechasing_real so the last one is editable by registered users and is included in the former. I hope that the spambots are dumb enough to just try on Idlechasing which will fail because it's protected. --Frazyl 22:02, 1 June 2011 (UTC)

In regards to the whole spamming thing, I did a tracert on the IP address of the most current one (173.234.121.94) and it resolved to rdns.ubiquityservers.com. Is it possible to just block all access from that domain somehow? I looked into it a wee bit and seems that specific company is used as a source by a large number of spammers, probably as a proxy of some sort. -- Baldarov 2 June 2011

They're a data center leasing servers. The ips are probably just compromised computers so blocking whole ranges is unlikely to fix anything because they'll be compromised computers outside that range, most of the ips will be collateral damage.

What we could do is not make new user be confirmed automatically. Not sure what restrictions there are on uploading files but if it's not protected by the captcha we could try to add that to it. --Frazyl 21:53, 2 June 2011 (UTC)

I've done a little searching - apparrently ubiquityservers are well-known for hosting spammers. Therefore, I've just tried putting in a set of range-bans on their entire domain. It's unclear whether the wiki actually supports range-blocks or not (there's a system setting that controls it; I can't tell whether it's set or not); we'll wait and see whether this eliminates the current lot. --Chat 14:11, 5 June 2011 (UTC)

I think we could cut nearly all the spambot edits by installing Extension:TitleBlacklist.

• We could block usernames with numbers or with CamelCase. Regexp could look like

([A-Z][a-z]+[A-Z]|[a-zA-Z]*[^a-zA-Z])

• We could block creation or move to pages having names used for spam but not for normal pages for example:

(cig|smoke|wiki|movie|bullion|bored|valium|proactol|reports|buy|submission|blackjack|casino|online|software|insurance|certification|User[^:]+:([A-Z][a-z]+[A-Z]|[a-zA-Z]*[^a-zA-Z]))

That way by blocking keywords the spambots will need to keep coming up with new ones and if we spot patterns in user names we can block those too. --Frazyl 23:27, 20 September 2011 (UTC)

CheckUser

Does anyone think installing the CheckUser extention would be useful, for blocking the IPs of the spammers? Яehevkor ✉ 12:25, 8 September 2011 (UTC)

Maybe but when blocking a user it says it blocks the last ip used by that user. Do we suspect the spammers use different ips to create the user and then to make changes?

What I'd like to use would be RevisionDelete to be able to delete revisions that are spam or gibberish so spammers can't link to the revisions (not sure if they do that though but maybe that's why they keep coming). This does not seem to be an extension but I don't see (show/hide) or (del/undel) buttons in history so it doesn't seem to be working.

To revert lots of bad edits by users we could consider Extension:Nuke. --Frazyl 14:21, 8 September 2011 (UTC)

Oh right to find if the spam users are in the same ip range and block that. Yes that would be useful. --Frazyl 16:22, 8 September 2011 (UTC)

I have php code that can do a basic "is this a valid mud character" name check. However, I have no idea if it can be incorporated into the wiki software or not .... Zexium 23:54, 20 September 2011 (UTC)

Thing is players often enough do not use a mud character name for wiki account. Though I suppose it could be mandatory for new ones. It would certainly be easier to check if they exist. Not sure how to include that check either. --Frazyl 00:02, 21 September 2011 (UTC)

As written it's an includable file with a single function that returns "true" if the name given is a valid character name. It uses the php sockets interface to open a telnet session and do a finger at the login screen, so there's no login (username / password) needed.

Ok, update - I spent some time this evening modifying a copy of the confirmUserCreate function for the version of wikimedia that we're using to incorporate a test of "is a currently logged in mud user with an mud account created at least 1 day ago". I *think* it's good to go. All new user accounts that weren't being created using character names of players would need to be pre-authorised by wiki admins, but I don't think that should be an issue. I can dial the test back to use "is a valid player charactername" with either or neither of "the character is logged into the mud" and "the character was created at least 1 day ago" instead of using both the secondary conditions as at present, but I don't think the triple check (valid player character, logged in, created at least 1 day ago) is that onerous a combination. Zexium 22:38, 14 October 2011 (UTC)

That sounds nifty. I'm wildly guessing there might be a way to hook in like extensions adding user creation checks presumably do without overwriting the function to avoid having to patch mediawiki with each version?

If you could put it up somewhere we could check it up. Mmm. Is there some means of preventing lots of requests in a short time?

I'm looking at that following a chat with Mishal (dwpriests wiki). Also, as a precursor filter, blocking any usernames outside the permitted lengths on the mud (less than 3 characters, more than 12 characters, containing digits). Actually, the latter qualifications I could implement easily, it's preventing the extension hitting the mud too hard when the wiki gets hit with an autocreating script that's the bigger issue. I'm thinking of a separate table of requests and if a site hits some threshhold (trying to create characters too fast, or too many failures in a given time) hooking back to the ip banning function. But this is a lot more effort than just patching the createUser function. Also, I have no idea how much of this could be done by, for example, prohibiting user names that include digits, have more than 12 or less than 3 characters in the existing wiki software. Eg if we can define a regex for a valid user name, use /[a-z]{3,12}/i and a message like "Ideally your user name should be your mud character name. User names are subject to the same character and length limits as the mud applies". Bear in mind that anyone whose mud character name is hijacked here can contact a wiki admin by mud-mail to get the issue resolved! Zexium 20:34, 17 October 2011 (UTC)

You could check Extension:TitleBlacklist, because it blocks users based on regexps in addition to other things and it should be compatible with Mediawiki 1.12.0+.

Looking at the subversion source files it adds a hook "$wgHooks['UserCreateForm'][] = 'TitleBlacklistHooks::addOverrideCheckbox';" to check various things.

In fact if the source is not too difficult to work with it would probably be a good idea to add functions to that extension so we could also block new pages with that code (because unregistered users post spam even despite the captcha). --Frazyl 00:45, 18 October 2011 (UTC)

For putting it up on the site you'd need to ask Drakkos to do it, I don't think anyone else has access.

Not yet, I need to mitigate sending repeated requests at the mud if we get hit by a script first. As I don't actually run a wiki myself, I need to work out the best way to marry such functions to mediwiki. I might create a new mediawiki extension that's designed specifically for validating against dw, rather than patch the existing one. Zexium 20:34, 17 October 2011 (UTC)

Checking fast I did not find any way to pre-authorize user names or do much of anything to users except modify groups or block them. Possibly creating a new user while logged in as admin might bypass checks but you'd need to turn it over to the user after that... --Frazyl 19:32, 17 October 2011 (UTC)

As an academic exercise, I pulled the latest 500 ips from the block log showing only single ips, and identified /16s that had 4+ hits and /24s that had 3. The following ranges were hits: 173.201.0.0/16, 173.203.0.0/16, 174.129.0.0/16, 60.217.0.0/16, 79.125.0.0/16, 188.143.232.0/24, 202.108.50.0/24 Zexium 03:31, 21 September 2011 (UTC)

Judge

As of this announcement , judge now works in a completely different way. This means that:

• All of the existing weapons rating data is invalid.
• We can't use the judge-method to determine a weapon's rating either.

There will be a short period of silence, followed by a long period of swearing, followed by changes to several templates. Please bear with me. --Chat 19:08, 10 January 2011 (UTC)

OK, I now think we've got enough research on Judge to start putting weapon ratings back in. A word of caution, however: Please don't add any weapon ratings in unless you:

1. Have read Research:Judge
2. Have a JIR of at least 220 in the appropriate weapon class (If you don't know what a JIR is, go back to step 1).

Or your information won't be accurate.

--Chat 19:46, 19 January 2011 (UTC)

Shortly I'll update the weapon infobox for entering judge data for overall, attack and parry with strength between 8 and 24. Provided it doesn't go horribly wrong and need to be reverted for fixes.

It should be easy to extend it beyond 24 if need be, just some copy paste but I'm not sure anyone is testing beyond that.

As a side-effect, the old judge overall, attack and parry data will not show anymore. This is necessary because without str we don't know what the old data was and it needs to be rechecked or entered. This is consistent with similar past updates.

The prototype for the new infobox filled with new data will be in Fine sabre.

Unfortunately, it's not possible to just copy the data from the tables because it reads the string, not the number... It's possible it can be made to work with numbers with more work.

--Frazyl 01:13, 25 May 2011 (UTC)

Ok it works now as in Fine sabre. I'd just like to put table lines for the str table but it doesn't want to work.

For those weapons done by Baldarov and others with the "Strength/Judge Results table" the info in that table was the one to use anyway, not the data without str in the infobox that's not shown anymore.

Todo: see if I can muck up something so we can put the numbers 1 to 14 instead of the label like "rather good" to place the info in the infobox for all those pages. Another day though. --Frazyl 03:16, 25 May 2011 (UTC)

I like the idea to summarize everything to one side of the weapon page. However, an opinion - aesthetically, the fine sabre example looks, well, overly busy on the weapon info column now. Would it be possible to do a multiinfobox? The front box could be as it has been, but have the Str-16 (being median 9 to 23) relevant judge info displayed. Then, if a person so desires, the second info box could just show the expanded judge info. If preferred, I can move this thought to the template's discussion area. --Groth 03:35, 25 May 2011 (UTC)

That's an interesting idea. But looking over all the str variations would take 14 clicks and wouldn't the buttons to show all available str be rather similarly spammy? Then again I'm not very knowledgeable on the multipane infobox things, maybe it can be made to work...

Would it help if the other judge info were put on top? --Frazyl 03:59, 25 May 2011 (UTC)

Oh maybe if instead of rather good (11/14) it was just "11 rather good" that would save 1/3 lines. Or I could scrap the string name to save on vertical space... --Frazyl 04:04, 25 May 2011 (UTC)

Ok changed it. It looks much more compact now. Still wish there were lines between rows. --Frazyl 04:36, 25 May 2011 (UTC)

Regarding the click for your str part there could be links to click for each str there is data for and one to show all. I just have no idea how to make that work with css at the moment. --Frazyl 07:10, 25 May 2011 (UTC)

I made the infobox accept numbers instead of string so you can put "11" instead of "very-good" as a first step to be able to enter the data from table in the infobox. I also tried to make a template {{Judge-str}} to make entering data take less typing but it doesn't work yet. --Frazyl 20:03, 25 May 2011 (UTC)

Ok it works now, you just need to type for example

{{subst:Judge-str|9|10|10|11}}

It then substitutes this when you save the page so that it looks like you didn't use it but it was used when converting Rose-hilted long sword. --Frazyl 05:52, 26 May 2011 (UTC)

It wasn't easy, but the dynamically updated table for weapons is done for Daggers.

Basically for every weapon page we need to change

{{Infobox weapon
...
}}

and replace it with

<onlyinclude>{{Weapon_data
...
}}</onlyinclude>

The data inside the template also needs to be updated to have the str versions like: Judge-overall-13 = pretty good

Numeric values also work like: Judge-overall-13 = 9

For now I put the values for 13 str in the table because there's no space for all possible str. Not sure if or how to make the str shown change.

On another topic, is there still what we can call "excellent xxx" weapons? Is someone going to update those pages with what, max overall value or do we scrap the pages?

--Frazyl 03:55, 30 May 2011 (UTC)

I synchronized the weights from the old table for daggers, some of those were more up to date than the pages for the weapons. Those checked with a balance should be bold as before. I weighted the delicate black stiletto, it wasn't the same weight for both. The new table is up and running, there's still a bunch of daggers with tables to move to the weapon_data. --Frazyl 08:28, 30 May 2011 (UTC)

For weapons using multiinfobox it is not possible to just include multiple boxes at once with current code. The solution is to create one sub page and place just the weapon_infobox inside them and then include those in the multiinfobox like in Switchblade. You then load the sub pages in the weapons table but not the main page and they'll all show up! :) --Frazyl 21:31, 30 May 2011 (UTC)

In regards to the weapon box info, should the "Appraises as" paragraph still be needed if all of the info is going to be in that? Seems a bit redundant to have the same exact data in two places. If it is due to some items not having exact measurements then I can see those being around. On a completely different subject, it is possible that the custom axes have a possibility of 10 different judge values for each type (5 weight categories, plus an additional one if weapon is stone which adds additional 20% to weigh, possibly changing judge as well) --Baldarov, 3 June 2011

Mmm. Well appraise serves as a nice way to verify the weapon type (there were some copy paste errors in the past it seems). I think the only thing that's sometimes in appraise and not in the infobox is the colour. There's the rough dimensions but I'd rather not have those in the infobox to prevent the weight issue of not being sure if it's exact. Plus the measuring tape can be carried around and the balance not. So yeah I guess after I do a check to verify the weapon types are in the right category I guess we won't strictly need it anymore.

For the custom axes we can do 10 different infoboxes I guess... Or maybe include 5 on top and 5 on the bottom. I need to check on what data I can include from Research:Flails for the custom stuff.

Baldarov could you please check and if possible fix the table in {{Wr-speed/doc}}? I tried to put something from the weapons in the wiki but I'm really not sure especially of those I made up that starts with "?". --Frazyl 23:34, 2 June 2011 (UTC)

I checked it out and put some new entries based on what the other categories have. I've not seen any others than what's listed there (I've looked also). I've been GFR'ng some of the heavier weapons in hopes of getting some other categories but I've not had any luck seeing any. I can compare swords now though so I can at least verify the order. Need a witch mocking in order for it to work though atm. I've started on the ordering of custom axes. Hope to get that cleared up too. -- Baldarov 00:01, 3 June 2011 (UTC)

Thanks. I've integrated those speed for the infobox and tables. Looks much better than just "?".

I'm thinking maybe if you GFR the lightest weapons they might go even faster? If you fail GFR it makes it heavier so you could try that on heaviest weapon to see if it goes slower.

I can cast GFR and mock if you see me online but I'm mostly trying to finish the weapons. :S --Frazyl 00:43, 3 June 2011 (UTC)

Work in progress

Need more info on ranged judge:

• Category:Fired weapons => Fired weapons
• Category:Thrown weapons => Thrown weapons

Changed to {{Weapon_data}}:

• Category:Axes => Axes
• Category:Daggers => Daggers
• Category:Flails => Flails
• Category:Heavy-swords => Heavy-swords
• Category:Misc weapons => Misc weapons
• Category:Polearms => Polearms
• Category:Swords => Swords
• Category:Maces => Maces

Summary tables:

• All melee weapons
• All ranged weapons

They had to be separate for the code to work and trying to pass the judge data just failed.

Parametric judge

You may have noticed some weapons pages being converted to use the {{weapon data var}} template.

This is because I've cracked the formulae for strength's effect on judge (works on all swords so far, at any rate) - so weapon data can be derived from a single number for each of overall, attack and parry, rather than an array from 9-23 str, and still produce the same results.

Pages with parametric judge format have various benefits:

• They take up a lot less template-expansion memory.
• They provide a much finer-grain measure - parametric overall judge, for example, has a range of 0-201 instead of 0-14 - so allow better weapon comparison.
• They can be used to extrapolate judge values at strengths outside the 9-23 range.

In order to determine what the parameters actually are for a given weapon, however, we still need the full judge/strength set (in most cases from 9-23 str, though there are some weapons that can be converted with less data).

Therefore, please:

• Continue the good work gathering full judge/strength info.
• Once full judge info is available for a weapon, either:
  • Convert it to parametric form yourself - you'll need to do a fair bit of trial-and-error with the parameters to make the results match up; or
  • Put the page in Category:Weapons ready to be converted and I'll get around to converting it at some point.

--Chat 21:19, 3 June 2011 (UTC)

I've tagged a bunch, there's more in Special:WhatLinksHere/Template:Rbkey that are missing 9 to 12 but have 13 - 23. --Frazyl 22:27, 3 June 2011 (UTC)

Vertical-select tables

I've added a new feature that collapses the rather large judge tables down to a single judge line, with buttons to change the strength the line uses. See Copper short sword for an example of it in action.

Please take a look, and let me know if you think this should be the correct long-term format for judge data (in which case all the weapons will be converted to use it), or whether you think something's not right.

--Chat 17:31, 4 June 2011 (UTC)

Well I think it looks great :D. Just wish I could figure out how that parametric thing works so I could change stuff if needed later on.

So... I guess the next step will be to add the same strength thing to the main weapon lists somehow?

--Baldarov

Alas, it won't be that straightforward. The vertical-select code requires the full table to be available in the article, and then works by hiding all but one of that table's rows. The server won't be able to cope with having 15 strength rows per weapon on the weapon list pages.

If we want to do something similar on the list pages, then we'll need to use another way. The most obvious solution would be to implement the parametric judge formulae directly in javascript and invoke that on the weapon list pages; I'd rather not do that until we're more sure that the current formulae work, however.

--Chat 20:16, 4 June 2011 (UTC)

It looks nifty but I'd like it if there were a show all button to switch back to seeing them all (and another to collapse it back I guess).

I guess it would be even niftyer if there was a list of the str buttons available to click on...

For the weapon tables for now I guess we could show a few. Like 13, 16, 20 maybe? That way you look at the closest one to your str if that's doable. Until we decide what to do next.

Mmm. Could we pass a parameter in the url for example str=14 and use that in the wiki templates to show just that? --Frazyl 21:25, 4 June 2011 (UTC)

Str variants of weapon type tables

Ok I've made completely dynamic tables for every str from 9 to 23.

No change for entering data, just modify the individual weapon page and add it to the base weapon type page. The base page is the "13" one, clicking on 13 return you to the base page.

The other pages include the base page so you can just go to the str you wish to see. The links for the other weapons type are the same str as you're currently viewing since the most likely use case it going to your str then look the different types for your str.

I had to change the templates a lot after doing lots of pages and it seems that as a result the pages are rather sluggish loading but it should stabilize after all the pages have been updated in the cache or something like that.

--Frazyl 01:37, 3 July 2011 (UTC)

I've put the "unknown" that replaced the "?" smaller because it was too visually obstructing for indicating lack of data.

I feel that the ? were easier to locate and took less visual space, not sure if the more verbose unknown is better. --Frazyl 22:39, 22 July 2011 (UTC)

Archiving

The main talk page was getting pretty big, so I've archived the old bits off.

The process for doing this is:

• Archive talk pages when you start seeing the "WARNING: This page is X kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections." message when editing them.
• Move any sections which have not had edits within the last 30 days to the archive page.
• The archive page is called 'Talk:pagename/Archive X', where X is 1, 2, 3, etc.
• Put the {{talkarchive}} template at the top of each archive page.
• Put (or update) the {{archives}} template at the top of the main talk page.

--Chat 17:25, 16 September 2009 (UTC)

Quest pages

What's the plan for the quest pages to remain in sync? That is, quests are duplicated on several pages, odds are modifications on one page won't be made on all of them unless everyone is aware that the quest is also present on another page.

I thought that maybe there was a wiki thing in place so that sections from one page came from another or that they mirrored each other but apparently not. Not sure if that's something that actually exists. Anyone know?

Barring that, should we remove duplicate quests and replace some of them with links? Or some other way to keep all the quest text in sync?

I came up with some ways to handle the issue:

• Make a page for every quest, the other pages link to the quest page. Downside is there will be lots of pages.
• Put all quests on one page, then the other pages link to the section of the quest. Probably a bad idea because the page would be too big.
• Make sure each quest is only on one page and that other pages are only links. Would need to decide on a level (domain/area/city) which would hold the real quest text.
• Add comments in the source of duplicated quests that the other version needs to be updated as well. People could miss that though.
• Insert idea here.

Or does everyone feel quests duplicated on several pages is no big deal after all? Frazyl 22:31, 14 March 2010 (UTC)

The third one would be easiest, but... eh. The first one is probably the best solution (possibly we could even stop using hidden text), but I don't like that they would then show up in Special:Random. They do currently, but it's not especially important because 1)there are comparatively few of them, and 2)spoilers are hidden and mostly below the fold anyway. There are only 1,234 content pages currently, so if we added a few hundred quest pages they'd be a significant portion of that. Maybe if we had a separate namespace ([1]) for them? Then they wouldn't show up randomly. --Ilde 02:23, 15 March 2010 (UTC)

A separate namespace sounds good especially if it allows us to show the text unhidden. As it turns out Special:Random also excludes redirects, so we could add redirects from the normal namespace for pages people might search or we want to link to... Probably only entry pages with warnings like Category:Quest pages and Unofficial_Quest_Solutions. --Frazyl 02:53, 15 March 2010 (UTC)

I actually like the hidden text as it enables me to uncover the mystery line by line if required (for example if I get stuck just because I cannot figure out the right verb, "exacto" comes to mind...). --Gunde 23:19, 31 March 2010 (UTC)

So, will someone create a quest namespace for quest articles? Or should we put them in the research namespace?

The primary advantage of a quest namespace is that this will stop quest pages appearing in Special:Random, which can send someone who doesn't want to be spoiled to a quest page and it will stop them appearing in default search (happens when the article doesn't exist) Special:Search, which will reveal the context of the search, that is unhidden quest info.

--Frazyl 18:31, 7 May 2010 (UTC)

AFAIK, creating a new namespace requires editing the server's LocalSettings.php; as such it's something that only Drakkos can do, so you should speak to him.

Please don't move quests into the Research: namespace - that will end up polluting Research: with things that aren't research, and we don't want that.

--Chat 22:45, 7 May 2010 (UTC)

Hey, what about the Help: namespace? It is somewhat appropriate and not really in use (the only thing in it is Help:Contents), and I don't think Special:Random catches pages in it.

--Ilde 18:42, 25 March 2011 (UTC)

Ok, so I came up with a few ideas to improve quest pages. For the namespace I was waiting for the captcha to be installed first so as not to ask too much at once...

So I made a template {{Prehidden}} that basically is like {{prebox}} with white on white text. The advantage of prebox is that it preserves line breaks and spaces and other characters without breaking out too easily as with <p> (making a list with * or : makes everything after visible) while removing then obsolete <br> tags and allowing some formatting like bold or italic. Also it puts a pretty box around the text.

See Alchemists'_Guild_quests for examples.

If it is agreeable we could turn {{Hidden}} like {{Prehidden}} unless there something that I didn't think of.

As for quest duplication, it is possible to include pages with {{Include}}. It's only a matter of merging quests into the subpage and the template includes them with formatting and a link to the included page.

As for what includes what Unofficial_quest_solutions looks good, there's some difference to the structure of the Discworld quest pages though.

If we get a namespace for quests, I was thinking that each quest could get its own page in non-hidden text, which would then be included in the lists in {{Prehidden}} boxes. So if you don't want to be spoiled too much you can check the lists and to edit the quest and to be spoiled it would be easier to see it all at once in the quest page. It would use a tweaked include template.

--Frazyl 07:02, 11 June 2010 (UTC)

Ooooo! The include templates are a neat solution for the duplication issue; kudos for that. --Ilde 03:04, 12 June 2010 (UTC)

Slight issue, when including a page with the template include it doesn't work. You'd think it would check if there really was a loop, but no it just refuses to do anything. The only workaround that comes to mind is to make duplicate {{Include}} templates, one per level. --Frazyl 07:14, 11 June 2010 (UTC)

Ok all pages have the same format and duplicate quests have all been merged except for Sentimentalist and Distant Exhibitionist which have several versions.

Some quests fitted several areas, put them in the most important area. To place a quest in several areas would mean putting the quests in individual quest pages and including those in all list pages that is concerned, but we said that would be too many pages so we'd need the quest namespace. --Frazyl 02:01, 9 July 2010 (UTC)

It occurred to me that while we can't include the text of the quests that could go in several places in more than one place (because we can't include sections, only pages as far as I know with mediawiki) we could place links to the quest.

Might be worth going through the quests vs the mud quest pages to put stubs for quests missing and links to quests that are somewhere else, at some point.

--Frazyl 23:20, 13 July 2010 (UTC)

Links

Ok so FIrefox has updated itself to reflect that people are no longer using http in regular usage and are just saying "whatever.com" - it would make sense if the wiki worked with that, e.g. [daftjunk.com/whatever]

http isn't really needed, we know unless specified otherwise it's not going to be ftp or whatever :) -Xola 07:56, 9 October 2011 (UTC)

I don't see the relevance of firefox 7 reportedly by default hiding the http:// protocol fragment in the address bar. Links can be made to show any text already, but require the url to still include http. If you mean change how the mediawiki software works you'd have to ask those developing it.

For many link types there's templates that allow you to concisely add a link.

For example for itemdb links please use either

{{Itemdb|123}} Kefka's item database or

{{Itemdb|123|}} [2] or

{{Itemdb|123|some text}} some text

to cut down on the source text, improve readability, and so that if the url changes we can update all the links at once. --Frazyl 17:02, 9 October 2011 (UTC)

Game Areas

Should we change this section to better reflect the traditional domain arrangements? eg Djelibeybi -> Klatch, Sto Lat -> Sto Plains? Zexium 16:58, 17 October 2011 (UTC)

I assume you mean on the main page.

That could be an idea, provided all the region pages exist already. How would you see this arranged? Something like the following?

• (Sto Plains): Ankh-Morpork, Sto Lat

How could it be made obvious that it's region -> most important cities without too much labeling?

There could also be a link to Category:Locations like "see all locations" or something. --Frazyl 19:08, 17 October 2011 (UTC)

Connection down discussion

See here: Status#Discussion --Xola 09:38, 21 October 2011 (UTC)

Please don't redirect this page again. Яehevkor ✉ 01:28, 22 October 2011 (UTC)