Tue, Sep 18
Mon, Sep 17
Do you really need to import all revisions? Just the most recent revision is sufficient for license compliance.
Sun, Sep 9
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.
Sun, Sep 2
I don't think there is any use keeping this old task open.
Mon, Aug 27
@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.
Apr 14 2018
Apr 12 2018
T179012 is complete. Perhaps it is time to revisit this?
Seems done. I assume the Russian community was notified? If not, they probably would have noticed by now anyway...
Apr 9 2018
Jaime, I think my observation related to the fact that the query you quoted didn't appear to correspond to the EXPLAIN output pasted below it. This may just be my amateurishness coming to the fore, but the first part of the EXPLAIN relates to the involvement of change_tag in the PRIMARY query, when change_tag only appears in the dependent subquery. (Or is this just a feature of how MySQL handles dependent subqueries?)
Apr 6 2018
Is there any benefit for doing so? For example, would it improve performance on certain joins? It's hard to see how it would, but I'm open to being corrected.
Apr 5 2018
Is this realistically fixable, given the way extension tags are currently handled? Could it be solved when Parser.php is shown the door?
The compact attribute for <poem> is going to be removed soon as part of work on T54061. No-one seems to know why it exists or exactly what it is meant to do, and it is clearly broken in its current implementation (it makes the poem less compact).
I'm strongly inclined to decline this. The existence of huge volumes of content, developed over many years, that depend the existing behaviour means there has to be need a very strong reason for change, which I am simply not seeing.
We had an IRC discussion in #mediawiki-parsoid about this.
Apr 4 2018
Probably a duplicate of the very old T20562: Indicate in output whether an interwiki link is marked local, for which I submitted a patch more than three years ago (shock horror, it needs rebasing!)