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!

In T132308#6856343, @Trappist_the_monk wrote:

In T132308#6856035, @Mvolz wrote:

I'd be happy to consider switching to a different way of representing partial dates that doesn't require the use of English, but unfortunately no one has suggested a standard that doesn't that I've noticed @Trappist_the_monk you suggested IETF but I had a look and couldn't find a partial date representation there - did I miss it maybe?

Isn't that what most of the whole long discussion has been about? The current IETF at Level 1 §Unspecified digit(s) from the right at item 3 reads:

Year and month specified, day unspecified in a year-month-day expression (day precision)
Example 4 ‘1985-04-XX’

Does that not provide a way to do month year dates that don't require English?

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)?

In T132308#6852980, @Jc3s5h wrote:

@Mvolz you write "we've been using EDTF". Who is we? And what discussion on the English Wikipedia are you referring to.

I'd be inclined to say No! The specification states " Level 0 specifies features of ISO 8601-1". ISO 8601 states it must be used with the Gregorian calendar. In addition to Gregorian, Wikidata needs to support the proleptic Julian calendar. Wikipedia needs to support the proleptic Julian calendar, the Julian calendar as observed in Rome, and the calendar of the Roman Republic.

In T132308#6335481, @Aklapper wrote:

In T132308#3305898, @mobrovac wrote:

The patch relaxing date validation is now live on all projects. It incorporates some of the suggestions outlined in this task, so please test it. Setting the task as stalled until further input.

Resetting task status as three years should have been enough time to provide further input (and as tasks should not be stalled forever).

In T258790#6819135, @awight wrote:

Even the wikitext 2017 editor experience is unhelpful. I learn "Syntax error in JSON." with no line number, and no error highlighting in the source view.

What I would prefer here is that we *allow* the user to save bad TemplateData JSON, and instead of showing an error on save, we show it as a warning when viewing the page. This is consistent with other extensions such as Cite, which *never* blocks save but instead injects bold red text in the content. (For comparison, we discuss how to better render reference errors in T238061.)

In T273741#6820298, @Joe wrote:

In T273741#6816099, @Joe wrote:

In T273741#6815874, @Majavah wrote:

Is the effect that the block will have in the app known?

No, hence we tried to reach out to them, although it seems that there is no good way to get in touch with them through email (I sent an email to all publicly available channels, only to get back an autoresponder that assumes I'm an user of the app and asking for my phone number). I eventually resorted to DM their CEO on twitter.

I think this is more than enough courtesy on our part. Anyways, the block will clearly link to this task as the reason for the block, see https://gerrit.wikimedia.org/r/c/operations/puppet/+/663004/4/modules/varnish/templates/upload-frontend.inc.vcl.erb#380, so that whoever is responsible for this can figure out how to reach us.

Small - and happy! - status update: we managed to get in touch with the app developers, who confirmed our suspicions were correct, and promised a quick turnaround in posting an updated version of the application. We will thus hold back the banning of the url for now, awaiting for confirmation of the desired effect to reduce the potential harmful impact on the application users.

Given how much "sample code" we found around the internet using that url, it might still be a good idea to merge the patch later just to prevent this from happening again.

This is now deployed. I have checked reftoolbar and VE citoid and seems to work okay but if there any other tools this causes problems for it can be reopened.

In T271438#6740988, @matmarex wrote:

The site itself defines the incorrect URL. From the HTML source of https://www.transfermarkt.de/wechsel-im-winter-brentford-verpflichtet-dervişoğlu-watkins-verlangert-langfristig/view/news/342949:

<meta property="og:url" content="https://_/wechsel-im-winter-brentford-verpflichtet-dervi%C5%9Fo%C4%9Flu-watkins-verlangert-langfristig/view/news/342949" />

"map" refers to the mapping between the parameters names of the template and the parameter names of the consumer.

(To answer the question about caching, we don't cache these results.)

The end point is a red herring; I was able to reproduce this instability on the wikipedia endpoint just by making the same request twice in a row. I got the newspaper one and then the webpage one.

Is there another use case other than on translatable pages?

I should probably also point out that earlier versions of the citoid tool on wikidata for wikidata references used open refine and produced better results.

This looks like a mismatch between VisualEditor and Citoid - I had this issue locally too on master with Citoid until I updated VisualEditor to master. Some code was moved about between the two.

In T160845#6525484, @gerritbot wrote:

Change 632732 had a related patch set uploaded (by Mvolz; owner: Mvolz):
[mediawiki/services/citoid@master] [WIP] Divide authors by first name and last name

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

In T115224#6415888, @Cyberpower678 wrote:

I would like to emphasize that the availability API has seen improvements since 2017. Is it possible you can redo your investigation a bit?

In T108713#6434245, @iamjessklein wrote:

I agree with @Amire80 - the issue here is really the word "form". If we were in an universe where the term "template" wasn't such a loaded word, I'd suggest "Basic Template".

The hold-up seems to be eventstreams; it actually uses a fork of service runner, and the fork is missing the feature, so it's slightly more complicated to update. https://github.com/wikimedia/service-runner/tree/prometheus_metrics

It looks like they've released a v2 of their search api since I last looked that returns JSON: https://developer.api.oclc.org/wcv2 (instead of MarcXML or Dublin core, which is what we use now).

I think switching to that is a good idea, although even just using their sample input there's still a bit of junk left over in the authors field (a stray period!) But probably better than doing that processing ourselves!

In T160845#6500357, @kaldari wrote:

@Mvolz - I would be fine with that, but there are a couple caveats:

• The refToolbar code isn't foolproof, and in fact, there is no foolproof way to handle the WorldCat author data since its formatting is just too inconsistent.
• It currently handles "Jr." and "Sr.", but not suffixes or prefixes that may exist in other languages.

If you want to use it, the most recent version of the code is at https://github.com/alexz-enwp/reftoolbar/blob/master/lookup.php#L139.

In the meantime, I'll see if we can ask our contact at WorldCat if there are any better options.

In T160845#6459280, @kaldari wrote:

@Whatamidoing-WMF - It looks like the Library of Congress is using the same "weird" punctuation and capitalization as WorldCat:

• A world undone : the story of the Great War, 1914-1918
• How we get free : black feminism and the Combahee River Collective
• Ada, the enchantress of numbers : a selection from the letters of Lord Byron's daughter and her description of the first computer

Maybe it's some kind of library database standard or maybe the LOC is reusing WorldCat data for their own books.
@Mvolz - Can you report the titles that you get for the following ISBN numbers via Zotero's API: 9781608468553, 9780553803549, 9780912647180. Just want to confirm that they are similar to those returned by the LOC search.

In T219919#6478632, @fgiunchedi wrote:

It looks like citoid is now on k8s but still using gelf for logging, possibly the easiest at this point is switching to stdout logging like other node services on k8s. What do you think @Mvolz ?

It's likely a difference between Cite book on en wiki and the template that is used on ar wiki for books?

I'm unable to replicate this, it looks like it works: https://en.wikipedia.org/api/rest_v1/data/citation/mediawiki/10.1098%2Frsta.2014.0376

Just FYI but the reason we put maps above parameters is because there are often a lot of parameters, which means that in many cases the edit maps visible button isn't visible because it's "below the fold." This was an intentional design decision we made.