Guild Wars Wiki talk:Requests for technical administration/Resolved issues

Prehistory

I think that this page title is too specific. Wouldn't a page where general technical queries and suggestions could be made be more appropriate? For example, installing ImageMagick and enabling user stylesheets. As discussed on Talk:Main Page there are a number of technical queries that this heading would not cover. LordBiro 16:30, 14 February 2007 (PST)

Great point -- how about Project:Requests for technical administration? If you agree, or have a better suggestion, feel free to move. —Tanaric 16:31, 14 February 2007 (PST)

It might be a little long, but I like it. I will move now. LordBiro 16:34, 14 February 2007 (PST)

Any standards here

Are users allowed to support/oppose if they obviously do not understand what the request is about? I am talking about LifeInfusion's recent oppose vote. S 18:14, 14 February 2007 (PST)

I doubt there is any good way to deny that right. --Rezyk 18:28, 14 February 2007 (PST)

We're not requiring a consensus before the request gets to ArenaNet, correct? --Rezyk 18:28, 14 February 2007 (PST)

The text of the proposal uses the magic word "vetting", which I understand as equivalent to "wallowing in mediocrity". I would have implemented it much differently, with no support/oppose voting at all. I am more than a bit irritated at our apparent regression towards evil. S 18:33, 14 February 2007 (PST)

I just hope it doesn't mean "3 more support than oppose". ^^ Also, we are still in proposal mode, so no fair getting too irritated yet.. --Rezyk 18:47, 14 February 2007 (PST)

Why are we voting on these per se, exactly? I'd much rather just have users add to the actual pro/con points, I think. — 130.58 (talk) 18:42, 14 February 2007 (PST)

Agreed. Not sure what the purpose of voting is here. --Dirigible 18:44, 14 February 2007 (PST)

Also agreed. If any sort of voting is needed, it can be in the form of informal straw polling in the talk pages. S 18:47, 14 February 2007 (PST)

Firstly, voting needs to go, consensus will work fine for this. Second, shouldn't we have a seperate policy page from an actual request page? Just seems weird to me. Maybe I'm naive. I liked how GuildWiki had specific pages for "Request Help" which used NEWSECTIONLINK. I would like to see a similar page for requests (which would be separate from Guild_Wars_Wiki:Requests_for_technical_administration). Oblio 11:35, 15 February 2007 (PST)

(Reset indent)

Before you go off about me, I'd like to point out that I did list my reasoning for my oppose vote. Do note that I didn't dismiss the idea of javascripts, I just felt that a more strict authorization procedure is needed. CSS doesn't have as much abuse potential so that's why I didn't comment on that. I don't see how the default wiki template is lacking in the JS department...if anything admins can just add the necessary JS to the default monobook.js

