Hello! I'm from Undertale Wiki. I want to ask you as the author of the template Global Lua Modules/Navbox: do you plan to update it? I have an idea about creating a new parameter based on the "above" and "below" params, which would add cells under the header and above the row data to nested navboxes. I saw something similar in the Minecraft Wiki on GAMEPEDIA (see the Version history).
I am indeed the author in the sense that I made the original Module for this wiki. The dev wiki simply copied my Module afterwards, I don't really maintain that version, per se.
My navbox does indeed not currently support above/below per section. You could emulate the behaviour though. If you add a "list" without a corresponding "group", that list will be centered, much like the above/below. You could then add some CSS styles to make it look the way you need it to. Of course that is all assuming you don't need the no-group lists anywhere else in the same navbox. But then you wouldn't need to alter the module.
In principle, you can complain to the devadmins about the user who copied your module without permission, and demand to delete the article there, but I doubt they'll listen to you. "Community content is available under CC-BY-SA unless otherwise noted"... and all that.
Yes, indeed! The autonomy of the "list" from the "group" can only be achieved if the first group starts with number 2 or even 3 (provided that the second no-group list goes after the first no-group list) in the corresponding section. But because of this, the meaning of using an "above" is lost when its analogue can replace it.
Everything would be fine, but I've two problems with my template that I'm racking my brain.
List items under a subgroups have poor formatting, ignoring the CSS style.
In bulleted list, after the left bracket and before the right bracket, a space is added, which is on your wiki and not only.
I ask you to look at the screenshot and at a part of the source code to understand where I made a mistake. Maybe need to watch the CSS...
Oh I didn't mean to imply that they "stole" it or anything. I'm fine with them having it. I was only saying I never made any changes to their version.
Anyway, the list under subgroups not working simply appears to be a use case that was not accounted for. My module is inspired by (but not a copy of) Wikipedia's, where they never put a normal list under a subgroup. That said, the fix seems to be rather simple (see it work here).
As for the second issue, I don't really know why it happens. It appears the parser inserts additional spaces around list items. Not sure if that is specific to Fandom (which has an outdated parser), or something my module should be able to trim. It can probably be somewhat solved through CSS with negative margins, though.
That leaves us with the "above"/"below" not being supported. For "above" this should be fairly simple to fix (after processing the header, check if there is an above with the same number and if so, render it). For "below" it would be more difficult, since the number would not need to match the header in any way. Another option could of course be to simply render the above/below in child navboxes, which would allow you to insert basically a complete navbox under any header, which is pretty much how Wikipedia does it.
Thank heaven, otherwise we could have needed three more modules from Wikipedia. However, I hasten to upset you that Wikipedians foresaw this case long before Wikia. In fact, you invented the wheel, but thanks to it I got off the ground.
The second issue is also confusing for me. And I, too, was not sure of the Fandom specificity until I copied the necessary things from Wikipedia (including CSS) on my wiki. As it turned out, this did not solve the problem with spaces in brackets, so probably a fault in the outdated parser (according to you). However, I am interested in your suggestion on how to fix it.
No, the numbering of "above" is impossible, since there is no hint of binding to the header in the module code. Although the implementation of the idea is real, but I think this is not necessary. It’s hard for me to say anything about another option, because it is not clear how the "below" will be displayed in the child navbox, without conflict with the "above" for the "place in the sun".
I have confirmed that the second issue is due to the parser. I copied the code to a locally installed mediawiki with the newest version and it works without problem there. I also confirmed that the issue is fixable with CSS (change here, example here).
Excellent! I believed that this issue is solvable, and my hunch was confirmed. Now I'm not ashamed to show the Minecraft navbox (ported from Gamepedia) on the Ukrainian wiki, because the current one there is just awful (example here). Thank you very much.
Hi Tjcool! I am the Fandom Wiki Manager for the Wiki. I am here to help you and the community out with anything you need. Additionally, I will be the liaison to full-time Fandom staff. Please if you ever have any questions regarding the wiki, editing, styling, infoboxes, templates, etc, don't hesitate to ask me, take care!
Can confirm that charm 20 (Lunar Lapis) is in Northern hill, somewhere around the two triangle shaped trees on the left side of the image. 14 and 48 are still missing though and I've got no clue of where they could be. Some of these locations are super specific and sometimes require multiple taps to even have it pop up. I made sure to throughly look around every single area with multiple taps but sometimes I'd find a coin just by tapping many times on a specific area, so it's driving me insane.
Thanks for the hard work! Hopefully the last two pop up.
No. 14 is apparently in the desk at Archibald's, but you can no longer access it after the chapter where you need to investigate it. :(
For 48 I have no clue, but I imagine it is also somewhere that you cannot get to after finishing (possibly somewhere at night).
I added information on Luke's recent appearance in the anime to his page, and removed "fanon" from Flora's (assumptions on her personality and the "adoption" fanon, since instead she's always been called a "protegee" of Layton and similar in the Japanese version, where she was written differently there in regards to Layton as well). If Flora is confirmed to be "adopted" when she later appears in the anime, then I would understand that reference, but as of now she is not (even with Katrielle's game) and it spreads misinformation. There is no Japanese materials or reference that confirm Layton "adopted" her either.
I might be making a few more edits but it'd only be for similar things (removing fanon, making a few notes on Japanese versions) etc. I hope that's ok.
Yes, I believe the same (the Wiki should be consistent with the canon). While I understood why the fanon came about, the currently running anime doesn't appear to contain any of it still, so it seems better to leave it out for now until it can be absolutely confirmed. However, since Flora was Layton's "self-proclaimed bride candidate" in the Japanese version, and no last names appeared to be changed as well (such as with Emmy), it seems very unlikely now. (For example, the anime would likely continue to refer to Flora as such unless she appears with her last name changed.) I edited some other articles to clarify these things as well, in hopes of preventing the continued spread of misinformation. Thanks for the response!