GuildWiki has been locked down: anonymous editing and account creation are disabled. Current registered users are unaffected. Leave any comments on the Community Portal.


Line 508: Line 508:
Tip: cleaning up [[Special:WantedCategories]] goes a long way towards finding mistakes. --[[User:Mendel|◄mendel►]] 20:53, 13 February 2011 (UTC)
Tip: cleaning up [[Special:WantedCategories]] goes a long way towards finding mistakes. --[[User:Mendel|◄mendel►]] 20:53, 13 February 2011 (UTC)
:I agree, been trying to clean up the wanted categories for pages first... [[User:Ariyen|Ariyen]] 21:00, 13 February 2011 (UTC)
:I agree, been trying to clean up the wanted categories for pages first... [[User:Ariyen|Ariyen]] 21:00, 13 February 2011 (UTC)
::Ok, first, wtf ariyen? Second, what's the big deal if both the nav box and the infobox both set the same cat as long as they don't conflict? Third, nav box categories tend to be less likely to be red-linked since they are usually hard coded. Fourth, all this is due to wanting to use mainspace templates in userspace? That's easily duplicated (can be changed from main to user version easily) or the cats could be namespace aware. Fifth, ariyen, why didn't you come out and ask for a potential solution before coming up with your own, knowing it would affect <s>terrible, terrible damage</s> many, many pages? --[[User:JonTheMon|JonTheMon]] 23:09, 13 February 2011 (UTC)

Revision as of 23:09, 13 February 2011

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.


 1   2   3   4   5   6   7   8   9  10 11 12 13 14 15 16 17 18 19 20 21 22
This talk page should be used for discussions regarding GuildWiki in general. For anything directly relevant to the Main Page or the edit copy, please use Talk:Main Page/editcopy. If you have any questions that aren't relevant to a specific talk page, head over to GuildWiki:Request assistance and add it.

The most recent forum posts are:

Coding (2018-11-26 16:50:38 by Pcjbot)
New GW2 info/The Professions (2011-12-14 22:41:36 by @DeletedUser119300)
Coding/Javascript (2011-04-15 14:05:33 by Dr ishmael)


been using the official in the meantime, man the way they organize quests it makes it really difficult to see what you need to do to acquire the quests (IMO). It was driving me crazy, but not as crazy as the wikia skin. 16:26, 1 December 2010 (UTC)

Seeking Fansite status

I spoke briefly with ArenaNet's Community Relations Manager Regina Buenaobra yesterday about getting GuildWiki back on the official fansites listing now that we're off Wikia. She was very positive about it and directed me to the Fan Site Program page. Interestingly enough, losing our fansite status on Wikia was a blessing in disguise, because they're encountering a lot of difficulty with PvX's situation- the wikia site is still listed as an official fansite, but we don't have that issue. In particular, I'd like to draw everyone's attention to the eligibility expectations- I want to be sure we meet all the expectations before asking for a preliminary review. To that end, I'd appreciate input on the best ways to meet those goals. Felix Omni Signature.png 20:06, 1 December 2010 (UTC)

I think we do. We might have lost our fan site status, but that doesn't mean we allow porn or gold seller ads. We might not be as up to date as GWW, but we try our best. Go for it! Arnout aka The Emperors Angel 20:19, 1 December 2010 (UTC)
Should we add more RSS feeds? I think they have community news, and we could also do an updates feed in addition to the commented one we do. (Of course noen of these are archived on-wiki.) I'm also more than willing to paste ANet logos all over the place if needed. --◄mendel► 05:32, 2 December 2010 (UTC)
Just curious, what made us ineligible in the first place when Wikia took over? I can't remember that far back. -- Isk8.png Isk8 (T/C) 20:54, 2 December 2010 (UTC)
They accused "us" of money selling ads. Arnout aka The Emperors Angel 21:52, 2 December 2010 (UTC)
I think accused is the wrong word there. It was simply that we no longer had any control over the ads that appeared, and because Wikia couldn't reliably block the gold-selling ads, Anet could no longer allow us to have fansite status. —Dr Ishmael Diablo the chicken.gif 22:27, 2 December 2010 (UTC)
It's why I used "us". I knew it was wikia, so I tried to explain. But I don't blaim em for removing the fan site status. Arnout aka The Emperors Angel 15:59, 3 December 2010 (UTC)
Synopsis of requirements:
  1. High Quality and design Yes.png
  2. Legal req'ts, copyrights, etc; attribute properly Yes.pngMaybe.png
  3. Reflects positively upon the company and the game Yes.png
  4. No porn/porn links, hackz/piratz, gold trading, cheats. Yes.png
  5. Active moderation of forums/chats. Staff behaves appropriately. Yes.png
  6. To abide by the game's User Agreement and Rules of Conduct. Yes.png
I think we're in good shape, except for possibly how we use screenshots (our policy isn't as strict as GWW's, but I'm sure it's at least as good as Guru's).  — Tennessee Ernie Ford (TEF) 22:47, 2 December 2010 (UTC)
We could add a tiny ArenaNet or Guild Wars logo to the footer. Felix Omni Signature.png 22:51, 2 December 2010 (UTC)
That seems sensible, Felix. Is there any reason not to ™ ANet on every page's footer?  — Tennessee Ernie Ford (TEF) 23:00, 2 December 2010 (UTC)
I applaud your efforts at regaining fansite status. If Curse can be of any assistance, please feel free to ask. -- Wynthyst User Wynthyst sig icon.png talk 22:07, 3 December 2010 (UTC)
Can we have $100,000? Felix Omni Signature.png 22:09, 3 December 2010 (UTC)
Doubt it, but it's worth a shot :P --El Nazgir 22:20, 3 December 2010 (UTC)
And just how would that help you regain your fansite status??? -- Wynthyst User Wynthyst sig icon.png talk 23:00, 3 December 2010 (UTC)
Bribe budget. Felix Omni Signature.png 00:32, 4 December 2010 (UTC)


This is awesome. Whoever made this possible is awesome. That's all. Thank you. Ethigenetic 20:42, 1 December 2010 (UTC)

We could only do it because the whole community was behind it. Now get the word out! --◄mendel► 06:27, 2 December 2010 (UTC)
I am sorry that it took Wikia behaving badly to get us to move. This new site already feels more like home than the old site did! Well done, Doc Ish, Felix, Mendel, RT, and everyone else who did the lion's share of the work to make this happen (coding, saving images, negotiating with Curse, scouting out new locations, keeping Wikia at bay while the work continued, etc and etc and etc).  — Tennessee Ernie Ford (TEF) 23:03, 2 December 2010 (UTC)

Meanwhile on Wikia

Browser screenshot - Which wiki was that again? o.O --◄mendel► 06:27, 2 December 2010 (UTC)

World of Warscape: Runiclysm Wiki. Can't you tell? It says so right on the top; if there's one thing the Wikia skin is knwon for, it's being clear about where you are.
Can't say how happy I am to be off Wikia. While I don't know that this'll affect my usual inactive activity level, one less tie to Wikia is worth celebrating! -- Jïörüjï Ðērākō.> 19:44, 2 December 2010 (UTC)
I say, embrace the change and make it work for us. Paid sponsorships of GW@wikia from the anti-wikia alliance?  — Tennessee Ernie Ford (TEF) 20:06, 2 December 2010 (UTC)
Hah! nice, I never see these backgrounds. Venom20 20:41, 2 December 2010 (UTC)
That is pure epic! -- Isk8.png Isk8 (T/C) 20:51, 2 December 2010 (UTC)
That's hilarious XD --Kirbman sig.png Kirbman 17:04, 9 December 2010 (UTC)

Even more ads in new places! --◄mendel► 20:29, 20 December 2010 (UTC)

Interwiki links

You can link to Guild Wars Wiki with e.g. gww:Jolvor Stoneforge; you can do the same with pvx: to link to PvXwiki, but to go to guildwars@wikia right now you need w:c:guildwars:. I suggest using wgw: for this (Wikia GuildWars), comments? Are there other sites you wish to link to easily, e.g. guru: or youtube: or whatever? (google: already works.) --◄mendel► 10:19, 3 December 2010 (UTC)

