User:Badon



I do mostly testing, bug hunting, and documentation writing. I have a particular interest in doing it for Semantic MediaWiki and related extensions, but I jump in anywhere I feel I can be helpful. I usually avoid documentation writing for SMW and related extensions, except on my user page here, where I like to add useful bits of info I want to share.

I have officially reported 75 bugs as of January 1, 2012 (and a few more unofficially *). 56 of them are either FIXED or still open, and the rest are DUPLICATE, WONTFIX, or LATER. That gives me a 75% "usefulness" rate in my bug reports, with the remaining 25% often resulting in improved documentation (when the bug is actually an undocumented feature). I am always trying to improve my bug hunting skills and methods.

Mediawiki etc.

 * I did some very minor bug fixes to the config for Extension:JSBreadCrumbs.
 * Bugs and fixes
 * Category:MediaWiki Releases
 * User:Badon/Extension:Semantic_MediaWiki/Manual
 * Markup spec
 * Help:Links
 * Help:Images
 * Help:Contents
 * Manual:Parameters to index.php
 * m:Help:List (Needs to be moved to Help:Lists)
 * Project:WikiProject SysAdmins
 * Project:Help
 * Manual:Collapsible elements
 * RL/DM
 * http://test.wikipedia.org/wiki/User:Krinkle/CollapsingTestpageMw
 * Automatic SMW refreshData, [ SMW query management and smart updates]
 * User:Nischayn22/Gsoc
 * http://greensmw.wordpress.com/
 * http://semantic-mediawiki.org/wiki/SQLStore_Update

Support

 * Web chat
 * WikiMedia mailing lists
 * Project:Support_desk
 * MediaWiki commercial support

Localization

 * Extension:Translate
 * Help:Magic_words

Image annotation

 * Google search: image annotator
 * W3C image annotation
 * Kanzaki Image Annotator
 * Lupo's ImageAnnotator
 * fotonotes.net

Data integrity

 * Data corruption
 * ZFS
 * PCBSD (with very easy ZFS!)
 * Parchive
 * MultiPar

Miscellaneous

 * David Edward Hughes, Inventor of radio
 * TorChat

Widgets
Extension:Widgets is a very powerful extension that's simple to use, and thoroughly replaces the obsolete Extension:RawMsg. Here's a Twiddla widget I made that you can use on your own wiki with the Widgets extension installed. It is very useful when you want to show someone how to do something on your wiki.

Google translate widget
 This widget enables Google translate tools. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;

 function googleTranslateElementInit { new google.translate.TranslateElement({   pageLanguage: 'en',    multilanguagePage: true,    layout: google.translate.TranslateElement.InlineLayout.SIMPLE  }, 'google_translate_element'); } 

It's not required, but if you add the following to your MediaWiki:Common.css, your widget will display nicely on the right side of wiki pages, on the same line as the page H1 title header thing:

 /* For the Widget:Google_translate in MediaWiki:Sitenotice */
 * 1) siteNotice { height:0; }
 * 2) localNotice { height:0; margin-bottom:0; }
 * 3) siteNotice p { margin:0; padding:0; } /* Clean easy-to-read wiki formatting while producing superfluous tags WITHOUT extra spacing in the sitenotice */

/* For the Widget:Google_translate in MediaWiki:Sitenotice */
 * 1) google_translate_element { text-align:right; position:relative; top:-0.67em; }

Twiddla widget
 This widget allows you to add a Twiddla meeting to a page. [ Edit the page] to see the widget text.

You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;



HTML5 video and subtitles widget
Widgets are usually pretty easy to make, but this one was a challenge. If you use this widget, I would be delighted to hear about it. It features not only video, but also user-entered multi-lingual subtitling. It's annotation for video! A big "Thank You!" to everyone who made this widget possible. You know who you are.

UPDATE: This widget does not work as well as I had hoped. I have discovered several flaws in the subtitling that sometimes cause other things to not work. I recommend ditching this widget in favor of the YouTube widget for now.

 This widget enables HTML5 video and audio using the html5media JavaScript component. This widget also optionally enables Universal Subtitles using the US Amara Widgetizer. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;


 * url is the URL of the video, and is the only required parameter.
 * width and height are optional video size dimensions. width=640 and height=360 is the default.
 * poster is an optional image URL to display while the video is loading. A video frame is ideal.
 * controls is an optional parameter that will show controls (play, pause, volume, etc) immediately upon load, before playback begins, when the value is yes, which is the the default value if not specified. Use the value no not show controls.
 * preload is an optional parameter that will preload the video immediately upon load, before playback begins, when the value is auto. If not specified, the value none will be used to not preload. The value metadata will only preload metadata. Note that not preloading the video will cause the subtitlesforall parameter to not take effect until the user begins playback.
 * subtitlesforall will enable subtitles for all videos on a page when the value is yes. Note that not preloading the video will cause the subtitlesforall parameter to not take effect until the user begins playback.