Prior to my oppose vote, nobody brought up the malicious scripts issue. (It was listed, but nobody brought it up). The argument was along the lines of "they are protected so there's no reason not to have it". In the very description itself, it is stated that cross-site scripting may be an issue. Speaking of which, my concerns aren't that far-fetched... just look at Mediawiki's release notes (http://sourceforge.net/project/shownotes.php?release_id=307067), (http://www.mediawiki.org/wiki/Manual:%24wgAllowUserJs). This argument is nullified if MediaWiki is consistently upgraded (hence why I retracted my oppose vote).

It is also assumed that users have a technical base, but that's a large generalization. Seemingly innocuous users who just copy-paste code into their "monobook.js" configuration files will cause problems. I don't know how this will affect the wiki, but that's extra burdens for no reason when any necessary JS can be added in the default monobook.js.

That brings me to the last point I'd like to make. If javascript is introduced just so that people can play with formatting and hotkeys at the expense of lowering security, it is something to be reconsidered. --Life Infusion

Recommendations for simplification of process

This article name was originally "Requests for MediaWiki extensions", and with that heading the procedures outlined make a little more sense. But I believe that we need a place where we can do the following:

• Ask general questions about server configuration
• Propose suggestions to improve the performance, usability or security of the wiki
• Suggest the installation of applications, i.e. ImageMagick, various caching proxies, etc. that work well with MediaWiki
• Ask for extensions to be installed

I think this page could serve well as a means for doing all these things, and I propose the following procedure:

1. A user has a technical question or proposal
2. The user posts the question on this talk page, i.e. Guild Wars Wiki talk:Requests for technical administration
3. The question is checked by other users
4. If the question has been asked before
   1. The user is shown the "answered questions" article
   2. The question is removed from the talk page
5. If the question has an apparent answer that does not need escalating to ArenaNet
   1. The users answer the question
6. Otherwise the question is added to the article
7. ArenaNet technical team check the page regularly and answer questions
8. After a question is answered it is moved to the "answered questions" article.

The "support" heading might give an idea of consensus behind a particular suggestion, but I'm not keen on it. I can understand why it's there, since it shows that this isn't just one person wanting an extension installed so they can put an image map on their user page, or something like that. But I think there must be a better way of doing this. Can we not just accept that once a question or suggestion has been discussed on the talk page then it's open to be submitted to the main article, regardless of the level of support it receives? LordBiro 02:02, 15 February 2007 (PST)

One question - how is the user supposed to draw attention to the question on their own talk page? --NieA7 02:14, 15 February 2007 (PST)

This talk page, not his talk page :P LordBiro 02:16, 15 February 2007 (PST)

I clearly have a blindness for T's this morning x.x Carry on... --NieA7 02:18, 15 February 2007 (PST)

You wont be able to dodge the question of "support", LordBiro. What if User XYZ requests the l33t upgrade ABC which would make his talk page play sounds but create a big drain on the servers. Everyone but XYZ hates it. Would you still place it on this page (when ANet thinks that this page contains stuff that the wiki wants them to do)? --Xeeron 16:07, 15 February 2007 (PST)

Per the policy on page. The request is listed on this talk page and if there's enough support will be moved to the main page (emphasis mine.). So if plugin ABC gets little to no support it doesn't show up on the page and consequently not be a request to ANet. Lojiin 16:10, 15 February 2007 (PST)

Errr, well yes ... but ::points up to LordBiro's post:: =) --Xeeron 16:49, 15 February 2007 (PST)

I think Xeeron was saying, if "support" is not a requirement for the request to be moved from this talk page to the article proper, then what's to stop anyone from posting ridiculous requests? And that's fair enough, but what about requests that are too technical to gain widespread understanding and therefore support, and at the same time are beneficial to the wiki? And what's to stop popular but poor requests being made if support plays a major role in deciding which requests make it to the main article? LordBiro 08:49, 16 February 2007 (PST)

In the first case those who see the benefit would have to try to point out and explain the benefits of the request to the non-technical people. Similar, in the second case, those who notice the request is poor have to explain why it is poor to those who feel it is good (maybe out of technical ignorance). If said people can make convincing agruements on the talk page, they should be able to win the rest of the community over. --Xeeron 09:35, 16 February 2007 (PST)

Talk page move

Seems to complicate stuff a bit for me. The talk page will now be a mixture of requests (like above) and discussion (like this), making it harder to find the requests. It would be better to make to different pages (with respective talk pages). That way stuff that ANet should do is speparated from stuff that is looked at and proposals are separated from discussions. --Xeeron 16:07, 15 February 2007 (PST)

I agree ... although I'm not sure what to name it. We have this Guild Wars Wiki:Requests for technical administration, would the second page then be Guild Wars Wiki:Proposals for technical administration? --- Barek (talk • contribs) - 16:16, 15 February 2007 (PST)

Guild Wars Wiki:Requests for technical administration/Proposals? --NieA7 00:59, 16 February 2007 (PST)

The current layout makes it very hard to actually ask questions about proposals. — 130.58 (talk) 08:22, 16 February 2007 (PST)

Well this wasn't really how I envisioned this page working. I thought the requests made on the talk page would be more informal and lead to discussion. Then, if consensus looked like the request was worthwhile, it would be posted as a formal request. LordBiro 08:45, 16 February 2007 (PST)

Please, if you know how to improve the process, implement your ideas instead of waiting for others to divine what you mean. S 08:59, 16 February 2007 (PST)

You're right, I should have, but I often like to see how things go before making changes. LordBiro 10:25, 16 February 2007 (PST)

Couldn't there be a separate page for each request, in..say... a category:technical-request or something... then people could discuss each page and when accepted it gets moved to a different category? Vlad 09:02, 16 February 2007 (PST)

I moved each proposal to a subpage of this page. Talk plus straw poll are on the sub-page's talk page. Only those requests that gain community support should be moved to this page, which is also the only one Anet needs to bother looking at (of course they are free to look where ever they want if they have the time, but this is the only one they need to look at). --Xeeron 09:35, 16 February 2007 (PST)

Was there any need to gum up the works on proposals that have tremendous support already? Why were they all moved out of the page? S 10:46, 16 February 2007 (PST)

I'm not 100% sure why you made the change to subpages there, Xeeron, but I have not undone it.

I have made a couple of changes, most notably the way in which requests are submitted. I don't think we need to have the strict requirements on a submission until that request is ready to be shown to ArenaNet. I think it is perfectly reasonable to be able to simply post "ImageMagick, should we have it?" and discuss it. Once consensus on the topic is reached, then we create a formal request, with all the information ArenaNet might need.

I don't think it makes a great deal of sense to have a separate article for each discussion. I know I personally just want to come to this talk page and discuss those requests that are currently of interest. Fracturing the discussion just makes that more difficult. If you think it makes sense to have a subpage for every formal request, than I would be fine with that, as long as the discussion is here! :) LordBiro 10:54, 16 February 2007 (PST)

LordBiro: No idea really, Vlad suggested it. Personally I dont care whether it is all on one page or different subpages. However, the less discussion is expected for each individual topic, the more sense one page makes instead of several pages. If you dislike the split, feel free to collapse all subpages into one page.

S: I only wanted to make formating changes. Whether individual requests already have consensus, I did not look at. --Xeeron 11:03, 16 February 2007 (PST)

Dynamic list

Can someone look into the dynamic list plug-in? IIRC, Gravewit tried to implement it on GuildWiki but for obscure reasons it never worked. I lack the knowledge to write up a nice request will pitfalls and all that stuff filled in. The reason I'm interested in this plug-in is it will allow lists such as "skills that are in the Monk profession, Nightfall campaign, and is an enchantment spell" be created without us having to put all the skills matching that criteria into a "Core Monk Enchantment Spells" category. -PanSola 18:13, 24 February 2007 (EST)

A nice request isn't needed at the first stage, just a discussion as to whether the community thinks it should be implemented. Do you have a URL for it? LordBiro 18:30, 24 February 2007 (EST)

[1]. I just noticed it doesn't output results alphabetically, though its discussion page mentions a 5-line patch that adds this feature. -PanSola 19:13, 24 February 2007 (EST)

Bump. Anyone wanna talk about it? Whether it be for, against, or questions? -PanSola 15:31, 27 February 2007 (EST)

Did you have anything particular in mind for it? Seems nice and all but I can't think of a use for us off the top of my head. --NieA7 15:39, 27 February 2007 (EST)

I'm guessing here ... but my assumption from PanSola's initial post is mainly for lists of skills. From my understanding (I haven't seen a real world example, only the descriptions), using a dynamic list list you could have a link that is structured to show a list of all skills that are in the "Prophecies skills" category, in the "Uses Adrenaline" category, and in the "Warrior skills" category. The dynamic list would generate a list (from what I see, the list would look similar to a category listing) that shows only those skills that fit all three criteria. That way the lists of skills don't need to be manually maintained anytime new skills are added, or existing skills are changed - once the skill's category is defined, the dynamic lists would show them.

But, like I said, I haven't seen any real-world examples of dynamic lists so I may be making incorrect assumptions. I wouldn't mind seeing a link to one on Wikipedia, just as an example of the possibilities. --- Barek (talk • contribs) - 16:05, 27 February 2007 (EST)

If I understood correctly how this works and if it really works, I'm all for it. I will delve into the documentation later. -- (gem / talk) 16:07, 27 February 2007 (EST)

I only skimmed the description but all the examples were lists of links - not useless, but no replacement for the skill quick references we know and love. Can any formatting be used with this plug in? --NieA7 17:55, 27 February 2007 (EST)

I'm for some DynamicPageList plug-in -- I found it to be one of the more useful ones when experimenting with new things for the wiki. One thing is the potential for auto-generated intersection lists like what PanSola described (which also lets us push for simpler categories, something I really want). It would also be nice for any category maintenance -- for example, how about automatically showing the items that have been tagged for deletion for the longest amount of time? Or if/when a builds system gets hammered out, we can automatically list the newest builds in any build category, instead of relying on recent changes. Stuff like that.

However, one reason I have for not pushing DynamicPageList yet is to see if it's more worthwhile to just go for DynamicPageList2 instead. It has less limitations than DPL -- note that DPL can't do a union of categories (this is the main obstacle I had when implementing generated lists like "Core Monk Enchantment Spells"...how do you get the Monk category factor if it's split up into the attribute subcategories?). Unfortunately, DPL2 also has disadvantages compared to DPL. --Rezyk 16:42, 27 February 2007 (EST)

I could be wrong, but I did try to implement this into my blogwiki...I might have been using an older version, but it didn't update the list unless you re-edited the page.

Informing ANet

A question: Has anyone informed ANet about this page? Just to make sure that we not all go on thinking someone else did. --Xeeron 05:56, 27 February 2007 (EST)

Gaile and Emily have been informed. -- (gem / talk) 05:59, 27 February 2007 (EST)

I've updated the status of these requests. At this point, three are pending install and one is still under discussion. I'll be sure to update you all when the pending features are installed, and when a decision has been made about the final item. --Emily Diehl 14:35, 27 February 2007 (EST)

Thank you! The ParserFunctions will allow us to proceed with a large amount of formatting and template work that has been on hold. I'm hoping you'll support the other implementation as well; I would love to see CSS (I'm indifferent on JS myself), but will wait to see what decision is reached on those. --- Barek (talk • contribs) - 14:38, 27 February 2007 (EST)

Making this policy

This seems to be taken as working by almost everyone already. Unless there is quick dissent, I'll move it over from policy proposals to policy soon. --Xeeron 16:50, 1 March 2007 (EST)

There is one problem of note. I had hoped that the ANet tech team would be able to check this page periodically and respond to requests, but Gaile has said that this probably won't be practical and recommended we send an email to the tech team. Are there any thoughts on this? LordBiro 17:21, 1 March 2007 (EST)

Send an email to them whenever there is a new (fully discussed) request on the page? Maybe we should name one person to do so. --Xeeron 03:02, 2 March 2007 (EST)

Perhaps some sort of mailing list would be best, I don't know. Having one person deal with this would be a bit of a bottleneck. What if that person was on holiday? LordBiro 17:50, 2 March 2007 (EST)

Well it doesnt have to be one specific person. Anyone would do. Just needs to be someone. Maybe put a note up when a proposal is moved to the page saying "Anet still needs to be informed" and the first person to mail them removes the note. --Xeeron 06:13, 3 March 2007 (EST)

I really don't like that idea. I imagine ANet get a lot of emails form people, and they have to filter out those that are important. If a random person were to send an email and remove the notice it may not be picked up by ANet. Perhaps I am wrong, but really this needs ANet's opinion. If they think this idea is fine then I have no problem with it, but I expect that they would prefer that either an individual or a group would report this kind of thing.

If there were a mailing list for admins then this task could be carried out on the mailing list, but this is not something we've discussed yet. LordBiro 07:07, 5 March 2007 (EST)

Clarification

Hi guys. There have been some questions about what is going on with this page and ArenaNet. Here's some information that may help.

We do look at this page frequently. From what I understand, you guys have a good process going on. Since it's not really possible for us to read every piece of the discussion pages for every possible add-on for the wiki, we'll need the community to discuss the pros and cons of these proposed suggestions and figure out which ones are really beneficial to the wiki and which ones may not necessarily be as needed. From what I see, individuals propose things they'd like added onto the wiki. They submit a request on the talk page that outlines the name of the add-on, what the add-on does, the reason for requesting the add-on, links to the add-on's documentation, and then possible issues surrounding the plug-in.

These suggestions then go into discussion. Once a general consensus in the community is reached, the proposal is either declined or moved onto the main request page for our evaluation. From here, we'll look at the requests and figure out if the add-ons in question are something that we can provide.

In most cases, these add-ons will be fine. I'll get word from IT that certain items are pending install to the wiki, and I'll move those items down to the "Pending install" section on the main request page. These will be installed as soon as the team has a chance to get them up. If something happens and the requests will take longer than expected, I will try to post updates. If I forget, don't think I'm ignoring the page! Feel free to poke me on my talk page to get an update, and that will jog my memory.

In some cases, we may determine that a requested add-on has aspects that may make it something that we can't install to the wiki. It isn't that we don't feel that the suggestion was valuable, but there are times when add-ons may require a certain upgrade in order to be installed. There are other times when we feel that installing a certain plug-in may cause issues with in-game integration in the future. Whatever the reason may be for a declined item, I will try to provide a reason for the decline.

Other than that, I don't believe that there is anything that should be confusing. If you guys would like to post on my talk page to let me know that something has been moved onto the main proposal page, you can do this. However, as I mentioned before, we do keep an eye on this page as it stands.

I hope this helps. Feel free to add any questions that you may have about this topic. --Emily Diehl 16:41, 7 March 2007 (EST)

Ok. I would like to set my expectations for when we will get technical assistance when we've requested it - It is difficult to get a good feel for this as we don't understand the priorities and workload of your IT team. How soon after something goes to "pending install" could it be installed - at what point is it "longer than expected" (defined completely differently for an eager wiki person such as myself, and your IT team, yes?) and you'll let us know of delays? --Aspectacle 16:58, 7 March 2007 (EST)

Well, as far as the IT workload goes, I can't really speak for this myself other than to say that it can be quite extreme at times, and the issues that they need to attend to are extremely important. It isn't that the wiki is not a priority, but there are times when a plug-in install may be delayed until critical issues can be worked out with other things. As far as timeframes go, I can't really give those and be able to ensure that they are accurate. I can set aside time to talk to the team on a weekly or bi-weekly basis to find out when updates can be installed, but again, the actual date of install will depend on any issues that may arise. So, to answer your question, I can provide general status updates every week regarding plug-in installs, but I'm afraid that I will not be able to guarantee any definite timeframe for these installs.--Emily Diehl 17:34, 7 March 2007 (EST)

That sounds like tech sup work. :) Honestly I'm sure that after the initial requests already listed are installed the number of request would be few and far between so any sort of regular status updates would be complete overkill and for most requests completely unnecessary. While an eta would be good from our point of view (especially for highly desirable installs, like parser functions ;)) I think that we (or at least I) can appreciate that it can be difficult to give an accurate one. --Aspectacle 18:49, 7 March 2007 (EST)

PARSER FUNCTIONS!

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!BLASTEDT 19:38, 14 March 2007 (EDT)

Inter-wiki linking...

The ability to type [[Wikipedia:Karl Malone|]] is not working in this wiki right now. It allows for seemless linking between our wiki and any external wiki on the net. This is usually most useful when providing trivia info about a creature or item or quote in the game. --Karlos 15:05, 16 March 2007 (EDT)

Yeah, good call. I don't think there are any implications to implementing interwiki links, although I'm not 100% sure what implementing it requires.

I support this request. LordBiro 15:26, 16 March 2007 (EDT)

I support it. I even have one link to Wikipedia on my user pge allready, just waiting for this to be done. ;) -- (gem / talk) 17:12, 16 March 2007 (EDT)

Here's the media wiki page on inter-wiki linking for technical reference. --Karlos 05:57, 17 March 2007 (EDT)

We should decide exactly which wikis we'd want. We already can do commons, mediazilla, wikibooks, wikimedia, wikinews, wikiquote, wikisource, wikispecies, and wiktionary. meta (meta.wikimedia.org) and mw (www.mediawiki.org) are supposed to also work but don't seem to. Wikipedia is the main one to add. Should we add GuildWiki? Or anything else? --Rezyk 06:07, 17 March 2007 (EDT)

The only one that I really think we should add is Wikipedia. --Rainith 13:24, 17 March 2007 (EDT)

I would like to be able to link back to GuildWiki, but it might be confusing to readers to do this. I'm not really sure. LordBiro 15:04, 17 March 2007 (EDT)

I think interwiki links to the GuildWiki is probably a bad idea. If we provide any links to the GuildWiki, they need to be ugly and cumbersome, so as to encourage the creation of similar or better content here. —Tanaric 16:02, 17 March 2007 (EDT)

lol Tanaric... lol... LordBiro 17:13, 17 March 2007 (EDT)

I agree with Tanaric. Currently I'm bothered by the user pages linking to GuildWiki (with no other content) and I would be even more bothered if this would come a custom in article pages without the possibility to easily spot that the link is to GuildWiki instead of an article in this wiki. -- (gem / talk) 17:25, 17 March 2007 (EDT)

I support adding Wikipedia, and adding/fixing mw (www.mediawiki.org). (Edit: I'm withdrawing all my support here, if that's okay, but not directly opposing either. My sole reason for this follows the concern that 84-175 mentions below.) --Rezyk 16:06, 17 March 2007 (EDT)

I am obviously looking for Wikipedia linking, any other linking can be added as needed. GuildWiki linking is fine by me. The interwiki links look different and the content in the new page will look like it's in GWiki with GWiki's license not GWWiki with its license. So, no need for a qualifier. However, we should only link to ANY other wiki for content that is NOT supposed to be on this wiki. Not for content that is missing.

In other words, I am as opposed to [[GuildWiki:Prince Rurik]] as I am opposed to [[Wikipedia:Prince Rurik]]. This is an article we should have HERE and placing a link to another wiki only serves to discourage people from actually doing the homework and creating the article. Linking to Wikipedia is useful for explaning things like Monty Python and linking to GWiki could be useful for stuff like "Builds."

Finally, Gem, people are linking to GuildWiki on their user pages because the content is not here yet and GWiki is almost complete. It's nothing to be upset about. GuildWiki is pretty darn good and you should be pretty proud of it. It's not like the people who made GWiki are enemies of ours that we should feel jealous of their success. --Karlos 18:19, 17 March 2007 (EDT)

Karlos, you didn't quite understand my point. I don't see GWiki as an enemy of any sorts, I even contribute more to it at this point. It's just that some people have an empty user page with a link to their GuildWiki user page even though they could easily copy the content here without great problems. And what comes to inter-wiki linking to GuildWiki, although all of us understand how the links shouldn't be used, most of the new contributors don't and we can't supervise all of the links in this wiki. If there is a possibility to link like that to GuildWiki, iw will be used in the wrong manner by some people. I don't see any real benefits in the link to GuildWiki as we are going to have all of the content on this wiki too. -- (gem / talk) 03:11, 18 March 2007 (EDT)

I am one such user with my page simply linking to my GWiki page and it's for this simple reason: Half the links in the general game talk stuff would be red. I actually want to change the design and update the character info and have not, for weeks, waiting on interwiki linking to work so I can move the profile here seemlessly.

As far as people "mis-linking" it can't be any worse than copying content straight off the wiki. Right now we have more admins supervising than editors editing, so, I think we are in a PERFECT spot to supervise and make sure no one abuses this feature. Until we install a build system of our own, I thikn it would be wise, and useful for the readers if we can link to famous well-used builds on the wiki. I don't see it causing all the mass miss-linking you are talking about. If this was a problem you would have seen a mass usage of [this link format] to GWiki, which has happened a few times, but nothing too drastic. --Karlos 06:21, 18 March 2007 (EDT)

I agree with Karlos for the most part here. I'm not that bothered either way. I think if we do implement this then we need some guidelines for their use. LordBiro 08:04, 18 March 2007 (EDT)

I didn't say that there would be massive amount of misuse of the linking, but probably some, which might hinder this wiki. I really don't see any use for the linking to GuildWiki aside from the builds and user pages, which isn't too bad. I don't feel too strongly about this though, so if you really really want this, I'll accept it. -- (gem / talk) 16:07, 18 March 2007 (EDT)

Does more need to be done to get this approved, is it in queue to being implemented? Do I need to ask Emily for comment on her talk page? --Karlos 22:15, 22 March 2007 (EDT)

Hmm, I assume I come quite late with this, but I personally don't like this feature. Imho, links to pages outside of this wiki should be easily identifiable. Well, actually, this wouldn't forbid a feature that allows links like [[Wikipedia:whatever|]] if this link would display the same icon that is displayed when I write [http://en.wikipedia.org/wiki/whatever whatever] (little box-with-arrow thingy). Either that or get rid of the icon altogether, but I demand consistency! ;D --84-175 (talk) 10:09, 28 March 2007 (EDT)

84-175 makes a good point, but just to address Karlos' question, if consensus has been reached on a proposal then the next step is to make a formal request. To quote the project page "If there is consensus that the request would be beneficial to the wiki then a formal request should be created. Create a subpage of this article to hold the request and then include it in the "community requests" heading below. This request must include the following details:"

So when consensus has been reached an article such as Guild Wars Wiki:Requests for technical administration/Inter-wiki linking should be created, containing all the information that ArenaNet need to make an informed decision on the implementation. LordBiro 10:24, 28 March 2007 (EDT)

While I support direct linking to Wikipedia, I am against direct linking to GuildWiki. The first is useful, the second is self-defeating. If an article does not exist here, then it should be created, not merely linked from GuildWiki Fox 15:23, 28 March 2007 (EDT)

Personally I favour the ability to easily link to GuildWiki, but I would prefer to see it only used in particular circumstances. In policy discussions and on user pages being able to reference GuildWiki is very useful.

However I understand the argument against linking to GuildWiki, and if everyone here is satisfied that we only need the ability to link to Wikipedia then I would be pleased with that request. LordBiro 15:34, 28 March 2007 (EDT)

My stance is that I support an inter-wiki link to Wikipedia, as well as NOT having one to GuildWiki - for reasons already outlined by others above. Also, I realize it's a bit early to discuss it yet; but with Mike O'Brien comment at Talk:Guild_Wars_2#Guild_Wars_2_Wiki? where he indicated that a seperate Guild Wars 2 wiki will be coming, I would like to say early that I support adding an inter-wiki link to (and from) the eventual Guild Wars 2 Wiki. --- Barek (talk • contribs) - 15:43, 28 March 2007 (EDT)

I agree with everything Barek just said. --Rainith 17:00, 28 March 2007 (EDT)

So has this request been made known to who ever should know about it? -- (gem / talk) 17:22, 28 March 2007 (EDT)

Yes, it has been posted on my talk page. If you guys want to proceed with the request, please create a request page for the feature (as with the other approved features). Once you guys have talked about what links you agree upon, stick the link on the main requests page and I will pass it along the proper channels. --Emily Diehl 19:50, 28 March 2007 (EDT)

I've written out the request. The final step is to link to it from the article. Before I this happens I'd like to ensure that everyone is happy with implementing inter-wiki linking to Wikipedia only at this point. We can discuss other links in the future. LordBiro 05:48, 29 March 2007 (EDT)

That's my stance Fox 05:50, 29 March 2007 (EDT)

→ moved from Guild Wars Wiki talk:Requests for technical administration/Inter-wiki linking

Strong agree, This is sorely needed, I thought this kinda thing came as standard for all mediawiki projects, I can't believe it wasn't installed before official launch of the wiki. --Jamie 05:53, 29 March 2007 (EDT)

Is it possible to include fixing of some of the default interwiki linkings that's currently not working? Meta for example, I think someone listed them here - Anja Astor 06:06, 29 March 2007 (EDT)

Are we to assume this dilemma is over with? 84.175, you've been around long enough, you know that inter-wiki links appear different than intra-wiki links. They are paler in color, even after being visited. Any furhter objections? --Karlos 06:36, 29 March 2007 (EDT)

Wow, you're right, there actually is a difference. Seriously, I wasn't aware of that. I'd still prefer having the external-link-icon, but then, maybe I just need stronger glasses. --84-175 (talk) 09:50, 29 March 2007 (EDT)

Me too I guess. I didn't notice any difference in color. -- ab.er.rant 22:49, 29 March 2007 (EDT)

Meh, I've never noticed a difference. :D -- (gem / talk) 04:04, 30 March 2007 (EDT)

Not noticing that there is a difference in colour might be an issue if there were links directing a reader from the official wiki to GuildWiki, and so I can understand why, with this in mind, we would not allow inter-wiki links to GuildWiki. I don't think linking to Wikipedia in this way poses much of a problem. The content of the two wikis is very different. LordBiro 06:42, 30 March 2007 (EDT)

To turn the argument around, would anyone of the inter-wiki-link-supporters oppose to adding the icon to inter-wiki links? I don't have that much in-depth knowledge about mediawiki, but it seems to me that it shouldn't be too difficult to implement the icon on inter-links. Shouldn't that be quickly done with a small change somwhere in the stylesheets? --84-175 (talk) 07:19, 30 March 2007 (EDT)

Answering that question myself (pokes around in the source coude over at Guildwiki), here are the relevant parts of style code:

Adding the icon to external link (now that's clever, it's a background image...):

#bodyContent a.external,
#bodyContent a[href ^="gopher://"] {
	background: url(external.png) center right no-repeat;
	padding-right: 13px;

Adding no icon to inter-links:

#bodyContent a.extiw,
#bodyContent a.extiw:active {
	color: #36b;
	background: none;
	padding: 0;

To sum it up: I have no reservations against inter-links per-se. But I have a problem with inter-links looking the same as intra-links (and I am not the only one who has a problem spotting the tiny color difference). So, what speaks against giving inter-links the icon? --84-175 (talk) 08:04, 30 March 2007 (EDT)

reset indent
I have reservations about the icon :( External (arrowed) links look awful in the main body of an article, which is why I prefer to move them to a "Links" section at the foot of the article. Depending where they are in the text they can also break up the appearance and place only partially visible arrows etc. I think we should avoid using the arrow-box in the body of an article. The color difference is apparent. Fox 08:18, 30 March 2007 (EDT)

Count me among those who had no idea there was a color difference. I'd still prefer some more differentiation though. If not the icon, we could also play around with the color choice, couldn't we? --Rezyk 11:59, 30 March 2007 (EDT)

I want a small icon or a different color, but I would like to see different proposals before choosing. -- (gem / talk) 12:29, 30 March 2007 (EDT)

Does this have to be decided before we request inter-wiki linking? I don't think it should hold things. I agree that many people, including myself, can't spot a colour difference, but I don't think it's important enough a problem to hold up this request. LordBiro 12:54, 30 March 2007 (EDT)

I suppose the wikipedia linking has allready been requested and that's good, but I would like something to differentiate Guildwiki links from the GuildWarsWiki links from the beginning. If we don't come up with a solution now, people will just forget about it. -- (gem / talk) 14:17, 30 March 2007 (EDT)

Woah, back up, cowboy! "To differentiate Guildwiki links..."? We're not getting direct links to Guildwiki, are we? I understood this to be Wikipedia direct linking only..? Fox 14:24, 30 March 2007 (EDT)

Even though I agree that visually distinct interlinks would be nice, I personally really find it critical at all. The most important issue here is what Karlos mentioned above, with which I agree fully:

"However, we should only link to ANY other wiki for content that is NOT supposed to be on this wiki. Not for content that is missing. In other words, I am as opposed to [[GuildWiki:Prince Rurik]] as I am opposed to [[Wikipedia:Prince Rurik]]. This is an article we should have HERE and placing a link to another wiki only serves to discourage people from actually doing the homework and creating the article. Linking to Wikipedia is useful for explaning things like Monty Python and linking to GWiki could be useful for stuff like "Builds.""

So, even if GuildWiki interlinking is made available it is not really an issue, as long as it's not used to link to content which should also be here. This should be put in big bold letters on a policy somewhere. And that's all that really matters about this issue IMHO. --Dirigible 00:29, 1 April 2007 (EDT)

wikia

Interlinking to wikia such as '''[[wikia:Main Page]]''' currently incorrect links to http://www.wikia.com/wiki/Index.php/Main_Page. It should instead be http://www.wikia.com/wiki/Main_Page. -PanSola 08:46, 13 April 2007 (EDT)

Enabling image undeletion

MediaWiki supports image undeletion since 1.8.0, but it is disabled by default. The backend work to enable it is relatively small (see http://www.mediawiki.org/wiki/Manual:%24wgSaveDeletedFiles). The drawback is extra server space taken by storing deleted images. --Rezyk 05:59, 17 March 2007 (EDT)

Space shouldn't be a problem in this wiki. I think it might or might not be usefull. Although it does initially sound good, we haven't needed this earlier. -- (gem / talk) 16:28, 17 March 2007 (EDT)

There have rarely been instances in my time at GW and GWW where image deletions posed any problems. I don't think because ANet is supplying us with the hardware does not mean we should abuse that generousity without a good cause. Though it may be an issue later down the line, without knowing how much ANet is willing to pour into this project and with the amount of deleted images I have seen and deleted in my time, I would recommend holding off unless this becomes a necessary addition. The ratio of images deleted versus those that are contested after deletion do not support this action. — Gares 08:22, 18 March 2007 (EDT)

Exactly my thoughts, I just couldn't form it so nicely as I was in a hurry in the morning and I also wanted some support before getting too radical. :) -- (gem / talk) 16:09, 18 March 2007 (EDT)

Also I would imagine almost all images are duplicated somewhere on the net or someone's hard drive so in most cases if you really needed to un-delete you could just re-upload. --Lemming64 11:32, 28 March 2007 (EDT)

Firefox Search Plugin

Problem:
When you visit this site in firefox and press the down arrow in the search box you will see Add Guildwars Wiki (English). When you press it it says Cant find(..).

Solution:
I dont know if this works but this guy posted a simple solution.

)

~ Kurd11:29, 21 March 2007 (EDT)

User CSS seems to be activated

It seems like User CSS has been enabled. I'm not sure when this happened! Can anyone verify that it isn't just me? :P LordBiro 16:25, 21 March 2007 (EDT)

It seems user css and js are both enabled. Also the Guild: and Guild Talk: namespace has been added according to Special:Search and Special:Allpages. I hope having a capital 'T' in Guild Talk: doesn't matter. -Smurf 17:12, 21 March 2007 (EDT)

It wont lemme use css. BLASTEDT 17:54, 21 March 2007 (EDT)

Did you clear your browser's cache? -Smurf 18:03, 21 March 2007 (EDT)

No, please slap me, I'm an idiot. BLASTEDT 18:17, 21 March 2007 (EDT)

CoRrRan slaps BlastedT around a bit with a large trout. (Hey, you asked for it!) -- CoRrRan (CoRrRan / talk) 18:23, 21 March 2007 (EDT)

isketch.net? -.- BLASTEDT 20:04, 21 March 2007 (EDT)

Guild Talk capitalization

It's incredibly important to change the "Guild Talk" namespace to "Guild talk" (note lowercase 't') before we start filling it. All other talk namespaces are lowercase. —Tanaric 00:07, 22 March 2007 (EDT)

Support. --Rezyk 02:47, 22 March 2007 (EDT)

Also support. I will fire off an email to ANet to see if this can be sorted out quickly, since I don't expect there to be any disagreement on this point. LordBiro 05:10, 22 March 2007 (EDT)

I disagree! Just because you don't expect any :P j/k -- ab.er.rant 06:30, 22 March 2007 (EDT)

...lol LordBiro 07:00, 22 March 2007 (EDT)

I just got an email back from Trey who has amended the entry to "Guild talk"! :) LordBiro 13:29, 22 March 2007 (EDT)

Variables within a page.

Here.

Sounds incredibly useful, both for minor things on userpages and large things which would require a quite a few templates to write quickly, effieciently, or neatly. I like the look of it, any objections? BLASTEDT 15:19, 22 March 2007 (EDT)

This one always seemed like a fun toy, but personally I've found less good uses for this than StringFunctions and it sets off my "whoops, the wikicode is now a programming language" alert even stronger. I'm not definitely opposing this but I'd really like to see some good examples of beneficial uses first.. --Rezyk 16:14, 22 March 2007 (EDT)

I think we ought to demonstrate a need before officially making the request -- simply "hey, this looks neat!" is not sufficient. Additionally, I agree with Rezyk above about over-Turing-ing our wikicode. I oppose this request unless need is demonstrated. —Tanaric 16:34, 22 March 2007 (EDT)

I also oppose this request unless we suddenly find a real need for it, which I doubt. -- (gem / talk) 16:52, 22 March 2007 (EDT)

I also oppose this request. I don't see any practical use for it. Could you enlighten us Blastedt? When could we make use of this? LordBiro 16:56, 22 March 2007 (EDT)

Like, when you have to type something over and over for somereason, use a variable. "Hey, this looks neat!" IS sufficient, thank you very much! :) BLASTEDT 17:30, 22 March 2007 (EDT)

Like what...? --Dirigible 17:33, 22 March 2007 (EDT)

Like the results of switches and ifs. For example, I need to put a parameter value through a switch and use the result of that switch in more than 1 place. Wouldn't variables help? But I admit that it'll only complicate the wikicode a lot for non-programmers so I'm not too eager for this extension either. -- ab.er.rant 19:46, 22 March 2007 (EDT)

Screw the newbs, they can learn! Gimme complex things! =P =) BLASTEDT 21:08, 22 March 2007 (EDT)

Game Update and Guild Wars News link on the menu bar (under new paragraph news)

How about two new links on the menu bar left: Game updates and GuildWars.com News? BigBlue 04:20, 29 March 2007 (EDT)

That topic should probably go here MediaWiki talk:Sidebar. Cheers. :) --Dirigible 04:23, 29 March 2007 (EDT)

