[00:04:36] <.elizabethy_, replying to truearena111> https://www.mediawiki.org/wiki/Help:How_to_install_fonts I think this could help you at some point [00:04:54] <.elizabethy_> Wait wrong one [00:05:15] <.elizabethy_> https://www.mediawiki.org/wiki/Design/Archive/Wikimedia_User_Interface/Use_cases/Font_family_stack [00:05:20] <.elizabethy_> This one hahaha [00:05:21] [1/2] Yep, that's for a local install, not for a hosted wiki. [00:05:22] [2/2] This can be done with the MediaWiki:Common.css page on your wiki [00:08:17] [1/2] Once you've found the font you want, you'll need to identify the URL for the font you want to utilize, and add it to the start of your CSS file with: [00:08:17] [2/2] ```@import url('https://fonts.googleapis.com/css2?family=Comfortaa')``` [00:09:19] [1/2] After that, you can target specific objects to utilize this font with [00:09:20] [2/2] `{font-family: 'Comfortaa', sans-serif;}` [00:13:07] Is it possible to make a wiki background one big image that adapts to screen size instead of a repeating one? [00:45:53] <.elizabethy_> [1/2] It's under my page... [00:45:53] <.elizabethy_> [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1202052098032943124/image.png?ex=65cc0d41&is=65b99841&hm=5b056c30d73c7d92696cb5038c7e5e7728c873564490e4aeeec081b0465c8347& [00:46:10] <.elizabethy_> The Background Image doesnt appear. [00:46:13] <.elizabethy_> That's odd. [00:46:45] <.labster, replying to thebasicperson> Yes, it’s possible. Either ‘contain’ or ‘cover’ and ‘no-repeat’ in the CSS [01:33:34] https://cdn.discordapp.com/attachments/407537962553966603/1202064090378555472/8a8845ede228309d2ae103be7885f23e.png?ex=65cc186c&is=65b9a36c&hm=f418a4d41afdde83e6f61f87deca79c22c033af58d4bd038ee589c4b930281b6& [01:33:34] what the hell happened [01:33:38] what migration [01:33:52] whatever it was it ruined my pages [01:34:46] oh nvm [02:00:51] when doubt, blame self [04:28:29] why it a module [05:23:08] <.labster> Hm, I'm tempted to ask for Extension:UnusedRedirects, which is a special page that does the thing [05:39:49] Some modules define dynamic CSS for reasons, it's a thing with TemplateStyles [05:41:30] (and without it too in some cases) [12:13:19] If there are some out here who have an idea how to solve a colour assignment issue, please venture in the Support thread https://discord.com/channels/407504499280707585/1198152075872321579 thank you [12:13:46] I'm out of ideas [12:51:58] any Meta rollbacker available? Talk:Request features needs anon rollabck [12:52:25] ugh [12:52:31] in other news, an RfC regarding anon editing has started [12:52:35] does northern italy need to be eliminated again [12:52:49] nah, that's something else lol [12:52:53] oh good [12:57:42] Hmm [12:57:59] [[Talk:Request features]] [12:57:59] https://meta.miraheze.org/wiki/Talk:Request_features [12:58:00]

