In T290717#7357773, @Zabe wrote:

@Mvolz is this still the case?

Could Legal do it?

A slightly edge-casey library is https://github.com/wikimedia/html-metadata which is not on gerrit and is also an npm package, so I'll need to point npm to the new location (Come to think of it I might be the only one with the rights to do that since mobrovac left? need to fix..). Happy to do that earlier rather than later but not be helpful as a template for other repos.

I think at this stage it makes sense to just move to gitlab instead so change the task to that ^-^

In T288811#7282816, @DannyS712 wrote:

Can this be made public if the credentials have been cycled and a new key created?

In T288811#7281764, @Mvolz wrote:

In T288811#7281761, @Mvolz wrote:

In T288811#7281744, @sbassett wrote:

Tagging Release-Engineering-Team as the ostensible owners of gerrit. It looks like the problem config file appears in PS2 and PS3 - not sure if we can remove those patch sets (or at least the config file/diff) from this change set's history?

@Mvolz - has the exposed key been deactivated or rotated? It likely shouldn't be used again, especially not within any kind of production envrionment.

It's not the production key fortunately but a currently unused one intended for beta but never configured. I can get it revoked upstream and ask for a new one.

I guess an easier solution would just be to revoke it actually!

In T288811#7281761, @Mvolz wrote:

In T288811#7281744, @sbassett wrote:

Tagging Release-Engineering-Team as the ostensible owners of gerrit. It looks like the problem config file appears in PS2 and PS3 - not sure if we can remove those patch sets (or at least the config file/diff) from this change set's history?

@Mvolz - has the exposed key been deactivated or rotated? It likely shouldn't be used again, especially not within any kind of production envrionment.

It's not the production key fortunately but a currently unused one intended for beta but never configured. I can get it revoked upstream and ask for a new one.

In T288811#7281744, @sbassett wrote:

Tagging Release-Engineering-Team as the ostensible owners of gerrit. It looks like the problem config file appears in PS2 and PS3 - not sure if we can remove those patch sets (or at least the config file/diff) from this change set's history?

@Mvolz - has the exposed key been deactivated or rotated? It likely shouldn't be used again, especially not within any kind of production envrionment.

I can temporarily silence this if you want, by commenting out the offending test and redeploying, at least for the time being? Doesn't seem to actually affect operation, at least. We used to actually probe www.example.com but that would cause errors like this too, and switched to our own stuff so uptime would be concurrent... is it a temporary DNS issue do you think?

connectivity hiccup probably

In T284345#7137909, @WMDE-Fisch wrote:

While playing with this locally I realized that, npm v7 uses a new lockfile version and whenever I run npm to install the packages it also updates the v1 lockfile to v2 adding a lot of diff overhead. - So I wonder if it might be useful ( when ever we are sure to stick with this version ) to run Libraryupgrader and mass adjust the repos.

Not sure if this a temporary hiccup / just things timing out, and if I should just try to deploy again or something more serious so filing :)

Not all citation templates have a DOI field, and only have a URL field. As long as we have this information, we should provide it, because some consumers will prefer to use the URL. If en wiki prefers to remove these with bots that's a preferred option imo. We can't delete fields that are being used on other wikis in the back-end just because of policy in en wiki.

@zeljkofilipin Thalia's handle is Tchanders but for some reason when I try to actually tag her it breaks Phabricator.

