User talk:Dinoguy1000

From Yugipedia
Revision as of 17:54, 10 February 2016 by Dinoguy1000 (talk | contribs) (Infobox Set: reply)
Jump to: navigation, search

Infobox character

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

Done. =) ディノ千?!? · ☎ Dinoguy1000 03:48, September 5, 2015 (UTC)
Thanks. WinterNightmare (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 <staff /> 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 aside, figure, figcaption, caption (which appears to be whitelisted but seems to currently just be silently stripped by the parser outside of tables) and nav) - 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 {{#switch}}-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 <staff /> 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 <staff /> 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 <staff /> 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 #switch: zero times, but does use #if: 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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#Second National Conference

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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 01:00, December 27, 2015 (UTC)

List "Template"

Hi Dino! I tried to use your template for creating Lists. I created this page, but it was a bit messy at first. For instance, Yang Zing Unleashed is a Continuous Trap, so it appeared Trap Card, Continuous Trap Card instead of only Continuous Trap Card. Did I do something wrong, or is this a problem with the template itself? Pendulum (talkcontribs) 14:28, January 15, 2016 (UTC)

It's a problem with the template, kind of; I'll have to do some work to make it work better. ディノ千?!? · ☎ Dinoguy1000 17:21, January 15, 2016 (UTC)
So, should I use the template nevertheless, or could I, say, copy the already existing SP NECH list and change the SP to FR and adapt it to create the FR NECH list? Is there any problem if I do that? I know the title would be a bit different than with your template, though. Pendulum (talkcontribs) 18:16, January 15, 2016 (UTC)
Copying should be fine, as long as you make sure to update all the relevant bits (for example, you'll also have to make sure you change the category from e.g. Spanish to French). As for the template itself, I should be able to look at getting it straightened out sometime in the next couple of days. ディノ千?!? · ☎ Dinoguy1000 06:26, January 16, 2016 (UTC)
Ok, thank you, Dino! Pendulum (talkcontribs) 09:40, January 16, 2016 (UTC)

Red Links on Lists

Hey. There are some red links on this page, leading to some deleted card galleries, apparently. Don't know if this is the best way to call the attention to them, but don't know how I should proceed and you seem to be here now. Pendulum (talkcontribs) 23:10, January 17, 2016 (UTC)

I've gotten both of the redlinks I saw; let me know if you spot any others anywhere. =) ディノ千?!? · ☎ Dinoguy1000 01:22, January 18, 2016 (UTC)
Sure! Thank you very much. Pendulum (talkcontribs) 11:35, January 18, 2016 (UTC)

Set Card Galleries/Lists Headers

Hi! I have a question: How should the headers/titles be presented?
Should they be:

Set name in region language with hyperlink
Region language (- Edition, in case of galleries)


Or:

Set name in English with hyperlink
Set name in region language without hyperlink

Region language (- Edition, in case of galleries)


I've seen both being used. I'm aware your Templates use the latter, but I've seen other users (including myself) updating old galleries/lists using the former, so I'm a bit confused with the one that should be used, because I don't like some pages using one and other using the other.
So, which one is preferred and should be used? Personally, I like the second one the most. It may have one more line, but the Wiki is majority in English. The names of the cards are in English and then, below it, have the name in their own language, so I think the second option makes more sense. It's more in agreement with the rest of the Wiki. It also prevents people from clicking on a link they can't be exactly sure what it means. Though maybe the font for the second line could be a bit smaller than 120%.
Here are two examples, respectively: Astral Pack Six French Gallery; Astral Pack Seven French Gallery.
Hope I made myself clear; English is not my first language. Thank you for your time! Pendulum (talkcontribs) 12:39, January 22, 2016 (UTC)

The second version (the one the boilerplate uses) is the one that's supposed to be used. The boilerplate represents the current preferred version, and when a template is eventually created to automatically format set galleries/lists (something I should really take care of already), it will be based on the boilerplate.
Good point on the font size of the localized name; would having it be the same size as the third line be acceptable, or did you have a different size in mind?
Don't worry, you're perfectly understandable. =) Out of curiosity, what is your native language, though? ディノ千?!? · ☎ Dinoguy1000 20:47, January 22, 2016 (UTC)
Ok, I'll update everything I see to that version, when I have the time, then.
I tried at 110%, but it was still too big, I'd say. The same size as the third line seems fine. But maybe in bold too, because the italics makes it seem too thin, I think. Well, it would be interesting to see other people's opinions too.
My native language is Portuguese.
And thanks for your answer, Dino! Pendulum (talkcontribs) 21:28, January 22, 2016 (UTC)
Okay, I'll reduce the text size to 100%.
I'm a little bit worried about bolding Japanese, Korean, and Chinese names, but maybe that's just me. They don't (or at least shouldn't) get italicized, so that helps some, at least. Guess I'll just go with it and we'll see how it turns out.
Cool, we definitely need more Portuguese editors. =) If you aren't already, is there any chance you could work some on checking/adding Portuguese card names and lores? Since Konami's card database doesn't list Portuguese releases (hopefully it will eventually), we don't really have any source for them other than card images, and it's a lot slower for someone who doesn't speak/read Portuguese to copy them than for someone who does. (Also, if you're interested, there's a Portuguese wiki that could use some more attention, too.) ディノ千?!? · ☎ Dinoguy1000 22:13, January 22, 2016 (UTC)
Oh, I'm not aware of those technical difficulties. Yeah, there's nothing like experimenting. You're the man here, you know what's best.
What do you mean exactly with adding Portuguese card names and lores? You mean find official ones and add them only, or also translate them and add the {{Unofficial name|Region}} tag? Because I could try to translate them, but having official ones is hard for me too, since I don't buy Portuguese cards nor I have any ones. Ah, thanks for that link. I'm a bit busy at the moment to spend too much time around the Wikis, though. But I'll try to give a hand whenever I can! Pendulum (talkcontribs) 23:13, January 22, 2016 (UTC)
Preferably official names/lores, since we're still missing a fair few of both, though if it would be a problem for you, don't worry about it too much (it's not like I'm in any position to demand others do work around here, after all =D ). ディノ千?!? · ☎ Dinoguy1000 02:35, January 23, 2016 (UTC)
Hahah! Ok, I'll see what I can do. Thanks again! Pendulum (talkcontribs) 11:43, January 23, 2016 (UTC)
Just to let you know I updated the DUEA galleries/lists and it seems the Japanese/Korean names do get italicized. Pendulum (talkcontribs) 14:04, January 23, 2016 (UTC)
It looks like you're using an older version of the boilerplate; be sure you copy from the latest version. If you're using the right version, the language codes used in {{Card table}} should be lowercase (e.g. "en", "fr", etc.) instead of upper case (e.g. "EN", "FR", etc.). ディノ千?!? · ☎ Dinoguy1000 21:04, January 23, 2016 (UTC)
Oh, oopsie. Ok, thanks for pointing it out. Pendulum (talkcontribs) 21:43, January 23, 2016 (UTC)

