Template talk:Char Box

New Coding
So, after seeing this edit,...why is this change needed? This looks like something that's going to be confusing for newer editors. We shouldn't have that. There may even be some Wikis that take our coding from us. Do we need to complicate things like this? 05:34, April 25, 2013 (UTC)

This is the reason why we shouldn't use this code. Every time the page gets renamed, the image is no longer there. 23:41, May 8, 2013 (UTC)

because it's simpler & more controlled and we aren't using a template inside a template.

Height
Can we set a max height for images? There are some images that are way to tall for a infobox in my opinion.

Surprised this got ignored. What height did you have in mind? 01:33, February 5, 2014 (UTC)

I agree with you, levi, but do you mean place a parameter in the infobox or actually crop the tall images? 12:36, February 6, 2014 (UTC)

Some examples would help, I think. Some of the long infoboxes like Law's or Robin's are ones that I really like because the feel very "full-body". Ultimately, my opinion would depend on what the limit is, and how images look with the limit. 16:09, February 8, 2014 (UTC)

Limit for height of images should be in this template. Pages like Kiev or Nico Robin look really ugly now. Ruxax (talk) 20:44, June 20, 2014 (UTC)
 * I added height limit of 600px into this template. I think it is better now. Ruxax (talk) 21:17, June 20, 2014 (UTC)

Status
Hi. I'd like to remove Wille Gallon's status (it says "alive"), because we know absolutely nothing about it. I noticed that it's a sort of automatic addiction, 'cause in the page there is no mention of the status. How can I remove that line? BTW I'd like to open a discussion about the possibility to completely remove that line. Or maybe just add it for the deceased ones. --Meganoide (talk) 19:01, July 5, 2015 (UTC)

Proposition of the image size
I propose to change the size of the image from 270px to 270x370px, since it would become a standard size among the images to better see the images of tall characters or with long images, such as Nico Robin, Kiev, Bartolomeo, Mr. Shimizu, Charlotte Nusstorte, among others. --Cdavymatias (talk) 22:30, March 23, 2018 (UTC)

This results in empty white space on the sides of the image which looks bad. The current size is fine, it's adjusted to the width of the Char Box itself. 17:33, April 8, 2018 (UTC)

