All The Tropes Wiki Project, Part XXXIII

[GethN7]

As to the laconic change, I'm all in favor of the solution that causes the least technical hassles to implement. That said, I don't think it's wise to throw out the laconic pages. One, it's a basic fallback in case the new schema has problems or doesn't show up under certain browsing conditions. Second, like other subpages, they are useful for SEO. I'm all for integrating the laconics into the main pages, wonderful idea, but I'd prefer a fallback plan as mentioned as well.

[robkelk]

... they are useful for SEO. ...

Perhaps I don't understand what SEO is supposed to be, but I don't see why we'd care. We don't run ads.

[Labster]

... they are useful for SEO. ...

Perhaps I don't understand what SEO is supposed to be, but I don't see why we'd care. We don't run ads.

I guess I disagree with both of you?

First, the Laconic pages are not good for SEO, they're a type of page called "thin content" which means that they're garbage and no search engine will link to them.  

Next, search engine optimization is important because we want people to actually use the thing we've worked on. Honestly I've gotten discouraged so many times because I've put in a lot of work on what a niche and more or less out of date site, but I guess that's fine.  Actually, let me quote a post from back on Yuku, which is 14 years old tomorrow.  I think about this one quite a lot.

I suppose it really depends on what kind of crowd you're going for. If this is just going to be a Tropeflower for itinerant Pilgrims fleeing King Edward's tyrannical trope-censorship in the New World of Tropes, then keeping the old, more idiosyncratic names is fine. But if you want to draw in newbies and folks that haven't done this before, more inclusive methods will definitely help. This doesn't mean killing the old trope titles. One of the things I really liked about TV Tropes' system was the fact you could have multiple URL titles go to the same page. A lot of variations on one Trope can link to the main page, and a simple "This trope is also occasionally referred to as a 'Takahashi Couple', due to said prolific manga writer's tendency to make nearly all romantic couples in her works according to this archetype" both acknowledges the original (and explains it for anyone who runs into an older edit that has the original term) while still not making the base article particularly obfuscating to non-longstanding tropers.

Which is the superior option really depends on the wiki's basic policy and aims, however.

For a long time, we've felt like the Tropeflower to me.  Or rather, I'm essentially an absentee at this point, so I guess I should say y'all feel like the Tropeflower Pilgrims.  Extension:Moderation contributes a lot of this feeling, but then I do virtually zero moderation so I don't really have much right to complain.  TikTok doesn't have a page.  Neither does Heated Rivalry which is the current fandom crack epidemic.  If no one finds ATT, it's just this irrelevant outside outpost.  I wanted to be a peer competitor, not this, but I never put in the energy to do that.

I'm not going to fix it.  I've aged out of troping, and I'd rather write original stuff with my creative time than go through and autistically categorize shows I watch.  (I'm sure I'm autistically writing fanfic too btw.)  I still like contributing technically, and I have ideas that I've had for a long time, but didn't really have the skill/tools to implement until now.  This is one of the ideas.

Basically, I accept the argument in the quote above, and I think that short definitions of all of the tropes should be very discoverable, because even with normal-ish names, a certain amount of jargon exists.  An elevator pitch is standard jargon, but if you don't know the term, does it sound like a short sales attempt or a rising key change in a song?  The closest we have is the Laconic pages, and honestly, as they are currently they're negative value to the wiki.  Undiscoverable, full of embedded jargon references, and a sink on SEO.  We do not need a way to get back to this point.

The grand scheme is to make short definitions available three ways: on the top of trope pages, via the Popups, and in category pages.  The first is automatic with SHORTDESC, and we can restyle it as we want.  Popups is just messing with the JS from extension Popups and deploying it as a gadget -- there's pretty much nothing on the backend that matters -- but this will only apply desktop users which is a minority.  The third means writing a new extension, likely along the lines of CategoryTree.  Because as much fun as jargon is, I honestly think that no one should be visiting the wiki and have no idea what it's talking about.

[MilkmanConspiracy]

I'm in favor of short descriptions. The way I understand it, it helps work with MediaWiki better, and so makes the Wiki function better for readers. I'm not sure if it necessarily needs to be at the exclusion of laconic pages, though deduplication of text would be ideal.

SEO is important, though inferior to editorial concerns. If for no other reason than you want the right pages to come up when searching for content off site, and that a lot of SEO methods are also good for accessibility, site performance, etc.

[GethN7]

Well, given the above arguments, I'll retract the SEO concerns; I was apparently mistaken. I still am willing to back whatever technical solution that works with the least hassle.

[robkelk]

Sigh.

"Let's You and Him Fight" is when two heroes fight each other when they're both looking for the same villain.

What's the trope that Phil Foglio calls "Let's You and Him Fight" in this Girl Genius strip, where one hero has two villains chasing him and he tries to get them to fight each other instead?

[Norgarth]

I thought the idea of 'Lets you and him fight' was simply Party A arranging Parties B and C (who are hostile to A but indifferent to each other) fight, allowing A to escape/conserve strength.

I hadn't really associated it with any specific combination of heroes and villains.