Ebon Magician Curran summoning

Hi, I'm new to Yugioh wika and I'm hoping to find an answer as to whether or not the effect of Ebon Illusion Magician can special summon Gemini spellcasters that are in the graveyard as they are considered to be "normal monsters" when there? --CobraC13 (talkcontribs) 23:45, January 22, 2016 (UTC)

Welcome to the wiki, CobraC13~ Unfortunately, I'm not the person to ask for rulings-related questions, as I don't play the game myself and thus my understanding of some of the mechanics is shaky at best. If you haven't already, though, see if any of the rulings on Card Rulings:Ebon Magician Curran are relevant to your question, and if that doesn't help, try asking in the ruling queries forum. Sorry, and good luck! ディノ千?!? · ☎ Dinoguy1000 02:35, January 23, 2016 (UTC)

Toon World non-English name glitch?

Sorry to bother you again. There seems to be a problem with the application of the region name template (don't know the real name of it) on Toon World's name.
For instance: {{Card name|Toon World|fr}} should output: Monde des Toons. But outputs: Monde des Toons. Pendulum (talkcontribs) 21:45, January 25, 2016 (UTC)

It's a known problem; for quite a while Toon World has been acting up like this, and nothing we've tried has been able to fix it (some of our attempts have actually made the problem worse). We're going to have to ask staff if they can look into it, if they haven't been asked already. ディノ千?!? · ☎ Dinoguy1000 03:59, January 27, 2016 (UTC)
Hum, seems really complicated. The same happens with Blackwing - Steam the Cloak.
Pendulum (talkcontribs) 12:02, January 27, 2016 (UTC)
Oops, forget it. It was a small problem with the input. Pendulum (talkcontribs) 21:21, January 27, 2016 (UTC)

Reply

I was just asking so calm down please

--Torimay24 (talkcontribs) 03:09, January 26, 2016 (UTC)Torimay24

I'm not upset or anything, I was just letting you know what the wiki's policy is. ディノ千?!? · ☎ Dinoguy1000 03:59, January 27, 2016 (UTC)

List

Yo there. Tiny issue, I'm not familiar with the coding for lists so I'm messing stuff up in my attempts haha, I think we should modify Yu-Gi-Oh! ARC-V The Strongest Duelist Yuya!! chapter listing a bit, mostly removing the "chapter name" parameters, since the series have no chapter names, and that's making the list come out pretty awkward. LegendaryAsariUgetsu (talkcontribs) 20:00, February 2, 2016 (UTC)

I'll have a look later, though the chapter/episode lists have always been pretty low-priority for me (though on the other hand I've intended to look at overhauling them for years). ディノ千?!? · ☎ Dinoguy1000 21:08, February 2, 2016 (UTC)

