User:Sovq

About me
Hi!

I'm Sovq. I'm an avid wiki editor ever since I started contributing to my first wikis. The idea of creating content and sharing it with others sucked me in pretty quickly. I enjoy the freedom that the MediaWiki software gives to the users, transforming them from passive receivers of information into active contributors. While most Web 2.0 sites offer only limited control over the content, giving the users just basic 'templates' to play around with, Wikia and other wiki-farms go way beyond that, allowing the user to create and customize skins, functionalities, layouts and tools which can be used to further expand one's idea for a wiki. I believe that the future of the Internet lies in giving the users more and more control over what they want to see and share, wiki-farms fit into this vision perfectly.

Most of my edits on Wikia can be found on: I also often visit the Community Central Forums, trying to help other Wikians however I can.
 * Sacred Seasons 2 Wiki
 * Sacred Seasons Wiki
 * Dead Frontier Wiki
 * Dungeons of Dredmor Wiki

I tend to be on the behind-the-scenes side of editing, which means: modifying styling and functionalities, designing templates, categorizing and organizing content, ensuring everything looks and works as expected.

I use another account, User:Sovbot, to make automated edits with a pywikipedia bot.

To-do list for Community Central
This is a list of Community Central Wiki issues that in my opinion diminish its quality. Due to lack of appropriate user rights or authority on the wiki, these cannot be solved by me. Too many forums I find splitting the forums into sub-forums and sub-sub-forums a bad idea. Even with one board, the number of added threads was easily manageable. Having one central place for forum activity is easier to find and browse. I would understand two boards; one for general requests and discussion one for design requests, but why make 6 of them? Especially since they cover pretty much the same subjects (as opposed to what has been said about their objectives when they were split up). I now feel sorry for users trying to post a question and having to decide which board it should be posted on: "Technical Help", "General Questions" or "Support Requests"...

Forumheader template It's a mystery to me why the admin forum and 'regular' forum use separate Forumheader templates, since they are (or should be) identical. What bothers me is that nobody, even after a number of reports, both on talk pages and chat, cares enough to make these templates look decent and not like on this page.

Support requests board listing unordered threads The "Support Requests" board lists both "Support Requests" category threads as well as "Community Central Forum" threads. While I'm partially responsible for that - the dpl forum extension doesn't allow (at least to my knowledge) having board listing two categorizes - the forum should be fixed already by excluding the "Community Central Forum" threads from the first page forum query.

To-do list for Wikia
This list will include all the problems, oddities and annoyances I had to endure during my history on Wikia wikis. Luckily some of these can be dealt with by modifying Special:Preferences, others by customizing personal .js or .css pages, but unfortunately new users will have to live with them, until they figure out how to customize their preferences. Hopefully some of these issues will be either fixed by Wikia or made just optional and disabled by default for new users. Rich Text Editor It's always been buggy, but since the new Wikia skin was released, more and more wikis are using dark color themes. In such themes, editing with the RTE can be anything from annoying to impossible. The RTE changes the page formatting on it's own, uses colors from wrong css classes or uses mixed styles (try to edit a template in a dark-themed wiki), doesn't support a huge number of normal wiki-markup functionalities and in my opinion discourages new users from editing. SOLUTIONS
 * Disable in Special:Preferences > Editing > Enable Rich Text Editor.
 * Request disabling through Special:Contact wiki-wide. Requires community support.

Add category buttons (CategorySelect extension) These buttons serve one purpose on the wikis I'm active on; make vandalism easier. Contributors who want to add a category shouldn't have a problem adding the category "the proper way". Furthermore, from my experience, it's usually the regular editors and admins that are responsible for the category structure and such users edit in source mode anyway. SOLUTIONS
 * Disable in Special:Preferences > Editing > Disable Category Select.
 * Request disabling through Special:Contact wiki-wide. Requires community support.
 * Add  to an appropriate CSS page.

Link Suggest extension Luckily I disabled it soon after I noticed it, but during the time it was on, it would only annoy me; the suggest box wouldn't go away, no matter what I wrote or clicked. SOLUTIONS
 * Disable in Special:Preferences > Editing > Do not show link suggest in Source mode.

Default user pages By default there is an image placeholder on those, which leads to users adding a number of unrelated, uncategorized and unlicensed images. There are already account avatars - why encourage users to add even more personal images? SOLUTIONS
 * Edit MediaWiki:Welcome-user-page and remove the placeholder.

