User:Gwyneth Llewelyn

Profile

Born:

31 Jul 2004

About:

Winking Loudmouth

Achievements:

• Still around here!
• Edits SL Wiki in her spare time

Yay! LOTS of templates!

If you have peeked into my user page, it's highly likely that you've caught my name on the SL Wiki logs, showing how I desperately and furiously created new templates over a comparatively short period of time...

Well, everything has a story. And here's mine!

The Journey Begins: A Broken Template Needs Fixing

In mid-August or so, I was busily trying to get the old QAvimator to compile under the latest-generation Qt framework, at least on macOS (I might be able to test it under Linux as well). Things were actually progressing well (who'd thought...) — not bad, for someone who only heard about Qt, but never actually coded using Qt's libraries, and who had learned C++ in the mid-1980s and never really did much afterwards — and, at some point, I was double-checking animation priorities. I was pretty sure they went up to 4, but couldn't quite remember if they started at 0 or at 1. A friend in SL told me that I was completely out of touch, and that priorities, these days, were 'theoretically unlimited' but for all practical purposes, most of those being sold these days would be at priority 5 or 6...

That got me completely flabbergasted. And, naturally enough, I immediately tried to upload one of my old animations. Sure enough, the familiar BVH uploading dialogue box popped up, but — exactly as I remembered it — it didn't allow any other priority but 1, 2, 3 or 4. Was my friend confused? Or making fun of me? She sort of hinted that 'it wasn't possible to upload them at higher priorities using the "usual" way'. So, uh... what is the unusual way of uploading animations?!

Well, it was time to peek into the SL Wiki, and, to my utter surprise, my friend was right! Apparently, the current generation of the SL Viewer does, indeed, allow animations of at least priority 5 to be used, and possibly even 6. Priority 0 anims did also exist, but that was reserved to the so-called 'Linden Animations'.

Although I couldn't figure out how to upload anims with a higher priority than 4 (at least using the standard viewer), it seems that, when using a BVH editor, you can set specific bones to higher priorities, and the uploaded animation will respect such priorities. Although technically you cannot upload a full priority 5 animation, the workaround seems to be to simply set all bones to 5 (or higher...), and upload the anim as priority 4 — the viewer should not change those priorities to a lower value, but rather respect them. I don't know, I haven't tried it out myself, but it surely explains why it seemed to be impossible to override some animations I've got. Hm. Worth exploring a bit!

While browsing the SL Wiki for more animation-related information, I noticed that there was a small notice saying that two articles were to be merged together, something which was proposed... in 2011 (!). The proposal is actually quite reasonable (no links here, since they may already have been merged at the time you're reading this) and I hope it goes ahead. Still, what caught my attention was how poor the Merge message was. I wondered why it didn't stand out as, say, on Wikipedia.

A little peeking and probing showed that the template used for the merger proposal is simply way too ancient, and that's why it doesn't look even remotely like what Wikipedia has.

Ok, so it was time to roll up my virtual sleeves and do some template tweaking. I'm a bit rusty at WikiSyntax, but the cool thing about MediaWiki is that you can, of course, 'learn from the masters', namely, from either  Wikipedia itself or the general-purpose reference wiki for all MediaWiki installations. And of course there are a few more! Vastly inspired by those great MediaWiki template writers (i.e., shamelessly copying their code), I started copying some of the templates over to the SL Wiki. After all, that's exactly what the earliest SL Wiki writers did, in the late 2000s — that's why there are so many 'familiar' templates, as well as some very early hacks that don't exist in Wikipedia anymore but are faithfully preserved here, exactly as they have been written in, oh, around 2005 or so.

The trouble with starting to edit Wikis is that it's hard to stop.

So, once I 'ported' (= shamelessly copied) the most generic Merge template — and actually figuring out that the particular choice used was not present on Wikipedia.org any longer, although it had been preserved elsewhere — it was clear that there were some other templates missing in order to make that template work. Hmpf. Ok, so let's figure out what those templates actually do, and copy them as well.

You know what happened next.

The 'new' templates, of course, rely upon a few more; so, I had to copy them over as well. These, in turn, depend on others still... and so on. It's not an exponential, unbounded, uncontrolled growth: rather, you have to trace some of those templates to their root, and, once you get there, you can switch to the next branch in the tree-of-templates, follow it to its root, and so forth, until, at the end, you have all templates you need to get that original one working satisfactorily.

Only... sometimes this means adding a few dozens of new templates. Or perhaps even a few hundreds. Some are very small one-liners; but in the past decade, Wikipedia (as well as their sister projects) have started to document all those templates in a standard way (the visual design will match each wiki, of course, but the underlying functionality is pretty much the same). Since I pulled in templates from different sources, that meant adapting them to one particular design. Such designs, of course, require more templates. Which, in turn, rely on even more templates just to do some fancy UI effects. Grumble! That meant adding another few dozens of templates, just to get the documentation right for the other templates that I actually needed!

This was actually going well for a while, with 20+ tabs open on my browser, each following a specific branch of the tree-of-templates, going deeper and deeper, until I started hitting some roadblocks.

It's Not Just the Templates That Are Broken

The first was easy enough to spot: video support — on those pages embedding video (mostly from Torley...) explaining how several things were done — was broken. That's not quite LL's fault: they were using a very old template, designed by my friend SignpostMarv Martin, who adapted it for use in the SL Wiki, as an extension, which the Lindens, back then, were glad to add. It used Flash to embed video (like pretty much everything in those days did). But around 2020 or so, Adobe dropped Flash support entirely — the browsers having started to discontinue it, one by one, as HTML5 video became the de facto standard, even though Flash continued to be supported for a while as a 'fallback' option.

The trouble is that you cannot directly embed things on pages of a 'standard' MediaWiki installation. Indeed, the work done by SignpostMarv Martin was to create a special extension that allowed videos to be embedded with the <videoflash> tag. Without that extension, such a tag — defined at the system core PHP engine, not on the templates — would simply not exist. We'd need a similar extension for HTML5 video embedding, or possibly just change the existing tag and let it embed HTML5 video instead. This is actually the work of a few minutes, since SignpostMarv Martin released his extension code as free and open source.

When Flash was officially discontinued, the MediaWiki community improved on that work, and created their own video-embedding extension, EmbedVideo. This is not installed on the SL Wiki, so there was nothing I could do about that, except file a bug report on Jira.

Back to the merger template, I noticed that the icon looked simply horrible. And no wonder: it was an ancient PNG fro pre-historic times, when browsers had a 640x480 resolution at best. It was time to replace it with a modern, contemporary  SVG, which, being vectorial, renders flawlessly on all possible resolutions, present and future.

And this is when I noticed that SVG support on the SL Wiki is broken. The 'breakage' requires a simple fix. To generate the thumbnails, the MediaWiki software can use several tools to do image manipulation, and the preferred option is to use the popular ImageMagick library. This is what Linden Lab installed (and configured), but, alas, sadly, it seems there was some neglect in keeping it up to date with the most recent releases, and the currently installed version (at the time of writing) gives a lot of errors when attempting to convert from SVG to PNG (which requires a library or an external plugin to work, which is sadly missing).

Alas, the best I could do was to upload lots of new, higher-resolution files, to replace the ancient ones.

But, of course, that was not all. My journey across the many templates used in the SL Wiki had just begun.

A Question of Style

One of the first issues I found was that there were a few strange scattered around the templates I've shamelessly copied. What were those doing there? WikiText allows quite a lot of  CSS tags, but that one doesn't exist. Intrigued, I tried to figure out what was going on...

Well, this is a 'new' extension, called TemplateStyles introduced... circa 2016. Its purpose is simple: instead of having to directly change the 'main' CSS for the wiki — accessible only to admins at MediaWiki:Common.css — this extension allows each template to be independently styled, including the CSS specified on a new page. This is rather convenient, since the extension will make sure that the original styles are not overwritten in any way, nor tampered with, nor even mistakenly 'broken' by an overeager template editor (such as myself...). It also allows experiments in changing the CSS, without risking breaking the whole SL Wiki at once — TemplateStyles will apply just to the template itself (and pages including a particular template using TemplateStyles, of course) and not interfere with anything else.

You might ask yourself why bother with such issues, if you can conveniently style whatever element on the Wiki with the usual CSS <style>...</style> tag. Well, that's true, but consider the scenario where a page includes a template multiple times (something which is very common). The style will be included over and over again, inline, growing the page unnecessarily. TemplateStyles will cleverly just include everything once and store it adequately on its post-template-rendering cache.

That's why all 'modern' Wikis — any one which received maintenance after 2016, that is — will have this extension active. SL Wiki doesn't, so I had to manually edit all those templates copied from elsewhere which 'assumed' that such a common extension would be installed...

Metadata That Doesn't Matter^[1]

The next thing that caught my attention was another 'new' tag — new for me, that is — which seems to proliferate in all those Wikis around the world: <TemplateData>. Even more strange, it features a lot of  JSON (depending on the template, of course), but it seems to do... nothing. The SL Wiki will not render JSON 'out of the box' (you just get messily formatted plain text...), and I was intrigued what purpose this JSON block did have.

At this point, things become really geeky. If you actually happen to have the patience to contribute to the SL Wiki, you know very well that you get the most basic of text editors (also known as the 'source editor'). There's no  WYSIWYG here — that is, after all, a 'novelty' that was only released with the standard editor coming with MediaWiki's  VisualEditor... around April 2013. We're still stuck in the early 2000s here and have no access to those goodies. The irony is that the currently installed version of MediaWiki does come with the VisualEditor extension pre-installed by default. However, you still have to enable it — a single configuration line on the MediaWiki master configuration file, which only the Lindens can change. It has remained untouched since the dawn of history, even though the current version — which is slightly outdated by about two years, at the time of writing — nevertheless incorporates almost all goodies, installed by default, ready to be used; they just need to be enabled...

Over the years, the MediaWiki's VisualEditor has evolved considerably, although using it is really a matter of taste (I'm still irked by its attempt to 'predict' the template I wish to include next... it's not very intuitive to work with, although it's quite good at writing simple pages). Lately^[2], however, it has acquired the ability to do automatic WikiSyntax highlighting, which is really convenient, and definitely the most useful of its features — at least, if you're editing templates and not merely 'standard' pages.

Well, around the same time that the VisualEditor was released publicly, its proponents thought that it would be great if that editor behaved like contemporary  IDE, showing what parameters were required to use each template and what they would actually do, by simply hovering over them. This led them to invent the TemplateData format, and, similar to what happens on other advanced IDE and code editors in the programming world, the format is reasonably easy to read JSON. As a side effect, templates using TemplateData would also show the many options nicely formatted, in a uniform way across all templates.

TemplateData works independently from the VisualEditor, but the two work well together; it is also included by default on this SL Wiki's installation, but, again, it's not enabled. While it would not be useful for syntax highlighting and as a template-programming aid, it nevertheless would give us a tool to consistently document the many templates.

Instead, we get rubbish.

Because — who knows! — in the future, some kind Linden may click on the checkbox enabling TemplateData, I did not simply remove those JSON blocks — I put <syntaxhighlight>...</syntaxhighlight> tags around them. Surprisingly, SyntaxHighlight is a standard extension, one of the very few that the Lindens have enabled in the SL Wiki! They just forgot to do a site-wide search & replace for the deprecated <source> (and, worse, the infamous <lsl> tag, hacked by them on a rainy day, two decades ago), and, as a consequence, there are a gazillion pages here on the SL Wiki still using that old tag — which requires manually editing each and every page, one by one, to change it. I have been doing that, every time I need to look something up on the SL Wiki and notice that a particular page still has the old tags, I change it. But as you can imagine, that's a lot of (manual) work, and there are still a few hundred (thousand?) pages that need to be changed.

But I digress. My point is that it will be possible to change the <syntaxhighlight> tags back to <TemplateData>, if the TemplateData extension ever gets enabled. Then again, such a change would also be much better to be done automatically... by enabling the site-wide search & replace extension, of course :-)

