TV Tropes 2.0: Database level redesign (Not in active development yet)

So the thing I wanted to point out was only partially the template switch, but more so the navigation oddity. For example, if you go to the Gushing About Characters You Like page, you'll notice the top bar only has the Sugar Wiki page linked. But if you click on any of the subpages, because of how subpage namespaces work, you are quite literally no longer in the Sugar Wiki namespace anymore, and the navigation top bar has a LOT of other connected subpages that are under the Anime & Manga namespace. The list is quite long (click the more drop down to see how long).

Now this isn't necessarily incorrect sorting since all of these subpages are about things related to Anime & Manga. But it's unintuitive in the sense that links are not structured like a tree, with each subpage branching off of the previous one before, such that you can just follow the same links back to get to the previous page you were on. Or use the navigation bar to see other subpages related to that one Sugar/Darth Wiki page. It's more like for these name space changes, it creates a separate branch each time you follow a different link. I'm not a programmer so that's the best way I can summarize the experience.

From a user standpoint, it's workable if a little bit jarring, so I get why it's not a high priority. I brought it up using the Sugar and Darth Wikis because they make it the most apparent, given that they also have a visual template as if they are separate from the main site.

Edited by amathieu13 on Feb 16th 2022 at 11:09:46 AM

You are not wrong. The subpage mechanism that we have is awful, but it's what we have. It's not changing any time soon.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

For sure, I was just explaining to others since it seemed to me that they thought I just wanted the visual template to be maintained.

An alternate structure that comes to mind is moving the "gush" namespace into the title. So CharacterGush.Anime And Manga -> SugarWiki.Character Gush Anime And Manga

Like with Characters pages?

TroperWall / WikiMagic Cleanup

you'd have to make a separate page on Sugar Wiki called "Character Gush Anime and Manga" for that. While that would make all Sugar/Darth Wiki pages stay on those wikis, the issue of related pages on those sub-wikis not being direct branches off of each other would still persist because of the namespace replacement thing. (Also I think it'd make some page titles obnoxiously long.)

But yeah, I don't think what we have currently is so bad or broken it needs to be changed. Just that if there are thoughts/plans on updating site navigation, one that can better separate darth/sugar/main wiki would be good.

I also was just curious to see what (if anything) was being discussed. Fighteer answered that for me already so I'm good on the sitch

Edited by amathieu13 on Feb 16th 2022 at 2:27:04 PM

Alright then. My personal system would likely be language -> wiki type -> namespace if we were to go multi-level, but that's my opinion (may already be thought of, though, and there's a 2.0 thread in the languages forum as well).

Edited by Piterpicher on Feb 16th 2022 at 8:41:04 PM

Currently mostly inactive. An incremental game I tested: https://galaxy.click/play/176 (Gods of Incremental)

I have some ideas for how the URI formatting could work in 2.0. To start, I have some criticism about the wiki disambiguation examples provided on that page:

• It creates confusion when the disambig is commonly used as part of the title. For example, Sonic the Hedgehog (2006) could either be titled SonicTheHedgehog2006 or SonicTheHedgehog. Even if we had a policy on this, it could make the page slightly harder to find, or determine which title to use. And that's no good!
• The slashes imply hierarchies of unrelated works. While the namespace system has its flaws, and would be overhauled with 2.0 anyway, the ways it organizes works makes sense. Frozen (2010) is in the category of Film, but the proposal suggests that the category would be "Frozen", which isn't a meaningful category. It just shares a name with Frozen (2013). Additionally, these kinds of hierarchies can be inconsistent between languages. Frozen (2013) may share its name with Frozen (2010) in English, but in French it's named La Reine des neiges, which instead shares its name with its inspiration (also known as The Snow Queen in English).

My idea would be to keep all works on a flat plane, so no hierarchies there by default. This means we would keep the current disambiguation style, like Frozen (2013).

However, URI hierarchies could be useful for troping In-Universe elements (mainly characters), and the now-auto-generated sub-pages which could look like so:

