As you know the old forum has been replaced by the new Discussion feature. But the activity and user right for discussions and wikis are different. I think than right now nobody is patrolling the discussions.
This matches the rights structure we've been using so far, so it would make sense to carry it over. It seems right now only admins can do any moderation there by default.
Honestly, so far I'm pretty unimpressed with discussions. The layout is okay-ish, looking modernized, but it overall feels like a downgrade feature-wise. Plus the lack of a recent activity monitor makes it hard to keep track of posts and moderate them. Not only that, but it's also unstyled, and so far I haven't found anything about styling it.
It feels like it's a beta more than anything with this lack of features. I'd imagine they'll be added eventually since they were so integral to the old forum, though. From what I've seen, they're omitted due to compatibility issues with the UCP, but shouldn't that not be the case in the first place?
Overall, I'm pretty upset about all the discussion and UPC stuffs. It's probably good for fandom in the long run. But for now, both are a strict downgrading of the existing platform. I'm upset that fandom is pushing these changes everywhere while they're still in beta.
In any case, they have already received many complaints and feedbacks and they are slowly upgrading. All we can do is adapt and be (very) patient.
Looks like you're one of the last admins who exhibited some activity on the site - even though your last edit was a few months ago, you blocked someone recently (thanks!)
The tabview extension is kind of dying rapidly... well, it's already gone. And it's not coming back once the wiki is ported to the UCP, so we need to perform the last of the pages as soon as possible
Unfortunately, to properly reorganize pages that are split with tabviews and persisting history, I'd need rights to move and delete pages, such as:
Move Pig/Normal to Pig
Disambiguate other subpages into their normal forms: Pig/Werepig -> Werepig
This would require deleting the redirect first, which I can't do because, well, you know
It's quite unfortunate for the other admins to just now have gone into inactivity, the last edit being from SpikeGuy a week ago
The lowest user right that can perform page deletions is Content Moderator, could I get it as a temporary measure for this task? Otherwise, Cuikui is probably gonna have to bear all of the burden alone
Don't worry, the message wasn't about flaming admins for being inactive, just to point out the rather bad timing for UCP migrations to be happening all at once while all the admins are away
While I'm at it, I'll keep a log of what I'm doing with these rights so you can mention any concerns you hay have with the methodology, I know how wikis work pretty well but I'm actually not super well versed with how admins usually do things
Deleted Werepig, and moved Pig/Werepig to Werepig
Deleted Pig, and moved Pig/Normal to Pig
Deleted Guardian Pig, and moved Pig/Guardian to Guardian Pig
Something I'll have to look into: Special:MergeHistory is disabled, however, I can restore deleted revisions after the fact and see how that goes
Also, I should worry about comment pages, maybe AjaxBatchUndelete could do the trick? All of the comments in the redirect pages were from back in 2013, but it would be a shame to lose 'em in the fire like that
Yeah, which is why I wanted to start off by moving pages to have more regular names rather than being subpages, and that would've led to having more disambiguations or categories instead of tabview pages (like Tree disambiguating to the others, with Tree/Evergreen moved to the base Evergreen page)
Speaking of, with the new method that retains comment sections, is it fine for me to move the gem and tree and other subpages now?
I've missed out on a lot, haven't I? Damn later college years...
I still keep an eye on the wiki even when I'm not editing (hence the block you mentioned earlier), so I do have a general idea of the broader situation, but not the fine details, so I might need a few explanations here and there.
Anyway, the retirement of tabviews was actually on the backburner for several months now to improve the experience on mobile, but it never got attention due to the lack of urgency, plus an "if it ain't broke, don't fix it" mentality, where if they were to be replaced, their replacement must do a better job presenting the content without negatively impacting the experience on any platform, even if it's minor - quite a high bar to reach. All of this is irrelevant now, though, since they'll straight up disappear soon.
I haven't been active for a while now, and as much as I want to return, realistically I will continue not being very active - if at all - for the next week or so. As such, I might not be able to help out or provide input on matters expeditiously, but I'll do my best.
I trust you, Bluegeist, and Cuikui to be able to handle this well. All three of you have been great at pretty much everything so far, so thank you! Keep it up. For now, I'll provide a few explanations and guidelines to help out, but remember they are not some be-all end-all 'rules'.
The manual way of merging pages without vapourizing either one's comment section is as follows (as far as I remember at least. I haven't done it in half a year, so take it with a grain of salt). (Edit: Just saw you got it figured out, nevermind. I'll still leave what I wrote here for reference.)
Delete the destination page. In other words, the one to bear the final name of the merged content.
Note: make sure you include all subpages in each step where applicable, otherwise you might accidentally nuke the comments instead.
As for the layout of pages formerly featuring tab views, It might be a good idea to have one disambiguation page linking the tabbed pages to each other. For example, "Pig (disambiguation)" with "Pig", "Pig Guard", and "Werepig" linked through it, and back to it on each one via a disambig notice. This was actually one of the many suggested solutions to replacing tabviews, inspired by Wikipedia's structure, and also doesn't affect mobile views at all since tabviews simply displayed their subpages as links, effectively serving the same purpose. This also opens up more options for styling, most obviously using images/galleries for links. This is just one option, you can feel free to get creative, so long as the final result is as clearly presented and easy to use as possible.
One more thing, should we put the content of the likes of Smallish Tallbird and Smallbird under the same page? The two in the example are heavily linked to each other and it's very likely a player would want to learn about both, and each one's page is rather small, so this would minimize unnecessary link-hopping.
That was quite a wall of text, wasn't it? Hopefully it was at least somewhat helpful. I'll be keeping an eye out here for now.
An open question: Do we want to turn all subpages into normal pages? (ex:Spider/Normal to Spider).
Subpage is not a feature specifically linked to tabview, as far as I know it is not broken with UCP. If we want the pages to remain linked by a common disambiguation page, why not keep the sub-page structure?
Well... I'll try to develop the most unbiased summary I can come up with for why to use subpages or not to use subpages
It provides a clear hierarchy for articles, where you can go to the subpage and always go back to the disambiguation by clicking the base page link in the breadcrumbs
It's already established. Not much to say about that, no changes needed
It's probably less readable to have the backwards title structure, with "Gem/Yellow" instead of "Yellow Gem" (this could be half-fixed by DISPLAYTITLE, but the url will always be the same)
The breadcrumbs link may go unnoticed since there's nothing that really states it outright to me a disambiguation, like the "For other uses of x, see y" template would
It forces pages into one specific disambiguation page and none others, which is the problem that Wikipedia had and solved with other kinds of disambiguation pages (we probably won't run into this, in videogames things can usually be categorized under one thing easier than the real world, but yeah)
The previous system wasn't even used consistently, with the "Pig" page being off in "Pig/Normal", but "Pig Traders" being in their own base article
Err... well, I might be already a little biased, I can't think of more pros than this. Maybe because I also found this and this which probably swayed my opinion... oh well!
Most opinionated one: I think it's ugly. Most people aren't used to having subpages as articles, and I think weird over just a page labelled (disambiguation) at the end
Hello, I'm glad to see the fast development of this wiki, but it still has some problems. The content of the page in Renovate Tab is incomplete. It just says those items and structures take some oincs to craft, but it doesn't show detailed value. I have a idea that making the page list, show Icon, Names, detailed crafting ingredient, characters'quotes, Crafting Description, Code and Notes. I consider that's too many, so I have a suggestion making the page expandable (Flooring, Shelves and so on). I know that's a big project, so I am here for help, would you like give me some advice?
I think the page "Renovate Tab" must stay simple. The Tab pages should only contain links to the tab objects.
Most items in the Renovation tab do not have associated pages. Perhaps we should create a new page for each type (flooring, shelves, etc.) where the details are listed.
I'm not sure what you mean here. I believe you're talking about adding hunger/health/sanity values for each character with such a multiplier to the food infobox, like how it's displayed for weapons. If so, that's quite a good idea. It seems food value multipliers will be used more extensively as a method of balance in the future.
If you're referring to something else, could you please clarify?
Hello, I'm SilentTwilight, the administrator of Don't Starve Chinese wiki.
Our team recently took over the wiki. Considering that the last authorization was too long, we want to reconfirm our rights.
The details are as follows:
-Translation right: the right to translate English wiki articles
-Use right of template: use right for some templates and contents of the template
-Free choice right of platform: under the restriction of CC agreement, part of the content of English wiki will be moved to non-commercial platform other than fandom.
We want to have our own original content, but because of the limitation of time and manpower, we can't do it. We will gradually revise the content later.
If you agree, we will attach the relevant website of the platform for your supervision at any time. You can raise objections to the above terms at any time. In our future wiki construction, you can also stop at any time if you find that we have commercial activities.
Versions of the wiki in other languages, including the Chinese wiki, are considered separate entities from the English wiki. They have all the rights you've mentioned, and they are free to use content from wikis in any other language so long as it's modified or translated to fit their wiki's needs. All non-English wikis are also free to develop their content independently of the English version.
Due to language barriers, I am not able to supervise your content or platform, and I'd imagine this would be the case for the majority of non-Chinese editors. However, such supervision is not required, since as mentioned earlier, wikis in other languages are considered separate entities.
I hope this has clarified the situation. If you have any more inquiries, feel free to contact me again. Have a good day/night.
It's possible, but it cannot be directly enabled. It requires Fandom staff to do that, and although I am already in contact with them right now and can request it, I don't think this is the best choice. This guy isn't your average troll, it's likely he'll just return the moment it's open again, and bringing activity on the wiki to a halt will guarantee his impact on the wiki - the very thing we're trying to minimize while blocking his IP ranges.
What we can do immediately, though (and have previously done), is disable editing for those without an account. But that won't do much to stop him, other than bring wiki activity down to make tracking him easier.
The option is still there, however. Should everyone be overwhelmed, it can be done to let everyone take a break.
They've been replacing page content with racial slurs, pornography, or spamming forum threads and message walls. They have been at this for about 18 hours now as well. Yes. Eighteen. Hours. Just take a look at Special:RecentChanges.
The level of dedication is unreal. Disabling anon editing is merely to slow them down and help keep them in check.