Template talk:Kolwiki

From Kolmafia
Revision as of 14:45, 30 July 2010 by imported>Heeheehee (Response to StD.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Don't forget, SOP on a wiki is that the external site icon should show up for sites outside of this particular wiki. I'm not sure how to make this work properly in a template such as this, but it should probably be looked at before it's used a great deal. (There's also the possibility of registering coldfront as an external wiki recognized by this one, which does much the same as this template, but involves getting fewyn to push some buttons.) --StDoodle (#1059825) 08:13, 30 June 2010 (UTC)

I didn't think of it like that. Since the Kol wiki uses wikipedia without the external site icon I just figured that it makes sense to not use links for the kol wiki since it is so important to us. I was about to include this template on Datatype Constants, Get ingredients and Mana cost modifier. Before I do that, do you think we should have external link icons for the kolwiki? They're.. well.. Ugly. Should we ask fewyn to push the button and remove plainlinks from the template or what? --Bale 08:22, 30 June 2010 (UTC)

That's a good point. In fact, that's probably what the result of registering coldfront as an external wiki would be; though it may be configurable, I dunno. It's a tough call. I'd say perhaps just add a note to the template description that the template shouldn't be used if the external / internal nature is at all in question (can't think of a page that would be off hand, but you never know...).

As to whether or not to get fewyn to look into it; my answer is usually "if we can figure out a way that doesn't require fewyn to mess with the backend, and isn't a huge PITA, let's use it." --StDoodle (#1059825) 08:33, 30 June 2010 (UTC)

So, does that means you approve of both this template and saving the trouble of troubling fewyn? --Bale 09:17, 30 June 2010 (UTC)

Er, yeah. Sorry, REALLY long night. Some kind of "don't use this template (do a full-out link instead, to get the symbol) when the link looks like one that might reasonably exist on THIS wiki" note is probably a good idea -- beyond that, it should work just fine. --StDoodle (#1059825) 10:16, 30 June 2010 (UTC)


Huh. Apparently this template doesn't quite work perfectly (see Bad_Moon#Special_Adventures vs. Bad_Moon#Special_Adventures). --Heeheehee 02:10, 25 July 2010 (UTC)

I noticed that. :( Sadly I couldn't figure out how to fix it. (Because of the special properties of the # character.) Do you have any idea?

Perhaps anchor as an optional (third?) parameter?
All right, well, I've got the links to not look all funky, but that didn't really resolve the problem. Generally not good. --Heeheehee 20:39, 25 July 2010 (UTC)
And... fixed. Bear in mind that you'll need to include the # character at the front of the anchor link, and you can {{ANCHOR_ENCODE}} the anchor if it'd take more effort to do that otherwise (demonstrated proper usage via one of the examples). --Heeheehee 03:39, 30 July 2010 (UTC)

That's too many revisions to go over, but did you try checking for a third parameter, and if present, running anchorencode on it and preceding with the hash mark? I would imagine it might be necessary to play with how the hash is added (perhaps as an html entity, perhaps something else). But hey, at least it works. However.... does it really save much time? If it's just to get rid of the external link mark, well... huh. --StDoodle (#1059825) 05:57, 30 July 2010 (UTC)

The template also saves a bit of time, I guess. An alternative to using ANCHOR_ENCODE is to convert it manually, which might take less time if it's something short like "Special_Adventures".
Preceding with a hash mark causes all sorts of errors that end up looking like: [kol.coldfront.net/thekolwiki/index.php/Bad_Moon
  1. Special_Adventures This piece of garbage]. (Yeah, I have no idea why it causes a line break.) Tried the HTML entity, nowiki tags, even having # as a template. All resulted in that piece of garbage. This was the only thing that really worked.
Further note: the whole reasoning behind the ifeq is that if an empty string is passed, it's not interpreted as no parameter, but rather the empty string. But yeah, I think I'm done messing around with this template. (The only way I can think of that would definitely work would be if we had fewyn set "$wgPFEnableStringFunctions = true;" in LocalSettings.php to enable StringFunctions so we could do more fiddly nonsense.) --Heeheehee 14:45, 30 July 2010 (UTC)