TASBot Wiki:Village pump

NEED MORE CONTENT in general (historians wanted). Fill out redlinks (and these, and also these) or work on a stub (list every article, list every category page).

Categories are arguably a direct upgrade to articles in that pages can have multiple parent categories, and categories have a nice UI for navigating to subpages. The longer URI is why you shouldn't just use them for everything.

Embrace hypertext—link to other pages (and also other sites, such as [[wikipedia:]] and {{TASVideos}}), but do also follow Wikipedia's linking guidelines: only link first mention, avoid adjacent links, don't over-link common concepts/entities (TASBot, in our case).

Use redirect shorthands wherever you feel they fit, with one exception: tagging pages with a category will not work if you use a redirect.

On that note, when tagging pages for appearances with categories, put the year category first, then the event category if it exists (or will later i.e. a redlink). {{infobox appearance}} handles this for you.

Familiarise yourself with what templates exist: inline/formatting ones, ones for infoboxes and other tables, complete list. Hit up User:YoshiRulz if you want help making new ones.

• To get the visual editor to generate nice code, ensure any block templates you create have "format": "{{_|_=_}}\n" (as inline but with trailing newline) or "format": "{{_\n|_=_\n}}\n" (improved version of block) in the TemplateData—see docs. This is unfortunately necessary to do on each individual template since the named aliases are hardcoded.
  • Getting the generated invocation to not be in sentence case is a lost cause. It seems to honour what was entered manually though.
• When different kinds of block templates are used at the top of a page, follow this order (copied from here): hatnote, ambox, infobox. nevermind that looks ugly (maybe only because amboxen are so big)

For consistency (TODO move this to a style guide page):

