The first video in the TASBot Re: (TASBot Revisited) series is out! TASBot Re: Gradius covers our first run from AGDQ 2014.

Historians wanted: Inquire here.

TASBot Wiki:Village pump

From TASBot Wiki

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).

TODOs for admins

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
Retrieved from "https://tas.bot/index.php?title=TASBot_Wiki:Village_pump&oldid=1201"
Last modified
This page was last edited on 21 March 2024, at 22:32.
Copyright
Content is available under CC BY 4.0 unless otherwise noted.