User:✓

Babel user information
de-N Dieser Benutzer spricht Deutsch als Muttersprache. bar-3 Der Benutzer kå schoh wirklé guad Boarisch. en-2 This user has intermediate knowledge of English.

	This user is active in the German Wikipedia as User:✓

	This user contributes Bugzilla

	This user has accounts on the test and test2 wikis

	This user has admin rights on the deWP beta wiki

	This user has the account User:Bergi at labs

	This user translates MediaWiki to German as User:✓

	This User is registered as [Haekchen] and [Bergi] at freenode.net

Hello, I'm Bergi. Since that username was already taken, I found the Unicode Checkmark being a nice choice and a great unicode compliance test for tools. In IRC you can see me as [Bergi] or [Haekchen] (German for checkmark).

My home wiki is de:WP, where I started in 2008. Since then I became an experienced template author, learning more and more about HTML and CSS. I also began to write some skin-extending userscripts. Was customizing the extra-editbuttons-gadget the first? I don't know (Ah, not really). But soon I got annoyed of flooding my version history and cache-purging for every try'n'error-edit, so I went to utilize my browsers userscript feature. What is left on my wikipedia (sub)pages you can see here, and where this ends my userscripts set in: quick'n'dirty snippets rose up to really very long and sometimes-even-not-so-dirty frameworks. As I wanted them to stay local editable I never published any, which also frees me from being responsible for outdated legacy code :-) Yet, there's a list available under /scripts, email me if you're interested.

My first big wikitext project was parsing a table and transforming it automatically into a infobox transclusion, for half-automatic editing a set of thousands of articles. Others include XHTML normalisation (per regex :-C) and comfortable <ref>-tag editing (e.g. for finding duplicates), see [1] or [2]. But all that lead to one diagnosis: We need an extensible, interactive, and exactly result-concordant JavaScript parser. Another purpose of that will be template preview - an impossible thing today.

So I dug through Preprocessor_DOM.php (and found some bugs :-) to implement the same in js (working: xml output). But it was still static, not needed. I pondered a lot about this, and now I will share my thoughts at /MediaWiki 2.0 parser, hoping to be able to contribute to the new Visual Editor project, too.

Another thing I'm keeping an eye on is the ResourceLoader. A fantastic piece of software, perfectly suitable for adding resources to a dynamically generated page. Yeah, good use for extension developers and anybody who has access to core. But it's not extensible, not usable for user (-script) customization. Even gadgets are hard to maintain, although you can activate asynchronous loading and define dependencies. For more, have a look at /RL 3.0.