Guild Wars 2 Wiki talk:Requests for technical administration/archive

Wikipedia

We need to set up interwiki to link to Wikipedia, sort of like on GWW.

Reason

Very useful for trivia sections and anywhere else to linking on Wikipedia.

Possible pitfalls

Umm, there are none? — ク Eloc 貢 22:30, 3 January 2008 (UTC)

Um, wikipedia:Main Page? Lord Belar 22:37, 3 January 2008 (UTC)

PWNT RT | Talk 22:49, 3 January 2008 (UTC)

Ok, it didn't work last night. — ク Eloc 貢 22:51, 3 January 2008 (UTC)

Oh, and we need it still to be set up to just type W as a prefix. — ク Eloc 貢 22:53, 3 January 2008 (UTC)

Bump? Could we get it so your can interlink like GWW by just using W: at the beggining of it? — ク Eloc 貢 15:40, 23 May 2008 (UTC)

These too, please :) -- pling | ggggg 15:54, 23 May 2008 (UTC)

Website logo

On GWW, the logo looks like , while here on GW2W, it looks like . Could we get the logo here changed to something better and more Guild Wars related? — ク Eloc 貢 00:09, 26 May 2008 (UTC)

I think Emily said they were creating a new GW2W one; check her talk page on GWW (or archives). -- pling | ggggg 01:20, 26 May 2008 (UTC)

