It appears that Lzlis last updated the enemy template on this wiki on December 2016, while on MWA wiki it was last updated June of 2017. This means the Bonus parameters (atkBonus, HpBonus, etc.) on this wiki don't work, although they're necessary for accurate 4* stats (compare: MWA and A). I'm probably gonna break everything if I try to copy it over, so do you think you can do so and reapply your autocategorizing again? Sorry for the trouble.
Sorry I didn't see this earlier. It was something I overlooked when creating Template:Prettybreak. It searches for the space nearest to the middle of the input and puts a <br> in there, and in [[Skill/Magic Weapon|Magic Weapon]]'s case, the space closest to the middle was the first instance rather than the second. (Its display on the class 1 row got a pass because there was also a Template:Checklink check there, which let the input go as-is without going through Template:Prettybreak.)
(Also probably a bit late to say this now, but if you edit the template itself you could've made the same change to all 500+ units' statblocks at once - it's kind of the point of a template.)
EDIT: Or, actually, I guess I spoke too soon since stalking recent changes and your contribs page shows you haven't actually made that many changes. I might as well go make the change right now, then.
Do you happen to know if it's possible to cause a template to display something radically different (but still the same information) based on the viewer's wikia skin layout? In particular, Mercury vs Oasis(Wikia)/Monobook.
Basically, what I'm scheming to do is show an extremely simplifed version of unit pages to mobile viewers, along with a button clearly labelled "desktop site" that would link to the page with ?useskin=wikia tacked on the end lol
This is my attempt at wikia's "portability" lol. I love all our fancy templates, and definitely don't want to make things less slick just so that Wikia's Mercury skin can handle it.
A while back I was looking into the issue of desktop vs mobile, and from what I gather there isn't really much we can do about it.
The only sort of controls that are applicable seems to be adding class="hidden" to make things not show up on mobile, and the Portable Infobox format they came up with a while back (my sandbox pages on MWA wikia  has my take on that; I wasn't fully satisfied with how they turned out for desktop, and while it's plausible to fit all the data we have on unit, skill, class, and ability into a portable infobox each for the mobile site, they don't have a way to look any different between mobile and desktop).
In the end I gave up and banked on the assumption no one would visit at least the wikia on a mobile. Sorry I couldn't help much there.
Meh, it's not a big deal. If fandom hasn't given any methods of implementation without sacrificing our desktop layout, then simply enough we don't need to be Mercury friendly.
I feel kind of stupid now for not adding two plus two, but considering the mobile layout removes pretty much all css it actually removes style="display:none;" too, which is used to hide things on desktop. So yeah, it's entirely possible to edit a page so that things that should show up only on desktop are wrapped in the "hidden" class and things that should only show up on mobile can have their display styling changed to "none".
I'll have to keep that in mind, and I'll try your suggestion once I (eventually) get around to renovating. (That said, I think a "change stage" button would still be impossible without flat-out listing everything and using hooks to jump around the page, and I don't know if including a button to change skins to Oasis in a place other than the place Wikia designated (bottom of page) would be against their ToS or not.)
@Valk - yeah it does. Just did a live example on the Prince page; because style="display:none;" doesn't work on mobile, the "Versions" box used to break on mobile by showing each toggle button twice (i.e. "NormalNormal - Sacred EquipmentSacred Equipment", etc.). With class="hidden" that box no longer shows, and instead shows the table styled "display:none;" which has all the versions stated once in bold. (Though I don't know how to style the table in mobile so that the right cell doesn't stick to its left border.)
@Kken - maybe? I haven't experimented, but things like background-color are exactly the sort of thing that's stripped in the transition to mobile. So I wouldn't expect using @media to make a difference there - if the alternate background-color worked the original should've as well. (Excepting relatively convoluted circumstances like Wikia using @media tags in the first place to strip styling, and not suppressing @media usage at the wiki level from overriding their setup.) But thanks for the point-out, I didn't know that was a thing in css before.
Maniacal laughter ensues as I successfully use a div that erases a unit's mobile page. This is good. I can work with this. :D
EDIT: Ok, so, I'm assuming the end-all be-all solution here is to enclose the unitlist item template inside <div class="hidden"></div>, and then append an additional part (still inside the unitlist item template) that would draw from the same variables to create the desired view on the page. Then, by enclosing the unitlist start and unitlist end templates in hidden divs as well, as well as placing the divs appropriately on a unit's page during creation, the only thing to show up would be the non-hidden part of the unitlist item template :D
Funny, I can type this out, but I'm already getting a headache about thinking how to go about implementation xD
EDIT again:  this thread made an interesting read. Funny, it covers exactly what you just mentioned above; the curious part was that they also mentioned that there is a template style that won't render on mobile.
In particular, I think they're talking about this template, which used a Notice template style prior to being changed to Design.
RE: unitlist item - I think it's better to put the "hidden" and "display:none;" tags into the template's table rows. Not sure if it would work just surrounding the unitlist item template; I tried doing that with the Prince's statblock and "display:none;", but it didn't work unless I made new tables for each row and enclosed the tables whole.
Thanks for the heads-up on some template styles not showing up, though I think we should be fine since most of the template types I've chosen should have been "Design".
Sure, and I'll do that for Sandy and Gordeaux. I'm not sure how to resolve the issue with Monica and Cuterie, though - I would want those ones to have separate sections, since the two abilities give separate numbers (plus extra effects on AW now).
EDIT: All right, done, sorry for the wait. Cuterie's page has a preview for my suggestion on separating the upgraded c3 ability with a different name. Category:May need sorting to see if + sign needed will have all the pages with the same c1 and c3 abilities, though not right now - needs to clear the cache after I mistakenly filled it up first.
I want to request the '(edit info)' button for AW abilities.
Right now, if 'upgrade = yes' the edit button is hidden. It works just fine for units with unique pre-AW ability. However that's not the case if the preAW ability is shared with someone, while postAW is not.
For example Kyuubi#Ability, Barous#Ability. Everything postAW has yellowish background, but if upgrade is set to yes, then edit button disappears. It's not unusable, but quite inconvenient.
Is it possible to Attach the edit button only to the 1st entry under abilities section, or add separate parameter for button (button = yes)?
I added the "edit info" button even if upgrade = yes. When I was making it, I think the only example I had on MWA wikia was Dine, who had both her abilities on a single page. For cases like hers, I've now added the capability to write button = no to make the edit button disappear.
Hope that works. And thanks for giving me a reminder - I actually did notice I should be fixing this before, but kept forgetting to get around to it.
All "upgrade" abilities are abilities that a unit gets upon AW, if the unit already had an ability pre-AW. That's how I meant it, at least, copying gcwiki. I thought all the abilities so far can conform to this format - can you tell me which one doesn't?
It can be circumvented by shoving 'dark elf of everlasting darkness' into 'Purebred Dark Elf' for gretel, while keeping the original 'dark elf of everlasting darkness' exclusively for dorothea. Should I do that?
It won't quite work with Majin however, unless 'Majin Reincarnation' is put into 'Dying Reincarnation Wave' for Rakshasa. It will get the desired visual result at least.
No, the whole point was this to have one page per each ability, so that one change on one ability can affect all displayed abilities. Putting multiple copies of an ability in different Ability/ pages defeats that purpose. I think I've a better idea - putting in the names of the units for whom it would be considered an upgrade in upgrade =, which would tell it whether to change the background colour or not. I'll show you in a moment.
Also...having looked at the recent changes page, I realized I wasn't quite cognizant of just how many Ability/ pages had two abilities in them. If I had known better I would've reversed the implementation and made it check for button = yes alongside upgrade = yes, as you suggested. Sorry to put you through that extra work.
I can't deny that it would be more convenient if I can edit the css myself, yeah. It's just, from where I stand, I don't think there will be very much more I'll need the css for...barring the one thing I mentioned there, tabber or portable infoboxes for the infobox template. Though on the same coin, I guess there's no particular disadvantage not to?
If you and Kure are okay with it, then, I'll gratefully take you up on that offer.
Gotcha and thank you, but uh...I wasn't completely familiar with with Wikia's stratifying of user right levels, just looked up Content Moderator right now...
Content Moderators can't actually edit MediaWiki pages like the css page. They can edit protected pages, but apparently whitelisted MediaWiki pages are a different thing altogether, and only admins can edit them.
That said, you have bureaucrat powers too, and I'm pretty sure bureaucrats have the power to add/delete rights to each user right level. If I can be so bold as to ask?
Ah, if you're still on the bureaucrats-can-edit-user-group-rights path I pointed out, sorry, it looks like that isn't as easy on Wikia as I thought. There's no mention of it on Community Wikia's Bureaucrats how-to guide, one related question I've seen thrown in CC Wikia's Help talk:User rights suggested contacting staff members, and the MediaWiki site's Manual:User rights page implies you'd need to edit a file called "LocalSettings.php" rather than a "Special:" page like I assumed.
I'm faster than that! :p there is an option, and that is to send a message via Special:Contact and ask for additional user rights to a user group, or to ask for an additional user group on the wikia (so, that's what I did). Word for word my message:
Hey there! I have an individual here who I would like to grant CSS-editing privileges to.
At first, I thought elevating them to Content Moderator was the solution, but turns out that doesn't allow the editing of MediaWiki pages (in particular, Wikia.css and Common.css)like I expected.
I was hoping we could get either an additional user group, along the name of "Interface Editor" or "CSS Editor" or the like.
With this additional user group, I could add them to both Content Moderator as well as this "Interface Editor" to allow them to edit all that a content mod can as well as these special MediaWiki pages.
I suspect the required user group rights would be among these two, but that's only a guess:
Edit restricted form fields (editrestrictedfields)
Edit the user interface (editinterface)
I would like this group to be available on both wikias that I am a bureaucrat of if possible please! ^_^  and 
Upon thought, I guess that also would mean that bureaucrats need the user right to give people this user group as well ^_^
With any luck, they might even ponder this and make it a standard across wikis.
I'm afraid Fandom doesn't create custom user groups on request. We have done this in the past, but noticed that it leads to confusion and chaos (or at the very least unnecessary complexity) more often than it actually solves problems on a wiki.
What is the reason why you can't give those community members admin rights so they can edit MediaWiki pages? They'd be under no obligation to use any of the other admin privileges, and could give up their admin rights again any time they want to.
If there is a compelling reason why the existing user groups don't work for your wiki, we may be able to alter an existing group, for example give content moderators the ability to edit MediaWiki pages. However, we'd like to avoid this if a different solution can be found, and it would mean that all your content moderators would then have that same right.
tl:dr; all you gotta do is say yes ;)
(to being an admin. Better specify in case I was too vague :p )
Edit: Derp, ofc breaks don't work in a pre tag. Changed to table :p
About Template:Unitlist_item. While doing pages with s55Range and s55SRangeMod the style ends up inconsistent with c2SRangeMod. Merone/stats , Maya/stats. Basically, there is a slash inbetween s55 range and s55 skill range that is not there in regular range. The issue is only cosmetic. I've tried messing with the template myself (undid my changes) but did not achieve the desired result.
Fixed. I copy-pasted the wrong part in there. Thanks for pointing that out. For the record, HTML line break tags are <br> (or <br />, whichever one you fancy).
I hope it all looks good? I'll probably end up bolding the red numbers that are boosted from abilities, too - I just forgot to do that yesterday. And the original idea I pitched to Kuremisago was to place the base block/range on the same (first) row and the boosted block/range under it, but mid-way through editing thought that it'd look neater if block values and range values were on the same row as themselves (since one uses slashes to separate red numbers, and the other uses line breaks, as you've already seen). But now I'm not sure how intuitive it looks to a person seeing all the numbers for the first time. Any opinions?
About placing 'base block/range on the same (first) row and the boosted block/range under it' I think either is fine. Can't say anything about how intuitive this is, but there is a mouseover tooltip, so it should work out.
RE: <br> - yeah, I know I said you can use <br> and <br /> interchangeably, but I kinda got used to working with just <br> so I didn't think to watch out for the other one when I needed to. My bad. It will work with either of them now, though I doubt it will be needed.
RE: two lines for Immortal Princess - I set it so you can set a min-width now, and did so for Class/Vampire Princesses specifically (though on the first row, the "Class Name" box still takes two lines). But I don't think it'll be needed for every case, though - in my opinion, an example being "Master of Powered Automata" from MWA wiki's Class/Puppeteers page so use the function with discretion.
Oh, I didn't even realize the line splitting you were talking about was as it wasn't happening on my setup. Should also be able to use (non-breaking space) to prevent line break between words if you think it is necessary.
That one's intentional. It arose from a point that User:Lzlis made way back, over on the MWA wikia. The discussion is here, but the basic gist of it is this: on the affection screen, the AFF bonus rounds up or down to the nearest integer, but when actually calculating the stats, the AFF bonus is always rounded down. So all those 50% aff bonus stats you see from the units on that list has either or both of its bonuses off by 1.
The main issue Lzlis brought up then is that when you try to back-calculate the unit's real stats by subtracting off its 50% AFF bonus, you may end up being a little inaccurate. That's the main reason I first created that category, along with drawing up an automatic list of all such units affected by this. Now, though, with Lzlis having the formula for calculating the stats from scratch, the stats probably won't be inaccurate anymore, so I meant to keep is as just a list of units that show the wrong number on its AFF screen. (Though I could probably name the category something different now.)
The current state of the list, holding only male members, is a coincidence. There used to be many, many more units affected by the rounding inconsistency, both male and female units, but the female units' AFF bonus stats were since patched and are no longer prone to showing inaccurate stats. Abel was meant to be on the list from the start, it's just that it didn't catch him before you corrected the 100AffBonus to 100AffBonusB because it was calculating from the wrong argument.
By the way, I'm pretty sure this bug is fixed, the aff screen and real stats now both round up (on Nutaku, assumed to be the same on DMM). However, there's still possibility of wrong stats for units that people added to whichever wiki beforehand -- of course that means that the old affection bonus might be more relevant than the current affection bonus... Before the big patch last year, I had checked almost all the MWA stats against the formula and made appropriate adjustments, but there are still a few rounding issues I've been meaning to iron out with the formula...
I'll just go and revert that italics-and-tooltip editing I did, then. Should I still keep the category as a list of units we might need to check later? I'm not quite sure what you mean by "the old affection bonus might be more relevant than the current affection bonus" - I can only guess you mean units that had its 50% AFF bonus stats changed here, on the wiki, to show actual boost, as opposed to than the numbers displayed on the unit screen. But I think only Marius had that, and I changed him (on here but not yet on MWA) yesterday.
I meant that for some units (e.g. Bernard), the old pre-patch 50% affection bonus was rounded, so it could have caused the off-by-1 issue, but his new 50% affection bonus is not rounded, so he won't be on the list -- but probably his base HP was not rechecked when the affection bonus changed.
Category could still be useful when I get around to going through double checking stats again, although I'll probably end up trying to look at everyone anyway. Shouldn't hurt anything, anyway.
Unless I'm missing something, Reve is the 1st unit to have once per sortie skill preAW that is not black. Skill/Holy_Field shows reuse timer if I want it show initial timer, but reuse timer is not needed since it's once per battle skill.
I can write in something that'll undisplay the reuse column like |noreuse=yes. I don't know which one you prefer, writing in the reuse# number to let the template calculate the initial numbers, or writing in the initial numbers directly.
While we're on the topic - for units like Alissa, whose range increase is shown in her range box without indication that it only occurs on Lv55, I was thinking about switching the block/range boxes to be displayed horizontally instead of vertically, and then add the s55Ability-modded numbers into the Lv55 row underneath. Does that sound all right?