As I'm writing this, all the 4 tasks have started and 3 of them have completed successfully (the last one takes more than one day to complete). The last step would be to try a monthly run but meanwhile I'm closing this ticket as resolved (and I'm hoping I won't need to open it again in one month).

In T320048#9542281, @dcaro wrote:

When did you create the tasks? They seem quite new (a bit more than 4h)

Fairly recently because I made a change to the command in the YAML file for some of them and reloaded.

As the time of speaking the one task that "never started" has started and is working fine so I believe 2 are successful and 2 fail.

@aborrero, @dcaro, we communicated on the support channel and asked me to open a ticket about my issue so I reopened this. As said there, tried again my 4 tasks with a daily command. 1 was completed successfully, 2 failed and 1, the main one, never started (its status shows still waiting to start).

Unfortunately I found out that only one of four tasks has been migrated successfully.

A less crude idea for implementation is to maybe use the already present functionality of advanced search. Make such functionality be easily accessible through URLs by giving commands to it, something like this:

All Smallem's tasks have been successfully migrated to Toolforge Kubernetes.

I'm the maintainer of this tool. Currently I'm trying to migrate my jobs into Kubernetes but I'm encountering technical difficulties. I'm trying to solve them with this discussion but any extra help or guidance would be appreciated. I'm just commenting to let everyone know where they can reach me since the tool has been listed as unreachable.

In T337908#9055942, @Pginer-WMF wrote:

We have plans to improve the way limits work (T251887), and hearing about specific cases with details in the context is very useful. Thanks for sharing the example of stub creations, and feel free to share more examples of the limits not working ass expected. Thanks!!

I was led into this task by this conversation. As you'll find explained in details in the link, this adds an increased degree of difficulty to what was already a very confusing experience for new users.