Thanks. Added a proposal there. BigBlue 04:29, 29 March 2007 (EDT)

Navigation popups

I understand from comments above that js is enabled; are we able/permitted to use Lupin's popups? An incredibly versatile and useful tool, might I add. Fox 07:45, 31 March 2007 (EDT)

We are permitted, but I'm not sure if we're able to use it. Not sure how compatible Lupin's script is with non-Wikipedia wikis. I'll give it a try in a bit, see if it works. --Dirigible 11:32, 31 March 2007 (EDT)

Much appreciated :) Fox 11:33, 31 March 2007 (EDT)

I tried them once on GuildWiki, and they sorta' worked - although it had a few minor problems (nothing major, just a few formatting glitches). I haven't tried it here yet, but I'm guessing it'll do similar. I didn't have time to debug the code, but I'm guessing that there's something wiki-specific in it someplace - either a call it's making to a site add-on or site JS may be missing, or something else in the code. --- Barek (talk • contribs) - 12:20, 31 March 2007 (EDT)

I was trying to make sense of this but I don't like to be bold with scripts, only articles lol Fox 12:23, 31 March 2007 (EDT)

Yea, I'm getting the same thing here that I got on GuildWiki. An expanded popup comes up showing links relevant to the page (talk page, contribs, what links here, etc) - but no preview. --- Barek (talk • contribs) - 12:33, 31 March 2007 (EDT)