• Where an event's name has a short form, the expanded form is the canonical one e.g. Summer Games Done Quick 2016, with e.g. SGDQ 2016 being a redirect to it.
  • For ESA, short names follow this (ESA YYYY through 2017, ESA {Summer,Winter} YYYY from 2018).
  • For Super MAGFest, have both MAGFest YYYY and magFAST YYYY as redirects (don't bother with DISPLAYTITLE, it doesn't work), regardless of whether there was TAS content in both a talk and the marathon, or just one.
  • LI Retro YYYY is the short name for that.
  • BSG Annual YYYY is the short name for that.
  • AGDQ/SGDQ/GDQx and LTX are trivial.
  • May Contain Hackers (Galactic Hacker Party's 2022 incarnation) was special-cased and has been given 2 redirects.
  • No other events need abbreviating at present.
• Event categories should also be expanded, with redirects in the main namespace only and following the above rules.

If you need to grep in wikitext, use this (change srsearch=querytext).

The banners at the top of the site are MediaWiki:Sitenotice (for everyone) and MediaWiki:Anonnotice (extra banner for everyone who's not logged in).

TODOs for admins

• There are 5 pages to delete
• There are 19 images/files missing copyright metadata
• upload images (list existing media)
  • please try reducing filesize with WebP: magick convert input.png -define webp:lossless=true output.webp
  • since we seem to have dealt with the bot problem, can we loosen the perms and let regular users upload?
• consider adding {{#babel:}} template for user pages
  • I went ahead and added a template-based userbox; see Babel overview. It can even be used for programming languages, though it doesn't have any special handling for them at the time of writing. I've used the private-use code qhx for that, as you can see on my user page. --yoshi
• fix quick search API
  • I researched as far as 'Generators' + prefixsearch and gave up --yoshi
• can the PortableInfobox link an image's media page rather than hotlink?
  • bonus points if clicking it opens a preview with the file's description as the caption, like on Wikipedia
    • this feature is part of mw:Extension:MultimediaViewer
• if semantic citation markup is desired, mw:Extension:Cite needs to be installed
• put an icon here rather than the landing page redirect it currently is
• we haven't needed a TASBot Wiki:Sandbox yet, but if we're expecting an influx of editors unfamiliar with MediaWiki, it may be a good idea, which raises the question of excluding it from Special:RecentChanges. I found this from 2011, and the modern equivalent appears to be the ChangesListSpecialPageStructuredFilters hook. IMO not worth messing with that. --yoshi
• class="extiw" links (e.g. to MediaWiki wiki) don't have indicator, only class="external"; affects both Citizen and Vector themes
  • I'm like 90% sure this is a regression from early November --yoshi
• current MediaWiki:Sitenotice is fairly unintrusive, but should we want to make it bigger in the future it should probably be dismissable—that requires mw:Extension:DismissableSiteNotice w/ $wgDismissableSiteNoticeForAnons = true
• visual editor is showing PortableInfoboxen as just the header, no content; supposedly fixed in MW 1.40
• favicon?

TODOs

• There are 0 pages with malformed template calls
• finish moving event pages to Category namespace, and cleaning up names
  • GDQ—either move to Category:Awesome Games Done Quick, or keep it as a disambiguation page (moved to Games Done Quick ofc) and create the category page from scratch
    • need someone to make the call here; should there be a page for GDQ as a whole, or not? --yoshi
  • MAGFest is all cleaned up and ready for new articles
  • ...then clean up {{prevnext appearance}} data done
    • could copy the start date from the infoboxen to comments in the data done
• infobox for individuals
  • Done, but it doesn't render correctly close enough now thanks to TheMas
  • consider adding fields for country/flag and for pronouns
    • Copied over a template from Wikipedia, and while it currently only works for users of this wiki, I have an idea for extending it if that ends up being necessary. In the meantime I suggest not making dummy accounts for people. --yoshi
  • could add email, but I'd like to have it deobfuscate on click (with JS) if it's going to be included, and with a personal site field it's kind of redundant --yoshi
  • consider adding field for (programming) languages spoken
    • for natural languages, there's mw:Extension:Babel, and it may be possible to hack in programming languages as qxx or something --yoshi
• consider redirecting (not sure how when #REDIRECT only allows local links) e.g. desync to TASVideos.org/Glossary#Desync
  • - introduces chance for link-rot
    • + can leave notes for TASVideos editors
  • - not everyone can add to that glossary
    • + yet
  • counter-proposal: could instead make a {{TASVideosGloss}} and use {{TASVideosGloss|term}} instead of [[term]]
    • + easy on a technical level
    • - no way to see valid link targets without visiting TASVideos
    • - same problems as above re: "delegating" content to TASVideos
• it seems reference lists e.g. Special:WhatLinksHere/Template:TASVideos don't differentiate between direct and transitive transclusions (that is, where the template is used as itself vs. where it's only used via another template)
  • worked around this by using search API e.g. this, but it's not ideal --yoshi
• why are category pages wider than articles? affects both Citizen and Vector themes
  • this was an explicit choice (namespaces -1, 6, and 14 are Special, File, and Category, respectively):

@media screen and (min-width:1300px) {
	.ns--1, .ns-6, .ns-14 {
		--width-layout:var(--width-layout--extended);
	}
}

• • • I'm not a fan of the postmodern max-width: 800px; margin: auto; epidemic, squishing all the text into the centre of the screen, but I understand it's a popular style. --yoshi
• use shorthand redirects in {{prevnext appearance}}, like {{prevnext of type}} does already?
  • would help with float-right text being left-aligned in practice due to a line break (why), as you can see on ESA Summer 2019 (that was from {{prevnext of type}} which is now using shorthand)
    • found that removing the inner {{float right}} and making the outer {{float right}} dir="rtl" will work around this... but that feels like a bad idea --yoshi
• speaking of, need to suppress {{prevnext of type}} in {{infobox appearance}} when it matches {{prevnext appearance}}
  • simply commented-out the first few entries in {{prevnext of type}}; for finer control we could comment-out individual fields too --yoshi
• hack for fixing hyperlinked monospace text (broken in both Citizen and Vector themes):

:is(a.extiw, a.external) code {
	color: var(--color-link);
}

• Citizen is wrapping wikitables in a div.citizen-table-wrapper, preventing margin collapse (case in point, {{showcase}} appears to have a newline above the table as part of the transclusion, but it definitely doesn't)
• The current landing page is fine by MediaWiki standards, but as the face of //tas.bot it's not great. Way too many links (above the fold, that is), and the only picture of TASBot is the one in the sidebar. --yoshi

---

re: run data

An important decision to make: Should run data be in one combined page or 1 page per run? (There's a third option of splitting the data into multiple groups somehow, maybe alphabetically, but that seems to just be a worse version of the one combined page option.)

See Runs/row for live samples of the proposal. The only facet that's not implemented is squishing the boilerplate for run data subpages (the self-transclude preview and the docs) into a single template call, and an updated contributing guide of course.

Combined (status quo)		Subpages (proposal)
unmatched brace can break half the wiki	<	unmatched brace can take down every call-site which references that one run
for novice editors: huge wall of text may be overwhelming	<	for novice editors: slightly more involved to find where to edit, but much easier once there
for experienced editors: a pain to scroll through everything	=	for experienced editors: a pain to tab through everything
N/A	=	lookup keys would inherit the limitations of page names—but we're already using a limited charset for other reasons, so no change there
adding a new field means adding N lines to 1 page; changing the format of a field means a RegEx replace on 1 page	>	adding a new field means adding 1 line to N pages†; changing the format of a field means a RegEx replace on N pages‡
need to keep table sorted (just for humans)	<	N/A
some risk of merge conflicts	<	minute risk of merge conflicts
maybe possible to search page sources for pages dependent on a particular record	<	WhatLinksHere can give precise list

† But would it? Surely if we didn't need it initially, it would be something that could have a default value, for example:

• bool desynced, would default to false
• bool bidding-incentive, would default to false
• wikitext media-coverage, would default to empty string

‡ This is unlikely to happen, as all fields have been broken down into machine-readable parts except for the lists of people (author, lead, and presenter) and the list of links recording.

---

Qs for dwango:

• I take it the focus here is on history, so how much technical information should be here vs on TASVideos?
  • tl;dr: we should put [technical info] on TASVideos. However, I have one pause here; there is a huge barrier to entry for TASVideos [wiki] at this time [...]
  • In essence, we should first and foremost ensure things like replay device and console verification documentation is complete (enough) on the TASVideos wiki. As CompuCat pointed out however, our needs and perspective is a bit different, and there's no harm in us also having technical details on the TASBot wiki with a perspective more geared toward live presentations at charity events. In fact, that's where I see the TASBot community as differentiated from the TASVideos side when it comes to on-hardware work; the TASBot community is centered around having our cute robot mascot play video games during public presentations, and our needs are going to involve things like proper presentation with visualization on camera that aren't relevant for just seeing if something syncs on hardware. To that end, I think there's room to have the core concepts explained from the different perspectives even if some of it may end up overlapping documentation on the TASVideos side. More documentation (so long as it isn't wholly inaccurate) is always better. There's another caveat here - despite my best efforts, it's still a lot harder for folks to edit wiki entries on TASVideos whereas anyone willing to share an email address is able to edit the TASBot Wiki
• apart from Ambassadors, how should individuals be categorised?
  • DWYW
    • pages can be in multiple categories, so I guess could just have one cat per role/specialty?
  • to that end, a definition of "notability" for inclusion here would be helpful
    • anyone who was credited for any event/showcase