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
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 bards; 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 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 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 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  $(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 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);      }    }  } });
 * Add
 * to an appropriate JS page.

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  $(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. 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. Additionally, it squeezes the content due to a useless sidebar, and removes some features like the navigation bar. SOLUTIONS  .AdminDashboardRail, .AdminDashboardDrawer, .AdminDashboardTabs, .AdminDashboardGeneralHeader { display: none !important; } .WikiaArticle.AdminDashboardChromedArticle { background: none !important; border-bottom: medium none !important; border-right: medium none !important; box-shadow: none !important; padding: 0 10px !important; width: 980px !important; } .ns-special .WikiaPage .WikiaPageBackground { background: #ffffff; }
 * Add
 * 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.