• https://tvtropes.org/wiki/AdventureTime/Tropes/A-C
• https://tvtropes.org/wiki/BigBad/Literature

Alternatively, these could just handled by queries, but I'd prefer page names to be more human readable.

I would also prefer to keep namespaces, but without the clutter of using it for subpages. They could match up with the page type, like Trope (Main), Work, Creator, Admin, etc. By combining namespaces with subpages, the above URIs could look like:

• https://tvtropes.org/wiki/work/AdventureTime/Tropes/A-C
• https://tvtropes.org/wiki/main/BigBad/Literature

...but that looks a bit cluttered. Maybe remove the wiki part. Also, not every language is going to use the same words. Either we could change the words depending on the language, or we could shorten them down to single letters or acronyms, which save a lot of time writing.

• https://tvtropes.org/w/AdventureTime/Tropes/A-C
• https://tvtropes.org/m/BigBad/Literature

There's a lot that could be said about languages in the URI, but that would probably be more suited for the dedicated thread about languages in 2.0.

I think you're misunderstanding the intent of the design.

1. Each article would have an internal, permanent ID that would form an unambiguous URI for that article. Example: tvtropes.org/wiki/12345 might be the permanent link to The Lord of the Rings.
2. Human-readable URIs would be automatically generated so as to be the shortest possible unique combination of the title plus category tags. Category tags include page type, medium, format, genre, subgenre, publication date, author, publisher, and so on.
3. Alternative titles, including language-specific translations, would be stored in the database along with the article itself. These would also become valid URIs and would go through the same disambiguation system.

---

Thus, if there is only one work named Frozen, tvtropes.org/wiki/Frozen would be unique and would be used as the default, human-readable URI for the article.

1. Because the wiki knows that "Frozen" is the English title, using that URI would imply that the reader wishes to see the English article.
2. If someone uses tvtropes.org/wiki/LaReineDesNeiges, and that is established as a French alternate title, the software would bring them to the French version of the article.

---

If there are multiple articles sharing a title, then the software would figure out the least number of tags needed to tell them apart and those would become the "default" URIs.

1. If there are two works named "Frozen" — a novel and a film — then the simplest possible URIs would be tvtropes.org/wiki/Frozen/Film and tvtropes.org/wiki/Frozen/Literature.
2. The tags would work in any order, so tvtropes.org/wiki/Film/Frozen and tvtropes.org/wiki/Literature/Frozen would also be valid. However, we would want to establish a preferred order to avoid confusion in constructing wicks (and especially in handling inbounds).
3. If this ends up being too confusing we could demand that the title always be the first element in the URI.
4. You could use any sufficiently unambiguous combination of category tags in the URI. For example, tvtropes.org/wiki/Frozen/2013 would also match only one article.

---

Subpages would be additional tags that would go into the same system. These would be automatically generated views, so hard splits of articles for length would no longer be needed.

1. If you want to see the YMMV view of the film version of Frozen, you might use tvtropes.org/wiki/Frozen/Film/YMMV.
2. If there are more examples in a particular view than can be comfortably rendered, the software will automatically paginate. You could control pagination via something like tvtropes.org/wiki/Frozen/Film/YMMV?page=2 or tvtropes.org/wiki/Frozen/Film/YMMV?count=101-200.

Note that subpage collision is impossible in this system. All examples are logically attached to their work and trope via the database. Subpage views would simply apply filters to the entire trope list. Characters subpages would employ hierarchies, which are discussed in my master design document but I don't know how well the 2.0 summary here describes them.

---

If a URI is used that is insufficient to disambiguate between all articles sharing a title, the software will bring the user to an automatically generated disambiguation page. If desired we could add content to such a page, like a description.

1. If you use tvtropes.org/wiki/Frozen, you'll come to a page that says, "Which version were you looking for?" and lists the film and the novel.
2. These auto-disambigs would return HTTP status code 300, or a similar code that instructs the requestor that they need to fix their link to point to a valid article.
3. We could also force such URIs to redirect to a predetermined article, such as one with the Franchise type.

