[01:55:41] I personally think that was a good idea if one person requested 6 different languages for the wiki. It seems like they were just collecting versions so no one else could. [02:36:13] My issue with that is that they could perfectly do the same functions while using the Translate extension or even Wikimedia Incubator if you don't want to hassle with Translate but this user disregarded that, asked for a Dormancy Policy exemption from the get-go and felt a bit offended by the fact that there are requirements for Interwiki Admin (as you may have seen on my talk page) [02:36:50] I'd be ok with multiple versions of a wiki in different languages having their own wiki but there isn't a need that has been demonstrated for that [02:37:25] Maybe if the requester requested 1 or 2 wikis and then showed that they can manage multiple wikis and translate them efficiently, then I'd be open for the approval of more wikis [02:37:49] I articulated that to the requester but they still requested more wikis [02:39:22] Potentially, or maybe he will thinks he'd be able to manage so many wikis alone. The requester has a sizable amount of content on his wiki but not many contributors (2 excluding his sockpuppet) which makes me doubt that he'd be able to manage so many wikis efficiently [11:14:09] While there's something to be drawn from how they respond to the suggestion (ie, polite explanation as compared to brisk 'nuh'-ing), I quite disagree that 'perfectly do the same functions' should invalidate the option to split given there are leading platforms that do that, and I would quite understand a user's apathy with the roundabout integration of translation units that aren't especially friendly to random editors and [11:14:09] may not be what is intended from a wiki design standpoint. It's perfectly acceptable to make the split from a content policy perspective and a precedence one, but I will give that doing all six off the bat is a bit much and they probably have enough to work with by sticking to the top 2, at most 3 languages that will be trafficked by the intended audience. [11:14:48] In so many words the idea isn't at fault, but from what I'm hearing the way they're going about it is an issue. Perhaps this could be articulated to them from start to finish unless you already have, at which point the ball is in their court. [14:18:28] The requester has experience with Translate but said that, from his point of view, the only wikis that used that are wikis that don't need additional wikis which leads me to believe that the requester doesn't necessarily believe there is something wrong with Translate but instead is comparing his wiki to other wikis and believes separate wikis would be needed from an aesthetic point of view. I will agree that the point of 'X [14:18:29] and X can perfectly do the same function' isn't something that will automatically invalidate the option of splitting wikis but as you said, doing all six off the bat is a bit much and I noted that I would be receptive to approving the wikis if the requester requested less wikis, showed work done and true need for so many wikis and then requested more wikis but so many off the bat is excessive and imho I feel like they might feel [14:18:29] overloaded which'll lead to abandoning of the wikis [14:19:38] In making my decision, I took precedence into account. There were some wiki requests in which Stewards declined even less amounts of wikis in different languages while articulating that Miraheze has finite space and can't host wikis in all languages [14:23:29] I have done so already in a comment but I believe the requester hasn't seen it per their comments on my talk page [14:38:54] I do think the first point is a fundamentally valid point of view, but the contingent 'six' is very much the tricky point. Plus it runs counter to a more conservative creation attitude that exists outside sheer content policy where one should make what they need or intend to use, rather than simply collect existence. I do think the reception wikis suffer from this, but in a more nebulous and less enforceable way. So given [14:38:55] the main principles you use I do think you've taken the right path, especially if it's accompanied with efforts to get him to rationalize the creation. In my unprofessional non-wiki-creator capacity, of course. [14:39:21] If they've been notified of that comment in response via talk page, ball's in their court [21:48:53] TIL: [[Meta:Community portal]] exists [21:48:53] https://meta.miraheze.org/wiki/Meta:Community_portal [21:48:54] https://meta.miraheze.org/wiki/Meta:Community_portal [21:48:55] [url] Meta:Community portal - Miraheze Meta | meta.miraheze.org [21:48:56] [url] Meta:Community portal - Miraheze Meta | meta.miraheze.org [21:59:25] It's a fun bit of history ^ [23:13:24] Indeed it is, there are plans to repurpose it but they seem to have been placed on hold since last year [23:27:46] I'm not sure what purpose it would take that isn't currently served, to be honest. [23:30:50] A Meta-only noticeboard to keep things seperate from the CN and SN [23:32:07] What would it contain beyond contents of the Meta Admin's noticeboard? [23:33:01] I guess to separate true Meta sysop-required needs from just general threads concerning Meta [23:34:06] Hm. I can't really imagine something that wouldn't be a small stretch to fit the community noticeboard or a given talk page, since meta isn't really designed to be a general or hangout anyways. [23:34:32] If anything I think that would end up a bit cluttery and result in things with blurred lines of placement.