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. Who would believe that you can get addicted to wikis? ;). Most of my edits can be found on: I'm also a regular at the Community Central Forum, 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

 * I find splitting the forums into sub-forums and sub-sub-forums a bad idea. Even with one board, there's not enough contributors to clutter a forum up - 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"...


 * 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.


 * 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 1 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 won't have a problem with spending 2 minutes to read the help page and add 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 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.

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 is unwanted and gets 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 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
 * Disable in Special:Preferences > Editing > Disable Create Page pop-up.

Image lightboxes File pages contain more info and are much more transparent than the lightboxes and 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);      }    }  } }); to an appropriate JS page
 * Add

Upload image pop-ups These encourage to upload unlicensed and uncategorized images, due to the fact that advanced options are hidden in the pop-up window. SOLUTIONS
 * None.

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. Let the users create their own customized content instead of suggesting a "standardized" one. Furthermore new wikis will 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 'phantom' 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
 * None.

Optional features 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 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.