Guild Wars Wiki talk:Requests for technical administration/Archive 1

Cite.php

The main page makes it sound like a really bad idea, not a good one... am I missing something? — 130.58 (talk) 15:33, 23 February 2007 (EST)

When I added the possible problems section, I just copied them directly from the main cite.php homepages. I honestly don't see them any more cumbersome than the ref tags currently used over at GuildWiki, but the output is much more reader-friendly.

But, thus far, I'm the only one to voice any support for this extension, so unless someone else speaks up, I'm ready to give in and just strike it from the requests. --- Barek (talk • contribs) - 15:48, 23 February 2007 (EST)

The way the process should work is that only requests that have been approved by the community (on this talk page) should appear on the main page, however I just copied everything over when I made the change. I have no problem with cite.php but it doesn't really seem like there is much support for it. Because of this I'm going to remove the inclusion from the page, and I recommend that if Barek still wants this installed he begin a discussion about it here :)

I haven't copied the discussion over from the other talk page, since it seemed rather short, but it can be copied over if it's relevant. LordBiro 16:39, 24 February 2007 (EST)

Gah, sorry. Forgot that page existed. — 130.58 (talk) 17:33, 24 February 2007 (EST)

Mouse-over skill descriptions

I would like to know whether it would be possible for this Wiki to support a mouse-over function for skills? Currently there are third party mods for forum software (gwbbcode), as well as the GW homepage (for instance: mouse-over example on mainpage) that make use of this feature. An example of a successful implementation into MediaWiki can be found here: Example @ French Wiki.

Since the Builds-policy still isn't entirely set in stone, I won't comment on the usefulness for builds of this feature, but even the general strategy-guides (for example: Split) can make good use of this feature.

I guess it would be a 'nice-to-have', and possibly too much strain on the guildwarswiki-server, but I would like to hear opinions of others on this. -- CoRrRan (CoRrRan / talk) 07:52, 20 March 2007 (EDT)

I'd definitely like to see it - I imagine it's one of those things that'll find uses once it's implemented, rather than having a concrete list of usage areas now. For a start it could be useful on quick reference listings. --NieA7 08:10, 20 March 2007 (EDT)

This was discussed on GuildWiki previously. I don't remember what the arguments against it were, but the idea was scrapped. You might want to search for the discussion to see what was said. -- (gem / talk) 08:32, 20 March 2007 (EDT)

Server load, as far as I can remember. --NieA7 08:37, 20 March 2007 (EDT)

Then it shouldn't be a problem in this wiki. -- (gem / talk) 09:17, 20 March 2007 (EDT)

Ahh, yes, I found some conversations talking about mouse-over stuff here: Fyren's Talk Page and Community Portal Archive 12 -- CoRrRan (CoRrRan / talk) 09:51, 20 March 2007 (EDT)

Coulndn't ths be achieved by using popups like the one mentioned below. They already display what the skill does. If there was only way to attach pictures to it :/ --Sith 13:11, 3 April 2007 (EDT)

LaTeX math equations

Perhaps not really relevant for this wiki, but for Damage calculation, I think it might be nice to have the <math> </math> option enabled. MediaWiki link What are your ideas about it? The requirements for it are:

• Installed LaTeX on server
• $wgMathPath, $wgMathDirectory and $wgTmpDirectory in LocalSettings.php

The downside to it, is of course that I can only see one page (as of now) using it. Perhaps it would be a too big resource strain on the wiki? -- CoRrRan (CoRrRan / talk) 04:49, 27 April 2007 (EDT)

I don't see resource strain on the server being relevant, especially if it is only one page that would use it. However, the question is, does one page justify the effort of implementing it? --84-175 (talk) 03:14, 30 April 2007 (EDT)

If implementation effort versus minimal benefit is the main issue, maybe we could pass the request to ArenaNet as something like "we'd like this, but it's very low priority"? --Rezyk 12:10, 30 April 2007 (EDT)

Yep, that'll work. It's not a problem if we don't have this, I just consider it a nice to have. -- CoRrRan (CoRrRan / talk) 15:53, 30 April 2007 (EDT)

I also wish to use this the Latex Math extension for a page: Match win percentage, the use of <math> will contribute to a better overview of the article. I was actually searching for a way to get it implemented, that is how I ended up here. I hope it can be implemented soon. --Jurrit 18:08, 8 June 2007 (UTC)

actually there are several other pages that use equations, that would benefit from a more correct display of mathematics, instead of using the shorthand used while typing on a computer. Can anyone write a proposal and put it under the heading of community request, or are only certain people allowed to do this? Is the request for installing the math function already passed through to Arenanet? Jurrit 09:54, 18 June 2007 (UTC)

Anyone can write a proposal, but it should only be added to "Community requests" if a consensus has first been reached to install here.

That said, I personally don't support installing LaTeX support here on the wiki. Reasons: a) LaTeX syntax is relatively intricate and unintuitive to those who are unfamiliar with it (~ everyone), presenting another learning curve for contributors to deal with. Other extensions like DPL or ParserFunctions also have this issue, but at least for those the practical benefits are more obvious. Which leads to b) I don't think the articles would really gain much by LaTeX-rendered images. The formulas we have here are relatively straightforward and simple to interpret in their current state, while TeX's helpfulness is more significant with more complicated formulas. c) Not only don't I think that TeX support adds much to these articles, I think it actually makes them slightly less practical. It's easier copy/pasting around text than images, and text allows you to dump a formula into a Google search field, plug in your values and hit Enter to get your results. d) In addition to needing to grab a bunch of packages to get LaTeX running, having to install gcc on a server box just to compile texvc for MediaWiki is not really that much fun either.

My question for you: Wouldn't it be simpler just rendering offwiki the images for the formulas that really would benefit from this and upload them here? (From those three pages you linked to, nothing I see would qualify for that, but that's just my personal opinion so feel free to disagree with it.) --Dirigible 18:28, 18 June 2007 (UTC)

I implemented your suggestion on these pages: Tournament Reward Points, Match win percentage. In my opinion this gives a much better overview of the formulas. I put the text version of the formulas in the comment, so it can be copied by going to the edit page. I did have some problem with the size of the pictures. I adjusted this with the |..px]] operator behind the picture based on the width of the pictures. This would be easier with the math plugin. Remark on a) if you go to the wiki handbook and to formulas, it is explained how to use the formulas, this is also how I knew this could be used, but didn't work. Jurrit 20:37, 18 June 2007 (UTC)

StringFunctions

StringFunctions would also be useful right? -- ab.er.rant 02:09, 22 March 2007 (EDT)

Agreed. StringFunctions will allow us to support auto-categorisation more effectively - I particularly like #explode. :) It does sound like there are ways to exploit it thou - but it seems that it maybe as simple as ensuring the delimiter sizes for the feature are suitably small to prevent this. Perhaps reducing the default values for the delimiters by half, possibly more. Does anyone have any experience with the add-on? --Aspectacle 02:37, 22 March 2007 (EDT)

Actually, I'm more interested in #sub, #len, and #replace. The #explode seems to have a problem where you can't tell exactly how many tokens you have. -- ab.er.rant 02:45, 22 March 2007 (EDT)

Can we list some examples of how it would be used? I'm not as worried about performance as I am about potential usages complicating things too much for wikicode novices. --Rezyk 13:40, 22 March 2007 (EDT)

A quest can have a type - at times it can be a mix of two. You would be able to pass in Primary/Skill type. You could spilt the Primary and Skill using '/' into separate entities wiki link them from display and automatically add the quest into Primary quests (Nightfall) and Skill quest categories. This is a hand full of special cases, but to capture this with our current toolset you need to provide a second or third parameters on the template to capture them. This is also true of weapons which have multiple attributes, missions which have multiple regions (Fort Aspenwood for instance), items/weapons which have multiple common salvage. The <no wiki>[[]]</nowiki> brackets could be removed from parameters simply using String Functions. Aberrant might have other uses. It is starting to get a bit more programmatic but not significantly so over the ParserFunctions stuff. --Aspectacle 19:08, 22 March 2007 (EDT)

