I like the idea of using two-letter codes for language projects though you obviously run into the issue of only being able to link to one project in that language that way (e.g. w.wiki/de would presumably go to de.wikipedia.org, not de.wiktionary.org, etc).

In T177949#3676337, @Aklapper wrote:

Not sure if @DanielFriesen still maintains this codebase?

@Verdy_p Hand rolling our own algorithm doesn't sound very great. IMHO a better idea, which is also easier, would just be to use zxcvbn.

I'm not sure how $wgConf works.

Not all wiki families are separated by domain; some use paths instead and this pattern will break for that.

@ashley They just want to use MW to host the policy pages rather than use it like an actual wiki. So omitting things like content_actions and just switching to Vector for logged in users should be fine.

@brion Also some privacy software / virus suites / intermediate proxies supposedly strip out the Referer header as well.

In T40417#2265444, @Bawolff wrote:

In T40417#2263011, @Krinkle wrote:

We can potentially avoid session inflation by creating the session separately from creating the edit html (which would indeed allow session inflation if an attacker requests edit urls repeatedly without cookies enabled). For example, we could start the session from JavaScript on the edit page in a background request (AJAX).

I don't understand how that would help the session inflation problem. The problem (if it still is a problem) is too many users have cookies on the client side, bypassing varnish. Using too much space in redis/whatever to store sessions on the server side, is not the problem (as far as I am aware). Creating sessions with javascript should not make a difference in that context

@Krinkle Javascript! Thanks, I just noticed a factor I wasn't taking into account this whole time.

Somewhat relevant old RFC; for which code was completed but simply halted because no-one would review it.
https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0

In T118932#1932148, @Tgr wrote:

In T118932#1932051, @MaxSem wrote:

Practically speaking, there is a huge difference: Ubuntu 14.04 LTS comes with PHP 5.5 and will be supported until 2019. You can't get anything like that for PHP 5.3.

How is that a practical difference? PHP 5.5 stops getting security fixes six months from now. (link) Is Ubuntu going to write/backport security fixes themselves?

In T118932#1846869, @Betacommand wrote:

I think that 1.27 should ship with 5.3 or 5.4, and then move to 5.6 after the LTS, Given how difficult it is to get third party hosting providers to update php we shouldn't use our LTS to move to a cutting edge version. Lets use 1.28 for that.

In T107561#1788847, @cscott wrote:

Daniel Friesen mentioned browserify as a major contributor to the move of client-side libraries to npm, although he warned that there were essential conflicts between "server side" and "client side" users of npm which would lead to confusion and delay as more client-side packages migrated. He also made some ResourceLoader-specific points which I don't feel confident recapping accurately.

In T30085#1701267, @devunt wrote:

@Tgr Then keeping old email addresses as same as now and only saving new email addresses as lowercase would be ideal?

You're right. I also tested with 500MB before, but it looks like Node.js requires 1GB of ram even for something as simple as this script:

console.log('...');

While the intention is to try and make things easier. This change basically adds a brand new unintuitive piece of syntax that now everyone has to learn.

In T30085#1692382, @Qgil wrote:

In T30085#1691937, @Tgr wrote:

where 1 has poor usability (why does my password not work?)

"We cannot log you in because this email address is being claimed by more than one Wikimedia account. You can log in using your username, and you can change your email address in your Preferences."

At least DigitalOcean has small $5/mo servers.

In T113210#1672261, @Ciencia_Al_Poder wrote:

Packages often do weird things with dependencies, so if you plan to install apache+php+mediawiki on one server, and mysql on other server, but the package marks a database server as required, you will end installing mysqlserver on the webserver where you don't want it, or else it won't install. This is something to consider.

The issue doesn't appear to exist anymore. Either the donation form changed or LastPass made some improvements.

I also brought up currently existing bugs and flaws:
The possibility we might actually want Allpages to be reasonably indexable (potentially helpful to smaller wiki).

Why was the RFC simply accepted with absolutely no discussion over the negative effects of blacklisting /wiki/*? which I brought up on wikitech-l and on the RFC's talkpage:

In T89456#1075262, @Ricordisamoa wrote:

In T89456#1073608, @DanielFriesen wrote:

Note that in the case of licenses our license-name may need an upgrade.

What do you mean? Both 'schemas' use SPDX codes:

• https://getcomposer.org/doc/04-schema.md#license
• https://www.mediawiki.org/wiki/Manual:$wgExtensionCredits#license-name

In T89456#1073289, @Ricordisamoa wrote:

Of course they can't be deduplicated right now, but some of them (except for name and description, as @DanielFriesen pointed out) are actually redundant between the two .json files.

Another note on something I noticed,
https://getcomposer.org/doc/02-libraries.md#specifying-the-version

In T89456#1056654, @MarkAHershberger wrote:

I think you did a good job of this. Thanks, especially, for identifying
why description might not work. I suggest that we talk to the SMW devs
about that one.
...
I agree with the caveat that I think there may be a way to compromise on
description.

In T89456#1054723, @MarkAHershberger wrote:

There was some discussion during the meeting about being able to refer to composer.json from extension.json if it contains the information already in order to reduce duplication.

I would suggest that we fall back to reading composer.json if it exists and an extension.json does not exist. This would allow us to gather basic author and name information for display on Special:Version.

In T18691#1043526, @Edokter wrote:

In T18691#1042886, @polybuildr wrote:

From what I can see in Resources.php, loading only the (default) skinning/elements.css and not content.css or interface.css.

So, why is this CSS not in skinning/elements.css? That's where headers and links are styled for all skins.

In T89456#1043385, @mwjames wrote:

I came to the conclusion that for the repositories I'm involved extension.json brings no benefit nor does maintaining information in two files (composer.json and extension.json) is time well spent. For us composer.json has functional relevance but extension.json has not therefore I can't see any motivation to actually maintain such a file.

In T89456#1042122, @Ricordisamoa wrote:

At least: name, description, homepage, author and license should not be duplicated between the two.

@Paladox this is about allowing users to explicitly pick a skin that happens to be the default (and won't change if the default is changed) or explicitly pick the site default skin (so it will change when the default changes). So it is not done.

en is already en-US, there's no point confusing people by having them both in preferences.

In T33874#952505, @MrStradivarius wrote:

We shouldn't be so quick to throw away "en". There is such a thing as International English, after all, so "en" doesn't necessarily have to refer to American English. Also, if we only have en-US, en-GB and en-CA, it doesn't leave any other category for other Englishes, of which there are quite a few. I imagine quite a few Australians may prefer "en" over "en-GB", for example, even though the spelling may be closer in the latter. Also, we shouldn't forget dialects like Indian English and Singlish. Perhaps English speakers of those dialects could get by with en-GB, but perhaps not; more investigation is needed, I think.