GET http://wiki.guildwars.com/wiki/index.php?title=User:Barek&action=raw&ctype=text/css&maxage=0&smaxage=0
Response: {{Deletedpage}}

GET http://wiki.guildwars.com/wiki/index.php?title=Talk:Guild_Lord&action=raw&ctype=text/css&maxage=0&smaxage=0
Response: {{Deletedpage}}

GET http://wiki.guildwars.com/wiki/index.php?title=User:Dirigible&action=raw&ctype=text/css&maxage=0&smaxage=0 
Response: {{Deletedpage}}

Same for any other page. The response is what would go in the Preview section of the popups, but for some reason it's giving Template:Deletedpage instead of the real content. And I have no clue why. The response should give the content of each page, (Wikia, Wikipedia, Metawiki, GuildWiki output examples). This might be trivial or difficult to fix, if it's even an error and not a design choice. I really don't know.

Edit: Nvm, this is why (thanks Rainith! :P) http://wiki.guildwars.com/index.php?title=Index.php&diff=prev&oldid=25178

That's one problem (and probably the main one). The second problem is that we don't have Query.php installed. This adds some extra features to Popups, like image preview etc. --Dirigible 15:32, 31 March 2007 (EDT)

LOL. I read this and I'm thinking "WTF did I do?" then I look at the link. We ran into issues with Index.php on GuildWiki getting slammed with porn link spam and it happened here once so I did that to try to preempt any additional hits. It might not be a problem if we could get SpamBlacklist installed. This is assuming that that page needs to be permanently unprotected. If something just needs to be added there, let me know and I'll do it. --Rainith 15:47, 31 March 2007 (EDT)