Chinese and Japanese fonts

This isn't really a priority but it's something that has been something that has been bugging me for some years

The coding for Japanese and Chinese fonts isn't good, the fonts looks pixely and jarred, and pmingliu (the chinese font) doesn't blend well with the design of the wiki because it's a serif font. I believe that they would look a lot better if this was added to MediaWiki:Wikia.css

.cardtable :lang(zh) {
    font-family: "Microsoft YaHei New", "Microsoft Yahei", "微软雅黑", 宋体, SimSun, STXihei, "华文细黑", sans-serif;
}


.cardtable :lang(ja) {
    font-family: "HiraKakuPro-W3", "Hiragino Kaku Gothic Pro W3", "Hiragino Kaku Gothic Pro", "ヒラギノ角ゴ Pro W3", "メイリオ", Meiryo, "游ゴシック", YuGothic, "MS Pゴシック", "MS PGothic", "MS ゴシック", "MS Gothic", sans, sans-serif;
}


So yeah, this is just a suggestion, but it would make the text a lot more aesthetically pleasing. Thank you for your time :)
Mediarahan (talkcontribs) 21:20, February 4, 2016 (UTC)

I've made the change as you requested. I don't have most (possibly any) of the specific fonts installed on my machine, but have to say, even just the sans-serif fallback looks better than the old fonts did. Is there a source you pulled these font stacks from, and do you have any similar recommendations for Korean text as well? ディノ千?!? · ☎ Dinoguy1000 21:50, February 4, 2016 (UTC)
These fonts are all system fonts that should work on new and old versions of Windows and OSX. As for sources i used this for chinese. For Japanese i pretty much copied the font-family tag from jisho's css. Sadly I don't know much about Korean system fonts except for Malgun Gothic. Googling something like "Korean web fonts" should probably help though. Mediarahan (talkcontribs) 22:10, February 4, 2016 (UTC)

Several Stuff

Hey, Dinoguy. Me again to bother you with several stuff. When it's something more technical I'll come either to you or Deltaneos, probably. And instead of being boring you every once in a while, this time I assembled some stuff to throw at you at once, so here it is:

  • As you can see here, Deskbot 005 French name won't display. I haven't been able to understand why yet. Something similar applies here for the Empowered Japanese names. However, their names appear here. They also appear on that table several times.
    I copied part of the tables to here, to facilitate visually. It's probably just something dumb that I'm not being able to see;
  • If a booster pack has a Super Edition, for some reason, it won't be displayed. For example, "The New Challengers" booster has a Super Edition. If you click Edit, you'll see it has "| super_edition = true", but nothing will be displayed in the page;
  • Another thing is I created this. Something is wrong with the link name on the Aether page. And I found the page for Aether members already existed.
  • Last but not least, I expanded your Set List template into 300 entries (because I needed to use it with more than 200 entries) and provided it here. Do you have any objection on this? Do you want me to give credit in a different way? I shouldn't use it? Is it too much text to provide on a page? Am I providing it wrong? It's not necessary to provide this? If something is wrong/not in the best way, I would appreciate you to tell me. Thanks.

And thanks for your time. Pendulum (talkcontribs) 12:51, February 5, 2016 (UTC)