[12:58:23] Done [13:19:06] Anyone? [13:19:41] https://discord.com/channels/407504499280707585/1198152075872321579 [14:50:06] hey! i just have a question. what sort of wiki activity level is miraheze suited for, monthly page views-wise? considering miraheze as a provider but unsure if we're going to be too much for you. [14:50:32] you'd have to have something extremely large to have a problem in that respect [14:50:44] if you link we could check it out [14:51:02] i saw on the server info page thay you have millions of page views a month but i'm not sure exactly how many "millions" is [14:51:15] how many visits do you estimate? [14:52:01] up to 5 million monthly page views, i don't have a users estimate off the top if my head [14:52:44] that's quite a wiki [14:52:53] we'd be glad to host it [14:53:45] hmm? 👀 [14:54:47] Will do. csn't say much more publicly [15:48:27] [1/9] since I can't discuss it in line I'm going to discuss some of the rational opposing proposal 1 of the following rfc here, [15:48:27] [2/9] https://meta.miraheze.org/wiki/Requests_for_Comment/Unregistered_(IP)_editing [15:48:27] [3/9] ```A lot of the reasons provided have flaws - for one, we are about as similar to Wikipedia as a platform can be. Second, IP addresses cannot vote. Third, that is correct, but unregistered voters accept that and proceed regardless. They're aware that their IP is being exposed, due to the large sitenotice above the editing box. Fourth, some edits can be constructive. It's not fair to [15:48:27] [4/9] get rid of all the above, thereby also removing helpful ones.``` [15:48:28] [5/9] # Miraheze is not Wikimedia, one of the first essays I wrote and a principle that should remain in mind. Being close to the processes of wikipedia should not exempt miraheze from doing what's best for itself, playing too close to the line has caused a number of the issues the platform has had over time when obviously inapplicable or incomplete wikimedian ideas conflict with miraheze [15:48:28] [6/9] reality. [15:48:28] [7/9] # The RfC is not about IP address voting, it is about IP based editing. It's about instances like this: https://meta.miraheze.org/wiki/Talk:Request_features?diff=prev&oldid=367258, on top of recent prolific IP vandalism, the fact that various wikis with no leadership and marginal content are a no man's land of IP editing in some cases, and the fact that point four (which I'll address [15:48:29] [8/9] here) tends to inadequately cover the drawbacks in volume. [15:48:29] [9/9] # Disproven considering an overwhelming majority of oversight requests in my time and presumably after were because people forgot they were logged out or had an issue. Big notices do not cut it in practice. [15:48:48] [1/9] since I can't discuss it in line I'm going to discuss some of the rational opposing proposal 1 of the following rfc here, [15:48:48] [2/9] https://meta.miraheze.org/wiki/Requests_for_Comment/Unregistered_(IP)_editing [15:48:48] [3/9] ```A lot of the reasons provided have flaws - for one, we are about as similar to Wikipedia as a platform can be. Second, IP addresses cannot vote. Third, that is correct, but unregistered voters accept that and proceed regardless. They're aware that their IP is being exposed, due to the large sitenotice above the editing box. Fourth, some edits can be constructive. It's not fair to [15:48:49] [4/9] get rid of all the above, thereby also removing helpful ones.``` [15:48:49] [5/9] * Miraheze is not Wikimedia, one of the first essays I wrote and a principle that should remain in mind. Being close to the processes of wikipedia should not exempt miraheze from doing what's best for itself, playing too close to the line has caused a number of the issues the platform has had over time when obviously inapplicable or incomplete wikimedian ideas conflict with miraheze [15:48:49] [6/9] reality. [15:48:50] [7/9] * The RfC is not about IP address voting, it is about IP based editing. It's about instances like this: https://meta.miraheze.org/wiki/Talk:Request_features?diff=prev&oldid=367258, on top of recent prolific IP vandalism, the fact that various wikis with no leadership and marginal content are a no man's land of IP editing in some cases, and the fact that point four (which I'll address [15:48:50] [8/9] here) tends to inadequately cover the drawbacks in volume. [15:48:50] [9/9] * Disproven considering an overwhelming majority of oversight requests in my time and presumably after were because people forgot they were logged out or had an issue. Big notices do not cut it in practice. [15:50:52] @Discord Moderators, the RfC should be announced. [15:51:25] It affects the global community and one of the proposal impacts currently existing wikis. [15:51:27] Will do [15:51:53] very true [15:53:08] mostly because proposal 3 would be quite the change from the status quo [15:53:31] legroom made an excellent point on making anon editing simpler [15:53:45] in general the permissions interface could use a rethink in presentation to allow for simpler common changes [15:54:32] read-only, anon editing, perhaps even certain 'editor trust levels' in cases where vandalism is a common problem from new accounts, that sort of thing [15:55:19] Well, read only is just removing `read` so I'm not sure how much easier that could be? [15:55:34] ManageWiki is really meant for more advanced users [15:55:40] even a template system so you can import the permissions setup you want to have ie, doing away with some groups that are pointless for many wikis or supporting semi-common custom setups, an evolution of resetting permissions to default (where a steward could just import a setup' [15:56:21] I think one issue is that many people expect MediaWiki to be _extremely user friendly_ [15:56:24] the advanced nature of managewiki and wiki admin in general tends to clash with the ethos of letting people get involved in wiki creation who may otherwise have no idea what they're doing, they just have a platform that's a nice place to spin up a wiki [15:56:42] Fandom does a good job at dumbing down the interface, I'll give them that [15:56:45] basically all these thoughts are user friendliness yes; most of the menus aren't too bad but I find permissions to be a chore even though I have a good understanding [15:57:26] agentisai: In fandom can you create groups and give permissions to groups like here? [15:57:36] if it's rethought to keep advanced permissions setup a thing but to also make it easy for people who don't want to sift around and learn all the permissions intricacies, I think that would be a benefit [15:57:40] I actually never had a fandom account funnily enough [15:57:47] they don't [15:57:51] [1/3] I guess for the frequently needed changes there could be quicker shortcuts, like on the first page hav esomething like: [15:57:51] [2/3] * Disable/Enable anon editing [15:57:52] [3/3] * Disable/enable anon and user editing [15:57:57] but I don't see how that would be hugely different to the current system [15:58:00] on Fandom, at most you can click a checkbox that says "Disable anon editing" [15:58:14] but you can't create custom groups without staff [15:58:17] I guess that would be one click less than removing edit from "(everyone)" [15:58:23] even that with some common options could be neat, a menu to do some simple tasks [15:58:44] hmm [15:59:00] that could be a good idea actually [15:59:08] Special:WikiSettings which is a watered down interface [15:59:09] perfect place/time to also put up that nice big red 'don't screw with this if you don't know what you're doing' to head off people who screw up managewiki by removing it from bc/deleting bc [15:59:16] and if you need to do something complex, go to Special:ManageWiki [15:59:22] also a neat thought [15:59:26] that's how a lot of websites do it too [15:59:42] they have a simple interface and if you need to do something more complex, you can enable that more complex interface [15:59:43] yeah that could be a great idea [15:59:47] as people always mess up permissions [16:00:00] so if they don't want to get into the advanced stuff they can just do some easier things via the new interface [16:00:25] another step to make miraheze accessible [16:00:39] Since I think we've got some very different users on MH: some people just want to quickly create a wiki and write stuff and some others want very complicated settings and extensions and to have everything exactly like they want it [16:00:55] I think a majority fall in the former's category [16:01:06] some try to fit in between and customize without the understanding, and that's where most of the issues start appearing [16:01:22] managewiki is very permissive of totally bricking your wiki [16:01:40] It appears very likely that the option to only disable IP editing on Meta will win. [16:01:41] well either way, ManageWiki is much better than most hosts offer, i.e. doing stuff yourself via LocalSettings [16:01:54] it's very early, the voting can change [16:02:08] but prop 1 has an important early lead [16:02:17] The hell is going on [16:02:29] OK then! The RfC that led to the merger with WikiTide was very predictable. [16:02:31] chatting about the RFC and managewiki [16:02:49] believe it or not there was early concern how well that was going to go [16:03:01] the near landslide of prop c was a pleasant surprise [16:03:21] I know. I was nervous when I saw that shutting down was an option! [16:03:56] hindsight is pain [16:04:27] You talking about the last big RfC? [16:04:44] Our issue in general is that a lot of stuff we have can probably be improved and made easier but we don't really have enough developers to do everything. There's many ideas but implementation is difficult [16:04:48] indeed, I thought it'd be a much closer race [16:04:57] honestly I'm thinking about the last 7 months in general [16:05:12] everything from how I handled things to how it took until december for true progress [16:05:24] and indeed bits of the rfc itself [16:18:45] I know. It was very stressful for everyone! And last month was also the holidays, adding to the stress. [16:19:10] not a perfect time for such an instrumental event for sure [16:19:25] but then nothing about it was ideal ¯\_(ツ)_/¯ [16:40:39] <34.29cm> It took me a secnod to catch, but the link in #announcements wrongly includes the end parenthesis, so it links to a page that doesn't exist [16:40:42] <34.29cm> https://cdn.discordapp.com/emojis/979430688887558254.webp?size=48 [16:41:09] ah ye, discord links be weird sometimes [16:41:12] cc @reception123 [16:41:38] fixed, thanks for noticing [16:41:42] Discord links can indeed be weird [17:07:24] Yes [17:08:02] [1/4] Not like ManageWiki, though, its done like [17:08:03] [2/4] `user|edit|1` [17:08:03] [3/4] or [17:08:03] [4/4] `user|edit|0` to remove a perm [17:08:06] So odd [17:11:45] <34.29cm> re:RfC, if one of your votes is "abstain", is it more helpful to actually vote for "abstain" or to... abstain... altogether? [17:12:48] Usually when people abstain it's just to comment or explain why they don't want to vote either way [17:51:21] there's some slowness w/ RC feeds [17:51:59] If you try to load like 500 edits with the 180 day day scope, yeah [17:52:55] usually 15 or 30 days ... [17:58:52] I've noticed no slowness in the past few days, on meta or otherwise [18:00:08] maybe russian internet is indeed about to close ... [18:00:33] we had issues across the country yesterday [18:01:42] it did take 3066ms to load meta [18:02:34] the RC? [18:02:47] I think it's cp26/27 at this point [18:02:52] not exactly us \:P [18:03:08] heh [18:03:15] though tbf Meta RC has always been slow [18:03:19] yeh i think the move to contabo is the caused of the slowness [18:03:29] they've just jampacked the servers. [18:03:37] Agent has asked them to move the cps [18:03:57] but i think if it continues we should at least move cp26/27 to ovh [18:22:54] [1/11] RSS [18:22:54] [2/11] I have a question about RSS. [18:22:55] [3/11] Extension is here: https://www.mediawiki.org/wiki/Extension:RSS [18:22:55] [4/11] The feed works fine now, but the display is much to be desired. [18:22:55] [5/11] https://jwmeeting.miraheze.org/wiki/User:Rodejong/sandbox9 [18:22:55] [6/11] The link/rss works, but images are shown as html-tags and full url's. [18:22:56] [7/11] NEWS RELEASES | 2024 Governing Body Update #1 [18:22:56] [8/11]