Don't worry about it too much, it seems we can do even with that page protected. :)

Using this code in your Special:Mypage/monobook.js page should get things going properly:

// Lupin's popups, [http://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups]

 document.write('<script type="text/javascript" src="' 
             + 'http://en.wikipedia.org/w/index.php?title=User:Lupin/popups.js' 
             + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
 function siteArticlePath(){ return 'wiki'; }
 function siteBotInterfacePath(){ return ''; }
// disabling features that depend on query.php until that is installed
 popupUseQueryInterface=false;

From what I see everything should be working fine, including popup previews for articles, diffs and such. There's still disabled features that depend on Query.php, like image and history preview, but that one will need to be installed server-side. --Dirigible 16:13, 31 March 2007 (EDT)

Awesome :) I haven't given it the full road test yet (gimme ten mins) but it is good to have this tool back on the end of the cursor. Thanks, D :) Fox 16:29, 31 March 2007 (EDT)

I read the request earlier, and I had some questions about how it would be implemented, so I'm glad to see progress is being made :) Good work! LordBiro 19:01, 31 March 2007 (EDT)

Just to add, I'm getting image previews fine, the only delay is for newly uploaded imgs which just take a few minutes from first uploading before popup's starts to show them - something to do with the way its cached I guess. But other than that, image previews are fine. Fox 05:38, 1 April 2007 (EDT)

You could limit this mostly to skills and small images, right? That would make them less exploitable for spam.Sith 13:45, 2 April 2007 (EDT)

While this does increase the number of GETs, I don't think it poses a problem as far as spam goes. GETs are very inexpensive, especially if a cache is used, and I believe one is. LordBiro 16:05, 2 April 2007 (EDT)

reseting indent. Can and will this be used to display a skills quick reference when you hover the mouse over image or text? IMHO this would make builds much easier to understand and give you a good overview. It could make need for quick referncing obsolete since it would display crucial informations anyway. PS. I tried this and it works fine but the problem is it takes too long for the pop up to appear. Could the time needed for popup to appear be reduced to 1sec?I time needed depends on connection. Could this be applied only to skills or some special pages? Sith 12:41, 3 April 2007 (EDT)