You covered my ideas for it. Basically, I was thinking it would be useful to help strip <no wiki>[[</nowiki> and <no wiki>]]</nowiki> from parameter values. It would be even more useful if they had a function to change strings to lowercase. As for the #explode function, it will help process comma-separated parameter values, like a list of location exits. Although, as I mentioned, we also need a way to figure out how many pieces there are for it to work. -- ab.er.rant 19:44, 22 March 2007 (EDT)

Sigh...you guys and your auto-categorization and over-categorization... =P Please count me as neutral/apprehensive on this and note that "{{lc:Guild Wars}}" gives "guild wars". --Rezyk 21:43, 22 March 2007 (EDT)

It does? Woot! Thank you! :p -- ab.er.rant 22:11, 22 March 2007 (EDT)

I'd just like to get some discussion rolling on the thought of adding stringfunctions to this wiki. As I see it, they would allow the forced wikification of links in infoboxes, which is the main reason of starting this discussion (e.g. replace all [[ or ]] with whitespace, and force the parameter to be surrounded by [[ and ]]). I'd like to hear the opinions of those who are more StringFunctions/Wiki savvy than myself before going ahead and making a request. Cheers. --Indecision 07:29, 27 April 2007 (EDT)

This was discussed further up the page, but it didn't really go anywhere so I'll continue here and you can move it with the rest if you want. I think in certain situations the use of StringFunctions would be helpful, but to use the example mentioned in the above discussion, in that instance StringFunctions is not the ideal choice.

The example given is that quests usually have one type, i.e. Primary. But sometimes they have two types, Primary and Skill. The suggestion above is that you would pass in "Primary/Skill" as the type and StringFunctions would parse this. The justification for using StringFunctions is that there is no easy way of doing it without using StringFunctions. But I disagree:

The problem has not been thoroughly thought out; if a skill cannot have one type then "type" should not be a parameter. "Primary" and "skill" should be individual parameters, i.e. {{ quest infobox | primary = y | skill = y }}.

My point is that, while StringFunctions is no doubt very useful, in certain situations it can easily be overused where the current tools would suffice. LordBiro 08:16, 27 April 2007 (EDT)

My bad LordBiro, I've moved everything down here now :). I can see your point, however, what to do about mis-entered/mis-wikified entries. My example mainly revolved around correcting all entries to be wikified. I agree that there are better, perhaps easier ways of entering data via existing parameters, however I'm not convinced that StringFunctions won't be useful. --Indecision 09:14, 27 April 2007 (EDT)

I wasn't saying that StringFunctions wouldn't be useful; far from it! I think it would be very useful. But I think that there will be occasions where people will implement a solution in StringFunctions that is unnecessary, and I think caution must be exercised to ensure that we do not fall into the trap of using StringFunctions to parse strings and such like. Such solutions are unnecessarily complex and the same results can be achieved using other means. LordBiro 09:39, 27 April 2007 (EDT)

So, we're not really arguing, merely saying that some restraint needs to be excercised in the use of StringFunctions :). Maybe it would be a good idea to write a quick guideline/help document on the use of StringFunctions to help people creating templates from overusing the abilities present. Don't want it to be LagWarsWiki afterall :). --Indecision 09:44, 27 April 2007 (EDT)

Damn, we don't have StringFunctions installed... :-( User:CoRrRan/Latest update... :-( I almost had the {{Latest update}} in full automatic mode... --  (CoRrRan / talk) 00:56, 18 July 2007 (UTC)

Revival

I would like to get this request rolling again, since I see a practical use of it to update the {{Latest update}}-template. As can be seen in my example in my previous comment, I am quite close to obtaining the code to fill the date into the template automatically, but I need StringFunctions for the final step. Am I the only one who would like this request to be brought to A.Net? I know LordBiro made an objection that perhaps StringFunctions might get used too quickly if they are implemented, and I'm wondering whether that objection would also fall on the proposed change to the {{Latest update}}-template? Personally, I haven't missed the StringFunctions much, but that is due to my inexperience with MediaWiki-code. I'm still learning as I go and this wiki has proven to be a great testbed for me up until now. But I do realize that the update template is easily updated by anyone with sysop/bcrat access.

Your thoughts? --  (CoRrRan / talk) 17:14, 24 July 2007 (UTC)

*B-U-M-P* "Help, help, I'm being ignored!" Variation on "oppressed". --  (CoRrRan / talk) 10:52, 27 July 2007 (UTC)

I agree that StringFunctions would be very useful, if for nothing else but to help wikifying/categorising entries. I can understand LordBiro's point about it being overused however I don't think that its something that will be necessary to monitor or worry about in the short term. To be honest I see mainly positive benefits from StringFunctions, with negative issues being able to be controlled either through policy, common sense or sheer lack of effort (on the behalf of those who might cause any negative issues). I'm open to ideas as to why StringFunctions shouldn't be allowed, but I still think it would be a beneficial addition to this wiki. (Feel better CoRrRan? :P)--Indecision 12:03, 27 July 2007 (UTC)

Need more support! I think stringfunctions are going to be very useful with further enhancement of the {{skill infobox}}. --  (CoRrRan / talk) 08:16, 8 October 2007 (UTC)

Archiving this

Was thinking about archiving this page, but I'm not quite sure how to handle proposals that haven't had much discussion yet (such as subpages or mouse-over skill descriptions); I'm somewhat worried that archiving them might give the (not necessarily true) impression that these proposals failed. These are the options that I see:

1. Archive all discussions with over 1 month inactivity (or some other timeframe), regardless of whether they succeeded or not.
2. Archive only the resolved sections, leaving everything else still up here.
3. Archive resolved and unresolved issues over 1 month old separately in two separate pages (/Installed and /Not installed, maybe?)

Thoughts? --Dirigible 19:01, 3 May 2007 (EDT)

The stuff that's resolved definitely needs archiving, so feel free to do that whenever! I think it's probably best we leave unresolved sections. "installed" and "not installed" do not equate directly to "resolved" and "unresolved". We might resolve that the proposal should not be installed :) in which case it should be archived. LordBiro 04:38, 4 May 2007 (EDT)

NavFrame

I am interested in creating "hidden" information on a page (to prevent spoilers from being visible or answers to questions, etc.). It was suggested by Dirigible that I bring it up here for discussion. Currently, the only reaon I would like this is for a riddles page that hides the answers until they are clicked on but I would imagine it could also be used for spoiler related info too, among other things. I don't know how to get this implemented or what it may take to do so. Ideas, suggestions, input? Thanks. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 07:59, 4 May 2007 (EDT)

This could be implemented in CSS/JavaScript, but I'm not a fan of using it by default on spoilers. LordBiro 08:13, 4 May 2007 (EDT)

Agreed. Our users must expect a website that exists solely to document the game in its entirety is going to have spoilers. I think intentionally obfuscating our information is contrary to that stated mission. —Tanaric 08:18, 4 May 2007 (EDT)

Ditto. I mean, we all know that using the wiki as a reference tool is kinda cheating a little bit anyway; by accessing info, you have to expect that "spoilage" will occur :D if you see what I mean Fox (talk|contribs) 08:33, 4 May 2007 (EDT)

That's fine. I was just trying to come up with a better reason to use it than a riddles page was all. If there's not good reason to have it then I'm not bothered by it. It's just a convenience thing was all. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 08:40, 4 May 2007 (EDT)

Can we use it for quick reference legends, a la Guild Wiki? I'm always looking for ways to cut down on page real estate on the quick refs, when I saw it at GW I thought that was a particularly good idea. --NieA7 08:57, 4 May 2007 (EDT)

