Thu, Jan 31
It's all good, @TJones. Thanks to you and @debt for investigating this in such detail back in 2017. I remember I was very impressed when I read the comments on this task, and especially the blog post! I regret not expressing my gratitude or commenting here at the time.
Jan 6 2019
Dec 14 2018
Nov 30 2018
Oct 29 2018
Is this the same as the ancient task T31961: Special:Export of a single page with huge history occasionally forgets </page> and </mediawiki> closing tags?
Oct 27 2018
Oct 20 2018
Oct 16 2018
The old toolbar is going away.
Oct 10 2018
I would suggest that d: could be added to the beginning of the links. This way, they should work both on Wikidata itself and other wikis. This isn't really an interwiki linking issue (well, philosophically speaking, this happened because the interwiki links system is fundamentally flawed, but that's a tale for another day).
Oct 6 2018
Oct 5 2018
I don't think this has anything to do with change tagging. The stack trace makes it clear that $revid is null at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MassMessage/+/master/includes/job/MassMessageJob.php#233.
Oct 4 2018
Sorry for the bikeshedding and delay.
Sep 18 2018
Sep 17 2018
Do you really need to import all revisions? Just the most recent revision is sufficient for license compliance.
Sep 9 2018
To be able to import by uploading XML files, you need to request permission at https://meta.wikimedia.org/wiki/Steward_requests/Permissions#Miscellaneous_requests.
Sep 2 2018
I don't think there is any use keeping this old task open.
Aug 27 2018
@Headbomb, I think you're asking the wrong question. You want to be able to pass the current user's username to an external tool. Instead, the external tool should use OAuth to authenticate the user and fetch their username.
Why is this marked "Stalled"? What is blocking it? If it's just been set to "Stalled" because no-one is currently working on it, it should be set to "Open".
Aug 21 2018
To get this deployed, community consensus would be needed, then someone from WMF (probably Bawolff or Reedy) would review the code prior to deployment.
Aug 19 2018
There is a function in MediaWiki called armorFrenchSpaces which does this. It's clearly intended behaviour, and I would even argue that it is correct behaviour for all languages (other than programming languages, perhaps). See https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/parser/Sanitizer.php$1146
Aug 18 2018
Aug 14 2018
No idea, I haven't been on IRC for ages.
Aug 8 2018
This situation could also use a dedicated message. The current message, TTO's apostrophe thanked you for your edit on User:This, that and the other/sandbox/Schfoof. could be replaced by TTO's apostrophe thanked you for creating the page User:This, that and the other/sandbox/Schfoof.
Aug 4 2018
This is intended behaviour. See the other task for more information.
Aug 3 2018
Aug 2 2018
Jul 31 2018
This is marked as a MediaWiki software issue. I said in the description:
Jul 30 2018
Merging per Jaime's suggestion.
Jul 24 2018
With the interface-admin proposal (T190015) progressing, I hope it is apparent that progress needs to be made on this task at the same time.
Jul 22 2018
OK. This behaviour is by design, so I'm going to close this task.
Jul 21 2018
Yep, this is correct behaviour. The idea is that when importing from another wiki, the usernames do not relate to users on your wiki, so they are distinguished with this prefix.
Jul 8 2018
Jul 6 2018
Please request this at Meta: https://meta.wikimedia.org/wiki/Talk:Interwiki_map.
Jul 4 2018
Jun 30 2018
Oh I see what you mean.,.. the class for en would be LanguageEn, and the class for he would be LanguageHe, so when you ask for a language with code code, it sees that a class LanguageCode exists and tries to construct that.
Jun 26 2018
Bad things happen if you try to do huge imports. To make the import work, try turning off "import all revisions of the page" - it's not required for license compliance so long as you link back to the source page (which the import process does automatically anyway).
Jun 25 2018
All logged actions are supposed to allow tagging. Not many people have taken advantage of this feature for various reasons, and I would imagine uptake has been limited to a few common log actions (probably upload and perhaps delete and block as well). But I don't see this feature creating a significant maintenance burden.
Jun 19 2018
At https://en.wikipedia.org/sec-warning why does the English text not refer to the section at the bottom with technical info? I can see that the French text (for example) has "Des informations supplémentaires plus techniques et en anglais sont disponibles ci-dessous.", which roughly translates to "Additional technical information in English is available below." But English readers are not invited to scroll to the bottom of the page.
Jun 17 2018
Jun 16 2018
Jun 14 2018
Jun 13 2018
I suppose the WikibaseClient would need to attach to one of the hooks in XmlDumpWriter or something similar, like XmlDumpWriterOpenPage.
Jun 12 2018
How many of those were from local privileged users vs global privileged users (e.g. global interface editors, global sysops, stewards)?
The prefix BN: has been set up as an alias for the Benutzer: namespace (per the config file). This overrides the interwiki prefix.
Jun 11 2018
Heh, thanks Andre! I have simply been too busy to work on this. I've set a reminder for Saturday.
Jun 9 2018
Jun 8 2018
And why did the last row in change_tag have ct_tag_id NULL?
It seems probable that ct_tag_id will eventually become part of the primary key, so I'm not sure why it is even allowed to be NULL. (never mind, I guess this is necessary for the window between the schema change and running the script)
Jun 6 2018
I don't think @cscott would be especially impressed if that patch were to be merged right now...
May 31 2018
I'd like to see this maintenance script written in such a way that it updates the count of tags already present in the table, removing those with ctd_user_defined = 0 and ctd_count = 0. In this way, we can set up a cronjob to update counts on every wiki, say every week or 2 weeks.
May 14 2018
I will work on this in two weeks from now. If I don't, please ping and/or unassign me.
For clarity I have split the work plan in my previous comment to a new task, T194651: Smooth out quirks in the <poem> tag to ease consistent rendering across parsers.
May 10 2018
Will the code actually be executed when previewing the page though? I wouldn't think so. That is why I was suggesting that particular message be dropped.
The Wiktionary query link points to a Wikibooks query...
May 9 2018
It's great that you found a solution to your problem, but what's the actual issue that you would like dealt with in this task? If everything is now OK we can just close this task.
If this is still an issue with current versions please reopen.
In my mind user-defined regex is essential for this system to be fully effective. Maybe not essential for an MVP, true. But a lack of proper replacement functionality in existing tools was one of the things that drove me to build powerful regex replacements into FtCG - it seriously minimises the amount of grunt work involved in performing transfers, in some cases reducing it to no manual work at all.
May 8 2018
May 7 2018
At the very least jswarning should go, but I think they should all go. There's nothing scary about JSON. @Bawolff might think differently though...
Apr 29 2018
Apr 23 2018
If you code it up I will be able to let you know whether it makes sense :)
@jcrespo One of the things we are talking about is the queries in this function. How would you feel if that function was called every time Special:AbuseFilter/* was GETted by a user with relevant permissions (mostly sysops, global sysops, stewards and so on)?
Let's just take a step back here: what problem are we trying to solve here? It seems that we need to allow tags used by other abuse filters, but not tags that are manually defined or in use by other extensions or the MediaWiki software.
Apr 22 2018
Per the note at https://www.mediawiki.org/wiki/Editor.
Apr 21 2018
Apr 19 2018
Ah, I see. I knew there was a sordid history here (the original patch goes back to 2015). In any case, Matt Flaschen's account is disabled, so I don't think he will be commenting here.