This is designed as a contributor's aid, not as a reader's aid. If you wish to use the navigation popups to preview other articles via links then by all means go ahead, but this cannot be a replacement for skill quick references or the like. LordBiro 13:01, 3 April 2007 (EDT)

Could you elaborate why you couldn't use these pop-ups to display an info simmilar to the quick references? My guess is that information such as activation and recharge time as well as the picture can't be displayed because they are fields. --Sith 13:31, 3 April 2007 (EDT)

As LordBiro points out, Lupin's is designed to aid contributors. I don't think it can be altered in the way you suggest, but even if it could I wouldn't support losing the multi-functionality just to speed up reading builds - which hopefully we will never have here anyway ;) Fox (talk|contribs) 14:06, 3 April 2007 (EDT)

@Sith, because not everyone turns on javascript. -- ab.er.rant 14:48, 3 April 2007 (EDT)

I would just like to mention quickly that these popups freaking rock. That is all. MisterPepe talk 11:21, 4 April 2007 (EDT)

Aww too bad no builds... they are rather interesting enhancments. I only dislike them needing too much to open (atleast for me). --Sith 13:01, 4 April 2007 (EDT)

This is a great help. Anny news about the installation of Query.phpon the server?--Phoenix File:Phoenix-sig.png 05:54, 17 April 2007 (EDT)

I don't think there's any plans to install it yet. The other editors using Lupin's Popups right now seem to be content even without query.php. I personally wouldn't mind having it installed, not only for the popups but even for AWB, and possibly other future uses. But right now it seems the only extensions having a chance of being installed are those that are a "must have", not the "would be nice to have" ones too. =\ --Dirigible 06:11, 17 April 2007 (EDT)

I think it depends on the proposal, Dirigible. If the cost of implementing Query.php is low, and the benefit is high then I would personally support it. I'm not that fussed about Query.php, because I don't know what benefit it provides really. Care to enlighten me? :) LordBiro 08:22, 17 April 2007 (EDT)

Heard that this query.php is usefull if I want to add more informations to the revert comment... so I support to add this :-) - MSorglos 05:15, 29 April 2007 (EDT)

CAPTCHA

Can we get some form of CAPTCHA installed to stop this spam? Wikipedia uses ConfirmEdit. -Smurf 10:32, 28 April 2007 (EDT)

I agree, been waiting for this for ages! ~ Kurd10:37, 28 April 2007 (EDT)

I'd rather we try the SpamBlacklist extension first, as I personally am not particularly fond of captchas, they're a major nuisance. =\ If SpamBlacklist isn't enough, then I guess we can do captchas, but we should really leave those for last. --Dirigible 10:38, 28 April 2007 (EDT)

true, we should probably try that first. I remember it being suggested before but I guess it was overlooked. -Smurf 10:51, 28 April 2007 (EDT)

I support either or even both solutions. The spam (likely from zombie machines) is growing considerably - it's becoming a major maintenance task in itself now. GuildWiki had similar issues at one time as well; but with spam prevention techniques in place, it's been considerably reduced on that site. --- Barek (talk • contribs) - 11:32, 28 April 2007 (EDT)

Actually after looking at some of the recent spam links SpamBlacklist wouldn't have helped. The spammers are linking to legit hosts that allow user content. However the spammers are making them redirect to their spam. I say we should use ConfirmEdit and configure it to only use CAPTCHAs for unregistered users. Then if it becomes too much of a nuisance for them they can register. -Smurf 11:53, 29 April 2007 (EDT)

...and only when they add a new external link or create an account. -Smurf 12:00, 29 April 2007 (EDT)

I don't know how SpamBlacklist works. Smurfs proposal sounds good to me - it will stop unregistered spammers (as long as they can't autosolve the captcha by using captcha-solver programs). It also can drive occasion editors to register. But it also could hinder that occasion editors. Don't know how many of them are around. - MSorglos 12:05, 29 April 2007 (EDT)

SpamBlacklist works by blocking links that contains certain keywords (defaults to m:Spam blacklist) in the domain name. However none of the spam I've seen would be blocked by the default list. We could add them; however the links link to legit domains that IMO shouldn't be blocked. The current spammers are using sites like blogs and forums and making them redirect to their advertisements. I agree that CAPTCHAs can be a nuisance, but it only pops up when you add a new external link. Also I like ConfirmEdit since if spammers do get past the simple math problem it can later be upgraded with FancyCaptcha to use images. -Smurf 13:23, 29 April 2007 (EDT)

I don't know what was done on Guildwiki to get rid of the spam, but it seems to be working very well. Spam was a serious issue at one point, we were banning multiple IPs a day, but I rarely see any spam nowadays (if I look at the blocklist, there have been two bans for "spam" this year so far). I'd say we do whatever was done there first, before annoying people with CAPTCHAs. But if we have to implement them, I strongly support that it should be limited like suggested. --84-175 (talk) 03:43, 30 April 2007 (EDT)

GuildWiki only uses ConfirmEdit according to Special:Version. -Smurf 04:15, 30 April 2007 (EDT)

Pity. Captcha it is, I guess. At least we should try to make them as painless as possible.

Skipping all registered users:

 $wgGroupPermissions['*'            ]['skipcaptcha'] = false;
 $wgGroupPermissions['user'         ]['skipcaptcha'] = true; 
 $wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true; 
 $wgGroupPermissions['bot'          ]['skipcaptcha'] = true; 
 $wgGroupPermissions['sysop'        ]['skipcaptcha'] = true;

Only triggering on links:

 $wgCaptchaTriggers['edit']   = false; 
 $wgCaptchaTriggers['create'] = false; 
 $wgCaptchaTriggers['addurl']        = true; 
 $wgCaptchaTriggers['createaccount'] = false; 

How do those look? The above only bugs non-logged in users when entering links; I don't think we should force them to a captcha even when creating an account. We haven't been getting any spams from logged in accounts so far, so I don't think we need to do that (yet). --Dirigible 07:53, 30 April 2007 (EDT)

Isn't this the same as GuildWiki uses? LordBiro 07:54, 30 April 2007 (EDT)

That looks fairly painless for all but the bots, D. Seems the sensible option right now. Fox (talk|contribs) 07:56, 30 April 2007 (EDT)

Aye Biro, this is what GuildWiki also uses, as Smurf also pointed out above. --Dirigible 08:06, 30 April 2007 (EDT)

I meant the configuration. Is the configuration the same as GuildWiki? I only ask out of curiosity. LordBiro 09:16, 30 April 2007 (EDT)

Just checked, and not exactly. GuildWiki also shows a captcha when the user is registering an account, and when a non-autoconfirmed account is entering a link (autoconfirmed accounts being those registered accounts older than $wgAutoConfirmAge, whatever that is for us; usually it's 3-4 days).

So GuildWiki has $wgCaptchaTriggers['createaccount'] = true; and $wgGroupPermissions['user']['skipcaptcha'] = false; . I still think we should try with the least amount of restrictions possible at first, then only add the rest if the need arises. --Dirigible 10:14, 30 April 2007 (EDT)

Makes sense. LordBiro 11:26, 30 April 2007 (EDT)

We can try this config for now; but if I recall correctly, the reason for the also placing this for account creation on GuildWiki was that some spammers were getting their bots to auto-register first then post their spam. I wouldn't be surprised to see this develop here as well; but as you said, try it like this for now and only up the criteria if/when the spammers do try that method to get around the captcha. --- Barek (talk • contribs) - 15:51, 30 April 2007 (EDT)

ConfirmEdit request posted, with the settings above. Looks alright to everyone? --Dirigible 08:58, 30 April 2007 (EDT)

looks good. thanks for creating it. -Smurf 10:03, 30 April 2007 (EDT)

Agreed :) LordBiro 11:26, 30 April 2007 (EDT)

Hi guys! I just got into the office and noticed this. I'll send an email out to IT to check it out as soon as I get back to my desk with coffee. I'm dragging today *yawn* -- Emily Diehl (talk) 13:21, 30 April 2007 (EDT)

Thanks! By the way, could you also let them know about Guild Wars Wiki:Reporting wiki bugs#System messages? The MW message cache isn't working right, and it's messing up a few things like the skill pages and the sidebar, and (most importantly) the GFDL copyright notice which is shown to users before submitting anything to the wiki. Thanks again. --Dirigible 13:29, 30 April 2007 (EDT)

Hey guys...the CAPTCHA extension has been installed, and the issue that was causing a problem with the main css (and other) files should be fixed. Let me know if you notice any issues! -- Emily Diehl (talk) 18:46, 1 May 2007 (EDT)

Thanks Emily :) LordBiro 19:22, 1 May 2007 (EDT)

Enabling subpages on more namespaces

