Template talk:GamesName

Optional xOG parameter?
For year values >= 1993, theoretically couldn't we make the |  parameter to this template optional? The type of games is implicit in the year, starting with the 1994 games. Requiring the type value after that point isn't really any sort of sanity check, even, because the template just breaks if you use the wrong value. It's not like it gives any sort of explanation why it's not outputting anything useful, to qualify as a "sanity check".

So I'm thinking something like

So, the SOG|WOG would actually always be ignored for dates >= 1993, even if the user specifies it. For those later dates, the year will be taken from the second parameter, preferentially... and if there's no second parameter, the first parameter will be used instead.

That should allow things like and  to be equivalent to the (still accepted), while still requiring one of either  or  and not accepting  or.

Granted, it would make display "🇳🇴 1994 Lillehammer", whereas today it would show nothing. But that's arguably an improvement too, since the user is probably more likely to have the year right and the type of games wrong, rather than vice versa. FeRDNYC (talk) 23:47, 11 January 2023 (UTC)


 * I don't think this is a very good suggestion. A strict description of parameters (both in programming languages and in Wikipedia templates) is more of a plus than a minus, as it leads to a simplification of bugs catching and fixing. The is a pretty good example precisely because we don't know if the year is right or the type of games is right. Therefore, we issue nothing (actually an error), so the bug becomes visible. Any assumption like that rather the year is right or the type of games is right - is not good, bugs become hidden. Nitobus (talk) 19:11, 12 January 2023 (UTC)
 * Granted, on further reflection this probably wouldn't play well with TemplateData... if I had it to do over from scratch, I'd put the year in the first parameter, and the second could just be optional when the year is > 1993.
 * I don't quite understand this part of your argument, though:  doesn't do any sort of error reporting or checking, it doesn't populate any tracking categories for bad parameter values — it just silently outputs nothing for any type of parameter error. That hardly qualifies as the bug "becom[ing] visible", in my mind, since it relies on the user even noticing that there's something missing, and then making the connection that the reason for it may be that the template parameters are bad.
 * You'd be surprised how easy it is for humans to overlook the absence of something, especially when it's a small detail in a larger context. For example, the wrong parameter in this call.
 * (There's actually a transclusion between "this" and "call" in the previous sentence, but how would anyone notice that something's missing there?)
 * Sanity checking for mismatched post-1993 years / games-type parameters could of course be implemented, for times when the user specifies both. The idea would be that they shouldn't, generally, because it's redundant information; the year alone is sufficient. (The same way the year and city is always sufficient, even for pre-1993 games. Which is why shows "" and doesn't [need to] specify whether it's a summer or winter games.) But, certainly  could be made to output the same nothing, again, as  does — even though the former case feels like a missed opportunity to actually report useful information about the nature of the problem.
 * But, yeah, in a TemplateData world it'd have to always be used as which is super unfortunate. (And that's assuming TemplateData even permits optional unnamed parameters before non-optional ones — most variable-length lists with positional elements sensibly require that optional ones go at the end.) FeRDNYC (talk) 04:40, 18 January 2023 (UTC)