User talk:Chieftain Alex/sandbox3

I personally like proposal 2 as it keeps the separate notices and it gives more context to historical flag (If I understand correctly). I have a few questions/concerns/clarification needed.

1. They may be a lot of Living World content coming soon that will be permanent content. My understanding is that this will only trigger if the historical flag is set in some way. Is that correct.
   1. If the above is true then we will still need in some cases to manually update the pages to set the historical flag. Other cases that may not be the case as we will know what is temporary and what is not. Either because we are told or it's context told us so. If we figure it out that it is temporary by the next patch we can easily be done run a bot at the end and we would exclude items that stayed in game and flag everything else correctly.
2. How does this handle seasonal content or festival content that may appear at any time?
3. The biggest problem with temporary content is that it shows up in the {{area events}} and {{Vendor list}} searchers. If we want to display historical information then we can simply make another query (or change the templates) to show historical. Will this proposal solve this problem?

End of comments for now. Anzenketh (talk) 18:41, 4 June 2014 (UTC)

My main issue with the current setup is that each infobox generally has a slightly different set of coding for the historical parameter and display of {{historical content}}. This annoys me for no reason, but I intend to correct that, either by using a template to produce the historical logic, or copying the logic across every infobox.

Content introduced permanently should not be using {{temporary}}, which means that the only things with that template should be:

1. Current content introduced with last release (not historical)
2. Content released with older releases that is no longer present (historical) and will not return
3. Content released with older releases that is no longer present (historical) and will return

We don't use many dynamic queries (smw) involving temporary content, but the stuff that springs to mind are events. There are cases where I'd like to query for events that took place in a particular release.

Whatever conclusion I reach at the bottom of the page will be the one I go for. -Chieftain Alex 18:56, 4 June 2014 (UTC)

We don't use many dynamic queries (SMW) involving temporary content many because we don't use dynamic queries as much as we possibly should. The acquisition section for the majority of items needs to be updated. SMW was not around when the game first launched(as I am sure you are aware) so the majority of pages are not set-up to use those queries where they should. {{area events}} and {{vendor list}} (Maybe there should be one for dropped by but that gets complicated fast) are steps in the right direction. There are places to where I would like to query for events that took place in a particular release. There are places where vendors disappear and re-appear later(even in historical content) Festival Rewards Vendor. There are times that a reader may be interested on how a specific item was obtained but the vendor is historical and the item is not. There are other times where a reader may be interested on where can I get the content now. I do agree that the auto-categorization(to some degree) and historical flag need to be standardized across all infoboxes. I think they should be included by a template. Similar to {{Infobox location}} Anzenketh (talk) 19:26, 4 June 2014 (UTC)

though functionally good, {{vendor list}} is pretty icky in terms of formatting and I'd avoid it. :P -Chieftain Alex 19:53, 4 June 2014 (UTC)

But the solution to the formatting will eventually be fixed so we will need to use it for that in the future. Listing items being sold using a SMW format(Whatever that may be) should be done in most cases. Personally I don't like it either I think location should be by the item name and cost should be to the most right. But that is a discussion for thread.Anzenketh (talk) 20:02, 4 June 2014 (UTC)

Proposal

User:Relyk/sandbox/availability on what we need tagged and the implementation.--Relyk ~ talk < 20:53, 4 June 2014 (UTC)

good work. We need to update non-recurring living world content to be historical then? -86.154.221.33 23:38, 4 June 2014 (UTC)

I think they do need to be flagged as historical as they are historical. But I don't feel that {{historical content}} is the best template for them. Nor do I feel that there should be two notices {{historical content}} and {{temporary}} mostly because the notices are redundant if both displays. One provides better information and gives context to the reader before even starting to read the article. I feel that is important. Anzenketh (talk) 00:11, 6 June 2014 (UTC)

(Reset indent)