I'm really in favor of NavFrame. I once saw a userpage utilize it, and I think it could be very useful overall. You'd be surprised how many things are spoilery but your eyes automatically catch onto a specific word as you scroll down past it. File:Esig2.jpg Eldin 16:11, 9 May 2007 (EDT)

You make it sound that it's such a rare thing Eldin :) Browse over to GuildWiki and there's dozens of user pages that use the show/hide navframe ^-^

But if we wanted to, we can actually make use of the hidden frames to hold different levels of "spoilage" ;) kinda like the hints system. So we start off with hints and a general explanation, then detailed tips and special notes, and the deepest level is a full blown walkthrough. This would mostly just apply to missions and maybe some of the more complex quests though. -- ab.er.rant 23:40, 9 May 2007 (EDT)

I support this "thing" here. The only thing I do not know is if allows for any coding exploits. If not, let's go for it, my user page could use it. --Karlos 06:24, 26 May 2007 (UTC)

So, are there any actual objections to the installation of NavFrame? If we don't want it to be used for spoilers or such, we can decide that on a case by case basis. --Dirigible 20:03, 8 June 2007 (UTC)

Seems we have a consensus then. If someone with the sysop bits can install it, it'd be great. The install instructions can be found at wikia:Help:Dynamic_navigation; just copy/paste that content into MediaWiki:Common.js and MediaWiki:Common.css, and that should be it. --Dirigible 11:45, 12 June 2007 (UTC)

Shouldn't we decide what we want to use it for before installing it? I don't see any consensus on what we'll be using it for. -- ab.er.rant 12:21, 12 June 2007 (UTC)

I think I'm going to say what no one else wants to: I think its main use would be in the user namespace. I can't think of any mainspace article that would benefit from using it (using it would be discouraged because of its limited functionality in different browsers). That being said, it is a neato thing, and while I wouldn't use it, I know a lot of users would like it for their userpages. It just depends on Anet whether or not that is a good enough reason to install it. - BeX 12:33, 12 June 2007 (UTC)

Miscellaneous uses in userpages, archive boxes, extended info navbars, that general idea. --Dirigible 14:36, 13 June 2007 (UTC)

Because of the intended use being primarilly user namespace - then I think this sort of thing should be in each individual's user css and js page for those who want it, rather than being site wide. That prevents something that would be used by some users from having to be loaded by all users. --- Barek (talk • contribs) - 15:02, 13 June 2007 (UTC)

Barek, do you honestly think that it being on userpages is going to affect you? I really think the commanding populus of the wiki needs to stop worrying about what they might run into and stop trying to police what goes on in people's userpages. It won't slow down the page load times, so I don't see why it would be a problem to add it. I think it's just an issue of control. - File:Drago-sig.gif Drago 15:14, 13 June 2007 (UTC)

That just implies the uselessness of all the talk sections here. Why bother discussing whether we need something when we should really just install everything that doesn't affect page load? As will all apps, every plugin installed does impact the whole in a small way. As such, before adding stuff, why shouldn't a discussion take place on whether something truly benefits the wiki as a whole or just a subset of registered users? -- ab.er.rant 16:04, 13 June 2007 (UTC)

If someone is so clearly against it, what does it matter to them if it's there or not. Other than the fact that said person wants to be in control in knowing that the navframe isn't there. I mean, if you don't use it, what should your opinion matter to those of us who DO want to use it, I mean, come on, some people really need to stop playing the devils advocate, and just stop trying to monitor every tiny little change. The NavFrame would help with organization greatly, and frankly because some people don't want it, doesn't mean we can have it, and they must use it. Using it is at user discretion, and shouldn't be left out of the wiki simply becuase a fraction of the users don't like it, nor want it. - File:Drago-sig.gif Drago 19:12, 13 June 2007 (UTC)

With the same reasoning, it shouldn't be installed simply because a fraction of the users like it. In my opinion. - anja (contribs) 19:21, 13 June 2007 (UTC)

That's bull.. It's not going to hurt anyone, why not have it, if not for the people who plan to use it. I mean, it's not going to hurt anyone, or is this another control issue? - File:Drago-sig.gif Drago 22:46, 13 June 2007 (UTC)

I am not suggesting trying to police or control user pages by this - I honestly have no clue where you're coming from with that, it's completely contrary to my statement. In fact, my words were I think this sort of thing should be in each individual's user css and js page for those who want it. If a user wants it in their own user space, let them add it to their own css and js, it's completely at the user's discretion and control on if they have it. Just don't make it site wide, there's no need for it if it's only for use on user pages. --- Barek (talk • contribs) - 03:28, 14 June 2007 (UTC)

I strongly agree with Barek. I do not think this should be installed just because some users (including myself) would find it neat in userspace. I interpret Biro's comment above as opposing this as well -- even if it isn't, I certainly don't see a consensus for implementation. —Tanaric 16:34, 15 June 2007 (UTC)

I definetly see no point in it for spoilers, it opens an incredibly large can of worms as to what is a spoiler anyway? Oooh Rurik dies is a spoiler to an extent, but then that makes everything after searing a spoiler too, and maybe searing itself. Basically if you come here I think you have to accept that this is an encyclopaedic site about the game and will document everything. As for user pages, honestly it's not your own personal website. The more silly tools there are for the user pages, the more irritating edits fill up recent changes and the less people contribute to the main space. --Lemming64 16:45, 15 June 2007 (UTC)

Although I would love this for my personal user space quick references, I have to agree with Tanaric. -- (gem / talk) 16:53, 15 June 2007 (UTC)

Rate limits

Setting $wgRateLimits is a simple way to limit edit floods. The primary reason to lower the rate limit is to mitigate the potential damage of malicious attacks. On the other hand, we generally want to keep rate limits high enough that regular editors will rarely/never run into it, and that legit bots will not be hampered too much (if at all). I'll throw out some starter numbers to consider:

array(
   'edit' => array(
       'anon'   => array( 600, 600 ), // for any and all anonymous edits (aggregate)
       'user'   => array( 100, 600 ), // for each logged-in user
       'newbie' => array( 100, 600 ), // for each recent account; overrides 'user'
       'ip'     => array( 100, 600 ), // for each anon and recent account
       'subnet' => array( 300, 600 ), // ... with final octet removed
   ),
   'move' => array(
       'user'   => array( 50, 300 ),
       'newbie' => array( 10, 300 ),
       'ip'     => array( 10, 300 ),
       'subnet' => array( 30, 300 ),
   ),
)

This would mean, for example, that a regular user or bot who makes 100 edits within the span of 10 minutes would get server errors on further edits for the rest of those 10 minutes. --Rezyk 18:28, 4 June 2007 (UTC)

Is this a problem yet? I'm aware of some of the concerns tossed around via email about bot abuse, but I'd still rather wait until this becomes an issue before we make it one. —Tanaric 18:59, 5 June 2007 (UTC)

No, it's not. I'd rather err on the side of caution, though. I'm not really sure about those times, though - the longer the period, the easier it is for a user to do valid edits, but if someone manages to go above that, they have to wait a longer period of time before editing again. MisterPepe talk 19:04, 5 June 2007 (UTC)

Maybe we could just up the limits enough that the risk of creating an issue or stalling a user is negligible? I took what appears to be the maximum rate of editing that we've ever had over 10 minutes, and then roughly doubled them to get:

array(
   'edit' => array(
       'anon'   => null, // for any and all anonymous edits (aggregate)
       'user'   => array( 200, 600 ), // for each logged-in user
       'newbie' => array( 200, 600 ), // for each recent account; overrides 'user'
       'ip'     => array( 200, 600 ), // for each anon and recent account
       'subnet' => array( 400, 600 ), // ... with final octet removed
   ),
   'move' => array(
       'user'   => array( 100, 600 ),
       'newbie' => array( 100, 600 ),
       'ip'     => array( 100, 600 ),
       'subnet' => array( 100, 600 ),
   ),
)&:::Also, part of my reasons for wanting this is to justify a more relaxed bot policy. The less damage that an irresponsible bot can potentially do, the less reason there is to worry on that front. --Rezyk 08:45, 6 June 2007 (UTC)愠

