User talk:Dinoguy1000

Infobox character
Could you add a ko_trans_name in the Infobox character, since it not there. WinterNightmare (talk • contribs) 00:23, September 5, 2015 (UTC)


 * Done. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 03:48, September 5, 2015 (UTC)


 * Thanks. WinterNightmare (talk • contribs) 04:10, September 5, 2015 (UTC)

Mobile Editing Difficulties
Apologies if this isn't the right place to ask, but I can't seem to do any edits from my mobile device. I edit the code, but when I click "Publish" it always comes up with the message "Something went wrong." I'm clueless as to what's causing it and it's been happening for almost a month now, do you have any idea what's wrong? Sanokal K-T (talk • contribs) 09:09, September 23, 2015 (UTC)


 * Unfortunately not, since I never edit from mobile. Are your edits actually being saved, even though you get an error on trying to save, or is nothing at all working? In either case, the only thing that can be done here is to report the problem to staff. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 15:11, September 23, 2015 (UTC)


 * Nah, they're not saving. I click "Publish" and it pops up with the error message and grays "Publish" out and I'm unable to proceed.
 * All right, I'll just check with them. Thanks. Sanokal K-T (talk • contribs) 20:19, September 23, 2015 (UTC)

Affiliations
Hello! I'm from the FCB Wiki. I would like to request to be affiliated with your wiki. Here is our wordmark.

Thanks! J.J. Chambers 21:45, September 27, 2015 (UTC)

September 2012
I really don't want to start any fights or anything, but why did you undo my edit for the OCG's September 2012 Lists? I thought that, with the exception of the Japanese text I removed, would make it more presentable. --''' Yes, it's PSYCHID! He talks! He does stuff!''' 02:02, October 3, 2015 (UTC)


 * Bolding the changed cards is completely redundant to the "Changes" section. The practice of bolding is nothing more than a holdover from other websites that did the same thing without providing a concise summary of which cards were changed and how, as we do now.
 * The header level I'm a bit less certain about; while I currently lean towards the extra level being unnecessary, I don't feel particularly strongly about it and could be swayed in the other direction.
 * Also, to expand on the topic of Japanese names/text and the lists while I have your attention, it's not necessary to have Japanese card names on the TCG-only lists, since by their very nature they don't/didn't apply in Japan. I haven't gone through the lists systematically to remove them all yet, but I think I've done one or two; if you start working on the TCG lists some time down the line, though, feel free to remove them as you go. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 04:53, October 3, 2015 (UTC)


 * While your reason may make sense, I kind of like doing these lists the way I usually do them (though most recently, I've removed the Japanese text from the headers on both the OCG and TCG-exclusive Lists), mostly because bolding the changes would be easier to notice. Frankly, I blame myself; old habits are hard to break.
 * But in your honest opinion, should I remove the Japanese kanji from the TCG-exclusive Lists? -- Yes, it's PSYCHID! He talks! He does stuff! 04:07, October 4, 2015 (UTC)


 * Are you saying you'd prefer to keep the bolding, then, or just commenting on how you're used to it? Your comment kind of reads both ways, so it's not really clear. =X
 * It should be removed, but it's not critical - it doesn't really hurt anything by being there, it's just superfluous information, which is why I didn't say you had to remove it as you went. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 15:51, October 4, 2015 (UTC)


 * It's moreover a bit of both: Something I prefer to keep, and something I'm used to. But I think I'll remove the Japanese names from the TCG-exclusive lists, if you think it best. -- Yes, it's PSYCHID! He talks!  He does stuff! 01:19, October 5, 2015 (UTC)


 * Can you give any good arguments for keeping the bolding? As I said originally, it's redundant to the "Changes" table, which unambiguously shows which cards changed status and provides more detail. In addition, it's completely unnecessary for the "Unlimited" section, since we only list cards that were changed to Unlimited and therefore all of the cards listed there have changed status; if, because of this, we stopped bolding the cards listed there, but continued bolding them under the other headers, that would be inconsistent and potentially confusing. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 05:59, October 5, 2015 (UTC)


 * Okay, I'll remove all the unnecessary bolding. But should I remove the Japanese names from the TCG-exclusive Lists, too? -- Yes, it's PSYCHID! He talks!  He does stuff! 17:11, October 7, 2015 (UTC)


 * Yeah. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 22:26, October 8, 2015 (UTC)

RE:Adminship
Thanks. ^^ LegendaryAsariUgetsu (talk • contribs) 14:01, October 4, 2015 (UTC)

Template:Sacred
What happened to the "sacred card" archetype thing? The one that listed the Egyptian gods, Exodia, Signer Dragons etc?

Felix —This unsigned comment was made by NervousShipper (talk • contribs) 06:57, October 9, 2015‎

I think you're talking about Sacred, which was deleted a couple years ago (by me, though I'd forgotten I did that). All it was was a list of monster groups without any clear connection, just a vague sense of "these are really powerful". If you need the list for some reason, I can provide it to you, but the template won't be getting restored without some very good reasons. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 06:48, October 10, 2015 (UTC)