Looks worst adjusted. Too long (for example Mr. Shimizu's picture is more than 1/3 of the page). The spaces on the sides are not so bad, that way the image fits better to be seen by the users. --Cdavymatias (talk) 20:20, April 8, 2018 (UTC)

What is more important? Try to see the images in better shape, or occupy the entire template's space with the images? (that some look pixelated in that size) Cdavymatias (talk) 11:38, May 27, 2018 (UTC)

Seeing images in proper size and not surrounded by white borders. The only problem is cases like Shimizu where the original image is very low res. This should be fixed by changing the code so that images don't get stretched beyond their original dimensions, not by limiting all char boxes so that high res images get squished by empty space. 08:03, June 18, 2018 (UTC)

I agree that preventing image stretching is the better option. Kaido King of the Beasts (talk) 04:12, June 23, 2018 (UTC)

Jesus. I just tested it. That way is absolutely awful. The current way is FAR better. SeaTerror (talk) 08:48, June 23, 2018 (UTC)

New Field: Nicknames
I noticed some contention on putting nicknames in the alias section of a profile, and while I understand that these two can be different, I think they're worth noting. Therefore, why not have a "Nicknames" field? Doflamingo alone not having "Doffy" in his profile is just super surreal to me. The Pope 02:31, August 9, 2020 (UTC)

If the nickname gets used by many characters in the story then it makes sense, otherwise what you are talking about is a pet name which should the staff agree could go into the relationship section to show how they interact. Marco (talk) 02:48, August 9, 2020 (UTC)


 * I disagree; you can note who uses the nickname in the profile box, but stuffing something like Doffy or Tra-o way down into relationships instead of front and center when lots of characters call that person by that name (in Law's case, Luffy's whole crew calls him that now so it's not just a Luffy thing). Nicknames are prominent enough that they should all be notable in the profile box. The Pope 03:09, August 9, 2020 (UTC)

Can you cite any nicknames that are well-known among the general public and aren't the byproduct of a specific relationship? Doflamingo doesn't go by Doffy & he isn't known to the world as Doffy - his crew just calls him that. Yamato didn't like Luffy calling her "Yama-o" and corrected him. There's also the matter of insults and name-calling, such as the numerous names Zoro has called Sanji over the years. Like Xelistren said, the Relationships section is the best place to note nicknames. Kaido King of the Beasts (talk) 05:34, August 9, 2020 (UTC)


 * Hence why the section would be called "Nicknames" and not "Aliases 2". While that info can also go in relationships, I'd also say specific nicknames like the above mentioned and "Mama" for Big Mom are appropriate, at least as appropriate as their birthday, height or dang blood type. The Pope 05:43, August 9, 2020 (UTC)

Infobox update
Hi, I noticed that the switch in the infoboxes is broken. The infoboxes here also used a pseudo-hack with the use of "navigation" instead of "image" and other templates. While that might have produced a working result, I'm quite sure it wasn't ideal because there is no image defined for the article that way. That would probably cause some internal issues, but it was also not ideal for the mobile version. Therefore, I tried to rewrite the infobox code using the standard image parameter and a gallery for multi-image infoboxes. The result was Template:Test infobox‎‎, you can test it out on any page by changing the template name (Char Box) with that one. You can see a live example on Nami's page.

The current test version should be able to replace the old one on all pages without any issues. If all infobox images can be selected given the pagename, I believe I can also get rid of the switch parameter entirely. The styling of the infobox can be changed, I opted to place the tabs on the bottom and use the wiki's theme color (it's a coincidence that they are the same as the straw hats colorscheme), but tell me if you'd like something else.

That said, I'd like to update the current template with the code I used on Template:Test infobox‎‎. Once update and assuming no other issues arise, I might try to get rid of the switch parameter entirely so we won't have to worry about that anymore.

This seems like a good, working solution. I'm fine with updating the Char Box right away and continuing from there, as the current version is broken and it will be easier to spot any issues once all the pages use this version of the template. Regarding the tabs, is it possible to make them change color based on the colorscheme of the infobox? 16:31, 25 October 2020 (UTC)


 * It should be possible, but not worth it, because the only way I can think of using the color scheme for the tabs is adding additional selectors to the CSS of every single color scheme. Not only that would be a lot more code, but I think you have to make two lines per color scheme since you have to invert the colors for the "selected" tab. Currently, I'm simply using the color of the wiki "theme", but we can change them to more neutral colors too.

How is that different from One Piece novel A and One Piece Doors! that use image=gallery and image=tabber respectively without changing the book infobox? Rhavkin (talk) 16:42, 25 October 2020 (UTC)

It's not different, for what I can see using "gallery" like on One Piece novel A is the standard and intended way to add multiple images to an infobox. That infobox also uses the "image" tag for the pictures like normal. It's this infobox, Char Box, that uses (currently) a completely different structure then the rest of the other infoboxes. You can see by looking at the code that there is no "image" tag and instead there is a "navigation" tag (so we are placing some images in a place intended for navigation links and use that in place of the infobox picture). That was done in order to use those complex codes for automatically selecting the profile picture, since those codes wouldn't have worked with the normal "image" tag.

Normally instead of doing all of those coding backflips, you would simply add a gallery to the articles when invoking the template (or alternatively, make a template that does that for you), exactly like One Piece novel A. Most likely we were reluctant of editing every character page to do that, so someone came up with that to keep the old "automatic selection" we were using from the old not-portable infobox. I think that sometimes ago, fandom improved the infobox code and that allowed the solution I'm using now. Apologies, I actually had this semi-working from a while, but never finished it.

Also, I'd advise to not use the tabber tag anymore, like on One Piece Doors!, because I'm pretty sure that is being deprecated by Fandom and might be stop working in the future. Since using "gallery" produces the same result in the infobox, better use that.

And switching the navigation to image would not work even now? Rhavkin (talk) 17:51, 25 October 2020 (UTC)


 * That is what I'm doing.

It looks great. I think having the tabs at the top would work better. Because profile images tend to vary in size, the tabs jump up and down the page when cycling through them. Dragonus Nesha (talk) 18:04, 25 October 2020 (UTC)

They were originally at the top, but I moved down to the bottom because they kinda blended with the title. Anyway, we can change that and other minor details later.

I'm completely lost. Sorry. Ignore everything I said, and if I'd have any questions I'll asked them after the edit. Rhavkin (talk) 19:25, 25 October 2020 (UTC)

Maybe I was a bit confusing with all the technical stuff, bottom line is I'm going to update the current template to the version used on Nami. 19:36, 25 October 2020 (UTC)

Basically, the code that automated images for Char Box was somewhat outdated and broke with the new UCP update. Levi wrote a new automation system that is more in line with the standard method of including multiple images in infoboxes, meaning that it is more stable and works on mobile. So when the Char Box template is updated, it should fix the image switching on all character articles and we won't need to edit the articles themselves. 19:46, 25 October 2020 (UTC)

Just FYI, I noticed an error on some pages, I need to fix that before updating the template. And something really weird is going on...

So apparently there is a weird bug where references in infoboxes makes sometime not display images in gallery. Staff said that they are looking into that, so until they fix that I won't update this template.

Since the bug was fixed, I updated the template to the new version. Tell me if you see any bugs, weird behaviour or if you want to change anything.

Thanks Levi. I agree with Dragonus Nesha that having the tabs at the top would work better due to varying image sizes. Maybe a different color too, something less saturated? 15:58, 12 November 2020 (UTC)

I moved the tabs on top (I commented out the code so that can be easily changed again later) and used neutral colors. The CSS is on MediaWiki:Infoboxes.css. I also noticed a small issue: if you add the parameter imagename and leave it empty, the image won't be displayed. This is due how the "default" code works, but it's normally not an issue. However, there is currently a bug with the visual editor that adds ALL unused parameters when someone save a page, so that might be an issue. I could prevent this by changing the code a bit, but that will require basically doubling the code I used for the image part. I'm not sure if that's worth it since the bug will be eventually be fixed anyway (however the fact that the image won't be shown with an empty imagename won't change).

Great, that looks good. I don't think the bug will be much of an issue, visual editor has always caused problems anyway. 16:55, 14 November 2020 (UTC)