I could also see it happening as:
- a villain manipulates 2 rival villains to fight
- a villain arranges a hero to be distracted fighting a rival villain
- a framed/falsely accused hero setting up a couple of pursuing Heroes to fight each other while the framed one escapes

[robkelk]

I thought the idea of 'Lets you and him fight' was simply Party A arranging Parties B and C (who are hostile to A but indifferent to each other) fight, allowing A to escape/conserve strength.
...

So did I, but the trope description says that the fight isn't arranged -- it happens accidentally.

Maybe the trope needs to be renamed, if we're all getting it wrong because of the name.

[Labster]

I decided to put off deploying the new template because I realized that I needed one new feature, and one bugfix which is really kinda also a new feature.

The new feature is easy: automatically generating Short Descriptions for subpages in the {{work}} template.  But unlike laconics, every page gets its own short description.  It would be easy-ish to do here, and also because they're likely to be somewhat boring.  At least I can do so 'splaining about things like WMG, which renders as "Fan theories about %s".  All of the descriptions are editable, so change it if you don't like it.    This can be overridden with another {{SHORTDESC}} later in the page.

The bugfix is that providing a wikipedia tab does not propagate to the subpages, unless you change it specifically on every page.  So I thought, hey, just read the value off the main page, then you only have to write it once.  This seemed like a good use for Bucket, with a very simple table.  But then I thought, what kinds of other tabs could I store in bucket?  So I'm going to add a new tab, "Fan Wiki", which can link to other wikis (yes, plural).  And then why not another tab, Source ... for external sources. 

So you might make this template on Sense and Sensibility (novel)

{{work
|wikipedia = Sense and Sensibility    # note: wppage still works, does same thing
|source = wikisource:Sense and Sensibility
|sourcename = Wikisource
|source2 = https://gutenberg.org/ebooks/21839
|sourcename2 = Project Gutenburg
|fanwiki = fandom:janeausten
|fanwikiname =    #note: empty or missing will just fill in "Fan Wiki" for this tab
}}

And then on all of the subpages, you just put {{work}}.  The pages will automatically load the other tabs (or will once the cache expires/subpages are purged).  Note you still need {{work|page=Fate/stay night}} the page param on all of the pages with slashes, because it's not smart enough to figure this out.  We could end up with two source tabs if we have the content on-wiki too... oh well I guess.

I've also added some accessibility attributes (I probably should do a few more now that I recall this part), and set it to hide the subpages menu from search, because navigation is not page content.

Anyway, I've written the code, in theory it should work.  But it's still untested as of now, because I need to start testing on real pages to save things into Bucket:Tab.

[Bob Schroeck]

Brent, I'm really looking forward to seeing this in action. The current button system works well, but it's always had little quirks that bothered me (like the Wikipedia button on subpages, as you note above). An overhaul with something far more flexible and capable is long overdue. Thank you for putting in this effort.

[robkelk]

... and set it to hide the subpages menu from search, because navigation is not page content.
...

As far as I'm concerned, this makes the entire upgrade worth doing.

[GethN7]

I echo the sentiments of my fellow admins. Godspeed to your efforts Brent.

[Labster]

Bells and whistles appear to work on Sense and Sensibility and on its YMMV subpage.

Note that we're not quite ready to deploy. One reason is that Bucket is only turned on for us on most mediawiki servers, but two of them have a old cached copy of our settings that doesn't include Bucket. And apparently the caches don't have a TTL, but are just flat files on disk? I'm trying to find out more information for now, but don't be surprised if you see me turning off an on some random extensions to force a cache rebuild. (Also, I need to test more.)

[MilkmanConspiracy]

This looks incredible - Amazing work!

Would it be acceptable to link to storefront pages through this? I frequently link to digital distribution for video games on work pages, and this seems ideal to standardize it.

Also looking forward to nowp, especially for pages that don’t have a page to link to, but do automatically link to a valid unrelated Wikipedia page.

Thank you again for doing this!

[Bob Schroeck]

Very impressive. I'm looking forward to when we go live with it!

[GethN7]

Looks promising, hope to see this widely deployed eventually.

[Labster]

This looks incredible - Amazing work!

Would it be acceptable to link to storefront pages through this? I frequently link to digital distribution for video games on work pages, and this seems ideal to standardize it.

Also looking forward to nowp, especially for pages that don’t have a page to link to, but do automatically link to a valid unrelated Wikipedia page.

Thank you again for doing this!

For nowp, it already exists, just only works on one page now.  You can start adding it on main pages for works.

I'm honestly not sure either way on storefront links.  From a Miraheze standpoint, we don't want wikis to do advertising, and wikipedia manages to avoid doing it.  But our purposes are different.  We want people to interact with a corpus, not just be a quick summary.

I think it might take an actual policy, because I see some different cases.  Webcomics: one source, it's easy.  Games: sold on Steam, maybe itch.io and GoG, rarely Epic (that's 4 stores).  Books: freely available, or sold at 10k outlets worldwide and how do we choose? openlibrary.org is obvious, but do we also help amazon hoard more money?  TV: a solved problem, we can link to justwatch.com.  Movies: justwatch.com, plus theaters but we probably don't want to update new releases.

[Labster]

Okay, posted an announcement about the new template on the wiki.