Board Thread:New Features/@comment-24739709-20150518230347/@comment-4812386-20150715081207

Right now, I use InfoboxBuilder because it allows me to have a Lua module with complicated code with which I can do things it is impossible to do with parser functions. You can see an example of what I'm doing at c:roblox:Module:GroupInfobox. If you look at it (you should!), you will see that it has some code to handle categories, error messages and other things automatically. For example, one of the fields in the infobox is the owner field, which contains the name of a ROBLOX user. The Lua module checks if the user has a page on the wiki; if that is the case, it provides a link to that page, while otherwise it gives a link to the user's profile on the ROBLOX website.

Another more striking example is the field for the number of group members. Right now, the argument given when transcluding the template is first unformatted (editors have a tendency to copy and paste it from the ROBLOX website, where it has commas for formatting), then rounded to a power of ten that depends on the number of digits and then formatted in a language-dependent way using the functions Scribunto provides for number formatting.

The previous infobox templates, created before InfoboxBuilder was introduced, can do some of this neat magic using crazy parser function hacks you could not even begin to imagine (things that look like ), and they are worse than impossible to understand. The Lua modules can do a lot more and are easier to understand, maintain and modify, and yet they are easy to create and very elegant because InfoboxBuilder was created specifically for them.

One may think the infobox I'm talking about is exaggeratedly complex (although Wikipedia has some that are worse in this regard, like the chess ones that literally generate chess boards in HTML and the chemistry infoboxes), but the error messages make it significantly easier to find and fix problems in pages and the automatic handling of categories is the only way we can hope to have a consistent category system (we also have problems with editors adding pages to random categories). And as long as the code is neat and nicely documented, it can't harm much…

Anyway, I think the problem here is that PortableInfoboxes don't integrate at all with Lua modules. I could create a module that generates XML tags, but that would be very inelegant and would look like bloat. I don't think I'd like to add to the wiki a module with hundreds of lines of Lua code from the dev wiki either, although I would choose that solution if it ended up being the only way to make the infoboxes acceptable on mobile devices. I could write such a module myself, but I'd end up recreating InfoboxBuilder exactly as it is (because it is as simple and elegant as it can get with Lua modules) with a very long module that would generate XML tags.

I like the idea of using XML tags for the infoboxes, but it cannot work for me unless there is some way it integrates with Lua modules. Therefore, I see two ways to go about this: maintaining InfoboxBuilder and making it work on mobile devices, or creating a Scribunto library that makes it possible to create infoboxes transparently from Lua modules. The second suggestion would mean, for example, creating a  library which could be used to create an   object which could have methods for adding fields, headers, labels, values, etc. to the infobox. Then, using the  function on the infobox object could generate the wikitext with the XML tags and everything else, as it does with the   library. This would be really neat, better than continuing to support InfoboxBuilder and more consistent since there would be only one way to do infoboxes, but it might require more work than the other option.