Pyra Wiki Scope


comradekingu

Glowing ember
Joined
Apr 15, 2011
Messages
5,071
Website
portfolio.anotheragency.no
Its not like any of those would be incapable of just making accounts anyway. The feedback plugin on the wiki has been very helpful, and its certainly easy enough to spam that down.

And bots are equally able to have email-addresses, so i dont see what stops spam about that.

Two different captchas that arent superhard is better than one insane one, since it limits the attack vector to targeted attacks. One super-captcha is bad because it annoys, and also you can just man-in-the-middle route it to an unsuspecting person thinking they are using it to log into a different site.

TL;DR allow guest editing, and get WYSIWYG editing. If it works on wikipedia, it can work elsewhere.
 
Last edited by a moderator:

LEOXD

Member
Joined
Feb 4, 2014
Messages
121
Age
24
Location
Denmark
On the Stupidedia, our biggest problems regarding unwanted content weren't bots (in fact, I haven't seen a single single content spam bot since I started there in 2011), but other people (with accounts) who tried to do damage and drunk IPs who edited a few pages. 
BTW, on MediaWiki you don't even need to provide E-mail-addresses to create accounts. 
 
From my experience at the Stupidedia, one person can easily check all edits made in an entire day within one, maybe two hours. And this is the largest German satire wiki. I expect the pyrawiki to have a much lower update frequency than Stupidedia.
If you have bots, your anti-spam-tools suck. And if one actually comes through, you can have a script that reverts all changes made by a user/IP/IP-range/regex-pattern, or that reverts all changes made within a certain time span. 
 
Having one captcha that requires the user to search for something is bad. Taking the example from the pandorawiki: "Please check the Pandora Boards General Section for the password". There is no link to "Pandora Boards" on the wiki. If I was a newbie and only mildly interested in helping, my journey would end here. But if I actually figured out that "Pandora Boards" means "Forum" and "General Section" means "General Talk Section" and then found the post, okay, I could register. But there are not that many people who would want to go through this process, just to fix a typo or another little thing.
However, if I wanted to spam and found that captcha thing once, I could just let my bot autofill the captcha field.
This system is a good protection against bots that spam at random (but then, so is a question like "what is 5+5 divided by ten? [write out the number]"), but a weak protection against aimed attacks. It is also a horrible user experience (unlike the 5+5 example). 

If you have the tools (already mentioned in a previous post), bots are basically a non-existent issue. If you want to maintain it manually though, the current lockout is probably the easiest way. But maintaining it manually is a bad idea anyways. 
 

comradekingu

Glowing ember
Joined
Apr 15, 2011
Messages
5,071
Website
portfolio.anotheragency.no
http://pandorawiki.org/Pyra:Main_Page

Dont know if thats done right, cant remember, all the old namespace language codes are old and defunct, using the right ones now,  &lang=** or any similar approach does not work though...

Anyhow, add pages thought to be missing, source info on the forum relating to the pages that are there.

The 1.23 wikiupdate is happening as soon as ED has some time over for it, which could be soon, or could be not soon.
 

LEOXD

Member
Joined
Feb 4, 2014
Messages
121
Age
24
Location
Denmark
http://pandorawiki.org/Special:Namespaces

You didn't set up the new namespaces though.

https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces

the lang parameter doesn't work, because its name is uselang (temporarily) or setlang (setting). The menu for the setlang stuff is located in the upper right, next to the account stuff. Note that this currently only alters the default stuff (MW interface, such as the headline for the search box), because it isn't anything else set. 

Edit: Also, why are new users immediately autoconfirmed? This kinda eliminates the sense of it.
 
Last edited by a moderator:

Nemo_bis

Newbie
Joined
Jun 7, 2014
Messages
3
Subpages [...] should be used for translations and other specifications

categories are used to group topics [...]

A common problem when putting all languages in one wiki is that you are basically always only one click away from reading english again. It is possible to prevent this to some extend by using stuff like Autotranslate and LangSwitch, but I'm not familiar with this stuff. 
Yes, subpages are the standard for translation of any kind of page including categories. Categories subpages can be handled automatically with some template tricks.

LangSwitch is ancient and superseded; autotranslate is only for templates and on its way to deprecation. Once the user has changed interface language with UniversalLanguageSelector, all the next links they follow will bring them to translations in that language when available. You just have to prefix all the links with Special:MyLanguage.

[...]

 &lang=** or any similar approach does not work though...

the lang parameter doesn't work, because its name is uselang (temporarily) or setlang (setting). The menu for the setlang stuff is located in the upper right, next to the account stuff. Note that this currently only alters the default stuff (MW interface, such as the headline for the search box), because it isn't anything else set.
LEOXD is right, but remember the configuration bit I mentioned on the other thread.
 
Last edited by a moderator:

LEOXD

Member
Joined
Feb 4, 2014
Messages
121
Age
24
Location
Denmark
I hereby suggest that every translation related stuff in the wiki is handled by Nemo_bis.
 

RuneIV

Member
Joined
Jul 17, 2013
Messages
88
Location
Qc, Canada
Personally, I prefer Binky's subdivision which is more succinct and doesn't overwhelm the visitor with too much information at first.

My gold standard for a technical wiki is the ArchWiki. They've put the detailed categories (similar to what comeradekingu is suggesting) in a Table of contents. What makes it so great is its completeness. But, of course there are no easy way to ensure that people write articles and keep them up to date.
 

comradekingu

Glowing ember
Joined
Apr 15, 2011
Messages
5,071
Website
portfolio.anotheragency.no
http://pandorawiki.org/Pyra:Main_Page  This is what it is so far, software sections and hacking has placeholders for now.

Is there anything you think of, that doesnt have a logically fitting place to find it?  Changes?   

I want to _____, this is where i would expect to find it _____.

Click on the pages for a brief into on what they are about if it isn't self-explanatory.

Changes:

1. The top text is going away, the pandorawiki was too much of a landing page. With the new website being better, and a good introduction on things pyra, there is no need for that. Instead it can be included in the theme and with the top-bar of the main webpage rather than having to visit mediawiki.  Here is how i envision that  http://boards.openpandora.org/topic/16658-pyra-website-design-ideas/#entry344981/URL]

Possible changes: 

1. Change in the alphabetical order of the hardware, to have CPU/GPU and RAM under moduleboard, but i dont know if ram is on there or the mainboard

Mainboard

→ Bluetooth

→ WiFi

→ USB

Moduleboard

  → CPU

  → GPU

  → RAM

A logical extention of this logic would be to start out with Case (which also is a quite central page)

2. Replace text with symbols/add symbols. Debian logo, Wifi logo, pictograms etc to make it faster to scan visually.

2. Colourcoding the hardware category header blue along with the "modifications"  so that its clear its about hardware

 Hardware       Software        Hacking

                                              Modifications
 
Last edited by a moderator:
Top