Well, it is Guild Wars 2 related (it's a two and it is basically the same shape as the logo on the left) poke | talk 23:50, 26 May 2008 (UTC)

Oh shit, I never noticed that it was a 2. lol. But still, I think it should be made into something better, and maybe a little more obvious. — ク Eloc 貢 02:34, 27 May 2008 (UTC)

Delete Gw1:Guild Wars Utopia

Reason

The page exists at a currently invalid page name, it cannot be accessed, however it still listed in Guild Wars 2 Wiki:List of candidates for deletion, Guild Wars 2 Wiki:List of candidates for deletion and Special:Allpages, sysops cannot delete it.

Possible pitfalls

Probably none, however there is a potential complication: it may be necessary to temporarily disable gw1 interwiki links in order to access and delete the page in question.

It's only a nuisance, but it would be nice if this was added to the to do list. -- Gordon Ecker 04:37, 16 June 2008 (UTC)

It seems that it has been deleted. -- Gordon Ecker (talk) 23:40, 27 October 2009 (UTC)

cite.php

Reason

• Inline citations would be useful for articles which draw from a large number of sources, including FAQs, lore-related articles such as Charr and pre-release articles.
• Can also be used for inline footnotes.

Possible pitfalls

• See http://www.mediawiki.org/wiki/Extension:Cite/Cite.php#Current_problems.

-- Gordon Ecker 00:16, 31 July 2008 (UTC)

And "pre-release articles" would also include articles about unreleased Guild Wars 2 expansions after Guild Wars 2 is released. -- Gordon Ecker (talk) 00:28, 28 October 2009 (UTC)

I second this request (if that makes any difference at all).-- Shew 01:22, 28 October 2009 (UTC)

References are important for the credibility of the uncertain GW2 information summarised by the wiki. So I also support the addition of this extension. -- Aspectacle  02:25, 28 October 2009 (UTC)

Based on the discussion from the GWW, I think the general consensus is that it would at least benefit this wiki.-- Shew 22:40, 14 November 2009 (UTC)

Since this was accidentally installed on the GWW, it's already up over there (oops). I've been told that you'd like it up on this site, too, so I will put in the request to get it installed here. -- Emily Diehl (talk) 02:43, 19 November 2009 (UTC)

Thanks!!-- Shew 04:09, 19 November 2009 (UTC)

Make creation of a redirect page for moved pages optional.

I'm not sure exactly what is involved, but I think I saw something about this discussed over on GWW.

• Pro: Less work for SysOps since a lot of delete requests are a result of useless redirects a.k.a. move remnants.
• Con: May be subject to abuse, but what isn't?

--Max 2 05:42, 13 May 2010 (UTC)

LoopFunctions Extension

Allows the processing of repeated template parameters. In particular, it makes the processing of lists of related items more manageable.
Note: This is not the same as the Loop Eetension. LoopFunctions are particularly suited for handling sequences of template parameters that make up a list. They are a not programming language kind of extension.

• Pro: Makes managing lists of things in template parameters easier.

It is a standard and tested extension and is less cumbersom than roll-your-own variants.

• Con: Yet another extension to test and keep up to date.
• Irrelavant: There are templates that currently take lists of parameters. These may or may not be candidates for rewriting, but they show how messy it is to handle lists without a mechnism like this.

--Max 2 06:07, 13 May 2010 (UTC)

I second this. Having the loop extension would cut down on duplicate condition checking (#if, #ifeq, etc.). One use I see out of it is for the New Krytan template and in any other situation where string length determines the number of times code is executed.-- shew|make 17:38, 7 June 2012 (UTC)

Semantic Forms has a function #arraymap that works pretty much the same way: it takes a delimited string as an input array, then applies a set of operations to each item in the array. There's also #arraymaptemplate where it passes each item to an auxiliary template for really complex operations. To split a string into characters, you simply don't specify a delimiter.

Usage: {{#arraymap:value|delimiter|var|formula|new_delimiter}}

Examples: {{#arraymap:Elixir, Transform|,|@@@|[[Category:@@@ skills]]|\n}} for skills with multiple types; {{#arraymap:abcde||@@@|{{NewKrytan/Encoder|@@@}}|}} for transliterating into New Krytan. —Dr Ishmael 18:03, 7 June 2012 (UTC)

That's reeaally nice to know. Thanks.-- shew|make 18:09, 7 June 2012 (UTC)

RevisionDelete

gw1:Guild Wars Wiki:Requests for technical administration/RevisionDelete wasn't added here. I know it'll be some time before installing extensions is technically feasible, but this is one to include on the list when it is. pling 01:04, 24 January 2011 (UTC)

Interwiki link

The current interwiki link to GWW is GW1:. Could we add GWW: as a valid entry? Thanks. – Tennessee Ernie Ford (TEF) 23:32, 14 February 2012 (UTC)

I believe our initial request was for that name, but for some technical reason they decided to go with gw1. I can't recall the reason why, perhaps poke or pling might remember better. The initial discussion was on Emily's page [1] but I can't remember where the problem or change was communicated to us. I will keep looking. -- aspectacle  20:44, 15 February 2012 (UTC)

The problem was that Anet mixed up which prefix should be on which wiki; i.e. "gww" was made an interwiki prefix on GWW, which meant shortcuts like GWW:POLICY got brokeded. Also, they wanted the wikis to have the same set of prefixes instead of two separate sets, but when they implemented the fixed prefixes, they created separate sets anyway, but using gw1 instead of gww. (link to the discussion). Once we get SpecialInterwiki up and running, it should be fine to add a gww interwiki prefix (on this wiki only, obviously). pling 20:55, 15 February 2012 (UTC)

Thanks for the updates. Any change in status in the last few months? – Tennessee Ernie Ford (TEF) 18:40, 28 April 2012 (UTC)

Looks like the extension has been installed (but only on GW2W, not GWW), but I get a server error when trying to access Special:Interwiki. pling 19:13, 28 April 2012 (UTC)

Lots of things this wiki needs

→ moved from Guild Wars 2 Wiki talk:Admin noticeboard#Lots of things this wiki needs

Hello, I'm new around here, but I've been editing in wikis since many years ago. I think this wiki lacks a lot of, in my opinion, essential features. Here's a short list, but I'm sure there's more missing:

• ExpandTemplates extension
• Editcount extension
• Cite extension merged with templates (use {{Reflist}} instead of <references/>
• Embed Video extension
• ParserFunctions extension
• Short Links extension
• Tabber extension
• YouTube extension

And those are just the extensions :P.

Anyway, is there any specific place to talk about the styles the pages should follow? I've got an idea or two to improve them in general, but I don't want to start without previous consensus.--Lon-ami 14:13, 2 May 2012 (UTC)

Quite a few of these extensions won't benefit the wiki any further compared to the systems already in place (most notably editcount, tabber, and YouTube extensions). As for formatting proposals, you should visit the main Practises and processes page and go from there. Remember we're a rather small wiki due to us being devoted to a game that is not released yet, so your input is very welcome. - Infinite - talk 14:18, 2 May 2012 (UTC)

I don't see much benefit out of these. I don't see how ExpandTemplates is useful at all (I'm not sure what it even is used for). We don't need Editcount, we already have ParserFunctions, and it doesn't look like ShortLinks does anything new. As for the video extensions, I think the wiki doesn't want to emphasize them much, so they've been external links, but that's a community decision. Tabber might be useful, so that could be looked into. You might want to bring a revised proposal to the Community Portal. --JonTheMon 14:38, 2 May 2012 (UTC)

They all have links to their official mediawiki pages explaining what they are for, but I'm explaining it anyway:

• Shortlink makes url editing easier, removing the "index.php?title=" thing.
• ExpandTemplates adds lots of new functions to the templates, that let you make dynamic stuff like these: example1 and example2.
• Tabber lets you make tabs, which are pretty awesome: example where you can change a photo using tabber
• Editcount is nice to keep track of where people is editing.

I don't propose them without reasons :P.--Lon-ami 17:28, 2 May 2012 (UTC)

I'm aware of what they do (having clicked the links and reading into their uses), but I feel that there is no direct use on GW2W for these extensions. Editcount, especially, appears to be merely listed for boasting rights ("I have editted over 15,000 articles!").

The tabber once had direct use (skill tiers), but the features that would benefit from tabs in main space are now no longer there.

We can already create templates as complex now; there is no need for ExpandTemplates, because it doesn't really add much that we actually would use here. Maybe that is wrong on our end, but I personally see no use for the features that it adds.

The Short Links extension is the only one that I can see direct use for (albeit limited use), but I don't know how that extension would work in conjunction with ArenaNet's servers. I'll leave this extension to Jon and other users. - Infinite - talk 17:41, 2 May 2012 (UTC)

After taking a closer look at ShortLinks, I still don't think it's necessary. For almost every link that's used now, the short form is already being used. When you have to make a link to an action, the long form is fine. --JonTheMon 18:17, 2 May 2012 (UTC)

EditCount may be negative, the last thing we need it people making microedits to rise their edit count, so yeah, remove that, at least until the game is out and the situation is stable.

The advantage of shortlinks is being able to use this directly. It's not vital, but I think it's looks visually better. But yeah, not indispensable.--Lon-ami 20:07, 2 May 2012 (UTC)

I'm not entirely sure why any of those are necessary. Why do wiki links need to be nicer? It's not like their 4000 character URLs.

And I think videos detract from pages unnecessarily, but that is another discussion for another day. Aqua (T|C) 20:25, 2 May 2012 (UTC)

Agreed with the above; most of these are vanity changes with no real benefit, and Editcount in particular should never be installed. -Auron 21:50, 3 May 2012 (UTC)

I agree. Only thing that can be useful would be tabber but I can't think of any scenarios where we would use it. I also can't imagine a scenario where embedding a video would be helpful for documentation. Editcounts would be meaningless and possibly detrimental. And for the rest of the extensions, I can't think of any scenarios that would need it. --Lania 22:42, 03 May 2012 (UTC)

Im new here an new to wiki edit, but was wondering if adding the preview code for weapons/armor could be added to the pertaining items page.

Semantic MediaWiki

Discussion started at Guild_Wars_2_Wiki_talk:Community_portal#Let.27s_talk_semantics. Personally, i do see a good use for this, since it has better selection, since a page can have a lot more properties than categories. --JonTheMon 21:16, 3 May 2012 (UTC)

How do we know whether Anet has seen these requests or not? Do you have a contact you can notify about stuff like this? —Dr Ishmael 14:57, 7 May 2012 (UTC)

Stephane's our point of contact. He stops by IRC fairly regularly for poking, as well as follows this page on his own. He has seen the current requests, but it still may take awhile for the server guys to get time and test and all.. Sadly not the most expeditious system, but it'll happen. - Tanetris 18:09, 7 May 2012 (UTC)

Alright, thanks. Would be nice to get on-wiki feedback about it, though, for those of us who haven't yet inducted ourselves into IRC. :P And of course, they can contact me (talk page or email) with questions about SMW - I helped Curse set up most of these extensions for GuildWiki. —Dr Ishmael 18:50, 7 May 2012 (UTC)

Stéphane will most likely comment on the wiki regardless of IRC being available. Not to worry about that one. - Infinite - talk 18:58, 7 May 2012 (UTC)

We're currently trying to get the MediaWiki upgrade to 1.19 and SMW installation tested. There's no category for that yet on the page so I've pushed them in the "being considered" category. I'll also try to put the InterWiki fix and RevisionDelete into the mix if possible. --Stephane Lo Presti talk 23:50, 24 May 2012 (UTC)

Using too many unfamiliar extensions and making the wiki dependent on them carries the danger of alienating potential contributors who don't know how to work them. Even overuse of standard features like templates and redirects were commonplace on GuildWiki and GWW, leading to unnecessary complexity and a structure that was basically unfriendly to new editors. I personally recommend against deploying anything that isn't on Wikipedia (where most potential editors cut their teeth) unless there is a very compelling reason to do so, and in those cases a stipulation that they only be used as such and not to replace standard MediaWiki features that accomplish the same thing. The lesson from GuildWiki and GWW is that it's a bad idea to let the admins and regular editors build a wiki platform that they like but nobody else knows how to use. Both of those sites suffered from technical choices because they put the personal convenience of admins and veteran editors over usability for the readership (from which new contributors are pulled) and as a result they've both been edited and maintained by a relatively small number of people. Let's not make the same mistakes with GW2 wiki please. There is really not much you can do with Semantic Wiki that can't be done more plainly using standard MediaWiki and common extensions. A wiki needs a wide editor base to meet its full potential and less extraneous gadgetry to confuse newcomers. There definitely needs to be more discussion about practical considerations before implementing technical changes just because it's possible. Anet would do well to examine Wikipedia's governance and rationale. 65.87.26.122 22:39, 7 September 2012 (UTC)

ANet does almost nothing regarding the extensions the userbase decides to employ; the extensions we request and build upon are discussed by the community with the needs of the community in mind. Once every six months (or whenever), ANet will look at the list of tech requests and possibly push a few through, but by and large your issue is better argued in a more public place (community portal talk maybe). Template proliferation was a big problem on GWW, but unfortunately the vocal opposition died out before they could effect any change - if you feel strongly enough, hopefully you can spur up some support and change how things work. -Auron 23:12, 7 September 2012 (UTC)

Mobile accessibilty

I originally posted this here It wasn't until I looked further around the wiki that I discovered this page so I thought I should submit it here.

Type: installation of a MediaWiki extension Extension:MobileFrontend

Reason: I was thinking with Guild Wars 2 being released during the age of Mobile devices It would be nice to have a mobile interface for the wiki to make it more accessible to users. I'm not sure what extension wikipedia uses for it's mobile interface, but something similar to that here would be very nice indeed for users.

• Currently when accessing the page via iphone the wiki looks like this:
  • [[:File:User Erasculio mobile view.PNG|Iphone Example]]
• However when accessing the wiki via Android 2.3.4 the user is presented with the following:
  • [[:File:User Wynterarwynrose 2012-06-03_19.58.55.jpg|Android Example 1]]
  • [[:File:User Wynterarwynrose 2012-06-04 01.22.06.jpg|Android Example 2]]
  • [[:File:User Wynterarwynrose 2012-06-04 01.20.34.jpg|Android Example 3]]
  • [[:File:User Wynterarwynrose 2012-06-04 01.29.33.jpg|Android Example 4]]

Possible pitfalls: People who edit the wiki would need to make one extra click to access the full wiki through a mobile device.

Wynterarwynrose 00:21, 4 June 2012 (UTC)

As mentioned in the link above, I would rather not have this feature. It's incredibly, heavily flawed; it removes access to a lot of significant wiki functionalities, such as:

• Talk pages
• Watchlist
• Recent changes
• Preferences
• Any kind of editing

It only has the barest functionality, by allowing people to look at a specific mainspace article they are trying to find. It doesn't even allow proper wiki browsing. As much as I would like to see some kind of mobile accessibility, something that removes access to more content than it shows, only for a small aesthetic benefit, is not worth having. I would rather think this through a bit better and aim for a good, useful solution, even if it takes some more time. Erasculio 02:45, 4 June 2012 (UTC)

If we could get a "m.wiki.guildwars2.com" website, I would be the first to help develop the mobile site, unless of course Infinite beat me to it. But I agree with what Erasculio said, it limits functionality on mobiles so much that its not worth having. Aqua (talk) 02:49, 4 June 2012 (UTC)

I posted this on the other discussion (mostly because I wasn't aware there was actually a discussion going on here finally) So Here goes. While it may not be the answer to everyone's problems I think it would benefit a great many more people, than it would not benefit. Generally when somebody wants quick information, the mobile version of wikipedia serves the purpose very well. It makes the information easy to view and fits it quite well to the screen. Chances are if somebody is accessing the wiki via a mobile device they are doing so because they need the info while they are playing the game and not because they are looking to contribute. The whole point of a wiki is to share knowledge and why should that knowledge not be easy to read on the device one chooses to use. Again I argue that there will be a lot more people who just need to quickly look something up using a mobile device then there will be who want to edit it and use the full features, as I pointed out before nothing is stopping users from accessing the full site should they want to. But for the majority who just want easy access to information quickly the mobile view works well.

People who want or need access to the full version the website can easily access it by scrolling to the bottom of the page and selecting the desktop version. So its an option to view it that way. Wynterarwynrose 03:00, 4 June 2012 (UTC)

You are assuming the majority would use the wiki as you plan to, while creating roadblocks to everyone else :-/ Watchlist, recent changes and talk pages are very basic features to lose. Why should we implement this now, when the game isn't even out and we don't have that many users who just want to look a piece of information, instead of trying to find a better solution? Erasculio 03:02, 4 June 2012 (UTC)

Erasculio, please - it does not remove access to that functionality. It does make it one step further away, because you have to follow the link to the "regular view," but it does not remove it.

99% of people accessing the wiki from their phone are not doing so in order to contribute, as Wynter pointed out - they are doing so simply to access information. As made obvious by [[:File:User Wynterarwynrose 2012-06-03_19.58.55.jpg|this screenshot]], the standard view of the wiki makes it very difficult to access information from the Main Page. The mobile interface will:

• Make it much easier to access information by stripping fancy formatting
• Reduce the bandwidth consumed by skipping most of the CSS/JS code and all associated style images

I will emphasize again: the regular version of the wiki will still be available. This extension only adds functionality, it does not remove anything. —Dr Ishmael 03:04, 4 June 2012 (UTC)

And only a masochist would be watching RC from their phone - I've tried it before, and it is no fun at all. —Dr Ishmael 03:07, 4 June 2012 (UTC)

Sorry, one more thing - the extension also creates a link to permanently disable the mobile view. That sounds like exactly what you want, Erasculio. —Dr Ishmael 03:11, 4 June 2012 (UTC)

Yes I am assuming that, I will admit it. But I mean honestly how many people that play Guild Wars do you honestly think actually go to the wiki to contribute to it? Most people go there to get a mission walkthrough, or check on titles and such, I have seen the discussions time & again during my years of play in Guild Wars. Regardless, the fact is that it would an option and not a requirement. If somebody wants access to those other features than they can easily switch to the full website. So why prevent those people who would want a mobile view from having it, when you can easily offer both options? Wynterarwynrose 03:09, 4 June 2012 (UTC)

Each time you claim how bad mobile access currently is, you are only going against your own point - this feature would not only not improve navigation for everyone who wants to use some basic wiki features (again, there are restrictions to much more than just editing the wiki), but it would actually make it worse by requiring those users to do one more step, having to click on the option to see the full site. It effectively reduces accessability, instead of improving it.

Would only masochists try to look at recent changes from a phone? IMO, that's just trying to ignore different opinions for the sake of bulldozing over a decision. Again, I ask: why implement such a flawed solution now, when the game hasn't even been released yet and there are not many walkthroughs or title descriptions for people to read, instead of waiting and working on a better, less flawed solution? Erasculio 03:16, 4 June 2012 (UTC)

All I'm trying to say is that the good of the many outweighs the needs of rabid editors like us. If it makes browsing the wiki easier for the 99% of our readers who don't care about features like talk pages and watchlists, while introducing a single click for the 1% to return to the normal version, then it is worth installing. —Dr Ishmael 03:27, 4 June 2012 (UTC)

Erasculio, try to maintain perspective here. The vast majority of wiki users are not editors. They do not need a watchlist, they won't look at recent changes, and they probably don't even know talk pages exist. Most of them aren't even registered users. 04:07, 4 June 2012 (UTC)

And right now, there is relatively little content for those users. We are not under the need to hurry as masses of users are reading this wiki looking for complete and up to date information about the game; we are still a relatively small wiki about a game that has not been released yet. Why should we accept a bad solution at this moment, if we could make something better in the time we have between now and when this wiki will truly be filled with readers, iow release?

Besides, it's not like this change would help readers while not doing anything to contributors; it would help readers (or some readers) while being negative to contributors, as not only they would not benefit, but also they would have one more step in order to be able to edit the wiki. As much as contributors are less in number than readers, are we that willing to do something that will actually negatively impact them?

This is a bad solution. Its drawbacks are significant and its benefits are significantly small (don't assume everyone in a mobile device sees the same as Wynter does). I am still trying to understand why is there such a hurry to implement it, instead of working in a solution that is actually better for everyone. Erasculio 04:15, 4 June 2012 (UTC)

When you speak of a better solution, are you being completely abstract or do you actually have an idea that you consider to be better than a widely used MediaWiki mobile interface extension that is by its very nature designed to be used for displaying wiki content on mobile devices? 04:29, 4 June 2012 (UTC)

As mentioned by Aqua above, a m.wiki.guildwars2.com website custom made here, to show what we want it to show. Would be rather more time consuming than the MediaWiki interface... But are we in a hurry? Erasculio 04:40, 4 June 2012 (UTC)

(Reset indent) do we even know how many people are accessing the wiki thew mobile means? its its like .01% then this is not worth it.- Zesbeer 04:44, 4 June 2012 (UTC)

The problem I see with your solution is that it would require double effort on behalf of those maintaining the wiki or at least double the volunteers. Why go through all that trouble when there is a perfectly viable solution available that only requires the installation of an extension? After all it's an option not a requirement for people to use it. Wynterarwynrose 04:45, 4 June 2012 (UTC)

I would say gouging a number would be difficult at best at this point because neither wiki for either game use a mobile interface. The best you could do is run the extension for a while and see what the statistics are, if not many folks are using it, just disable the interface. Wynterarwynrose 04:47, 4 June 2012 (UTC)

anet should have the statistics on that information. seeing as they are running the servers.- Zesbeer 04:52, 4 June 2012 (UTC)

Considering how fast mobile internet users via smartphones and tablets is growing, the demand for a mobile friendly version is also likely growing... But then again, tablets don't need to have a mobile version since they usually can work with normal version of the website. Smartphone access to mobile wikipedia related sites is pretty popular though, according to Digital strategy consulting. So, it's not weird to think that GW2 players who own smartphones will access GW2W on their smartphone especially when they are not at their computer. --Lania 04:57, 04 June 2012 (UTC)

I'm sure they have some statistics but I wonder how accurate they would be. People might get to the front page on their device and then just close it because it's so painful to navigate either games wiki on a small screen. Wynterarwynrose 04:58, 4 June 2012 (UTC)

Wynter, your viable solution is detrimental to those very volunteers you are talking about. Not to mention how you are assuming that all users have the same issues you have when navigating the wiki - in my iPhone, the main page does not look as bugged as it does to you. Erasculio 05:00, 4 June 2012 (UTC)

I think "not bugged" is generally preferable to "not as bugged." 05:08, 4 June 2012 (UTC)

My two major concerns here are 1: whether it would inflict the mobile version on those who don't ask for it (i.e. is it opt-in, or is it autodetect with an opt-out), one of the cardinal sins of web design imo. 2: Is it going to break things? Particularly all those fancy infoboxes and tables and such that so much of our .css is dedicated to. Are those going to be readable in a situation where the .css isn't loaded or is only partially loaded?

Wynterarwynrose: Is it just the Main Page that's an issue for you, or are normal pages a problem too? Could you show some examples? If it's pretty much just a Main Page problem, we could probably just set up a Mobile Portal or somesuch that contains the same information in a more mobile-friendly setup. If it's more extensive than that, there may be some steps we can take with the .css and/or wikicode to alleviate it if we know what's actually a problem.

Zesbeer: Statistics are meaningless as there is no way that current statistics would be statistically relevant to our readership once the game goes live.

Eras and Ish: Keep it calm. Not saying either of you is over the line, but a deep breath may be worth taking. - Tanetris 05:10, 4 June 2012 (UTC)

@ Tanetris: without the fancy CSS, the tables and infoboxes look quite strange though somewhat usable. That is a major issue IMO. --Lania 05:16, 04 June 2012 (UTC)

Tan, all mobile interfaces should be auto-detected with an opt-out for an extremely good reason- if a user cannot or will not navigate the site in its regular format, they certainly won't be able to manually enable a mobile version. A mobile interface is a feature, not an option. 05:23, 4 June 2012 (UTC)

(Reset indent) My viable solution gives an alternative interface for the people that are the reason the volunteers are here. You say you don't like a mobile interface, I'm fine with that I'm also not suggesting that you be forced use it. You however seem to be suggesting that since you don't like it and wouldn't use it everyone who might should basically just deal with it. As has been stated again and again throughout this discussion using the interface is an option not a requirement. You also state that on your device the page looks different to the screenshot I posted, well if GW2W is looking to present a good uniformed interface, which seems to be implied by the new look matching the color & design of the GW2 Website, then it makes sense to make sure that all devices share a uniformed look as well. Wynterarwynrose 05:13, 4 June 2012 (UTC)

For the records, [[:File:User Erasculio mobile view.PNG|here]] is what I see in my iPhone. As far as I can tell, there isn't anything bugged there. A double tap zooms in the link areas, allowing me to navigate without significant issues. Now, per Tanetris' suggestion, I'll take my leave of this discussion, but keep this in mind: we should not hurry to accept a flawed suggestion adopted by an entirely different wiki just because that would be easier, just as we have never simply copied policies from Wikipedia. Erasculio 05:18, 4 June 2012 (UTC)

Tanetris Give me a few and I will provide more screenshots the wiki loads very very slowly on my phone. Wynterarwynrose 05:19, 4 June 2012 (UTC)

(Edit conflict) Well for smartphones with competent browsers like the iphone, android 2+ etc this extension is not needed at all. But a lot of people use smartphones with a basic browser on a low resolution screen, with an anemic processor, and all those css rules and extra elements in the website slow the device down too much. This feature is nice for some people who are having problems can at least have something so they can see the wiki even if it's not perfect or even good. --Lania 05:24, 04 June 2012 (UTC)

Here is another page I attempted to access them from my android 2.3.4 phone http://wiki.guildwars2.com/images/4/43/User_Wynterarwynrose_2012-06-04_01.29.33.jpg I actually took 3 screenshots, but my wifi is acting up and I couldn't get dropbox to upload the other two, I'll post them if I can get them up Wynterarwynrose 06:08, 4 June 2012 (UTC)

Hm. Okay, I think I get the idea. I take it your screen is 320px wide? And it's trying to fit the full sidebar + content area into 320px, with other wider elements variously sticking out and/or overlapping... Might be worth trying the Nostalgia skin for the moment, to at least take the sidebar out of the equation. - Tanetris 07:00, 4 June 2012 (UTC)

yes it has a small screen, changing the theme is an option but it only works for registered users, that means it's not very convenient for most users. p.s. I edited my submission to include my screenshots as well as Erasculio's Wynterarwynrose 07:07, 4 June 2012 (UTC)

Like I said: for the moment. Not saying it solves the wiki, but it may at least help you not be (as) frustrated while things are being looked at and discussed. - Tanetris 07:15, 4 June 2012 (UTC)

Thank you I appreciate that :) Wynterarwynrose 07:18, 4 June 2012 (UTC)

I just want to be clear on android 2.2.2 a lower version then what you are running the site looks fine 0 issues. (both on the default browser and on dolphin hd [even switching from horizontal to vertical view]) so maybe you should change the browser you are using? - Zesbeer 07:33, 4 June 2012 (UTC)

I'm also using the latest Dolphin HD version Wynterarwynrose 07:36, 4 June 2012 (UTC)

after reading your post I also went and tried the default browser I get the same results. Switching from horizontal to vertical in either browser doesn't have much of an effect Wynterarwynrose 07:51, 4 June 2012 (UTC)

well you either have a small screen on your phone, or this problem is only affecting you because my phone is kind of old and has a smaller screen (then normal phones) and lags doing almost anything. and i am unable to recreate the issue you are having.- Zesbeer 07:55, 4 June 2012 (UTC)

I appreciate that you at least tried to re-create the issue. Here is the phone I'm using It's not that old of a device. My display is 320 x 480. Wikipedia's mobile website loads pretty fast, it's only the GW & GW2 Wiki's which seem to load slow. Wynterarwynrose 08:07, 4 June 2012 (UTC)

Out of curiosity to see for myself, I nabbed the Android SDK and ran a 2.3.3 (they didn't have 2.3.4 for whatever reason) virtual device at 320x480. Not really sure how to download apps, or if you can within the SDK, so didn't get to try Dolphin, but looking at things with the default browser, things seemed pretty reasonable: [[:File:User Tanetris android 2-3-3 main.jpg|Main Page]] and [[:File:User Tanetris android 2-3-3 charr.jpg|Charr]]. Rather curious what's happening with your phone. Still looking at things, but just wanted to mention it. - Tanetris 21:38, 4 June 2012 (UTC)

Perhaps more relevantly to the discussion of the extension, I also tried Wikipedia's site from the Android browser. While the link to change back to desktop version is simple enough to find, but the first time I did and then navigated to a different page, it took me right back to the mobile version. Bad, bad. Another try and it now seems to keep me on non-mobile. Guess the cookie didn't take the first time. Curious how long it should last for. Apparently they've removed the "permanently disable" button. Not thrilling. I tend to remain of the opinion that if we do install the extension, it not automatically redirect based on detected device, but make sure a link to the mobile site is easily accessible. Those who are so inclined can just as easily bookmark m.wiki.guildwars.com, and once on the version they want to be on, no one would ever be sent back to the version they don't without doing it themselves.

Then again, I don't even have a smartphone currently, so what's my opinion really worth? - Tanetris 23:08, 4 June 2012 (UTC)

As a frequent and active smartphone user, I wanted to (re)confirm what your page content settings are for your smartphone browser. There is a possibility that your browser is forcing the wiki's content to be as wide as your resolution, subsequently causing the overflowing content to bug out. - Infinite - talk 10:57, 8 June 2012 (UTC)

Alternative: Mobile app

I've decided to start a project to build an app for GW2W- this wouldn't necessarily replace a mobile frontend extension or a custom mobile layout, but it would provide a (relatively) quick-loading lightweight solution for people who just want to view wiki content on the go. We could go about this a few ways.

Copy Wikipedia

Wikipedia's official app (https://github.com/wikimedia/WikipediaMobile) is open source, so it may be possible to modify it to suit our needs with relatively little effort. This would also allow us to support pretty much all mobile platforms, because Wikipedia's app uses a tech called PhoneGap to encapsulate HTML5/CSS3 and JavaScript code in a native wrapper for each system. The major problem with this approach is that I don't have any experience coding in HTML5/CSS3 and JavaScript, so it would make me crazy and probably never work unless other devs are willing to help out.

From scratch

Pretty self-explanatory. This would require additional devs to release on any platform other than Android, since I don't have an iOS developer account and I don't know Objective-C anyway. I'll probably try a few different approaches, but my initial plan is to grab wiki content through MediaWiki's built-in web API with JSON, convert it to html using the Bliki Engine, and throw that in a webview. At some point it'll be formatted I guess.

I intend to make this an open source project- I haven't really worked out the details yet. I'd welcome collaborators. 14:14, 8 June 2012 (UTC)

While from scratch is tempting because it allows you to do it in a way you immediately understand and get the enjoyment of creation, the fact the wikipedia app is working already and supports all the platforms (windows mobile. o_o) is a huge leg up to a working gw2w app.

So my question is, what do we get from a "from scratch" solution that reskinning the wikipedia app doesn't give us? (Personal satisfaction, I understand that, but functionality stuff...) My enterprise experience tells me that most times you shouldn't really roll your own just cause you feel like it because from scratch always works out to be more complex.

That said I'm happy to help out on either route - but probably just reinforcing the areas you're able to do yourself android and java stuff. -- aspectacle  16:19, 8 June 2012 (UTC)

So this would be an actual app that people would have to install on their phone separate from the bundled browser, right? I'm wondering if that's going to be a palatable option for most people. I'm also thinking that we should coordinate with Anet on this - they're already developing mobile apps, so maybe they could take on this project officially. —Dr Ishmael 16:23, 8 June 2012 (UTC)

You'd probably need to have something which made it over and above just using the wiki from a browser to make it worthwhile installing and using - I haven't put much thought into what that could be. For example, I have the wikipedia app installed on my tablet, but tend not to use it because I get more/as much utility from just using my browser. -- aspectacle  17:40, 8 June 2012 (UTC)

The main thing discouraging me from using Wikipedia's code is that I don't know how. I asked Stephane if Anet had any plans for a wiki app and he said he didn't know of any. 18:28, 8 June 2012 (UTC)

This is one of the topics Stephane plans on covering next Wednesday the 13th, so i think we should hold off until then.- Zesbeer 18:41, 8 June 2012 (UTC)

Well shucks, I was hoping to build the entire app in 4 nights and launch it on the 12th. ): 21:28, 8 June 2012 (UTC)

[alt+shift]+[c] shortcut — request to add its functionality to other spaces

I request that we enable the [alt+shift]+[c] shortcut to work in the Project space as it does in Main, Template, and File spaces.

There are some wiki keyboard shortcuts that work across the wiki: [alt+shift]+[t] takes you to a talk tab, [alt+shift]+[h] is the history tab, and [alt+shift]+[e] is the edit tab. Some universal shortcuts also work everywhere (e.g. to get to watchlist, recent changes, preferences, my user page, my user talk, etc.).

However, [alt+shift]+[c] only works in Main, Template, and File spaces; it does not work in the Project space. It should take you to the primary tab for the article (i.e. the one entitled Project). For reference, this was resolved previously on GWW. Thanks

PS is there any way we can ensure this functionality should we add any new spaces, e.g. a feedback or whatever? – Tennessee Ernie Ford (TEF) 17:13, 8 June 2012 (UTC)

Bump, please (I thought this was pretty easy to fix.) – Tennessee Ernie Ford (TEF) 16:56, 10 July 2012 (UTC)

Hah, about 6 months later, Dr ish fixes it :D MediaWiki:Accesskey-ca-nstab-project. (deja vu..) -Chieftain Alex 21:03, 29 January 2013 (UTC)

Extension:HttpsLogin

I'm sure it's pretty obvious for most of us editors that, wiki login at GWW and GW2W... and most wikis in general do not encrypt the password at login. Instead, user ID and password is being transmitted in plain text, so programs like wireshark can easily intercept it w/o the need for decryption. While I use a throwaway password for both wikis, I'm not sure all users do that, and with this being the official wiki, some users might feel that this wiki is more secure than an unofficial wiki, and end up using the same password as their game password (Something that Anet, gaile gray, and every IT profesional stress over and over again, while many players still use the same password...). With malicious network sniffers becoming more common and less detectable, I think it might be time to add encryption to the login process to improve the wiki security. Wouldn't want someone to sniff a sysop account password+userID, and wreak havoc on the wiki :P. It hasn't been a problem in the past afaik, but I'd rather not wait until something does happen to implement something like this.

Of course this will require Anet to use their SSL certificate and there is some techical hurdles, but regular wiki editors will likely won't have to do anything. --Lania 18:12, 13 June 2012 (UTC)

[2] This is an alternative implementation of the above. --Lania 18:31, 13 June 2012 (UTC)

screenshots

Because I was kinda bored, and maybe some people needed some visible examples, I wanted to show how unencrypted passwords show up on programs like wireshark etc (assuming the hacker spoofed the network successfully). As you can see it is in RAW viewing mode, and the password and user ID underlined in green is in plain text and does not need any decryption to read the password. There are other things that the hacker needs to do like ARP poisoning, MAC spoofing etc to be able to capture passwords in a network but those things are fairly easy to do and automated tools are available to do that. So basically, users in large local networks like universities, corporations, airports, coffee shops, malls etc are the most vulnerable to having their account information stolen. --Lania 21:22, 14 June 2012 (UTC)

I am all for this but know little about this extension. - Zesbeer 21:29, 14 June 2012 (UTC)

It is good to send passwords encrypted, but I will note that both linked extensions require that the wiki already work with both HTTP and HTTPS (ours does not currently work with HTTPS). As noted on the HttpsLogin extension's page, the login page is also not the only place sensitive information can be entered. While SecurePages claims to fix this, the wiki it links to as an example actually has the entire wiki redirected to HTTPS rather than such key pages. There's also this configuration setting since 1.17 that would seem to render the login page part obsolete: http://www.mediawiki.org/wiki/Manual:$wgSecureLogin All in all, while I agree with the concept, we need to get the implementation right. - Tanetris 21:47, 14 June 2012 (UTC)

Yeah, getting HTTPS working will be something that Anet will have to do... but they can probably use their existing SSL certificate since it's issued to *.guildwars2.com. As far as the extension being obsolete, i did not know that it's a configuration setting since 1.17 :P. So an extension won't have to be installed then... which means implementation should be easier and faster yay!. --Lania 22:30, 14 June 2012 (UTC)

I'll add this to the MW upgrade request, so that they can hopefully set it the way we want at the time of upgrade, and we won't have to get it changed later. —Dr Ishmael 00:36, 15 June 2012 (UTC)

Database download

This is a feature available in Wikipedia, as seen here. Basically, the entire Wikipedia database is made available for download. Here, it would have the following advantages:

1. It would allow users to browse the wiki when offline. Since a player without internet access cannot use the wiki or play the game, this would allow players to at least do something GW2-related when their internet connection is off-line, for whatever reason.
2. It would be compatible with the many "wikis in a stick" methods, allowing easy transportation of wiki information.
3. It would allow users to keep a backup of the wiki, in case something goes terribly wrong with ArenaNet's servers.
4. It would allow users to test changes, such as template changes, without flooding recent changes.

The only possible issue I can think of is the size of the database. I don't know how big it would be, but if it's really really huge, it could hurt ArenaNet's bandwidth to have people downloading something this massive. Erasculio 12:42, 23 June 2012 (UTC)

copy rights?- Zesbeer 20:31, 23 June 2012 (UTC)

Same as Wikipedia did. The copyright notice needed to allow users to see the wiki in their computer (by reading it online) is the same copyright notice needed to allow users to see the wiki in their computer (by hosting an off-line version). The Wikipedia article linked above mentions that, as well. Erasculio 21:11, 23 June 2012 (UTC)

I don't see a need for this. To use the wiki offline, you'd have to know to DL it (and know how to set it up to work offline) before you lost you internet connection. If the goal is transporting to another wiki (esp. in a language other than En/Fr/De), then that's probably easier to do on a one-off basis (which would also make it more likely that appropriate copyrights are acknowledged). If ANet servers go under so that we have to depend on Ish's backup, then getting the wiki backup and running will be the least of our concerns. Finally, I don't see any advantage in protecting "recent changes" — there's only a tiny number of contributors that are heavy consumers of RC and yet cannot filter out changes from one name space or another. (There are also a handful of tools that allow creation of a virtual environment in which one can test template modifications, without saving the template.) – Tennessee Ernie Ford (TEF) 05:24, 24 June 2012 (UTC)

Heh, when I said "transportation", I didn't mean copying the wiki data to another online wiki; I meant in the literal meaning of walking around taking the wiki with you, such as using MoWeS. This is part of the "Wiki on a stick" functionality (which I had mentioned above, for the records).

I don't think there are many doubts about how this idea has many benefits; see the links above to Wikipedia for the reasons why they decided to offer the database download for their wiki, despite how it's a few gigabytes in size. Whether the benefits outweigth the trouble this would cause is something worth discussing, though. TEF appears to not care about allowing people to use the wiki when they don't have internet access or having multiple backups easily available or avoiding recent changes flood; do other people care about those things? And does someone have any idea of how big would this wiki's database be, if one were to download it? Erasculio 12:27, 24 June 2012 (UTC)

TEF's point is that this idea would only benefit a very few users who A) know about it, B) have the patience to download it, C) have the technical knowledge to set up a "wiki on a stick", D) absolutely have to be able to access the wiki anywhere/anytime. —Dr Ishmael 13:37, 24 June 2012 (UTC)

And users who don't follow points C and D but have spotty internet connection and want to read the wiki when off-line (even in their desktop, so there's no need to install the wiki on a stick), and everyone in case there are server issues and there's the need for a backup, and everyone who would be spared the recent changes flooding when testing new templates, not to mention how it would avoid creating test pages that are often required when testing a new template. Basically, the scenarios I have mentioned in my first entry in this discussion, of which apparently all points but point 2 have been ignored in the above comment. Erasculio 13:59, 24 June 2012 (UTC)

RC flood and test pages are non-issues - yes, they can be annoying, but in the end they don't cause any harm. I would be very surprised (and disappointed) if Anet were not performing their own backups. Reading the wiki offline "even in their desktop" requires work to set up, and if someone has "spotty internet connection" then they probably won't be playing GW2 anyway. —Dr Ishmael 14:28, 24 June 2012 (UTC)

I care about giving people an offline alternative to the wiki; I'm not convinced that this tool provides that for all that many people. I've skimmed through the linked instructions...and it's hard to imagine more than a dozen or two who are going to figure out what needs to be done to enjoy "wiki on a stick" or even just offline. (The number shrinks for those who want to be able to edit as well as read). I apologize if I'm misunderstanding the complexity involved based on the 4,000-word manual (if there's a simple alternative that requires a single link and a single tool installed on the same PC or same "stick," I missed it).

To the question of size: I don't think it's an issue for this suggestion. The smallest compressed version of Wikipedia is less than 8GB for nearly 4,000,000 articles. By contrast, GWW hosts less than 22,000 — all things equal, that would suggest a data dump of 40-50 MB. (Probably more for GW2W: there's some overhead and ultimately, we'll have probably 10x as many articles here.) – Tennessee Ernie Ford (TEF) 16:54, 24 June 2012 (UTC)

So the discussion is basically about whether ArenaNet could allow us to download a 40-50 MB file they already have (their back-up). Somehow, the discussion feels like it's more work than ArenaNet would have implementing this feature. TEF, the installation guide for MoWeS Portable has 902 words. This discussion has a bit over 1.100. If we're talking about unnecessary complexity when trying to achieve a simple goal, I don't think we need to look very far... Erasculio 23:30, 24 June 2012 (UTC)

An automated database backup doesn't generally produce a .zip file that someone could download, unzip, and use; a good backup system is more efficient than that. So no, this would not be a file that Anet already has that they can just copy to the web server. —Dr Ishmael 02:25, 25 June 2012 (UTC)

Erasculio: the link you pointed us towards is 4,000 words. There are all sorts of tools, databases, and techniques covered. If you have a simpler proposition, I'd appreciate it if you could outline it; I assumed from your introduction that you were referring to exactly what Wikipedia provides, for tools like Wikipanion and other mobile readers. – Tennessee Ernie Ford (TEF) 02:38, 25 June 2012 (UTC)

The first link I pointed you towards is a collection of multiple different ways to use the Wikipedia database. Claiming the entire article is too long thus any individual way is too complex equals claiming that this very page has more than 8 thousand words, thus all discussions here are too complex for any given person to follow. Erasculio 02:53, 25 June 2012 (UTC)

Twitter

Is there a possible way, using HTML coding, to make a the most recent Twitter update to appear on one's userpage? Please answer :) ChristianSky2 02:53, 9 July 2012 (UTC)

On the wiki, no. At least not until we get the Widgets extension. —Dr Ishmael 03:16, 9 July 2012 (UTC)

Is there any scheduled date for the widgets to start being used in this wiki? ChristianSky2 03:27, 9 July 2012 (UTC)

If there were, it would be on this page. —Dr Ishmael 12:32, 9 July 2012 (UTC)

Interwiki links

Shouldn't we have interwiki links for some of the obvious official sites?

• Forum: forum.guildwars2.com
• Blog: arena.net/blog
• GW2: guildwars2.com
• Tweet/Twitter: twitter.com/GuildWars2

And perhaps some of the likely source sites:

• Guru: guildwars2guru.com
• Reddit: reddit.com/r/Guildwars2/
• Massively: massively.joystiq.com

And GW1 official sites that might be linked from here:

• Feedback: wiki.guildwars.com/wiki/Feedback:
• Forum1:Accounts: forum.guildwars.com/forum/forums/accounts (https)

– Tennessee Ernie Ford (TEF) 16:14, 12 July 2012 (UTC)

I could see Forum, blog, and the main site. If we're doign the GW2 twitter, that needs to be reflected in the interwiki name. I'm not a fan of making them for the other fansites. As for the official sites I don't see those being needed; the former is taken care of by the regular GW1 link and the other isn't related to GW2. --JonTheMon 16:22, 12 July 2012 (UTC)

Official Anet-site interwikis are fine, fansite interwikis aren't imo. It's still important to show when a link points to an external page.

That said, wouldn't they still be kind of pointless? It'd be easier to copy the entire url for things like the blog and twitter, instead of selecting the part of the url referring to the blogpost or the tweet's id. Interwikis only work nicely for other wikis, i.e. when there's a degree of uniformity and intuitiveness about the page's location, and you can just type out the link without having to look at the url. I think it might be a bit confusing for people to sometimes use [[gw1:Main Page]] and at other times [[blog:the-golden-rules-of-guild-wars-2]] or [[officialsite:the-game/professions/mesmer/]]. Particularly for new editors, it complicates the distinction between [[double square brackets]] and [<normal-looking-url-here> single square brackets]. pling 16:43, 12 July 2012 (UTC)

(Edit conflict) How do you define the link patterns for those sites? You have to know how [[Prefix:$1]] translates to http://<domain>/foo/$1, and more importantly for a user, what part of the URL is $1 in order to make your interwiki link work. This is easy for interwiki links because you use the article name as $1.

At a more basic level, using the interwiki feature for links to non-wiki sites seems like a subversion of the feature's intended use. Also, Pling expressed the same ideas I was trying to convey much more clearly. —Dr Ishmael 16:47, 12 July 2012 (UTC)

Eh, I don't want to push it if no one else supports the idea. But first: "interwiki link" is just jargon for "use plainlinks to display a hyperlink" — it doesn't have to be used only for linking to wikis, as can be seen by imdb:, google:, googlegroups:,and dictionary:. Secondly, contributors are always confused by linking syntax, which is why we have so many plurals within brackets, use of http for links within GW2W, and constant discussions about whether [[NPC]] is better than [[Non-player character|NPC]].

The use of linking shortcuts (which is what this feature really is) makes it a lot easier to read and edit, b/c you don't have to deal with all the extra http: everywhere. It's similar to using {{gold}} instead of [[Image:Gold coin.png|link=Coin]] — both are convenient shortcuts to typing/reading/editing longer bits of syntax. – Tennessee Ernie Ford (TEF) 17:03, 12 July 2012 (UTC)

Those sites aren't wikis so they shouldn't be treated as interwikis, this would be an abuse of the feature as a user following such a link expects to be taken to another article page and not just some webpage (interwiki links are rendered differently than plain external links). For convenience, commonly linked sites (official or not) can be wrapped in a template. As always, a more mature wiki (Wikipedia) has already dealt with this type of question and there is little reason to deviate... proven methods are proven. 65.87.26.122 23:23, 7 September 2012 (UTC)

Caching Server issues

Please see the section on the bug page. This is causing account registrations to be severely limited and causing IP blocks to affect nearly every user regardless if they're logged in or not. Yes, I am a mediawiki developer. 192.168.104.30 23:33, 28 August 2012 (UTC)

Ability to align a table to the center

I'm creating footer tables that serve as navigational tools for articles that are somehow related to one another and I need to be able to conform to the CSS stylesheet of the tables and align the table itself to the center of the page but the CSS won't let me. It seems that the CSS forces all tables to be aligned to the left.

The template in question is: [[Template:Exalted armor]] which links all the Exalted armors together in a single table for easy navigation. I need this table to be aligned to the center and have a smaller text than normal.

--Preedee 13:10, 23 September 2012 (UTC)

Take a look at the existing Category:Armor navigation templates. —Dr Ishmael 14:39, 23 September 2012 (UTC)

Suppress redirect

There's pretty much no downside, and would save sysops lots of time otherwise spent deleting literally thousands of move remnant pages. It seems to be installed by default on current mediawiki versions, the rights just need to be given to autoconfirmed users. -Auron 03:25, 14 December 2012 (UTC)

Hey there. (scratch my previous message) We've done the change, here and on the Guild Wars Wiki. Let us know if there's any issue with this. Thanks. --Stephane Lo Presti talk 23:51, 14 December 2012 (UTC)

What were the indented user groups for this? Because right now only sysops and bots have it. --JonTheMon 18:37, 16 December 2012 (UTC)

I don’t think normal users should be able to do this, as in general keeping redirects in place is preferred. If there was a visible option, inexperienced users would probably move everything without leaving a redirect. poke | talk 18:50, 16 December 2012 (UTC)

I don't think autoconfirmed users would check the box unless they know what it does.--Relyk ~ talk > 23:10, 29 January 2013 (UTC)

Whoops, forgot about this section. Jon: my idea was for every autoconfirmed user to have it. Sysops having it is mostly pointless, as they can manually delete pages at any time - the point of suppress redirect is to relieve the burden of deleting the aforementioned thousands of redirects left behind when normal users move stuff.

And yes, I agree Relyk - I doubt it would be abused by the average pleb, and the curious ones will figure out what it's for and help sysops by not creating needless redirects. -Auron 03:09, 1 February 2013 (UTC)

Sounds fine with me. If there are problems, we could create a specific user-group, similar to how some wikis have a rollback group. pling 20:32, 6 March 2013 (UTC)

Attaching contributions from an IP to an Account

This is certainly not vital, but perhaps it's easy to implement and can be useful. Suppose I made some contributions before I created a Wiki account (so under my IP). I later create an account and start contributing under the account. Is it possible to attach the contributions made under the my IP (which is easy to verify since it is static), to my account? --Alad 04:51, 23 February 2013 (UTC)

With the extensions we have at the moment, this is unfortunately not possible. (We have "user merge and delete", but afaik it doesn't work on IP edits.) I have seen an extension somewhere that does allow you to reassign IP edits, but we don't have it + don't have any plans to install it. (perhaps a link to the IP on your userpage would do.) -Chieftain Alex 11:35, 23 February 2013 (UTC)

Also, editors can share the same IP address, so it would ethically incorrect to assign contributions made by an IP to a user. Some users have laid claim o IP's here, but I'm not a fan of this practice. That's an entirely different issue though. Venom20 12:20, 23 February 2013 (UTC)

I don't really see why it matters.- Zesbeer 00:30, 24 February 2013 (UTC)

Captcha settings & bot creations

There's a topic on the GW1W tech request page about CAPTCHA settings that is also relevant to this wiki, as we use the same CAPTCHA method. - Tanetris 15:46, 27 February 2013 (UTC)

SMW query limitations

I love how there is semantic functionality now, but I have concerns about the limitations on queries. I tried to build a fairly simple query to find all staves that meet 3 attribute bonus criteria. It gave me a message that the query exceeded the limit on query size or depth. What are the limits on queries, so I know how to structure things in the future? Is it possible to loosen these limits? Any hints or suggestions appreciated. Here is the query I was attempting: {{#ask: [[Category:Staves]] [[Gives_attribute_bonus::>120;Power]] [[Gives_attribute_bonus::>120;Precision]] [[Gives_attribute_bonus::>80;Condition]]}} and here is the results: Tsafran (talk) 22:53, 24 May 2013 (UTC)

Wasn't the depth limited to 1 level or something stupid? -Chieftain Alex 23:13, 24 May 2013 (UTC)

SMW doesn't like the compound query to multiple records with multiple comparators. Your query shouldn't be returning anything because Condition isn't a valid value:

{{#ask: [[Category:Staves]] [[Gives_attribute_bonus::>120;Power]] [[Gives_attribute_bonus::>120;Precision]] [[Gives_attribute_bonus::>80;Condition Damage]]}}.

You can do the same query and not hit the size limit as:

{{#ask:[[Category:Staves]]
       [[Gives attribute bonus::>120;Power]]
       [[Gives attribute bonus::?;Precision]]
       [[Gives attribute bonus::?;Condition Damage]]
}}

The query currently won't work correctly even if it didn't hit the limit because some pages have multiple sets of records like Kodan Staff, which doesn't have a power/precision/condition damage combination. In addition, the only combination for power/precision/condition damage has precision as the major attribute. When you make a query, you would query for a set based a the major attribute and wildcards like in the example. We need to put the attribute sets into subobjects to keep them together. It would probably have major and minor attribute properties so your query first has to grav a valid combination and then check if any weapons that give those bonuses base don the argument. I don't think we will need a query that hits the query size limit.--Relyk ~ talk < 00:25, 25 May 2013 (UTC)

Account-creation spam, CAPTCHA settings, and Asirra

We've been getting hit with a very high level of account-creation spam for a few months now. We're pretty sure this is because Anet changed our ConfirmEdit configuration from ReCaptcha to FancyCaptcha a while back - while both are similar in that they require the user to enter the characters seen in a distorted image, FancyCaptcha is considered much less secure than ReCaptcha. I don't recall exactly why they changed this, but Poke or Tane might remember. Account creation on its own isn't a huge problem - it's just annoying to people following Recent Changes - but most of these are "sleeper" accounts that spammers can utilize in the future.

In any case, Poke and I had proposed switching to Asirra. This method presents the user a set of 12 images of dogs and cats (sourced from adoption listings at PetFinder.com), and the user must select all of the cat images to pass. You can try it out on this test wiki to see what it's like - edit that page or create an account. It is very difficult for a bot to differentiate cat and dog pictures, and the wide variety of subject poses and photo quality present in the Asirra images makes this even harder, which means Asirra is very secure against bots. GuildWiki decided to switch to Asirra after we moved to Curse, and now Curse uses it on all of their Gamepedia wikis.

At the time, Stephane and Justin did not want to use Asirra because there had been issues reported with IE8 and IE9 browsers. However, these incidents seem to have been isolated, as no further incidents have been reported (since August 2012), and my own testing using IE9's Developer Tools to try different IE configurations has shown no issues with using Asirra on that test wiki.

So what does everyone think? Does Asirra seem like a good option? Is the problem serious enough for us to make this change? —Dr Ishmael 14:45, 2 August 2013 (UTC)

I think that even though the problem is not really serious it would be a good change going forward. After all, who doesn't like cat and dog pictures on the internet? 15:00, 2 August 2013 (UTC)

I think it's a good idea when Recent Changes has more account creation than other material some days. And anyone who has an account but never used it should be forced to re-authenticate. I tried the test wiki, it's no problem. --Claret (talk) 15:22, 2 August 2013 (UTC)

Personally I'd prefer requiring a GW2 account, but I guess cats and dogs are fine too :P Just imagine all that wasted space... --zeeZ (talk) 15:30, 2 August 2013 (UTC)

Pretty sure you got it squirrelwise + they changed it to ReCaptcha from FancyCaptcha. (at least I get the google book one (recaptcha) when I add links as an IP). ReC was better than FancyC, but its still weaker than asirra though so your suggestion holds. -Chieftain Alex 16:03, 2 August 2013 (UTC)

It originally was ReCAPTCHA, but they changed it to FancyCaptcha at some point. After the issues started on GWW, we had them change it back to ReCAPTCHA but the overall sitation didn’t really get better. So yeah, I definitely want to try out Asirra now. poke | talk 16:40, 2 August 2013 (UTC)

please read this article. Asirra isn't as secure as the asirra website is claiming. The technique described here is pretty well doable for a skilled programmer. So thats a negative. The other negative in my opinion is the level of the challenge. I tried to pass the test, and when taking your time it is an easy task. The failrate when being in a hurry is a lot higher though. The existing captcha techniques fail mostly cause of bad captcha's. This system is more frustrating when you make a human error. Having said that. This is account creation and we all only do it once. Besides that, the current captcha's we tried earlier aren't helping either, so I don't see why we shouldn't give this one a go.Ranique (talk) 17:27, 2 August 2013 (UTC)

(Reset indent) There's a lot I'd like to write about this as this is something we've internally discussed a lot (I actually had a big message drafter a long time ago but it turned out that other things got in the way and changed the content of that message), but my time is limited so I'll be brief. The real truth is that we believe there's no ideal and proven Captcha method that works, all of them can be bypassed (for example by paying companies/real humans). We've seen, after some research, conflicting reports, for example about which of ReCaptcha and FancyCaptcha are stronger (and we did see reports from IT professionals pointing to technical issues with ReCaptcha which prompted us to test FancyCaptcha, which we have now reverted). You'll note that Wikipedia also has no solution to this problem either, although these account creations get buried under a lot more useful stuff. We've briefly discussed going deeper into the problem (e.g., hiding account creations, requesting email confirmation for account creation, cleaning the user database, etc.) but that particular topic hasn't been a priority for us. I'll refresh that internal discussion to see if we can make some progress but I think it's essential that the wiki community debates this, as we don't have infinite wiki resources and want to make a good use of this. For example, how is this impacting the work of editors? If this is only about readability of the RecentChanges, then the fact that there are tons of useless wiki accounts may not be a problem? Or is the number of RegisteredUsers a useful resource and if so what can we do about it? etc. I'll keep an eye on this discussion to see if there's any insight I can bring, or answer questions. Sorry for intruding :) --Stephane Lo Presti talk 17:53, 2 August 2013 (UTC)

I think the most successful (and also most accessible) CAPTCHAs are simple questions. Maybe we can crowdsource some simple GW related questions which we then can supply to QuestyCaptcha? poke | talk 18:12, 2 August 2013 (UTC)

@Ranique: No CAPTCHA is perfect. There will never be a CAPTCHA that all humans can solve, but that cannot be automated. It’s just not possible. Just like you pointed out that Asirra can be hacked, I tell you that ReCAPTCHA can be hacked very easily as well. It’s just that Asirra is probably a smaller target than ReCAPTCHA making it possibly more efficient.. poke | talk 18:16, 2 August 2013 (UTC)

I found I don't really need to know if accounts are created. I borrowed ishmael's js stuff to hide account creation in RC and happy with it. Account creation can be hidden in RC by default, with an option to show. Users can set a preference to show/hide by default.--Relyk ~ talk < 19:24, 2 August 2013 (UTC)

Stephane, it's not the account creation itself that is a problem. It's the fact that spammers are creating all of these "sleeper" accounts that they could use in the future - any registered account automatically bypasses a number of spam-prevention mechanisms (including ConfirmEdit) which makes it easier for spammers to successfully post their payload. Making it more difficult for spammers to create accounts makes the site more secure against spam.

QuestyCaptcha has a number of potential issues, the biggest of which is that spammers can usually commit a small amount of effort to find the answer to each question and then store the responses. We would have to either set up a very large set of possible questions or rotate them frequently to prevent this.

No, Asirra isn't perfectly secure (any Captcha can be forwarded to a human solver, there's no way to stop that), but it is probably the best option we have that requires the least amount of effort at this time. —Dr Ishmael 19:46, 2 August 2013 (UTC)

What would the spammers use these sleeper accounts to do what? (vandalism would be stopped by AbuseFilter right?) Like I said, we also discussed the possibility to "clean" our userdatabases (delete accounts that had no activity for a long while), but it's only been a vague thought on our side at this point. We're not sure that Asirra is the best option and how much work it'd require to set it up, but it's another possibility we're open about.

Anyway, before we do that, we need a clear and strong signal from the wiki community that this is an issue so important that we need to prioritize it above other work that our team is busy with. I'm not saying we won't eventually do it, but it's more about understand how pressing an issue this is. --Stephane Lo Presti talk 20:06, 2 August 2013 (UTC)

Well, once the accounts are registered, they can easily reach the autoconfirmed status later, and from there on they are safe from nearly all filter rules. poke | talk 23:35, 2 August 2013 (UTC)

I think cleaning the user database would be a beneficial counterpart to beefing up the Captcha security, as that would eliminate all the sleeper accounts that have already been created. This cleanup should probably only affect accounts with zero contributions, rather than basing it on time-since-last-contribution, since there are many valid accounts of users who simply created a userpage or made a couple copyedits to mainspace and then lost interest in the wiki/game. Valid accounts who haven't made any contributions aren't losing anything if we delete their account, and they were probably very unlikely to ever come back and contribute in any case. —Dr Ishmael 00:12, 3 August 2013 (UTC)

We could delete those accounts ourselves if the user database wasn’t still linked with GWW’s btw. (any news on that? ^^) poke | talk 02:09, 3 August 2013 (UTC)

I have done some research bout this. As being said here, no captcha system is waterproof. People who can program a bot to auto-make accounts like this are smart programmers. Deleting all current sleeper-account only solves this problem for now and buys us some time. If this is a successfull method, those people can easily program to add a single line to the user page saying 'Work in progress', or 'Will fill this later :)' (and even randomly select one from a list of 20 possible lines there). As stephane said, the accounts are not doing any harm at the moment. The main problem is that we don't know the motives and it is in my opinion more important to weapon ourselfes against (wich is mostly a task for Anet). It seems that the spam filters are very good working at the moment. Some other harmfull things that pops in my mind involves ddos attacks. This could be a generic attack, having all sleeper accounts activated at once to shut down the wiki and hold it for ransom. It can also be to target the spamfilters specifick, so the sleeper accounts disable the filters. My main question therefor is if those mass amounts of accounts are made by a few amount (always the same) of IP's or a lot of different. The last indicates it is done by a botnet, wich indicates possible future ddos-attacks. Maybe Stephane can check that with the team?? As for the security itself. I don't see that changing all the time will benefit us all, the only thing that might be worth to try is using a selection of capthca techniques and rotate them automaticly. For example, rotating with a RNG system in place for how long till the next rotation. (so a bit of software, that will select one of the capthca systems and randomly picks a number between 240 and 2400 wich is the amount of seconds that pass till the program cahnges the captcha again). Making such a program however takes time and resources, and I'm still not sure if the problem is so big that we should ask Arenanet for it.Ranique (talk) 12:08, 5 August 2013 (UTC)

That sounds a bit paranoid - you wouldn't need accounts to ddos a site, just a bunch of "get page" commands at once. The account creation problem is mostly just the annoyance of spamming rc with them, so hiding them could be a good idea to start with, and cleanup of the userdatabase on users that haven't contributed would be a good followup. Questy/asirra sound like an improvement, but it would have to be an easy gw2 question, since you're here to find information! -77.97.208.117 14:08, 5 August 2013 (UTC)

Exactly: CAPTCHA and account registration can't do diddly about DDOS, so that's irrelevant. The accounts are typically created from a wide range of IP addresses, but that doesn't necessarily indicate a botnet, either - it could also indicate a dynamic proxy. A rotating CAPTCHA system won't help either, since the botter could write type-detection into his program to deal with it (and if they're already using live-person forwarding, it wouldn't make any difference).

If you go to the deletion log and look at all of the "Spam" deletions, you'll see that these sleeper accounts are already starting to wake up in significant numbers. Each spam deletion indicates a different account, since we admins will block the account that created the page at the same time we delete it (block log, harder to parse due to all the AbuseFilter autoblocks). —Dr Ishmael 14:29, 5 August 2013 (UTC)

I just checked the block log and (if I see it correct) yesterday (the 4th) 10 accounts where blocked (and some ip's but thats irrelevant). Looking back in history there isn't a significant peak visable. Yesterday there where 112 new accounts created who didn't had any contribs (yet). Assuming the goal is to spam us in the future is dangerous and I think the question Stephane asked is very relevant ('What would the spammers use these sleeper accounts to do what?'). The problem is that I (we?) simply don't know. I know that for a classic ddos attack, there is no need for having an account. But (and i'm only speculating) it might be the people responsable know about a leak in the current wiki-software that can be exploited by a bunch of accounts performing the same action. As for the current request. I'm not against switching to Asirra, but I don't think it will change a lot (or maybe only for a small amount of time). I still would really appreciate if someone checks if this account creation flood is done by a few single IP's or by unique IP's for each account. If it is done by someone who has a botnet, it is in my experience unlikely that this is just to spam.Ranique (talk) 15:52, 5 August 2013 (UTC)

@poke: do you mean that if we split the database for the 2 English wikis you'll be able to do the cleaning by yourself? If this is true, we can prioritize this.

@Ranique: we've asked ourselves the question of motive but have failed to see a pattern with these accounts (IP, email addresses, account names, etc.). At this point it just looks like there's no real point to this we can determine (a DDoS is always possible but this has been going on for so long that it doesn't look realistic). Be ensured also that we've got regular backups of the wikis and can step up to attacks, if they were to happen. Captcha rotation is something we could do but we don't think it'd buy us anything since they can go through them already (like Dr Ishmael said).

If anyone knows a solid MediaWiki extension that could help us improve the situation, we'd be happy to hear about it! —The preceding unsigned comment was added by Contributions/ ([[User talk:|talk]] • contribs) at 22:52, 5 August 2013‎ (UTC).

There's no "magic bullet" extension, that's why we're having this discussion. :) If you or Justin haven't seen it already, though, you should check out mw:Manual:Combating spam - it's a comprehensive list of techniques that system administrators can use within MediaWiki to prevent the kind of spam that we're seeing. The majority of them involve wiki and server configuration changes, which are out-of-scope of anything we would normally discuss within the wiki community. But if there's anything in there that you guys think you can implement easily and will have a significant effect, go ahead! —Dr Ishmael 23:58, 5 August 2013 (UTC)

We already went through this page, indeed. I was thinking that it'd be nice if there was an extension that'd require email confirmation for the account to be created, but well :) --Stephane Lo Presti talk 00:01, 6 August 2013 (UTC)

I think email confirmation would discourage legitimate users from registering too. 00:40, 6 August 2013 (UTC)

they could just use a ip if that's the case. but its a rather standard thing to have e-mail confirmation on websites. and if someone wants to be a registered user they will jump thew any hoop.- Zesbeer 00:51, 6 August 2013 (UTC)

It is distinctly anti-wiki to require an email address for account creation, and since we want users to register, putting up hoops for them to jump through is not a good thing. 00:54, 6 August 2013 (UTC)

Puttng it that way, ReCaptcha or Asirra is also a hoop for users to jump through when registering. We could replace that hoop with email confirmation (although I haven't found the extension or configuration setting for that, it is mentioned on MW.org that "[some] wikis require email confirmation" so apparently it's possible). Both of those are common security techniques employed on other websites, it's simply a tradition of wikis to not require email confirmation. That doesn't mean we can't or shouldn't do it if it's the "right thing" to do. —Dr Ishmael 01:21, 6 August 2013 (UTC)

I think those email configuration things usually work in a way that you can register your account, but to use it (or get elevated rights, i.e. autoconfirmed) you need to confirm your email. So this won’t really solve the registration spam. It should rather be something that requires you to enter your email, and then you get a mail with a personalized registration token you can use to register a new account. But I’m not sure how we could prevent that being abused as well, given that you could just keep generating tokens and distribute those to spam bots. And we don’t really want to limit accounts to one user per email address, do we?

And yes Stephane, if the user databases are unlinked, we will be able to savely delete user accounts ourselves. poke | talk 10:31, 6 August 2013 (UTC)

(Reset indent) Hello. I'm fairly new to this wiki, but the wiki I am most familiar with had a huge spam problem too. I just wanted to hop in here with a little input in case it might help. First off, can you check how many spammy accounts have actually registered with an email account? Most of them were on the other wiki I use, so it may not help here very much if that's the case. In addition, bots were bypassing the captcha by creating accounts through the API (which was stopped) and were bypassing CheckUser (we still don't know how); I am unaware whether that is possible here.

With Asirra, our spam account creation has cut down some, but not as much as desired. (Between 18 March and 31 March, shortly before implementation, it averaged 80 per day; between 19 July and 9 August, 48 per day.) The main concern was that it used JavaScript, but we haven't heard any issues with that yet. Once set up on a test server, it was tested on multiple browsers, and worked on the most recent versions of Chrome, IE, Firefox, Opera, and Safari. While it may not be perfect, per Ranique's article, it has been useful. Vely^►t►e 04:27, 10 August 2013 (UTC)

Hi Vely, thanks for the useful information. We'll take this into account in our internal discussion. Did you have feedback from your users about the change, e.g. if it was harder for them to create accounts? Thanks --Stephane Lo Presti talk 18:56, 12 August 2013 (UTC)

The only issue encountered was an unexpected loop with adding links, where you would repeatedly be asked to answer the captcha when using Show Preview if adding a link, but would only answer it once when not previewing; I'm pretty sure this is removed for autoconfirmed users on that wiki though (10 edits on a 3-day-old account). (We couldn't apply the captcha to just account creation, so it replaced the previous captcha.) Otherwise, all I've seen in terms of feedback has been something like "lol, cats" in the chatroom. We have had over 93 legitimate accounts created since then (93 being those who have made userpages), with no apparent increase or decrease in anonymous edits. Vely^►t►e 19:30, 12 August 2013 (UTC)

And the new user "problem" is ramped up even more. Some decisions may just take too long. Special:RecentChanges has more "users" joining than genuine wiki entries. There's over 150 new users with TWO making a contribution. Time to set up another study group and decide on the agenda probably. <-Irony --Claret (talk) 15:27, 15 August 2013 (UTC)

Have you ever thought of using a honeypot on the account creation forms? Add another label/input line to the form with a random unique name/id which is generated with each refresh. Hide the original e-mail input via the stylesheet (never inline, because it's our honeypot) and add the description of the label via css :content. A bot will try and fill the original fields and also possibly the new field with data. Now you'll only need to check if the honeypot is filled and abort account creation if so. Simple but usually effective. --Smiley™ de: user | talk 16:58, 15 August 2013 (UTC)

Question CAPTCHAs

So, as per my idea somewhere above, I’d like to give the “QuestyCaptcha” a try. It essentially works by giving the user a textual question which he has to answer. Such kinds of questions usually have the highest effectiveness because while for ReCAPTCHA and Asirra there exist standard solutions to solve the CAPTCHAs with a bot, customized questions require actual work to target a single site specifically. So if those spammers wanted to continue, they would have to figure out all the answers to all the questions manually and program the bots to handle that. It’s unlikely that this will be the case because as far as I noticed, none of the spam bots so far really targeted us directly (using GW or gaming related spam) but rather used the open vulnerability to just register on every wiki they find.

So anyway, we need some questions. And because it would be somewhat stupid to collect those publicly, I would like you to email me your suggestions. I’ll then collect those and send them to Stephane so they can enable it for us. Questions should be rather simple, so really any real visitor can answer them; so stuff like “Enter the word ‘hello’:” would be just fine. Requiring some basic GW or wiki knowledge is fine too—you can even link to articles so if they really don’t know the answer, they can look it up. For example “How many races are available as playable characters?” or “Which soldier profession starts with the letter ‘G’?”.

So really, there are very many possibilites; the only restriction would be that it’s simple and static (so “What is the current chapter in the living world?” would be bad). And we really can’t have enough different questions, so keep the suggestions coming! poke | talk 15:58, 15 August 2013 (UTC)

"What is the capital city of the Norn?", "What is the capital city of the Asura?","What is the capital city of the Sylvari?" etc, "Who is the racial leader of the Norn?", etc. But, really, make the suggestion now with a high priority and the questions can follow. Probably better change them regularly, even bot-masters can learn. it can't be too difficult to change a Q&A text file. --Claret (talk) 17:41, 15 August 2013 (UTC)

“make the suggestion now” – No idea what you are talking about. And no, questions cannot follow because it’s not a simple text file we can just get replaced quickly. poke | talk 18:01, 15 August 2013 (UTC)

Actually, we could: instead of defining them directly in LocalSettings.php, include a separate file that contains the questions.

• LocalSettings.php

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php");
$wgCaptchaClass = 'QuestyCaptcha';

require_once("./GW2WQuestyQuestions.php");

• GW2WQuestyQuestions.php

$arr = array (
        "A question?" => "An answer!",
        ...
);

foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );
}

This would clearly demarcate the questions from all other wiki configuration, making it simpler to modify the questions without touching anything else. —Dr Ishmael 18:11, 15 August 2013 (UTC)

To quote Stephane: “we’re now testing any new stuff we add to wikis and it can take a week”. poke | talk 21:51, 15 August 2013 (UTC)

I talked to our engineer and we're willing to give QuestyCaptcha a try. If you can provide us with the file GW2WQuestyQuestions.php that Ish mentions, we can then start to put it in our next wiki update (which will include a couple of other minor things). I have still have concerns about the user experience for legitimate players but it didn't raise anyone's flag here or on the IRC channel. --Stephane Lo Presti talk 21:59, 15 August 2013 (UTC)

"make the suggestion now" means, in context, make the suggestion to ArenaNet now rather than thrash out all the details first. My thought was that if ArenaNet took the idea and agreed to it in principle, something which I could not see that they had done when I wrote the comment, then the details could be sorted out later. Evidently that's happening. As an addition, it would be better if one person or a small group compiled the question/answer list off the wiki. It would be silly to publicise the security questions/answers surely? —The preceding unsigned comment was added by Claret (talk • contribs) at 22:18, 15 August 2013‎ (UTC).

That’s why I asked people to send me their questions per email. poke | talk 22:33, 15 August 2013 (UTC)

I see that. Well done. --Claret (talk) 22:36, 15 August 2013 (UTC)

(Reset indent) Two weeks since the last entry on this subject and new users averaging about 150 a day -that's about 2000 in that time, many spammers but thankfully only a small proportion, although a very large proportion of the new users contributions. Any progress with the CAPTCHA or whatever? --Claret (talk) 01:03, 30 August 2013 (UTC)

Another two weeks and no comment to my previous. Still 100+ new "users" a day with a very large proportion of spammers in those accounts that actually contribute. Is this a dead subject? --Claret (talk) 13:17, 17 September 2013 (UTC)

Justin (Anet wikidev) is working on testing QuestyCaptcha, that was also about 2 weeks ago. Haven't heard anything since, but Poke is probably more in touch on this subject. —Dr Ishmael 14:04, 17 September 2013 (UTC)

As Ish mentionned, we've got QuestyCaptcha set up and ready to be tested. I've been a bottleneck in the whole update process, as the last week have been incredibly busy for me. We're going to try to start the testing process this week but the push of the update to live won't probably happen until a few weeks later. --Stephane Lo Presti talk 16:36, 17 September 2013 (UTC)

Thanks for info. --Claret (talk) 16:38, 17 September 2013 (UTC)

QuestyCAPTCHA failed. Bots 1, us 0. :( poke | talk 19:40, 24 October 2013 (UTC)

So now, as the QuestyCAPTCHA has failed, I get the impression that the problem is going to be hidden rather than solved. There must be some overhead to approximately 150 new members a day = approximately 55k per year. Or does anyone care? --Claret (talk) 01:54, 7 November 2013 (UTC)

Well, we discussed multiple possibilities, but agreed, that we simply can’t win this war. We could make the registration more restricted and add other things, but in the end it would just require us to invest a lot of work and it would hurt the good users a lot. Nearly all of those registered accounts don’t end up doing anything ever. We don’t understand why they are even bother to register, but at least they don’t do any harm apart from spamming the recent changes (which will hide those entries by default starting later today). Yes, we do get a ton of unneeded accounts this way, but it’s not like they take away something. The space that is required to store those accounts is very small (a vandalism edit is likely bigger) and disk space is not a problem anyway.

Right now, we still have the situation that the GWW and GW2W user databases are linked, so accounts created on one wiki also exist on the other wiki. This is the next change that is planned for the near future, splitting the databases, so each wiki is independent. That will allow us to use the existing features to delete user accounts. As soon as we can do that, we will start to periodically clean up the user database and remove a lot of those spam accounts. So that shouldn’t be an issue either.

I personally am quite sad that our tries so far have done literally nothing. I did expect a lot more success from QuestyCaptcha. After all we added custom and GW2-relevant questions. But the spam bot creations didn’t stop at all; they apparently weren’t even impeded at all. So yeah, at this point I just agree with Stephane that we cannot win this. poke | talk 11:56, 7 November 2013 (UTC)

We can always try Asirra. It did help when GuildWiki implemented it. —Dr Ishmael 15:03, 7 November 2013 (UTC)

Hi Claret. I'm going to add a bit of background to poke's good explanation of the situation. When we first heard about this issue a while ago, we did some research and investigation about it. It lead us to believe that the problem was probably unsolvable. Yet we acknowledged that it was a annoying problem for the wiki community and in particular the part of the community that works to ensure that the wikis are in a "good state". So I pushed for us to try our best different things, given the resources we had and despite the fact that some hard facts point to the problem being unsolvable (e.g., wikipedia is hurt the same way). When we decided to implement QuestyCaptcha, and there was quite some work involved (ask poke), we thought that it'd be a turning point into our attempts to fix the issue. And it failed because, within minutes of the change, the account creation spam was back in full force.

So now we're thinking differently. We're not trying to fix the issue, because we think it's an arms race that we cannot really win, but rather use a two-prongued approach: 1) remove the Recent Changes cluttering with poke's extension; and 2) clean the user database (at a later stage). #1 is coming today, while #2 will require more work on our side, both from a server backend perspective (we may also work at the same time on other tasks such as splitting the GW1 and GW2 user databases) but also to communicate this adequately to the wiki community.

In conclusion: there's been a lot of work and talk behind the scene on this topic. It's not that we don't "care" (we do) but that this specific issue required an unusual amount of work and we've reached the end of a road that's several months long. We're not happy about the problem but we're now focusing on spending our time on actions that will visible benefit the community. --Stephane Lo Presti talk 17:50, 7 November 2013 (UTC)

Thanks for that information and the background. --Claret (talk) 21:56, 7 November 2013 (UTC)