Board Thread:News and Information/@comment-26143371-20170304235143/@comment-26143371-20170502220655

others wishing to contribute would probably appreciate automatic maintenance categories giving them a ready-made list of tasks to chip away at when they have the time. Yup, that makes sense. Now that I think about it, it is probably best to add some support to explicitly differentiate the absence of a field value (unknown) from the absence of said feature (non-existent, e.g.  or  ) directly to the first release. There is no need to actually use those values right away, but we can use them in the infoboxes have them ready for later.

[...] rather get a pile of complaints [...] and you can solve them all with a more general solution, rather than [...] doing a series of small hacks.

[...] a lot of oddities that only affect one or two pages in a given category, so I worry that you'll find major design issues months (or years) in the future that you'll wish you knew about now. Yeah, that's a legitimate concern. And it works fine for the smaller categories (Category:Voice Actors as the extreme example). However if we want to update all or at least most of the (decos) + (buildings) = pages for the Building/Deco Infobox before using it on any new pages we'll probably never get there because there is always so much stuff to do (personally I won't have much time during at least the next three months and after that I'll probably focus on realizing some better automation that simplifies editing).

The two things where I'm less confident that everything is covered are Currencies and Consumables. This is partially caused by the fact that those infobox types are rather new. Ccurrencies never used them and the Consumables category is pretty new compared to the others. Since those two are reasonably small it would be possible to update them in batch mode as you suggested. Simultaneously we could successively update the infoboxes for the bigger (and better established) categories when the pages are edited anyway. Though it would at least be necessary to find all consumables first...I don't think they are consistently categorized or even treated as such).

I don't know Lua, but if you can at least code a few different examples, I should be able to modify them easily enough to cover any other cases that we can think of. Code is code. I can't say that I know Lua either. I've read some of the basic chapters of the Lua Book, done some experiments locally and wrote the stuff in Category:Lua Modules. That certainly doesn't make me a knowledgable Lua programmer. But like you said, code is code, at least if you are familiar with the basic paradigm set of the language in question. Of course writing stuff that way is slow and stupid beginner errors are going to happen. From what I've seen in the book Lua is prone to such errors unfortunately (e.g. some results are magically discarded if you append another parameter). But the amount of complexity is limited, so this should all be handleable.