Hi. Two questions.

1. T378833#10284757.
2. Looks like the archiving script has a bug. It fails if there is a target page already. See here, the page of @Mooeypoo.

Thank you.

And where are the rest of group 1 wikis with working Flow?

In T223772#10248039, @Trizek-WMF wrote:

Do you mean that date is not used when pretty is not defined? Or something else?

In T223772#10247886, @Trizek-WMF wrote:

if it is not supported, the "date" format is used.

I see. But how about to check if there is such a field in the correspondent php file?

In T223772#10231769, @PerfektesChaos wrote:

I guess it would be sufficient in such cases to add the dir to the table cell:

before ||dir="ltr"| {{#timef:now|date|en}} || next

This is much shorter than introducing a <span> element.

Sure, I've started with it and changed to make it more visual to you.

I thing we're talking about different things. Here you are, on rtl page:

I can understand your 2., but I don't agree with 1., because wrong directionalty shows something like "2024 in October, year 14".

In T223772#10225457, @Tacsipacsi wrote:

In T223772#10225266, @IKhitron wrote:

What about "pretty"? There are still enough languages that show not "pretty" and not "date", but just weird irrelevant text.

I think it’s because those languages have no pretty localization, so they fall back to the US English order (but with translated month – and year and day, if applicable – names), although mentioning a few specific examples could help better understanding the situation. (Of course, if it’s really the missing localization, the solution is adding it. Maybe a new task could be created in which people speaking different languages could collect the correct formats – I’d be happy to fix them as a developer, but I have no idea what the correct format is in Hebrew, Chinese or Czech.)

In T223772#10224493, @tstarling wrote:

In T223772#10210207, @IKhitron wrote:

I just saw it in the Tech News. Thank you. Could you please write a manual?

Done.

3. The third parameter is a language code or "user". The default value is "user".

The "user" keyword was not implemented. Instead we added {{USERLANGUAGE}} (T4085). The default value is the page language, not the user language.

In T375975#10216060, @Jdlrobson wrote:

Hey all this looks like it caused T375975

I just saw it in the Tech News. Thank you. Could you please write a manual? Because I've tried

{{#timef:2000-09-01|F|en}}

and get an error message. Actually, 49 from 53 standard tests failed, and the rest four showed wrong date.
UPD: I've tried to understand it by myself, and this is what I get:

1. The first parameter is a regular datetime parameter from #time and #timel. The default value is "now"
2. The second parameter is "both", "date", "time" or "pretty". The default value is "both".
3. The third parameter is a language code or "user". The default value is "user".
4. For the local time #timefl should be used instead.

I do not know if this is right, and if there is something else. Also, pretty does not work in a lot of languages.
UPD: And also, there is a total directionality problem. Until it is fixed, every usage of #timef should be wrapped by

<span dir="{{#dir:<third parameter>}}">...</span>

Until the bug will be fixed, I've created this wrapper template.

You mean it's because the log was from before I temporarily left the admin group? I see, weird. Thank you, my bad. I'm closing the task.

In T375265#10163823, @Bugreporter wrote:

This is because content models can be changed by admins, and in ruwiki, engineers (which you are one), but not interface admins. This is not a regression.

Great, thanks.

FMHO, there should be a link to a list of these 11 wikipedias from the Tech News. I came here to check some wikipedias, but couldn't find such a list, maybe even missed it without a direct link.

Looks fine now.

UPD. There is only testwiki again. Special:Version on Mediawiki:org shows a rollback.

I see. Still don't know how could I see that.

In T195546#10075992, @Pppery wrote:

No.

But see Tasciaspi's comment on the paste:

However, you don’t need to know the namespace to access the page: you can use the curid index.php parameter instead, passing the very first number in the given line to it. For example, if the line you’re interested in is

angwiki:  renaming 8321 (1,'Ƿicipǣdia:Ȝemǣnscipe_Ingang') to (1,'Ȝemǣnscipe_Ingang')

you can access the concerned page at https://ang.wikipedia.org/w/index.php?curid=8321 – MediaWiki will figure out what the correct namespace is.

So, is there a way to get a right log?

I'm just curious, why wasn't the standart Wikicode editor Search popup extended with the new functionality instead of creating two working at the same time?

In T110645#10014240, @01tonythomas wrote:

The expected Flow shutdown will kill the Newsletter extension, FMHO, if there will not be done adjustments in the extension code.

This is news for me (was away for a long time). From what I know, we are not directly dependant on Flow. Or, do you see something which I dont, @IKhitron?

Answering to the wikitech letter. As a heavy user of the extension over the years I can add my five cents.

1. I really hope there will be local notifications, so the readers can see their content immediately, without a need to go to Meta.
2. The expected Flow shutdown will kill the Newsletter extension, FMHO, if there will not be done adjustments in the extension code.
3. The Newsletter extension is a great thing, and it should continue and evolve.

Yes, good idea. One possible impact is that looks like it kills the Newsletter extension, except there will be found an alternative way to keep it.

In T368034#9909566, thiemowmde wrote:

By the way, the gadget has apparently no support for keyboard navigation, one of our most basic Accessibility requirements.

Well, @thiemowmde, it took us always a month, but I've implemented it by your request. So much time because I've made it at least ten times more functional than the bare minimum, and every key was needed to be coded and approved in the metro project. Hope you like it, on both maps. Thanks again for paying my attention to this issue.

Maybe there is a way to add to the algorithm a paragraph "if you show subsubpage in the line X, but its master page exists and wasn't shown above, then show the master page in the line X+1?"

Done.

I think the task should be reopened, there were a couple of cases in the last few days.

In T368034#9916126, @TheDJ wrote:

@IKhitron This would have started affecting sites in the week of june 11th.

In T352320#9777680, @gerritbot wrote:

Change #1028849 had a related patch set uploaded (by Jack who built the house; author: Jack who built the house):

[jsdoc/wmf-theme@master] js: Fix redirecting for links to methods and properties

https://gerrit.wikimedia.org/r/1028849

Could anyone, please, tell me, for inwiki purposes, when exactly the noresize code was changed in the New Vector, so I could tell the community when the problem started. Thank you in advance.

In T368034#9911279, @TheDJ wrote:

It's a multilevel problem. I discocered that the metromap module in turn uses https://ru.wikipedia.org/w/index.php?title=Шаблон:Одноразмерная_карта_изображений

It uses a width for the outside, and then uses that same with for the image size, even thought hat is supposed to be 10pixels smaller.

This is where the root problem is (the patch is just a tidy up on the MediaWiki side).
Fix: https://ru.wikipedia.org/w/index.php?title=Шаблон:Одноразмерная_карта_изображений&diff=prev&oldid=138474305

Thank you all for this. I'm not so sure I'm smart enough to understand all this but I'll try my best at least to evaulate it as described. I'm glad you agree it's not the gadget problem.

In T368034#9909566, @thiemowmde wrote:

I don't think it can be an issue with the SVG rendering because it would be equally broken in all skins then.

I tried to dig into the gadget, but it's surprisingly complex. As far as I can tell what it does is:

1. A normal 270px thumbnail of https://commons.wikimedia.org/wiki/File:Moscow_metro_map_sb.svg.
2. It looks like there is a <map> with a series of <area> shapes. But that is completely invisible and only used to make the areas interactive when hovering them with the mouse.
3. There is a transparent <canvas> on top that's probably used to display the colored lines. But I couldn't figure out where they come from.

One thing I noticed is that it's not an issue with the position, but with the size.

• In the upper left corner everything is almost correctly placed, but more and more wrong in the lower right corner.
• I believe this issue is also reflected in the code. There are a lot of "262" in the resulting HTML that should probably be 270.

I don't know where this code is that calculates these width and height values.

I don't think you should check the gadget at all, just the area tags in the safemode. But if you insist, there is a completely separate sandbox with completely separate sandbox javascript code, and you can edit them all, if you wish. The area coordinates are here.

By the way, the gadget has apparently no support for keyboard navigation, one of our most basic Accessibility requirements.

Great idea, thanks, we'll consider it.

The gadget author suggests it could be T265549.

In T368034#9909206, @doctaxon wrote:

Can you remember when the hovering behavior was okay last time?

Maybe if I could know, what changed in the New Vector in svg rendering on in area tag, I could understand what to look.

In T368034#9909370, @thiemowmde wrote:

What probably happened is that some of the code (CSS?) in the gadget is a little fragile and starts to behave odd depending on the skin. It's entirely possible that such issues are invisible for a very long time and only become visible much later together with seemingly unrelated changes in MediaWiki, skins, or extensions.

This is possible, of course. But I have no idea how to find what part could volitale, when the gadget do not distinct between skins.

In T368034#9909370, @thiemowmde wrote:

Sorry, my comment was not very helpful. What probably happened is that some of the code (CSS?) in the gadget is a little fragile and starts to behave odd depending on the skin. It's entirely possible that such issues are invisible for a very long time and only become visible much later together with seemingly unrelated changes in MediaWiki, skins, or extensions. Still I suspect the issue is probably in the gadget and needs to be fixed in the gadget.

We have https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend that aims to cover situations like this. I can't tell if it applies here.

In T368034#9909340, @Aklapper wrote:

In T368034#9909314, @IKhitron wrote:

Of course you can't, because without the highlighting script you can't see any area at all, and do not know if it's broken or not.

The initial task description does/did not mention a local script. Thus I pointed out how you can check if a local script is involved before filing a task: Trying safemode, as mentioned on https://www.mediawiki.org/wiki/How_to_report_a_bug . Better bug descriptions often help to fix issues faster.

And I think that "Local-Wiki-Template-And-Gadget-Issues" has nothing to do with the fask, because there is no problem in the gadget, it just helps to see the New Vector problem.

Sounds like that local gadget code needs to be adjusted to work with all skins.

In T368034#9909337, @doctaxon wrote:

Can you shift the hovering overlay to (40,0) pixels by a change of this community .js file?

In T368034#9909260, @Aklapper wrote:

Removing SVG (see its dsescription).

Cannot reproduce on https://ru.wikipedia.org/wiki/Шаблон:Интерактивная_схема_Московского_метрополитена?useskin=vector-2022&safemode=1 so this is custom local code that needs to get fixed.
See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts for how to use safemode.

For future reference, please use the bug report form (linked from the top of the task creation page) to create a bug report, and fill in all the sections in the template, instead of deleting them. Thanks.

In T368034#9909214, @thiemowmde wrote:

I might be wrong, but as far as I can see this has nothing to do with MediaWiki, but is a community gadget: https://ru.wikipedia.org/wiki/MediaWiki:Gadget-ondemand-imagemapHighlight.js. The skin has no knowledge about this.

In T368034#9909206, @doctaxon wrote:

Can you remember when the hovering behavior was okay last time?

New Vector:

Well, for the last 21 hours no querry could run. So it's pretty bad.

I didn't see any complains this time on hewiki forums.

-1. But I think it's fine to have a non default preference for this. So anyone who does want to get these mails could turn this on.

In T366461#9857814, @DannyS712 wrote:

@IKhitron if adding

#ext-globalwatchlist-toolbar {
	background: var(--background-color-base)
}

is really all that is needed, maybe you want to try sending a patch yourself and I can review it?

I hope it will work soon, because now I can't delete any item, not just some.

Any solution that avoids the situation with script does not run without any explanation is fine.

Yep. Exactly. There are a lot of people that upload files with wrong licenses onto local wikis and Commons. There are special forces which are supposed to stop them, VRT. There will be the same count, or maybe even more, people that will do it inline. Who will recognize and stop them? Or the VRT groups are supposed to do much more work? And to learn how to do this at all?

A silly question. Apologies if it was already mentioned before and I missed it.
Where exactly will be the license? And how exactly it will be checked, and by whom, to avoid copypasting inline some copyrighted svg file, such as a company logo?

Thanks, done.

In T353996#9721338, @Samwilson wrote:

(By the way @IKhitron, the file you attached is restricted; could you change its visibility?)

A pity.

Well, there is a new button "delete" on mediawiki.org. Clicking on it makes the item disappear. Refreshing Special:EditRecovery brings everything back. Houston, we have a problem.

There are much more cases when this needed, see here.

Looks like it indeed.

My attention was drawn to this bug after I saw this, when moving the help icon to its appropriate place:

In this case we definitely should consult to community first, because otherwise, from my experience, nobody will pay attention. A week discussion will put it on the radar.

"Opt-in" means that newcomers to enwiki, for example, do not get it by default, @MusikAnimal?

I request to cancel the change for hewiki, please. The community decided to ask this, in Village pump, with more than enough voices, at least 31 supported from 32 that participated. You can find the voting over here. Thank you.

Well, I tried a couple of times to explain you it has nothing to do with all this, with new pages for example, only with any edit in any article. I can see no way to explain more.

This is something else, of cource. For me, if some user can't be trasted to make their one edits in articles, they for sure can't be trusted to have an Interface admin flag, which was created just because the Foundation didn't think the admins (sic!) were trusted enough to have. You definitely can have different ipinion.

In T356044#9587090, @Xaosflux wrote:

In most WMF projects "autopatrol" is only in sysop, bot. I can't see why we would want to prevent a community from assigning someone this group if they want to without also making them one of those other groups. Additionally, the assertion that "everyone has" autopatrol is false. For example, see ruwiki. Not only do they have non-admin/non-bot intadmins, but they also do not have anygroup with autopatrol. dewiki is deprecating patrol as well (see T316393).

This is not a software security concern, and is not a globally supported default setting. Task should be declined.

Don't know what are the relevant tags.

Seems obvious, but OK.

In T170001#9574231, @MusikAnimal wrote:

If anyone wants to test this, CodeMirror 6 is installed on https://en-rtl.wikipedia.beta.wmflabs.org and https://he.wikipedia.beta.wmflabs.org. We have not done any additional work yet for RTL support other than what comes stock with CodeMirror, but two things I'd like to look into are:

• Add bidi isolation to tags such as <div class="foobar">
• Use LTR inside the content of applicable tags like <div dir="ltr">. We probably can't do the same if the direction is changed with a template, unfortunately.

Are there other things I should be looking at? Most of the things mentioned at T170001#3676449 by @IKhitron should be fixed now.

Any help with testing is appreciated :) Thank you!

In T355639#9574561, @Iniquity wrote:

In T355639#9574560, @IKhitron wrote:

In T355639#9561700, @IKhitron wrote:

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

While we're waiting for the answer, one more question, please. When you say in the Tech News that "Your community can ask to retain the old configuration on your wiki before this change happens.", what do you expect? A local concensus? A request from random user? A request from somebody that actualy used this? Thank you.

For both questions, a link to the discussion on the wiki with a request to keep everything as it is + minimal consensus is enough.

In T355639#9561700, @IKhitron wrote:

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

Really hope this is the case. The current text looks like "write us, we make statistics, and abandon the current task, if there are a lot".

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

Hi there. A couple of questions.
If patroller X has a patrolling script that adds tags to some existing edit, will it work?
If AbuseFilter triggered by autoconfirmed adds tags to theirs edit, will it work?

In T356984#9544519, @IKhitron wrote:

Well, I've just tried four most significant scenarios, and it works fine.

Wow, I created a task, a d didn't even remember the previous one that I created in 2017 wasn't fixed, thought it's a new bug.