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.

Wikipedia-logo-v2.svg This user is active in the German Wikipedia as User:✓
Buggie.svg This user contributes Bugzilla
Wikipedia logo v2 (black).svg This user has accounts on the test and test2 wikis
Wikipedia logo v2 (black).svg This user has admin rights on the deWP beta wiki
Wikimedia Cloud Services small logo.png This user has the account User:Bergi at labs logo.svg This user translates MediaWiki to German as User:✓
Icon External Link IRC.png This User is registered as [Haekchen] and [Bergi] at

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.