A less strict threshold is considered for paragraphs that a user marks as resolved—taken as a signal that the user reviewed and confirmed the status of the translation. For paragraphs where the unmodified content warning is shown, but the user marks it as resolved, a less strict threshold is applied (accepting 95% of Machine translation or 75% of source content). This will provide a way to accommodate cases where the automatic translation was exceptionally good, but still avoid potential abuse of the feature (i.e., not blindly following a user's confirmation).

The percentage of user modifications is also measured for each paragraph. A paragraph is considered problematic when it contains more than 85% of the initial machine translation (or, when copying the contents from the source document, it contains more than 60% of unmodified content).

@KartikMistry, yes, I was seeing that now while working on the code (why I wrote that my patch may be wrong). This was rather unexpected as I was told from some manual tests that my community performed that the default threshold was 85%. Do you think it would be a meaningful change if we set it to 97%? Or maybe we should aim even higher?

Trying to help, based on past similar tickets, I've already created a patch for this (which may as well be wrong).

@Jdlrobson, is my patch the right way to fix this?

In T324883#8485825, @Andrew wrote:

When I log in to toolsadmin it looks like this:

If you see something other than that then I'd suggest clearing cookies or trying in a private browser tab and see if you can get to the standard login options. Be aware that toolsadmin /might/ require 2fa for all logins; Horizon definitely does.

In T324883#8484595, @Andrew wrote:

@Klein, are you able to log in to wikitech now?

In T324883#8477049, @Nahid wrote:

Hey @Klein, can you please send a note to T&S through [email protected] by referencing this phabricator task? Thanks.

In T324883#8472177, @Andrew wrote:

For reference: I believe that @Klein has also lost their ssh keys and so are unable to follow the policy as described at https://wikitech.wikimedia.org/wiki/Password_and_2FA_reset#Wikimedia_or_wikitech_two_factor_authentication_removal

Handing this off to Trust and Safety to find a solution or say 'no'.

I would like to add that the kind of collapsing/expanding I suggested differs with the overall idea explained here. The system I suggest deals with marking topics as resolved or open (which would coincide with their states as collapsed or expanded) not with the readability preference of how one might want to have the talk page topics presented to it. If anything, I'm not very fond of having to interact with collapsed topics (in my suggestion, collapsed topics would be resolved, already "semi-archived", and one would generally have no reason to interact with them). That already happens in the mobile version and it makes following reply emails hard for me.

In T201491#7982912, @Yaron_Koren wrote:

It's these two:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlexDiagrams/+/788408
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlexDiagrams/+/789906/

For some reason, only the second one is linked above - I don't know why.

In T201491#7981841, @Yaron_Koren wrote:

@Klein - I just saw the changes you made last month to the Flex Diagrams extension. Those were indeed typos, but they were in an upstream library, so they should not have been fixed (see note at the top). It's not a big deal, but I just wanted to point that out.

In T245225#7981322, @Tacsipacsi wrote:

...although adding a strikethrough button to the toolbar would be nice indeed...

In T245225#7979283, @Tacsipacsi wrote:

Sorry, I wasn’t clear enough about the strikethrough. Not signatures are often struck through, but the substantially changed parts themselves...

In regard to typo fixing personally I can see changing the timestamp as being equal to "this comment was edited". Generally speaking, I'm not too fond of heavy notices that tell that so a "time confusion" would be a subtle enough clue that comment editing had happened. Indentation would preserve the logical flow of the conversation.

Regarding the whole signature discussion... I believe the importance of the timestamp must be stressed. If one comment changes, there's no logical sense to keep the old timestamp. Keeping that in mind, maybe the signature should be removed automatically altogether and re-introduced in the new version of the comment every time an edit happens.

Prepared the patch. Feel free to abandon if not necessary.

Can someone add this link in the list of typos above, assign it to me and mark it as pending? It's one of the most common typos apparently and I've already fixed the majority of them. I'm scared of tables.

In T201491#7900706, @thiemowmde wrote:

why exactly do we need the regex \.js$ as a filepath filter?

Oh, this was just to make my example run faster. You can ignore this.

@thiemowmde, would it be possible explaining to me why exactly do we need the regex \.js$ as a filepath filter? Why are we only looking at the js pages? Are those the only ones which should be corrected?

In T201491#7899997, @thiemowmde wrote:

I'm sorry for the mistakes I've made.

@Klein, oh no, don't feel sorry. I wouldn't say these are "mistakes" but opportunities to learn.

Here is an example for a filter that might help: https://codesearch.wmcloud.org/search/?q=seperator&files=%5C.js%24&excludeFiles=(%5E%7C%2F)(node_modules%7Cvendor%7Cdist)%2F

Is there any way to exclude searches from some file path patterns using the CodeSearch tool?

I hate, hate tables. I was trying to add some patch-links and ended up butchering the whole table. Tried fixing it twice but failed. Afraid to annoy everyone with extra emails by my experiments, I'm leaving it like that for someone more experienced than me to fix it. I'm sorry.

Allowing the first comment that starts the discussion (what comes immediately after the title of the section), the so called "post" or "topic" or "question", stand aside in a way (maybe by highlighting it) would also help in navigating threads and ease participation in them. This would also formalize the discussion elements better: Post, comments and replies (and replies of replies in multi-level subthreads) by making it easier to see which is which and subsequently making it easier for you to choose how to participate in that discussion.

Keeping up with the collapsing/expanding part, if discussions could have the ability to be marked as resolved, maybe they could get fully hidden once they were marked like that. This would make help seeking pages appear less crowded I believe.

Beside thread collapsing/expanding, (and maybe comment/reply counting) being able to provide summaries might also be a good thing to consider. I was inspired by this long discussion to start the thread at MediaWiki and in it I've had to do the summary approach in a subsection manner. (See in bottom.) This may be also useful in closing remarks in RFCs.

In T305393#7829315, @Klein wrote:

I'd wish for the "implement VE / 2017 wikitext editor framework" solution personally because that would hopefully also come with extra features such as text formatting in summaries etc.

No, it probably wouldn’t. Summaries are used at a lot of places, and lifting a 18-year-old restriction (7c1b75d, although Phabricator refuses to show the diff for the interesting part, Skin.php, probably just because the author is written as Erik M�ller instead of Erik Möller) needs much more discussion than just this ticket. Exactly because edit summaries can’t be edited afterwards, letting users use various formatting would make it possible to create a hard-to-read edit histories (colors, font sizes, maybe even images) without a way to moderate them except for the total removal.

In T305393#7829281, @DLynch wrote:

It's technically doable but has a few dependencies:

• the @mention stuff in DT uses the VE / 2017 wikitext editor framework, which is currently not used in edit summaries; we'd either need to drop it in there or reimplement the completion widget to not depend on anything VE-related
• I'm not sure an API exists for fetching users who're involved in the page history (the one in DT uses a combination of gathering usernames that're on the current discussion and the query:allusers API)

In T304531#7800472, @Jdlrobson wrote:

@Klein it looks like https://gerrit.wikimedia.org/g/mediawiki/extensions/Score/+/d99a2722f62173ecc85e8e8108ee6e115cfca31a/includes/ScoreException.php#71 but note to fix this you'll also need to be setup to test this extension which might be a little trickier unless you are using something like MediaWiki vagrant.

@Jdlrobson, sorry for the noobish question but can you tell me what's the file's path that should be edited in the said extension? I'd like to help but I'm still not that versatile in these details. This seemed like a pretty straightforward job and I thought it could help me build more self-trust if I could get it done.

In T304205#7790077, @Tacsipacsi wrote:

This is a typical case where a screenshot helps a lot, especially to check afterwards that it has been fixed – if the space is no longer there, it’s impossible to tell whether the space has been added or you just referred to something else.

Maybe, instead of Special:MassMessage, Special:CreateMassMessageList can be considered as the targeted special page for the change to happen.

I believe that's coming because the https://translatewiki.net/wiki/MediaWiki:Translate-manage-import-ignore page doesn't exist yet. Someone with the needed privilege should create it with this text:

In T299638#7661840, @ShailRT wrote:

I think I have done it how can I send the push request?

@Tgr, take a look at this short discussion which led to the creation of the task. Apparently I had erroneously believed that you got specific emails from being replied to and from getting messages from threads you were subscribed + watchlist emails (which would make the total emails received from 1 action 3). This explains why in the original task I mentioned "Echo" and "bundling". Then I changed from 3 to 2 when I saw that reply notifications and comments on subscripted threads were actually already bundled. Please do check the aforementioned discussion as that would make everything clear and I don't want to make the thread any longer here by replicating the conversation.

General comment: At my community (SqWiki) in many edit-a-thons that we've held, the phrase "edit it normally, like you're using Microsoft Word" gets tossed around a lot by mentors and mentees when describing VE. It is generally considered a very beneficial thing that when you're editing, the overall page layout doesn't change and you can view your changes in real time, like they'd appear when "printed". I think that whatever route is chosen to be followed on this (I do think we need ways to distinguish between the two modes) we should be careful to preserve that characteristic as much as possible.

@Rjwilmsi, yes. I was thinking about newlines as the delimiter/separator. If we have 5 entries in 5 individual lines and try to have them pasted in normal settings, they get squeezed in 1 cell. Instead the initial format should be preserved and each line should be able to get automatically aligned in different individual cells, thus having them spread in 5 different cells.

Our CS1 redundant parameters in SqWiki went from almost 0 to 3k articles in around a week.
This link that was given to me some days ago by another user shows that there are more than 1k results only with the archive[-]url problem. And this is only for SqWiki that has less that 100k articles in total.

Was shown this task when I presented the same problem. It would be very nice if the matched case could be highlighted in Edit Filters. In SqWiki we have many cases when new users activate the bad words filter accidently because they create a full article on Content Translation Tool and one of the names mentioned there could be listed as a bad word in our language. After having written the full article they try to publish their changes only to find out they can't because of this filter and they ask for help. It takes quite some effort to find out what specific word caused the filter to activate and to solve the problem. Having this feature would tremendously speed up the process of finding false positives.

In T243604#6635970, @Aklapper wrote:

@Klein: Any news to share? (Asking as tasks shouldn't be stalled for too long.) Thanks! :)

@Legoktm, to be honest, to me it doesn't look much riskier than the current power admins/interface admins hold. Even then, maybe we could take extra steps like only giving that privilege to crats or a new kind of user.

@Legoktm, Wikimedia sites.