Fair enough. TBH, I'm no longer sure we even need a full-fledged bot policy. MisterPepe talk 08:50, 6 June 2007 (UTC)

During a shorter time period the one edit per 3 seconds limit would be too restricting, but during a 10 minute time span it wont harm normal users at all. Agreed on the latter suggestion. -- (gem / talk) 12:05, 6 June 2007 (UTC)

Heh we should ask Bex about how many edits per second/minute/10 mins is ok! I do also wonder if this is totally necessary though, if it was implemented I'd like to see it set to a very high rate to guarantee that no user will hit it accidently, getting an error message halfway through a crusade would be pretty annoying, is the medicine worse than the sickness? --Xasxas256 12:27, 6 June 2007 (UTC)

:( - BeX 13:21, 6 June 2007 (UTC)

Awwww... ^_^. Those limits look fine to me. Ale_Jrb (talk) 15:16, 6 June 2007 (UTC)

I don't think anyone can hit those limits unless they pack their browser full of dozens of tabs, edit them all and then save them all at the same time. -- (gem / talk) 15:21, 6 June 2007 (UTC)

Ok a question from the technically not so savvy: What does the null in the anon line mean? There is no limit for anonymous accounts? Or a limit of 0 edits? For the general policy, as long as the limit is cleary about anything a human editor could possibly achieve, I see no harm in implementing it. --Xeeron 17:17, 6 June 2007 (UTC)

That's the limit for all of the IP accounts put together. The "IP" one limits each specific anon user. MisterPepe talk 18:12, 6 June 2007 (UTC)

"null" imposes no extra limit for that criteria, and is the default value. Individual users/IPs are still subject to the other criteria. --Rezyk 18:23, 6 June 2007 (UTC)

Yes, we want to keep that line as null. -- (gem / talk) 21:07, 6 June 2007 (UTC)

No complaints so let's put this up for ANet to consider. -- (gem / talk) 21:39, 8 June 2007 (UTC)

I complained. I dislike arbitrary limitations with no benefit. Until this becomes an issue, I'd really rather not make it one. —Tanaric 23:21, 8 June 2007 (UTC)

Sorry, didn't spot it earlier. -- (gem / talk) 09:02, 9 June 2007 (UTC)

ConfirmEdit problem

Inserting a delete tag gives me it :( Fixola please, so I don't have to log in on my dad's pc >.> 72.192.54.23 20:09, 5 June 2007 (UTC)

... Um... you mean the CAPTCHA? All IP users have to fill in the little box at the top to confirm their edits. The way to get rid of it is to make an account... there's nothing to fix. MisterPepe talk 20:40, 5 June 2007 (UTC)

The captcha only triggers on external links, Pepe, not all anon edits.

I'm not sure there's much we can do, 72.192.54.23. You're getting the captcha because the {{delete}} template inserts an external link to point to the history of the page, [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=history}} the page history], which triggers ConfirmEdit. The only option is removing that link from the template, but it's kinda useful, so not sure about it. =\ --Dirigible 20:12, 8 June 2007 (UTC)

Oh. Once again, Dirigible is far more informed than I am. MisterPepe talk 05:32, 9 June 2007 (UTC)

By the way, this was me when I was on my dads pc. BLASTEDT 20:23, 14 June 2007 (UTC)

302 redirects

I was going through my mailbox, and found that old discussion (here) where Rezyk proposed removing hard 302 redirects for everything but "self:"
Basically, this keeps people from being hard-redirected to a different site. Thoughts, and for that matter, how do we do it? =P MisterPepe talk 19:32, 11 July 2007 (UTC)

Changing the value of iw_local for all other hostnames in the interwiki table should do it. In fact, the wrong iw_local value for "self" originally caused those redirects to be soft (see Guild Wars Wiki talk:Game integration#Game integration) -- we just push that same cause+effect to the other hostnames. --Rezyk 21:57, 11 July 2007 (UTC)

This is a sound move. --Karlos 22:44, 15 July 2007 (UTC)

Does anyone disagree with this change? If not, I'll make up a request page and pop it up. MisterPepe talk 06:46, 31 July 2007 (UTC)

Added to community requests. MisterPepe talk 21:54, 23 August 2007 (UTC)

favicon

It's about time it was changed! Old discussion here Talk:Main_Page/February_2007#browser_icon_needed. The lack of transparency is yucky. :( - BeX 06:00, 12 July 2007 (UTC)

The transparent version of the current icon would be great indeed. -- (gem / talk) 07:11, 12 July 2007 (UTC)

Small Project

I have been working on and off in my spare time on a simple project. It can be found here

Basicly I am working on a few templates to drive a Skill Template Code system so we can easily show our favorite builds on our user pages etc.

The problem I have is the Wiki does not let me do anything I like. It is a bit limiting in some ways. So I had to select PHP to build a few functions that would turn a code into the template format code needed... My work is pretty ugly at this time and I am new to the wiki in general, lack of time and all is also a factor.

If I am not able to turn my php functions into a wiki extension' then I will have to use a third party to host the php code to output a format that others can just copy and paste easily from... Chik En 20:41, 12 July 2007 (UTC)

Ok I guess I must be insane with my little project :) because I had zero response on this....Chik En 18:53, 16 July 2007 (UTC)

Try GWW:RFC. --Santax (talk · contribs) 19:17, 16 July 2007 (UTC)

I think first the #Mouse-over skill descriptions project should be implemented first. And how can your project work together with that one. --Jurrit 19:20, 16 July 2007 (UTC)

I am sure the "skill database" template can be updated to output whatever format is needed for anything of this nature. My biggest concern is how do I get the those php functions I have into a wiki extension and in turn get that to call the templates I have created. Chik En 17:45, 17 July 2007 (UTC)

You can remove this section. I am not sure if I am allowed. I have canceled my project after some feedback. Chik En 20:45, 19 July 2007 (UTC)

You can't remove stuff from talk pages ;) except your own talk page. You can archive, but not remove them from view. -- ab.er.rant 02:30, 20 July 2007 (UTC)

I figured that much I had hoped to erase my efforts completely even though version one was working fine but had limits so I tried to fix with version two. But it was not well received so I simply corrected the problem :) and removed the project with some help Chik En 03:50, 20 July 2007 (UTC)

Spam control

Judging by the block log, it may be time to take a look at our antispam tools once again. Several options are available to us at this point, that I can see:

1. ConfirmEdit: We can change $wgCaptchaTriggers['createaccount'] = false; to true, which will trigger a CAPTCHA when an account is registered.

   Con: Forces all new users to deal with a CAPTCHA.

2. ConfirmEdit: We can change $wgGroupPermissions['user']['skipcaptcha'] = true; to false, which will trigger a CAPTCHA whenever a logged in user posts an external link.

   Con: Can get pretty annoying.

3. SpamBlacklist: As Smurf noted last time, these spammers are using legit hosts to redirect to the spam. We could add keywords to block the flavour of spam we've been getting, I think it'd be pretty effective.

   Con: To make this work, we'd have to block links to legit hosts such as [1], [2] or [3], which (probably due to misconfiguration) allow external redirects to be created on their sites from anyone. Not sure if this a sufficiently major issue though, since a user can just avoid turning that URL into a link, and they may be generally rarely used (if at all) on the GWW.

Thoughts on these alternatives? Other possibilities? --Dirigible 03:35, 21 July 2007 (UTC)

Just trash any posts with external links. *cough* Kidding. On a serious note, though, I'm in favor of the first measure and against the second and third - I don't think a single CAPTCHA during registration is an unnecessary hindrance, and it would address most of the problem, while the second and third options have too much of a downside in my view. (Is it possible to allow sysops, or even just bureaucrats, the ability to create user accounts, if for some reason there's a need to allow a user who cannot deal with a CAPTCHA to create an account? (I.e. poor vision etc) (Aiiane - talk - contribs) 03:40, 21 July 2007 (UTC)

In order to fight the spam issue, I think our option is either choice #1 or #2 above. The problem with option 1, to me, is it places a roadblock against becoming a registered member - but I think that's the lesser of the evils from the choices that the spammers have forced us to choose between. --- Barek (talk • contribs) - 03:57, 21 July 2007 (UTC)

I am against 2 and 3. With regards to 1, the con is bigger than it might at first seem, since even minor obstacles might stop new contributers from creating an account, but I guess the pros still outweight the cons. --Xeeron 09:16, 21 July 2007 (UTC)

Just wondering, is there any way to enable a CAPTCHA for people posting external links, who also have < 5 (or some other number) contributions? If not, never mind, but it would stop the spam bots without hindering regular users. If it's not possible, #1 seems the best out of the three. A CAPTCHA at sign up is common now, so I don't think many people would be put off creating an account. -- AT(talk | contribs) 12:14, 21 July 2007 (UTC)

I agree, CAPTCHA @ registering won't be THAT big a trouble, since a lot of people already have to face it when frequenting fora. --  (CoRrRan / talk) 12:19, 21 July 2007 (UTC)

There are accessibility issues with catchpa's for people who rely on screen readers - I wouldn't rule it out altogether, especially if spam becomes a big problem, but I don't think it should be a preferred option at any stage. --NieA7 10:40, 22 July 2007 (UTC)

A CAPTCHA has never caused me to change my mind in creating an account. Other fields like emails and compulsory addresses or phone numbers have. I don't think option 1 has much of a con. -- ab.er.rant 14:05, 22 July 2007 (UTC)

"is there any way to enable a CAPTCHA for people posting external links, who also have < 5 (or some other number) contributions?" Could also convince spambot scripters that they sdhould set their bots to trashing 6+ random articles before posting their spam.Backsword

(Reset indent) The proposal can be found at GWW:TECH/ConfirmEdit/Update, but I haven't added it to the Community Requests yet, giving people some more time to find this thread and reply. To be noted is the fact that in addition to requesting for $wgCaptchaTriggers['createaccount'] to be enabled, the current proposal is also asking for ConfirmEdit to be upgraded to the latest version, which allows the third part of the request to be enabled, $wgCaptchaTriggers['badlogin']. This parameter was added in a later version, after we'd installed ConfirmEdit here. It pops up a CAPTCHA whenever someone tries to login with an incorrect username or password, thus slowing down any password-guessing bots. This was mentioned on the ANet mailing list as a security issue, and it was suggested by them to add it to this request.

Finally, just as a reminder for everyone, we are currently using the basic implementation of ConfirmEdit, which uses a text-based simple math question instead of one of those more popular distorted-image CAPTCHAs; usually what you'd see is something like this, in plain text: 24 - 7 = ____. So, at this point I think our system can be simply bothersome, rather than presenting an accessibility problem for users with screen readers and such. --Dirigible 05:49, 27 July 2007 (UTC)

I fully support the implementation of this feature. --  (CoRrRan / talk) 10:47, 27 July 2007 (UTC)

Are there any objections to this being implemented? Can we migrate this to being an official request? --- Barek (talk • contribs) - 05:23, 31 July 2007 (UTC)

Go for it. -Auron 05:25, 31 July 2007 (UTC)

Support. -- ab.er.rant 05:46, 31 July 2007 (UTC)

I posted a request of Dirigible's talk page, as he's more familiar with the technical side, he can verify that all discussed technical settings are in the proposal. --- Barek (talk • contribs) - 05:48, 31 July 2007 (UTC)

Yep, added it to the community requests section. --Dirigible 05:54, 31 July 2007 (UTC)

Tango Wiki Theme?

When looking through the Tango Desktop Project I stumbled across this. What does everyone think of this? Personally I think that with LordBiro's upcoming profession icons it'd get a nice little theme for the wiki going. Plus it looks nice :P --Santax (talk · contribs) 09:44, 25 July 2007 (UTC)

The bullets look horrible o.O poke | talk 11:22, 25 July 2007 (UTC)

iawtc. :( - BeX 11:25, 25 July 2007 (UTC)

They can be changed remember... that link is just a collection of icons that can be found elsewhere... if need be then other icons from that location can be used, or if necessary new ones created. --Santax (talk · contribs) 15:24, 25 July 2007 (UTC)

If people want more tango icons then that's fine, but that particular theme seems to be badly implemented. The bullets are not from any tango icon I have ever seen (they don't seem to follow the standards) and the icons look poorly scaled :/ unless the screenshot is dodgy! LordBiro 17:41, 25 July 2007 (UTC)

Yeah, the icons do seem badly scaled, but it's not too difficult to find them again and re-scale them properly. The bullet points are unfortunate... I think new ones would have to be made altogether. --Santax (talk · contribs) 07:27, 26 July 2007 (UTC)

BUMP!

Check it. Replaced wiki.png and headbg.jpeg with our current ones, removed wiki-indexed.png and bullet-alt.gif (which seem to be unused, if not they could be restored with the current ones the wiki uses), and restored the olf bullet.gif. The icons seem scaled alright to me, but if not they can be rescaled on the MediaWiki software, where they all exist in SVG format here and here. Any icons that seem inappropriate for their purpose can also be replaced with ones from there. --Santax (talk · contribs) 20:30, 16 August 2007 (UTC)

New request for version upgrade?

Should I make a new request if I want DPL to be upgraded from 1.2.3 to 1.3.x (where x = latest version), or should we include an easier way to request an AddOn version upgrade? See here for my problem case and the response from the developer of DPL. Obviously DPL wasn't working correctly in accordance with MediaWiki standards.

Should I even make the request? I have learned to control the output of the DPL pages much more and I don't need the extra functionality yet. But perhaps with future pages, this flaw in DPL might pose a problem.

Your thoughts? --  (CoRrRan / talk) 21:18, 30 July 2007 (UTC)

I think a new request should not be needed if the update on the feature isn't really big and controversial. And updates that fix anomalies/bugs with the features should definitely not need a new confirmation and consensus, imo. - anja 21:22, 30 July 2007 (UTC)

Had to revert your adding the request to "Community requests", CoRrRan, sorry. The current policy needs the community to express its consensus here before we add it, and two people isn't consensus. We can certainly discuss and add that change regarding updates to the policy, but until it's accepted, we should be doing this the usual way, which means allowing people more time to see this and reply.

For now consider this message a "weak support" from my side. Since we don't urgently need the update now, maybe it's better to wait till a future time when another important update arrives, or when we actually do need this bugfix? We really need to discuss how we're going to handle updates in the policy. With all these extensions + MW, it could easily get out of hand requesting for all of them to be kept upgraded. Do we need something like that? Can the ANet IT guys keep up with those requests? I'm uncertain of what the answers are; maybe we should ask Emily? --Dirigible 07:57, 31 July 2007 (UTC)

I know Dirigible, again my apologies. I do agree that we should nudge Emily onto this discussion (but AFAIK she has this page on watch too). As for the updating of extensions, I guess waiting till a major update is a decent way to go forward, but for this update, I think we should request A.Net to have it installed. After all, this might not be only a problem for the way I did it in the first place. Perhaps when we are making more lists, this "bug" will surface again.

As for the updating of installed extensions: I support a modification of the policy to only allow requests for update of existing addons when a bugfix is required or a major update (1.x to 1.(x+1) update) is released. --  (CoRrRan / talk) 11:01, 31 July 2007 (UTC)

Just wanted to say that I'm waiting for the update ;) (two people + one). A fix of this would really help new users with making DPL lists as everybody who will try to make a dpl list will get this problem.. poke | talk 11:55, 31 July 2007 (UTC)

Hi guys...I was asked to pop over and give my thoughts. Here they are!

• I think that it may realistically be impossible for IT to keep up with new versions of the installed extensions, especially since they have a LOT on their plate. That's why I like to try to pass things on to them as it's requested, because it's a lot easier to remember something when it's in your inbox. With that being said, it's also a bit difficult for me to personally keep track of all of the project pages for these features, as well as the stability of the versions as they are released. What I'd recommend for this situation would be for you guys to just casually keep an eye out for new upgrades and fire me a note on my talk page (or even here...I have this page watched too) and I'll pass it along to IT. Of course, I'd advise that the version be considered stable, so try to avoid posting updates that are in alpha states (I'm thinking that we may want to avoid accidentally blowing things up :))

• I also think that you guys may want to discuss an addendum or addition to the RTA policy that deals with add-on upgrades. In my opinion, I'd imagine that if an add-on has been discussed with the community to the point that it gets approved and installed, that it may be a bit redundant to bring up upgrading that extension unless it's an upgrade that introduces huge changes or alters the original purpose of the add-on. If it's standard bug fix/streamlining functionality updating, it would seem that the community would be alright with installing this stuff automatically as long as there's a note as to the version/date of upgrade available on the extension's page.

These are just my thoughts and suggestions, though. In general, it's probably more efficient for me to be the tech go-between with IT and the requests. That way, requests aren't missed when things go crazy over here :) -- Emily Diehl (talk) 01:44, 2 August 2007 (UTC)

(Reset indent) I've added the DPL upgrade request to this page again. It seems to me the easiest way to try to get it rolling. --  (CoRrRan / talk) 16:52, 21 August 2007 (UTC)

Improved Recent Changes GWW:RC

"WoWWiki:RC

This is a Recent Changes list that filters out all users in WoWWiki:RC/Skip, and attempts to alert on various things that could be deemed vandalism or inappropriate content. The script is available in User:Mikk/Scripts#RC bot.

This list is updated hourly."

I think it would help a lot in monitoring the pages against vandalism, spam, etc. Please post your ideas & comments! --Phoenix File:Phoenix-sig.png 04:59, 15 September 2007 (UTC)

"This list is updated hourly." - This is one of the greatest arguments not to implement such a thing. A hourly updated list cannot help against vandalism, it's more useful to see all edits (by everyone) whenever you want. poke | talk 14:07, 15 September 2007 (UTC)

The way we could use this is to add a list of well know users to list and protect it from all edits. This way people could ignore all edits from the core editors when looking for vandalism. The problem then would be to decide which users are added to the list.

Even then I wouldn't use this myself, I like to see all edits. -- (gem / talk) 14:12, 15 September 2007 (UTC)

== Moving pages == (CoRrRan / talk) 11:39, 15 September 2007 (UTC)

This is an internal problem. It seems that mediawiki uses stripslashes for page titles which removes a single backslash. You can manually avoid this by using a double backslash "\\". poke | talk 14:02, 15 September 2007 (UTC)

That doesn't help, it took me to a page named with two \\ instead of the one named with one \. - anja 14:17, 15 September 2007 (UTC)

Hm, I just noticed that it seems to work here correctly: \Example1, Example\Two, \Example\Three. poke | talk 14:31, 15 September 2007 (UTC)

Try now, now that that page exists. It's messing now :P - anja 14:33, 15 September 2007 (UTC)

Hm, ok. When used with get-parameters it works: click. When using the mod_rewrite syntax, it works only with double \\ click. So this could really be fixed by modifiying the .htaccess.. poke | talk 14:47, 15 September 2007 (UTC)

Keeping problematic characters out of article names

Is there a MediaWiki extention which can prevent problematic characters such as backslashes from being used in article names? Yesterday I accidentally used a backslash rather than a forward slash when moving a page to a subpage, and it was a huge nuisance to clean up. -- Gordon Ecker 01:10, 21 September 2007 (UTC)

I don't think it would be possible (it would be also rather negative for non-Latin Guild names..). See the section above for the backslash problem poke | talk 05:26, 21 September 2007 (UTC)

So what kind of clean-up do you need to do? It might be good to right it down somewhere. -- ab.er.rant 06:00, 21 September 2007 (UTC)

What about requiring confirmation before something is created at or moved to a name with a character which MediaWiki has trouble parsing? -- Gordon Ecker 08:54, 21 September 2007 (UTC)

I meant what sort of problems you had in getting rid of it... in case I ever get into the same situation :P -- ab.er.rant 09:14, 21 September 2007 (UTC)

There is no problem with mediawiki - you can access every page by using the title link (index.php?title=XY). The problem is that the backslash needs to be escaped when using the /wiki/XY link. So instead of X\Y you have to type X\\Y - but that is not a mediawiki problem, it's a server-side problem. Which can be fixed in the .htaccess poke | talk 09:54, 21 September 2007 (UTC)

Aberrant, see the three links in the above section? The Example1 link is blue, yet when you click on it you get to a nonexistant page. This is mainly the problem, they are hard to reach and you have to use special methods to access them and delete them, as poke explains. - anja 10:34, 21 September 2007 (UTC)

Thanks, I'll be sure to remember this. -- ab.er.rant 13:49, 21 September 2007 (UTC)

Reducing the job que run rate

I have created a draft here as a result of the discussion, here. --Lemming 17:18, 25 September 2007 (UTC)

Support. --Dirigible 17:23, 25 September 2007 (UTC)

Considering the volume of our traffic, I'd be happier with either reducing the job rate to something like 0.001 or disabling it entirely, and running these sorts of updates nightly via a cronjob. This is a good step forward though, and I certainly don't oppose. —Tanaric 19:12, 25 September 2007 (UTC)

Can someone explain to the wiki technically challenged what the difference between 0.05; 0.001 and disabling it is? Mainly what is the disadvantage of lowering the number and what happens if we disable it? --Xeeron 19:16, 25 September 2007 (UTC)

The lower that number is, the longer it will take for the pages to be updated after a template change (e.g. all NPC articles after a change to {{NPC infobox}}). A nightly cronjob would mean that those changes would only be updated once a day, when the server-side OS runs the appropriate MediaWiki maintenance script. I think that may be overkill though. --Dirigible 19:21, 25 September 2007 (UTC)

I did some experiments on my own wiki and it appears a job rate of 1 actually runs at about 5 per refresh. Anyway, what would be useful is the approximate number of hits/requests the site gets per minute or even second. I think a nightly cronjob would be hard to define, when is the night in a worldwide used website anyway? You could put it at the most "offpeak" time, but if it at a suitably low level I imagine it would not impact on the normal running of the wiki. --Lemming 19:26, 25 September 2007 (UTC)

Agreed. I don't know the numbers either, and just wanted to ensure we put a little thought into choosing said number rather than just picking a cool fraction. :) Perhaps we can ask the tech team to choose a lower number themselves? They have data we don't. —Tanaric 19:29, 25 September 2007 (UTC)

I like that idea, probably the most sensible option. --Dirigible 19:31, 25 September 2007 (UTC)

According to this, this does not help with the problem. When changing a template, all pages which use that template have to be flagged as uncached, so they will be generated again when someone accesses them.

When I understand the Job queue correct, it only does the lists like "Whatlinkshere" and "Templates used" etc. poke | talk 19:37, 25 September 2007 (UTC)

Are you sure this wouldn't help? In the section "Updating links tables when a template changes" it says "MediaWiki 1.6 adds a job to the job queue for each article using the template. Each job is a command to read an article, expand any templates, and update the link table accordingly." And judging from the following section, template changes both invalidate the cache and the links tables, which would result in new job items. Am I missing something? --Dirigible 19:52, 25 September 2007 (UTC)

No, you're not, Dir. poke, while you're correct that the job queue is for link tables, modifying a widely used template invalidates a LOT of link tables and thus creates a lot of jobs to fix each of them - the jobs aren't to update each page. (Aiiane - talk - contribs) 20:27, 25 September 2007 (UTC)

But it's initially =1, so there should be only one job per request? That's not that much, I think... And the great lags only appear in ~1 minute after the change, so it cannot really be the job queue... poke | talk 20:44, 25 September 2007 (UTC)

Poke, the problem is that when you consider how many hits the wiki gets per minute, and then realize that 1 job is run for each hit, not per any given period of time. Thus, the job limit is really just a multiplier - it takes hits/minute and converts it into jobs/minute. Unlike serving pages (which in most cases, is just retrieving it from cache), each job takes multiple database interactions to run. This means that the capacity required to run jobs at the same rate that pages are served is much greater than the capacity required to simply serve pages at that rate.

Again, the key element is that the job rate is not linked to time, and thus a value of 1 is actually extremely high for servers that have a high number of requests per minute. (Aiiane - talk - contribs) 23:14, 25 September 2007 (UTC)

Regarding templates effecting this - I tested this on my own wiki, making a tiny font edit to a template created many jobs in the job queue. --Lemming 23:26, 25 September 2007 (UTC)

I just realised if you refresh the Special:Statistics you can get a rough idea of page views/hits, and there was just under 1000 in the minute I tested, if that helps at all :) --Lemming 00:01, 26 September 2007 (UTC)

current draft

Does anyone have a problem with this final draft before I add it to the list? --Lemming 16:34, 27 September 2007 (UTC)

Not per se, but I'm not sure that 0.01 is the best value for it. I think it's arbitrarily chosen, right? Would there be a way for A.Net to calculate the best value for this, based on the amount of hits that are generated each minute? I.e. leave it open for them? --  (CoRrRan / talk) 16:49, 27 September 2007 (UTC)

I have suggested that in the draft, and it is not entirely random it is based upon the approximation of the number of hits per minute based on the statistics page, page views. --Lemming 16:54, 27 September 2007 (UTC)

If this solution will fix the lag, you should not talk so much about it but change it immediately. So in this case, put the draft on the main page. --Jurrit 11:55, 28 September 2007 (UTC)

Well there have been no objections per-se so far so I will put it on the main page. --Lemming 18:33, 28 September 2007 (UTC)

Adjustments?

I noticed that most jobs are really slowly removed. One evening when I worked on some templates, I needed the "Whatlinkshere" feature to see what pages use the template. When Aiiane then unprotected the Skill progression template there were ~1400 jobs (= 1,400,000 page views). Even now there are 166 jobs open; I think 0.01 is a bit too low, so I would like to increase it to 0.1 instead. poke | talk 20:34, 7 October 2007 (UTC)

Support, it seems that the page views on this site aren't enough to support a once every 100 views for a job to be processed. I think 1 in 10 would be a good 2nd 'test' value. --  (CoRrRan / talk) 08:19, 8 October 2007 (UTC)

The best would be if someone from ANet could check the pageviews per minute and calculate a good number. Btw. I would like to see a Job queue level in MediaWiki as jobs/minutes instead of jobs/pageviews in future.. poke | talk 09:12, 8 October 2007 (UTC)

In the proposal it did suggest they set it as a suitable number, whether they did that or used 0.01 is hard to tell really. I think factoring it up by 10 is a big step, I would suggest a factor of 5 would be more suitable. You can roughly work out the page views per minute manually if you refresh the Special:Statistics once a minute. --Lemming 10:56, 8 October 2007 (UTC)

Some things...

First, I noticed that we have DPL 1.3.3 installed; The actual version is 1.4.4 which contains some bugfixes and new features. I think we could request a new update.
Because of those Updates and Emily's comment above, I think we should add something that updates do not need to be discussed.

Another thing I would like to discuss is the VariablesExtension extension. I find this extension really useful as it would allow us to make complex templates as Template:Weapon infobox more cleaner and probably a lot faster as it would allow us to set variables once instead of using a lot of switches for the given parameters. poke | talk 20:28, 29 September 2007 (UTC)

Support for both issues, I like those variables. --  (CoRrRan / talk) 23:22, 29 September 2007 (UTC)

Any more comments? poke | talk 20:28, 7 October 2007 (UTC)

I support this request. A few days ago, i wanted to use a feature for a polymock table which is broken in dpl 1.3.3 and was repared in 1.3.7 (this features enables tables to be sorted by sortkey instead of page title). The current stable version is now 1.4.6. I think we should ask for this one to be put in the wiki. Chriskang 22:29, 7 October 2007 (UTC)

I don't think you'll get many more comments because everyone who has commented already is part of that tiny pool of people that understands and uses DPL. :P I think that any update that makes things easier and tidier for you guys is a good thing, so support from me. - BeX 04:40, 8 October 2007 (UTC)

Yeah, Bex. But what I also want is some comments on that update process in general. It's a bit annoying to have to get to a consensus each time, we want to update something; I would like to have a automatic consensus on all following updates except someone opposes. This would speed up those update processes. poke | talk 05:20, 8 October 2007 (UTC)

The only issue I could see with updates is when a bug is introduced in a new version. If that bug causes more problems than other parts of the update helps, is something we should talk about first. But if there is no such issue, then I see no reason not to update directly. Backsword 05:46, 8 October 2007 (UTC)

The trouble with that is, is that those bugs usually only get known once the update has taken place. However, I do believe I've read on the website for DPL that sometimes there is a change in implementation of DPL, which would require a slight change in syntax. I guess those things might be a bit more a concern to us, but that won't be too difficult to solve. And I'd like for updates to be automatically accepted, without the need for consensus. --  (CoRrRan / talk) 08:15, 8 October 2007 (UTC)

You can never be sure that there is no bug (and there will be never a software without any bug). Also it's just that I don't want to ask here everytime for an update but just add a request for an update without having to discuss it again and again.

As far as I can tell, the most installations of extensions for MediaWiki are quite easy (copying a new file and adding some lines to one file); there are not that much things you have to change (in contrast to other online software like BulletinBoards), at least not for extensions (updating the whole MediaWiki software is probably more work). poke | talk 09:10, 8 October 2007 (UTC)

Well, CoRrRan, if the issue is unknown, it's rather unlikely we'd debate it anyway, no? Backsword 06:12, 9 October 2007 (UTC)

Removing Guild: from Wanted pages

Currently Special:Wantedpages is filled with missing Guild namespace pages. This reduces the usefulness of the page as gaps in the guild name space aren't something a general wiki editor is able to do something about. I propose making a change to the php script which generates the page so it no longer display wanted pages from the Guild namespace.

I forsee the fix borrowing extensively from method #2 step 3 discussed here. This is a simple change to the sql which selects the pages to list.

This is a minor change with any possible problems limited to the wanted page link. I highly doubt there are any performance or security implications for this change. While I do not think that this page is especially widely used in this wiki I still think there is some value restoring its usefulness. --Aspectacle 04:22, 24 October 2007 (UTC)

It is not widely used because of it's uselessness imo. The guild pages are making tiresome to use. If this is possible, I'd love it. - anja 07:21, 24 October 2007 (UTC)

I support this change. Wantedpages is useless in its current state. - BeX 09:26, 24 October 2007 (UTC)

Yah. -- (gem / talk) 12:07, 24 October 2007 (UTC)

Full support :) poke | talk 14:40, 24 October 2007 (UTC)