It appears that subpages are currently disabled for the "Guild Wars Wiki" namespace (thanks to Barek for noticing), which matches default MediaWiki settings for the project namespace. I suggest we turn on this feature for that namespace, and also for the upcoming "Guild" and "Guild talk" namespaces. Subpages are already on for the other talk and User namespaces (but not main/Image/Category namespaces).

Effects of this feature are described at http://meta.wikimedia.org/wiki/Link#Subpage_feature . Note that we can still create subpages without this feature -- it's just that MediaWiki won't recognize them as such and basic things get complicated (with workarounds and such).

Details on the necessary backend work can be found at: http://www.mediawiki.org/wiki/Manual:%24wgNamespacesWithSubpages#Enabling_for_a_namespace . It appears to be a one-line fix for each of the 3 namespaces.

The main reason to not use this feature is to completely discourage subpages on a namespace, which is why it's generally off for primary content (main/Image/Category) namespaces on other wikis. It doesn't seem like we want that for the GWW/Guild/GuildTalk namespaces. Another drawback is that pages that are named with a "/" but not intended to be subpages will still be recognized as such.

Please comment.

--Rezyk 16:13, 15 March 2007 (EDT)

Enabling it for the GWW and Guild name spaces is a good idea. Also, if we create the Build name space, it should be enabled there too. -- (gem / talk) 16:37, 15 March 2007 (EDT)

More comments from others, please? I don't expect much/any opposition to this, but I'd like it to be made obvious enough that ArenaNet doesn't have to give it a second thought. --Rezyk 16:09, 2 April 2007 (EDT)

Support. Seems as a very practical feature to me. --Dirigible 16:14, 2 April 2007 (EDT)

Agreed. LordBiro 16:15, 2 April 2007 (EDT)

I was away from the wiki while this was being discussed. My only concern on this is with pages that were created with a "/" in these namespaces prior the change. It's not something that should cause this not to go forward, I fully support it - but I do have this one concern that I would like feedback on if anyone knows how it may be impacted.

As an example, my understanding is that if a page were created with a prefix "something:blah-blah-blah" were created, then later a namespace was created that was named "something", the first page that I mentioned becomes unreachable. This is because when you enter that page name, the MediaWiki software at this point tries looking for "blah-blah-blah" in the "something" namespace; but the article is actually still in the main namespace with the full article name "something:blah-blah-blah" because the MediaWiki software does not recognize articles created with the prefix prior to the namespace existing as being part of the namespace.

So, my concern is will the same sort of thing happen here? If a page such as "Guild:Some Guild/Some subpage" were created, then later the subpages activated for that namespace, would the MediaWiki software correctly convert the pre-existing "/" into being a subpage - or would the software again choke, making those pages either unreachable, or at the very least un-linkable via the normal subpage linking structures?

Again, I don't see this as a reason to stop the implementation - but it is something that I think we should investigate and be prepared to clean-up if it is an issue. --15:37, 15 June 2007 (UTC)

Just tested it, and there doesn't seem to be such a problem. Pages with a slash in their name created before the subpages being enabled will continue to remain fully functional. --Dirigible 16:20, 15 June 2007 (UTC)

Hi guys! I've received word that subpages have been enabled for the main Guild Wars Wiki namespace. The IT team mentioned that subpages should have already been active on the Guild and Guild talk namespaces, so if you guys have any issues creating them, please let me know immediately so I can pass the problem along for review. Since this page is getting super long, I'm going to move this topic to the resolved archives tomorrow (unless someone beats me to it :))-- Emily Diehl (talk) 01:27, 20 June 2007 (UTC)

DynamicPageList

I think we should seriously consider installing the latest DynamicPageList extension (DPL). Refer to its website for lots more detailed info on it.
(Note: There was some previous discussion over an older version of DPL, which was at the time superceded by DPL2. The current DPL (version 1.0.7) takes the name of that oldest version but supercedes both it and DPL2.)
Some examples of potential benefits/uses:

1. The same stuff covered in the previous discussion -- auto-generating lists like "core monk enchantment spells" from categories. Auto-generating helpful maintenance lists, like a list of pages that have been marked for deletion for 3 days, sorted by staleness. Auto-listing the policies or formatting guidelines accepted/proposed/drafted/rejected in the last week. Listing the newest guides/builds in a particular category. One particular criticism we had before was that the generated lists were restricted to simple wiki list format (bullets). This is no longer true; now the mode=userformat feature allows for generic formatting (e.g. fancy tables). This also opens the door to auto-generating image galleries where we retain control over the format instead of being forced to basic wiki gallery format. Time to start thinking about making some sweet item skin galleries! =)
2. Replaces the need for subpages holding some content of articles in main namespace. Example: Instead of splitting up the Warrior armor article among 58 separate subpages (!) like Warrior Ascalon armor/Male (so that the content can also be transcluded in Ascalon armor), put all the content directly into Warrior armor and have pages like Ascalon armor selectively transclude the sections they want. This would be made possible by the labeled section transclusion feature, which used to come in its own extension, but is now included in DPL through its includepage parameter. This also applies to stuff like collector item lists in subpages. EDIT: Bad example; for some reason (confused by the armor collector subpages?) I thought those armor subpages were transclusion pieces, but they're actually individual pages, so this doesn't apply.
3. An alternative transclusion system for skill quick reference lists! Well, not a huge difference -- the underlying complexity is similar to the onlyinclude proposal. Performance-wise, as far as I know, it might be a lot better (optimized/unified SQL queries and processing..?) or a lot worse (re-query every time..?). If it is usable, then there are these benefits:
   1. Skill wikicode is even cleaner (I didn't think this was possible =). The skill pages can look like they do under the separate-template-pages system, with zero noinclude/includeonly/onlyinclude tags and no variable in the infobox template name (Skill infobox {{{variable|}}}). Even with essentially zero footprint within the skill page, we can still transclude exactly the stuff we want from it, yet without a separate template for each skill.
   2. More flexibility in skill page wikicode. Right now, under any current transclusion proposal, we'd still have to fold the skill in-game description into the infobox template call to use it in transclusion lists (although it can stay out of the infobox visually). This might limit our page layout options -- maybe the description will have to stay at the top of the page, or the infobox has to lower? With DPL transclusion, the description and infobox can be completely separate in the wikicode and page layout (but the in-game description would need a header) (EDIT: Never mind, might not be true).
   3. Shorter wikicode in the transcluding pages. Instead of a line for each skill, one DPL call handles it all.

Some potential worries:

1. Performance -- my opinion: I don't know yet. I'm sure DPL is fine for simple uses, but it might end up not feasible for popular and lengthy transclusion lists (skills). There is some general test data available, and server side variables to limit it in various ways.
2. Complexity -- my opinion: Not so bad, but we should be cautious. Basic usage is maybe easier than ParserFunctions, but advanced usage can get a little more advanced (SQL LIKE patterns or regular expressions, although those wouldn't be needed for anything I've brought up so far). If we want, we might be able to disable some particularly scary options individually (see $wgDPL2Options). Turing complexity isn't so much of a worry, as the tag is generally only useful to invoke at the top-level, render stage.

--Rezyk 19:36, 7 April 2007 (EDT)

I support this, I personally can't possibly give any other answer. I've been playing around with DPL since you posted this, Rezyk, and it's simply great, no doubt about it. It'd open a whole lot of options for us, which would definitely add to what the wiki has to offer to both readers and editors. It's...great. I've been hesitant to post this comment so far, bothered by the worry that installing DPL might result in a much more difficult learning curve for future editors; current contributors will have the advantage of learning how to use it starting from the basics, while future editors would need to deal with however advanced our DPL usage may have gotten by then. But the more I play around with DPL, the more I think it's worth that risk, it has just too much to offer. As long as we make an active effort to use it with moderation and caution, it should be fine. (I'd be very surprised if DPL doesn't eventually become part of the default MediaWiki installation, once it's polished enough.)

As far as performance goes, I have no idea what it'd be like on the actual servers here. =\ --Dirigible 06:51, 14 April 2007 (EDT)

It seems that DPL 1.1.0 would also allow for another skill transclusion system (distinct from the above "normal" way) that would not use separate templates for each skill yet give the same or better performance on the big lists while skill pages are edited. This could be done by putting the skill data directly into the big profession skill lists and having everything else (including skill pages) transclude the data from them. I'm not saying we'd want this, but it's an option. --Rezyk 02:58, 17 April 2007 (EDT)

I see. That doesn't sound that desirable to me. The main thing I dislike about the GuildWiki system is that a user can't simply click edit on a skill article and see all the details, because those details are held in a template. I think this solution suffers from the same problem. LordBiro 03:33, 17 April 2007 (EDT)

I agree with Biro about skill articles. I think ease of editing should be our primary concern. We have (or will have) enough editors that a little redundancy is okay. —Tanaric 05:09, 17 April 2007 (EDT)