Aiming For the Moon

As some of the pieces were slowly falling into place, I stumbled upon the next issue — a complete novelty even to me, although the technology behind it is as old as the others mentioned above (i.e. around 2012-2013). In fact, it seems that the SL Wiki had exhausted its impetus around 2011 or so, while MediaWiki was literally exploding with excellent ideas around 2012 (which were then implemented in 2013!). Bummer! Now that's reverse  synchronicity!

Anyway... while copying Wikipedia and MediaWiki templates, I stumbled across a tag I had never encountered before: <invoke#>. It was not a template by itself, and the SL Wiki didn't recognise it. What was it doing there? The truth is that many Wikipedia templates, although bearing the same name and functionality as SL Wiki templates, are much shorter, and that was because they simply called <invoke#> with one parameter or two and that was all. What was going on?

For those that have never bothered to take a look at how the MediaWiki software works, it's worth spending a few paragraphs to explain what goes 'under the hood'. Interestingly,  Sir Tim Berners-Lee, the inventor of the World-Wide Web, had in mind something much closer to a Wiki than to what eventually became the Web: a place where anyone could edit every available online text, and interlink them together. In fact, the web's  HTTP protocol includes a few commands that are meant to deal with editing and deleting Web pages remotely (!), something which has, for well over two decades, hardly been used (nowadays, these commands are quite useful for all sorts of  web services, but I'd claim that this was more of a fortunate coincidence!).

At its core, MediaWiki is mostly a glorified, overblown templating engine — and it even shows in the way templates are called, which follow a loose convention dating back to the first Web template engines, such as the before-mentioned Smarty (for PHP), which is two decades old (obviously there are a few variations, but anyone familiar with a template engine will immediately recognise the structure of how a MediaWiki template page is created, and the syntax will be familiar). A template engine is not a programming language. Rather, it's a convenient way to direct the engine to replace strings on the aptly known 'templates' to produce a result. For instance, every time I wish to add a link to  Wikipedia, I don't need to place the whole link (and remember it!) when writing on a page. Instead, I call a small template which does the work for me, namely, {{Wikipedia|parameter}}

[to be continued...]

And in the very remote case that you wish to know more about me...

You see,

I'm just a virtual girl in a virtual world...

— Gwyneth Llewelyn (talk)

Visit my blog (some years it even gets updated)

More info on me on the Second Life History Wiki

My reported issues:

View the issues Gwyneth Llewelyn has filed at jira.secondlife.com

I hail from !

My RSS feed

Declaration

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I, Gwyneth Llewelyn, declare my intention to make all contributions I have made to this Wiki to be fully distributable under the Creative Commons Attribution-ShareAlike 4.0 (International)] license (or any posterior version, at your choice), but allow any re-licensing under a different license, which, however, must include terms that comply with CC-by-SA.

