(Blog post created or updated.) |
m (Blog post created or updated.) |
||
Line 15: | Line 15: | ||
So the final solution I chose is actually a combination of solutions 2 and 4: |
So the final solution I chose is actually a combination of solutions 2 and 4: |
||
:''We'll keep the L template as it is now for all pages: it only links series' pages and "X" pages that actually exist for the first 49 (and a half) rows of the table. Past that they won't be linked. Too bad. It's a limit we'll have to deal with. However, such pages will have a warning letting readers know of the limit (using a dedicated template), and links to subpages with sections of the table that will each be less than 50 rows long. |
:''We'll keep the L template as it is now for all pages: it only links series' pages and "X" pages that actually exist for the first 49 (and a half) rows of the table. Past that they won't be linked. Too bad. It's a limit we'll have to deal with. However, such pages will have a warning letting readers know of the limit (using a dedicated template), and links to subpages with sections of the table that will each be less than 50 rows long. |
||
− | The criteria for the split will be chosen depending on the page itself. In some cases we might split between "In-universe links" (type 1), "sub-universe links" (type 2) and "out-universe links" (type 3); in some cases we might |
+ | The criteria for the split will be chosen depending on the page itself. In some cases we might split between "In-universe links" (type 1), "sub-universe links" (type 2) and "out-universe links" (type 3); in some cases we might split based on the company (for exaple Marvel series might have a table page dedicated to "links to other Marvel series" and one for "links to non-Marvel series"); in some cases we might spit based on media, and so on. It depends on the nature of the series and its links. |
The main problem with this solution is that now rows in the table might need to be duplicated to each table subpage, but duplication had to be done before as well to some degree, so I think it can be handled. |
The main problem with this solution is that now rows in the table might need to be duplicated to each table subpage, but duplication had to be done before as well to some degree, so I think it can be handled. |
||
− | I'll start implementing this solution soon, but as I was writing this one more thing came to my mind. What if we |
+ | I'll start implementing this solution soon, but as I was writing this one more thing came to my mind. What if we try to decrease the number of links in those tables? What if from now on we are more strict about what we consider a link? Maybe this is an issue that deserves a blog post on its own in the future, but I am considering to change the definition of "[[Link]]" to not include any more all those minor mentions or background cameos and stuff like that. Maybe we'll discuss that in a later time. |
Let me know if you disagree with any of the things I wrote. |
Let me know if you disagree with any of the things I wrote. |
Revision as of 21:01, 19 November 2017
Ok after doing some thinking I settled on a solution for the table of links in series' pages. In case you don't know what I'm talking about, this is a follow up on this blog post. The gist is that I changed the "L" template so that now only series and "X" pages that actually exist on the site will be linked, therefore removing redlinks, however this has a limit: only the first 49 rows in the table will be correctly linked, past that there won't be any link. Pages that exceed the limit are easily found because they're automatically added to this category.
In that blog post I proposed 5 solutions, including to increase the limit, but since that's basically impossible to me (I'd have to actually access a file in the Wikia servers and edit it), I'd remove that and replace it with another solution I hadn't considered before: leaving things as they are right now. If I do find a way to increase the value, that would automatically be the chosen solution, so either way it's pointless to have it listed. So the updated possible solutions are:
- All redlinks: just reverting things back to how they were before. The series and the "X" page are always linked in each row of the table.
- No link past 49th row: things as they are right now, with the #ifexist function called on the series' name and on the "X" page. (actually the 50th row does correctly link the series name, but not the "X" page since the limit is to 99 calls of the function).
- Half the problem: only call #ifexist on the series name. The "X" page will either never be linked (making it unaccessable directly), always be linked (creating redlinks), or have the link be tied to the series (so if the series has a page, the link to the "X" page will also appear, resulting in some redlinks and some unaccessable X pages). The series still will never be linked past the 99th row though.
- Table split: series with too many links will have their table split into subpages, instead of having one long glitched table. There are various possible criteria to chose from for the split.
- Different templates: pages with too many links will use a template different than "L", making it possible for dedicated solutions. This however would create a consistency problem.
As I said in the original post I would also consider combining some solutions, and I did toy with that, since I believe it's the way to go (for example I thought about combining 1, 3 and 5: for pages with over 49 rows we would use a different template with only one call of the function, then for pages that go over 99 rows we would use yet a different template that doesn't call the function; or we could combine 3, 4 and 5, meaning that past the 99th row instead of a different template we would split the table and revert to the former template for the subpage, unless they too go over 49 and then over 99)
Now, after doing some thinking I happen to have developed a new philosophy for this site, which is: some of this Wiki's pages will never exist. Before, I took for granted that theoretically all series and all connections between them would have to have a page, but now I'm convinced that's not true. Some pages don't deserve to be here. We don't have to have a page for a TV series just because they mentioned Pac-Man once; we don't have to have a "detailed link page" (aka an "X" page) for something that can be explained in a sentence in the description in the table. Stuff like that. With this in mind, to me redlinks are unacceptable now: before, I considered them placeholders for pages that would teoretically be made one day. Now they're just redlinks and it's wrong to have them here. With this in mind, any implementation of solutions 1 and 3 are prohibited.
Also, I've been thinking that having the table split would go against this site's philosophy to some degree: I want all the informations about a series' connections to be in one page (that is evident considering how long some of the pages I made are). To me this is possibly more important than having the page links there, and that's why I started to consider solution 2.
So the final solution I chose is actually a combination of solutions 2 and 4:
- We'll keep the L template as it is now for all pages: it only links series' pages and "X" pages that actually exist for the first 49 (and a half) rows of the table. Past that they won't be linked. Too bad. It's a limit we'll have to deal with. However, such pages will have a warning letting readers know of the limit (using a dedicated template), and links to subpages with sections of the table that will each be less than 50 rows long.
The criteria for the split will be chosen depending on the page itself. In some cases we might split between "In-universe links" (type 1), "sub-universe links" (type 2) and "out-universe links" (type 3); in some cases we might split based on the company (for exaple Marvel series might have a table page dedicated to "links to other Marvel series" and one for "links to non-Marvel series"); in some cases we might spit based on media, and so on. It depends on the nature of the series and its links.
The main problem with this solution is that now rows in the table might need to be duplicated to each table subpage, but duplication had to be done before as well to some degree, so I think it can be handled.
I'll start implementing this solution soon, but as I was writing this one more thing came to my mind. What if we try to decrease the number of links in those tables? What if from now on we are more strict about what we consider a link? Maybe this is an issue that deserves a blog post on its own in the future, but I am considering to change the definition of "Link" to not include any more all those minor mentions or background cameos and stuff like that. Maybe we'll discuss that in a later time.
Let me know if you disagree with any of the things I wrote.