Would anyone who speaks Spanish be interested in inquiring at es: whether they want to set up mutual language links with us (we link to them, they to us)?

Also, somebody who speaks French (El Nazgir?) might inquire at fr: whether they'd change their en: interwiki to if we added links to them to all our pages?

What do you think about making "GWW" a language so that we can link to the official wiki from the sidebar? (Have a look at the Main Page sidebar to see what it looks like.) --◄mendel► 11:01, 3 December 2010 (UTC)

If you want persistent links to GWW, just install the page-top tab in common.js. Making that a language link doesn't make any sense. —Dr Ishmael Diablo the chicken.gif 13:24, 3 December 2010 (UTC)
The page-top tabs are not a logical place for this as they act on the present page. It would be possible to add an automatic link to the sidebar, even without javascript. The language links are a collection of links that lead to related pages off-site, that's why I think that gww: links would be ok there. The question is, do we want to? They're not linking to us. --◄mendel► 13:34, 3 December 2010 (UTC)
If they're not linking to us, then no, we don't need to edit all ~20k articles to add a link to them. —Dr Ishmael Diablo the chicken.gif 13:41, 3 December 2010 (UTC)
A good portion of the information on GWW is redundant with the information we have here- I see no reason to link to them on every article when it wouldn't be a useful addition. We could make a template to link to GWW for specific pages that they might cover in a better or different way- say, ArenaNet staff pages or armor galleries. Felix Omni Signature.png 14:59, 3 December 2010 (UTC)
While they may have official renders for armor/etc., I have heard many people say they prefer our in-game armor galleries. We are definitely deficient on staff pages, though. —Dr Ishmael Diablo the chicken.gif 15:14, 3 December 2010 (UTC)
I like ours better too, but there's no reason not to provide extra resources whenever we can. Felix Omni Signature.png 15:23, 3 December 2010 (UTC)
While I would love to help, and I disliked not being able to help with the move, but my French is terrible, especially written. I could try, but I'm afraid google translate would do better in an incredibly much shorter timeframe. I might be able to get some smaller mistakes out of google translate's version though.--El Nazgir 16:13, 3 December 2010 (UTC)

External links

You guys might want to look at,,, and linksearches and figure out what to do with all those. - 16:39, 8 December 2010 (UTC)

We've been discussing plans to run a bot to update those. Thanks for bringing this up here so we don't forget about it. —Dr Ishmael Diablo the chicken.gif 16:59, 8 December 2010 (UTC)
Have we decided on an interwiki prefix for gw@w yet? Some of these links will be to diffs and such and should point to now. Actually, I think we can just replace with most of the time. --◄mendel► 18:35, 8 December 2010 (UTC)
It would be better to changd all and to use the future-proof {{fullurl}} magic word. —Dr Ishmael Diablo the chicken.gif 19:09, 8 December 2010 (UTC)
Yes. --◄mendel► 21:03, 8 December 2010 (UTC)

We're moved! (Now what?)

So, Guild Wiki has finally obtained the independent, don't-tread-on-me hosting site it has desired since moving to Wikia. Huzzah! Long live Guild Wiki. But: now what?

It seems to me that there are any number of possible directions we can take:

  • Carry on. (Seemed to work for us so far, although there's no future for GWiki 2 on Curse.)
  • Step up our game (Compete more directly with GWW, even though we have trouble keeping up with the modest updates this year. Also: no GWiki 2.)
  • Complement GWW, instead of competing. (We already do better/different job in terms of walkthroughs, advice, innovation. Of course, done well, this would probably be bigger than the move.)
  • Squabble amongst ourselves about interesting and important, but non-critical issues. (Seems to occupy a big portion of recent edits.)

Are people ready to consider what's next? Or is everyone too exhausted from moving (and keeping GW@wikia safe from WikiaStaff) to worry about this now?  — Tennessee Ernie Ford (TEF) 23:07, 8 December 2010 (UTC)

I plan to continue implementing SMW across more classes of articles. I've simply been occupied with trying to get the last little things implemented that we need for the wiki to work how we want, as well as the normal real-life stuff that happens this time of year (read: stupidly-planned project deadlines that I had no say in setting but am now solely responsible for meeting). —Dr Ishmael Diablo the chicken.gif 23:19, 8 December 2010 (UTC)

Search box position

Should we move the Search box to be higher up? It feels awkwardly low, especially since its probably the box that gets the most use. Some lower resolutions even have to scroll down to see it. Let me (and the admins) know where you think it should be.

  1. stay where it is
  2. above the support box
  3. above the news box
  4. all the way at the top like it was in Monaco

I'm in support of 2, 3, or 4. --Kirbman sig.png Kirbman 17:14, 9 December 2010 (UTC)

We could remove the news box altogether, it's all on the main page anyway. Felix Omni Signature.png 17:20, 9 December 2010 (UTC)
Search should be high (useful to all). Command center should be at bottom (not useful to casual readers). Support should higher (somewhat useful to some). Toolbox should be higher (mostly useful to most). News should remain (not everyone visits main, especially frequent readers).  — Tennessee Ernie Ford (TEF) 17:55, 9 December 2010 (UTC)
Command center?
Agreed, news should stay. I haven't looked at the main page for information in years.
Imo, move Search to below Nav. Rest is fine to me. --Vipermagi 18:21, 9 December 2010 (UTC)
The "command center" is part of his custom javascript (based on mine).
Agreed, news is important because my default page is RC.
Agreed, search below navigation is a good place for it. —Dr Ishmael Diablo the chicken.gif 04:25, 10 December 2010 (UTC)
gww: has it between navigation and support; if we want to make it easy for readers to switch, we should go with option 2 or 3. --◄mendel► 22:34, 9 December 2010 (UTC)
I'm in support of #2.–User Balistic Pve sig.pngalistic 00:25, 10 December 2010 (UTC)
I'd be in favor of vector as default skin when curse is done it's fixing with the ads + all skins thing, the search is in the upper right hand corner such as UnAnswers uses. Though doesn't mendelbook have it there too? — Scythe 3:08, 10 Dec 2010 (UTC)
It definately needs to move up, since I have to scroll down everytime I want to use it.

I'm using a 10,1inch netbook with the standard resolution on it. Rook 16:51, 12 December 2010 (UTC)

I'm in favor of option 1. You'd need an extremely low resolution to have to scroll down for it... The navigation is more important, and search comes right after that imo.--El Nazgir 17:37, 12 December 2010 (UTC)
Oops, I should've mentioned here that I've already edited Mediawiki:Sidebar to put the search box below the navigation box (option 3 listed above). —Dr Ishmael Diablo the chicken.gif 17:41, 12 December 2010 (UTC)

Anti-Wikia Skin Alliance newsletter

moved to User:Anno1404/Anti-Wikia Skin Alliance newsletter

The AWA have sent us a letter. Since it doesn't "regard GuildWiki in general", I've moved it to User:Anno1404/Anti-Wikia Skin Alliance newsletter, and Gigathrash's comment to the talkpage there. Feel free to drop a short link paragraph here when new newsletters become available, but please do not assume that it will be a GuildWiki community matter. --◄mendel► 18:02, 18 December 2010 (UTC) (edited 22:08, 20 December 2010 (UTC))

We could say that the AWA is now looking for people who can help support admins and editors who have decided to move (but are having trouble making it happen). (Read the newsletter for details, if you are interested.) And hey, I just did! ^-^  — Tennessee Ernie Ford (TEF) 20:44, 20 December 2010 (UTC)

Overloaded (Curse) server

I've gotten overloaded server messages (from curse) 3 times in the last week (including today and yesterday). In one case (yesterday's), it was 15 minutes or more before I could view anything. Is anyone else experiencing anything similar?  — Tennessee Ernie Ford (TEF) 20:52, 22 December 2010 (UTC)