Recommended widths and heights
height=215 height=236 height=360 height=450 height=576
 * For 16:9 wide screen format videos
 * width=400
 * width=420
 * width=640
 * width=800
 * width=1024

height=300 height=315 height=480 height=600 height=768
 * For 4:3 monitor format videos
 * width=400
 * width=420
 * width=640
 * width=800
 * width=1024

Recommended software

 * Screen recording
 * http://camstudio.org/
 * http://www.hyperionics.com/hc/downloads.asp


 * Video format encoding
 * http://www.mirovideoconverter.com/ - To convert to WebM format.

How to setup incompatible browsers to view WebM video
Browser support for HTML5 WebM video is now widespread. Only a few browsers cannot display HTML5 WebM video. The most notable browsers are Microsoft Internet Explorer (IE or MSIE, including mobile versions) and Apple Mac Safari (including iPad, iPhone, etc, versions). However, most of those web browsers can be made to work by installing a plugin to enable HTML5 WebM video.

How to setup your HTTP server for the correct WebM MIME type

 * http://www.webcoder.de/2010/06/04/how-to-configure-your-webserver-for-webm-video-and-audio-files/

Uploading
Upload your videos at the Special:Upload page.

Subtitling best practices

 * http://blog.universalsubtitles.org/2011/08/09/best-practices-for-subtitling-videos/

Future ideas

 * https://www.google.com/search?q=subtitles+html5+video - There are other subtitlings options that should be explored and further developed, that do not rely on third parties like Amara Universal Subtitles. They could allow the wiki to host the subtitles after they're created using US Amara tools (or other tools), and they could then be translated on-wiki using Extension:Translate.

  

YouTube widget
 This widget allows you to add the YouTube video player to a page. [ Edit the page] to see the widget text.

You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;


 * id is the YouTube video ID, taken from the last part of the YouTube URL, like this (colored red ): http://www.youtube.com/watch?v= DWef69ItVrU
 * width and height are optional video size dimensions. width=420 and height=315 is the default.
 * showmore will suggest more videos if the value is yes. If not specified, the default is no.
 * subtitlesforall will enable subtitles for all compatible videos on a page when the value is yes. YouTube videos will not be affected by other videos if the value is not given or is no (the default).


 * https://developers.google.com/youtube/player_parameters

   <param name="allowscriptaccess" value="always"> <embed src="http://www.youtube.com/v/?version=3&amp;hl=en_US&amp;rel=0" type="application/x-shockwave-flash" width="" height="" allowscriptaccess="always" allowfullscreen="true">  <iframe width="" height="" src="http://www.youtube.com/embed/?rel=0" frameborder="0" allowfullscreen>

Bug hunting tips


This section may evolve into a full guide for debugging. For now, he's a few tips:


 * Check to make sure you haven't accidentally pasted the wrong text into a page. Semantic Forms pages and template pages getting swapped can produce errors that take down the wiki (until the code prevents those error conditions).
 * Check your clipboard manager's hotkey settings (if you have one) to make sure that you're not accidentally triggering hotkey functions that can be screwing up your pastes.
 * Use code inspectors like FireFox FireBug, Opera Dragonfly, or Chrome Inspector, to look at what HTML, CSS, JS, etc is being generated on a wiki page that isn't behaving like you think it should.
 * Use some code to automatically show an error message if you paste code into the wrong page by accident, like this (with Parser functions):


 * Strip down the problem code or circumstance until the bug goes away. That will be your bug demo.
 * If you're struggling with isolating the bug, try setting up a fresh MediaWiki install with the bare minimum of extensions and other "accessories" so you can reproduce the bug with minimum confusion.
 * Try running your test MediaWiki on a separate host from your usual host, so you can eliminate the possibility of a hosting quirk as being the source of your bug. I recommend No Support Linux Hosting for a really cheap hosting solution that makes it easy to set up as many as you want, as long as you're skilled enough to not need support for setting up a website.
 * Make sure common data corruption is not the problem by doing your production hosting on a ZFS system. I think nearly all mysterious failures that can't be traced to a bug are caused by normal data corruption. Data corruption is something that I hope is one day not considered normal anymore. Here are some hosting suggestions:
 * No Support Linux Hosting virtualizes their Linux systems on top of a ZFS storage backbone, so you can use ZFS with Linux even though Linux doesn't support ZFS yet.
 * Another recommendation for ZFS hosting is Entic.net, with very good support and Cartika, which I haven't used yet, but I would like to. All of my recommended hosts will not cause "bugs" to suddenly appear due to data corruption.
 * You can also set up your own ZFS hosting with FreeBSD, which has software support that's almost as good as Linux, and ZFS support that's almost as good as Solaris.
 * If you can't get ZFS, consider at least using MultiPar to protect your files. Read on Wikipedia about MultiPar's underlying Parchive technology.
 * Finally, if you're sure you've found a bug, report it.

Advanced MediaWiki programming toolkit

 * Help:Magic words
 * Extension:Variables
 * Extension:ParserFunctions
 * Extension:StringFunctions
 * Extension:Arrays
 * Extension:HashTables
 * Extension:Loops
 * Extension:ExpandTemplates
 * Extension:DynamicFunctions
 * Extension:ReplaceText
 * Extension:MyVariables
 * Extension:CSS