https://meta.miraheze.org/wiki/Template:vde [18:54:03] [6/10] |- [18:54:03] [7/10] |'''Ziana''' [18:54:03] [8/10] |Abode ... [18:54:03] [9/10] ... [18:54:04] [10/10] |}` [18:54:04] yes, that wiki is not ours (well, in fact, it is, but because we adopted, I mean we didn't create it). I want to implement that navboox without importing all of that messy things [18:54:37] will try, thank you [18:58:35] For another example that's more just HTML table-centric, something like https://rootsofpacha.fandom.com/wiki/Template:Navbox_Characters may also work [18:58:59] Not as reusable, but for a basic use case is just fine [19:02:27] I've confirmed that no default is set for this, which implicitly sets it to false based on the extension. You can request that $wgRSSAllowImageTag gets switched to True for your wiki, or that it be added as a configuration option in Managewiki, via phabricator.miraheze.org [19:04:11] Okay, I'll do that. Thnks [19:16:45] https://phabricator.miraheze.org/T11762 :DoneMH: [19:59:24] [1/12] I wanna know how to fix a very silly issue [19:59:25] [2/12] it's just so that I can make the source code for pages looks better spaced [19:59:25] [3/12] some templates when placed with a line in between add an actual newline for some reason when they shouldn't [19:59:25] [4/12] ``` [19:59:26] [5/12] text text text [19:59:26] [6/12] {{box}} [19:59:26] https://meta.miraheze.org/wiki/Template:box [19:59:26] [7/12] ``` [19:59:27] [8/12] shows up as [19:59:27] [9/12] > text text text [19:59:27] [10/12] > [19:59:28] [11/12] > [19:59:28] [12/12] > [box template whatever] [20:02:21] there might be a stray line in template itself [20:02:49] for that reason `` tag is used in templates often [20:03:35] also lines might act funky inside `

` [20:06:48] ahh [20:11:26] [1/2] does this make any difference at all or no [20:11:26] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1202345417384132669/image.png?ex=65cd1e6e&is=65baa96e&hm=09abe670ae1490186ef332004ce61126bffdbc8046dd3da114e4ecf80afbd7db& [20:11:37] [1/2] like this is the code [20:11:37] [2/2] https://sona.pona.la/wiki/Template:lipu_pona?action=edit [20:11:54] [1/2] and ends up like so [20:11:55] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1202345535906783302/image.png?ex=65cd1e8a&is=65baa98a&hm=6055ac6743be5560736b472b07023e1d0b39de18440b44f062f0fb5c519baadf& [20:14:01] [1/2] speaking of templates, another unrelated thing is [20:14:02] [2/2] where can one find where all the useful templates areeee [20:14:23]