Came across this as well - triggered in reftoolbar (https://en.wikipedia.org/wiki/MediaWiki:RefToolbar.js) found this archived topic where it's suggested it's due to Ace being outdated and it's since been fixed* https://www.mediawiki.org/wiki/Topic:Tat8gxmbmjtpn5dl

I just had a request take nearly a full minute ... :/ 57293 ms

I've now changed the settings to respond with the following message to all new posts to the list:

In T278516#7046847, @Dzahn wrote:

for the record: it's also possible to request a shared google group that acts like a shared inbox for multiple people. So you can actually see which mail was read or acted upon on the group level. We do this for maint-announce mails.

Of course this still is a members-only group and group members need to be managed, but that seems to always be the case. noc@ itself is also a members-olny group, via the redirect to root users.

We can also do a special alias that does "forward to noc@ AND some other team email of the services team" but then it seems like the services mailing list we are about to remove here already was the team email address. Or is there another existing group address that is nowadays your team, @Mvolz?

(And what does drop b/c mean?)

Is there a related task for this somewhere? Or code? (Like if I did this today it'd all be fine, right?) :)

To fix this I've submitted a change to the template data.

In T263632#6702707, @alaa wrote:

2. The authors are different?

Yes, per arwiki user complain

In T281046#7043022, @ppelberg wrote:

@Chicocvenancio for, let's say, the last 10 citations you've tried to add using Citoid, how many have timed-out? Also, have you noticed any similarities among the attempts that timeout?

In T278516#7043057, @Legoktm wrote:

In T278516#7041242, @Mvolz wrote:

I've replied on the list, but we use this in citoid as a contact point for crossref to report traffic issues from us (I hope none of those are stuck in moderation :( ). If deleted we'd need to replace it with a different email; open to suggestions.

Typically noc@wm.o (goes to all SRE) is the entrypoint for external entities to reach out to us for traffic/abuse issues, we could either forward them onto you or set up a different alias that includes noc@ and you.

I've replied on the list, but we use this in citoid as a contact point for crossref to report traffic issues from us (I hope none of those are stuck in moderation :( ). If deleted we'd need to replace it with a different email; open to suggestions.

In T132308#7015612, @stjn wrote:

In T132308#7015604, @kaldari wrote:

The error is actually coming from the conversion into a standard JavaScript Date object, not MediaWiki parser function #time:

var DT = new Date(data.date);

The above code errors with 2020-03-XX, but is fine with 2020-03.

To be clear, I wasn’t talking anywhere about RefToolbar, just about the possibility that if some template code uses it for date formatting, those templates would break. So, my comment wasn’t related to Trappist the monk’s, I left it because of a tech news item.

In T132308#7015539, @kaldari wrote:

@Mvolz - Also here is my opinion on what the correct solution to the original problem is:

In T132308#6983683, @Trappist_the_monk wrote:

In T132308#6983334, @Mvolz wrote:

@Trappist_the_monk any chance of unearthing the old CS1 code to make these more human readable? Here's an example DOI for testing: 10.1016/S0305-0491(98)00022-4

Already done in cs1|2 sandbox; module suite update is scheduled for this weekend. See https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1#edtf_date_formats_as_cs1|2_date_parameter_values_(2)

This is now deployed. It does not make anything worse, because dates that cause CS1 errors still cause CS1 errors :).

In T132308#6959990, @Johan wrote:

@Mvolz As a general rule we prefer to announce things in beforehand, but it's not a blocker for minor changes that won't affect editing much. If things risk being confusing or create issues for editors, it's generally better to wait a week so we get the chance to announce it (next issue will be delivered on Monday).

In T132308#6958016, @Whatamidoing-WMF wrote:

In T132308#6856784, @Jc3s5h wrote:

editors will inevitably write 2011-12 when they mean 2011-2012. There is no way to tell if 2011-12 means 2011-2012 or December 2011. So it is an error and should always be flagged as such.

I don't think this is correct. It might be a potential error, but it is not necessarily an actual error.

Additionally, I think this potential error affects approximately one in sixteen possible dates in the YYYY-MM format. Consider:

YYYY-MM	interpretation
YYYY-00	not a valid month number, therefore a multi-year range
YYYY-13	MM ≥13 = not a valid month number, therefore a multi-year range
YY01-01	MM 01 to 12 are ambiguous when YYYY ends in 00 to 12
YY13-01	year–month, because 13 > 01

I don't think that the citation template should be trying to spot typos.

It looks like they have some of the same ones from en Wiki: Template:Citation, Template:Cite web, Template:Cite book, Template:Cite news... but no Template:Cite journal. There's also no template data, so essentially it'd have to be enabled in English if done as-is!

In T97936#6945876, @cscott wrote:

This came up again on twitter wrt "cite web": https://twitter.com/wikkit/status/1375091344465666048

It would be nice to allow at least certain common cases initially, eg "cite web" => "cite news" on enwiki, apparently "cite book" to <something> on dewiki. That seems to be what @Mvolz was suggesting:

In T97936#1947829, @Mvolz wrote:

Yeah, that would be the first case. We'd have to discard any invalid fields
but as long as many of the fields were in common it might not be too bad.

In T132308#6946740, @Johan wrote:

@Mvolz Thanks for adding the user-notice tag. Is this just about the ambiguous days (the latest patch), or the task in general?

Or, rather: How would you suggest phrasing it in a couple of simple sentences for Tech News?

The date - unfortunately seems to be javascript loaded entirely. Might not be possible to get this using html scraping.

In T278281#6943795, @John_Cummings wrote:

In T278281#6940634, @TheDJ wrote:

I'm not sure how zotero returns channel name and date published, but it's not being returned by citoid at least. The fact that it is on YouTube can be retrieved from the "libraryCatalog": "www.youtube.com" attribute.

thanks, who might know how to fix this?

So I guess my question is, what would be the purpose of using wikidata for this? It doesn't seem like it would really solve any problems or indeed work very well.

Multilingual template data already exists!

In T274813#6853220, @ppelberg wrote:

@Mvolz: do you have availability to enable Citoid at ig.wiki within the next month (read: by 24-March-2021)?

Is there any reason the Wikipedia library can't just redirect these urls itself to the unproxied url if it's a bot instead of a logged in user? (You could check user agent string you could use if you want to make an exception just for us- it's "Citoid (Wikimedia tool; learn more at https://www.mediawiki.org/wiki/Citoid)") .

It looks like from these examples it's bad metadata in the source.

Since I didn't get any further information about this bug to duplicate it, I'm closing as invalid. Feel free to re-open if you can provide further information!