I agree with you both; that's why I considered not even mentioning the option. ^^ --Rezyk 05:27, 17 April 2007 (EDT)

Any chance we can get some more feedback on this? Either support or some reason to be against it? Take a look at the examples Rezyk mentioned above for some interesting ideas. Even the most simple uses would be very helpful right now, like being able to generate a list of Awakened bosses articles that are also stubs without needing to check every single one of them by hand. --Dirigible 19:35, 28 April 2007 (EDT)

Everything that makes work here more comfortable and easier has my support :) I think the performance aspect should be considered, I don't know how wiki works (e.g. how much caching there is) so I don't know how performance is affected. Having more possibilities to generate content for this Wiki or easier maintain content is desirable. - MSorglos 03:03, 29 April 2007 (EDT)

I also support the addition of this. Looks like it could be quite handy for us here. I don't know what the performance concerns may be, but I presume we can limit them through the disabling of excessive options in the server settings. Also, which version would we be looking at using? It appears that the most current release is 1.1.4. --Indecision 16:52, 30 April 2007 (EDT)

If it'll get us nice Quick Reference lists, I'm all for it! -- CoRrRan (CoRrRan / talk) 17:09, 30 April 2007 (EDT)

I suggest 1.1.5 or later. --Rezyk 03:07, 2 May 2007 (EDT)

I also support this, for the same reason CoRrRan does. Erasculio 22:25, 2 May 2007 (EDT)

Support. I've written about this subject before in a diff section. -User:PanSola (talk to the File:Follower of Lyssa.png) 12:45, 5 May 2007 (EDT)

It seems to me we've got consensus to install then. Do we want to apply any particular values to the global variables? For reference, the default values are:

$wgDPL2MaxCategoryCount         = 4;      // Maximum number of categories allowed in the Query
$wgDPL2MinCategoryCount         = 0;      // Minimum number of categories needed in the Query
$wgDPL2MaxResultCount           = 500;    // Maximum number of results to allow
$wgDPL2CategoryStyleListCutoff  = 6;      // Max length to format a list of articles chunked by letter as bullet list
$wgDPL2AllowUnlimitedCategories = true;   // Allow unlimited categories in the Query ($wgDPLMaxCategoryCount will be ignored)
$wgDPL2AllowUnlimitedResults    = false;  // Allow unlimited results to be shown

Via $wgDPL2Options we can also set the default values for all parameters or disable specific values completely. I personally don't think there's any need to change anything until the need arises, but the possibility is there. Thoughts? --Dirigible 22:22, 8 May 2007 (EDT)

I guess those defaults are perfectly fine to start with. AFAIK, not too many people have had the chance to work with DPL yet, so many don't have a clue what certain options might improve. I'd say, just go with the defaults and if need arises, change them. --  (CoRrRan / talk) 05:08, 9 May 2007 (EDT)

Yeah, I say go with default for now. --Rezyk 14:00, 9 May 2007 (EDT)

Request page is up Guild Wars Wiki:Requests for technical administration/DynamicPageList. I'll wait for a day or so for any last thoughts on the matter (and hopefully for someone to read over that request, to make sure I didn't write anything ridiculous), and then will make the request official.

By the way, something interesting I noticed while jotting down that request, the D&D Wiki is running seven different installations of DPL. :) --Dirigible 05:00, 10 May 2007 (EDT)

Ooh, that's a cool site. Completely unrelated, but still cool. :) —Tanaric 11:58, 10 May 2007 (EDT)

CreateBox

The CreateBox extension allows for another, handier, interface to page creation. This takes the form of an HTML input box and submit button that can be inserted into any page(s). Users type an article name in the input box and click the submit button; this takes them to an edit form of that page, but also with a customized intro and customized text preloaded in the edit box.

A general use could be in creating any pages where a lengthy formatting guideline with full syntax/example applies (including NPCs, Missions, Quests, Locations, Skills, Guilds, Unique items, Weapons, etc). An example with guild pages: We could have an input box where users type in their guild name, and it brings them to an edit form (automatically adding the "Guild:" prefix) with the base template preloaded in the edit area, and whatever extra instructions/restrictions we want showing at the top. One might see benefits here in making the creation process easier (by automating the cut'n'paste of example syntax), or more generally helpful (by showing relevant instructions directly on the edit page), or both.

--Rezyk 04:12, 27 May 2007 (UTC)

I can definitely see the merits of this. (Aiiane - talk - contribs) 04:14, 27 May 2007 (UTC)

This is a great thing, and I don't know how we've done without it for so long. —Tanaric 05:50, 27 May 2007 (UTC)

Can you link to an example where this is usefully implemented? The example on the link above is simply dublicating the create article link you get whenever entering a new term into search. --Xeeron 09:47, 27 May 2007 (UTC)

It looks good, but I'd like to see a more in-depth example as well. LordBiro 09:52, 27 May 2007 (UTC)

This is awesome if it works. The guild problems are getting out of hands and with the wiki links in the game... -- (gem / talk) 10:09, 27 May 2007 (UTC)

Support. --Dirigible 11:22, 27 May 2007 (UTC)

For those wanting a more detailed example, I've utilized the hosting wiki of the module to create another one, that's slightly more relevant to our purposes. You can take a look at it here. (Aiiane - talk - contribs) 15:29, 27 May 2007 (UTC)

Ok, I see. So that would go together with an (easy to understand, plaintext) guild template. Sounds like a great idea. --Xeeron 17:19, 27 May 2007 (UTC)

I might be getting ahead of myself, but would it be possible to auto-populate the guild name? What I mean is, someone will no doubt click the link in the help menu in GW and be directed to the location of their guild article. They then click the edit button and are directed to the edit box for this article. At the bottom it says something like "filling in a guild article? Follow this link!". Clicking the link directs them to a CreateBox form.

At this point we don't want them to enter a guild name, this is the only value that is not variable. It's only the other information that needs filling in, i.e. tag, number of members, faction etc. My main concern is that someone will follow the link from Guild Wars to their guild article, i.e. Guild:House Of Kyan (my guild) and then they go to create the article, jump to the CreateBox, and enter a different value for the guild name, i.e. Guild:House of Kyan. LordBiro 18:17, 27 May 2007 (UTC)

I think that's a great idea, but I'm not sure if it can work or not. We could use {{PAGENAME}} to prefill the article name into the input box, and even check if the namespace is "Guild" with parserfunctions before having it show up. The thing is: my testing shows that these should work within articles, but we'd want to work this into a system message instead. I don't know if that would throw off the mechanisms. --Rezyk 19:55, 29 May 2007 (UTC)

If there's no objection, Guild Wars Wiki:Requests for technical administration/CreateBox will be added to the list of community requests. --Rezyk 19:45, 6 June 2007 (UTC)

DismissableSiteNotice

This election is going to go on for the rest of the month, and we'll have another month-long election coming soon in August, so that blue bar at the top of each page is going to be there for quite a while. Xeeron suggested adding a "Dismiss this notice" link, ala-Wikipedia, and I agree that it'd be a useful idea. How does everyone else feel about this?

That link is achieved by using the wfDismissableSiteNotice MediaWiki hook, installed through the DismissableSiteNotice extension, by default enabled on all Wikimedia projects. --Dirigible 14:32, 13 June 2007 (UTC)

Sounds like a good idea. Is there a way to get the notice back though? Or does the status reset when you log in the next time? -- (gem / talk) 17:49, 13 June 2007 (UTC)

From the user side, DismissableSiteNotice.php creates a cookie named dismissSiteNotice which remembers that setting. When the user removes that cookie, or accesses the wiki from another browser/computer she'll see the notice again.

From the wiki side, we can trigger the notice to reappear for all users without they needing to mess with cookies by changing the id number at MediaWiki:Sitenotice id, which resets the dismissSiteNotice cookie. --Dirigible 07:59, 14 June 2007 (UTC)

Better than I hoped for, I support this fully. -- (gem / talk) 10:22, 14 June 2007 (UTC)

I also support this. —Tanaric 20:04, 13 June 2007 (UTC)

Thirded. While I don't mind site notices, it would be nice to be able to hide one I've already seen, and I'm sure it'd be more of an annoyance for some users. (Aiiane - talk - contribs) 03:38, 14 June 2007 (UTC)

With the clarification from Dirigible on how to reset the notice, I support this as well. --- Barek (talk • contribs) - 16:17, 14 June 2007 (UTC)

Guild Wars Wiki:Requests for technical administration/DismissableSiteNotice. Any last comments before we add this to Community requests? --Dirigible 05:46, 15 June 2007 (UTC)

Submitted. --Dirigible 18:31, 18 June 2007 (UTC)