FANDOM


Here's what I have so far.

An Automated system for generating chronologies

Problem Statement:
The system I imagined was based on two tags, which, for the sake of argument I'll call {{chron}} and {{chronList}} (because "Appearance" is just too long to type repetitively). {{chron}} would be a tag placed on a page to automatically add it to a list or chronology, while {{chronList}} would actually be responsible for displaying such a list on a page. As I see it, there are a few basic requirements for the two tags:

  1. Adding/removing the chron tag to/from a page should automatically add/remove an entry in the appropriate character/vehicle/item chronology
  2. A chronology is necessarily sorted, so there should be some mechanism within the tag to allow placement control in the list.
  3. Comics are very convoluted things, and a single issue can have many stories, reprints, retellings, and flashbacks, so multiple tags on page A to list B should produce multiple entries on the list.
  4. Needless to say, the above requirement would just be confusing if there were no way to put description/notes directly in the list with each entry.

There are also several desirable qualities

  1. Some comic pages are named in rather..."ungraceful" ways. For example, if you want to make an entry for "the Incredible Hulk Vol. 2, #183 (Month, Year)", we would rather it didn't display as "Hulk 2 183".
  2. Character names change all the time, forcing us to move pages and add redirects. Character names are reused all the time, forcing us to add disambiguation. Given that, the method needs to cover redirects and moved pages more gracefully than Categories do; that is, without forcing us to change every chron tag.
  3. Some chronologies are short, some ridiculously long. It would be best to maintain the Category style of displaying them: links for displaying the next/previous (20,50,100,250,500) entries.


Proposal:
Create the chron tag with three parameters, two of them optional. Let 'where' be the page containing the tag.
who - the list for whoever's chronology it is, such as "Spider-Man (Peter Parker)".
sortkey - a text string used to sort the entries, just like Category; defaults to the value of 'where' if not explicitly given.
markup - wikitext which is displayed instead of the 'who' variable (for reasons given below); defaults to [[where]].
The chronList tag is a bit more complicated, and I'll explain my reasoning below. For now, let us consider it as taking any number of unnamed inputs, each representing a 'who' list. All such lists will be merged into a single chronology, which is displayed as a list in a div element as described above. It can also accept optional inputs to control style of the displayed list (exactly what those will be aren't yet decided).

Form:
The form for the chron tag follows directly from the form of the Category tag:


{{ chron | who [| sortkey] [| markup] }} - with optional input in brackets.


The chronList tag would look like so:


{{ chron | who1 [| who2] [| who3...] [| style=input] }} - with optional input in brackets.



Reasoning:
Some features of the tag are necessary (like that automatic addition/removal of list entries), and are totally determined by the coding implementation below. Others are more questionable.

  • I feel that the using wikitext markup as an optional third input is a good way to go, and also feel it should completely hide the 'who' information. This way, if you want to make an entry in a characters chronology from the page 'Hulk 2 282', you can add the tag
{{chron|Hulk (Bruce Banner)|1983, 04|[[Incredible Hulk Vol. 2, #282 (April, 1983)]] -- The Hulk move into Avenger's Mansion}}
Granted, there is a natural problem if someone adds a tag {{chron|Hulk (Bruce Banner)||This entry has no link in it}}, but that could be solved in special pages (see next point), or else we could just tack a small link (something as small as edit links, saying something generic like '[source]') at the end of every entry. Not a major problem
  • Handling redirects and moved pages is a pain. That's why categories now don't do it. It would be a major headache to try and make them keep track of where their "target page" is constantly jumping to. Besides, what if we just linked to a disambig? What if a page becomes a redirect, then later a disambig? What if the page just plain doesn't exist? It makes more sense just to have a page request/catch all the lists it wants for a chronology, then merge them. Since this is all just entries in mySQL, there's no law that states 'who' has to be an exact page name. We could have the list on "Spider-Man (Peter Parker)/Appearances" catch all chron entries for both that name (that is, "Spider-Man (Peter Parker)" and just plain old "Spider-Man", just like we could have "Scarlet Spider/Appearances" catch that and entries for "Spider-Man (Ben Reilly)" and "Spider-Clone". This still doesn't solve the problem of what to do about lists that just never get called, but again, that can be handled in special pages.
  • Originally I planned on a system that would closely resemble Categories. I've come to the conclusion that's overkill. best to keep it simple.


Implementation:

  • The entries should be stored in a database table, say tb_chron, with columns where, who, sortkey, markup. The database should also have a table tb_chronList, with columns who, and where. The second table will make it easy to tell which lists are actually being displayed.
  • Special:Appearances could be used a lot like "Special:Wantedpages" -- a list of all distinct 'who' entries in tb_chron, along with the number of entries. Clicking on one will load "Special:Appearances/'$who'" for each individual who; that page will in turn display links to all pages with chron listings for 'who', along with the sortkey and markup.
Special:OrphanedAppearances would be similar, except it would list distinct 'who' entries present in tb_chron, but not tb_chronList. With these two, the users can go through periodically and "clean house" just like they do with orphaned pages, broken links, multiple redirects, etc. This removes a lot of the overhead associated with the Category code.
  • The code to display the list can be adapted or lifted from view() from CategoryPage.php and the portion of Parser.php associated with the gallery tag. Default values can be set by the template calling an extension tag. Sorting by sortkey is trivial in SQL.
  • The hardest part will be in automatically updating entries and lists. We can tell when a tag is added and update accordingly, but how do we know when all tags/lists have been removed from a page? (what about section edits?) I still need to look into all that, but it will probably require a parser hook. As far as events go, I think save, move, and delete all trigger the "saveComplete" event, so we might get by with just catching that.

Updates: (These comments are supplementary to the original proposal above)

  • It seems categories stores page names in two database columns: one for title, one for namespace. This mostly seems to be a time saver for when they check the namespace against the Category: namespace (which displays as a sub-category, not a listing) and the Image: names space (which displays thumbnails, not just links). This raises two points. First, in the implementation we need to handle those same special cases (just in case someone accidentally adds a chron tag to a category or image page), so that {{chron|Hulk}} placed on Image:Banner.jpg does not produce the wikilink [[Image:Banner.jpg]] when we would prefer [[:Image:Banner.jpg]]. That concern is fairly minor. Second, that does point out that namespaces are a function of language (the namespace 'Category:' is 'Categorías:' in Spanish, for example). Since we want to make sure the database stays multilingual, we probably don't want Spanish chronology notes appearing in English chronology lists, or vice versa. With both those points in mind, the two tables should also have columns for namespace, and language. Image and Category links need to be handled as special cases (remember the extra ':'), and lists on pages writen in language A need to filter lists for the same language. I recall that there should be a way to access the language information of a page in php, so this may not be too much of a problem.
  • So far, it looks like automatically updating database tables will be the difficult part, whereas getting the list to display once the info is in the database will be relatively easy. I'm not sure how much time I'll have to work on this (work looks like it'll pick back up again soon, but we'll see), so if anyone knows the best way to populate/update the tb_chron and tb_chronList tables when a page changes, let me know.
  • If anyone has any other points to watch out for, feel free to post.

Thoughts?

Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+