Cry not for special:wantedpages. Discover Category:Stubs and Special:Wantedcategories instead. Backsword 05:09, 25 October 2007 (UTC)

*sobs* Wanted pages! *sniff*
I'm not a categorization fan. Stubs sure, I could stand to remove a few of those, but I've honed in on this issue and decided I want it fixed. So there. :P --Aspectacle 05:42, 25 October 2007 (UTC)

Linebreak

I saw on some other wikis they added something custom for a wikicode linebreak. Is that possible here? It's annoying having to br or use a bullet or some other substitute. - BeX 02:40, 25 October 2007 (UTC)

What do you mean BeX, a template? --Aspectacle 05:44, 25 October 2007 (UTC)

No, it was added into configuration I think. One of the sites I looked at had instructions on how to add it to your own wiki. - BeX 07:49, 25 October 2007 (UTC)

Page Needs Archiving

Page is 86kb and needs archiving, can someone who is familiar with the issues on the page please archive things that have been resolved Fall 07:41, 13 November 2007 (UTC)

Math

→ moved from User talk:Ab.er.rant

I noticed all the math formulas on wikipedia are done through the <math> tag. I looked into it and found it it's TeX tags. I tried that on this wiki and found it doesn't work here. Is there anyway to get this working? Lightblade 18:51, 15 November 2007 (UTC)