Default welcome messages PARTIALLY SOLVED These would be fine if, by default, wouldn't include a link to the edited article. If a vandal creates a rubbish article and this article gets deleted, the WantedPages report will still show that article as "Wanted" by the vandal's user talk page, unless the talk page gets edited as well. SOLUTIONS
 * Edit MediaWiki:Welcome-message-anon, MediaWiki:Welcome-message-user-staff and MediaWiki:Welcome-message-user and replace the $1 symbol or the whole sentence with something not linking to the article in question.

SOLVED
 * This has been partially solved. The new default MediaWiki:Welcome-message-anon and MediaWiki:Welcome-message-user now use  instead of the previous  . MediaWiki:Welcome-message-user-staff is still using the link though.

Wanted Pages/Categories/Files/Templates reports This issue is related to the previous one. The reports will show all content that is wanted on pages in all namespaces which means all the personal stuff, which has been added by users, but was unwanted and got deleted, will show up in the reports making them hard to use or useless. Excluding the user namespaces from the reports would make it easier. SOLUTIONS
 * None

Wanted Pages The WantedPages report will list a page that turned out 'false' when using the ifexist parser function, making the WantedPages report useless on any wiki using the ifexist function. See bugzilla for details. I know that this is a MediaWiki issue, but I imagine Wikia has the resources to figure out a workaround for it. SOLUTIONS
 * None

Create page pop-ups The new page pop-up, by default, allows you to chose one of 2 layouts, which causes inconsistencies among articles on wikis that don't use/need custom layouts. I don't see why that should be enabled by default. SOLUTIONS  $(document).ready(function { $('.createpage').unbind('click',CreatePage.openDialog); });
 * Disable in Special:Preferences > Editing > Disable Create Page pop-up.
 * Add
 * to an appropriate JS page. Thanks to Rappy for this one.

Image lightboxes File pages contain more info and are more intuitive than the lightboxes. If users want to enlarge the image they can always click on it again on the file page. SOLUTIONS  $(document).ready(function { $('#WikiaArticle').unbind('click.lightbox');  var a = document.getElementsByTagName("a");  for ( var t = 0; t < a.length; ++t ) {    var a2 = a[t];    var img = a2.getElementsByTagName("img");    if ( img[0] != null ) {      if ( a2.href.indexOf("images.wikia.com") != -1 ) {        var link = wgServer + '/wiki/File:' + a2.href.substring(a2.href.lastIndexOf('/') + 1);        a2.setAttribute('href',link);      }    }  } });
 * Add
 * to an appropriate JS page.

Upload image pop-ups These encourage to upload images without category or license info, due to the fact that advanced options are hidden in the pop-up window. SOLUTIONS  $(document).ready(function { $('a.wikia-button.upphotos').unbind('click',UploadPhotos.showDialog); });
 * Add
 * to an appropriate JS page.

Default content on new wikis New wikis always receive a number of project pages, community guidelines and default templates that will never be used and just clutter the wiki up. I believe that the users should create their own 'backbone' content - that way it will fit the wiki better. Furthermore new wikis receive a number of dysfunctional content, for example a Template:For/doc page but not an actual Template:For page. This is true for multiple pages, not just 'ghost' templates. SOLUTIONS
 * The only solution is to remove all the rubbish content as soon as possible before anyone uses it. Afterwards a proper category/policy/template structure should be established.

Admin Dashboard Similarly to the issue with the RTE, the Admin Dashboard looks horrible and unreadable on wikis with dark color themes. On light ones looks functional, but it's sill a mystery to me why new styling had to be used instead of using the user-customized one. SOLUTIONS 
 * Add

.AdminDashboardGeneralHeader, .AdminDashboardArticleHeader, .AdminDashboardHeader { display: none !important; }

.WikiaArticle.AdminDashboardChromedArticle, .ns-special .WikiaPage .WikiaPageBackground { background: #ffffff; }
 * to an appropriate CSS page. The  needs to be replaced with the background color of your article space. While this does not solve all the Dashboard drawbacks, it makes it more manageable and resembles the default, superior layout.

Optional features SOLVED Read more sections, category galleries, picture attribution etc.. can all be disabled via Special:Contact - why not allow admins to do that themselves through an additional tool (or Theme Designer)? SOLVED
 * Wikia Labs is doing the job.

Floating footer SOLVED When using a browser's search function, the searched phrase will usually appear in the bottom line.. which is blocked by the footer. That means that every performed search requires an additional 'scroll down' to see the word. That can be a real annoyance when browsing through a really long article. SOLVED
 * This has been fixed by making the whole page automatically scroll up 1 line whenever a successful search is performed. That's certainly a creative idea and an improvement. It gives a slightly buggy impression when quickly going through searched phrases, but otherwise it's perfect.