---

It would also be possible to construct a URI with explicit parameters. This could be helpful if there is confusion between category tags and titles, like a film that is named "Literature".

1. Another way to reach the YMMV subpage of the film version of Frozen, on page 2 with 100 examples per page, would be tvtropes.org/wiki?title=Frozen&medium=Film&format=Animated&year=2013&subpage=YMMV&page=2&count=100. Of course, most of those parameters would be unnecessary since there's no ambiguity between the format and year tags.
2. There would be a search page that allows the specification of these parameters explicitly.

---

Languages would also be category tags, but as I said above, a translated title should also imply the desired language.

1. If there's a French version of the Frozen article, you could use tvtropes.org/wiki/Frozen/Film/Fr, or tvtropes.org/wiki/Frozen/Film?lang=Fr. The wiki would give you the French translation if one exists. If it does not, you would get an automatically generated page saying that there's no French translation and offering other language options along with the option to create the French version.

---

Since tropes are distinct article types from works, we could explicitly distinguish them in the URI or apply the same disambiguation logic as above.

1. If there's a work named Stating the Simple Solution and a trope named Stating the Simple Solution, tvtropes.org/wiki/StatingTheSimpleSolution would take you to a disambiguation page.
2. tvtropes.org/wiki/Work/StatingTheSimpleSolution would go to the work article and tvtropes.org/wiki/Trope/StatingTheSimpleSolution would go to the trope.

Edited by Fighteer on May 13th 2022 at 4:01:36 AM

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Thank you for the info, but I can't tell that it addressed either of my concerns. Specifically, that:

• The disambig may or may not be part of the official title, such as with Sonic the Hedgehog (2006). Figuring out whether or not this is the "real name" wouldn't be necessary if it were consistently in the page title when it's needed to disambiguate.
• Forward slashes are used in an URL to indicate a hierarchy, and disambiguating a name isn't really a hierarchy that's relevant to the content of the page. The two movies named Frozen are unrelated.

---

I don't like these parts of the URL examples:

Assuming these are the end page URLs and don't redirect to anything cleaner, they're messier than what we have now. Your average person won't be familiar with the query format, so having a clean URL would be preferable.

Page lengths may also vary depending on site configuration and user settings. Linking to a page could lead to somewhere different with different settings, which is a problem I've noticed with linking directly to pages in FluxBB. Both also suffer the risk of entries being added or removed, resulting in the content shifting out of range.

All these issues would both be solved using alphabetical ranges, as we tend to do now for splits. The difference being that this is now done automatically, based on URL:

For lists organized by year, year ranges could also come in handy:

Queries may be useful for custom searches, but they aren't necessary for browsing the wiki.

What's the difference, logically, between tvtropes.org/wiki/SonicTheHedgehog2006 and tvtropes.org/wiki/SonicTheHedgehog/2006? The latter preserves the original title of the work and makes the year of publication one of the category tags so it can be sorted and filtered.

The slashed components of the URL are not namespaces because namespaces will no longer exist.

The ?page=2 parameter is for pagination and filtering, not a part of the permanent URL, although I suppose it could be condensed into a slashed component (tvtropes.org/wiki/SonicTheHedgehog/2006/p2). I want to get rid of the "Tropes A-C" hard-split thing permanently.

You can only really use a numeric URL component (2000-2010) for one thing, and that would be publication year. It would be equivalent to the parameter "?year=2000-2010", and would generate a filtered view of an article, presumably an index.

Remember, in this system, every slashed part of the URL is a parameter to a database query that will use that information to figure out which article the user is looking for and what view of that article they want.

Edited by Fighteer on May 14th 2022 at 12:59:20 PM

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

The reason I brought up Sonic the Hedgehog (2006) is because I noticed the (2006) is included in the title when referenced in Super Smash Bros., but not on the box art.

After doing more research, most other sources I could find call it Sonic the Hedgehog. It turns out I was wrong about the inconsistency, so that likely isn't as much of an issue as I suspected it would be.