We would need a extension for the mediaWiki software to allow Maths, you can put up your request at GWW:TECH if you want. poke | talk 21:17, 15 November 2007 (UTC)

We don't need no stinking mathematics! Most of us wants gramer n speeling -elviondale (tahlk) 23:40, 15 November 2007 (UTC)

What sort of math formulas for we need? -- ab.er.rant 01:22, 16 November 2007 (UTC)

No, elviondale, we's needs an edumacation *smiles crooked smile with chipped teeth*. And, to aberrant, I would guess formulas for calculation of level, critical hits, damage from weapons, and with modifiers. Especially the level formulas before GW2, with 100 levels. Though it looks respectable already. Calor - talk 01:27, 16 November 2007 (UTC)

Yes, what he said. Lightblade 04:29, 16 November 2007 (UTC)

We don't have that many formulas do we? And no really complex formulas beyond simple mathematics. Seems to me the current ones are pretty readable. Also, do users even bother about the formulas? GW is (thankfully) a game that's much less concerned about the numbers. Either your weapons and stats are maxed or they're not. It's not like other MMOs which has players crazily (in a nice way) analyzing every single calculation to maximize their character's damage output. Either that... or I'm just ignorant of it, since I play infrequently these days :) anyhowal, I'm not really against it, I'm just wondering how much we'd be using it. -- ab.er.rant 06:39, 16 November 2007 (UTC)