Never had any problems :S --El Nazgir 21:27, 22 December 2010 (UTC)
I had a curse message showing that there was maintenece or something. Went to bed short afterwards, so I don't know how long that lasted. Arnout aka The Emperors Angel 21:59, 22 December 2010 (UTC)
I had the same thing happen yesterday afternoon. After about 5 min, I just went off to do something else and came back later in the evening and it had passed. Nylana Greymoon 22:55, 22 December 2010 (UTC)
Happened to me a few times but always only lasted a minute or so. (So I herd we dont liek indents or wut) EM Signature.jpg ***EAGLEMUT*** TALK 23:34, 22 December 2010 (UTC)
Curse is working on it. Actually, that's part of the reason, because when the server configuration is upgraded, the caches are restarted, leading to a high load on the backend servers until things normalize again. --◄mendel► 23:35, 22 December 2010 (UTC)
Bryan was installing new servers and increasing the RAM in the existing ones yesterday, so that would explain any issues you encountered yesterday. He hasn't mentioned that the upgrade is complete yet, so if he was still working on it today, that would also explain today's issues. When the upgrade is complete, though, we shouldn't have any more performance issues. —Dr Ishmael Diablo the chicken.gif 00:08, 23 December 2010 (UTC)
That's good news. It would be great if Bryan et al could find a way to let us know before/during/after about any work that might affect performance. I have a lot of patience for planned maintenance; I don't have that much patience for spontaneous outages — and I cannot tell which is which without the kindness of administrative strangers. Thanks for the update, Ish.  — Tennessee Ernie Ford (TEF) 01:34, 23 December 2010 (UTC)
Bryan told us about it on IRC yesterday, right before the major outage started. If he had mentioned it sooner, I would've put something in the sitenotice, but since the site was already going under, I didn't have a chance.
We'll definitely mention this to him and ask that he give us more lead time in the future. —Dr Ishmael Diablo the chicken.gif 05:06, 23 December 2010 (UTC)
That would be good. I realize it might be difficult sometimes to alert all the curse clients at once, so mebbe they have some sort of sitewide notification service?  — Tennessee Ernie Ford (TEF) 05:24, 23 December 2010 (UTC)
I don't think this was Curse-wide, I'm pretty sure it was just us and PvX and maybe a couple other wikis. —Dr Ishmael Diablo the chicken.gif 14:11, 23 December 2010 (UTC)
Got hit again. Not sure how long it lasted because I don't bother checking anymore. I now assume that the outage will be indefinite and that I will have no way of knowing when or why it will be back up.
This is among the reasons it's important for Curse staff to put a timely notification system in place, targeted to whatever sites are affected by whatever planned operations on their schedule. There's simply no reason in the 2010s to leave the impression that a site is poorly maintained when the opposite is true. With a decent system, it won't add significant time to their change management process.
Wikia suffers from this same misunderstanding of customer/client/contributor communication: just because a company doesn't have an obligation to notify folks about system health doesn't mean it's smart to leave it to our imagination.  — Tennessee Ernie Ford (TEF) 01:25, 24 December 2010 (UTC)

(Reset indent) Today, I have seen some more Curse outage notices and, when I try to "Mark All Pages Visited" on my watch list, I get, "Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information." (this last is listed as a GWiki error; only the GWiki icon loads).  — Tennessee Ernie Ford (TEF) 19:56, 25 December 2010 (UTC)

I got that error when I tried to preview a change on Air Dragon (the change being the addition of a move tag). Only time I've encountered it. -- Konig/talk 20:05, 25 December 2010 (UTC)
I'm now getting "Servers temporarily at capacity" several times per day. Sometimes reloading resolves the issue; mostly not.  — Tennessee Ernie Ford (TEF) 16:52, 26 December 2010 (UTC)
I got the capacity error yesterday; it was the first Curse error I've seen. Felix Omni Signature.png 18:06, 26 December 2010 (UTC)
Same Felix, although when loading this page I got an overload error too, but when I clicked the "refresh page" button, it went fine.--El Nazgir 19:22, 26 December 2010 (UTC)
Have yet to run into errors except the one I mentioned here. EDIT: Viper here. Sig dun works? I guess that makes two errors. Checked prefs; nothing strange going on there. --<signature> 19:31, 26 December 2010 (UTC)
I'm glad other people aren't seeing errors as often as I am. However, I'm ready to give up posting/reviewing here for 1-2 weeks until I'm able to do so more reliably. I'm not seeing issues with other sites, with pings, or with other evidence that that there's an ISP issue or one internal to my home. I'm getting errors just trying to preview this.  — Tennessee Ernie Ford (TEF) 20:25, 26 December 2010 (UTC)
Just got a curse "server-full" error, while I was talking to Yamagawa on IRC about the show preview error (the same one TEF and Konig encountered) --Ezekial Riddle 01:17, 27 December 2010 (UTC)
I'm currently seeing about every 1 in 2 previews or edits fail on the 'Set $wgShowExceptionsDetails' error. Most annoying. Yamagawa 01:20, 27 December 2010 (UTC)
I am having errors in editing my user space page like the one Yama mentioned and the server overload one as well... Ariyen 02:54, 27 December 2010 (UTC)

502 Bad Gateway

I've gotten this error a LOT lately, at least 10 times over the past day or so. It happens when I try to save a page or revert an image, including rollbacks. It doesn't occur during regular browsing however.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 10:04, 3 January 2011 (UTC)