---

I'm not talking about namespaces; I'm referring to the standard URL syntax which most websites attempt to follow.

For every slash added in the URL, that's an extra relationship being implied. The work name can act as both a directory and a standalone page. To use a random work I found, you could use Brockmire or Brockmire/2007 or Brockmire/Series.

Having a single, central page name determined by the editors is beneficial. It makes it easier to figure out the best name for a page.

---

A-C would be a range automatically handled by the database, so it wouldn't be a "hard split". You could write A-B, or A-D in the URL and they would also work.

The benefit of using these is that the URL is consistent, showing the reader where the content is. I suppose page numbers would be a simpler solution to the problem of loading an overly long page though.

---

I understand the general benefits of 2.0, but I have a hard time understanding the motivations for some of the smaller decisions. You mention that that namespaces won't exist—but why? Most wikis have namespaces because they help in distinguishing different kinds of pages. It's no different here, where there are distinct page categories like trope, work, or administrivia.

Since these things affect the people who use the site, we should be able to know how these kinds of changes are so precisely planned out.

Namespaces don't actually help the wiki very much. The original reasoning was to be able to tell apart articles with identical titles, but we've since seen that we get subpage collisions and custom title collisions anyway.

What we're doing here is transforming namespaces into category tags and making them more flexible.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

For the record, subpage collisions are generally a subjective problem, not everyone would easily agree they cause issues. Custom title issues generally are more so. Though I do kind of see a use in namespaces since they help show what kinds of works we have pages on and what ones we don't, what media type can be seen as oversaturated and what could use more coverage. As long as 2.0 lets me easily tell that, I'm fine with it.

Edited by Piterpicher on May 15th 2022 at 3:02:43 PM

Currently mostly inactive. An incremental game I tested: https://galaxy.click/play/176 (Gods of Incremental)

For the record, I like everything said here. I almost want the return of ptitles because manually moving wicks for one rename takes forever.

TroperWall / WikiMagic Cleanup

The category tags would automatically generate indexes. That's one of the best parts of this.

In this scenario, a custom title would be applied to the article ID, not to the title. So if there are two different works with the same title that use different capitalization or punctuation, the custom titling could be done independently for each.

Even better, renaming an article would only require one change: the title element of that article. All wicks would update automatically since they are using the article ID internally. The only things that would have to be updated manually would be potholes.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Since we don't have an anti-Necro policy...

Am I correct in saying that the "database-level trope example method" is like what's going on with Video Examples? They're a link to and from works and tropes, that automatically place themselves?

Disambig Needed: Help with those issues! tvtropes.org/pmwiki/posts.php?discussion=13324299140A37493800&page=24#comment-576

Who knows. From database design, it'd be logical to make a separate list for examples, like "* Context: Trope - Work", and let the two pages scan for own mentions.

Edited by Amonimus on Feb 8th 2023 at 8:04:03 PM

TroperWall / WikiMagic Cleanup

I believe so. Lets you do stuff like . You could also automate a lot of stuff like crosswicking, alphabetization, and splitting and merging pages, which would take a lot of grunt work out of maintaining the wiki.

Edited by badtothebaritone on Feb 8th 2023 at 11:07:28 AM

I get the feeling the current team isn't particularly interested in developing that, though. They still haven't fixed the search engine, which has been broken for years now. It's been seven years since this update broke it. That's inexcusable.

Edited by Redmess on Feb 9th 2023 at 12:28:28 PM

Optimism is a duty.

2.0 isn't happening any time soon. We shouldn't worry about it yet.

I had a dog-themed avatar before it was cool.

Is it ever going to happen at this point?

Optimism is a duty.

Not our in lifetimes I expect

New theme music also a box

It's always been a theoretical, really.

Currently Working On: Incorruptible Pure Pureness

I'm sorry, but that's not how they put it when they were running a Go Fund Me campaign for the site way back when.

Optimism is a duty.