Aye, they are readable, and I'm fine with them the way they are. But there's probably some neat freak nerd out there who wants a formula for everything properly positioned on every page. Calor - talk 14:42, 16 November 2007 (UTC)

Install or not, I think I have another way of doing this. I can enter TeX codes on wikipedia, get a preview, and get a screenshot, then cut the formula out and upload to here as an image. The thing is...how should I name them? Lightblade 20:29, 16 November 2007 (UTC)

Having it installed is easier, due to page layout with text compared to images. If you did, it would probably be Image:(article name) formula.jpg. Calor - talk 20:37, 16 November 2007 (UTC)

I think we shouldn't install every unnecessary extension out there just because 'someone might like them'. It's unnecessary work load for the IT team and doesn't help anyone. -- (gem / talk) 00:40, 17 November 2007 (UTC)

Well, it's also unnescessary work load for me too...to promote their product. Making the wiki better only benefits Anet, not me. Lightblade 23:23, 17 November 2007 (UTC)

Err what? Any help on the wiki helps everyone. The math functions helps no one. I don't see your point. -- (gem / talk) 23:25, 17 November 2007 (UTC)

As far as I know, MathML is rendered by the browser, so it won't be displayed on all browsers (especially older ones). But images always display in the same way - I prefer images for a wiki which shall reach many different people.. poke | talk 23:33, 17 November 2007 (UTC)

