[00:00:03] I'm not sure if that is the case [00:00:20] I'm just using freerangegames right now [00:02:54] Just make a bot account. Usually the best way. [02:38:12] SOY LAURA FIORUCCI Y TUVE SEXO CON LOURDES CARDENAL.. HISE CACA EN ELLA HHAHA 💝💝💝 [06:46:57] Hello all. I need help (of course ;)). I have a Mediawiki 1.27 (one wiki folder, one database) ... But I have two URL (test1.com and test2.com) for this wiki. [06:47:47] But In my localsettings, I have only one wgServer [06:48:20] If i write test1.com, when i surf with test2.com URL, the URL change to test1.com (and it's normal for me) [06:48:55] And if I clean the value (wgServer = "";) ... All page are empty ... [06:49:34] any idea ? :) [06:50:16] thanks for your help :) [08:15:00] MEDIAWIKI.. VALEN MIERDA [08:15:02] 💝💝 JEM Y ASIMOVBOT SE AMAN 💝💝 [08:32:34] Strange, the "Edit X" title is not updated after saving https://phabricator.wikimedia.org/F4356020 [15:39:33] hey, we're a collective trying to set up a wiki page for our project and looking for a bit of support how to set up multilingual functionality... can anybody help us out? [15:41:45] qxm0f: basically there are two ways to do it [15:41:49] using a single wiki [15:41:53] or one wiki per language [15:42:49] yeah i saw that... this is the site we are trying to move to a wiki platform: http://skillsharing.net/ it has 8 languages (might add more in the future), and ideally the language wikis should be able to develop independently [15:43:06] do you have a suggestion which option would fit better? [15:43:43] if the language wikis will develop independently, a multiwiki setup seems more appropriate [15:43:58] "All the content of this website is anti-copyright. Feel free to copy, adapt and distribute it, as long as the final work remains anti-copyright." [15:44:05] this doesn't seem like a real license [15:44:41] there's some kind of freeish sharealike intention [15:44:52] but it's not clear at all how it can be reused [15:45:06] seems a goot time to clarify it [15:45:21] yeah, i guess that's another point we are discussing in recreating the site.. [15:46:28] as for the actual setup: https://www.mediawiki.org/wiki/Manual:Wiki_family [15:46:43] you can probably share almost all ocnfiguration [15:46:52] just switch the db appropiately [15:47:05] I also encourage you to use a shared user table [15:47:14] so the same users can be used on all wikis [15:47:38] you will want to set some interwikies, probably [15:47:46] but those are the final touches [16:01:40] I have a question about the design of extension.json / extension management - I don't know if this is the right place to ask. [16:01:58] yes, it is, Yaron [16:02:26] I'm not the best one to answer extension.json questions [16:02:32] but hopefuly the right person will see it [16:02:50] The "limitations" page (https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations) says that PHP constants can't be defined, and "The rationale for this is constants are either used in LocalSettings.php when raw strings should be used instead (you can't use constants in a configuration database), or in code, when they should instead be a part of a class." [16:03:16] I don't know if the last part of that got chopped off. [16:03:50] Anyway, I've run into a case where constants would indeed be ideal for use within LocalSettings.php settings; but I can't do it because of this. [16:04:18] I'm curious about that "configuration database" thing - I don't understand that reasoning. [16:05:24] Is it really better to have strings like 'low', 'medium', 'high' in the settings (or in a database) rather than numbers like 0, 1, 2? [16:05:37] ...or am I misunderstanding something? [16:06:05] Platonides: thanks. [16:07:13] Well, you can do it as an enum, so it's essentially a more-readable way of storing as numbers. [16:08:48] Kemayo: sorry, I don't understand - are you talking about in LocalSettings.php, or in a database? [16:09:16] In a database, since that was part of the question. [16:10:13] So if you do that, the extra storage from using strings isn't a concern. In LocalSettings.php, it's often easier to have a string which you can understand when you see it, rather than a number which you have to go look up and can't understand at a glance. [16:10:22] Well, only certain database systems support enums, if I understand correctly. [16:10:27] Maybe just MySQL? [16:11:07] Nah, I [16:11:19] 'm fairly sure all the mediawiki supported databases support enum. [16:11:30] Oh, okay. [16:11:42] not correct [16:11:50] Well, apart from SQLite. [16:12:08] they all support some way of achieving the same functionality, such as check constraints, but enum is not a supported datatype on every dbms mediawiki supports [16:12:58] Anyway, my greater concern is about LocalSettings.php. [16:13:17] anyway, I'd recommend strings [16:13:20] they're more meaningful [16:13:40] Yes, I understand that 'medium' is more readable than '1', but it's not more readable than MYEXTENSION_LEVEL_MEDIUM, or MyExtensionClass::LEVEL_MEDIUM. [16:13:55] it's certainly more readable than either of those :) [16:14:03] it's just not as "safe" [16:14:14] in that PHP won't immediately error if you typo it [16:14:21] Okay, that's fair. :) Yes, it's not as safe. [16:15:08] ...and it feels like more of a hack. [16:15:21] Not a huge hack, but still not as nice. [16:16:32] MyExtensionClass::LEVEL_MEDIUM should be possible though even with extension.json I think [16:16:47] as long as you register MyExtensionClass with the autoloader [16:17:19] haven't tested that though [16:17:23] I can switch over to using strings (I guess I have to), but I wish the "limitations" page (https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations) offered a clearer rationale, or maybe took out the rationale altogether... [16:17:46] Skizzerz: oops, I missed your responses. [16:18:06] No, that doesn't work - I tried with both global constants and class constants. [16:18:32] The problem is that the class doesn't get autoloaded quickly enough. [16:19:20] then yeah, use strings [16:19:42] Alright, I'll do that. [16:19:44] and the rationale looks correct insofar as the configuration db is concerned [16:20:10] Well... it depends on how the configuration DB is structured. [16:20:32] in order to have a "constant" (e.g. some fixed value that resolves to some other value), you'd need an extra mapping table [16:21:00] (I assume this is all theoretical, by the way - the only MediaWii extension configuration DB I know is in an extension I created, SiteSettings.) [16:21:06] otherwise the db is just storing special strings anyway, so there's no difference between using a constant and just using a string value [16:21:21] there's a stagnant RFC to move actual wiki config into a db [16:21:24] Yes, you'd need an extra mapping table. Which is theoretically possible to have. [16:21:27] Ah. [16:21:39] (e.g. killing off LocalSettings entirely for everything except for db credentials) [16:21:55] Right. There's certainly an argument for that. [16:22:18] I don't think anything has happened with that RFC for quite some time though [16:22:23] ...though creating a GUI to handle all cases would be a lot of work. As I discovered when I created SiteSettings. [16:22:32] Alright. [16:23:19] Maybe I'll "be bold" and edit that page to try to clarify some of this stuff. [16:23:30] go for it :) [16:58:42] Okay, here is the new wording about constants: https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations It might be overly long, I don't know. [20:08:34] James_F: hey, around? [20:26:09] Amir1: Hey, in meeting now but back soon. [20:27:44] thanks