Nookipedia talk:The Roost/2019

This page is an archive.

Only Administrators may edit the contents of this page. Please direct any additional comments to the current talk page.

This page is an archive.

Only Administrators may edit the contents of this page. Please direct any additional comments to the current talk page.

How the wiki Handles Styles

I don't know if this isn't the right place to put this discussion, or if it has been raised before somewhere else. I noticed that some of the lists of furniture of each color list what "style" they are in New Leaf, but the colorful, blue, brown, gray, black, and white pages call them "vibes" instead. There do not seem to be any lists for clothing to see their styles. Also, the Villager Info template seems to automatically draw items of the appropriate color and style for ideal gifts, but I do not know where it draws it from. This template also links to a page for the appropriate color and style, but none of the style pages exist. Might it be possible to automatically generate pages for each style in a similar way to how the template does it? Also, should I be saying "style" or "vibe"? Should there be a page for "Styles"? Ok (talk) 14:43, February 10, 2019 (EST)

The tables for furniture sorted by color are horribly outdated. The last update in content was at 2014, and by then Template:TableHeader was already a thing, which should standardize these all (i.e., they're called styles). And where did you get "vibe" from? There was not a single instance of that word in any of the articles you've linked. I am not so sure whether Style is notable enough to merit a separate page. Updating Furniture to add mechanics (e.g., effects of the colors and styles on villager interaction) is a wiser decision.

The ideal gifts are drawn from Template:Villager Info. I invite you to read the source code yourself, but, from <!--Second Table-->, it is generated from Template:Ideal Clothing, Template:Ideal Furniture, or Template:Ideal Gifts, and from there, the "ideal gifts" are hardcoded. (The ideal gifts are non-exhaustive, but a small sample from a large pool.) This is all done by User:sunmarsh, which we should commend.

Those links in the bottom, e.g., List of Cute Items in Animal Crossing: New Leaf in Chrissy's page, say that the original authors of the templates intended these pages be made. If you have sufficient time, you can create these pages using Template:TableHeader and by parsing data (e.g., regex) from, say, Liquefy's item list with proper citation.

I hope that helps. Feel free to update the pages if necessary (and if you make a mistake, the kind people here will let you know on your talk page), but you're already doing good work on the Japanese transcription. Also I don't know whether you're already there, but consider joining the Discord server for asking little questions regarding the Wiki, or just hanging out in general. Decomposer (talk) 07:41, February 14, 2019 (EST)

Yeah, really soon after I made this section, Drago changed Template:ItemList NL to say "style" instead of "vibe." Ideally, though, they would all use Template:TableHeader instead. I might look at those templates you linked, thank you! Also, I will look into the discord. Ok (talk) 13:36, February 14, 2019 (EST)

Romaji Standard

I'm sorry to put two topics here in a row (so soon after making an account) and maybe raise points that no one cares about, but I think it would be helpful if we had a clearly defined standard for romaji use (transliterating Japanese into Latin letters) so that we could make it consistent everywhere. If there already is a standard, I'm sorry! I put together the following proposal for rules based on what seems to be the de facto standard here (of course, there are exceptions; I wanted to be able to edit those out consistently):

• Consonants and short vowels are represented identically to their representations in Modified Hepburn.
• As a consequence, （ん、ン）is always n, not m, and is followed by an apostrophe (') before an ア行 kana (a vowel). (note: On some pages, an apostrophe is also used before a ナ行 kana (a kana beginning with an 'n' sound). However, it is a minority, and I would argue against including this in a set of rules because it is non-standard and serves no purpose; There is no ambiguity when just using a double n because the sokuon does not ever appear before ナ行 kana.)
• The sokuon (っ、ッ) is not represented at all at the end of a word.
• Long vowels spelled with an ア行 kana after a kana of the same 段 (ie, spelled with two of the same vowel in a row), or spelled with a chōonpu (ー), are all represented with a macron over the vowel (ā, ī, ū, ē, ō).
• ～ is treated as a chōonpu.
• Other long vowels are represented with vowel sequences, as if they were sequences of the short vowels that they are spelled with in kana. (ex. おう -> ou, えい -> ei)
• Small kana which are not part of a standard digraph are treated as their large variants.
• Changing between hiragana and katakana, as well as other word boundaries, are represented by a space (ex. Ribbot's catchphrase だロボ -> da robo).

In situations where diacritics (the macrons, in this case) should not be used, such as when the Japanese name of a character is being used as their English name due to not yet having appeared in an English game, There are a couple of options (I use Twiggy's Japanese name as an example):

• Simply omit macrons. (ピーチク -> Pīchiku -> Pichiku)
• Spell long vowels that would be represented with macrons with two of the same vowel letter. (ピーチク -> Pīchiku -> Piichiku)

I think that I prefer the first alternative, since with the second option, English spelling would make people likely to mispronounce many words spelled with ee or oo. Maybe we could do a hybrid where we spell ē and ō as e and o, and the rest as double letters. Or, we could just use the macrons everywhere (the only downside is that they're hard to input for most keyboards).

If anyone disagrees with any of these rules or thinks I got something wrong, or if you have other ideas, feel free to say so!

Also, I would like to ask how to handle the Japanese names in Infobox Villager and Infobox Special templates. A couple of days ago, I edited the japanese field in the Infobox Villager of a couple of villagers whose names in Japanese come from other languages and thus have standardized spellings in Latin letters. I followed the example of the pages for Alfonso and Ruby, where the first line has the name in kana, the second has the romaji, and the third has the standard spelling. I like this format because it includes the most information. However, virtually all of the other villagers whose names were from other languages only had the romaji or the standard spelling, not both. Furthermore, many use the JN template, which only has 2 lines (and has the unfortunate side-effect of cancelling the bold text; can someone change that? If it's not intended...) If we only include one, I think that the standard spelling would be more useful. I don't mind at all going through a lot of these pages and putting in the spellings.

Many of the special characters' Japanese names (like Reese, who is Lisa) also have standard spellings, and all of these pages use the JN template (it looks prettier in the Infobox Special template) so I think it would be most convenient thing would be for someone to just add a line to the template.

Again, sorry if I've missed something. Ok (talk)

I don't have anything useful to add to this as I'm unfamiliar with Japanese - just wanted to say, appreciate you bringing this up and I think it would be great if we can come up with a documented standardization for all this :) ~SuperHamster Talk 22:31, February 13, 2019 (EST)

Thank you so much SuperHamster!

Anyway, I noticed I forgot one obvious thing, so I will add it here (it goes with the 2nd bullet point):

• An apostrophe should also be used after n before a ヤ行 kana (one starting with a y) to distinguish it from youon. (んや　-> n'ya, にゃ -> nya)

Also, I realized that if we do put all three forms of some villagers' Japanese names, then we may or may not not want to include the standard spelling if:

• The standard spelling is the same as the villager's English name (as with Ketchup)
• The standard spelling is being used as the villager's name here, but there is no official English name (as with Joe)
• The standard spelling is the same as the romaji spelling (as with Becky)

I'm not really against including it in any of these situations, but it would become redundant. (Finally, I should have spelled chōonpu as chouonpu as per this standard, oops.) Ok (talk) 13:36, February 14, 2019 (EST)

Note: As of now, I'm leaning against using any of these exceptions. --Ok (talk) 15:31, March 4, 2019 (EST)

I'm one of the seemingly few people here who know Japanese (though you definitely seem to be a level ahead of me) and overall I agree with everything you've said. Those are more or less the rules I've been trying to follow anyway, and having a standardization for it would be great!

For the villagers with three name forms (using Alfonso as an example) I'd like to suggest something like:

アルベルト

Albert

as I feel stacking all three names ends up feeling a bit cluttered. Maybe we could even update Template:JN to work like this?

Also, regarding macrons, I'm in favor of just using them everywhere. The editor does have a built-in "special characters" list so being hard to input shouldn't be too big of an issue. --Lotter(talk) 09:37, February 18, 2019 (EST)

Hey, thanks! That's actually a really good idea, and it looks good in both templates! I went ahead and made 2 test templates for JN to test this idea: User:Ok/sandbox/JN and User:Ok/sandbox/JN2. The first one always puts the romaji in the hover-over text, while the second one only does so if there is no latin spelling given. I don't know which would be better; the JN2 might be good because it looks the same for both types of names. I didn't make it bold it in the templates since both infoboxes automatically bold their "japanese" field, but if this template needs to be used anywhere else, I can add bold to it. Also, to see comparisons of their effects, I used them on test names with and without latin spellings, alone and in both Template:Infobox Villager and Template:Infobox Special, which you can see at User:Ok/sandbox.

By the way, if we can use macrons anywhere, do you think it's ok to use them in page titles? Because if so, I think we should move Jubei to Jūbē. I actually was kind of unsure of what to do about him, because ベエ is actually an old male name suffix that is spelled with 2 kanji, 兵衛 (ジュウベエ would probably be 十兵衛). There is often a convention not to group together as long vowels sounds that are written with different kanji, but they are pronounced the same. Also, his name isn't really spelled with 2 kanji, so I kind of think we should just treat it as a long vowel, in any case. Lol sorry to bring up so much extra stuff in this response, I mainly just wanted to thank you for your idea!

Ok (talk) 21:01, February 18, 2019 (EST)

Looks great! I'd say JN2 is better since it's both more visually consistent and always easy to tell even at a quick glance. We probably don't need to use it anywhere else so I don't think you need to worry about bolding it - and if we ever do we could just change it then.

As a general rule I see no reason why we couldn't have macrons in page titles, as long as we also keep a redirect that omits them. As for Jubei in particular, that's kind of a tricky situation; if we simply transcribe the kana following the stated rules, then yes, it would be Jūbē. But at the same time Jubei (or Jūbei) seems to be the common English spelling, so in a sense it also falls under the same category as for example Joe, despite being a Japanese name. To a lesser extent there's also the issue that the name has already established itself throughout the fandom at large. (Though he's obscure enough that I wouldn't consider that a huge deal.) All in all, though, I could really see it going either way. If it was up to me I think I'd only move it to Jūbei at most, but it would probably be good to get more people's opinion on the matter as well.

And no worries, I think it's great that you're bringing this up because we really do need to sort some of these things out! Thank you for taking the time and effort! --Lotter(talk) 22:49, February 18, 2019 (EST)

Wow, you're right. I didn't think to look the name up in English. It's kind of weird that they chose that spelling, but I guess it was to prevent people from pronouncing it like "jew-bee" or "joob." Anyway, I suppose that's ok then. Ok (talk) 23:55, February 18, 2019 (EST)

I'm going to go ahead and start editing the villagers' pages, not using Template:JN. It seems that it doesn't add very much anyways. Ok (talk) 21:23, February 17, 2019 (EST)

Note: the JN template has now been updated and as such should be used. --Ok (talk) 15:31, March 4, 2019 (EST)

I have created a page on my user page that will compile just the bullet points of the standard, so its current state can be more easily referred to. You can still discuss it here. In addition, I changed all usages of 行 and 段 for kana to the words "row" and "grade" to make it easier for English speakers to read. I would also like to propose the following rule about word boundaries:

• All particles, such as が, を, よ, ね, and だ, are treated as separate words, unless they begin with ん or っ, in which case they should be written together with the word they follow.

Treating particles as separate words would make it easier to place word boundaries, as sometimes what is considered a particle by some is considered a full word by others. However, particles like ん and って cannot be words on their own, because their first sound must go at the end of a syllable. As such, they must be treated as part of the word they modify. (We could hyphenate them? It might look ugly: あるんだって言ってた -> Aru-n da-tte itteta?) --Ok (talk) 15:31, March 4, 2019 (EST)

I would like to discuss how we handle an i-grade kana followed by small ィ. It seems like there is somewhat of a standard to use "yi" for the rōmaji. However, I would suggest that for all cases except for イィ, we use "ī" instead. This is how it is actually pronounced in Japanese; it is mostly used as a cutesy way to transcribe an "ie" or "y" sound from English at the end of a word (/iː/ for most speakers, /ɪ/ in some dialects, especially British). For example, "Lily" is written リリー or リリィ; Harpie Lady from Yu-Gi-Oh is written ハーピィ・レディ. It is also used for a /ji/ ("yi") sound from other languages, but since English lacks this with any consonants beforehand (we don't have "byee," for example) it is usually only used this way for イィ. I would really like some discussion before I changed pages' rōmaji, though. The only villager names that use this type of kana are Bonbon (who is named the same as Mimmy from Hello Kitty), Carrie (Mommy), Frobert (Cozy), and Skye (Lily).—Ok (talk) 14:23, March 15, 2019 (EDT)

I'm not sure if you'll be back anytime soon Ok, but even with an undergraduate degree in linguistics I have to defer to your professional opinion on this. :P Please make whatever changes you feel are necessary to standardize the rōmaji. If you keep the user page at User:Ok/Rōmaji Standard updated with the guidelines you are using I'll make sure they are (eventually) incorporated into Nookipedia's future manual of style. Your work on this has been very helpful and we can't thank you enough. *throws confetti* (talk) 02:10, June 6, 2019 (EDT)

Multiple colors or HHA themes in tables

In Animal Crossing: New Leaf, every clothing and furniture item has two colors, which may or may not be the same and may have up to three HHA themes. However, the treatment of both of these in tables here is not consistent. When the colors are different, they are represented in a table separated by a slash:

"Black / Blue"

However, when they are the same, they are sometimes represented the same way, but sometimes only one color template appears, followed by "(x2)":

"Black / Black" or "Black (x2)"

When an item has multiple HHA themes, they are separated by either slashes, commas, ampersands, or only spaces:

"Antique / Rustic" or "Antique, Rustic" or "Antique & Rustic" or "Antique Rustic"

On the discord, Decomposer and I discussed forming a standard for these tables. We would like to propose that slashes always be used to separate both colors and HHA themes, without ever using "(x2)." I think that this will make tables look the most clean and consistent. Examples of the proposed standard follow.

"Black / Blue" or "Black / Black"

"Antique" or "Antique / Rustic" or "Antique / Harmonious / Rustic"

Ok (talk) 20:24, February 28, 2019 (EST)Ok

Note: the standard for colors would also apply to furniture tables from all games from Wild World onwards. In the previous games, furniture only has one type of Feng Shui, so no separators are needed. Ok (talk) 20:33, February 28, 2019 (EST)

Following this one up. I mentioned in the Discord that List of yellow furniture items and List of green furniture items use different styles. The lack of some Nookipedia Manual of Style is most likely to blame. While this inconsistency can be mitigated by changing the tables right now (preferably parsing through regex), a MOS could be drafted to prevent more inconsistencies in the future.  Decomposer 07:28, March 5, 2019 (EST)

• I agree with making a MOS. There are already a few style policies at Nookipedia:Policy, but it would be nice to have more standards established, and a place to reference for editors to reference. --Ok (talk) 09:32, March 5, 2019 (EST)

Hats and accessories

Does anyone have any opinions on what's the best thing to do with the Headgear and Accessories articles? Liquefy's WW and CF guides consider headgear to be part of the accessories category, but in NL they are completely separate categories. The articles for headgear and accessories on Nookipedia are also very similar to each other, and I'm surprised they haven't been merged before now. Drago (talk) 13:09, April 3, 2019 (EDT)

Afaik you can wear both an accessory and a headgear in WW and CF, making them separate things. Regarding the articles themselves, I'd suggest moving all descriptions (on what each article is) to Clothes, since they're sufficiently short. Regarding the listing of items, an article "List of clothing articles in some game" could be done, including tops, bottoms, headgear, and accessories. >Decomposer 02:44, April 4, 2019 (EDT)

I really like this idea and I will probably go ahead with it if no-one else opposes! Drago (talk) 10:56, April 4, 2019 (EDT)

NL, at least, does separate the two in Able Sisters; headgear is sold in the back while accessories are sold on the right. In WW and CF, accessories use head mannequins to display while headgear does not. Also, they have different inventory icons: accessories have a glasses icon, and headgear has either a hat icon if an accessory can be worn at the same time, or a helmet icon otherwise. This kinda suggests to me that there could just as easily be a three-way distinction, but it is never referenced explicitly other than in the icon as far as I know. In any case, I'm not opposed to merging them into clothes.—Ok (talk) 21:05, April 5, 2019 (EDT)

Characters following you around

I feel that characters following you around should be mentioned on the wiki. Tom Nook, Timmy and Tommy, Mabel, Reese, Leif, and Redd all follow you around their respective shops. Gracie also does this, but walks slower than the player's max walking speed (not running), unlike these aforementioned characters. In T&T Emporium, on the first floor, Leif will only follow you if you're in the bounds of the Garden corner, and Tommy will only follow you if you are anywhere else, except the section directly north of the garden corner that houses the Kiosk. These characters do not follow you when the ticket gates are open. In addition, Isabelle will follow you if you choose a PWP to set up, Tom Nook will follow you when you're deciding where to put your house/tent, and Katie will follow you if you tell her you'd like to take her to another town. Villagers can also follow you when they want to visit your house or want you to visit their house, and they can also be escorted to another villager's house if said other villager asks you to fetch them. Along with all this, in Animal Crossing: Wild World, on a day when Lyle appears outside the player's house, he'll follow them around as long as they're within the vincinity of their house. AgentParadox (talk) 00:21, April 25, 2019 (EDT)

It doesn't seem THAT notable to me, but maybe it could be mentioned on the individual character articles (and the Favors page for the villager stuff). Drago (talk) 11:41, April 25, 2019 (EDT)

On Screenshots of Items and Creative Commons

Animal Crossing Wiki (De), a German-based AC Wiki licensed under CC BY-SA 4.0, has had a wonderful job on uploading photos for Wild World and City Folk. For example, their Wild World Einrichtungsgegenstände (Catalog) contains a list of all furniture available in Wild World with images, while admittedly lacking other information. Is it possible for Nookipedia to reupload such images and attribute Animal Crossing Wiki (since Nookipedia is CC BY-SA 3.0) while licensing the images using Template:Game sprite? And, following up, is said template the proper one to use in this context, since they are technically screenshots from the catalog screen? >Decomposer 09:12, April 28, 2019 (EDT)

(copying over from Discord, for reference's sake) Since they're sprites from the game, the copyright ultimately belongs to Nintendo and is still considered copyrighted, even if someone else did the ripping / cropped out the background. I'd upload the photos under the fair use license template, and have the source as animalcrossingwiki.de. ~SuperHamster Talk 01:04, May 9, 2019 (EDT)

I have all the images already, but I am wondering whether it would be wise to add spacing (padding) or upload them as is. As follows is a demonstration of them being used in Template:TableContent:

Sample Table

Item	Image	Buy Price	Sell Price	Available From	Group	Color(s)	Genre	Size	Info
Anatomical Model	64x64px	3,360	840	Tom Nook	C	Colorful / Colorful	Modern/Lovely		-
Anatomical Model		3,360	840	Tom Nook	C	Colorful / Colorful	Modern/Lovely		-

I am just thinking of doing the latter. Related to this, is it possible to be permitted to write a script using the Nookipedia API to upload and add descriptions for WW furniture icons (considering it's unfeasible to upload 578 photos manually)? Current policy forbids doing so. >Decomposer 06:00, June 2, 2019 (EDT)

The demo here looks better without padding, so I'd go with that. Drago (talk) 11:19, June 2, 2019 (EDT)

I don't mean to be contrarian, but I like the padded version better as it is similar to the HHD Icons. If you end up having to upload manually let me know and I'll help. That's how I uploaded the HHD Icons... *eyes gloss over* (talk) 01:33, June 6, 2019 (EDT)

I'll probably not include padding for now, believing that the table looks better without it. Caution must be exercised when inserting them to tables; it is best to be consistent on image size. Regarding uploading, I'm currently researching on scripting that could automate the upload and add descriptions (e.g., Sprite of ??? from Animal Crossing: Wild World. Taken from (link).) and categories to each image, but a staff member ought to run it. I'll put it here once done. >Decomposer 02:27, June 14, 2019 (EDT)

Actually I should include padding to make them within a 128x128 PNG so that they may be inserted gracefully (c.f.: File:Barbel steed (City Folk).png, which are already enclosed in a "badge"), although this may take a while. >Decomposer 10:02, June 29, 2019 (EDT)

I've done some experiments on User:Decomposer/Sandbox#Padding_it_up and Iconify, where it would be possible to just upload the images directly without padding, although I don't think this would be the best strategy. Hey User:Sunmarsh, do you have some experience with padding up a lot of images at once? I can send you the ripped images already renamed properly. Otherwise, I'll try to make a script doing that. >Decomposer 22:54, September 23, 2019 (EDT)

Nice work with the templates! It's an interesting solution, but I think it's more useful in cases where the primary use for the image is without padding and iconify is needed in isolated cases. To be honest I haven't found a quick way to do it. With the Category:E+ Items I've been doing it manually by hand. My 'formula' is to take the largest dimension (length or width), divide it by three and multiply it by four. Then use that product and create a square canvas of that size. For example, a 90x120 image would sit centered on a 160x160 canvas. This creates a variable amount of padding, but the ratio between the subject and the padding is always the same 3:4. Thought about a different way, it's like fitting the subject in a square that was 3x3 and centering that square inside a larger one that measures 4x4. If you know how to automate this by all means do, otherwise if you want to send them to me I'll do it manually when I have the time. (talk) 10:21, September 24, 2019 (EDT)

So I managed to create a script that allows batch resizing of photos to a specific canvas size. I am currently looking for a way to batch upload these images with description, citation, and categories (maybe with Category:Animal Crossing: Wild World items or similar?) using the MediaWiki API, although I am unsure if I have enough permissions for such. Do I have permission to run scripts that use the MediaWiki API? Or should I send them over to some Patroller/Administrator? >Decomposer 09:48, December 22, 2019 (EST)

All logged-in users can use the API, so you should be OK. Let us know if not though! Drago (talk) 11:18, December 22, 2019 (EST)

Alright. I have uploaded a select few in Category:Animal_Crossing:_Wild_World_furniture_icons and added them in Blue Series. Are there any comments about the icon images? (What I did is fit them in a 60x60 border around a 64x64 blank canvas and resized using bilinear interpolation. Are there better methods?) If all is well I'll upload everything with the same Description before the New Year comes. >Decomposer 07:38, December 28, 2019 (EST)

I don't mean to be nit-picky, but I think it's better to have the images at full resolution (and therefore differing sizes) and then just specify the image size as 64px in the item tables. You can reference the way this was done for the E+ items in my previous post on September 24th. If automating this method isn't feasible, then feel free to use yours. I appreciate you continuing to work on this! (talk) 14:26, December 28, 2019 (EST)

Preferably, yeah, the images should be at full resolution. The script could just add padding and adjust the canvas size rather than resize the image in the process. However, if you don't really feel like going over it again, it's completely fine to just continue what you've started. ™ 16:11, December 28, 2019 (EST)

I think I see what you all mean. The reason why I went with making everything in 64x64px is so that they could all be inserted in image tables easily. I decided to incorporate the same amount of padding (at least 10px for all sides) in File:Mini-Dharma_WW.png and File:Lunar_Rover_WW.png. Their previous revisions are the result of having the images be placed in a constant 128x128px canvas, as I believe that the "sizes" of the objects should be shown (the Lunar Rover is definitely much bigger than the Mini-Dharma), although, if displayed, the Mini-Dharma would look too small. Instead, I added at least 10px for all sides, made them into a square, and, if the image is still too small, made sure that the images are at least 64x64px. The following is a demo of these two images in action:

Sample Table 2.0: At least 10px of padding for all sides

Item	Image	Buy Price	Sell Price	Available From	Group	Color(s)	Genre	Size	Info
Lunar Rover		2,560	640	Tom Nook	C	Gray / Gray	Modern/Lovely		-
Mini-Dharma		800	200	Tom Nook	C	Red / Red	Old School/Chic		-
Anatomical Model		3,360	840	Tom Nook	C	Colorful / Colorful	Modern/Lovely		-

Further thoughts? Is 10px padding too much? >Decomposer 04:10, December 29, 2019 (EST)

This looks a lot better to me! Also I appreciate the fact that you're trying to preserve the relative size of the items. That is one of the things that my method doesn't do very well. In my method, items that are closer to a square in shape tend to appear the largest, regardless of their size relative to other objects. I would move ahead with this. *thumbs up* (talk) 10:19, December 29, 2019 (EST)

Done (Category:Animal Crossing: Wild World furniture items), and I think I might've done a bit... too much in so little time. Without filters, Special:RecentChanges is flooded with the uploads. Should I just restrain my script so that it terminates after the 50th upload the next time I do mass edits? Or is there a way to tag those edits as a Bot or similar? >Decomposer 08:10, December 30, 2019 (EST)

Hey, nice work! Although the recent changes is just a bit flooded right now (xD), there's no problem with mass uploading as long as the images are constructive. And to answer your question, you can't hide your edits from Recent Changes unless a director gives you bot status. Whether SH or Jake would give you that, I'm not too sure. Drago (talk) 11:02, December 30, 2019 (EST)

Creation of subcategories for [[Category:(game) Images]]

Just a heads up: I have created some subcategories, such as Category:Animal Crossing: Wild World furniture icons and Category:Animal Crossing (GCN) screenshots; the latter one has been deleted. It is believed to be a better choice to use said categories instead of lumping everything in Category:Animal Crossing: Wild World Images and Category: Animal Crossing (GCN) Images. >Decomposer 06:00, June 2, 2019 (EDT)

Nice one, they do need splitting! Drago (talk) 11:19, June 2, 2019 (EDT)

On moving of lists and adding sublists

Would lists like Fish/Animal_Crossing:_Wild_World be better off renamed as Fish/Wild_World for brevity? More of these can be found in Category:Lists. I am also thinking of creating subpages such as Fish/Wild World/January to be transcluded into pages found in Category:Months. >Decomposer 10:02, June 29, 2019 (EDT)

I'm a fan of both ideas. Subpages sound great for maintainability and re-usability. ~SuperHamster Talk 02:46, July 24, 2019 (EDT)

Also in support of this, I'll take care of the shortened names today or tomorrow when I find the time! (talk) 15:59, September 22, 2019 (EDT)

Proposal to remove/disallow all content about hacking

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

---

Continuing on from the discussion on Talk:Hacking, I've gone away and thought about whether we should cover the aforementioned topic, and I've decided to propose that we remove all content about hacking from Nookipedia (and ban any future edits relating to the subject). Programs such as Action Replay, GameShark, ACToolkit, etc., are not made or endorsed by Nintendo and therefore unofficial. As Decomposer said in the discussion linked above, this information falls outside our scope and shouldn't really be covered on Nookipedia. And then you've got the argument that including hacking content could make it more likely that someone's game will get damaged (even though we're not going to be held responsible for that).

If this proposal goes ahead, affected articles would include Hacking, Hacked villager, Cheating device, Seeds (hacking), Chestnut, and Villager modifier. I am not proposing that we remove other cheats such as time traveling and Universal Codes which don't require hacking. That would be for a separate discussion. Also, the cheat policy and general policy would need to be updated of course.

So, should the subject of hacking be removed from Nookipedia or should it stay? Start the argument below! Drago (talk) 13:53, July 23, 2019 (EDT)

• Personally, I  Oppose removing it since I feel as a wiki, it is something we should cover and it also is a segway of sorts into discussing unused/beta objects from the series like the Dummy object. Also preventing such topics from being covered for fear of it possibly sparking someone's interest should only be the concern of the user itself in my opinion. Alcohol commercials are on TV all the time here in the US, yet it's up to me in the end if I'd like to start partaking in such beverages. In the end, I feel topics of hacking should be covered since we are striving to cover all info related to the Animal Crossing series and hacking is one of the major things in the AC series community. ~PoizonMushro0m
•  Oppose - I see our goal as an encyclopedia to provide a comprehensive and useful overview of Animal Crossing, and as unofficial as it is, hacking has become a decently sized part of it. Coverage of hacking provides an interesting history and insights about the technical side of games, and can provide interesting information on unreleased content like Chestnut that I think most AC fans would find relevant and would like to learn more about. Hacking coverage can also be practically useful for players to understand what's possible and what they might encounter through online play (such as the ability for players to crash other players' towns through seeding in WW). Hacking isn't official, but it can be encountered by any player. Hacking in Animal Crossing has been significant enough to even make stories on major sites, like the revealing of the NES emulator, which made stories on Ars Technica, Tech Times, Kotaku, and more - which I think is a strong point for us to cover it as well. Ultimately a video game franchise goes beyond canon content (hacking, unreleased content, tournaments, records, etc.), and as long as any of those things are a notable aspect of the franchise (as I think the case is here), we'd be doing a disservice by not covering it.

Regarding someone damaging their game, I don't really see that as a real risk, given we have a very large disclaimer that warns of potential side effects of hacking. Ideally our coverage of hacking doesn't serve as a how-to guide, but just an overview of what's out there.

That all being said, we should still be careful about our coverage - we're not a how-to guide or a directory of all the different tools out there. Our coverage should be encyclopedic overviews of notable hacking-related things, such as Action Replay or the NES emulation I mentioned before. Articles like Villager modifier and Hacked villager are too trivial to keep I think, and could be rolled up into cheating device or some other broader article (but that's another discussion to have). ~SuperHamster Talk 02:45, July 24, 2019 (EDT)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

Super Smash Bros. content

I was reviewing the content of Super Smash Bros. Ultimate and saw that the content there was out of date. I was considering how we might be able to transclude some of this information directly from the Smash Wiki, when I found myself asking the question... why are we maintaining character lists for the SSB series anyway? I understand that there are Animal Crossing references throughout most of the series, but I don't see why we should maintain character images and a full roster when most of the fighters are beyond the scope of the wiki. My suggestion is to instead include more obvious links directing readers to SSB content on the Smash Wiki, similar to the way it is handled by WiKirby. I am by no means suggesting that we lessen our Animal Crossing content as it relates to SSB, in fact I would like to expand that content and integrate pages and info between the Smash Wiki and Nookipedia. Everyone's thoughts on this would be appreciated. (talk) 15:58, September 22, 2019 (EDT)

Yup, agreed. Let's just list the Animal Crossing related characters in the roster, and people can go to SmashWiki for the rest. Drago (talk) 12:50, September 23, 2019 (EDT)

How Nookipedia handles guide pages

I wanted to initiate a discussion regarding the wiki's Guide pages. Right now, some of the most popular pages on the wiki in terms of views are our guides and lists (Guide:Face Styles, Hairstyle, Fashion Check, Public works project and the Fish & Bug lists.). As it stands, however, I feel that we do a poor job of incorporating these highly-searched pages into other articles or ensuring that they themselves are of the highest quality. I also question the relationship of the Guide subpages in general to the content on Strategy Wiki. We link to this wiki on the main pages for each game (also high-traffic pages), and yet I can't find an instance in which that wiki links back to us (other than in the NIWA list). Also the content there is generally lacking and not somewhere I would want to send our readers. I guess my main question is: what is the role of the guide subpages here on the wiki, and when/where do we incorporate them into our article pages in addition or instead of strategywiki? Or do we migrate our guide info to strategywiki and eliminate our Guide space altogether? Regardless of what we choose to do on our end, I think we should try and develop a closer relationship with strategywiki to both improve some of their pages as they relate to the Animal Crossing series and also have some more consistent backlinking. Thoughts are appreciated. (talk) 16:48, September 22, 2019 (EDT)

I definitely agree with most of your points. That said, I definitely think we should keep our guide pages seeing as they are popular for our readers. Some of them do need definite improvement though. Drago (talk) 12:50, September 23, 2019 (EDT)

Nookipedia mobile

One last thing I wanted to bring to everyone's attention, is that according to the Piwik data supplied by Jake, 63.5% of viewers access Nookipedia over their Smartphone, with only 26.8% accessing from their computers, which I assume is how most of us edit the wiki. Given this information, it's crucial that we start looking to provide a more phone-friendly experience to our users. I don't know how the mobile version of the Main Page is edited (kudos to whoever initially set it up), but it could use some work in terms of layout/design and providing access to relevant links. We might also consider generating phone-friendly pages for our most popular pages, or updating our templates to take into account the smaller screen size. If someone knows how this works and could fill me in I would be happy to work on this. (talk) 16:59, September 22, 2019 (EDT)

I totally agree with the need to make the site more mobile friendly. It would be great if we can make a start before New Horizons comes out, since there will be a sharp increase in traffic and predominantly on mobile devices. I've started some preliminary work on mobile-friendly templates in my sandbox, just to get an idea of how they could look (only view them on a mobile device, they look awful on desktop). I guess the exact specifics of how we implement mobile-specific styles are up for debate, since we have a few options.

I also think it would be good if we can overhaul the mobile theme to have it match the regular site's theme, or at least share its visual identity to some extent. There's some strange visual issues with tables that need to be worked out (though it might be because the CSS needs porting over to the mobile theme) and the Coustard font needs to be implemented as well. --Dorsal Axe (talk) 19:28, November 11, 2019 (EST)

Thank you for your work on this, Dorsal Axe. It would be ideal to work on the CSS used in the original notice templates so that it can responsively adjust to the mobile dimensions. This may indicate the need for a departure from the HTML tables currently used, opting for DIVs instead. In regards to theming, the Minerva mobile skin doesn't really afford us very many options there, but it is certainly something to look into. (I believe custom CSS can be put on MediaWiki:Mobile.css.) Also, since you're testing this a lot, I thought I'd mention that you can add "?useformat=mobile" to the end of any URL to force it to render the mobile site on your desktop. --Jake 20:22, November 11, 2019 (EST)

Yes, you're right about converting templates to DIVs. I've set up a Mobile Sandbox to work on some (very) rough prototypes, and everyone is welcome to participate and test things. The main thing for now is just testing possible layouts to see if they are practical for a mobile screen, we can clean up the code before implementation. Regarding the Minerva skin, I don't think we need to do a whole lot more than set up a matching color scheme and font to be honest. Maybe throw in the logo at the top, if that's something that can be done with that skin? I suppose the goal would be to make it match the site and not feel like a second-rate skin. Also, thanks the tip! --Dorsal Axe (talk) 06:54, November 12, 2019 (EST)

Interwiki icons proposal

No really, one last point. >.> I wanted to get everyone's feedback on a proposal to introduce icons after interwiki links here on Nookipedia as is done on Inkipedia. This would help to highlight outbound links to distinguish them from links to other articles here on Nookipedia. I think it also serves as a form of self-advertisement for NIWA itself and reinforces the spirit of cooperation between the wikis. I apologize for hogging up the board here- I will leave everything up to discussion now. (talk) 11:32, September 23, 2019 (EDT)

Sounds good to me! Drago (talk) 12:50, September 23, 2019 (EDT)

Agreed - it'd be good to make it more clear that links are going to other NIWA sites. ~SuperHamster Talk 20:49, November 25, 2019 (EST)

Language Project

Language Project

Many AninalCrossers cannot enjoy Nookpedia because it is only in English.

Language project would like to see wikis created for all major languages.

Discover more

Support This Project

ValeJappo (talk) 03:30, October 19, 2019 (EDT)

Hello and welcome! I appreciate what you're doing and agree that Animal Crossing wikis in more languages would be great, but unfortunately we are only of limited help if you're looking to create the websites for them. I do want to point out that there is a German wiki already though, so take a look if you're interested! Drago (talk) 13:58, October 19, 2019 (EDT)

I have to agree with User:Drago here. Non-English wikis already exist, which can appease local speakers In addition, how do we implement a multilingual Nookipedia? That will require a lot of maneuvering in the Nookipedia backend, which may be more trouble than its worth. I think that we should focus on improving the pages we have now in English instead of exerting effort in localization. >Decomposer 11:53, October 21, 2019 (EDT)

If you're serious about this project, you might try to enlist the help of some other Italian editors, I believe we have a few here (Astrena & TheFunGamer). They might be interested in helping. I would suggest that you first tackle high-traffic pages like Animal Crossing: New Horizons, Animal Crossing: New Leaf, and Animal Crossing: Pocket Camp. We could also create alternate-language pages for high-traffic lists like List of Villagers and Fish/New Leaf. If you can translate the New Horizons page, we can host it at Animal Crossing: New Horizons/Italian. If you end up translating more pages, or if you get more volunteers we can talk about establishing it as an official Nookipedia project. Best of luck with your project. Let me know if you need any help with templates/linking to translated pages. (talk) 12:32, October 21, 2019 (EDT)

Organizing and displaying data on Nookipedia

I wanted to start a discussion about how Nookipedia manages and accesses data. Many of our pages contain lists, and while I've created a few tools to help manage the display of these lists (e.g. Template:TableHeader etc.), these tools are very limited in that they are not very flexible or adaptable to different pages or item types. So the first thing that I would like to do is propose a more flexible solution to table generation, one which is not preset at the template level, but uses parameters allowing for the generation of customizable table headers and column numbers, using a standardized visual style (e.g. {{roundy}}).

My second proposition, is that we think about how we want to store all of the data about all of the items in our tables. And by items, I'm mostly referring to items found in Animal Crossing. Each item has many properties (e.g. name, image, sell price etc.), and using the current system these properties have to be manually entered any time we want to create a table displaying these items. It becomes particularly cumbersome when we need to generate long lists of items such as Miscellaneous furniture. I'm proposing using a data management tool that allows us to pull information about items from a database.

I'm currently looking at the Cargo extension, which will do exactly what we need, and is capable of generating custom tables based on the data we specify. What I'm not certain about is the extent to which the visual style of these generated tables is customizable, or if we are better off just using Cargo to store and retrieve data and do our own custom table generation. My other concern with Cargo is the fact that it seems that the data for the database is accessed and stored via templates, and so using Cargo might result in the necessity to create a large number of templates. Right now I'm not sure I understand exactly how the extension works. If anyone has any thoughts on this/knows of how we might better manage our data, I'd love to hear your thoughts. (talk) 12:01, November 5, 2019 (EST)

Just making a note here for any future readers, this topic was brought up in the Discord #development chat in March 2017 and a test installation of Wikibase was set up. For more information you can contact one of the Nookipedia Directors. I would still be interested in hearing discussion on Wikibase vs Cargo. (talk) 01:05, November 11, 2019 (EST)

Glad you're bringing this up! As you mention, this is something we've been looking at for...several years. I've always leaned towards using Wikibase. Animal Crossing games have a decent amount of relational data (items appearing in multiple games; villagers appearing in various games wearing various clothes; etc.), and Wikibase works well for that. Cargo would work too of course, but I'd rather have the nice UI to enable users to easily make visual edits. I'm also just a fan because it's relatively new and exciting, and (selfishly) I'd like to get more engaged with it as Wikidata becomes more notable and used for Wikipedia and other projects. A potential downside is the amount of legwork that will have to go into transferring all our data into a structure that can be imported into Wikibase, but I don't think that's that much more work than it would be for Cargo. That all being said, both seem like great viable options, and I'm willing to support Cargo if I hear a compelling reason to use it over Wikibase. ~SuperHamster Talk 01:44, November 11, 2019 (EST)

I agree that we should implement a database, since each Animal Crossing game is giving us increasingly more data to manage on top of the existing repetition. I'd certainly be interested in seeing the Wikibase test for myself just to get my head around it. I don't know enough about Wikibase vs Cargo to have an opinion about that matter, though this outline does highlight some differences between them. This page has some examples of sites that use Cargo, though to be honest I had a bit of look and I can't say I understand how exactly it functions any better than I did before.

Regarding tables, I want to bring up the TemplateStyles extension (which I mentioned on the Discord). I think if we're going to overhaul table generation, we may as well consider this extension while we're at it. We'd be able to create styles that can be invoked as needed without having to modify global CSS, and we'd be able to make tables and templates mobile-friendly since we could specify different styles for mobile view. --Dorsal Axe (talk) 10:46, November 11, 2019 (EST)