I think if you weigh up the work/benefit ratio for this wiki then using screenshots is easier for the occasions when formulae are required. --Lemming 23:47, 17 November 2007 (UTC)

Character Escapes

See Guild Wars Wiki:Requests for technical administration/Character Escapes.
The reason is the Weapon stats template in which I used the Variables Extension the first time. The variable definitions are always executed without having the possibility to assign conditional values - at least not without having to use one conditional for each variable, which can be very slowing.
Everything else is explained on the request page. Please answer fast as I want to have this implemented soon. poke | talk 15:02, 23 November 2007 (UTC)

It looks pretty interesting, but I'm afraid of the pitfalls to it. It also kind of reminds me of C++ in a way. — ク Eloc 貢 19:59, 23 November 2007 (UTC)

The pitfalls I mentioned are probably weaker than I wrote. For example if I write something like \n than it will be - after installation - a linebreak instead of a \n.. Same goes for the other 5 (?) escape sequences. The only thing that can happen is that an article which used one of these escape sequences displays something other instead :P poke | talk 20:08, 23 November 2007 (UTC)

Is there a way to get around those codes? Like it reminds me of C++ as something like / is a vital command, but / is simply for typing /. Get what I mean? — ク Eloc 貢 20:17, 23 November 2007 (UTC)

Not really :P But as I said, we could make the combination harder so that the chance is lower that an article will use one of the escape sequences. For example \\n instead of \n.. poke | talk 20:22, 23 November 2007 (UTC)

Would <nowiki> work on those codes? — ク Eloc 貢 04:08, 28 November 2007 (UTC)

Time zone

Type

Change of time zone.

Reason

Arena Net is an American company located in the Pacific Time Zone, so why go we have a British time zone for an American company's site? I propose we change the time zone of this site to the Pacific Time Zone

Links

W:Pacific Time Zone — ク Eloc 貢 03:16, 28 November 2007 (UTC)

This wiki is about Guild Wars, not ArenaNet. It doesn't matter where their office is located. UTC is a standard reference. -- ab.er.rant 03:27, 28 November 2007 (UTC)

But why is it the standard reference? Also, all the times ingame are used in Pacific Time, so why not the Official Wiki too? — ク Eloc 貢 04:07, 28 November 2007 (UTC)

UTC is good for non-Americans. I know how many hours different I am to UTC, but when I think of Pacific Time, I go, "Uh, well, my ex-girlfriend in Arizona used to be like, five to seven hours ahead of me the day earlier, depending on Daylight Saving, maybe subtract an hour for the adjacent state, and... forget it—I'll look up one of those time zone sites." I need to go check out one of those time zone sites every time I need to know what a time in the USA equals. The world does not revolve around the west coast of the United States. -- 208.100.56.34 04:34, 28 November 2007 (UTC)

Correct. It revolves around the east coast. -elviondale (tahlk) 04:58, 28 November 2007 (UTC)

Lol! -- ab.er.rant 06:03, 28 November 2007 (UTC)

Agree with the previous statement. Same as with ye olde GMT, UTC is a standard that helps every user to calculate the time only knowing it's own, and without having to worry about daylight save time. If you start using PST, you need to make sure PST is used always, including while on PDT (which will not be always the case).--Fighterdoken 04:56, 28 November 2007 (UTC)

See W:Coordinated Universal Time. It's just an internationally accepted successor to the previous internationally accepted GMT :) The anon is right. A lot of countries are fully in one single time zone, so the only other reference we use is UTC. And I can never get my head around the daylight time savings thingy :D -- ab.er.rant 06:03, 28 November 2007 (UTC)

Indeed UTC is the way to go. Personnally, I would not mind going back to that strange time zone somewhere in the pacific we once used (was that on GW??) ;-) --Xeeron 11:44, 28 November 2007 (UTC)

I have to agree it makes way more sense to use UTC as almost everyone knows what their timezone is in relation to that. If you asked someone in Australia what their timezone was in relation to PST they would probably have to double check. (that and GMT = UTC most of the time :D) --Lemming 17:30, 28 November 2007 (UTC)

I thought GMT and UTC were always the same, just that BST is usually GMT unless its BDT. - BeX 08:56, 29 November 2007 (UTC)

Sorry that me mis-stating what I mean, I basically always think I am in GMT even when we are in BDT. lol, This is why we need UTC!!! --Lemming 12:19, 29 November 2007 (UTC)

As long as you don't need times which are exact to the second, GMT and UTC are identical. poke | talk 13:45, 29 November 2007 (UTC)