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. Having six boards, possibly more in the future, in different sections of the wiki is confusing. Especially since they cover pretty much the same subjects. I 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". SOLUTIONS Users who consider this a problem can create a 'summary' forum page using regular DPL, like here. One downside is that due to this not being the forumdpl extension, threads which have been visited will always show as :visited, even if someone responds to them.

Forumheader template The Forumheader templates, both of them, use a table instead of the default div block to display the thread info. This thread shows the exact problem - when thread subjects are too long, they split into two lines disrupting the formatting. SOLUTIONS Replace with Forums: Index → Forum: → in the Forumheader template. For consistency, the Forumheader2 template should be similarly adjusted.

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 categories - the forum should be fixed already by excluding the "Community Central Forum" threads from the first page forum query. Otherwise the Community Central Forum threads will be listed forever. SOLUTIONS The solution is as simple as it gets; replace

in the Forumheader template with

and remove the Community Central Forum query from the forum.

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 really challenging. 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. I believe that adding categories is straightforward already. Additionally, from my experience, it's usually the regular editors and admins that are responsible for the category structure and such users should have no problem with adding categories in the editor. 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.

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. The option to exclude 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 for different kinds of pages. The option to disable this pop-up would be helpful 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 in the pop-up window are hidden. 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 unwanted 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, the dashboard changes alignment of elements in the header area, thus making it look bugged in wikis which have customized their header. 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 layout.

New editor layout In general I consider the new editor layout an improvement over the old layout with RTE enabled, but there a bugs which could use fixing: SOLUTIONS
 * I'd like to have access to the navigation menu, because I often require to visit other articles while editing.
 * I'd like the layout to remember which mode (Visual/Source) I was last in. As I recall this was supposed to be added.
 * Lack of Javascript in preview mode makes the preview unreliable.
 * Color theme is fixed, would be nice if it derived colors from Theme Designer or even better - Wikia.css (Same goes for Admin Dashboard btw).
 * The warning before closing window/tab can be useful for some and annoying for others, like me. Making it optional would be a relief.
 * I'd like the notifications to disappear after I click anywhere, not just on the text area.
 * Lack of autocomplete in the edit summary box makes some tasks take much more time
 * MediaWiki:Newarticletext isn't visible enough.
 * The font size in source mode - 13.5px -looks worse than the good, old 13px.
 * The dark color theme issue can be fixed by adding a lot of CSS code to an appropriate CSS page. If anyone's interested, the Dead Frontier Wiki uses a customized black/red editor theme, feel free to copy the code which is in the "EDIT PAGE LAYOUT OVERRIDES" in Wikia.css

New user page design I don't really mind the new design. It's a bit too big for my liking but it's not an inconvenience. The main concern is the way it automatically adds wikis to the "My favourite wikis" section. Users who contribute to a lot of wikis, but don't want to share that information, not only need to manually clean the list once in the beginning, they also need to do so every time they edit a new wiki. SOLUTIONS
 * None

Solved problems
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/WikiFeatures 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.

Link Suggest extension SOLVED 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 SOLVED Either my attitude towards this feature has changes or the extension has been adjusted to be less intrusive than it was.
 * Disable in Special:Preferences > Editing > Do not show link suggest in Source mode.