Oh, and there's this. It doesn't seem very correct. Pendulum (talkcontribs) 14:48, February 5, 2016 (UTC)
You don't have to worry about only dropping stuff on me when you've got several things; if you notice something, go ahead and let me know. =)
The problem with Deskbot 005 is that for some reason, the French name isn't being stored by Semantic MediaWiki (SMW) - see Special:Browse/Deskbot 005, where you'll notice there is no "French name" entry. I'm not sure what's going on here, and null-editing doesn't fix it (and it's not an invisible control character causing this, either, since I tried retyping the name, which didn't produce any changes).
The Empowered monsters are also acting like that because of SMW, though not for the same reason. The difference between the set list and the Pendulum Monster list is because the contents of the set list are manually listed, while the Pendulum Monster list uses something called a query, which automatically finds and lists all the pages that meet a certain criterium (in this case, all pages for Pendulum Monsters). There's a way to fix this, but I can't remember for sure how.
I can assure you there's no shame in not being able to see the problem here. =) SMW tends to act up in several non-obvious ways that have the end result of information not displaying, or being displayed multiple times; we've had these problems with some pages for months now, if not longer.
Super Editions not displaying would be because the infobox doesn't have a super_edition parameter, since there're so few of them right now. For now, you can instead use the special_edition parameter, with the full name of the Super Edition's page (e.g. | special_edition = The New Challengers: Super Edition). If the page already has a Special Edition, you should instead use the other_sets parameter.
That's another SMW cache issue, though it usually happens after renaming a page. I've fixed it by deleting and recreating List of "Aether" cards.
That's fine, if you need it then don't be afraid to create/use it. =)
I don't see anything wrong there, myself; it looks like a redirect accounting for a punctuation difference. Am I missing something? ディノ千?!? · ☎ Dinoguy1000 15:13, February 5, 2016 (UTC)
Thank you for all the clarifications. Thank you very much!
Yeah, the Aether page is working now.
I'll search for those boosters that have "Super Edition" and correct it.
The thing with the redirect is that the first link for the Japanese gallery at this page was using that redirect. That's what I meant with doesn't seeming correct. But I gave it a "fix", so I think that redirect can be deleted, no? Pendulum (talkcontribs) 15:37, February 5, 2016 (UTC)
Aah, you meant the redirect itself didn't seem right. We do try to avoid redirects in the "extra info" namespaces (Set Card Galleries/Lists and the various Card namespaces), but really, the redirects don't hurt anything and there is no particular rush to get them deleted. You can tag those redirect for deletion, though, if you first make sure there's nothing linking to them (you can use Special:WhatLinksHere to check that). ディノ千?!? · ☎ Dinoguy1000 00:49, February 8, 2016 (UTC)
Yep, already did it. Nothing links to it. I just felt it could have been avoided. It was created because a link was wrong in the first place, I believe. And I don't like redundancy much, that's all. Pendulum (talkcontribs) 11:45, February 8, 2016 (UTC)

Infobox Set

Hi again! I think there's something not quite correct on the Template:Infobox set. When it displays the Spanish prefix for the set, it displays it as "ABBR-ES (sp)" instead of "ABBR-SP (es)" (example). Though I'm not sure what should be really displayed inside the "()". Pendulum (talkcontribs) 00:13, February 10, 2016 (UTC)

Oh, good catch! I've fixed it; it was originally correct but I accidentally changed it when I rewrote the code that handles set prefixes in {{Infobox set}}.
The question of what should be displayed in the parentheses isn't an easy one, and depends on whether they should indicate language, region, or some combination. When I rewrote the code, I chose to change it to region, since the tooltips displayed when you hover over them are the full region name (more or less), but there are arguments for languages instead, or for a combination. ディノ千?!? · ☎ Dinoguy1000 04:21, February 10, 2016 (UTC)
Thanks for fixing it!
Hum, that seems a tough decision, indeed. But shouldn't it be the same as the "Yugioh-Card database ID" section of the infobox? Because that part uses ja and es instead of jp and sp. Or is it supposed to be like that because of the region vs. language thing? I really don't know. And, in the case of DUEA, shouldn't a prefix for "Japanese-Asian" ("DUEA-JA") be displayed as well? Or should it be added manually, since it's a very particular case? Pendulum (talkcontribs) 11:37, February 10, 2016 (UTC)
The region vs. language distinction has caused a lot of trouble over the years, in no small part because no one really recognized it as problematic for quite some time. I've recently been working on separating their handling in templates, but it's slow going because of how embedded it is across the wiki (for example, all the parameters in {{Infobox set}} currently use language abbreviations in their names, with alternate abbreviations or extra tags for disambiguation; updating this will require editing several hundred set articles). Ideally, regions would be limited to release-related stuff (mostly release dates themselves and set prefixes/card numbers), and languages would be used for names, lores, etc., but the database adds to the confusion itself, at least a bit.
The JA-JP thing is a demonstration of this problem: until DUEA-JA was released, all Japanese releases used JP, and because the language code for Japanese is "ja", the two were used somewhat interchangeably for parameter names and the like, with a bias towards the language code (as can be seen in the parameter names for {{Infobox set}}, for example, which all use "ja"). After its release, though, no one bothered to add support for it in {{Infobox set}} (and doing so would have been quite difficult because of the JP-JA ambiguity), and it kind of got forgotten about, at least by me. In my rewrite, I made a start at finally adding support (you can use jp_set_prefix to specify the JP prefix, and ja_set_prefix for the JA prefix), but I haven't touched the reldate code yet, and finalizing support will also require an update run through all set pages, to switch JP releases to "jp"-prefixed parameters. ディノ千?!? · ☎ Dinoguy1000 17:54, February 10, 2016 (UTC)

Ratios Pages

Sorry for being spamming your talk page. Could you give a look at this, please? I don't know if I did it correctly, because the name of the set appears twice (I guess one is embedded on the Ratio template?), and I don't know if I missed something. Pendulum (talkcontribs) 14:45, February 10, 2016 (UTC)