2.0 is the name of a planned overhaul of the TV Tropes database and page handling systems.
The key concept is that where nowadays pages are each one database object, in the future system they will instead be assembled from many database objects. Each of these objects is editable and has a history associated with it, similar to how pages work today. In technical terms, the wiki will be constructed from "relational database" elements rather than unstructured text.
Other design goals are Unicode compatibility and integrated multi-language/translation support. All pages of the same trope or work will automatically link to the cross-language (identified as "same page ID, different language ID") versions thereof.
open/close all folders
Core Concept
- The wiki structure will move from flat text objects that are analyzed by a parser to a relational, data-driven system.
- Articles, article components, and individual examples will be structured data elements.
- Pages will be generated dynamically, allowing alternative views, sorting, filtering, and pagination, which can be controlled by individual user preferences (e.g. number of examples displayed per page).
- Indexing, media tags, and other meta-data expressed as relationships.
- Relationships between wiki objects in code rather than in text.
- Integrated comment sections that permit conversations to be attached to any wiki element, but still viewed at the main article level.
Purpose
- Examples will automatically appear on both work and trope pages, making Crosswicking superfluous.
- Tropes and works are now identified by an ID rather than by their name, which should facilitate renames.
- Many editing rules (e.g Example Indentation in Trope Lists or What Goes Where on the Wiki) will be enforceable by the software rather than by hand.
- Conversation in the Main Page would be diverted into comment threads, making it much less likely to be inserted into the article body.
- There will no longer be a need to hard-split articles, as pagination, filtering, and grouping would allow a given article to handle any amount of content.
- Actions (e.g editing, cutting) can be done now on a per-object basis without the need to apply them to the whole page.
- Checks that rely on "diffs", such as spam filtering, text-replacer detection, and so on, can be applied only to a user's individual edits, not to the entire body of each article.
- Articles would no longer be at hard-coded text URLs; rather, the parser would take a submitted URL and treat it as a database query, looking up the closest match. Disambiguation and prioritization would be automatic.
- Article subpages would no longer be hard-coded but rather based on the user’s filtering selection. Certain types of subpages could have predefined style/layout.
URLs
Article linking (URL construction and querying)
In the new system, an article will have an internal ID value that forms its permanent URL. Examples: https://tvtropes.org/wiki/3885774
= The Lord of the Rings, Literature. https://tvtropes.org/wiki/549437 = Big Bad.
= The Lord of the Rings, Literature. https://tvtropes.org/wiki/549437 = Big Bad.
All other wiki URLs, other than to static objects like Ask The Tropers, will be treated as database queries. These queries will contain parameter elements that identify the search terms. Certain parameter elements will also modify the display of the article, such as sorting, filtering, subpage display, etc.
A “human friendly” URL will contain textual parameter elements separated by slashes, which the parser will take a “best guess” at, returning the element with the highest probability if there are insufficient secondary matches, or a list of elements that the user must choose from if the ambiguity is above a certain threshold.
Human-readable default URL
- All articles should have a human-readable default URL that contains all the information needed to uniquely disambiguate it. The wick component (everything after https://tvtropes.org/wiki) would be used in the editor instead of the ID to avoid confusion.
Complex URLs
- The expanded destination URL will look something like https://tvtropes.org/wiki/search.php. May have synonyms.
Search parameters may include any of the following:
- id — Article ID. If found and valid, this will generate an exclusive result.
- title (t) — Article title. This will generate a fuzzy query against the title repository.
- type — Article type. Allows all page types.
- medium (m) — Medium. Reference against medium index, smart enough to understand nesting.
- genre (g) — Genre. Reference against genre index, smart enough to understand nesting.
- author (a) — Author. Reference against Creator articles related to work page.
- year (y) — Publication year.
Presentation parameters may include any of the following:
- subpage (sub) — Subpage: could be YMMV, WMG, Characters, or any supported subpage filter.
- filter (f) — Synonym for subpage.
- sort (s) — Sort: choose from sort options (alpha, date added, date modified)
- group (grp) — Group: choose grouping: medium, genre, trope category, etc.
- page (p) — Page number in a paginated article.
- length (l) — Number of examples listed on each page.
- view (v) — Read (default), Edit, Comments, Images, Quotes, History
Examples of complex URLs:
- Resolves uniquely to The Lord of the Rings, Literature
- Finds multiple hits, shows disambiguation or franchise landing page if available.
- Titles without spaces are acceptable in URLs, so are partial names of authors. This will resolve to the LOTR book article.
- This will return the LOTR article with 50 examples per page, grouped by trope category (plot, character, production, etc.)
- This will return the LOTR literature article in the Comments view.
- This will find the Big Bad trope article.
Friendly URLs The wiki parser should also understand URLs submitted in a more reader friendly format, using fuzzy logic to handle them. Rather than using parameter elements, forward slashes will separate terms that will be fed to a search engine.
Examples of friendly URLs and handling:
- URLs with a single text object will assume a title search. This will resolve to a disambiguation page or a franchise landing page.
- https://tvtropes.org/wiki/LordOfTheRings/film
- URLs with two components will assume one to be the title and the other to be an author, genre, type, medium, or year keyword. This will find two hits
- the Bakshi animated film and the Jackson live action film, and generate a disambiguation.
- https://tvtropes.org/wiki/LordOfTheRings/1955
- This will match one of the publication dates of the original LOTR books and so will resolve to the literature page.
- This will recognize the ‘edit’ keyword asking for the page to be shown in edit mode.
- This will find the Lord of the Rings literature article, open it to the Characters view, and drill down to the tropes associated with the character Legolas.
- This will arrive at (a) the work-agnostic general article for the character Legolas, (b) a disambiguation page showing all matching character articles, (c) the Lord of the Rings character, Legolas, if there is only one such entry.
Search and Indexing
- It should be possible to enter queries without a title element; this would be interpreted as an index search.
- Both of these queries will enumerate all works in the Fantasy genre and the Literature medium published between 1950 and 1959.
Note that some degree of prioritization is implied in the “fuzzy” searches; it will be necessary to rank indexes higher than tropes and works, for example.
Article/Page
When a page is parsed a query calls all these elements and the parser assembles the final HTML. This HTML may be cached so that it doesn't need to be re-parsed with each request. Several types exist, all with particular element types that can be associated with them:
- Administrivia (Just a description element)
- Trope.
- Work.
Real Life will be a special work page, with additional restrictions. These page types are hard coded and cannot be changed.
Then the wiki would gather all the relational elements of the article and assemble them.
- The displayed title would be the Title element identified.
- The header would contain a set of controls to visit its related sub-elements. For example, if an article has an associated Analysis text element, it would be available to click on. This is similar to current buttons. The header would contain an automatically generated subpage filter for examples. For example, if there are any examples on a work article linked to tropes flagged as YMMV, then those would not appear on the main article display, but instead there would be a “YMMV” filter available to select.
- For articles that are parents (they index child articles, as a trope index, author index, etc.; they have child relationships such as a franchise with sub-works or a serial work with episode/volume articles), a list of child articles will be displayed. This should be collapsible and sortable. Some form of control over the organization of the list may be useful, as would some form of nesting.
- In the examples section (if that section is not hidden by mod control), up to [X] examples would be shown based on defaults and/or the user’s preferences in alphabetized form. If more than [X] examples are present, pagination controls would appear. Folders would appear for tropes based on the medium categories of the works linked to its examples.
(Note: Discuss how/whether to automatically folderize work articles.) - Examples would be automatically indented as appropriate. When more than one example for a trope/work is present, the nested examples should be organized by the relationship hierarchy (see below for more).
- At the top of the examples section, sorting and filtering controls would be present. Possible sorts: alphabetical, by medium (for trope articles), by trope category (for work articles), by character (for work articles), by date added, etc.
- In the footer of the article, additional URLs would be shown along with the Stinger text element, if present.
Objects, also named "elements"
Each of these is created either during page creation or by an addelement function. Individual elements each have an ID that cannot be reused. They have a history page and an edit page associated with them.
- Analysis: Several per page, can be created by an addelement function. Allows bullet points.
- Description: One per page, contains the description text and is created during page creation. Deleting a description is what "cuts" a page. Allows bullet points.
- Example: These contain example text and are connected each to a trope and a work. They can be flagged with Playing with a Trope, potentially also through the markup. Also, there will optionally be two versions of the example text, for work page and trope page.
- Image Links: Several per page, allow links to image URLs. Need a dedicated addImageLinks function.
- Laconic: One per page, can be created during page creation or afterwards, displays a laconic. Automatically formatted.
- Playing With: For tropes, allows a formatted list of Playing With elements.
- Quote: Formatted like quotations, these hold quotes. Each is attached to a trope or work.
- Self-Demo: A free form page, sort of an equivalent to description. Allows bullet points.
- Settings: One of each exists for each page/article and is created during page creation. It applies cross-language. By default only editable by moderators, it includes all per-page settings:
- "Global lock" (elements associated with that article are only moderator editable), "Google ads" (for whether to display Google ads), "Fake redlink" (overriding the blue link colour for URLs pointing at the article), "Funky markup" (allowing text colours and strikethrough), "Spoiler tags" (whether to allow spoiler tags on associated elements to work)
- For works, "Published" (for Unpublished Works, disables crosswicks)
- For tropes, "Trope" (Audience Reaction, Example Sectionectomy, Flame Bait, Trivia, Trope, Useful Notes; each controls the appearance and induces filtering in default appearances, plus setting banners) and "Real Life examples allowed?" (implements No Real Life Examples, Please!)
- Stinger: One for each page, is an optional element that can be added. Each page can only have one visible stinger element. Formatted like a quote.
- Title: One for each page, is created during page creation and only moderator editable afterwards. It contains the appearance of the article title (similar to a Custom Title).
Per-element functions
Aside from standard editing, there are functions associated with elements. They are all subject to locks and edit bans. Some of them will be assisted with AJAX (e.g ) but there will be non-scripting fallbacks. All such functions generate an entry both in the edit history of the element and the troper in question.
- Change Play: For examples, it allows the Playing With status of an example to be changed.
- Edit: Obvious.
- Delete: Available for moderators on most elements save for Settings and Title, it automatically hides the element text and its history behind a splash page "Element X was deleted by Y on date Z for reason: A" for anyone who isn't a moderator. This element is automatically excluded from queries.
- Delist: Available for everybody on examples, Image Links, quotes and Analysis, it hides the element from queries, thus also from example and quote lists. A banner named "Element X was delisted by Y on date Z for reason: A" appears above the element. It generates an entry both in the edit history of the element and the troper in question.
- History: Obvious.
- Lock: Done by moderators. It generates an entry both in the edit history of the element and the troper in question.
- A plain lock does prevent non-moderators from modifying the element in question.
- A "cascading lock" (which does not imply a plain lock!) tells the addelement function to not permit to add elements that feature the metadata (elementtype+work+trope combination).
- A button to simultaneously perform "delete" and "cascading lock" - "salt"? - is also good.
- Move: For quote, Analysis, Image Links, example elements, it allows one to change the trope or work the element is associated with.
- Relist: It automatically creates a clone of a delisted element (including its history) but set to "not delisted". Allowed everywhere delisting is allowed.
- Revert: A moderator button which allows older versions of an element to be restored.
- Translate: Applies to all elements save for Settings, it allows elements to be translated in different languages while forking the element. It automatically assigns the correct language ID while keeping the page ID(s) identical. It needs to check that no elements are created for tropes whose descriptions weren't yet translated in the given language.
- Undelete: It automatically creates a clone of a deleted element (including its history) but set to "not deleted". Allowed everywhere deletion is allowed.
Some markups may be allowed only in particular elements. Direct links to elements are excluded from search engines.
Other functions
The "New Edits" function needs to be filterable on per-element and per-action (e.g Delete) basis. And perhaps per troper - having two different functions for edit lists is rather pointless.
Related To pages:
- Element ought to be assessed individually by the Related To page. In other words, the page would no longer list wicks on a per-article basis, but on a per-elements one.
- It also should link to the edit page for each section linked to.
- A function to remove "ghost wicks" from there.
- Wicks should be listed by element and page type, not by alphabet.
- There are other requests in various threads, which can be found in the forum search "related" - of course, some might not be feasible for performance reasons.
A function to rename tropers may be desirable, it will need a system in the backend.
A way to have Edit Notices for pages meeting particular criteria? They would replace the standard edit tips on the pages concerned.
A way to merge one page ID into another. This is a moderator tool that works irreversibly to reassign elements from one page ID to another. Useful to handle translation goofs as well as duplicates.
Troper permissions
- Global moderator: They have all the non-wiki tools as well as the ability to grant and revoke local moderator status on a per language basis.
- Local moderator: Assigned per language domain, they have the ability to (un)lock and (un)delete elements as well as to edit them in the locked and view them in the deleted state. They are limited to their assigned language domain.
Save element edit actions
Aside from standard editing, there are functions associated with elements. They are all subject to locks and edit bans. Some functions will be assisted with AJAX (e.g ) but there will be non-scripting fallbacks. Edit pages are accessible by an unique URL addon to the element ID URL.
- It checks any added links that they resolve to an unique function
- For examples, it checks that the trope exists
- For examples, it checks that the example text is sufficiently long
- It checks whether the entry text contains Word Cruft, First-Person Writing and other problem items. Needs a configuration function.
Createpage and createlement actions
Aside from standard editing, there are functions associated with elements. Aside from standard edit bans, special bans may apply to both. Some functions will be assisted with AJAX (e.g ) but there will be non-scripting fallbacks. In the following order:
- For all elements, it needs to check whether they have at least one page they are attached to.
- For examples, it needs to check whether the trope exists; the work existing is not so important.
- It needs to check whether the submitted element clashes with a "cascading lock", and reject it if it clashes and is submitted by a non moderator.
- It checks whether the entry text contains Word Cruft, First-Person Writing and other problem items. Needs a configuration function.
One idea is to have addexample be only linked from trope pages, to force people to read the description. Also, maybe having a function that can convert free-form text into structured elements is useful. Perhaps reuse the Conversion script?
Mass edit function
- Access to the function is granteable by moderators, but is not assigned to anybody by default. Access adds a "Mass Edit Query" form in the sidebar.
- The form allows one to fetch all elements containing a) a link to a given page or b) a given text string (e.g "This troper"). Perhaps make it so that it allows wildcards, case sensitive or insensitive selection or markup- or view-specific search.
- Saving the query generates a list of elements, each of them displayed in edit mode. The initial page contains as many elements as can be a) loaded by a browser and b) as can be saved in one go without causing server lag. If too large, the list should be paginated with paginated URLs so that the entire query can be displayed in tabbed form.
- Each element can be edited (during the save process, unedited elements are not altered) and has checkboxes allowing for actions (e.g "Delist", "Put into Maintenance mode" or "Move", equivalent to the element action buttons).
- Each page has a Save button and an edit reason input box. Saving causes all the elements be modified if they were edited or some action was selected, using the input edit reason. The other pages part of the paginated query can be edited/modified afterwards (the save affects only the elements on a particular pagination, not all queried elements).
Convert
Presumably, we'll write a script that will go through all current wiki articles and convert them into the new database structure. For a substantial percentage of articles, there will be markup that an automated parser is not able to understand. How shall we deal with this problem?
The proposal:
- Don't convert everything all at once. Instead, the new and old designs will run parallel for a while.
- Articles will be, over time, entered (automatically or manually?) into a transport queue.
- The agent driving the queue will come up with a "confidence" value indicating how much of the content was successfully converted.
- Articles over a certain confidence value will get converted automatically.
- Articles below this confidence value will be flagged for user attention.
- Articles in the queue should be automatically locked to (a) prevent data conflicts, (b) encourage editors to participate in the conversion process.
- User attention would involve any/all of:
- Cancelling the conversion to spend more time cleaning the article.
- Correcting the article's destination (example: subpages merging with main article, proper medium tags for works, etc.).
- Fixing markup in the article that is not recognized by the parser.
- When an article is converted, the existing article is removed from view, automatically redirects to the new article, and generates a HTTP 301 code for referrers.
- The old content should be archived in case a reversion (or re-conversion) is needed.
- The old history and discussion pages would be archived in a read-only mode.
- Converted articles would contain an "unconverted markup" section that would show any markup that was not successfully transported.
- In the conversion queue, prioritize high level docum
Open questions
- Adaptations and franchises, how to make a hierarchy of them.
- Substitute for commenting out elements?
- Compare/Contrast element? See thread.
- Connecting article ID with an URL or several
- Creator pages?
- Createpage restrictions for Administrivia?
- Crosslanguage links?
- "Curator" user right?
- Customizability of the example section header?
- Decide on how to handle languages.
- Discussion as well as whether to put a link to it on edit forms
- How to handle character pages?
- ID thing creates some hairy problems if a page is cut then recreated (say, for having insufficient examples) ... examples would become disconnected from the new page. Basically, how the createarticle function for works would "catch" already existing examples for that work.
- Images: Markup things or individual elements?
- Indexes and Categories?
- Laconic as hovertext?
- Language specific bans?
- Media categories?
- Merge ID function?
- Meta information: Authors, Genres, Publication for works and Trope Attributes (e.g Appearance Trope, not the same thing as Trope Types in "Settings"). Some could be tied to particular example types in the addexample function.
- Old histories: AKA the old edits by troper, page histories and "combined history". These should be archived in watch-only mode, linked from the appropriate new pages.
- Page creation: When to trigger it
- Post-expand article size: How many elements of how much length can be parsed before pagination.
- Permanent Red Link Club: How to enforce it?
- Permanent Red Link Club: Allow examples from works in there?
- Recap pages?
- Red links?
- Report function
- Rotation of images
- Sandbox namespace
- Selective deletion: The deletion system should apply to edit reasons as well, hiding them from non-moderators but still displaying to staff (with the red border and note as mentioned under Deletion, as well as the ability of restoring). Maybe such a system could apply to old versions of elements, hiding the history entries around the deleted version. Same stipulations as before regarding visibility to staff, red border and note/un-deletion ability.
- Spoilers
- Sugar Wiki and Darth Wiki
- Tagging: Characters? See also here.
- Translations: One proposal, another exists.
- Troper pages
- Examples for nonexistent works
- Integrated voting feature for sections like Quotes, Images, and Moments.
- How to work with Recap, Timeline and Fanworks namespace pages.
- Watchlist.
- Wicks: Current standard link to URL or internally replaced with an ID?
- WMG and Headscratchers
- ZCE rule exemption?