And to ensure that this message remains inviolable for all eternity, I dutifully sign the above paragraph and this one with my PGP key (available from any popular PGP key server or from https://keybase.io/gwynethllewelyn).

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEzopgBrYRhQ8SdXK62T6qPcSz4csFAmYuxSQACgkQ2T6qPcSz
4ctk7w/+NJEnC19jTu0Lb0wN6Q3nLENkMb0d33LWRiG0Uso84FsLeDE+KqzzwL/f
iyFj7hLp2K3EHwRYxmfk/2anIzfegRuHW3HhvMXCnSJWhyGfN/yEHGJE3o7N6e3K
WCO6TmxsMgbiYWmnsokgbSkmIIHPWjZ5fjAkcsPaSorQVMMDd4EFv6hGIP8BgUup
AQTkY4bgshHGi3Iqn/Qn7zyT8h9UQTyzi5GmLQ3mH04g6DtMu0CsdtarJlayrUF7
ryLMPDehhLo0ptJBhwvYWZ5DMzMzHIdPv8YNRnsHT+8qoct46nPlYp699n0egWOv
tp6mMTlbJ/WE/vUYd2Biap3psNhPdpdnc4fCWCDsXSJ3gf7NiMb4G4H9fzcj8vJP
AeZRzGtYLfpQElXRdU6K8SEOToDCKsaPHVsA6Aw4SRLnig4OjlOjt49g3gbRhpyA
+1VeyLBzy0IPrhm+xIizJfegRiVoXWX6WfwvWhRDRpVqz7Md/exyTaiLTwmyXiLV
Me2BPdgy3cI+peaIQKsVHjadPi+LG+QFtH12c8fe8K6GGzBmFFLRMz0AM1WeWbGg
7vys3NOgSs1aWDfKsps90e8acSD5WRi9jVXrLJp5WNjdtUlBzASfLO06jSg5VNgl
NOqgVEkHb3zoehBqB56a4r8WQNXv7dyLvEg2x/Q9AGsp7l3XrXw=
=aWOx
-----END PGP SIGNATURE-----

— Gwyneth Llewelyn (talk) 14:53, 28 April 2024 (PDT)

---

Projects in SL

I'm not even sure if we're allowed to promote our own projects on the talk page, so it suffices to say that this ia an image of the LOCUS in Amiais Project — no links (to prevent being accused of promoting it!), but a bit of googling should give you access to it.

Notes

1. ^ Sorry, my bad puns get worse and worse...
2. ^ That is, a decade or so ago.

Haiku
Wonderful summer A redhead loudmouth winking beyond the flower — Gwyneth Llewelyn