Portable infoboxes
Heya :) I see you worked with DaNASCAT back in late July to try to work out a way to use portable infobox code here at Yu-Gi-Oh! Since development stopped soon after the last comment at Forum:Portable Infoboxes, I was just wondering if there were any problems that you couldn't figure out. We've made a lot of changes to the portable infobox code since the summer, so it may well be that you'll find making a second run at Template:Infobox/Draft will be easier than you remember.

I'll just point out, as well, that the time you stopped working on portable infoboxes was the high-water mark for mobile uniques here. On 1 August you had nearly a million uniques on mobile devices. That number is now about ~750k — a pretty big slide of around 25%. We think a part of this decrease can be attributed to pages that start with infoboxes that aren't really adequate to the mobile experience. People whose first browse of YGO reveals a somewhat unattractive infobox at the top of a page may well not be inclined to continue looking at the wiki.

Happily, we're in a really good period of development with infoboxes! We have established robust lines of communication with our core engineers. If we hit roadblocks, we'll therefore be able to get quick answers from the people who are actually developing our backend code!

So please don't hesitate to ask any questions at all! I think we'll be able to make some real progress with genuine speed. — CzechOut 17:29, October 20, 2015 (UTC)


 * I have to be honest, I more-or-less ran out of steam after the last comment in that forum thread, when I stopped receiving feedback and realized I would be working on the port basically on my own (not that I'm blaming Tim for that or anything; I don't do anything compared to how much he does =D ). At the time, I had three major concerns with PI: proper support for inline styles and classes on individual parts of infoboxes, an ability to work with PI via Lua, and an ability to emulate the child navbox behavior from our current Infobox using PI (which sufficiently robust interaction with Lua would allow to be addressed). As I mentioned in the forum thread several times, what I really want to be able to achieve with PI is to only do one conversion ever - Infobox itself - and then just continue to work on converting our individual infoboxes to using Infobox as a metatemplate. I do not, for example, have any desire to try to switch Infobox character from using Infobox as a metatemplate to directly using PI; it would be far simpler to allow it to continue using Infobox, and just convert Infobox directly, so that Infobox character automatically gets converted with minimal or no changes required to it (I believe this simplifies everything in the long run: because all the logic on whether and when to show a particular cell happens in Infobox character, and Infobox just displays whatever it's given for a particular cell, it means the meat of the processing can happen in Infobox character and whatever values fall out of that get handed straight back to Infobox, which plunks them right into the PI markup, and no one has to worry about how the various parser functions interact with the PI markup, since they've all already resolved; in addition, any such solution we develop here should be broadly applicable across much of the rest of Wikia (with or without some further simplification to remove features that only we and a scant few other wikis use), greatly simplifying infobox development efforts in the long run).
 * One thing I would like to see is the HTML tags that PI uses added to the parser's whitelist (looking at Help:Infoboxes/Tags, I think the necessary tags would just be,  ,  ,   (which appears to be whitelisted but seems to currently just be silently stripped by the parser outside of tables) and  ) - there's a Phabricator ticket for them and a number of other HTML5 tags to be added to the whitelist in vanilla MediaWiki, with the blocker being IE≤8 support, but I'm not sure how much of a concern that is for Wikia, especially given PI is using the tags. This would allow for work on PI-compatible templates and modules without being limited to whatever the PI markup actually plays nice with (though, because the HTML would be hardcoded, it would mean that future changes to the HTML underlying PI's markup would have to be manually applied, so that wouldn't be a general solution for most wikis).
 * While I won't argue that our infoboxes are contributing to the drop in mobile traffic, they're definitely not the whole picture, as you hinted at yourself. I suspect that a bigger reason for the drop is our current implementation of CardTable2, which is just a single huge table. It's due to be replaced eventually by the Card table system, but there's a huge amount of work that has to be done before we're at that point and it's going to take a long time to get there. In the meantime, I've toyed with the idea of changing CT2 to instead use divs for everything but the actual data part, but haven't tried switching it yet because I'm a bit leery of the CSS work it would require. But I'd be willing to bet that even that small of a change now would help to recapture some of the lost mobile traffic over the long term (not to mention it should also slightly reduce the amount of markup CT2 generates).
 * I'm quite certain I managed to talk a lot here without actually giving many satisfactory answers, though, so please ask me to clarify or explain anything you might need. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:31, October 21, 2015 (UTC)


 * Hey man! I just wanted to touch bases and let you know that you have not been forgotten. I was just working on your ticket today.  Unfortunately, our guys in Poland got hella busy back in late October, and they just ran out of time before they could help you out.  While I and some other people can help you build infoboxes, I'm particularly intrigued by your question about adding to the parser's whitelist.  This seems an important observation to me, and something we definitely want to get an answer from Engineering about, since it is not within my personal power to actually make such a change.


 * So that question has been pushed again to them. I'm hoping for an answer soon on that. Their next window of availability comes somewhere after about the 7th of December, so hopefully we'll get an answer on that front before Christmas. But understand that we've never done this kind of direct outreach of engineers to communities before, so it's possible that our reach might exceed our grasp, just as it did in October. If so, don't hesitate to reach out to me and ask me what the hell is going on. :)  See, the problem is that you and other power users like you are so damned smart that we end up spending so much time with each community that our schedule gets absolutely destroyed!


 * On other matters in your above post, if you had some specific questions about Lua/PI interaction, I could pass them on to our engineering staff. In the meantime, I encourage you to visit w:c:portability, if you haven't already. There, in the forums, you'll find a group of power users like yourself debating matters of Lua/PI interaction. They've found some highly intriguing solutions that might well interest you.


 * Finally, on the issue of a meta-template like infobox, I'm going to propose something that might not immediately strike you as sensible. Because PI coding is comparatively simple, there is no real need for the -ed out meta template anymore.  The faster route to success is really the opposite of what you'd do with traditional infobox coding.  We actively recommend that you just break up your meta template into separate, specific templates.  It's genuinely faster, easier and lighter on page load times. — CzechOut 02:36, November 19, 2015 (UTC)


 * If you'd like my opinion on the topic of whitelisted HTML, I think it's probably best for new features to try to stick with what's already on the whitelist, and if a new feature really needs to use a non-whitelisted tag for whatever reason, to take a good look at whether there's any reason to not just whitelist that tag as well. I understand it's out of your say, but you should at least be able to float the idea around a bit. =)


 * Seeing you say that got me curious, and I checked whether we're contacts on Skype. Turns out, not only are we, but we've discussed infoboxes a bit in the past! If I'm remembering the context correctly from the CC Skype group, I'd been bemoaning the lack of a Wikia-supported metatemplate, instead requiring everyone to work with raw wikitables; you then messaged me to encourage me to develop one and write a blog post about it. =)


 * I was aware of the portability wiki, but haven't been keeping up with the discussions there; I'll have to take a look at them and see what's been going on.


 * That's actually kind of what our Infobox already does: each of the rows uses Infobox/row for the actual rendering, which vastly cuts down the amount of code required in Infobox itself (especially given there's 80 rows supported). I'm also no stranger to the idea of using a modular metatemplate system; our older infoboxes use a system developed by Dantman back in 2007 or 2008 (I'm not sure of the exact dates since IIRC the system was developed on another wiki that no longer exists, and was ported to a number of different anime/manga wikis as part of a long-defunct collaboration that said wiki served as the hub for), and when I was active on Wikipedia, I helped to maintain and develop new features for the animanga infobox, which is also modular (though not a metatemplate). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 18:51, November 22, 2015 (UTC)
 * Heya :) I sent your whitelisting opinions skyward on Monday, and they're being discussed internally. Obviously US Thanksgiving is getting somewhat in the way of full discussion this week, but hopefully I'll have something to report back next week.


 * On the matter of having something like a central infobox that then #switch-es its way into more specific infoboxes, or even specific instances that leverage the power of meta infoboxes (however people wanna play that), you're absolutely right to remember discussions we had earlier in the decade about that. Indeed, I think such things make a lot of sense — for the old way of doing infoboxes.


 * However, in the current PI system, it's massively easier to steer clear of all that. The major strategy of the old school wikitext meta-infobox was to basically make it so all of one's code complexity was within a single infobox, like infobox.  The specific infoboxes could then be super simple, because all they had to do was call infobox.


 * Since PIs have #if structures inherent, as well as a number of other automatic features, it's less work to ignore infobox and just build new infoboxes. After completing a couple of PIs, one finds that the exercise becomes no more difficult than just cutting and pasting one's successfully rebuilt PIs. And let's face it, that's pretty much all one was doing in the meta infobox era, anyway.  One grabbed the code of the, say, character infobox and plopped it onto the location infobox, and then one changed the variables as necessary.


 * I'm not speaking theoretically here. I've been working on the Fallout Wiki a lot this past week, and that's exactly what I've done. Cutting infobox out of the action hasn't been painful or controversial, really. And I find that the code is generally pretty easy to read — certainly less dense than what you'd find in something like infobox.


 * Moreover, our engineering department is, at the moment, very easily swayed by the opinions of early adopters. So when you find something that doesn't work, sending in a Special:Contact — or talking to me and having me ticket it directly — actually does produce results.  The answer is sometimes "no", of course, but we're actively soliciting and answering feedback in a way that I've never seen in all the time I've been using the Wikia platform. And that goes all the way back to the beginning, really.


 * So, all of this is to say that, while I was a strong proponent of the meta infobox solution a few years ago, I pretty much see it as unnecessary today. Speaking as an admin, and not as staff, I'd find it particularly objectionable to continue with a system whose history was as murky as the one your older templates currently use.  Switching to PI code means that you'll know the exact origins of the code, and you'll be able to provide maintenance delivered with full knowledge of the history of the code.


 * Just stuff to chew on. Get it? Thanksgiving. Chewing.  Ugh.  Finding puns around Thanksgiving is easy.  Finding good ones is as difficult as finding live turkeys.  — CzechOut 15:41, November 25, 2015 (UTC)


 * Oh! Almost forgot. I just wanted to get some clarity on card table situation. I read your earlier statements as effectively saying that development on PIs was impossible without resolving the transition to card table. Was I right to have done so?  Or could we possibly divorce the two things?  That is, could we switch to PIs, leaving the card table component out of them until it can get resolved.  And could you please better define the work that's necessary to make the transition? — CzechOut 15:51, November 25, 2015 (UTC)


 * While simplifying markup is one reason for using templates, they are used to centralise code. If an update, such as now, is necessary, is it not just as well to only have to change one thing?
 * Regarding metatemplates' parsers taking a toll on load times, infobox uses  zero times, but does use   a lot. Although, wouldn't it use considerably less, if switched to using portable infobox markup? -- Deltaneos (talk) 21:58, November 25, 2015 (UTC)


 * I think this is something we're going to just have to disagree on; I simply can't imagine a scenario where things are made easier by not using a metatemplate where one was previously used (that is not to say there aren't other reasons not to use metatemplates in specific cases, but it's a case-by-case thing and, in my experience, ease of editing never works out to be in favor of such a switch). This is not necessarily a deal-breaker for me, and the rest of the community may in fact disagree with me on its importance, but as things stand now I don't see PI having enough benefit to outweigh the downside of loss of a metatemplate.
 * I also disagree with your comparison of reading PI infoboxes with reading Infobox; that is comparing article-editor-facing templates with a template-editor-facing template, and is not at all a fair comparison to make. Infobox by its nature is not meant to be edited regularly, since it has been rigorously tested via Wikipedia (meaning having to fix bugs should be a rare to nonexistent occurrence), is thoroughly documented (meaning editors should rarely if ever have to actually read its code to find out how to do something or why the template is or isn't doing what they want), and has a robust feature set that can support the vast majority of infobox requirements (meaning edits to add needed features should be rare); this is borne out by its [ edit history] here, which consists of updating the template from Wikipedia's copy and fixing a single bug that doesn't occur on WP because of their use of HTML Tidy. By comparison, individual infoboxes are far more likely to be edited by people who are far less familiar with the obscure intricacies of wikimarkup, for any of the three reasons I outlined already, and when that happens they shouldn't have to worry about navigating through the code responsible for displaying the infobox itself in order to understand the code that handles the information the infobox is menat to display.
 * I may have confused you with my mention of our older infoboxes, and for that I apologize; I was not trying to suggest we are wanting to continue using them indefinitely, and in fact we have been working (gradually) on replacing them with infobox-based templates for some time now. I am right there with you in having little desire to use a system with a hazy history, especially when we have an alternate system which is pretty clearly superior.
 * Same for my comments on Card table: I'm definitely not suggesting that we can't do anything with PI until we get that sorted. PI and the card tables are entirely separate from each other, in fact, and it would be inappropriate to try and use PI for them, unless we wanted to completely restructure how our card pages work to begin with (and maybe we will at some point in the future, but I don't think anyone wants to do something that drastic at this point). What I was saying is that our card articles, most of which currently use CardTable2, undoubtedly account for a significant portion of our traffic, both on desktop and mobile, and that therefore improving that situation might have a better immediate return on investment than our infoboxes. However, updating that is somewhat slow going because we're not just updating existing templates, but writing entirely new ones and splitting pages as we go, and the final updating of CardTable2 to a card table-based replacement will be one of the final steps of the whole thing. I do have some ideas for further improvements to the new system, which among other things should make it more mobile-friendly, I just haven't taken the time to prototype them (but among them are a replacement for the current Tabber system which would allow mobile devices to only download one tab's worth of content (but which would require some custom JS to actually function, which is what's been putting me off of actually trying it out), and some ruminations on using a definition list instead of a table for the information shown alongside the image). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 00:59, November 30, 2015 (UTC)

Removal of Anime Lore
I have a question Dinoguy1000. Why exactly do you remove the anime lore of each card under your Dinobot1000 account?

It should be noted, that the anime effects are interresting trivia as well as giving insight, why the cards in question needed to be nerfed in question for the OCG/TCG.

As such the anime lore should be moved to either a different section or to their own pages.

Also, there are players, which make use of the anime lore for DevPRO/YGOPRO and DuelNetwork for their own duels. Thus their existence is also a boon for players, which can experience what the anime originals feel like. Thanatos-Zero (talk • contribs) 12:53, October 24, 2015 (UTC)
 * Nevermind this entry. I just found the anime pages. They weren't as visible as I hoped to be. Thanatos-Zero (talk • contribs) 13:18, October 24, 2015 (UTC)


 * If you have suggestions for improving their visibility, I'd love to hear them! That's a known problem, but we're short on ideas for how to improve the situation, unfortunately. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 13:52, October 24, 2015 (UTC)


 * There is one. We can add at the top following sentence: "If you are looking for the card with the anime effects go here "Name of the Card (Anime)"."Thanatos-Zero (talk • contribs) 16:50, October 24, 2015 (UTC)


 * That doesn't scale, though; some cards have a number of articles covering a specific version, and that number is only going to increase. For example, Dark Magician currently has pages for its manga, Toei anime, NAS anime, DDM anime, Bandai, Bandai Sealdass, Labyrinth Battle Game, Forbidden Memories, Duelists of the Roses, and BAM versions, and there will be additional pages created in the future as we continue to split out individual release types from CardTable2.
 * There may be a case to be made for calling specific attention to "major" or very important versions of a card, but in that case we have the problem of deciding what the threshold for "major"/"important" is. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 17:54, October 24, 2015 (UTC)

Asian Tournament Promos: 2001
If you believe these cards are counterfeit, I urge you to provide proof for that statement (since Kevin Tewart hasn't done so). If these cards are fake what were the original prizes for that tournament? Thanks Fensterhoff (talk • contribs) 21:39, November 1, 2015 (UTC)


 * I think you're confusing acknowledgment with agreement. He said that Tewart claimed the cards were fake. He didn't say the cards are fake. The Wikipedia article on Hitler acknowledges that he believed the Holocaust victims were socially undesirable sub humans. That doesn't mean it's saying he was right. -- Deltaneos (talk) 22:19, November 1, 2015 (UTC)


 * I don't know why you brought Hitler in this conversation, it's not like he is a trusted public figure who people listen to in our time. The facts are that Mr. Tewart hadn't provided any proof. And if there is no proof then I don't see why should this information even belong on that Wikia page misleading people (because people take his word for granted). There is a separate page for what Kevin Tewart had claimed for anybody who cares what he says: http://yugioh.wikia.com/wiki/Kevin_Tewart Fensterhoff (talk • contribs) 22:55, November 1, 2015 (UTC)


 * As Delt said. My personal position is that I simply don't know enough to draw a conclusion for myself whether the cards are fake or not. This doesn't change the fact that Tewart has publicly stated they're fake, and that he did so while acting as a representative of Konami. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 22:35, November 1, 2015 (UTC)


 * I understand what your position is, but what I don't understand is why should we further mislead people to believe a statement that is not proven to be true? Isn't the purpose of this community to form a realistic perception? Because what I see has the exact opposite effect. Thanks Fensterhoff (talk • contribs) 22:55, November 1, 2015 (UTC)


 * As written, the statement is perfectly clear that it's something that Tewart said and not necessarily objectively true by itself. If someone really doesn't understand that the phrase "[person] said that [thing]" means, literally, that the person said a thing, and that thing may not necessarily be true even though the person said it, it's their problem and not ours. As it is, Tewart's role in relation to the franchise, and the content and context of his statement, mean it is fully appropriate to make note of it there. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 23:35, November 1, 2015 (UTC)

Egyptian God
Sorry about that, I didn't realize that I'd zapped yours off the page. Sanokal K-T (talk • contribs) 02:09, November 3, 2015 (UTC)


 * Not a problem, it's not like it was a complicated edit or anything. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 03:22, November 3, 2015 (UTC)

Vandalism report
Hi, I would like to report vandalism by this user.

Regards, -- Memmon ( talk ) (report) 20:04, December 11, 2015 (UTC)


 * Completed by Jr Mime -- Memmon ( talk ) (report) 21:17, December 11, 2015 (UTC)

Hide Factbox
Hey Dinoguy,

Thank you so much for your explanation. Initially, I wasn't sure what its purpose was; although I assumed that it did serve a purpose on some pages. Anyway, I'll be sure not touch them just in case. Thanks again for your help, =) --ToonPegasus (talk • contribs) 01:00, December 27, 2015 (UTC)