Other extensions

 * Extension:Semantic MediaWiki
 * Extension:Semantic Forms
 * Extension:Semantic Maps
 * Extension:Labeled section transclusion

Advanced MediaWiki programming tips

 * Whitespace is the enemy. If you can't find it when it's screwing something up, it's because they're wascally whitespace wabbits.
 * Whitespace wabbits like this always bite me at first, but I hunt them down later:

<pre style="white-space:normal;"> 


 * If you can't get rid of the whitespace that's screwing up your wiki pages (especially in tables), put this in your MediaWiki:Common.css to make most of the annoying whitespace "disappear":

.wikitable p { margin:0; padding:0; }


 * Since MediaWiki and web browsers do not show all whitespace characters, finding extra whitespace can be done with the urlencode magic word, like this:


 * To get this, where you can see two  next to each other:

This%20line%20is%20perfect%20except%20for%202%20spaces%20before%20the%20last%20%20word }}


 * You can also persuade the web browser to preserve whitespace using CSS, so you can see where the problems are. Use the CSS white space properties to reveal them.
 * Use HTML lists and tables instead of wiki lists and tables. It makes formatting much easier, and less fragile.
 * Use  at the end of lines to prevent the buildup of empty wiki paragraphs (1  paragraph for each 2 newlines), like this:


 * Do not use  inside   if you are going to test it later with an , because   in your variables will cause them to always pass the test. Like this:


 * is not needed inside functions that do not directly or indirectly output anything, like in string manipulation code.
 * It is better to use many 's within nested   tests than to place your   statements inside a  . It makes debugging mysterious whitespace much easier. Like this:

Distributed template job queue management
When a high-usage template is edited, it can dominate the MediaWiki job queue for days or weeks, sometimes more. The simple solution to this problem is to create several identical versions of the same template, each with a different number. Then, when edits need to be made, the template changes can be rolled out gradually to all the identical templates. While the job queue is processing each numbered template, other jobs can get into the queue before the next template is edited. This also improves testing of template changes, because errors do not affect the entire site, and multiple changes to the same template do not further clog the job queue.

About 30 numbered, identical templates can be used for MediaWiki sites up to about the 100,000 page level. You can use Extension:ReplaceText to find and replace the "main" template with a randomly numbered identical template, like this:


 * Find:
 * Replace:

See also: Bug 37570: Enable parser functions and magic words in Semantic Forms template definition to allow distributed template job queue management.

I have some fancy distributed template management code that I might be willing to share if you contact me about it privately. I don't want to release it under an open source license yet, until I'm finished deploying it and thoroughly testing it in production. Although it is presently quite useful and fairly sophisticated, it's still experimental and could cause problems for someone not able to tear it apart and customize it for themselves.

The ultimate solution to every difficult problem
If you're having no success in solving a difficult problem, you can keep pathetically hacking away at it, or you can put down your psychological torture devices and help someone else solve their problems. Every time I get stuck on something because:


 * I don't have enough skills.
 * I don't have enough experience.
 * I don't have enough knowledge.
 * I've spent too much time coding and my brain is fried.
 * All of the above.

I always find the solution after spending time helping other people solve their problems. Why? Well, for starters, even if I know exactly how to solve the problem, I usually still need to freshen my knowledge by re-reading documentation and doing some easy searches. After a few minutes to a few days of answering questions on the mailing lists, forums, talk pages, and IRC, most of the time I have read and written enough documentation (the answer to someone's question) to stumble upon a fresh idea for solving my own issues.

Whenever I can't sleep at night because some problem is challenging me, I find peace and inspiration by helping others. That works for me, and maybe it will work for you too.

Giving gifts


If you are an awesome MediaWiki helper, please put your Amazon wishlist on your user page. Note that you will not be able to stay anonymous if you do that. If you want to remain anonymous, "printable" eBay gift certificate codes can be emailed to you. If you're a recipient of help from an awesome MediWiki helper, here's where you go to get an eBay gift certificate code to show your appreciation:

https://www.paypal.com/cgi-bin/webscr?cmd=_ebay-gift-certificate

Be sure to select the option:


 * I will print out the gift certificate and deliver it myself.

And then select the amount you want to give. Don't enter in anything else.

Buying stuff for people on their Amazon wishlist, and sending "printable" eBay gift certificate codes, are both anonymous for the sender too! I recommend that you stay anonymous when sending people gifts for several reasons:


 * 1) Everyone loves a mystery.
 * 2) It does not create any expectations of future gift-giving.
 * 3) It encourages everyone to be polite and helpful to each other, since there's no way to know who's sending the gifts and who isn't.

That last one is the most important. Even if only 2 or 3 people are sending gifts, as long as they do it anonymously, it makes the MediaWiki community much more friendly for every one of the thousands of people involved.

See also: WMF Benefactors.