Done, and updated Web2Cit-Server to use this.

This one should be solved. @Superzerocool, could you please confirm? Thanks!

Addressed both in Web2Cit-Core and Web2Cit-Server.

Unordered array comparisons disabled in 1d643ece.
Pending merge into Web2Cit-Core's main, and updating Web2Cit-Server.

One alternative to compare arrays independently of the order of their items could be:

1. sort both arrays alphabetically
2. if one array is shorter, equate its length to that of the longest array by adding undefined items; create different versions of this extended array with the undefined items in different positions
3. compare one array vs all versions of the other array, 1st item vs 1st item, etc; return the highest score

Unordered array comparisons disabled in 1d643ece.

Thanks for pointing this out! I'll work on T302591 as soon as possible then. Marking this one as depending on that one.

The server does fail with a 404 error if both tests and templates files do not exist, or if no paths have been configured in any of them, as shown in this example.

Probably this is because Web2Cit-Core automatically includes a test case for any paths for which a template has been configured in the corresponding templates.json file.

Implemented in 89b9f932.

Implemented in 89b9f932.

Implemented in 89b9f932 and deployed.

make sure that for each field we always return the output, test and score properties, even if they are undefined

I think that the best we could do is convert things like spanish to its canonical form es.

Note that there are some values that, although valid for CS1/2 templates' language parameter, would not pass Citoid validation. For example, abq-latn, or es-419. We may have to report this to Citoid.

In addition, consider checking this enabled flag from within the credit's labelChange event handler, as it could be the case that it remained set from a previous call which did not trigger it (see T310656).

I wonder whether addressing T310653 would solve this.

Done: https://gitlab.wikimedia.org/diegodlh/w2c-gadget

Implemented on the translation-tests branch.

Implemented in test-configuration branch and merged into main.

Fixed in test-configuration branch. Added a fetchAndLoadConfigs method to the Domain object prototype.

Fixed in test-configuration branch. Now Webpage objects are created via the getWebpage method of a WebpageFactory object included in the Domain objects.

Fixed in test-configuration branch. The Domain object now includes a WebpageFactory object, with a getWebpage method.

Noting that this also happens when importing the item into Zotero using the Zotero browser connector.

This feels related to T290834. Both have in common that we are getting an intermediary page, not only breaking translation, but also and more significantly, loosing the original URL. That is, if the user does not spot the error, they will insert a citation with a completely useless URL.

Alternatively, we may also support defining translation procedures for the URL field.

This also affects Web2Cit (a tool to collaboratively work around automatic citation problems), both where it relies on Citoid (i.e., Citoid selection steps) and where it relies on webpage's HTML (i.e., XPath selection steps). I hope it's OK that I add the Web2Cit-Core tag too.

Another point is that having separate templates for separate wikis would allow wikilinking to pages in the fields

Fixed in 12da4a7a. Pending deployment.

Because a date transformation step is included in the fallback template (see T308354 for a discussion of whether this should continue to be the case), partial dates returned by Citoid, some of which may be incompatible with English Wikipedia's citation templates (see T132308), are (incorrectly) force-coverted to full dates. For example, 2020-12 is converted to 2020-12-01, and 2020 is converted to 2020-01-01.

what about adding a $wgCitoidEDTF boolean option (just as we have $wgCitoidFullRestbaseURL) to configure on a per-wiki basis whether we want 2010-12 (false) or 2010-12-XX (true) dates? Then, inside CitoidInspector's populateTemplate function, if $wgCitoidEDTF = true, we may append -XX to YYYY-MM values in any field mapping to the date base field (i.e., date, dateDecided, filingDate, issueDate and dateEnacted).

Thanks again for your feedback, @AlexisJazz!

I've been experimenting with JSON-LD selection. What I'm doing so far is:

1. Concatenate multiple JSON-LD objects in a webpage into a single array (some webpages may have more than one JSON-LD object)
2. Use JSONPath to select nodes.

Thanks, @AlexisJazz. I've just fixed this in 59e0858e. It should be working now. It tried it with the four types of usernames that you mentioned.

Try adding itemType and title fields to your template. Use the default procedure for both. This should fix the "I don't see a difference in the output" of the problem.

Fixed in ee84866d.

I think this is related to this bug here: T132308. In short, the English Wikipedia (and apparently *only* the English Wikipedia) rejects dates in the YYYY-MM format (when the day is unknown or unspecified) because, they argue, could be mistaken for a date range. For example, 2010-12 could either mean "December 2010" or "2010-2012". As mentioned in that (long) thread, the Citoid team tried to fix it with 2010-12-XX (for example); but although it works in the English Wikipedia, it fails in all others.

Thank you, @AlexisJazz! I've opened a separate task to discuss this, so we don't continue detouring from the topic of this task (i.e., fixing Citoid response for Condé Nast publications). I know it was me who started it, sorry: T309310

Thank you very much for your interest in Web2Cit, for helping us test it, and for reporting the issues you found! It's very helpful for us.

At Wikimedia Hackathon 2022's Web2Cit session (T308449) we configured Web2Cit translation for news.yahoo.com domain. Using our user script, Wikipedia's automatic citation tool now shows correct citations for webpages from that domain.

At Wikimedia Hackathon 2022's Web2Cit session (T308449), @Mvolz commented that having separate Web2Cit configurations per Wikipedia may be useful for the specific case described in T132308. That is, that incomplete dates returned by Citoid (e.g., 2010-12, meaning December 2010) throw an error in English Wikipedia citation templates, to avoid confusion with date ranges (i.e., 2010-2012). As described there, it was tried with -XX at the end (i.e., 2010-12-XX), but whereas accepted by English Wikipedia, it was rejected by other Wikipedias.

Hi! I just learned today (at Wikimedia Hackathon 2022's Web2Cit session, T308449) about the problem of incomplete dates (e.g., 2010-12, meaning December 2010) being rejected in English Wikipedia because they could be confused with date ranges (i.e., 2010-2012). From what @Mvolz commented at the session, and from what I managed to read above, it was tried to make Citoid return 2010-12-XX instead, but that fails in other Wikipedias.

These invalid XPath expressions are not being caught at config validation because for some reason jsdom's document.createExpression() is not failing on them. Reported to jsdom here.

Given a Target URL, the 3-file set defined for the most-specific subdomain is used

Because transformation step types are defined within a oneOf object in the templates json schema, the default value of the itemwise property is not being used

Logging both Citoid raw and Web2Cit citations (returned when the server is used with option citoid=true, as is the case with the Web2Cit-Gadget) would help us evaluate if Citoid's coverage gap is narrowing with Web2Cit (Web2Cit-Research).