Ditto. Felix Omni Signature.png 12:24, 3 January 2011 (UTC)
Same. Also, editing this took a hell of a long time to load.--TalkpageEl_Nazgir 14:59, 3 January 2011 (UTC)
Same. It also seems like most of the time the edit does get saved, but not always. Rose Of Kali Rose Of Kali SIG.png 22:09, 3 January 2011 (UTC)
4 out of 5 more-than-read actions result in the 502 or connection reset error (i.e. I haven't seen an issue navigating to an article, only previewing, saving, or viewing diffs). (also: cannot tell if page has been successfully saved)  — Tennessee Ernie Ford (TEF) 04:03, 4 January 2011 (UTC)
Hmm, I don't think I've encountered it while previewing or viewing diffs, only when trying to save changes, i.e. changing something on the server that affects what other users see. If I get the error, I hit Back and open the page in a new tab to see if my edit got saved, and re-save if needed. Good thing FFox preserves all I typed in the edit box when going back. Rose Of Kali Rose Of Kali SIG.png 06:22, 4 January 2011 (UTC)
Same as Rose... Also: hurrah for Opera :P (but let's not derail this into a browser contest...)--TalkpageEl_Nazgir 09:04, 4 January 2011 (UTC)
Correction: Am now seeing it simply when navigating to articles (direct URLs, followed links, and searches).  — Tennessee Ernie Ford (TEF) 09:48, 4 January 2011 (UTC)
I even got it when mailing users here. Arnout aka The Emperors Angel 09:49, 5 January 2011 (UTC)
It seems to me its spiking again. Over teh past few days, I made more then a few edits, and some where double, because I got a 504, even though the edit was saved. And refreshing RC is getting troublesome too. Arnout aka The Emperors Angel 22:38, 8 February 2011 (UTC)


← Moved from User talk:Dr ishmael#ConfirmEdit

Hey doc, aren't we supposed to have that installed/running? --JonTheMon 15:12, 23 December 2010 (UTC)

No, mendel said it would "tone down the appeal of the wiki" by "discouraging anon edits," so we didn't have it installed. I'll push it to the repository, hopefully Bryan will check in today so we can get it pushed live. —Dr Ishmael Diablo the chicken.gif 15:42, 23 December 2010 (UTC)
Think that's going to stop the spammers/vandals much? Or rather stop anon edits? I know that on minor changes, if I'd run into those, I'd say "sod it" more often than not. --◄mendel► 15:43, 23 December 2010 (UTC)
At the very least, confirm edit can kick into gear for things like urls for anons. --JonTheMon 15:50, 23 December 2010 (UTC)
ConfirmEdit can be configured - we've already had this discussion. —Dr Ishmael Diablo the chicken.gif 15:57, 23 December 2010 (UTC)
I'm actually going to go with the reCAPTCHA extension, which is the same thing (it includes the ConfirmEdit code and simply builds on it) with a much stronger captcha. Bots could easily recognize and respond to plain-text math questions, which is the default in ConfirmEdit. The other options in ConfirmEdit mostly require additional server-side configuration, which we should avoid.
reCAPTCHA uses the same trigger settings as ConfirmEdit, and the defaults in the current version are as follows:
$wgCaptchaTriggers['edit']          = false; // Would check on every edit
$wgCaptchaTriggers['create']        = false; // Check on page creation.
$wgCaptchaTriggers['sendemail']     = false; // Special:Emailuser
$wgCaptchaTriggers['addurl']        = true;  // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true;  // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin']      = true;  // Special:Userlogin after failure
I don't see any reason to change these. Also, I changed group permissions for Users and (all) to remove the writeapi permission, since vandal-bots could easily use that vector to bypass all our other protection mechanisms. —Dr Ishmael Diablo the chicken.gif 18:02, 23 December 2010 (UTC)
Which groups should the captcha trigger for? By default I believe it's anons, new users and auto-confirmed. --JonTheMon 18:06, 23 December 2010 (UTC)
I'm setting it for anons only. We trust our registered users (and they're easier to block). —Dr Ishmael Diablo the chicken.gif 18:07, 23 December 2010 (UTC)
I just wonder if it'd help to have captcha true on say page creation and edits... Well, would that help against vandalisms and at least autobots? Ariyen 18:08, 23 December 2010 (UTC)
Take that up with mendel, he doesn't want to scare away potential editors. —Dr Ishmael Diablo the chicken.gif 18:11, 23 December 2010 (UTC)
Speaking as a potential editor of other sites:
  • I am 5% less likely to contribute the occasional edit to a site that requires confirmation (that goes up to 10% if CAPTCHA is the requirement rather than 4+5=...).
  • I am 1% more likely to register as a user for the same site if I find myself contributing more than X edits in Y weeks.
  • I am 70% less likely to contribute to the same site if I perceive it to be unable to handle vandalism.
So, while I agree with Mendel that we should err on the side of openness for anons, I don't think that adding a minor hurdle is going to scare aware well-intentioned folks.  — Tennessee Ernie Ford (TEF) 19:51, 23 December 2010 (UTC)
I registered at PvX to get rid of their obnoxious captcha (gotta type 2 skill 1-word names. Every edit. Ugh). I also contributed a lot, though. If I just wanted to make an edit a week or less, I'd rather just forget about it and not edit at all. --Vipermagi 20:25, 23 December 2010 (UTC)
To both Ernie and Viper: If the instructions for the captcha included a friendly reminder that you could completely disable them by creating an account, for free, with a link to the signup form, what would you do? I've already made that modification to the reCAPTCHA message that will be displayed to our anons. —Dr Ishmael Diablo the chicken.gif 21:12, 23 December 2010 (UTC)
I don't hate Captcha as much as Viper, but it would reduce my participation on a site slightly. I would not be inclined to sign up simply to avoid it. I use different logons for different types of sites, use multiple passwords, need to coordinate some sites across multiple machines, etc. So, for me, signing up is more trouble than it's worth for casual participation. Captcha, horrible as it is, is less trouble.  — Tennessee Ernie Ford (TEF) 21:27, 23 December 2010 (UTC)
As configured, an anon would only get the captcha for putting urls on pages, registering, and having bad logins. How do you two feel about those scenarios? --JonTheMon 21:40, 23 December 2010 (UTC)
The captcha for registering is almost standard practice, if someone has a problem with it they're going to be unhappy with most of the internet. The bad login one is reasonable, though I know if I typed my password in wrong once, I already feel frustrated at having to type it in again, let alone having to type something extra. Good thing I never get my password wrong, as I use Keepass (Thanks Doc!) As for the url one: does it apply to all external links, including gw@wikia, gww, wikipedia, etc.? Other than those, I don't see any reason why anyone would need to post a lot of external links on a lot of pages, so the captcha shouldn't be too annoying, and if someone feels the need to spam a link to their shoddy Gate of Madness "walkthrough" video on Youtube, well, they can deal with it. --Macros 22:46, 23 December 2010 (UTC)
If you use the interwiki prefix inside double-square-bracket notation, then no, those are not considered external links (even though they link to something outside the wiki). In this context, "external" links are those entered as an actual URL, optionally using the single-square-bracket notation.
The badlogin only shows a captcha after 3 failed login attempts, so if you just fat-finger it once or twice before realizing your capslock is on, you won't see it. —Dr Ishmael Diablo the chicken.gif 22:56, 23 December 2010 (UTC)
Oh, well, that's perfectly reasonable, from my point of view. --Macros 23:06, 23 December 2010 (UTC)
(edit conflict) Request more interwiki links if you need them, the admins can add them. Would an anon have to captcha if they edited a page with a URL already on it? -- 23:07, 23 December 2010 (UTC)
No, only if new urls are added. That's why the trigger is called 'addurl'. —Dr Ishmael Diablo the chicken.gif 23:10, 23 December 2010 (UTC)
The bad login captcha on pvx forced me to jump through hoops after I messed up my password once- it made me enter the captcha, then copy+paste a string of characters into a mysterious text box, then retype my user name, then retry the password. I wouldn't mind if we didn't have captcha for bad logins at all, the likelihood of people bothering to bruteforce a free wiki account is pretty low. Felix Omni Signature.png 07:07, 24 December 2010 (UTC)

Currently, pages being bot-spammed are mostly off the main (who sees the editcopy or the "recent discussions"?). So the main consideration here is, does the spam annoy more people reverting it than a captcha would annoy anons editing? How many reverts do we save, as opposed to the number of captchas anons would be exposed to? Can we get some numbers? --◄mendel► 08:44, 24 December 2010 (UTC)

It seems like you're still missing the point that this will only trigger when someone adds an external link to a page. (And once when creating an account, and after 3 failed login attempts). It will not trigger on every single edit. I'm not going to go data-mining to satisfy your paranoia, but I know it's very rare that we have an external link added to an article. —Dr Ishmael Diablo the chicken.gif 14:16, 24 December 2010 (UTC)
We currently have 1 to 1.5 new accounts per day (should be increasing if our traffic is rising), so that's a number to watch, then. I think spambot incidence is higher? - 16:38, 24 December 2010 (UTC)

Captcha on addexternal also kicks in when reverting a vandal who blanked a page with an external link on it. We should try to make sure we have no external links on mainspace pages by setting up enough interwiki aliases and using fullurl: . -- 18:33, 25 December 2010 (UTC)

You should create an account then. —Dr Ishmael Diablo the chicken.gif 15:47, 27 December 2010 (UTC)
What's wrong with the suggestion? --◄mendel► 22:09, 27 December 2010 (UTC)

(Reset indent) Ok, ConfirmEdit, yes/no? If yes, it'd be nice to get it pushed sooner rather than later. --JonTheMon 17:21, 27 December 2010 (UTC)

GW2-related articles

Since I heard that there would be no "Guild2Wiki" (or w/e the name would of been), I'm wondering if there's anything intended to be done with existing and future GW2-related articles (for instance, Zhaitan, Sylvari and pretty much everything here). Just wanting to know because I'm beginning to go through lore articles here like I have on the official wiki for a while, and removing speculation/inaccuracies that are presented as facts (a common reason for not using the GuildWiki for lore purposes), and I wanted to know where to stop with my edits to articles. -- Konig/talk 20:11, 25 December 2010 (UTC)

I think only the stuff that's relevant to the current game should be here, but once it gets out of the scope of GW1, it should link off to GW2W. A small intro type paragraph and a single image is the most GW2 info that should ever be seen on those pages, such as Zhaitan. And only the most important GW2-related pages should exist here if they have little to nothing about them in GW1. Rose Of Kali Rose Of Kali SIG.png 04:50, 27 December 2010 (UTC)
/agree with Rose.--El Nazgir 08:06, 27 December 2010 (UTC)
I don't like breaking up the lore and spreading it across two wikis with reference to some decision that AFAIK has never been formally made (and it would IMO be too early to). --◄mendel► 22:07, 27 December 2010 (UTC)
I also don't like breaking up lore if possible. Though I'm not concerned with expanding lore information here, I just want to get rid of speculation and this became a curious thing I was wondering about. The template seems very unnecessarily page-breaking (especially for those like norn which have it mid-way). I'm not against the idea of going all-out for lore for articles relevant to both gw1 and gw2, but it seems silly to have articles relevant only to gw2 here.
And that template... *wishes to stab it*-- Konig/talk 00:37, 30 December 2010 (UTC)

Templates and unregistered users

What do you think of semi-protecting all templates from unregistered users? One vandalism has the potential to break hundreds or thousands of pages where the template is used until it's reverted, and most if not all templates are maintained by a handful of our regular users, while rarely (if ever) receiving useful edits from IP's. This is stemming from spambot edits like this. And while edits like these usually get caught quickly and taken care of, I don't see a reason not to semi-protect mainspace templates. Rose Of Kali Rose Of Kali SIG.png 16:48, 27 December 2010 (UTC)

That specific template probably should be protected, since it is used on the Main Page. Most high-usage templates are already protected at the admin-only level. There's no pressing need to protect all the thousands of other templates that aren't so highly visible. —Dr Ishmael Diablo the chicken.gif 17:02, 27 December 2010 (UTC)
I think we should leave things unprotected until there's a compelling reason to protect. The particular edit you link would have been prevented by the plan (above) to ask for validation from anon edits that add an external URL. If templates start to be hit so frequently that we can't keep up, then we can temporarily semi-protect (and discuss permanent semi-protect). In the meantime, I think we do damage to the wiki's openness and inclusiveness every time we protect something. Not a lot of damage, of course, but those qualities are two of the things that set us apart from other wikis.
It's worth reviewing all the templates used in main-space and the few that are used on lots of pages; some of them might be appropriate to restrict to admins (as Ish notes) or registered users.
I also think we should re-ask this question every 4-6 months; bots get smarter, sysops get busy, contributors focus on other things.  — Tennessee Ernie Ford (TEF) 17:09, 27 December 2010 (UTC)
I think the templates that are used for like say mainpage/editcopy or main pages should be protected from Ip vandalism... As I fear it could hurt many pages, if a vandal does ruin a template and cause issues/problems. Ariyen 17:22, 27 December 2010 (UTC)
Right, I agree with all of you. I guess I wasn't really meaning all the obscure templates on the entire wiki, but mainly the high traffic ones that are used on the main page and similar high traffic pages. I also think that the highest level armor gallery template should also be protected just due to the sheer number of image galleries involved, which would all be getting recached and re-recached after each change, though that might not be as big an issue as I think (is it?). Keep in mind, I'm not asking admin-only level protection, only IP block. If you prefer to keep this to a case-by-case decision, that'll work as well. Rose Of Kali Rose Of Kali SIG.png 17:34, 27 December 2010 (UTC)
Protecting specific high-visibility templates is exactly what I think we should do - I should've made my position on that more clear above. —Dr Ishmael Diablo the chicken.gif 17:59, 27 December 2010 (UTC)
Now just to figure out what those are, aside from the ones that are already protected. I guess that'll just come along as we notice them. The one I linked is a start. Rose Of Kali Rose Of Kali SIG.png 18:55, 27 December 2010 (UTC)
We want unregistered users to participate as much as possible, and I seem to recall constructive template namespace edits do happen. In this case, the temnplate gets edited because the page got protected - if you want to fight this battle, be prepared to end up protecting most of the wiki, because a vandal always finds a place to vandalize. Wikis used to work by making it more easy to fix vandalism than to commit it - by entering the "protection fight", you are giving teh vandal attention and an objective of interest, and that's precisely what you want to avoid: you want to bore him into editing the same page and the edit always getting reverted without further reaction shortly. Most other approaches are less effective, in my opinion.
High visibility pages can be protected (if desired) with cascading protection (or do we not have that here?) which automatically protects all templates on it, and would presumably un-protect them once the originating protection is removed.
High use templates (those used on hundreds or thousands of pages) have long since protected. --◄mendel► 22:04, 27 December 2010 (UTC)
High use does not necessarily equal high visibility, as in the above example, but both types deserve protection. I think you are overly protective of the few constructive edits that were made by anons to high visibility/use templates (I'm not saying they never happen, but most of those templates are finalized and should rarely need any edits at this time). I don't want to get on the slippery slope and start protecting everything on the wiki, that's not the point. There's "don't feed the troll" and there's also "don't leave the pantry door open." I'm just trying to find a reasonable balance between risk and merit. Rose Of Kali Rose Of Kali SIG.png 22:27, 27 December 2010 (UTC)
The editcopy page is neither high use nor high visibility, yet it got protected.
My point re: high-use templates is that the discussion is pointless, these have always been protected and still are.
My other point is that if you want to protect high-vis pages, do it right instead of piecemeal (i.e. Template:Copyright should not have been protected separately, unless we don't actually have cascading protection, in which case we should get it).
How much is "overly protective", and why am I it? Please answer this on my talkpage. --◄mendel►
Then let's do it "right" if the feature does exist. The point of these discussions is to find the best solution to things. :) Rose Of Kali Rose Of Kali SIG.png 22:45, 27 December 2010 (UTC)
I'd say the edit-copy is pretty high visibility, and I'd agree with protecting it from anons. --El Nazgir 22:50, 27 December 2010 (UTC)
"This page has been accessed 280 times." This statistic is found in the footer of the page; I don't really know how accurate it is, but according to it, there are right now 269 pages more popular than it is. --◄mendel► 06:59, 28 December 2010 (UTC)
Of course we have cascading protection, mendel, it's a core feature of MediaWiki. The problem with enabling it on the Main Page is that you can't pick-and-choose which transcluded pages get cascaded - it's going to protect everything that's transcluded there, which means all of the "forecast" templates, and specifically, the Traveler one, which needs to be updated every week. And over the past 5 weeks, 3 of those updates have come from anons. —Dr Ishmael Diablo the chicken.gif 23:30, 27 December 2010 (UTC)
I agree with Rose's suggestion that we should handle protection on a case-by-case basis. When in doubt, mention the discussion here to invite more opinions. There are potentially other solutions, too, e.g. validation (to prevent bot edits).  — Tennessee Ernie Ford (TEF) 03:37, 28 December 2010 (UTC)
The case-by-case is exactly what's happening: we protect the mainpage, so the vandals go for the editcopy; this effect is intended. Once the editcopy got protected, the vandal went for a template transcluded on it, which also affected the mainpage (which is worse, actually). Protect that one, what's he going to do then? We can't "close the pantry door", as Rose says, because we're a wiki, and everyone can edit. We can direct vandalism; by protecting it, we do direct it; but by doing these protections case-by-case, we're not really making ourselves aware of this going on.
Taking a closer look, many sysops seem to be aware that what is closed must eventually be opened again, time-limiting their protections. This is good. --◄mendel► 07:32, 28 December 2010 (UTC)
I think part of doing a case-by-case basis is identifying what kind of vandal source we're talking about. If we're talking about a person maliciously editing, that's one thing, and it's hard to keep up. If it's a bot, we can implement tools to stop/stall them. As this seems to be bot-like behavior, I think some spam/vandalism extensions would be sufficient. --JonTheMon 15:51, 28 December 2010 (UTC)
If the vandal is going to vandalize anyway, and we're gonna be reverting him anyway, might as well be on something less in the face of the readers, but kind of behind the curtain, if you will. So I still absolutely think that we should protect as much as possible of what shows up on the main page. And while it would be bad to protect the Nicholas' and other forecast templates that need frequent updating, I recall a few cases where users were commenting about some weird item Nick is asking for because the template was tempered with, and stayed cached a while after the vandalism was reverted. I admit that I know next to nothing about this sysoping/protecting/blocking stuff, but the least I can do is bring it up for discussion. If you guys can recognize some kind of pattern in what these vandals are doing and somehow screw it up, that would be great. If not, we're left with dealing with the symptoms rather than the cause. "Bad" external links are definitely worse than just gibberish vandalism, so they deserve the most attention. Is it possible to block external links being added by anons to specific pages, without blocking other anon edits, or blocking/forcing validation of external links being added by anons on the whole wiki? I noticed there's a "blacklist" of external links, but is there anything more that can be done, if semi-protection isn't an option? Rose Of Kali Rose Of Kali SIG.png 16:36, 28 December 2010 (UTC)
While some things may be okay for Ips, etc. to edit. I think other things that have a bigger "effect/affect (not sure which word to use there)" should be left to the registered users to edit. By this, I mean things like the Traveler, etc. I don't think things like the traveler template should be permanently protected to where only the sysops should edit them, but I know they can be protected enough that the users, etc. can edit them. While this may deter the Ip edits a bit, I don't think it'd hurt all that much. Ips can leave comments as to where he is or register to edit where he is and even may upload an Image of his location. This would help deter a little bit of the vandalism. Maybe we should create a list of what should be protected and to what extreme? I would like to see an extension that would detect the site links and not allow any of that, unless it's sites we already have in a list that we'd allow like youtube, facebook, mmorpg, guru, etc. Thoughts? Ariyen 23:43, 28 December 2010 (UTC)
You may be onto something here, Ariyen. Is it possible to disallow IP's to link to external websites except for a certain "white list" like the examples Ariyen gave? All non-white list links would then have to be validated, or the IP would have to register and log in. Rose Of Kali Rose Of Kali SIG.png 01:40, 29 December 2010 (UTC)
mw:Extension:ConfirmEdit and mw:Extension:Spam blacklist, both of which are now installed here. —Dr Ishmael Diablo the chicken.gif 02:28, 29 December 2010 (UTC)
Most other websites we would wish to link to can get "interwiki" links (such as google:) that allow anyone to form links that we can possibly get to keep working even if the site layout changes. These don't count as external links and can be placed by anyone. Indeed we could hack it so that www: would just be http://www.$1 and that would allow any editor who knows about this to linkt to pretty much any website, but nots would be to "stupid" to do that. --◄mendel► 14:32, 30 December 2010 (UTC)

fansite redux

So, is there any news on us getting our fansite status back? --El Nazgir 22:51, 27 December 2010 (UTC)

No, but if everyone is comfortable with the current state of the wiki I will request a preliminary review from the CR team. Felix Omni Signature.png 22:55, 27 December 2010 (UTC)
If there are any anti-spambot measures left to put into place, it might be wise to hold off until that's done. Having things like this in RC would likely not reflect the best on us. Though I'm not entirely certain that it would prevent qualification, either (unless some of these bots were posting RMT links...) — ızǝ 07:17, 28 December 2010 (UTC)
True, but I personally haven't got a clue what we can do against spambots other than reverting them, seeing as their IPs constantly change.--El Nazgir 09:41, 28 December 2010 (UTC)
I'd also like to make sure these Curse errors have settled down gone away. Felix Omni Signature.png 10:17, 28 December 2010 (UTC) (fixed that for you, --◄mendel► 00:14, 29 December 2010 (UTC))
How about something that blocks linking posts from IPs. If we wanted to make it useable for well-intentioned anons then we could just do something like pile them somewhere for review, and create a blacklist filter (is that even possible?) — Scythe 1:07, 29 Dec 2010 (UTC)
mw:Extension:ConfirmEdit and mw:Extension:Spam blacklist, both of which are now installed here. —Dr Ishmael Diablo the chicken.gif 02:28, 29 December 2010 (UTC)
I haven't encountered any errors in a couple of days. I know the ArenaNet staff doesn't work on weekends, so I'll submit a request for review on Monday unless something terrible happens. Felix Omni Signature.png 23:13, 30 December 2010 (UTC)
I'm still encountering errors at about the same frequency as before. Also, Regina mentioned that the person replacing Emily as GWW liaison (and related community relationship duties) was out until early January, so it's possible that we might have to wait a while.  — Tennessee Ernie Ford (TEF) 00:00, 31 December 2010 (UTC)
Regina is the person I talked to regarding fansite status in the first place. She and the other CR managers (Martin and Stephane) are in charge of it, not Emily. Felix Omni Signature.png 02:45, 31 December 2010 (UTC)
Since we still have our fair share of errors, I'm going to hold off on requesting review. Felix Omni Signature.png 12:24, 3 January 2011 (UTC)

anon edit confirm for URLs

Decided to start a new topic from the above two. So here's what I'm thinking: Add a CAPTCHA Edit Confirmation to anon edits that add URLs. Also add interwiki links to common "good" sites, such as google, youtube, etc. (We'd have to expand and implement the interwiki list before going forward.) There's a good possibility that anons will not be familiar with some or all interwiki links, so add a note to the "you're adding a URL" error message with a link to interwiki links list, so that anons can easily discover them and use them in the future without having to enter the CAPTCHA again.

This pretty much completely takes care of IP link spam bots. (Sure, the bots can modify their spam to use (dot) or otherwise avoid the captcha trigger, but then the link becomes unclickable, which is a ton better than clickable spam in my books.) It also affects a small number of "good" anon edits, and only adds a simple step in the case that they're wanting to add some oddball external link, without completely blocking the edit. Am I understanding this correctly?

Yay? Nay? Maybe? Any modifications? Rose Of Kali Rose Of Kali SIG.png 16:26, 30 December 2010 (UTC)

If how you're saying it is correct (although I'm not familiar enough with the terms to fully understand if I'm afraid :S ), I can get behind that.--TalkpageEl_Nazgir 16:49, 30 December 2010 (UTC)
Like I said above: we already have this. And I don't think we should abuse the interwiki feature, either. If anything, we should be encouraging anons to register instead of dumbing-down the wiki for them. —Dr Ishmael Diablo the chicken.gif 16:55, 30 December 2010 (UTC)
Oh, is the CAPTHCA enabled? And I was talking in the spirit of encouraging anon edits without encouraging them to register, because you know why. Though, for me personally, seeing fewer ads is reason enough to log in. :P There's a long list of pros to registering, but we all already know this.
I don't know if I'd call that "abuse" of the interwiki feature, but it might just be that I don't know enough about it. Rose Of Kali Rose Of Kali SIG.png 18:54, 30 December 2010 (UTC)
Curse has ads for logged-out users only? That's neat, I didn't know that. Is it true? --◄mendel► 21:52, 30 December 2010 (UTC)
Currently, we have no ads at all. That may change soon, though. —Dr Ishmael Diablo the chicken.gif 22:04, 30 December 2010 (UTC)
Curse doesn't have ads? O_O Neat! But you're just making fun of me now, so forget the whole thing. Rose Of Kali Rose Of Kali SIG.png 22:57, 30 December 2010 (UTC)

Tabs to Wikia

I think it's great that we can easily link to GWW, but why do we want to link to Wikia? In fact, I would go so far as to say I don't want us to do anything to direct traffic to GW@Wikia. I don't think there's any value for Guild Wiki in doing so. I can see that we discussed the GWW links, but I don't see where we discussed (and agreed) to link to Wikia. Could we have the tab removed pending consensus on whether it should be there or not? Thanks.  — Tennessee Ernie Ford (TEF) 08:50, 13 January 2011 (UTC)

I agree with TEF on this one.--TalkpageEl_Nazgir 11:30, 13 January 2011 (UTC)
Um, you copied that .js code from me. That's not on our Common.js. —Dr Ishmael Diablo the chicken.gif 13:41, 13 January 2011 (UTC)
Sigh. Well a big d'oh from me and a big apology to everyone for my confusion. (And, yeah, obviously, the wikia tab can be very useful to individuals for a variety of reasons). Thanks, Ish, for clearing up my misapprehension.  — Tennessee Ernie Ford (TEF) 17:17, 13 January 2011 (UTC)

Tabs to GWW

As I've mentioned elsewhere, I like that we have a tab pointing to similar/corresponding articles on GWW. I have two questions:

  1. Should we adjust our pointer to go directly to the correct article? Or is it ok if we point to a redirect page?
  2. How do we fix things when we know that we are pointing to a non-existent page? For example, we have Rabbit Valley, but they have GWW:Rabbit hole to refer to Nulfastu's little zone of weirdnesss. (And they do not have a redirect from Rabbit Valley.)

I'm sure there's a simple bit of code that can be placed on the page to fix these things, but I can't find it. Thanks.  — Tennessee Ernie Ford (TEF) 08:54, 13 January 2011 (UTC)

I vaguely recall that some time ago (when GWW was still in its infancy), someone (maybe Entropy?), was trying to create a system where you could click a tab or something on the sidebar that would link to the page of the exact same name on GWW (probably using {{PAGENAME}}). It was in their personal .css, not sitewide. I don't know if it ever worked, but it sounded pretty simple (even by my standards!) But of course, as you mention, the problem would be with pages that don't exist on GWW. Would they object to simply creating redirects corresponding to names we use here? Or the other way around, the link would be to a page here on GuildWiki with the same name as the one on GWW, and that would redirect to GWW... or something like {{DEFAULTSORT}} for redirects... or something. --Macros 09:52, 13 January 2011 (UTC)
When Cleo's job is finished, we can just take another copy of the language links, and any instances where there are special cases for gww and us are those where the naiming differs, pretty much; there's going to be fairly little remainder that won't work.
I don't know where the name correspondence list ist going to be kept; it's been my suggestion to implement it as another type of langugage links, but that didn't seem to be favored at the time. If you're editing on gww: anyway, why not get support for redirects there; since wikis are not paper, it won't hurt to have those redirects on any wiki (there'd be redirects here for the switch back, too), and that'd solve your problems without much ado, all that's needed are two complete lists of mainspace article names each (one with redirects, one without), and the issue could be solved.
Also, I might point out that "we" do not have a tab; it's an undocumented personal JS installable option that few people use; it could be made into a preferences option with some skin work, or installed sitewide; but for that, the feedback was that we wouldn't link to gww: if they didn't link to us. Reconsider? --◄mendel► 11:44, 13 January 2011 (UTC)
I never understood the need to link to GWW in the first place. The large majority of articles are very similar, and since we are both encyclopedic, we are in direct competition with each other. I don't think it needs to be reconsidered, as linking to them doesn't provide any actual benefit. The articles that we have very little information on, they have very little information as well. And the articles that GWW has that we don't are mostly developer blogs and the like that we don't have pages for anyway, and thus we would have to create an empty page to support a tab that leads to a different website.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 14:25, 13 January 2011 (UTC)
We have users who like to consult both wikis. Suggested strategies differ, gww: has more pages and more info, especially on the recent War in Kryta content; if we were a commercial concern, we'd focus on getting that content up to speed before filling little used landmarks in; but since we're just a bunch of hobbyists, that's perfectly ok :). Because we're a community driven project and like to allow minorities to put their stiff on here as long as it doesn't get in the way of everyone else, obliging the minority (is it?) who wants to see these cross-links is what we ought to do, even if you personally don't see a benefit. I doubt that there are GuildWiki readers who are not yet aware that gww: exists, so I don't see the harm done. --◄mendel► 15:51, 13 January 2011 (UTC)
I won't allow any minority stiffs around here. Felix Omni Signature.png 16:07, 13 January 2011 (UTC)
"Undocumented"? This begs to differ. —Dr Ishmael Diablo the chicken.gif 15:01, 13 January 2011 (UTC)
Well, for it to be a community feature, I'd expect a notice how to enable this in a place more prominent than that (e.g. on the Community Portal). And since we're talking about this here, is it to be considered a community feature? Or do we want it to be in the future? --◄mendel► 15:51, 13 January 2011 (UTC)
"I like that we have a tab pointing to similar/corresponding articles on GWW." No, *we* don't. You have it because you copied my monobook.js, just like the Wikia tab above. —Dr Ishmael Diablo the chicken.gif 15:00, 13 January 2011 (UTC)
(1) Well apologies again. So, we don't have the tab.
(2) Undocumented? Who said that? "I'm sure there's a simple bit of code that can be placed on the page to fix these things, but I can't find it. " Thanks for providing the link.
(3) I think we should have such a tab, but that's a different discussion; please don't hijack this one b/c I got confused between what was in common.js and TEF.js. I think it's a good idea, but I don't think it's urgent (I'd personally prefer that we consider what type of wiki we want to be). (@Mendel: we did start a discussion about this; it just never included a so, let's implement it sentence. The opinions were basically the same as listed here.)  — Tennessee Ernie Ford (TEF) 17:32, 13 January 2011 (UTC)
Following up, I don't see that there is currently any way to fix the pointer from GWiki to GWW by adding a simple bit of code. If it points to a redirect page, well, hey, that gets the job done. If it points to a non-existent page, we have the option of creating a re-direct (which I will do for the aforementioned Rabbit Valley). Since I was so obviously wrong about, well, everything, let me know if I misunderstood this bit, too.  — Tennessee Ernie Ford (TEF) 17:36, 13 January 2011 (UTC)

(mission) / (location) / (explorable)

While working on the new location infobox, my attention has been drawn to the way that we disambiguate missions, mission outposts, and explorable areas that share the same name. This isn't my first involvement with this issue, either: 2.5 years ago, I undertook the task of making them compliant with GW:ULC (e.g. converting (Mission) -> (mission)).

A similar proposal to the one I'm going to make has come up before, and while it was mostly shot down back then, I think the time is right for us to reconsider it.

The changes I'm proposing are as follows:

(location) -> (outpost)
According to the location article, we use "location" as a generic term to cover a vast swathe of topics. Identifying an article as (location) really doesn't provide any useful information about what exactly the article is about.
(mission) removed completely
Currently, [<name>] redirects to [<name> (mission)]. The argument for this was that "most people who search for <name> are looking for info on the mission." If so, then why bother with the redirect at all? Just put the mission article at <name> so that it's simple to write links to it.
(explorable) clarified to the full terminology -> (explorable area)
Not as serious as the others, but I think it makes sense to do so.

Some of you have probably noticed that these changes will put our naming schemes in line with GWW's. It seems to me like there's been increasing interest lately in making it easy for readers to switch between different wikis (e.g. interlanguage links to the German GuildWiki). By undertaking these changes, we eliminate the most visible disconnects between GuildWiki and GWW, making it easier for us to recommend the GWW switch tab to a broader range of readers, if they wish to use it.

I will of course volunteer to perform all the link updates through AWB, should we agree to go ahead with any or all of these changes. —Dr Ishmael Diablo the chicken.gif 22:09, 14 January 2011 (UTC)

Short version: I have no consensus-blocking objections (I disagree on only very minor points).
Long version: I think there are other, more serious issues to resolve (e.g. we're missing details about WiK, HotN, accurate maps, ...). However, I think reviewing the standards we use and adjusting is generally worthwhile, especially when we are updating associated templates/info boxes.
  • Yes.png (location) → [specific]
I can't think of any reason that we should use (location)
  • Maybe.png (mission) → remove
What's the harm in keeping a redirect? I sometimes find it faster to fix the URL (e.g. outpost → mission) than to search for a link, so it's also vaguely useful.
  • Maybe.png (explorable) → (explorable area)
I don't see any benefit for GWiki, but I agree there's some benefit to readers of both; it makes GWiki → GWW links easier.
See also: name similarity matrix. (@doc ish: that last might be vaguely useful for Services)  — Tennessee Ernie Ford (TEF) 01:22, 15 January 2011 (UTC)
I don't have any objections. I'd be glad to be of help, though. :-) 10:16, 15 January 2011 (UTC)
I agree fully with TEF. First is complete agree; second I say keep redirect; third is not necessary but definably helpful. -- Konig/talk 12:20, 15 January 2011 (UTC)
Since we (read: everyone who took the time to comment) are unanimous on (location) -> (outpost), I'm going to try to get started on that tonight. —Dr Ishmael Diablo the chicken.gif 22:30, 18 January 2011 (UTC)
Bah, didn't have time tonight. Won't have time tomorrow. Bah. —Dr Ishmael Diablo the chicken.gif 04:23, 19 January 2011 (UTC)
Okay, I'm going to make the moves while at work today. I can't run AWB from here, so I'll just compile a list of all the pages that link to the moved pages and fix them from home tonight.
In connection with this, we should probably rename Mission location to Mission outpost for the same reason - "location" is not specific enough, it could refer to either the outpost or the zone. —Dr Ishmael Diablo the chicken.gif 16:24, 27 January 2011 (UTC)

Fatal Error

I received this error, " Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 22136 bytes) in /home/guildwiki/public_html/includes/media/Bitmap.php on line 213 " when I tried to view the category of Guild wars screen capture license... I was actually trying to find icons for like the Kurzicks, etc. Ariyen 03:37, 21 January 2011 (UTC)

Canthan New Year

I strongly suggest imediately copying the background (and perhaps more) from de:, might as well make the most out of the fact that we share the same open content license. --◄mendel► 21:38, 3 February 2011 (UTC)


We now have Gadgets enabled on the wiki. These are similar to Widgets, except that instead of providing parser extensions to use in specific locations, gadgets have a global and persistent effect and are enabled on a per-user basis.

Currently, we have 3 gadgets installed:

  • GuildWarsWiki Switch: Adds a page-top tab providing a link to the article of the same name on Guild Wars Wiki.
  • RC Hide User: A small utility that lets you temporarily hide all edits by a specific user on Special:RecentChanges.
  • UTCLiveClock: A clock in the personal toolbar that shows the current time in UTC and acts as a purge link for the current page. Useful for knowing exactly when the next finale event is going to start.

To enable them, go to the "Gadgets" tab in your preferences.

Feel free to suggest ideas for additional gadgets. For starters, you can check out the gadgets currently in use on Wikipedia and Wikimedia Commons.

Admins: The "master" page for gadgets is MediaWiki:Gadgets-definition. Special:Gadgets provides convenient links to all gadget component pages.

Dr Ishmael Diablo the chicken.gif 01:56, 9 February 2011 (UTC)

Cool. Thank you.  — Tennessee Ernie Ford (TEF) 02:34, 9 February 2011 (UTC)
Great! --◄mendel► 11:46, 9 February 2011 (UTC)
Could it be at all possible to move the clock to the left side of the personal links as poke's done? On the right it's kinda...out of the way. :| — Scythe 22:27, 10 Feb 2011 (UTC)
It's possible, but it would require quite a bit of tweaking. Get more people to comment here and ask for it, then I might do it. :P —Dr Ishmael Diablo the chicken.gif 23:21, 10 February 2011 (UTC)
comment asking for it More People
Smooth scythe, real smooth :P --TalkpageEl_Nazgir 00:06, 11 February 2011 (UTC)
That's not nice. Pretending to be the "voice" of more people? I like the Gadgets, but what kind of tweaking would it need? Just curious. Ariyen 00:07, 11 February 2011 (UTC)
Actually, I quite like the larger font and the rightside :)–User Balistic Pve sig.pngalistic 03:27, 11 February 2011 (UTC)

Templates and pages

I don't feel the need of having this <includeonly> (category) </includeonly> on a template. Most templates, that could use that. Don't. I felt the obligation to go with the most templates and have the rest of them be the same/similar. And add the needed categories to those pages. I don't think there'd be more. The only things I feel would be more would be the additional content to go after War In Kryta. I don't see that much being added other wise and so I don't see the "issue" that's been raised on my talk page. I am bringing this here to ask the community. Would you prefer templates to add in all categories? (I would rather see ItemInfo do that - instead of a navigation template - so one could (like me wanting to use the sweets nav) use them on their user page, etc.) or them be added separately so that the pages could have all the correct categories needed. Ariyen 19:24, 13 February 2011 (UTC)

I don't think that there's anything that we need to urgently change about how we use templates and info boxes for categorization. If there's an issue with a specific auto-cat method, let's bring it up for the specific situation. For example, if the info box has been updated to allow categorization after the creation/addition of a temple, it might make sense to move cats into the info box and out of the template.
  • "Should categories be automatically tagged to articles via the use of templates and/or info boxes?" Yes, absolutely.
    • "When should we tag via info boxes? When via templates? " That depends on the situation. The answer is more a matter of art than of science. This should be handled on a case-by-case situation.
  • "Should categories be manually tagged by users?" No, not unless absolutely necessary; it's better to adjust templates and info boxes whenever possible.
    • "Doesn't this make editing of categorization less user friendly?" yes, but that is a small price to pay to protect the wiki's overall categorization. It's easy for someone unfamiliar with the category tree to make well-intentioned mistakes; heck, it's easy for those familiar to make mistakes. Protecting categories is no different from protecting important articles.
 — Tennessee Ernie Ford (TEF) 19:39, 13 February 2011 (UTC)
So if some Navs are wanted to be on user pages. They'd have to put up with the "Auto tagging" of cat. on that user page? Ariyen 19:42, 13 February 2011 (UTC)
No, then I think we should create different navs for user pages. Those navs were created for main space, not for user space. (I suspect that there is a sneaky way to code them so that they get auto-tagged in Main, but not in User, but I have no idea how to do that.)
If that's the only concern, it's far easier to create a second template (even one that transcludes from the current one); it's far harder to change dozens and dozens of articles to make the square template fit into the round hole.  — Tennessee Ernie Ford (TEF) 19:49, 13 February 2011 (UTC)
Creating additional or different navs.. I disagree with, not everyone would know how to do that. I also don't think the navs could be messed up and if a potential hazard - can be blocked to be edited by admins only and suggestions be on talk pages.
Now, if there's a way to create a code to where the cat is only tagged to teh actual pages, then I'd be okay with it and not raise this "concern" and I'd be willing to put categories into the navs and remove them from the pages. Opposite of what I have done. Ariyen 19:56, 13 February 2011 (UTC)

(Reset indent) To clarify, the question is, given the choice (i.e. an appropriate navbox or infobox actually being on an article), should a category be assigned via

  1. the infobox
  2. the navbox
  3. wikicode on the page?

I think it would be good to arrive at an "official" order of preference and clearly state it.

As a secondary question, should infoboxes/navboxes be made to be includable on user pages, i.e. the category be protected by a namespace condition so only mainspace or GuildWiki: pages get categorized?

it's far harder to change dozens and dozens of articles to make the square template fit into the round hole -- easy bot work, methinks, especially if the category already exists.

Tip: cleaning up Special:WantedCategories goes a long way towards finding mistakes. --◄mendel► 20:53, 13 February 2011 (UTC)

I agree, been trying to clean up the wanted categories for pages first... Ariyen 21:00, 13 February 2011 (UTC)
Ok, first, wtf ariyen? Second, what's the big deal if both the nav box and the infobox both set the same cat as long as they don't conflict? Third, nav box categories tend to be less likely to be red-linked since they are usually hard coded. Fourth, all this is due to wanting to use mainspace templates in userspace? That's easily duplicated (can be changed from main to user version easily) or the cats could be namespace aware. Fifth, ariyen, why didn't you come out and ask for a potential solution before coming up with your own, knowing it would affect terrible, terrible damage many, many pages? --JonTheMon 23:09, 13 February 2011 (UTC)