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)

I have a limited understanding of coding, but wouldn't this be more readable:

And keep only the "no image" and automatically add it to Category:Unknown Appearance Characters. What do you say? Rhavkin (talk) 18:51, 16 November 2020 (UTC)

I think there are extra pipe characters in it, that wouldn't work with the gallery tag. Theoretically, there is also the issue that if a character does not have a post-timeskip anime image, but a post-timeskip manga image, the pre-timeskip anime image will be shown first, I don't know if such cases exist though. I had a half idea to do something like that and remove the switch parameter altogether (that would require removing it from pages too), but I started by converting the code as it was currently used to avoid further issues. If everything works, we can think of simplifying it even more.

If the order is the issue that can be resolved. What about:
 * 1) Anime Post
 * 2) Manga Post
 * 3) Anime Pre
 * 4) Manga Pre
 * 5) Anime
 * 6) Manga
 * 7) ... Infobox

Is there really extra links that way? Right now the Anime Pre, Manga Post, and Manga Pre appear five times, and Anime Post three times. Rhavkin (talk) 19:50, 16 November 2020 (UTC)

I meant extra pipe characters ("|"), not links. What do you mean with "they appear multiple times"? If you mean in the code, then I wouldn't worry about it because there is a switch, it's just some code repeated for different cases. The template doesn't make extra galleries. We can make simplify it, as you suggested, but then we will have to remove almost all switch parameters from pages too.

Tab Links
I added an option to display the page tabs links in the infobox. This is because there is a serious issue that needs to be addressed: on mobile, there are no links to the tabs since the tab template is not displayed and therefore it's hard for people to navigate tabbed pages. I already wanted to remake the tab template to make it more mobile-friendly, but even if I did that, I think it will be more helpful to have the links in the infobox anyway.

In order to add the links, it's sufficient to add the parameter  like so. I saw that gallery, personality and relationship tabs are different for some pages. The template should check if those tabs exist before displaying the link, but if there are issues tell me (redirects might create some issues). I did not account for the history sub-tabs, which cannot fit anyway. That is another problem to address, but first I have to update the tab template.

If there are no issues with this, please add the tab links to all tabbed character pages, otherwise tell me what's wrong.

I added the parameter to the infoboxes. If you're planning to update the tab template, you should also note that Luffy's relationships are split into several sub-subpages. 18:27, 16 November 2020 (UTC)

If (or "since" now) we do that, why have the tabs at all? Why not show them in the Infobox alone? Rhavkin (talk) 18:51, 16 November 2020 (UTC)

When a page has so many tabs, I don't think the infobox is suitable for it... the links will be too cramped. Adding the links to the infobox was to make it easier for mobile users. The most problematic issue of making the tab template mobile friendly is using colorschemes, I'm not sure if it's possible as it is, but it will be if I change the colorschemes code. Anyway, that's another discussion.

This works as a temporary solution, but I think fixing the tab template would be better for the long term. Dragonus Nesha (talk) 19:35, 16 November 2020 (UTC)

The "fix" of the tab template will make it display the links as a simple list on mobile, it's nothing much. I also think that using the infobox will help google "understand" that the subpages are tabs. Regardless of what we do with the tab template, I believe it's better to leave the tab links in the infobox too, at least the "main" ones. If people don't like them, we could always hide them with CSS (this way, since CSS is not loaded on mobile, the links will be only displayed on mobile).

Yeah, the mobile version isn't much to look at. But with multiple subpages having subpages of their own, mobile readers are stuck scrolling to the bottom of long history sections or have to know the titles of the other subpages. Dragonus Nesha (talk) 20:26, 16 November 2020 (UTC)