Multiple games in 1 wiki |
0 | ||
As per a private a conversation going on with Anvil God mods, we're moving wiki(s) to there. One difference to both the Wikia and CFM approach is this is meant to be a more general single wiki hub for all Atelier 801 games. So this brings up the issue about how we separate content. This discussion is so we can all try to choose a way that is good, clear, simple and easy to use for visitors and editors alike. Better to figure this out now before we get started. Please leave feedback. We'll all be stuck with this way probably. I tried my best to not make this painful to read, but sorry for long post. TL;DR Since I'd like feedback from everyone:
Long vs Short form This somewhat affects all the other sections, so mentioning it first. When separating pages by game and putting the name in the title, there are 2 ways to do it: Long form (Transformice) or short form (TFM). Many/Most Wikias that have this issue seem to use short form. Based on personal experience long form gets a bit... old fast. However, the long form is clear, understandable, and professional. I -want- to say we should do long form, but I really would not be sad at all if we did short form. ex: Maps (Transformice) vs Maps (TFM) / Transformice:Maps vs TFM:Maps Note that our answer to this -may- differ for article pages vs files/templates. Article pages are "vistor facing", while files and templates are usually more technical and "secret", so don't need to be as "professional" in naming. Article Pages As I see it, there are three main approaches we have:
This the the more traditional way, and have seen it on multiple wikis. I would suggesting doing it this way: Maps (Transformice). Putting the name after the end in ()s is the traditional wiki wiki to differentiate pages with same name, and also benefits from the pipe trick for quicker typing. Compared to subpages, an upside to this method is the subject of the page goes first, which makes it easier to know what page your on, and also makes it easier to search for something, as there will only be a handful of "map" pages, but hundreds of "Transformice" pages. A downside to this method is other than manually adding categories, the wiki has no idea what topic a page belongs to, which makes it harder to potentially run certain scripts for a specific wiki (like adding a game-specific navigation bar via JS); in my opinion ()s are more intended for one-off conflicts, not site wide organization. But this is how I usually see this problem solved on Wikia. "Atelier 801 Wiki" content (staff, company page, etc) and some shared content (account, guests, friends, etc) would just inhabit the main namespace. We'd also probably make "disambiguation" pages. Nothing or () method if conflicts No other game would have a "Cheese" page, so adding "(Transformice)" to it could be overkill. The downside is if your just looking around, you might have no idea what game the page belongs to without looking at the comments. or with this method we'd likely have to purposefully specify "In Game Name" at the top of every page's content. or just make a template we manually add. While many wiki use this approach, it's -usually- when games are sequels. Like the Mario wiki will have 1 Mario page, with sections for each game. This makes sense when games have many similarities but not so much for games that have little in common aside from some core features / mechanics. Like I could see us having a single "settings" page, where we say what ones are common and then have section for differences. but we wouldn't want to share "map", "shop", "controls", etc pages. Some like "tribes" might have both pages. Note: This is the Wikipedia approach. But Wikipedia doesn't usually have multiple pages for a given topic except for thing like episodes/characters/etc, and they usually do list "list of characters in show", which I don't think we want to do for over 200 pages. Subpages While this seems like the logical choice, it's not really a great idea in mediawikis. As the help page linked above says, it's intended for archiving, making personal pages on User: namespace, and potentially making language pages. It's even disabled on the main namespace by default. One issue I know with namespaces is people get tempted to keep making namespaces. like Transformice/Maps/1 or Transformice/Events/Halloween. But where does a Halloween map go? do we separate maps by their type? This is why Wikis use categories, since it solves that issue. Now, we could have clear rules that subpages only be used for games (with potential exceptions for archiving like with updates, or potentially titles/shop). But subpages get wonkey when using search bar; the issue is it treats the parent page as part of the name. so to see maps you'd have to do "Transformice/M" before it shows up. And while not a deal breaker it doesn't work with the pipe trick. Really it just comes down to subpages are not really intended for this. Once upside is that by default subpages link to their parent page. Namespaces While this way looks very similar to subpages, it has some key differences. First, while namespaces organize content, it doesn't really organize it in a way MediaWiki cares about. Namespaces behind the scenes count as a different type of page and are meant for grouping a specific type of content (much like only using subpages for game, but this way is more expected by the wiki). Some upsides is if a namespace is a "Content" namespace, searching for "maps" would bring up Transformice:Maps without needing to add Transformice in front of it. And since it's organized on wiki level, you can easily do some stuff like making a searchbox specifically for the namespace (if we added a custom nav with JS, we could included the searchbox there maybe), it adds a CSS class to the body which would allow some game-specific coloring (for like infoboxes / navboxes), and potentially some other stuff I haven't looked into.It also benefits from the pipe trick. I've seen this used for separating types of "Article" content on mediawiki, and also seen it used once on a wiki for different version of a game. However, I've never seen it used for separating content of different games (although the different game version did work well enough). One "downside" it shares with namespaces is the game name always goes ahead of the page title. I know this can be fixed with JS, but not sure if there's a built in way to make it less intrusive (while still being easy to check). My conclusion I prefer either Namespaces or ()s. I like the idea of using namespaces, but just haven't used them in this way to know for sure there aren't any issues I'm not thinking of. Templates and Files Organizationally these would just have the game name in the name. The simple solution is to just use the () method here (ex: Template:Infobox map (Transformice) ). since they are sometimes typed out a lot I like to lean towards making them shorter (like "File:Map 1-tfm.png"), and using ()s in template names seem wrong to me for some reason, but that's probably just a bad habit / weird preference. But again, thoughts. Categories I think the () method is 100% the way to go here. Misc If anyone is a fan of the namespace method, would love to know if you've seen any other wikis use it for different games (or books/movies/etc). Also would love to see how other wikis (that have various pages on multiple non-similar games) handle game-specific files/templates/categories, if they do. Dernière modification le 1481647980000 |
0 | ||
Articles The best way for me really seems to be namespaces. I'm not a fan of having ()s in articles name in a organization point of view (there is no organizaton at all with ()s). I don't think to any major issue with namespaces, but I never seen examples with multiple games in one wiki using this method so I might miss something. The only downside : "fr:Transformice:Magasin" (lang + game + page name) starts to be long for a page name, but it's not that bad. Templates and Files I first thought to continue using game namespaces, but "fr:Transformice:Template:Infobox map" is a bit too much (I don't even know if we can do this in MediaWiki). That said, the best way is probably what Fewfre mentionned. There may also be a good idea to add categories to templates and files to organize them (there could just be a problem to be sure files are categorized since there is a lot). Categories Again, "fr:Transformice:Category:Maps" would be too much so ()s is probably the best way to do it. Similar to Templates and Files, categories may be a good idea from an organization point of view ("Maps (Transformice)" on "Transformice" category for example). Long vs Short form Articles : I have a preference for long form for namespaces because it's more friendly (RFC might be not clear about what it is if you don't know very well Atelier 801). Templates and Files : These are more in editing background so I don't have a special preference. Short form is shorter (no, seriously ?) but with autocomplete it's not a major advantage. Categories : Same as articles, it's more friendly to have long form. Altough categories are less visible than articles, users can still use them to navigate on the wiki. |
0 | ||
While fr:Transformice:Magasin might be long, using () would still be long, just at the end instead of front. I also think I'll probably make a JS script to shrink namespaces in the title (ex: Transformice:Maps), or maybe remove the namespace, make it smaller, and put it on the line above. and maybe also have it auto-link to the portal page. To my knowledge you cannot chain namespaces; I believe "fr:" isn't technically a namespace behind the scenes, or at least is modified in some way to allow it to work (I haven't look in detail on that link to find out exactly what it can/can't do). So File:, Template:, and Category: could not use game namespaces. And yes, I agree that you're right and it should go Game > Category Name (Game). We can also have a general "maps" category if we want, but people are mostly likely more interested in following categories by game before anything else. The issue is that by default mediawiki doesn't have autocomplete in editing. I -believe- there's a JS script to add that functionality (or I could whip one up potentially). But fair point, with autocomplete it's a moot point, so better to lean towards being clearer. |
0 | ||
Actually why it`s needed? |
0 | ||
Why is what needed? If you mean the move, this is not the thread for that, lets keep this on topic please. While it doesn't cover all the reasons (and isn't about this exactly / not the place to discuss, this is just a semi-related thread), see this. Dernière modification le 1481648520000 |