Template talk:Release
From Brickipedia, the LEGO Wiki
|
This is the talk page for discussing improvements to the Template Release. | ||
|---|---|---|
|
||
Flaw[edit source]
- Shouldn't 2016 be "to be released"? Eg, what if it's to be released in December? NovaHawk 03:28, 19 September 2016 (UTC)
- I'vve been thinking about that actually for the past few days of how to implement that, but I have an idea now :D What we could do now is make a 2nd parameter (that's optional) which accepts a month by a number, and then in the
#ifexprargument, we add another argument (with theandoperator) to also check if it's less than or equal to{{CURRENTMONTH1}}({{CURRENTMONTH}}is zero padded, aka 08 instead of 8). That should work, I'll try to implement it but parser functions in wiki markup aren't my cup of tea, meaning you might be able to do it faster than me. :P SamanthaNguyen (talk) 04:05, 19 September 2016 (UTC) - Edit: And then we'd basically do the same thing if we want to add a 3rd parameter for entering a day value, except it'd compare the value to
{{CURRENTDAY}}(there's also{{CURRENTDAY2}}, but that value is zero-padded, e.g 08 instead of 8). 04:09, 19 September 2016 (UTC)- Ahh.. so as you can see... for me the way that wiki markup has to be formatted, it gets pretty confusing and I managed to break it. (it'd be nicer if it could parse correctly if you put everything on a new line + tabs like in actual code files but you can't do that) can you take a try? :P SamanthaNguyen (talk) 04:26, 19 September 2016 (UTC)
- Sorry, probably should have gone more in-depth in case you started anything :P Basically, take Kabuki Twins - I've used that for the lead saying they'll be released in 2017. I don't have a clue when in 2017 they'll be released, but it'll read that they've already been released from January 1 onwards when they might not be released until May. Just saying I think it'd be safer for the same year to read "to be released" wouldn't it? I can fix it so if a month and day are specified it'll change like you mentioned as well though NovaHawk 05:09, 19 September 2016 (UTC)
- That's okay, don't worry about it. :P The goal of this template is to make it so the grammar maintenance is basically equivalent to 0 (or very close to 0 but maybe that's too idealistic?) and after thinking about it, making that default would help us reach that goal. :) Thanks in advance! SamanthaNguyen (talk) 05:24, 19 September 2016 (UTC)
- Edit: If you really want, you could do some magic to figure out whether or not if it's a leap year, detect if the month value is equivalent to 2, and check for the day value. If it isn't a leap year, the month val is 2, and the day value is equivalent to 29, you could throw an error back? That kinda seems like more work than necessary though, so you don't have to if you don't wanna. :P SamanthaNguyen (talk) 05:31, 19 September 2016 (UTC)
- What would that even accomplish though? :D If people start putting in September 57 then it's obviously going to be wrong :P Anyway, made it basically from {{future set}}, CJC had a much better way of doing it, but I tried {{future set/2}} out before copy/pasting that code and it wasn't working for me so I figured it'd be safer just to go with a way that I know works :S NovaHawk 06:16, 19 September 2016 (UTC)
- Hmm, nothing, good point. :P I tried reading the source code from each of the 3 templates but it still doesn't make sense to me, so all I can say is thank you for being a wiki markup genius and for making it work. Here's another cookie for your hard work! :P SamanthaNguyen (talk) 06:23, 19 September 2016 (UTC)
- What would that even accomplish though? :D If people start putting in September 57 then it's obviously going to be wrong :P Anyway, made it basically from {{future set}}, CJC had a much better way of doing it, but I tried {{future set/2}} out before copy/pasting that code and it wasn't working for me so I figured it'd be safer just to go with a way that I know works :S NovaHawk 06:16, 19 September 2016 (UTC)
- Sorry, probably should have gone more in-depth in case you started anything :P Basically, take Kabuki Twins - I've used that for the lead saying they'll be released in 2017. I don't have a clue when in 2017 they'll be released, but it'll read that they've already been released from January 1 onwards when they might not be released until May. Just saying I think it'd be safer for the same year to read "to be released" wouldn't it? I can fix it so if a month and day are specified it'll change like you mentioned as well though NovaHawk 05:09, 19 September 2016 (UTC)
- Ahh.. so as you can see... for me the way that wiki markup has to be formatted, it gets pretty confusing and I managed to break it. (it'd be nicer if it could parse correctly if you put everything on a new line + tabs like in actual code files but you can't do that) can you take a try? :P SamanthaNguyen (talk) 04:26, 19 September 2016 (UTC)
- I'vve been thinking about that actually for the past few days of how to implement that, but I have an idea now :D What we could do now is make a 2nd parameter (that's optional) which accepts a month by a number, and then in the
Usage[edit source]
Since the flaw has been fixed, shouldn't we be using it from now on for new articles created here on out? :P SamanthaNguyen (talk) 16:40, 16 October 2016 (UTC)
- (Shhh :P) Sorry, I'll try to remember it if we get any more info coming in NovaHawk 06:37, 17 October 2016 (UTC)
- That's fine, I was just wondering. :P SamanthaNguyen (talk)
New template for ignoring exceptions?[edit source]
- Is there a template we could create for bots to ignore exceptions such as those sets that were planned to be released in a certain year, but ended up never being released? 70153 Fang Trap is a good example. SamanthaNguyen (talk) 16:57, 30 October 2016 (UTC)
- Edit: We should also consider things that were going to be released in x, but was actually released in y. Part:12769 is an example, if we ever decide to run a bot? It might be a while, but I think it's something worth considering. SamanthaNguyen (talk) 19:29, 30 October 2016 (UTC)
- The way I understood it, this template was intended for pages about something that was currently unreleased so the text would auto-update when it was released, not as a replacement everywhere for a manually written sentence. If somethng was cancelled or delayed, the text could be changed to a manually written sentence (considering how rare cancellations are, I think we'd be on top of those). It also means I really don't understand changes like this- if a set's already been released why do we want that in a template since it's never going to change? Doesn't that just mean using more computing power (template vs. plain text) , a chance for a whole lot more pages to break if something goes wrong with the template itself and more casual users not being able to understand what's going on if they hit "edit" on a page? NovaHawk 21:37, 30 October 2016 (UTC)
- I agree with NovaHawk — using a template is computationally more expensive than just using plain text. Maybe not much, but still. The truth is, however, that we've definitely had issues with templates in the past (Template:ThemeTable comes to mind, for example) and I don't dare to say that we've absolutely gotten rid of every single template-related bug, so I'd be wary about intentionally introducing popular templates. If you think about a typical set page, it has already a lot of "moving parts" — and just like with software in general, the more moving parts, the harder it is to debug if and when things go south and the harder it is to generally understand what's going on. This might not be exactly as obvious with wikitext templates as it is with large projects like MediaWiki itself, but looking at the source code of this template, I doubt anyone could say that this is easier to understand than "X was released in ..." or "X will be released in ..."; one is plain English, the other is a spaghetti mess full of curly braces and other strange things. Consider the page 41069 Treasure's Day at the Pool, for example. Even without this template the page already has 32 templates, of which only three are protected. While I'm all for the "anyone can edit" slogan and the general open nature of wikis, it's a fact that templates provide a rather easy way to also vandalize multiple pages at once. With 32 templates, I'd argue it's relatively trivial to inject some nasty CSS or whatnot into one of those and leave the rest of us wondering into what's wrong with the set pages.
I'm not trying to say "you can't create any new templates ever because security", but IMO it's a good idea to also consider that aspect. --Jack Phoenix (talk) 02:58, 31 October 2016 (UTC)
- I agree with NovaHawk — using a template is computationally more expensive than just using plain text. Maybe not much, but still. The truth is, however, that we've definitely had issues with templates in the past (Template:ThemeTable comes to mind, for example) and I don't dare to say that we've absolutely gotten rid of every single template-related bug, so I'd be wary about intentionally introducing popular templates. If you think about a typical set page, it has already a lot of "moving parts" — and just like with software in general, the more moving parts, the harder it is to debug if and when things go south and the harder it is to generally understand what's going on. This might not be exactly as obvious with wikitext templates as it is with large projects like MediaWiki itself, but looking at the source code of this template, I doubt anyone could say that this is easier to understand than "X was released in ..." or "X will be released in ..."; one is plain English, the other is a spaghetti mess full of curly braces and other strange things. Consider the page 41069 Treasure's Day at the Pool, for example. Even without this template the page already has 32 templates, of which only three are protected. While I'm all for the "anyone can edit" slogan and the general open nature of wikis, it's a fact that templates provide a rather easy way to also vandalize multiple pages at once. With 32 templates, I'd argue it's relatively trivial to inject some nasty CSS or whatnot into one of those and leave the rest of us wondering into what's wrong with the set pages.
- The way I understood it, this template was intended for pages about something that was currently unreleased so the text would auto-update when it was released, not as a replacement everywhere for a manually written sentence. If somethng was cancelled or delayed, the text could be changed to a manually written sentence (considering how rare cancellations are, I think we'd be on top of those). It also means I really don't understand changes like this- if a set's already been released why do we want that in a template since it's never going to change? Doesn't that just mean using more computing power (template vs. plain text) , a chance for a whole lot more pages to break if something goes wrong with the template itself and more casual users not being able to understand what's going on if they hit "edit" on a page? NovaHawk 21:37, 30 October 2016 (UTC)
- Edit: We should also consider things that were going to be released in x, but was actually released in y. Part:12769 is an example, if we ever decide to run a bot? It might be a while, but I think it's something worth considering. SamanthaNguyen (talk) 19:29, 30 October 2016 (UTC)
Hey I read both of your comments and I thought about both then and you're re right, sorry about that! Ill change it back to how it was, and will temporarily self-assign bot rights so I don't flood the RC. Anyways thanks for pointing that out :) I'll ask next time I attempt on making a mass change like that (which I should've done in the first place) SamanthaNguyen (talk) 23:33, 1 November 2016 (UTC)
- Should be back to plain text now! Let me know if I missed anything and I'll try to change the ones that I missed to plain text ASAP :) SamanthaNguyen (talk) 00:29, 2 November 2016 (UTC)