The more I think about this the less I like the property. I can't think of a query where I'd want to only pick up current (non-discontinued) content. We can query based on the category in any other cases, e.g. {{#ask: [[Category:Discontinued items]] }}.

In terms of parameter names, "availability" is also more awkward to type than "historical". I would prefer a different + shorter name for the parameter... e.g. "status".

I'm moving to London on Sunday, so I've got a few days to clean up this mess I've made, I just want to make sure its not a massive fuckup. -Chieftain Alex 13:24, 12 June 2014 (UTC)

I like the idea of renaming the property to status. I also find typing in the full name for status to be a bit annoying. As for finding a query to where we can only pick up current non-discontinued/historical content I can think of plenty of situations where that is the case {{{NPC service list}},{{vendor list}}, and the profession trainer pages. However besides for cleanup and origination I can not think of a query where I would want to search for current and discontinued or current and historical. To me a elements of the game are either available freely, have limited availability(discontinued content), or not available. To me the problem was never the SMW flag itself(besides perhaps the wording) The problem was the notification that was appearing at the top of the page. {{Historical content}} as it was worded before did not accurately describe Living World content that is no longer available. That template has been re-worded so that is no longer the case. However {{Historical content}} does not accurately describe seasonal, limited availability items, future, and unimplemented content. I think property status should have three options available, limited, removed. However there are more then 3 templates and categories for content that may apply so the logic needs to be more then just SMW logic. Anzenketh (talk) 14:20, 12 June 2014 (UTC)

Historical temporary content

"Temporary only for current content + recurring content. Historically temporary content will be demoted to use {{historical content}}." I do not agree that historical temporary content should be using the {{historical content}} template. I do not have time to explain I will expound on this later. Anzenketh (talk) 14:31, 5 June 2014 (UTC)

I think there are the following types of content. Permanent, Recurring, Discontinued, Historical, and Living world historical. I think that historical and living world historical need to be handled differently. Mainly I feel that the release on living world historical should be noted inside of the template that gives the notice on when it was available. Historical to me is content that was removed from the game as it was replaced with another feature or deemed to be not worth continued development on. I also think that there should be one notice at the top not multiple. Anzenketh (talk) 23:50, 5 June 2014 (UTC)

Why don't we need to filter out seasonal stuff

I can see the need to filter out seasonal stuff. I don't think it is still current if it is not a release that the seasonal event is running. Anzenketh (talk) 13:05, 13 June 2014 (UTC)

Its the same, and isn't even equivalent + breaks stuff.

Yes that is because you are not flagging it as historical SMW query or you are not searching for it to be excluded in the SMW queries. What you are still working on is still useful however for different reasons that you expect. Please read other notes I placed on the talk page for the reason why. Anzenketh (talk) 13:08, 13 June 2014 (UTC)

Change paramiter name

I show that you are adding the parameter Is historical to future and unimplemented. Should we change the parameter name to Is Available? Anzenketh (talk) 16:53, 13 June 2014 (UTC)

the property name, not parameter name. That would make it more sensible based on what its used for yes, but even I can't find a list of everything that queries based on "Is historical" to update it. I'm going to leave everything intact for the time being. Work starts on Monday, moving to London on Sunday.. this is basically my final set of bulk edits for a while. -Chieftain Alex 17:35, 13 June 2014 (UTC)

No way to convert a string, e.g. "A=1;B=2;C=3" into "A=1|B=2|C=3" in such a way that it will be correctly read as 3 parameters by a template?

^ . Oh man. -Chieftain Alex 17:27, 1 February 2015 (UTC)

Special:UnusedProperties

So I "managed" to add a bogus property to Special:UnusedProperties successfully ("Page alpha, +Page beta"). The + sign is naturally removed when you follow the link to the properties page. Now to figure out what is required to remove it. -Chieftain Alex 17:46, 2 September 2016 (UTC)

skill infobox

blockquote.skill-description {
  box-shadow: 0px 0px 7px 2px rgba(0,0,0,0.3);
  border: 1px solid #AAA;
  border-radius: 5px;
  display: inline-block;
  width: auto;
  position: relative;
}

blockquote.skill-description > * {
  width: 100%;
}

blockquote.skill-description .statistics {
  text-align: right;
}

hard to make statistics not look like crap. -Chieftain Alex 17:25, 1 May 2023 (UTC)